아무도 당신이 AI로 작성한 코드를 이해하지 못한다

데이브(Dave)를 상상해 보세요. 나쁜 개발자는 아닙니다. 경력 6년 차에, 적당히 호기심이 많고, 중요한 것들은 대부분 잡아냅니다. 지난 화요일, 데이브는 AI에게 기능의 스캐폴딩 (scaffold)을 요청했습니다. AI는 약 4분 만에 340줄의 코드를 작성했습니다. 코드는 리뷰를 통과했습니다. 테스트도 통과했습니다. 기능은 금요일에 배포되었습니다.

그다음 월요일, 해당 기능에서 버그가 발생했습니다. 데이브는 파일을 열고 11분 동안 멍하니 바라보다가 채팅창에 질문을 입력했습니다.

이것이 제가 만든 에피소드입니다. 꼭 데이브에 관한 이야기는 아닙니다... 데이브는 여러 인물을 합쳐놓은 가상의 인물입니다. 하지만 지난 2년 동안 개발 팀에 있었다면, 여러분은 데이브를 만난 적이 있을 것입니다. 어쩌면 여러분 자신이 데이브였을지도 모릅니다.

아무도 추적하지 않는 비용

여러분의 팀 대시보드에는 아마 없을 지표가 하나 있습니다. 개발자가 자신이 배포한 코드에 대한 질문에 답하는 데 시간이 얼마나 걸리는가 하는 점입니다.

사이클 타임 (Cycle time). PR (Pull Request) 개수. 변경된 라인 수. 테스트 커버리지 (Test coverage). 아무도 그 11분을 기록하지 않습니다. "이게 무슨 역할을 하지?"라는 질문이 "AI에게 물어봐야지"로 변할 때, 아무도 그것을 기록하지 않습니다.

그것이 숨겨진 비용입니다. 버그가 아닙니다. 버그는 찾아낼 수 있습니다. 비용은, 이제 버그를 찾는 데 시스템을 실제로 이해하는 사람이 아닌 예측 엔진 (prediction engine)과의 대화가 필요하다는 점입니다.

이것은 조용히 복리로 쌓입니다. 그러다 어느 날 시니어 개발자가 퇴사하면, AI는 자신이 그것을 작성했을 때의 의미를 기억하지 못하고, 다른 누구도 기억하지 못하게 됩니다.

병목 현상이 어디로 사라졌는가

소프트웨어 역사의 대부분 동안, 병목 현상 (bottleneck)은 코드를 생산하는 것이었습니다. 시니어 개발자는 비용이 많이 들었고, 유능한 개발자는 드물었으며, 소프트웨어를 출시하는 것은 진정으로 어려운 일이었습니다.

그 병목 현상은 기본적으로 사라졌습니다.

Claude Code는 여러분이 커피 한 잔을 내리는 시간 동안 작동하는 기능을 만들어낼 수 있습니다. 주니어 개발자는 시니어 개발자가 이틀 걸렸을 코드를 배포할 수 있습니다. 이것은 현실이며, 사라지지 않을 것입니다.

새로운 병목 현상은 생성된 결과물을 이해하는 것입니다. 그리고 아이러니하게도 우리는 이를 대부분 그냥 받아들여 왔습니다. 코드는 배포되고, 기능은 작동하며, 팀원 중 누구라도 그 이면의 추론 과정을 재구성할 수 있는지에 대해서는 더 이상 묻지 않게 되었습니다.

저는 이것이 심화되는 문제라고 생각합니다.

DDD가 더 이상 오버헤드가 아닌 이유

저는 수년간 "코드가 너무 많아진다"는 논리에 맞서 도메인 주도 설계 (Domain-Driven Design, DDD)를 옹호해 왔습니다. 모든 코드를 직접 손으로 작성하던 시절에는 그 논리가 어느 정도 일리가 있었습니다. 하지만 깨끗한 도메인 모델 (domain model)을 작성하는 비용이 거의 무료에 가까워진 지금은 거의 의미가 없습니다.

DDD, 클린 아키텍처 (Clean Architecture), 헥사고날 아키텍처 (Hexagonal Architecture). 이 중 그 어떤 것도 코드베이스를 인상적으로 보이게 만들기 위해 발명된 것이 아닙니다. 이것들은 복잡한 시스템을 이해 가능하게 만들기 위해, 비즈니스의 언어를 코드 안에 담기 위해, 그리고 미래의 개발자(그리고 미래의 당신)에게 지도를 제공하기 위해 발명되었습니다.

AI가 코드를 작성할 때, 그 지도는 덜 중요해지는 것이 아니라 오히려 더 중요해집니다. AI는 당신이 쓰라고 명령하는 것은 무엇이든 쓸 것입니다. 당신의 도메인 (domain)과 일치하고 명확하게 명명된 개념들로 깨끗한 방향을 제시한다면, 사람이 실제로 읽을 수 있는 코드를 얻게 될 것입니다. 모호한 아키텍처 안에서 모호한 지시를 내린다면, 아무도 설명할 수 없는, 테스트만 통과하는 340줄의 코드를 얻게 될 것입니다.

저는 두 가지 결과 모두를 목격했습니다. 차이점은 AI가 아닙니다. 차이점은 개발자가 프롬프트 (prompt)를 작성하기 전에 도메인을 이해했는지 여부입니다.

5분의 습관

에피소드에서 이 내용을 다루었으며 여기서 전부 공개하지는 않겠지만, 요약하자면 이렇습니다. 프롬프트를 작성하기 전에, 당신이 무엇을 왜 만드는지 적으십시오. 티켓 설명이나 기능 이름이 아닙니다. 실제 의도 (intent) 말입니다. 이것이 어떤 도메인 개념 (domain concept)을 건드리고 있는가? 비즈니스 용어로 기대되는 동작은 무엇인가? 무엇이 이 코드가 정확하다는 확신을 줄 수 있는가?

이 5분의 습관이 AI가 생성하는 코드를 변화시킵니다. 상당히 말이죠.

또한 무언가 고장 났을 때 발생하는 상황도 변화시킵니다. 의도(intent)가 기록되어 있기 때문에, 디버깅(debugging) 대화는 당신과 도메인(domain) 사이에서 이루어집니다. 의도가 무엇이었는지 추측하려는 AI와 당신 사이에서 이루어지는 것이 아닙니다.

그것이 바로 당신이 구축하고 있는 것을 스스로 통제하는 상태를 유지하는 것입니다. 도구(tooling)가 우리 대부분이 생각하는 속도보다 더 빠르게 코드를 작성할 수 있는 이 시대에, 그러한 습관이 곧 직업적 역량입니다.

에피소드에는 더 많은 내용이 담겨 있습니다. 숨겨진 비용(hidden cost)에 대한 논거를 더 자세히 다루며, 월요일 아침부터 바로 시작할 수 있는 구체적인 연습법에 대해서도 이야기합니다.

저는 모든 댓글을 읽습니다. 아래에 당신의 경험담(war story)을 남겨주세요. 아무도 추적할 수 없었던 버그(bug), 아무도 설명할 수 없었던 서비스 등, 그런 이야기들은 들을 가치가 있습니다.

John Nickell — The Thinking Engineer