코드는 더 이상 희소한 자원이 아닙니다. 이것이 변화시키는 것들

소프트웨어 역사의 대부분 동안 병목 현상은 구현 (implementation)이었습니다. 코드를 작성하는 것은 어렵고, 느리며, 비용이 많이 드는 부분이었습니다. 우리가 구축한 모든 엔지니어링 관행—코드 리뷰 (code review), 페어 프로그래밍 (pair programming), 신중한 채용, 스프린트 계획 (sprint planning)—은 정확한 코드를 작성하는 것이 희소하고 가치 있었기 때문에 존재합니다.

그 가정이 깨지고 있습니다. 에이전트 (agent)가 당신이 검토하는 속도보다 더 빠르게 작동하는 구현물을 만들어낼 수 있게 되면, 코드는 더 이상 희소한 자원이 아닙니다. 그리고 희소한 자원이 바뀌면, 과거의 희소성을 중심으로 구축된 모든 것이 재구축되어야 합니다.

이것이 제가 '하네스 엔지니어링 (harness engineering)'이라고 부르게 된 것입니다. 이는 인간이 조종 (steering)을 하는 동안 에이전트가 구현을 수행할 수 있도록 하는 시스템을 구축하는 규율입니다. 이는 소프트웨어 엔지니어링 (software engineering)과는 다른 직업이며, 당신을 과거의 직업에서 유능하게 만들었던 대부분의 본능이 새로운 직업에서는 오히려 당신에게 불리하게 작용합니다.

제가 이를 어떻게 생각하는지 설명하겠습니다.

핵심적인 변화: 인간은 조종하고, 에이전트는 실행한다

다른 모든 것을 가능하게 하는 사고 모델은 다음과 같습니다: 당신은 더 이상 코드를 작성하는 사람이 아닙니다. 당신은 무엇이, 왜, 어떤 표준으로 작성될지를 결정하는 사람입니다.

이로부터 세 가지 전제가 도출되며, 이는 충분히 숙고하기 전까지는 불편하게 들릴 수 있습니다:

코드는 풍부한 자원이다

구현을 생성하는 비용이 저렴하다면, 코드 그 자체는 더 이상 당신이 보호해야 할 대상이 아닙니다. 코드는 재생성할 수 있습니다. 버릴 수도 있습니다. 가치는 스택의 상위 단계인 명세 (specification), 아키텍처 (architecture), 검증 (validation)으로 이동합니다.

토큰 빌리어네어 (token billionaire) 마인드셋

만약 당신이 토큰 (token)을 소중한 것으로 취급하며 사재기한다면, 시스템을 충분히 활용하지 못할 것입니다. 에이전트로부터 가장 많은 것을 얻어내는 엔지니어들은 여러 번의 시도를 실행하고, 버려질 탐색 (exploration)을 생성하며, 에이전트가 반복 (iterate)할 수 있도록 토큰을 자유롭게 사용합니다. 토큰은 저렴한 자원입니다. 비싼 자원을 아끼기 위해 토큰을 사용하십시오.

구현은 더 이상 희소하지 않다

이것은 다른 모든 것들이 기반을 두는 전제입니다. 만약 이 전제를 받아들이지 않는다면, 당신은 잘못된 것을 최적화하게 될 것입니다. 즉, 구현 (implementation)을 보호하는 데 급급할 것이 아니라, 구현을 안전하게 재생성할 수 있게 만드는 아키텍처 (architecture)를 보호해야 함에도 불구하고 말입니다.

현재 실제로 희소한 것들

세 가지 자원이 진정으로 제한되어 있으며, 하네스 엔지니어링 (harness engineering)은 이 세 가지를 모두 보존하는 실천법입니다.

엔지니어의 역할은 이제 기본적으로 스태프 레벨 (staff-level)입니다

만약 당신이 구현을 직접 작성하지 않는다면, 당신은 무엇을 하고 있습니까? 스태프 엔지니어 (staff engineer)가 하는 것과 동일한 일을 하고 있습니다. 다만 이제 그것은 당신이 성장하며 도달하게 되는 일부가 아니라, 직무 전체가 되었습니다.

1. 시스템 사고 및 설계 (Systems thinking and design) - 아키텍처는 당신의 몫이며, 구현은 위임됩니다.

2. 위임 및 오케스트레이션 (Delegation and orchestration) - 명확한 계약 (contracts)을 가진 에이전트 크기의 단위로 작업을 분할합니다.

3. 비기능적 요구사항 명시 (Specifying non-functional requirements) - 성능, 신뢰성, 보안 등 에이전트가 스스로 추론하지 못하는 것들입니다.

4. 스태프 엔지니어 마인드셋 (Staff engineer mentality) - 코드 한 줄이 아니라 시스템을 생각합니다.

깨끗한 함수를 작성하는 주니어 엔지니어의 기술은 이제 에이전트가 처리하는 기본 요건 (table stakes)이 되었습니다. 무엇을 구축해야 하는지, 그리고 그것이 어떻게 구조화되어야 하는지를 결정하는 시니어의 기술이 이제 직무의 전부입니다.

하네스 구축하기

하네스 (harness)는 에이전트를 생산적이고 안전하게 만드는 인프라입니다. 세 가지 구성 요소가 대부분의 작업을 수행합니다.

기술 프레임워크 (A skills framework)

에이전트에게 필요한 고레버리지 (high-leverage) 역량을 중앙 집중화하고, 그 뒤에 인프라의 복잡성을 숨기십시오. 에이전트가 테스트 스위트 (test suite)를 실행하거나 프리뷰 (preview)를 배포하는 방법을 고민해서는 안 됩니다. 대신 이를 처리하는 로컬 개발 도구를 호출해야 합니다.

기술이 인터페이스 (interface)가 되고, 복잡성은 그 뒤에 존재합니다. 이는 대규모 코드베이스를 유지 관리 가능하게 만드는 추상화 원칙 (abstraction discipline)과 동일하며, 이를 에이전트의 역량에 적용한 것입니다.

컨텍스트 관리 (Context management)

이 지점이 대부분의 하네스(harness)가 성공하거나 실패하는 지점입니다. 효과적인 세 가지 기술은 다음과 같습니다: 자동 압축 (auto-compaction, GPT-5.4/Codex와 같은 모델은 실행이 길어짐에 따라 컨텍스트를 압축함), 적시 지침 (just-in-time instructions, 모든 지침을 미리 제공하는 것이 아니라 작업에 필요할 때 관련 가이드를 로드함), 그리고 리뷰어를 통한 컨텍스트 갱신 (refreshing context via reviewers, 리뷰어 에이전트가 작업 에이전트의 컨텍스트가 표류할 때 다시 기반을 잡아줌).

컨텍스트 윈도우 (context window)는 장기적인 관점에서 가장 희소한 자원입니다. 이를 관리하는 것은 단순히 있으면 좋은 기능이 아니라, 20개의 마일스톤 동안 일관성을 유지하는 에이전트와 5번째 마일스톤에서 맥락을 놓쳐버리는 에이전트를 가르는 차이점입니다.

프롬프트 인젝션 지점 (Prompt injection points)

하네스는 시작 시점에 하나의 거대한 시스템 프롬프트(system prompt)를 던지는 것이 아니라, 에이전트가 지침을 가장 잘 받아들일 수 있는 순간에 가이드를 주입해야 합니다. 네 가지 고가치 인젝션 지점은 다음과 같습니다: 코드베이스에 남겨진 규칙 파일 및 브레드크럼 (breadcrumbs), 린트(lint) 에러 메시지 (린트 실패는 교육의 순간임), 테스트 실패 교정 (단순히 실패했다는 사실이 아니라 어떻게 수정해야 하는지 에이전트에게 알려줌), 그리고 리뷰어 에이전트의 코멘트입니다. 각각은 실행 가능한 시점에 정확히 전달되는 컨텍스트입니다.

팀의 운영화 (Operationalizing the team)

개별 에이전트의 생산성은 별개의 문제입니다. 이러한 방식으로 팀을 운영하려면 의도적인 운영상의 선택이 필요하며, 그중 일부는 왜 작동하는지 확인하기 전까지는 급진적으로 느껴질 수 있습니다.

수동 코드 편집 금지 (Ban manual code editing)

극단적으로 들릴 수 있습니다. 그 이유는 다음과 같습니다: 만약 인간이 코드를 직접 편집하면, 코드베이스에 대한 에이전트의 모델이 현실과 괴리되어 재생성(regeneration) 안전망이 깨지게 됩니다. 모든 것이 에이전트를 거쳐 간다면, 코드베이스는 에이전트 친화적(agent-native)인 상태를 유지합니다. 이러한 규율이 바로 풍요로움을 사용 가능하게 만드는 핵심입니다.

가비지 컬렉션 데이 (Garbage collection day)

에이전트는 쓰레기, 즉 죽은 코드(dead code), 불필요한 추상화, 일관성 없는 패턴을 생성합니다. 가비지 컬렉션(GC) 패스가 메모리를 회수하는 것과 같은 방식으로, 이를 정리하기 위한 전용 시간을 예약하십시오. 정리를 사후 처리가 아닌 일급 스케줄 활동(first-class scheduled activity)으로 취급하는 것이 코드베이스를 건강하게 유지하는 방법입니다.
페르소나 중심의 문서화 (Persona-oriented documentation).

그것을 읽게 될 에이전트 페르소나(agent personas)를 위해 문서를 작성하십시오. 예를 들어 프론트엔드 아키텍트(front-end architect) 페르소나, 신뢰성/확장성 전문가(reliability/scalability expert) 페르소나, QA 전문가(QA specialist) 페르소나 등이 있습니다. 각 페르소나는 자신이 내리는 결정에 맞춰 조정된 문서를 받게 됩니다. 일반적인 문서는 누구에게도 도움이 되지 않지만, 페르소나 중심의 문서는 각 에이전트가 자신의 특정 작업에 더 날카로워지도록 만듭니다.

동기식 인간 차단(synchronous human blocks) 제거

워크플로우가 인간을 기다리기 위해 멈추는 모든 곳은 가장 희소한 자원에 대한 병목 현상(bottleneck)입니다. 인간의 입력이 비동기적(asynchronous)이 되도록 구조를 재편하십시오. 즉, 에이전트가 합리적인 기본값(defaults)을 가지고 진행하되, 차단(blocking) 없이 검토를 위한 결정 사항을 표면화(surfaces)하도록 해야 합니다.

에이전트 네이티브 코드베이스 아키텍처 (Agent-native codebase architecture)

인간의 가독성에 최적화된 코드베이스는 에이전트에 최적화된 코드베이스와 다릅니다. 구조적 선택이 달라집니다:

750개 이상의 패키지라는 숫자는 인간의 기준으로는 터무니없어 보입니다. 아무도 그렇게 많은 패키지를 수동으로 탐색하고 싶어 하지 않기 때문입니다. 하지만 에이전트는 탐색하지 않습니다. 필요한 패키지만 정확히 로드합니다. 독자가 유한한 컨텍스트 창(context window)을 가진 모델일 때, 극단적인 모듈화(Extreme modularization)는 하나의 기능(feature)이 됩니다.

이것이 향하는 방향

이 전제들을 진지하게 받아들인다면 뒤따라오는 네 가지 아이디어는 다음과 같습니다:

퍼지 컴파일러(fuzzy compiler)로서의 LLM.

전통적인 컴파일러는 정밀한 소스(source)를 결정론적(deterministically)으로 머신 코드(machine code)로 변환합니다. LLM은 모호한 의도(fuzzy intent)를 확률적(probabilistically)으로 구현(implementation)으로 변환합니다. 만약 이러한 프레임을 받아들인다면, 당신의 업무는 출력이 아닌 명세(specification)를 작성하여 퍼지 컴파일러를 위한 소스를 쓰는 것이 됩니다.

토큰 예산 기반 개발 (Token budget-driven development).

만약 토큰이 구축의 비용이라면, 개발은 과거에 엔지니어 시간(engineer-hours)을 기준으로 계획했던 것처럼 토큰 예산(token budgets)을 중심으로 계획됩니다. 질문은 '얼마나 많은 엔지니어가 필요한가'가 아니라 '이 토큰 예산으로 무엇을 만들 수 있는가'가 됩니다.

일회용 빌드 산출물로서의 코드 (Code as a disposable build artifact).

이것은 코드가 풍부해짐에 따라 도달하게 될 논리적 종착점입니다. 만약 명세(Specification)로부터 구현(Implementation)을 재생성할 수 있다면, 구현은 컴파일된 바이너리(Compiled binary)와 같은 빌드 산출물(Build artifact)이 됩니다. 우리는 모든 바이너리를 조심스럽게 보존하지 않습니다. 대신 그것을 생성하는 소스(Source)를 보존합니다. 이제 '소스'는 명세와 아키텍처(Architecture)가 됩니다.
자율적인 제품 발전.

더 먼 종착점은, 인간이 방향 설정, 검증 및 판단에 완전히 집중하는 동안, 구현 계층(Implementation layer)에서 인간의 개입이 점차 줄어들며 제품을 발전시키는 시스템입니다.

내가 실제로 얻은 통찰

이곳의 모든 전제가 확정되었다고 생각하지는 않습니다. '일회용 산출물로서의 코드'는 강력한 주장이며, 구현을 버리기 전에는 재생성이 신뢰할 수 있을 만큼 충분히 안정적이어야 합니다. 제가 직접 수행한 벤치마크(Benchmark)에서 발견한 통계적 유효성 격차를 고려할 때, 이 부분은 아직 완전히 충족되지 않았습니다.

하지만 핵심적인 변화는 실재하며 이미 일어나고 있습니다. 희소한 자원은 구현에서 주의력(Attention)으로 이동하고 있습니다. 가장 빠르게 적응하는 엔지니어들은 자신의 코드를 지키는 것을 멈추고, 자신의 아키텍처와 명세를 지키기 시작한 사람들입니다.

이러한 적응을 일컫는 이름이 바로 '하네스 엔지니어링 (Harness engineering)'입니다. 이 비전 전체를 수용하든 그렇지 않든, 컨텍스트(Context)를 무자비하게 관리하고, 명확하게 명세하며, 코드베이스를 에이전트 친화적(Agent-native)으로 유지하고, 주의력을 아끼기 위해 토큰(Token)을 아낌없이 사용하는 실용적인 핵심 원칙은 지금 바로 채택할 가치가 있습니다.

코드가 풍부하다는 점, 구현이 더 이상 희소하지 않다는 점, 혹은 코드가 일회용 빌드 산출물이라는 점 중 당신이 가장 강하게 반박하고 싶은 전제는 무엇입니까?