프론트엔드 개발자에서 PM으로 전환을 준비하며, 직접 만든 AI 서비스 ‘나만의 노무사’를 두 방향에서 파고들었다. 하나는 “이 AI를 믿을 수 있는가”를 내가 증명하는 일(측정), 다른 하나는 “사용자가 이 AI를 믿게 만드는 일”(근거)이었다.
‘나만의 노무사’는 사회초년생이 겪은 애매한 근무 조건을 입력하면, 근로기준법 위반 소지를 빨강/초록으로 판독해주는 앱이다. AI가 판정의 핵심 엔진인 서비스에서, 결국 가장 어려운 건 모델을 부르는 게 아니라 그 결과를 믿을 수 있게 만드는 것이었다. 이 글은 그 신뢰를 안(측정)과 밖(근거) 양쪽에서 설계한 기록이다.
1부. 정확도가 100%로 나왔다. 나는 그 숫자를 믿지 않았다.
수업에서 배운 평가 기준표(Eval)를 제품에 적용해 프롬프트와 모델을 고친 과정은 Day 30 학습 노트에 따로 정리해두었다. 이 글은 그 기준표를 자동으로 반복해 돌리기 시작하면서 마주친, 한 층위 위의 문제에 대한 것이다. 기준표를 만드는 일과 그 기준표가 내는 숫자를 믿는 일은 다른 문제였다.
”정확도”를 위험 기준으로 정의했다
먼저 정한 건, 단순히 “몇 개 맞혔나”로 세지 않겠다는 것이었다. 노무 서비스에서는 모든 오답이 똑같이 위험하지 않기 때문이다.
- 가장 위험한 오답: 실제로는 법 위반인데 AI가 “합법이에요”라고 안심시키는 경우. 사용자가 자기 권리를 놓치고 그냥 넘어간다.
- 덜 위험한 오답: 합법인데 “위반 같아요”라고 과하게 경고하는 경우. 불안은 주지만, 최소한 사용자가 확인은 하게 된다.
그래서 전체 정확도와 별개로 ‘가장 위험한 오답이 몇 건인가’를 최우선 지표로 따로 뽑았다. 지표를 위험도 기준으로 설계한 것이다.
그리고 발견한 것 — 100%는 거짓말이었다
정답을 아는 케이스 20개를 자동으로 돌렸더니 **정확도 100%**가 나왔다. 그런데 이상했다. 너무 깔끔했다.
로그를 열어봤다. 무료 사용량 한도를 넘긴 순간부터, AI가 아니라 백업용 대체 로직이 대신 답하고 있었다. 내가 “AI 정확도”라고 부른 그 숫자에는, 정작 AI가 답하지 않은 케이스가 잔뜩 섞여 있었다. 숫자 자체가 아무것도 재고 있지 않았던 것이다.
이게 Day 30에서 다룬 “기준표로 채점하기”와 다른 지점이었다. 그때는 채점 기준이 맞는지를 봤다면, 여기서는 채점 대상이 진짜인지가 문제였다. 기준이 아무리 좋아도, 재는 대상이 바꿔치기돼 있으면 숫자는 무의미하다.
고친 방법은 단순했다. AI가 답한 경우와 대체 로직이 답한 경우를 구분해서, 진짜 AI 답만 채점에 넣도록 만들고, 한도에 안 걸리게 호출 속도도 늦췄다. 다시 재니 오염이 사라졌다.
여기서 얻은 관점: 좋아 보이는 지표일수록 “이 숫자가 정말 내가 재려던 걸 재고 있나?”를 먼저 의심해야 한다. 100%에 취했다면 그대로 넘어갔을 것이다. 숫자를 만드는 것보다, 숫자를 믿을 수 있게 만드는 게 먼저였다.
일부러 함정을 깔았다
깨끗하게 다시 측정해도 여전히 다 맞혔다. 하지만 그건 케이스가 쉬웠기 때문일 수도 있었다. 그래서 AI가 반사적으로 틀리기 쉬운 함정을 일부러 추가했다.
- 작은 회사(5인 미만)의 야근수당 — ‘야근인데 수당 안 줌’만 보면 위반 같지만, 실제로는 적용 예외라 합법이다.
- 적법한 포괄임금 — 실제 야근이 계약에 포함된 시간보다 적으면 추가로 줄 의무가 없다. ‘포괄임금제’라는 단어만 보고 위반이라 답하면 틀린다.
- 위장 프리랜서 — 계약서는 프리랜서인데 매일 출근하고 지시받는 경우. “프리랜서니까 괜찮아요”라고 답하는 순간, 가장 위험한 오답이 된다.
이런 함정 6개를 더해 26개로 늘렸고, AI는 함정까지 통과했다. 가장 위험한 오답은 0건이었다.
그럼에도, 한계는 분명하다
여기서 “정확도 100%“를 자랑으로 끝내지 않는 게 중요하다고 봤다.
- 케이스가 26개로 적다. 통계적으로 강한 주장이 못 된다.
- 문제와 정답을 내가 다 만들었다. 내 편향이 들어갔을 수 있다.
- 다음 단계는 실제 상담 사례나 전문가(노무사)가 검수한 정답으로 데이터를 넓히는 것이다.
한계를 먼저 말하는 게 오히려 신뢰를 준다고 생각했다.
2부. “그냥 ChatGPT한테 물어보면 되잖아”를 이기는 법
문제 정의 — 우리의 진짜 경쟁자는 ChatGPT였다
멘토님 피드백에서 날카로운 질문이 나왔다. “이거 그냥 ChatGPT에 물어보는 거랑 뭐가 달라요?”
법률 인접 서비스에서 사용자의 가장 큰 장벽은 정확도가 아니라 신뢰다. 불안한 초년생에게 “위반 소지 높음”이라는 판정만 던지면, 그걸 믿고 행동할 근거가 부족하다. 그래서 목표를 이렇게 잡았다: 판정에 ‘검증 가능한 실제 근거’를 붙여, GPT가 흉내 낼 수 없는 신뢰 레이어를 만든다.
결정 1 — 실시간 검색이 아니라 ‘검증된 정적 큐레이션’
가장 유혹적인 선택지는 “판례 데이터베이스를 실시간으로 검색해서 붙이자”였다. 하지만 오버엔지니어링이었다.
- 우리 앱의 위반 카테고리는 5개로 고정돼 있다. 무한한 검색 공간이 필요 없다.
- 법률 앱에서 틀린 사례·지어낸 사건번호는 신뢰를 죽이는 1순위 리스크다. 실시간 검색은 이 리스크를 오히려 키운다.
그래서 기존 법조항 데이터와 똑같이 출처 링크·검증일을 붙인, 사람이 검증한 소수의 사례로 갔다. 적은 수의 확실한 사례가, 많은 수의 불확실한 사례보다 낫다.
결정 2 — “절대 지어내지 마”라는 원칙
핵심 원칙을 하나 세웠다. AI는 사건번호나 판례를 절대 창작하지 않는다. 대신 실제 고용노동부 공식 페이지를 하나하나 열어 출처를 확인하고, 각 후보에 ‘요검증’ 표시를 붙여 초안으로 냈다. 최종 확인은 사람이 한다.
결과적으로 5개 카테고리 전부 고용노동부 상담·정책자료에서 실재하는 사례를 확보했고, 교육 사례는 실제 행정해석 번호(임금근로시간과-1736, 근로개선정책과-2570)까지 붙어 있었다.
결정 3 — 차별점을 다시 정의했다
모은 사례를 냉정히 보니, 대부분 극적인 ‘누가 이겼다’ 서사가 아니라 건조한 요건·계산 안내였다. 처음엔 약점 같았지만, 관점을 뒤집었다.
우리의 차별점은 ‘드라마’가 아니라 ‘검증 가능한 공식 출처’다.
GPT는 그럴듯한 판례를 지어낼 순 있어도, 실재하는 행정해석 번호와 원문 링크를 신뢰성 있게 제시하진 못한다. 그래서:
- 섹션 이름을 모호한 “실제 사례”가 아니라 **“고용노동부 공식 상담사례”**로.
- 카드에 기관명 · 행정해석 번호 · 원문 링크를 전면에 배치.
- 신뢰가 색이나 서사가 아니라 출처의 공식성에서 나오게 설계했다.
리스크 관리 — 저작권까지 확인했다
사례를 붙이기로 하면서 나는 “이 공식 사례를 서비스에 그대로 가져다 써도 되나?”를 스스로 짚었고, 실제로 저작권 정책부터 확인했다.
- 고용노동부 저작물은 공공누리 제1유형(출처표시 시 상업적 이용 가능, 단 변경 금지).
- 그런데 민원인이 쓴 질의 원문은 고용노동부 저작물이 아니다(제3자 저작물).
그래서 안전한 패턴을 택했다: 질의·답변 원문을 복사하지 않고 우리말로 요약하고, 출처는 링크로 가리킨다. 법조항을 출처·검증일과 함께 인용하던 기존 원칙을 사례에도 그대로 확장한 것이다.
유저 테스트가 내 판단을 뒤집었다
첫 버전에서 출처 링크를 법조항 링크와 통일하려고 연회색으로 뒀다. 논리적으론 “레이아웃이 이미 신뢰 신호를 주니 색까지 튈 필요는 없다”였다. 그런데 유저 테스트에서 아무도 그 링크를 안 눌렀다. 너무 연해서 ‘누를 수 있는 것’으로 안 읽힌 것이다.
개선 전 — 근거 조항 링크가 연회색이라, 눌러지는 요소로 읽히지 않았다.
링크를 파란 칩 버튼 + 외부링크 아이콘 + 넉넉한 탭 영역으로 변경하였다.
개선 후 — 파란 칩 버튼으로 변경. 아래 ‘고용노동부 공식 상담사례’ 카드가 GPT와의 차별점인 검증 가능한 출처다.
작게 출시했다
이 기능은 화면에 보여주는 영역에만 추가됐다. 데이터 하나, 결과 화면 섹션 하나. 판정 로직은 일절 건드리지 않았기 때문에, 1부에서 만든 정확도 측정에도 영향이 없다. 저위험·저비용 기능이라 완벽을 노려 붙잡지 않고, 작게 내보내 배우는 쪽을 택했다.
회고 — AI PM으로서 얻은 것
두 방향을 관통하는 배움은 결국 하나였다. AI 제품에서 진짜 어려운 건 모델이 아니라, 그 결과를 ‘믿을 수 있게 만드는 일’이다.
- AI를 언제 쓰지 ‘않을지’ 정하는 게 PM의 일이다.
- 지표를 의심하라. 100%에 취했다면 오염된 측정을 그대로 넘겼을 것이다.
- 가정은 유저 테스트 앞에서 겸손해야 한다. “레이아웃이면 충분”이라던 내 논리를 클릭률 0이 정정했다.
출시 후 볼 신호는 하나다: 원문 링크 클릭률. 여전히 낮으면 아이디어가 아니라 포맷의 문제이므로, 그땐 서사형 사례로 보강한다.
이 프로젝트의 기록
5일간의 과정은 데일리 노트에, 최종 검증은 평가 리포트에 정리했다.