더 일상적이고 개발자의 성장이 덜 필요한 작업은 개발자의 노력이 덜 들어야 함을 의미합니다.

서론 (Intro)

이전 기사에서 저는 AI Bounded-Context Development, 즉 AB-CD를 소개했습니다. 이는 개발자가 예상되는 솔루션을 결정하고, 각 구현 단계의 정보 경계(information boundary)를 제어하며, 상당 부분의 저수준 구현(low-level implementation)을 LLM에 위임하는 워크플로입니다.

하지만 AB-CD가 모든 작업에 적합한 워크플로는 아닙니다.

때로는 솔루션 자체를 여전히 찾아내야 할 때가 있습니다. 다른 경우에는 솔루션과 구현 절차 모두가 훨씬 더 광범위하게 위임할 수 있을 만큼 충분히 안정적일 수도 있습니다.

이번에는 하나의 실제 기능 요청(feature request)을 사례로 들어, 그 엔지니어링 형태에 따라 AI-as-a-Helper, AB-CD, 그리고 Agentic AI 사이의 선택이 어떻게 달라지는지 보여드리고자 합니다.

작업은 간단해 보입니다:

엔드 투 엔드(end to end)로 새로운 필터를 추가하세요.

하지만 이 문장만으로는 AI 워크플로를 선택하기에 충분하지 않습니다.

이 필터가 기존의 필터와 거의 동일한가요?

새로운 상호작용 패턴(interaction pattern), 데이터 타입, 또는 데이터베이스 요구사항을 도입하나요?

아니면 프로젝트에 필터링 인프라가 전혀 없나요?

이 모든 것들이 "필터 추가"라고 설명될 수 있지만, 근본적으로는 서로 다른 엔지니어링 작업입니다.

당신이 좋아하는 AI 도구가 아니라, 작업(task)에서부터 시작하세요.

아래의 코드 샘플은 축약되고 익명화되었습니다. 목표는 이 아키텍처가 보편적으로 옳다는 것을 제시하는 것이 아니라, 실제 코드베이스에 대한 지식이 워크플로 결정에 어떤 영향을 미치는지 보여주는 것입니다.

프로젝트와 작업 (The Project and the Task)

이 프로젝트는 교육용 스타트업입니다. 관련 코드는 사용자가 생성한 요약(summary)을 주요 엔티티(entity)로 하는 Filter-Sort-Paginate 모듈에 속해 있습니다.

기술 스택: ASP.NET Web API, C#, OpenAPI, Angular, TypeScript, RxJS, 그리고 ng-open-api입니다.

왼쪽 패널에는 필터링 컨트롤 (filtering controls)이 포함되어 있습니다.

오른쪽 영역에는 선택된 필터 칩 (selected-filter chips)과 필터링된 요약 (filtered summaries)이 포함되어 있습니다.

필터 변경 사항은 공유 이벤트 허브 (shared event hubs)를 통해 방송되며, UI의 여러 독립적인 부분에서 이를 소비합니다. 따라서 필터를 추가하는 것은 단순히 로컬 폼 (local form)을 변경하는 작업이 아닙니다.

높은 수준에서 데이터 흐름 (data flow)은 다음과 같습니다:

필터 컨트롤 (Filter control)
→ 공유 필터 상태 (shared filter state)
→ 칩 동기화 (chips synchronization)
...

과제는 이 전체 흐름을 통해 새로운 필터를 추가하는 것입니다.

어떤 필터인지 아직 명시하지 않은 이유는, 그 누락된 세부 사항이 워크플로 (workflow)를 결정하기 때문입니다.

워크플로를 선택하기 전 작업 스크리닝 (Screening the Task)

워크플로를 선택하기 전에, 개발자는 다음 네 가지 질문에 답할 수 있을 만큼 충분한 이해가 필요합니다:

• 예상되는 솔루션이 이미 알려져 있는가?
• 구현 경로 (implementation path)가 안정적인가?
• 정보 경계 (information boundary)를 확신을 가지고 정의할 수 있는가?
• 재사용 가능한 절차 (reusable procedure)가 이미 존재하는가?

이 프로젝트의 경우, 저는 코드베이스 (codebase)를 이미 잘 알고 있었기 때문에 초기 스크리닝 (screening)에 약 5분에서 10분 정도 소요되었습니다.

Angular 필터 컴포넌트 (component)는 외부 상태를 복구하는 동시에 사용자의 변경 사항을 발행 (publish)합니다:

export class SumsFilterComponent implements OnInit {
  private _reactOnInputTechDataChanged() {
    this._sumsFilterBhub.selectedDataInputChanged
...

새로운 필터는 양방향 모두에 참여해야 합니다. 템플릿 (template)에 컨트롤을 추가하는 것만으로는 상태 흐름 (state flow)을 완성할 수 없습니다.

동일한 상태는 칩 모듈 (chips module)에서도 소비되며, 생성된 API 요청 파라미터 (API request parameters)로 변환된 후, 최종적으로 백엔드 필터링 파이프라인 (backend filtering pipeline)에 의해 적용됩니다:

if (fpsParams.FilterStarred.HasValue)
{
    query = query.Where(
...

생성된 프론트엔드 API 계약 (API contracts)은 수동으로 편집해서는 안 됩니다.

새로운 필터가 기존 백엔드 메서드 (method)에 직접 포함될지, 전용 쿼리 서비스 (query service)가 필요할지, 아니면 데이터베이스 (database) 변경이 필요할지는 그 의미론 (semantics)에 따라 달라집니다.

이 시점에서 애플리케이션을 통한 구현 경로가 가시화됩니다. 남은 질문은 우리가 어떤 종류의 필터(filter)를 추가하고 있는가 하는 점입니다.

하나의 기능 요청 뒤에 숨겨진 세 가지 서로 다른 작업

사례 1: 유추를 통한 필터 추가

요구사항이 다음과 같다고 가정해 봅시다:

기존의 starred 필터를 따라 불리언(boolean) 필터를 추가하십시오.

예상되는 동작, 영향을 받는 레이어(layers), 상태 형태(state shape), 칩(chips)의 생명주기(lifecycle), API 매핑, 백엔드 술어(backend predicate), 그리고 예상되는 테스트 구조는 이미 알려져 있습니다.

이것은 기본적으로 패턴 복제(pattern-replication) 작업입니다.

첫 번째 시도에서는 AB-CD를 사용하여 암시적인 절차를 명시적으로 만들고, 실제 변경 사항과 대조하여 검증할 것입니다.

절차가 안정화되고 문서화되면, 이후의 반복 작업들은 Agentic AI의 강력한 후보가 됩니다.

개발자의 머릿속에 있는 알려진 절차
→ AB-CD를 통해 이를 표현
→ 실제 작업에서 검증
...

작업이 반복 가능하다는 사실이 자동으로 그것을 에이전틱(agentic)하게 만드는 것은 아닙니다. 절차 또한 명시적이고, 안정적이며, 검증 가능해야 합니다.

AI-as-a-Helper는 제어권은 유지하겠지만, 예측 가능한 엔드 투 엔드(end-to-end) 변경 사항을 고립된 파편들로 축소시킬 것입니다.

사례 2: 새로운 유형의 필터 추가

이제 필터가 starred와 유사하지 않다고 가정해 봅시다.

다음과 같은 사항들이 필요할 수 있습니다:

• 새로운 컨트롤(control) 또는 UX;
• 생소한 상태 의미론(state semantics);
• 범위(range), 계층 구조(hierarchy), 또는 다중 값 형태(multi-value shape);
• 다른 API 계약(API contract);
• 데이터베이스 필드(database field) 또는 관계(relationship);
• 전용 백엔드 쿼리(backend query).

애플리케이션에는 이미 필터링 아키텍처(filtering architecture)가 존재하며, 영향을 받는 레이어(layers)도 알려져 있습니다.

불확실한 상태로 남아 있는 것은 해당 아키텍처 내부에서의 올바른 동작입니다.

이 사례의 경우, 저는 AB-CD를 주요 구현 워크플로우(workflow)로 사용할 것입니다.

AI-as-a-Helper는 통합 경로의 상당 부분이 이미 이해되어 있기 때문에 너무 적은 권한을 위임할 것입니다.

Agentic AI는 중요한 엔지니어링 결정 사항들이 여전히 안정적인 절차로 인코딩될 수 없기 때문에 너무 많은 권한을 위임할 것입니다.

구체적인 루프(loop)는 다음과 같을 수 있습니다:

1. 개발자가 해당 필터가 Nullable(null 허용) 날짜 범위라고 결정합니다.
2. 개발자가 필터의 형태(form), 칩(chips), API 및 백엔드 의미론(semantics)을 정의합니다.
3. 프론트엔드 상태(frontend-state) 단계를 위한 컨텍스트 계약(Context Contract)이 생성됩니다.
   ...

단일 기능이 처음부터 끝까지 하나의 워크플로우(workflow)만 사용할 필요는 없습니다.

AI-as-a-Helper:
익숙하지 않은 UX 또는 아키텍처 대안 조사

...

워크플로우의 소유권(ownership)은 동일한 작업의 단계 사이에서 변경될 수 있습니다.

사례 3: 진공 상태에서의 필터링 구축 (Build Filtering in a Vacuum)

이제 프로젝트에 필터링 아키텍처가 전혀 없다고 가정해 봅시다.

이 작업은 더 이상 "필터 하나를 더 추가하는 것"이 아닙니다.

실제 작업은 다음과 같습니다:

유지보수가 불가능해지지 않으면서도 다양한 필터 형태를 지원할 수 있는 필터링 파이프라인(filtering pipeline)을 설계하고 구현하십시오.

여전히 불확실한 요소들은 다음과 같습니다:

• 필터링 상태(filtering state)가 어디에 위치해야 하는지;
• 컨트롤(controls)이 UI의 나머지 부분과 어떻게 통신하는지;
• 필터가 어떻게 직렬화(serialized)되는지;
• 술어(predicates)가 어떻게 합성(compose)되는지;
• 페이지네이션(pagination) 및 정렬(sorting)이 필터링과 어떻게 상호작용하는지;
• 향후 추가될 필터들이 설계를 어떻게 확장하는지.

이 단계에서 가장 중요한 작업은 구현(implementation)이 아닙니다.

올바른 솔루션을 결정하는 것입니다.

여기서 AI-as-a-Helper가 주요 추론 워크플로우(reasoning workflow)가 되어야 합니다. 개발자가 아키텍처에 대한 소유권을 유지하는 동안, AI는 대안을 조사하거나, 의존성(dependencies)을 추적하거나, 탐색적인 코드(exploratory code)를 생성할 수 있습니다.

워크플로우는 AI가 얼마나 많은 코드를 생성하느냐가 아니라, 누가 결정 루프(decision loop)를 소유하느냐에 의해 정의됩니다.

AB-CD는 아직 안정적인 경계(boundaries)를 도출할 수 있을 만큼 충분히 이해된 솔루션이 없기 때문에 시기상조입니다.

Agentic AI는 광범위한 자율적 구현이 하나의 그럴듯한 아키텍처를 의도치 않은 확정(accidental commitment)으로 만들어버릴 수 있기 때문에 위험할 수 있습니다.

에이전트(Agents)는 여전히 코드베이스 탐색, 의존성 추적, 일회성 개념 증명(disposable proofs of concept)을 도울 수 있습니다. 에이전트의 출력물은 결정을 위한 근거(evidence)로 남을 뿐, 결정을 대체하는 것이 아닙니다.

아키텍처가 이해된 후에는 워크플로우가 다음과 같이 변경될 수 있습니다:

AI-as-a-Helper
→ 아키텍처를 결정하고 높은 불확실성을 해결

...

모든 작업이 이 세 단계를 모두 거칠 필요는 없습니다.

개발자가 방정식을 변화시킨다

변수는 작업만이 아닙니다.

동일한 요청이라도 누가 수행하느냐에 따라 서로 다른 워크플로우가 필요할 수 있습니다.

저는 이 코드베이스의 설계자이기 때문에 이를 잘 알고 있습니다. 저는 어떤 경로가 의도된 것인지, 어떤 추상화 (abstraction)를 건드리지 말아야 하는지, 그리고 AI가 생성한 결과가 그저 그럴듯한 것인지 아니면 실제로 정확한 것인지를 빠르게 식별할 수 있습니다.

덜 익숙한 프로젝트라면, 구현에 대한 소유권 (ownership)을 더 적게 위임할 것입니다.

AB-CD는 직함에 의존하지 않습니다. 그것은 개발자가 다음을 수행할 수 있는지 여부에 달려 있습니다:

• 중요한 엔지니어링 결정을 인식하는 것
• 기대되는 솔루션을 정의하는 것
• 관련 정보 경계 (information boundary)를 식별하는 것
• 구현을 분해 (decompose)하는 것
• 결과를 비판적으로 검토하는 것

학습 가치 또한 상대적입니다.

필터링 작업은 프로젝트 설계자에게는 일상적인 일일 수 있지만, 해당 문제를 처음 접하는 개발자에게는 가치 있는 설계 연습이 될 수 있습니다.

구현 경로가 이해되어 있고, 결과를 신뢰할 수 있게 검증할 수 있으며, 개발자의 학습 가치가 낮을 때 더 많이 위임하십시오.

목표는 AI의 자율성을 극대화하는 것이 아닙니다.

목표는 개발자의 노력이 가장 큰 가치를 창출하는 곳에 투입되도록 하는 것입니다.

워크플로우 선택하기

이 매트릭스는 점수 산정 시스템이 아닙니다.

기준들은 서로 다른 방향을 가리킬 수 있습니다.

명확한 검증이 없는 반복적인 작업은 여전히 에이전트 (agent)에게 안전하지 않을 수 있습니다.

비용이 많이 드는 변경 사항이라도 샌드박스 (sandbox) 내에서 실행되고 강력한 검증이 뒷받침된다면 여전히 Agentic AI를 사용할 수 있습니다.

잘 이해된 일회성 작업은 이를 재사용 가능한 에이전트 절차로 공식화할 이유가 없더라도 여전히 AB-CD를 사용할 수 있습니다.

핵심은 표를 암기하는 것이 아니라, 왜 구현의 소유권(implementation ownership)이 이동하는지를 이해하는 것입니다.

요약

“필터를 추가하라”는 것은 단 하나의 엔지니어링 작업이 아닙니다.

해결책 자체가 불분명할 때는, 개발자가 AI-as-a-Helper를 통해 추론 루프(reasoning loop)에 대한 소유권을 유지해야 합니다.

기대되는 해결책은 이해하고 있지만 의도적인 조정(adaptation)이 필요한 경우에는, AB-CD가 자연스러운 구현 워크플로우(workflow)가 됩니다.

절차가 안정적이고, 명시적이며, 반복 가능하고, 강력하게 검증된다면, Agentic AI를 사용하는 것이 점점 더 합리적이 됩니다.

불확실성이 감소함에 따라 하나의 기능은 이러한 워크플로우 사이를 이동할 수 있습니다.

작업이 더 일상적이고 개발자의 성장이 덜 필요하다는 것은, 개발자의 노력이 덜 들어야 함을 의미합니다.

AB-CD는 개발자가 기대되는 해결책을 이해하고, 의사결정 소유권을 유지하고 싶어 하며, 통제된 구현 단계와 정보 경계(information boundaries)를 통해 해당 해결책을 표현할 수 있을 때 가장 유용합니다.