위험하게 코드 읽기를 건너뛰는 경우: LLM이 코드를 읽는 속도보다 빠르게 코드를 작성할 때

기본 전제는 간단합니다. AI가 생성한 코드를 완전히 읽지 않는 것은 어떨까요? 어셈블리, 바이트코드, 트랜스파일된 자바스크립트처럼 취급하는 겁니다. 고급 언어 소스는 다른 형태의 기계어가 됩니다. 이 아이디어는 Thoughtworks의 리트리트 보고서와 Facundo Olano의 블로그 게시물에서 비롯되었습니다.

이것이 합리적인 이유

LLM은 비결정적 출력을 생성하며, 인간이 읽는 속도보다 훨씬 빠르게 코드를 만듭니다. 모든 diff를 검토하는 것은 더 이상 실용적이지 않습니다. 엄격함을 포기하는 대신, 명세와 테스트로 그 초점을 옮기자는 것입니다.

조직적 전제 조건

이는 개인이나 팀의 결정이 아니라 조직 차원의 결정이어야 합니다. 암달의 법칙이 적용됩니다. 프로세스 재구성 없이 코드 생성 속도만 극대화하면 실제 이득이 없습니다. 어떤 개발자는 하루에 2만 줄의 쓰레기를 쏟아내고, 다른 개발자는 여전히 그것을 읽고 승인해야 하는 상황은 용납될 수 없습니다.

요구 조건은 다음과 같습니다:

• 인간-인-더-루프 제거, 조정 및 게이트키핑 축소
• 사실상 무한한 요구사항 공급, 엔지니어가 작업 흐름을 자율적으로 소유
• 재작업 비용이 거의 없으므로, 잘못된 작업을 방지하지 말고 명세/테스트를 통해 발견

제안된 워크플로우

표준화된 마크다운 명세를 새로운 지식 단위로 사용합니다. 제품 소유자와 엔지니어가 비즈니스 규칙에 대한 명세와 테스트 케이스를 협업하여 작성합니다. 이를 구현 코드와 함께 저장소에 체크인합니다.

자동화된 풀 리퀘스트 검사가 다음을 확인합니다:

• 테스트 통과
• 코드가 명세를 준수

명세가 코드가 아니라 팀이 이해하고 검토하며 책임을 지는 대상입니다.

주요 차이점

명세는 프롬프트가 아닙니다. 테스트는 TDD가 아닙니다. 이는 구현 계층이 아닌 계약 계층으로 엄격함을 옮기는 것입니다.