2025.07.31 Hackathon Lesson Learnt in KR

해커톤 개요

사내에서 열린 AI 해커톤을 마쳤다.

해커톤의 주제는 AI를 이용하여 사내에서 하는일들의 생산성을 높히는 것!

사실 이미 VS Code Copilot을 한 2년 쓰다가 Cursor로 올초에 갈아탔고, Cursor의 Agent 기능을 초기부터 잘쓰다 이제는 Claude Code Max를 쓰고있는 내입장에서는 잘은 모르겠지만 생산성이 엄청 올랐다는 생각은 해왔다.

일단 감각적으로 개발자 생산성지표인 DORA 지표상으로는 뭔가 좋아졌을거같은 느낌은 받는데, 이게 얼마나 좋아졌는지 애매하기도하고.. 사내에서 DORA지표를 체크하는 것도 아니라 생산성 증대라는 결과를 청중에게 어떻게 어필하느냐가 참으로 어렵더라.

아이디어: Token 사용량 추적 대시보드

쩝, 고민하다가 결국 특정 인물이 AI를 이용하면서 사용한 Token의 수와 생산성이 얼추 양의 증가관계에 있다는 가정을 하고, 매니저나 테크리드, 디렉터들을위한 개발자 Token 사용수 추적 대시보드를 만들기로 했다.

자본주의의 특성상 비지니스는 최적의 효율을 찾아갈것이고, AI가 생산성을 올릴수있다는 가정이 맞다면 Token수도 일정 Correlation이 있을것이기 때문에, Higher level은 이를 이용한 비지니스 로직의 재설계가 결국에는 필요하지 않을까라는 사고실험에서 시작된 주제인것이다.

AI Agent 워크플로우 교육

일단 내가 리더를 맡았고, 참여자들에게 CC(Claude Code) $100 을 결제하게 했다..(강매 미안…ㅋㅋ)

이 프로젝트전체를 Vibe Coding으로 짜야 빨리 짤수있다고 내가 설득했기 때문이다… ㅋㅋ 여기서 내가한 실수는 설득과정에서 최신의 CC기능 (Super Claude, Subagents 등)을 소개하는데 시간을 너무 많이썼다는 것.

Hackathon 주제에만 집중했다면 진짜 금방끝냈을텐데 말이다. 하지만 그 과정에서 이 똑똑한 엔지니어들은 정말 금방금방 흡수하고, 각자 하고있는 영역에서 CC같은 AI Agent를 이용해서 일을 시키고 매니지하는 일종의 방법론이 머리속에 조금은 각인된듯하다. 오히려 이게 회사에 내가 기여한 큰일인것 같은데 ? 아닌가 ..ㅋㅋㅋ

워낙에 다들 뛰어난 엔지니어들이지만 Cursor/Copilot + LLM(ChatGPT, Claude, Grok)을 보조도구로 이용해서 직접 개발하는것이 기존의 업무를 대하는 방식이었다면, 이제는 업무자체를 더 크게보고 세분화할수있어야하고, 컨텍스트를 더 길게 대하고, Todo List or Action items들을 설계하고, Tester, Designer, Developer, DevOps등의 Agent들에게 일을 시키고또 결과를 내고 Feedback을 반영하는 일련의 워크플로우자체가 변하는 새로운 패러다임으로 일을하는 방법을 뭔가 채득한 첫경험이 아닐까 싶다.

병목 현상 문제

해커톤을 진행하면서 겪은 가장큰 문제는 워크플로우변경에 의한 무한한 병목현상이다.

엔지니어 한명당 하나의 Agent만써서 하나의 저장소에서 일한다해도 저장소에 수 많은 Conflict가 발생하고 이를 해결하는데에만 Token이 많이 소모된다. 혼자서 일할때는 아무래도 Conflict가 발생해도 작았고, Main의 Protection Rule이나 CICD pipeline에 다른 설계를 많이 안해놔서 그냥 그 Cost자체가 적었다.

Main의 Protection Rule을 넣고, TDD로 설계를 시킨 테스트들이 Github Action CICD에서 돌고, CC가 이를 모니터링하면서 생기는 Token은 실제 CC가 코드를 개발하면서 발생하는 Cost보다 비교도 안되게 높더라 (물론 느낌으로)

제 아무리 프로젝트의 CLAUDE.md를 잘설계하여 모두가 공통의 Repo에서 잘지켜야할 룰들을 잘넣어놔도, 결국 Context Window에서 이를 다 지키지 못하는 일도 가끔씩벌어졌다. 심지어 Feedback까지 반영하게하여 문제 발생시 CLAUDE.md에 다시 룰을 추가하도록 설계하니, Subagent마다 이걸 건드려고하고, 거기에 엔지니어들의 수만큼 곱한 크기로 병목현상이 발생했다.

결국 첫날은 프로젝트 골달성은 언감생심이고 넷다 병목 해결하는걸 기다리다가 Token 소모를 다한듯.

Agent Engineering 시대

더욱 이를 가속화 한것은 나의 막간을 이용한 Claude Squad 를 이용하면서 발생했다.

Claude Squad는 tmux기반으로 workspace 를 worktree기반 file path로 나눠서 한유저가 하나의 프로젝트에 Claude Code 를 여러개 돌릴수있다.

나는 총 6개의 Claude Code instance를 돌렸는데 각 안에서 서브에이전트들이 돌면서 일을 하다보니 뭔가 일하는 속도 자체는 빠른데, 80퍼센트의 시간은 병목 해결하는데 쓰더라.

Prompt Engineering → Context Engineering 으로 옮겨간지 얼마나되었다고 이제는 Agent Engineering 이라는 말이 맞는듯..

해결책과 인사이트

두개의 Subagent간의 Workflow 부터 잘정의해야 Claude Squad 건, 여러명이서 동시에 같은 프로젝트를 하건 할수있을듯 하다. 인간적으로 병목기다리는게 대부분이면 ㅜㅜ

결국 돌고돌아 한명(나)가 프로젝트의 개발을 나의 CC로 일을 시키기로했고, 나머지는 Repo를 주기적으로 sync하여 UI/UX 개선할점을 Playwright같은 mcp을 이용해 도출해서 나에게 다시 Markdown file로 피드백주면 그걸 다시 나는 CC에게 Action item 화하는 워크플로우로 바꿨다.

그리고 github action cicd 를 전부 삭제하고, issue creation, pull request 하는 스탭도 빼니 개발 속도가 획기적으로 늘더라.

뭔가 여기에 DORA 측정같은 걸 하게 만들어 방법론마다의 kpi를 측정하면 좀더 좋은 모델을 찾을수있지않을까 라는 생각을 하며.. 긴글을 마무리