해커톤에서 배운 것 - 잘 만드는 것과 보여주는 건 다른 일이었다

제출을 몇 시간 앞둔 새벽이었다. 시연 영상에 넣을 앱 화면을 찍고 있는데 갑자기 지도가 안 떴다.

확인해보니 카카오맵 API 한도 초과였다. 돈을 내고 쓰려고 봤더니 승인까지 3~5일이 걸린단다. 제출까지는 몇 시간밖에 안 남았는데. 결국 다른 팀원 계정으로 키를 새로 파서 갈아 끼우고 나서야 겨우 숨을 돌렸다.

그날 밤 내가 넘긴 건 전부 이런 종류의 문제였다. 그게 심사에서는 별 소용이 없다는 걸 다음 날 발표장에 가서야 알았다.

TECH4GOOD은 하나 청년 금융인재 과정 중간에 있던 1박 2일 해커톤이다. 하나 참가자 54명과 SKT FLY AI 참가자 61명이 섞여서 팀을 새로 짰다. 주제는 '포용적 미래를 위한 AI 서비스'. 우리 팀은 7명이었고, 전원 처음 보는 사람들이었다.

그 과정 얘기는 따로 적었고, 이 글은 그 한복판에 끼어 있던 이틀이다.

처음 만난 일곱 명이 반나절을 아이디어에 썼다

시작하자마자 누가 먼저랄 것 없이 말을 놓자고 했고, 그게 이틀을 살렸다고 생각한다. 존댓말 사이에 숨을 데가 없으니까 의견이 그냥 나왔다.

첫날 오전 10시에 모여서 인사하고, OT랑 레크리에이션으로 어색함을 풀었다. 12시쯤 다 같이 밥을 먹고 나서 본격적인 회의가 시작됐다.

각자 가져온 아이디어를 공유하고, 누구 아이디어가 제일 좋은지 토론하고 투표했다. 주제가 확정된 게 오후 3~4시였다.

1박 2일짜리 해커톤에서 반나절을 아이디어에 쓴 셈인데, 지금 생각해도 이 시간은 아깝지 않았다.

비어 있던 자리를 내가 맡았다

신청할 때 각자 잘하는 분야를 체크하고 들어온 팀이라 구성 밸런스가 좋았다. 기획·발표 3명, 프론트 1명, AI 2명, 백엔드는 나 하나.

서로 잘하는 걸 소개하고 역할을 딱딱 나눴는데, 어쩌다 보니 나는 개발 전체를 조율하는 역할까지 하게 됐다. 누가 시켜서가 아니었다. 그 자리가 비어 있었고, 하나 프로젝트에서 그 빈자리가 팀을 어떻게 망가뜨리는지 이미 겪어봤기 때문이다.

이 서비스에 어떤 API가 얼마나 필요한지부터 조사해서 개발 기획을 구체화했다. 프론트가 할 일과 AI 쪽이 할 일을 명확하게 정리해주고, 프론트에서 얼추 가닥이 잡히고 나서야 내 백엔드 작업에 들어갔다.

몇 달 전의 나라면 상상도 못 할 일이다. 그때의 나는 회의에서 아이디어가 있어도 입을 다물고 있다가 남의 결정에 올라타는 쪽이었는데, 이번엔 머릿속에 있는 걸 전부 꺼내서 보여줬다.

타겟을 좁히니 만들 게 보였다

아이디어 후보로 시각장애인, 노약자 등 여러 타겟이 나왔다. 나는 거동이 불편한 교통약자로 잡자고 제안했다.

길찾기 서비스의 핵심은 결국 시간과 경로다. 그런데 계단·경사·엘리베이터·저상버스 같은 조건 때문에 표준 예상 도착시간이 실제와 가장 크게 벌어지는 사람들이 바로 이들이었다. 타겟이 선명해야 주제도 부각된다고 봤다.

그렇게 나온 게 My ETA다. 교통약자를 위한 개인화 길찾기 앱으로, 서울시 엘리베이터·저상버스·지하철 실시간 정보를 TMAP 경로 위에 얹고 개인 보행속도까지 반영해서, 표준 예상 시간이 아니라 "나의 도착시간"을 보여준다.

팀에서 카카오맵 API, TMAP API, 공공데이터 API를 실제로 다뤄본 사람이 나뿐이라, 어떤 데이터를 어디서 가져와 어떻게 조합할지는 내가 구체적으로 제안할 수 있었다.

그 밤에 넘긴 건 전부 기술 문제였다

말은 쉬운데, 10개가 넘는 API를 하나의 앱 안에 통합하는 건 전혀 다른 문제였다. 규모가 크지 않은 프로젝트라 개발이 금방 끝날 줄 알았는데, 코드보다 API 신청 절차가 발목을 잡았다.

신청 과정이 복잡한 건 기본이고 결제까지 해야 하는 것도 있었다. 저상버스 API는 승인을 받아놓고도 정작 데이터를 쓸 수가 없어서, 결국 그 부분은 목 데이터로 처리할 수밖에 없었다.

사람 쪽 이슈도 있었다. 프론트 담당 팀원이 개발 초보라 밤이 깊어지고 기술적으로 복잡해지자 손을 못 대는 상황이 왔다. 그래서 프론트를 같이 보던 다른 팀원에게 클로드 사용법을 처음부터 끝까지 설명해주면서 어떻게든 개발이 굴러가게 만들었다.

내 백엔드는 오래 안 걸렸는데 프론트, API, AI를 다 정리하고 나니 다음 날 오전 8시였다. 그 와중에 새벽엔 카카오맵 한도까지 터진 거고.

솔직하게 적어두자면, 개인화 ETA 계산도 끝내 발표에 쓸 만큼 완성하지 못했다. 그래서 저상버스 데이터와 ETA 계산, 이 두 곳은 목 데이터로 시연했다. 나머지 API 연동과 앱 흐름은 진짜였다.

그런데 심사는 장면을 봤다

한숨도 못 자고 발표장에 앉았다. 발표는 팀원이 맡았고 나는 개발 쪽으로 들어올 예상 질문과 답변을 준비해 줬다. 우리 발표를 들으면서, 질의응답이 매끄럽게 넘어가는 걸 보면서, 이번엔 진짜 수상을 기대했다.

못 받았다.

이유는 발표장에서 이미 보였다. 우리가 보여준 건 결국 숫자와 경로였다. 화면에서 도착 시간이 바뀌고 경로가 바뀐다.

기술적으로는 할 말이 많은데, 보는 사람 입장에선 "오"까지는 안 나온다. 수상한 팀들은 달랐다. 보이스, 동화책, 앱 사용 시뮬레이션 같은, 짧은 발표 안에서 바로 감정이 움직이는 결과물을 들고 왔다.

숫자와 경로로는 사람이 안 움직인다. 해커톤에서는 재미없고 뻔한 완성품보다, 미완성이어도 사람에게 감동과 흥미를 주는 프로젝트가 통한다.

기술이 필요 없다는 얘기가 아니다. 기술적 타당성 위에 문제가 해결되는 순간을 짧고 인상적으로 체험시키는 장면이 하나는 있어야 한다는 얘기고, 우리한테는 그게 없었다. 잘 만드는 일과 그걸 보여주는 일이 서로 다른 일이라는 걸 그 이틀에 배웠다.

그래도 내 인생 최고의 팀플이었다

그게 팀 탓은 아니었다. 상을 못 받았는데도 이 팀은 내가 살면서 해본 팀플 중 가장 매끄럽고 좋은 경험이었다. 각자 확실히 잘하는 게 있으니 서로 존중하고 믿고 맡기는 분위기가 됐고, 의견이 갈려도 일단 듣고 조율이 됐다. 그 사람들은 지금도 좋게 기억한다.

아쉬움은 팀이 아니라 나한테 남았다. 내가 아이디어를 더 내고, 개발을 더 잘했다면 우리 팀이 더 좋은 점수를 받지 않았을까.

하나 프로젝트에서의 아쉬움이 "말을 못 한 것"이었다면, 여기서의 아쉬움은 "더 잘하고 싶은 것"이었다.

그래서 다음에 뭘 만들든 심사장에 들고 갈 장면 하나는 먼저 정해두려고 한다. 기능 목록 말고, 보는 사람이 한 번에 "아" 하는 장면.