SITE SEARCH

검색

사이트 전체 글을 빠르게 찾을 수 있습니다.

RSS FEED

RSS 구독

RSS 리더에서 Project Research의 새 글을 바로 받아볼 수 있습니다.

EMAIL SUBSCRIBE

이메일 구독

새 글을 이메일로 받아봅니다. RSS는 별도 RSS 아이콘을 눌러 동일한 크기의 패널에서 열 수 있습니다.

이메일로 블로그 구독하기

이 블로그를 구독하고 이메일로 새글의 알림을 받으려면 이메일 주소를 입력하세요







[AI가 코딩하고, AI가 관리한 1주일의 기록]

시리즈

이 편이 답하는 질문
  • Claude 트랙(90.3점, 565개 테스트, 116개 이슈 해결)과 Codex 트랙(51.8점, 29개 테스트)의 38점 격차가 “AI 엔진 선택”이 아닌 “체계적 거버넌스의 유무”에서 비롯되었다면, 어느 시점부터 두 체계가 분화되었고 돌이킬 수 없었는가?
  • AI 품질 점수가 59점에서 82점으로 뛰었을 때, “2배 풍부한 내용”과 “AI Slop Detection 30개 패턴”이 실제 운영 비용(시간×토큰)을 어떻게 증감시키는지 측정할 방법은?
  • PM 역할(오케스트레이션·ADR·버전 진화)과 PL 역할(테스트 작성·모듈 구현·품질 검증)을 AI가 동시 수행했을 때 최종 성숙도가 결정된다는 것을 현장에서 재현하려면, 스프린트 초반에 어떤 체크포인트를 설정해야 하는가?
  • 1주일 116개 이슈 해결한 Claude 트랙의 의사결정 기록(5 ADR·PRD v0.8)이 6개월 후 조직 자산으로 남을 조건은 무엇이며, 이를 보장하는 거버넌스 구조를 어떻게 설계해야 하는가?
이 시리즈를 읽는 세 개의 눈
  • PO: AI 트랙 선택과 체계 설계가 같은 가치를 창출하지 않는다는 점에서, “어떤 AI”가 아니라 “어떤 프로세스”에 투자해야 장기적 가치가 누적된다.
  • PM: 116개 이슈 해결과 5 ADR 작성의 병렬 진행이 가능한 것은 AI가 코드뿐 아니라 “왜 그렇게 했는가”를 동시에 기록할 수 있기 때문이므로, 이 기능을 PM 제도 설계에 명시적으로 요구해야 한다.
  • PL: 565 테스트는 단순 수량이 아니라 심도 있는 리팩토링을 심리적으로 가능하게 하는 기반이므로, 테스트 작성을 “마지막 검증”에서 “아키텍처 설계 단계”로 앞당겨야 한다.

AI-SDLC / Agentic coding 주제로 흥미로운 실험을 했습니다. "책을 쓰고 출판까지 자동화하는 시스템"을 두 가지 방식으로 동시에 바이브코딩기법으로 개발한 것입니다. 같은 목표, 같은 기간, 다른 AI 엔진. Codex와 Claude를 경쟁시켜 봤습니다. AI가 코드를 짜고, AI가 프로젝트를 관리했습니다.

결과는 예상 밖이었습니다. 하나는 빠른 실험에 적합한 MVP로, 다른 하나는 상업 출판이 가능한 프로덕션 시스템으로 스스로 분화했습니다.

1. 같은 원고, 다른 결과

가장 흥미로운 발견은 어떤 AI 엔진을 쓰느냐에 따라 결과물이 완전히 달라진다는 점이었습니다. 같은 원고(Mindful Running)를 넣었는데, Claude 엔진은 OpenAI 대비 2배 더 풍부한 내용을 생성했고, 품질 점수는 59점에서 82점으로 뛰었습니다.

물론 시간은 더 걸립니다. 2분이면 될 일이 6분 반이 걸리죠. 하지만 실제로 책을 출판하려면 이 정도 품질 차이는 결정적입니다. 특히 "AI가 쓴 티"를 잡아내는 기능(AI Slop Detection)은 30개 이상의 패턴을 감지하는데, 이게 없으면 기계적이고 상투적인 문장이 그대로 남습니다.

2. AI가 PM과 개발 리더 역할을 할 수 있을까?

이번 실험의 핵심 질문은 'AI가 프로젝트 매니저(PM)와 개발 리더(PL) 역할을 실제로 수행할 수 있는가?'였습니다.

결과는 "된다"입니다. 구체적으로 AI가 1주일간 수행한 일을 보면:

– PM 역할(오케스트레이션): 116개의 이슈를 생성하고 해결했습니다. "왜 이런 구조로 만들었는지" 기록하는 의사결정 문서(ADR)를 5건 작성했고, 요구사항 문서(PRD)를 v0.3에서 v0.8까지 4번 진화시켰습니다. 6개월 후에 "왜 이렇게 했지?"라는 질문에 답할 수 있는 기록이 남은 겁니다.

– PL 역할(코딩): 565개의 테스트 코드를 만들었습니다. Codex Track의 29개와 비교하면 19.5배 차이입니다. 이게 왜 중요하냐면, 테스트가 29개면 코드 구조를 바꾸는 게 무섭습니다. 뭐가 깨질지 모르니까요. 565개면 마음껏 개선할 수 있습니다. 17개의 기능 모듈(Skill)도 AI가 설계하고 구현했습니다.

최종 성숙도 점수는 Claude Track 90.3점, Codex Track 51.8점. 38점 차이는 코드 양이 아니라 체계의 차이입니다. 테스트, 문서화, 품질 관리—이 모든 것이 갖춰졌느냐가 갈랐습니다.

Production
ready

Prototype
only

Codex Track — 51.8

29 Tests

MVP-level output

Fast but shallow

Claude Track — 90.3

116 Issues resolved

565 Tests

5 ADRs + PRD v0.8

17 Skill modules

Human PM
Orchestrator

Deployable
System

Quick
Experiment

3. aipm-ops 오픈소스 공개

이 경험을 aipm-ops 라는 이름으로 오픈소스로 공개합니다. AI가 프로젝트를 관리할 때 필요한 운영 체계—이슈 관리 방식, 의사결정 기록 형식, 품질 검증 기준—를 담았습니다. @aipm.pl

4. 교훈

1주일간 배운 핵심은 이것입니다: Agentic Coding의 본질은 빠른 코드 생성이 아니라, 품질을 반복적으로 재현할 수 있는 체계를 만드는 것입니다. AI가 코드만 짜는 게 아니라 왜 그렇게 짰는지 기록하고, 제대로 작동하는지 검증하고, 문제가 생기면 추적할 수 있어야 합니다.

그게 가능하다는 걸, 이번 1주일이 증명했습니다.

[AI가 코딩하고, AI가 관리한 1주일의 기록]
[AI가 코딩하고, AI가 관리한 1주일의 기록]
[AI가 코딩하고, AI가 관리한 1주일의 기록]
[AI가 코딩하고, AI가 관리한 1주일의 기록]
[AI가 코딩하고, AI가 관리한 1주일의 기록]

#AgenticCoding #AI개발 #ClaudeAI #OpenAI #LLM비교 #AIPM #소프트웨어개발 #오픈소스 #aipm-ops #자동화 #출판자동화 #개발회고

함께 읽기 · Related Posts

시리즈 네트워크에서 이 편과 연결된 글

Project Research에서 더 알아보기

지금 구독하여 계속 읽고 전체 아카이브에 액세스하세요.

계속 읽기