Harness Engineering 관점에서 생각하는 AIDD 성숙도 모델

Harness Engineering에 대해 그 정의나 구체적인 실천 사례를 소개하는 기사가 늘어나고 있습니다.

반면, 실제 팀 개발에 있어서 어느 날 갑자기 "완벽한 AI 주도 개발"이 실현되는 것은 아닙니다.

실제로는 AI 주도 개발의 성숙도는 시계열적으로 조금씩 진화해 나갑니다.

따라서 본 기사에서는 당사의 개발 조직에서의 노력을 바탕으로, AI 주도 개발의 진화 단계를 "Level"로 정리해 보고자 합니다.

참고로, 본 기사에서의 Harness Engineering 사고방식은 Birgitta Bockeler 씨의 "Harness Engineering for Coding Agents"에 게재된 정의를 참고하고 있습니다.

이 기사에서는 세세한 정의 자체를 깊게 파고들지는 않겠지만, 대략적으로 말하자면 AI 코딩 에이전트가 안전하고 효과적으로 개발할 수 있도록 가이드(Guide), 피드백(Feedback), 실행 환경 등의 "울타리(Enclosure)"를 정비하는 사고방식입니다.

AIDD가 이루어지지 않는 단계

Level-null: AI를 사용할 수 없음 / ChatGPT의 코드를 복사해서 붙여넣기만 함

AIDD, 즉 AI 주도 개발을 수행하기 위한 밑바탕조차 없는 상태입니다.

예를 들어, 다음과 같은 상태입니다.

• ChatGPT에 표시된 코드를 그대로 복사하여 붙여넣고 있다
• AI에게 코드를 쓰게 하고 있지만, 개발 환경이나 테스트와는 연결되어 있지 않다
• 팀으로서 AI를 활용하는 규칙이나 지견이 없다
• AI의 출력을 리뷰하는 관점이 없다
• AI가 생성한 코드의 품질을 기계적으로 검증하는 메커니즘이 없다

물론 개인의 학습 단계로서는 문제가 없습니다.

하지만 팀 개발 현장에서 이 상태가 길게 지속되고 있다면, AI를 사용하고 있는 것 같지만 실제로는 개발 프로세스에 AI가 통합되지 않은 상태입니다.

AI는 단순한 "코드 파편을 제공해 주는 외부 도구"에 머물러 있으며, 개발 조직의 생산성이나 품질을 지속적으로 끌어올리는 메커니즘이 되지 못하는 상태입니다.

Level-0: 엔지니어 개인별로 AI 개발을 하고 있음

이 단계에서는 팀 내 각 엔지니어가 저마다의 방식으로 AI를 사용하기 시작합니다.

예를 들어, 어떤 사람은 Cursor를 사용하고, 다른 사람은 VS Code와 확장 기능을 사용하며, 또 다른 사람은 Claude Code나 ChatGPT를 사용하여 개발하고 있습니다.

언뜻 보기에는 자유도가 높고 각자가 최적의 방법을 모색하는 좋은 상태로 보일지도 모릅니다.

하지만 팀 개발이라는 관점에서는 문제가 있습니다.

개인마다 AI 활용 노하우가 폐쇄되어 국소 최적화(Local Optimization)가 진행됩니다.

그 결과, 개발 생산성이나 결과물의 품질에 편차가 발생합니다.

이 단계를 "AI 주도 개발을 하고 있다"라고 표현할 수도 있습니다.

다만, 필자는 이 단계를 진정한 의미의 AI 주도 개발이라고 부르기는 어렵다고 생각합니다.

왜냐하면 소프트웨어 개발은 팀 협업(Team Collaboration)이며, AI 활용 또한 팀의 개발 프로세스에 통합되어야 비로소 큰 효과를 발휘하기 때문입니다.

이 상태를 벗어나기 위해서는 누군가가 "이대로는 안 된다"라고 말할 필요가 있습니다.

즉, 누군가가 총대를 메겠다는 각오가 필요한 것입니다.

엔지니어링 매니저(Engineering Manager)나 CTO가 앞장서서 총대를 메는 역할을 맡아야 합니다.

당사 조직에서 가장 총대를 멨던 사람은 CEO인 저였습니다.

Level-1: AI를 활용한 개발이 팀 단위로 이루어지는 단계

Level-1은 개인의 AI 활용에서 팀으로서의 AI 활용으로 이행하는 단계입니다.

여기서부터 Harness Engineering의 사고방식이 본격적으로 중요해집니다.

Level-1a: Guides 작성과 도구의 통합

가장 먼저 해야 할 일은 AI에 대한 "Guides"를 정비하는 것입니다.

여기서 말하는 Guides란 AI 에이전트에게 사전에 부여하는 규칙이나 전제 정보입니다.

이른바 피드포워드 제어(Feedforward Control)에 해당합니다.

구체적으로는 다음과 같은 노력입니다.

• 팀 공통의 CLAUDE.md를 작성한다
• AI에게 읽힐 개발 규칙을 정비한다
• 사용하는 AI 모델이나 IDE를 어느 정도 통일한다
• 개발 지원 플러그인을 표준화한다
• devcontainer 등으로 개발 환경을 통일한다
• AI가 개발 DB나 로컬 환경을 안전하게 참조할 수 있도록 한다

특히 개발 환경의 통합은 중요합니다.

AI가 실제 개발 환경에 액세스할 수 없고, DB 구조도 알 수 없으며, 테스트도 실행할 수 없는 상태에서는 실용적인 AI 주도 개발이 어려워집니다.

이 단계는 작은 한 걸음처럼 보일지도 모릅니다.

하지만 팀에게는 매우 큰 도약입니다.

중요한 것은, CLAUDE.md를 한 번 만들고 끝내는 것이 아닙니다.

오히려 정말 중요한 것은, 그 이후에 멤버들로부터 CLAUDE.md나 규칙 개선을 위한 PR(Pull Request)이 올라오는 상태를 만드는 것입니다.

잘 풀린다면, 팀 멤버들끼리 AI 활용 노하우를 공유하기 시작합니다.

이 상태가 되어야 비로소 개인의 궁리가 팀의 자산으로 변하기 시작합니다.

Level-1b: 회의체의 창출과 PDCA 루틴의 확립

Level-1a가 원활하게 진행되면, 자연스럽게 AIDD에 대해 정보를 공유할 장소가 필요해집니다.

당사에서는 AIDD 추진 회의를 두고 있습니다.

현재는 월 1회 빈도이지만, 초기 단계에서는 주 1회 정도 실시하는 것이 좋다고 느끼고 있습니다.

이 회의에서는 다음과 같은 내용을 다룹니다.

• AI 리뷰가 지적하지 못한 점과 과잉 리뷰가 된 점
• AI가 생성한 코드의 문제점과 그 개선책
• 테스트나 Lint로 검지하지 못한 문제
• AI가 읽기 어려운 설계 문서나 프로그램의 공유 (리팩터링 필요)
• 보안상의 우려
• 개발자별 프롬프트(Prompt)의 노하우

이 회의체가 기능하기 시작하면, 이후의 Level에서 나타날 문제들이 자연스럽게 공유되게 됩니다.

즉, AIDD 추진 회의는 단순한 정보 공유의 장이 아닙니다.

팀의 하네스 엔지니어링(Harness Engineering)을 지속적으로 개선하기 위한 PDCA 루틴입니다.

Level-1c: 설계 문서의 AI 최적화

AI 개발을 진행하다 보면, 품질이 낮은 코드가 생성되는 원인이 사실은 코드가 아니라 설계 문서 측에 있다는 것을 깨닫게 됩니다.

혹은 사람이 설계서를 작성하는 것 자체가 병목(Bottleneck)이 되고 있는 경우도 있습니다.

특히 문제가 되기 쉬운 것이 AI가 해석하기 어려운 형식의 설계 문서입니다.

대표적인 예가 Excel 설계서입니다.

이 단계에서는 설계 문서를 AI가 읽기 쉬운 형식으로 이행해 나갑니다.

예를 들어, 다음과 같은 변화가 일어납니다.

• API 설계서를 OpenAPI / Swagger 등의 형식으로 전환
• DB 설계서를 Markdown이나 DDL 기반으로 관리
• UML이나 구성도를 Mermaid로 기술
• 요구사항 정의서를 Markdown 기반으로 관리
• Notion 등 AI가 참조하기 쉬운 도구로 집약

AI에게 설계서를 쓰게 하는 일이 늘어나면, 자연스럽게 AI가 다루기 쉬운 형식으로 기울어지게 됩니다.

이 단계에서는 '사람이 읽기 쉬운 설계서'에서 '사람과 AI 모두가 읽기 쉬운 설계 문서'로 발상을 전환해야 합니다.

Level-1d: Sensors의 재검토

다음에 중요해지는 것이 Sensors입니다.

Sensors란 AI가 생성한 결과물에 대해 피드백을 돌려주는 메커니즘입니다.

특히 중요한 것은 기계적으로 검지할 수 있는 피드백 기구입니다.

예를 들어, 다음과 같은 것들입니다.

• 테스트 코드
• Lint
• 타입 정의 (Type Definition)
• 스키마 검증 (Schema Validation)
• CI/CD 상의 자동 체크

이것들은 AIDD를 시작하기 전부터 존재하고 있는 경우가 많을 것입니다.

하지만 AI 주도 개발이 진행되면, 기존의 Sensors로는 불충분하다는 것을 깨닫게 됩니다.

예를 들어, 다음과 같은 문제입니다.

• 테스트 실행 속도가 느려 AI가 빈번하게 돌릴 수 없음
• 테스트 커버리지(Test Coverage)가 낮아 AI의 실수를 검지할 수 없음
• 타입이 복잡해져서 AI가 올바르게 다루지 못함
• Lint 규칙이 모호하여 품질의 편차를 방지할 수 없음
• 검증 로직이 분산되어 있음
• 실행 환경에 따라 결과가 달라짐

이 단계에서는 Sensors를 AI 개발을 전제로 강화해 나갑니다.

예를 들어, Zod와 같이 타입과 검증을 통합할 수 있는 스키마(Schema)를 도입하기도 합니다.

또한 테스트를 고속화하거나, AI가 국소적으로 실행하기 쉬운 테스트 구조로 재검토하는 것도 중요합니다.

필자의 감각으로는, 이 단계까지 도달해야 비로소 "팀에 하네스 엔지니어링이 존재하고 있다"라고 자신 있게 말할 수 있게 됩니다.

Level-1e: Guides의 재설계

처음에 만든 CLAUDE.md는 머지않아 한계에 부딪힙니다.

프로젝트가 커지면 단일 CLAUDE.md에 모든 규칙을 쓰는 것이 어려워지기 때문입니다.

이 단계에서는 Guides를 재설계해 나갑니다.

구체적으로는 다음과 같은 노력입니다.

• CLAUDE.md

• 분할한다 - rules를 용도별로 정리한다

• 폴더별로 AI를 위한 규칙을 최적화한다

• 리뷰용 가이드를 만든다

• PR(Pull Request) 작성용 가이드를 만든다

• 테스트 작성용 가이드를 만든다

• 특정 태스크에 특화된 에이전트(Agent)나 스킬(Skills)을 만든다

처음에는 CLAUDE.md나 rules의 개선이 중심이 됩니다.

그 후, AIDD 추진 회의에서 제기된 문제를 바탕으로 더욱 구체적인 가이드로 발전해 나갑니다.

더 나아가면 「리뷰」, 「PR 작성」, 「테스트 생성」, 「장애 조사」 등 특정 작업에 특화된 에이전트(Agent)나 스킬(Skills)을 정비하는 단계에 진입합니다.

이 단계에서는 AI에게 무엇이든 자유롭게 시키는 것이 아니라, 태스크마다 적절한 문맥(Context)과 제약(Constraint)을 부여하는 것이 중요해집니다.

Level-1f: 프롬프팅 리뷰 실시

여기까지 진행되면 개발자마다 생산성에 차이가 나고 있다는 사실을 깨닫게 됩니다.

그 원인 중 하나가 프롬프팅(Prompting) 능력의 차이입니다.

물론 환경 정비가 불충분한 단계에서는 "하네스 엔지니어링(Harness Engineering)이 부족해서 생산성이 오르지 않는다"라고 말할 수 있습니다.

하지만 가이드(Guides)와 센서(Sensors)가 갖춰지기 시작하면, 그러한 변명은 점차 통하지 않게 됩니다.

동일한 환경, 동일한 규칙, 동일한 AI 에이전트(AI Agent)를 사용하더라도 개발자에 따라 결과물의 품질이나 속도에 차이가 나기 시작합니다.

이 문제에 대해 당사에서는 프롬프팅 리뷰를 실시했습니다.

구체적으로는 PR에 개발 시 실행한 AI와의 대화, 즉 프롬프트(Prompt) 이력을 첨부하여 이를 리뷰 대상으로 삼았습니다.

프롬프트는 AI 주도 개발(AIDD)에 있어 「작업 로그」이자 「설계 판단의 흔적」이기도 합니다.

이를 리뷰함으로써 각 엔지니어의 습관이나 문제점을 찾아내고, 팀 전체의 프롬프트 엔지니어링(Prompt Engineering) 역량을 높일 수 있습니다.

실제로 당사에서는 이 노력을 통해 개발자별 프롬프트의 질을 개선할 수 있었습니다.

Level-1g: 보안 및 개발 환경 재검토

이 단계에서는 AI 활용에 따른 보안 리스크가 본격적으로 문제가 됩니다.

본래라면 더 이른 단계에서 다루어야 했을 테마일지도 모릅니다.

하지만 실제로는 AI의 편의성이나 생산성 향상에 너무 집중한 나머지, 보안 대책이 뒤로 밀리는 경우도 있습니다.

특히 중요한 것이 프롬프트 인젝션(Prompt Injection)이나 정보 유출에 대한 대책입니다.

예를 들어, AI 도구가 제공하는 ignore 설정이나 「읽어서는 안 되는 파일」 지정만으로는 불충분할 수 있습니다.

이 단계에서는 "AI를 신뢰하는" 것이 아니라, 제로 트러스트(Zero Trust)를 전제로 개발 환경을 재검토합니다.

구체적으로는 다음과 같은 대책입니다.

• .env에 기밀 정보를 두지 않는다 - AWS Secrets Manager 등을 활용한다
• 개발 DB에 대한 액세스 권한을 최소화한다
• AI가 액세스할 수 있는 네트워크를 제한한다
• 운영 환경에 준하는 데이터를 AI가 읽을 수 없게 한다
• 로컬 환경에 불필요한 인증 정보를 두지 않는다
• AI 에이전트(AI Agent)에게 전달하는 컨텍스트(Context)를 제어한다

AI 에이전트(AI Agent)는 강력합니다.

그렇기에 편리하게 만들수록 리스크도 증가합니다.

이 단계에서는 AI를 활용하기 위한 개발 환경과, AI에게 보여주어서는 안 되는 정보를 분리하는 설계가 중요해집니다.

Level-1h: 소프트웨어의 AI 최적화 리팩터링

여기까지 오면 하네스 엔지니어링(Harness Engineering)만으로는 해결할 수 없는 문제에 직면합니다.

그것은 소프트웨어 자체가 AI가 다루기 어렵다는 문제입니다.

이 단계에서는 AI가 이해하기 쉽고 변경하기 쉬운 코드베이스(Codebase)로 리팩터링(Refactoring)해 나갑니다.

당사에서는 예를 들어 다음과 같은 노력을 기울였습니다.

• 특정 패턴의 개발에서 참조할 수 있는 베스트 프랙티스(Best Practice) 구현을 만든다
• codemod의 기준이 될 수 있는 샘플 코드를 정비한다
• 거대한 비타입(Non-typed) 스크립트를 분할 및 타입화(Typing)한다
• 폴더 구조를 재검토한다
• 파일명을 역할을 알 수 있는 이름으로 변경한다
• Zod schema와 같이 AI가 다루기 쉬운 타입 구조를 도입한다

AI는 문맥(Context)을 바탕으로 판단합니다.

따라서 폴더명, 파일명, 타입(Type), 스키마(Schema), 테스트, 샘플 구현 등 모든 정보가 AI에게는 단서가 됩니다.

AI 최적화 리팩터링(AI Optimization Refactoring)이란 단순히 인간이 읽기 좋은 코드로 만드는 것이 아닙니다.

AI를 포함한 개발 팀 전체가 이해하기 쉬운 코드베이스로 바꾸어 가는 것입니다.

Level-1i: 멀티 에이전트 개발과 리소스 제약

이 단계까지 진행되면, 각 엔지니어가 여러 개의 AI 에이전트 (AI Agent)를 동시에 사용하면서 여러 태스크를 개발하게 됩니다.

이러한 멀티 에이전트 (Multi-agent) 개발이 시작되면, 다음에 문제가 되는 것이 리소스 제약 (Resource Constraint)입니다.

먼저, 토큰 (Token)이 부족해집니다.

다음으로, 개발 PC의 메모리가 부족해집니다.

Serena와 같이 토큰 소비를 억제하는 메커니즘을 도입하는 것도 유효합니다.

하지만 그것만으로는 한계가 있습니다.

본격적으로 멀티 에이전트 개발을 수행하려면, 툴이나 인프라 (Infrastructure)에 대한 투자가 필요합니다.

AI 주도 개발 (AIDD)은 단순히 툴을 도입한다고 끝나는 것이 아닙니다.

생산성을 진정으로 높이려면, 개발자의 PC 사양, AI 이용 플랜, 개발 환경, 문서 구조까지 포함한 투자가 필요하게 됩니다.

Level-1 너머에 있는 과제

본 기사에서는 세부적인 이야기는 Level-1까지만 다룹니다.

하지만 Level-1의 후반부까지 진행되면, 개발 팀에는 새로운 문제가 발생합니다.

그것은 대량의 결과물이 생겨나는 한편, 그 리뷰나 품질 보증 (QA)이 따라가지 못하게 된다는 점입니다.

AI에 의해 구현 속도는 올라갑니다.

하지만 리뷰, 테스트, 릴리스 판단, 프로덕트 매니지먼트 (Product Management)가 따라가지 못하면, 소프트웨어 품질은 일시적으로 저하됩니다.

즉, AI에 의해 개발 속도가 올라간 결과, 이번에는 애자일 프로세스 (Agile Process) 전체가 병목 (Bottleneck)이 됩니다.

이 문제를 어떻게 해소할 것인가.

그것이 Level-2 이후의 테마입니다.

Level-2 이후의 진화 단계

본 기사에서는 상세히 파고들지 않겠지만, Level-2 이후는 대략 다음과 같은 단계가 될 것이라고 생각합니다.

Level-2: 애자일 프로세스에 AI가 통합된 단계

• Level-2a: PJ 관리 툴 및 주변 툴과의 통합 (CS나 영업과의 통합)
• Level-2b: FR / E2E 테스트의 자동화
• Level-2c: 멀티 에이전트 개발을 위한 환경 정비
• Level-2d: 장애 조사 자동화

Level-3: AI가 자율적으로 태스크를 실시하는 단계

• Level-3a: 완전 스탠드얼론 (Stand-alone) AIDD
• Level-3b: 스탠드얼론 환경에서의 활동 범위 확대
• Level-3c: 고객 커뮤니케이션과의 AI 통합

Level-2 이후에 대해서는 별도의 기사에서 구체적으로 정리하고자 합니다.

요약

AI 주도 개발은 툴을 도입하는 순간 완성되는 것이 아닙니다.

처음에는 개인이 AI를 사용하는 것부터 시작됩니다.

다음으로, 팀으로서 Guides나 Sensors를 정비합니다.

그 후, 설계 문서, 테스트, 타입 (Type), 보안, 코드베이스 그 자체를 AI 전제로 재검토해 나갑니다.

더 나아가면, 멀티 에이전트 개발이나 애자일 프로세스 전체의 재설계가 필요해집니다.

중요한 것은, AI 주도 개발을 '개인의 프롬프트 능력'만으로 파악하지 않는 것입니다.

정말로 필요한 것은, AI가 안전하고 효과적으로 개발할 수 있는 환경을 팀으로서 지속적으로 정비하는 것입니다.

그런 의미에서, 하네스 엔지니어링 (Harness Engineering)은 AI 주도 개발의 핵심이 됩니다.

본 기사에서는 Level-1을 중심으로 정리했습니다.

Level-2 이후에 대해서는 별도의 기사에서 더욱 구체적으로 깊이 있게 다루겠습니다.

함께 일할 동료를 찾고 있습니다

이 기사를 읽고 저나 당사의 엔지니어 팀에 관심이 있는 분은 꼭 한번 이야기 나누었으면 합니다.

Discussion