그렇게 LLM 프로덕트를 잘 찍어내는 팀이 되었다..?

3줄 요약

• 해커톤 드리븐 빌딩방식으로 LLM 해커톤 참여 + MVP 제품 개발 중

• Lab Lab ai 해커톤 출전. Vec:lix app MVP 제작

• 이번에도 역시나 집 안 감. 사무실에서 잠. 그런 후 회고

목차

• 🌪️ 해커톤-드리븐 빌딩

• 🥽 Lab Lab ai agent 해커톤

• 🧐 회고

• 마무리

🌪️ 해커톤-드리븐 빌딩

Hackathon-Driven Building(해커톤 주도의 개발 방식)이 뭔가요?

(기존에 있는 말이 아니라, 새롭게 만든 말입니다.)

Pax_humana는 현재 연쇄적으로 LLM 해커톤에 참여하며, 각 해커톤마다 Veclix 서비스에 필요한 기능들을 제작하고 있다.

왜 해커톤에 참여하면서 MVP 개발을 하고 있느냐고 물어보면 그것만의 장점이 있기 때문이다.

최근 LLM 기반 해커톤이 국내/국외에서 많이 생겨나고 있다.

해커톤은 대부분 짧은 시간의 아이디제이션을 통해 프로덕트를 빠르게 만들어내는 대회다.

주제가 LLM기반이기 때문에 허용되는 아이디어의 폭이 굉장히 넓다.

Pax_humana가 만들어내고 있는 LLM기반 프로덕트라는 방향성과 해커톤의 주제가 일치한다.

보통 해커톤에 참여하는 다른 팀처럼 짧은 기간동안 아이디제이션을 하는게 아니라,

마일스톤대로 계획되어 있던 개발을 해커톤 기간 내에 끝내는 방식으로 참여하고 있다.

현재 Pax_Humana에서는 LLM기반 프로덕트를 빠르게 만들어내고 있기 때문에 이것과 핏이 잘 맞았다.

이 방식의 MVP 개발을 Hackathon-Driven Building으로 부르기로 했다.

Hackathon-Driven Building은 굉장히 큰 장점이 있다.

제품의 마감 기한이 정해져있고, 어쨌든 경쟁이라는 긴장감이 있기 때문에 팀 내부적으로 밀도있는 경험을 할 수 있었다.

대체로 MVP 개발은 최소 기능과 빠른 마감기한을 목표로 한다.

빠른 마감기한이라는 목표를 어떻게 설정하느냐에 따라서 애매해질 수 있는 포인트가 있다.

1. 최소 기능을 제외한 유저의 인터페이스를 고려하기 쉽지 않다. 2. 빠른 마감기한으로 인해 생기는 자잘한 에러를 감수한다.

이런 것들을 생각하지 않고, 적절한 or 충분한 마감 기한을 설정하면, 개발 밀도가 타이트하지 않을 수 있다.

개발 밀도를 올리면서, 빠른 마감 기한을 지키고, 성공적으로 최소기능을 제작하는 것이 MVP 개발에서 중요한 포인트라고 할 수 있다.

이 포인트를 Hackathon-Driven Building으로 채울 수 있다고 생각했다.

해커톤으로 가장한 MVP 개발은

경쟁이라는 요소를 추가해. 기존 MVP 개발이 줄 수 있는 경험보다 한 단계 더 높은 경험을 할 수 있다.

경쟁 때문에 조금 더 잘 만들기 위해, 사소한 부분까지도 정해진 시간 내에서 최선을 다한다.

MVP임에도 불구하고 조금 더 잘 만든 제품까지 챙기고자 했고,

같은 시간임에도 불구하고, 경쟁이 그것을 부추겼다.

최소 기능, 빠른 마감, 조금 더 나은 제품, 이 3마리 토끼를 잡는다는 목적으로

조코딩 AI 해커톤, LabLab Ai agent 해커톤에 연쇄적으로 참가했다.

결국 해커톤과 MVP 개발를 같이했기에, 빠른 시간 내에 최소 기능을 챙기면서 더 나은 제품을 만들기 위해 노력할 수 있었다.

지난 글은 조코딩 AI 해커톤에 참여한 이야기고

이번 글은 Lab Lab ai에서 해커톤 드리븐 빌딩을 실천한 회고다.

🥽 Lab Lab ai agent 해커톤

Lab Lab ai

lab lab ai는

ai 관련 해커톤 or

ai 관련 이벤트를 통해

ai 생태계의 발전을 이루고자 하는 단체다.

이번에 위와 같은 해커톤에 참여했다. 에이전트를 활용한 프로덕트를 만드는 것이 주제인데, 다양한 후원사들이 참여했다.

Open ai에서 종사하시는 연사분과 LLM관련 서비스, 오픈 소스의 대표분들이 나와서 자신의 제품을 소개하고 agent에 대한 개념을 소개했다.

(대회을 위해 Open ai api의 약간의 크래딧을 대회 참여한 메일의 계정으로 부여했다.)

🇰🇷 강제 국가대표

이번 해커톤에는 2381명이 참여했고, 398명의 팀과, 81개의 서비스가 탄생했다.

개회식을 트위치로 진행했는데, 트위치에서 다음과 같은 자료를 볼 수 있었다.

우리 팀에서 @연주환 Felix와 내가 해당 개회식을 시청하고 있었는데, 한국에서는 우리만 개회식을 시청하고 있었다.

태극기가 있으니, 기분이 이상했다. 마치 국가대표가 된 기분. 태극기의 무게가 무거웠다 ㅋㅋㅋㅋㅋ

💪 이전보다 더 미친 몰입

해커톤 기간동안, 무엇을 만들었나?

이전 7일 합숙을 통해 만들었던 프로덕트가 Veclix studio라면

이번에 만든 프로덕트는 사용자가 Veclix를 더 쉽게 사용할 수 있는 Veclix:app이다.

*Veclix는 유저가 더 쉽게 노코드로 AI Agent를 생성 및 판매할 수 있는 Agent 플랫폼이다.

Veclix 앱을 통해 유저는 조금 더 쉽게 벨릭스의 에이전트를 고용(employ)할 수 있다.

이번 해커톤에서는 Veclix의 에이전트와 상호작용을 쉽게 할 수 있는 창구로

UX/UI 개선과

기존 Veclix LLM 엔진을 고도화하는 것을 목표로 했다.

Vec:lix 앱에서는 사용하고 싶은 Agent를 고용하고, 그 결과를 싶게 확인할 수 있다.

이전 vec:lix 스튜디오에서는 유저가 결과를 확인하는 것이 쉽지 않았다. + 유저가 Vec:lix의 전체적인 사용 흐름을 파악하는 것이 어려웠다.

조코딩 해커톤에서도 심사위원들이 Veclix 스튜디오에서 에이전트를 만들고,

에이전트를 고용하는 것까지의 한 사이클을 시도해보기를 기대했다.

실제로는 에이전트를 제작 중에 유저가 이탈했는데, 이것은 유저가 제품 전체의 사용 흐름을 파악하는 것이 어려웠기 때문이다.

그걸 위해 Saas앱의 튜토리얼 과정을 제품 내에서 만들어야 하나, 혹은 튜토리얼 영상과 문서를 제작하고 고도화해야하는지에 대한 고민이 많았다.

처음에 로그인한 유저에게 사용방법을 처음부터 끝까지 하나하나를 알려줄 필요가 있었다.

Veclix 스튜디오는 유저가 처음 서비스에 들어갔을 때, 사용자의 흐름이 하나로 정리되지 못했다.

그렇기 때문에 유저는 Veclix 스튜디오에서 자신이 어떤 행동을 할지 몰라 서비스를 이탈하게 된다. 

(Vec:lix 스튜디오에서는 유저가 에이전트를 고용하고 사용하는 과정까지의 여정이 하나로 정리되어있지 못하다. 이미 사용해본 제작자가 아니라면, 튜토리얼 없이 한 번의 그 과정을 찾아가기 어렵다.)

그렇기에 이번에 주목했던 것은 유저의 흐름을 강제하자는 것이었다. 전체적인 UI를 채팅 형태로 바뀌었다.

유저는 처음부터 끝까지 하나의 채팅 화면에서 모든 것을 다 할 수 있다.

처음 유저가 veclix 서비스에 입장했을 때, 고용한 에이전트가 없고, 현재 사이클과 스케줄이 없으면, 첫 화면부터 veclix가 말을 거는 것부터 시작을 한다. 

채팅으로 store에서 에이전트를 고용해야 한다고 말한다.

그 다음, 다음 동작을 요청을 한다. 

채팅의 안내에 따라 유저가 에이전트를 고용한다면,

그 다음에는 에이전트에 필요한 Tool을 등록하라고 안내해준다.

만약 유저가 notion 툴이 필요하다면, 유저는 notion툴 등록페이지 버튼을 채팅에서 볼 수 있다.

Tool 등록을 완료했다면, 스케줄 등록을 안내한다.

정리하자면, 이전 veclix 스튜디오에서는

한 화면 내에서 유저가 에이전트를 생성할 수 있고,

진행 중인 에이전트를 사이드바에서 볼 수 있고

스케줄을 생성하기 위한 화면으로 이동할 수 있고,

working 중인 에이전트의 상태를 확인할 수 있었다.

Veclix app은 위와 같이 여러가지의 선택지를 한 화면에 두는 것이 아니라,

한 가지 선택지만 한 화면에 두는 것을 목표로 했다.

한 채팅 경험 안에서 모든 상태에 대한 체크와 안내를 가능하게 한다. 

에이전트 고용이 필요한 경우, -> 고용화면으로 이동하라는 버튼을 채팅으로 보내줌 

Tool 등록이 필요한 경우, -> 툴 등록 링크를 채팅으로 보내줌. 

모든 것이 완료되었다면 -> 스케줄 등록 메세지를 보내줌  

사이클이 워킹 중이라면 -> 워킹 중인 사이클의 결과들을 보여줌. 

이로 인해 팀 내부적으로도 따로 안내 메세지나 튜토리얼 영상 or 문서를 제작이 후순위의 task가 되었다.

앞으로 다양한 기능을 유저의 흐름을 의도적으로 유도하는 방향에서 고도화해보고자 한다.

🍚 월요일에는 밥도 안 먹음

얼마나 몰입을 했냐면, 토요일 밤에는 해커톤 오프닝을 들으면서 계속 작업에 몰두했고, 사무실에서 잤다. (역시나)

잠자고 일어나서 바로 일을 했다. 

그리고 밥은 포장이나 배달로해서 먹었다.

사실상 마감 시간인 월요일에는 밥도 먹지 않았다. 모두가 자고 일어나서 작업에 몰두하다가 첫 끼를 22시가 지나서야 먹었다. 

초 집중상태에서 주마등처럼 스쳐지나가던 것들은 다음과 같다.

아, 현재 성공한 팀들은 다 이렇게 지금까지 했구나.

🕖 남은 시간은 30분, 배포도 안 되고 발표자료도 없는데, 큰일났다?

이런 미친 몰입의 도중 우리는 깨달았다. 남은 시간은 30분이고, 우리는 아직 우리가 계획한 것들이 산더미처럼 남았다는 사실을. 

해커톤 드리븐 빌딩 방식으로 빌딩하고 있기 때문에 해커톤 과정에서 우리의 제품을 만들었다는 것에 안도해야 하나? 

초 몰입을 지친 팀원들을 몰아붙이고, 주섬주섬 데모를 만들어서 결과를 제출해야 하나? 

이런 고민들이 모두의 머리속에서 딜레마처럼 떠오를 때쯤. 우연히 모니터에 띄워놓은 lablab ai 홈페이지의 마감시간을 발견하게 된다. 

응? 3시간 남았는데? 

그것을 본 순간 많은 생각이 들었다. 시차가 잘못된 건가? 아니면, 통신의 문제인가? 혹시??!? 시간이 연장된 건가?  

위기는 곧 기회 

디스코드에 lablab ai 채널 해당 해커톤에 들어가서 공지를 봤더니 아래와 같았다. 

(해커톤 시간 3시간 연장 )

우리는 다시 결의에 차올랐다. 3시간 이내에 남은 것들을 최대한 만들고, 남은 발표 자료들도 만들어서 결국 마감 시간을 30분 정도 넘어서 제출했다. 마치 모든 걸 다 쏟아부은 슬램덩크의 산왕전이라고나 할까? 그 후 첫끼를 먹고 그제서야 퇴근을 했다.

🧐 회고

📈 성장

또한번 우리는 성장했다. 팀적으로도 개인으로도. 

팀적으로는 제품개발에 있어서 손발이 맞았다. 

신기했던 점은 약 6시간동안 서로 말도 없이 각자 자기 문제에 집중을 하느라, 대화를 일절하지 않은 적이 있는데, 

6시간 후에 대화를 해도, 그 동안 서로가 어떤 테스크들을 했고, 어떤 테스크들을 진행 중이었고, 어디까지 끝냈는지 예상되었다.

그 후에 서로가 필요한 요구사항들을 서로에게 제시하고, 다시 일을 하는 경험이었다..

제품 개발에 손발이 맞는 느낌이었고, 집단적 몰입이 굉장히 좋았다. 

🤔 고객을 빠르게 만나는 것 VS 제품을 제대로 빌딩하는 것 

팀에서의 다음 단계의 고민은 “고객을 빠르게 만나는 것” VS “제품을 제대로 빌딩하는 것” 중 어떤 것을 선택하느냐이다.

Saas 제품은 고객을 빠르게 만나는 것도 중요하지만, 제품을 제대로 빌딩하는 것도 중요하다고 생각된다. 

물론 가설은 검증해야겠지만, 제대로된 제품을 검증받는 것과 핵심 가설만 검증받는 것은 다르다.

지금까지 우리는 팀의 우선순위가 계속해서 바뀌고, 그것에 맞는 새로운 것들을 제작했기 때문에

고객을 만나기 위한 제품의 최소 사이클이 80%쯤 되었을 때, 새로운 최소 기능을 만들었다.

다시 새로운 최소 기능이 80%쯤 완료가 되었을 때, 다시 우선순위가 설정되고 새로운 최소 기능을 만들기 시작했던 것 같다. 

제품을 100%만들고, 테스트를 받고, 테스트를 기반으로 다음 단계로 가봐도 좋았을 것 같지만,

제품을 빠르게 만들 수 있다는 자신감이 있었던만큼 최소 기능 제품의 범위가 늘어나고 있었다.

그래서 이번에는 지금까지 만들어왔던 빈 곳들을 모두 채워서 제품을 제대로 빌딩하고,

고객을 빠른 시일 내에 만나는 것을 목표로 하고 있다.

시행착오로 우리의 좋았던 선택과 아쉬웠던 선택을 되돌아보고 있다.

그래봤자, 우린 Veclix를 시작한지 아직 약 한달밖에 지나지 않았다.앞으로의 한달이 기대된다. 

⤵️ 하방한계 

하방 한계란?

창업을 시작할 때, 최악을 생각하곤 한다. 최악 중 어떤 최악을 목표로 하는지를 정해야 한다. 

어떤 최악을 팀의 목표로 정하는지가 바로 하방 한계다.

사실 창업을 시작했을 때, 결과는 "input" X "direaction" X "luck" = "result"으로 결정된다. 

최상의 결과는 예측을 할 수가 없다.  luck에 따라 굉장히 서로 다른 결과를 준다. 

input과 direaction은 한계가 있다. input과 direaction의 범위가 1 ~ 10이라면 

luck의 범위는 1 ~ 100,000,000… 으로 정의할 수 있다. 

luck의 따라서 result의 결과가 크게 바뀐다. 

하지만, luck를 1로 가정했을 때, input * direaction만으로 얻을 수 있는 최상의 값을 설정할 수는 있다. 

그것이 바로 하방한계다. 

창업 팀에서는 하방 한계와 상방(최종 미션)을 설정하고 달려야 한다.

창업은 단기적인 불안과 장기적인 확신으로 이어진다. 불안은 하방 한계로 최소화할 수 있다. 

불안은 운에서부터 기원하는데, 그런 운을 최소값으로 넣을 때, 만족스러운 결과(하방 한계)가 나온다면, 

그 결과는 망해도 만족스러운 것이다. 

불안은 하방한계로 다스리고, 장기적인 확신의 꿈의 크기는 더 크게 계속해서 몰아붙여야 한다.

아마존보다 더 큰 기업을 만들겠다. 에어비엔비보다 더 큰 기업을 만들겠다. 나스닥에 상장하겠다. 인류의 새로운 평화의 시대를 만들겠다. 등등

그래서 우리의 하방한계는 무엇인가? 현재 우리의 단기적인 하방한계는 바로 

대한민국에서 LLM 프로덕트를 가장 잘 만들어 내는 팀

내부적으로나 외부적으로나 대한민국에서 LLM 프로덕트를 가장 잘 만드는 팀이 우리의 목표다. 

그렇게 된다면 망했을 때의 불안은 없다.

우리는 각 단계마다의 하방한계와 하늘을 뚫는 상방의 목표를 계속해서 설정하며 달려갈 계획이다. 

마무리

초기팀의 메이킹 로그는 소중하다.

글로벌 기업들이 어떻게 초기 고객 1000명을 모았는지에 대한 뉴스레터 first 1000를 요즘 많이 보고 있다.

초기의 notion은 어땠을까, 제피어는 어땠을까?

초기 팀의 스토리를 볼 때, 흥분되고 떨린다.

이렇게 하고, 더 하면 되는구나, 될때까지 하면 되는 구나. 

여기 없는 기업도 많다. 그 기업들이 초기에 많은 이야기들을 남겨놓았으면 어땠을까 싶다.

디스콰이엇의 메이킹 로그도 이것과 같다. 생생한 메이킹 로그가 떨림을 준다.

다양한 초기팀, 혹은 다양한 스테이지에 있는 팀들의 buiding in public을 보며 인사이트와 동기를 얻는다.

그렇기에 pax humana도 꾸준히 메이킹 로그를 남기고자 한다. 우리의 스토리를 공유하며 발현될 수많은 상호작용을 기대한다.

pax humana의 다음 스테이지는 무엇인가? 

• Veclix MVP 고도화.

• 베타테스트 + 디스콰이엇 + 프로덕트 헌트에 올리기 

• 다시한번 해커톤 드리븐 빌딩 시작이다. => SKT AI 해커톤 "프롬프터 데이 서울 2023"가자고