천하제일 입코딩 대회(LipCoding) 2026 후기
천하제일 입코딩 대회 2026 후기
행사 참여 후기

참가 신청
6월 20일에 열린 천하제일 입코딩 대회에 참여하기 위해 광화문 마이크로소프트에 방문하였다.
작년 2025년 천하제일 입코딩 대회가 처음 개최된다는 것을 알았지만 일정상의 이유로 참여 신청조자 해보지 못해 아쉬웠던 기억이 남아있었다.
무엇보다 키보드를 전혀 사용하지 않고 마이크를 통해서만 바이브 코딩한다는 대회 규칙이 인상적이어서 더더욱 아쉬움이 컸던 것 같다.
이번 년도에도 대회가 열린다는 소식에 후다닥 신청하게 되었고 그 결과는,,

탈락을 해버렸다. 이런 행사에 신청해서 당첨되어본 적이 없어, 큰 기대를 하진 않았지만 내심 섭섭했었던..
그렇게 기대를 접고 기억 속에 잊혀질 무렵, 디스코드에 채팅이 하나 올라왔다. 이전에 가입하였던 바이브코딩 커뮤니티에서 티켓을 양도하신다는 메시지를 발견하게 되었고 바로 연락을 드렸다.

다행히 티켓을 양도받을 수 있었고 정말 운이 좋게 천하제일 입코딩 대회에 참여할 수 있게 되었다.
(양도해주셔서 정말 감사드립니다 🙌)
AI 관련해서 여기저기 많은 인사이트를 얻어가려고 하는 요즘, 정말 좋은 기회가 왔다고 생각했고 열심히 참여해서 최대한 많은 것들을 얻어가고자 하였다.
무엇보다 참가자들 전원 Github Copilot Max 한 달 이용권을 무료로 제공해준다고 한다!
참가 당일
천하제일 입코딩 대회는 광화문에 위치한 마이크로소프트에서 진행되었다.
9시까지 참석이었기에 가는 길에 미리 편의점에 들려 줄 이어폰을 하나 구매하였다.
사실 전 날에 미리 다이소 들려 샀다면 싸게 구매했을 텐데 게으른 탓에 당일 비를 맞아가며 편의점 세 군데를 돌아 15,000원에 이어폰을 사버렸다..

그렇게 우여곡절 건물에 도착하였고 입장 줄을 서서 9시에 대회 공간에 입장할 수 있었다.

로비는 천하제일 입코딩 대회 현수막으로 이쁘게 꾸며져 있었고 입장 체크와 굿즈를 나눠주셨다.


Github과 Copilot 스티커도 자유롭게 가져갈 수 있었고 양말과 마이크로소프트 굿즈도 나눠주었다.
대회 진행
⚙️ 세팅
대회를 본격적으로 시작하기 앞서 세팅할 수 있는 시간을 1시간정도 제공해주셨다.
-
Copilot Max 등록
-
VScode Copilot & Speech Extension 설치
-
Copilot CLI & Azure CLI 설치
-
Azure 클라우드 환경 세팅
마이크로만 할 수 없는 작업들을 미리 세팅할 수 있는 시간을 제공해었다. 프롬프트를 입력하거나 코드를 작성하는 것은 항상 키보드로 해왔었는데, VSCode에서 제공하는 Speech extension을 통해 말로 입력해보니 확실히 새로운 경험이었다.
글로 작성하면 명확한 요구사항을 구체적으로 작성할 수 있다는 장점이 있겠지만 마이크로 입력하는 프롬프트는 구어체로 빠르게 입력하며 흐름을 끊기지 않고 개발을 할 수 있다는 인상을 주었다.
⭐️ 대회 주제 결정
작년 대회 후기를 보았을 땐 공통 개발 요구사항이 주어지고 모든 인원이 동일한 과제에 대해 각자 개발하여 그 완성도로 순위를 매기는 방식이이었다.
이번 연도도 당연히 동일한 방식일 거라 생각했고, 아무런 준비도 없이 당당하게 참석했다. 하지만 진행자분의 말씀을 들으면서 무언가 잘못되었다는 느낌을 받았다. 마치 이미 모든 인원이 대회의 주제나 구체적인 진행 규칙을 완벽히 알고 있다는 전제하에 이야기를 이어 나가시는 것이다.
간담이 서늘해진 채로 대회 repository를 확인해보니 이미 몇 일 전에 discussions에 대회에 대한 공지와 사람들 간 팀원 모집이 활발하게 진행되고 있던 것이다.
대회의 주제는 ‘개인 생산성 향상 앱’ 이었고 나는 대회를 시작하기 30분 전에서야 알게되었다.

개인 생산성 향상 앱을 만들되, Copilot SDK를 활용하여 AI 기반의 기능이 포함되어야 했고 Azure 플랫폼을 통해 배포를 해야하는 것이 이번 대회의 도전 과제다.
대회의 수상이 목적이 아닌 짧은 시간 안에 바이브 코딩으로 생산물을 도출하는 경험이 목표였기에 어떤 앱을 만들까 빠르게 머리를 돌려서 작업 아이디어를 구상하였다.
최근에 일정이 많아지면서 이를 관리할 수 있는 무언가가 필요하겠다고 생각하였고, 일정을 간단히 생성하고 관리할 수 있는 캘린더 앱을 계획하였다. 이미 시장에 나와있는 서비스는 많지만 편리한 기능은 구독을 요구하는 경우가 많아, 무료 서버와 에이전트를 사용할 수 있는 김에 나만의 서비스를 만들고자 하였다.
캘린더 앱의 기능으로는 간단히 3가지를 계획했다.
-
사용성을 위해 크롬 확장 프로그램으로 설치
-
AI 프롬프트를 통해 요일과 일정을 입력하면 자동으로 캘린더에 등록
-
AI 프롬프트를 통해 연결된 repository의 issue & PR 생성 가능
🏁 대회 시작
대회 시작과 동시에 점심 시간이 되었고 제공해주는 소불고기 도시락을 먹으면서 바이브 코딩을 시작하였다.

스포츠 타올 굿즈도 하나 받았는데, 무려 코파일럿 스포츠 타올이었다. 이 수건을 키보드 위에 올려두어 마우스와 키보드 사용을 금지하도록 하였다. 물론 음성 입력을 위해 마이크 아이콘 클릭은 허용해주었다.

만약 키보드 사용 행위가 적발되면 로비에 있는 죄인존으로 퇴장당한다. 키보드 사용이 불가피하다면 스탭분이 지켜보는 가운데에서 키보드 사용을 허용해주셨다.

✏️ 간단한 개발 방식
4시간의 바이브 코딩 속에서 크게 두 가지 점을 활용하였다.
1. 코파일럿 에이전트 활용
Github에서 공식적으로 awesome-copilot이라는 Repository를 통해 유용한 스킬과 에이전트에 대한 문서를 제공해준다.
그 중에서 ai-team-producer, ai-team-dev, ai-team-qa 에이전트를 발견하였다. 각각의 에이전트들은 다음과 같은 역할을 갖고 있다.
| 에이전트 | 페르소나 | 역할 | 주요 업무 | 제한사항 |
|---|---|---|---|---|
| ai-team-producer | Remy | 프로듀서/PM | 스프린트 계획, PROJECT_BRIEF.md 작성, 버그 트리아지, PR 머지, 팀 간 조율, GitHub Issue 생성, 브레인스토밍, 프로젝트 컨텍스트 복구 | 코드 작성 절대 안 함 |
| ai-team-dev | Nova, Sage, Milo | 개발자 (풀스택) | 기능 구현, 버그 수정, UI 컴포넌트 개발, API 작성, CSS 스타일링, DB 쿼리, 스프린트 플랜 실행 | 프론트/백엔드/디자인 역할 자동 전환 |
| ai-team-qa | Ivy | QA 엔지니어 | 기능 테스트, E2E 테스트 실행, 플레이테스팅, 버그 리포트(GitHub Issue), 테스트 자동화, QA 사인오프, 버그 수정 검증 | 코드 수정 안 하고 버그만 보고 |
이 에이전트 파일을 .github/agents 하위에 위치시키고 바이브 코딩을 할 때 각각의 에이전트를 호출하여 작업을 수행하도록 시켰다.
한 가지 인상깊었던 점은 이 3가지 에이전트가 유기적으로 움직이며 주어진 요구사항에 대해 작업을 수행한다는 것이다.
2. 계획 & 개발 & 테스트
처음 기획 및 아이디어 구체화는 ai-team-producer 에이전트와 함께 진행하였다.
전체적인 아이디어와 추가해야할 기능을 구현함에 있어, 내가 결정해야 할 것들을 에이전트를 통해 리스트업하였고 구체적인 요구사항을 정리해가며 전반적인 프로젝트 계획은 PROJECT_BRIEF.md파일에, 구체적인 개발 계획은 docs/ 폴더 내부에 각각의 스프린트 단위로 정리하였다.
이 후 각 스프린트 단위로 ai-team-dev 에이전트를 호출하여 개발을 진행하게 된다. dev team 에는 3개의 페르소나가 있는데, 각각의 역할이 프로젝트 성향에 맞춰 혼합되었다.
## Role Guidelines
### Nova (Frontend)
- Component architecture: small, focused components
- State management: lift state only when needed
- Accessibility: semantic HTML, keyboard navigation, ARIA labels
- Performance: avoid unnecessary re-renders
- AI 응답은 SSE 스트리밍으로 실시간 렌더링
### Sage (Backend — NestJS)
- NestJS 패턴 준수: feature별 Module/Controller/Service 묶음
- DI 컨테이너 활용, 직접 인스턴스화 금지
- Security first: validate inputs, sanitize outputs, use env vars for secrets
- Copilot SDK 에이전트는 `agent/agent.service.ts`에서 관리
- 시크릿은 Azure Key Vault, 절대 코드에 커밋 금지
### Milo (Visual)
- TailwindCSS 유틸리티 클래스 우선 사용
- Animations: subtle, purposeful, respect `prefers-reduced-motion`
- Responsive: mobile-first, test at multiple breakpoints
- Consistency: follow existing patterns before creating new ones
영어로 되어있는 부분은 미리 정의된 페르소나고, 한국어로 추가된 부분은 프로젝트 성격에 맞춰 Role을 구체화된 부분이다. 조금 더 시간이 있었다면 Role Guidelines도 구체적인 역할들로 보강해볼 수 있을 것 같다.
이 개발팀은 기존 ai-team-producer가 생성한 스프린트 내 각 태스크를 가져가서 작업을 수행한다.

기본적으로 각 페르소나는 항상 작업을 시작하기 전,PROJECT_BRIEF.md와 스프린트 계획을 컨텍스트에 채우고 개발을 시작한다.
한 가지 신기했던 점은 미리 세워진 계획이 모호하거나 작업 중 변경 사항이 필요하면 사용자에게 의논하지 않고 스스로 판단하여 progress.md 파일에 결정사항과 근거를 작성한다는 점이다.
이와 관련해서 한 가지 문제가 발생하기도 하였다. 과제의 필수 규칙 중에 하나는 Copilot SDK를 사용하는 것이고 나는 이 SDK를 통해 캘린더 앱에서 두 가지 방식으로 활용하고자 하였다.
-
AI 프롬프트 입력창을 통해 일정 CRUD API 호출
-
AI 프롬프트 입력창을 통해 특정 Repo의 Issue & PR 생성
이 때 Copilot SDK를 통해 AI 프롬프트를 실행시켜 동작하려 했지만 갑자기 Azure 클라우드에서 제공하는 Azure OpenAI 서비스를 구축하기 시작한 것이다. 그 당시 로그를 확인해보면 아래와 같다.
[05:09:25] npm view @github/copilot-sdk
[05:10:06] tar -xzf github-copilot-sdk-1.0.2.tgz && cat package/dist/index.d.ts
[05:10:16] cat types.d.ts | grep "ProviderConfig\|defineTool"
[05:11:18] cat client.d.ts
[05:11:41] cat session.d.ts
[05:13:00] "copilot-sdk는 CLI JSON-RPC SDK다. BYOK LLM 패턴 없음
→ openai 패키지로 Azure 직접 호출하는 걸로 결정"
이 때 Copilot SDK를 통해 AI 프롬프트를 실행시켜 동작하려 했지만, Azure App Service 환경에서 동작하지 않아 직접 패키지를 분석하며 디버깅을 하였고, @github/copilot-sdk를 사용할 수 없다고 판단하였다.
BYOK(Bring Your Own Key)는 GitHub Issue & PR 등록을 위한 GitHub Personal Access Token을 의미했지만, ai-team-dev는 이를 LLM API를 위한 API Key로 착각하여 LLM 호출을 Azure OpenAI 서비스를 통해 구축하기로 결정한 것이다.
## 엔지니어링 결정사항
### `@github/copilot-sdk` vs `openai` SDK
- `@github/copilot-sdk`: Azure App Service 환경에서 CLI 사용 불가
- `openai` npm 패키지: AzureOpenAI 클래스로 실제 BYOK 구현
- ProviderConfig type은 `"azure"` (SDK 실제 값),
plan의 `"azure-openai"` 표기와 약간 다름 ← 플랜과 다르지만 이유 기록
결과적으로 필수 조건이었던 Copilot SDK를 활용하여 구현하려 했던 요구사항이, 이를 구현하기 위해서 Copilot SDK를 사용하지 않게된 주객 전도 사건이 발생한 것이다.
결국에는 Open AI와 Copilot SDK를 억지로 끼워넣어서 완성하긴 했는데, AI가 코드를 작성하더라도 개발의 방향성을 결정하는 키는 개발자가 쥐고 있어야 한다는 것을 다시 한 번 더 느끼게 되었던 것 같다.
하나의 스프린트 작업이 완료되면 ai-team-qa를 호출하여 작업한 내용에 대해 테스트를 간단히 진행하였다.
▶️ 실제 동작
결과적으로는 이런 앱을 만들었다.
조금 더 사용성을 높이기 위해 크롬 확장 프로그램으로 등록할 수 있게 해주었고, AI 프롬프트롤 통해 일정을 추가하거나 Github Issue & PR을 등록하는 기능을 넣었다.


짧은 시간 안에 급하게 정한 아이디어로 정신없이 미흡한 결과물을 만들어냈지만, 이번 바이브코딩에서도 기존에 시도하지 못했던 것들을 경험하고 새로운 인사이트를 얻어갈 수 있었던 것 같다.
결론
✅ 최종 결과
기대는 안했지만 약 40팀 중에 12등을 했다..!
프로젝트를 제출하면 기존 심사 조건마다 각각의 에이전트가 병렬적으로 돌아가며 심사를 매겨준다.


전체적으로 심사 조건은 충족한 기본적인 앱이지만 보안이나 창의력 부분에서는 부족한 점수를 받았던 것 같다.
📚 인사이트
- 코드는 AI가, 결정은 내가 (책임도 내가..)
부트캠프 교육을 받으며 처음부터 끝까지 나는 한 가지 목표를 갖고 있었다.
내가 작성한 코드는 내가 이해할 수 있어야 한다.
하지만 점차 시간이 흐를수록 코드를 작성하는 주체는 ’나’에서 ’AI’로 빠르게 넘어가고 있다. 이 시점에서 우리는 한 가지 질문을 던져야 한다. “내가 직접 짜지 않은 코드도, 내가 작성한 것만큼 완벽히 이해해야 하는가?”
AWS Summit 기조 연설에서 나온 르네상스 시대 개발자의 특징으로 ’품질에 대한 주인의식(Ownership of Quality)’이 있었다. AI가 아무리 많은 코드를 자동으로 만들어내더라도, 그 결과물에 대한 최종 책임과 주인은 결국 개발자라는 뜻이다.
나 역시 이 의견에 공감한다. 누가 코드를 작성했던 간에, 시스템을 지탱하는 코드에 대한 책임은 코드의 주인인 개발자에게 있기 때문이다. 하지만 여기서 한 가지 더 고민에 빠지는 점은 과연 어느 수준까지 알아야 코드를 이해했다고 말할 수 있냐는 것이다.
내가 코드를 작성했을 때만큼? 혹은 누군가가 작성한 코드를 리뷰할 수 있을 정도로 이해할만큼? 여기에 대해서는 아직 결론을 내리지 못한 것 같다.
AI 시대의 가장 큰 장점은 빠른 구현과 생산성이다. 하지만 AI가 짠 코드를 내가 직접 짠 수준으로 완벽하게 파헤치고 검증하는 데 다시 많은 시간을 쓴다면, AI가 가져다준 생산성의 이점은 상쇄되고 만다.
결국 이 간극을 얼마나 메울 수 있는지가 중요할 것 갖고 그 능력의 기반은 탄탄한 기초 지식과 기술의 이해도에 있을 것 같다. 코드를 작성하는 것은 AI가 하겠지만 문제를 정의하고 해결하기 위해 어떤 선택을 내릴 것인지 그 근거는 코드의 주인인 개발자가 하기 때문이다.
결론적으론 AI도 많이 쓰고 CS 공부도 많이 하고 문제도 많이 만나보고 많이 많이..
2. 동기부여
점심을 먹으면서 광화문 마이크로소프트 건물에서 바라본 풍경이다.

날이 많이 흐리긴 하지만 높은 곳에서 보는 광화문은 이뻤다.