7부 33장. 코드 생성 AI에서 코딩 에이전트로

코딩 AI를 처음 떠올리면 많은 사람이 이런 장면을 생각한다. 에디터에서 몇 글자를 치면 다음 줄이 회색 글씨로 따라오고, 탭을 누르면 코드가 완성되는 장면 말이다.

그 장면은 여전히 유효하다. 하지만 이제는 절반만 맞는 그림이기도 하다. 오늘의 코딩 AI는 단순히 다음 줄을 추천하는 도구에 머무르지 않는다. 점점 더 많은 도구가 여러 파일을 읽고, 수정하고, 터미널 명령을 실행하고, 테스트를 다시 돌리고, 실패하면 스스로 고쳐 보려는 방향으로 움직이고 있다.¹²

이 변화는 꽤 중요하다. 왜냐하면 이제 코딩 AI를 잘 쓴다는 말이 더 이상 "자동완성을 잘 받는다"는 뜻이 아니기 때문이다. 이제는 AI를 개발 흐름 안에 어떻게 넣을 것인가가 더 중요한 질문이 되었다.

이번 장에서는 그 판의 변화를 살펴본다. 코드 추천 도구와 코딩 에이전트는 무엇이 다르고, 왜 이 차이가 실무 생산성을 바꾸는지, 그리고 개발자는 어떤 방식으로 AI와 함께 일하게 되는지를 차근차근 정리해 보자.

예전의 코딩 AI는 무엇을 잘했는가

초기의 코딩 AI는 대체로 세 가지에 강했다.

• 다음 토큰이나 다음 줄 예측

• 짧은 함수나 보일러플레이트 코드 생성

• 문법, API 사용법, 간단한 예시 제안

이런 도구는 꽤 유용했다. 특히 반복적인 코드, 익숙한 패턴, 자주 쓰는 프레임워크 작업에서는 속도를 분명히 올려 주었다. 주석으로 "로그인 함수 만들어 줘"라고 쓰면 초안이 나오고, 함수 이름 몇 개만 써도 나머지를 채워 주었다. 초보자에게는 진입 장벽을 낮춰 주었고, 숙련자에게는 손가락 노동을 줄여 주었다.

하지만 한계도 분명했다.

자동완성은 주로 지금 보고 있는 파일 근처에서 움직인다. 길게 말 잘 듣는 챗봇도 대개는 "이 함수는 이렇게 고치세요" 수준에서 멈췄다. 실제 프로젝트는 그렇지 않다. 버그 하나가 라우터, 서비스, 데이터베이스 쿼리, 테스트 코드, 환경 설정 파일까지 걸쳐 있는 경우가 흔하다. 이럴 때는 좋은 한 줄보다 여러 단계를 이어서 처리하는 능력이 더 중요하다.

즉, 예전의 코딩 AI는 "코드를 써 주는 비서"에 가까웠다면, 지금의 코딩 에이전트는 "작업을 굴려 보는 동료" 쪽으로 이동하고 있다.

진짜 변화는 코드가 아니라 행동에 있다

많은 사람이 이 변화를 모델 성능 향상으로만 이해한다. 물론 모델이 좋아진 것은 맞다. 하지만 더 큰 변화는 다른 데 있다. AI가 행동할 수 있는 범위가 넓어졌다는 점이다.

예를 들어 예전 도구는 이런 식으로 일했다.

"테스트가 실패합니다. 이 함수를 고쳐 보세요."

그러면 후보 코드를 제안한다. 여기서 끝이다.

반면 코딩 에이전트는 이런 흐름으로 움직일 수 있다.

먼저 프로젝트 파일을 읽는다. 실패한 테스트를 확인한다. 관련 코드를 찾는다. 원인을 추정한다. 여러 파일을 수정한다. 테스트를 다시 실행한다. 실패하면 다른 가설을 시도한다. 마지막에는 무엇을 왜 바꿨는지 요약한다.¹

이 차이는 아주 크다. 전자는 대답하는 도구이고, 후자는 과정을 수행하는 도구이기 때문이다.

개발자가 체감하는 변화도 여기서 나온다. 단순히 코드 한 덩어리를 받는 것이 아니라, 원인 파악부터 수정, 확인까지 이어지는 작은 작업 루프를 AI가 맡기 시작한 것이다.

코드 생성 AI와 코딩 에이전트는 무엇이 다른가

둘의 차이를 가장 쉽게 이해하는 방법은 질문을 바꾸는 것이다.

코드 생성 AI에게는 보통 이렇게 묻는다.

"이 기능 코드를 작성해 줘."

코딩 에이전트에게는 이렇게 맡긴다.

"이 이슈를 해결해 줘. 필요한 파일을 찾아 수정하고, 테스트까지 확인해 줘."

비슷해 보여도 본질은 다르다.

코드 생성 AI의 중심은 출력물이다. 좋은 함수, 좋은 컴포넌트, 좋은 예제 코드를 받는 일이 핵심이다.

코딩 에이전트의 중심은 완료된 작업이다. 파일 변경, 명령 실행, 검증, 요약까지 포함한 하나의 흐름이 중요하다.¹²

그래서 코딩 에이전트는 보통 다음 요소를 가진다.

• 목표를 단계로 쪼개는 계획 능력

• 여러 파일과 폴더를 오가는 작업 능력

• 터미널, 테스트, 린트 같은 도구 사용 능력

• 실패했을 때 다시 시도하는 반복 능력

• 작업 기록과 변경 내용을 설명하는 능력

이 다섯 가지가 붙는 순간, AI는 "코드 추천기"에서 "작업 수행기"로 성격이 바뀐다.

왜 개발 현장에서 체감 차이가 큰가

실무의 대부분은 사실 새 알고리즘을 발명하는 일이 아니다. 이미 있는 시스템을 읽고, 고치고, 맞추고, 확인하는 일이다.

버그 수정 하나를 생각해 보자. 개발자는 보통 이런 순서로 움직인다.

오류를 재현한다. 로그를 본다. 관련 파일을 찾는다. 가설을 세운다. 수정한다. 테스트한다. 다시 실패하면 가설을 바꾼다. 그리고 마지막에 변경 범위를 정리한다.

코딩 에이전트가 유용한 이유는 바로 이 흐름의 여러 칸을 건드릴 수 있기 때문이다. 단순 자동완성은 한 칸만 돕는다. 하지만 에이전트는 여러 칸을 이어 준다.

그래서 체감 생산성이 달라진다. 생산성은 "몇 줄을 대신 써 줬는가"보다 "몇 번의 문맥 전환을 줄여 줬는가"에서 더 크게 올라가기 때문이다.

개발자는 원래도 자주 왔다 갔다 한다. 에디터를 보다가 터미널을 열고, 테스트 결과를 보고, 다시 코드를 수정하고, 문서를 찾아본다. 코딩 에이전트는 이 분절된 흐름을 하나의 작업 단위로 묶어 준다. 바로 이 지점에서 AI는 단순한 편의 기능이 아니라 개발 워크플로의 일부가 된다.

코딩 에이전트의 기본 루프를 이해하자

겉보기에는 그럴듯하게 "알아서 해 준다"처럼 보이지만, 내부에서는 꽤 익숙한 루프가 돈다. 생각보다 사람의 작업 방식과 닮아 있다.

먼저 목표를 받는다. 그다음 해야 할 일을 쪼갠다. 필요한 파일과 맥락을 읽는다. 수정안을 만든다. 명령을 실행해 결과를 확인한다. 문제가 있으면 다시 수정한다. 마지막에 결과를 정리한다.¹

이 과정을 아주 단순하게 적으면 이렇다.

목표 설정 → 계획 → 파일 읽기 → 수정 → 실행/검증 → 실패 시 재시도 → 결과 요약

중요한 것은 이 루프가 붙는 순간, AI의 품질 기준도 달라진다는 점이다.

예전에는 "코드를 그럴듯하게 잘 쓰는가?"가 중요했다. 이제는 거기에 더해 "문제를 올바르게 이해하는가?", "적절한 파일을 찾는가?", "테스트와 실행 결과를 반영하는가?", "실패 후 엉뚱한 방향으로 폭주하지 않는가?"까지 봐야 한다.

즉, 코딩 에이전트의 평가는 문장 품질이 아니라 작업 완수 품질로 이동한다.

IDE 안의 AI와 에이전트형 AI는 어떻게 달라지는가

최근 도구들은 같은 IDE 안에서도 역할을 나눠 제공한다. 예를 들어 어떤 환경에서는 질문만 답하는 모드, 계획만 세우는 모드, 실제로 파일을 바꾸고 명령을 실행하는 에이전트 모드를 구분한다.¹

이 구분은 꽤 실용적이다.

질문이 목적일 때는 굳이 파일 수정 권한이 필요 없다. "이 코드베이스에서 인증은 어디서 처리하나?" 같은 질문에는 읽기 중심 모드가 적합하다. 반대로 "이 테스트 실패를 고쳐 줘"처럼 실제 수정을 원하면 실행 가능한 에이전트가 필요하다.

여기서 중요한 포인트가 하나 있다. 이제 AI 도구는 단순히 "어느 모델을 쓸까?"만 고르는 문제가 아니다. 어떤 모드로, 어느 정도 자율성을 주고, 어떤 도구 접근을 허용할까까지 설계해야 한다.¹

이 말은 곧, 개발자가 AI를 쓰는 방식도 달라져야 한다는 뜻이다. 질문을 잘하는 것만으로는 부족하다. 작업의 범위, 권한, 확인 절차를 함께 정해야 한다.

이제 중요한 것은 프롬프트보다 작업 단위다

코딩 AI를 처음 배울 때는 좋은 프롬프트가 중요했다.

예를 들어 이런 식이다.

"TypeScript로 작성하고, 함수형 스타일을 우선하고, Jest 테스트도 함께 작성해 줘."

물론 여전히 유효하다. 하지만 에이전트 시대에는 여기에 한 층이 더 생긴다. 좋은 지시보다 더 중요한 것은 좋은 작업 단위다.

작업 단위가 좋다는 것은 다음과 같은 뜻이다.

• 목표가 분명하다

• 범위가 적절히 잘려 있다

• 성공 기준이 있다

• 검증 방법이 있다

• 건드리면 안 되는 영역이 정해져 있다

예를 들어 "결제 시스템 전반을 개선해 줘"는 나쁜 작업 단위다. 너무 크고, 성공 기준도 흐리다.

반면 "결제 실패 시 재시도 로직에서 중복 청구가 발생하지 않도록 수정하고, 관련 테스트를 추가해 줘. 데이터베이스 스키마는 바꾸지 마"는 훨씬 좋은 작업 단위다.

에이전트는 똑똑해질수록, 오히려 더 분명한 일감을 받을 때 강해진다. 추상적인 요구에 만능으로 반응하는 존재가 아니라, 잘 정의된 작업을 빠르게 굴리는 존재로 보는 편이 현실적이다.

실전에서 코딩 에이전트가 특히 강한 일

코딩 에이전트는 모든 개발 업무를 똑같이 잘하지는 않는다. 하지만 몇몇 영역에서는 확실히 힘을 발휘한다.

첫째, 여러 파일에 걸친 정형화된 수정이다. 타입 이름 변경, 설정 마이그레이션, 공통 유틸 교체, 린트 규칙 맞추기 같은 일은 에이전트가 꽤 잘 처리한다.

둘째, 테스트와 함께 움직이는 버그 수정이다. 실패하는 테스트가 있고, 재현 경로가 있고, 수정 후 다시 검증할 수 있다면 에이전트가 일하기 좋은 환경이 된다.

셋째, 초안 작업이다. 새 기능의 뼈대를 만들고, API 핸들러와 테스트 틀을 깔고, 문서 초안을 준비하는 일은 사람의 출발 속도를 크게 높여 준다.

넷째, 리포지토리 탐색과 요약이다. 큰 프로젝트에서 "어디를 봐야 하는가"를 찾는 데 시간을 많이 쓰는데, 에이전트는 코드베이스 질의응답이나 계획 초안에서 특히 도움이 된다.¹

이런 작업의 공통점은 분명하다. 전부 "한 줄 추천"보다 "작업 흐름 수행"이 더 중요한 일들이다.

그렇다고 개발자가 사라지는 것은 아니다

이쯤 되면 이런 생각이 든다.

"그럼 이제 개발자는 뭘 하지?"

답은 의외로 단순하다. 개발자는 사라지지 않고, 역할의 중심이 이동한다.

예전에는 개발자가 직접 타이핑하는 비중이 컸다. 이제는 점점 더 많이 문제를 정의하고, 작업을 나누고, 결과를 검토하고, 경계를 설정하는 일이 중요해진다.

쉽게 말해 손보다 눈과 판단이 더 중요해진다.

좋은 개발자는 이제 단지 코드를 빨리 쓰는 사람이 아니다. 어떤 작업은 에이전트에게 맡기고, 어떤 작업은 사람이 직접 잡아야 하는지 구분하는 사람이다. 또한 AI가 만든 결과를 맥락 속에서 읽고, 아키텍처와 운영 위험까지 고려해 받아들이거나 거절할 수 있어야 한다.

이 변화는 무섭게 느껴질 수도 있지만, 사실은 개발의 본질에 더 가까운 이동이기도 하다. 원래 소프트웨어 개발의 핵심은 타이핑 속도가 아니라 문제 해결과 시스템 이해였기 때문이다.

코딩 에이전트 시대에 더 중요해진 질문

이제 실무에서는 이런 질문이 더 중요해진다.

"어떤 모델이 가장 똑똑한가?"보다 "이 작업을 어디까지 맡길 것인가?"

"프롬프트를 어떻게 예쁘게 쓸까?"보다 "작업 단위를 어떻게 자를까?"

"코드를 얼마나 잘 생성하나?"보다 "테스트, 실행, 검증까지 포함해 얼마나 안정적으로 끝내나?"

실제로 최신 코딩 도구들은 단순한 에디터 보조를 넘어, 여러 파일 수정, 명령 실행, Git 흐름, CI와의 연결, 클라우드나 백그라운드 실행 같은 방향으로 확장되고 있다.¹²³

이 말은 곧, 코딩 AI를 도구 하나로 볼 것이 아니라 개발 시스템 안의 한 작업자처럼 봐야 한다는 뜻이다. 물론 아직은 감독이 필요한 작업자다. 그래도 더 이상 단순한 자동완성 플러그인만은 아니다.

좋은 비유는 "매우 빠른 인턴"보다 "작업 가능한 동료"다

코딩 에이전트를 설명할 때 "엄청 빠른 인턴"이라는 비유를 자주 쓴다. 어느 정도 맞지만, 조금 부족하다.

인턴 비유는 에이전트의 미숙함은 잘 보여 주지만, 도구 사용 능력과 반복 실행 능력을 충분히 담지 못한다. 오늘의 코딩 에이전트는 단순히 설명을 듣고 받아 적는 존재가 아니다. 파일을 뒤지고, 명령을 실행하고, 테스트를 돌리고, 다시 고쳐 보는 식으로 실제 작업 루프 안에 들어온다.¹²

그래서 더 정확한 비유는 작업 가능한 동료에 가깝다. 다만 경험 많은 동료는 아니다. 빨리 움직이고, 많이 시도하지만, 중요한 순간에는 검토가 필요한 동료다.

이 관점을 가지면 기대치도 건강해진다. 완벽을 기대하지 않게 되고, 그렇다고 단순 장난감으로 치부하지도 않게 된다.

앞으로의 개발 흐름은 어떻게 바뀌는가

앞으로 개발자의 일상은 대략 이런 식으로 바뀔 가능성이 크다.

짧은 코드는 자동완성이 돕는다. 구조를 잡을 때는 대화형 AI가 아이디어를 정리한다. 여러 파일이 걸린 작업은 에이전트가 초안을 만들고 테스트까지 돌려 본다. 개발자는 그 결과를 검토하고, 위험한 변경을 통제하고, 더 큰 설계를 결정한다.

즉, 한 가지 AI가 모든 일을 대체하는 그림보다, 여러 수준의 AI가 하나의 개발 흐름 안에 배치되는 그림이 더 현실적이다.¹⁴

이 변화는 단순한 기능 추가가 아니다. 개발 방식 자체의 재배치다. 예전에는 "내가 코드를 쓰고 AI가 거든다"였다면, 이제는 "AI가 일부 작업을 굴리고 내가 방향과 기준을 잡는다"로 이동하고 있다.

그리고 바로 이 지점에서 다음 장들의 주제가 이어진다. 왜 CLI 기반 도구가 강력한지, 파일·터미널·테스트가 어떻게 연결되는지, 코드 작업을 맡길 때 어떤 지시가 필요한지는 모두 이 변화의 연장선에 있다.

이 장의 정리

코딩 AI는 이제 단순 자동완성이나 코드 추천 도구를 넘어, 실제로 작업을 수행하는 에이전트로 이동하고 있다.

예전의 코드 생성 AI가 좋은 함수와 코드 조각을 만들어 주는 데 강했다면, 코딩 에이전트는 목표를 받아 계획하고, 여러 파일을 수정하고, 명령을 실행하고, 테스트로 확인하고, 실패하면 다시 시도하는 식으로 개발 흐름의 일부가 된다.¹²

그래서 이제 중요한 것은 "코드를 얼마나 잘 써 주는가"만이 아니다. 어떤 작업 단위로 맡길 것인가, 어떤 권한을 줄 것인가, 어떤 검증 루프 안에서 쓸 것인가가 더 중요해졌다.

한마디로 정리하면 이렇다.

코딩 AI의 시대는 끝나지 않았다. 다만 이름이 바뀌고 있다. 이제 그것은 단순한 코드 생성기가 아니라, 개발 흐름 안에서 일하는 코딩 에이전트가 되어 가고 있다.

참고

¹Using agents in Visual Studio Code

²Codex  AI Coding Partner from OpenAI

³Best AI Coding Tools & Agents for 2025–26 (By Workflow)

⁴AI Coding Agents in 2026: How to Choose Between Claude Code, Cursor, and GitHub Copilot