16팀 48명이 이틀 만에 실제 서비스를 만들어내기까지, 무대 뒤에서 준비한 것들.
이틀 안에 아이디어 기획서에 그치지 않고 실제로 동작하는 서비스까지 만들어낼 수 있을까요? 지난 2026년 10월 14일부터 15일까지 열린 ‘AID-X 해커톤 Pro-Code’는 바로 그 질문에 도전한 실전 개발 대회였습니다.
이름에 붙은 ‘Pro-Code’라는 말처럼, 이번 대회는 발표 장표로 아이디어를 겨루는 자리가 아니었습니다. KT의 8개 부문·실과 그룹사(밀리의 서재, BC카드, kt ds, kt cloud)에서 모인 참가자 48명이 3명씩 16개 팀을 이뤄, AI 코딩 도구를 파트너 삼아 이틀 동안 직접 코드를 짜고 완성된 웹 서비스를 시연했습니다. 주제는 현업의 고민과 맞닿아 있는 네 가지(‘모두의 AI’, ‘나만의 디지털 트윈’, ‘Always On’, ‘AI Skill.registry 포털’)로 주어졌습니다.
참가자들이 이틀 동안 개발에만 몰입하려면 무대 뒤에서는 훨씬 긴 준비가 필요했습니다. 대회 전에는 48명이 같은 환경에서 출발할 수 있도록 도구와 작업 공간을 갖춰야 했고, 대회 중에는 각 팀이 어디까지 만들고 있는지 실시간 화면으로 비추며 응원도 모아야 했습니다. 개발이 끝난 뒤에는 제출된 결과물과 심사 점수를 빈틈없이 취합해 다음 활용으로 이어주는 일까지 하나의 흐름으로 맞물려야 했습니다.
저는 이 전 과정을 뒷받침할 운영·평가 시스템을 AI와 함께 직접 개발했고, 16명의 동료들과 인프라·사전 점검·현장 운영을 함께 챙겼습니다. 1편에서는 48명의 참가자를 맞이하기 전의 고민부터 뜨거웠던 이틀의 현장, 그리고 대회가 끝난 뒤의 이야기까지 차근차근 돌아보려 합니다.
대회 전 · 48명을 맞이하기까지
01. 대회가 끝난 뒤, 무엇을 남길까
대회를 기획하며 가장 먼저 던진 질문은 “시상이 끝난 뒤에도 이 결과물들이 살아남을 수 있을까?”였습니다. 흔히 해커톤은 발표 현장에서 멋진 시연을 보여주고 나면 행사가 마무리됩니다. 하지만 나중에 현업 부서에서 “그 서비스 우리 업무에 써볼 수 있나요?” 하고 찾아와도, 당일 만든 프로그램 코드만 덩그러니 남아 있으면 왜 이렇게 설계했는지, 어떻게 켜서 확인해야 하는지조차 알기 어렵습니다.
그래서 이번 대회는 진행 방식 자체를 조금 다르게 정했습니다. 참가팀이 이틀 동안 단순히 화면만 코딩해 발표하는 것이 아니라, 실제 현업에서 서비스를 만들듯 ‘기획 → 설계 → 개발 → 보안 점검 → 테스트’의 전 과정을 밟으며 코드 옆에 인수인계 설명서를 함께 완성하는 것을 대회 과제로 삼았습니다. 그래야 대회가 끝난 뒤 다른 조직이 결과물을 넘겨받더라도 처음부터 다시 설명을 듣지 않고 곧바로 검토와 후속 개발을 시작할 수 있기 때문입니다.
물론 이틀이라는 짧은 시간에 참가팀이 문서 형식까지 새로 고민하게 할 수는 없었습니다. 그래서 운영진은 팀별 온라인 공동 작업 공간(GitHub 저장소)을 미리 열어 두고, 그 안에 모든 팀이 똑같이 채워 넣을 수 있는 공통 문서 틀 8종과 주최 측 보안·작업 기준 2종을 미리 넣어 두었습니다. 참가팀은 서비스를 만들어 가면서 아래 목록의 빈칸을 채우듯 자연스럽게 문제 정의와 설계 의도, 실행 방법, 보안 점검과 테스트 결과를 남겼습니다.
결과물 기록과 더불어 ‘개발하는 과정 자체’를 현장에서 함께 볼 수 있는 장치도 준비했습니다. 완성된 발표 화면만으로는 각 팀이 AI와 어떤 시도를 주고받았고 어디서 고비를 넘겼는지 알기 어렵기 때문입니다. 참가자의 AI 활용 기록을 모으고, 팀별 진척도와 사내 응원을 실시간 중계하며, 발표 자료와 심사 점수까지 한곳에 담는 전용 운영 시스템을 직접 만들기로 한 이유였습니다.
02. 48명이 같은 출발선에 설 수 있도록
서로 다른 부서와 그룹사에서 모인 48명이 당일 아침 같은 출발선에 서려면 행사장 밖에서부터 환경을 맞춰야 했습니다. 참가자들은 사전에 사내 보안망(VPN) 접속과 계정 권한을 확인하고, 대회에서 지원한 두 가지 AI 코딩 도구(Claude Enterprise, GitHub Copilot Enterprise)와 개발 기록 수집 프로그램을 각자의 노트북에 설치했습니다.
운영진은 사전 설명회를 열고, 참가자가 여러 공지를 헤매지 않도록 일정·설치·제출 절차를 한곳에 모은 사전 안내(온보딩) 웹페이지를 운영했습니다. 안내 문구와 실제 설치 파일의 버전을 일치시키고, 주제 공개 시점에 맞춰 16개 팀의 작업 공간과 운영·평가 화면의 팀 명단이 어긋나지 않는지도 미리 점검했습니다.
03. 참가자에게는 하나의 대회여야 했다
참가자 눈에는 사전 안내부터 실시간 중계, 응원, 최종 평가까지가 끊김 없는 하나의 대회로 보여야 했습니다. 이를 위해 여러 웹 화면과 서버를 사내 클라우드 실험 환경(Azure Sandbox) 위에 하나로 묶어 구축했습니다.
외부 접속은 앞단 안내 창구인 중계 서버(Caddy)가 받아 각 화면으로 연결했습니다. 행사 중 수시로 손봐야 하는 중계·응원·평가 등 8개 웹 서비스는 한쪽을 고칠 때 다른 화면이 영향받지 않도록 독립된 컨테이너 환경(ACA)에 나눠 올렸습니다. 당시 네트워크·파일시스템 제약으로 중계 서버와 대용량 기록 저장소(ClickHouse)는 한 가상 서버(VM)에 함께 두었고, 단일 서버 장애에 대비해 백업·복구 절차를 별도로 마련했습니다.
48명의 노트북에서 보내오는 개발 기록이 유실되지 않도록 수집 경로도 단계별로 나눴습니다. 네트워크가 잠시 흔들려도 노트북에 기록을 임시 보관했다가 재전송하게 했고, 서버에서는 수신 창구(OpenTelemetry Collector)와 중간 대기열(Event Hubs)을 거쳐 저장 프로그램(writer)이 데이터베이스에 적재하도록 역할을 분리했습니다.
데이터 성격에 따라 보관 장소도 나눴습니다. 대량으로 쌓이는 AI 활동 기록은 분석용 저장소(ClickHouse)에, 계정·제출 자료·점수·응원 기록은 관계형 데이터베이스(PostgreSQL)에 담고 운영 설정과 백업 사본도 따로 분리했습니다. 다만 AI 도구와 버전마다 내보내는 기록 범위가 달라 모델 내부의 전체 문맥이나 부가 기능(MCP·Skill)의 모든 실행을 남긴 것은 아니며, 도구의 연결 기록과 실제 실행 기록도 구분해 다뤘습니다.
대회 중 · 개발과 응원, 발표가 이어지는 동안
04. 설치가 끝났다고 준비가 끝난 것은 아니었다
대회 당일 현장에서 노트북을 열자 사전 설치만으로는 알 수 없던 변수들이 나타났습니다. 참가자마다 운영체제(OS)와 설치 버전, AI 도구 실행 방식이 조금씩 달랐기 때문입니다. “설치했어요”라는 말만으로는 충분하지 않아 수집 프로그램 실행 여부, 전송 설정 활성화, 서버 도착과 화면 표시까지 단계별로 확인했습니다.
사람과 기록을 짝짓는 일도 신중해야 했습니다. 한글 명단과 다른 영문 계정으로 들어오거나 재설치로 새 기기 번호가 생긴 경우, 이름만 보고 합치면 다른 사람의 기록이 섞일 수 있어 본인 확인을 거쳐 기존 기록을 보존한 채 연결했습니다.
Copilot 안에서 Claude 모델을 호출한 기록과 별도 터미널로 실행한 Claude Code 기록처럼 수집 경로가 다른 사례도 구분해 대응했습니다. 바뀐 설정을 읽지 못하던 점검 도구의 오류는 새로운 버전에서 바로잡았지만, 안내 수정 뒤에도 실제 PC에서 기록이 다시 들어오는지는 따로 확인했고 무엇을 수집했고, 무엇을 확인하지 못했는지도 투명하게 남겼습니다.
05. 캐릭터들이 하나둘 뛰기 시작했다
현장에서 연결을 하나씩 맞추고 나자, 대형 중계 화면 속 캐릭터 48명이 하나둘 움직이기 시작했습니다. 설정과 로그로만 보던 연결 작업이 모두가 함께 바라보는 장면으로 바뀌는 순간이라 꽤 뿌듯했습니다.
캐릭터들은 최근 10분간의 프롬프트·활동 기록을 바탕으로 달리기·걷기·대기 상태를 보여줬습니다. AI 사용량(토큰)이 많다고 더 빨리 달리게 하지는 않았습니다. 잠시 손을 멈추고 설계를 고민하거나 팀원과 상의하는 시간도 필요하기 때문에, 대기 상태만으로 수집 장애나 개발 성과를 단정하지 않도록 했습니다.
제 모니터에서 잘 보이는 것만으로는 부족해 행사장 대형 화면에 맞춰 글자 크기와 캐릭터 간격을 조정하고 하이라이트도 실제 재생까지 확인했습니다.
06. 팀의 작업을 경기장 한 바퀴로 보여줬다
개인의 활동은 캐릭터로, 팀 단위의 완주 과정은 경기장 트랙으로 보여줬습니다. 참가팀에는 구현할 기능과 해결할 문제를 공동 작업 공간의 ‘할 일 카드(GitHub Issue)’에 등록하고, 완료 조건을 확인한 뒤 닫도록 안내했습니다. 시스템은 전체 카드 중 완료된 비율을 읽어 트랙 위 팀 위치로 바꿔 보여줬습니다.
단순 코드 병합 요청(Pull Request)이나 취소·중복으로 닫은 카드는 집계에서 제외했습니다. 팀마다 작업을 나누는 크기가 다르기 때문에 이 진행률은 현장의 흐름을 함께 보기 위한 표시였을 뿐, 코드 품질이나 심사 점수를 뜻하지는 않았습니다.
07. 응원글이 쌓이면서 화면의 느낌도 달라졌다
행사장 밖 동료들도 함께할 수 있도록 온라인 응원 페이지를 열었습니다. 위 이미지는 행사 초반 하트 161개가 모였을 때의 실제 화면인데, 응원 메시지가 쌓이자 현장 분위기도 한층 따뜻해졌습니다. 상태를 점검하려 띄워 둔 화면에서 응원 문장을 읽다 보면 준비한 보람이 고스란히 느껴졌습니다.
실시간으로 글이 올라오자 새 글마다 화면이 맨 아래로 끌려 내려가는 불편도 바로 고쳐, 읽던 스크롤 위치를 유지하고 최근 300개 응원글 다시보기 기능을 추가했습니다. 밖에서도 볼 수 있도록 송출용 PC에 방송 프로그램(OBS)을 설치해 유튜브 라이브로 중계했고, 최종 백업에는 공식 16팀 기준 누적 하트 1,340개와 공개 응원글 400개(행사 이틀간 하트 1,038개·응원글 274개)가 남았습니다.
08. 발표가 시작되자 확인할 것도 달라졌다
발표가 시작되자 챙겨야 할 대상도 개발 기록에서 발표 자료와 채점 입력으로 바뀌었습니다. 평가는 AI 기술평가 70점·동료평가 10점·심사위원 평가 20점으로 구성했습니다.
발표 직후에는 심사위원 화면의 점수 버튼이 눌리지 않는 아찔한 상황도 있었습니다. 운영자 콘솔에서 행사를 ‘발표 단계’로 바꾸는 설정과 평가 포털(Eval)의 점수 입력창을 여는 설정이 따로 나뉘어 있었기 때문입니다. 우선 수기로 기록한 초기 점수를 입력창 개방 뒤 포털 저장 값과 대조하며 수습했습니다.
이후에도 확인은 계속됐습니다. 심사위원 점수는 시스템상 최소 6명부터 집계할 수 있었지만 실제 운영에서는 오전·오후 확정 7명 전원의 입력 완료를 확인했고, 미입력 칸을 0점으로 채우지 않도록 했습니다. 동료평가는 팀 공용 계정으로 다른 세 주제에서 한 팀씩 총 세 팀을 교차 평가하도록 했으며, 저장·합산·확정·공개 단계도 각각 분리해 관리했습니다.
AI 기술평가는 Claude·Codex·Copilot 세 도구로 준비했습니다. 처음에는 제출된 서비스를 직접 실행해 확인하려 했지만, 대용량 자료를 정리하고 팀마다 다른 실행 환경을 준비하는 데 예상보다 많은 시간이 들었습니다. 발표 전까지 평가를 마치기 위해 확보한 실행 시험 근거를 보존하면서 코드와 문서를 대조하는 정적 검토로 전환했습니다. 구체적인 평가 과정과 한계는 2편에서 다루겠습니다.
대회 후 · 남은 기록을 다음으로 이어가기
09. 행사는 끝났지만 정리는 남아 있었다
대회가 끝난 뒤에는 데이터베이스와 제출물, GitHub 소스, 배포 설정, AI 작업 세션을 백업하고, 격리 환경에 실제로 복원해 원본과 대조한 뒤에야 서비스를 순서대로 중지했습니다. 운영·행사·개발 리포트에는 관측 통계와 함께 도구별 수집 한계를 나란히 적었습니다.
여러 AI 도구를 오가며 개발하다 보니 왜 그렇게 결정했고 무엇을 고쳤는지 다음 대화에서도 바로 이어갈 수 있어야 했습니다. 그 결정 이유와 수정 내역, 실패한 시험 결과를 문서로 남기고 서로 연결한 작업 기록소가 llm-wiki입니다.
10월 16일 기준 해커톤 관련 문서는 과거 판본과 검증 사본을 포함해 2,731개가 쌓였고, 문서 연결 지도(Obsidian 그래프)로 펼쳐보니 설치 점검부터 현장 의사결정 이력까지가 촘촘히 이어져 있었습니다.
다만 문제를 고치느라 정작 잘 돌아가던 응원 화면 사진을 충분히 남기지 못한 점은 아쉬운 배움으로 남았습니다.
10. 결과물과 운영 경험을 다시 꺼내봤다
정리를 마친 뒤에는 처음 던졌던 질문으로 돌아가, 결과물을 필요로 하는 조직이 쉽게 검토할 수 있도록 네 주제별 16팀의 소스와 문서·발표 자료를 다시 대조했습니다. 팀별 강점·한계와 통합 아이디어를 정리하고 직접 눌러보며 흐름을 살펴볼 수 있는 예시 포털로 묶었습니다. 실제 현업 서비스로 도입하려면 별도의 본개발과 인수 검증이 필요합니다.
네 주제는 다음과 같은 후속 활용 방향으로 연결할 계획입니다.
- 모두의 AI: 모두의 AI TF에 전달
- 나만의 디지털 트윈: 경영플랫폼팀·IT역량강화팀에 전달
- Always On: AI&아키텍처컨설팅팀에서 아이디어를 통합해
kode:crew·kode:harness고도화 추진 - AI Skill.registry: AI&아키텍처컨설팅팀·DevOps엔지니어링팀에서 아이디어를 취합해 개발에 반영
운영 시스템 역시 현장에서 겪은 단계·입력창 분리 문제, 동료평가 사전 점검, 수집 프로그램 진단 등을 보완해 재배포용 구축 패키지로 묶었습니다. 실제 행사 데이터와 예시 데이터를 분리해 정리했으며, 새 망 환경의 권한·네트워크·파일 서명·전체 복구 검증은 다음 도입 단계의 과제로 남겨두었습니다. 참가자 설문과 운영진 회고 의견까지 더해 다음 대회를 준비하고 있습니다.
사전 안내 하나, 수집 연결 하나, 점수 저장 하나가 끊기지 않고 이어져야 참가자에게는 비로소 ‘하나의 대회’가 된다는 사실을 배웠습니다. 함께 준비하고 고생한 16명의 동료들, 끝까지 결과물을 완성한 48명의 참가자, 화면 너머로 응원해준 모든 분께 감사드립니다. 사람이 현장에서 일일이 메웠던 빈틈을 시스템과 기록으로 채워, 다음 대회는 더 자연스럽게 이어가려 합니다.
2편 · AI 기술평가 이야기 (Coming soon)
공통 평가 기준과 제출본 준비, Claude·Codex·Copilot 검토 운영과 정적 검토 전환 과정, 확인한 근거와 한계를 점수에 연결한 방법을 자세히 다룹니다.