네이버클라우드 AI 포텐데이 후기

우연한 기회로 심은 인생 첫 잔디, 새로운 원동력이 되다.

 

(좌) 딱 10분만 서비스 / (우) 디자이너 분이 그려주신 나(?)

 

 

[① 508 AI 포텐데이]

 

01-01. 해커톤 소개 

• AI 포텐데이 X 네이버클라우드는 네이버클라우드 AI 서비스와 함께하는 밤 새지 않는 온라인 해커톤이다. 실상은 10일 동안 밤을 새는… 팀은 최소 1인 ~ 최대 6인으로 구성할 수 있으며 10일 동안 CLOVA Studio를 필수적으로 활용해 서비스를 기획하는 것이 프로그램의 특징이다.
• 10일간 진행되는 AI 포텐데이를 완주한 후 팀은 서비스 고도화 트랙을 신청해 10일간 추가로 프로젝트를 고도화할 수 있다. 서비스 고도화 트랙에 참여한 팀의 프로젝트는 네이버클라우드, 포텐데이 팀 현직자 분들의 심사를 거쳐 최종 5개의 팀이 최종 데모데이에 참가하게 된다.

01-02. 해커톤 참여 목적 

• 사실 예전부터 AI 포텐데이를 눈여겨 보고 있었다. 현업자가 아닌 내가 실제로 AI 기술을 활용해 서비스 기획을 해볼 수 있는 기회는 드물기 때문에, 네이버의 AI 기술을 활용한 서비스 기획을 경험할 수 있는 AI 포텐데이가 나한테 매력적으로 다가왔다. 그러나, AI 포텐데이를 처음 알게 되었을 당시에 스스로 기획 역량이 부족하다고 느꼈고 AI 기술을 활용하는 해커톤은 더욱 부담되어 참여를 망설였다.
• 그 후 약 1년 반에 걸쳐 크고 작은 프로젝트를 하며 6번의 서비스 기획을 경험했다. 이제는 AI 포텐데이를 도전할 수 있지 않을까 싶어 이번 AI 포텐데이의 참여를 결정하게 되었다. 참여 목적은 크게 두 가지였다. 첫 번째로 AI 기술을 활용한 기획 프로세스에 익숙해지기 위해서, 두 번째는 제한된 시간 내 문제를 해결하는 역량을 강화하기 위해서이다.

01-03. 해커톤 후기

• 이번 해커톤은 10일간 약 86시간을 몰입할 만큼 너무나도 즐거운 경험이었다. 솔직히 말하면 많이 힘들었지만(체력 이슈…) 내 인생 첫 해커톤이기도 했고 개인적인 챌린지를 하나씩 헤쳐 나가는 경험이 정말 재밌었다. 지금 돌이켜 보면 해커톤을 할 때 개발자 연락 두절, 기술적 제약 등 정말 예상치 못한 변수가 많았는데 이것들을 하나씩 해결해 나가며 기획자이자 팀 리더로서 많이 성장한 것 같다.
• 해커톤은 처음이라 다른 해커톤과 비교해 설명하기는 어렵지만, 개인적으로 해커톤 운영이 꽤 체계적이라고 느껴졌다. 팀 빌딩부터 주차별 가이드까지 Slack 채널에서 운영자 분이 매일 페이스메이킹을 해주셨는데, 이러한 운영진의 배려가 팀의 스케줄을 계획하고 실행하는데 있어 큰 도움이 되었다. 해커톤에 참여하기 전에는 해커톤 참가비가 8만원(얼리버드 기준)이 정말 비싸다고 생각했지만, 고도화 트랙까지 수료한 지금에는 그 금액이 전혀 아깝지 않다.

 

 

[② 딱 10분만: 서비스 기획]

 

02-01. 서비스 기획: 주제 선정 

• 우리 팀은 일상에서 누구나 겪는 문제를 해결하고 싶었다. 일상에서 누구나 겪는 문제를 다루게 될 경우 타겟이 넓다는 장점도 있지만 반면에 뾰족한 기획이 나오기 어렵다는 단점도 있다. 따라서, 나는 타겟이 공통적으로 경험하는 특정 상황에 집중하자고 제안했고 긴 아이데이션 끝에 우리 팀은 ‘지각 습관 개선의 어려움’이라는 문제에 집중하게 되었다.
• 1) 우리 팀이 재밌게 풀 수 있고 2) 모두가 쉽게 공감할 수 있는 문제라는 점에서 해커톤 주제로 적합하다고 생각했지만 개인적으로 문제를 정의하는 것이 어려웠다. 지각 개선의 어려움이라는 문제와 지각을 반복하는 현상은 분명한 사실이지만, ‘일상적인 문제에 너무 큰 의미를 부여하는 게 아닌가?’라는 생각이 들었다. 문제를 풀기 위해 일상적인 현상을 문제화 하는 게 아니라는 것에 대해 스스로 납득이 필요했다.
• 빠르지만 깊게 데스크 리서치를 진행하면서, 실제 지각이 사회적으로 문제라는 사실을 파악할 수 있었고 특히 회사에 지각하는 경우 그 문제가 더 크다는 점을 발견할 수 있었다. 또한, "다른 세대와 달리 Z세대의 경우 직장에 10분 정도 늦는 게 괜찮다고 생각한다."는 재밌는 연구 결과를 발견했다. Z세대는 팬데믹 기간 동안 집이라는 편안한 공간에서 직장생활을 시작했으며, 그 시기에 누군가 기술적인 문제로 회의에 접속할 때까지 더 오래 기다려주는 것이 익숙하다는 게 그 이유이다.
• Z세대의 지각이라는 키워드에 집중해 리서치를 더 진행하면서 지각을 반복하게 되는 근본적인 원인을 찾고자 노력했다. 관련 연구들을 조사하던 중 디지털 환경이 젊은 세대의 인지 능력에 미치는 영향에 대한 연구들을 접하게 되었고, ‘인지 과부하(cognitive overload)’라는 키워드를 발견할 수 있었다. 디지털 사회를 살아가는 현대인은 1) 선택 과부하, 2) 숏폼의 노출, 3) 치열한 경쟁을 경험하고 있었고, 이로 인해 인지 과부하를 느끼고 있다.

02-02. 서비스 기획: 기획 의도 

• 인지 과부하란, 우리 뇌가 한 번에 처리할 수 있는 정보의 양을 초과했을 때 발생하는 상태이며 집중력 저하, 결정 피로, 우선순위 판단의 어려움, 스트레스와 불안감 증가 등의 증상으로 발현된다. 앞서 언급한 세 가지 배경이 현대인들의 1) 계획 부담의 증가, 2) 시간 인지 왜곡, 3) 자기 객관화 회피라는 현상으로 나타났다. 우리 팀은 조금 더 직접적으로 문제를 정의하기 위해서 지각 경험이 있는 사람을 대상으로 2일간 설문 조사를 진행했다.
• 설문 응답자(n=84)의 62.3%가 지각 습관 개선의 필요성을 느꼈고, 그 중 88.9%는 지각 습관 개선을 시도했지만 결국 지각 습관을 개선하지 못했다. 지각 습관 개선이 어려운 이유는 1) 계획의 어려움, 2) 실행의 어려움, 3) 회고의 어려움이 도드라졌고 Z세대의 경우 어려움의 정도가 더 컸다. 이를 통해 인지 과부하를 경험하고 있는 현대인이 ‘지각 습관 개선’이라는 목표를 달성할 수 있도록 개인을 이끌어주는 어떤 존재를 필요한다는 사실을 알 수 있었다.
  *Z세대는 Pew Research Center의 정의를 차용해 1997년생부터 2012년생까지로 분류하였다.

02-03. 서비스 기획: 기능 도출 

• 딱 10분만은 Z세대의 지각 습관 개선을 돕는 AI 페이스 메이킹 서비스이다. AI 에이전트 ‘구원신’은 사용자와의 대화를 바탕으로 사용자를 더 잘 이해하고, 개인화된 페이스로 사용자의 지각 습관 개선을 돕는다. 자체 설문 조사에 따르면 설문 응답자가 지각하는 가장 큰 이유는 출발이 늦어져서(64.6%)였다. 따라서 우리 서비스는 외출 준비 단계에서 사용자가 느끼는 페인포인트를 해결하는 것에 집중해 솔루션을 도출했다.
• 기능은 비교적 단순하다. 1) 내 외출 루틴과 약속 정보를 고려한 스케줄 자동 생성, 2) 타이머와 피드백을 통해 스케줄 실행을 돕는 챌린지, 3) 챌린지 분석 기반 공감형 피드백 세 가지 기능으로 구성했다. 그 중에서도 실행의 어려움을 해결하는 ‘챌린지’ 기능이 우리 서비스의 핵심 기능이다. 챌린지 기능에서는 타이머와 함께 사용자 맥락을 고려한 적응형 피드백(adaptive feedback)을 제공한다. 시각적/청각적 피드백 두 가지 유형의 피드백을 통해 사용자의 실행을 돕는다. 무엇보다 하이퍼클로바 X 모델을 거쳐 개인화된 피드백을 제공함으로써 사용자의 피드백 수용도를 높여, 스케줄 실행을 돕고자 했다.
• 구원신은 AI 페이스 메이커로서 계획-실행-회고 단계를 함께하며 Z세대의 지각 습관 개선을 돕는다. 사용자는 딱 10분만을 지속 사용하며, 약속 시간 딱 10분 전 약속 장소에 도착하게 되며 시간 관리 능력 향상을 기대할 수 있다. 지속 가능한 습관 형성으로 자기 효능감 향상과 대인 관계에서 신뢰를 유지할 수 있다.

 

해커톤에 참여할 예정이면 꼭 API 가이드 미리 숙지하기!

 

[③ 딱 10분만: 사용한 기술]

 

03-01. 사용한 기술: 계획 단계 

• 서비스에 AI가 접목된 지점은 총 3 곳으로 계획-실행-회고 단계에서 모두 쓰인다. 첫 번째 계획 단계에서는 CLOVA Studio 서비스에서 Structured Outputs 기술을 추가로 사용한다. 해당 기술을 활용해 사용자와 구원신의 대화 턴 내에서 원하는 JSON Schema 형식의 출력 결과를 얻을 수 있다. 시스템(구원신)은 사용자와 대화 턴을 통해 1) 스케줄 생성에 필요한 약속 정보와 2) 피드백 생성에 필요한 부가 정보를 수집한다. Structured Outputs는 HCX-007 모델에서만 사용할 수 있기 때문에 해당 모델을 사용했다.

03-02. 사용한 기술: 계획 단계 

• 두 번째 실행 단계에서도 CLOVA Studio가 쓰인다. 실행 단계에서는 사용자에게 두 가지 페르소나 1) 구원신과 2) 호통신을 제공하는데 이를 위해 튜닝을 진행했다. 첫 번째는 ‘신’이라는 컨셉에 어울리는 말투를 제공하기 위해서 자체적인 데이터셋 500건을 구축하고 이를 학습시켰다. 데이터셋을 구축할 때 중점적으로 고려한 사항은 신이 쓸 것 같은 말투를 만들기 위해 ‘인간계’, ‘전설’ 등의 단어를 발화에 포함시켰다. 또한 신과 같은 말투를 수집하는 건 어려웠기 때문에 직접 작성했어야 했는데, 내가 만든 데이터셋 생성기라는 GPTs를 사용해 500건의 데이터셋을 쉽게 생성할 수 있었다. 생성한 데이터를 직접 검수하는 과정을 디자이너 분들이 도와주셨지만, 아무래도 우리가 생성한 데이터이다 보니 수집한 데이터 대비 데이터의 질이 떨어지는 점은 한계이다.
• 두 번째는 CLOVA Speech이다. 실행 단계가 진행되는 챌린지 기능에서는 사용자의 루틴 · 진행 상황 · 남은 시간 등 사용자 맥락을 고려한 적응형 피드백을 시각과 청각 두 가지 유형으로 제공한다. 우리는 CLOVA Speech를 사용해 청각적 피드백을 구현했고, 무엇보다 선택할 수 있는 보이스가 많아서 좋았다. 딱 10분 만에 등장하는 구원신과 호통신의 목소리로 ‘경태’를 선정했다. 감정을 선택할 수 있는 목소리도 있어 고민했지만, 서비스 컨셉에 ‘경태’의 연령대가 적합하다고 생각해 최종 결정했다. 대신 속도, 음색, 높낮이 조정을 통해 구원신과 호통신의 목소리를 차별화했다.

03-04. 사용한 기술: 회고 단계 

• 세 번째 회고 단계에서도 CLOVA Studio를 사용했다. 실제로 구현하지는 못했지만 기획서 상에서는 사용자의 챌린지 수행 정보에 따른 피드백을 제공하고자 했다. 챌린지 종료 상태는 포기, 성공, 실패로 세 가지로 구분되는데, 경우에 따라 다른 피드백을 제공한다. 특히 실패하는 경우 실패한 원인을 분석하고, 외출 루틴 예상 시간 조율을 능동적으로 제안한다. 따뜻한 공감형 말투로 피드백을 제공해 사용자가 자기 자신에게 실망하지 않고, 서비스를 지속 사용할 수 있도록 유도한다. 

 

[④ 딱 10분만: 서비스 한계]

 

04-01. 서비스 한계 

• 딱 10분만의 서비스 한계도 분명하다. 사용자가 지속적으로 서비스를 찾게 만드는 요소가 부족하다는 점이다. 서비스 고도화 트랙을 수료할 경우, 현업자 분들의 피드백을 받을 수 있는데 역시 이 부분에 대해서 언급해 주셨다. 추가로 실용성 측면에서 일반 알람을 넘어 설 만큼의 강력한 후킹 요소가 추가되면 매력적인 서비스가 될 것 같다고 말씀해 주셨다. 개인적으로 단순한 기록을 넘어 소셜 기능을 연계하면 이러한 아쉬움을 해결할 수 있을 것 같다. #오운완처럼 챌린지 클리어 인증샷을 공유하거나, 그룹 내 시간 관리 순위를 재미있게 표시하는 등의 기능을 추가하는 방식이다.

 

첫 잔디...(뿌듯) / 개발자 심정을 조금이나마 이해할 수 있게 되었다...

 

 

[⑤ 바이브 코딩 경험]

 

05-01. 바이브 코딩의 시작 

• 고도화 트랙 진행 중 개발자 한 분이 연락 두절되는 예상치 못한 상황이 발생했다. 팀원 모두 프로젝트 완성 의지와 기대가 컸던 만큼 처한 상황에 아쉬운 마음이 크게 들었다. 내가 팀 빌딩을 했기 때문에 나를 믿고 팀에 합류한 다른 팀원들에게 너무나도 미안했다. 정말 어떻게든 끝내 보겠다는 절실한 마음을 가지고 해결 방법을 모색했고, Cursor와 Figma Devmode MCP를 활용하면 프론트엔드 개발이 가능하다는 걸 알게 되었다.
• Cursor IDE에서 GitHub에 있는 프로젝트를 불러와 프로젝트를 구조를 파악하게 만들고, 베타 버전으로 제공되고 있는 Figma Devmode MCP를 활용해 Figma에서 디자인된 화면 정보를 불러왔다. 다행이라면 1) 고도화 트랙 이전까지 프론트엔드 개발자 분이 작업해 두신 게 있었고, 2) 앱이 아닌 웹(PWA)이라서 내가 조금 더 손 쉽게 개발해볼 수 있었다. 정말 다행인 건… 내가 디자인을 전공해서 어느정도 미감이 있다는 사실이다.(?)

05-02. 바이브 코딩의 장점

• 바이브 코딩은 OpenAI 공동 창립자 안드레 카파시(Andrej Karpathy)에 의해 소개된 개념으로 대규모 언어 모델(LLM)에 프롬프트를 입력해 코딩을 하는 AI 기반 프로그래밍 방식이다. ‘바이브 코딩’은 AI가 생성한 코드를 일일이 검토하지 않고 말 그대로 느낌에 따라 개발을 진행하는 방식인데, 나의 경우 이미 결정된 명확한 설계와 지침을 통해 개발했다는 점에서 ‘협력적 코딩’에 가까운 것 같다. 이를 통해 기획자인 나는 AI와의 협업을 통해 디자인된 화면을 구현할 수 있었다.
• 바이브 코딩의 장점이라고 한다면, 단연 비개발자가 직접 서비스를 구현해볼 수 있다는 사실이다. 흔히 Hi-Fi 프로토타이핑이라고 하면, Figma를 활용한 프로토타입이 최선이었지만 LLM 기반의 AI IDE를 활용해 더 높은 수준의 프로토타이핑이 가능해졌다. 노코드 툴과 LLM 기반 AI IDE의 확산은 비개발자들의 MVP 구현 수준과 가능성을 높인다. 빠른 시간 내 개발 직군 없이도 서비스를 시장에 선보이고 PMF를 찾을 수 있다는 점은 큰 장점이다.

05-03. 바이브 코딩의 단점 

• 실무적인 관점에서 바이브 코딩은 명확한 한계가 있다. 물론 이는 개발 경험이 부족한 비개발자의 시선에서 바라본 의견이지만, 실제 프로젝트에서 경험한 구체적인 문제들을 통해 확인할 수 있었다. 바이브 코딩을 진행하면서 100% 자연어로 개발했고, AI가 생성한 코드를 별도로 검토하거나 검수하지 않았다. 비개발자로서 에이전트 작업 도중 적절히 개입해 의도를 전달하고 수정을 요청하는 과정은 할 수 있었지만, 생성된 코드의 품질이나 구조적 문제를 파악하기는 어려웠다.
• 가장 큰 문제는 코드의 구조가 협업에 적합하지 않았다는 점이다. AI가 생성한 코드는 기능 구현에만 집중되어 있어 가독성과 유지보수성을 고려하지 않았다. 예를 들어, className의 경우 bg-gradient-to-r from-blue-500 via-purple-500 to-pink-500 rounded-lg shadow-xl 같이 60자가 넘는 긴 문자열을 인라인으로 작성했고, 컴포넌트 간 코드 중복도 심했다. 또한 변수명이나 함수명도 일관성 없이 작성되어 백엔드 개발자 분이 크게 당황하셨다.
• 결국 백엔드 코드와 통합하는 과정에서 이러한 문제가 심각하게 드러났다. 백엔드 개발자는 AI가 생성한 프론트엔드 코드의 구조를 파악하는 데 예상보다 많은 시간이 소요되었고, API 연동 지점을 찾기 어려워했다. 제한된 프로젝트 일정상 빠른 해결이 필요했기 때문에, 결국 백엔드 개발자와의 협업보다는 다시 AI 에이전트에게 통합 작업을 맡길 수밖에 없었다.
• 하지만 이 과정에서 예상치 못한 문제가 발생했다. 코드 통합 중 발생하는 충돌을 해결하면서 에이전트가 기존 UI 디자인을 임의로 변경해버렸다. 예를 들어 원래 설계된 버튼 스타일이나 레이아웃을 코드 통합 과정에서 다른 형태로 바꿔버렸고, 통합 전 없었던 버튼들을 임의로 생성하는 할루시네이션 현상도 나타났다. 결과적으로 개발 속도는 빨랐지만 최종 결과물의 일관성과 품질 관리에서는 한계를 느낄 수 밖에 없었고 결국 시간 내 서비스를 완성할 수 없었다.

[⑥ AI 포텐데이를 돌아보며]

 

06-01. 레슨 런 

• 해커톤을 참가하며 나의 한계에 도전해볼 수 있었고 이 경험을 통해 1) AI 기술을 서비스에 접목하고, 2) AI를 업무에 활용하는 유연한 기획자로서의 첫걸음을 뗄 수 있었다.
  • 1. CLOVA Studio, CLOVA Speech 등 AI 기술을 활용한 서비스 기획
  • 2. 튜닝 데이터셋 생성용 GPTs를 제작하여 500개의 데이터셋을 효율적으로 생성
  • 3. Cursor IDE와 Figma Devmode MCP를 활용한 프론트엔드 UI 구현
  •  
• 그 외에도 일상적 문제를 사회적 문제로 재정의하고, 설문조사를 통해 가설을 검증하는 과정을 경험했다. 특히 Z세대라는 타겟 세분화를 통해 차별화된 인사이트(인지 과부하)를 발견할 수 있었다.

06-02. 아쉬운 점

• 아쉬운 점을 꼽자면 두 가지가 있다. 첫 번째는 프로젝트를 완성하지 못했다는 것이다. "몰입 아니면 죽음"이라는 뜻의 팀 'DOD' 구성원 모두가 최선을 다해 프로젝트에 참여했다. 여러 번의 팀 프로젝트를 진행했지만 개인적으로 지금까지 경험한 팀 중에서 가장 좋았다. 무엇보다 팀 빌딩을 주도한 리더로서 팀원들을 끝까지 책임지지 못했다는 점이 가장 아쉽다. 팀원들이 나를 믿고 합류해준 만큼, 어떤 변수가 생겨도 좋은 프로젝트를 하고 싶었는데 그러지 못해서 아쉬운 마음이 크다.
• 두 번째는 AI 활용의 아쉬움이다. 기획자로서 CLOVA Studio에서 활용할 수 있는 기능들을 명확하게 인지하고 있었더라면, 주제 선정이나 AI 활용 측면에서 조금 더 좋은 결과를 만들 수 있지 않았을까 싶다. 다른 해커톤과 달리, 네이버에서 제공하는 기술을 필수적으로 사용해야 하므로 기술에 대한 깊은 이해는 분명 주제 선정이나 기획에 큰 도움이 되었을 것이다.

06-03. 보완할 점

• 나의 한계에 도전하며 크게 성장한 한편, 나의 부족함도 파악할 수 있었다. 무엇보다 AI 시대의 PM/PO를 희망하는 나에게 개발에 대한 이해가 너무나도 부족하다는 것을 깨달았다. 최근 링크드인에서 한 현직자 분이 "제가 본 AI PO는 단순한 관리자가 아닙니다. 직접 구조를 설계하고, 아키텍처를 짜고, PoC까지 구현할 수 있는 사람입니다."라고 작성한 글을 접하게 되었는데, 해커톤을 경험한 후라 정말 크게 공감되었다.
• 특히 이번 해커톤에서 바이브 코딩을 경험하면서, 비개발자도 AI의 도움으로 구현이 가능하지만 코드 품질과 구조를 판단할 기본 지식은 여전히 필요하다는 것을 절실히 깨달았다. TPM이 아니더라도 AI 시대에 기술과 코드에 대한 이해는 필수적이다. 실제로 내가 코드를 읽고 검수할 수 있었다면 프로젝트의 성패가 달라졌을 수도 있다는 아쉬움이 컸다.
• 이와 같은 맥락에서 최근 앤드류 응(Andrew Ng) 교수도 Y Combinator에서 "Building Faster with AI"라는 강의에서 코딩하는 법의 중요성을 강조했다. 앞으로 코딩하는 법을 아는 프로덕트 매니저 혹은 프로덕트 관련 지식이 있는 프로그래머가 활약할 것이라고 말하며, 모든 직군의 사람들이 코딩을 배워야 한다고 주장했다. 나 또한 이번 경험을 통해 그분의 주장에 동의하게 되었다. AI 시대가 도래하며 코딩의 생산성은 높아졌지만, 코딩을 몰라도 되는 것은 아니다. 코딩에 대한 진입 장벽이 낮아진 건 사실이지만, 여전히 기본적인 지식을 이해하고 있어야 AI 에이전트와 함께 효과적으로 협업할 수 있다.

06-04. 마치며

• 세상이 참 빠르게 변하면서 산업의 구조와 일하는 방식이 달라지고 있다. 취업을 준비하는 학생으로서 가끔은 이 흐름을 따라가기 벅차다는 생각이 들 때도 있다. 이렇게 벅찬 와중에 우연한 기회로 심어본 인생 첫 잔디는 내게 새로운 원동력을 제공했다는 점에서 큰 의미가 있다. AI 시대의 PM/PO로서 필요한 역량은 조금씩 그리고 꾸준히 채워나갈 예정이다. 앞으로도 부단한 노력을 통해 궁극적으로는 사람을 진정으로 이해하고 기술을 활용하여 사람에게 새로운 가치를 전달하는 엔지니어링 PM/PO가 되고 싶다.