엔지니어링의 제어: 인간의 지능이 가이드하는 AI의 힘

바이브 코딩 (Vibe coding)은 우리에게 매혹적인 꿈을 제시했습니다. AI와 대화를 나누고, 코드가 존재한다는 사실조차 잊은 채 소프트웨어를 출시하는 것입니다. 이는 국소적이고 일회적인 문제를 해결하는 데는 유용한 방법이 될 수 있습니다. 하지만 수년간 살아 숨 쉬고 진화해야 하는 프로덕션 시스템 (Production systems)의 경우에는 이야기가 달라집니다.

"하네스 엔지니어링 (Harness engineering)"이라 불리는 새로운 개념은 프로덕션급 AI 생성 코드를 만들기 위해 무엇이 필요한지를 가리키며, 그 이름에 숨겨진 은유가 모든 것을 말해줍니다.

말과 마구 (The horse and the harness)

말은 강력한 동물이지만, 제어되지 않은 상태로 내버려 두면 자신이 원하는 방향으로 힘을 쏟습니다. 마구 (Harness)는 말의 힘을 약화시키는 것이 아니라, 그 힘을 한곳으로 모아줍니다. 고삐를 잡고 있는 인간은 물리적인 일을 하는 것이 아니라 지적인 일을 수행합니다. 즉, 목적지를 선택하고, 지형을 읽으며, 언제 속도를 줄여야 할지를 결정하는 것입니다.

하네스 엔지니어링도 이와 동일하게 작동합니다. AI 에이전트 (AI agent)는 당신의 말입니다. AI는 생성적이고, 빠르며, 지치지 않고, 소수의 엔지니어 팀이 작업을 지시하는 것만으로도 대규모 소프트웨어 시스템을 생산할 수 있는 능력을 갖추고 있습니다. 마구는 그 모든 가공되지 않은 능력을 일관성 있고, 유지보수 가능하며, 신뢰할 수 있는 무언가로 유도하는 도구, 제약 조건, 그리고 피드백 루프 (Feedback loops)의 체계입니다.

팀이 마구 없이 AI 에이전트로 대규모 시스템을 구축하려고 시도할 때, 그들은 대개 말에게 치이고 짓밟히게 됩니다. 만약 프로세스의 일부로 수정 세션 (Fixing sessions)이나 정리하는 날 (Tidy-up days)을 따로 잡아야 하는 상황이라면, 당신에게 마구가 없다는 사실을 알게 될 것입니다.

바이브 코딩이 확장(Scale)되지 않는 이유

Andrej Karpathy가 2025년 초 "바이브 코딩 (Vibe coding)"이라는 용어를 만들었을 때, 그는 매우 솔직한 무언가를 설명하고 있었습니다. 그것은 바로 "분위기(vibes)에 완전히 몸을 맡기고, 기하급수적인 성장을 받아들이며, 코드가 존재한다는 사실조차 잊어버리는" 방식입니다.

바이브 코딩 (vibe coding)을 할 때, 당신은 모든 변경 사항을 검토 없이 수용하고, 발생하는 모든 에러 메시지를 AI에게 다시 전달하여 수정하게 합니다. 이러한 접근 방식을 사용하면, 성공과 실패의 수준이 당신을 서로 다른 경로로 밀어붙이도록 내버려 두게 됩니다. 만약 코드가 원하는 대로 작동하지 않는다면, 작동하는 무언가를 얻기 위해 당신의 아이디어를 유연하게 수정합니다.

Karpathy는 이것이 "한 번 쓰고 버릴 주말 프로젝트"에는 효과적이라고 말했지만, 1년이 지난 지금 그는 이 방식의 전문적인 버전을 "에이전틱 엔지니어링 (agentic engineering)"이라고 부르고 있습니다.

이 차이는 중요합니다. 바이브 코딩은 인식론적으로 수동적입니다. 즉, 키보드와 함께 이해(understanding)를 포기하는 것입니다. 반면 하네스 엔지니어링 (harness engineering)은 인식론적으로 요구 사항이 많습니다. 단지 당신이 이해해야 할 대상을 재지정할 뿐입니다. 모든 함수를 이해하는 대신, 함수가 작성되는 방식을 제약하는 시스템을 이해해야 합니다.

OpenAI는 실험의 일환으로 하네스 엔지니어링을 만들었습니다. 한 팀이 수동으로 작성된 코드 없이 내부 제품을 구축하는 데 5개월을 보냈습니다. 로직, 테스트, 빌드 구성, 문서화, 그리고 관찰 가능성 (observability) 도구 모두가 AI 에이전트 (AI agents)에 의해 생성되었습니다. 그들은 3명의 엔지니어로 100만 줄 이상의 코드를 생성했으며, 내부 사용자 및 외부 알파 테스터들에게 시스템을 배포했습니다. 그들은 이 작업이 AI 에이전트 없이 팀이 시스템을 작성했을 때 걸렸을 시간의 10%밖에 걸리지 않았다고 추정합니다.

이 실험을 통한 통찰은 AI 에이전트가 제대로 작동하는 소프트웨어를 전달하게 만드는 핵심 요소가 바로 "환경 판독성 (environment legibility)"이라는 점이었습니다. 이러한 판독성이 없다면, 에이전트는 작업을 완료하는 데 필요한 정보를 찾거나 추론할 수 없기 때문에 실패하게 됩니다.

하네스 엔지니어링을 작동하게 만드는 3가지 관행

OpenAI의 글과 Thoughtworks 블로그에 게재된 Birgitta Böckeler의 날카로운 분석에 따르면, 하네스 엔지니어링은 세 가지 범주의 관행을 중심으로 모입니다.

컨텍스트 엔지니어링 (Context engineering)

현재 사용 가능한 AI 에이전트(AI agents)의 경우, 컨텍스트(context)는 매우 귀중한 자원입니다. 무제한의 컨텍스트 윈도우(context window)를 가질 수 없으므로, 이를 어떻게 사용할지 영리하게 결정해야 합니다. 지침(instructions)으로만 가득 찬 거대한 에이전트 마크다운(agent markdown) 파일을 제공하는 것은 실제 작업(task)을 밀어낼 뿐입니다. 또한 거대한 에이전트 마크다운 파일은 이해하고 업데이트하기 어렵습니다.

대신, 에이전트 마크다운 파일을 100줄 이내로 제한하고 이를 목차(table of contents)로 사용하십시오. 맵(maps), 실행 계획(execution plans), 설계 사양서(design specifications)가 담긴 개별 문서로 연결할 수 있습니다. 이러한 문서들은 코드베이스(codebase) 내에 잘 정리되어 버전 관리(versioned)가 되고 검색 가능(discoverable)해야 합니다.

관측 가능성 데이터(observability data), 로그(logs), 메트릭(metrics), 트레이스(traces), 그리고 브라우저 개발자 도구(browser dev tools)의 정보를 통해 동적 컨텍스트(dynamic context)를 제공할 수 있습니다. 이를 통해 에이전트는 자신이 유발한 버그를 스스로 감지하고 수정할 수 있습니다.

아키텍처 제약 조건 (Architectural constraints)

이 지점은 하네스 엔지니어링(harness engineering)이 바이브 코딩(vibe coding)의 "무엇이든 허용되는" 철학으로부터 가장 명확하게 갈라지는 부분입니다. OpenAI 팀은 비즈니스 도메인(business domain)을 다음과 같은 고정된 계층(layers)의 시퀀스로 나누는 엄격한 아키텍처 모델을 강제했습니다:

Types → Config → Repo → Service → Runtime → UI

의존성(Dependencies)은 오직 화살표 방향으로만 흐를 수 있으며, 인증(auth), 텔레메트리(telemetry), 피처 플래그(feature flags)와 같은 횡단 관심사(cross-cutting concerns)는 "Providers"라고 불리는 단일 명시적 인터페이스를 통해서만 들어옵니다. 그 외의 것은 허용되지 않습니다. AI 에이전트를 사용하여 구현할 수 있는 커스텀 린터(custom linters)와 구조적 테스트(structural tests)를 통해 설계를 강제해야 합니다.

커스텀 강제 도구(custom enforcement tools)의 에러 메시지를 활용하여 수정 지침(remediation instructions)을 제공함으로써, AI 에이전트가 위반 사항을 스스로 수정할 수 있도록 할 수 있습니다.

가비지 컬렉션으로서의 엔트로피 관리 (Entropy management as garbage collection)

에이전트는 패턴 복제기(pattern replicators)입니다. 만약 일관성 없는 코드로 가득 찬 코드베이스를 제공한다면, 에이전트는 이를 대규모로 충실하게 재현할 것입니다. 편차를 스캔하고 자동으로 수정하는 백그라운드 에이전트(background agents)를 실행함으로써 이 문제를 해결할 수 있습니다. 향후 에이전트 실행 시 가독성을 유지할 수 있도록 코드를 잘 팩터링(factored)하고 일관되게 유지해야 합니다.

에이전트가 작업에 어려움을 겪을 때, 수동으로 직접 수정해서는 안 됩니다. 어떤 능력(capability)이 부족한지 식별한 다음, 에이전트가 이해할 수 있고(legible) 강제할 수 있도록(enforceable) 만드세요. 조정을 마친 후에는 AI 도구를 사용하여 수정 사항을 작성하게 합니다. 이는 하네스(harness)를 개선하고 시간이 지남에 따라 그 가치를 더욱 높여줍니다.

하네스 엔지니어링(harness engineering)에서 인간의 역할

에이전트가 코딩을 처리함에 따라, 인간은 환경 설계(designing environments), 의도 명시(specifying intent), 그리고 피드백 루프(feedback loops) 구축으로 초점을 전환합니다.

환경 설계는 코드, 문서, 그리고 제약 조건(constraints)의 배치와 관련이 있습니다. 의도는 상위 수준의 목표를 일관된 구현으로 연결하는 정밀한 프롬프트(prompts)를 통해 명시됩니다. 피드백 루프는 테스트 자동화, 구조적 점검, 그리고 에이전트 주도의 리뷰를 통해 이루어지며, 에이전트가 수행하는 작업을 인간이 개입하여 수정해야 하는 필요성을 최소화합니다.

코드 리뷰의 부담은 하네스에 내장된 기계적 점검(mechanical checks)을 통해 관리되며, 에이전트가 초기 리뷰를 담당합니다. 리뷰는 새로운 아키텍처 설계(architectural design)를 승인해야 하는 경우와 같이 인간의 판단이 필요한 경우에만 상위 단계로 에스컬레이션(escalated)됩니다. 이는 코드 리뷰가 병목 현상(bottleneck)이 되는 것을 방지합니다.

이것이 미래에 의미하는 바

플랫폼 엔지니어링(Platform Engineering) 커뮤니티에서 우리는 플랫폼 엔지니어의 역할을 AI의 조직적 조력자(organizational enablers)로 논의해 왔습니다. 플랫폼 팀은 환경의 가독성을 확보하고 적절한 제약 조건을 제공하기 위한 하네스 엔지니어링용 템플릿을 생성하고 유지 관리할 수 있습니다. 심지어 공유 가능한 커스텀 린터(custom linters)와 구조적 테스트 도구를 제공할 수도 있습니다.

하네스 엔지니어링을 기존 코드베이스에 도입하는 것은 새로운 시스템에 적용하는 것보다 더 어려울 수 있습니다. 명확한 표준이 적어 하네스가 약화될 수 있기 때문입니다. 이미 구축된 코드베이스에 축적된 엔트로피(entropy)는 테스트 주도 개발(TDD)이나 코드 린터(code linter)를 처음 도입할 때와 유사한 문제를 야기할 것입니다.

하네스 엔지니어링 (harness engineering)이 탄력을 받게 되면, 업계가 지루하지만 잘 확립된 기술적 선택지로 수렴하도록 유도할 것입니다. 훈련 데이터 내에 고품질 샘플이 더 많고 수년간 커뮤니티의 질의응답 (Q&A) 데이터가 축적된 프로그래밍 언어 및 기술 스택 (tech stacks)은 니치 (niche)한 기술 스택보다 자연스럽게 더 나은 결과를 만들어낼 것입니다.

하네스 엔지니어링과 지속적 인도 (Continuous Delivery)

이미 지속적 인도 (Continuous Delivery)를 실천하고 있는 팀에게 하네스 엔지니어링은 자연스럽게 부합합니다. 이러한 기술들은 기존의 피드백 루프 (feedback loops) 및 검증 관행에 녹아들 것입니다.

하네스 엔지니어링은 팀이 고품질 문서화 (documentation), 모듈형 설계 (modular design), 일관된 명명 규칙 (consistent naming), 그리고 아키텍처 결정 사항 (architectural decisions) 기록과 같이 오랫동안 유지되어 온 좋은 관행들을 채택하도록 강제합니다. 에이전트 (Agents)는 암묵적 지식 (tacit knowledge)을 가지고 있지 않습니다. 명시적으로 만들어지기 전까지 그것은 존재하지 않는 것과 같습니다.

하네스가 코드가 작성되는 방식을 제약할 뿐, 사용자의 요구사항이 충족되었는지를 검증하는 것은 아니기 때문에, 시스템이 의도한 대로 작동함을 증명하는 강력한 자동화 테스트 스위트 (automated test suite)로 하네스 엔지니어링을 보완해야 합니다.

시작하기

하네스를 구축하는 것은 지속적인 과정이며, 수개월간의 반복 (iteration)을 거치기 전까지는 그 가치가 증명되지 않을 수도 있습니다. 프리커밋 훅 (pre-commit hooks), 커스텀 린터 (custom linters), 구조적 테스트 프레임워크 (structural testing frameworks), 문서화 (documentation), 그리고 테스트 자동화 (test automation)와 같이 초기 속도를 높여줄 수 있는 기존의 기반 요소들을 찾아보아야 합니다.

각각의 기존 기반 요소들은 하네스에 엮여 들어갈 수 있으며, 이후 공백을 식별함에 따라 이를 반복적으로 개선해 나갑니다. 코드에 직접 수정하는 대신 하네스를 통해 수정을 수행함으로써, 하네스를 강화하고 에이전트의 능력을 더욱 향상시킬 수 있습니다. 동시에 인간의 업무는 방향을 선택하고 지형을 읽는 흥미로운 작업으로 전환됩니다.