RiCo-v2: 더 나은 연구자 커리어 관리 툴
URL: rico-lab.vercel.app
RiCo-v1은 사용자를 잡아두지 못한다
연구자에게 커리어 관리는 중요한 문제예요. 최근 채용 트렌드가 수시 채용으로 바뀌면서 평소에 자신을 PR할 수 있는 수단이 더 중요해졌어요. 저도 이 문제를 인지하고 rico-v1을 만들었어요.
RiCo-v1은 베타 딱지를 붙여 2달 동안 운영했어요. 체계적인 리서치나 기획으로 시작한 프로젝트가 아니어서 실제 수요가 있는지 확신하지 못했어요. 그래서 일단 MVP를 내보내고 데이터로 확인하자는 취지로 v1을 운영했어요. 2달 동안 운영 로그는 총 200건 이상, 세션은 56번 발생했어요. 사용자를 익명으로 받기 때문에 unique한 사용자가 몇 명인지는 알 수 없어요. 다만 제가 테스트한 횟수를 제외해도 최소 40번 넘는 접속이 있었어요.
접속한 세션 중 62.5%는 홈 화면에 도달했지만 아무 액션 없이 이탈했어요. 편집 화면까지 도달한 세션은 35.8%, 배포 화면까지 간 세션은 14.3%였어요. 그중 배포 코드를 다운로드한 세션이 1건, github으로 배포한 세션이 1건이었어요. 유입 경로는 티스토리가 9건, 검색이 5건, github이 2건이었고, 그 외 71.4%는 접속 경로를 알 수 없었어요. 79.9%는 한국에서 접속했고, 미국이 9.8%, 나머지는 이탈리아, 캐나다 등 기타 8개국이었어요. 사용자 기기는 노트북과 데스크탑이 75%, 모바일이 25%였어요.
데이터를 해석하면, 블로그나 검색으로 유입된 사용자는 있지만 대부분 실제로 사용하지 않고 첫 화면에서 이탈해요. 재사용을 위해 다시 방문한 경우는 없는 것으로 추정돼요. 따라서 개선 방향은 명확해요. 첫 페이지에서 서비스가 무엇을 제공하는지 빠르게 보여줘야 해요. 또한 사용자가 반복해서 접속할 명분을 만들기 위해 로그인 기능을 붙이고 사용자 데이터를 계정에 귀속시켜야 해요. 블로그를 통한 유입은 생각보다 많았어요. 그래서 블로그를 유입 채널로 쓰는 전략은 그대로 유지해요.
이력서 출력, 홈페이지 배포를 한 번의 흐름으로
v1에서는 사용자가 정보를 입력하고 홈페이지를 배포하면 정보가 휘발되는 일회성 흐름이었어요. 정보를 정리하고 입력하는 일은 번거로운데, 홈페이지 하나를 만들자고 그 수고를 들이라는 건 설득력이 약해요. 그래서 v2는 세 가지를 한 흐름으로 묶었어요.
- 입력한 정보를 서비스 내에 저장할 수 있어요.
- 버튼 딸깍으로 홈페이지를 배포할 수 있어요.
- 이력서를 PDF로 출력할 수 있어요.
한 번 입력해 두면 다음에 이력서가 필요할 때 빠르게 수정하고 출력할 수 있어요. 이력서는 표준적으로 쓰는 CV 형식으로 포맷팅해요. PDF는 AI나 ATS(지원자 추적 시스템)가 읽을 수 있는 형태로 출력해요. 주기적으로 접속하지는 않겠지만, 이력서가 필요한 시점마다 정기적으로 다시 방문할 여지가 있어요.
이 장점은 첫 랜딩 페이지에서 빠르고 직관적으로 보여줘야 해요.
두 달 간의 서류 작성 경험
RiCo에는 단순한 기술 개발이 아니라 실제 채용 프로세스를 겪으며 쌓은 노하우가 담겨 있어요. 저는 여러 번의 서류 탈락 끝에 KAIST 연구실, 네이버, 국내 스타트업 등에서 서류 합격을 경험했어요. 이 과정에서 이력서를 어떻게 구성해야 하는지, 어떤 실수를 자주 하는지 직접 시행착오를 겪으며 배웠어요. 이 도메인 지식을 AI 피드백 기능으로 제공해요.
사용자가 직무 공고를 읽고 직무명과 키워드를 입력하면, 이력서의 각 항목에서 개선할 부분을 제안해요. 예를 들어 성과에 대한 수치가 부족한 경우, 채용 공고에서 쓰는 언어와 다른 표현을 사용한 경우를 확인해요.
노코드 프로덕션 진짜 가능할까
최근 바이브 코딩으로 무언가를 만들었다는 이야기가 많이 들려요. 그런데 실제 사용자가 많은 프로덕션 환경에서도 AI로 개발하는 사례가 있더라고요. 그래서 이게 정말 가능한지, 어느 정도까지 맡겨도 되는지 도전해 보고 싶었어요.
먼저 짚어둘 점이 있어요. ‘아무것도 모르는데 코딩했어요!’ 같은 이야기를 하려는 건 아니에요. 저는 개발 지식이 있는 사람이에요. 작은 프로젝트지만 프론트엔드와 백엔드를 구현해 본 경험이 있어요. secret key나 api key를 어떻게 관리해야 하는지, CORS 정책이나 rate limit을 왜 걸어야 하는지 같은 개발 지식이 있어요. 다만 이번에는 써본 적 없는 기술 스택으로, 최대한 코드를 직접 건드리지 않고 프로덕트를 완성할 수 있는지 경험해 보고 싶었어요.
Frontend는 React를 사용했어요. 저는 react를 한 번도 써본 적이 없어서 비전공자의 입장을 간접 체험할 수 있을 것 같았어요. 게다가 react는 현재 가장 널리 쓰이는 UI 라이브러리라서 AI가 참고할 자료도 풍부해요.
DB CRUD와 로그인 관리는 supabase를 사용했어요. Firebase와 supabase 사이에서 고민했어요. Firebase는 DB 조회와 쓰기에 일일 제한이 있지만, supabase는 제한이 없어요. 대신 일주일 동안 비활성 상태면 프로젝트가 일시 중지돼요. 이 단점은 주기적으로 실행되는 매크로를 예약해 해결할 수 있어요. 구글과 깃헙 로그인도 코드 없이 supabase로 처리해요.
LLM은 openrouter API를 사용해요. Openrouter는 무료 모델을 제공하고, 모델명만 바꾸면 여러 provider로 전환할 수 있어서 업데이트할 때 코드를 건드릴 일이 없어요.
배포는 vercel로 해요. Github에 push하면 자동으로 release되고, 무료 hobby 플랜에서 월 100GB, 100만 회까지 요청을 서빙해 줘요. 사실상 무제한이에요. 다만 hobby 플랜은 비상업적 용도로만 쓸 수 있어요.
시스템 상태는 세 가지 채널로 추적해요. 오류는 Sentry로 추적해요. 에러가 발생하면 sentry에 로그가 쌓이고 메일로 알람이 와요. 사용자 로그는 Umami에 기록해요. 사용자가 어느 경로로 접속했는지, AI 피드백을 받았는지, github 배포를 했는지, PDF를 다운로드했는지가 익명화된 상태로 저장돼요. 사용자 피드백은 Sendto로 직접 받아요. 사용자가 보낸 피드백은 Sendto를 거쳐 제 메일로 전달돼요.
클로드 코드 외주 후기
앞서 말했듯 코드 구현은 전적으로 클로드 코드에 맡겼어요. 우선 Opus 5.5와 Sonnet 5.5가 나오면서 코드 구현 능력이 Opus 5 시절보다 좋아진 게 체감돼요. 특히 토큰 효율이 많이 개선되었어요. v2.0.0을 배포하기까지 약 24시간 동안 작업했는데, pro plan 토큰으로도 가능했어요. 모델은 작업에 따라 나눠 썼어요. 설계 점검, 코드 리뷰, 보안 점검 같은 중요한 작업은 Opus, 단순 구현과 부분 점검은 Sonnet, 자료 조사는 Luna를 사용했어요.
클로드로 작업하면서 전반적으로는 만족스러웠지만 아쉬운 부분은 있었어요.
디자인
위 예시는 클로드에게 디자인을 자율적으로 맡긴 사례예요. 왼쪽에 곡률이 들어간 선이 있고 오른쪽에 padding이 들어간 텍스트는 전형적인 AI 디자인이에요. 한눈 팔면 바로 AI 행동을 해버려요.
그래서 getdesign에서 디자인 시스템을 가져와 초기화했어요. 구현 결과가 어느 정도 나온 시점에는 /design:design-system 스킬로 수정된 가이드를 문서화했어요. 그리고 일관성에서 벗어나거나 공통으로 관리되지 않는 컴포넌트를 수정하도록 지시했어요. 중간중간 엇나가는 사례는 여전히 있었어요. 그래도 sonnet에게 디자인을 점검하라고 지시하면 곧잘 처리했어요.
마케팅 문구
마케팅 문구 작성은 결과가 일차원적이었어요. /brand-voice:generate-guidelines로 브랜드의 보이스톤을 문서화하고, /marketing:draft-content로 랜딩 페이지에 들어갈 문구를 sonnet에게 작성시켰어요. 그랬더니 단순하게 어떤 기능이 있는지 나열하기 시작했어요. ‘커리어를 관리하는 열정적인 연구자’라는 페르소나를 주고 제품의 주요 기능과 엮어서 구성하라고 다시 지시했어요. 그러자 마음에 드는 결과물이 나왔어요. 원하는 방향이 있다면 처음부터 함께 지시해야 했어요.
SEO
개선한 뒤 성능
랜딩 페이지에서는 SEO 최적화가 문제였어요. React는 브라우저에서 javascript를 실행해 페이지를 그려요. 그래서 주소로 접근해 받는 원본 HTML에는 내용이 거의 없어요. 구글 같은 검색 엔진은 javascript를 실행해 내용을 읽지만, 색인이 늦어지거나 불안정할 수 있어요. Javascript를 실행하지 않는 크롤러나 링크 미리보기는 내용을 읽지 못해요. 그래서 랜딩 페이지 한정으로 정적 HTML을 서빙하도록 지시했어요.
여기에 문제가 하나 더 있었어요. 이 HTML이 전체 시스템의 CSS 파일을 불러오고 있었어요. 랜딩 페이지에 필요하지 않은 스타일 정보까지 모두 가져와야 해서 약 500ms의 지연이 생겼어요. 랜딩 페이지에서 500ms 지연은 치명적인 사용 경험이에요. 그래서 랜딩 페이지에 필요한 최소한의 코드만 가져오도록 분리해 SEO와 UX를 개선했어요.
코드 삭제
마지막으로 코드를 날려 버린 일이 있었어요. 기존 요소를 다른 페이지로 옮기라고 지시했어요. 원래는 옮길 요소를 새 페이지에 복사한 뒤에 기존 페이지를 지워야 해요. 그런데 기존 페이지를 먼저 지우고서 위와 같은 메시지를 보냈어요. AI에게 지시할 때는 사람과 작업할 때보다 훨씬 자주 git 커밋을 남겨 버전을 관리해야 할 것 같아요.
배포하면 언제나 문제가 터진다
이번 작업에서는 개발자보다 QA 역할을 하는 느낌을 강하게 받았어요. 클로드가 만든 결과가 잘 돌아가는지, edge case는 없는지 점검하고 수정을 지시하는 일을 한참 반복했어요. 그렇게 점검해도 실제로 배포하면 문제는 반드시 터져요.
주변 동료에게 서비스를 공유했고 서비스 전 과정을 사용해 주었어요. 이 때 아이폰 사파리에서 HEIC 형식의 이미지를 업로드하면 문제가 생기는 걸 발견했어요. 알고 보니 사파리에서는 canvas를 통한 webp 인코딩을 지원하지 않았어요. 이 때문에 프로필 이미지를 webp로 변환하지 못했고, 결국 서버로 전송하는 데 실패했어요. 그래서 webp 변환이 실패하면 jpeg로 fallback하도록 수정하고 바로 배포했어요. 그 외에도 자잘한 에러가 계속 메일로 날아와서, 배포한 지 한 시간 만에 3곳 정도를 수정했어요.
매도 먼저 맞는 게 낫다고 하잖아요. 완벽해질 때까지 미루기보다 일단 배포하고 부딪히는 편이 효율적인 것 같아요.
최고의 하네스는 인간이다
이제 코드 작성은 확실히 클로드가 더 잘해요. 속도까지 생각하면 압도적이에요. 하지만 코드를 잘 쓰는 것과 프로덕트를 잘 만드는 것은 다른 이야기 같아요.
위에서 언급했듯, 마케팅 문구 작성부터 성능 개선까지 자율적으로 분석하라고 지시했는데도 문제를 찾아내지 못한 사례가 종종 있었어요. 위에서 다루지는 않았지만, 민감한 정보가 새어 나갈 여지가 있는 결함도 /security-review나 /code-review로는 잡아내지 못했어요.
코딩 에이전트가 발전하더라도 프로덕트에 대한 책임과 신뢰는 결국 사람에게서 나와요. 사용자는 AI가 아니라 사람을 믿고 자신의 정보와 시간을 맡기니까요.
RiCo를 만들면서 무엇을 만들어야 하는지, 무엇을 놓치고 있는지, 어디까지 믿고 맡길 수 있는지는 계속 고민해야 한다는 것도 배웠어요. 앞으로도 AI로 더 빠르게 만들되, AI가 놓친 문제를 발견하고 실제 사용자에게 필요한 방향으로 다듬는 일은 직접 해 나가려고 해요. RiCo는 그 과정을 계속 실험하는 프로젝트가 될 것 같아요.