원본: SOL_CASE_STUDY.md

끼리(KKIRI) 케이스 스터디

작성일: 2026-09-04
사례 유형: 가상 시뮬레이션 — 실제 고객 성과가 아님
주제: 4인 팀의 반나절 워크숍 결정

1. 사례를 왜 만들었나

이 케이스는 “AI 대리인이 협상한다”는 말을 제품 규칙과 화면으로 검증하기 위한 설계 사례다. 실제 사용자 조사, 완료 시간, 만족도 개선을 주장하지 않는다. 숫자는 합의 엔진의 선택 과정을 설명하기 위해 만든 입력과 계산 결과다.

2. 상황

한 스타트업의 4인 성장팀이 다음 주 팀 워크숍을 정해야 한다. 팀장은 단톡방에 의견을 물었지만 답은 아무거나 좋아요와 이모지만 남았다. 공개적으로 말하기 어려운 조건은 다음과 같다.

팀장이 이 사유를 알 필요는 없다. 합의안은 조건을 지키되, 누구의 조건인지 밝히지 않아야 한다.

3. 참가자별 비공개 입력

아래 이름과 조건은 모두 가상이다.

참가자 하드 제약 가장 중요한 선호 양보 가능한 것
민 반나절, 서울 아이디어 발굴 야외 여부
준 격한 야외 활동 제외 팀워크 지역
서 1인 예산 상한 7만원 재충전 활동 강도
현 서울 또는 대중교통 60분 안 팀워크 반나절/하루

공개 화면에는 위 표가 나타나지 않는다. 각 참가자는 자기 행만 개인 화면에서 확인한다.

4. 후보안

후보는 방장의 입력 범위와 운영 가능한 워크숍 카탈로그에서 만든다.

후보 형식 예상 시간 위치 활동 특성
A. 성수 팀 미션 데이 협업 미션 + 회고 + 식사 반나절 서울 성수 실내 중심
B. 양평 리트릿 아이디어 세션 + 산책 + 식사 하루 경기 양평 이동 포함
C. 한강 아웃도어 챌린지 팀 스포츠 + 피크닉 반나절 서울 한강 격한 야외 활동
D. 사내 회의실 워크숍 아이디어 세션 + 배달 식사 반나절 사무실 업무 환경과 동일

예산 액수는 실제 견적이 없으므로 후보 표에 넣지 않았다. 엔진은 운영자가 확인한 견적 데이터가 있을 때만 예산 하드 제약을 판정한다.

5. 1차 계산: 하드 제약 필터

후보 판정 이유
A. 성수 팀 미션 데이 통과 반나절, 서울, 실내 조건 충족. 예산은 견적 확인 필요
B. 양평 리트릿 제외 반나절과 서울 이동 조건 위반
C. 한강 아웃도어 챌린지 제외 격한 야외 활동 제외 조건 위반
D. 사내 회의실 워크숍 통과 일정·이동·활동 조건 충족. 예산은 견적 확인 필요

예산 견적이 없는 상태에서 A와 D를 바로 확정하면 안 된다. 실제 제품은 예산 확인 필요 상태를 표시하고 방장에게 후보별 견적 입력을 요청한다. 이 케이스에서는 두 후보 모두 1인 7만원 이하라는 시뮬레이션 입력을 추가한 뒤 다음 계산으로 간다.

6. 2차 계산: 공정성 우선 순위

만족도는 0~100의 시뮬레이션 값이다. 실제 제품에서는 선호별 가중치와 후보 속성의 일치도를 이용해 같은 입력에 같은 결과가 나오도록 계산한다.

후보 민 준 서 현 최저 만족도 평균 만족도
A. 성수 팀 미션 데이 84 76 73 82 73 78.75
D. 사내 회의실 워크숍 88 62 55 78 55 70.75

선택 규칙은 다음 순서다.

  1. 하드 제약 위반이 0인 후보만 비교한다.
  2. 최저 만족도가 높은 후보를 고른다.
  3. 최저 만족도가 같으면 평균 만족도가 높은 후보를 고른다.
  4. 그래도 같으면 운영 부담이 낮은 후보를 고른다.

A의 최저 만족도는 73, D는 55다. 따라서 A를 1순위로 제안한다. D의 민 점수 88이 더 높아도, 준과 서에게 크게 불리하므로 다수 평균만으로 밀어붙이지 않는다.

7. 대리인 협상 로그

사용자에게 에이전트의 긴 대화를 그대로 보여주지 않는다. 개인 정보가 새거나 설명이 산만해질 수 있기 때문이다. 화면에는 아래 네 단계만 보여준다.

1. 하드 제약 확인
   → 일정·이동·활동 조건을 어긴 후보 2개 제외

2. 가장 불리한 사람 확인
   → 남은 후보의 최저 만족도 73 대 55

3. 양보 범위 확인
   → 야외 여부와 하루 일정 선호는 양보 가능

4. 공개 설명 생성
   → 개인을 특정하지 않는 집단 이유만 작성

이것이 “AI끼리 협상한다”의 제품 표현이다. 내부에서는 각 대리인이 자기 사용자의 조건을 평가하고, 조정자는 하드 제약과 공정성 규칙으로 결과를 합친다.

8. 공개 결과 화면

합의 제안

성수 팀 미션 데이
반나절 안에 협업과 재충전을 함께 담은 안

이 안을 제안한 이유

가장 가까운 대안

사내 회의실 워크숍은 일정과 이동 조건은 지키지만, 재충전과 팀워크 선호의 편차가 더 큽니다.

공개 결과에는 “누가 이동이 어렵다”, “누가 활동을 피해야 한다”는 문장을 쓰지 않는다.

9. 개인 합의 영수증

각 참가자는 자기 화면에서만 아래와 같은 결과를 본다.

민의 화면

준의 화면

서의 화면

현의 화면

10. 최종 재확인

이 사례의 시뮬레이션 응답은 다음과 같다.

응답 인원
동의 3
조건부 동의 1
재조정 요청 0

조건부 동의의 공개 조건은 시작 시간을 오후 1시 이후로 확정이다. 이는 특정 참가자의 사유가 아니라 실행 조건으로만 표시한다. 방장이 시작 시간을 반영하면 4명 전원이 확인한 상태로 결정 완료가 된다.

11. 재조정이 필요한 실패 분기

만약 한 참가자가 예산 상한이 반영되지 않았다고 재조정을 요청하면:

  1. 집단 화면에는 1명이 새 조건을 추가했습니다만 표시한다.
  2. 요청자의 이름과 원문은 숨긴다.
  3. 예산 견적이 확인되지 않은 후보는 잠정 제외한다.
  4. 가능한 후보가 0개면 AI가 그럴듯한 결과를 만들지 않는다.
  5. 방장에게 예산 상한을 올리기, 프로그램 구성을 줄이기, 새 후보를 추가하기의 세 가지 조정 선택지를 보여준다.
  6. 조건이 바뀌면 모든 참가자가 새 결과를 다시 확인한다.

실패를 숨기지 않는 것이 신뢰 장치다. “합의 불가”는 제품 오류가 아니라 현재 조건의 정직한 결과일 수 있다.

12. 발표 시연 시나리오

아래 시간은 실제 성능 측정이 아니라 4분 발표 리허설 구성안이다.

구간 시연 말할 것
0:00~0:35 워크숍 방 생성 “공개 투표가 아니라 말하기 어려운 조건을 받습니다.”
0:35~1:20 참가자 1명의 비공개 입력 “이유는 쓰지 않아도 되고, 조건만 구조화합니다.”
1:20~1:45 나머지 3명 제출 상태 자동 채움 “데모의 다른 참가자는 시뮬레이션입니다.”
1:45~2:20 합의 계산 4단계 “하드 제약을 먼저 빼고, 최저 만족도를 비교합니다.”
2:20~3:05 공개 결과와 대안 “누구의 사유인지 공개하지 않습니다.”
3:05~3:35 개인 합의 영수증 “각자는 자기 조건의 반영과 양보만 봅니다.”
3:35~4:00 최종 재확인 “추천이 아니라 전원 확인에서 합의가 끝납니다.”

13. 이 사례가 증명하는 것과 못 하는 것

증명하는 것

증명하지 못하는 것

이 다섯 가지는 12개 팀 파일럿에서 측정해야 한다. 파일럿 전에는 성과 주장으로 바꾸지 않는다.

14. 제품에 남길 교훈

  1. AI의 말솜씨가 아니라 합의 규칙이 제품이다.
  2. 비공개는 카피가 아니라 권한 설계와 결과 분리로 증명해야 한다.
  3. 추천 결과가 나와도 사람이 다시 동의하기 전에는 합의가 아니다.
  4. 가능한 안이 없으면 없다고 말해야 한다.
  5. 현재 데모는 시연 자산이며 실제 다자간 합의의 증거가 아니다.

15. 근거