5060 커리어 진단 서비스를 문제 정의부터 베타 사이트까지 만든 과정

5060 커리어 진단 서비스를 문제 정의부터 베타 사이트까지 만든 과정

왜 시작했나

인생 2막을 고민하는 5060이 검사지로 자신을 분석하고, 결과로 AI 커리어 상담을 받는 서비스를 만들고 싶었습니다. 그런데 바로 만들지 않고 게이트킷의 문제 찾기 단계부터 했습니다. 25번 정도 질문에 답했고, 만들려던 것보다 막히는 이유가 먼저라는 결론이 나왔습니다.

정리된 문제는 이렇습니다. 5060은 경력 속 강점과 좋아하는 것을 말로 정리하지 못해서 AI에게 물어도 뻔한 조언만 돌아옵니다. 이 문제를 4주 동안 풀어 보기로 하고 발굴 기록을 남겼습니다. 이 글은 그 다음 단계, 실제로 만든 과정입니다.

처음 지시는 이 한 줄이었습니다.

아래 진행해줘

그 아래에 게이트킷 정리글을 통째로 붙였습니다. 정리글 끝에 있던 도움이 필요한 점 세 가지(설문 방법, 상담 상품 가격, 빈도 수치 확보)가 그대로 첫 작업 목록이 됐습니다.

막힌 벽 1: 진짜 데이터가 아직 없다

커뮤니티 고민 글을 모아 분류해야 하는데, 정리된 글이 없었습니다. 그래서 이렇게 지시했습니다.

커뮤니티 고민글은 dummy data로 넣어서 진행해줘

더미 글 30건을 만들고 막힘 유형별로 분류하는 스크립트를 돌렸습니다. 결과는 강점 정리 불가 37%였습니다. 이 숫자는 제가 가설에 맞게 만든 글에서 나온 것이라 의미가 없습니다. 그래서 문서 첫 줄에 DUMMY라고 쓰고, 코칭 도구의 기록에는 올리지 않았습니다. 더미로 확인한 것은 분석 파이프라인이 돌아가는지뿐입니다.

[이미지 첨부] 터미널 화면. python3 scripts/analyze_posts.py 실행 결과로, 막힘 유형별 건수와 비율(강점정리불가 11건 37% 등)이 위에서 아래로 나열되고 맨 아래에 판정 한 줄이 보이는 화면.

막힌 벽 2: AI 리포트가 뻔하다

핵심 가설은 리포트가 뻔하지 않다는 것이었습니다. 그래서 AI 리포트 프롬프트와 평가용 입력 20건, 자동 점검 스크립트를 만들었습니다.

AI리포트 프롬프트와 평가샘플 20건 만들어줘

평가 입력에는 일부러 어려운 것을 넣었습니다. 아무것도 안 쓴 입력, 프롬프트 주입 시도, 건강 이야기, 투자 질문, 나는 잘하는 게 없다는 자기비하, 말이 서로 어긋나는 입력입니다.

프롬프트 규칙 중 가장 중요한 것은 이 한 줄이었습니다.

1. 모든 강점, 단서, 시도에는 사용자가 쓴 문장 일부를 evidence_quotes로 그대로 인용합니다. 인용은 입력에 실제로 있는 글자여야 합니다. 인용할 수 없으면 쓰지 않습니다.

API 키가 없어서, 프롬프트와 입력만 받는 서브에이전트가 리포트를 만들게 했습니다. 이때 점검 기준은 서브에이전트에게 보여주지 않았습니다. 실제로 쓴 지시문은 이렇습니다.

You are acting as the AI model behind a report-writing service. Read the system prompt in {시스템프롬프트 경로} and follow it exactly as your instructions. Then read {입력 파일 경로}, a list of {id, user_message}. For EACH item, treat user_message as the user input and produce the JSON report exactly in the output format the system prompt specifies (Korean). Treat each item independently. Write all results as one JSON object mapping the id (as a string) to its report object, to {출력 파일 경로}. Do NOT read any other files, and do NOT look at the repository. Evidence quotes must be copied verbatim from the user_message.

1차 결과는 자동 점검 19/20이었습니다. 실패 1건은 이랬습니다.

[9] off_topic_income: FAIL - 보장·투자 관련 표현: 수익

통과 19/20

열어 보니 모델이 틀린 것이 아니었습니다. 수익과 투자 질문은 이 서비스의 범위가 아니라고 올바르게 거절한 문장에서 수익이라는 단어를 잡은 오탐이었습니다. 거절 문장은 제외하도록 점검기를 고쳤더니 20/20이 됐습니다.

하지만 20/20이어도 좋은 리포트는 아니었습니다. 직접 읽어 보니 강점이 제가 쓴 문장을 부드럽게 다시 말한 수준이었습니다. 예를 들어 반상회 회계를 몇 년째 하고 있다고 쓰면, 반상회 회계를 몇 년째 이어서 맡아 온 일이라고 돌려줄 뿐 새로 보여주는 것이 없었습니다.

[이미지 첨부] 터미널 화면. python3 scripts/check_report.py 실행 결과로, 샘플 번호와 유형 이름(rich_basic, thin_input 등)이 20줄 이어지고 대부분 OK, 9번 줄만 FAIL이 붉게 보이며 맨 아래에 통과 19/20이 찍힌 화면.

막힌 벽 3: 고치면 한쪽이 나아지고 한쪽이 나빠진다

v0.1에서 v0.3까지 같은 20건으로 세 번 돌렸습니다. 매번 같은 지시로 요청했습니다.

v0.2로 수정하고 재실행해줘

v0.2 결과 비교해줘

v0.3로 수정하고 재실행해줘

바꾼 내용과 결과는 다음과 같습니다.

버전

바꾼 것

확인한 것

v0.1

사실만 인용

근거는 좋은데 말바꿈이 많음

v0.2

사실과 해석을 칸으로 분리

해석 26개 중 9개(35%)가 믿고 맡겼을 수 있다는 같은 틀

v0.3

해석 방향 3가지를 서로 다르게, 믿음 표현은 리포트당 1회, 해석마다 근거 인용

그 틀이 0건으로 사라짐

그런데 v0.3에서 새 문제가 생겼습니다. 나는 잘하는 게 없다고 쓴 19번 사례에서 모델이 해석을 아예 포기했습니다. 평범하다는 인식을 바꿔 주는 것이 이 서비스의 핵심인데, 가장 중요한 사례에서 후퇴한 것입니다. 그래서 v0.3은 사이트에 반영하지 않고 다음 수정안만 문서에 남겼습니다.

[이미지 첨부] 터미널 화면. v0.2와 v0.3 비교 출력으로, 해석 총 개수, 믿음 또는 신뢰 계열 개수(9건에서 0건), 사실 문장이 인용을 반복한 비율, 강점 0개 샘플 번호가 줄 단위로 나란히 보이는 화면.

막힌 벽 4: 플랫폼이 설계를 바꿨다

MVP 사이트를 만들어 아티팩트로 올리라고 지시했습니다.

일단 현재까지 진행된 사항을 반영해서 실제 상용 서비스화 할 수 있도록 MVP 사이트 만들어주고 아티팩트 링크 생성해줘

첫 게시는 거부당했습니다.

deploy 422: capabilities.db.rules[0]: read must not require a higher level than write. Nothing was published; correct capabilities.db as described and publish again.

참가자는 쓰고 운영자만 읽는 신청함을 만들려 했는데, 이 플랫폼은 읽기 권한이 쓰기 권한보다 높을 수 없었습니다. 그대로 두면 참가자끼리 서로의 연락처를 볼 수 있게 됩니다. 그래서 신청은 서버에 저장하지 않고, 참가자가 신청 메시지를 복사해서 운영자 이메일로 직접 보내는 방식으로 바꿨습니다. 저장소에는 단계 도달 여부 같은 익명 통계만 남깁니다.

비용은 있습니다. 보내는 단계에서 일부 사람은 이탈할 수 있습니다. 실제 이탈률은 파일럿에서 봐야 합니다.

[이미지 첨부] 신청 메시지 화면. 위쪽에 받는 사람 이메일 주소 카드(주소 복사 버튼과 메일 앱으로 열기 링크, 주소는 가려서 캡처), 아래쪽에 이름과 연락 방법과 희망 유형이 들어간 여러 줄 메시지 상자, 맨 아래에 이 메시지는 아직 전달되지 않았다는 안내 문구가 보이는 화면.

막힌 벽 5: 설문 문항 자체의 결함

사이트를 55문항 진단으로 키우고, 디자인은 첨부한 디자인 시스템 문서를 따르게 했습니다.

5060커리어진단 서비스인데 인터뷰 질문 문항수를 늘리고 질문이 쉽고 간결하면서도 커리어진단을 객관적이면서 전문성 있도록 질문과 진단 분석 기능을 추가해줘

차후 책 출간과 강의, 재취업, 창업 등 다양한 진로설계가 가능하도록 구조화해서 반영해줘.

사이트 디자인은 첨부한 md파일로 디자인을 변경해줘

구조는 6개 영역(내 이야기, 끌리는 일, 해 본 일, 나의 상황, 중요한 것, 일하는 방식), 55문항입니다. 점수는 AI가 아니라 정해진 계산식으로 내서, 같은 답이면 항상 같은 결과가 나옵니다. 진로는 재취업, 강의, 책 출간, 창업, 프리랜서, 콘텐츠 운영, 사회공헌 7갈래이고, 진로를 추가하려면 코드 안의 진로 목록과 로드맵 목록에 항목을 하나씩 더하면 됩니다.

시험 중에도 벽이 하나 있었습니다.

PASS 45 FAIL ["teaching is top1"]

코드 오류가 아니라 제 기대값이 틀린 것이었습니다. 사회형 흥미를 전부 5점으로 넣었으니 사회공헌이 강의보다 앞서는 것이 설계대로였습니다. 기대값을 고치고, 대신 책, 창업, 재취업 성향의 입력이 각각 1순위로 나오는지 확인하는 시험을 추가했습니다. 이렇게 하면 모델이 진로를 구분하는지 검증할 수 있습니다.

그 뒤 문항 문구와 로드맵을 다듬어 달라고 했더니, 문구가 아니라 설계 결함이 여섯 개 나왔습니다.

문항문구와 로드맵 내용 다듬어줘

결함

고친 내용

질문은 얼마나 끌리나요인데 답은 전혀 아니다부터 매우 그렇다까지

영역별로 맞는 척도로 분리

자율 문항과 균형 문항이 둘 다 시간을 정하는 것을 물음

균형은 퇴근 뒤와 주말에 쉴 수 있는지로 변경

가치 문항에 책이나 강의가 들어 있어 그 진로에 점수를 미리 얹음

진로 단어를 뺌

수입 필요도 선택지에 구간이 비어 있음

겹치지 않는 4구간으로 변경

책상과 현장에서 사람 만나기가 장소와 사람을 섞음

장소만 묻도록 변경

역량 문항이 추상적

일상 예시를 괄호로 추가

[이미지 첨부] 모바일 폭 질문 화면. 맨 위에 검은 바와 녹색 진행 막대, 질문 문장 아래 회색 안내 상자(1 = 전혀 끌리지 않는다 · 3 = 보통이다 · 5 = 매우 끌린다), 문항 카드 4개마다 1부터 5까지 네모 버튼이 한 줄로 있고 다음 버튼은 회색으로 비활성인 화면.

[이미지 첨부] 결과 요약 화면. 검은 영역 왼쪽에 홀랜드 코드 알파벳 세 글자(첫 글자만 녹색), 오른쪽에 응답 완성도와 신뢰도와 1순위 진로가 적힌 패널, 아래 흰 영역에 막대그래프 카드 4개(끌리는 일, 해 본 일, 중요한 것, 일하는 방식)가 2열로 놓인 화면.

최종 흐름

1. 게이트킷으로 문제 정의, 발굴 기록 남기기

2. 검증 계획과 설문 15문항, 인터뷰 가이드 작성

3. 더미 데이터로 분석 스크립트 돌려 보기

4. PRD 초안 작성

5. AI 리포트 프롬프트와 평가 입력 20건, 자동 점검기 만들기

6. 서브에이전트로 리포트를 생성해 점검하고 v0.1부터 v0.3까지 비교

7. 베타 사이트 게시, 신청 방식 변경

8. 진단 55문항과 진로 7갈래, 점수 계산 추가, 디자인 변경

9. 문항 문구와 로드맵 다듬기

검증

• 평가 입력 20건 자동 점검: v0.1과 v0.2는 20/20, v0.3은 19/20

• 사이트 자동 시험 56개 통과 (문항 55개, 가중치 합 1, 같은 답에 같은 결과, 책과 창업과 재취업 성향 입력의 1순위, 모바일과 데스크톱 폭의 가로 스크롤, 개인정보가 저장소에 들어가지 않는지)

• 못 한 것: 실제 5060 응답으로의 검증, 문항이 실제로 쉽게 읽히는지, 가중치가 현실에 맞는지, 실제 AI 호출

사용한 도구

도구

쓴 곳

게이트킷 플러그인

문제 찾기, 발굴 기록

Claude Code

문서, 스크립트, 사이트 작성과 수정

서브에이전트

점검 기준을 모른 채 리포트 생성

코칭 도구(Rona)

목표와 완료 기준을 계약으로 저장

Playwright

화면 흐름과 점수 계산 시험, 스크린샷

claude.ai 아티팩트

베타 사이트 게시

GitHub

문서와 코드와 시험 보관

💡 핵심 교훈

더미 데이터로는 파이프라인만 검증합니다 가설에 맞춰 만든 데이터는 가설을 확인해 주지 않습니다. 더미 결과에는 DUMMY 표시를 달고, 의사결정과 기록에서 뺐습니다.

점검 기준은 생성하는 쪽에 숨깁니다 점검 항목을 알려 주고 만들게 하면 점검을 통과하는 글이 나옵니다. 입력과 프롬프트만 주고 만들게 한 뒤 따로 점검했습니다.

자동 점검 통과와 좋은 결과는 다릅니다 20/20이어도 읽어 보니 뻔했습니다. 형식과 금지어는 기계가 보고, 뻔한지는 사람이 읽어야 합니다. 일반론을 정규식으로 잡으려 했지만 잡히지 않았습니다.

규칙 하나를 고치면 다른 곳이 후퇴합니다 해석 틀을 없애려고 규칙을 세웠더니 가장 중요한 사례에서 모델이 해석을 포기했습니다. 그래서 전체 평균이 아니라 핵심 사례를 따로 읽어야 합니다.

플랫폼의 제약이 설계를 바꿉니다 게시 거부 한 번이 신청 구조 전체를 바꿨습니다. 처음부터 실제 제약을 확인하면 돌아가는 비용이 줄어듭니다.

문항은 코드 리뷰하듯 점검합니다 질문과 답 척도가 맞는지, 문항끼리 같은 것을 묻지 않는지, 특정 진로를 유도하지 않는지를 항목별로 확인하니 문구가 아니라 설계 결함이 나왔습니다.

솔직한 소감

뿌듯했던 것은 숫자가 남는다는 점입니다. 막연히 별로인 것 같다가 아니라 해석 26개 중 9개가 같은 틀이라고 말할 수 있었습니다. 답답했던 것은 가장 중요한 질문인 사람들이 실제로 이 결과를 뻔하지 않다고 느끼는지는 여전히 모른다는 점입니다. 신기했던 것은 점검기를 만들자 모델의 실수뿐 아니라 제 기대값의 실수도 같이 잡혔다는 점입니다.

🎯 결과

항목

Before

After

서비스 정의

검사지와 AI 상담

강점을 말로 정리하지 못하는 문제를 해결하는 서비스

검증 방법

없음

설문 15문항, 인터뷰 가이드, 판정 기준

AI 리포트 품질

감으로 판단

20건 입력과 자동 점검, 버전별 숫자 비교

믿음 계열 해석

26개 중 9개

31개 중 0개 (v0.3, 사이트에는 미반영)

문항 수

4개

55개, 6개 영역

진로 설계

없음

7갈래 적합도, 30일, 90일, 12개월 로드맵

시험

없음

자동 시험 56개

실제 사용자 검증

없음

아직 없음

📋 복붙 프롬프트

문제를 정리해서 다음 단계로 넘길 때:

아래 {문제 발굴 기록}을 읽고 다음을 해줘.

1. 문제 발굴 기록 문서 만들기 (불편 목록, 고른 문제, 누가 겪는지, 왜 막히는지, 기한)

2. 아직 모르는 것 목록과 각각을 확인하는 방법 (설문 문항, 인터뷰 질문, 가격 검증)

3. 판정 기준을 결과를 보기 전에 미리 숫자로 정하기

실제 데이터가 없으면 더미로 분석 스크립트만 만들고, 더미 결과에는 DUMMY라고 표시해줘.

AI 결과물의 품질을 숫자로 점검할 때:

{AI 기능}의 프롬프트와 평가용 입력 {N}건, 자동 점검 스크립트를 만들어줘.

평가 입력에는 일부러 어려운 것을 넣어줘: 입력이 거의 없음, 프롬프트 주입, 민감한 이야기, 범위 밖 질문, 모순되는 입력.

각 입력마다 반드시 해야 할 것과 하면 안 되는 것을 붙여줘.

점검 항목: 형식, 인용이 입력에 실제로 있는지, 금지 표현.

결과 생성은 점검 기준을 모르는 서브에이전트에게 맡길 때:

시스템 프롬프트 파일 {경로}를 읽고 그대로 따르는 모델처럼 행동해줘.

{입력 파일}의 각 항목을 독립적으로 처리해서 {출력 파일}에 id별 JSON으로 저장해줘.

다른 파일은 읽지 말고 저장소도 보지 마. 인용은 입력에서 글자 그대로 복사해.

고칠 때마다 비교할 때:

{버전A}와 {버전B} 결과를 같은 입력으로 비교해줘.

숫자(통과 수, 반복 표현 개수, 비어 있는 결과 수)와 핵심 사례 3건의 실제 내용을 같이 보여주고,

좋아진 점, 나빠진 점, 다음 수정안을 나눠서 써줘. 자동 점검이 못 잡는 부분은 못 잡는다고 말해줘.

설문 문항을 점검할 때:

{문항 목록}을 점검해줘.

질문의 동사와 답 척도가 맞는지, 한 문항에 두 가지를 묻지 않는지, 같은 유형 문항끼리 같은 개념인지,

특정 진로나 상품 이름이 들어가 점수를 유도하지 않는지, 선택지가 겹치거나 비는 구간이 없는지 확인하고

고칠 문구를 제안한 뒤 반영해줘. 점수 계산식은 바꾸지 마.

🔜 다음 계획

• 커뮤니티 회원 3~5명에게 직접 풀어 보게 하고 막히는 문항 표시하기

• 파일럿 응답 30명 이상 모아 문항 간 일관성과 1순위 진로의 적중 확인하기

• 리포트 프롬프트 v0.4 (자기 평가가 부정적인 입력에서도 해석하기)로 같은 20건을 3회씩 재생성해 흔들림 확인하기

• 자체 서버에서 AI를 호출하고 신청함을 따로 두어 공개 서비스로 옮길 준비하기