사실 같이 하고 싶던 두 명이 더 있었지만, 시간이 짧고 너무 모르는 사람 5명이 모이면 오히려 호흡 맞추기가 어려울 것 같아 3명으로 팀을 확정지었다.
브레인스토밍
사실 하고싶었던 기획이 있었던 거 치고 꽤나 오래동안 브레인스토밍 했는데, 아이디어들이 다 신박하고 재밌어서 해커톤 한 5번 더 나가도 괜찮을 거 같았다.
기획
프로덕트명
프로덕트 명은 Gandalf 이다. 사람과 사람을 연결해주는 추상적인 상징체 또는 등장인물을 이름으로 하고 싶었다.
GPT가 추천해준 여러 이름 중에 피터틸 패밀리에 들어가기 위해서 ‘여러 종족을 이어주는 반지의제왕의 간달프’를 골랐다.
처음에는 너무 이상했는데, 영어로 적어두고 계속보다 보니 익숙해졌다.
문제제기
그동안의 닫힌 조직 내에서의 네트워킹은 다소 구시대적인 방법이었다.
조직 내 커뮤니티에 글을 올려 나에게 맞는 사람을 찾거나,
링크드인과 같이 전세계 플랫폼에서 키워드 검색으로 열심히 반복 검색을 통해 찾거나,
아니면 오프라인에서의 만남을 기대해야했다.
그래서 우리는
‘닫힌 조직’ 내에서
‘말하듯이 검색’하면
‘AI’가 가장 적합한 인재를 찾아주는
솔루션/플랫폼을 만들고자 한다.
feat1: AI 기반 인재 검색 시스템
유저가 프롬프트 창에 찾고 있는 사람에 대해 기술하거나, 필요한 상황을 말하듯이 작성한다.
창 하단에는 시작하기 좋은 예시들을 보여줘서 유저가 어떤식으로 입력해야 할 지에 대한 고민을 줄여준다.
5~10초의 검색이 끝나면 AI가 찾은 검색어에 적합한 인재들을 보여준다.
그 사람에 대한 간단한 키워드, 추천하는 이유, 적합도, 보유 스킬을 카드 형식의 UI로 보여준다.
feat2: 적응형 이력 관리 시스템
AI 기반의 검색 시스템은 인재에 대해 더 많은 컨텍스트를 가지고 있어야 좋은 검색이 된다.
A 회사 경력 3개월, 특정 자격증 보유, 토익점수 950점 처럼 규격화된 포맷으로 스스로를 표현하기보다
자기소개서, 포트폴리오 사이트, 프로젝트 결과물, 커뮤니티 활동 등 풍부한 컨텍스트로 스스로를 표현할 수 있다.
feat3: 원클릭 제안서 발송
원하는 사람을 찾는 것도 어렵지만, 그런 사람에게 선뜻 연락하기 귀찮거나 겁이나 연결되지 못하는 경우도 많다.
그래서 검색된 사람에게 검색 유저의 컨텍스트를 기반으로 제안서를 작성해주는 기능 또한 제공할 예정이다.
해커톤 개발
하루 안에 가장 이 프로덕트의 핵심적인 기능을 보여주려면 어떤 기능이 우선일까 를 생각해봤다.
인재 Pool이 이미 존재한다라는 가정하에, 자연어로 사람을 검색한다는 개념을 보여주고 싶었기에 feat1을 먼저 구현해보기로 했다.
Dataset
플랫폼은 유저를 모을 때, 콜드 스타트 문제가 있다. 그래서 이걸 프로덕션에서 어떤 식으로 풀어낼 것인지에 대한 토의도 많이 진행했다.
이번 해커톤에서는 공개된 서강대학교 컴퓨터공학과 교수님 데이터 101명으로 데이터 스키마를 만들었다.
그리고 일부 수집한 학생 데이터를 AI로 합성된 다양한 분포의 가상의 학생 데이터 200명으로 인재 Pool의 다양성을 높였다.
Tech Spec
Design : figma , lovable
figma로 디자인하고 lovable, figma mcp 로 react code를 porting 했다.
FE : React.js
BE : FastAPI + Supabase(RDB + pgvector)
Search Augmentation: Gemini 2.5 Flash
supabase 가 생각보다 많은 것들을 해주었다. 기본 회원관리, OAuth 인증, vector DB ….
그래서 사실 API endpoint를 줄이고 줄인다면 /search 하나만 만들 수 도 있었다. (양심상 향후 개발 방향을 위해 인증은 백엔드로 데려왔다.)
AI가 가장 적합한 인재를 찾아주는 방법
AI로 검색을 어떻게 구현할 것인가에 대해서 여러가지 시도를 많이 해보았다.
1. Full Context Prompting으로 가장 적합한 사람, structured output으로 profile card 만들기
모든 인재에 대한 정보 + 검색 프롬프트 쿼리 + 조직 컨텍스트 ⇒ 가장 적합한 후보 3명 + 그 이유, 표시할 정보를 structured output 으로 출력하는 방법.
가장 간단하고, 실험 결과 만족할 만한 결과를 얻을 수 있었다. 하지만 인재 pool이 20명만 넘어가도 컨텍스트에 무리가 간다고 생각한다.
2. vector DB 로 검색
우리는 AI 검색을 내세웠기에 전통적인 SQL을 생각하지는 않았다. 그러면 vector 유사도 비교는 AI 검색이고 더 잘되지 않을까 라는 생각으로 진행했다. 인재풀의 인재는 모든 정보를 이어붙여 하나의 벡터를 만들고, 프롬프트를 임베딩해서 유사도 비교했더니 완전 망했다.
두번째 시도는 입력된 프롬프트를 인재풀의 데이터 형태와 유사하게 바꾸는 과정을 거치고 임베딩 하는 것이었다.
이것도 잘 안됐다.
세번째는 column 마다 벡터를 만들고, 각각에 대한 유사도의 평균을 구하는 방식을 적용해봤는데 잘 나왔다.
3. 자연어 프롬프트를 필터/페르소나로 LLM 으로 정규화
유저가 검색의 자연어 프롬프트를 우리가 예상한 대로 깔끔하게 적을거라고 믿지 않기로 했다. 유저가 찾고자하는 인재상을 적을 수도 있지만, 인재가 필요한 상황이나 자신에 대한 정보를 적을 수 도 있다.
따라서 유저가 입력한 자연어 프롬프트를 찾고자 하는 이상적인 인재상(페르소나)형태로 변환해주는 LLM 레이어를 만들었다. 이 작업을 하면서 추가적으로 검색을 위한 키워드도 함게 뽑는다.
4. 하이브리드 서치
BM25/SPLADE 기반 키워드 매칭, vector 기반 cosine 검색들을 블렌딩 했다.
성능이 너무 좋지 않아 키워드 매칭 기반 검색은 버렸고, 5번의 동적 SQL 방법론으로 바꿨다.
4. AI as Judge 로 적합도 점수 측정
모델을 학습시키지 않고, 단순한 프롬프트만으로 LLM을 적합도 생성 레이어로 만드는 방법을 적용하였다.
심사위원님의 조언 중에 루브릭을 적용해 적합도(수치)를 기준을 가지고 생성하는 방법에 공감해 적용하고자 한다.
5. 검색 키워드 추출 후 동적 SQL 쿼리
3번에서 추출된 키워드를 가지고 where 조건문에 like로 한놈만 걸려라 해서 가져오는 방법론. 나름 잘 작동했다.
이걸 좀 더 발전시키려면 LLM이 where에 들어가는 keyword 만 생성하는게 아니라 쿼리 전체를 동적으로 여러번 iteration 하며 생성하고, 그안에서 다시 select 하는 그런 구조도 생각해봤다.
6. 종합
데이터 스키마
개발삽질
•
Supabase connection 하는 방식을 헷갈려서 DB.name 에 프로젝트 이름을 써서 1시간 동안 삽질함.
•
파이썬으로 백엔드 개발해본건 처음이었는데, python3랑 python이랑 막 헷갈리고 가상환경에서 의존성 받은거는 외부에서 안되는거로 중간중간 짜증났음.
•
아무래도 LLM 응답을 함수처럼 사용해서 체이닝을 하다보니,AI response를 JSON 을 파싱하는 과정에서 오류가 잦았다.
•
Google login을 넣었는데 OAuth 로그인 할 때 redirection URL랑 토큰 받느라 시간 좀 썼다.
사업성
시장 규모
우리 서비스를 HR 플랫폼으로 포지셔닝 해야할지, HR/커뮤니티 SaaS로 포지셔닝 해야할지 고민이 되었다.
수익 모델 : B2C
유저 인터뷰를 했을 때 가장 어려웠던 점이 ‘검색’에 돈을 낸다는 거부감이었던 것 같다.
아이디어를 설명했을 때 ‘오 좋은데요?’라는 반응을 보이다가도, 그러면 ‘검색에 얼마까지 쓰실 수 있나요’라고 했을 때는 ‘에이 양아치네 그러면 안쓰죠’ 라는 반응이었다.
그래서 제공하는 가치를 살짝 바꿔 검색이 아닌 매칭에 과금하는 수익모델을 기획해봤다. 김과외 처럼 실제로 매칭이 되었을 때 일정금액을 받는 것이다.
또 하나는 검색결과를 모두 보여주고, 식별 가능한 정보와 연락 가능한 정보에 과금하는 방식이다. 과금에 거부감이 있다보니 이 핵심적인 기능에 광고를 보여주는 수익모델도 기획해봤다.
개인적으로는 이 방법이 마음에 드는데, 검색을 통해 ‘어 이 사람 진짜 잘 맞는데? 연락해보고 싶다’ 라는 가치를 확인 한 후에, 유저가 결제(또는 광고 시청)를 할 수 있다. 제품의 value가 확인 된 후에 결제할 수 있는 모델은 흔치 않기에 마음에 들었다. (바나나는 한입 먹어보고 맛없으면 안살래요가 안 되니까)
수익 모델 : B2B
초반에 회의를 할 땐 B2B가 위주였다.
‘조직의 장이 조직의 네트워킹 강화를 위해서 우리 서비스를 구매해주지 않을까?’
운 좋게도 이번 해커톤에 컴공학회 5개가 모여 구매 결정권자의 유저 인터뷰를 진행할 수 있었다.
‘무료면 기분좋게 도입 해 볼 것 같다. 유료면 연간 5만원이 마지노선.’
그래서 B2B 수익모델에만 의존하는 것은 포기했다. 왜냐하면 B2B 조직은 우리가 돈을 벌어야할 대상이기도 하지만 유저를 모아주고, 하나의 인재 풀이 되어주는 자산이라고 생각했기 때문이다. 개인이 아무런 조직에 소속되지 않은 상태에서 우리 서비스를 가입하여 자신의 정보를 업로드 할 이유는 없다. 조직에 소속되어 조직 내 네트워킹을 위해, 팀빌딩을 위해, 조직 장의 안내에 따라 진행하게 된다.
이러한 이유로 일정 규모 이하의 조직 이용 비용은 모두 무료로 하기로 했다. (물론 B2C로 광고를 열어 검색 비용정도는 충당하려한다.)
어느 정도 검증이 되었다면, 구매여력이 충분한 조직(돈 많은 학회, 인재 관리 툴이 부재한 인원이 많은 기업, 동문회, 대학교)에서는 구매할 수 있다고 생각했다. 따라서 광고제거, 인원 무제한, 조직 관리의 추가적인 기능 들을 제공하는 엔터프라이즈 요금제로 B2B 수익모델을 고려해보았다.
수익모델 : B2C 번외
갑자기 생각 난건데 다른 조직에 참여하여 검색하고 싶으면 돈내라는 것도 괜찮겠다.
헤드헌터들이 학회 조직 DB 풀에서 검색하고 싶을 수도 있으니까. 그러면 그 수익의 일부를 조직에 주거나, 검색 대상에게 리워드를 주는 방법도 괜찮을 것 같다.
후기
개발이 새벽 7시 즈음 완성(만족할 만한 수준의 검색 정확도)되었는데, 정말 뿌듯했다.
비록 feature1 까지의 개발이었지만, 가치를 보여줄 수 있는 최소 기능 단위를 만들어냈다.
친구들에게 소개해줘도 신기해했고, 각자 지금 팀에 부족한 사람들을 검색해보며, ‘아 이런사람 있으면 진짜 좋았을텐데’라는 후기도 있었다.
우리가 아는 서강대 교수님 데이터가 중간중간 등장하기에 검색결과의 신뢰성이 있었고, 가상의 데이터셋 200명은 검색결과의 다양성을 높여주었다.
사실 이 솔루션의 가장 어려운 문제인 양질의 데이터 확보를 건너뛰었기에, (실제였다면 300명이 모두 저렇게 완벽하게 자신의 정보를 채웠을리 없다.) 살짝은 대회용 프로덕트라는 지적을 받을만하다.
그래도 AI를 어떻게 기술적으로 녹여낼지, 사업성에 대한 고민을 한 부분, 디자인이나 심미적 완성도를 인정 받아 1회 Hack@thon에서 감사하게도 대상을 수상했다.
대회가 끝났지만 아직 더 하고싶은게 많이 남았고, 애정과 열정이 남아있기에(흔치 않다..!), 이 프로덕트를 더 발전시켜보고 싶다.
번외 : 식사
2.8 만원짜리 고급 도시락이 나왔다. 갈비찜이 아주 맛있었다. 감자샐러드도 고급졌다. 달달한 과자만 잔뜩 먹다 한식을 먹으니 소화가 잘되는 것 같았다.
아쉽게도 야식이 없어서(저녁에 돈을 다 쓴 것 같다.) 새벽 한시에 곱도리탕을 시켰다. 미안하게도 운영진이 옆에서 부러워했지만, 사람이 너무 많아 나눠주기엔 무리인 2.5인분이었다.
아침도 맛있었다.
Subscribe to 'Yejun Cheon'
Subscribe to my site to be the first to receive notifications and emails about the latest updates, including new posts.
Join Slashpage and subscribe to 'Yejun Cheon'!