개발자가 코드를 안 읽게 되더라도 끝까지 읽을 단 한 가지
코드는 원래 읽히라고 만든 게 아니었습니다. 그냥 다른 대안이 없었을 뿐이죠.
실제 사례를 하나 떠올려 봅시다. 프로덕션 결제 서비스에 리트라이 로직, 멱등성 키, 서킷 브레이커, 피처 플래그, 컴플라이언스 체크가 미들웨어 곳곳에 얽혀 있습니다. 제어 흐름 자체는 기술적으로 깔끔하고 테스트도 다 통과하지만, 의도는 조건문, 데코레이터, 유틸리티 추상화 사이에 흩어져 있습니다. 환불 경로 하나가 5개 파일과 3단계의 간접 참조를 거치는 셈입니다.
기계는 결정론적 실행 그래프를 봅니다. 사람은 흩어진 분기와 암묵적 제약 조건을 보며, 어떤 실패 모드가 허용 가능했고, 어떤 것이 비즈니스 크리티컬이었고, 어떤 것이 우연한 부작용이었는지를 스스로 재구성해야 합니다.
오랫동안 우리는 코드를 소프트웨어에서 가장 높은 수준의 진실로 다뤄왔습니다. 시스템이 뭘 하는지 알고 싶으면 코드를 읽었고, 뭐가 만들어졌는지 확인하고 싶으면 코드를 검사했습니다. 사람이 주된 작성자일 때는 합리적인 가정이었죠. 하지만 에이전트가 작성의 주체가 되기 시작하면서, 이 가정에 균열이 생기고 있습니다.
우리는 에이전트가 소프트웨어를 만드는 세계로 "이동 중"인 게 아닙니다. 이미 그 안에서 살고 있습니다. 에이전트가 코드를 작성하고, 디프를 리뷰하고, 사람이 보기도 전에 버그를 잡아냅니다.
CodeRabbit에서는 매달 수백만 건의 PR을 리뷰하고 있고, 최전선에 있는 기업들에서 사람이 작성한 코드와 AI가 작성한 코드의 비율이 역전되는 현상을 직접 목격하고 있습니다. 올해 초 470개의 오픈소스 GitHub PR을 샘플링한 결과, 320건이 AI 공동 작성 PR이었고 150건만이 순수 인간 작성 PR이었습니다.
에이전틱 AI의 활용이 늘어나면서, 백로그에 쌓여만 있던 기능이 프롬프트 한 줄에서 구체화되고, 몇 주가 걸리던 마이그레이션이 하룻밤 만에 완료되고, 우선순위에서 밀려있던 리팩토링이 실제로 실행에 옮겨지고 있습니다.
하지만 이 가속만으로는 메울 수 없는 빈틈이 생겼습니다.
아무도 이야기하지 않는 격차
에이전트가 생성한 코드가 코드베이스에 처음 들어올 때는 마법처럼 느껴집니다. 20번째 PR쯤 되면 시스템이 불투명하게 느껴지기 시작합니다. 50번째 PR이 되면, 팀은 아무도 완전히 이해하지 못하지만 모두가 확장해야 하는 결과물을 유지보수하게 됩니다.
생성된 코드는 퇴적물처럼 쌓입니다. 각 레이어는 그럴듯하지만, 시간이 지날수록 전체를 추론하기 어려워집니다. "그냥 코드를 읽어보세요"는 더 이상 진지한 조언이 아닙니다. 더 나은 기록 시스템이 없기 때문에 반복되는 의례에 불과합니다.
문제는 코드 품질이 아닙니다. 에이전트는 깔끔하고, 테스트도 통과하고, 로컬에서는 올바른 코드를 작성합니다. 문제는 의도입니다. 코드가 원래부터 잘 답해주지 못했던 질문들이 있습니다.
- 왜 이 패턴을 선택했는가?
- 어떤 제약 조건이 중요했는가?
- 에이전트가 명시적으로 하지 않기로 결정한 것은 무엇인가?
- "완료"의 기준은 무엇인가?
에이전트는 코드의 이 한계를 더 이상 무시할 수 없게 만들었습니다.
코드는 새로운 어셈블리어다
유용한 비유가 있습니다. 1950년대, 프로그래머들은 어셈블리를 작성했습니다. 레지스터, 메모리 주소, 명령 사이클 등 하드웨어의 전체 메커니즘을 이해해야 했죠. 그 뒤로 추상화 레이어가 등장했고, 오늘날 어셈블리를 직접 작성하는 프로그래머는 거의 없습니다. 어셈블리는 여전히 모든 것의 밑에서 돌아가지만, 더 이상 인간의 인터페이스는 아닙니다.
코드가 바로 그 어셈블리 수준의 언어가 되어가고 있습니다.
코드는 여전히 중요합니다. 프로덕션은 코드 위에서 돌아가고, 기계는 코드가 필요합니다. 하지만 사람에게 코드는 점점 너무 저수준이어서, 대부분의 사고가 일어나는 곳이 되지 못합니다. 코드의 역할이 바뀌고 있습니다. 코드는 기계가 실행하는 것이 되고, 다른 무언가가 사람이 이해하는 것이 됩니다.
그 무언가가 바로 플랜(Plan)입니다.
기록 시스템으로서의 플랜
좋은 플랜은 "왜"가 "어떻게" 속으로 사라지기 전에 포착합니다. 가정이 보이지 않게 되기 전에 기록합니다. 트레이드오프를 읽을 수 있게 만듭니다. 제약 조건을 부족의 지식(tribal knowledge) 대신 공유된 맥락으로 바꿔줍니다. 수천 줄의 생성된 코드에서 의도를 역으로 추적하지 않고도, 사람이 리뷰하고, 토론하고, 다듬고, 승인하고, 다시 돌아볼 수 있는 무언가를 제공합니다.
이 구분이 가장 중요한 곳은 소프트웨어 업무가 진짜 어려워지는 지점입니다.
결제 마이그레이션 예시를 다시 생각해 봅시다. 스태프 엔지니어, PM, 보안 책임자에게 가장 중요한 아티팩트는 최종 디프가 아닙니다. 의도입니다. 무엇이 절대 깨져선 안 되는지, 어떤 엣지 케이스가 비즈니스 크리티컬인지, 실패는 어떻게 처리해야 하는지, 어떤 트레이드오프를 의식적으로 수용했는지. 플랜은 이것들을 폭발 반경이 현실이 되기 전에 리뷰할 수 있게 해줍니다.
인시던트 대응도 마찬가지입니다. 장애 이후, 압박 속에서 작성된 코드에서 의도를 재구성하는 것은 최악의 타이밍입니다. 명확한 플랜 기록이 있으면 당시에 무엇을 믿었는지, 어떤 완화 조치가 우선시되었는지, 무엇이 미뤄졌는지, "완료"가 실제로 무엇을 의미했는지를 보여줍니다.
온보딩도 생각해 볼 수 있습니다. 지난 1년간 에이전트가 대거 투입되어 만들어진 코드베이스에 합류하는 새 엔지니어에게 "레포를 읽어보세요"라고만 할 수는 없습니다. 하지만 플랜의 흐름을 보여주면(무엇을 최적화했고, 어디서 숏컷을 택했고, 어떤 제약이 고객에게서 왔고, 어떤 가정이 아직 열려 있는지) 혼란은 이해로 바뀝니다.
오해의 비용이 큰 곳이라면 어디서든, 플랜은 구현 세부 사항 단독보다 더 가치 있습니다. 진짜 일은 코드를 생성하는 게 아니라, 의미를 보존하는 것이기 때문입니다.
우리가 만들어가는 방향
미래는 프롬프트의 것도, 코드만의 것도 아닙니다. 프롬프트는 너무 휘발적이고, 코드는 곧 너무 저수준이 됩니다. 그 사이에 있는 내구성 있는 레이어, 사람이 실제로 추론할 수 있는 레이어가 바로 플랜입니다.
플랜은 안목이 사는 곳입니다. 판단, 책임, 협업이 살아 있는 곳입니다.
코드는 앞으로도 작성될 것이고, 그 양은 어느 때보다 많아질 것입니다. 하지만 그 코드의 상당 부분은 우리보다 빠르고, 우리보다 저렴하며, 스스로를 설명하는 데는 관심이 없는 시스템이 만들어낼 것입니다. 소프트웨어 개발이 읽을 수 있고, 통제 가능하고, 협업이 가능한 상태로 남으려면, 사람이 붙들 수 있는 더 나은 아티팩트가 필요합니다.
그것이 바로 CodeRabbit Issue Planner가 지향하는 바입니다. Issue Planner는 AI 에이전트를 사용하는 팀이 코드가 작성되기 전에 협업으로 계획하고 의도를 맞출 수 있게 도와주는 도구입니다. 모호한 이슈를 공유 가능하고 리뷰 가능한 플랜으로 바꾸고, 코드베이스의 맥락을 바탕으로 편집 가능한 프롬프트를 생성합니다. 동시에, 여러분이 내린 선택과 의도한 시스템의 기록 보관소 역할도 합니다.
더 예쁜 프롬프트 입력창도, 코드 생성 위에 씌운 또 하나의 얇은 래퍼도 아닙니다. 에이전트 시대의 의도를 위한 실질적인 기록 시스템입니다.
시인이 자신의 시를, 셰프가 자신의 요리를 자신이 만든 아티팩트로 바라보듯, 개발자는 그동안 코드와 PR을 자신이 만든 아티팩트로 바라봐왔습니다.
하지만 이 새로운 세계에서는 코드가 아닐 것입니다. 플랜이 될 것입니다. 개발자가 "이것이 우리가 만든 것"이라고 가리킬 대상. 팀원에게 자신의 성과를 보여줄 때 공유할 대상. 평가의 기준이 될 대상.
플랜은 앞으로의 개발 업무에서 중심이 될 것입니다. 기계가 인수하기 전, 마지막 인간의 터치포인트로서 세상에 나가는 것이 바로 플랜입니다.