한 개발자가 LLM으로 수만 줄짜리 프로젝트를 몇 주째 유지하고 있습니다. 버그율은 오히려 손으로 짤 때보다 낮다고 합니다. 그런데 그는 여전히 하루 종일 일합니다. 코드를 쓰지 않을 뿐입니다.

개발자 Stavros Korokithakis는 최근 자신의 LLM 개발 워크플로우를 상세히 공개했습니다. 같은 시기, O’Reilly는 “AI 시대의 소프트웨어 장인정신”을 주제로 한 컨퍼런스 라인업을 발표하며 업계가 공통으로 도달한 질문을 던졌습니다. 두 자료가 서로 다른 각도에서 같은 결론을 가리킵니다. 개발자의 역할은 사라지는 게 아니라, 코드 작성에서 판단과 설계로 이동하고 있다는 것입니다.

출처: How I write software with LLMs – stavros.io

• Software Craftsmanship in the Age of AI – O’Reilly Radar

현장에서 확인한 것: 스킬이 이동한다

Stavros는 architect-developer-reviewer로 구성된 멀티 에이전트 구조를 씁니다. Opus 같은 강력한 모델이 아키텍처를 설계하고, Sonnet이 실제 코드를 생성하며, Codex나 Gemini 같은 다른 회사 모델이 리뷰를 맡습니다. 같은 모델에게 자신이 쓴 코드를 검토하게 해봤자 대개 자기 판단에 동의하기 때문에, 다른 모델의 시각이 필요하다는 것입니다.

이 구조에서 그가 실제로 하는 일은 “설득하고 방향을 잡는 것”입니다. 기능 구현을 시작할 때 LLM과 길게는 30분씩 대화하며 목표, 제약, 트레이드오프를 정리합니다. 그 과정에서 LLM이 놓친 설계 결함을 잡아내거나, 이미 코드베이스에 더 나은 방법이 있다는 걸 알려줍니다. 실제 세션에서 그는 LLM이 새 채널 추가 시 매번 하드코딩하던 패턴을 발견하고 공통 상수 배열로 리팩토링하도록 유도합니다.

반면 기술을 잘 모르는 영역(모바일 앱 등)에서는 코드가 금세 엉망이 됩니다. LLM이 잘못된 판단을 해도 잡아내지 못하기 때문입니다. 도구가 강력할수록, 그것을 올바른 방향으로 이끄는 사람의 역량이 결과를 가릅니다.

업계가 같은 질문에 도달한 방식

O’Reilly가 3월 26일 개최하는 AI Codecon은 흥미롭게도 한 방향의 답을 내놓지 않습니다. 에이전트가 PR을 자동으로 생성하고 사람은 결과물만 검토하는 “다크 팩토리” 접근과, 인간이 지속적으로 개입해 방향을 조율해야 한다는 접근이 같은 무대에 섭니다.

그러나 판단력이 핵심 자원이라는 데는 수렴합니다. pandas 창시자 Wes McKinney는 한 달에 100억 토큰 이상을 소비하며 손으로 코딩을 전혀 하지 않지만, 10만 줄을 넘어서면 에이전트가 스스로 만든 코드 더미에 막히는 “브라운필드 장벽”을 발견했다고 밝혔습니다. 에이전트는 필수적인 설계 복잡성을 건드리지 못하고, 오히려 기계 속도로 불필요한 복잡성을 쌓아간다는 것입니다. 그는 Fred Brooks의 50년 전 논지, “설계 재능이 진짜 병목”을 다시 꺼냅니다. 인력 제약이 사라진 지금, 그 논지는 오히려 더 강해졌다는 결론과 함께.

코드에서 취향으로

두 자료가 교차하는 지점은 한 문장으로 정리됩니다. 살아남는 개발자는 가장 많은 에이전트 세션을 돌리는 사람이 아니라, 시스템의 개념적 모델을 머릿속에 유지하며 무엇을 만들고 무엇을 빼야 할지 판단하는 사람이라는 것입니다.

O’Reilly는 이 변화를 “코드 작성에서 시스템 설계로, 타이핑에서 취향으로”라고 표현합니다. Stavros는 그것을 실제로 살고 있습니다.

이 전환이 어떤 조직적 구조 변화를 요구하는지, 그리고 에이전트 파이프라인이 실제로 무너질 때 어떤 일이 벌어지는지는 두 원문에서 더 깊이 다루고 있습니다.

참고자료: The Mythical Agent-Month – Wes McKinney