에이전틱 개발 파이프라인 – 08. AI-native 파이프라인 운영 회고

---

AI-native 파이프라인 운영 회고 — 결국 바뀐 건 ‘도구’가 아니었다

이 시리즈를 쓰기 시작했을 때 솔직히 말하면, ‘어떤 모델을 쓰느냐’·’어떤 명령어를 치느냐’가 핵심이라고 생각했다. 틀렸다. 회고를 정리하면서 Claude Code 도입 후기의 진짜 교훈은 하나로 수렴한다 — AI 네이티브 개발 회사가 되는 것은 도구의 문제가 아니라 프로젝트 관리의 문제다.

이 글은 시리즈 마지막 편이다. 앞선 7편에서 쌓아온 인프라(구형 서버, Docker MSA, Gitea, 에이전틱 루프)가 실제로 어떻게 작동했는지, 무엇이 기대와 달랐는지, 그리고 AI 전환 개발사를 고민하는 팀이 어디서 시작해야 하는지를 정리한다.

---

무엇이 바뀌었나 — 체감 변화 3가지

구체적인 수치를 제시하고 싶은 유혹이 있지만, 단일 팀·단일 프로젝트 데이터를 외부에 일반화하기는 어렵다. 대신 체감 변화를 솔직하게 쓴다.

1. 반복 작업의 감소 — ‘그 코드 또 써야 해?’가 줄었다

가장 먼저 느낀 변화는 보일러플레이트 작성 시간이 체감상 크게 줄었다는 것이다. 새 서비스를 추가할 때마다 반복되던 nginx 설정 초안, DB 사용자 생성 스크립트, Dockerfile 골격, 헬스체크 설정 — 이전에는 기억에서 꺼내 타이핑하거나 스니펫을 복사했다. 이제는 컨텍스트를 설명하면 Claude Code가 초안을 만들고, 나는 검토·수정에 집중한다.

중요한 건 ‘자동화’가 아니라 집중점의 이동이다. 타이핑 시간이 줄면서 설계 결정과 검증에 더 많은 주의를 쏟게 됐다. 이것이 AI 개발 생산성의 실체에 가깝다.

2. 1인이 MSA 전체를 다룬다

인증(iam), 검색(srch), API 백엔드 여러 개, 프론트엔드, 백오피스 앱 — 혼자서 이 전체를 동시에 다루는 건 예전이라면 불가능하거나 매우 느렸다. 에이전틱 코딩은 ‘서비스 A를 고치는 동안 서비스 B의 테스트를 만들어라’ 같은 병렬 작업을 가능하게 한다.

물론 한계가 있다. 컨텍스트 창에 너무 많은 서비스를 밀어 넣으면 오류가 늘어난다. 이슈 단위로 범위를 좁혀서 주는 것, 서비스 경계를 명확히 정의해두는 것이 핵심이다.

3. 개발 속도 — ‘구형 서버라 느리지 않냐’는 오해

이 질문을 가장 많이 받는다. 결론부터: 전혀 느리지 않다.

Claude Code는 Anthropic 클라우드 모델을 사용하므로 로컬 GPU가 필요 없다. 로컬 LLM 서빙(Ollama 등)을 한다면 GPU가 있어야 하지만, 우리는 그걸 하지 않는다. 개발 서버의 역할은 ‘언어 모델 추론’이 아니라 MSA 컨테이너 동시 구동이다.

Intel Xeon E5-2690 v2 듀얼 소켓 20코어, DDR3 64GB, 1TB SSD라는 사양은 오히려 유리하다. iam, srch, api 백엔드들, nginx, 백오피스 앱을 Docker 컨테이너로 동시에 띄워도 메모리 압박이 없다. 여러 대의 서버가 도는 것처럼 컨테이너들이 안정적으로 공존한다. 응답 속도가 느리다고 느껴진다면 서버 사양보다 네트워크 레이턴시나 개별 서비스 코드를 먼저 의심하라.

---

★ 핵심 결론: AX는 프로젝트 관리 능력과 비례한다

이 시리즈에서 가장 강조하고 싶은 논지다. 개발 환경의 AI 전환(AX) 수준은 결국 그 팀의 프로젝트 관리 능력과 비례한다.

처음에는 ‘좋은 프롬프트’가 성패를 가른다고 생각했다. 실제로 운영해보니 달랐다. 프롬프트는 전술이고, 관리 체계가 전략이다. 전략 없는 전술은 빠르게 헤맨다.

Gitea 이슈가 AI의 두뇌가 된다

우리가 실제로 운영하는 방식은 이렇다. Gitea에 서버 레포지토리와 서비스별 레포지토리를 생성한다. 새 기능이나 버그가 생기면 Claude Code가 스스로 Gitea 이슈를 등록하고, MSA 구조에서 어느 서비스가 담당인지 지정하며, 그 이슈 안에서 실제 작업을 진행한다. 사람 팀이 협업하듯 AI에게 소통의 형식을 부여한 것이다.

결과적으로 이슈·PR이 히스토리로 남는다. 몇 달 전에 왜 이 결정을 내렸는지, 어떤 컨텍스트에서 코드가 쓰였는지를 이슈 스레드에서 추적할 수 있다. AI가 코드를 생성했더라도 책임과 맥락이 문서화된다.

이게 없으면 어떻게 되는가? AI가 만든 코드가 왜 그 모양인지 아무도 모르는 블랙박스 코드베이스가 쌓인다. AI 개발 생산성이 높아질수록 그 위험도 함께 커진다.

AI가 주체가 될수록 사람의 관리 역량이 더 중요해진다

역설처럼 들리지만 사실이다. Claude Code가 코드를 생성하고 테스트를 쓰고 PR을 만드는 비중이 늘어날수록, 사람이 해야 하는 일이 달라진다.

이전 역할	AI-native 환경에서의 역할
코드 타이핑	설계 결정 · 아키텍처 리뷰
스니펫 검색	AI 결과물 검증 · 품질 게이트
태스크 수동 추적	이슈 구조 설계 · 오케스트레이션
개발 병목 해소	컨텍스트 경계 관리 · 서비스 담당 지정

이 변화를 받아들이지 못하는 팀은 AI를 ‘빠른 자동완성’ 수준으로만 쓴다. 관리 체계를 먼저 갖춘 팀은 1인이 MSA 전체를 다루는 경험을 한다. 같은 도구, 다른 결과다.

---

한계와 실패 — 정직하게

좋은 것만 쓰면 광고다. 실제로 부딪힌 문제를 기록한다.

1. AI의 그럴듯한 오류 (과신 위험)

Claude Code는 자신감 있게 틀린 코드를 낸다. 특히 버전에 민감한 라이브러리 API, 잘 알려지지 않은 내부 설정, 복잡한 비동기 경쟁 조건에서 오류가 잦다. 더 위험한 것은 그 코드가 ‘일단 컴파일은 된다’는 점이다 — 런타임에서 터지거나 엣지 케이스에서만 드러난다.

도입 초기에 “AI가 만들었으니 괜찮겠지”라는 안일함이 생기고, 그게 나중에 트러블슈팅 시간으로 돌아왔다. 생성된 코드를 검토 없이 머지하지 않는다는 원칙은 반드시 유지해야 한다.

2. 컨텍스트 한계와 범위 이탈

이슈 하나에 너무 많은 배경과 코드를 넣으면 모델이 핵심을 놓친다. ‘이 파일만 고쳐’라고 했는데 연관 파일까지 건드리는 범위 이탈도 생긴다. 이슈를 작게 쪼개고, 범위를 명시적으로 제한하는 훈련이 필요하다. CLAUDE.md로 컨텍스트를 고정하면 도움이 되지만 완벽하지는 않다.

3. 검증 비용은 줄지 않는다

코드 생성 속도가 빨라졌다고 테스트·검증 비용이 줄지는 않는다. 오히려 생성 속도에 비례해서 검증해야 할 양이 늘어난다. 테스트 커버리지와 리뷰 프로세스를 단단히 해두지 않으면 기술 부채가 빠르게 쌓인다. 보안 검토 역시 AI에게 위임할 수 없다 — AI가 생성한 설정 파일에 과도한 권한이 들어가거나 시크릿이 하드코딩될 위험은 항상 존재한다.

4. 인프라는 무대일 뿐, AX 자체가 아니다

Proxmox 운영 서버와 MSA 구조를 갖췄다고 AI 전환이 완성되는 게 아니다. 인프라는 빠른 피드백 루프를 가능하게 하는 무대다. 무대를 잘 갖춰도 팀의 관리 체계가 없으면 공연은 없다. 인프라 구축에 시간을 쏟으면서 정작 이슈 체계와 검증 프로세스를 미루는 실수를 경계하라.

---

도입 판단 체크리스트

AI-native 개발 파이프라인 도입을 고민하는 팀을 위한 질문 목록이다. ‘예’가 많을수록 준비가 됐다는 신호다.

1. 이슈 트래킹 도구를 실제로 쓰고 있는가? (GitHub, Gitea, Jira 무관 — 없으면 AI와의 협업이 블랙박스가 된다)
2. PR 리뷰 프로세스가 있는가? (AI 생성 코드를 누가, 어떤 기준으로 검토할지)
3. 서비스 경계가 문서화되어 있는가? (모놀리스라면 먼저 모듈 경계를 명확히)
4. 팀 내 오케스트레이터 역할을 맡을 사람이 있는가? (AI를 조율·검증하는 사람 — 이 역할이 핵심이다)
5. 테스트 커버리지가 어느 정도인가? (생성 속도가 빠를수록 테스트 안전망이 더 중요하다)
6. API 비용 모니터링 방법이 있는가? (에이전틱 루프는 토큰을 많이 쓴다 — 예산 통제 필수)

절반 이상이 ‘아니오’라면, 도구 도입 전에 프로세스를 먼저 다듬는 것을 권한다.

---

AI-native 개발환경·파이프라인 구축, 주니크에 문의하세요

이 시리즈에서 다룬 파이프라인 — Claude Code 에이전틱 코딩, Gitea 이슈 기반 관리 체계, Docker MSA 개발환경, Proxmox 운영 서버 배포 — 은 주니크가 실제로 운영하는 방식이다. 동일한 방식으로 팀의 AI 개발 환경을 구축하거나 전환하는 작업을 지원한다.

---

자주 묻는 질문 (FAQ)

도입까지 얼마나 걸리나요?

이슈 트래킹과 PR 리뷰 프로세스가 이미 갖춰진 팀이라면 Claude Code 설치부터 에이전틱 루프 적용까지 2~4주 안에 체감 변화를 경험할 수 있다. 프로세스 자체가 없는 팀은 관리 체계 정비가 선행되어야 한다 — 그 기간이 별도로 필요하다.

팀 규모가 작아도 효과가 있나요?

오히려 1~3인 소규모 팀에서 효과가 크다. 한 사람이 MSA 여러 서비스를 병렬로 다뤄야 할 때, 에이전틱 코딩은 ‘한 명이 여러 서비스를 동시에 진행하는 감각’을 준다. 단, 오케스트레이터 역할을 맡을 사람이 적어도 한 명은 반드시 필요하다.

보안이 걱정됩니다. 코드가 외부로 나가는 건가요?

Claude Code는 Anthropic API를 통해 코드 컨텍스트를 전송한다. Anthropic의 데이터 처리 정책을 먼저 확인하고, 시크릿·자격증명은 환경변수로 분리해 코드베이스에 포함되지 않게 관리하는 것이 기본이다. AI가 생성한 파일에 하드코딩 시크릿이 들어가지 않는지 배포 전 반드시 확인하라. 내부 코드 노출이 엄격히 제한된 환경이라면 로컬 LLM 옵션도 있지만, 현재 에이전틱 코딩 품질 면에서는 클라우드 모델이 앞선다.

Claude Code 비용이 많이 드나요?

에이전틱 루프는 일반 대화형 사용보다 토큰을 많이 소비한다. 작업 범위를 이슈 단위로 좁히고, 불필요한 컨텍스트를 반복 주입하지 않는 것이 비용 관리의 핵심이다. 대량·반복 작업은 저가 모델(Haiku)에, 설계·검증은 고성능 모델에 배분하면 비용을 효과적으로 조절할 수 있다. 실제 비용은 작업 패턴마다 달라 일반화하기 어려우므로, Anthropic 공식 가격표 기준으로 자체 예산을 추정해보기를 권한다.

---

이 시리즈를 처음부터 따라온 독자라면 지금쯤 자신의 개발 환경에서 한두 가지는 바꿔보고 싶은 것이 생겼을 것이다. 완벽한 파이프라인부터 갖출 필요는 없다. 반복되는 작업 하나를 CLAUDE.md 규칙 하나로 줄이는 것부터 시작하면 된다. 그다음 단계로 Gitea 이슈 체계를 붙이고, AI가 히스토리를 남기게 만들면 — 그게 AI-native 개발의 실체다. → guniq.co.kr/contact

---

『에이전틱 개발 파이프라인』 시리즈
← 이전: 07. Proxmox VM 자동 배포 파이프라인