본투시니어 프로덕트 엔지니어
0.0본투비
경력근거: 비개발 직군과 긴밀하게 소통하며, 고객 관점에서 문제를 정의하고 빠르게 검증하는 문화
어제 확인채용 공고 보기
이 도구가 보여주는 것은 풀스택 제품 구현(Next.js·React Native·Node·PostgreSQL·GCP)과 주문 상태전이·정합성 검증 엔진, 자연어를 규칙으로 번역하는 구조화 기술이며, 캐릭터 IP 나 스티커·굿즈 커머스 도메인 자체의 전문성은 주장하지 않습니다. 다만 이 사슬이 말이 되려면 트웬티라는 맥락, 즉 5.7천 명 작가가 등록한 캐릭터 굿즈를 45만 유저가 주문하고 스티커·굿즈 국내 1위로 굴러가는 커머스, 그리고 나만의 캐릭터 상품을 제작하는 캐디처럼 상품·주문 규칙이 계속 바뀌는 제품이 있어야 의미가 있습니다. ‘비개발 직군이 규칙을 던지면 실데이터 위반을 바로 본다’ 는 각도는 규칙이 자주 바뀌는 이 커머스에서만 값을 합니다. 실제 굿즈 제작 공정이나 캐릭터 IP 라이선스의 깊이는 도메인 담당자와의 협업이 있어야 하고, 면접에서 모르는 부분은 모른다고 말하는 편이 낫습니다.
‘AI 를 활용한 개발 인프라 개선 및 아키텍처 설계(빠른 개발 속도)’ 가 이 포지션의 한 축입니다. 모델 연구가 아니라, 반복되는 검증 작업을 자동화해 실행 속도를 높이는 실전 도구가 보여줄 대상입니다.
‘비개발 직군과 함께하는 가설 검증 문화 및 프로세스 구축(빠른 가설 검증)’ 이 다른 한 축입니다. 기획자가 코드 없이 상품·주문 규칙 가설을 던지고 바로 검증받는 흐름을 기술로 떠받칩니다.
‘백엔드·프런트 경계 없이 해내는 실행력’ 을 봅니다. Next.js 콘솔·React Native 작가 앱·Node 검증 엔진·PostgreSQL 진실원·GCP 비동기 파이프라인을 한 사람이 잇는 풀스택 구현이 필요합니다.
트웬티 기획자가 ‘결제 완료된 주문만 제작에 들어간다’, ‘품절 상품은 신규 주문을 못 받는다’ 처럼 굿즈 상품·주문 규칙 가설을 말로 정의하면, LLM 이 이를 상품 제약과 주문 상태전이 규칙(created→paid→in_production→printed→shipped)으로 번역합니다. 그다음 결정론 엔진이 실제 등록 상품(character_products)과 주문 이벤트 로그(order_events)를 그 규칙에 대조해, 결제 없이 배송된 주문·등록되지 않은 상품 참조·품절 상품 판매 같은 위반 건만 근거를 붙여 뽑아냅니다. 위반 판정은 규칙표로 고정되고 LLM 은 번역과 사람말 요약만 맡습니다. 1주차만으로 완성품이고, 번역·판정 검토(2주차)·GCP 비동기 주문 파이프라인(3주차)으로 키웁니다. (근거는 채용공고 정렬입니다.)
본투비 시니어 프로덕트 엔지니어입니다. 개발직군 2명·대표·COO 로 빠르게 움직이는 팀에서, 기획자가 새 굿즈 상품 타입이나 주문 규칙을 실험하려 할 때마다 개발자에게 물어보고 코드로 확인하느라 검증이 느려지는 걸, 기획자가 스스로 규칙을 던지고 실제 데이터 위반을 바로 확인하게 만들어 가설 검증 속도를 높이고 싶은 사람입니다.
굿즈 상품·주문 규칙을 상태전이 규칙표와 정합성 제약으로 구조화하고 자연어 번역기를 앞에 두면, (a) 기획자가 코드 없이 던진 가설을 LLM 이 규칙으로 번역하고, (b) 결정론 엔진이 실제 상품·주문 데이터에서 위반 건과 그 근거를 고정적으로 잡아내며, (c) 규칙에 없는 판정은 만들어내지 않아, 비개발 직군이 바로 돌려보는 신뢰할 검증 도구가 된다는 걸 보여줄 수 있습니다.
기획자가 자연어로 던진 굿즈 상품·주문 규칙 가설을 LLM 이 상태전이 규칙·상품 제약으로 번역하고, 결정론 엔진이 실제 등록 상품·주문 이벤트에서 위반 건과 그 근거를 뽑는 동작하는 콘솔입니다. 주문 상태 처리는 1주차엔 동기 함수 호출로 검증만 돌리고, GCP 비동기 파이프라인 구동은 3주차로 분리합니다.
커머스 운영·기획 페르소나 2명이 가설 번역이 타당한지, 위반 판정이 규칙에 맞는지 라벨링하고, 규칙에 없는 판정을 지어낸 비율을 대조하는 대시보드입니다.
결제→제작→인쇄→배송 상태 전이를 GCP Cloud Tasks 큐와 Cloud Functions 훅으로 비동기 처리하고, 각 단계 전이마다 규칙 검증을 자동으로 태워 위반 이벤트를 실시간으로 리포트하는 단계입니다.
굿즈 가설 30종(‘결제된 주문만 제작에’, ‘품절 상품은 신규 주문 불가’ 등)과 주문 이벤트 세트를 넣으면, 가설을 규칙으로 번역해 위반 주문·상품과 그 근거를 짚어내는 걸 시연합니다
같은 데이터·같은 규칙이면 위반 목록이 항상 똑같이 나오는지 자동 대조합니다. LLM 이 만든 요약 문구와 무관하게 위반 판정 자체는 규칙 엔진으로 고정되는 걸 보여줍니다
일부러 심은 불법 전이(결제 없이 배송)·등록 안 된 상품 참조·품절 상품 주문 20종을 넣으면, 정상 흐름과 구분해 전부 위반으로 잡아내는 걸 보여줍니다
내가 만든 정답 30건 중 규칙 번역·위반 검출이 일치한 게 26건(87%)입니다. 단, 정답·데이터를 모두 작성자가 만든 합성 기준이라 ‘성능 검증’ 이 아니라 ‘데모 조건 동작’ 임을 밝힙니다
위 수치는 전부 작성자가 만든 더미데이터 자가채점이며, 실제 위반 검출 정확도·기획자 체감 검증 속도는 트웬티 실 상품·주문 로그와 실 기획자가 있어야 측정 가능합니다. 이 도구는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다
이건 사용자·실데이터 없이 혼자 만든 포트폴리오라, 수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서 ‘데모 동작 + 실검증 준비 상태’ 로 솔직히 설명합니다
정답을 작성자가 만들었으니 잘 맞는 것이 당연합니다. 불법 전이·orphan 참조·품절 판매·금액 불일치·경계값(재고 0·금액 0)을 더미에 일부러 섞어, 쉬운 주문 흐름만 통과시키는 게 아님을 보여줍니다
이 포트폴리오가 보여주는 것은 풀스택 제품 구현·주문 상태전이 검증·정합성 가드·자연어 규칙 번역 기술이지, 캐릭터 IP 나 스티커·굿즈 커머스 도메인 자체의 전문성이 아닙니다. 실제 굿즈 제작 공정이나 IP 라이선스 규칙의 깊이는 도메인 담당자 협업이 있어야 하고, 면접에서 모르는 부분은 모른다고 말하는 편이 낫습니다
실제 도입 시 달라지는 것 명시합니다. 트웬티 실제 주문 상태·상품 규칙은 더미와 다르므로 합법 전이표와 정합성 제약을 실데이터로 다시 맞춰야 하고, 검토자도 실 기획자·운영자로 교체해야 합니다(도입 단계 과제로 분리)
비개발 직군이 던진 가설이 애매하면 규칙 번역이 어긋날 수 있어, 한 문장으로 규칙이 안 되는 가설은 판정을 지어내지 않고 되묻는 질문으로 돌려보냅니다
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
작가가 등록한 캐릭터 굿즈 상품 카탈로그이자 주문 정합성 검증의 마스터입니다. 품절·재고 결측·상품 타입 별칭 표기(스티커=sticker)·미연결 캐릭터·경계 가격을 일부러 섞어, 규칙을 무시하거나 없는 상품을 정상으로 보지 않는지 보여줍니다.
| product_id | artist_id | character_id | type_raw | type | price_krw | stock | status |
|---|---|---|---|---|---|---|---|
| P-101 | A-01 | C-001 | sticker | sticker | 3,500 | 120 | published |
| P-102 | A-01 | C-001 | 키링 | keyring | 8,900 | 40 | published |
| P-103 | A-02 | C-014 | phonecase | phonecase | 18,000 | 0 | soldout |
| P-104 | A-02 | — | 스티커 | sticker | 3,000 | 200 | published |
| P-105 | A-03 | C-020 | 티셔츠 | tshirt | 26,000 | — | draft |
아래 JSON Schema 에 맞는 캐릭터 굿즈 상품 카탈로그 30행 JSON 배열로 생성합니다. 작가·캐릭터·상품 타입·가격대를 고루 섞습니다.
{"type":"object","properties":{"product_id":{"type":"string"},"artist_id":{"type":"string"},"character_id":{"type":["string","null"]},"type_raw":{"type":"string"},"type":{"type":["string","null"],"enum":["sticker","keyring","phonecase","tshirt",null]},"price_krw":{"type":"integer"},"stock":{"type":["integer","null"]},"status":{"type":"string","enum":["draft","published","soldout"]}},"required":["product_id","artist_id","type_raw","price_krw","status"]}
쉬운 데이터만 만들지 말 것. 하드 케이스 의도적 혼입: (1) stock 이 null 인 재고 미입력 2~3건, (2) stock=0 인데 status=published 인 품절 모순 1~2건, (3) type_raw 가 한글·영문·띄어쓰기 별칭(스티커·키링·phone case)이라 type enum 매핑이 필요한 표기 흔들림 3~4건, (4) character_id 가 null 인 미연결 상품 1~2건, (5) price_krw=0 인 경계 상품 1건, (6) type_raw 는 있으나 enum 매핑이 안 되는 type=null 1건. JSON 배열만.{"type":"object","properties":{"product_id":{"type":"string"},"artist_id":{"type":"string"},"character_id":{"type":["string","null"]},"type_raw":{"type":"string"},"type":{"type":["string","null"],"enum":["sticker","keyring","phonecase","tshirt",null]},"price_krw":{"type":"integer"},"stock":{"type":["integer","null"]},"status":{"type":"string","enum":["draft","published","soldout"]}},"required":["product_id","artist_id","type_raw","price_krw","status"]}굿즈 주문의 상태전이 이벤트 로그입니다. 합법 전이표(created→paid→in_production→printed→shipped, paid/created→cancelled, shipped→refunded)에 대조해 위반을 잡습니다. 결제 없이 배송·등록 안 된 상품 참조·금액 결측·중복 순번을 섞어, 정상 흐름만 통과시키는 게 아님을 보여줍니다.
| order_id | product_id | seq | from_state | to_state | event_type | amount_krw | ts |
|---|---|---|---|---|---|---|---|
| O-001 | P-101 | 1 | — | created | order_created | 3,500 | 2026-07-01T10:00:00Z |
| O-001 | P-101 | 2 | created | paid | payment_captured | 3,500 | 2026-07-01T10:02:00Z |
| O-001 | P-101 | 3 | paid | in_production | production_started | — | 2026-07-01T11:00:00Z |
| O-002 | P-102 | 1 | — | created | order_created | 8,900 | 2026-07-02T09:00:00Z |
| O-002 | P-102 | 2 | created | shipped | shipment_created | 8,900 | 2026-07-02T09:05:00Z |
아래 JSON Schema 에 맞는 굿즈 주문 상태전이 이벤트 로그 30행 JSON 배열로 생성합니다. 한 order_id 는 seq 순서로 여러 이벤트를 갖습니다. 합법 전이표는 created→paid→in_production→printed→shipped, paid→cancelled, created→cancelled, shipped→refunded 입니다.
{"type":"object","properties":{"order_id":{"type":"string"},"product_id":{"type":"string"},"seq":{"type":"integer"},"from_state":{"type":["string","null"],"enum":["created","paid","in_production","printed","shipped","cancelled","refunded",null]},"to_state":{"type":"string","enum":["created","paid","in_production","printed","shipped","cancelled","refunded"]},"event_type":{"type":"string"},"amount_krw":{"type":["integer","null"]},"ts":{"type":"string"}},"required":["order_id","product_id","seq","to_state","event_type","ts"]}
쉬운 데이터만 만들지 말 것. 하드 케이스 의도적 혼입: (1) 결제 없이 배송(created→shipped)·제작 건너뜀(paid→shipped) 같은 불법 전이 3~4건, (2) product_id 가 character_products 마스터에 없는 orphan 참조(예: P-999) 2건, (3) 결제 이벤트인데 amount_krw 가 null 인 금액 결측 1~2건, (4) from_state 가 null 인데 to_state 가 created 가 아닌 순서 붕괴 1건, (5) 같은 order_id 에 seq 가 중복된 이벤트 1건, (6) refunded 이후 다시 in_production 으로 가는 역행 전이 1건. JSON 배열만.{"type":"object","properties":{"order_id":{"type":"string"},"product_id":{"type":"string"},"seq":{"type":"integer"},"from_state":{"type":["string","null"],"enum":["created","paid","in_production","printed","shipped","cancelled","refunded",null]},"to_state":{"type":"string","enum":["created","paid","in_production","printed","shipped","cancelled","refunded"]},"event_type":{"type":"string"},"amount_krw":{"type":["integer","null"]},"ts":{"type":"string"}},"required":["order_id","product_id","seq","to_state","event_type","ts"]}| JavaScript | 콘솔·앱·서버를 잇는 공통 언어(자격요건의 JavaScript) |
| Next.js | 기획자용 가설 검증 콘솔. 가설 입력·규칙 미리보기·위반 리포트 화면을 SSR 로 렌더(자격요건의 Next.js) |
| React | 위반 목록·규칙표·근거 하이라이트 등 콘솔 UI 컴포넌트(자격요건의 React) |
| React Native | 작가용 모바일 앱에서 캐릭터 굿즈 상품을 등록하고 주문 상태를 확인하는 화면(자격요건의 React Native) |
| Node.js | 가설 번역 API 와 상태전이·정합성 검증 엔진 서버(자격요건의 Node.js) |
| PostgreSQL | character_products / order_events / 상태전이 규칙표의 단일 진실원과 검증 뷰(자격요건의 PostgreSQL) |
| GCP | App Engine(콘솔 호스팅)·Cloud Run(검증 엔진 컨테이너)·Cloud Tasks(주문 상태 단계 큐)·Cloud Functions(주문 이벤트 훅·검증 트리거) |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 2주차(번역·판정 검토)로 진행합니다.
✓ pass → 여기서 멈춰도 완결입니다. 더 키우면 3주차(GCP 비동기 주문 파이프라인)로 진행합니다.
기획자가 던진 자연어 가설에 대한 검증 리포트입니다. 번역된 규칙(parsed_rules), 대조한 위반 건(violations)과 각 위반의 근거(evidence), 사람말 요약(summary), 최종 판정(verdict)을 한 스키마에 담아, 규칙에 없는 판정을 지어내지 않고 실제 상태전이 규칙·정합성으로만 위반을 잡았는지 객관 검증합니다.
{"type":"object","properties":{"hypothesis":{"type":"string"},"parsed_rules":{"type":"object","properties":{"transition_rules":{"type":"array","items":{"type":"object","properties":{"from":{"type":["string","null"]},"to":{"type":"string"},"allowed":{"type":"boolean"}},"required":["to","allowed"]}},"product_constraints":{"type":"array","items":{"type":"string"}}},"required":["transition_rules","product_constraints"]},"violations":{"type":"array","items":{"type":"object","properties":{"ref":{"type":"string"},"rule":{"type":"string"},"evidence":{"type":"string"},"severity":{"type":"string","enum":["high","mid","low"]}},"required":["ref","rule","evidence","severity"]}},"summary":{"type":"string"},"verdict":{"type":"string","enum":["pass","fail","need_clarification"]}},"required":["hypothesis","parsed_rules","violations","summary","verdict"]}[
{
"input_ref": "가설: ‘결제 완료된 주문만 제작에 들어가야 한다’",
"output": {
"hypothesis": "결제 완료된 주문만 제작에 들어가야 한다",
"parsed_rules": {
"transition_rules": [
{
"from": "paid",
"to": "in_production",
"allowed": true
},
{
"from": "created",
"to": "in_production",
"allowed": false
}
],
"product_constraints": []
},
"violations": [],
"summary": "표본 주문 중 제작(in_production)으로 넘어간 건은 모두 직전 상태가 paid 였습니다. 결제 없이 제작에 들어간 주문은 없습니다.",
"verdict": "pass"
}
},
{
"input_ref": "가설: ‘모든 주문은 결제 후에만 배송될 수 있다’ (O-002 위반)",
"output": {
"hypothesis": "모든 주문은 결제 후에만 배송될 수 있다",
"parsed_rules": {
"transition_rules": [
{
"from": "printed",
"to": "shipped",
"allowed": true
},
{
"from": "created",
"to": "shipped",
"allowed": false
}
],
"product_constraints": []
},
"violations": [
{
"ref": "O-002/seq2",
"rule": "created→shipped 는 불법 전이(결제·제작 단계를 건너뜀)",
"evidence": "from_state=created, to_state=shipped, event_type=shipment_created",
"severity": "high"
}
],
"summary": "주문 O-002 가 결제(paid) 없이 created 에서 곧바로 배송(shipped)으로 넘어갔습니다. 합법 전이표를 어긴 1건입니다.",
"verdict": "fail"
}
},
{
"input_ref": "가설: ‘모든 주문 상품은 등록된 캐릭터 상품이어야 한다’ (O-004 orphan)",
"output": {
"hypothesis": "모든 주문 상품은 등록된 캐릭터 상품이어야 한다",
"parsed_rules": {
"transition_rules": [],
"product_constraints": [
"order.product_id 는 character_products 에 존재해야 함"
]
},
"violations": [
{
"ref": "O-004",
"rule": "정합성 위반: 주문이 참조한 상품이 카탈로그에 없음",
"evidence": "product_id=P-999 는 character_products 마스터에 없음",
"severity": "high"
}
],
"summary": "주문 O-004 가 등록되지 않은 상품 P-999 를 참조합니다. 카탈로그에 없는 상품이라 정합성 위반으로 표기하고, 없는 상품을 있는 것처럼 통과시키지 않습니다.",
"verdict": "fail"
}
},
{
"input_ref": "가설: ‘좋은 상품이면 많이 팔려야 한다’ (규칙으로 번역 불가 → 되묻기)",
"output": {
"hypothesis": "좋은 상품이면 많이 팔려야 한다",
"parsed_rules": {
"transition_rules": [],
"product_constraints": []
},
"violations": [],
"summary": "‘좋은 상품’ 과 ‘많이’ 의 기준이 규칙으로 정해지지 않아 상태전이·정합성 규칙으로 번역할 수 없습니다. 판정을 지어내지 않고 되묻습니다. 예를 들어 ‘published 상태이고 재고가 10개 이상인 상품’ 처럼 기준을 정해 주시겠어요?",
"verdict": "need_clarification"
}
}
][자동 검증] 1. 출력이 스키마를 통과하는가(형식·필수 필드). 2. violations 의 각 위반이 상태전이 규칙표·정합성 규칙으로 재현되는가. 같은 데이터·같은 규칙이면 위반 목록이 항상 동일한가(결정론 고정). 3. violations 의 ref 가 실제 order_events/character_products 행을 가리키고 evidence 의 값이 그 행의 실제 필드와 일치하는가(근거 조작 검출). 4. 규칙표에 없는 전이를 위반으로 표기했는데 실제로는 합법이면 실패(과검출). 반대로 불법 전이·orphan·품절 주문을 놓치면 실패(미검출). 5. 규칙으로 번역 불가한 가설에 verdict=need_clarification 이 나오고 violations 를 지어내지 않았는가. [수동 검증] 1. 커머스 운영·기획 페르소나 2명이 가설 번역 타당성·위반 판정을 라벨링 → bootstrap Cohen’s κ(두 사람 답이 우연 이상으로 일치하는 정도, 0~1) 하한 ≥ 0.6. 2. 규칙에 없는 판정을 지어낸 비율 5% 사람 점검.