원문: https://velog.io/@playername_ltt/AI-에이전트로-개발-생산성-10배-높이기-Cursor-엔지니어-Lauren-Tan의-실전-노하우
AI 에이전트에게 작업을 맡기고 잠시 다른 일을 하려다가, 결국 터미널 앞에서 진행 상황을 지켜보고 있는 경우가 있습니다.
코드는 빠르게 만들어집니다. 하지만 방향이 맞는지 확인하고, 실행 결과를 살펴보고, 놓친 조건을 다시 설명하다 보면 생각보다 자리를 비우기 어렵습니다.
코드를 작성하는 시간은 줄었는데, 왜 여전히 바쁠까요?
에이전트가 작업하는 속도와 우리가 안심하고 일을 맡길 수 있는 범위는 다르기 때문일 겁니다. 생산성을 더 높이려면 이 간격을 줄일 방법이 필요합니다.
Cursor 엔지니어 Lauren Tan의 발표는 바로 이 문제를 다룹니다. Lauren은 발표 당시 Cursor에서 개발하고 있었으며, 이전에는 Meta에서 React Compiler를, Netflix에서는 테크 리드와 엔지니어링 매니저 역할을 맡았다고 소개합니다.
이번 글에서는 발표에 등장하는 검증 스킬과 자동화 사례를 살펴보면서, 에이전트에게 작업을 맡기기 위해 어떤 환경을 준비해야 하는지 이야기해보려고 합니다.
AI에게 오류 수정을 요청하면 이런 답변을 받곤 합니다.
원인을 찾았습니다. 수정했습니다.
그런데 다시 실행해보면 같은 오류가 발생합니다. 다른 곳을 수정하더니 이번에는 기존에 되던 기능까지 동작하지 않습니다.
이런 일이 반복되면 자연스럽게 AI의 작업을 하나하나 확인하게 됩니다.
지금 올바른 파일을 수정하고 있는가?
실제 원인을 찾은 것이 맞는가?
기존 구조를 무시하고 새로 만들고 있지는 않은가?
테스트를 실행한 것인가, 실행하면 된다고 설명한 것인가?
확인하는 것 자체는 필요합니다. 문제는 모든 작업이 내가 지켜보고 있을 때만 진행되는 상태입니다.
에이전트를 여러 개 실행해도 결과를 확인하는 사람이 나 한 명이라면, 어느 순간부터 검토할 작업만 쌓이게 됩니다.
저는 여기서 생산성의 기준을 조금 다르게 잡아야 한다고 생각합니다.
코드가 얼마나 빨리 만들어지는지도 중요하지만, 내가 계속 개입하지 않아도 어디까지 작업이 진행되는지를 함께 봐야 합니다.
그렇다고 갑자기 AI를 믿고 전부 맡길 수는 없습니다. 먼저 믿을 수 있는 근거가 필요하겠죠.
예를 들어 다음과 같이 요청했다고 해보겠습니다.
사용자 설정을 저장하면 화면에 바로 반영되지 않는 문제가 있습니다.
원인을 찾아 수정하고 테스트해주세요.에이전트가 관련 코드를 수정하고 단위 테스트를 실행했습니다. 테스트는 모두 통과했습니다.
이제 작업이 끝났다고 할 수 있을까요?
실제 화면에서 저장 버튼을 눌러봤는지, 새로고침해야만 변경 사항이 보이는 것은 아닌지, 다른 화면으로 이동했다 돌아와도 유지되는지는 별개의 문제입니다.
우리가 기대하는 검증과 에이전트가 수행한 검증의 범위가 다를 수 있는 겁니다.
그래서 검증에도 구체적인 절차가 필요합니다. 버그 수정이라면 변경 전에 문제가 재현되는지부터 확인해야 합니다. 수정 전에도 통과하던 검사만으로는 문제가 해결됐는지 판단하기 어렵기 때문입니다.
1. 개발 환경에서 테스트 계정과 데이터를 준비합니다.
2. 수정 전 설정 화면에서 문제를 재현하고 조건을 기록합니다.
3. 코드를 수정한 뒤 같은 조건으로 설정값을 변경하고 저장합니다.
4. 새로고침 없이 변경 사항이 화면에 반영되는지 확인합니다.
5. 페이지를 다시 불러오고, 조회 API에서도 저장한 값이 반환되는지 확인합니다.
6. 이 문제를 재현하는 회귀 테스트와 관련 기존 테스트를 실행합니다.
7. 실행한 명령, 기대값과 실제 결과, 확인하지 못한 항목을 보고합니다.이 예시는 제가 실무 적용을 위해 구성한 것입니다. 문제를 재현하지 못했다면 추정 원인과 확인된 사실을 구분하고, 수정 효과를 검증하지 못했다고 남겨야 합니다.
완료 조건은 구현 전에 정해두는 편이 좋습니다. 에이전트가 자신이 작성한 코드에 맞춰 기대값을 바꾸거나, 기존 테스트를 삭제하고 검사를 통과시키지는 않았는지도 확인해야 합니다.
핵심은 에이전트가 무엇을 실행하고, 어떤 상태를 확인해야 하는지 알 수 있도록 만드는 데 있습니다. 실행 환경에 접근할 수 없다면 그 이유를 보고해야 하고, 확인하지 못한 것을 통과했다고 처리해서도 안 됩니다.
발표에 등장하는 Control-Glass는 애플리케이션 실행과 조작, 트레이스 수집 등을 돕는 검증 스킬입니다. 여기서는 발표자의 구현 사례로 살펴보겠습니다. 그대로 설치해 사용할 수 있는 공개 도구라는 전제로 소개하는 것은 아닙니다.
직접 우리 프로젝트에 적용한다고 생각하면 이해하기 쉽습니다.
에이전트가 코드만 읽을 수 있다면 결과를 추론하는 데 머무를 수 있습니다. 실제로 실행하고 관찰할 수 있다면 자신의 예상과 다른 결과가 나왔을 때 다시 조사할 수 있습니다.
이런 과정을 반복하려면 실행 명령뿐 아니라 필요한 환경 설정, 테스트 데이터, 결과를 확인하는 방법도 준비되어 있어야 합니다.
Lauren은 Feature Map을 더해 에이전트에게 각 기능에 접근하는 방법까지 알려줍니다.
브라우저를 조작할 수 있는 도구를 연결했다고 해서 에이전트가 우리 서비스를 이해하는 것은 아닙니다. “예약 취소가 안 됩니다”라는 보고를 받았을 때 어떤 메뉴로 들어가야 하는지, 취소 가능한 예약을 어떻게 준비해야 하는지부터 알아야 합니다.
그래서 기능별로 다음 정보를 남겨둘 수 있습니다.
기능을 사용할 수 있는 화면과 접근 경로
필요한 계정 권한과 테스트 데이터
사용자가 수행하는 주요 동작
정상적으로 처리됐을 때 확인할 상태
자주 발생하는 예외 상황
백엔드라면 화면 대신 API 호출 순서, 인증 방법, 데이터 준비 과정, 응답과 저장 결과를 확인하는 방법이 될 수 있겠죠.
코드의 위치만 알려주는 것으로는 부족합니다. 사용자가 기능을 사용하는 과정과 개발자가 결과를 확인하는 방법까지 전달해야 합니다.
여기까지 읽으면 이런 생각이 들 수 있습니다.
이 정도면 검증 절차를 작성하는 일이 더 번거로운 것 아닌가?
한 번만 수행할 작업이라면 그럴 수 있습니다. 하지만 같은 기능을 수정할 때마다 같은 화면을 열고, 같은 데이터를 입력하고, 같은 결과를 확인한다면 이야기가 달라집니다.
그 과정을 이미 반복하고 있기 때문입니다. 다만 문서나 도구에 남아 있지 않고, 개발자의 머릿속에 들어 있을 뿐입니다.
저는 자동화를 이런 지점부터 시작하는 것이 좋다고 생각합니다.
처음부터 개발 과정 전체를 맡기기보다, 내가 매번 확인하는 작은 작업 하나를 정리합니다. 에이전트에게 수행하게 하고, 빠뜨린 부분을 확인하고, 절차를 보완합니다.
예를 들어 저장 성공만 확인하고 끝났다면 실패 응답을 받는 경우도 추가할 수 있습니다. 데이터가 없는 계정에서 계속 막힌다면 테스트 데이터를 준비하는 방법을 추가할 수 있습니다.
중요한 것은 이번 작업을 해결한 뒤 같은 설명을 다시 하지 않아도 되도록 만드는 것입니다.
이런 과정이 쌓이면 내가 하던 판단과 확인 절차의 일부가 에이전트의 작업 방식으로 남습니다.
발표에서 소개하는 Benny는 버그 리포트를 받아 클라우드에서 Cursor를 실행하고 재현을 시도하는 에이전트입니다. 이미 main 브랜치에서 해결된 문제임을 확인하는 사례도 등장합니다.
저는 이런 자동화가 꽤 실용적이라고 생각합니다.
버그를 처리할 때 시간을 쓰는 부분이 항상 코드 수정인 것은 아니기 때문입니다.
“저장이 안 됩니다”라는 보고를 받으면 우선 어떤 화면인지 찾아야 합니다. 어떤 계정과 데이터에서 발생하는지 확인하고, 현재 버전에서도 재현되는지 살펴봐야 합니다.
조사해보니 이미 수정됐지만 아직 배포되지 않았을 수도 있습니다. 특정 조건에서만 발생하는 문제일 수도 있고요.
이런 정보를 확보하는 과정만 자동화해도 개발자가 시작하는 위치가 달라집니다.
막연한 버그 리포트를 받아 처음부터 조사하는 대신, 재현 조건과 확인 결과를 보고 다음 행동을 결정할 수 있습니다.
모든 버그를 자동으로 수정해야만 가치 있는 자동화가 되는 것은 아닙니다. 반복적인 조사 시간을 줄이고, 판단에 필요한 정보를 준비해주는 것부터 충분히 의미가 있습니다.
발표에서는 Dune이라는 아키텍처와 강한 CI 규칙도 소개합니다. useEffect와 코드 주석을 금지하는 사례가 등장합니다.
물론 이 규칙을 그대로 복사할 필요는 없습니다. 모든 프로젝트에서 useEffect나 주석이 잘못된 선택이라는 뜻으로 받아들여서도 안 됩니다.
제가 중요하게 보는 부분은 프로젝트에서 반복적으로 발생하는 문제를 규칙으로 만들고, 실제 검사 과정에 반영했다는 점입니다.
우리 프로젝트라면 이런 규칙이 더 적절할 수 있습니다.
- 도메인 모듈은 외부 API 클라이언트에 직접 의존하지 않습니다.
- 데이터 접근은 정해진 계층을 통해서만 수행합니다.
- 타입 검사와 핵심 시나리오 테스트를 통과해야 합니다.
- 민감한 정보가 로그에 기록되면 안 됩니다.이 내용을 컨텍스트 파일에 적어두는 것만으로 끝내면 여전히 에이전트가 잘 기억하고 지켜주기를 기대하는 상태입니다.
자동 검사할 수 있는 규칙은 린터, 의존성 검사, 테스트 등에 연결하는 편이 좋습니다. 위반하면 CI가 실패하고, 에이전트가 그 결과를 보고 수정하도록 만드는 겁니다.
물론 자동 검사로 모든 설계 문제를 판단할 수는 없습니다. 그래서 검사할 수 있는 조건과 사람이 판단해야 하는 조건을 구분해야 합니다.
Lauren은 PR을 자동 병합하는 단계까지 갔다고 설명합니다.
이 결과만 보면 우리도 에이전트가 작성한 PR을 바로 병합하도록 설정하면 될 것처럼 보입니다.
하지만 먼저 생각할 것이 있습니다.
자동 병합을 허용할 변경 범위는 어디까지인가?
반드시 통과해야 하는 검사는 무엇인가?
검증 환경에 문제가 생기면 어떻게 중단할 것인가?
배포 후 문제가 발견되면 어떻게 되돌릴 것인가?
CI가 통과했다는 사실은 CI가 검사한 조건을 만족했다는 뜻입니다. 우리가 중요하게 생각하는 조건이 검사에 빠져 있다면, 초록색 표시만으로 충분하지 않습니다.
따라서 자동 병합을 목표로 한다면 먼저 완료 조건과 검증 범위를 구체화해야 합니다. 그 위에 병합과 배포 절차를 연결해야 하고요.
자동 병합은 변경의 위험과 팀 운영 방식에 따라 선택할 수 있는 옵션입니다. 검증을 자동화하고 병합 승인은 사람이 맡는 방식으로도 충분한 효과를 얻을 수 있습니다. 병합을 허용할 조건과 실제 배포를 허용할 조건도 따로 정해야 합니다.
영상에 등장하는 생산성 커브는 실측 통계가 아니라 Lauren이 자신의 경험을 표현한 그림입니다.
저는 이 그림을 자동화에 대한 투자가 언제 효과를 내는지 설명하는 것으로 받아들였습니다.
처음에는 에이전트가 하는 일을 계속 확인해야 합니다. 실행 환경을 준비하고, 검증 절차를 작성하고, 잘못된 결과가 나오면 다시 수정합니다. 당장 눈앞의 작업만 보면 직접 처리하는 편이 빠를 수도 있습니다.
하지만 그 과정에서 만든 도구와 규칙을 다음 작업에도 사용할 수 있다면 비용이 달라집니다.
매번 처음부터 설명하던 내용이 줄어들고, 사람이 확인하던 일부 항목을 에이전트가 먼저 확인하게 됩니다. 그만큼 다른 문제에 집중할 시간이 생깁니다.
이때 살펴볼 지표도 코드 생성량만으로는 부족합니다. 비슷한 유형의 작업을 대상으로 자동화 전후를 비교해보면 좋겠습니다.
확인할 항목 | 기록할 내용 |
|---|---|
사람의 투입 시간 | 지시, 개입, 리뷰와 재작업에 쓴 시간 |
완료까지 걸린 시간 | 작업 요청부터 검증 완료까지의 경과 시간 |
결과의 품질 | 재작업 발생 여부와 배포 후 발견된 결함 |
자동화 유지 비용 | 초기 환경 구축과 스킬·테스트 보완에 든 시간 |
처음부터 정교한 대시보드를 만들 필요는 없습니다. 반복 작업 몇 건에 간단히 기록하는 것부터 시작해도 됩니다. 다만 작업의 난이도가 크게 다른 사례끼리 비교하거나, 초기 구축 시간을 제외한 수치를 전체 생산성 향상으로 해석하지는 않아야 합니다.
PR이 많이 만들어져도 검토와 재작업이 더 늘었다면, 우리가 기대한 생산성 향상과는 거리가 있을 테니까요.
Lauren은 에이전트와 일하는 개발자를 여러 요리사를 이끄는 총괄 셰프에 비유합니다. 직접 모든 요리를 하기보다 주방을 구성하고 작업을 배분하는 역할입니다.
이 비유를 개발에 적용하면 우리가 해야 할 일이 조금 더 선명해집니다.
어떤 문제를 풀 것인지 정하고, 작업을 나누고, 필요한 맥락을 준비해야 합니다. 에이전트가 결과를 확인할 수 있는 도구를 제공하고, 중요한 판단은 직접 내려야 합니다.
그렇다고 구현을 이해할 필요가 없어지는 것은 아닙니다.
검증 조건이 충분한지 판단하려면 기능과 구조를 알아야 합니다. 테스트를 통과했지만 설계가 잘못된 경우도 구분할 수 있어야 하고요.
저는 이런 변화가 개발자에게 요구하는 엔지니어링의 범위를 넓힌다고 생각합니다.
코드를 어떻게 작성할지 고민하는 것과 함께, 에이전트가 올바르게 작업할 수 있는 환경을 어떻게 만들지도 고민해야 하는 겁니다.
제가 생각하는 개발 자동화의 핵심은 AI 에이전트가 나와 비슷한 사고과정으로 엔지니어링하도록 만드는 것입니다. 이를 실제 작업으로 옮기면, 문제를 재현하고 수정한 뒤 합의한 완료 조건을 검증하도록 만드는 일이 됩니다.
자주 발생하는 오류 하나나 반복해서 확인하는 화면 하나부터 시작해보면 좋겠습니다. 내가 확인하던 절차를 정리하고, 에이전트에게 맡긴 뒤, 결과의 품질을 유지하면서 내 개입과 재작업이 줄었는지 확인하는 겁니다.
효과가 있었다면 범위를 넓히고, 부족했다면 어떤 판단이나 정보가 빠졌는지 보완합니다.
생산성을 크게 높이고 싶다면, 코드를 생성한 다음에 어떤 일이 남아 있는지부터 살펴봐야 한다고 생각합니다.
작은 작업 하나를 실제로 끝까지 맡길 수 있는 환경을 만드는 것.
저는 거기서부터 시작하는 것이 좋겠습니다.
피드백은 언제나 환영합니다 :)