AI 지원 개발에 관한 대부분의 대화는 코딩에 집중되어 있습니다. 어떤 모델이 코드를 가장 잘 작성할까요? 어떤 IDE가 최고의 자동 완성 기능을 제공할까요? 어떤 에이전트가 프롬프트 하나로 전체 애플리케이션을 생성할 수 있을까요?

AI 코딩 도구들을 몇 달 동안 실험해 본 후, 저는 다른 결론에 도달했습니다: 병목 현상은 코딩이 아니었습니다.

병목 현상은 코딩을 둘러싼 모든 것이었습니다. 계획(Planning), 요구사항 분석(Requirements analysis), 아키텍처 결정(Architecture decisions), 테스트(Testing), 코드 리뷰(Code reviews), 문서화(Documentation), 배포 준비(Deployment preparation), 그리고 검증(Validation)이 여전히 제 시간의 대부분을 소비하고 있었습니다. AI는 코드를 빠르게 생성할 수 있었지만, 그 코드를 프로덕션 준비가 된 소프트웨어(Production-ready software)로 만드는 과정은 여전히 파편화되어 있고 매우 수동적인 프로세스로 남아 있었습니다.

그때 저는 AI를 단순한 코딩 보조 도구로 생각하는 것을 멈추고, 개발 시스템의 일부로 생각하기 시작했습니다. 이는 제가 **AI 하네스 (AI harness)**를 구축하는 계기가 되었습니다. 즉, 코드 생성을 고립된 활동으로 취급하는 대신, 전체 개발 라이프사이클(Development lifecycle) 전반에 걸쳐 AI를 오케스트레이션(Orchestrate)하는 구조화된 워크플로(Workflow)를 만든 것입니다.

AI 코딩 어시스턴트의 문제점

대부분의 AI 개발 워크플로는 다음과 같은 형태를 띱니다:

1. 프롬프트(Prompt) 작성
2. 코드 생성
3. 결과물 검토
4. 오류 수정
5. 추가 코드 생성
6. 반복

이러한 접근 방식은 작은 작업에는 놀라울 정도로 잘 작동합니다. 하지만 프로젝트가 커짐에 따라 몇 가지 문제점이 나타납니다:

• 요구사항이 불분명해짐
• 컨텍스트(Context)가 유실됨
• 시간이 지남에 따라 아키텍처가 어긋남
• 테스트가 일관성을 잃음
• 문서화가 뒤처짐
• 세션마다 코드 품질이 달라짐

그 결과는 종종 코딩은 빨라지지만, 반드시 소프트웨어 전달(Software delivery)이 빨라지는 것은 아닙니다. 저는 소프트웨어를 만드는 대신 AI를 관리하는 데 상당한 시간을 소비하고 있는 저 자신을 발견했습니다.

통찰: 프롬프트가 아닌 시스템을 구축하라

돌파구는 제가 프롬프트를 최적화하는 것을 멈추고 프로세스를 최적화하기 시작했을 때 찾아왔습니다. _"어떻게 하면 AI가 더 나은 코드를 쓰게 할 수 있을까?"_라고 묻는 대신, 저는 다음과 같이 물었습니다:

"어떤 AI 모델을 사용하든 상관없이, 일관되게 고품질의 소프트웨어를 생산하는 워크플로 (Workflow)를 어떻게 만들 수 있을까?"

그 답은 여러 개발 활동을 조정하고 라이프사이클 (Lifecycle) 전반에 걸쳐 구조를 강제하는 하네스 (Harness)였습니다.

AI 하네스가 하는 일

개괄적인 수준에서 워크플로는 다음과 같습니다:

기능 요청 (Feature Request) → 요구사항 분석 (Requirements Analysis) → 구현 계획 (Implementation Planning) → 코드 생성 (Code Generation) → 테스트 생성 (Test Generation) → 검증 (Validation) → 문서화 (Documentation) → 검토 및 승인 (Review & Approval)

각 단계는 다음 단계의 입력값이 되는 산출물 (Artifacts)을 생성합니다. 단일한 거대 프롬프트 (Massive prompt)에 의존하는 대신, 시스템은 개발을 더 작고 전문화된 단계로 나눕니다. 이는 컨텍스트 과부하 (Context overload)를 줄이고 일관성을 향상시킵니다.

실제 사례

다음과 같은 기능 요청을 받았다고 가정해 봅시다: "애플리케이션에 에너지 가격 예측 기능을 추가해 주세요."

하네스는 즉시 코드를 생성하지 않습니다. 대신 다음과 같은 과정을 거칩니다:

1. 요구사항 분석 (Analyze Requirements): 시스템이 비즈니스 목표, 기능적 요구사항, 기술적 의존성 및 잠재적인 엣지 케이스 (Edge cases)를 식별합니다.
2. 구현 계획 생성 (Generate an Implementation Plan): 코딩이 시작되기 전에 하네스는 아키텍처 업데이트, 필요한 서비스, 데이터베이스 변경 사항, API 통합 및 테스트 전략을 생성합니다.
3. 코드 생성 (Generate Code): 계획이 완료된 후에만 구현이 시작됩니다. AI가 모호한 프롬프트가 아닌 구조화된 명세 (Specification)를 바탕으로 작업하기 때문에, 생성된 코드는 프로젝트 요구사항과 훨씬 더 잘 일치합니다.
4. 테스트 생성 (Generate Tests): 하네스는 유닛 테스트 (Unit tests), 통합 테스트 (Integration tests) 및 검증 시나리오를 자동으로 생성합니다.
5. 문서 생성 (Produce Documentation): 기술 문서와 구현 노트가 사후 작업으로 취급되는 대신 코드와 함께 생성됩니다.

기대보다 더 효과적이었던 점

처음에 최적화하려 했던 것 외에도 몇 가지 이점이 나타났습니다:

• 일관성 (Consistency): 가장 큰 개선점은 속도가 아니라 예측 가능성이었습니다. 시스템은 작업의 복잡도와 상관없이 동일한 표준을 따르는 결과물을 생성합니다.
• 컨텍스트 스위칭 (Context Switching) 감소: 다음에 무엇을 할지 끊임없이 결정하는 대신, 워크플로 (Workflow) 자체가 실행을 주도합니다. 이를 통해 저는 더 높은 수준의 의사결정에 집중할 수 있습니다.
• 더 나은 지식 캡처 (Knowledge Capture): 모든 단계에서 추론, 결정 사항, 구현 세부 정보를 기록하는 아티팩트 (Artifacts)가 생성됩니다. 프로젝트는 시간이 지날수록 이해하기 어려워지는 것이 아니라 오히려 더 쉬워집니다.

여전히 발생하는 문제들

이 시스템은 완벽과는 거리가 멉니다. AI는 여전히 다음과 같은 실수를 합니다:

• 요구사항 오해
• 아키텍처 (Architecture)에 대한 잘못된 가정
• 지나치게 복잡한 솔루션 생성
• 엣지 케이스 (Edge cases) 누락
• 올바른 동작을 검증하지 못한 채 통과되는 테스트 생성

이것이 바로 인간의 검토 (Human review)가 여전히 필수적인 이유입니다. 목표는 자율적인 개발이 아닙니다. 목표는 엔지니어링 규율을 유지하면서 개발자의 효율성을 증폭시키는 것입니다.

얻은 교훈

만약 제가 오늘 다시 시작한다면, 다음과 같이 할 것입니다:

• 명세 (Specifications)에 더 많은 비중을 두겠습니다.
• 평가 (Evaluation)와 검증 (Validation) 단계를 더 앞당기겠습니다.
• 불필요한 에이전트 (Agent) 복잡성을 줄이겠습니다.
• 워크플로 전반의 관찰 가능성 (Observability)을 개선하겠습니다.
• 모델 선택 이전에 프로세스 설계에 집중하겠습니다.

아이러니하게도 하네스 (Harness)가 성숙해짐에 따라 모델 선택의 중요성은 줄어들었습니다. 잘 구조화된 프로세스는 단순히 더 유능한 모델로 교체하는 것보다 종종 더 나은 결과를 만들어냈습니다.

더 큰 기회

저는 AI 지원 소프트웨어 개발의 미래가 개발자를 대체하는 것에 있지 않다고 믿습니다. 그것은 소프트웨어 개발을 둘러싼 반복적인 조정 작업을 자동화하는 시스템을 구축하는 것에 관한 것입니다.

코딩은 라이프사이클 (Lifecycle)의 한 단계일 뿐입니다. 계획, 테스트, 검증, 문서화, 그리고 검토는 똑같이 중요합니다. AI를 단순한 코드 생성기가 아닌 개발 플랫폼으로 취급하는 조직이 장기적으로 가장 큰 이득을 얻게 될 것입니다.

가장 가치 있는 엔지니어링 기술은 더 이상 코드를 더 빠르게 작성하는 것이 아닐지도 모릅니다. 그것은 인간과 AI가 효과적으로 협업할 수 있도록 워크플로 (Workflows)를 설계하는 것일 수 있습니다. 그것이 바로 제가 구축한 AI 하네스 (AI harness)의 진정한 목적입니다.