위험하게 코드 읽기 생략하기: AI 에이전트 시대의 엄격함 변화

소프트웨어 엔지니어의 전통적인 역할은 오랫동안 소스 코드를 읽고 이해하고 유지하는 능력에 중심을 두어 왔습니다. 이 패러다임에서 코드는 소프트웨어 시스템을 이해하는 주요 프록시입니다. 그러나 Large Language Models (LLMs)과 자율 에이전트가 인간읽기 능력을 훨씬 초과하는 속도와 규모로 코드를 생성하기 시작하면서 이 모델은 돌파점에 도달하고 있습니다.

에이전트가 분 단위로 수천 줄의 코드를 쏟아낼 수 있다면, 전통적인 풀 리퀘스트(PR) 검토 프로세스가 병목 현상이 됩니다. 생성된 코드의 모든 줄을 검토하려 한다면 AI가 약속한 생산성 향상을 무효화하게 됩니다. 이로 인해 도발적인 질문이 생깁니다: 코드 읽기를 완전히 중단하면 어떤 일이 일어날까요?

코드-머신 코드 가설

LLM이 생성한 코드를 인간이 읽을 수 있는 소스가 아닌, 머신 코드의 한 형태로 대해야 한다는 주장이 점점 늘어나고 있습니다. 이는 개발자들이 어셈블리, 바이트코드, 또는 트랜스파일된 자바스크립트를 대하는 방식과 유사합니다. 이 관점에서 고수준 언어(Python, TypeScript, Rust)는 더 이상 인간 의도의 주요 산물이 아니며, 단지 AI가 생성한 구현 세부 사항일 뿐입니다.

이를 위해 업계는 "rigor"의 정의를 바꿔야 합니다. 코드인 how를 검증하는 대신, 엔지니어는 사양인 what과 결과인 result(테스트)에 전적으로 집중해야 합니다.

지식의 단위 이동

이 변화를 구현하기 위해 프로젝트의 "지식의 단위"는 소스 코드에서 표준화된 사양으로 이동하게 되며, 이는 잠재적으로 Markdown으로 작성될 수 있습니다. 이 제안된 워크플로우는 다음과 같습니다:

협업 사양: 제품 소유자와 엔지니어가 비즈니스 규칙을 강제하는 테스트 케이스 세트와 함께 상세한 Markdown 사양을 공동으로 작성합니다.
자동 구현: AI 에이전트가 사양을 기반으로 코드를 구현합니다.
검증: 자동 검사가 테스트가 통과되고 코드가 사양에 conforms하는지 확인합니다.
책임: 팀은 결과물이 아닌 사양과 테스트 스위트에 대해 책임을 집니다.

조직적 의무

이 변화는 단일 개발자나 팀의 결정이 될 수 없으며, 조직적 의무가 되어야 합니다. Amdahl의 법칙에 따르면, 조직 구조를 재배열하지 않고 코드 생성 속도를 최대화해도 구체적인 생산성 향상을 얻을 수 없습니다.

작업 단위가 "API에 새로운 엔드포인트 추가"로 유지된다면, 조정과 관료제의 마찰이 여전히 처리량을 제한할 것입니다. 에이전트를 진정으로 활용하기 위해 조직은 다음과 같이 해야 합니다:

사소한 구현에 대해 humans-in-the-loop를 제거하세요.
엔지니어를 전체 작업 스트림을 소유하는 "유사 제품 디자이너"로 전환하세요.
재작업이 "거의 무료"임을 받아들여, 잘못된 코드 한 줄이라도 작성되지 않도록 하는 데 드는 노력을 줄이세요.

중요한 반론과 위험

극단적인 속도의 전망은 유혹적이지만, 커뮤니티는 이 접근 방식의 장기적 viability에 대해 상당한 우려를 제기했습니다.

"인지적 부채" 함정

주요 우려는 인지적 부채의 축적입니다. 개발자가 코드 읽기를 중단하면 복잡하고 체계적인 오류를 디버그하는 능력을 잃게 됩니다. 한 코멘테이터가 지적한 바와 같이, LLM이 단기적인 편의를 위해 데이터베이스를 비정규화하는 것과 같은 근본적인 건축 오류를 저지르면, 시스템은 모든 테스트를 통과하고 사양에 conforms할 수 있지만, 나중에 진화시키는 것이 불가능해집니다. 왜냐하면 아무도 기반 구조를 이해하지 못하기 때문입니다.

"사양의 역설"

소프트웨어 공학에서는 "충분히 정확한 사양은 코드다"라는 주장이 반복적으로 제기됩니다. 사양이 LLM이 환각하거나 표류하지 않도록 충분히 상세해야 한다면, 그 사양을 작성하는 데 필요한 노력은 코드를 작성하는 노력과 같거나 이를 초과할 수 있습니다. 이 경우, 변화는 생산성 향상이 아니라 단순히 더 장황한 새로운 프로그래밍 언어로의 이동일 뿐입니다.

"맛"의 상실

일부는 코드 리뷰가 단순히 버그를 찾는 것이 아니라 "맛"을 적용하는 것이라고 주장합니다—코드가 유지 가능하고 우아하며 아키텍처 패턴을 따르도록 보장하는 것입니다. 코드를 빌드 아티팩트로 취급하면, 기능적으로는 올바르지만 구조적으로 일관되지 않은 시스템을 만들 위험이 있으며, 이로 인해 "알 수 없는 버그가 가득한 수정 불가능한 코드"가 미래에 나타날 수 있습니다.

실제 구현

위험에도 불구하고, 일부 개발자는 이러한 문제를 완화하기 위해 "Plan-First" 워크플로를 이미 채택하고 있습니다:

"에이전트가 계획 파일(spec)을 만들도록 항상 하세요... 에이전트가 계획 파일이 완전하고 철저해질 때까지 반복하도록 하세요... 계획이 최종화되면 에이전트가 이를 구현하도록 하세요. impl 커밋과 함께 계획을 체크인하세요. 계획은 의도를 인코딩하기 때문에 실제로 작업의 단위입니다.

다른 사람들은 사양 내에서 RFC 키워드(MUST, SHOULD, MAY)를 사용하여 LLM에 더 명확한 제약을 제공하라고 제안하며, 이를 통해 사양을 공식 계약으로 효과적으로 전환합니다.

결론

코드를 일회용 아티팩트로 취급하는 것은 고위험 고보상 전략입니다. 이는 전례 없는 개발 속도로 가는 길을 제공하지만, 시스템 이해의 근본을 위협합니다. 현대 엔지니어에게는 "생산적인 속도"와 "무책임한 소홀" 사이의 경계가 어디인지 판단하고, 사양의 엄격함이 소스 코드에 대한 깊은 탐구의 엄격함을 진정으로 대체할 수 있는지 결정하는 것이 과제입니다.