Demo Day Care 팀, AI:GO로 벤치마크 결과를 시각화하다

8월 21일부터 23일까지 포항 POSTECH에서 열린 JunctionX Korea 2026 해커톤에서 래블업과 퓨리오사AI는 '손에 쥘 수 있는 모델로 어디까지 갈 수 있는가'라는 과제를 냈습니다. 참가 팀은 FuriosaAI RNGD 서버가 서빙하는 K-EXAONE-236B-NVFP4, gpt-oss-120b, Qwen3-32B 세 모델을 래블업 AI:GO의 스쿼드(Squad) 기능으로 묶어 코딩, 수학, 일반 벤치마크를 가장 적은 비용으로 풀어내고, 스쿼드가 문제를 푸는 과정을 보여 주는 시각화도 함께 만들어야 했습니다.

Demo Day Care 팀은 벤치마크 점수와 효율, 총 토큰 사용량을 3D 형태의 시각화로 구현한 관측 도구로 트랙 1위 및 전체 우승에 올랐습니다. 학부생 세 명과 인턴 한 명으로 꾸려진 이 팀이 48시간 동안 AI:GO의 에이전트 스쿼드(agent squad) 기능을 활용하여 벤치마크 문제를 해결하는 스쿼드를 어떻게 설계했는지, 그 과정을 들어보았습니다.

* 본 인터뷰는 9월 9일에 진행되었습니다.

1. 래블업 - 퓨리오사AI 트랙에 대하여

Q. 먼저 한 분씩 소개 부탁드립니다. 해커톤에서는 어떤 역할을 맡으셨나요?

배석현 | 마지막 학기를 다니고 있는 학부생 배석현입니다. 제가 이 팀을 모았고, 챌린지를 처음 받아서 역할을 나누고 전체를 통합하는 일을 주로 했어요.

이재원 | 학부생 이재원입니다. 전체 시각화를 맡았고, 기획자로서 프론트엔드와 백엔드를 만들 때 인사이트를 주는 역할을 했어요. UI/UX 디자인도 제가 했고요.

유원석 | 학부생 유원석입니다. 개발을 같이 하면서, 결과물이 나오면 QA를 진행하며 고칠 부분을 찾아 리포트하거나, 직접 보완했습니다.

김록연 | 학부를 졸업하고 인턴으로 일하고 있는 김록연입니다. 석현 님이 준 테스트를 돌리는 걸 보조했고, 프롬프트를 어떻게 개선할지 의견을 내는 일을 주로 맡았습니다.

Q. 세 개의 트랙중에 래블업-퓨리오사AI 트랙을 고른 이유는 무엇이었나요?

김록연 | 나머지 두 트랙은 주제를 잡다 보면 결국 공공 서비스를 만들어야 해서, 그 분야의 도메인 지식과 평소 관심이 필요하다고 봤어요. 그 점에서 저희는 다른 팀과 차별점이 없었죠. 반대로 석현 씨, 원석 씨, 재원이 모두 에이전트에 관심이 워낙 많고 재원이는 시각화를 잘하거든요. 트랙 3 주제와 저희 팀의 장점이 딱 맞아서 거의 바로 정했습니다.

이재원 | API를 호출하는 데서 끝나는 게 아니라 기술적으로 더 깊게 들어갈 수 있는 트랙을 해 보고 싶었어요. 석현 씨가 하네스를 잘 다루고 ML 지식도 있어서, 어려운 트랙이어도 저희가 잘할 수 있다고 생각했습니다. 기술로 풀 수 있는 주제라서 오히려 더 매력적이었어요.

배석현 | 산출물이 뚜렷하게 정해진 주제는 다른 팀들도 다 비슷한 결과물을 낼 거라고 저희끼리 얘기했어요. 솔직히 저희가 다른 트랙에 들고 갈 만한, 새롭고 쓸모가 분명한 아이디어가 딱히 떠오르지 않은 상태이기도 했어요. 그런 명분 없이 하면 의미도 재미도 없겠다고 생각했어요. 저는 평소에 에이전트 작업이나 오픈소스 기여를 해 왔고, 재원이의 강점도 있었고요. 산출물이 뚜렷하지 않다는 걱정은 있었지만, 시각화라는 확실한 산출물에서 두각을 드러낼 수 있고 점수도 잘 낼 자신이 있었습니다.

2. AI를 '진짜' 사용하는 사람들을 위한 대시보드를 만들다

Q. 우승작 이야기를 해 보죠. 점수와 효율, 토큰을 세 축으로 보여 주는 3D 관측 도구는 어떻게 나왔나요?

이재원 | 저는 AI 모델을 볼 때 솔직히 지능이 가장 중요하다고 생각해요. 좋은 아웃풋을 얻으려면 무조건 모델이 크고 무거운 게 좋으니까요. 그런데 이번 대회는 평가 지표에 효율성도 있고, 전체 토큰을 얼마나 썼는지도 있고, 점수도 있었어요. 테스트를 계속 돌리다 보면 어떤 때는 점수가 좋고 어떤 때는 효율이 좋은데, 이걸 팀원들이 한눈에 봤으면 좋겠다는 게 출발점이었어요. 그래서 그래프의 축을 세 개로 만들었어요. 3차원 공간에 점만 찍혀도, 세 축의 양의 방향으로 나와 있으면 효율적이고 성능이 좋은 실행이라는 걸 바로 알 수 있으니까요.

AI를 자주 쓰는 사람은 새 모델이 나올 때마다 서비스를 만든다면 어떤 LLM을 쓸지 고민하면서 벤치마크를 계속 봐요. 비슷한 태스크를 변수만 살짝씩 바꿔 여러 번 돌렸을 때 결과를 쉽게 비교하고, 보자마자 뭐가 문제인지 빨리 찾을 수 있으면 좋겠다고 생각했어요. 마지막에 팀들이 다 gpt-oss로 수렴했잖아요. 다른 팀들도 이 도구를 썼다면 그 수렴이 더 빨랐을 거라고 봐요. 벤치마크 시스템을 사람이 파악하기 편하게 만든다는 철학으로 만들었고, 처음엔 저희 문제를 풀려고 시작했지만 결과적으로는 그 이상의 범용 시각화가 됐습니다.

3. Demo Day Care 팀이 스쿼드를 설계한 방법

Q. 최종 스쿼드는 어떤 구성이었나요? 거기까지 가는 과정도 궁금합니다.

배석현 | 최종 스쿼드는 플래너 하나와 범용 임플리멘터(Universal Implementer) 하나였어요. 플래너는 Qwen, 임플리멘터는 gpt-oss였습니다. 여기까지 세 단계를 거쳤는데요. 처음에는 전형적인 하네스 구조로 짰어요. 수학, 코딩, 일반 태스크마다 에이전트를 따로 두고, 수학에는 EXAONE, 코딩과 일반에는 gpt-oss, 플래너는 Qwen을 붙였고, 리뷰어와 리페어 에이전트도 뒀죠. 그런데 단계마다 문제가 생겼고, 무엇보다 라우팅이 제대로 안 됐어요. 그래서 리뷰어와 리페어를 빼고 gpt-oss가 수학, 코딩, 일반 태스크 안에서 알아서 한 번 검증하게 바꿨는데, 여전히 라우팅 문제가 풀리지 않아서 결국 범용 임플리멘터 하나로 갔습니다.

Q. 모델 배치는 어떻게 정하셨어요?

배석현 | 조합을 바꿔 가며 써 봤어요. 플래너는 Qwen을 넣었을 때 결과가 제일 좋았고, 반대로 Qwen을 임플리멘터로 두고 gpt-oss를 플래너로 두니 Qwen이 문제를 못 풀더라고요. 그렇다고 전부 gpt-oss로 하기에는 토큰을 생각하면 정답이 아니라서, 최소한 모델 두 개는 쓰자고 판단했습니다. oh-my-agent' 같은 시리즈를 보면 페르소나가 강한 임플리멘터를 두는데, 저는 거기에 늘 불만이 있었어요. 태스크는 코딩, 수학, 글쓰기로 딱딱 나뉘는 게 아니라 훨씬 다각적이거든요. 그래서 서브에이전트를 짤 때 페르소나를 다 지우고 범용 임플리멘터 하나를 두는 편이에요. 제가 늘 설파해 온 '팬아웃'이라는 방법론이 있어서 과감하게 바꿀 수 있었습니다.

Q. 팬아웃이 어떤 방법론인지 조금 더 설명해 주세요.

배석현 | 제가 붙인 이름이에요. 저만의 하네스, 서브에이전트 할당 구조를 만들고 싶었던 동기도 사실 비용이었어요. Cursor 대회에서 우승해서 크레딧을 많이 받은 적이 있는데, 그걸 잘 써 보려고 한 모델을 플래너로, 다른 모델을 임플리멘터로 두고 Codex 하네스 안에 서브에이전트를 코드로 넣어 보는 시도를 했어요. 처음에는 특화 에이전트를 계속 만들었어요. 학부생이니까 학교 과제 에이전트, 글쓰기 에이전트, 코딩 에이전트요. 그랬더니 제약이 너무 많았고, 에이전트마다 시스템 프롬프트를 읽는 비용을 줄이는 게 낫겠다고 생각했어요.

팬아웃의 장점은 에이전트가 알아서 판단한다는 거예요. 이름처럼 퍼져 나가는 구조라서, 서브에이전트 세 개를 만들면 그 서브에이전트가 각자 또 세 개를 만드는 식으로 뻗어 나가요. 그런데 페르소나를 가진 특화 에이전트가 있으면 이게 안 돼요. 코딩 에이전트가 코딩 에이전트를 만드는 건 그렇다 쳐도, 수학 에이전트가 수학 에이전트를 또 만드는 건 구조가 이상하잖아요. 요즘 Codex에 대화를 포크해 와서 서브에이전트에 할당하는 기능이 새로 생겨서, 거기에 맞춰 팬아웃을 V2로 만들어 쓰고 있어요.

Q. 발제에서는 '포기 시점을 정하는 에이전트'도 설계해 보라고 했는데요. 풀다가 안 되면 물러서는 구조도 생각하셨나요?

배석현 | 하려다가 말았어요. 에이전트를 하나 늘리는 비용이 너무 크다고 봤거든요. 부분 점수를 챙길 방법도 여러 가지로 검증해 봤는데, 수학 태스크의 SymPy 문제 같은 건 어떤 방법을 써도 확정적으로 못 풀더라고요. 그래서 안 되는 건 안 되는 거다, 포기가 아니라 틀리면 틀린 거다, 하고 넘어갔습니다.

유원석 | 보통 개발을 하거나 AI를 쓸 때는, 토큰이나 쓸데없는 세션 시간을 줄이려고 에이전트가 '모른다', '포기한다'를 말할 수 있게 하는 게 연구자에게도 개발자에게도 굉장히 중요하잖아요. 그런데 이 트랙에서는 포기 시점을 정하고 다른 에이전트를 다시 불러 풀게 하는 과정이 큰 의미가 없다고 느꼈어요. 그래서 석현 씨의 팬아웃처럼 태스크를 적당히 나누고, 지능이 높은 범용 모델이 자기 능력 안에서 최대한 많이 처리하게 구조를 단순하게 만든 게 좋았다고 생각합니다.

Q. 벤치마크 영역이 코딩, 수학, 일반 세 가지였는데요. 영역마다 프롬프트를 다르게 가져가셨나요?

배석현 | 페르소나를 아예 없앤 건 아니에요. 서브에이전트 프롬프트 하나에 '수학이면 이렇게, 코딩이면 이렇게, 일반 태스크면 이렇게'를 다 넣었어요. 굉장히 긴 지시문 하나를 넣은 셈이죠. 일반 태스크는 Qwen 플래너 단계에서 바로 풀고 폴백을 내는 경우도 있었습니다. 컨텍스트나 입력 길이 제한도 있어서 제약이 많았지만, 최대한 직관적으로 쓰려고 했어요.

4. 사용해본 세 가지 모델에 대한 인상

트랙에서 래블업과 퓨리오사가 제공한 세 모델은 크기가 달랐고, 가격도 모델마다 다르게 매겨졌습니다. 최종 심사를 위한 점수 환산에는 벤치마크 점수와 함께 토큰 사용량도 반영되었기 때문에, 비싼 모델을 얼마나 아껴 쓰느냐도 각 팀에서 구사할 수 있는 전략의 일환으로 구성된 것입니다.

Q. EXAONE을 최종적으로 사용하지 않으셨어요. 이유가 무엇이었나요?

배석현 | 가장 큰 이유는 비용이었어요. EXAONE을 준 데는 이유가 있을 거라고 생각해서 이렇게 저렇게 계속 써 봤어요. 수학은 잘 풀었고, 처음 구성에서도 수학 에이전트는 EXAONE이었죠. 그런데 이 트랙의 가격 기준으로는 저희 구성에서 그 비용을 들일 만한 이유를 찾지 못해서 결국 뺐어요.

유원석 | 비싸게 매겨지긴 했는데, 그 만큼 기대한 점수가 더 오르지는 않더라고요.

Q. Qwen과 gpt-oss는 어땠나요?

배석현 | Qwen은 알쏭달쏭한 모델이었어요. 플래닝은 셋 중에서 제일 잘했어요. 플래너 자리에 gpt-oss도 넣어 봤는데 Qwen일 때 결과가 가장 좋았고, 일반 태스크는 플래너 단계에서 어느 정도 혼자 해결하기도 했어요. 그런데 구현까지 맡기면 문제를 잘 풀지 못했어요. 세 모델 중 가장 작은 모델이라 크기의 한계가 있었던 것 같아요.

gpt-oss는 정말 GPT답게 육각형이었어요. 일반 태스크, 수학, 코딩을 고르게 잘해서 임플리멘터로 그대로 갔어요. 다만 플래너로 쓸 만큼의 이점은 없었고, 모든 역할을 gpt-oss로 채우기에는 토큰 비용이 부담이라 플래너는 Qwen에 맡겼습니다.

5. AI:GO: 서브에이전트 할당 구조를 만들 수 있는 새로움

Q. AI:GO는 이번에 처음 써 보셨을 텐데요. 스쿼드를 꾸리면서 좋았던 점이 있을까요?

배석현 | 다른 하네스에는 서브에이전트 할당 구조 자체를 만드는 기능이 없잖아요. 개발자가 아니면 서브에이전트를 할당하거나 스쿼드를 구성할 방법이 아예 없는데, 그걸 GUI로 할 수 있다는 것만으로도 의의가 있다고 생각합니다.

Q. 개발자가 아니어도 스쿼드를 짤 수 있다는 점이 장점이라면, 에이전틱 도구에 익숙하지 않은 사람에게는 실제로 어땠나요?

김록연 | 저는 다른 팀원들에 비해 하네스나 에이전틱 스킬을 가장 모르는 편인데요, 그런 입장에서 보면 무엇을 하는 애플리케이션인지 다소 이해하기 어려웠어요. 탭이 좀 많고, 지원하는 기능이 많다 보니 어디서부터 출발해야 할 지 모르겠다는 느낌도 조금 받았습니다.

AI:GO는 래블업의 AI-Driven 개발 방법론을 실험하는 프로젝트였습니다. JunctionX를 통해 래블업은 AI:GO의 사용성을 업그레이드하는 작업에 착수했고, UI/UX 전문가와 함께 더욱 많은 사람들이 자신들의 하드웨어 성능을 레버리지해서 더욱 쉽게 에이전트를 돌려 볼 수 있는 환경을 구축하기 위해 노력하고 있습니다. 열심히 준비 중인 AI:GO의 2.0 버전도 기대해 주세요.

Q. 앞으로 사람보다 에이전트가 앱을 더 많이 쓰게 된다면, 화면은 어떤 모습이어야 할까요?

배석현 | 요즘 다들 그런 얘기를 하죠. 남는 GUI는 채팅창이거나 마이크일 거라고요.

이재원 | CLI든 Codex나 Claude 앱이든, 태스크가 쭉 이어지고 툴이나 에이전트가 스스로 할 수 있는 일은 사람이 계속 손대지 않잖아요. 툴을 켜고 끄는 건 따로 정리돼 있고요. 결국 화면의 중심에는 에이전트와의 소통, 그러니까 에이전트에게 무엇을 시키는지가 와야 한다고 생각해요.

6. 해커톤의 묘미는 예상하지 못한 문제를 해결하는 재미

Q. 아무래도 48시간 동안 가장 어려웠던 순간부터 여쭤보는 것이 좋을 것 같습니다. 가장 위기였던 순간이 있었나요?

배석현 | 첫날이요. 역할을 나누고 아이디어만 계속 짜다 보니 AI:GO 프로그램을 실제로 써 볼 기회가 없었어요. 모텔방으로 돌아가서 "내가 밤새서 할 테니 너희는 자" 하고 저 혼자 하나하나 뜯어봤는데요. 저는 파이썬 커널에서 검증하는 하네스가 요즘 점수를 잘 내니까, 그 방법으로 1등을 할 수 있겠다고 생각하고 있었거든요. 그런데 여기서는 외부 툴을 쓸 수 없고, 제가 짠 코드를 안에서 인식시킬 수도, 밖으로 뺐다 넣을 수도 없는 완전히 폐쇄된 환경이더라고요. 그걸 새벽 4시쯤 혼자 깨달았어요. 할 수 있는 게 없어서 일단 자고, 다음 날 아침 팀원들이 물어보길래 "우리 좀 망했다"고 했죠.

한 숨 자고 일어나서 다음 날부터 풀리기 시작했어요. 저는 하루 종일 하네스를 짜는 데 매달렸고, 재원이한테는 API 로그가 이런 구조로 찍힌다는 것만 알려 주고 "오늘 하루 종일 시각화해" 하고는 거의 말을 안 했어요. 서로 소통을 안 하고 각자 집중했죠. 어떻게 보면, 믿고 맡긴 거죠. 셋은 한 팀으로 스쿼드를 만들고 시각화는 따로 떼어 냈어요. 그때는 굉장히 불안했는데, 돌아보면 각자 할 수 있는 걸 한 그때가 가장 잘 풀린 순간이었어요.

Q. 최종 발표를 들은 저희 회사 사람들은 다들 이 팀이 우승하겠다고 생각했대요. 어떻게 준비하셨나요?

이재원 | 데모는 시각화를 세 번 거쳤어요. 처음 받은 데이터로 한 번 완성하고, 두 번째로는 리더보드에 올라온 다른 팀들의 데이터를 가져와 벤치마크를 비교했어요. 그걸 저희 모델 오케스트레이션에 반영하고 싶었거든요. 마지막에는 저희가 쓴 데이터만 다시 모아서 그걸로 발표했습니다. 무대에 올라간다는 건 한 10분 전에 알았어요. 원래는 제가 발표하기로 했는데, 스쿼드가 어떻게 돌아가는지는 다른 세 명이 더 잘 알고 있으니 같이 하자고 해서 급하게 준비했죠.

김록연 | 재밌는 일이 있었는데요. 제출하고 나서 김칫국을 마시면서, 1등 할 수도 있으니 영어로 한번 해 보자고 했어요. 그것도 정말 막판이었고 오래 한 건 아니지만, 그 덕분에 다른 팀보다 영어 발표에 아주 조금 더 준비가 되어 있었던 것 같아요.

7. 에이전틱 시대의 팀: 하나의 뇌

Q. 정션은 기획, 디자인, 개발 직군을 모아 팀을 꾸리는 해커톤이에요. 그런데 요즘은 개발자가 개발 밖의 일을 하기도, 개발자가 아닌 사람이 개발을 하기도 쉬워져서 직군의 경계가 많이 흐려졌죠. 이번 팀은 어떻게 일을 나눴나요?

유원석 | 포항 가는 KTX 안에서도 방법론이나 역할 분담 얘기를 많이 했어요. 재원 씨는 예전에 같이 한 프로젝트들에서부터 UI/UX 재능이 뛰어나서, 그쪽은 재원 씨가 혼자 맡기로 했고요.

이재원 | 재능도 재능이지만, 사실은 넷이 합의한 게 있었어요. 바이브 코딩으로 커다란 MVP를 빠르게 만들어야 하는데, 기능이 서로 얽혀 있으면 프론트를 빨리 키울 수 없거든요. 에이전트가 만드니까 더 그렇고요. 그래서 서로 분리된 구조에서 구현하기로 미리 정했어요.

배석현 | 결론은 '하나의 뇌처럼 움직이자'였어요. 우리는 한 사람이고, 이 컴퓨터들도 각자 분업하는 기계가 아니라 하나의 컴퓨터다. 다만 토큰과 요금제가 제각각이라 네 개의 스레드로 나눴을 뿐이라고요. 그래서 '난 프론트, 난 백' 하고 각자 컴퓨터에서 자기 역량만 구현하는 게 아니라, 역량을 먼저 다 모은 다음에 구현했어요. UI/UX는 아직 개인의 역량이 필요한 것 같지만, 로직을 짤 때는 특히 저희 셋이 거의 한 몸처럼 움직였어요. 노트북 세 대에서 실험을 1배치, 2배치, 3배치로 돌리는 느낌이었죠. 다른 팀들 후기를 들어 보면 '프론트가 너무 오래 걸린다', '내가 할 게 없다' 하면서 불화가 생긴 경우가 많았는데, 저희는 그러지 말자고 했어요.

이재원 | 정리하면, 기획 단계부터 소통을 1순위로 둔 게 다른 비효율을 크게 줄여 줬다고 생각해요. 모두가 같은 방향을 보고 합의하는 것이 바이브 코딩 시대에 속도와 품질 면에서 원팀으로 움직이게 해 준 방법론이었습니다.

Q. 에이전트가 디자인도 코딩도 거의 다 하는 시대에, 팀에서 사람이 딱 하나 쥐고 있어야 한다면 무엇일까요?

배석현 | 저는 기술 스택이 중요하다고 생각해요. 제가 해커톤에서 상을 받는 것도 사실 기술 스택의 차이라고 보고요. 아키텍처를 짤 때 프레임워크는 뭘 쓸지, 배포는 뭘로 할지, 컴포넌트 라이브러리는 뭘 쓸지, 이런 선택 하나하나가 다 스택이에요. 비개발자는 시켜 놓고 하라는 대로 하게 두지만, 시행착오 없이 그때그때 맞는 스택을 골라 결정하는 능력이 지금 바이브 코딩을 잘하고 못하는 차이를 가르는 딱 하나라고 봐요. 개발자 입장의 얘기로 들릴 수도 있지만, 그래서 오히려 지식을 많이 쌓아야 한다고 생각합니다.

유원석 | 저는 직관을 꼽고 싶어요. 프로젝트를 할 때 PRD나 TRD 같은 문서를 쓰면서 우리가 만드는 방향과 맞는지 다시 검증하잖아요. 직관이 있으면 그걸 더 쉽게 고치고, 방향을 더 확고하게 밀고 나갈 수 있어요.

이재원 | 저는 주인의식이라고 생각해요. 서브에이전트를 아무리 많이 돌리고 멀티태스킹을 많이 해도, 결국 내가 책임지는 범위가 어떻게 돌아가는지는 직감으로 파악하고 있어야 해요. 2026년의 트랜스포머 구조는 사람이 20년, 30년 반복 훈련하며 앞을 계획하는 능력을 아직 구조적으로 갖추지 못했다고 봐요. 시간을 사람처럼 인식하지 않으니까요. 그래서 기획하고 방향을 정하는 건 여전히 사람의 역량이 큽니다.

8. 해커톤이 남긴 것

Q. 이번 해커톤에서 얻은 것을 한마디씩 부탁드려요.

배석현 | 저희 프로젝트보다 다른 프로젝트들을 보면서 명분이 굉장히 중요하다는 걸 느꼈어요. 바이브 코딩이든 뭐든 그 드라이브가 중요하다고 생각하는데, 해커톤에 나갈 때마다 명분 없이 아이디어를 위한 아이디어가 많다고 느껴요. 저희가 트랙 3를 고른 이유도 그거였고요. 명분이 없으면 좋은 결과물이 안 나온다, 드라이브를 잘 갖추거나 없으면 하지 않는다는 생각이 더 확고해졌습니다.

김록연 | 저는 리더의 중요성이요. 좋은 의견은 많이 나올 수 있지만, 결국 그걸 잘라 내고 하나를 고르는 건 리더예요. 빠르게 잘라 내고 좋은 방향을 제시해 주는 리더가 있었다는 게 저희 팀의 차별점이었습니다.

유원석 | 기초 지식의 중요성을 다시 깨달았어요. 방향을 확신할 수 있게 해 준 건 결국 기본적으로 알고 있던 지식이었거든요.

이재원 | 자기 아이디어를 설명하는 능력이요. 팀원들이 생각을 하나로 모으려면 각자의 아이디어가 제대로 설명돼서 사람에서 사람으로, 사람에서 AI로 전해져야 해요. 그 능력이 없으면 에이전트에게 전부 맡길 수밖에 없고요. 기업 단위로 봐도, 한 사람이 에이전트와 무엇을 했든 다른 사람에게 전하지 못하면 그 아이디어는 거기서 끝난다고 생각해요.

Q. 마지막으로, 못다 한 이야기가 있다면요?

이재원 | GPU 클러스터 기업이든, 반도체를 만드는 기업이든, 그 위에 무언가를 얹어 AI 서비스를 만드는 기업이든, 국내 기업들이 다 정말 잘됐으면 좋겠어요. AI 기술이 아니더라도 인프라 자체가 국력이라고 생각하거든요. 저는 그게 명분이라고 봐요.

배석현 | 정션에 갔을 때 트랙 3가 있어서 정말 재밌었어요. 저 같은 사람들이 놀 수 있는 놀이터 같은 주제였어요. 대표님을 비롯해 래블업 분들이 많이 와서 질문을 다 받아 주시고, EXAONE을 쓰니 마니 하면서 함께 풀어 간 과정이 개인적으로 너무 재밌었어요. 대표님은 경영하는 사람이 아니라 만든 사람이라는 느낌이 물씬 났고요.

---

이번 트랙을 준비하며 저희도 고민이 많았습니다. 참가자는 학생부터 현업까지 경험의 폭이 넓었기 때문에, 과제의 난이도를 어느 수준에 맞출지와 무엇을 주제로 삼을지를 두고 오래 논의했습니다. 이틀 가까이 주제를 정하지 못하던 저희에게 시각화라는 아이디어를 건넨 사람은 지나가던 래블업 CTO였고, 그 5분의 제안이 이번 트랙의 두 번째 과제가 됐습니다.

해커톤과 이번 인터뷰를 거치며 이 트랙을 고른 사람들이 어느 정도의 기술 지식을 갖추고 어디에 관심을 두는지 확실하게 느낄 수 있었습니다. 모델과 하네스를 직접 뜯어보고, 48시간 안에 스쿼드 구조를 여러 차례 바꾸고, 자기만의 방법론에 이름을 붙여 쓰는 모습에서 그 긱(Geek)한 면모와 함께 열정을 볼 수 있었고, 저희도 많은 영감을 받았습니다. 긴 시간 이야기를 나눠 준 데모 데이 케어 팀의 배석현, 이재원, 유원석, 김록연 님께 감사드립니다. 래블업이 트랙을 준비하고 운영한 이야기는 JunctionX Korea 2026 해커톤 회고에서 확인할 수 있습니다.

---

Interviewee 배석현, 이재원, 유원석, 김록연 (Demo Day Care)

Interviewer, Editor, and Photographer 허진호 (래블업)