오늘의 프론트 페이지에는 '이해하지 못하는 AI가 작성한 코드를 어떻게 처리할까요?'라는 제목의 Ask HN 글이 올라왔는데, 246개의 포인트와 거의 400개의 댓글이 달렸습니다. 이 비율 자체가 하나의 이야기입니다. 사람들은 그 코드가 작동하는지 여부를 묻는 것이 아닙니다. 오히려 그것이 작동한 후, 아무도 이유를 설명할 수 없을 때 무슨 일이 벌어지는지를 묻고 있습니다.
그 질문은 우리가 아직 다루지 않은 계층에 속합니다. Custody(#65)는 그 자산이 당신의 손에 있는지 물었고, Provenance(#64)는 그 바이트가 당신이 생각하는 바로 그 바이트인지 물었습니다. 반면 Comprehension(이해력)은 실제로 시스템을 운영할 수 있는지를 결정하는 질문을 던집니다: 이 시스템을 소유한 사람들이 압박 속에서 그것을 변경할 만큼 충분히 잘 이해하고 있는가?
왜 이해력이 계층이고, 감정이 아닌가
모든 시스템에는 두 가지 비용이 있습니다. 하나는 구축하는 데 지불하는 비용이고, 다른 하나는 현실이 변하여 시스템 스스로 답해야 할 때마다 지불하는 비용입니다. AI 지원은 첫 번째 비용을 강력하게 공격하고, 두 번째 비용은 조용히 공격합니다. 이 청구서는 숫자의 형태가 아니라 모양의 형태로 도착합니다: 사고 대응(incident response)은 느려지고, 변경 사항은 더 위험해지며, 온콜 로테이션(on-call rotation)은 잘못된 방식으로 고요해집니다.
이해력 부채(Comprehension debt)는 '나쁜 코드'가 아닙니다. 나쁜 코드는 읽고 싫어할 수 있는 코드입니다. 이해력 부채란 읽기에는 문제가 없고, 테스트를 통과하며, 배포되지만, 테스트가 다루지 않는 상황에서 어떤 일이 벌어질지 예측할 수 있는 사람이 없는 코드를 말합니다.
- 녹색 테스트(Green tests)는 이해도 그 자체가 아닙니다. 테스트는 한 번 생각했던 동작이 여전히 유효하다는 것만 단언합니다. 아무도 생각지 못한 경로에 대해서는 아무것도 말해주지 못합니다. 모델이 구현과 테스트를 모두 작성했더라도, 두 아티팩트가 서로 일치한다는 것이 둘 중 어느 하나가 옳다는 것과는 다릅니다. 커버리지(Coverage)는 당신이 질문한 것을 측정할 뿐, 당신이 질문하지 않은 것은 측정하지 못합니다.
- 기술 부채(Technical Debt)는 코드를 작성하는 단계가 아니라 디버깅 단계에서 복리처럼 쌓입니다. 생성은 빠르고 검토는 느리기 때문에, 우리는 결코 병목 지점이 아니었던 부분을 최적화합니다. 그 비용은 몇 달 후에, 새벽 2시에 나타나는데, 이때 수정하려면 리트라이 루프(retry loop)가 왜 특정한 백오프(backoff)를 가져야 하는지 알아야 하고, 유일하게 정직한 대답은 "diff에 있었고 괜찮아 보였다"는 것입니다.
- 소유권(Ownership)은 기술적인 문제가 아니라 법적인 문제입니다. 일단 코드가 당신의 저장소(repo)에 들어가고 커밋(commit)에 당신의 이름이 올라가면, "모델이 작성했다"는 것은 그 누구도 받아들이지 않는 방어 논리가 됩니다. 그것이 당신의 사고 검토 과정이든, 고객이든, 규제 기관이든 마찬가지입니다. 이해도를 물려받았는지 여부와 관계없이, 설명해야 할 의무를 상속받게 됩니다.
- 리버트(reverts)가 진실을 말해준다. 오늘 또 다른 글: "사기는 사기가 개선될 때까지 계속될 것이다" (192점). 리버트는 공공연하게 이해도가 실패했음을 의미합니다. 누군가가 아무도 영향 범위를 모델링하지 못한 변경 사항을 배포했고, 가장 빠른 복구 방법은 그것을 되돌리는 것이었습니다. 자주 리버트하는 팀이 부주의한 팀인 것은 아닙니다. 그들은 자신이 무엇을 배포했는지 반복적으로 깨닫는 과정에 있는 팀입니다.
실제로 도움이 되는 것들
이것들 중 어느 것도 모든 것을 수동으로 작성해야 한다고 주장하는 것은 아닙니다. 이는 이해도의 비용을 눈에 보이지 않게 축적되도록 내버려 두는 대신, 의도적인 곳에 배치할 것을 주장합니다.
AI 지원 개발 환경에서의 코드 이해와 검증 방법
- 설명 자체를 아티팩트로 만들어라. 모든 비자명한 AI 지원 변경 사항에 대해 짧은 서면 모델을 요구해야 한다. 이 모델에는 무엇을 하는지, 어떤 불변성(invariant)을 보존하는지, 세상에 대해 무엇을 가정하는지, 그리고 어떻게 고장 났는지 알 수 있는지 등이 포함되어야 한다. 아무도 세 문장을 작성할 수 없다면, 테스트가 아무리 성공적이라 할지라도 그 변경 사항은 준비되지 않은 것이다.
- 차이점(diff)만 검토하지 말고 모델 전체를 검토하라. 차이점 검토는 "이 줄이 올바른가?"라고 묻는다. 이해도 검토는 "작성자가 고려하지 않은 경우에 이 모듈의 동작을 예측할 수 있는가?"라고 묻는다. 만약 그렇지 않다면, 그것이 바로 발견 사항이며 사소한 지적이 아니다.
- 인간이 작성한 골격(skeleton)을 유지하라. 인터페이스, 데이터 모델, 불변성, 그리고 실패 모드는 호출될 사람이 직접 작성해야 한다. 생성 AI가 중간 부분을 채우도록 하라. 이 골격이야말로 중간 부분이 재구성 가능하게 만드는 요소이다.
- 필요하기 전에 계측(Instrument)하라. 추적(Traces), 구조화된 로그(structured logs), 그리고 호출별 비용 할당은 "뭔가 이상한 동작을 했다"는 것을 답이 있는 질문으로 바꾼다. 에이전트 관찰 가능성 도구(Agentic observability tooling)가 프론트 페이지에 등장하는 이유가 있다 (오늘의 예: 에이전트 추적에서 오류를 찾는 YC 출시 제품인 "에이전트 모니터링"). 사고 발생 중에 가시성을 구매하지 말고, 사전에 구매하라.
- 토큰 사용량뿐만 아니라 설명 능력을 예산으로 책정하라. 토큰 사용량은 정체기에 접어들 수 있지만, 검토 역량이 진짜 제약 사항이며 모델 처리량에 따라 확장되지 않는다. 만약 팀이 동일한 리뷰어를 가지고 코드를 3배 더 많이 배포한다면, 그들은 세 번째만큼 이해하려고 선택했다는 의미이다.
- 재도출(re-derivation)을 연습하라. 분기별로 중요한 모듈 하나를 골라, 그것을 작성하지 않은 사람이 그 동작과 변경 사항을 설명하고 수정하게 하라. 만약 이것이 실패한다면, 당신은 코드베이스가 아니라 실행 가능한 소문만 가지고 있는 것이다.
불편한 교환 (The uncomfortable trade)
이 논거 중에는 "속도를 늦추라"는 조언으로 변질되는 버전이 있는데, 이는 속도가 느려지지 않는 시장에서는 쓸모없는 조언이다. 실용적인 버전은 더 좁다: 당신은 타이핑(코딩) 작업은 아웃소싱할 수 있지만, 소유권(ownership)까지는 할 수 없다. 속도는 정당한 이점이며, 첫 번째 사고가 발생한 후에도 그것을 유지하는 대가는 이해도이다.
이 부분을 제대로 이해하는 팀들은 AI의 도움을 받아 코드를 덜 작성하지 않습니다. 그들은 절약된 시간을 오직 인간만이 할 수 있는 부분, 즉 시스템이 무엇을 보장해야 할지 결정하고 압박 속에서 그것을 증명할 수 있는 부분에 사용합니다.
한 줄 버전
설명할 수 없는 코드는 레버리지가 아니라 지연 타이머가 달린 부채입니다. 모델은 작성할 수 있지만, 오직 당신만이 소유할 수 있습니다.
다음 시리즈: 코드 생성 주체와 평가 주체가 동일해질 때 무슨 일이 발생하는지 — 평가 계층.