배경
시작은 팀 리더와의 1:1 미팅 몇 차례였습니다. 리더는 제가 AI 도구를 어떻게 활용하고, 개인용 Harness 를 어떻게 구축하며, AI 코딩 워크플로를 어떻게 구조화하는지에 관심이 많았습니다. 제가 요구사항을 빠르고 정확하게 구현해 내고 있고, 이미 일부 프로젝트의 메인 오너 역할을 맡고 있었기 때문입니다. 그래서 이 기회를 틈타 저의 일상적인 AI 워크플로를 한번 정리해 보기로 했습니다. 현재 저는 그룹 내에서 기존 백엔드 비즈니스 로직을 유지보수하면서 주로 Agent 개발을 담당하고 있습니다.
이전에 샤오홍슈(Xiaohongshu)에서 관련 워크플로를 공유한 적이 있습니다. 당시의 맥락은 GPT-5.4 와 Opus 4.6 이 정확한 컨텍스트와 합리적인 제약 조건만 주어지면 이미 작업을 훌륭하게 완수할 수 있다는 것이었습니다. Harness Engineering 의 부상으로 모두가 깨달은 사실이 하나 있습니다. 바로 제약 조건을 추가함으로써 강력한 모델을 더 잘 통제할 수 있다는 점입니다.
예를 들어 Superpowers 같은 Skills 는 비교적 무거운 구현 방식을 제공하며, 주로 Spec 과 TDD 를 중심으로 사람들이 더 쉽게 작업을 정리하고 진척시킬 수 있도록 돕습니다.
하지만 여기에는 단점도 있습니다. 가장 체감되는 부분은 Token 소모가 매우 빠르다는 것입니다. Superpowers 같은 Skills 에는 모델의 다음 행동을 제한하기 위한 수많은 Workflow 가 포함되어 있습니다. 전체적인 관점에서 특정 단계가 더 이상 필요하지 않더라도(예: 컨텍스트가 충분해서 바로 구현에 착수할 수 있는 상황), 모델은 여전히 정해진 프로세스를 따라 실행을 이어갈 수 있습니다.
새로운 모델들이 출시되면서, 많은 개발자들이 이런 무거운 Skills 를 사실상 더 이상 사용하지 않는다고 공유하기 시작했습니다. 주된 이유는 모델의 성능이 향상되면서, 우리가 원래 유용하다고 생각했던 일부 제약과 프로세스가 오히려 모델에게는 노이즈가 되고 있기 때문입니다. 예를 들어 OpenAI 가 Astra 를 출시했을 때, 불필요한 Skills 와 시스템 프롬프트를 정리하여 모델 사용 경험을 개선하는 방법을 소개하는 블로그 글을 따로 작성하기도 했습니다.
그래서 이번 글에서는 지난 몇 달간 제가 직접 적용해 온 실무 경험을 바탕으로, 현재 저에게 효과적으로 작동하는 방법들을 공유하고 다양한 Agent 를 활용해 일상적인 개발 효율을 어떻게 높일 수 있는지 이야기해 보려 합니다.
1. 제가 자주 사용하는 Skills 와 Prompts
현재 제가 사용하는 도구 구성은 다음과 같습니다.
코딩 구현에는 주로 Codex + GPT-5.6 Sol 을 사용하고, 기획에는 Astra 를 사용합니다. Astra 가 출시되기 전에는 기획 업무를 주로 GPT-5.6 Sol Max 에 맡겼습니다.
단순한 요구사항은 pi + DeepSeek V4 Flash 로 구현하며, 솔루션에 대한 적대적 리뷰(Adversarial Review)와 Code Review 는 주로 Claude 5 Fable 이 담당합니다. 개인 프로젝트에서는 웹 기반 GPT-6 Pro 를 사용해 메인 솔루션을 설계하기도 합니다.
자주 사용하는 Skills
- think: tw93 의 Skill 로, 주로 솔루션 방향성 일치와 브레인스토밍에 사용합니다.
- grill me / grill with docs: 주로 요구사항 명확화에 사용합니다. 끊임없는 질문을 통해 목표, 제약 조건, 트레이드오프를 명확히 하고, 개발 프로세스 필요에 따라 이를 ADR 이나 CONTEXT.md 로沉淀(정리 및 기록)시킵니다. 초기 방향성 조율 과정에서 미처 고려하지 못한 이슈를 파헤치는 데 큰 도움이 됩니다.
- implement: grill 과 함께 사용하며, Matt Pocock 의 Skills 스위트 중 하나입니다. 명확히 정의된 계획이나 Issue 를 구현할 때 씁니다.
- ponytail: AI 의 과도한 설계를 정리하여 Review 난이도를 낮추는 데 사용합니다. GPT-5.6 Sol 이 종종 과잉 설계를 하는 편이라 제가 아주 자주 쓰는 Skill 입니다.
- handoff: 현재 컨텍스트를 파일로 정리해 새로운 세션에서 작업을 이어가기 쉽게 만듭니다. 보통 Codex 에서 Claude Code 나 pi agent 로 작업을 넘길 때 사용합니다.
- check: 코드 리뷰에 사용하며, 주로 MR 을 제출할 때 활용합니다.
- 업무 및 개인 개발 과정에서 축적한 Skills: 주로 재사용 가능한 프로세스 SOP(예: 엔드투엔드 테스트) 등입니다. 제 조언은 이렇습니다. 일상 업무에서 어떤 프로세스가 세 번 이상 반복된다면, Codex 에게 이를 Skill 로 정리해 달라고 요청해 나중에 바로 재사용하는 것을 고려해 보세요.
자주 사용하는 Prompts
요즘은 제가 직접 긴 Prompt 를 작성하는 일이 드뭅니다. 필요할 때는 보통 Codex 에게 정리를 맡깁니다. 예를 들어 여러 차례 논의를 거친 후, 현재 컨텍스트를 GPT Pro 에 넘겨 솔루션 설계를 맡기고 싶다면 먼저 Codex 에게 완전한 handoff Prompt 를 생성하게 합니다.
그 외에 저는 다음과 같은 아주 짧은 Prompt 들을 자주 사용합니다.
때로는 "짧은 한마디가 천 마디 말보다 낫다"는 효과를 냅니다. 저는 이를 모델의 "사고 지름길"이라고 이해합니다.
마법 주문이 아니라, 인간의 지식 속에서 고도로 표준화된 방법론들입니다. 모델은 학습 과정에서 이와 관련된 방대한 논문, 코드, 설계 문서, 토론을 이미 접했기 때문에 수백 줄짜리 Workflow 를 직접 작성할 필요가 없는 경우가 많습니다. 그저 어떤 사고방식을 채택할지 알려주기만 하면 됩니다. 다음은 제가 실무를 통해 매우 효과적이라고 느낀 프롬프트들입니다.
- 제1원리(First Principles): 기존 솔루션을 계속 개선하려 하지 말고, 이 문제를 실제로 어떻게 해결해야 하는지 다시 묻습니다. 예를 들어 인터페이스가 느리다면 이렇게 말할 수 있습니다.
"Redis 캐시 추가"라는 기정사실화된 솔루션을 기반으로 계속 설계하지 마세요. 제1원리에 입각해 이 인터페이스가 왜 느린지, 그리고 최소한으로 필요한 솔루션은 무엇인지 분석하세요.
그러면 모델의 초점은 "Redis 를 어떻게 설계해야 할까"에서 다음으로 바뀝니다.
병목이 SQL, 네트워크, 직렬화, 락 경합, 아니면 반복 계산에 있나요? SQL 에 인덱스를 추가하면 해결될 문제라면 왜 Redis 를 도입하나요?
이런 유형의 Prompt 는 "질문 자체가 잘못되었을지도 모른다"고 의심될 때 적합합니다.
- 적대적 리뷰(Adversarial Review): 내 솔루션이 맞을 이유를 찾지 말고, 틀렸음을 증명하려고 시도하세요.
평범한 질문 방식은 이렇습니다.
이 기술 솔루션에 문제가 없는지 확인해 주세요.
이를 다음과 같이 바꿀 수 있습니다.
이 솔루션에 대해 적대적 리뷰를 수행하고, 핵심 가정을 뒤집을 수 있는 반례를 찾는 것을 최우선으로 하세요.
당신의 솔루션이 "중복 요청을 해결하기 위해 분산 락 도입"이라고 가정해 봅시다. 그러면 모델은 단순히 락 타임아웃 설정 방법을 알려주는 데 그치지 않고, 다음과 같이 질문을 던지기 시작합니다.
중복 요청에 정말 상호 배제가 필요한가요? 인터페이스 멱등성으로 해결할 수 있지 않나요? 락 서비스가 다운되면 어떻게 되나요? 락은 만료되었는데 비즈니스 실행이 끝나지 않았다면요? 로컬 문제를 해결하려고 새로운 분산 장애점을 만든 건 아닌가요?
이런 Prompt 는 특히 솔루션 리뷰와 Code Review 에 적합합니다.
- 절제 실험(Ablation Experiments): 시스템이 좋아졌다고 해서 당신이 추가한 모든 것이 유용하다는 뜻은 아닙니다.
예를 들어 한 번에 세 가지 최적화를 진행했다고 해 봅시다.
인덱스, Redis 캐시, 배치 쿼리를 추가한 후 인터페이스 지연 시간이 800ms 에서 100ms 로 감소했습니다.
이때 바로 이렇게 물어볼 수 있습니다.
이 세 가지 최적화에 대한 절제 실험을 설계하여 실제 성능 향상이 어디서 오는지 파악하세요.
모델은 Baseline 을 시작으로 다양한 조합을 둘러싼 대조군을 설계합니다. 인덱스만 추가한 경우, 인덱스 + 캐시, 인덱스 + 캐시 + 배치 쿼리 등을 비교하겠죠.
최종적으로 다음과 같은 결론을 낼 수도 있습니다.
인덱스만 추가해도 지연 시간이 800ms 에서 120ms 로 줄었고, 나머지 두 가지 복잡한 솔루션은 겨우 20ms 만 기여했습니다.
이렇게 되면 어떤 코드를 유지할 가치가 있고 어떤 복잡성은 불필요할 수 있는지 훨씬 명확해집니다.
- 오컴의 면도날(Occam's Razor): 효과가 비슷하다면 가정이 적고 복잡도가 낮은 솔루션을 우선시하세요.
예를 들어 Agent 가 다음과 같은 솔루션을 설계했다고 합시다.
Kafka + Redis + 분산 락 + 상태 머신 + 주기적 보상 트랜잭션.
여기에 한 마디만 덧붙이면 됩니다.
오컴의 면도날을 적용해 이 설계를 다시 검토하고, 요구사항을 충족한다는 전제하에 필수적이지 않은 메커니즘은 모두 삭제하세요.
그러면 대부분 최종적으로 이런 결론에 도달합니다.
현재 시나리오는 단일 데이터베이스 쓰기만 포함하므로, 하나의 트랜잭션과 유니크 인덱스로 충분합니다.
이 한 마디는 요즘 Coding Agent 들에게 특히 유용합니다. 모델들이 '완벽함'을 추구하다가 과잉 설계를 하기 쉽기 때문입니다.
- 높은 응집도, 낮은 결합도(High Cohesion, Low Coupling): 코드의 책임과 경계를 다시 점검하세요.
예를 들어 OrderService 가 벌써 2000 줄이 되었다는 걸 발견했다면 이렇게 물어볼 수 있습니다.
높은 응집도와 낮은 결합도 원칙에 따라 OrderService 의 책임 경계를 검토하세요. 분리만을 위한 분리는 하지 마세요.
그러면 모델은 보통 다음과 같은 점검을 시작합니다.
왜 주문 서비스가 재고, 쿠폰, SMS, 결제, 리포트를 동시에 처리하나요? 어떤 로직이 주문 도메인 자체에 속하고, 어떤 로직이 안정적인 인터페이스를 통해 다른 모듈로 넘어가야 하나요?
이는 단순한 '파일 쪼개기'가 아니라 모듈화, 정보 은닉, 의존성 방향, 책임 분할에 관한 일련의 판단을 활성화합니다.
그래서 저는 더 이상 이런 식으로 작성하지 않습니다.
1단계 요구사항 분석, 2단계 가정 검증, 3단계 대안 탐색, 4단계...
이미 성숙한 많은 방법론을 모델이 학습하고 있습니다. 저는 차라리 직접 이렇게 말하는 것을 선호합니다.
제1원리부터 다시 분석하고 현재 솔루션에 대해 적대적 리뷰를 수행하세요. 핵심 메커니즘은 반드시 절제 실험을 통해 검증해야 하며, 솔루션은 오컴의 면도날을 따르고 코드는 높은 응집도와 낮은 결합도를 유지해야 합니다.
이 수십 단어 뒤에는 사실 다섯 가지 서로 다른 인지적 행동이 지정되어 있습니다.
문제 재정의 → 가정 공격 → 기여도 검증 → 복잡성 제거 → 시스템 경계 정리.
제가 이해하는 새로운 모델 시대 Prompt Engineering 의 변화이기도 합니다. 모델을 위해 완벽하고 고정된 사고 과정을 작성해 주기보다는, 정확한 방법론을 사용해 "어떤 방식으로 생각할지" 알려주고, 현재 작업에 정말로 필요한 제약 조건만 추가로 제공하는 것이 낫습니다.
2. 나의 일상적인 개발 워크플로
요구사항을 받으면 보통 먼저 PRD, 회의록, 채팅 기록, 사용자 피드백 등 관련 컨텍스트를 Agent 에게 넘기고, grill 을 사용해 요구사항 방향성을 맞춥니다.
이 자료들은 흔히 완전하고 일관된 하나의 요구사항이 아닙니다. PRD 가 업데이트되지 않았을 수도 있고, 회의 중에 일부 제한 사항이 추가되었거나 채팅에서 우선순위가 조정되었을 수도 있습니다. 저 스스로의 요구사항 이해에도 명시되지 않은 가정이 섞여 있을 수 있습니다.
Agent 가 팀 Wiki 와 기존 코드를 참고해 이 자료들을 이해하게 한 뒤, 끊임없는 질문을 통해 구현에 영향을 미치는 목표, 경계, 트레이드오프를 명확히 합니다. 어떤 질문은 제가 즉시 답할 수 있지만, 어떤 것은 돌아가서 PM 이나 관련 동료에게 확인해야 합니다.
여기서 저는 하나의 기준을 지킵니다. 남은 질문들이 구현 방향과 인수 결과를 크게 바꾸지 않을 정도가 되면 개발을 시작합니다.
모든 구현 세부 사항을 미리 기획하도록 요구하지는 않습니다. 그렇지 않으면 요구사항 조율 과정 자체가 너무 무거워지기 때문입니다.
조율이 끝난 결론은 Spec 이나 CONTEXT.md 로 정리합니다. 주로 이번에 해결할 문제, 범위, 주요 결정 사항, 인수 조건을 기록합니다. 이렇게 하면 이후 구현과 리뷰를 담당하는 Agent 들도 동일한 컨텍스트를 공유할 수 있어 이전 대화를 전부 다시 읽을 필요가 없습니다.
솔루션이 결정되면 작업 복잡도에 따라 메인 Agent 가 실행 방식을 결정하게 합니다. 단순한 요구사항은 바로 구현하고, 복잡한 요구사항은 경계가 명확하고 독립적으로 인수 가능한 Issue 로 분리합니다. 독립적으로 진행할 수 있는 부분만 subagent 에게 넘겨 각기 다른 worktree 에서 병렬 개발을 진행하고, 마지막으로 메인 Agent 가 통합합니다.
코딩 Agent 가 먼저 테스트를 완료합니다. 납품 준비가 되었다고 판단되면, 작업 복잡도에 따라 다른 Agent 들을 투입해 교차 적대적 리뷰를 진행합니다. 발견된 이슈는 메인 코딩 Agent, 즉 Codex 에 일괄 피드백되어 수정 및 재검증을 거칩니다.
제가 직접 Review 하기 전에도 엔드투엔드 테스트를 수행합니다.
현재 저는 생성된 코드를 한 줄씩 전부 읽지는 않고, 주로 테스트 결과와 핵심 비즈니스 로직을 살펴봅니다. 여기에는 중요한 전제 조건이 있습니다. 각 MR 의 범위가 충분히 작아야 하고, 개발이 진행됨에 따라 완전한 비즈니스 경로가 점진적으로 검증되어야 한다는 것입니다.
작은 MR 은 매번 이해하고 판단해야 하는 변경 사항을 통제 가능한 범위 내로 유지시켜 줍니다. 엔드투엔드 테스트는 이러한 변경 사항이 실제 비즈니스 프로세스에 놓였을 때도 버텨내는지 확인하는 데 도움을 줍니다. 수동 Review 시에는 비즈니스 로직을 확인하고, 기존 테스트 결과가 이번 배포를 뒷받침하기에 충분한지 집중적으로 점검합니다.
3. Agent 친화적인 엔드투엔드 테스트 구축하기
AI 는 이미 테스트 케이스를 아주 잘 작성합니다. Bugfix 하나에 수백 줄의 테스트를 짜는 경우도 흔합니다(특히 5.6 sol). 테스트를 많이 작성하는 것 자체가 문제는 아니지만, 배포 및 출시 후에도 여전히 예상치 못한 오류를 마주하게 됩니다.
제 경험상 핵심적인 문제 중 하나는 Agent 에게 엔드투엔드 테스트 환경을 제공하지 않아, 코딩 및 자체 테스트 단계에서 이러한 문제를 발견할 기회를 주지 못한다는 점입니다.
이런 환경을 구축하여 Agent 가 테스트 환경의 실제 진입점에서부터 편리하게 작업을 실행하고, 사용자가 필요로 하는 결과까지 쭉 확인할 수 있게 된다면 우리는 AI 가 작성한 코드가 실제 시스템에서 돌아가도록 자신 있게 맡길 수 있습니다.
실제 개발에서 저는 저희 비즈니스를 위한 엔드투엔드 개발 테스트 환경 세트를 구축했습니다. Agent 는 데이터베이스 테이블과 로그를 손쉽게 조회하고, 머신에 접속해 문제를 해결할 수 있습니다.
전체 구축 과정은 본질적으로 Agent 가 저의 일상적인 개발 자가 테스트 프로세스를 추출하고, 흩어진 도구와 역량을 통합하도록 만드는 것입니다. 도구화할 수 있는 기능은 MCP 나 CLI 로 만들고, 재사용 가능한 프로세스는 Skills 로 작성합니다.
물론 초반에 어느 정도의 노력은 필요합니다. 하지만 번거로움을 두려워하지 마세요. 일단 구축해 두면 개발 속도가 눈에 띄게 빨라지고 재작업 및 운영 환경 이슈 가능성이 줄어들며, AI 가 짠 코드가 사고를 치지 않을까 하루 종일 전전긍긍할 필요도 없어집니다.
Agent 친화적인 엔드투엔드 테스트를 위해 저는 주로 네 가지를 진행했습니다.
- Agent 가 환경에 익숙해지도록 만들기: 테스트 환경 원클릭 구동 지원, 테스트 데이터 생성, 현재 버전/테스트 계정/권한 명확화, 정리 및 초기화 기능 제공 등.
- Agent 가 비즈니스 시스템을 조작하도록 만들기: 브라우저, API 또는 CLI 를 통해 실제 비즈니스 프로세스를 실행.
- Agent 가 데이터베이스 테이블과 로그를 편리하게 조회하도록 만들기: 읽기 전용 데이터베이스 MCP 를 통해 저장 결과 확인, 로그 시스템 Skills 와 Trace 조회를 통한 문제 위치 파악.
- 번거롭지만 안정적인 프로세스 재사용: 안정적인 작업은 스크립트로 작성하고, 진입점과 문제 해결 방법은 Skills 로 정리하여 반복적인 수동 개입과 대화를 줄임.
이러한 작업을 바탕으로, 현재 제가 효과적이라고 느끼는 몇 가지 방법은 다음과 같습니다.
- 브라우저 자동화: 비즈니스 시스템에 브라우저 조작이 필요하다면 오픈소스 브라우저 ego lite 를 추천합니다. 사용하기 편리하고 빠릅니다. pi agent + DeepSeek V4 Flash 와 조합하면 테스트를 비교적 빠르게 완료하여 테스트 시간을 단축할 수 있습니다.
- CLI 로 작업 통합: 재사용 가능한 Skills, 구성된 MCP, 작성된 스크립트를 통합된 테스트 CLI 로 묶어 환경 점검, 데이터 준비, 시나리오 실행, 결과 조회, 정리 기능을 제공합니다. 이는 사내 효율성 도구가 될 수도 있습니다. 현재 저는 이 세트를 CLI 로 만들어 두었는데, 문제가 발생했을 때 트러블슈팅하기에도 아주 편리합니다.
- 도구가 인수를 직접 지원하게 하기: DB 조회는 상태 확인에, 로그와 Trace 는 실패 원인 설명에 사용되지만, 기대 결과는 여전히 비즈니스 계약에서 나와야 합니다. 시스템이 반환한 값을 봤다고 해서 Agent 가 그것을 정답이라고 짐작하게 두지 마세요. 복잡한 비즈니스 로직 하에서는 시스템이 겉보기엔 그럴듯하지만 실제로는 규격에 맞지 않는 결과를 완전히 틀리게 반환할 수도 있습니다. 도구는 증거를 확보하는 데 도움을 줄 뿐, 우리를 대신해 정답을 정의하지는 않습니다.
- 제품 자체가 Agent 라면 답변 품질도 점검하기: 테스트 대상 제품이 그 자체로 Agent 라면, 비즈니스 프로세스가 끝까지 돌아가는지 여부 외에도 답변 품질을 고려해야 합니다. 흔히 말하는 Agent Eval 인데, 여기서는 자세히 다루지 않겠습니다.
4. AI 가 작성한 코드 Review 하기
앞서 AI 가 고품질 코드를 작성하게 만드는 방법을 공유했지만, 결국 비즈니스 요구사항에 대한 1차 책임자는 개발자 본인입니다.
Review 없이는 대규모 시스템에서 문제가 발생하기 쉽습니다.
한밤중에 On-call 호출을 받고 일어나서 보니 AI 가 짠 코드 때문이었다는 상황을 겪고 싶지는 않으실 겁니다.
Review 와 관련하여 현재 제가 주로 실천하는 방법은 다음과 같습니다.
- 인수 조건을 먼저 보고 그다음 테스트 결과 확인: 먼저 Agent 가 제시한 인수 조건을 확인한 뒤, 이전 엔드투엔드 테스트 결과와 비교하여 기대치가 충족되었는지, 누락된 부분은 없는지 점검합니다. 단순히 테스트가 몇 개 통과했는지만 보지 말고, 해당 테스트들이 이 요구사항이 진정으로 중요하게 여기는 부분을 검증했는지 살펴봐야 합니다.
- 비즈니스 경로를 따라 구현을 살펴보며 고위험 부분에 집중: 저는 주로 권한, 상태 변경, 동시성, 재시도, 데이터 정합성, 마이그레이션 및 롤백 같은 고위험 부분을 점검합니다. 안정된 패턴의 CRUD 에는 시간을 덜 쓸 수 있으며, 요즘은 이 중 일부를 아예 보지 않기도 합니다.
- 새로 추가된 추상화와 메커니즘 집중 점검: 새로 추가된 추상화와 메커니즘에 대해서는 오컴의 면도날 같은 사고방식을 활용해 AI 에게 다시 리뷰를 시킵니다. 정말 필요한 것인지, 더 간단한 구현 방법이 없는지, 국지적인 문제를 위해 지나치게 많은 복잡성을 도입한 것은 아닌지 묻습니다.
- MR 이 많다면 전용 Review Bot 구축 고려: 그룹 내 MR 이 많다면 교차 리뷰를 처리할 전용 Review Bot 을 설계할 수 있습니다. 앞서 언급한 pi agent / Claude Code 를 직접 호출해 적대적 리뷰를 하는 것과는 다릅니다. Git 변경 정보와 사전 설계된 리뷰 프로세스를 결합하여, MR 에 특화된 반복 가능한 리뷰 역량을 형성하는 데 중점을 둡니다.
5. 요약 및 생각
현재 제 개발 과정에서 가장 뚜렷한 병목은 Review 속도입니다.
Agent 는 여러 작업을 동시에 추진할 수 있지만, 제가 비즈니스를 이해하고 솔루션을 판단하며 납품을 확인하는 속도는 그에 비례해 늘어나지 않습니다. 그냥 더 많이 짜게만 둔다면, 결국 리뷰를 기다리는 코드만 잔뜩 쌓일 가능성이 큽니다.
그래서 다음으로 제가 개선하고 싶은 것은 반복적인 이슈가 제 손에 닿기 전에 발견되고 수정되도록 만드는 것입니다.
타입 검사, 테스트, 비즈니스 어설션을 통해 찾을 수 있는 이슈는 개발 단계에서 Agent 가 최대한 스스로 처리해야 합니다. 제 판단이 필요한 부분은 요구사항을 올바르게 이해했는지, 핵심 비즈니스 로직이 타당한지, 이번 변경 사항에 아직 검증되지 않은 위험이 무엇인지 등에 집중됩니다.
전용 Review Bot 이 이런 일을 돕는 데 유용하지만, 그 가치는 단순히 댓글을 몇 개 남겼느냐가 아니라 유효한 이슈 누락과 수동 작업 부담을 실제로 줄여주느냐에 달려 있습니다.
이러한 과정을 거치며 Harness 에 대한 제 이해도 점차 구체화되었습니다. Agent 에게 올바른 컨텍스트를 제공하는 것 외에도, 작업을 실행할 수 있는 환경과 결과를 판단할 근거가 필요하다는 점입니다.
저는 일상적인 자가 테스트에서 반복하던 작업들을 CLI, 스크립트, Skills 로 정리하여, Agent 가 스스로 시스템을 실행하고 결과를 확인하며 실패 증거를 찾도록 만들었습니다. 앞으로 유사한 작업에서도 이러한 역량을 계속 활용할 수 있고, 점차 다른 동료들에게 넘겨 재사용하게 할 수도 있습니다.
동시에 이 워크플로도 정기적으로 덜어내는 과정이 필요합니다.
일부 단계는 특정 세대 모델의 부족한 점을 보완하기 위한 것입니다. 모델이 바뀌면 이러한 단계들의 효용은 재평가되어야 합니다. 단순한 작업은 바로 처리하고, 복잡한 작업에는 기획, 분리, 교차 리뷰를 추가합니다. 예를 들어 Astra 업데이트 이후 저는 AGENTS.md 에서 지나치게 엄격한 제약 조건 일부를 삭제했습니다. 모델이 발전하는 만큼 우리의 워크플로도 그에 맞춰 진화해야 합니다.
물론 테스트와 Review 가 불확실성을 줄여주지만, 인간은 여전히 올바른 인수 조건을 제시해야 합니다. 코드와 테스트가 서로 맞아떨어지더라도, 둘 다 요구사항을 함께 오해했을 수 있습니다. 엔드투엔드 테스트는 선택된 환경과 시나리오에서의 동작만 커버합니다. 운영 환경의 트래픽, 동시성, 데이터 분포는 여전히 새로운 문제를 야기할 수 있습니다.
저처럼 이제 막 일을 시작한 개발자로서, 저는 여전히 업무를 통해 해당 분야의 전문 지식을 더 많이 배우기를 희망합니다. 하지만 AI 는 확실히 직접 함정에 빠져볼 기회를 일부 줄여버렸습니다. 원래는 문제를 겪고 원인을 조사하며 얻었을 귀중한 경험이 이제는 AI 의 한마디로 대체될 수 있습니다.
"제가 틀렸습니다. 지금 수정하겠습니다."
그래서,
저는 이제 매일 개발 시간의 일부를 학습과 회고를 위해 남겨두고, 동시에 이런 고민을 합니다. AI 시대의 R&D 동료들에게 진정으로 필요한 역량은 무엇일까.
이번 글은 제가 입사 후 처음 몇 달 동안 제 업무 속에서 점차摸索(탐색)해 낸 방법들을 기록한 것입니다. 그 적용 범위와 부족한 점은 저도 아직 탐구해 나가고 있습니다.
여러분도 평소 자주 하던 자가 테스트 경로 하나를 골라, Agent 가 독립적으로 실행하게 해보고 증거를 보존한 뒤 효과적인 단계를沉淀(정리)해 보는 것으로 시작해 보시길 권합니다.
회사의 보안 규정상 많은 세부 사항을 글에 담지 못했습니다. 이 글이 옥을 끌어내기 위한 벽돌(겸손한 표현)이 되었으면 하며, 실제 개발 현장에서 여러분이 가진 좋은 사례들도 꼭 듣고 싶습니다~
