시작은 딴 나라 얘기였습니다

미국 개발자 커뮤니티에서 요즘 "Roast My ~" 시리즈가 한창 화제입니다. Roast My Strava, Roast My Code, Roast My Github... AI한테 내 결과물을 가져다 주면 신랄하게 까달라고 하는 콘셉트입니다.

보면서 딱 생각했습니다. 이거 재밌겠다!

마침 그 날 LinkedIn 프로필을 수정했어서인지 바로 눈에 들어왔습니다. LinkedIn 프로필 팩폭 서비스! 우리나라에도 있을까 싶어서 찾아봤는데 아직은 없었고, 해외에 있는 비슷한 서비스들도 직접 들어가봤더니 하나같이 작동을 안 했습니다. 스크래핑 API 할당량이 다 찼거나, LinkedIn이 봇 접근을 아예 막아버린 거였습니다.

그래서 바~로 만들기로 맘먹었습니다! 이왕이면 한국식으로! 🇰🇷

목적부터 분명히

이 프로젝트는 온전히 나와 Claude 둘이서 만든 프로젝트입니다. 기획 단계에서부터 Claude와 함께 계속해서 대화를 주고받으며 만들어나갔습니다. 처음에는 이것저것 거창하게 생각했는데, 대화하다 보니 결국 하나로 정리됐습니다.

빠르고 간단하게, 재미있어 보이는 걸 만들자.

완벽보다는 일단 만들어서 세상에 내놓고 반응부터 보는 걸 목표로 했습니다. 단순하게 진짜 사람들이 이걸 쓸까? 궁금했기 때문입니다. 무료 API 할당량이 얼마나 빨리 소진될지 기대됐습니다.

첫 번째 기술 결정 — 스크래핑을 포기하지 않는다

LinkedIn은 스크래핑을 철저하게 막습니다. 실제로 소송까지 간 케이스가 있을 정도입니다. 근데 찾아보니 아직 가능한 API들이 있었습니다.

그래서 Claude와 기본 UI부터 빠르게 만들어서 스크래핑이 어떻게 진행되는지 어떤 에러가 나는지 테스트를 해보았는데, 하다보니 고민이 생겼습니다.

API가 막히거나 할당량이 다 차면 어떡하지?

그래서 RapidAPI 마켓플레이스를 뒤지기 시작했습니다. LinkedIn 스크래핑 API를 하나하나 다 찾아봤습니다. 유료는 사용자가 급속도로 늘어났을 때 고려하기로 하고, 우선 무료를 열심히 찾아서 8개를 모았습니다! 하나의 RapidAPI 키로 여러 API를 무료 구독할 수 있다는 걸 알게 되면서, 하나가 한도에 걸리면 다음 API로 넘기는 fallback chain 구조를 만들었습니다. 이렇게 할당량 문제는 해결!🌞

그리고 스크래핑 차단 문제는 더 재밌게 풀어보았습니다. 막히는 경험 자체를 재미있는 UX로 만들어버리자! 에러 페이지를 보여주는 대신, 차단당하는 순간을 할미 말투로 풀어내면 오히려 더 웃기지 않을까?

└─ 8개 RapidAPI를 순차적으로 시도
    ├─ 성공 → AI 분석으로 이동
    └─ 전부 실패
         ├─ 429 할당량 초과 -> "할미떼가 너무 인기가 많아부러서 요청 한도를 넘겨부렀어유~"
         ├─ 403 스크래핑 차단 -> "LinkedIn이 할미 못 들어오게 막아부렀어유~"
         └─ PDF/스크린샷 업로드로 안내

사용자 입장에서는 이 과정이 전혀 안 보입니다. 내부에서 조용히 돌다가, 정말 안 될 때만 할미 말투로 안내하고, 거기엔 항상 두 번째 방법(직접 업로드)이 기다리고 있습니다. 차단당하는 게 실패가 아니라 스토리가 되는 구조입니다. 이 아이디어가 떠올랐을 때 얼른 사용자들에게 보여줄 생각에 신나서 작업했던 것 같습니다.

두 번째 기술 결정 — PC와 모바일을 다르게

거의 다 만들어갈때쯤 테스트하다보니 하나가 걸렸습니다. LinkedIn 프로필을 PDF로 저장하는 기능이 PC에서만 됩니다. 모바일 앱에는 그런 기능이 없습니다.

잠깐 고민했지만, 그러면 둘 다 지원하면 되지! 하는 마음으로 바로 작업에 들어갔습니다.

• 💻 PC: LinkedIn → 더보기 → PDF로 저장 → 업로드
• 📱 모바일: 프로필 스크린샷 촬영 → 업로드 → AI Vision으로 분석

PDF는 텍스트가 그대로 뽑히니까 분석 정확도가 높고, 스크린샷은 AI의 이미지 분석 능력을 쓰는 겁니다. 어떤 방법이든 같은 /api/roast 엔드포인트로 들어오고, 파일 타입에 따라 처리만 달라지게 만들었습니다.

아키텍처 설계 — 토스 Frontend Fundamentals 적용

폴더 구조를 잡을 때 토스 Frontend Fundamentals를 참고했습니다. 핵심은 간단합니다 — 함께 수정되는 코드는 같은 디렉토리에. 예를 들어 결과 화면을 고치면 ResultScreen.tsx와 CringeGauge.tsx는 거의 항상 같이 수정되는데, 이 둘이 다른 폴더에 있으면 왔다갔다 하느라 정신없습니다.

app/
├── components/           # 전역 공유 UI (2개 이상 도메인에서 사용)
│   └── HalmiSpinner.tsx
│
├── domains/              # 화면별 도메인 (함께 수정되는 코드 응집)
│   ├── result/
│   │   ├── ResultScreen.tsx
│   │   └── CringeGauge.tsx  # result 전용 — 다른 곳에서 안 씀
│   └── upload/
│       ├── UploadScreen.tsx
│       └── UploadZone.tsx
│
├── lib/                  # 전역 공유 타입/유틸
└── api/                  # API 라우트

판단 기준은 딱 하나였습니다. "이 컴포넌트 다른 화면에서도 쓰나?"

쓰면 components/ 안 쓰면 해당 도메인 폴더 안. 심플하니까 좋습니다.

상태 관리 — 상태 머신으로 7개 화면 관리

page.tsx 하나에서 상태 머신 패턴으로 화면을 관리했습니다. Router 없이!

type Screen = 'landing' | 'scraping' | 'blocked' | 'upload' | 'loading' | 'result' | 'error'

// 흐름
landing → scraping → (성공) → loading → result
                   → (실패) → blocked → upload → loading → result

AI 모델 선택 — Claude에서 Gemini로 갈아탄 이유

처음엔 Claude Sonnet 4를 썼습니다. 근데 비용이 걸렸습니다. 바이럴 서비스라 트래픽을 예측할 수가 없는데, 건당 비용이 나가면 부담이 큽니다.

응답은 구조화된 JSON으로 받게 했습니다:

{
  "cringeScore": 72,
  "detectedWords": ["성장하는", "임팩트", "커뮤니케이션"],
  "roastText": "아이구~ 이 프로필 쓸 때 부끄럽지 않았어유?...",
  "tips": ["...", "...", "..."]
}

detectedWords를 배열로 받으니까 결과 화면에서 뱃지로 예쁘게 보여줄 수 있고, Slack 로그에도 바로 찍힙니다.

프롬프트 엔지니어링 — "발작 버튼" 시스템

충청도 사투리 할머니가 팩폭해주는 서비스니까 프롬프트가 핵심입니다. 한국인들이 LinkedIn에서 제일 많이 쓰는 단어들을 조사해서 프롬프트에 직접 넣었습니다. 이걸 "발작 버튼"이라고 이름 붙였는데 AI가 이 단어들을 보면 반드시 반응하도록 만든 클리셰 패턴입니다.

감성 설계 — 팩폭과 응원은 따로

처음엔 AI한테 "마지막엔 따뜻하게 마무리해줘"라고 시켰는데, 톤이 매번 달라져서 어색했습니다. 그래서 역할을 나눠버렸습니다.

• AI → 끝까지 팩폭만. 자기가 잘하는 것에 집중
• HalmiCheer 컴포넌트 → 고정 응원 문구로 마무리

브랜딩 — 할미떼의 탄생

미국에 "Roast My"가 있다면, 한국에는 뭐가 어울릴까?

"라떼는~" 드립이 떠올랐습니다. 꼰대 어른이 젊은 사람 훈수 두는 그 느낌. 거기서 디자이너로 일하는 친한 친구가 예전에 만들어줬던 힙머니 사진이 떠오르면서 딱 맞아떨어졌습니다.

할미떼 이름 지은 순간 이미 반은 된 느낌이었습니다.

밈 서비스 만드는 김에 생각난 건데, 이스터에그도 하나 넣었습니다. 재밌을 것 같아서.

🍫 동서식품 담당자님 보고 계시유? 할미떼 × 미떼 콜라보 어떻겠어유~ 💛

이런 쓸데없는 디테일 넣을 때가 제일 재밌습니다.😄

모니터링 — Sentry + Slack으로 끝

에러는 Sentry, 정상 사용 로그는 Slack Webhook. 심플하게 갔습니다.

👵 팩폭 완료!
• 오글 점수: 72/100 (부끄럽지 않았어유? 💀)
• 허세 단어: 성장하는, 임팩트, 커뮤니케이션
• 분석 방식: URL 스크래핑

사용자가 실제로 쓰다가 에러가 터지면 바로바로 대응하고 싶었고, API 할당량이 얼마나 소진되고 있는지, 업로드 방식으로 넘어가는 비율은 어떤지도 확인하고 싶었습니다. DB나 어드민 패널까지 만들 필요는 없어서, Slack으로 간단한 정보만 오도록 했습니다. 사이드 프로젝트에는 이게 딱입니다.

런칭 후 — 실서비스에서 터진 것들

배포하고 하루 만에 코드로는 절대 잡을 수 없었던 문제들이 발생했습니다. 분명 이상없었는데...

1. 한글 LinkedIn URL 스크래핑 실패

상아-이-1234567 같이 한글이 섞인 username을 넣으면 8개 API가 전부 실패합니다. RapidAPI 스크래퍼들이 비영문 username을 아예 못 처리하는 거였습니다.

에러 화면보다 사전 안내가 낫다고 봤습니다. 한글이 감지되면 "스크래핑이 안 될 수 있어유" 문구를 미리 띄워서, 업로드로 자연스럽게 유도하도록 바꿨습니다.

2. Gemini JSON 파싱 실패

간헐적으로 500이 터졌습니다. Gemini가 JSON을 반환할 때 가끔 json ... 마크다운 코드블록으로 감싸거나, 앞뒤에 설명 텍스트를 붙이는 경우가 있었습니다. 단순 JSON.parse()로는 당연히 터집니다.

2단계 파싱으로 해결했습니다:

try {
  // 1차: 코드블록 제거 후 파싱
  const cleaned = text.replace(/```[\s\S]*?\n([\s\S]*?)```/g, "$1").trim();
  result = JSON.parse(cleaned);
} catch {
  // 2차: 응답에서 첫 번째 { ~ 마지막 } 를 직접 추출
  const firstBrace = text.indexOf("{");
  const lastBrace = text.lastIndexOf("}");
  if (firstBrace !== -1 && lastBrace > firstBrace) {
    result = JSON.parse(text.slice(firstBrace, lastBrace + 1));
  }
}

1차에서 정규식으로 코드블록을 제거하고, 실패하면 2차에서 JSON 객체의 시작({)과 끝(})을 직접 찾아 추출합니다. Gemini가 코드블록 앞뒤에 어떤 텍스트를 붙이든 JSON만 정확히 꺼낼 수 있습니다. 파싱 실패 시에는 raw text를 Sentry에 찍어서 나중에 뭐가 깨뜨렸는지 추적할 수 있게 했습니다.

3. Gemini가 날짜를 모릅니다!

사용자 피드백으로 알게 된 문제입니다. 프로필에 "삼성 청년 SW 아카데미 2025년 1월"이라고 적혀 있으면, Gemini가 이걸 미래 일정으로 오인해서 "시작도 안 한 걸 경력이라고 올려 놓으면 사람들이 알아주는 줄 아는겨?"라고 팩폭하는 상황이 발생했습니다. 2025년 1월은 이미 지난 과거인데도.

LLM은 학습 시점의 지식만 가지고 있어서, 프롬프트에 현재 날짜를 명시적으로 알려주지 않으면 시간 기준을 잡지 못합니다. 해결은 간단합니다.

function buildSystemPrompt() {
  const today = new Date().toISOString().split("T")[0];
  return `...
오늘 날짜: ${today}
프로필에 적힌 날짜/기간을 판단할 때 반드시 오늘 날짜 기준으로 과거/현재/미래를 판단하세요.
...`;
}

한 줄 추가로 해결됐지만, 직접 피드백을 받기 전까지는 전혀 떠올리지 못한 문제였습니다. 실제로 사용자의 피드백을 통해 문제점들을 파악할 수 있어서 피드백 영역을 추가하길 정말 잘했단 생각이 들었습니다.

4. 클립보드 권한 거부

결과 화면 공유 버튼에서 NotAllowedError가 터졌습니다. navigator.share() → 실패 → clipboard.writeText()를 순서대로 호출하는 구조였는데, 버튼 클릭 한 번으로 보안 API를 두 개 연달아 부르면 두 번째에서 제스처가 소비된 걸로 간주돼서 거부당합니다.

navigator.share 지원 환경이면 그것만 쓰고 바로 return, 미지원이면 클립보드로 분기하게 고쳤습니다. 두 API가 경쟁하는 구조를 없앤 겁니다.

마치며

할미떼를 만드는 내내 재밌었습니다. 8개 API fallback chain을 엮을 때, 차단 화면을 스토리로 바꿀 때, 이스터에그를 심을 때...등등 이런 디테일 하나하나를 만들 때 재미있어 할 유저들을 생각하니 더 신나게 만들 수 있었던 것 같습니다.

그냥 AI 챗봇과 재밌는 서비스의 차이는 결국 디테일에서 나온다고 생각합니다. 그리고 무엇보다 만드는 사람이 재밌어야 쓰는 사람도 재밌습니다!

주변에 많이들 공유해주세요~~🙏

👉 할미떼 직접 써보기