또는: 하네스 엔지니어링 (harness engineering)만으로는 충분하지 않다

참고

저는 인간/에이전트 협업 분야의 도구를 구축하는 회사(HumanLayer)를 운영하고 있으므로, 아래에서 제가 드릴 말씀은 약간의 편향이 있을 수 있습니다. 그럼에도 불구하고, 여러분이 이 주제가 도움이 되거나 적어도 제가 느끼는 만큼 흥미롭다고 느끼시길 바랍니다. -Dex

우리 모두는 AI 코딩을 프로덕션(production)에 적용하기 위해 경주하고 있습니다. 루프 엔지니어링 (loop engineering)에 대해 많은 이야기가 오갔으며, 지배적인 견해는 우리가 아마도 더 많은 루프를 작성해야 한다는 것입니다.1

StrongDM은 인간이 코드를 읽지도 않고 인간이 코드를 쓰지도 않는 '라이츠-오프(lights-off)' 소프트웨어 팩토리에 대해 글을 썼습니다.

서사는 대략 다음과 같습니다:

• 당신이 병목 현상(bottleneck)이다.
• 모델들은 충분히 훌륭하다.
• 코드는 공짜다.
• 그냥 더 많은 것을 출시하라.

OpenAI의 Ryan Lopopolo는 지난 2월에 이에 대해 글을 썼고, 4월에는 OpenAI의 소프트웨어 팩토리인 Symphony에 대해 강연했습니다.

이 사람들은 모두 정말 똑똑하며 저는 그들에게 엄청난 존경을 표합니다. 하지만 여기서 가장 냉소적인 해석은, 이것이 '슬롭 캐논(slop cannon, 저질 콘텐츠 생성기)'에 더 많은 VC 자금을 쏟아붓기 위한 또 다른 변명이라고 부르는 것일 겁니다.

우리의 친구 Mario는 AI Engineer Europe에서 우리에게 속도를 늦춰달라고 간청했습니다. 왜냐하면 코딩 에이전트(coding-agent)의 실수로 인해 장애(outage)가 발생해서는 안 되는 기업들이, 음... 코딩 에이전트의 실수로 인해 장애를 겪고 있기 때문입니다.

Matt Pocock이 표현했듯이, 코드베이스(codebases)는 그 어느 때보다 빠르게 무너지고 있습니다.

저는 StrongDM의 그 '다크 팩토리(dark factory)'가 어떻게 진행되었는지에 대한 결정적인 데이터나 조사 결과를 찾아낼 수 없었습니다. 기상 보고(weather-report)에는 올해 2월과 6월 사이에 몇 가지 드문 업데이트가 있을 뿐입니다.

Faros AI의 사람들은 보고서를 발표했습니다: 우리 모두가 지난 1월과 2월에 이러한 AI 코딩 도구들을 채택한 이후, 풀 리퀘스트(pull-request, PR) 리뷰 품질이 훨씬 낮아졌습니다.

• 더 많은 코멘트, 더 긴 코멘트, 그리고 리뷰가 전혀 없이 머지(merge)되는 수많은 PR들.
• 인시던트(incidents)가 훨씬 증가함.
• 개발자당 버그(bugs)가 훨씬 증가함.

|

이 보고서는 검증 가능한 결정적인 증거(smoking gun)라기보다는 상관관계 신호에 가깝습니다. 이 게시물의 핵심은 '쓰레기 데이터(slop data)'를 경계하는 것이지만, 제가 본 바에 따르면 방향성 측면에서는 유효하게 느껴집니다.

많은 사람들이 이것이 기술적인 문제(skill issue)라고 말할 것입니다. 즉, 좋은 결과를 얻지 못한다면 그것은 당신의 잘못이라는 식으로요.

하지만 어떤 방식으로든... 음... 붙잡고 계시더라도, 제가 보장하건대 토큰을 최대한 활용하는 것(token-maxxing)이 효과가 없다면 그것 역시 기술적인 문제라고 듣게 될 것입니다. 단지 더 많은 토큰을 사용해야 할 뿐이라고요. 코드를 읽는 것을 그만두세요. 그리고 만약 당신이 겨우 거기까지 도달하고 있다면, 그것은 발전 과정의 일부일 것이라고 약속합니다. 저도 지난여름에 그렇게 생각했었습니다.

| Coding Agents를 위한 고급 컨텍스트 엔지니어링 | 분위기 금지 - 복잡한 코드베이스에서 어려운 문제 해결하기 | RPI에 대해 우리가 잘못 알았던 모든 것 |

어쨌든, 우리가 견뎌야 했던 이 온라인의

저는 매일 새롭게 등장하는 기술 플러그인에 대한 과장된 광고와 'AI 정신병적 토큰 맥스킹 (ai-psychosis-tokenmaxxing)' 조언 팬데믹을 뚫고 나가, 특정 기술이나 프레임워크를 언급하지 않고 효과가 있는 것들의 유형에 대해 일반적인 관점에서 이야기해 보려 합니다.

비디오 버전: 이 포스트는 AI Engineer World's Fair 2026에서 진행한 저의 기조 연설을 바탕으로 하며 (이를 확장하여) 작성되었습니다.

이 포스트에 대한 피드백을 주신 @addyosmani, @CyrusNewDay, @HamelHusain, @zeeg, @dillon_mulroy, @nayshins, 그리고 @jeffreyhuber 님께 감사드립니다.

Addy Osmani는 강조할 만한 가치가 있는 이 지점을 명확히 정리해 주었습니다:

만약 당신이 바이브 코딩 (vibe coding)을 좋아한다면, 제발 계속 그렇게 하세요. 저도 여전히 많은 것들을 바이브 코딩으로 만듭니다. 다만 저는 동시에 수많은 프로덕션 소프트웨어를 유지보수하고 있으며 (HumanLayer를 통해 수천 명의 다른 엔지니어들이 그렇게 할 수 있도록 돕고 있습니다), 따라서 이 글의 나머지 내용은 복잡한 코드베이스에서 어려운 문제를 해결하는 사람들을 대상으로 합니다.

저는 이러한 분리를 설명할 때 **브라운필드 (brownfield)**라는 단어를 자주 듣습니다. 역사적으로 이는 10년 된 Java 프로젝트 같은 것을 의미했지만, 현재 우리가 배포할 수 있는 속도를 고려하면, 에이전트가 구축한 코드베이스는 아마도 3개월에서 6개월 정도 후에 어려움을 겪기 시작하는 것처럼 느껴집니다. 즉, 속도가 느려지기 시작하며, 새로운 것을 추가하는 접근 방식이 바뀌어야만 합니다.

저는 커리어 내내 소프트웨어 팩토리 (software factories)를 구축하고 연구해 왔지만, 이것을 최근에야 알게 되었습니다. 이 용어는 1968년 NATO 컨퍼런스까지 거슬러 올라가는데, 바로

사람들이 무엇을 만들지 결정합니다 -- 엔지니어, PM, 비전을 추진하는 리더십
트래커(tracker)에 기록됩니다 -- Linear, Jira 등 무엇이든: 무엇이 일어나야 하는지에 대한 상태 머신 (state machine)
누군가 티켓을 가져가서 만듭니다 -- 아마 그 과정에서 수동/자동 테스트를 병행할 것입니다
풀 리퀘스트 (Pull request) -- 자동화된 체크, 사람이 코드를 리뷰하며, 아마 누군가는 테스트를 위해 코드를 내려받을 것입니다
문제가 있나요? 루프를 돌립니다 -- 다시 "누군가 그것을 만드는 단계"로 돌아갑니다
프로덕션(prod)에 배포합니다 -- 그리고 사용자와 접촉하게 됩니다
모니터링을 추가합니다 -- 무언가 고장 났을 때 새벽 3시에 엔지니어에게 호출(paging)을 보내는 일에 기반한 거대한 산업이 이미 존재합니다
사용자가 불만을 제기합니다 -- 무언가를 요구하거나, 버그를 발견하거나, 기능 요청(feature request)을 제출합니다 → 다시 팀으로 돌아가 트래커에 추가합니다

wsff-boxes-2x.mp4

이런 과정이 계속 반복됩니다. 아직 AI에 대해서는 언급조차 하지 않았는데도, 이미 이 그림 안에는 여러 개의 루프가 존재합니다.

팀들이 수십 년 전에 깨달은 사실은 이것입니다: 빌드(building)에 몇 시간 또는 며칠이 걸리며, 리뷰(review) 역시 마찬가지라는 점입니다.

그래서 우리는 계획(planning), 아키텍처 제안(architecture proposals), 스프린트 계획(sprint planning)과 같은 작업들을 팀으로서 함께 수행하며 앞단에 배치(front-load)합니다. 이는 다음을 의미합니다:

재작업(rework) 감소: 코드를 작성하기 전에 이미 조율을 마쳤기 때문입니다.
모든 줄을 리뷰하는 시간 감소: 길지만 잘 작성된 PR을 읽어본 적이 있다면, 내용이 완벽에 가까울 때 리뷰가 얼마나 빠르게 진행되는지 알 것입니다.

이 내용은 나중에 다시 다루겠습니다. 이제 에이전틱 코딩 (agentic coding)이 이 그림에 들어왔을 때 어떤 일이 발생하는지 살펴봅시다.

이제 모든 회사와 그 주변 사람들 모두가 --

올해의 대부분을 자신들이 어떻게 코드의 75% 정도를 배포하는 에이전트 팩토리 (agent factory)를 구축했는지 설명하는 데 소비했습니다.

에이전틱 팩토리 (agentic factory)는 대부분 **"누군가 그것을 만든다" → "에이전트가 그것을 만든다"**로 교체된 모습입니다. 여기에는 오케스트레이션 (orchestration), 하네스 (harness), 샌드박스 (sandbox), 모델 (model), 컴퓨터 사용 (computer use) 등과 같은 요소들이 포함됩니다. 저는 이 세부 사항들에 대해 깊이 파고들지 않겠습니다. 솔직히 말해서 저는 이런 글을 읽는 것에 질렸고, 여러분도 분명히 그럴 것이기 때문입니다.

에이전트가 그것을 만들 때:

• 빌드 시간이 몇 시간 또는 며칠에서 몇 분 또는 몇 시간으로 단축됩니다.
• 리뷰는 여전히 몇 시간 또는 며칠이 걸립니다. 사람이 코드를 읽고 변경 사항을 테스트해야 합니다. 따라서 리뷰가 이제 병목 지점입니다.

그래서 리뷰 속도까지 높일 수 있습니다:

• 스타일, 버그, 보안 취약점을 잡아내는 에이전트 기반 코드 리뷰(Agentic code review).
• 브라우저와 컴퓨터 사용으로 외부에서 테스트하고 완료되면 귀여운 작은 비디오를 보내줄 수도 있는 에이전트 기반 회귀 테스트(Agentic regression testing).

리뷰는 이제 더 빨라졌지만, 여전히 병목 지점일 가능성이 높습니다. 하지만 우리는 더 많은 루프를 돌릴 수 있습니다.

다음으로는 인시던트(incident)를 팩토리로 라우팅할 수 있습니다. 새벽 3시에 누군가에게 페이지를 보내는 대신, 그들은 이미 수정되었을 수도 있는 PR에 일어나게 됩니다.

사용자 피드백도 팩토리로 라우팅할 수 있습니다. 사람들이 무언가를 요청하면, 그것이 만들어집니다.

이 지점에 이르면 작업은 두 가지 질문으로 귀결됩니다: 대기열에 얼마나 많은 것을 채울 수 있는가, 그리고 나오는 것을 얼마나 빠르고 잘 리뷰하고 테스트할 수 있는가?

이것이 바로 '상시 가동 소프트웨어 팩토리(lights-off software factory)'로 이어집니다.

dan Shapiro가 이 용어를 만들었고 Simon Willison은 StrongDM의 구현 사례에 대해 글을 썼습니다. 그곳에서는 우리가 더 이상 코드를 읽지 않습니다.

당신은 아름다운 소프트웨어 팩토리를 바라봅니다. 그것이 짜증 나는 작은 코드 리뷰 단계 때문에 망가지고, 당신은 이렇게 말합니다: 있잖아요, 사람이 모든 변경 사항을 읽는 그 작업? 됐어요. 고맙습니다.

그래서 그것을 제거하고 노력을 다른 곳에 투자합니다:

• 테스트에 투자하고 에이전트가 자체 작업을 테스트하도록 합니다.
• 샌드박스(sandboxes)와 오케스트레이션(orchestration)에 투자합니다.
• 자동화된 리뷰에 투자합니다.
• 모니터링에 투자합니다.
• 배포(rollout)에 투자합니다.
• 사용자로부터 피드백 신호를 수집하는 데 투자합니다.

그리고 이제 작업은 정말 단 하나의 질문으로 귀결됩니다: 우리가 에이전트에게 얼마나 많은 것을 만들도록 요청할 수 있는가? 바다의 얼마나 많은 부분을 끓여낼 것인가?

저는 잠재적으로 논란이 될 만한 주장을 하려고 합니다: 상시 가동 팩토리는 작동하지 않습니다.

왜 소프트웨어 팩토리가 실패하는지 알아보겠습니다.

2025년 7월에 우리는 완전한 상시 가동(full lights-off) 상태로 갔습니다. 스펙과 티켓만 읽고, 모든 소규모/중규모 작업에 대한 백그라운드 에이전트가 작동하게 했습니다. 그게 전부였습니다.

만약 당신이 이것을 몇 달 동안 진지하게 시도해 보았다면, 결과가 어떻게 끝나는지 이미 알고 있을 것입니다. 당신의 가장 진보된 프롬프팅 (prompting)과 워크플로우 (workflows)를 동원하더라도 에이전트가 해결할 수 없을 만큼 까다로운 문제를 적어도 하나는 발견하게 됩니다.

• 당신은 모델이 분석할 수 있도록 모든 적절한 부분들을 스마트 존 (smart zone)으로 모아 깊이 있는 컨텍스트 인식 (context-aware) 조사를 수행합니다.
• 에이전트가 10가지 다른 방식으로 재현하도록 시도합니다.

결국 당신은 체념하고, 무엇이 고장 났는지 알아내기 위해 3개월 전에 읽기를 중단했던 코드베이스 (codebase)를 파헤치러 가야만 합니다.

그리고 그동안:

• 당신의 사이트는 다운되었습니다.
• 사용자들은 화가 났습니다.
• 그리고 만약 당신이 저와 비슷하다면, 당신은 당신이 시스템에 흘려보낸 그 모든 형편없는 코드 (slop code)를 읽으며 비참함을 느꼈을 것입니다.

이런 일이 처음 발생했을 때, 저는 그냥 넘겼습니다. Claude가 만들어낸 스파게티 코드 (spaghetti code)를 파헤치는 데 거의 2주를 보냈음에도 불구하고, "속도 (velocity)를 위해서라면 하방 리스크 (downside risk)를 감수할 가치가 있다"고 생각했습니다. 11월쯤 세 번째로 이런 일이 발생했을 때, 우리는 처음부터 다시 작성하는 것이 더 쉽겠다고 결정했고, 저의 공동 창업자는 꼬박 2주 동안 (Cursor도 아닌) VS Code에서 모든 패턴을 수작업으로 하나하나 정리했습니다.

제가 말하고자 하는 핵심은 이것입니다: 모델에는 한계가 있습니다. 모델은 상당한 수준의 인간의 조종 (human steering) 없이는 시간이 지남에 따라 코드베이스의 품질을 유지하고 개선할 수 없습니다.4

제가 유지보수성 (maintainability)을 말할 때, 그것은 코드베이스의 한 부분을 변경하면 다른 부분이 깨지게 되어 정말, 정말 어려워지는 특정한 상황을 의미합니다. 이것이 바로 Martin Fowler가 말한 샷건 수술 (shotgun surgery)입니다.

유지보수성에 대해 더 이상 많은 말을 하지는 않겠습니다. 이에 대해 읽어볼 수 있는 책들이 많이 있습니다.

• John Ousterhout의 A Philosophy of Software Design
• Robert C. Martin의 Clean Code
• Martin Fowler의 Refactoring

그렇다면, 왜 모델은 소프트웨어 유지보수성을 수행할 수 없는 걸까요?

이 시점에서 당신은 이렇게 말하고 싶어 죽을지도 모릅니다: 하지만 Dex, 분명 모델들이 7월 이후로 훨씬 좋아졌잖아요.

어떤 면에서는 그렇습니다. 하지만 다른 면에서는 여전히 비슷합니다.

• 일회성 문제를 해결하거나, 새로운 마케팅 사이트를 바이브 코딩 (vibe-coding) 하는 것? 네, 훨씬 좋아졌습니다.
• 시간이 지남에 따라 코드베이스 (codebase) 품질을 개선하는 것? 제가 알기로는 별로 나아지지 않았습니다.

저는 이것을 증명할 수 없습니다. 여러분도 증명할 수 없습니다. 모델의 코드베이스 품질 유지 능력에 대한 좋은 벤치마크 (benchmarks) 가 없기 때문입니다. (이 부분에 대해서는 나중에 더 자세히 다루겠습니다.)

하지만 코딩 에이전트 (coding agents) 와 한동안 작업해 보셨다면 — 그리고 실제로 많은 사람이 정확히 이 점에 대해 글을 올리고 있습니다 — 아마 이미 느낌(vibe)을 알고 계실 것입니다. 에이전트들은 시간이 지날수록 상황을 악화시키고, 코드베이스를 작업하기 더 어렵게 만드는 경향이 있습니다.

그래서 왜 이런 일이 발생하는지 알아보기 위해, 첫 번째 위대한 코딩 에이전트로 시야를 넓혀보고자 합니다.

Claude Code는 1년도 채 되지 않아 매출이 0달러에서 약 40억 달러 — 현재는 약 90억 달러 — 로 성장했습니다.

이는 조금 놀라운 일인데, 이미 훌륭한 CLI 에이전트들이 있었기 때문입니다. aider, cline, codebuff는 모두 Claude Code보다 앞서 나왔으며, 모두 진정으로 훌륭한 컨텍스트 엔지니어링 (context engineering) 이 내장되어 있었고, Claude Code에 부여할 법한 동일한 도구 세트(읽기, 쓰기, 편집, grep, bash)를 갖추고 있었습니다. 저도 그것들을 사용해 보았습니다. 좋았습니다. 하지만 도구 사용 (tool use) 이 가끔... 실패하곤 했습니다. 에이전트가 동일한 편집 작업을 세 번이나 허우적대며 실패하는 것을 지켜보다가, 결국 직접 하기 위해 에디터를 다시 열어야만 했습니다.