AI 엔지니어링 스킬 맵: 코딩 에이전트 활용
TMTAI 엔지니어링의 핵심 역량 가운데 하나는 코딩 에이전트를 다루는 능력입니다. 코드를 작성하게 하는 일뿐 아니라 데이터를 분석하거나 시스템 운영을 관리하는 것처럼 코드가 아닌 작업까지 에이전트에게 잘 지시할 수 있으면, 훨씬 더 많은 일을 해낼 수 있습니다.
코딩 에이전트가 워낙 빠르게 발전하기 때문에 이 역량 자체도 빠르게 변하고 있습니다. 다른 상위 AI 엔지니어링 역량들보다도 변화 속도가 빠릅니다. Claude Code, Codex, Cursor 같은 상용 에이전트와 OpenCode, Pi 같은 공개 에이전트 모두 하네스와 모델이 함께 개선되면서 성큼성큼 나아가고 있습니다. 그래서 코딩 에이전트를 어떻게 쓸지 계속 따라가려면 실험하고 만들고 배우는 과정을 끊임없이 반복해야 합니다.
최고 수준의 AI 엔지니어 수십 명을 인터뷰하고 저희 팀이 코딩 에이전트를 쓰는 방식을 돌아보면서, 에이전트로 소프트웨어를 만들 때 공통적으로 나타나는 큰 흐름의 작업 방식을 발견했습니다. 핵심 단계는 다음과 같습니다.
- 계획. 크게 두 가지로 나뉩니다. (i) 브레인스토밍인데, 여기에는 조사와 실험, 그리고 기존 코드베이스가 있다면 그 코드베이스를 파악하는 일까지 들어갈 수 있습니다. (ii) 요구사항과 기술 설계, 아키텍처를 담은 스펙을 쓰고, 이어서 실행 계획을 만드는 일입니다. 계획을 검토하면서 핵심 가정을 따져 보고 보안이나 과도한 설계, 그 밖에 빠뜨린 부분이 없는지 점검할 수도 있습니다.
- 실행. 에이전트의 자율성과 사람의 감독 사이에서 알맞은 균형을 잡으면서 만들고 시험하고 검증하는 단계입니다. (i) 자율성 수준을 적절히 조절한 상태로 에이전트에게 소프트웨어를 만들게 하고, (ii) 그 결과물을 자동 검사나 사람의 검사, 또는 둘 다로 검증합니다.
- 배포와 모니터링. (i) 배포를 하는데, 이때 CI/CD 파이프라인이나 사람이 승인하는 관문을 추가로 두기도 합니다. (ii) 그리고 에이전트를 써서 로그를 지켜보고 문제를 찾아내고, 개선안을 제안하고 실행하게 합니다.
이 큰 흐름은 코딩 에이전트가 없던 시절에 소프트웨어를 만들던 방식과 크게 다르지 않습니다. 달라진 점은 이제 코드에 쏟는 비중이 훨씬 줄고, 무엇을 만들지 결정하고 아키텍처를 설계하고 스펙을 쓰고 결과물을 검증하는 데 집중한다는 것입니다.
각 단계에 드는 시간은 프로젝트마다 크게 다르고, 아예 건너뛰는 단계도 있습니다. 예를 들어 처음부터 새로 만드는 그린필드 프로토타입이라면 스펙을 급하게 쓴 프롬프트 한 편에 느슨하게 담아도 됩니다. 반면 사용자가 많은 브라운필드, 즉 이미 돌아가고 있는 프로젝트라면 스펙을 쓰고 검증하는 데 훨씬 많은 공을 들여야 합니다. 게다가 이 작업 방식은 반복이 매우 잦아서, 숙련된 개발자는 뒤 단계에서 나온 피드백을 언제 앞 단계로 되돌려야 하는지 압니다. 예를 들어 검증이 실패하면 에이전트가 다시 만들고 오류를 고치도록 어떻게 지시해야 하는지 알고, 모니터링에서 문제가 드러나면 에이전트에게 시스템을 고쳐 다시 배포하게 하는 방법도 압니다.
이 작업 방식 안에서 코딩 에이전트를 제대로 쓰려면 다음 역량이 핵심입니다.
- 작업 흐름을 이끄는 능력
- 에이전트의 자율성을 살리는 능력
- 결과물을 검토하는 능력
- 에이전트와 그 환경을 손보는 능력
- 코딩 에이전트의 기본 원리
작업 흐름을 이끄는 능력. 위에서 말한 각 단계를 어떻게 헤쳐 나갈지 아는 것입니다. 단계마다 사람의 노력과 에이전트의 노력을 각각 어느 정도 들일지, 언제 앞 단계로 돌아가 다시 반복할지 판단해야 합니다. 그러려면 속도와 비용, 기술적 위험, 사람이 들이는 노력 사이의 상충 관계를 깊이 이해해야 합니다. 그래야 처음에 조사와 계획을 어디까지 할지, 중요한 작업의 주도권을 언제까지 사람이 쥐고 있을지, 아키텍처를 어떻게 고를지, 스펙 같은 계획 산출물에 세부 내용을 어느 정도까지 적을지, 작업을 검증할 수 있는 단계들로 어떻게 쪼갤지 결정할 수 있습니다.
에이전트의 자율성을 살리는 능력. 작업 흐름의 각 단계에 코딩 에이전트를 붙일 때는 자율성 수준을 골라야 합니다. 옆에서 지켜보며 주고받듯 진행할까요, 아니면 더 큰 덩어리의 일을 통째로 맡길까요? 목표만 분명히 정해 주고 성공할 때까지 알아서 반복하게 하는 건 언제가 좋을까요? 여기에 더해 에이전트의 컨텍스트를 세심하게 관리해야 합니다. 작업이 여러 국면을 지나는 동안, 핵심적으로 알게 된 내용과 사용자 피드백, 그리고 중간에 바뀐 가정까지 포함한 여러 가정을 언제 정리해 두어야 에이전트가 이후 단계에서 쓸 수 있는지 가늠하게 됩니다. 또 작업을 쪼개서 여러 에이전트를 병렬로 돌릴 시점도 정해야 합니다. 이때 조율은 사람이 맡을 수도 있고 상위 에이전트가 맡을 수도 있습니다. 동시에 돌아가는 여러 에이전트 세션에 사람의 주의를 어떻게 배분할지도 판단해야 합니다. 에이전트를 안전하게 돌리는 방법도 알아야 합니다. 권한을 알맞게 설정하고 위험한 동작에 관문을 두어, 개발은 빠르게 진행하면서도 정보 유출이나 데이터 손실, 그 밖의 피해가 생길 위험은 줄이는 것입니다.
결과물을 검토하는 능력. 코딩 에이전트가 내놓는 결과는 미리 알기 어렵습니다. 어떤 좋은 아이디어를 떠올릴지, 어떤 버그를 심어 놓을지 알 수 없습니다. 그래서 결과물을 검토하고 검증하는 일이 원하는 결과를 얻는 데, 그리고 그렇지 않을 때 에이전트의 방향을 다시 잡아 주는 데 핵심입니다. 작업에 맞는 테스트와 검증 방식을 설계하고, 필요에 따라 동작 검증과 기능 검증을 함께 적용합니다. 사용자 흐름을 직접 시험해 볼 수도 있는데, 이때 에이전트에게 성공이나 실패의 증거로 스크린샷을 받는 방법도 있습니다. 정성적인 동작 평가에는 평가 세트를 쓸 수 있고, 여기에 LLM을 심판으로 두는 방식(LLM-as-a-judge)을 곁들일 수도 있습니다.
이 테스트를 어디까지 자동화할지도 정해야 합니다. 어떤 작업 방식에서는 테스트와 검증을 전부 자동화해서, 에이전트가 스스로 결과를 확인하고 작업을 제대로 끝냈는지 판단하게 합니다. 테스트가 정말 목표에 부합하는지 평가해야 하고, 그렇지 않다면 테스트를 계속 다듬어 나갑니다. 여기에 더해 에이전트를 활용한 코드 리뷰를 하고, AI 기반 보안·아키텍처 감사도 돌립니다. AI 검토만으로 부족할 때는 코드가 실제로 어떻게 동작하는지 사람이 직접 보는 검토를, 드물게는 코드 자체를 보는 검토까지 신중하게 끼워 넣고, 동시에 이 검토를 어떻게 더 자동화할지 계속 찾아봅니다. 마지막으로 배포가 제대로 됐는지 확인하고, 모니터링과 장애 대응을 에이전트로 운영할 수 있습니다.
에이전트와 그 환경을 손보는 능력. 에이전트 자체와 에이전트가 일하는 환경을 함께 고칠 수 있으면, 에이전트가 필요한 컨텍스트를 효율적으로 얻고 도구에 접근하며 올바르고 효율적으로 만들어 냅니다. 에이전트 스킬과 플러그인, MCP 서버를 붙이는 방법을 알아야 합니다. 더 이상 필요가 없어지면 이따금 정리하기도 합니다. 새 모델이 나와서 기존 스킬이 필요 없어지는 경우가 그렇습니다. 훅을 써서 개발 과정에서 반복되는 부분을 자동화할 수도 있는데, 코드 리뷰를 자동으로 돌리거나 CI/CD 파이프라인을 실행하는 일이 여기에 해당합니다. 에이전트가 일하는 환경을 관리하는 것도 포함됩니다. AGENTS.md나 CLAUDE.md처럼 늘 유지되는 컨텍스트에 코드베이스 정보와 핵심 아키텍처 가정, 코드 스타일, 데이터 접근 패턴을 최신 상태로 적어 두는 것입니다. 여러 세션과 병렬로 돌아가는 여러 에이전트 사이에 상태를 어떻게 보존할지, 그리고 에이전트가 배운 것을 시간이 지나면서 어떻게 쌓아 갈지도 알아야 합니다. 실행이 끝난 뒤 회고를 돌려 무엇이 통했고 무엇이 통하지 않았는지 정리하는 방법도 있습니다. 코드베이스를 에이전트가 잘 돌아다닐 수 있도록 일관된 관례와 구조를 세우는 방법, 그리고 에이전트가 만들어 놓은 부채를 이따금 걷어내는 방법도 알아야 합니다. 팀으로 일한다면 개발자마다 쓰는 에이전트 사이에서 컨텍스트를 어떻게 맞출지도 고민하게 됩니다.
코딩 에이전트의 기본 원리. 마지막으로, 이 모든 과정에서 좋은 판단을 내리려면 코딩 에이전트가 어떻게 동작하는지 잘 이해하고 있어야 합니다. 코드베이스를 어떻게 검색하고 가져오는지, 컨텍스트 윈도우를 어떻게 관리하는지, 도구 호출이나 MCP 서버를 추가하는 것처럼 서로 다른 작업이 컨텍스트에 어떤 영향을 주는지, 에이전트와 서브에이전트가 서로 어떻게 맞물려 돌아가는지, 그리고 LLM을 하네스로 감싸서 에이전트를 만든다는 것이 어떤 구조인지 알아야 합니다. 이렇게 알고 있으면 에이전트가 블랙박스처럼 느껴지는 정도가 줄고, 에이전트가 어떤 식으로 실패하는지 알아차리는 데도 도움이 됩니다. 간단하면 되는 해결책을 과도하게 설계하거나, 명시적인 검증 절차가 없어서 엄밀함을 잃거나, 목표에 못 미친 채 멈추거나, 파일이나 운영 데이터를 망가뜨릴 위험이 있는 동작을 하는 경우가 그렇습니다. 에이전트가 지금 어떤 상태인지 헤아리고, 알맞은 처방이나 컨텍스트를 주어 방향을 잡아 주는 데도 도움이 됩니다. 그리고 실행 과정을 지켜볼 때, 에이전트가 언제 궤도를 벗어나 사람이 개입해야 하는지 더 잘 알아볼 수 있습니다.
소셜 미디어에서는 코딩 에이전트를 쓰는 법을 지나치게 단순하게 설명하는 경우가 많다고 느낍니다. 예를 들어 에이전트를 몇 시간 동안 알아서 돌게 하면서 수백만에서 수천만 토큰을 쓰는 방식이 유용할 때도 분명 있습니다. 하지만 지금으로서는 아주 긴 시간에 걸친 작업이 실제로 얼마나 쓸모가 있는지, 특히 들어가는 비용에 견주면 얼마나 쓸모가 있는지가 실제보다 부풀려져 있습니다. 오히려 효과적인 코딩 에이전트 활용은 대부분 복잡하고 반복이 잦은 과정이며, 숙련된 판단으로 중간에 개입할 수 있을 때 훨씬 좋은 결과가 나옵니다.
코딩 에이전트를 다루는 역량은 여러분을 유능한 빌더로 만들어 줍니다. 그러면 개발 전체를 이끄는 자리에도 서게 됩니다. 이 이야기는 다음 글에서 더 자세히 다루겠습니다.
