2026. 3. 17. 20:10ㆍAI
AI를 활용한 개발이 이제는 낯선 이야기가 아니게 되었다.
처음에는 자동 완성이나 간단한 질의응답 정도로 시작했지만, 최근에는 한 단계 더 나아가 에이전트(agent) 형태의 도구를 적극적으로 사용하는 개발자들이 많아졌다. 나 역시 최근에는 GitHub Copilot 에이전트 모드를 사용하거나, Claude Code를 통해 실제 코드베이스를 탐색하고 수정하는 흐름을 자주 사용하고 있다. 그리고 체감상 Claude Opus 4.6 모델이 꽤 좋은 결과를 보여줬다.
이번 글에서는 현업에서 AI 에이전트를 어떻게 활용하고 있는지, 그리고 잘 쓰기 위해 어떤 관점이 필요한지 정리해보려 한다.
AI 에이전트란 무엇일까?
간단히 말하자면 AI 에이전트는 답변만 하는 모델이 아니라, 주어진 목표를 해결하기 위해 스스로 탐색하고 도구를 사용하며 여러 단계를 수행하는 형태의 AI라고 볼 수 있다.
기존의 챗봇이 질문 하나에 답변 하나를 주는 데 가까웠다면, 에이전트는 그보다 조금 더 행동에 가깝다. 예를 들어 단순히 “이 에러 원인이 뭐야?”라고 설명하는 데 그치는 것이 아니라, 실제로 프로젝트 파일을 읽고, 관련 코드를 찾고, 수정안을 만들고, 필요한 경우 명령 실행이나 테스트까지 이어가는 식이다. GitHub Copilot 문서도 IDE의 agent mode를 “특정 작업을 주면 어떤 파일을 수정할지 결정하고, 코드 변경과 터미널 명령을 제안하며, 문제가 있으면 반복적으로 수정하는 방식”으로 설명하고 있다.
즉, 에이전트의 핵심은 “더 똑똑한 답변”이 아니라 문제를 해결하기 위한 작업 단위를 스스로 이어갈 수 있느냐에 있다.
현업에서 가장 자주 쓰는 활용 사례
1. 처음 보는 코드베이스를 빠르게 탐색할 때
현업에서는 내가 직접 작성하지 않은 코드가 훨씬 더 많다.
프로젝트에 새로 합류했거나, 예전에 만들어 둔 기능을 다시 볼 때 가장 먼저 드는 생각은 대개 비슷하다.
“이 로직이 어디서 시작되는 거지?”
“상태는 어디서 바뀌는 거지?”
“이 화면은 어느 API 응답을 바라보고 있지?”
이럴 때 에이전트는 꽤 강력하다.
단순히 검색창에 키워드를 넣는 것보다, “사용자 프로필 수정 플로우가 어디서 시작되고 어떤 API를 거쳐서 어떤 상태를 변경하는지 설명해줘”처럼 요청하면 코드 흐름을 훨씬 빠르게 잡아준다. 특히 폴더 구조가 크고 관심사 분리가 복잡한 프로젝트일수록, 에이전트는 사람의 첫 탐색 비용을 줄여주는 역할을 한다.
내가 체감하기로 에이전트의 첫 번째 가치는 “코드를 대신 짜주는 것”보다 “코드베이스를 빨리 이해하게 해주는 것”에 더 가깝다.
2. 반복적인 수정 작업을 맡길 때
현업의 많은 작업은 사실 창의적인 알고리즘 설계보다 반복 수정에 가깝다.
예를 들면 아래와 같은 일들이다.
- 여러 컴포넌트의 props 이름을 일괄 변경하는 작업
- 공통 유틸 함수로 로직을 묶는 작업
- API 응답 타입이 바뀌었을 때 관련 타입을 전파 수정하는 작업
- 로딩, 에러, 빈 상태 UI를 여러 화면에 동일하게 붙이는 작업
- 콘솔 로그 제거, 불필요한 import 정리, lint 경고 해소
이런 작업은 사람이 해도 할 수 있지만, 집중력이 빨리 소모된다. 반면 에이전트는 명확한 규칙만 주어지면 생각보다 꾸준하게 처리한다.
예를 들어 아래처럼 요청할 수 있다.
users 관련 화면 전체에서 isLoading, isError, data 분기 패턴을 공통 훅으로 추출해줘.
기존 UI 구조는 유지하고, 파일 변경 이유를 각 파일마다 설명해줘.
중요한 점은 막연하게 “리팩터링해줘”라고 던지는 것보다, 범위와 제약을 같이 주는 것이다. 에이전트는 자유도가 너무 높아지면 오히려 불필요한 수정까지 하려는 경향이 있다.
3. 리팩터링 초안을 빠르게 잡을 때
리팩터링은 방향을 잡는 데 시간이 많이 든다.
특히 “어디까지 추상화해야 하는가”, “이 로직을 훅으로 빼는 게 맞는가”, “공통 컴포넌트로 묶는 순간 오히려 복잡해지지 않는가” 같은 판단은 늘 어렵다.
이때 에이전트는 정답을 주기보다 초안 몇 개를 빠르게 비교하게 해주는 도구로 쓸 때 좋다.
예를 들어 어떤 화면 컴포넌트가 지나치게 비대해졌다면 아래처럼 요청할 수 있다.
이 컴포넌트를 관심사 기준으로 분리하는 방법을 3가지 제안해줘.
각 방법의 장단점과, 지금 구조에서 가장 부작용이 적은 안을 추천해줘.
그리고 추천안 기준으로 실제 파일 분리 초안까지 만들어줘.
이렇게 하면 바로 완성본을 받는 것이 아니라, 설계안 자체를 비교하면서 생각할 수 있다.
개인적으로는 이 지점이 꽤 중요하다고 본다. 에이전트는 “내 생각을 대체하는 도구”가 아니라, 설계 후보를 빠르게 늘려서 비교 비용을 줄여주는 도구에 더 가깝다.
4. 테스트와 디버깅 보조에 사용할 때
버그 수정은 흔히 “원인을 안다”고 끝나지 않는다.
실제로는 아래 질문들이 더 어렵다.
- 이 수정이 다른 화면에는 영향이 없을까?
- 지금 깨진 것은 증상이고, 진짜 원인은 더 아래에 있는 것 아닐까?
- 테스트를 어디까지 써야 안전할까?
이럴 때 에이전트는 디버깅 보조 역할을 꽤 잘 수행한다.
에러 메시지와 관련 파일 몇 개를 주고 “가능한 원인을 우선순위대로 정리해줘”, “재현 경로를 추정해줘”, “가장 작은 수정으로 막을 수 있는 방법부터 제안해줘”라고 하면, 생각 정리에 도움이 된다.
또 수정 이후에는 다음처럼 활용할 수도 있다.
이 수정이 회귀 버그를 만들 수 있는 지점을 체크리스트로 정리해줘.
가능하면 테스트 코드 초안도 함께 작성해줘.
물론 테스트 코드가 항상 바로 통과하는 수준으로 나오는 것은 아니다. 하지만 최소한 “무엇을 검증해야 하는지”를 빠르게 정리해준다는 점에서 생산성이 높다.
5. 문서화와 인수인계 자료를 만들 때
현업에서는 코드를 작성하는 시간만큼, 그것을 설명하는 시간도 중요하다.
특히 기능을 배포하고 나면 아래 문서들이 자주 필요하다.
- PR 설명
- 릴리즈 노트
- 기능 명세 초안
- QA 체크리스트
- 회고 문서
- 팀원 인수인계 문서
에이전트는 이 부분에서도 꽤 유용하다.
실제 수정 diff를 읽게 한 다음 “변경 목적, 영향 범위, QA 포인트를 정리해줘”라고 하면 초안이 금방 나온다. 특히 개발자는 구현 당시 머릿속에는 너무 익숙한 내용이라 오히려 설명문을 쓰기 어려운 경우가 많은데, 에이전트는 그 설명의 첫 문장을 열어주는 역할을 한다.
그렇다면 에이전트에게 어디까지 맡겨도 될까?
여기서 중요한 점이 하나 있다.
에이전트를 많이 쓴다고 해서, 무조건 많은 일을 맡기는 것이 좋은 것은 아니다.
오히려 현업에서는 애매하게 어려운 문제일수록 전부 맡기기보다, 단위를 잘게 쪼개서 맡기는 편이 더 안정적이다.
예를 들어 “우리 서비스의 인증 아키텍처를 전면 개선해줘” 같은 요청은 범위도 넓고 판단 포인트도 많아서 실패하기 쉽다. 반면 아래처럼 나누면 훨씬 좋아진다.
- 현재 인증 플로우를 먼저 요약한다.
- 취약한 지점을 찾는다.
- refresh token 처리 부분만 개선안을 낸다.
- 타입/에러 처리/UI 영향 범위를 나눈다.
- 마지막에 실제 코드 수정으로 들어간다.
즉, 에이전트는 거대한 문제를 한 번에 해결하는 마법 도구라기보다, 잘게 나눈 작업을 빠르게 이어서 처리하는 도구라고 보는 편이 맞다.
잘 쓰는 사람과 잘 못 쓰는 사람의 차이
AI 에이전트를 잘 쓰는 사람은 프롬프트를 화려하게 쓰는 사람이 아니다.
오히려 아래 세 가지를 잘하는 사람이다.
1. 작업의 범위를 명확하게 자른다
“리팩터링해줘”는 나쁜 요청이다.
“이 컴포넌트의 데이터 fetching 로직만 custom hook으로 분리하고, 기존 마크업은 유지해줘”는 좋은 요청이다.
좋은 요청은 목표가 작고, 변경 범위가 명확하고, 성공 조건이 보인다.
2. 제약 조건을 분명히 준다
현업 코드에는 늘 제약이 있다.
- 라이브러리를 추가하면 안 된다.
- public API는 바꾸면 안 된다.
- 디자인 시스템 컴포넌트만 써야 한다.
- 기존 테스트를 깨면 안 된다.
- 성능 특성이 바뀌면 안 된다.
이 제약을 빼먹으면 에이전트는 너무 쉽게 “그럴듯하지만 곤란한 답”을 낸다.
3. 검토는 반드시 사람이 한다
이 부분은 아무리 강조해도 지나치지 않다.
에이전트는 상당히 유용하지만, 여전히 코드의 의미와 서비스의 책임을 최종적으로 지는 주체는 개발자다. 특히 인증, 결제, 권한, 데이터 정합성처럼 중요한 영역에서는 더더욱 그렇다.
나는 개인적으로 AI 에이전트를 사용할 때 아래 기준을 갖고 본다.
- 구조 제안은 적극적으로 받는다.
- 반복 수정은 넓게 맡긴다.
- 핵심 비즈니스 로직은 사람이 중심을 잡는다.
- 머지 전 최종 판단은 반드시 직접 한다.
실제로 써보며 느낀 한계
에이전트가 잘하는 것도 많지만, 당연히 한계도 있다.
가장 대표적인 것은 문제의 본질을 잘못 정의한 채 부지런히 일할 수 있다는 점이다.
즉, 방향이 틀리면 열심히 틀린 답을 만들어낸다.
예를 들어 어떤 버그의 진짜 원인이 상태 동기화 문제인데, 에이전트가 화면 컴포넌트만 계속 고치고 있을 수도 있다. 또는 현재 프로젝트의 컨벤션을 충분히 이해하지 못한 채, 코드 모양만 그럴듯하게 맞출 수도 있다.
그래서 에이전트를 쓸 때 중요한 것은 “얼마나 많이 시키는가”가 아니라, 중간중간 올바른 방향으로 가고 있는지 체크하는 것이다.
이 점에서는 오히려 사람 시니어 개발자와 일하는 감각과 비슷하다. 일을 던져놓고 기다리는 것이 아니라, 중간 산출물을 보면서 계속 방향을 맞춰야 한다.
결국 중요한 것은 도구보다 작업 분해 능력이다
요즘은 어떤 모델이 더 좋으냐, 어떤 에이전트 도구가 더 강하냐는 이야기가 많다.
물론 체감 차이는 분명히 있다. 실제로 GitHub Copilot은 여러 모델을 지원하고, Claude 쪽도 Claude Code와 Agent SDK, MCP 같은 흐름을 꾸준히 확장하고 있다.
하지만 현업에서 생산성을 가장 크게 가르는 것은 모델 이름 자체보다, 개발자가 문제를 얼마나 잘 쪼개고, 제약을 얼마나 명확히 전달하며, 결과를 얼마나 비판적으로 검토하는가에 더 가깝다고 생각한다.
AI 에이전트는 개발자를 대체하는 존재라기보다, 개발자의 사고 과정을 더 빠르게 순환시키는 도구다.
코드를 대신 쳐주는 도구로만 보면 생각보다 금방 한계를 느낄 수 있다. 반대로 코드베이스 탐색, 반복 수정, 리팩터링 초안 작성, 테스트 보조, 문서화까지 포함한 작업 흐름 전체의 가속 장치로 보면 꽤 강력하다.
결국 중요한 것은 “AI가 얼마나 똑똑한가”보다, 내가 이 도구를 어떤 단위의 일에 어떻게 연결할 수 있는가다.
나 역시 최근에는 AI 에이전트를 단순한 보조 도구가 아니라, 하나의 실무용 인터페이스처럼 다루게 되고 있다.
아마 앞으로의 개발 생산성 차이는 코드를 한 줄 더 빨리 치는 사람보다, AI 에이전트에게 더 정확한 작업을 맡기고 더 정확하게 검토할 수 있는 사람에게서 더 크게 벌어지지 않을까 싶다.