위험하게 코드 읽기 건너뛰기 – olano.dev

출처: Hacker News

나는 내 이전 글에서 코드를 더 이상 읽고 디버깅할 필요가 없다고 가정하는 것이 무책임하다고 결론지었다—즉, 발생하는 어떤 문제든 LLM이 우리 대신 해결해 줄 것이라고 가정하는 것이 무책임하다는 것이다. 지금까지는 프로그래머가 소스 코드를 이해하고 유지보수하는 것이 소프트웨어 시스템을 이해하고 유지보수하는 대리 역할을 해 왔기 때문이다. 우리는 LLM이 만든 결과물에 대해 책임을 진다.

하지만 이제는 상황이 달라진다면 어떨까? 위험과 트레이드오프를 조직의 리더십에 성실히 알렸음에도 그들이 여전히 위험을 감수하고 싶어한다면? 이는 드문 일은 아니다. 기업, 특히 기술 스타트업은 생산성을 높이고, 경쟁보다 빨리 시장에 진입하며, 투자자를 끌어들이기 위해 단기적인 타협을 자주 한다.

조직 차원에서 코딩에 소요되는 시간을 최소화하기 위해 LLM을 활용하라는 명령이 있다면, 그것은 우리가 다룰 새로운 제약이다. 그 맥락에서 좋은 엔지니어링이 무엇인지 정의할 수 있다. 우리는 어셈블리나 바이트코드, 트랜스파일된 JavaScript를 읽지 않듯이 LLM이 만든 코드를 읽지 않을 수 있다—우리의 고수준 언어 소스가 이제 또 다른 형태의 머신 코드가 되는 것이다.

이 생각은 Thoughtworks의 리트릿 보고서를 읽고 나서야 확실히 와 닿았다. LLM은 비결정적 출력을 내놓고 우리가 읽을 수 있는 속도보다 훨씬 빠르게 코드를 생성한다. 따라서 이제는 모든 diff를 효과적으로 검토하고 이해하며 승인한다는 기대를 진지하게 가질 수 없다. 하지만 이것이 엄격함을 포기한다는 의미는 아니다; 오히려 엄격함을 다른 곳으로 옮겨야 할 수도 있다.

하지만 중요한 점은 이것이 개인이나 팀의 선택이 아니라 조직 차원의 결정이어야 한다는 것이다. 위험 관리와 책임 소재 때문만이 아니라, 암달의 법칙 때문이다. 조직 구조와 프로세스를 재배치하지 않고 단순히 코드 생성 속도만 높인다면 실질적인 생산성 향상은 일어나지 않는다.

몇몇 개발자가 하루에 2만 줄의 엉성한 코드를 쏟아내고도 나머지 팀이 이를 읽고 이해하거나 승인할 수 있다고 기대할 수는 없다. 작업 단위가 여전히 “RESTful API에 새로운 엔드포인트 추가”라면 에이전트를 활용할 수 없다. 각 엔지니어가 동시에 네 개의 작업을 수행하고 에이전트를 야간에도 돌릴 수 있다면, 제품 소유자가 두 피자 팀을 바쁘게 유지할 만큼의 작업을 지속적으로 제공할 수 없을 것이다.

따라서 우리는 인간‑인‑루프를 제거하고, 조정·마찰·관료주의·게이트키핑을 최소화해야 한다. 거의 무한에 가까운 요구사항 공급, 엔지니어가 사실상 제품 디자이너 역할을 하며 전체 작업 흐름을 소유하고 자율적으로 의사결정할 수 있는 환경이 필요하다. 재작업 비용이 거의 없으므로 잘못된 작업을 방지하려는 노력을 들일 필요도 없다.

그렇다면 엄격함은 어디로 가는가? Thoughtworks 보고서와 마찬가지로 나는 사양(프롬프트와는 다름)과 테스트(테스트 주도 개발과는 다름)를 첫 번째 후보로 꼽는다. 오늘 바로 이런 개발 프로세스를 도입한다면, 표준화된 Markdown 사양을 소프트웨어 프로젝트의 새로운 지식 단위로 만든다. 제품 소유자와 엔지니어가 처음에 이 사양과 테스트 케이스를 협업해 비즈니스 규칙을 강제한다. 이 사양은 구현 코드와 함께 프로젝트 저장소에 체크인되어야 한다. 자동화된 풀‑리퀘스트 검증이 테스트 통과 여부뿐 아니라 코드가 사양을 준수하는지도 확인한다. 팀이 이해하고 검토하며 책임을 져야 하는 것은 구현된 코드가 아니라, 그 코드를 구현하게 만든 사양이다.