코딩 에이전트를 잘 쓰는 역량 소개
Andrew Ng는 AI Engineering Skills Map의 세 번째 축으로 코딩 에이전트를 활용하는 능력을 제시합니다. 에이전트가 코드를 작성하는 속도만 보는 것이 아니라, 무엇을 맡기고 어느 정도 자율성을 주며 어떤 증거로 결과를 검증할지를 결정하는 능력입니다. 앞선 전체 역량 지도, AI 애플리케이션 구축 역량, 소프트웨어 기본기에 이어지는 원문 연재의 네 번째 편입니다.
원문은 Claude Code, Codex, Cursor, OpenCode, Pi처럼 서로 다른 코딩 에이전트를 언급합니다. 도구마다 모델과 하네스가 빠르게 달라지고 있으므로, 특정 제품의 사용법을 외우는 것보다 작업을 계획하고 결과를 확인하는 공통 원리를 익히는 편이 유용합니다. 코딩 에이전트는 코드 작성 외에도 데이터 분석이나 운영 작업을 지원할 수 있습니다.
Ng는 여러 AI 엔지니어와의 인터뷰, 팀의 사용 경험에서 계획, 실행과 검증, 배포와 관찰이라는 큰 흐름을 정리합니다. 기존 소프트웨어 개발 절차와 닮아 있지만, 사람이 직접 타이핑하는 코드의 비중이 줄면서 무엇을 만들지, 어떻게 설계하고 검증할지에 더 많은 주의가 필요해졌다는 설명입니다. 원문은 각 단계에 쓰는 시간과 세부 수준이 프로젝트마다 다르며, 필요하지 않은 단계는 생략할 수 있다고 설명합니다. 검증이나 운영 관찰에서 문제가 드러나면 앞 단계로 돌아가 다시 결정합니다.
계획은 요구사항과 검증 방법을 함께 정하는 단계입니다
계획(planning) 에는 아이디어 검토, 자료 조사, 실험, 기존 코드베이스 이해가 포함됩니다. 그 결과를 요구사항과 기술 설계, 아키텍처를 담은 명세로 정리하고 실행 순서를 정합니다. 원문은 계획에 담긴 가정을 다시 살펴보며 보안 문제나 과도한 설계가 없는지 확인하는 과정도 제안합니다.
모든 작업에 긴 설계 문서가 필요한 것은 아닙니다. 처음 만드는 작은 프로토타입은 짧은 지시로 충분할 수 있습니다. 반면 이미 이용자가 많은 서비스에서는 현재 동작, 데이터 구조, 배포 조건을 조사해야 변경 범위를 정할 수 있습니다. 프로젝트의 위험이 다르므로 계획의 길이와 세부 수준도 달라집니다.
예를 들어 문서 검색 기능에 출처 표시를 추가한다면, *"답변에 링크를 붙여 달라"*는 요구만으로는 부족할 수 있습니다. 어떤 문서 버전을 인용해야 하는지, 검색 결과가 없을 때 어떻게 표시할지, 기존 답변 형식과 호환돼야 하는지를 명세에 적어야 합니다. 이 예시는 원문의 원칙을 보여주기 위해 덧붙인 사례입니다.
실행에서는 자율성과 확인 지점을 조절합니다
실행(execution) 단계에서는 에이전트가 코드를 만들고 테스트를 돌리며 결과를 확인합니다. 개발자는 작업을 옆에서 대화형으로 조정할지, 검증 가능한 단위로 묶어 맡길지 결정합니다. 여러 작업을 병렬로 맡길 때는 서로 같은 파일을 바꾸거나 같은 가정을 다르게 해석하지 않도록 범위와 합치는 순서를 정해야 합니다.
원문은 사람과 에이전트가 어느 단계에 시간을 쓸지 정하는 능력을 워크플로 지휘(directing the workflow) 라고 설명합니다. 빨리 진행하는 것만이 목표는 아닙니다. 기술적 위험, 사람의 검토 비용, 에이전트 실행 비용을 고려해 조사와 구현의 비중을 조절해야 합니다. 검증에 실패하면 다시 계획이나 구현으로 돌아가는 반복도 자연스러운 과정입니다.
자율성 부여(enabling agent autonomy) 에는 컨텍스트 관리와 권한 설정이 함께 들어갑니다. 작업 도중 바뀐 가정과 사용자 피드백을 다음 단계의 에이전트가 알 수 있게 남겨야 합니다. 파일 수정, 외부 전송, 배포처럼 영향이 다른 행동에는 각각 적절한 권한과 확인 지점을 둬야 합니다. 자율성을 높일수록 목표와 성공 기준을 더 분명히 적어야 합니다.
검토는 코드뿐 아니라 사용자가 겪는 결과를 확인합니다
에이전트가 만든 결과는 미리 확정할 수 없습니다. 예상하지 못한 좋은 구현을 제안할 수도 있지만, 테스트를 통과하면서도 사용자 흐름을 망가뜨릴 수도 있습니다. 따라서 작업 검토(reviewing the work) 에는 기능 검증과 동작 검증이 모두 필요합니다. 화면이 있는 제품이라면 실제 사용 흐름을 실행하고 화면 캡처를 근거로 남길 수 있습니다.
정답이 명확한 기능은 자동 테스트로 확인하고, 답변의 품질처럼 판단이 필요한 동작은 평가 세트와 사람의 검토를 조합할 수 있습니다. 원문은 필요에 따라 LLM을 평가자로 쓰는 방법도 언급합니다. 다만 테스트가 통과했다는 사실과 테스트가 제품 목표를 제대로 나타낸다는 사실은 다릅니다. 잘못된 성공 기준을 자동화하면 같은 오류를 더 빠르게 반복하게 됩니다.
검토에는 에이전트를 활용한 코드 리뷰, 보안 점검, 아키텍처 점검도 들어갑니다. 이 결과가 충분하지 않을 때는 사람이 코드나 실제 동작을 살펴봐야 합니다. 특히 배포 결과는 로컬 테스트와 별도로 확인해야 하며, 운영 중 발생한 사고도 다음 개선 작업의 입력이 됩니다.
앞의 출처 표시 예시에서는 단순히 링크 문자열이 화면에 있는지만 검사해서는 부족합니다. 인용한 문서가 실제 답변의 근거인지, 접근 권한이 없는 문서가 노출되지 않는지, 검색 결과가 없을 때 출처를 지어내지 않는지를 확인해야 합니다. 검증 기준을 이렇게 나누면 에이전트가 실패를 고칠 때도 방향을 더 분명히 제시할 수 있습니다.
에이전트 환경을 정리하면 같은 실수를 반복하지 않습니다
에이전트와 환경 맞춤화(customizing the agent and its environment) 는 필요한 자료와 도구에 접근할 수 있도록 작업 공간을 정리하는 일입니다. 원문은 스킬, 플러그인, MCP 서버를 연결하고 반복 작업을 훅으로 자동화하는 방식을 예로 듭니다. 더 이상 필요 없는 연결은 정리해 에이전트가 불필요한 도구 정의에 주의를 쓰지 않게 할 수 있습니다.
프로젝트의 구조와 핵심 가정, 코드 규칙, 데이터 접근 방식을 AGENTS.md나 CLAUDE.md 같은 지속 문맥에 기록하는 것도 여기에 포함됩니다. 여러 세션에서 확인한 사실과 사용자의 피드백을 보존하면 같은 조사를 다시 하지 않아도 됩니다. 팀에서는 서로 다른 개발자의 에이전트가 충돌하지 않도록 공통 규칙을 맞추는 문제도 생깁니다.
그러나 문맥 파일을 길게 만드는 것 자체가 목적은 아닙니다. 현재 코드와 어긋난 지시나 한 번 쓰고 끝난 절차는 오히려 오류를 만들 수 있습니다. 원문도 필요 없는 스킬을 덜어내고 에이전트가 만든 기술 부채를 정기적으로 정리할 필요를 언급합니다.
에이전트의 동작 원리를 알아야 개입 시점을 찾습니다
마지막으로 코딩 에이전트의 기초(coding agent foundations) 를 이해해야 합니다. 에이전트가 코드베이스를 검색하고, 컨텍스트 창을 관리하며, 모델 호출과 도구 호출을 반복하는 방식을 알면 실패 원인을 더 잘 찾을 수 있습니다. 원문은 하네스가 LLM을 감싸 에이전트의 동작을 구성한다고 설명합니다. 이는 여러 구현의 작동 방식을 설명하는 표현이지 모든 에이전트에 적용되는 단일한 표준 정의는 아닙니다.
대표적인 실패에는 간단한 일을 과하게 설계하는 것, 명시적인 검증 없이 완료를 선언하는 것, 목표에 이르기 전에 멈추는 것, 파일이나 운영 데이터를 위험하게 바꾸는 것이 있습니다. 에이전트가 어떤 자료를 읽었고 어떤 명령을 실행했는지 살펴보면 이런 징후를 더 빨리 발견할 수 있습니다.
Ng는 코딩 에이전트를 몇 시간씩 자율 실행하고 많은 토큰을 쓰는 방식의 효용이 과장되기 쉽다고도 지적합니다. 긴 실행이 필요한 작업도 있지만, 비용에 비해 유용한 결과가 나오는지 따져야 합니다. 그의 경험상 효과적인 사용은 작업을 잘 나누고 중간 결과를 보고 다시 지시하는 반복 과정에 가깝습니다.
배포와 관찰까지 이어져야 한 번의 작업이 끝납니다
원문의 세 번째 단계는 배포와 관찰(deployment and monitoring) 입니다. 지속적 통합 및 배포(CI/CD)와 사람의 확인 절차를 거쳐 변경을 내보내고, 에이전트로 로그를 살피며 문제를 찾아 개선안을 제안할 수 있습니다. 하지만 로그에 문제가 없다는 것만으로 사용자 경험이 정상이라고 단정할 수는 없습니다. 앞에서 정한 성공 기준을 실제 환경에서도 확인해야 합니다.
결국 코딩 에이전트 활용 역량은 명령을 잘 쓰는 재주만이 아닙니다. 계획의 깊이, 자율성, 검증 방식, 운영 권한을 작업의 위험에 맞게 조정하는 판단입니다. 마지막 글에서는 이렇게 빨라진 구현 능력을 바탕으로 무엇을 만들지 결정하는 역할까지 살펴봅니다.
코딩 에이전트 활용 역량 원문
AI Engineering Skills Map 전체 개요 원문
더 읽어보기
-
Andrew Ng의 AI Engineering Skills Map: AI 앱 구축과 운영 역량 (Building and deploying AI applications)
-
Andrew Ng의 AI Engineering Skills Map: 개발자의 소프트웨어 기본기(Software engineering fundamentals)
이 글은 GPT 모델로 정리한 초안을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 댓글로 알려주시기를 부탁드립니다. 
파이토치 한국 사용자 모임
이 정리한 이 글이 유용하셨나요? 회원으로 가입하시면 주요 글들을 이메일
로 보내드립니다! 텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로도 새 글 알림을 받으실 수 있습니다. 
아래
쪽에 좋아요
를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~ 