AI Agentic Coding
Agentic Coding 경험과 앞으로의 개발자 역할
본격적으로 AI 와 함께 코딩한건 2025년 3월로 기억한다.
그때 나는 처음으로 Cursor 를 사용했고, 이후 5월부터는 Claude code CLI, 그리고 GPT-5 모델이 나왔을 때부터는 Codex CLI까지 병행하게 됐다.
이 글은 그동안 AI와 함께 코딩하며 쌓은 경험과, 그 속에서 얻은 교훈과 시행착오를 정리해보려 한다
2025년 2월 vibe coding 이 시장을 뜨겁게 달구었다.
나는 막 새로운 회사로 이직한 직후였고, 그곳은 AI를 적극적으로 실무에 도입하던 조직이었다.
4월 나는 새로운 프로젝트에 참여하게 되었고, 완전히 낯선 도메인을 마주했다.
AI의 도움이 절실했다.
이 당시 나는 AI 에게 큰 권한을 주었다.
그 결과 나는 놀라움과 불안감을 동시에 느꼈다.
놀라웠던 순간과 이내 찾아온 불안감
AI에게 큰 권한을 주었을때의 경험을 정리하자면 이렇다.
장점
"모르는 기술이어도 빠른 프로토타이핑 가능"
"새로운 접근이나 예상 못한 아이디어를 얻을 수 있음"
단점
"빌드 깨짐, 반복 실수"
"연속된 프롬프트 적용 후 되돌리기 어려움"
"유지보수는 결국 내 몫"
"실망이 누적되면 피로도 증가"
Kent Beck 은 이를 지니에 비유했다.
"소원은 들어주지만 종종 예상치 못한 방식으로 소원을 들어주는 지니"
"우리가 '의도'한 것이 아닌 '말' 한것을 실행"
Kent Beck은 AI와 일하면서 엄청난 생산성을 얻으면서도, 동시에 예측 불가능한 오류와 불안감을 경험했다고 한다.
이때 나는 궁금증이 생겼다. "원하는 결과를 얻기 위한 제어가 가능할까?"
AI 에게서 일정하고 예측 가능한 결과를 얻고 싶었다.
AI와 일을 할 수록 불안정한 결과가 쌓이는 느낌을 받았다.
그래서 나는 한 발 물러나, AI 와 내가 협업하는 흐름을 정리해보기로 했다.
첫번째는 프롬프트 입력 단계다.
AI.md 파일로 프로젝트의 맥락을 전달하고 목표와 제약을 명확히 했다.
두번째는 실행 단계다.
AI 가 작업 하는 동안, 필요하면 중간에 개입한다.
프롬프트 입력 단계에서 세분화된 계획을 세우도록 함으로써 실행을 제어했다.
세번째는 검토 단계다.
테스트 코드나 기능 검증을 통해 결과를 피드백하고, 이 과정을 루프로 반복했다.
AI 제어에 대한 기존 연구와 사례들을 살펴보다
내가 찾은 제어 방법이 과연 근거가 있을까 궁금했다.
그래서 비슷한 고민을 했던 사람들의 사례와 연구를 찾아보기 시작했다.
To vibe or Not to vibe
- Thoughtworks 의 Birgitta Böckeler [링크]
"이 바이브 코딩이 좋은가 나쁜가는 이분법적 질문으로 둘 다 아니며, 상황에 따라 다르기 때문이다"
"핵심은 이분법적 선택이 아니라 지속적이고, 직관적인 리스크 평가에 있다"
이 글에서는 AI 와 함께 일할때 리스크 평가의 3가지 요소를 소개한다.
발생 확율이 낮고, 영향력이 적으며, 탐지 가능성이 높으면 안전하게 vibe 코딩이 가능하며,
발생 확율이 높고, 영향력이 높으며, 탐지 가능성이 낮으면 더 면밀하게 검토해야 하는 것으로 리스크 평가를 활용하는 것에 대한 소개다.
리스크 평가의 3요소이 글에서는 리스크를 평가하는 것에 그치지 않고, 이를 완화 하는 전략에 대해서도 소개한다.
예시로 레거시 시스템 개편 작업을 했던 프로젝트를 소개한다.
발생 확율은 프롬프트를 반복 실행 하므로써 AI 가 실수를 할 가능 성을 줄였으며,
영향력은 단계적 출시 계획을 세우고 실행하므로써 결과에 대한 위험을 줄였다.
전문가의 리뷰를 거치고, 테스트 코드를 추가하는 것으로 탐지 가능성을 높였다.
이 글의 필자는 " 중요한 것은 체크리스트가 아니라 리스크를 줄이면서 AI 를 활용하는 직관적인 습관을 기르는 것이다. " 라고 정리했다.
Future of Agentic Coding
- Anthropic 의 Boris Cherny 인터뷰 [링크]
"가장 중요한 신호는 바로 '감(vibes)' 이에요/ 모델이 더 똑똑하게 느껴지는가 하는거죠"
모델이 개선되고 있는지를 확인하기 위해 평가를 만들려고 노력했지만, 소프트웨어 엔지니어링의 모든 복잡성을 포함하는 합성 평가를 구축하는 것은 "너무 어렵다"
코드는 아이디어를 실현하기 위한 일회용 도구가 되어가고 있다. 코드 자체는 더 이상 소중하지 않다.
( 선생님... 정말요? )
Anthropic 에서는 개밥먹기를 매우 긴밀한 피드백 루프로 활용했다고 한다.
그리고 에이전트 코딩의 팁으로 두가지를 제안해 준다.
첫번째 팁
- 처음부터 코드를 작성하지 말고 먼저 코드베이스에 대해 질문하기
두번째 팁
- 쉬운작업 > 자유롭게 맡겨라 ( github 에서 @Claude 태그후 PR 생성까지 맡길수 잇는 정도의 작업 )
- 보통 작업 > Plan 모드를 통해 계획을 검토하고 맡겨라
- 어려운 작업 > 사람이 주도권을 가지며 보조도구로 활용해라
* 어려운 작업에서 Claude 의 역할
- 아이디어 프로토타이핑
- 시스템의 경계를 이해하기 위한 옵션 코딩 ( vibe )
- AI 가 단위 테스트를 작성할수 있지만 구현은 엔지니어 자신이 주로 해야할 일이다.
나는 '핵심은 하려는 작업이 무엇인지 파악하고 올바른 에이전트 사용법을 결정하라는 것'으로 해석됐다.
An example of LLM prompting for programming
- 마틴 파울러 블로그 [링크]
COT ( chain of thought )
핵심 전략은 코드 작성전 계획을 먼저 생성하게 하고, 단계별 추론 과정을 설명하도록 유도하는 기법
이 글은 LLM 을 주니어 개발자를 대하듯, 단계별 계획을 세우고 그 결과를 미세 조정하는 반복적인 피드백을 나누며, 결과적으로 생성된 코드가 팀의 기존 코드 작성 방식 및 테스트 작성 방식에 맞도록 수정하는 과정을 소개한다.
더불어 장기적인 작업에서도 맥락을 유지하기 위해 마스터 플랜 접근 방식도 제안한다.
마스터 플랜 : COT 프롬프트 기법과 Generated Knowledge 프롬프트 기법을 결합해서 생성 )
마틴 파울러는 이와 같이 AI Agent 를 잘 활용하려면 최상의 결과를 얻기 위한 프롬프트를 구성하는 방법을 배워야 한다고 말한다.
Tree of Thoughts
문제 : 전통적인 AI 프롬프팅은 하나의 단서만 따라감
생각의 나무
- 여러 추론 경로를 탐색하고 진행 상황을 평가하는 방법
평가의 목표
- 올바른 해답은 촉진
- 불가능한 경로는 조기 제거
- 가능성이 존재하는 부분은 추가 탐색을 위해 유지
제어의 핵심
자체 평가 : LLM 이 의도적 추론 과정을 통해 문제 해결을 향한 중간 사고의 진행 상황을 스스로 평가
탐색 알고리즘 결합 : BFS ( 너비 우선 탐색 ) 및 DFS ( 깊이 우선 탐색 )와 결합 되어 예측 및 역추적을 통해 사고를 체계적으로 탐색
후보 필터링 및 제어 : BFS 를 수행할때 각 사고 후보를 " 확실함 / 어쩌면 가능 / 불가능함 " 으로 평가해서 제어
Tree of Thoughts 는 궁극적으로 프롬프트 입력 후 중간 수행 단계를 체계적으로 제어하고 탐색하여 복잡한 문제를 다룰때 원하는 결과를 얻기위한 방법론으로 볼 수 있다.
TDD, AI Agents, and the Future of Coding
- Kent Beck 인터뷰 [링크]
TDD: 불안함을 관리하는 도구
AI 가 놓친것을 테스트의 형태로 전달
( AI 에게 뭘 원하는지 정확하게 알려주고 가르키는 도구로 사용 )
켄트백의 작업 흐름켄트백은 Agent 와 함께 일할때 초점이 코드 작성에서 '정확성 정의' 로 이동하고 있다고 말한다.
명확하게 원하는 결과를 얻을수 있는 방법으로 생각된다. 하지만 항상 모든 것이 명확한 명세를 가진채로 시작되지 않을수도 있다고 생각해서 그때에는 절충안이 필요할 것 같다.
여러 AI 제어에 대한 기존 연구와 사례들을 살펴보았다.
목적은 AI와 작업할때 원하는 결과물을 얻기위한 방법으로 수렴된다
나의 경험과 시행착오
프롬프트 증강을 위한 노력
프로젝트를 진행하면서 나는 Plan 문서와 Spec 문서를 작성하고,
작업 중간마다 내용을 업데이트 하며 AI 에이전트에게 맥락을 지속적으로 전달하려 했다.
이 시도는 분명 효과가 있었다.
AI가 이전보다 더 일관된 방향으로 결과를 보여주는 순간들을 보였기 때문이다.
하지만 문서가 비대해질수록 토큰 낭비와 핵심 맥락이 손실되는 부작용도 생기기 시작했다.
결국 프롬프트 증강의 효과는 '정확한 결과를 꾸준히 보장' 하기 보다는, AI 작업 결과를 조금 더 안정적인 방향으로 향하도록 유도하는 정도에 머무르는 듯 했다.
분명한 상관관계를 설명하기 어렵지만, 일정한 맥락 축적이 결과의 일관성을 높이는데 기여했다고 생각됐다.
피드백 루프 확보
이후 나는 테스트 코드 작성과 더미 서버를 통한 E2E 테스트로 AI 가 작성한 코드의 결과를 체계적으로 검증하기 시작했다.
나에게 가장 중요한 기준은 하나 "소프트웨어 명세를 올바르게 구현했는가" 였다.
이 검증은 어렵지 않다. 테스트를 통과하면 되고, 테스트로 검증 범위 밖의 것은 E2E 테스트나 수동 테스트를 통하면 된다.
이 단순한 사실이 나를 안정시켰고, 그래서 나는 결과 검토와 피드백 루프 설계에 가장 많은 에너지를 쏟았다.
의도적 수련
AI 와 함께 코딩하는 시간이 길어질수록, 어느 순간 '이건 단순한 사용이 아니라 학습에 가까운데?' 라는 생각을 하게 되었다. 그동안 나는 시행착오 속에서 조금씩 개선을 해왔다고 생각했지만, 좀더 체계적으로 만들수는 없을까 고민하기 시작했다.
그동안 집중 학습을 할때 사용했던 개념인 의도적 수련을 떠올렸다. 단순한 반복이 아니라, 명확한 목표와 실행 규칙을 두고, 개선을 위한 루프가 있는 학습. AI 와 협업하는 능력도 같은 방식으로 훈련 될 수 있지 않을까?
K. Anders Ericsson
Deliberate practice 와 그 의미에 대한 연구
의도적 수련이란?
성과 향상을 위해 특별히 고안된 활동이다.
(중략) 꾸준하고 일관된 개선을 이루고 새로운 수준의 숙련도에 도달하기 위해 집중적이고 반복적인 연습이 필요하다.
알려진 기술을 반복하기 보다 자신의 약점을 개선하기 위해 노력하는 것으로 '능력의 한계'에 초점을 맞춘다.
내가 설정한 루프
목표 정의
Seed 를 고정한채 명확한 목표 설정
예를 들어 하나의 거대한 모놀리식 클래스를 준비하고 목표는 모듈화된 코드 구조로 리펙터링 하는 것으로 두었다.
프롬프트 입력 단계
프롬프트 입력 후 결과를 보고 프롬프트 맥락 추가 혹은 제거, 필요한 제약 추가등을 하며 프롬프트 증강을 학습한다.
수련 효과 : 맥락 전달 방법 성장
실행 단계
플랜 수정, 실행 중간에 진행상황을 점검하며 잘못된 경로로 가지 않도록 방향 수정
COT , TOT 같은 프레임워크도 활용
수련 효과 : 개입 타이밍, 필요한 만큼 개입 등의 경험치 상승
결과 검토 단계
테스트 코드, 빌드 검증, 품질 지표 ( 복잡도 / 중복도 ) 로 결과 정량or정성적 검증
실패한 경우에도 무엇이 부족했는지 회고
수련 효과 : 피드백 루프의 다양한 방법에 대한 체득 및 경험 치 상승
이 방법의 한계도 있다고 생각한다.
AI 의 비결정성 때문에 같은 프롬프트여도 결과가 달라지며, 컨텍스트의 한계때문에 긴 코드로는 실행하기 어렵다. 학습 측정 또한 확고한 정답이 정해진 것은 아니므로 어느정도 감으로 평가해야 한다.
아직 나는 이 개념을 완전히 실천했다고 말하기 어렵다.
다만, 지금까지의 시행착오를 돌아보면 분명히 그 방향으로 나아가야 겠다는 확신은 생겼다.
AI 와 협업하는 능력또한 '의도적으로 연습' 할 수 있는 영역으로 보여지고 나에게는 이 역량 강화가 필요하기 때문이다.
AI 코딩 시대에서 개발자의 새로운 역할
이런 고민과 수련을 고안하면서 얻은 깨달음은, AI와의 협업 능력은 새로운 형태의 개발 역량이라는 점이다.
이제 나는 더이상 코드를 직접 짜는 사람보다, AI 를 조율하고 검증하는 사람으로 변화하고 있었다.
Kent Beck 은 이렇게 이야기 했다.Ryan J. Salva ( Google Sernior Director of Product ) 역시 같은 맥락에서 이야기했다. [링크]
"AI 시대에 소프트웨어 엔지니어의 역할은 사라지는 것이 아니라 진화하고 있다.
엔지니어 들이 이제 원시 코드를 작성하는데 시간을 덜 쓰고, 제품 설계, 아키텍쳐, 그리고 문제 해결같은 더 높은 수준의 사고에 집중하게 될 것이다."
개발자의 역할은 이미 전통적인 모습과는 달라지기 시작했다.
새로운 모델들이 등장하고 ToT 같은 프롬프트 증강 전략이 연구되고 있다.
하지만 변하지 않는 사실이 하나 있다.
" AI는 여전히 '명령을 받아 일하는 도구'라는 것 "
결국 중요한건, 그 도구를 얼마나 잘 다루고 활용하느냐이며, 이 능력은 앞으로 개발자에게 점점 더 중요한 역량이 될 것이다.
이 글은 이런 고민속에서 작성했고, 나는 앞으로 필요한 역량을 갖추기위해 올바른 뱡향의 노력을 하고 싶다.
아직 가야할 길이 멀다.
