Claude Code 해커톤에 필요한 것을 메타적 관점에서 생각해 보다

이 글은 시(poem)입니다. 해커톤의 공식 심사 기준을 설명하는 것도 아니고, 수상 조건을 통계로 확인하는 것도 아닙니다. 모집 공고문과 과거 작품들을 보면서, 소프트웨어를 만드는 인간의 가치가 어디로 이동해 갈지 생각해 본 기록입니다. 참고로, 필자는 이번 해커톤에 참가하지 않습니다. 그 이유도 마지막에 쓰겠습니다.

본 기사는 Claude Code와 함께 만들었습니다. 출처 확인과 문장 교정에도 사용했습니다. 내용과 결론은 필자의 것입니다.

2026년 11월에 일본을 대상으로 하는 온라인 해커톤 'Built with Claude: Japan 2026'이 개최됩니다. 모집은 선발제이며, 참가자는 최대 250명이고, 개발 기간은 11월 2일부터 10일까지, 응모 마감일은 10월 26일입니다. 참가 조건은 일본 거주자이며, 참가자에게는 Claude Max 5x 플랜과 500달러의 API 크레딧이 제공됩니다(공식 모집 페이지, TechnoEdge 기사).

저는 평소에 Claude Code를 사용해서 소프트웨어나 AI 관련 연구 개발(R&D)을 하고 있습니다. 도구 사용법을 모르는 것도 아니고, 기술적으로 아무것도 만들 수 없는 것도 아닙니다. 그럼에도 '좋아하는 것을 만들어 주세요'라고 하면 갑자기 주제가 어려워집니다. 떠오른 것은 생각한 순간에 이미 전부 만들어 버리고 말기 때문입니다.

AI 에이전트, 로봇 제어, 시뮬레이션, 개발 기반. 그런 것들은 일상적으로 만들고 있습니다. 그런데 그 연장선에서 무언가를 만들어도 'R&D 엔지니어가 평소의 R&D를 했습니다'라는 이야기로 끝날 뿐입니다.

그래서 수상권에 들기 위해 노력하는 것이 평가될까요?

물론, 수상권을 노리는 것이 중요하다고는 생각하지 않습니다. 해커톤은 참가하는 것에 의미가 있습니다. 다만, 나간다니 받고 싶다. 그 두 가지가 본심입니다.

이 글에서는 그 질문을 모집 공고문과 과거 수상작들로부터 생각해 보겠습니다.

주최 측의 공식 모집 페이지는 흥미로운 방식으로 작성되어 있습니다. 도입부에서 던지는 질문은 모델의 추론 성능이나 에이전트 구성에 관한 것이 아닙니다.

'이런 도구가 있으면 좋을 텐데'라고 생각한 적이 없으신가요?

주제의 출발점으로는 본인이 가장 잘 아는 영역에서 나오는 것과, 많은 사람을 가로막았던 벽을 제거하는 것이 제시되고 있습니다. 게다가 완성된 프로젝트뿐만 아니라 그것을 만든 사람들까지 세계에 소개한다고 합니다.

이 모집은 누가, 무엇 때문에 어려움을 겪고 있고, 왜 그것을 만드는지를 강하게 의식시키는 설계로 보입니다. '무엇이든 좋으니 Claude Code로 고도화된 것을 만들어라'라는 모집은 아닌 것 같습니다.

물론, 'B면(이면)을 평가한다'고 공식적으로 선언한 것은 아닙니다. 심사위원은 곧 발표될 예정이며, 심사 기준도 공개되지 않았습니다. 전문가가 직무상의 문제를 해결하는 것도 충분히 모집 취지에 맞을 것입니다. 다만, 소프트웨어를 개발하는 것 자체가 일이 된 사람에게는 주제를 고르는 데 있어 또 다른 어려움이 있습니다.

Anthropic이 공개한 Built with Opus 4.6의 수상자 소개에 따르면, 5명의 수상자 중 4명은 전문 소프트웨어 개발자가 아니었습니다. 변호사, 심장 전문의, 도로/인프라 분야 전문가, 전자 음악가, 그리고 전문 소프트웨어 엔지니어입니다.

각 작품에는 만든 사람의 구체적인 출발점이 있습니다.

• A면: 직업인으로서의 전문성. 저라면, AI나 소프트웨어 연구개발 엔지니어로서의 모습.
• B면: 직업 외적인 모습. 저라면, 생활자, 취미인으로서의 모습.

Elisa의 개발자는 A면의 기술력을 충분히 사용하면서도, B면에서 발견한 과제를 해결했습니다.

B면 자체가 필수라고 말하고 싶은 것은 아닙니다. 의사가 의료 현장의 과제를 해결한다면, A면만으로도 상당한 힘을 가진 이야기가 됩니다. 필요한 것은 그 사람만이 발견할 수 있는 과제와, 그것을 만들 필연성입니다.

다만, 저처럼 A면이 거의 '소프트웨어를 만드는 것' 자체에 맞춰져 있다면, A면의 과제를 그대로 내놓아도 범용 개발 도구나 연구개발의 연장선상에 머무르기 쉽습니다. 심사위원들 앞에서 작동시켜 보여도, '기술적으로는 대단하네요'에서 끝날 위험이 있습니다.

그렇기에 B면에 주목해야 한다는 발상이 나오는 것입니다.

예를 들어 이전에 저는 M5Stick으로 주변 Wi-Fi의 혼잡도를 측정하는 작은 장치를 만들었습니다. 픽셀 아트 캐릭터로 혼잡도를 표시하고, 채널별 혼잡도와 가장 여유로운 채널을 화면에 보여줍니다. 본인에게 현실적인 불편함이 있었고, 손에 닿는 기술로 이를 해결했습니다. 주제를 제시하는 방식으로는 이런 것이 가깝다고 생각합니다.

M5Stick으로 만든, Wi-Fi의 혼잡도를 측정하는 장치. 화면에는 채널별 혼잡도와 가장 여유로운 채널이 표시됨

다만, 이것만으로는 작품으로서 작고 소박합니다. 현실에 뿌리내린 문제 설정과 사람을 사로잡는 작품으로서의 강점은 별개의 문제입니다. 기능을 추가해서 크게 만들면 되는 것이 아닙니다. 그 부분이 어렵습니다.

지금까지의 이야기에는 두 가지 종류의 스토리가 섞여 있습니다.

• 작품 설명으로서의 스토리: '이 기술로 이런 사회 과제를 해결할 수 있습니다.'
• 만드는 필연성으로서의 스토리: '내 눈앞에 이 문제가 있었고, 정말 이것이 필요했습니다.'

둘 다 중요하지만, 후자는 나중에 기능을 추가해서 만들 수 있는 것이 아닙니다. Elisa가 강한 것은, 후자가 그대로 작품의 출발점이 되었기 때문이라고 저는 생각합니다.

여기서는 Anthropic의 사업 전략에 대한 가설입니다.

Claude Code의 시장을 이미 코드를 작성하는 사람으로만 한정할 필요가 있을까요?

이전에 저는 GitHub 계정 100만 개를 무작위로 조사한 글을 썼습니다. 거기서 추정한 인원은 다음과 같습니다.

그럼에도 불구하고, 일상적으로 공개적인 장소에서 개발하는 사용자층은 세계 인구에 비하면 상당히 제한된 집단입니다.

여기서 '엔지니어 대상 시장은 이미 포화되었다'고 말하는 것은 성급합니다. 기존 고객의 이용 증가, 기업 도입, API 이용 증가 등 성장 여지는 얼마든지 있습니다. 하지만 비(非) 엔지니어에게 영역을 넓히는 것이 다음 큰 시장 확대 경로가 될 것이라는 추론은 자연스러울 것입니다.

전통적인 소프트웨어 개발은 과제를 가진 전문가가 엔지니어에게 요구사항을 전달하고, 그 엔지니어가 구현하는 분업이 기본이었습니다. Claude Code와 같은 도구가 그 거리를 좁힌다면, 의사, 음악가, 장인, 보호자, 지역 활동가 등이 자신의 문제를 스스로 소프트웨어로 바꿀 세상이 넓어질 것입니다.

그렇게 생각하면, 공모전 모집 문구가 모델의 성능 과시가 아니라 '당신이 가장 잘 아는 것'부터 시작하도록 유도하는 것은 마케팅적으로도 이치에 맞습니다.

수상작이 기술적으로 우수할 뿐만 아니라, '나도 만들 수 있겠다'고 새로운 사용자에게 상상하게 만드는 사례가 된다면, Claude Code라는 제품의 시장 자체를 넓힐 수 있습니다.

다만, 이것은 모집 문구와 사례로부터 읽어낸 것입니다. Anthropic 내부의 전략이나 심사의 숨겨진 평가 항목을 아는 것은 아닙니다.

지금까지의 이야기에는 적어도 세 가지 능력이 관련되어 있습니다.

• 과제를 발견하는 것: 현장이나 생활을 깊이 알고 있어, 무엇에 어려움을 겪고 있는지 간파할 수 있는 능력.
• 해결책을 구현하는 것: 사양, 코드, 테스트, 운영을 성립시킬 수 있는 능력.
• 가치를 보여주는 것: 실제로 사용하게 하여, 무엇이 변했는지를 제삼자에게 전달할 수 있는 능력.

전통적으로는 두 번째 구현 능력이 큰 진입 장벽이었습니다. 코딩 에이전트(coding agent) 덕분에 그 장벽의 일부가 빠르게 낮아지고 있습니다. 그 결과, 첫 번째와 세 번째 중요성이 상대적으로 높아지지 않을까요?

물론, 구현 능력 자체가 무가치해진 것은 아닙니다. 어려운 시스템을 올바르게 작동시키고 안전하게 유지보수하는 능력에는 계속해서 가치가 있습니다. 다만, 해커톤처럼 짧은 시간 안에 매력을 전달해야 하는 장에서는 '무엇을 만들었는지'보다 '왜 만들었는지'가 평가를 좌우하는 정도가 이전보다 커진 것 같습니다.

기술력이 충분해도, 과제 발견이나 스토리의 설득력에서 밀릴 가능성이 있습니다. 반대로, 거의 코드를 작성해 본 적이 없는 사람이 누구보다 강력한 소재를 가지고 있을 때도 있습니다. 참으로 아이러니한 이야기입니다.

여기까지 메타적 관점에서 여러 가지를 생각해 봤습니다.

공모전 모집 글의 의도를 읽고, 과거 수상작을 조사하고, GitHub 개발자 인구를 언급하며, 심지어 Anthropic의 시장 전략에까지 이야기를 확장했습니다.

그래서, 저는 무엇을 만들까요? 떠오르지 않습니다.

연구개발 엔지니어로서 만들어보고 싶은 것은 얼마든지 있습니다. 하지만 그것은 평소에도 하고 있는 일입니다. 이번에 필요한 것은 기술적으로 흥미로운 것이 아니라, '제가 이것을 만들 이유'를 다른 사람에게 자연스럽게 설명할 수 있는 소재입니다.

그런데 가슴을 펴고 말할 만큼 강력한 B면(B-side)이 저에게는 보이지 않습니다. 해커톤에 맞추어 그럴듯한 사회적 과제를 나중에 붙이거나, 억지로 감동적인 이야기를 만들어내는 것도 옳지 않을 것입니다.

참여 자체에 의미가 있다는 생각도 있습니다. 그럼에도 불구하고, 참가한다면 입상하고 싶습니다. 그러기 위한 소재가 지금의 저에게는 없습니다.

따라서 이번 해커톤에는 참여할 수 없습니다. 적어도 현재의 저는 납득할 만한 주제를 준비할 수 없습니다.

여기까지 Claude Code 해커톤에 필요한 것을 길게 분석했던 사람이, 마지막에는 코드를 작성하기 전 단계에서 막히고 있습니다.

Claude Code는 만드는 능력을 확장해 줍니다. 하지만 만들고 싶은 이유까지 대신 살아주지는 않습니다.

아무래도 저에게 부족한 것은 차세대 코딩 에이전트가 아니라, 자랑할 만한 B면이었던 것 같습니다.