TL;DR
- 에이전틱 코딩이란 AI 에이전트가 계획·실행·검증을 다단계로 수행하는 개발 방식이다. 즉흥 프롬프트인 ‘바이브 코딩’보다 구조적이고, AI가 개발의 주체로 올라선다.
- AX(AI Transformation)는 제품·업무·개발 세 층위 모두에 걸쳐 있지만, 소규모 팀이 체감 가능한 진입점은 단연 ‘개발 환경’이다.
- AI가 개발 주체가 될수록 그 AI를 조율·추적·소통시키는 프로젝트 관리 체계가 성패를 가른다. 이 시리즈는 그 구조를 8편에 걸쳐 풀어낸다.
GPU 없이, GitHub 없이 — 에이전틱 코딩이 우리 개발 환경을 바꿨다
작년 이맘때 우리 팀의 개발 방식은 평범했다. 코드는 사람이 짜고, AI는 자동완성이나 질의응답 정도에 쓰는 보조 도구였다. 그 경계가 무너진 건 Claude Code를 개발 서버에 붙이면서부터다. AI가 이슈를 읽고, 코드를 작성하고, 테스트 결과를 보고 수정 방향을 결정하는 것을 보면서 “이건 단순 자동화가 아니다”라는 확신이 생겼다.
에이전틱 코딩(Agentic Coding)이란, AI 에이전트가 하나의 목표를 받아 계획 수립·파일 탐색·코드 작성·실행·검증을 다단계로 반복 수행하는 개발 방식이다. 사람은 방향을 잡고 결과를 검증하는 오케스트레이터가 된다. 이것이 이 시리즈에서 말하는 AX — AI Transformation — 개발 층위의 실체다.
에이전틱 코딩 vs 바이브 코딩 — 어떻게 다른가?
두 용어가 혼용되지만 성격은 다르다.
| 구분 | 바이브 코딩 | 에이전틱 코딩 |
|---|---|---|
| 작동 방식 | 즉흥 프롬프트 → AI 출력 → 사람이 붙여넣기 | AI가 목표를 받아 계획·실행·검증을 다단계 수행 |
| 사람의 역할 | 프롬프트 작성자 + 붙여넣기 실행자 | 방향 설정 + 오케스트레이터 + 최종 QA |
| 맥락 유지 | 세션 단위 (맥락 단절 잦음) | 파일 트리·이슈·히스토리 등 지속 맥락 |
| 적합 규모 | 단발 스니펫, 빠른 PoC | 멀티파일·MSA·장기 프로젝트 |
| 리스크 | 코드 일관성 낮음, 검증 부담 큼 | 방향 설정 실수가 여러 파일에 전파 가능 |
바이브 코딩이 나쁜 건 아니다. 빠른 탐색·PoC에는 오히려 맞다. 그러나 MSA 구조의 서비스를 팀이 장기 개발한다면 에이전틱 코딩의 체계가 필요해진다. 이 시리즈가 전자가 아닌 후자를 다루는 이유다.
AX 3층위 — 개발 환경이 가장 현실적인 진입점인 이유
AX(AI Transformation)는 세 층위에서 동시에 진행된다.
| 층위 | 내용 | 소규모 팀 체감도 |
|---|---|---|
| 제품 층위 | AI 기능을 제품에 내재화 (추천·생성·분류 등) | 중 — 기획·설계 비용 큼 |
| 업무 층위 | 업무 프로세스에 AI 보조 도입 (문서·고객응대 등) | 중 — 도구 도입은 쉽지만 효과 측정 어려움 |
| 개발 층위 | AI를 개발 파이프라인 자체에 통합 | 높음 — 즉시 체감, 팀 규모와 무관 |
소규모 팀이 “AX 해야 하는데”라는 막연함에서 벗어나는 가장 빠른 경로는 개발 환경부터 AI를 주체로 올리는 것이다. 거창한 데이터 파이프라인이나 ML 인프라가 필요 없다. 에디터를 Claude Code로 바꾸고, 이슈를 Gitea에서 관리하면 시작할 수 있다.
정직한 선긋기 — AI가 개발 주체가 된다는 것, 인프라는 무대일 뿐
이 시리즈를 읽다 보면 Docker·MSA·Proxmox 같은 단어가 자주 등장한다. 분명히 해두고 싶은 게 있다.
Docker와 MSA, Proxmox는 AX의 핵심이 아니다. 인프라 현대화다. 컨테이너로 서비스를 격리하고, 운영 서버를 별도 Proxmox 노드로 분리하는 것은 AI 에이전트가 안정적으로 개발·배포할 수 있는 무대를 만드는 일이다. 무대가 튼튼해야 배우가 제대로 움직인다.
AX의 핵심은 따로 있다. AI가 개발의 주체가 된다는 것이다. 이슈를 읽고, 파일을 탐색하고, 코드를 작성하고, 테스트를 돌리고, 결과를 분석해 다음 행동을 결정하는 주체가 AI가 되는 순간 — 그게 AX 개발 층위의 전환점이다. 인프라는 그 전환을 받쳐주는 기반이지, 전환 그 자체가 아니다.
★ AX와 프로젝트 관리는 비례한다
여기서 많은 팀이 간과하는 지점이 있다. 개발 환경의 AX는 결국 프로젝트 관리 능력과 비례한다.
AI가 개발 주체가 될수록, 그 AI를 조율하고 추적하고 소통시키는 관리 체계가 성패를 가른다. AI는 맥락이 명확할 때 강하다. 맥락이 흐릿하면 방향이 흔들리고, 수정 비용이 사람이 직접 짰을 때보다 커진다. 이슈가 잘 정의되어 있고, 히스토리가 남아 있고, 서비스 경계가 분명할 때 에이전틱 코딩은 제 힘을 낸다.
우리가 실제로 운영하는 방식은 이렇다. Gitea에 서버 레포지토리를 생성하고, 서비스별로 앱 레포지토리를 분리한다. Claude Code가 스스로 이슈를 등록하고, MSA 구조에서 각 서비스의 개발 담당자를 지정하며, 이슈 안에서 실제 개발을 진행한다. PR이 올라오면 이슈와 연결되어 히스토리가 남는다. 사람 팀이 협업하는 방식 그대로, AI가 그 자리를 채우는 것이다. 자세한 내용은 06편(Gitea 이슈 기반 협업)에서 다룬다.
이 관점은 같은 사이트의 『PMBOK 완독기』·『IT PM 실전 플레이북』 시리즈와도 맞닿는다. AI를 잘 쓰는 것과 팀을 잘 관리하는 것은 결국 같은 원리 위에 있다.
이 시리즈 로드맵 — 8편 구성
전체 흐름을 미리 잡아두면 각 편이 더 잘 읽힌다. 개발 서버(구형 워크스테이션·Docker)와 운영 서버(Proxmox)가 물리적으로 분리되고, Gitea가 그 둘을 잇는 구조다.
- 01편 (지금 이 글) — 에이전틱 코딩 개념 · AX 3층위 · 프로젝트 관리 논지
- 02편 — 구형 Xeon 워크스테이션에 Docker로 개발 환경 구축 (Ubuntu 24 서버, 파티션 설계
/app·/log·/data, Docker data-root/data/docker) - 03편 — Claude Code 설치·설정 · CLAUDE.md로 컨텍스트 구조화 · 에이전트 위임 패턴
- 04편 — MSA 서비스 분리 · Claude Code가 서비스 경계를 인식하게 하는 방법
- 05편 — 에이전틱 코딩 검증 · 사람의 QA 게이트 설계
- 06편 — Gitea 이슈 기반 협업 · Claude Code가 이슈를 등록·추적·진행하는 실전 흐름
- 07편 — 별도 Proxmox 운영 서버로 배포 · Gitea Runner CI/CD 파이프라인
- 08편 — 회고 · AX 도입 후 달라진 것 · 프로젝트 관리 관점 정리
🎓 이 글에서 얻어가야 할 것
- 에이전틱 코딩은 AI를 보조 도구가 아닌 개발 주체로 올리는 구조적 전환이다.
- AX는 인프라 현대화와 다르다. Docker·MSA·Proxmox는 AI가 일할 수 있는 무대를 만들어줄 뿐이다.
- AI가 개발 주체가 될수록 프로젝트 관리 체계가 더 중요해진다. 이슈·히스토리·서비스 경계가 명확해야 에이전틱 코딩이 힘을 발휘한다.
- 진입점은 거창하지 않다. Claude Code + Gitea면 시작할 수 있다.
FAQ
에이전틱 코딩과 바이브 코딩, 실무에서 어떻게 구분하나요?
바이브 코딩은 “이 함수 짜줘”처럼 즉흥적 단발 프롬프트에 AI 결과를 붙여넣는 방식이다. 에이전틱 코딩은 AI가 이슈를 받아 파일 트리를 탐색하고, 코드를 작성하고, 테스트 결과를 보고 다음 행동을 스스로 결정하는 다단계 흐름이다. 바이브 코딩은 빠른 탐색·PoC에 적합하고, 에이전틱 코딩은 일관성이 필요한 장기 프로젝트에 맞다.
AX와 DX(디지털 전환)는 어떻게 다른가요?
DX가 디지털 도구로 업무를 전산화·자동화하는 것이라면, AX는 그 위에서 AI가 의사결정과 실행의 주체로 올라서는 전환이다. DX는 시스템이 사람의 지시를 따르는 구조이고, AX는 AI가 목표를 받아 스스로 행동하는 구조다. 개발 층위에서는 “AI가 내 코드를 돕는다”에서 “AI가 코드를 짠다”로 주체가 바뀌는 것이 AX의 핵심이다.
소규모 팀도 에이전틱 코딩을 도입할 수 있나요?
오히려 소규모 팀이 체감 효과가 더 크다. 대형 조직의 복잡한 거버넌스 없이 Claude Code와 Gitea만으로 바로 시작할 수 있다. 주니크도 소수 팀으로 이 파이프라인을 운영한다. 필요한 건 비싼 GPU 서버가 아니라 코어 수가 넉넉한 서버 한 대와 명확한 이슈 관리 체계다.
왜 AX 개발이 프로젝트 관리와 연결되나요?
AI 에이전트는 맥락이 명확할 때 잘 작동한다. 이슈가 잘 정의되어 있고, 서비스 경계가 분명하고, 히스토리가 쌓여 있을 때 에이전틱 코딩의 출력 품질이 높아진다. 반대로 이슈가 모호하면 AI가 방향을 잃고 수정 비용이 커진다. PM이 팀을 잘 구조화해야 팀이 잘 돌아가듯, AI를 잘 구조화해야 에이전틱 코딩이 잘 돌아간다.
NEXT → 02편
다음 편에서는 구형 Xeon 워크스테이션 한 대에 Ubuntu 24 서버를 올리고, 파티션을 /app·/log·/data로 분리한 뒤 Docker data-root를 /data/docker로 두는 실전 세팅을 다룬다. GPU 없이, 클라우드 없이 개발 환경을 구축하는 과정이다.
에이전틱 코딩 도입을 검토 중이거나 파이프라인 구성에 대해 이야기 나누고 싶다면 guniq.co.kr/contact로 연락해 주세요.
『에이전틱 개발 파이프라인』 시리즈
→ 다음: 02. GPU 없이 구형 Xeon으로 AI 개발 서버 구축
