Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
본 글은 코딩 에이전트의 프롬프트와 작업 과정을 개발 티켓 스레드에 기록하고 검토하는 새로운 파이프라인 디자인을 소개합니다. 이 방식은 모든 요청과 결과물이 하나의 중앙 집중식 채널(티켓)에 보존되어, 마치 Pull Request처럼 전체 과정과 의도를 추적할 수 있게 합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기저희 팀이 코딩 에이전트를 위해 작성하는 모든 프롬프트는 해당 요청을 담은 티켓에 저장됩니다. 이 티켓 스레드가 개발자가 에이전트와 대화할 수 있는 유일한 방법이기 때문에, 프롬프트가 갈 다른 곳은 없습니다.
저는 Oizom의 소프트웨어 팀 리드를 맡고 있는 Panth입니다. 저희 Envizom은 공기질 및 환경 모니터링 장치 데이터를 도시와 산업이 실제로 행동으로 옮길 수 있는 형태로 변환하는 플랫폼입니다. 이 글은 저희 에이전트 파이프라인의 디자인 목표 중 하나에 관한 것입니다. 바로 프롬프트가 작업과 함께 보존되며, 검토될 수 있다는 점입니다.
개발자는 티켓에 평범한 영어로 원하는 바를 작성하고 '승인됨(Approved)'으로 이동시킵니다. IDE도 열려 있지 않고, 터미널도 없고, 프롬프트 창도 없습니다. 그 티켓 텍스트 자체가 전체 명세서가 됩니다.
저희 오케스트레이터(orchestrator), orch는 이 티켓에 자체 스택을 부여합니다. 즉, 모든 레포지토리의 브랜치, 자체 백엔드, 드라이버, 시뮬레이터 및 프론트엔드, 개발자 데이터베이스 사본, 그리고 비공개 미리보기 URL입니다. 코딩 에이전트는 이 스택 내부에서 작업을 수행합니다. 작업이 완료되면, 에이전트는 미리보기 링크를 스레드에 게시하고 티켓을 'QAQC'로 이동시킵니다.
개발자는 미리보기를 열고 테스트한 후, 같은 스레드에 답글을 달아 티켓을 다시 되돌립니다. 동일한 에이전트가 동일한 컨텍스트를 가지고 중단된 지점부터 작업을 이어갑니다. 모든 후속 조치는 스레드의 메시지 형태로 이루어지기 때문에, 모든 후속 조치 역시 저장됩니다.
저희가 이것을 구축할 때 세운 목표 중 하나는 다음과 같았습니다:
모든 프롬프트는 자신이 생성한 작업과 함께 저장되어야 하며, 이를 통해 사람들이 어떻게 요청하는지 검토하고 코칭할 수 있어야 한다.
티켓이 완료될 때쯤이면, 그 스레드에는 전체 교환 내용이 차례대로 담겨 있습니다:
| 스레드 내 내용 | 작성자 |
|---|---|
| 요청된 사항 | 개발자 (티켓 및 각 답글) |
| ... |
ticket camera layout change on the device page -> Approved
agent builds it in the ticket's stack, posts the preview -> QAQC
me "also handle more than 4 cameras with a horizontal scroll,
...
이 모든 줄은 스레드에 기록됩니다. 누구나 티켓을 열고 무엇이 요청되었는지, 어떤 단어로 요청되었는지, 그리고 그 결과물 옆에서 그것이 어떻게 나왔는지를 읽을 수 있습니다.
프롬프트가 저장되기 때문에 검토될 수 있습니다. 저는 팀의 각 사람이 무엇을 요청하는지 보고 코칭할 수 있습니다. 이것은 어떤 프롬프팅 가이드보다 더 유용했습니다.
프롬프팅 가이드는 전반적으로 좋은 요청이 어떻게 보이는지를 알려줍니다. 하지만 티켓 스레드는 팀원 중 한 명이 특정 변경 사항을 어떻게 요청했는지, 에이전트가 그것으로부터 무엇을 구축했는지, 그리고 그들이 만족할 만한 결과에 도달하는 데 몇 번의 답장이 필요했는지를 보여줍니다. 마치 풀 리퀘스트(pull request)의 한 줄을 가리키듯이 특정 메시지를 지적하고 논의할 수 있습니다.
비용 라인도 여기서 중요합니다. 각 에이전트 턴은 요청이 이루어진 바로 그 스레드에 자신의 비용을 게시합니다. 요청한 사람은 요청하는 데 얼마의 비용이 들었는지 확인하며, 이는 다음 요청을 작성하는 방식에 변화를 줍니다. 이것 역시 의도된 것입니다.
저장된 프롬프트는 그것이 생성한 작업 옆에, 그리고 다른 어떤 것과도 분리되어 있을 때만 유용합니다. 여기에 '티켓별 격리(per-ticket isolation)'가 들어갑니다.
각 티켓은 모든 리포지토리(repo)에서 자체 브랜치(branch), 자체 서비스, 그리고 자체 개발 데이터베이스 사본을 가집니다. 따라서 티켓의 스레드는 자립적인 기록이 됩니다: 무엇이 요청되었는지, 해당 스택에서 무엇이 구축되었는지, 어떤 미리보기(preview)에서 테스트되었는지를 말입니다. 한 티켓은 다른 세 개의 티켓이 배포되는 동안 QA 단계에 일주일 동안 머무를 수 있으며, 그 이력은 여전히 한 곳에, 다른 사람의 기록과 섞이지 않고 존재합니다.
해당 스레드에는 나머지 프로세스도 표시됩니다. Git Push 이후로는 어떤 에이전트도 관여하지 않습니다: 오케스트레이터(orch)가 커밋하고, 풀 리퀘스트를 병합하며, 열고, 병합을 기다리고, CI(지속적 통합)를 기다린 후, 개발 VM에 배포하고 상태를 확인한 다음, PR 및 커밋 링크를 같은 스레드에 다시 게시합니다. 프롬프트, 결과, 그리고 검토 기록이 하나의 티켓에 모입니다.
만약 팀이 코딩 에이전트를 사용한다면, 작업이 배포된 후 프롬프트는 어디로 가나요?
저는 Oizom의 소프트웨어 팀을 이끌고 있습니다. 우리가 경계를 그은 부분(개발 전용, 인간 QA, 가시적인 비용 포함)을 포함한 전체 파이프라인은 The ticket is the interface에서 확인할 수 있습니다.