부제: "다른 사람도 쓸 수 있게 만들고 싶어" — 그 한마디에서 시작된 여정
이전 글에서 저는 Claude Code로 뉴스 스크래퍼를 만들었어요. CLI(Command Line Interface) 방식의 도구였는데요, CLI란 우리가 흔히 보는 버튼이나 아이콘 대신 텍스트 명령어로 컴퓨터를 조작하는 방식이에요. 윈도우의 검은 창(명령 프롬프트)이나 맥의 터미널 같은 거죠.
매일 아침 터미널을 열고 python onda_news_scraper.py라고 명령어를 치면, 제가 원하는 뉴스만 쏙쏙 골라서 이메일로 보내주는 도구였죠. PR 담당자로서 매일 30분씩 뉴스 검색하던 시간을 10분으로 줄여준 고마운 녀석이에요. 사실 아래 내용은 이전 글을 안보셨거나, 바이브 코딩에 대한 감이 없으면 조금 어려울 수 있거든요. 가능한 스스로 바이브코딩 환경 세팅을 안해보셨거나, 잘 모르시겠다면 이전 글을 읽어보시길 권해요^^
암튼 근데 어느 날 문득 이런 생각이 들었어요.
"이거... 나만 쓰기 아깝지 않아?"
문제는 CLI 도구는 나만 쓸 수 있다는 거예요. 다른 사람이 쓰려면 Python을 설치하고, 터미널 여는 법을 배우고, 명령어를 외워야 해요. 개발자가 아닌 이상 진입장벽이 너무 높죠. PR 담당자, 마케터, 투자자... 뉴스 스크랩에 시간 쓰는 사람들이 얼마나 많은데요. 저처럼 매일 아침 구글 뉴스, 네이버 뉴스 돌아다니면서 기사 찾는 분들 많잖아요.
그래서 웹 서비스로 만들기로 했어요. 웹 서비스는 브라우저에서 주소만 치면 누구나 쓸 수 있으니까요. 네이버, 구글처럼요. Claude에게 물었습니다.
👤 나: "자 이걸 기반으로 다른 사람들도 쓸 수 있는 프로그램을 만들고 싶은데 다른 폴더에 새로운 프로젝트를 시작해 볼까?"
🤖 Claude: "좋은 생각이에요! 다른 사람들도 쉽게 자신만의 뉴스 스크래퍼를 만들 수 있는 범용 프로젝트를 시작해볼까요?"
이렇게 시작된 여정. 이번 글에서는 CLI 도구를 웹 서비스로 진화시키는 과정을 따라가 볼게요. 코딩 한 줄 모르는 제가 어떻게 로그인, 회원가입, 대시보드까지 만들었는지 — 그리고 그 과정에서 실제로 어떤 기술들이 돌아가고 있었는지 함께 알아봅시다.
솔직히 말하면, 저도 "프론트엔드", "백엔드", "API" 이런 말 들으면 머리가 아팠어요. 근데 바이브 코딩의 좋은 점은 다 몰라도 일단 만들 수 있다는 거예요. 물론 기본 개념을 알면 훨씬 수월하고요. 그래서 이 글에서는 [작업기] 로 실제 대화를, [바이브 이면의 기술] 로 그 뒤에서 뭐가 돌아가는지 설명해드릴게요.
처음에는 그냥 "뉴스 스크래퍼 웹사이트 만들어줘"라고 할까 했어요. 근데 이전 경험상, AI에게 막연하게 요청하면 결과물도 막연해지더라고요. "웹사이트 만들어줘"라고 하면 "어떤 웹사이트요? 기능은요? 디자인은요?" 이렇게 되물어보거든요. 그래서 기획부터 제대로 하기로 했습니다.
👤 나: "음 ㅇㅋ 일단 엔진이 돌아가는 걸 확인했으니. 제품 기획을 좀 더 명확히 해야 할거 같아. 기획서를 같이 작성해 볼까?"
🤖 Claude: "좋아요! 기획서를 같이 작성해 봅시다. 몇 가지 방향을 먼저 정리하면 좋을 것 같아요. 핵심 질문들 — 타겟 사용자는? 핵심 가치는? 수익 모델은? 차별점은? MVP 범위는?"
Claude가 질문을 던져주니까 머릿속에 흩어져 있던 생각들이 정리되기 시작했어요. 이게 바이브 코딩의 장점이에요. AI가 적절한 질문을 던져주면서 생각을 구조화해줘요.
👤 나: "뭐 마케터, 경영진, 투자자 모두지 뭐. 핵심가치는 정말 디테일하게 원하는 기사만 보게 하고 싶어. 수익모델은 그냥 무료로 배포하려고. 차별점은 개인화가 진짜 잘됐으면 좋겠어."
기존에 시중의 뉴스 클리핑 서비스들을 써봤는데, 무료 버전은 키워드 5개밖에 못 넣고, 원하는 기사가 잘 안 나오더라고요. "삼성전자"를 키워드로 넣으면 삼성전자 주식 이야기, 삼성전자 부고 기사, 삼성전자 광고 기사까지 다 나와요. 제가 원하는 건 "삼성전자의 B2B SaaS 사업 동향"인데 말이죠.
그래서 확실한 차별점을 잡았습니다:
👤 나: "일단 그렇게 하고 타 서비스는 무료 버전에서 키워드 등록이 한정적이니까 우리는 그걸 좀 풀고 한 30개까지 등록되게, 그리고 내가 원하는 기사를 스크랩할 수 있는 튜토리얼 과정을 세밀하게 세팅하게 해서 원하는 기사가 잘 나왔으면 좋겠어"
Claude는 이 내용을 바탕으로 PRD(Product Requirements Document) 문서를 만들어줬어요. 타겟 사용자, 핵심 기능, 화면 구성, 데이터 구조까지 정리된 20페이지짜리 기획서가 뚝딱 나왔습니다.
PRD(Product Requirements Document) 는 '제품 요구사항 문서'예요. 쉽게 말해 "우리가 뭘 만들 건지 정리한 기획서" 죠. 스타트업이나 IT 회사에서 새 제품 만들 때 항상 이걸 먼저 써요.
왜 AI한테도 기획서가 필요할까요? AI는 맥락을 이해하고 일관성 있게 작업하려면 명확한 가이드라인이 필요하거든요. 사람도 마찬가지잖아요. "그냥 좋은 거 만들어줘"라고 하면 뭘 만들어야 할지 모르는 것처럼요.
PRD가 있으면:
우리 PRD에는 이런 내용들이 담겼어요:
팁: 바이브 코딩할 때 처음부터 PRD를 완벽하게 쓸 필요 없어요. Claude와 대화하면서 점점 구체화하면 됩니다. 저도 "챗봇 넣을까?" 같은 아이디어는 대화 중에 추가했거든요. PRD는 살아있는 문서예요.
기획서가 나왔으니 이제 만들어야죠. 근데 여기서 첫 번째 난관이 왔어요.
🤖 Claude: "백엔드는 어떻게 하실 건가요? FastAPI로 직접 만들까요, 아니면 BaaS를 사용할까요?"
백엔드? BaaS? FastAPI? 뭔 소리야... 😱
솔직히 이 시점에서 "아 역시 개발은 개발자가 해야 하나"라는 생각이 살짝 들었어요. 근데 다행히 저는 우리 회사(Popup Studio)에서 만든 bkend.ai가 있었어요. 동료들이 "백엔드 직접 안 짜도 되는 서비스"라고 소개해줬거든요.
👤 나: "어디까지나 난 개발을 잘모르는 왕초보야. 근데 우리 동료들이 백엔드로 https://www.bkend.ai/를 사용하라고 추천해줬어. 이걸 감안해서 작업해줘."
🤖 Claude: "이해했습니다! ,다양한 회사 PR 담당자들을 위한 범용 서비스의 백엔드는 bkend.ai를 사용하겠습니다."
웹 서비스는 크게 프론트엔드와 백엔드로 나뉘어요. 이 개념을 이해하면 바이브 코딩할 때 훨씬 수월해요.
비유하자면 레스토랑이에요:
손님(사용자)은 예쁜 홀(화면)만 보지만, 실제 음식(데이터)은 주방(서버)에서 만들어져요. 손님이 "스테이크 주세요"라고 하면(버튼 클릭), 웨이터가 주방에 전달하고(API 호출), 주방에서 요리해서(데이터 처리) 내놓는 거죠(응답).
백엔드가 하는 일을 구체적으로 보면:
**BaaS(Backend as a Service)**는 이 백엔드를 직접 만들지 않고, 서비스로 제공받는 것이에요. 마치 집에서 요리 안 하고 배달 시켜먹는 것처럼요. Firebase, Supabase, 그리고 bkend.ai 같은 서비스들이 대표적이죠.
직접 서버 만들기 vs BaaS 비교:
| 구분 | 직접 만들기 | BaaS 사용 |
|---|---|---|
| 난이도 | 어려움 (서버 구축, DB 설정, 배포, 보안 다 해야 함) | 쉬움 (클릭 몇 번이면 끝) |
| 시간 | 몇 주~몇 달 | 몇 시간~며칠 |
| 비용 | 서버비 발생 (AWS, GCP 등) | 무료~저렴 (소규모는 대부분 무료) |
| 유연성 | 높음 (원하는 대로 커스텀 가능) | 제한적 (서비스가 제공하는 범위 내에서) |
| 추천 대상 | 개발자, 복잡한 서비스 | 바이브 코더, MVP, 빠른 검증 👈 |
저처럼 백엔드를 모르는 사람에게 BaaS는 구세주예요. "회원 테이블 만들어줘", "로그인 API 써도 돼?" 이런 고민 없이 그냥 쓰면 되니까요.
bkend.ai에 가입하고 프로젝트를 만들었어요. 콘솔 화면이 뜨는데, 뭘 해야 할지 모르겠더라고요. 그래서 Claude에게 물었죠.
🤖 Claude: "PRD에 정의된 4개의 Collection을 만들어야 합니다: users, profiles, scrape_results, briefings"
Collection? 아, 테이블이구나. 엑셀 시트 같은 거.
👤 나: "profiles 만들거야" 👤 나: "scrape_results 만들거야" 👤 나: "briefings 만들어볼까?"
하나씩 테이블을 만들었어요. bkend.ai 콘솔에서 테이블 이름 입력하고, 필드 추가하면 끝. 생각보다 간단했어요. 근데 나중에 알아보니 bkend.ai는 클로드 mcp를 지원해서 제가 일일이 만들 필요 없이 그냥 클로드에게 시키면 되는 일이더군요.
MCP(Model Context Protocol) 는 AI가 외부 서비스와 직접 연결되는 프로토콜이에요. 원래 Claude는 인터넷에 직접 접속을 못 해요. 근데 MCP를 설정하면 특정 서비스(bkend.ai, Jira, Slack 등)에 접속할 수 있는 "열쇠"를 주는 거예요. 덕분에 Claude가 "테이블 목록 보여줘"라고 하면 진짜로 bkend.ai에서 데이터를 가져올 수 있는 거죠.
그런데 API 테스트에서 문제가 생겼어요. Claude가 bkend.ai에 데이터를 넣어보려고 했는데 계속 에러가 나는 거예요.
🤖 Claude: "API 테스트해봅시다. curl로 users 테이블 조회를 먼저 해볼게요." 🤖 Claude: "네트워크 문제가 있네요. bkend.ai API 엔드포인트 형식이 다를 수 있습니다."
이런저런 시도 끝에 MCP(Model Context Protocol) 연동을 하기로 했어요. MCP는 AI가 외부 서비스와 직접 연결되는 프로토콜인데, 이걸 설정하면 Claude가 직접 bkend.ai 데이터베이스를 조회하고 수정할 수 있어요.
👤 나: "mcp 설정하는 법이 나와 있네. 아래 내용을 따라 줄래?"
json{ "mcpServers": { "mcp-bkend": { "type": "http", "url": "https://api.bkend.ai/mcp", "headers": { "X-Organization-Id": "여기에_Organization_ID_붙여넣기", "X-Api-Key": "여기에_API_키_붙여넣기" } } } }
MCP 설정 후 Claude Code를 재시작하니까, Claude가 직접 bkend.ai 데이터베이스를 조회할 수 있게 됐어요! 마치 Claude한테 bkend.ai 열쇠를 준 것 같았어요.
🤖 Claude: "bkend.ai 연동이 성공적으로 완료되었습니다! 모든 테이블이 정상적으로 배포되어 있습니다."
| 테이블명 | 상태 |
|---|---|
| users | ✅ deployed |
| profiles | ✅ deployed |
| scrape_results | ✅ deployed |
| briefings | ✅ deployed |
드디어 백엔드 준비 완료! 🎉
테이블은 엑셀 시트라고 생각하면 쉬워요.
users 테이블 = 회원 명단 시트 (이메일, 이름, 가입일...)profiles 테이블 = 뉴스 설정 시트 (키워드, 회사명, 경쟁사...)scrape_results 테이블 = 스크랩 결과 시트 (기사 제목, 점수, 날짜...)briefings 테이블 = 발송 기록 시트 (보낸 날짜, 받는 사람...)각 테이블에는 **필드(컬럼)**가 있어요. 엑셀의 열(A, B, C...)과 같은 개념이죠.
API(Application Programming Interface) 는 프론트엔드와 백엔드가 대화하는 방법이에요. 좀 더 쉽게 비유하자면 식당 주문서예요:
예를 들어 회원가입할 때 이런 일이 일어나요:
프론트엔드 → "이메일: test@test.com, 비번: 1234로 가입해줘" (API 요청) 백엔드 → 비밀번호 암호화, DB에 저장 → "오케이, 가입 완료!" (API 응답)
여기까지 기획 → 백엔드 설정을 마쳤어요.
다음 편에서는:
까지 다뤄볼게요. "로그인 화면 만들어줘" 한마디에 진짜 로그인이 되는 과정, 그리고 그 과정에서 터진 에러들을 어떻게 해결했는지 공유할게요! (스포일러: AI도 문서가 틀리면 틀린 코드를 짜요 😅)
(이게 뭔 말이다냐...)
💬 질문이나 의견은 댓글로 남겨주세요!
댓글을 작성하려면 로그인이 필요합니다.
부제: "다른 사람도 쓸 수 있게 만들고 싶어" — 그 한마디에서 시작된 여정
이전 글에서 저는 Claude Code로 뉴스 스크래퍼를 만들었어요. CLI(Command Line Interface) 방식의 도구였는데요, CLI란 우리가 흔히 보는 버튼이나 아이콘 대신 텍스트 명령어로 컴퓨터를 조작하는 방식이에요. 윈도우의 검은 창(명령 프롬프트)이나 맥의 터미널 같은 거죠.
매일 아침 터미널을 열고 python onda_news_scraper.py라고 명령어를 치면, 제가 원하는 뉴스만 쏙쏙 골라서 이메일로 보내주는 도구였죠. PR 담당자로서 매일 30분씩 뉴스 검색하던 시간을 10분으로 줄여준 고마운 녀석이에요. 사실 아래 내용은 이전 글을 안보셨거나, 바이브 코딩에 대한 감이 없으면 조금 어려울 수 있거든요. 가능한 스스로 바이브코딩 환경 세팅을 안해보셨거나, 잘 모르시겠다면 이전 글을 읽어보시길 권해요^^
암튼 근데 어느 날 문득 이런 생각이 들었어요.
"이거... 나만 쓰기 아깝지 않아?"
문제는 CLI 도구는 나만 쓸 수 있다는 거예요. 다른 사람이 쓰려면 Python을 설치하고, 터미널 여는 법을 배우고, 명령어를 외워야 해요. 개발자가 아닌 이상 진입장벽이 너무 높죠. PR 담당자, 마케터, 투자자... 뉴스 스크랩에 시간 쓰는 사람들이 얼마나 많은데요. 저처럼 매일 아침 구글 뉴스, 네이버 뉴스 돌아다니면서 기사 찾는 분들 많잖아요.
그래서 웹 서비스로 만들기로 했어요. 웹 서비스는 브라우저에서 주소만 치면 누구나 쓸 수 있으니까요. 네이버, 구글처럼요. Claude에게 물었습니다.
👤 나: "자 이걸 기반으로 다른 사람들도 쓸 수 있는 프로그램을 만들고 싶은데 다른 폴더에 새로운 프로젝트를 시작해 볼까?"
🤖 Claude: "좋은 생각이에요! 다른 사람들도 쉽게 자신만의 뉴스 스크래퍼를 만들 수 있는 범용 프로젝트를 시작해볼까요?"
이렇게 시작된 여정. 이번 글에서는 CLI 도구를 웹 서비스로 진화시키는 과정을 따라가 볼게요. 코딩 한 줄 모르는 제가 어떻게 로그인, 회원가입, 대시보드까지 만들었는지 — 그리고 그 과정에서 실제로 어떤 기술들이 돌아가고 있었는지 함께 알아봅시다.
솔직히 말하면, 저도 "프론트엔드", "백엔드", "API" 이런 말 들으면 머리가 아팠어요. 근데 바이브 코딩의 좋은 점은 다 몰라도 일단 만들 수 있다는 거예요. 물론 기본 개념을 알면 훨씬 수월하고요. 그래서 이 글에서는 [작업기] 로 실제 대화를, [바이브 이면의 기술] 로 그 뒤에서 뭐가 돌아가는지 설명해드릴게요.
처음에는 그냥 "뉴스 스크래퍼 웹사이트 만들어줘"라고 할까 했어요. 근데 이전 경험상, AI에게 막연하게 요청하면 결과물도 막연해지더라고요. "웹사이트 만들어줘"라고 하면 "어떤 웹사이트요? 기능은요? 디자인은요?" 이렇게 되물어보거든요. 그래서 기획부터 제대로 하기로 했습니다.
👤 나: "음 ㅇㅋ 일단 엔진이 돌아가는 걸 확인했으니. 제품 기획을 좀 더 명확히 해야 할거 같아. 기획서를 같이 작성해 볼까?"
🤖 Claude: "좋아요! 기획서를 같이 작성해 봅시다. 몇 가지 방향을 먼저 정리하면 좋을 것 같아요. 핵심 질문들 — 타겟 사용자는? 핵심 가치는? 수익 모델은? 차별점은? MVP 범위는?"
Claude가 질문을 던져주니까 머릿속에 흩어져 있던 생각들이 정리되기 시작했어요. 이게 바이브 코딩의 장점이에요. AI가 적절한 질문을 던져주면서 생각을 구조화해줘요.
👤 나: "뭐 마케터, 경영진, 투자자 모두지 뭐. 핵심가치는 정말 디테일하게 원하는 기사만 보게 하고 싶어. 수익모델은 그냥 무료로 배포하려고. 차별점은 개인화가 진짜 잘됐으면 좋겠어."
기존에 시중의 뉴스 클리핑 서비스들을 써봤는데, 무료 버전은 키워드 5개밖에 못 넣고, 원하는 기사가 잘 안 나오더라고요. "삼성전자"를 키워드로 넣으면 삼성전자 주식 이야기, 삼성전자 부고 기사, 삼성전자 광고 기사까지 다 나와요. 제가 원하는 건 "삼성전자의 B2B SaaS 사업 동향"인데 말이죠.
그래서 확실한 차별점을 잡았습니다:
👤 나: "일단 그렇게 하고 타 서비스는 무료 버전에서 키워드 등록이 한정적이니까 우리는 그걸 좀 풀고 한 30개까지 등록되게, 그리고 내가 원하는 기사를 스크랩할 수 있는 튜토리얼 과정을 세밀하게 세팅하게 해서 원하는 기사가 잘 나왔으면 좋겠어"
Claude는 이 내용을 바탕으로 PRD(Product Requirements Document) 문서를 만들어줬어요. 타겟 사용자, 핵심 기능, 화면 구성, 데이터 구조까지 정리된 20페이지짜리 기획서가 뚝딱 나왔습니다.
PRD(Product Requirements Document) 는 '제품 요구사항 문서'예요. 쉽게 말해 "우리가 뭘 만들 건지 정리한 기획서" 죠. 스타트업이나 IT 회사에서 새 제품 만들 때 항상 이걸 먼저 써요.
왜 AI한테도 기획서가 필요할까요? AI는 맥락을 이해하고 일관성 있게 작업하려면 명확한 가이드라인이 필요하거든요. 사람도 마찬가지잖아요. "그냥 좋은 거 만들어줘"라고 하면 뭘 만들어야 할지 모르는 것처럼요.
PRD가 있으면:
우리 PRD에는 이런 내용들이 담겼어요:
팁: 바이브 코딩할 때 처음부터 PRD를 완벽하게 쓸 필요 없어요. Claude와 대화하면서 점점 구체화하면 됩니다. 저도 "챗봇 넣을까?" 같은 아이디어는 대화 중에 추가했거든요. PRD는 살아있는 문서예요.
기획서가 나왔으니 이제 만들어야죠. 근데 여기서 첫 번째 난관이 왔어요.
🤖 Claude: "백엔드는 어떻게 하실 건가요? FastAPI로 직접 만들까요, 아니면 BaaS를 사용할까요?"
백엔드? BaaS? FastAPI? 뭔 소리야... 😱
솔직히 이 시점에서 "아 역시 개발은 개발자가 해야 하나"라는 생각이 살짝 들었어요. 근데 다행히 저는 우리 회사(Popup Studio)에서 만든 bkend.ai가 있었어요. 동료들이 "백엔드 직접 안 짜도 되는 서비스"라고 소개해줬거든요.
👤 나: "어디까지나 난 개발을 잘모르는 왕초보야. 근데 우리 동료들이 백엔드로 https://www.bkend.ai/를 사용하라고 추천해줬어. 이걸 감안해서 작업해줘."
🤖 Claude: "이해했습니다! ,다양한 회사 PR 담당자들을 위한 범용 서비스의 백엔드는 bkend.ai를 사용하겠습니다."
웹 서비스는 크게 프론트엔드와 백엔드로 나뉘어요. 이 개념을 이해하면 바이브 코딩할 때 훨씬 수월해요.
비유하자면 레스토랑이에요:
손님(사용자)은 예쁜 홀(화면)만 보지만, 실제 음식(데이터)은 주방(서버)에서 만들어져요. 손님이 "스테이크 주세요"라고 하면(버튼 클릭), 웨이터가 주방에 전달하고(API 호출), 주방에서 요리해서(데이터 처리) 내놓는 거죠(응답).
백엔드가 하는 일을 구체적으로 보면:
**BaaS(Backend as a Service)**는 이 백엔드를 직접 만들지 않고, 서비스로 제공받는 것이에요. 마치 집에서 요리 안 하고 배달 시켜먹는 것처럼요. Firebase, Supabase, 그리고 bkend.ai 같은 서비스들이 대표적이죠.
직접 서버 만들기 vs BaaS 비교:
| 구분 | 직접 만들기 | BaaS 사용 |
|---|---|---|
| 난이도 | 어려움 (서버 구축, DB 설정, 배포, 보안 다 해야 함) | 쉬움 (클릭 몇 번이면 끝) |
| 시간 | 몇 주~몇 달 | 몇 시간~며칠 |
| 비용 | 서버비 발생 (AWS, GCP 등) | 무료~저렴 (소규모는 대부분 무료) |
| 유연성 | 높음 (원하는 대로 커스텀 가능) | 제한적 (서비스가 제공하는 범위 내에서) |
| 추천 대상 | 개발자, 복잡한 서비스 | 바이브 코더, MVP, 빠른 검증 👈 |
저처럼 백엔드를 모르는 사람에게 BaaS는 구세주예요. "회원 테이블 만들어줘", "로그인 API 써도 돼?" 이런 고민 없이 그냥 쓰면 되니까요.
bkend.ai에 가입하고 프로젝트를 만들었어요. 콘솔 화면이 뜨는데, 뭘 해야 할지 모르겠더라고요. 그래서 Claude에게 물었죠.
🤖 Claude: "PRD에 정의된 4개의 Collection을 만들어야 합니다: users, profiles, scrape_results, briefings"
Collection? 아, 테이블이구나. 엑셀 시트 같은 거.
👤 나: "profiles 만들거야" 👤 나: "scrape_results 만들거야" 👤 나: "briefings 만들어볼까?"
하나씩 테이블을 만들었어요. bkend.ai 콘솔에서 테이블 이름 입력하고, 필드 추가하면 끝. 생각보다 간단했어요. 근데 나중에 알아보니 bkend.ai는 클로드 mcp를 지원해서 제가 일일이 만들 필요 없이 그냥 클로드에게 시키면 되는 일이더군요.
MCP(Model Context Protocol) 는 AI가 외부 서비스와 직접 연결되는 프로토콜이에요. 원래 Claude는 인터넷에 직접 접속을 못 해요. 근데 MCP를 설정하면 특정 서비스(bkend.ai, Jira, Slack 등)에 접속할 수 있는 "열쇠"를 주는 거예요. 덕분에 Claude가 "테이블 목록 보여줘"라고 하면 진짜로 bkend.ai에서 데이터를 가져올 수 있는 거죠.
그런데 API 테스트에서 문제가 생겼어요. Claude가 bkend.ai에 데이터를 넣어보려고 했는데 계속 에러가 나는 거예요.
🤖 Claude: "API 테스트해봅시다. curl로 users 테이블 조회를 먼저 해볼게요." 🤖 Claude: "네트워크 문제가 있네요. bkend.ai API 엔드포인트 형식이 다를 수 있습니다."
이런저런 시도 끝에 MCP(Model Context Protocol) 연동을 하기로 했어요. MCP는 AI가 외부 서비스와 직접 연결되는 프로토콜인데, 이걸 설정하면 Claude가 직접 bkend.ai 데이터베이스를 조회하고 수정할 수 있어요.
👤 나: "mcp 설정하는 법이 나와 있네. 아래 내용을 따라 줄래?"
json{ "mcpServers": { "mcp-bkend": { "type": "http", "url": "https://api.bkend.ai/mcp", "headers": { "X-Organization-Id": "여기에_Organization_ID_붙여넣기", "X-Api-Key": "여기에_API_키_붙여넣기" } } } }
MCP 설정 후 Claude Code를 재시작하니까, Claude가 직접 bkend.ai 데이터베이스를 조회할 수 있게 됐어요! 마치 Claude한테 bkend.ai 열쇠를 준 것 같았어요.
🤖 Claude: "bkend.ai 연동이 성공적으로 완료되었습니다! 모든 테이블이 정상적으로 배포되어 있습니다."
| 테이블명 | 상태 |
|---|---|
| users | ✅ deployed |
| profiles | ✅ deployed |
| scrape_results | ✅ deployed |
| briefings | ✅ deployed |
드디어 백엔드 준비 완료! 🎉
테이블은 엑셀 시트라고 생각하면 쉬워요.
users 테이블 = 회원 명단 시트 (이메일, 이름, 가입일...)profiles 테이블 = 뉴스 설정 시트 (키워드, 회사명, 경쟁사...)scrape_results 테이블 = 스크랩 결과 시트 (기사 제목, 점수, 날짜...)briefings 테이블 = 발송 기록 시트 (보낸 날짜, 받는 사람...)각 테이블에는 **필드(컬럼)**가 있어요. 엑셀의 열(A, B, C...)과 같은 개념이죠.
API(Application Programming Interface) 는 프론트엔드와 백엔드가 대화하는 방법이에요. 좀 더 쉽게 비유하자면 식당 주문서예요:
예를 들어 회원가입할 때 이런 일이 일어나요:
프론트엔드 → "이메일: test@test.com, 비번: 1234로 가입해줘" (API 요청) 백엔드 → 비밀번호 암호화, DB에 저장 → "오케이, 가입 완료!" (API 응답)
여기까지 기획 → 백엔드 설정을 마쳤어요.
다음 편에서는:
까지 다뤄볼게요. "로그인 화면 만들어줘" 한마디에 진짜 로그인이 되는 과정, 그리고 그 과정에서 터진 에러들을 어떻게 해결했는지 공유할게요! (스포일러: AI도 문서가 틀리면 틀린 코드를 짜요 😅)
(이게 뭔 말이다냐...)
💬 질문이나 의견은 댓글로 남겨주세요!
댓글을 작성하려면 로그인이 필요합니다.