부제: 디버깅, 디버깅, 또 디버깅... 그래도 60점은 되겠지?
이번 글에서 배울 것들
PRD만으로는 부족하다 - 초기 기획서에 "이런 문제가 생길 수 있다"까지 적어뒀으면 더 좋았을 거예요. 예를 들어 "네이버 API는 출처를 안 줄 수 있음", "중복 기사 처리 필요" 같은 것들요.
모르는 말이 나오면 바로 물어보자 - "BaaS가 뭐야?", "토큰이 뭐야?", "node_modules는 왜 이렇게 커?" — 부끄러워하지 말고 바로바로 물어봤어요. 그래야 이해하면서 진행할 수 있어요.
도메인 전문성은 AI가 대체 못한다 - AI는 코드를 잘 짜지만, "이 결과가 맞는지"는 몰라요. 뉴스 스크랩 10년 해본 사람이 "어? 이거 이상한데?"를 알아채는 거예요. 바이브 코딩은 도메인 전문가 + AI의 조합이 최강입니다.
디버깅이 진짜 일이다 - "만들어줘" 한마디로 끝나는 게 아니에요. 만들고 → 테스트하고 → 이상한 거 발견하고 → 고치고 → 또 테스트하고... 이 과정이 실제 작업의 80%예요.
1편에서 기획서(PRD)를 만들고, bkend.ai로 백엔드를 설정했어요.
테이블도 만들고, API도 연결했죠. 이제 진짜 눈에 보이는 화면을 만들 차례입니다.
"프론트엔드 만들어줘", "로그인 만들어줘", "대시보드 만들어줘"... Claude에게 요청하면 뚝딱뚝딱 코드가 나왔어요. 실행해보니 화면도 예쁘게 나오고, 버튼도 눌리고, 로그인도 되더라고요.
"오, 이거 진짜 되네?"
근데 말이죠... 실제로 써보니까 작동은 하는데 쓸모가 없는 예쁜 쓰레기였어요 😅
" 같은 이상한 문자가 섞여 있고...이번 편에서는 만들고 나서 진짜 쓸 수 있게 고치는 과정을 공유할게요. 바이브 코딩의 현실은 "만들어줘 → 완성"이 아니라 **"만들어줘 → 어? 이상한데? → 고쳐줘 → 또 이상한데? → 또 고쳐줘..."**의 무한 반복이더라고요.
백엔드 설정을 마치고 Claude에게 물었어요.
👤 나: "이거 프론트엔드 디자인이나 UI/UX는 전혀 구현이 안 돼 있는 거지?"
🤖 Claude: "네, 맞습니다. 현재는 백엔드/CLI만 구현되어 있고, 프론트엔드는 전혀 없습니다."
그래서 바로 시작했죠.
👤 나: "이거 시간은 얼마나 걸릴까? 나 20분 뒤에 나가야 하는데"
🤖 Claude: "프론트엔드 기본 세팅은 약 10-15분 정도 걸립니다. 20분 안에 할 수 있는 것: Vite + React + TypeScript 프로젝트 생성 (~2분), Tailwind CSS 설치 (~2분), 기본 폴더 구조 + React Router 설정 (~5분), bkend.ai API 클라이언트 설정 (~3분)"
15분만에 이게 다 된다고? 진짜 되나 싶었는데...
🤖 Claude: "프론트엔드 기본 세팅 완료!"
frontend/ ├── src/ │ ├── api/bkend.ts # bkend.ai API 클라이언트 │ ├── pages/ │ │ ├── Login.tsx # 로그인 페이지 │ │ ├── Signup.tsx # 회원가입 페이지 │ │ ├── Dashboard.tsx # 대시보드 │ │ └── Onboarding.tsx # 온보딩 위저드 │ ├── components/ # 공통 컴포넌트 │ ├── hooks/ # 커스텀 훅 │ └── App.tsx # 라우터 설정 └── .env # bkend.ai 설정
![생성된 폴더 구조 스크린샷 - VS Code 탐색기]
폴더가 잔뜩 생겼어요. 뭐가 뭔지 하나도 모르겠지만... 일단 됐대요. 모르는 게 나오면 바로바로 물어봤어요.
👤 나: "node_modules 폴더는 왜 이렇게 커?"
🤖 Claude: "React, Vite, Tailwind 등 모든 패키지(라이브러리)가 여기 들어있어요. 우리가 직접 만든 게 아니라 가져다 쓰는 코드들이죠."
아, 남이 만든 코드를 가져다 쓰는 거구나. 그래서 Git에 안 올리는 거고.
프론트엔드 작업을 시작하면서 온보딩 설계를 다시 논의했어요.
🤖 Claude: "온보딩을 3단계로 간소화했습니다. 처음 사용자가 '어떤 키워드가 좋을지' 모르고, 노이즈 필터도 뭘 제외해야 할지 모르니까요. 너무 많은 단계는 온보딩 포기율을 높입니다."
합리적인 제안이었어요. 근데 제가 반박했죠.
👤 나: "아니, 5단계는 해야 정교하게 기사가 나갈 거 같아. 지금도 나 매일 온다 뉴스 스크래퍼 조정하잖아. 대신 부담스러우면 공란으로 넘어갈 수 있게 해주고, 나중에 설정 가능하도록 하자."
PR 담당자/기자로 15년간 뉴스 모니터링을 해본 경험에서 나온 판단이었어요. 키워드 하나 차이로 쓸모없는 기사가 잔뜩 나오거든요.
결국 이렇게 합의했어요:
| 단계 | 내용 | 특징 |
|---|---|---|
| 1단계 | 기본 정보 | 회사명 → AI가 대표자/업종 자동 검색 |
| 2단계 | 관심 키워드 | AI 추천 5개 + [×]로 쉽게 제거 |
| 3단계 | 경쟁사 설정 | AI 추천 + 건너뛰기 가능 |
| 4단계 | 업계 동향 | 트렌드 키워드 (건너뛰기 가능) |
| 5단계 | 노이즈 필터 | "지금은 설정 안 함" 권장 |
핵심은 5단계를 유지하되, 부담을 줄이는 것이었어요:
도메인 전문가의 경험 + AI의 효율화 제안이 만나서 더 나은 설계가 나온 거죠.
갑자기 생긴 폴더와 파일들, 뭐가 뭘까요?
React: 화면을 만드는 도구예요. 레고 블록처럼 컴포넌트를 조립해서 화면을 만들어요.
Login.tsx = 로그인 화면 블록Dashboard.tsx = 대시보드 화면 블록Vite: React 프로젝트를 빠르게 만들어주는 도구예요. npm run dev 명령어를 치면 내 컴퓨터에서 웹사이트가 실행돼요.
Tailwind CSS: 디자인을 쉽게 하는 도구예요. CSS를 직접 안 써도 클래스명만 붙이면 스타일이 적용돼요.
html<!-- 이렇게 클래스만 쓰면 --> <button class="bg-blue-500 text-white px-4 py-2 rounded"> <!-- 파란 배경, 흰 글씨, 패딩, 둥근 모서리가 자동 적용 -->
TypeScript: JavaScript에 타입을 추가한 언어예요. "이 변수는 숫자야", "이 변수는 문자야"를 미리 정해두면 오류를 미리 잡아줘요.
👤 나: "로그인 회원가입 화면 만들어줘"
Claude가 열심히 코드를 생성하더니...
🤖 Claude: "완료! 로그인/회원가입 화면 만들었어요."
![로그인 화면 스크린샷]
오, 화면은 예쁘게 나왔어요! 이메일, 비밀번호 입력하고 로그인 버튼 누르면...
어? 또 로그인 화면이야?
👤 나: "ㅇㅋ 근데 로그인 기능까지만 구현되고 이후는 구현이 안 된 건가? 로그인하고 나니 다시 로그인 화면 보여지면서 안 넘어가네?"
알고 보니 두 가지 문제가 있었어요.
문제 1: 토큰 저장 버그
🤖 Claude: "API 응답을 보니
token이 아니라access_token으로 오네요. 수정하겠습니다."
bkend.ai에서 보내주는 응답 형식이 우리가 예상한 것과 달랐던 거예요. token이라고 생각했는데 실제로는 access_token이었죠.
문제 2: 대시보드가 없다
👤 나: "대시보드 기본 페이지 구현은 왜 안 됐을까?"
🤖 Claude: "대시보드 페이지는 기존에 기본 껍데기만 만들어져 있습니다. 지금 바로 구현하겠습니다."
로그인은 되는데, 로그인 후에 보여줄 화면 자체가 없었던 거예요! 😅
로그인이 기술적으로 어떻게 작동하는 걸까요?
1. 회원가입: 이메일+비밀번호를 서버에 저장 2. 로그인: 서버가 확인 후 토큰(Token) 발급 3. 토큰 저장: 브라우저의 localStorage에 저장 4. 이후 요청: 매번 토큰을 같이 보내서 "나 로그인한 사람이야" 증명
토큰은 놀이공원 입장 팔찌 같은 거예요. 한 번 받으면 그 다음부터는 팔찌만 보여주면 "아, 입장권 있는 사람이구나" 하고 인정해주는 거죠.
우리 버그는 서버가 access_token이라고 보내줬는데, 코드에서는 token을 찾고 있어서 토큰 저장이 안 됐던 거예요. 작은 오타 하나가 전체 로그인을 망가뜨린 셈이죠.
회원가입 버튼을 눌렀는데 에러가 떴어요.
🤖 Claude: "bkend.ai API 연결 문제네요. 에러 메시지를 보면:
SSM_PARAMETER_NOT_FOUND: Userside MongoDB 연결 문자열을 찾을 수 없습니다"
MongoDB? 뭔 소리야... 결국 bkend.ai 팀에 직접 물어봤어요.
👤 나: "bkend 쪽에 문의를 해보니 https://api-enduser-dev.bkend.ai 이거 api-enduser.bkend.ai인데 -dev가 붙었네요. -dev가 붙으면 bkend 개발진 쪽이 쓰는 거라는데? 빼고 한번 해볼래?"
🤖 Claude: "성공했습니다! URL에서 -dev를 빼니까 됩니다."
URL에 -dev가 붙어있어서 개발팀 전용 서버로 연결되고 있었던 거예요!
👤 나: "근데 왜 처음에 https://api-enduser-dev.bkend.ai 이렇게 호출한 거야? 어디서 뭘 참고했어?"
🤖 Claude: "MCP 응답에서 가져왔습니다. bkend.ai MCP 문서 자체에 -dev가 붙은 URL이 적혀 있어서 그대로 사용했습니다. bkend.ai 측에서 문서를 업데이트해야 할 것 같습니다."
중요한 교훈: AI도 문서가 틀리면 틀린 코드를 짜요. AI를 맹신하지 말고, 안 되면 직접 서비스 팀에 물어보는 것도 방법이에요.
바이브 코딩하다 보면 에러는 무조건 만나요. 제가 터득한 해결 방법:
1. 에러 메시지 읽기 - 무섭게 생겼지만 힌트가 들어있어요 2. Claude에게 에러 메시지 통째로 보여주기 - "이런 에러가 났어: [복붙]" 3. 공식 문서 확인하기 - 근데 문서가 틀릴 수도 있음! 4. 서비스 팀에 직접 문의 - 이게 제일 확실함
더 큰 문제는 중복 기사였어요. "삼성전자 실적 발표" 기사가 조선일보, 동아일보, 한경, 매경, 연합뉴스... 10개 언론사에서 거의 똑같이 나오거든요. 전부 보여주니까 TOP 10이 다 같은 내용이에요.
🤖 Claude: "제목 유사도를 계산해서 중복을 제거하는 알고리즘을 만들겠습니다."
pythondef deduplicate_articles(articles, threshold=0.5): # 1. 링크 중복 체크 # 2. 제목 유사도 계산 # 3. 같은 인물/회사가 나오면 더 엄격하게 체크 # 4. 점수 높은 기사만 유지
비슷한 제목의 기사들을 찾아서, 그 중 점수가 가장 높은 기사만 남기는 방식이에요.
여기서 깨달은 게 있어요. AI는 코드는 잘 짜는데, "이게 이상한 결과인지"는 잘 몰라요.
업계 경력이 있으니까 "어? 이거 이상한데?"를 알아챌 수 있었어요.
예를 들어볼게요. 스크래핑 결과를 보는데:
AI는 이런 걸 구분 못해요. "숙박"이라는 키워드가 들어갔으니 점수를 줬을 뿐이죠.
만약 제가 뉴스 스크랩을 한 번도 안 해본 사람이었다면? 이 문제들을 발견하지 못했을 거예요. "AI가 잘 해줬네~" 하고 넘어갔겠죠.
바이브 코딩에서 AI가 대체 못하는 건 "이게 맞는 결과인지 판단하는 도메인 전문성"이에요. 코드는 AI가 짜지만, 결과물을 검증하는 건 여전히 사람의 몫입니다. 뭐, 제가 바이브 코딩을 잘 못해서 그럴 수도 있지만요 😅
로그인도 되고, 대시보드도 나오고, 뉴스 스크래핑도 성공! 근데 결과를 보니...
👤 나: "음 api 호출을 하니까 출처가 전부 '네이버뉴스'로 나와. 그런데 실제는 이투데이, 조선일보, 동아일보 이처럼 원 언론사 출처가 있고, 실제 클릭해도 언론사로 넘어가잖아? 이 부분을 고칠 수 있을까?"
![출처가 전부 네이버뉴스로 나오는 스크린샷]
네이버 뉴스 API가 원래 언론사 정보를 안 주는 거였어요. 그래서 Claude와 해결책을 찾았죠.
🤖 Claude: "URL에서 도메인을 추출해서 언론사명으로 매핑하면 됩니다."
pythonDOMAIN_TO_SOURCE = { 'chosun.com': '조선일보', 'donga.com': '동아일보', 'mk.co.kr': '매일경제', 'platum.kr': '플래텀', # ... 100개 이상 매핑 }
기사 URL에서 도메인(chosun.com, donga.com 등)을 추출하고, 미리 만들어둔 매핑 테이블에서 언론사명을 찾는 방식이에요. 100개 넘는 언론사를 일일이 매핑했습니다.
또 다른 문제. 기사 제목에 이상한 문자가 섞여 있었어요.
삼성전자, "AI 반도체" 시장 공략
이건 HTML 엔티티라는 건데, 웹에서 특수문자를 표현하는 방식이에요. "는 큰따옴표(")를 의미해요. API에서 받아온 데이터를 그대로 보여주니까 이렇게 된 거죠.
🤖 Claude: "
html.unescape()함수로 변환하면 됩니다."
pythonimport html title = html.unescape(raw_title) # " → "
솔직히 말하면, 위에 적은 건 빙산의 일각이에요.
서비스는 엉망진창이었어요. 하루 종일 이상한 거 발견하고, Claude한테 물어보고, 고치고, 또 이상한 거 발견하고... 이 과정의 반복이었죠.
그리고 이 과정에서 깨달은 게 있어요.
PR 경력이 없었으면 발견하지 못했을 문제가 정말 많았어요.
AI는 "코드가 돌아가면 성공"이라고 생각해요. 근데 저는 결과물을 보고 "어? 이거 실제로 쓰면 안 되는데?"를 알아챌 수 있었거든요.
10년간 뉴스 모니터링하면서 쌓인 감각이 있으니까 "이건 아닌데?"를 바로 알아챌 수 있었어요.
그래서 저는 이렇게 생각해요:
"도메인 전문가가 바이브 코딩을 할 줄 알 때, 진짜 무서운 조합이 된다."
코딩만 할 줄 아는 사람? AI가 대체할 수 있어요. 도메인만 아는 사람? 만들 수가 없어요.
근데 도메인 전문성 + 바이브 코딩? 이건 AI도 대체 못하고, 기존 개발자도 쉽게 따라올 수 없는 영역이에요.
PR 10년 경력자가 직접 뉴스 스크래퍼를 만들면서 "이건 이래야 해, 저건 저래야 해"를 실시간으로 잡아내는 거잖아요. 외주 개발자한테 맡겼으면 이 디테일을 어떻게 설명했겠어요? 설명하다가 지쳐서 "그냥 됐어요, 이대로 쓸게요" 했을 거예요.
바이브 코딩의 진짜 힘은 여기 있는 것 같아요. 도메인 전문가가 직접 만들고, 직접 고치고, 직접 완성하는 것.
뉴스 스크랩의 꽃은 브리핑 이메일이죠. 매일 아침 메일함에 오늘의 뉴스가 정리되어 오는 거예요.
👤 나: "브리핑 발송부터 하고 UI는 이처럼 TOP 3 기사는 별도로 기사 내용을 요약하는 방식으로 해줘"
Claude가 이메일 발송 시스템을 만들어줬어요.
┌─────────────────────────────────────┐ │ 📰 팝업스튜디오 Daily Briefing │ │ 2026년 1월 2일 │ ├─────────────────────────────────────┤ │ 🥇 TOP 1 │ │ [기사 제목] │ │ AI 요약: 이 기사는... │ ├─────────────────────────────────────┤ │ 🥈 TOP 2 │ │ [기사 제목] │ │ AI 요약: 이 기사는... │ ├─────────────────────────────────────┤ │ 📋 기타 주요 기사 │ │ 4. [기사 제목] - 출처 │ │ 5. [기사 제목] - 출처 │ └─────────────────────────────────────┘
TOP 3 기사는 Claude API로 내용을 요약하고, 나머지는 제목+출처만 보여주는 형태예요.
실행해보니...
진짜 메일이 왔어요! 🎉
하루 4시간씩 작업하다 보니 코드가 엄청 늘어났어요. 컴퓨터 고장나면 다 날아가겠죠? Git으로 저장하고 GitHub에 올려뒀어요.
Git: 코드의 버전 관리 도구예요.
commit = 게임 세이브 포인트GitHub: Git으로 관리하는 코드를 온라인에 저장하는 서비스예요.
push = 로컬에서 만든 세이브를 클라우드에 업로드이번 프로젝트에서 생성된 코드량:
혼자서 4,600줄을 3일 만에? 바이브 코딩 아니었으면 불가능했을 거예요.
솔직히 말하면 아직 60점짜리예요.
해결한 문제들:
아직 남은 문제들:
1. PRD만으로는 부족하다 초기 기획서에 "이런 문제가 생길 수 있다"까지 적어뒀으면 더 좋았을 거예요. 예를 들어 "네이버 API는 출처를 안 줄 수 있음", "중복 기사 처리 필요" 같은 것들요.
2. 모르는 말이 나오면 바로 물어보자 "BaaS가 뭐야?", "토큰이 뭐야?", "node_modules는 왜 이렇게 커?" — 부끄러워하지 말고 바로바로 물어봤어요. 그래야 이해하면서 진행할 수 있어요.
3. 도메인 전문성은 AI가 대체 못한다 AI는 코드를 잘 짜지만, "이 결과가 맞는지"는 몰라요. 뉴스 스크랩 10년 해본 사람이 "어? 이거 이상한데?"를 알아채는 거예요. 바이브 코딩은 도메인 전문가 + AI의 조합이 최강입니다.
4. 디버깅이 진짜 일이다 "만들어줘" 한마디로 끝나는 게 아니에요. 만들고 → 테스트하고 → 이상한 거 발견하고 → 고치고 → 또 테스트하고... 이 과정이 실제 작업의 80%예요.
지금은 제 컴퓨터에서만 돌아가는 상태예요. 다음 편에서는 진짜 웹에 배포해서 누구나 쓸 수 있게 만드는 과정을 다뤄볼게요.
드디어 "다른 사람도 쓸 수 있는 서비스"가 완성되는 순간이 올 거예요! 🚀
| 상황 | 팁 |
|---|---|
| 시작할 때 | PRD + 예상 문제점까지 정리 |
| 모르는 말 나올 때 | 바로 Claude에게 "이게 뭐야?" |
| 에러 날 때 | 에러 메시지 통째로 복붙 |
| 결과가 이상할 때 | 도메인 지식으로 직접 판단 |
| 안 될 때 | 공식 문서 or 서비스팀 문의 |
| 작업 끝날 때 | Git commit + GitHub push |
💬 질문이나 의견은 댓글로 남겨주세요!
댓글을 작성하려면 로그인이 필요합니다.
부제: 디버깅, 디버깅, 또 디버깅... 그래도 60점은 되겠지?
이번 글에서 배울 것들
PRD만으로는 부족하다 - 초기 기획서에 "이런 문제가 생길 수 있다"까지 적어뒀으면 더 좋았을 거예요. 예를 들어 "네이버 API는 출처를 안 줄 수 있음", "중복 기사 처리 필요" 같은 것들요.
모르는 말이 나오면 바로 물어보자 - "BaaS가 뭐야?", "토큰이 뭐야?", "node_modules는 왜 이렇게 커?" — 부끄러워하지 말고 바로바로 물어봤어요. 그래야 이해하면서 진행할 수 있어요.
도메인 전문성은 AI가 대체 못한다 - AI는 코드를 잘 짜지만, "이 결과가 맞는지"는 몰라요. 뉴스 스크랩 10년 해본 사람이 "어? 이거 이상한데?"를 알아채는 거예요. 바이브 코딩은 도메인 전문가 + AI의 조합이 최강입니다.
디버깅이 진짜 일이다 - "만들어줘" 한마디로 끝나는 게 아니에요. 만들고 → 테스트하고 → 이상한 거 발견하고 → 고치고 → 또 테스트하고... 이 과정이 실제 작업의 80%예요.
1편에서 기획서(PRD)를 만들고, bkend.ai로 백엔드를 설정했어요.
테이블도 만들고, API도 연결했죠. 이제 진짜 눈에 보이는 화면을 만들 차례입니다.
"프론트엔드 만들어줘", "로그인 만들어줘", "대시보드 만들어줘"... Claude에게 요청하면 뚝딱뚝딱 코드가 나왔어요. 실행해보니 화면도 예쁘게 나오고, 버튼도 눌리고, 로그인도 되더라고요.
"오, 이거 진짜 되네?"
근데 말이죠... 실제로 써보니까 작동은 하는데 쓸모가 없는 예쁜 쓰레기였어요 😅
" 같은 이상한 문자가 섞여 있고...이번 편에서는 만들고 나서 진짜 쓸 수 있게 고치는 과정을 공유할게요. 바이브 코딩의 현실은 "만들어줘 → 완성"이 아니라 **"만들어줘 → 어? 이상한데? → 고쳐줘 → 또 이상한데? → 또 고쳐줘..."**의 무한 반복이더라고요.
백엔드 설정을 마치고 Claude에게 물었어요.
👤 나: "이거 프론트엔드 디자인이나 UI/UX는 전혀 구현이 안 돼 있는 거지?"
🤖 Claude: "네, 맞습니다. 현재는 백엔드/CLI만 구현되어 있고, 프론트엔드는 전혀 없습니다."
그래서 바로 시작했죠.
👤 나: "이거 시간은 얼마나 걸릴까? 나 20분 뒤에 나가야 하는데"
🤖 Claude: "프론트엔드 기본 세팅은 약 10-15분 정도 걸립니다. 20분 안에 할 수 있는 것: Vite + React + TypeScript 프로젝트 생성 (~2분), Tailwind CSS 설치 (~2분), 기본 폴더 구조 + React Router 설정 (~5분), bkend.ai API 클라이언트 설정 (~3분)"
15분만에 이게 다 된다고? 진짜 되나 싶었는데...
🤖 Claude: "프론트엔드 기본 세팅 완료!"
frontend/ ├── src/ │ ├── api/bkend.ts # bkend.ai API 클라이언트 │ ├── pages/ │ │ ├── Login.tsx # 로그인 페이지 │ │ ├── Signup.tsx # 회원가입 페이지 │ │ ├── Dashboard.tsx # 대시보드 │ │ └── Onboarding.tsx # 온보딩 위저드 │ ├── components/ # 공통 컴포넌트 │ ├── hooks/ # 커스텀 훅 │ └── App.tsx # 라우터 설정 └── .env # bkend.ai 설정
![생성된 폴더 구조 스크린샷 - VS Code 탐색기]
폴더가 잔뜩 생겼어요. 뭐가 뭔지 하나도 모르겠지만... 일단 됐대요. 모르는 게 나오면 바로바로 물어봤어요.
👤 나: "node_modules 폴더는 왜 이렇게 커?"
🤖 Claude: "React, Vite, Tailwind 등 모든 패키지(라이브러리)가 여기 들어있어요. 우리가 직접 만든 게 아니라 가져다 쓰는 코드들이죠."
아, 남이 만든 코드를 가져다 쓰는 거구나. 그래서 Git에 안 올리는 거고.
프론트엔드 작업을 시작하면서 온보딩 설계를 다시 논의했어요.
🤖 Claude: "온보딩을 3단계로 간소화했습니다. 처음 사용자가 '어떤 키워드가 좋을지' 모르고, 노이즈 필터도 뭘 제외해야 할지 모르니까요. 너무 많은 단계는 온보딩 포기율을 높입니다."
합리적인 제안이었어요. 근데 제가 반박했죠.
👤 나: "아니, 5단계는 해야 정교하게 기사가 나갈 거 같아. 지금도 나 매일 온다 뉴스 스크래퍼 조정하잖아. 대신 부담스러우면 공란으로 넘어갈 수 있게 해주고, 나중에 설정 가능하도록 하자."
PR 담당자/기자로 15년간 뉴스 모니터링을 해본 경험에서 나온 판단이었어요. 키워드 하나 차이로 쓸모없는 기사가 잔뜩 나오거든요.
결국 이렇게 합의했어요:
| 단계 | 내용 | 특징 |
|---|---|---|
| 1단계 | 기본 정보 | 회사명 → AI가 대표자/업종 자동 검색 |
| 2단계 | 관심 키워드 | AI 추천 5개 + [×]로 쉽게 제거 |
| 3단계 | 경쟁사 설정 | AI 추천 + 건너뛰기 가능 |
| 4단계 | 업계 동향 | 트렌드 키워드 (건너뛰기 가능) |
| 5단계 | 노이즈 필터 | "지금은 설정 안 함" 권장 |
핵심은 5단계를 유지하되, 부담을 줄이는 것이었어요:
도메인 전문가의 경험 + AI의 효율화 제안이 만나서 더 나은 설계가 나온 거죠.
갑자기 생긴 폴더와 파일들, 뭐가 뭘까요?
React: 화면을 만드는 도구예요. 레고 블록처럼 컴포넌트를 조립해서 화면을 만들어요.
Login.tsx = 로그인 화면 블록Dashboard.tsx = 대시보드 화면 블록Vite: React 프로젝트를 빠르게 만들어주는 도구예요. npm run dev 명령어를 치면 내 컴퓨터에서 웹사이트가 실행돼요.
Tailwind CSS: 디자인을 쉽게 하는 도구예요. CSS를 직접 안 써도 클래스명만 붙이면 스타일이 적용돼요.
html<!-- 이렇게 클래스만 쓰면 --> <button class="bg-blue-500 text-white px-4 py-2 rounded"> <!-- 파란 배경, 흰 글씨, 패딩, 둥근 모서리가 자동 적용 -->
TypeScript: JavaScript에 타입을 추가한 언어예요. "이 변수는 숫자야", "이 변수는 문자야"를 미리 정해두면 오류를 미리 잡아줘요.
👤 나: "로그인 회원가입 화면 만들어줘"
Claude가 열심히 코드를 생성하더니...
🤖 Claude: "완료! 로그인/회원가입 화면 만들었어요."
![로그인 화면 스크린샷]
오, 화면은 예쁘게 나왔어요! 이메일, 비밀번호 입력하고 로그인 버튼 누르면...
어? 또 로그인 화면이야?
👤 나: "ㅇㅋ 근데 로그인 기능까지만 구현되고 이후는 구현이 안 된 건가? 로그인하고 나니 다시 로그인 화면 보여지면서 안 넘어가네?"
알고 보니 두 가지 문제가 있었어요.
문제 1: 토큰 저장 버그
🤖 Claude: "API 응답을 보니
token이 아니라access_token으로 오네요. 수정하겠습니다."
bkend.ai에서 보내주는 응답 형식이 우리가 예상한 것과 달랐던 거예요. token이라고 생각했는데 실제로는 access_token이었죠.
문제 2: 대시보드가 없다
👤 나: "대시보드 기본 페이지 구현은 왜 안 됐을까?"
🤖 Claude: "대시보드 페이지는 기존에 기본 껍데기만 만들어져 있습니다. 지금 바로 구현하겠습니다."
로그인은 되는데, 로그인 후에 보여줄 화면 자체가 없었던 거예요! 😅
로그인이 기술적으로 어떻게 작동하는 걸까요?
1. 회원가입: 이메일+비밀번호를 서버에 저장 2. 로그인: 서버가 확인 후 토큰(Token) 발급 3. 토큰 저장: 브라우저의 localStorage에 저장 4. 이후 요청: 매번 토큰을 같이 보내서 "나 로그인한 사람이야" 증명
토큰은 놀이공원 입장 팔찌 같은 거예요. 한 번 받으면 그 다음부터는 팔찌만 보여주면 "아, 입장권 있는 사람이구나" 하고 인정해주는 거죠.
우리 버그는 서버가 access_token이라고 보내줬는데, 코드에서는 token을 찾고 있어서 토큰 저장이 안 됐던 거예요. 작은 오타 하나가 전체 로그인을 망가뜨린 셈이죠.
회원가입 버튼을 눌렀는데 에러가 떴어요.
🤖 Claude: "bkend.ai API 연결 문제네요. 에러 메시지를 보면:
SSM_PARAMETER_NOT_FOUND: Userside MongoDB 연결 문자열을 찾을 수 없습니다"
MongoDB? 뭔 소리야... 결국 bkend.ai 팀에 직접 물어봤어요.
👤 나: "bkend 쪽에 문의를 해보니 https://api-enduser-dev.bkend.ai 이거 api-enduser.bkend.ai인데 -dev가 붙었네요. -dev가 붙으면 bkend 개발진 쪽이 쓰는 거라는데? 빼고 한번 해볼래?"
🤖 Claude: "성공했습니다! URL에서 -dev를 빼니까 됩니다."
URL에 -dev가 붙어있어서 개발팀 전용 서버로 연결되고 있었던 거예요!
👤 나: "근데 왜 처음에 https://api-enduser-dev.bkend.ai 이렇게 호출한 거야? 어디서 뭘 참고했어?"
🤖 Claude: "MCP 응답에서 가져왔습니다. bkend.ai MCP 문서 자체에 -dev가 붙은 URL이 적혀 있어서 그대로 사용했습니다. bkend.ai 측에서 문서를 업데이트해야 할 것 같습니다."
중요한 교훈: AI도 문서가 틀리면 틀린 코드를 짜요. AI를 맹신하지 말고, 안 되면 직접 서비스 팀에 물어보는 것도 방법이에요.
바이브 코딩하다 보면 에러는 무조건 만나요. 제가 터득한 해결 방법:
1. 에러 메시지 읽기 - 무섭게 생겼지만 힌트가 들어있어요 2. Claude에게 에러 메시지 통째로 보여주기 - "이런 에러가 났어: [복붙]" 3. 공식 문서 확인하기 - 근데 문서가 틀릴 수도 있음! 4. 서비스 팀에 직접 문의 - 이게 제일 확실함
더 큰 문제는 중복 기사였어요. "삼성전자 실적 발표" 기사가 조선일보, 동아일보, 한경, 매경, 연합뉴스... 10개 언론사에서 거의 똑같이 나오거든요. 전부 보여주니까 TOP 10이 다 같은 내용이에요.
🤖 Claude: "제목 유사도를 계산해서 중복을 제거하는 알고리즘을 만들겠습니다."
pythondef deduplicate_articles(articles, threshold=0.5): # 1. 링크 중복 체크 # 2. 제목 유사도 계산 # 3. 같은 인물/회사가 나오면 더 엄격하게 체크 # 4. 점수 높은 기사만 유지
비슷한 제목의 기사들을 찾아서, 그 중 점수가 가장 높은 기사만 남기는 방식이에요.
여기서 깨달은 게 있어요. AI는 코드는 잘 짜는데, "이게 이상한 결과인지"는 잘 몰라요.
업계 경력이 있으니까 "어? 이거 이상한데?"를 알아챌 수 있었어요.
예를 들어볼게요. 스크래핑 결과를 보는데:
AI는 이런 걸 구분 못해요. "숙박"이라는 키워드가 들어갔으니 점수를 줬을 뿐이죠.
만약 제가 뉴스 스크랩을 한 번도 안 해본 사람이었다면? 이 문제들을 발견하지 못했을 거예요. "AI가 잘 해줬네~" 하고 넘어갔겠죠.
바이브 코딩에서 AI가 대체 못하는 건 "이게 맞는 결과인지 판단하는 도메인 전문성"이에요. 코드는 AI가 짜지만, 결과물을 검증하는 건 여전히 사람의 몫입니다. 뭐, 제가 바이브 코딩을 잘 못해서 그럴 수도 있지만요 😅
로그인도 되고, 대시보드도 나오고, 뉴스 스크래핑도 성공! 근데 결과를 보니...
👤 나: "음 api 호출을 하니까 출처가 전부 '네이버뉴스'로 나와. 그런데 실제는 이투데이, 조선일보, 동아일보 이처럼 원 언론사 출처가 있고, 실제 클릭해도 언론사로 넘어가잖아? 이 부분을 고칠 수 있을까?"
![출처가 전부 네이버뉴스로 나오는 스크린샷]
네이버 뉴스 API가 원래 언론사 정보를 안 주는 거였어요. 그래서 Claude와 해결책을 찾았죠.
🤖 Claude: "URL에서 도메인을 추출해서 언론사명으로 매핑하면 됩니다."
pythonDOMAIN_TO_SOURCE = { 'chosun.com': '조선일보', 'donga.com': '동아일보', 'mk.co.kr': '매일경제', 'platum.kr': '플래텀', # ... 100개 이상 매핑 }
기사 URL에서 도메인(chosun.com, donga.com 등)을 추출하고, 미리 만들어둔 매핑 테이블에서 언론사명을 찾는 방식이에요. 100개 넘는 언론사를 일일이 매핑했습니다.
또 다른 문제. 기사 제목에 이상한 문자가 섞여 있었어요.
삼성전자, "AI 반도체" 시장 공략
이건 HTML 엔티티라는 건데, 웹에서 특수문자를 표현하는 방식이에요. "는 큰따옴표(")를 의미해요. API에서 받아온 데이터를 그대로 보여주니까 이렇게 된 거죠.
🤖 Claude: "
html.unescape()함수로 변환하면 됩니다."
pythonimport html title = html.unescape(raw_title) # " → "
솔직히 말하면, 위에 적은 건 빙산의 일각이에요.
서비스는 엉망진창이었어요. 하루 종일 이상한 거 발견하고, Claude한테 물어보고, 고치고, 또 이상한 거 발견하고... 이 과정의 반복이었죠.
그리고 이 과정에서 깨달은 게 있어요.
PR 경력이 없었으면 발견하지 못했을 문제가 정말 많았어요.
AI는 "코드가 돌아가면 성공"이라고 생각해요. 근데 저는 결과물을 보고 "어? 이거 실제로 쓰면 안 되는데?"를 알아챌 수 있었거든요.
10년간 뉴스 모니터링하면서 쌓인 감각이 있으니까 "이건 아닌데?"를 바로 알아챌 수 있었어요.
그래서 저는 이렇게 생각해요:
"도메인 전문가가 바이브 코딩을 할 줄 알 때, 진짜 무서운 조합이 된다."
코딩만 할 줄 아는 사람? AI가 대체할 수 있어요. 도메인만 아는 사람? 만들 수가 없어요.
근데 도메인 전문성 + 바이브 코딩? 이건 AI도 대체 못하고, 기존 개발자도 쉽게 따라올 수 없는 영역이에요.
PR 10년 경력자가 직접 뉴스 스크래퍼를 만들면서 "이건 이래야 해, 저건 저래야 해"를 실시간으로 잡아내는 거잖아요. 외주 개발자한테 맡겼으면 이 디테일을 어떻게 설명했겠어요? 설명하다가 지쳐서 "그냥 됐어요, 이대로 쓸게요" 했을 거예요.
바이브 코딩의 진짜 힘은 여기 있는 것 같아요. 도메인 전문가가 직접 만들고, 직접 고치고, 직접 완성하는 것.
뉴스 스크랩의 꽃은 브리핑 이메일이죠. 매일 아침 메일함에 오늘의 뉴스가 정리되어 오는 거예요.
👤 나: "브리핑 발송부터 하고 UI는 이처럼 TOP 3 기사는 별도로 기사 내용을 요약하는 방식으로 해줘"
Claude가 이메일 발송 시스템을 만들어줬어요.
┌─────────────────────────────────────┐ │ 📰 팝업스튜디오 Daily Briefing │ │ 2026년 1월 2일 │ ├─────────────────────────────────────┤ │ 🥇 TOP 1 │ │ [기사 제목] │ │ AI 요약: 이 기사는... │ ├─────────────────────────────────────┤ │ 🥈 TOP 2 │ │ [기사 제목] │ │ AI 요약: 이 기사는... │ ├─────────────────────────────────────┤ │ 📋 기타 주요 기사 │ │ 4. [기사 제목] - 출처 │ │ 5. [기사 제목] - 출처 │ └─────────────────────────────────────┘
TOP 3 기사는 Claude API로 내용을 요약하고, 나머지는 제목+출처만 보여주는 형태예요.
실행해보니...
진짜 메일이 왔어요! 🎉
하루 4시간씩 작업하다 보니 코드가 엄청 늘어났어요. 컴퓨터 고장나면 다 날아가겠죠? Git으로 저장하고 GitHub에 올려뒀어요.
Git: 코드의 버전 관리 도구예요.
commit = 게임 세이브 포인트GitHub: Git으로 관리하는 코드를 온라인에 저장하는 서비스예요.
push = 로컬에서 만든 세이브를 클라우드에 업로드이번 프로젝트에서 생성된 코드량:
혼자서 4,600줄을 3일 만에? 바이브 코딩 아니었으면 불가능했을 거예요.
솔직히 말하면 아직 60점짜리예요.
해결한 문제들:
아직 남은 문제들:
1. PRD만으로는 부족하다 초기 기획서에 "이런 문제가 생길 수 있다"까지 적어뒀으면 더 좋았을 거예요. 예를 들어 "네이버 API는 출처를 안 줄 수 있음", "중복 기사 처리 필요" 같은 것들요.
2. 모르는 말이 나오면 바로 물어보자 "BaaS가 뭐야?", "토큰이 뭐야?", "node_modules는 왜 이렇게 커?" — 부끄러워하지 말고 바로바로 물어봤어요. 그래야 이해하면서 진행할 수 있어요.
3. 도메인 전문성은 AI가 대체 못한다 AI는 코드를 잘 짜지만, "이 결과가 맞는지"는 몰라요. 뉴스 스크랩 10년 해본 사람이 "어? 이거 이상한데?"를 알아채는 거예요. 바이브 코딩은 도메인 전문가 + AI의 조합이 최강입니다.
4. 디버깅이 진짜 일이다 "만들어줘" 한마디로 끝나는 게 아니에요. 만들고 → 테스트하고 → 이상한 거 발견하고 → 고치고 → 또 테스트하고... 이 과정이 실제 작업의 80%예요.
지금은 제 컴퓨터에서만 돌아가는 상태예요. 다음 편에서는 진짜 웹에 배포해서 누구나 쓸 수 있게 만드는 과정을 다뤄볼게요.
드디어 "다른 사람도 쓸 수 있는 서비스"가 완성되는 순간이 올 거예요! 🚀
| 상황 | 팁 |
|---|---|
| 시작할 때 | PRD + 예상 문제점까지 정리 |
| 모르는 말 나올 때 | 바로 Claude에게 "이게 뭐야?" |
| 에러 날 때 | 에러 메시지 통째로 복붙 |
| 결과가 이상할 때 | 도메인 지식으로 직접 판단 |
| 안 될 때 | 공식 문서 or 서비스팀 문의 |
| 작업 끝날 때 | Git commit + GitHub push |
💬 질문이나 의견은 댓글로 남겨주세요!
댓글을 작성하려면 로그인이 필요합니다.