에이전트가 쓴 코드, 검증보다 다음 결정을 위해 이해해야 한다는 주장

프로덕션에 넣을 커밋이면 내가 이해할 때까지 코드를 읽어야 함. 결과의 책임은 내가 지는 거고 에이전트가 대신 질 수는 없음.

읽기만으로는 부족함. 예전에도 테스트와 코너 케이스, 코드베이스 담당자의 도메인 지식이 있었는데 지금은 코드 생산량이 3배에서 5배라 읽다가 결국 훑게 됨.

병목이라는 말부터 과장 같음. 코딩이 원래 유일한 병목도 아니었고, LLM이 그 자리에 새 병목 열 개쯤을 만든 거래가 좋은지 모르겠음.

팁은 유용해도 AI 설명을 믿고 코드 소유자가 되는 길은 위험함. 복잡도가 쌓이면 모델은 설명도 환각할 수 있으니, 먼저 튼튼한 구조로 설계하게 만드는 방법이 필요함.

내가 아키텍처를 잡고 방향을 주면 LLM은 꽤 잘 따라옴. 사업 요구 같은 비기술 조건까지 포함한 시스템 설계를 완전히 맡기기에는 아직 멀었다고 봄.

우리 팀에서 LLM이 만든 PR 설명은 대체로 싫어함. 기계적인 변경을 길게 늘어놓을 뿐 왜 바꿨는지는 모르고, 이해의 원천도 LLM이면 그 설명으로 LLM 오류를 검증할 수 없음.

질문을 제대로 하고 맥락을 주면 PR 설명은 꽤 쓸 만하게 나옴. 문제는 기본 출력이 아니라 프롬프트와 팀 규칙을 안 정한 쪽일 수도 있음.

내 불만은 Claude가 원래 의도를 아는 사람이면 3줄로 고칠 일을 200줄 PR로 만든다는 점임. 동료가 이해 없이 그대로 밀어 넣으면 불필요한 복잡도와 장황한 설명을 내가 떠안게 됨.

이해 안 되는 에이전트 코드는 버림. 읽어도 불명확하거나 설명을 많이 요구하면 처음부터 다시 시키거나 내가 직접 씀.

바꾸려면 너무 많이 손대야 하는 코드도 같은 신호로 봄. 리뷰하기 쉬운 변경을 요구하고, 안 되면 코드베이스를 리팩터링해서 작은 변경이 되게 함. 코드가 싸져도 적게 쓰는 편이 낫더라.

이해는 원래부터 병목이었음. LLM은 에디터에 문자를 치는 쉬운 일을 빠르게 하지만, 문제를 이해하고 최선의 해법을 고르는 어려운 일에는 중립적이거나 해로울 수 있음.

사람에게는 제한된 이해 예산이 있는데 LLM은 그 예산을 훨씬 많은 코드와 프로젝트에 쓰게 만듦.

문제는 LLM 이전에도 있었음. 동작은 하지만 시스템의 모델을 깨는 코드는 그럴듯해서 경고가 안 나고, 그 모델을 기준으로 보는 사람이나 LLM만 알아챔. 다만 LLM은 모순된 모델도 계속 붙잡으니 권위자가 될 수는 없음.

코드에서 모델은 대개 암묵적이라 코드만 보고 문서를 만들면 기계적인 설명이 나오기 쉬움. 모델을 코드와 따로 문서화하거나, 언어 추상화로 모델을 코드에 박아 코드와 모델이 어긋나지 않게 해야 함.