[AI 해커톤 후기] AI 시대의 해커톤과 인간의 역할: AI의 계획과 사람의 전략

모두가 같은 주제로, 같은 수준의 AI 도구를 들고 시작한 해커톤. 그런데 결과물은 팀마다 전혀 달랐습니다. 같은 도구를 썼는데 왜 결과는 달라졌을까요?

네이버가 전사 차원에서 처음으로 개발자와 비개발자의 구분 없이 연 모두의 Engineering Day AI 해커톤에서 가장 흥미로웠던 질문입니다.

이 글은 그 질문에 대한 회고로, AI를 어떻게 활용했는지, 그리고 끝까지 사람의 몫으로 남은 일은 무엇이었는지 정리했습니다. 결론부터 말하면 AI는 계획(planning)에 강했고, 끝까지 사람의 몫으로 남은 일은 전략(strategy)이었습니다.

해커톤의 배경

이번 해커톤은 사내에서 실제로 겪는 문제를 해결하는 방식으로 진행됐습니다. 출제자(problem holder)가 문제와 요구 사항을 제시했고, 팀은 선발된 세 가지 문제 중 하나를 배정받았습니다. 요구 사항은 반드시 충족해야 하는 Must 항목과 추가로 해결하면 좋은 Nice 항목으로 나뉘었습니다.

제약은 분명했습니다. 짧은 시간 안에 사내 인프라와 보안 환경에서 실제로 동작하는 결과물을 만들어야 했습니다. 단순 데모로는 충분하지 않고 사내 시스템과 실제로 연동되어야 한다는 점이 가장 어려웠습니다. 평가는 코드 실행 없이 결과물 문서(readme.html)와 저장소 정적 분석으로 이뤄졌고, 사람과 LLM이 함께 심사했습니다.

저희 팀이 맡은 과제는 사내 경비 정산 자동화였습니다. 목표는 사내 메신저인 WORKS로 영수증 사진 한 장만 보내면 정산을 끝낼 수 있게 만드는 것이었습니다.

무엇을 만들었나

저희 팀은 WORKS로 영수증 사진을 보내면 OCR, 비용 분류, 카드 내역 매칭, 임시 저장까지 처리하는 정산 봇과 PC 인증을 위한 크롬 익스텐션을 만들었습니다.

사내 인증 세션의 SSO 쿠키가 PC 웹에서만 전달된다는 제약 때문에 WORKS 챗봇만으로는 정산 API를 호출할 수 없었습니다. 그래서 크롬 익스텐션이 최초 1회 인증 세션을 수행하고, 이후 WORKS 챗봇이 영수증 정산 흐름을 처리하는 2단계 구조를 선택했습니다. 봇 서버는 사내 PaaS에 배포했습니다.

그 결과, 매월 1시간 이상 걸리던 정산 작업을 영수증 10장 기준 약 30초, 사용자 액션 2번으로 줄일 수 있었습니다.

시스템 구성

전체 구조는 크롬 익스텐션, WORKS 봇 플랫폼, FastAPI 기반 봇 콜백 서버, 외부 연동 API군으로 이어집니다. 크롬 익스텐션이 인증 세션을 한 번 확보하면, 이후 영수증 처리는 콜백 서버가 비동기로 진행합니다.

1. 해커톤 자체에 대한 회고

이번 해커톤에서 가장 흥미로웠던 점은 모두가 같은 주제로 같은 수준의 AI 도구를 썼는데도 접근법, UI/UX, 활용 방식까지 산출물이 제각각이었다는 것입니다. AI가 항상 최적의 답을 준다면 '같은 주제'의 산출물은 하나로 수렴해야 할 텐데 실제 결과는 달랐습니다. 그 차이를 만든 것은 완성도를 더 끌어올리고자 하는 사람의 의지였습니다.

개발 그 이상의 영역 — 사람의 개입이 필요한 순간

실제 병목은 코드 작성이 아니라 WORKS 봇 권한 신청과 타 부서가 관리하는 경비 API 명세 확보 과정에서 발생하는 '불확실성'이었습니다. 이 문제는 AI에게 더 많은 컨텍스트를 준다고 해결되지 않았습니다. 인증 방식이 바뀌었는데 사내 문서는 최신 상태가 아니었습니다. 외부 문서는 저희 환경과 달라 AI도 혼란스러웠고, 경비 API는 공개 문서가 없어 담당자부터 찾아야 했습니다.

그래서 휴먼 인 더 루프를 적용해 역할을 나눴습니다. 사람은 아웃라인, 부서 소통, 업무 분장을 맡고, AI는 세부 구현, 코드 생성을 맡았습니다. 모듈 통합에는 AI를 오케스트레이터로 활용했습니다.

계획과 전략의 차이

계획은 목표를 작은 작업으로 쪼개고, 구현 순서를 정하는 일입니다. 이 영역에서 AI는 탁월했습니다. 반면, 전략은 불확실성 속에서 이기기 위한 가설과 방향을 세우는 일입니다. 사내 인프라의 제약을 어떻게 넘을지, 어떤 기능을 먼저 완성해야 평가단의 문제 의식을 정확히 건드릴지와 같은 결정은 AI가 대신하지 못했습니다. AI가 '어떻게 만들지'는 정할 수 있어도, '이기기 위해서는 무엇을 해야 할지'는 사람의 몫이었습니다.

프로세스 민첩성을 위한 바이브 코딩

주어진 시간이 짧았으므로 저희는 오버헤드가 큰 문서 중심 개발(SDD)은 과감히 배제하고 도메인 지식을 바탕으로 AI와 빠르게 주고받는 바이브 코딩 을 택했습니다. 일부 팀이 plan.md 셋업에 리소스를 쏟다 속도가 느려지기도 한 것을 보면, 단기 스프린트에서는 형식적 프로토콜보다 휴리스틱과 유연한 애자일이 더 잘 맞았습니다.

인프라/보안과 '책임 있는 투명성'

구현을 서두르는 과정에서 사내 보안과 권한 프로세스의 사각지대도 발견했습니다. 저희 팀은 이를 편법으로 이용하는 데 그치지 않고, 해커톤 종료 직후 관련 부서에 내용을 투명하게 공유했습니다. 덕분에 단순히 해커톤 산출물을 내는 것을 넘어 전사 공용 플랫폼 보안에 선제적으로 기여하고, 동시에 정산 자동화가 실제 업무에도 충분히 적용 가능하다는 것을 확인해 정식 기능 출시 검토까지 이어진 것이 가장 값진 성과였습니다.

2. 개발 파트 회고: 속도와 안정성의 균형을 찾아서

개발 파트는 각자의 도메인을 책임지되, AI를 공통 언어로 삼아 조립해 나가는 과정이었습니다.

작은 블록으로 나누기

저희 팀은 레고식 개발을 적용해 전체 시스템을 인증 캡처, 경비 API 연동, 봇 콜백 서버, 메시지 송신, OCR, LLM 분류라는 6개의 독립 블록으로 나눴습니다. 각자 AI를 사용해 각 블록을 빠르게 구현한 뒤 AI에게 인터페이스 포팅과 머지를 맡겼습니다.

출처: OpenAI Harness engineering

검색, 리서치, 로그를 컨텍스트로 제공

AWS, GCP 등의 퍼블릭 클라우드와는 달리 사내 배포 환경은 LLM이 학습하지 못한 영역입니다. 따라서 'AI가 아는 것'에 기대기보다, 사내 정보에 연결해 '잘 찾게 만드는 것'이 관건이었습니다.

저희 팀은 사내 코드 저장소, 이슈 트래커, 위키를 사내 MCP로 연결해, AI가 직접 검색하며 사내 배포 플랫폼, 로드밸런서, 분산 DB 환경에 맞게 설정하도록 했습니다. 막힐 때 던지는 질문은 크게 세 종류였습니다.

구분	질문	활용 방식
WHAT	무엇을 써야 하는가	사내에서 사용할 수 있는 플랫폼과 유사 사례를 먼저 검색
HOW	어떻게 써야 하는가	설정 방법과 예시를 찾아 적용(예: DDL 분석, 마이그레이션, 쿼리 테스트 순서로 분산 DB 이관)
WHY	왜 실패하는가	빌드, 배포, 오류 로그를 제공하고 원인과 다음 조치를 확인

속도와 품질을 높이기 위한 327개의 테스트

빠르게 바꾸는 만큼 회귀도 빠르게 생깁니다. 저희 팀은 실패한 케이스를 지나치지 않고 테스트로 고정해 327개의 테스트를 만들었습니다. 정보가 부족하면 문서를 보강했고, 동작이 깨지면 테스트를 추가했습니다. 같은 실수가 반복될 것 같으면 가드레일로 검증 로직을 넣음으로써 속도에만 치중하지 않고 품질을 함께 지킬 수 있었습니다.

3. 비개발 파트 회고: AI라는 징검다리

해커톤에서 AI는 코드를 만드는 도구일 뿐만 아니라, 비개발자가 개발 상황을 이해하고 기획과 디테일에서 팀의 협업 속도를 높일 수 있게 해주는 징검다리이기도 했습니다.

개발 상황을 따라잡기

해커톤 중 팀 개발 채널에서 빠르게 흐르는 기술 대화를 비개발자가 이해하기는 어려웠습니다. 그래서 Playwright와 로그인된 Chrome 브라우저를 활용해 AI가 팀 채팅, 발표 자료, 사내 코드 저장소를 읽고 진행 상황 문서로 정리하게 했습니다. 그 결과 '지금 무슨 개발이 진행 중인지'를 파악해 담당 개발자에게 더 정확하게 질문할 수 있었습니다.

사용자 흐름을 구체화하기

서비스가 사용자에게 닿기까지의 흐름을 도입 페이지, 챗봇 플로우, 발표 자료 세 영역으로 나눠 AI와 함께 설계했습니다.

• 도입 페이지: 2단계 인증 구조로 인해 크롬 익스텐션만으로는 봇 사용법을 알기 어려워, 설치, 튜토리얼, 유의 사항을 모아놓은 페이지를 AI와 함께 기획했습니다.
• 챗봇 플로우: '언제 실패하는가'를 AI와 브레인스토밍해 분류 모호, 매칭 실패, 결제 익일 반영, 개인카드 오등록과 같은 오류 케이스를 설계하고, 이상적인 흐름과 오류 케이스를 HTML로 시각화해 개발 우선순위를 논의했습니다.
• 발표 자료: 코드 실행 없이 평가되는 만큼, 평가자를 LLM 평가단, 출제자, 청중으로 정의하고 첫 페이지에 Must, Nice, Beyond 충족도를 두괄식으로 배치했습니다.

디자인 톤을 하나로 맞추기

크롬 익스텐션, 도입 페이지, 발표 자료가 서로 다른 제품처럼 보이면 완성도가 낮아 보일 수 있습니다. 그래서 민트색(#0d9373), Pretendard 글꼴, 캐릭터, 아이보리색 알림 창과 같은 디자인 토큰을 정하고 팝업, 도입 페이지, 슬라이드에 일관되게 적용했습니다.

발표 덱은 출제자가 공유한 HTML 형식을 AI가 참고하게 해 기본 골격을 만들었습니다. 이후 내용을 이식해 약 1시간 만에 11장 분량의 초안을 완성했습니다. HTML 단일 파일이라는 특성 덕분에 지시 한 줄로 문구와 레이아웃을 빠르게 고칠 수 있었고, 실제로 마감 직전까지 20번 넘게 수정해 완성도를 높였습니다.

마치며

이번 해커톤에서 가장 분명하게 남은 것은 처음 질문에 대한 답이었습니다. 같은 AI를 쥐여 줘도 결과를 가르는 것은 사람의 선택과 전략입니다.

AI는 '계획과 구현'의 영역에서 압도적인 속도를 냈습니다. 하지만 불확실성 속에서 가설을 세우고, 조직 안의 의존성을 풀고, 보안 사각지대를 책임 있게 공유하는 '전략'의 영역은 사람의 몫으로 남았습니다.

개발 파트에서는 사람이 AI 에이전트를 오케스트레이션하며 큰 작업을 작은 블록으로 나눠 병렬로 진행한 전략이 중요했습니다. 비개발 파트에서는 AI를 소통과 기획의 징검다리로 삼아 협업 속도를 높인 전략이 중요했습니다.

AI 시대의 협업은 사람이 AI로 대체되는 그림이 아니라, 사람이 전략을 쥐고 AI에게 계획과 실행을 위임하는 그림에 가깝습니다. AI는 매일 더 똑똑해지지만, '만들었다'를 넘어 시장에서 선택받는 프로덕트를 만들어내는 것은 여전히 사람의 역할이 아닐까요?

이것이 이번 해커톤이 저희 팀에 남긴 가장 큰 배움이었습니다.