카카오페이증권
경력근거: 모호한 요구사항을 Acceptance Criteria, Edge Case, 기술적 제약 조건이 명확히 정의된 SPEC으로 변환
※ 실제 산출물이 아닌 AI 예측 시안입니다.
카카오페이증권 프로덕트 엔지니어는 PRD를 검토·구체화해 AI 개발용 SPEC과 컨텍스트(Harness)를 작성하고, 모호한 요구사항을 인수 조건·예외 케이스가 정의된 SPEC으로 변환하는 게 명시된 주요 업무입니다. 요구사항을 명세로 바꾸는 이 도구는 그 업무를 그대로 MVP로 만든 것입니다. 풀스택 PE가 0에서 1로 만드는 자리라 명세 콘솔(React·Next.js)·변환 API(Node.js·Python)·검증 체계·관측성(Sentry·Grafana·OpenTelemetry)까지 한 사람이 끝까지 구현하는 데 적합합니다.
PRD를 검토·구체화해 AI가 개발하는 데 필요한 명확한 SPEC과 컨텍스트(Harness)를 작성하는 게 핵심 업무입니다. 요구사항을 인수 조건·예외 케이스 명세로 바꾸는 이 도구가 그 업무와 곧바로 정렬됩니다.
모호한 요구사항을 인수 조건·예외 케이스·기술 제약이 정의된 SPEC으로 변환하는 역량을 직접 요구합니다. 빠진 예외 케이스를 짚어주는 이 콘솔의 핵심 로직과 맞습니다.
AI 생성 코드를 신뢰하도록 유닛·통합 테스트·린트·타입 체크의 다층 검증 체계를 설계하고, 관측성 도구로 서비스 지표를 본다는 업무입니다. 명세를 검증 체크리스트·모니터링으로 잇는 단계와 닿습니다.
제품 기획자가 쓴 모호한 요구사항(이슈)을 받아 인수 조건·예외 케이스·기술 제약이 명시된 개발 명세서 초안으로 변환하고, 각 인수 조건이 요구사항 원문 어느 문장에서 나왔는지 인용으로 붙이며, 빠진 예외 케이스와 서로 충돌하는 요구를 짚어 관리자 페이지에 모읍니다. 도메인 용어·금융 규제 체크 항목 사전을 붙여 표준화합니다.
카카오페이증권 프로덕트 엔지니어입니다. 기획자가 넘긴 모호한 요구사항을 AI에게 개발시키기 전에 인수 조건과 예외 케이스를 손으로 일일이 정리하던 상황을, 한 콘솔에서 자동 변환된 명세 초안과 근거 문장을 함께 보고 빠진 예외 케이스까지 확인하고 싶은 사람입니다.
요구사항 원문과 도메인·규제 체크 사전을 한 표준 구조로 묶으면, (a) 요구사항을 인수 조건·예외 케이스·제약 명세로 변환하고, (b) 각 인수 조건에 원문 인용을 강제하며, (c) 변환 명세가 심어둔 정답 인수 조건·예외 케이스와 맞는지 대조로 채점합니다.
모호한 요구사항을 받아 인수 조건·예외 케이스·기술 제약 명세 초안을 만들고 각 인수 조건에 원문 인용을 붙이며 빠진 예외 케이스를 짚는 동작하는 콘솔입니다. 입력은 증권 서비스 기획 요구사항을 가정한 더미로 시작하고, 충돌·누락 점검은 규칙으로 처리합니다. 1주차 기본 기능은 Next 프론트를 Vercel로 배포해 바로 도는 데모로 만듭니다.
변환한 명세를 심어둔 정답 인수 조건·예외 케이스와 대조해 추출 정확도를 보여주고, 모호 요구사항은 검토자 2명이 의도를 라벨링해 일치도를 보여주는 화면입니다. 인수 조건마다 유닛·통합 테스트 골격과 타입·린트 체크 항목을 자동 생성해 다층 검증 체계로 잇습니다.
Sentry·Grafana·OpenTelemetry로 배포 후 각 인수 조건이 실제로 지켜지는지 지표로 관측하고, 서비스별로 다른 금융 규제·도메인 체크 항목을 공통 사전으로 묶어 새 서비스 요구사항을 빠르게 변환하는 단계입니다.
증권 서비스 요구사항 12종을 넣으면, 인수 조건·예외 케이스·제약 명세 초안과 원문 인용이 몇 초 안에 나오는 걸 시연합니다
일부러 만든 악성·결측 입력 30종(모호 요구·서로 충돌하는 요구·정보 누락·한 줄짜리 요구)을 넣어도 출력 형식(스키마)이 한 번도 안 깨지고 충돌·누락이 표시되는 걸 보여줍니다
요구사항이 들어오면 명세 초안과 검증 체크리스트가 자동으로 채워지는 걸 시연으로 보여줍니다
내가 만든 정답 40건 중 변환 명세가 정답 인수 조건·예외 케이스와 일치한 게 34건(약 85%)입니다. 인수 조건 정답은 원문에 심은 문장이라 인용 매칭으로 객관 채점되고 충돌·누락은 규칙으로 결정됩니다. 단, 정답과 데이터를 모두 작성자가 만든 합성 기준이라 '성능 검증'이 아니라 '데모 조건에서의 동작'임을 명시합니다
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 전부 작성자가 만든 더미데이터 자가채점이며, 실제 변환 정확도는 카카오페이증권 실 기획자 요구사항과 실 검토자가 있어야 측정 가능합니다. 이 도구는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다
수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명합니다
정답 인수 조건을 작성자가 만들었으니 잘 맞는 게 당연합니다. 모호 요구·충돌 요구·정보 누락 같은 경계 케이스를 더미에 일부러 섞어, 쉬운 문제만 푸는 게 아님을 보여줍니다
변환은 원문에 없는 인수 조건을 지어내거나 있는 제약을 놓칠 수 있습니다. 인수 조건은 원문 인용을 강제하고 충돌·누락은 규칙으로 검출하며, 모호하면 단정 대신 '추가 확인 필요'로 표시합니다
같은 의미의 요구가 서비스마다 다른 용어로 적힙니다. 도메인 사전으로 같은 항목으로 묶고, 못 묶은 건 추측하지 말고 '미정의 용어'로 알립니다
실제 도입 시 달라지는 점을 명시합니다. 실 기획자 요구사항 형식·금융 규제 항목은 더미와 다르므로 체크 사전·변환 규칙을 다시 맞추고 검토자도 실제 기획·개발 인력으로 교체해야 합니다(도입 단계 과제로 분리)
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
기획자가 쓴 증권 서비스 더미 요구사항 문서. 변환 LLM이 가장 먼저 읽는 입력입니다. 모호 표현·서로 충돌하는 요구·정보 누락·한 줄짜리 요구를 일부러 섞어, 쉬운 데이터만 푸는 게 아님을 보여줍니다.
사용자가 해외주식을 주문할 수 있어야 합니다. 매수·매도 모두 지원하고, 환율은 주문 시점 환율로 표시합니다. 잔고가 부족하면 주문을 막아야 합니다. 미국 장 마감 시간에는 예약 주문으로 받습니다.
초보 사용자에게 투자 상품을 추천해 주세요. 가능하면 빠르게요.
아래 JSON Schema({"type":"object","properties":{"title":{"type":"string"},"body":{"type":"string"}},"required":["title","body"]})에 맞는 증권 서비스 기획 요구사항 문서 40건을 JSON 배열로 생성합니다. 주문·계좌·알림·포트폴리오 등 기능 6~8개. 모두 가상 더미.
쉬운 데이터만 만들지 말 것. 인수 조건을 추출할 명확한 문장을 심되 다음 하드 케이스를 의도적으로 섞어라(쉬운 문제만 푸는 함정 회피): (1) 모호 표현('빠르게'·'가능하면'·기준 불명) 4건, (2) 서로 충돌하는 요구('항상 즉시'와 '야간 금지', '영구 잠금'과 '고객센터 해제') 3건, (3) 정보 누락(최소 금액·제한 개수 미정) 3건, (4) 한 줄짜리 정보 부족 요구 2건. JSON 배열만(각 원소 {title, body}).{"type":"object","properties":{"title":{"type":"string"},"body":{"type":"string"}},"required":["title","body"]}요구사항별 정답 인수 조건·예외 케이스·충돌 여부 정답셋. 변환 명세 채점이 대조하는 기준입니다. 누락·충돌·모호를 일부러 섞어, 쉬운 문제만 푸는 게 아님을 보여줍니다.
| req_id | gold_criteria | gold_edge_cases | has_conflict | missing_info |
|---|---|---|---|---|
| req_001 | ["해외주식 매수·매도 주문이 가능하다","환율은 주문 시점 환율로 표시한다","잔고 부족 시 주문을 차단한다"] | ["미국 장 마감 시간에는 예약 주문으로 받는다"] | false | — |
| req_002 | ["초보 사용자에게 투자 상품을 추천한다"] | [] | false | 추천 기준과 응답 속도 기준이 명시되지 않음 |
| req_003 | ["보유 종목 가격 변동 시 알림을 보낸다","사용자가 알림을 끌 수 있다"] | ["야간에는 알림을 보내지 않는다"] | true | '항상 즉시 발송'과 '야간 미발송'이 충돌 |
| req_004 | ["비대면 계좌 개설을 지원한다","신분증 인증과 본인 명의 계좌 확인을 거친다","미성년자는 개설을 차단한다"] | ["본인 명의가 아닌 계좌는 거부한다"] | false | — |
| req_005 | ["목표 비중에서 벗어나면 리밸런싱을 제안한다","목표 비중은 사용자가 설정한다"] | [] | false | 벗어남의 임계값이 명시되지 않음 |
아래 JSON Schema에 맞는 요구사항별 정답셋 40행을 JSON 배열로 생성합니다.
{"type":"object","properties":{"req_id":{"type":"string"},"gold_criteria":{"type":"array","items":{"type":"string"}},"gold_edge_cases":{"type":"array","items":{"type":"string"}},"has_conflict":{"type":"boolean"},"missing_info":{"type":["string","null"]}},"required":["req_id","gold_criteria","gold_edge_cases","has_conflict","missing_info"]}
쉬운 데이터만 만들지 말 것. 정답 인수 조건을 요구사항 원문 문장에 맞춰 심되 다음 하드 케이스를 의도적으로 섞어라: (1) 충돌 있는 요구(has_conflict=true, missing_info에 충돌 설명) 6건, (2) 정보 누락(missing_info 채움, gold_edge_cases에 미정 항목) 8건, (3) 예외 케이스가 없는 단순 요구(gold_edge_cases=[]) 다수. gold_criteria는 원문에 실제로 있는 문장 기반만. JSON 배열만.{"type":"object","properties":{"req_id":{"type":"string"},"gold_criteria":{"type":"array","items":{"type":"string"}},"gold_edge_cases":{"type":"array","items":{"type":"string"}},"has_conflict":{"type":"boolean"},"missing_info":{"type":["string","null"]}},"required":["req_id","gold_criteria","gold_edge_cases","has_conflict","missing_info"]}| Python | 요구사항 변환 파이프라인·인수 조건 추출·충돌·누락 점검 규칙의 구현 언어 |
| Java | 일부 기간계 증권 서비스 명세 연동 어댑터를 가정한 백엔드 경로 |
| Kotlin | 변환 API를 JVM 서비스로 분리할 때의 서버 구현 가정 |
| React | 명세 작성 콘솔(요구사항 입력·명세 초안 검토·예외 케이스 카드) 화면 구현 |
| Next.js | 콘솔 라우팅·서버 컴포넌트 호스팅 + 1주차 기본 기능 Vercel 배포 |
| Node.js | 변환 API·인용 매칭 서버·검토자 라벨 수집 백엔드 |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 2주차(정답 대조 채점 + 검증 체크리스트 생성)로 진행합니다.
✓ pass → 여기서 멈춰도 완결입니다. 더 키우면 3주차(명세 준수 관측성 + 도메인·규제 체크 사전 표준화)로 진행합니다.
요구사항 1건의 명세 초안 카드. 추출한 인수 조건(원문 인용·확신도)과 예외 케이스·충돌·누락 점검을 한 스키마로 담아 명세 작성 콘솔에 씁니다.
{"type":"object","properties":{"req_id":{"type":"string"},"acceptance_criteria":{"type":"array","items":{"type":"object","properties":{"text":{"type":"string"},"source_quote":{"type":["string","null"]},"confidence":{"enum":["low","mid","high"]}},"required":["text","source_quote","confidence"]}},"edge_cases":{"type":"array","items":{"type":"string"}},"checks":{"type":"object","properties":{"has_conflict":{"type":"boolean"},"missing_info":{"type":["string","null"]},"note":{"type":["string","null"]}},"required":["has_conflict","missing_info","note"]}},"required":["req_id","acceptance_criteria","edge_cases","checks"]}[
{
"input_ref": "req_001 (해외주식 주문 — 정보 충분)",
"output": {
"req_id": "req_001",
"acceptance_criteria": [
{
"text": "해외주식 매수·매도 주문이 가능하다",
"source_quote": "매수·매도 모두 지원하고",
"confidence": "high"
},
{
"text": "환율은 주문 시점 환율로 표시한다",
"source_quote": "환율은 주문 시점 환율로 표시합니다",
"confidence": "high"
},
{
"text": "잔고 부족 시 주문을 차단한다",
"source_quote": "잔고가 부족하면 주문을 막아야 합니다",
"confidence": "high"
}
],
"edge_cases": [
"미국 장 마감 시간에는 예약 주문으로 받는다"
],
"checks": {
"has_conflict": false,
"missing_info": null,
"note": null
}
}
},
{
"input_ref": "req_003 (알림 — 충돌 있음)",
"output": {
"req_id": "req_003",
"acceptance_criteria": [
{
"text": "보유 종목 가격 변동 시 알림을 보낸다",
"source_quote": "보유 종목 가격이 오르거나 내리면 알림을 보냅니다",
"confidence": "high"
},
{
"text": "사용자가 알림을 끌 수 있다",
"source_quote": "사용자가 알림을 끌 수 있어야 합니다",
"confidence": "high"
}
],
"edge_cases": [
"야간에는 알림을 보내지 않는다"
],
"checks": {
"has_conflict": true,
"missing_info": "'항상 즉시 발송'과 '야간 미발송'이 충돌해 추가 확인이 필요합니다",
"note": "충돌하는 두 요구를 그대로 두지 않고 기획자에게 되물어야 합니다"
}
}
},
{
"input_ref": "req_002 (간편 투자 추천 — 정보 부족)",
"output": {
"req_id": "req_002",
"acceptance_criteria": [
{
"text": "초보 사용자에게 투자 상품을 추천한다",
"source_quote": "초보 사용자에게 투자 상품을 추천해 주세요",
"confidence": "mid"
}
],
"edge_cases": [],
"checks": {
"has_conflict": false,
"missing_info": "추천 기준과 '빠르게'의 응답 속도 기준이 명시되지 않았습니다",
"note": "추천 알고리즘 기준이 없어 인수 조건을 단정하지 않습니다"
}
}
}
][자동 검증 — 코드가 매 출력마다 자동으로 거릅니다] 1) JSON Schema 형식 통과: 출력이 정한 필드·타입을 지키는지 검사하고, 어기면 거부합니다. 2) 각 acceptance_criteria.source_quote 가 요구사항 원문에 실제로 있는 문장인지 인용 매칭합니다 — 원문에 없는 인수 조건을 지어내지 못하게 합니다. 3) acceptance_criteria 와 edge_cases 가 정답셋(gold_criteria·gold_edge_cases)과 매칭되는지 봐서 추출 정밀도·재현율을 계산합니다. 4) checks.has_conflict 는 충돌 규칙(상호 배타 표현 쌍)으로 코드가 자동 판정합니다. 5) source_quote 가 null 이면 confidence=high 를 금지합니다(근거 없는 단정 방지). [수동 검증 — 사람이 일부만 확인합니다] 1) 검토자 2명이 같은 모호 요구사항의 의도를 따로 라벨링해, 두 사람 판단이 우연 이상으로 일치하는지 봅니다(Cohen's κ ≥ 0.6 — 0~1, 높을수록 일치). 2) 전체 출력의 5%는 사람이 직접 다시 확인합니다(spot check). [전제] 인수 조건 정답은 요구사항 원문에 심어둔 문장이라, 추출 정밀도·재현율을 객관적으로 채점할 수 있습니다.