메이커톤 Part 1. Tradvance — 해외 바이어 문의 응대 도우미
메이커톤 Part 2. Tradvance — 무엇을 만들고 무엇을 버렸는가 ▼
[게시글 목차]
1. MVP에서 검증하려는 가설
2. 확인 항목 7개를 정한 이유
3. 위험 구간 체크리스트를 넣은 이유
4. 영어를 못해도 수정할 수 있게 만들기
5. 화면 흐름을 어떻게 잡았나
1) 랜딩 페이지
2) 문의 입력 화면
3) 로딩 화면
4) 예외 화면
6. 결과 화면은 4단계 아코디언으로 구성했다
Step 1. 원문 확인
Step 2. 문의 항목 분류
Step 3. 답변 초안 생성
Step 4. 위험 구간 확인
7. 위험 구간 확인 모달
8. 이번 MVP에 포함한 것 / 이번 MVP에서 제외한 것
9. 기능명세서를 작성하면서 느낀 점
+) 오늘의 인사이트/KPT 회고
활동 내역
AI가 대신 답변하지 않게 설계하기
-
구현 가능성을 위해 멋짐 포인트 포기하기...
Part1에서는 처음 아이디어였던 '중소기업 해외 수출 판로 지원 서비스'를
어떻게 '해외 바이어 문의 응대' 문제로 좁혔는지 정리했다.
처음에는 너무나도 거창했다.
바이어 발굴도 하고, 수출 판로도 연결하고, 문의 응대도 돕고,
나아가 거래처 관리까지 해주면 좋겠다고 생각했다.
but, 프로젝트를 진행할수록 이 방향은 너무 넓었다.
문제가 넓으면 기능도 넓어진다.
기능이 넓어지면 MVP가 흐려진다.
MVP가 흐려지면 결국 '무엇을 검증하려는 서비스인지' 설명하기 어려워진다.
그래서 2단계에서는 질문을 바꿨다.
'이 프로젝트에서 진짜 검증해야 하는 최소 기능은 무엇인가?'
🔹Tradvance 지난 이야기...
문제 정의와 설문 결과를 바탕으로 Tradvance를 이렇게 정의했다.
Tradvance는 해외 바이어 문의를 입력하면 확인해야 할 항목과
검토 가능한 영어 답변 초안을 정리해 주는 수출 문의 응대 보조 도구다.
설문 결과, 사용자들은 AI 초안에는 관심이 있었다.
답변 작성 시간이 줄어들고, 영어 표현 부담이 줄어드는 점은 분명한 장점이었다.
하지만 동시에 아래와 같은 우려를 표했다.
- AI 답변을 그대로 믿고 보내면 어떡하지?
- 잘못된 견적을 안내하면 어떡하지?
- 납기나 재고를 틀리게 말하면 어떡하지?
- 기술 사양을 잘못 해석하면 어떡하지?
즉, 문제는 'AI가 답변을 써줄 수 있는가?'가 아니었다.
AI가 만든 답변을 사람이 안전하게 검토할 수 있는가?
위 질문이 진짜 문제였다.
→ Tradvance 원칙 : AI는 초안을 만들고, 최종 판단은 담당자가 한다.
이 문장은 이후 랜딩 페이지, 상단 안내바, 위험 구간 체크리스트, 복사 버튼 활성화 조건까지 서비스 전반의 기준이 됐다.
1. MVP에서 검증하려는 가설
- 이번 MVP에서 검증하고 싶었던 가설
→ 바이어 문의를 입력했을 때 확인 필요 항목과 위험 구간이 표시된 답변 초안을 제공하면,
담당자는 더 빠르고 안전하게 응대할 수 있을 것이다.- 설계 규칙 초안
- 첫째, 문의 내용을 빠르게 이해해야 한다.
- 둘째, 확인해야 할 항목을 정리해야 한다.
- 셋째, 잘못 보내면 위험한 부분을 따로 확인해야 한다.
- 설계 규칙 초안
- MVP도 단순한 '영어 답변 생성기'가 아니라 아래 흐름으로 설계했다.
1. 바이어 문의 원문을 붙여넣는다.
2. 원문을 한국어로 확인한다.
3. 문의 항목을 7개 카테고리로 분류한다.
4. 영어 답변 초안을 생성한다.
5. 초안 안의 위험 구간을 표시한다.
6. 담당자가 위험 구간을 확인한다.
7. 확인이 끝나야 초안을 복사할 수 있다.
⚠️주의점
- 자동 발송하지 않는다.
- 담당자가 확인해야 한다.
- 확인 전에는 복사도 막는다.
→ 서비스가 할 일과 사람이 해야 할 일을 분리
2. 확인 항목 7개를 정한 이유
- 해외 바이어 문의는 보기에는 단순한 이메일처럼 보이지만, 실제로는 여러 업무 항목이 섞여 있다.
바이어 질문 ex.- 500개 주문하면 단가가 얼마인가요?
- MOQ는 얼마인가요?
- 납기는 2주 안에 가능한가요?
- CE 인증이 있나요?
- 포장 방식은 어떻게 되나요?
- FOB 조건으로 견적을 받을 수 있나요?
→ 각 문장은 내부 확인이 필요한 업무 항목으로 바뀐다.
| 문의 내용 7개 카테고리로 분류 | ||||||
| 가격/견적 | MOQ | 납기/리드타임 | 기술 사양 | 포장/물류 | 인증/품질 기준 | 결제 조건 |
| → 특히 가격/견적은 가장 많이 언급된 항목이었다. 그만큼 바이어 문의에서 자주 등장하고, 동시에 잘못 답변하면 위험한 항목이기도 하다. |
||||||
- 카테고리 분류는 사용자가 문의를 받았을 때 이런 질문에 바로 답하게 만든다.
→ '지금 이 문의에서 무엇을 확인해야 하지?'
3. 위험 구간 체크리스트를 넣은 이유
- AI가 답변 초안을 만들어주는 것만으로는 부족했다.
초안 안에 있는 일부 표현은 담당자가 반드시 확인해야 한다.
표현 ex.- USD 12 per unit
- MOQ 500 units
- within 14 days
- CE certificate available
→ 확인하지 않고 보내면 위험할 수 있다.
- 주의점
- 가격은 최신 견적과 다를 수 있다.
- 납기는 생산 일정에 따라 달라질 수 있다.
- MOQ는 재고나 생산 단위와 연결될 수 있다.
- 인증 여부는 문서 확인이 필요할 수 있다.
→ so, Tradvance는 이런 표현을 위험 구간으로 표시한다.
(담당자가 확인해야 할 가능성이 높은 부분이라는 뜻)
- 화면에서도 위험 구간은 핑크 계열로 표시했다.
강한 경고라기보다는 '확인 필요'에 가까운 톤으로 잡았다.
→ 그리고 모든 위험 구간을 체크해야 초안 복사 버튼이 활성화되도록 했다. - 설문 결과와 직접 연결되는 구조
- 9명 중 8명이 완전 자동화가 아닌 사람 개입 구조를 선호했다.
- 9명 중 6명이 AI 답변을 그대로 믿고 보낼 위험을 우려했다.
→ 즉, 위험 구간 체크리스트는 부가 기능이 아니라 MVP의 핵심 기능이다.
4. 영어를 못해도 수정할 수 있게 만들기
- 이번 MVP에서 특히 강조하고 싶었던 부분은 한국어 번역문 수정 기반 초안 재생성이다.
→ 해외 바이어 문의 응대 도구라고 하면 자연스럽게 영어 답변 초안을 떠올리게 된다.
but, 실제 사용자가 영어에 익숙하지 않다면 문제가 생긴다. - AI가 영어 초안을 만들어줘도, 사용자가 그 영어 문장을 제대로 이해하지 못하면 수정하기 어렵다.
잘못된 조건을 발견해도 영어로 어떻게 고쳐야 할지 막막할 수 있다.
→ 그래서 Tradvance는 답변 초안을 한국어로 함께 보여주도록 했다.- 단순히 번역만 보여주는 데서 끝내지 않았다.
사용자가 한국어 번역문을 수정하면, 그 수정 내용이 다시 영어 답변 초안에 반영되도록 만들었다.
→ 즉, 사용자는 영어 문장을 직접 고치지 않아도 된다. - 흐름 보기
1. AI가 영어 답변 초안을 만든다.
2. 초안을 한국어로 번역해 보여준다.
3. 담당자가 한국어 문장을 읽고 필요한 내용을 수정한다.
4. 수정된 한국어 문장을 다시 영어로 반영한다.
5. 영문 초안과 위험 구간을 다시 계산한다.
- 단순히 번역만 보여주는 데서 끝내지 않았다.
- Tradvance가 해결하려는 문제는 영어 실력 자체가 아니라,
담당자가 내용을 이해하고 검토한 뒤 안전하게 응대할 수 있는가에 가깝다.
→ so, 영어를 잘 못하는 사람도 한국어로 내용을 확인하고 수정할 수 있게 하는 것이 중요했다.
5. 화면 흐름을 어떻게 잡았나
- MVP 화면은 크게 랜딩 페이지와 도구 페이지로 나눴다.
- 랜딩 페이지 : 서비스의 문제와 가치를 설명하는 역할을 한다.
- 도구 페이지 : 실제 사용자가 문의를 입력하고 답변 초안을 얻는 핵심 기능이다.
1) 랜딩 페이지
- 랜딩 페이지에서는 사용자가 서비스를 처음 봤을 때 바로 이해할 수 있어야 했다.
- 랜딩 페이지 배치 요소
- Tradvance 로고와 한 줄 설명
- 'AI는 초안을 만들고, 최종 판단은 담당자가 합니다' 안내 문구
- 히어로 이미지 슬라이드쇼
- 타이핑 헤드라인
- 답변 초안 미리 보기 카드
- 핵심 기능 3개
- 동작 순서 3단계
- 설문 기반 신뢰 지표
- 랜딩 페이지의 목적은 단순 홍보가 아니었다.
서비스가 왜 필요한지, 어떤 문제를 해결하는지, 왜 자동 발송이 아닌지 설명하는 역할이었다. - 특히 신뢰 지표에는 설문 결과를 넣었다.
- 89% : 사람 개입 구조 선호
- 67% : AI 답변 과신 우려
- 7개 : 확인 항목 카테고리
→ 이 숫자들은 '그럴듯한 기능'이 아니라, 실제 조사 결과를 기반으로 설계했다는 근거로 사용했다.
2) 문의 입력 화면
- 도구 페이지의 첫 화면은 문의 원문 입력이다.
- 사용자는 해외 바이어 문의 원문을 텍스트박스에 붙여 넣는다.
텍스트가 없으면 분석 버튼은 비활성화된다. - 또한 사용자가 바로 테스트해 볼 수 있도록 샘플 문의 3종을 넣었다.
- MOQ 중심 문의
- 납기 중심 문의
- 인증/품질 중심 문의
→ 샘플을 넣은 이유 : 부스나 데모 상황에서 사용자가 바로 실제 문의를 가지고 있지 않을 수 있기 때문이다.
(샘플을 통해 기능 흐름을 빠르게 체험할 수 있어야 한다고 생각했다)
- 입력 화면에는 개인정보 안내도 넣었다.
→ '입력하신 내용은 문의 분석 용도로만 사용되며, 원문은 서버에 저장되지 않습니다.'
AI 도구에서 사용자가 가장 먼저 걱정할 수 있는 지점이기 때문에, 입력 단계에서 명확히 안내하는 것이 필요하다고 봤다.
3) 로딩 화면
- 분석 버튼을 누르면 로딩 화면으로 이동한다.
- API 응답이 빨라도 최소 500ms는 로딩 화면을 유지하도록 했다.
너무 즉시 결과가 나오면 사용자가 분석이 실제로 진행됐다는 느낌을 받기 어렵기 때문이다.
(생각하는 척... 그래도 코리안 타임으로 500ms로 설정함) - 작은 디테일이지만, 사용자가 '서비스가 일을 하고 있다'라고 느끼는 흐름을 만들기 위한 장치였다.
4) 예외 화면
- 모든 입력을 바이어 문의로 처리하면 안 된다고 생각했다.
→ so, 입력 텍스트가 너무 짧거나, 문의 신호가 전혀 없거나,
7개 카테고리와 관련된 키워드가 없으면 문의로 인식하지 않도록 했다. - 이 경우에는 예외 화면을 보여준다.
→ '바이어 문의로 인식하지 못했습니다.' - 그리고 다시 입력할 수 있도록 안내한다.
- 이 기능은 데모에서는 작아 보일 수 있지만, 실제 도구처럼 보이기 위해 필요했다.
무엇을 넣어도 무조건 그럴듯한 결과를 내는 AI 도구는 오히려 신뢰도가 낮아질 수 있기 때문이다.
6. 결과 화면은 4단계 아코디언으로 구성했다
- 분석 결과 화면 4단계 구성
1. 원문 확인
2. 문의 항목 분류
3. 답변 초안 생성
4. 위험 구간 확인
→ 사용자가 무엇부터 봐야 하는지 헷갈리지 않도록 신경 썼다.
Step 1. 원문 확인
첫 번째 단계에서는 사용자가 입력한 바이어 문의 원문을 그대로 보여준다.
그리고 한국어 자동 번역을 함께 제공한다.
원문 번역은 읽기 전용이다.
사용자가 바이어 문의 내용을 먼저 이해하는 데 집중하도록 했다.
Step 2. 문의 항목 분류
두 번째 단계에서는 문의에 포함된 항목을 7개 카테고리로 분류해 보여준다.
원문에서 키워드가 매칭된 항목은 강조 표시하고, 나머지는 비활성 상태로 보여준다.
이 화면의 역할은 명확하다.
→ 이 문의에서 확인해야 할 업무 항목을 빠르게 파악하게 하기
Step 3. 답변 초안 생성
세 번째 단계에서는 영어 답변 초안을 보여준다.
초안은 언급된 카테고리별 템플릿 문장을 조합해서 생성한다.
가격, MOQ, 납기, 사양, 물류, 인증, 결제 조건 등이 언급되면 각 항목에 맞는 문장이 포함된다.
그리고 초안 안의 위험 구간은 하이라이트 된다.
체크 전에는 핑크로 표시하고, 확인 후에는 초록색으로 상태가 바뀌도록 했다.
이렇게 해서 사용자가 '내가 확인해야 할 부분'과 '이미 확인한 부분'을 구분할 수 있게 했다.
또한 이 단계에서 한국어 번역 편집기를 제공한다.
사용자는 한국어로 초안을 이해하고, 필요한 내용을 수정한 뒤,
'이 번역으로 영문 초안 수정하기' 버튼을 눌러 영문 초안을 다시 반영할 수 있다.
(Tradvance의 차별점...★)
Step 4. 위험 구간 확인
네 번째 단계에서는 위험 구간 확인 상태를 보여준다.
위험 구간이 없으면 바로 복사할 수 있다.
위험 구간이 있으면 '위험 구간 N건이 발견되었습니다'라는 안내와 함께 확인 버튼을 보여준다.
모든 위험 구간을 확인하면 상태가 초록 체크로 바뀐다.
그제야 초안 복사 버튼이 활성화된다.
 |
 |
| 전체 체크 전 → '확인 완료' 버튼 비활성화 | 전체 체크 후 → '확인 완료' 버튼 활성화 |
7. 위험 구간 확인 모달(위의 표 이미지 참고) ▲
위험 구간은 별도 모달에서 확인하도록 했다.
| 모달 정보 | ||||
| 카테고리 배지 | 원문 인용구 | 한국어 번역 | 위험 사유 | 체크박스 |
ex. 납기와 관련된 표현이 위험 구간으로 잡히면, '왜 확인해야 하는지' 짧은 설명을 함께 보여준다.
단순히 '위험합니다'라고 하면 사용자가 납득하기 어렵다.
그래서 어떤 이유로 확인이 필요한지 설명하는 구조로 만들었다.
전체 체크를 하지 않은 상태에서 확인 완료를 누르면 경고를 보여준다.
→ '모든 위험 구간을 확인해야 계속할 수 있습니다.'
이 역시 자동화보다 검토를 우선하는 설계와 연결된다.
8. 이번 MVP에 포함한 것 / 이번 MVP에서 제외한 것
| 이번 MVP에 포함한 것 | 이번 MVP에서 제외한 것 |
| • 랜딩 페이지 • 바이어 문의 원문 입력 • 문의 미인식 예외 처리 • 원문 한국어 번역 • 확인 항목 7개 카테고리 분류 • 영어 답변 초안 생성 • 한국어 번역문 수정 기반 영문 초안 재생성 • 위험 구간 하이라이트 • 위험 구간 체크리스트 모달 • 전체 확인 후 초안 복사 → '바이어 문의를 받은 뒤, 담당자가 확인하고 답변을 준비하는 흐름을 끝까지 보여주기' |
1. AI 자동 발송 : 설문에서도 자동 발송에 대한 불안감이 있었고, 프로젝트 방향과도 맞지 않았다. (Tradvance 답변 보내는 서비스 X, 답변 준비 돕는 서비스) 2. Gmail OAuth 실연동 : 편리한 기능이지만 이번 MVP의 핵심이 아니었다(인증과 보안까지 다루면 프로젝트 범위가 커져서 제외). 3. 바이어 발굴 : 처음 아이디어에는 포함되어 있었지만 제외했다. 이 영역은 Rinda, EC21, 고비즈코리아 등 기존 서비스와 겹친다. 또한 대규모 데이터베이스와 영업 자동화가 필요한 영역이라, 개인 미니 프로젝트로 검증하기 어렵다. 4. 견적/납기 자동 확정 : 가격과 납기는 회사 내부 기준과 생산 상황에 따라 달라진다. AI가 자동으로 확정하면 오히려 위험하다. 그래서 Tradvance는 값을 확정하지 않고, 확인이 필요한 위험 구간으로 표시한다. 5. 계약 클로징 지원 : 계약에 가까워질수록 사람 간 신뢰가 중요하다. 이번 MVP는 1차 문의 응대에 집중하기 때문에 계약 클로징은 범위에서 제외했다. |
9. 기능명세서를 작성하면서 느낀 점
- 기능명세 : PM의 판단을 화면 단위로 쪼개는 작업에 가깝다.
ex. '초안 복사하기 버튼' 하나에도 조건이 있다.- 위험 구간이 없으면 활성화
- 위험 구간이 있으면 전체 확인 후 활성화
- 클릭 시 클립보드 복사
- 복사 완료 후 토스트 표시
- 참여 통계 API 호출
- API 실패해도 사용자 흐름은 유지
→ 버튼 하나에도 사용자의 흐름, 데이터 기록, 예외 상황이 연결된다.
| 화면 | 핵심 기능 |
| 랜딩 페이지 (/) | 서비스 소개, 답변 초안 미리보기, 핵심 기능 3종·동작 순서 3단계 소개, 신뢰 지표(89%/67%/7개 카테고리) 통계 카드, /tool로 유입시키는 CTA |
| 입력 화면 | 바이어 문의 원문 붙여넣기, 샘플 3종 자동 채움, '분석 시작하기' → 분석 API 호출 |
| 로딩 화면 | 분석 중 스피너 + 안내 문구 (최소 0.5초 노출) |
| 예외 화면 | 문의로 인식 안 될 경우 재입력 유도 |
| 결과 화면 | 4단계 아코디언 : ①원문 확인+한글 번역 ②7개 카테고리 자동 분류 ③영문 초안 생성(위험 구간 하이라이트)+한글 번역 편집·재반영 ④위험 구간 체크 후에만 복사 가능 |
| 위험 구간 모달 | 위험 항목별 근거 설명 + 체크리스트, 전체 확인해야 닫기 가능 |
| 하단 액션 | 처음으로 / 메인으로 / 초안 복사하기(위험 미확인 시 비활성) + 복사 완료 토스트 |
| 공통 백엔드 | 키워드 기반 문의 인식·카테고리 분류·초안 생성·위험 탐지(규칙 기반, AI 미연동), 무료 번역 API, Supabase 이벤트/참여 통계 로깅 |
- 이걸 정리하다 보니 MVP가 더 명확해졌다.
사용자가 실제로 한 단계씩 진행할 수 있는 흐름을 설계해야 한다...
(쉽지 않군요..)
오늘의 인사이트
근 4일간(치료 일정 포함) 달려온 결과가 배포까지 되다니
그저 감개무량한 기분만...
배포 링크 : 🚀 Tradvance
코드로 한 땀 한 땀 장인 정신으로 빚었던 과거의 프로젝트에 비하면 아주 쉬웠다...
(과거에 작업한 게 오히려 미련해 보이는 수준.. 대박 열심히 했는데 말이죠?)
그때는 팀플이라 내가 하고 싶은 것이라기보다는 다수결 결과로 선정된 서비스였다면
이번엔 주변의 불편함을 찾아서 개선하고자 내가 처음부터 기획하고 배포까지 했다.
(정말.... 짱이다....!!!!!!!!!!)
아무튼, 설문조사 결과로 '영어를 어려워하는 유저' + '위험 구간 더블 체크'에 대한
수요를 찾아내고 서비스에 반영하는 작업은 흥미롭고 재밌었다.
그리고 작업하다 보니 LLM을 쓸 필요가 없길래(로그인 기능도 없으니까)
규칙 기반으로만 적용해서 구현했다... 굿이라고 생각한다.
(이전부터 AI 기반 기능을 기획하고 피드백받았었는데 AI를 꼭 써야 하는 이유가 있을 때만 쓰라고 하셨다...!)
오늘의 KPT 회고
| Keep | • 처음 기획한 서비스의 방향을 끝까지 끌고 가서 실제 배포까지 완료했다. • 'AI가 대신 답변하는 서비스'가 아니라 '담당자가 안전하게 검토할 수 있게 돕는 서비스'로 원칙을 명확히 잡았다. • 설문에서 확인한 두 가지 신호, 즉 영어 응대 부담과 AI 답변 과신 우려를 기능에 반영했다. • 한글 번역문을 수정하면 영어 초안이 다시 반영되도록 설계해, 영어가 익숙하지 않은 사용자도 사용할 수 있는 흐름을 만들었다. • LLM을 무조건 쓰기보다, 현재 MVP 범위에서는 규칙 기반 로직으로 충분하다고 판단한 점이 좋았다. • 기능명세서를 작성하면서 버튼, 예외 상태, 복사 조건, 위험 구간 확인 등 사용자 흐름을 더 구체적으로 정리했다. |
| Problem | • Gmail 실연동, 바이어 발굴, 자동 발송 등 매력적인 기능을 떠올렸지만, 이번 검증 목적과는 거리가 있어 계속 덜어내야 했다.(눈물을 머금고 제외했다...) • 설문 표본이 9명으로 많지 않아 실제 수출 담당자의 사용성을 충분히 검증했다고 보기는 어렵다. • 위험 구간 탐지는 규칙 기반으로 구현했기 때문에 다양한 실제 문의 유형에서 얼마나 안정적으로 작동할지는 아직 추가 검증이 필요하다. |
| Try | • 복사 완료율, 위험 구간 확인 완료율, 초안 수정 여부를 기준으로 MVP 사용성을 점검하면 좋겠다. • 부스 운영이나 추가 인터뷰에서 '확인 항목 분류'와 '위험 구간 체크리스트'가 실제로 유용한지 직접 물어보기. |
'PM Notes > 서비스 기획 및 제작 과정' 카테고리의 다른 글
| 메이커톤 Final. 미니 프로젝트 박람회 → Q&A!! (0) | 2026.07.10 |
|---|---|
| 메이커톤 Part 1. Tradvance — 해외 바이어 문의 응대 도우미 (0) | 2026.07.06 |
| 서비스 제작기) 📢 깜놀방지 - 회의 볼륨 평준화 서비스 🙉 (0) | 2026.06.17 |
