Vibe coding과 agentic engineering은 어디서 갈릴까 2026 – 실무 적용 체크표

Posted on by

AI 코딩 에이전트에게 일을 맡길 때 진짜 질문은 얼마나 빨리 만들까가 아니라 누가 검증 책임을 지는가다.

그럼 같은 Claude Code 작업도 언제는 vibe coding이고, 언제는 agentic engineering일까?

짧은 답은 이렇다.

Vibe coding은 결과물이 그럴듯하게 동작하면 코드 이해와 운영 책임을 뒤로 미루는 쪽에 가깝다.

Agentic engineering은 AI가 코드를 쓰더라도 사람이 요구사항, 권한, 테스트, 리뷰, 배포, 복구 책임을 끝까지 붙잡는 쪽에 가깝다.

둘을 가르는 선은 AI를 썼는가가 아니다.

코드를 사람이 직접 몇 줄 썼는지도 아니다.

차이는 검증 루프다.

더 정확히는 실패했을 때 누가 어디까지 설명하고 되돌릴 수 있느냐다.

2026년 5월 7일 기준으로 이 질문이 애매해진 이유는 단순하다.

코딩 에이전트가 예전보다 꽤 잘하기 때문이다.

API 엔드포인트를 만들고, SQL 쿼리를 붙이고, 테스트를 추가하고, 문서를 쓰는 작업은 이제 꽤 자연스럽게 이어진다.

문제는 여기서부터다.

잘하니까 덜 보게 된다.

덜 보니까 더 믿게 된다.

더 믿으니까 어느 순간 프로덕션 권한까지 살짝 열고 싶어진다.

개발팀 입장에서는 이게 제일 위험한 유혹이다.

AI가 못해서 생기는 사고는 눈에 잘 보인다.

AI가 잘해서 생기는 과신은 조용히 쌓인다.

이 글은 vibe coding은 나쁘고 agentic engineering은 좋다 같은 단순한 편 가르기가 아니다.

TECHTAEK 관점에서는 둘 다 쓸 수 있다.

다만 작업의 위험도, 검증 가능성, 리뷰 비용에 따라 다른 모드로 다뤄야 한다.

먼저 나눌 기준

Vibe coding과 agentic engineering의 차이는 말투보다 운영 방식에서 갈린다.

프롬프트를 대충 썼다고 무조건 vibe coding은 아니다.

반대로 에이전트가 계획서를 만들었다고 바로 agentic engineering도 아니다.

실무에서 먼저 볼 기준은 네 가지다.

  • 내가 이 코드를 설명할 수 있는가.
  • 자동 테스트나 입출력 검증으로 결과를 확인할 수 있는가.
  • 실패했을 때 고객 데이터, 결제, 권한, 보안에 피해가 가는가.
  • 문제가 났을 때 되돌릴 경로가 준비되어 있는가.

이 네 질문 중 하나라도 답이 흐리면, 작업은 아직 agentic engineering이 아니다.

그냥 조금 차려입은 vibe coding일 수 있다.

겉으로는 계획표가 있고 커밋도 예쁘고 README도 멀쩡한데, 운영 책임은 비어 있는 상태다.

이게 2026년에 더 헷갈린다.

Simon Willison은 2026년 5월 6일 글에서 예전에는 100개 커밋, 좋은 README, 테스트가 있으면 정성이 들어간 프로젝트로 보기 쉬웠지만, 이제는 그런 저장소도 아주 빠르게 만들 수 있다고 설명했다.

그래서 프로젝트 평가 기준이 겉모습에서 실제로 누가 꾸준히 써봤는가로 옮겨간다.

개인 도구라면 만든 사람이 2주 동안 매일 써봤는지가 큰 신호다.

팀 도구라면 여러 사람이 실제 업무에서 써보고, 장애와 수정 루프를 거쳤는지가 더 중요하다.

코드가 빨리 생기는 시대에는 생성물보다 검증 이력이 더 비싸다.

여기서 글의 방향이 정해진다.

vibe coding과 agentic engineering의 경계는 철학 논쟁이 아니라 체크리스트 문제다.

실무 비교표

아래 표는 도구 이름이 아니라 작업 모드를 나누기 위한 표다.

Claude Code, Codex, GitHub Copilot, Cursor, Gemini CLI 어느 쪽을 쓰든 기준은 비슷하게 적용된다.

비교축 Vibe coding Agentic engineering 실무 판단
출발점 만들고 싶은 결과를 자연어로 던진다 문제, 제약, 성공 기준을 먼저 적는다 목표가 한 문장뿐이면 위험도를 낮게 잡는다
코드 이해 코드를 거의 읽지 않거나 나중에 본다 주요 흐름과 위험 지점은 사람이 설명한다 설명 못 하는 코드는 핵심 경로에 넣지 않는다
작업 범위 화면, 데모, 개인 자동화에 강하다 멀티 파일 변경, 테스트, 배포 전 검증에 맞다 범위가 넓을수록 계획과 리뷰를 분리한다
검증 방식 눈으로 눌러보고 되면 넘어간다 테스트, 로그, 스크린샷, 샘플 데이터로 확인한다 검증할 방법이 없으면 배포하지 않는다
실패 비용 나 혼자 불편하거나 다시 만들면 된다 사용자, 데이터, 비용, 평판에 영향이 있다 실패 비용이 큰 작업은 vibe 모드 금지다
권한 로컬 파일, 임시 프로젝트 중심 repo, CI, MCP, 배포, 데이터 접근을 통제한다 권한이 늘면 승인 게이트도 늘린다
리뷰 결과물 중심으로 본다 diff, 테스트, 의도, 롤백을 같이 본다 리뷰할 시간이 없으면 작업 크기를 줄인다
비용 토큰 비용보다 속도 체감이 먼저다 토큰, Actions minutes, 리뷰 시간을 같이 본다 자동 리뷰도 인프라 비용을 먹는다
적합한 사람 빠른 실험자, 비개발자, 사이드 프로젝트 개발자, 리드, 운영 책임자 비개발자는 민감 영역을 건드리면 안 된다
완료 기준 작동한다 작동하고, 설명되고, 되돌릴 수 있다 이 세 단어가 운영의 최소선이다

표만 보면 agentic engineering이 더 멋져 보인다.

하지만 모든 작업에 agentic workflow를 붙이면 오히려 느려진다.

작은 오타 수정에 계획, 서브에이전트, 보안 리뷰, 회고까지 붙이면 생산성이 아니라 의식행사가 된다.

의식행사는 가끔 필요하지만 매일 하면 피곤하다.

그래서 기준은 항상 더 엄격하게가 아니다.

기준은 실패 비용만큼 엄격하게다.

2026년에 경계가 흐려진 이유

예전에는 구분이 쉬웠다.

코드를 안 보면 vibe coding, 코드를 읽고 책임지면 일반적인 AI-assisted programming이었다.

그런데 2026년에는 에이전트가 직접 파일을 읽고, 명령을 실행하고, 테스트를 돌리고, PR까지 만들 수 있다.

Claude Code 공식 문서는 Claude Code를 단순 챗봇이 아니라 파일 읽기, 명령 실행, 수정, 문제 해결을 수행하는 agentic coding environment로 설명한다.

GitHub도 2026년 3월 5일 Copilot code review를 agentic tool-calling architecture로 전환했다고 발표했다.

이제 AI는 코드를 제안하는 수준에서 멈추지 않는다.

레포지토리 구조를 찾고, 관련 파일을 읽고, 테스트를 실행하고, 리뷰 코멘트를 만들고, 때로는 자체 세션 로그까지 남긴다.

그러면 사람의 감각이 바뀐다.

예전에는 AI가 만든 코드를 내가 복붙한 코드로 느꼈다.

이제는 AI가 만든 작은 서비스나 내부 모듈을 다른 팀이 준 컴포넌트처럼 대하기 시작한다.

문서가 있고 테스트가 있고 샘플 입력이 통과하면 일단 써도 될 것처럼 보인다.

하지만 사람 팀과 AI 에이전트는 한 가지가 다르다.

사람 팀에는 평판과 책임이 있다.

AI 에이전트에는 실행 기록과 결과물은 있어도, 전문적 책임 주체는 없다.

그래서 에이전트 결과를 블랙박스처럼 쓰려면 책임을 대신할 구조가 필요하다.

그 구조가 테스트, 로그, 권한 분리, 리뷰 게이트, 롤백이다.

말은 조금 딱딱하지만, 이걸 빼면 운영이 바로 얇아진다.

얇은 운영은 속도가 붙을수록 더 빨리 찢어진다.

결정 체크표 1: 이 작업은 어디까지 맡길 수 있나

아래 체크표는 AI 코딩 작업을 시작하기 전에 3분 안에 보는 표다.

점수표처럼 엄밀하게 쓰기보다, 빨간불을 찾는 용도로 쓰면 된다.

질문 초록불 노란불 빨간불
실패하면 누가 피해를 보나 나 혼자 내부 사용자 몇 명 고객, 결제, 개인정보, 운영 데이터
코드 위치는 어디인가 leaf node 중간 계층 auth, billing, migration, 권한, 데이터 모델
검증 기준이 있나 테스트와 샘플 출력 있음 수동 확인 가능 기대 결과가 말로만 있음
롤백할 수 있나 revert와 백업 있음 일부 되돌릴 수 있음 한번 실행하면 복구가 어려움
diff 크기는 어떤가 1-3파일 4-10파일 넓은 폴더 전체 변경
사람이 설명할 수 있나 흐름 설명 가능 일부만 이해 설명은 AI에게 다시 물어봐야 함
비용을 예측했나 토큰/CI/리뷰 시간 예상 대략만 예상 비용 계정이 열려 있음
리뷰자는 누구인가 소유자 지정 나중에 정함 리뷰자 없음

초록불이 대부분이면 vibe coding에 가까운 빠른 흐름을 허용해도 된다.

예를 들어 개인용 스크립트, 내부 노트 정리 도구, UI 목업, throwaway demo는 속도가 더 중요할 수 있다.

노란불이 섞이면 agentic engineering으로 올려야 한다.

이때부터는 계획, 테스트, 변경 범위 제한, 리뷰 기준이 필요하다.

빨간불이 하나라도 있으면 자동 실행보다 사람 설계가 먼저다.

특히 데이터베이스 migration, 결제 로직, 인증/인가, 프로덕션 환경변수, 운영 배치 작업은 일단 에이전트에게 시켜보고 보자 모드로 가면 안 된다.

이런 작업은 AI가 못해서 위험한 게 아니다.

AI가 너무 자신 있게 진행해서 위험하다.

결정 체크표 2: vibe coding으로 둬도 되는 경우

Vibe coding도 자리가 있다.

오히려 이 모드를 무조건 부끄러워하면 실험 속도가 죽는다.

아래 조건에 가까우면 vibe coding으로 빠르게 돌려도 된다.

  • 실패해도 나만 불편하다.
  • 결과물을 버리고 다시 만들어도 된다.
  • 데이터가 샘플 또는 공개 데이터다.
  • API 키, 고객 정보, 결제 권한이 없다.
  • 목적이 학습, 탐색, 화면 스케치, 아이디어 확인이다.
  • 결과물을 1-2주 직접 써보며 고칠 계획이 있다.
  • 코드베이스의 핵심 아키텍처를 건드리지 않는다.
  • 자동 테스트보다 수동 체험이 더 빠르고 충분하다.
  • 배포 대상이 프로덕션이 아니라 로컬 또는 임시 URL이다.
  • 비용이 한 세션 안에서 닫힌다.

예를 들어 블로그 초안 정리 스크립트, 개인 대시보드 목업, CSV 변환 도구, 임시 크롤러, 작은 Obsidian 정리 도구는 vibe coding이 어울릴 수 있다.

다만 여기에도 최소선은 있다.

생성된 결과물을 바로 오래 쓰려면 README보다 사용 로그를 남기는 편이 낫다.

내가 지난 2주 동안 실제로 매일 썼다는 증거는 생각보다 강하다.

그 기간 동안 깨진 입력, 느린 구간, 이상한 출력이 드러난다.

AI가 만든 코드는 처음 10분보다 첫 10일이 더 많은 걸 말해준다.

결정 체크표 3: agentic engineering으로 올려야 하는 경우

다음 조건이면 vibe coding이 아니라 agentic engineering으로 봐야 한다.

여기서는 AI가 코드를 잘 쓰는지보다 사람이 운영판을 깔았는지가 중요하다.

  • 고객이 쓰는 기능이다.
  • 내부 직원 여러 명의 업무 흐름에 들어간다.
  • 데이터베이스 schema, migration, permission을 건드린다.
  • 장애가 나면 비용, 신뢰, 법무 리스크가 생긴다.
  • 변경 파일이 넓고 기존 설계와 충돌할 수 있다.
  • PR 리뷰자가 전체 diff를 읽기 어렵다.
  • AI가 만든 테스트가 실제 요구사항을 충분히 대표하는지 의심된다.
  • 배포 후 모니터링과 롤백 경로가 필요하다.
  • 같은 패턴을 여러 레포에 반복 적용한다.
  • 팀원 교육이나 온보딩에 영향을 준다.

이 경우에는 작업을 작게 쪼개야 한다.

에이전트에게 기능 전체 만들어줘라고 던지는 대신, 먼저 탐색과 계획을 시킨다.

Claude Code 공식 베스트프랙티스도 Explore first, then plan, then code 흐름을 권한다.

처음에는 파일을 읽고 설계를 설명하게 한다.

그다음 사람이 계획을 고친다.

그 뒤 구현을 맡긴다.

마지막으로 테스트, 리뷰, 로그, 롤백 기준을 확인한다.

여기서 중요한 건 순서다.

코드가 나온 뒤에 계획을 끼워 맞추면 이미 늦다.

계획을 먼저 세워야 리뷰자가 무엇을 봐야 하는지 안다.

비용과 시간은 어디서 새나

AI 코딩의 비용은 모델 요금만이 아니다.

실무에서는 네 가지 비용이 같이 움직인다.

비용 항목 보이는 비용 숨어 있는 비용 줄이는 방법
모델 토큰 입력/출력 토큰 재시도, 장기 세션, 불필요한 파일 읽기 작업 범위와 컨텍스트를 좁힌다
CI/러너 테스트 실행 시간 agentic review의 Actions minutes PR 크기와 리뷰 빈도를 정한다
리뷰 시간 사람이 diff 읽는 시간 AI가 만든 그럴듯한 코드의 검토 피로 diff를 작게 자르고 리뷰 기준을 미리 쓴다
운영 복구 장애 대응 시간 롤백 불가, 로그 부족, 책임자 불명확 배포 전 rollback runbook을 둔다

GitHub는 2026년 4월 27일 Copilot code review가 2026년 6월 1일부터 AI Credits와 GitHub Actions minutes 양쪽으로 비용 처리될 수 있다고 안내했다.

이건 중요한 신호다.

자동 리뷰도 공짜 공기가 아니다.

레포 컨텍스트를 읽고 agentic review를 돌리는 순간, AI 비용과 CI 비용이 함께 붙는다.

Sonar의 2026년 State of Code Developer Survey도 같은 방향을 보여준다.

1,100명 이상 전문 개발자 설문에서 현재 커밋 코드의 42%가 AI 생성 또는 AI 보조 코드라고 보고됐고, 2027년에는 65%까지 늘어날 것으로 예상됐다.

그런데 개발자의 96%는 AI 생성 코드를 완전히 신뢰하지 않는다고 답했고, 항상 검증한다고 답한 비율은 48%에 그쳤다.

또 38%는 AI 코드를 리뷰하는 일이 동료가 쓴 코드를 리뷰하는 것보다 더 힘들다고 답했다.

이 숫자는 꽤 실무적이다.

AI가 코드를 많이 만들수록 병목이 코드 작성에서 검증으로 이동한다는 뜻이기 때문이다.

팀에서 AI 덕분에 구현이 빨라졌는데 왜 리뷰가 더 피곤하지라는 느낌이 든다면, 착각이 아닐 수 있다.

병목이 다른 곳으로 옮겨갔을 뿐이다.

리뷰 부담을 줄이는 작업 쪼개기

Agentic engineering을 한다고 해서 PR 하나에 모든 걸 몰아넣으면 안 된다.

AI는 큰 diff를 만들기 쉽고, 사람은 큰 diff를 읽기 어렵다.

그래서 작업을 리뷰 단위로 자르는 게 먼저다.

제가 실무 글감을 만들 때 쓰는 기준은 이렇다.

작업 단위 에이전트에게 맡길 것 사람이 볼 것 중단 기준
탐색 관련 파일, 호출 경로, 테스트 위치 찾기 에이전트가 놓친 소유자와 위험 영역 핵심 파일을 못 찾으면 중단
계획 변경 파일 목록, 단계, 테스트 전략 작성 요구사항 누락, 과한 설계, 권한 접근 계획이 1페이지를 넘으면 쪼개기
테스트 실패하는 테스트, 샘플 입력, fixture 작성 테스트가 요구사항을 대표하는지 mock만 늘어나면 중단
구현 작은 단위 diff 작성 단순성, 기존 패턴, 예외 처리 기존 유틸 재구현하면 중단
검증 테스트 실행, lint, 스크린샷, 로그 요약 출력 해석과 배포 판단 실패 원인을 추측하면 중단
문서화 변경 이유, 사용법, 롤백 메모 운영자가 이해할 수 있는지 README만 예쁘고 runbook 없으면 중단

이렇게 쪼개면 에이전트가 느려질 것 같지만, 실제로는 리뷰가 빨라진다.

리뷰자가 이 PR은 무엇을 검증하면 되는가를 바로 알기 때문이다.

AI가 만든 코드의 진짜 문제는 코드가 길다는 것만이 아니다.

의도가 코드 사이에 숨어버리는 것이다.

그래서 의도를 계획과 테스트에 먼저 고정해야 한다.

코드는 그다음이다.

권한은 기술 문제가 아니라 운영 문제다

Claude Code auto mode 글에서 Anthropic은 Claude Code 사용자가 permission prompt의 93%를 승인한다고 설명했다.

이 수치는 approval fatigue를 이해하는 데 도움이 된다.

승인창이 너무 자주 뜨면 사람은 꼼꼼히 보지 않는다.

그냥 누른다.

이때 수동 승인은 안전장치처럼 보이지만 실제로는 피로 장치가 될 수 있다.

그래서 권한 설계는 프롬프트보다 낮은 층에서 해야 한다.

민감 파일을 못 건드리게 하고, 프로덕션 DB 접근을 분리하고, MCP 서버 권한을 읽기와 쓰기로 나누고, 자동 실행 가능한 명령을 제한해야 한다.

GitHub가 Copilot coding agent 커밋에 agent session logs URL을 연결한다고 발표한 것도 같은 맥락이다.

누가 무엇을 시켰고, 에이전트가 왜 바꿨는지 나중에 추적할 수 있어야 한다.

에이전트 시대의 리뷰는 diff만 보는 일이 아니다.

요청, 계획, 실행 로그, 테스트 결과, 커밋 출처를 같이 보는 일이다.

권한이 넓은 작업일수록 이 기록이 중요하다.

작업이 끝난 뒤 대충 잘 된 것 같은데요는 운영 문장이 아니다.

운영 문장은 무엇을 했고, 무엇을 확인했고, 무엇은 확인하지 못했는가다.

흔한 실수

실무에서 가장 자주 보이는 실수는 AI를 너무 믿는 것보다, 어디서 믿었는지 모르는 것이다.

믿음도 로그가 있어야 한다.

1. README와 테스트를 품질 증거로 착각한다

AI는 README를 잘 쓴다.

테스트도 꽤 잘 만든다.

하지만 README와 테스트가 있다는 사실은 품질의 시작이지 끝이 아니다.

Simon Willison이 지적한 것처럼 2026년에는 커밋, README, 테스트가 그럴듯한 저장소를 매우 빠르게 만들 수 있다.

그래서 봐야 할 것은 테스트가 있다가 아니라 그 테스트가 실제 사용을 대표하는가다.

개인 도구라면 2주 실사용 로그가 더 강한 증거일 수 있다.

팀 도구라면 실제 업무 사용 사례, 장애 대응 기록, 롤백 경험이 더 중요하다.

2. 에이전트가 만든 테스트를 에이전트 구현의 면죄부로 쓴다

AI에게 테스트와 구현을 모두 맡기면 편하다.

하지만 같은 에이전트가 만든 테스트는 같은 오해를 공유할 수 있다.

요구사항을 잘못 이해한 상태에서 테스트와 구현을 동시에 맞추면, 아주 깔끔하게 틀린 코드가 나온다.

그래서 중요한 작업에서는 테스트 작성과 구현을 분리하는 편이 낫다.

먼저 사람이 입력/출력 예시와 실패 조건을 고정한다.

그다음 에이전트가 테스트를 쓰게 하고, 구현 단계에서는 테스트를 마음대로 바꾸지 못하게 한다.

3. 큰 PR을 리뷰하면서 AI가 했으니 괜찮겠지라고 넘긴다

AI가 만든 큰 diff는 리뷰하기 어렵다.

문법 오류보다 더 무서운 것은 정상 작동처럼 보이는 설계 퇴행이다.

기존 유틸을 다시 만들거나, 에러 처리를 다르게 하거나, 추상화를 한 겹 더 얹어버리는 식이다.

이건 테스트가 모두 통과해도 남을 수 있다.

큰 PR은 에이전트 문제가 아니라 리뷰 설계 문제로 봐야 한다.

작게 자르고, 각 PR의 검증 질문을 하나씩만 둔다.

4. auto approve를 생산성 기능으로만 본다

자동 승인은 편하다.

하지만 권한 없는 편함은 운영 부채가 된다.

특히 rm, migration, cloud CLI, secret 접근, 배포 명령, 외부 API 쓰기 작업은 자동 승인 대상에서 빼야 한다.

권한이 필요한 작업은 사람이 더 똑똑해져서 안전해지는 게 아니다.

시스템이 덜 열려 있어야 안전해진다.

사람 컨디션을 보안 경계로 쓰면 언젠가 진다.

5. 학습이 필요한 작업을 전부 에이전트에게 넘긴다

주니어 개발자에게 AI 코딩 에이전트는 강력한 학습 도구다.

하지만 모든 구현을 에이전트가 하고 사람은 리뷰만 하면, 코드로 사고하는 근육이 약해질 수 있다.

이건 AI 쓰지 마라가 아니다.

학습 목적 작업에서는 에이전트에게 답을 만들게 하기보다 질문하게 만드는 편이 낫다.

예를 들어 이 함수 고쳐줘보다 이 함수가 왜 이렇게 설계됐는지 설명하고, 내가 고칠 수 있게 3단계 힌트를 줘가 더 낫다.

팀의 장기 실력까지 생각하면, agentic workflow도 교육 모드와 생산 모드를 나눠야 한다.

6. 비용을 모델 가격표로만 계산한다

AI 코딩 비용을 월 구독료나 API 토큰만 보면 부족하다.

리뷰 시간, CI 실행, agentic code review, 실패한 시도, 컨텍스트 낭비, 배포 복구가 같이 붙는다.

GitHub Copilot code review처럼 agentic review가 Actions minutes까지 쓰는 구조라면 비용 계산은 더 복잡해진다.

팀에서 도입할 때는 한 달에 얼마보다 한 기능당 검증 비용을 봐야 한다.

이게 안 보이면 생산성이 오른 것처럼 보이는데 계정과 리뷰 큐가 같이 타기 시작한다.

누구에게 맞나

이 글의 기준은 AI 도구를 많이 쓰는 개발자에게 특히 잘 맞다.

하지만 개발자만을 위한 이야기는 아니다.

AI로 작은 도구를 만드는 PM, 디자이너, 마케터, 데이터 담당자도 같은 기준을 쓸 수 있다.

다만 역할에 따라 허용선은 다르게 잡아야 한다.

사용자 맞는 사용 조심할 사용 금지에 가까운 사용
1인 개발자 개인 도구, 실험, UI 목업 장기 운영할 내부 서비스 고객 데이터 자동 처리
팀 리드 작업 분해, 테스트 설계, 리뷰 보조 큰 PR 자동 생성 소유자 없는 agentic workflow
주니어 개발자 코드 설명, 학습 보조, 작은 수정 구현 전체 위임 이해 못 한 코드 merge
PM/기획자 프로토타입, 요구사항 구체화 내부 도구 배포 권한/결제/DB 작업
운영 담당자 로그 분석, runbook 초안 자동 복구 스크립트 프로덕션 명령 자동 실행
보안 담당자 정책 점검, 위험 목록화 자동 수정 PR 승인 없는 권한 변경

가장 좋은 사용은 AI가 초안을 만들고 사람이 책임을 닫는 방식이다.

가장 위험한 사용은 AI가 만들고 AI가 검증하고 사람은 속도만 보는 방식이다.

중간에 사람이 있어도, 사람이 무엇을 봐야 하는지 모르면 책임이 닫히지 않는다.

그래서 agentic engineering은 사람을 빼는 기술이 아니라 사람의 판단을 어디에 써야 하는지 다시 배치하는 기술에 가깝다.

좋은 개발자는 더 빨라질 수 있다.

하지만 좋은 개발자가 되기 전 과정을 건너뛰게 해주지는 않는다.

이 차이를 헷갈리면 팀이 아주 효율적으로 혼란스러워진다.

효율적인 혼란, 이름만 들으면 스타트업 OKR 같지만 실제로 겪으면 꽤 매운맛이다.

agentic workflow를 쓰지 말아야 할 때

Agentic workflow는 멋져 보이지만, 안 쓰는 편이 나은 경우가 분명히 있다.

아래 조건에서는 에이전트를 구현자로 쓰기보다 조사자나 리뷰 보조자로 낮추는 게 낫다.

  • 요구사항이 아직 모호하다.
  • 성공 기준을 테스트나 샘플 출력으로 표현할 수 없다.
  • 작업자가 해당 코드의 기본 구조를 이해하지 못한다.
  • 변경이 핵심 아키텍처를 건드린다.
  • 장애 시 롤백보다 수동 복구가 먼저 필요하다.
  • 프로덕션 데이터베이스, 결제, 인증, 권한 로직이 포함된다.
  • 팀이 AI 생성 코드 표시와 리뷰 정책을 정하지 않았다.
  • 비용 상한, 토큰 예산, CI 예산이 없다.
  • 학습 목적의 작업인데 에이전트가 전부 대신하게 된다.
  • 빨리 해야 해서 리뷰는 나중에라는 말이 나온다.

이 목록에서 마지막 문장이 제일 중요하다.

리뷰는 나중에는 거의 항상 이해도 나중에와 같이 온다.

이해를 나중으로 미룬 코드는 시간이 지나면 더 비싸진다.

AI가 만든 코드라고 해서 그 원칙이 사라지지 않는다.

오히려 코드가 더 빨리 쌓이기 때문에 더 세게 적용된다.

실무 적용 6단계

팀에서 바로 적용하려면 복잡한 방법론보다 6단계면 충분하다.

각 단계는 한 문서나 PR 템플릿에 체크박스로 넣어도 된다.

1. 작업을 위험 등급으로 나눈다

먼저 작업을 낮음, 중간, 높음으로 나눈다.

낮음은 개인 도구, 화면 목업, 문서 초안, 샘플 코드다.

중간은 내부 자동화, 테스트 추가, 작은 API 변경, 운영 스크립트 초안이다.

높음은 고객 데이터, 결제, 인증, 권한, migration, 배포 자동화다.

낮음은 빠른 vibe coding을 허용해도 된다.

중간은 agentic engineering의 최소 절차를 붙인다.

높음은 사람이 설계하고 에이전트는 제한된 하위 작업만 맡긴다.

2. 에이전트에게 먼저 탐색만 시킨다

처음부터 코딩시키지 않는다.

먼저 관련 파일, 기존 패턴, 테스트 위치, 위험 파일을 찾게 한다.

이 단계에서는 write 권한이 필요 없다.

탐색 결과가 틀리면 구현도 틀릴 가능성이 높다.

그래서 탐색 요약을 사람이 먼저 고친다.

이 단계가 귀찮으면 보통 뒤에서 더 귀찮아진다.

코딩계의 무이자 할부 같은 거다.

3. 성공 기준을 사람이 닫는다

성공 기준은 에이전트가 대충 추측하게 두면 안 된다.

입력 예시, 출력 예시, 실패 조건, 금지 조건을 사람이 적는다.

예를 들어 CSV 변환기를 만들어줘보다 아래가 낫다.

  • UTF-8 CSV를 읽는다.
  • 빈 금액은 0으로 처리하지 않고 에러로 표시한다.
  • 날짜 형식은 YYYY-MM-DD만 허용한다.
  • 결과 JSON은 필드 순서를 유지한다.
  • 샘플 파일 3개를 통과해야 한다.

이 정도 기준이 있으면 에이전트는 훨씬 덜 헤맨다.

사람도 리뷰할 때 무엇을 봐야 하는지 알 수 있다.

4. 테스트와 구현을 분리한다

중요한 작업에서는 테스트를 먼저 만든다.

그다음 구현을 맡긴다.

그리고 구현 중에는 테스트를 마음대로 바꾸지 못하게 한다.

테스트가 틀렸다면 사람이 수정한다.

에이전트가 테스트를 계속 고치며 통과시키는 흐름은 조심해야 한다.

테스트는 goalpost다.

goalpost를 에이전트가 들고 뛰면 축구가 아니라 산책이다.

5. 리뷰는 코드가 아니라 질문으로 시작한다

PR 리뷰를 열 때 먼저 질문을 고정한다.

  • 이 변경이 기존 설계를 따르는가.
  • 새 유틸을 만들지 않고 기존 유틸을 재사용했는가.
  • 실패 경로와 예외 처리가 있는가.
  • 로그가 운영자가 읽을 수 있는 수준인가.
  • 보안과 권한 경계가 넓어지지 않았는가.
  • 테스트가 실제 요구사항을 대표하는가.
  • 롤백 경로가 있는가.

이 질문 없이 diff만 보면 사람이 길을 잃는다.

AI가 만든 diff는 특히 그렇다.

코드는 많고 설명은 그럴듯해서, 리뷰자가 피곤해질수록 통과시키고 싶어진다.

그래서 리뷰 질문이 먼저 있어야 한다.

6. 배포 후 사용 증거를 남긴다

Agentic engineering의 완료는 merge가 아니다.

실사용 증거가 있어야 한다.

개인 도구라면 1-2주 사용 로그를 남긴다.

내부 도구라면 사용자 2-3명의 실제 업무 피드백을 남긴다.

프로덕션 기능이라면 에러율, latency, rollback 여부, 문의 패턴을 본다.

이 기록이 쌓이면 다음번에는 AI에게 더 좋은 컨텍스트를 줄 수 있다.

에이전트는 과거 실수를 자동으로 배우지 않는다.

하지만 팀은 배울 수 있다.

그 배움을 CLAUDE.md, AGENTS.md, PR 템플릿, 테스트 fixture, runbook으로 내려야 한다.

그때부터 agentic engineering이 팀 자산이 된다.

한 장 체크리스트

아래는 저장해두고 작업 시작 전에 보는 버전이다.

너무 길게 느껴지면 상위 10개만 써도 된다.

  • 이 작업의 실패 피해자는 누구인가.
  • 고객 데이터나 결제, 인증, 권한이 포함되는가.
  • 변경이 leaf node인가, core module인가.
  • 사람이 변경 이유를 설명할 수 있는가.
  • 에이전트가 탐색한 파일 목록이 맞는가.
  • 성공 기준이 입력/출력으로 적혀 있는가.
  • 실패 조건과 금지 조건이 적혀 있는가.
  • 테스트와 구현이 분리되어 있는가.
  • 에이전트가 테스트를 임의로 수정하지 못하게 했는가.
  • diff가 리뷰 가능한 크기인가.
  • 기존 패턴과 유틸을 재사용했는가.
  • 새 의존성을 추가했다면 이유가 있는가.
  • 권한이나 네트워크 접근이 넓어졌는가.
  • MCP 서버나 외부 API 접근이 필요한가.
  • 민감 파일, .env, key, production config 접근을 막았는가.
  • CI 비용과 Actions minutes를 예상했는가.
  • 리뷰자가 누구인지 정했는가.
  • 배포 전 rollback 방법이 있는가.
  • 배포 후 확인할 로그와 지표가 있는가.
  • 1-2주 실사용 기록을 남길 곳이 있는가.

이 체크리스트를 통과하면 agentic engineering에 가까워진다.

통과하지 못하면 실패가 아니라 분류가 바뀐 것이다.

그 작업은 아직 vibe coding으로 남겨두거나, 더 작게 잘라야 한다.

분류를 잘하는 팀은 AI를 더 많이 쓸 수 있다.

분류를 못 하는 팀은 AI를 많이 쓸수록 뒤처리 일이 늘어난다.

FAQ

Q1. Vibe coding은 프로덕션에서 절대 쓰면 안 되나?

절대 금지는 아니다.

하지만 프로덕션에서 쓸 거면 vibe coding이라는 말의 원래 느슨함을 그대로 가져가면 안 된다.

코드를 전부 읽지 않더라도 입력/출력 검증, 테스트, 로그, 롤백, 권한 분리로 책임을 보완해야 한다.

특히 leaf node처럼 다른 모듈이 의존하지 않는 말단 기능부터 시작하는 편이 안전하다.

핵심 인증, 결제, 데이터 migration은 vibe coding 대상이 아니다.

Q2. Agentic engineering이면 코드를 안 읽어도 되나?

아니다.

Agentic engineering은 코드를 덜 읽어도 된다는 면허가 아니다.

대신 어떤 코드를 반드시 읽고, 어떤 부분은 테스트와 로그로 검증할지 정하는 방식에 가깝다.

보안, 데이터, 권한, 아키텍처 경계는 사람이 읽어야 한다.

반복적인 boilerplate나 leaf 기능은 검증 기준이 충분하면 전부 읽지 않아도 되는 구간이 생길 수 있다.

Q3. README와 테스트가 있으면 믿어도 되나?

그것만으로는 부족하다.

2026년에는 README와 테스트도 AI가 아주 빠르게 만들 수 있다.

봐야 할 것은 테스트의 존재가 아니라 테스트의 대표성이다.

실제 사용 로그, 운영 피드백, 장애 대응 기록, 롤백 경험이 더 강한 품질 신호가 된다.

개인 프로젝트라면 만든 사람이 2주 정도 실제로 써봤는지가 꽤 좋은 기준이다.

Q4. 팀에서 가장 먼저 정해야 할 정책은 뭔가?

권한 정책과 리뷰 정책이다.

어떤 파일과 명령은 에이전트가 읽기만 가능한지, 어떤 작업은 자동 승인에서 제외할지 정해야 한다.

그리고 AI 생성 코드 PR에는 어떤 추가 질문을 붙일지 정해야 한다.

예를 들어 기존 패턴 재사용, 테스트 대표성, rollback, 권한 확장 여부는 기본 질문으로 넣을 만하다.

도구 선정은 그다음이다.

Q5. 비용은 어떻게 잡아야 하나?

모델 구독료만 보면 안 된다.

토큰, CI, Actions minutes, 리뷰 시간, 실패한 재시도, 배포 복구 시간을 같이 봐야 한다.

GitHub가 Copilot code review의 Actions minutes 사용을 안내한 것처럼, agentic workflow는 AI 비용과 개발 인프라 비용이 함께 움직인다.

팀에서는 월 비용보다 기능 하나를 검증해서 배포하는 비용으로 보는 편이 현실적이다.

Q6. 주니어 개발자에게 AI 코딩 에이전트를 쓰게 해도 되나?

써도 된다.

다만 학습 모드와 생산 모드를 나눠야 한다.

학습 모드에서는 에이전트가 코드를 대신 쓰기보다 코드 설명, 힌트, 테스트 작성, 리뷰 질문 생성에 쓰이는 편이 좋다.

생산 모드에서는 작은 작업부터 맡기고, 사람이 직접 설명할 수 있는지 확인해야 한다.

이해하지 못한 코드를 merge하는 습관은 장기적으로 비싸다.

Q7. 이미 큰 AI 생성 PR이 생겼다면 어떻게 해야 하나?

먼저 merge를 멈추고 PR을 검증 질문별로 쪼개는 게 낫다.

기능, 테스트, 리팩터링, 문서, 설정 변경을 한 PR에 섞지 않는다.

에이전트에게 이 PR을 리뷰 가능한 단위로 나누는 계획만 작성해줘라고 시키는 것도 좋다.

그다음 소유자가 각 단위의 성공 기준을 다시 적는다.

큰 PR을 억지로 읽는 것보다 쪼개는 데 쓰는 시간이 보통 더 싸다.

Q8. 결국 개발자는 무엇을 더 잘해야 하나?

코드를 덜 쓰는 대신 더 많이 판단해야 한다.

요구사항을 좁히고, 위험을 분류하고, 테스트를 설계하고, 권한을 제한하고, 배포 후 증거를 봐야 한다.

AI가 코드 작성 속도를 올릴수록 사람의 병목은 설계, 리뷰, 운영, 실사용 검증으로 이동한다.

그래서 개발자의 가치는 사라지는 게 아니라 위치가 바뀐다.

좋은 개발자는 이제 코드 작성자이면서 검증 시스템 설계자에 가까워진다.

공식 출처 및 참고 자료

관련 글

아래 링크는 python3 .claude/scripts/blog_sheet.py list-published --channel TECHTAEK로 공개 URL이 확인된 글만 넣었다.

TECHTAEK식 운영 메모

이 글의 목적은 용어 싸움을 이기는 게 아니다.

팀이 내일부터 AI 코딩 작업을 더 안전하게 분류하게 만드는 것이다.

Vibe coding은 빠른 실험에 좋다.

Agentic engineering은 책임 있는 반복에 좋다.

둘 사이의 경계는 고정된 선이 아니라 작업마다 움직이는 슬라이더다.

그래서 도구를 바꾸기 전에 작업을 분류해야 한다.

이 작업은 vibe로 끝내도 되는가.

agentic workflow로 올려야 하는가.

아니면 아직 사람이 직접 설계해야 하는가.

이 세 질문만 제대로 던져도 AI 코딩 에이전트는 훨씬 덜 위험해진다.

그리고 이상하게도 더 빨라진다.

검증 기준이 있는 속도는 팀 자산이 된다.

검증 기준이 없는 속도는 나중에 티켓으로 돌아온다.

티켓으로 돌아오면 이름도 바뀐다.

그때는 보통 긴급 버그라고 부른다.