본고는 2026년 7월 7일에 개최된 「【CDLE Hokkaido】 2026 before & after AI LT회」에서의 발표를 배경으로 하고 있다.

슬라이드 상에서는 생략하고 구두로 설명한 내용을 문서로 보충함으로써, 이벤트에 참가하지 않은 사람도 동일한 수준 이상의 정보를 얻을 수 있는 동선을 확보하는 것이 본고의 목적이다.

구두쇠란 무엇인가

구두쇠(吝嗇家)는 돈이나 물건을 아끼는 사람을 말한다.

결국 「짠돌이」라는 뜻이지만, 「짠돌이」라는 단어를 사용하면 다소 부정적인 인상이 너무 강해진다고 느꼈기에 이 단어를 일부러 사용하고 있다.

한편으로, 단순히 「AI에 돈을 내고 싶지 않다」는 이야기로 만들고 싶지 않았던 의도도 있다. 코딩 에이전트(Coding Agent)는 편리하며, 편리한 것에는 돈을 지불해도 좋다.

문제는 편리하다고 해서, 아직 생각이 굳어지지 않은 단계부터 무작정 실행하면 판단의 흔들림까지 에이전트 이용료로 지불하게 된다는 점에 있다.

여기서 다루는 것은 단순히 「지출을 억제한다」는 이야기가 아니라, 「에이전트 사용의 효율을 높인다」는 테마라고도 할 수 있다.

개인 개발에서 한 달에 수천 엔에서 수만 엔이 날아가는 것은 충분히 아프다. 업무에서 사용하는 예산감과 개인적으로 즐기는 예산감은 다르다.

그렇기에 어떻게 하면 사전 단계에서 문제를 다듬고, 어디서부터 에이전트에게 넘길지를 나누고 싶다.

ChatGPT를 최대한 활용하기

결론부터 말하자면, 코딩 에이전트에게 태스크(Task)를 넘기기 전에 ChatGPT를 사용하여 과제를 날카롭게 다듬는다는 방침이다.

왜 거기서 ChatGPT인가.

나의 관측으로는, Claude는 Claude Code와 일반적인 Claude 이용이 동일한 소비 프레임으로 취급된다.

즉, Claude를 사용하면 Claude Code의 사용량이 늘어나고, 그 반대도 마찬가지일 것이다.

반면, ChatGPT는 Codex와 기본적으로 별도 프레임[1]이 된다. 적어도 Codex 측의 이용 상한에 도달한 상태에서도, ChatGPT를 통해 GitHub Issue를 업데이트하는 작업은 가능했다.

이 점(ChatGPT는 Codex와 소비 상한이 별도로 관리된다는 점)에 주목하여, 코딩 에이전트의 전 단계로서 ChatGPT를 활용하자라는 것이 본고의 입장이다.

ChatGPT와 키보드 배틀(レスバ)을 벌이기

가장 먼저 하는 것은 ChatGPT에 대한 상담이다.

하고 싶은 것, 바꾸고 싶은 것, 고치고 싶은 버그를 일단 던진다. 「이런 것을 하고 싶다」, 「이런 동작이 마음에 들지 않는다」, 「이 설계가 수상한 것 같다」 정도에서 시작해도 좋다.

ChatGPT로부터는 아마 그럴싸한 안이 돌아올 것이다. 신경 쓰이는 부분이 특별히 없다면 그것을 바탕으로 더욱 구체화된 방침을 내놓겠지만, 오히려 「이미지와 맞지 않는다」, 「뭔가 다르다」, 「잘 모르겠다」를 찾아내는 것이 더 중요하다고 생각한다.

「뭔가 다르다」, 「이미지와 맞지 않는다」 정도라도 좋으니 어긋남이나 위화감, 불명확한 점을 찾아내어 그것을 ChatGPT에 다시 던지고, ChatGPT가 다시 안을 내놓는다. 그러면 다시 이쪽에서 걸리는 부분이 생긴다.

슬라이드에서는 이것을 거칠게 「키보드 배틀(レスバ)」이라고 불렀다.

「키보드 배틀」이라고 말하지만, 그 실체는 아직 언어화되지 않은 전제를 거친 안에 부딪혀 떠오르게 하는 작업이다.

앞서 언급했듯이, ChatGPT는 Codex와는 별도로 관리되는 듯하므로, 여기서는 사양 말고 고민하며 말을 바꿔도 된다. 적어도 Plus 플랜이라면 7~8개의 태스크를 병행하여 계속 토론하지 않는 한, 그리 쉽게 상한에 걸리지 않는다[2].

Issue로 축적하고, 다시 키보드 배틀

하고 싶은 것의 윤곽이 어느 정도 보이기 시작하면, ChatGPT에게 Issue를 작성하게 한다.

여기서 만들어지는 Issue는 기껏해야 체크포인트 정도의 취급이며, 아직 완성품이 아니다.

대부분의 경우, 거기서 더욱 검토하고 고찰할 여지가 있다. 구두쇠라면 여기서 코딩 에이전트에게 던지는 것은 다소 토큰(Token) 소비가 아깝다고 생각하고 싶다.

일단 Issue가 만들어지면 스스로 읽는다. 신경 쓰이는 부분이 있다면 당연히 ChatGPT에게 묻는다.

신경 쓰이는 부분이 없더라도 일단 거칠게 「Issue #38을 리뷰해줘」라고 던지는 것만으로도 꽤 여러 가지 내용이 나온다.

그렇게 ChatGPT가 제안해 온 내용이나 판단을 요구해 온 내용을 확인하고 응답하며, 그것을 다시 Issue에 반영시킨다.

또한 Issue를 다시 리뷰하게 하고, 제안 등에 응답하며, 그것을 다시 Issue에 반영시킨다. 이것을 「Issue의 구현자가 판단에 망설이지 않는다」라는 평가가 내려질 때까지 끊임없이 반복한다.

나 자신은 이를 Issue를 Get Ready 상태로 만든다고 표현하고 있다.

즉, Issue가 「에이전트에게 던져질 수 있는 상태」가 된 상태, 즉 에이전트가 망설일 여지를 줄이고, 망설일 때 참조할 수 있는 판단 재료가 한 차례 Issue에 놓인 상태를 ChatGPT와의 「논쟁 (Debate)」을 통해 목표로 한다.

이 정도 단계에 도달했다면 에이전트에게 넘겨도 좋다. 반대로 말하면, 이 단계에 도달하지 못한 Issue는 아직 인간과 ChatGPT가 함께 다투며 다듬는 것이 좋다. 거기서 비용을 아낀다.

에이전트에게 Issue를 던지기

Issue가 Get Ready 상태가 되면, 비로소 코딩 에이전트 (Coding Agent)를 사용한다. 이 단계까지 오면 「Issue #38을 구현해줘」 정도의 거친 지시만으로도 대체로 충분하다.

개인적으로는 Claude Sonnet 5와 Codex 5.5를 메인으로 사용하고 있는데, 어떤 에이전트든 대체로 끝까지 완주해 주며 내용도 그리 나쁘지 않다는 것이 체감상 느낌이다.

여기까지 와서야 비로소 비용이 많이 드는 고가의 처리를 실행한다.

물론 PR (Pull Request)을 읽고 신경 쓰이는 부분이 있으면 코멘트를 남기고, 코멘트 대응을 다시 에이전트에게 의뢰한다.

하지만 처음부터 모호한 의뢰를 던져서 길을 잃게 만드는 것보다 훨씬 저렴하게 먹힌다고 생각한다.

Issue와 PR에 문맥을 남기기

이 운용에서 중요한 것은 대화 로그에 문맥 (Context)을 가두지 않는 것이다.

ChatGPT와의 대화는 편리하지만, 채팅 로그에만 방침이 남아 있으면 나중에 다른 도구로 인계하기 어렵다.

예를 들어 이용 한도에 걸려 다른 에이전트로 갈아타고 싶을 때 [3]도, 대화 로그에 의존하고 있다면 힘들다.

Issue와 PR에 문맥이 남아 있다면, 「Issue #38의 작업을 인계해줘」 정도의 말로 다시 던지기 쉽다.

특별한 오케스트레이션 (Orchestration) 기반이나 도구 종류는 필요 없다는 것이 이 운용의 간편한 점이다.

GitHub Issue 혹은 유사한 Issue Tracking System만 있으면 동일한 작업을 할 수 있다.

인간, ChatGPT, 코딩 에이전트 사이에서 프로세스를 가로질러 공유할 수 있는 메모리 (Memory)로서 Issue를 이용한다.

AI 시대의 Issue / Ticket Driven Development

이것은 Issue Driven Development 혹은 Ticket Driven Development에 대한 소박한 재평가라고도 할 수 있다고 생각한다.

인간끼리라면 거친 Issue라도 대화로 어느 정도 보완할 수 있지만, 에이전트에게 넘길 경우 Issue에 적혀 있지 않은 내용은 높은 확률로 누락되거나 멋대로 보완된다.

멋대로 보완된 것이 맞다면 다행이지만, 틀렸을 때는 그 수정에도 다시 비용이 발생한다.

그래서 Issue를 작성한다. 그것도 인간이 읽기 위해서뿐만 아니라, AI가 읽는 것을 전제로, 대인 관계라면 싫어할 정도로 집요하게 수정을 반복하며 작성한다.

그렇다고 해서 수정을 반복하여 Issue의 정보량이 많아질수록 좋다는 뜻은 아니다.

우리가 원하는 것은 판단이 갈리는 지점, 실패하면 비용이 많이 드는 부분, 나중에 논란이 생길 법한 부분에 대한 명시적인 단서이며, 동시에 그것이 공유 가능한 장소에 놓여 있는 것이다.

요약

• ChatGPT와 Codex는 소비 토큰 (Token)이 별도로 관리되는 점을 이용해, 왕복이 심한 부분은 ChatGPT를 최대한 활용한다.
• AI 에이전트가 구현에서 망설이지 않을 수준까지 구체화·상세화한 뒤, 마지막 마지막 단계에서 에이전트를 실행한다.
• Issue / Ticket Driven 방식을 통해 여러 도구를 연계한다.
• 도중에 한도에 걸리면 에이전트를 교체하여 인계하는 등의 작업도 특수한 메커니즘 없이 가능하다.

코딩 에이전트는 편리하지만 비싸다.

따라서 에이전트를 사용하는 국면을 뒤로 미루고, 그 전 단계에서 저렴한 방법을 사용하는 것이 본고의 취지이다.

그리고 그 실천을 뒷받침하는 메커니즘으로서, Issue / Ticket Driven Development는 이 AI 시대에 다시금 평가받아야 할지도 모른다.

Discussion