안녕하세요!

지난 2025년 10월 30~31일, KT 광화문빌딩 West에서 AI에 관심 있는 KT 임직원을 대상으로 AI 주도 개발 해커톤 ‘kode:vibeJAM’을 진행했습니다. 이번 해커톤은 GitHub Copilot과 CursorAI 등 AI 개발 도구를 적극 활용해, 기존과는 다른 방식의 AI 주도 개발 해커톤으로 진행되었습니다.

당초 해커톤 전문업체를 통해 행사 운영과 평가 시스템을 마련하려 했으나, 예상치 못한 상황으로 직접 평가 시스템을 구축하게 되었습니다. 이에 어떤 평가 체계를 만들지에 대해 많은 논의가 이어졌고, 결국 ‘AI를 최대한 활용하는 해커톤’이라는 취지를 정하고 기획을 시작했습니다.

특히 준비 과정 전반에서도 AI 활용 방식을 고민하며, “AI 주도 개발 해커톤이라면 준비 역시 AI답게 해야 한다”는 원칙을 세웠습니다. 그 결과 평가 시스템에 AI 기반 평가 기능을 포함시켰고, 개발 과정 전반에서 AI를 활용하여 보다 효율적이고 공정한 심사 환경을 구축하는 데 집중했습니다.

기획 단계부터 “AI 주도 개발 해커톤이라면 준비 과정도 AI답게 해야 하지 않을까?”라는 고민으로, 준비 과정 전반에서도 AI 활용 방식을 고민했습니다. 특히 kode:vibeJAM 평가 시스템을 구축하면서 AI 평가 기능을 포함하고, 개발 과정에서도 AI를 최대한 활용해 보다 효율적이고 공정한 심사 환경을 만드는 데 집중했습니다.

1. 평가 시스템 기획

간단한 미팅을 통해 평가 시스템에 필요한 주요 요구사항을 정리했습니다.

AI 평가 기능: AI를 활용해 객관적이고 일관된 평가를 수행하여 공정성 확보
심사위원 평가: 심사위원이 시스템에 로그인해 온라인으로 평가를 진행하면, 점수가 자동으로 집계
동료 평가: 유튜브에 데모 영상을 등록하고, 동료들이 영상을 시청한 뒤 시스템에서 직접 평가를 할 수 있게 구성

이 요구사항을 바탕으로 AI 도구인 Figma Make를 활용해 본격적인 기획 작업을 진행했습니다. 요구사항을 정리해 Figma Make에 입력할 프롬프트를 작성한 뒤 요청하자, 짧은 시간 안에 첫 번째 초안이 생성되었습니다.

이후 Figma Make와 대화하듯 추가 요구사항을 전달하고 수정 사항을 반영하며, 평가 시스템 기획의 완성도를 점차 높여갔습니다.

2. 개발의 시작

Figma Make에서 자동 생성된 소스를 기반으로 본격적인 AI 주도 개발을 진행했습니다.

먼저 CLAUDE.md 파일에 프로젝트 개요, 요구사항, 개발 가이드를 정리해 Claude Code가 전체 맥락을 이해하고 잘못 개발을 방지할 수 있도록 했습니다. 이후 요구사항을 토대로 프롬프트를 작성해 자동 생성된 소스를 개선하고 부족한 부분을 채워나갔습니다.

처음에는 프런트엔드 소스가 거의 완성된 상태라, 백엔드 기능만 추가하면 금방 끝날 것이라고 예상했지만 현실은 달랐습니다. Figma Make에서 데이터셋을 체계적으로 정의하지 않으면 페이지별로 서로 다른 데이터셋이 생성되어 DB 설계 시 페이지마다 별도의 테이블이 만들어지는 문제가 발생했습니다.

이 문제를 해결하기 위해 데이터셋 구조를 통일하는 작업을 먼저 진행했고, 이후 동일한 기준으로 다시 프롬프트를 작성해 화면과 코드를 재생성했습니다.

그 후, 정리된 소스를 기반으로 DB 스키마와 API 명세를 자동 생성하도록 AI에 다음과 같이 지시했습니다.

“현재 생성된 소스를 기반으로 DB 스키마와 API 명세서를 만들어줘. DB는 PostgreSQL을 사용할 거야.”

AI가 전체 소스를 분석하여 DB 스키마 설계와 API 명세서를 생성했고, 일부 도메인과 맞지 않는 부분만 수작업으로 빠르게 수정해 개발 효율성을 유지했습니다.

이후에는 다음 프롬프트로 백엔드 개발을 시작했습니다.

“API 명세서를 기반으로 백엔드 개발을 진행해줘. 스펙은 Spring Boot를 사용할 거야.”

요구사항과 개발 가이드를 CLAUDE.md에 정리해 두었기 때문에 프롬프트에는 별도 세부 내용을 포함하지 않고 요청을 했습니다. AI는 API 명세서에 따라 Spring Boot 기반의 백엔드 코드를 자동으로 생성했습니다.

백엔드 구현이 완료된 뒤에는 로컬 환경에서 서버를 기동해 기동오류나 호출 오류 등 기본적인 기동에 필요한 오류를 수정했습니다. 이 과정이 어느 정도 안정화된 후, 다시 다음 작업을 요청했습니다.

“백엔드 개발이 완료되었으니 API 테스트 스크립트를 만들고 API 테스트를 진행해줘.”

AI는 테스트 코드와 API 호출 스크립트를 생성하고 바로 테스트를 실행하면서 추가적인 오류를 찾아 자동으로 수정하는 작업까지 수행했습니다. 덕분에 수동으로 일일이 테스트 케이스를 작성하고 검증하는 시간을 크게 줄일 수 있었습니다.

또한 Postman용 API 콜렉션 파일도 함께 생성해 개발자가 직접 호출을 검증할 수 있도록 했습니다.

백엔드가 안정화된 이후에는 프런트엔드 수정 작업을 통해 실제 서비스를 완성해 갔습니다.

“백엔드 개발이 완료되었으니 소스를 확인해서 프론트에서 백엔드 API를 호출하도록 수정해줘.”

AI는 백엔드 프로젝트의 코드를 하나씩 분석하면서, 프런트엔드에서 사용하던 Mock 데이터를 실제 백엔드 API 호출로 하나씩 치환하기 시작했습니다.

작업이 끝난 뒤 로컬에서 프런트엔드와 백엔드 서버를 함께 실행하고, 로그인부터 각 기능이 하나씩 동작하는 모습을 보며 AI 주도 개발 프로세스의 위대함을 체감할 수 있었습니다.

3. 버그의 역습!!

개발이 완료된 뒤 통합 테스트를 진행하자 크고 작은 버그들이 다수 발견되었고, 이때부터 본격적인 AI와의 전쟁이 시작되었습니다.

버그 수정을 위해 AI에게 요청하고 피드백을 받는 과정이 반복되었고 일부 요청은 의도를 파악 못하고 엉뚱한 부분을 수정하는 경우도 있었습니다. 그럴 때마다 문제 상황을 다시 정확히 설명하고 수정 요청을 여러 차례 반복해야 했습니다.

이 과정에서 테스트 시간이 예상보다 길어졌고, 일정 지연의 우려가 생기기 시작했습니다. 이에 대한 해결책으로 Claude 멀티 활용 방안을 도입했습니다.

우선 터미널 창을 두 개 띄워 각각의 Claude 세션을 열고, 기능별로 역할을 분담했습니다. 이 방식에 익숙해지자 창을 세 개, 네 개로 늘려 병렬적으로 버그를 하나 하나 개선해 나갈 수 있었습니다.

아래와 같이 멀티 세션을 통해 작업을 진행했습니다.

이렇게 멀티 세션을 활용해 작업을 진행하니 한 세션에서 버그 수정 요청을 하는 동안 다른 세션에서 결과를 확인하고 추가 요청을 진행할 수 있었습니다. 그 결과 요청 후 대기 시간이 줄어들고 전체적인 작업 속도가 빨라지는 효과를 얻을 수 있었습니다.

4. AI 평가는 어떻게?!

개발이 어느 정도 마무리된 뒤, 평가 시스템에 AI 평가 기능을 어떻게 녹여 넣을지에 대해 별도의 논의를 진행했습니다. 여러 차례 논의 끝에, 두 가지 방식의 AI 평가 기능을 추가 하는 방향으로 결정했습니다.

첫 번째는 예선 단계에 참가팀이 제출한 아이디어 제안서를 중심으로 AI가 내용을 분석·평가하도록 하는 기능으로 이 평가에는 Claude Code, Cursor AI, GitHub Copilot 세 가지 도구를 활용해 각기 분석하고, 그 결과를 리포트 형태로 제공하는 방식으로 구현했습니다.