복잡한 작업에서 개발자의 제어권과 AI 실행력을 극대화하십시오.

나의 여정 (My Path)

제가 AI 에이전트(AI agents)와 함께 작업을 처음 시작했을 때, 개발자가 설명하는 속도보다 더 빠르게 RESTful 개념 증명(PoC, proof-of-concept) 애플리케이션을 만들어내는 에이전트의 능력에 깊은 인상을 받았습니다. 이러한 애플리케이션의 아키텍처(architecture)는 보여주기에 적합한 수준은 아닐지라도, PoC 용도로는 대개 충분합니다.

이러한 PoC 중 일부는 수백 줄에 달하는 함수, 수십 개의 중첩된 루프(loops), 조건문(conditions), 그리고 재귀 호출(recursive calls)을 포함하고 있습니다. 확장성(scale)은 떨어지지만, 작동은 합니다. 때로는 놀라울 정도로 안정적으로 작동하기도 합니다.

이는 에이전트가 작동하는 애플리케이션 아키텍처를 생성할 수 있고, LLM(Large Language Model)이 작동하는 저수준 코드(low-level code)를 작성할 수 있음을 의미합니다.

이 때문에 저는 처음부터 잘 만들어진 애플리케이션이 왜 에이전트 주도의 비교적 작은 변경 사항들 이후에 퇴보하기 시작하는지 이해하기 어려웠습니다. 그리고 그러한 변경 사항이 축적될수록 코드베이스(codebase)는 더욱 악화되었습니다.

저는 예전에 이것을 에이전트의 한계라고 생각했습니다. 하지만 시간이 흐르면서, 개발자가 해당 변경 사항이 어떤 모습이어야 하는지를 충분히 정밀하게 설명할 때 에이전트가 좋은 변경을 수행할 수 있다는 점을 깨달았습니다.

따라서 문제는 에이전트가 작업을 완료할 수 있느냐가 아니라, 개발자가 작업을 올바르게 명시하기 위해 어떤 대가를 치러야 하는가입니다.

비용은 무엇인가? (What Is the Cost?)

자율 개발(autonomous development)의 주요 문제는 에이전트가 형편없는 코드를 작성한다는 것이 아닙니다. 문제는 그보다 더 앞선 단계에서 시작됩니다. 개발자가 구현(implementation)뿐만 아니라 솔루션의 선택까지 위임해 버리고, 정작 자신만의 예상되는 솔루션도 없이 그 결과를 검토하려고 시도한다는 점입니다.

제어권을 유지하기 위해 개발자는 먼저—독립적으로든 AI와 함께든—작업이 어떻게 해결되어야 하는지를 이해해야 하며, 그 다음 무엇을 변경할지, 무엇을 보존할지, 그리고 결과가 어떻게 평가되어야 하는지를 설명해야 합니다.

예상되는 솔루션이 없다면, 개발자는 결과가 그럴듯해 보이는지, 테스트를 통과하는지, 그리고 명백한 문제가 없는지만을 판단할 수 있을 뿐입니다. 그것만으로는 아키텍처(architecture), 의존성(dependencies), 그리고 변경 지점(change points)이 올바르게 선택되었는지 결정하기에 충분하지 않습니다.

엔지니어링 결정을 AI에게 위임한 뒤, 코드 리뷰 단계에서 다시 제어권을 되찾을 수 있기를 기대할 수는 없습니다.

만약 결과물에 심각한 문제가 포함되어 있다면, 개발자는 선택의 기로에 서게 됩니다: 이를 계속 수정할 것인가, 아니면 처음부터 다시 작업을 구현할 것인가.

매 반복(iteration)은 리뷰를 더 어렵게 만듭니다. 새로운 변경 사항을 기존 코드베이스(codebase)와 에이전트(agent)의 이전 수정 사항 모두에 비추어 평가해야 하기 때문입니다. 결과물을 포기하는 것도 점점 더 어려워집니다. 프롬프팅(prompting), 생성(generation), 그리고 리뷰에 시간을 투자한 후에는, 전체 결과물을 버리는 것보다 각각의 새로운 로컬 문제를 수정하는 것이 더 저렴해 보이기 때문입니다.

때로는 해결책을 복구할 수도 있습니다. 하지만 다른 경우에는 수많은 반복을 거친 후에도 개발자가 여전히 이를 수동으로 구현하게 됩니다.

이것이 바로 복잡한 작업에서 개발자들이 종종 안전한 선택, 즉 해결책을 직접 구현하는 방식을 택하는 이유입니다. 이는 에이전트가 작업을 완료할 능력이 없어서가 아니라, 미리 정의된 해결책이 없다면 그 결과물과 협업하는 비용이 얼마나 들지 알 수 없기 때문입니다.

물론, 원시인처럼 코드를 수동으로 작성하는 것은 느리고 고통스럽습니다. 하지만 개발자는 선택한 해결책을 이해하고, 변경 사항을 제어하며, 그것이 코드베이스에 어떻게 부합하는지 알고 있습니다.

결과적으로, 선택은 종종 다음 두 가지 옵션으로 귀결됩니다:

• 구현과 해결책 선택 모두를 에이전트에게 위임하고, 결과가 보장되지 않는 비용이 많이 드는 반복의 연쇄 위험을 감수하는 것;
• 해결책을 독립적으로 정의하고 이를 수동으로 구현하여, 제어권과 예측 가능성을 유지하는 것.

독립적인 구현(independent implementation)이라고 해서 오직 완전히 수동적인 코드 변경만을 의미하는 것은 아닙니다. 이는 저수준의 세부 사항(low-level details)을 구현하기 위해 LLM을 사용하는 것도 포함할 수 있습니다.

이 두 가지 옵션 사이에는 또 다른 접근 방식이 들어설 자리가 있습니다: 개발자가 해결책과 작업의 경계(boundaries)를 정의하되, 고립된 함수, 테스트, 또는 문서화보다 훨씬 더 큰 비중의 실제 구현을 AI에게 위임하는 방식입니다.

나는 이 접근 방식을 AI Bounded-Context Development, 즉 AB-CD라고 부릅니다.

AI Bounded-Context Development

AB-CD는 복잡한 코드베이스 내의 복잡한 엔지니어링 작업을 위해 설계되었습니다. 핵심적인 도입 계기는, 에이전트(Agent)에게 모든 해야 할 일(do)과 하지 말아야 할 일(don't)을 설명하는 것보다 해당 작업을 수동으로 구현하는 것이 더 빠를 것 같다는 의구심이 들 때입니다.

보편적인 복잡성 임계값은 존재하지 않습니다. 추가적인 징후로는, 확신을 가지고 검토하기에는 너무 광범위한 디프(diff), 예상치 못한 변경 지점, 또는 AI가 선택해야만 하는 여러 개의 유사한 아키텍처 패턴 등이 있습니다.

AB-CD가 반드시 작은 규모의 로컬 변경, 일회성 PoC (Proof of Concept), 잘 격리된 그린필드 (Greenfield) 모듈, 또는 개발자가 의도적으로 여러 가지 대안을 원하는 작업에서 이득을 주는 것은 아닙니다. 잘못된 방향을 선택했을 때의 비용이 경계를 사전에 정의하는 비용보다 높을 때 유용합니다.

공식 정의

AI Bounded-Context Development는 개발자가 각 구현 단계마다 LLM (Large Language Model)이 사용할 수 있는 정보 경계(Information Boundary)를 명시적으로 정의하고 발전시켜 나가는 AI 개발 워크플로우(Workflow)입니다.

그 핵심 원칙은 다음과 같이 기술할 수 있습니다:

현재 구현 단계에 정확히 필요한 정보만을 LLM에 제공하라. 그보다 적어서도 안 되며, 그보다 많아서도 안 된다.

AB-CD에서 개발자는 기대되는 솔루션을 정의하고 이를 정보 경계를 통해 표현합니다. AI는 해당 경계 내에서 미리 정의된 하나의 단계를 구현하며, 이를 통해 아키텍처의 방향성을 위임하지 않으면서도 AI 실행력 (AI Execution)을 높입니다.

AI-as-a-Pie 분류에서 AI의 역할은 두 개의 독립적인 축인 AI 의사결정 자율성 (AI Decision Autonomy)과 AI 실행력 (AI Execution)을 따라 평가됩니다. 사분면은 각 차원에서 누가 통제권(Controlling Interest)을 갖느냐, 즉 누가 주로 목표 달성 방법을 선택하고 누가 목표 달성에 필요한 대부분의 행동을 수행하느냐에 따라 결정됩니다.

AB-CD에서 개발자는 작업을 조사하고, 솔루션을 선택하며, 이를 단계별로 나누고, 각 단계의 정보 경계를 정의합니다. AI는 해당 솔루션의 미리 정의된 부분을 구현합니다.

이러한 특성으로 인해 AB-CD는 AI-as-a-Pie 모델의 첫 번째 사분면에 위치합니다. 즉, AI 실행력 (AI Execution)은 높지만 AI 의사결정 자율성 (AI Decision Autonomy)은 낮습니다. AI-as-a-Helper와 달리 AI가 구현의 상당 부분을 수행하며, 에이전트 방식 (agentic approaches)과 달리 AI가 스스로 경로를 선택하지는 않습니다.

AAAP

컨텍스트 계약 (Context Contract)

AB-CD의 핵심 산출물은 **컨텍스트 계약 (Context Contract)**입니다. 이는 현재 단계의 역할, 모델이 사용할 수 있는 정보, 그리고 구현 제약 사항을 명시적으로 기술한 것입니다.

컨텍스트 계약에는 다음과 같은 내용이 포함될 수 있습니다:

• 단계 역할 (Step Role) — 기대되는 솔루션 중 현재 단계가 구현하는 부분과 해당 단계가 남겨야 하는 결과물;
• 수정 가능 범위 (Editable Scope) — LLM이 수정을 허용받은 목록;
• 읽기 전용 범위 (Read-only Scope) — 작업을 이해하는 데 필요하지만 수정해서는 안 되는 목록 (자동 생성된 파일 포함);
• 제외 범위 (Excluded Scope) — 현재 단계의 솔루션에 영향을 미치지 않도록 의도적으로 컨텍스트에서 제외한 관련 목록;
• 프로젝트 제약 사항 (Project Constraints) — 아키텍처 제약, 코드 스타일, 로컬 프로젝트 규칙 및 특별 지침.

컨텍스트 계약은 단순히 파일 목록을 나열한 것이 아닙니다. 이는 이전에 선택된 솔루션 내에서 해당 단계의 역할을 포착하며, LLM이 구현 선택의 근거로 삼을 수 있는 정보의 범위를 제한합니다.

예를 들어, “엔드 투 엔드(end to end)로 새로운 필터 추가”와 같은 작업은 폼(form) 자체보다 더 많은 부분에 영향을 미칩니다. 필터 값은 공유 상태(shared state)를 통해 전달되고, 칩(chips)에 나타나며, API 파라미터로 변환되어 백엔드 필터링 파이프라인에 적용됩니다. 또한, 프론트엔드 계약(frontend contract)은 OpenAPI로부터 생성될 수 있으며 수동으로 편집해서는 안 됩니다.

구현이 시작되기 전, 개발자는 이 흐름을 조사하고 예상되는 솔루션을 정의합니다. 즉, 필터에 필요한 상태 타입(state type)은 무엇인지, null과 빈 값(empty values)을 어떻게 해석해야 하는지, API 매핑은 어디에서 발생하는지, 백엔드가 기존의 술어(predicate)를 재사용해야 하는지 아니면 별도의 쿼리 서비스(query service)를 사용해야 하는지, 그리고 데이터베이스 변경이 필요한지 여부를 결정합니다.

그 후 작업은 구현 단계로 나뉩니다. 프론트엔드 상태(frontend-state) 단계를 위한 **편집 가능 범위 (Editable Scope)**에는 필터 컴포넌트, UI 모델, 그리고 파사드(facade)가 포함될 수 있습니다. 브로드캐스터 허브(broadcaster hub)는 기존의 경계를 설명하지만 변경할 필요는 없으므로 **읽기 전용 범위 (Read-only Scope)**로 제공될 수 있습니다. 생성된 API 모델 또한 현재의 계약(contract)을 명확히 하기 위한 목적으로만 포함될 수 있으며, 이를 편집하는 것은 명시적으로 금지됩니다.

개발자가 해당 아키텍처를 재현하지 않기로 이미 결정했다면, 유사한 레거시 필터는 의도적으로 **제외 범위 (Excluded Scope)**에 배치될 수 있습니다. LLM은 전체 체인을 한꺼번에 받거나 독립적으로 경로를 선택할 권한을 갖지 않습니다. LLM은 오직 미리 정의된 솔루션 내에서 하나의 특정 단계를 구현하는 데 필요한 정보만을 전달받습니다.

검토 후에 경계는 변경됩니다. 백엔드 단계를 위한 편집 가능 범위 (Editable Scope)에는 요청 계약(request contract), 필터링 파이프라인(filtering pipeline), 그리고 테스트가 포함될 수 있는 반면, 프론트엔드 파일은 더 이상 필요하지 않습니다. 만약 LLM이 예상치 못한 의존성이나 예상 범위를 벗어난 변경을 제안하더라도, 개발자가 아키텍처를 처음부터 다시 조사할 필요는 없습니다. 대신, 컨텍스트 계약(Context Contract)이 잘못되었는지, 아니면 모델이 현재 단계에 할당된 역할을 벗어났는지를 확인하면 됩니다.

이러한 방식으로, 하나의 엔드 투 엔드(end-to-end) 작업은 단일한 광범위한 프롬프트가 아니라, 이미 선택된 엔지니어링 솔루션의 각기 다른 부분을 표현하는 통제된 경계들의 연속을 통해 구현됩니다.

컨텍스트 계약 (Context Contract)이 반드시 별도의 문서로 존재해야 하는 것은 아닙니다. 중요한 것은 경계가 개발자에 의해 명시적으로 정의되어야 하며, 작업에 대한 개발자의 이해와 함께 발전할 수 있어야 한다는 점입니다.

제외 범위 (Excluded Scope) 또한 반드시 전부 나열될 필요는 없습니다. 개발자는 LLM이 제공된 파일에만 의존하도록 요구할 수 있으며, 추측을 하거나 불완전한 솔루션을 내놓는 대신 누락된 컨텍스트가 있다면 이를 설명하도록 할 수 있습니다.

계약의 정확한 형태는 도구와 개발자의 선호도에 따라 달라집니다. 통제된 경계는 필수적이지만, 그 구문(syntax)은 필수 사항이 아닙니다.

AB-CD의 핵심 아이디어

AB-CD는 새로운 기술적 메커니즘을 도입하는 것이 아닙니다. 이는 컨텍스트가 미리 정의된 엔지니어링 솔루션으로부터 도출되고, AI에 대한 제약 조건으로 사용되는 워크플로우로 컨텍스트 관리 관행을 공식화하는 것입니다.

핵심은 어떤 리스팅이 **편집 가능 범위 (Editable Scope)**와 **읽기 전용 범위 (Read-only Scope)**에 포함되는가뿐만 아니라, 시스템의 어떤 관련 부분이 의도적으로 제외되는가에 있습니다.

**제외 범위 (Excluded Scope)**는 **편집 가능 범위 (Editable Scope)**만큼이나 중요한 엔지니어링 결정입니다.

AB-CD는 단순히 컨텍스트 크기를 줄이는 것에 관한 것이 아닙니다. 이는 구현에 영향을 미칠 수 있는 정보를 제어함으로써 허용 가능한 솔루션의 범위를 제어합니다.

AB-CD는 제공되는 파일의 수를 제한하는 것이 아니라, AI가 현재 단계에서 정당화할 수 있는 솔루션의 집합을 제한합니다.

추가적인 모듈, 유사한 구현, 그리고 대안적인 패턴들은 모델에게 더 그럴듯한 경로들을 제공하지만, 그 경로들이 모두 개발자의 의도와 일치하는 것은 아닙니다. 저의 실무적인 가설은, 과도하게 넓은 컨텍스트가 종종 예상치 못한 변경 지점과 점진적인 범위 확장을 초래하는 이유가 바로 이것이라는 점입니다. 이는 하나의 관찰 결과이며, 보편적인 법칙은 아닙니다.

최종 솔루션을 알지 못하는 에이전트는 의존성 누락을 피하기 위해 광범위한 컨텍스트를 수집하거나, 컨텍스트를 최소화하여 중요한 무언가를 제외할 위험을 감수해야 합니다. 두 전략 모두 작동할 수 있지만, 컨텍스트를 선택하기 위해서는 예상되는 솔루션에 대한 이해가 필요합니다.

개발자가 그러한 이해를 갖추고 나면, 경계(boundary)는 하나의 아키텍처 필터(architectural filter)가 됩니다. 즉, 모델은 현재 단계에 영향을 미쳐야 하는 패턴만을 전달받게 됩니다. 리뷰(Review) 방식 또한 변화합니다. 독립적으로 선택된 AI 솔루션을 평가하는 것에서, 구현 내용이 해당 단계에 미리 정의된 역할(role)에 부합하는지 확인하는 방식으로 바뀝니다.

이때 예상치 못한 의존성(dependencies)이 발생하면, 이는 계약(contract)이 불완전하거나 모델이 경계를 벗어났음을 알리는 신호가 됩니다. 이를 통해 개발자는 의도한 솔루션에 대한 제어권을 유지하면서도, 상당한 수준의 저수준 구현(low-level implementation)을 위해 AI를 활용할 수 있습니다.

주요 흐름 (Main Flow)

기본적인 AB-CD 사이클은 다음과 같습니다:

탐색 (Discover)

개발자가 작업을 조사하고 예상되는 솔루션을 정의합니다.

↓