웹서비스가 결국 뭔지 알게 됐다 — 백엔드를 질문으로 정복하고, 하루 만에 설계도를 그리다

📚 「AI 헬스케어 파이널 프로젝트」 연재 6편입니다. (5편: 데이터는 모았다고 끝이 아니었다)

📝 한줄 요약

기획도 데이터도 준비됐으니, 이제 ‘어떻게 만들지’를 그릴 차례였습니다. 그런데 저는 백엔드(사용자 눈에 안 보이는 서버 쪽) 구조가 뭔지조차 헷갈렸어요. 그래서 “이건 뭐고 왜 필요해?”를 하나씩 물어 백엔드를 본질부터 이해했고, 그 위에서 요구사항 하나로 데이터 구조·통신 명세·화면 설계 25개를 하루 만에 그렸습니다. 그리고 팀에서 RAG 챗봇 담당이 되며 이 연재의 다음 막으로 넘어갑니다.

바쁘시면 이것만 읽어도 돼요:

깨달은 점: “웹서비스란 결국 데이터를 주고받고·저장하고·꺼내 쓰는 것”이라는 한 줄로 백엔드 구조가 정리됐어요
방법: 라우터·서비스·레포지토리·모델 같은 낯선 부품을 “이건 뭐고 왜 필요해?”로 하나씩 물어 정복
속도: 요구사항이 단단하니, 그걸 바탕으로 데이터 구조·통신 명세·화면 25개가 하루 만에 줄줄이 나옴
추적성: 화면마다 요구사항 번호를 박아 “이 화면이 어느 요구에서 왔는지” 한눈에 거슬러 올라가게 함
전환점: 팀 역할 분담에서 RAG 챗봇 담당 확정 → 다음 편부터 본격 구축

🎯 이런 분들께 도움돼요

백엔드·서버 구조가 용어부터 막막한 비개발·입문자
요구사항은 있는데 데이터 구조·통신 명세·화면 설계로 어떻게 넘어가는지 모르는 분
기획에서 설계로 넘어가는 다리가 필요한 PM·기획자

😫 문제 상황 (Before)

5편까지 기획(무엇을·누구에게)과 데이터(재료)가 준비됐습니다. 이제 “그래서 이걸 어떻게 만들지”를 설계할 차례였어요. 그런데 가이드 문서엔 라우터, 서비스, 레포지토리, 모델, DTO… 처음 보는 단어가 가득했습니다.

백엔드가 어떤 부품으로 이뤄지고, 각자 무슨 일을 하는지 몰랐어요.
요구사항에서 데이터 구조·통신 명세·화면 설계로 어떻게 넘어가는지도 막막했고요.

여기서도 전략은 똑같았습니다. 3편에서 RAG를 그렇게 배웠듯이, 모르면 그림을 외우지 말고 “이건 뭐고 왜 필요해?”부터 묻자는 것.

🛠️ 사용한 도구

도구: Claude Code + Pencil(화면 설계 도구)
모델: Claude Opus
특이사항: 백엔드 구조를 눈높이로 풀어주는 과외 선생님이자, 요구사항을 데이터 구조·통신 명세·화면으로 옮겨주는 설계 보조로 썼습니다.

🔧 작업 과정

1) 백엔드 부품을 “이건 뭐야?”로 하나씩 정복

먼저 백엔드 폴더 구조를 보며, 모르는 걸 그대로 물었습니다.

라우터의 기능은 서비스를 호출하는 거야?
비즈니스 로직이란? 서비스?
레포지토리가 서비스와 모델을 연결하는 중계 역할이라고 보면 되나?
app/models/ 의 역할은? 왜 폴더명이 모델이지?
DTO?? Pydantic Schema??

AI가 부품 하나하나의 역할을 눈높이로 풀어줬어요. 라우터(문 앞 안내)·서비스(실제 일 처리)·레포지토리(창고 담당)·모델(데이터 설계도)처럼요. 그리고 이걸 그때그때 폴더 구조 가이드 문서에 정리해서, 팀원도 같이 볼 수 있게 했습니다.

💡 낯선 구조는 통째로 외우지 말고, 부품마다 “이건 뭐고 왜 필요해?”를 물어보세요. 하나씩 풀리면 전체가 흐름으로 보입니다.

2) 한 줄로 정리된 본질 — “웹서비스란 결국…”

부품을 다 이해하고 나서, 핵심을 한 번에 물었습니다.

그럼 결국 웹서비스, 기능이라는 것은 데이터를 주고받고 저장하고 호출하는 것인가?

이 질문에 대한 답이 그동안의 안갯속을 걷어냈어요. 복잡해 보이던 폴더가 **“데이터가 흐르는 길의 각 정거장”**으로 정리됐습니다. 한 기능을 만드는 표준 순서(데이터 약속 → DB 구조 → 저장·조회 → 로직 → 화면 연결 → 점검)까지 손에 잡혔고요. 3편에서 RAG를 본질로 환원했던 것과 똑같은 방식이죠. 모르는 건 늘 본질부터.

💡 웹서비스 = 데이터를 주고받고(통신) · 저장하고(DB) · 꺼내 쓰는(서비스) 흐름. 본질 한 줄을 잡으면 나머지가 따라옵니다.

3) 요구사항 하나로 설계도가 줄줄이 — 데이터 구조·통신 명세·화면 25개

백엔드 구조가 이해되니 설계가 빨랐습니다. 완성된 요구사항(v0.7)을 주고 차례로 부탁했어요.

요구사항 정의서 v0.7을 참고해서 ERD(데이터 구조)를 만들 코드를 작성해줘
이어서 API 명세서도 작성해줘
이어서 와이어프레임(화면 설계)을 만들려고 하는데 pencil 앱 알아?

그러자 설계 산출물이 연쇄적으로 쏟아졌습니다.

데이터 구조(ERD) 35개 테이블 — 붙여넣으면 바로 그림이 되는 코드로
통신 명세(API) 51개 — 개발자용 문서 + 검토자용 엑셀, 두 형태로
화면 설계(와이어프레임) 25개 — 게임화 대시보드부터 챌린지·챗봇 화면까지

가장 좋았던 건 추적성이에요. 각 화면 위에 요구사항 번호를 박아서, “이 화면이 어느 요구사항에서 나왔는지” 한눈에 거슬러 올라가게 했습니다. 혼자였으면 며칠 걸렸을 설계가, 요구사항이 단단한 덕에 하루 만에 끝났어요.

💡 앞 단계(요구사항)가 단단하면, 설계는 AI가 하루 만에 줄줄이 뽑아줍니다. 공은 늘 앞 단계에 들이세요.

4) 전환점 — RAG 챗봇 담당이 되다

설계가 마무리될 즈음, 팀 역할이 정해졌습니다.

이제 나는 팀 역할분담에서 RAG 구축을 담당하게 되었어
Phase 0부터 시작할 건데, 우선 세션 정리하고 새로운 세션에서 시작하자

3편에서 본질을 공부해둔 바로 그 RAG 챗봇(자료를 찾아 근거로 답하는 방식)이 제 담당이 된 거예요. 곧바로 학습 로드맵(Phase 0~6)을 짜고, 다음 작업(Phase 0 학습카드)을 예약했습니다. 그리고 앞으로의 작업 규칙도 못 박았어요. 코드는 개발용 폴더에, 문서·기록은 프로젝트 폴더에. 이 규칙이 이후 내내 작업을 깔끔하게 지켜줍니다.

💡 공부해둔 게 결국 내 일이 됩니다. 호기심으로 미리 본질을 파둔 3편이 6편에서 역할로 돌아왔어요.

✅ 결과 (After)

Before vs After

항목	Before	After
백엔드 이해	라우터·서비스가 뭔지 모름	”데이터 흐름의 정거장”으로 구조 이해
설계 산출물	없음	데이터 구조 35테이블 + 통신 명세 51개 + 화면 25개
추적성	—	화면 ↔ 요구사항 번호 1:1 매핑
내 역할	미정	RAG 챗봇 담당 + Phase 0~6 로드맵

결과물

폴더 구조 가이드 — 백엔드 각 부품의 역할 + 개발 순서
데이터 구조 35테이블 / 통신 명세 51개 / 화면 25개 (하루 산출)
RAG 담당 확정 + 로드맵 + 작업 경로 규칙

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

낯선 구조는 “이건 뭐고 왜 필요해?”로 정복하라 — 부품을 하나씩 물으면, 전체 구조가 흐름으로 보입니다.
본질 한 줄을 찾아라 — “웹서비스 = 데이터를 주고받고·저장하고·꺼내 쓰는 것”처럼 한 문장으로 정리되면 나머지가 따라옵니다.
요구사항이 단단하면 설계는 빠르다 — 잘 정리된 요구사항을 주면 데이터 구조·통신 명세·화면이 연쇄적으로 나옵니다.
산출물에 추적 번호를 박아라 — 화면·통신 명세에 요구사항 번호를 매기면, 나중에 “이게 왜 있지?”를 즉시 추적할 수 있습니다.

이렇게 하면 안 돼요

용어를 모른다고 그냥 넘어가지 마세요 — 라우터·DTO 같은 단어를 모른 채 진행하면, 설계가 사상누각이 됩니다. 물어보세요.
설계 산출물의 ‘형식’만 베끼지 마세요 — 데이터 구조·통신 명세는 예쁜 양식이 아니라 요구사항과 연결돼야 의미가 있습니다.

🌍 다른 업무에 적용한다면?

낯선 시스템·업무 파악: “이 부품은 뭐고 왜 필요해?”를 반복하면, 어떤 복잡한 구조도 흐름으로 이해됩니다.
기획 → 산출물 전환: 잘 정리된 기획서가 있으면, AI로 명세·구조·화면 초안을 하루 만에 만들 수 있어요. 핵심은 앞 단계(요구사항)의 완성도입니다.

🚀 앞으로의 계획

여기까지가 ‘프로젝트 준비’ 구간입니다. 데이터 수집 → 데이터 검증 → 라벨 누수와 CKD 피벗 → 게임화·RAG 학습 → 데이터 재빌드 → 백엔드 이해와 설계, 그리고 RAG 담당까지 왔어요.

다음 편부터는 드디어 그 RAG 챗봇을 직접 만들기 시작합니다. 검증된 의료 가이드라인만 근거로 답하는 “환각 없는” 챗봇을요. 그런데 첫날부터 반전을 마주합니다. AI가 의료 질문을 거절했는데, 알고 보니 그게 정답이었다 — 만성콩팥병 RAG를 만든 날 이야기로 이어집니다.

📋 재사용 가능한 프롬프트

프롬프트 1: 낯선 시스템 구조를 질문으로 이해하기

나는 [이 시스템/구조]가 처음이라 용어부터 막막해. [구성 요소]가 각각 무슨 일을 하고 왜 필요한지 일상 비유로 하나씩 설명해줘. 마지막에, 이 시스템이 결국 무엇을 하는 것인지 한 문장 본질로 정리하고, 전체가 어떤 흐름으로 동작하는지 순서대로 보여줘.

프롬프트 2: 요구사항 기반 설계 산출물 일괄 생성

이 요구사항 정의서를 바탕으로 설계 산출물을 만들어줘. ① 데이터 구조를 [도구]용 코드로 ② 통신 명세서를 ③ 화면 설계 목록을. 각 산출물은 **요구사항 항목과 1:1로 연결(번호 매핑)**되게 하고, 빠진 요구가 없는지 점검해줘.

프롬프트 3: 산출물 추적성 부여

만든 [화면/명세/기능]마다 대응되는 요구사항 번호를 표시해줘. 그리고 “어떤 요구사항이 어떤 산출물로 구현됐는지” 한눈에 보는 매핑 표를 만들어, 누락되거나 근거 없는 산출물이 없는지 확인할 수 있게 해줘.

📌 「AI 헬스케어 파이널 프로젝트」 연재 6편입니다. 다음 막에서 또 이어집니다.