1년간의 AI 코딩 여정: 손으로 치던 코드에서 에이전트가 쓰는 코드까지

PE Expert 지식 공유 - 회원주문개발팀 김규원 팀장 & Product Engineer

2026년 2월, 주문 서비스 GitHub에 한 가지 흥미로운 변화가 나타났습니다. 한 달간 커밋 291건까지 올라간 것입니다.

야근의 결과였을까요?

“단순히 개발량이 늘어난 것이 아니라 개발 방식 자체가 바뀌었어요.”

1년 전만 해도 AI는 코드를 물어보고 수정하는 보조 도구에 가까웠습니다. 하지만 지금은 상황이 다릅니다. 코드뿐 아니라 테스트, 문서, 커밋 메시지까지 AI가 생성하는 개발 흐름이 만들어졌습니다. 지난 1년 동안 7개의 레포지토리에서 약 1,700건의 커밋이 만들어졌습니다.

그중 상당수는 사람이 아닌 AI 에이전트가 생성한 코드였습니다.

그렇다면 이런 변화는 어떻게 가능했을까요?

단순히 AI 도구를 사용하는 것만으로는 설명하기 어렵습니다. 핵심은 개발 방법론 자체의 변화에 있었습니다.

지난 1년 동안 규원님은 AI를 활용한 개발 방식을 실험하며 변화를 기록해 왔습니다. Vibe Coding에서 시작해 Harness Engineering까지, 이 글에서 “사람이 코드를 작성하던 방식이 어떻게 에이전트 중심 개발 방식으로 바뀌었는지를 소개해 보려고 합니다.

숫자가 보여주는 변화의 궤적

먼저 GitHub 커밋 데이터를 통해 변화의 흐름을 살펴보겠습니다.

2025년 1월에는 월 26건 수준으로 시작했습니다. 하지만 3월에는 186건으로 첫 번째 피크가 나타났고, 이후 여름 동안 60~80건 수준으로 안정화됩니다.

그리고 2025년 10월 이후 다시 증가하기 시작해 2026년 2월에는 291건으로 최고점을 기록합니다. 레포별 분포를 보면 패턴이 더 선명해집니다.

이 변화의 흐름에는 두 번의 중요한 전환점이 있습니다.

2025년 3월

2026년 2월

각각의 시점에서 무엇이 달라졌는지 살펴보겠습니다.

2025년 상반기에는 커밋이 여러 레포에 고르게 분포합니다. 특히 2025년 3월에는 glados 레포에 63건의 커밋이 집중됩니다. 이 시점에는 AI Slack Bot을 개발하고 있었습니다.

하반기로 갈수록 order에 집중되기 시작합니다.

2025년 10월 95건

2025년 11월 121건

2025년 12월 99건

그리고 2026년 2월. order 182건, claude-code-plugins 38건. 두 레포에서 동시에 집중되어 일어납니다.

이 변화 뒤에는 개발 방법론의 진화가 있었습니다.

Copy-Paste AI Coding

2025년 초, AI 코딩은 비교적 단순한 형태로 시작했습니다.

프롬프트로 코드를 생성하고, 결과를 가져와 수정한 뒤 커밋하는 방식입니다. AI가 도움을 주긴 하지만, 최종 검증과 마무리는 여전히 개발자의 몫입니다.

이 시기 커밋 메시지를 보면 특징이 있습니다. 한글과 영어가 섞여 있고, 짧고, 불규칙적입니다. 직접 작성했기 때문입니다.

그런데 3월에 186건이라는 첫 번째 피크가 찍힙니다. 무슨 일이 있었던 걸까요?

이 시기에 규원님은 AI 슬랙봇을 직접 개발합니다. 팀의 회고 자동화와 Jira 연동을 처리하는 내부 Slack Bot이었습니다. 3월 한 달 동안 glados 레포에는 63건의 커밋이 올라갔습니다.

“슬랙 챗봇 서비스를 만들면서 AI를 활용해 업무 생산성을 높이고 개발에 집중할 수 있었어요”

이 프로젝트를 통해 깨달은 것이 있습니다. AI는 단순히 코드 생성을 도와주는 도구가 아니라, 개발 생산성 자체를 바꿀 수 있는 도구라는 점이었습니다.

하지만 이 단계에서는 여전히

AI = 보조도구

였습니다.

Vibe and Augmented Coding

2025년 하반기에는 AI 활용 방식이 한 단계 더 발전했습니다.

가장 큰 변화는 AI 코드 리뷰의 도입이었습니다. PR을 올리면 Claude가 자동으로 리뷰를 남기는 GitHub Action을 도입했습니다. AI가 변경 의도를 더 잘 이해할 수 있도록 파일 변경점을 기준으로 커밋을 구조화하고, 코드 리뷰에 맞는 프롬프트도 함께 설계했습니다.

이때부터 커밋 메시지가 달라지기 시작합니다. 짧게 의도만 전달하는 커밋 대신, 기능의 맥락과 변경 의도를 설명하는 형태가 늘어나기 시작합니다. Conventional Commit 스타일도 자연스럽게 자리 잡았습니다.

영문 conventional commit이 등장한 것은 사실 AI가 커밋 메시지 생성에도 참여하기 시작했다는 신호였습니다.

같은 시기에 테스트 가이드라인을 문서화하기 시작합니다. 이 결정의 의미는 곧 드러납니다.

7월부터 9월까지 월별 커밋 수는 81건, 66건, 69건으로 완만하게 유지됩니다. 이 시기를 Augmented Coding 단계라고 볼 수 있습니다. AI가 코드 작성을 보조하는 단계로, 코드 리뷰와 테스트 생성, 리팩토링 제안 등에 적극적으로 참여하지만 개발의 주도권은 여전히 사람에게 있습니다.

전환점은 10월에 찾아옵니다.

월 100개의 커밋

2025년 10월, order 레포에서 눈에 띄는 변화가 나타납니다. 한 달 커밋이 95건으로 늘어나더니, 11월에는 121건, 12월에는 99건까지 이어집니다. 이 시기부터 커밋이 order 레포에 집중되기 시작합니다.

이 변화의 배경에는 SDD(Spec-Driven Development) 도입이 있었습니다.

개발 방식은 단순해 보이지만, 이전과는 본질적으로 달랐습니다. 요구사항을 받으면 먼저 스펙 문서를 작성합니다. AI는 이 문서를 기반으로 코드와 테스트를 생성하고, 사람은 결과를 검증합니다. 사람은 스펙을 정의하고, 구현은 AI가 담당하는 방식입니다.

핵심은 3-Layer Context입니다.

• 프로젝트 컨텍스트: 코드베이스 구조와 컨벤션
• 도메인 컨텍스트: 비즈니스 로직과 용어집
• 태스크 컨텍스트: 지금 구현해야 할 작업 스펙

이 세 가지 맥락을 AI에게 전달하면, 코드베이스에 맞는 초안 코드와 테스트를 생성할 수 있습니다.

여기서 9월에 문서화한 테스트 가이드라인이 중요한 역할을 합니다. AI가 테스트 코드를 생성할 때 참조할 기준이 생긴 것입니다.

“10월에는 Feature Flag 프레임워크를 만들었고,

11월에는 클린 아키텍처 기반 UseCase 패턴과 환불 정책 Strategy 패턴을 적용했습니다.

12월에는 렌터카 시나리오 확장과 취소 V2 파이프라인까지 이어졌습니다.

AI가 테스트 케이스를 대량으로 생성하기 시작하면서 리팩토링 속도가 완전히 달라졌습니다.”

이 시기부터 테스트와 문서가 빠르게 쌓이기 시작합니다. AI가 테스트 코드를 작성하고, 문서까지 함께 생성하기 시작했기 때문입니다.

하지만 이것은 더 큰 변화의 시작에 불과했습니다.

지도를 그리다

2026년 초, 규원님은 피드에서 OpenAI가 소개한 Harness Engineering이라는 글을 접합니다.

5개월간 수동으로 작성한 코드 0줄. Codex 에이전트만으로 100만 줄 규모의 프로덕션 제품을 만들었다는 이야기. Harness Engineering은 AI 에이전트가 코드 작성의 주체가 되고, 사람은 방향을 설정하고 검증하는 역할로 전환되는 개발 방식입니다.

특히 인상 깊었던 문장이 있었습니다.

“Give Codex a map, not a 1,000-page instruction manual.”

‘거대한 AGENTS.md 하나는 실패한다. 에이전트에게 필요한 건 지도이지 백과사전이 아니다.’

처음에는 필요한 규칙과 정보를 프롬프트에 계속 추가하는 방식으로 문제를 풀려 했습니다. 하지만 이 접근에는 금방 한계가 드러났습니다. Harness Engineering에서 힌트를 얻습니다.

Made repository knowledge the system of record

Google Docs나 Slack에 있는 지식은 에이전트에게는 존재하지 않는 것과 같다. 모든 컨텍스트는 레포 안에, 버전 관리되는 형태로 있어야 한다.

그래서 직접 만든 게 docs-tree-tools 플러그인입니다.

docs-tree-tools: 에이전트를 위한 지도

docs-tree-tools는 Claude Code 플러그인으로, 레포지토리를 에이전트 친화적으로 구조화하기 위한 도구입니다.

핵심 기능은 세 가지입니다.

첫 번째 기능은 docs/ 트리 자동 구조화입니다. index.yml이라는 중앙 레지스트리로 모든 문서를 ID와 경로로 매핑합니다. 에이전트가 워크플로우별로 필요한 문서만 자동으로 로딩합니다. 루트 AGENTS.md는 100줄 이내로 유지하고, 나머지는 docs/index.yml로 포인팅합니다.

두 번째 기능은 Doctor입니다. 4계층 진단 엔진으로 문서 품질을 점수화합니다. 인덱스 정합성 40%, 에이전트 가이드 위생 30%, Harness 원칙 정렬 20%, 링크 품질 10%. pre-commit 훅으로 커밋마다 자동 진단합니다. 외부 참조(Notion이나 Google Docs)가 감지되면 경고를 띄웁니다.

세 번째 기능은 코드 역분석입니다. 소스코드에서 용어집, 유스케이스, 스펙, 표준, 제품 문서를 자동으로 추출합니다. endpoint를 스캔해서 Usecase 문서를 자동 생성하는 파이프라인도 있습니다. Usecase 문서와 시나리오, E2E 테스트 간 추적성을 강제해서 문서와 코드의 동기화를 유지합니다.

Harness Engineering의 원칙을 마이리얼트립 주문 레포에 어떻게 적용했는지 정리하면 이렇습니다.

“Harness Engineering에서 배운 것은 원칙이었고, docs-tree-tools는 그 원칙을 레포지토리에서 실제로 동작하도록 만드는 도구입니다.”

도구와 개발이 동시에 진화하다

2026년 2월, docs-tree-tools는 빠르게 진화합니다. 사내 plugins 레포에는 38건의 커밋이 올라갔고 동시에 order 레포에는 182건의 커밋이 쌓였습니다. 이렇게 해서 월 291건 커밋이라는 숫자가 만들어졌습니다.

핵심은 단순했습니다.

도구를 만들면서 동시에 그 도구로 실제 개발을 진행한 것.

즉, 개발 방식 자체가 에이전트 중심 구조로 재설계되고 있었던 것입니다.

네 단계의 진화

1년간의 여정을 정리하면 개발 방식은 크게 네 단계의 진화를 거쳤습니다.

2025년 상반기는 Copy-Paste AI Coding, Vibe Coding 단계입니다. 프롬프트로 코드를 생성하고, 수동으로 검증합니다. AI 슬랙봇 개발로 AI 프롬프팅 실전 경험을 쌓습니다. 커밋 메시지는 한글 혼용, 즉흥적입니다.

2025년 3분기에 Augmented Coding으로 전환됩니다. Claude Code Review 워크플로우가 도입되고,에이전트 테스트 작성 가이드가 문서화됩니다. 커밋 메시지가 영문 conventional commit으로 바뀌기 시작합니다. AI가 코드 리뷰와 테스트 생성에 참여하면서 개발 과정에 보조적인 역할을 하기 시작한 시기입니다.

2025년 4분기에 Spec Driven Development(SDD)가 자리 잡습니다. 3-Layer Context 기반 개발이 정착하고, AI가 TC와 리팩토링을 대량 생성합니다. UseCase 패턴, Strategy 패턴이 적용되고, 월 100건 이상의 커밋이 가능해집니다.

2026년 1분기에 Harness Engineering 단계로 진입합니다. BDD E2E 테스트 스위트, Document Tree가 구축됩니다. docs-tree-tools 플러그인을 자체 개발하고, 에이전트가 문서-코드-테스트 전체를 관리하기 시작합니다.

에이전트 친화적 구조는 사람에게도 좋다

규원님이 1년간 얻은 교훈은 네 가지로 정리됩니다.

첫째, 프롬프트에 모든 것을 담으려는 접근은 실패합니다. 처음에는 모든 컨텍스트를 담은 거대한 프롬프트를 만들었습니다. 한계가 빠르게 드러났습니다. 에이전트에겐 지도가 필요하지, 백과사전이 필요하지 않습니다.

둘째, 레포지토리를 모든 지식의 기준이 되는 곳으로 만들어야 합니다. 레포 밖의 정보는 없는 정보입니다. 모든 중요한 정보는 docs/ 폴더에 커밋되어 있어야 합니다.

셋째, 테스트가 있어야 에이전트를 신뢰할 수 있습니다. AI가 생성한 코드를 어떻게 검증하나요? 테스트입니다. 사용자 스토리 기반의 E2E 테스트 스위트를 만들었고, 에이전트가 생성한 코드는 반드시 이 테스트를 통과해야 합니다.

넷째, 에이전트 친화적 구조는 사람에게도 좋습니다. 문서가 잘 정리되고, 용어집이 있고, 스펙이 명확하면, 그건 사람이 읽기에도 좋습니다. 에이전트를 위해 레포를 정리하면, 온보딩도 쉬워집니다.

그리고 다음 단계

앞으로의 1년이 어떻게 변할지는 아직 알 수 없습니다.

다만 한 가지는 분명해 보입니다.

앞으로 개발에서 중요한 것은 코드를 얼마나 잘 작성하느냐가 아니라 에이전트가 일할 수 있는 환경을 얼마나 잘 설계하느냐일지도 모릅니다.

지난 1년은 AI를 사용하는 방법을 배운 시간이 아니라, AI가 일할 수 있는 개발 환경을 설계하는 방법을 배운 시간이었습니다.

설계 결정과 아키텍처 판단, 비즈니스 로직에 대한 검증과 책임은 여전히 사람의 몫입니다.

하지만 그 결정을 코드로 옮기는 건, 점점 더 에이전트의 영역이 되고 있습니다.

Humans steer. Agents execute.

마이리얼트립은 이런 실험들을 계속하고 있습니다