Big Project · AI's EYE 33

운영 목표 달성을 위한 최소 인원 탐색: 고정 비교의 함정을 넘어

두 staffing 조건 중 더 나은 쪽을 추천하면 적정 인원 판단이 끝난 것처럼 보인다. 둘 다 목표에 못 미치거나 더 적은 인원도 충분한 경우를 놓치기 쉽다.

근거 · 프로젝트 문서 · 코드 · 테스트

1장: 고정 비교는 항상 최선의 답을 줄까?

솔라는 노트북 화면에 떠 있는 두 개의 깔끔한 보고서 양식을 나란히 띄워놓고 미간을 찌푸렸다. 하나는 ‘직원 1명 운영안’, 다른 하나는 ‘직원 2명 운영안’. 각 보고서에는 예상되는 평균 고객 대기 시간, 주문 포기율, 직원 가동률 같은 지표들이 보기 좋게 정리되어 있었다. 솔라가 받은 요청은 명확했다. 두 운영안을 비교해서 더 나은 쪽을 추천하는 것.

“언니, 이것 좀 봐봐.”

마침 옆을 지나던 루나가 솔라의 부름에 걸음을 멈췄다.

“새 매장 운영안 시뮬레이션 결과인데, 직원 1명일 때랑 2명일 때를 비교해서 추천하라는 거야. 그런데 이거, 그냥 2명이 낫다고 하면 되는 거 아냐? 뭘 더 보라는 건지 모르겠어.”

솔라의 말대로 ‘직원 2명’ 안은 거의 모든 지표에서 ‘직원 1명’ 안보다 좋아 보였다. 고객 대기 시간은 더 짧았고, 기다리다 지쳐 떠나는 고객 비율도 낮았다. 솔라의 눈에는 답이 정해진 문제를 괜히 복잡하게 묻는 것처럼 보였다.

루나는 화면을 잠시 들여다보더니, 질문을 돌려주었다.

“이 보고서의 목표가 뭘까, 솔라? 단순히 둘 중에 ‘더 나은’ 걸 고르는 게 전부일까?”

“음… 일단은 그렇지 않을까? 더 효율적인 쪽을 선택하는 거니까.”

“그럼, 이 두 가지 경우를 한번 생각해 볼래?”

루나는 책상 위의 메모지를 가져와 간단한 표를 그리기 시작했다. 위쪽에는 ‘운영 목표: 평균 대기시간 5분 이하’라고 적었다.

“첫 번째 경우. 만약 시뮬레이션 결과가 이렇게 나왔다면 어떨까?”

루나는 표의 첫 번째 줄을 채워나갔다.

운영안	평균 대기시간	목표 달성 여부
직원 1명	15분	❌
직원 2명	8분	❌

“직원 2명일 때가 1명일 때보다 대기시간이 훨씬 짧아. 하지만 우리가 세운 ‘5분 이하’라는 목표는 둘 다 만족시키지 못했어. 이럴 땐 뭐라고 추천해야 할까?”

“어… ‘2명 안이 더 낫지만, 여전히 목표에는 미달합니다’라고 해야 하나?”

솔라는 잠시 말문이 막혔다. ‘더 낫다’는 건 사실이지만, ‘추천’하기에는 찜찜한 결과였다. 어느 쪽도 정답이 아니었다. ‘1명 대 2명’이라는 틀 안에서는 마땅한 답을 찾을 수 없었다.

“그럼 두 번째 경우.”

루나는 표에 한 줄을 더 추가했다.

운영안	평균 대기시간	목표 달성 여부
직원 1명	4분	✅
직원 2명	2분	✅

“이번엔 둘 다 목표를 달성했네. 2명일 때가 1명일 때보다 대기시간이 2분 더 짧아. 이 경우엔 어때?”

“이건… 당연히 2명 안이 더 좋다고…”

솔라는 자신 있게 대답하려다 순간 망설였다.

“아니, 잠깐만. 1명만으로도 이미 목표를 달성했잖아. 굳이 인건비를 더 써가면서 2명을 투입할 필요가 없네. 이럴 땐 ‘1명이면 충분하다’고 해야지. ‘2명이 더 낫다’고 말하면 안 되는 거였어.”

그제야 솔라는 자신이 처음부터 문제의 틀을 잘못 보고 있었다는 사실을 깨달았다. 문제는 ‘A와 B 중 무엇이 더 나은가’가 아니었다.

“알겠다. 그러니까 이건 둘 중 하나를 고르는 선택 문제가 아니었네. 우리가 처음부터 던져야 할 질문은 ‘우리가 원하는 운영 목표를 만족시키는가?’ 였던 거야. 그리고 그 목표를 만족시키는 가장 효율적인, 그러니까 가장 적은 인원을 찾는 게 진짜 문제였어.”

솔라는 고개를 끄덕이며 자신의 생각을 정리했다. 평균 대기시간 5분 이하, 주문 포기율 5% 이하, 직원 가동률 90% 이하. 만약 이런 구체적인 목표들이 있다면, 단순히 주어진 두 개를 비교하는 건 의미가 없었다. 이 모든 조건을 동시에 만족시키는 ‘최소 인원’을 찾는 것이 핵심이었다.

루나는 표를 그린 메모지를 솔라 쪽으로 밀어주었다. 고정된 선택지를 비교하는 대신, 목표를 기준으로 판단의 축을 옮기는 것. 솔라는 이제 새로운 질문을 손에 쥐었다.

“좋아. 그럼 이제 질문을 제대로 바꿀 수 있겠어. ‘우리의 모든 운영 목표를 만족시키는 최소 인원은 몇 명인가?’ 라고. 그런데 언니, 이건 어떻게 찾아? 1명부터 10명, 20명… 한 명씩 다 시뮬레이션해봐야 하는 걸까? 만약에, 10명을 투입해도 목표를 달성하지 못하면 그땐 뭐라고 보고해야 해?”

고정 비교의 함정에서는 벗어났지만, 목표를 만족하는 최소 인원을 ‘탐색’하는 과정은 또 다른 막막함으로 다가왔다.

2장: 최소 인원은 어떻게 ‘찾아지는’ 걸까?

솔라는 깨끗한 A4 용지 위에 자신만의 로직을 그려보고 있었다. 왼쪽 맨 위에는 ‘직원 1명’이라는 네모 상자가, 그 아래에는 ‘시뮬레이션 실행’이, 그리고 그 옆으로는 ‘목표 달성?‘이라는 마름모가 화살표로 연결되어 있었다. 지난번 루나와 대화한 뒤로, 솔라는 ‘1명 대 2명’ 비교 보고서를 덮고 ‘최적 인원 탐색기’의 개념을 구상하는 중이었다.

하지만 솔라의 다이어그램은 금세 복잡한 미로가 되어버렸다. ‘목표 달성?‘에서 ‘No’로 빠져나온 화살표는 ‘직원 2명’ 상자로 향했고, 거기서 나온 화살표는 다시 ‘직원 3명’으로, 꼬리에 꼬리를 물고 이어졌다. 그러다 용지 한가운데에 이르러서는 화살표가 갈 곳을 잃고 허공에 멈춰 있었다. 그 끝에 솔라는 굵은 글씨로 이렇게 써두었다. ‘만약 계속 실패하면? 언제까지?’

“언니, 내가 생각한 ‘최소 인원 찾기’ 과정인데, 뭔가 이상해.”

솔라가 미완성 다이어그램을 내밀자, 옆에서 책을 읽던 루나가 고개를 돌렸다.

“1명부터 시작해서 목표를 통과할 때까지 한 명씩 늘려보는 건 알겠어. 그런데 만약 10명을 투입해도 목표 달성이 안 되면 어떡해? 11명, 12명… 계속 시도해봐야 하나? 그럼 보고서에 뭐라고 써야 해? ‘필요 인원: 무한대’ 라고 쓸 수도 없잖아.”

솔라의 질문에는 ‘어떻게든 정답 숫자를 찾아내야 한다’는 초조함이 묻어 있었다. 그녀는 시뮬레이션의 역할이 언제나 명쾌한 ‘숫자’를 제시하는 것이라고 믿고 있었다.

루나는 솔라의 다이어그램을 잠시 들여다보더니, 그 옆에 새로운 그림을 그리기 시작했다. 복잡한 화살표 대신, 간결한 단계별 목록이었다.

“솔라, 네 접근 방식은 맞아. 한 명씩 늘려가면서 확인하는 것. 컴퓨터가 바로 그 정직하고 성실한 일을 대신 해주는 거야. 우리가 그 과정을 한번 같이 따라가 보자.”

루나는 목록의 첫 줄에 ‘운영 목표’라고 적고, 지난번과 같은 세 가지 조건을 나열했다.

평균 대기시간 ≤ 5분
주문 포기율 ≤ 5%
직원 가동률 ≤ 90%

“자, 이제 시뮬레이션 진단기가 되어서 한 단계씩 검사해 보는 거야.”

루나는 첫 번째 검사 대상을 칠판에 쓰듯 적었다.

1. 직원 = 1명

시뮬레이션 결과: 평균 대기 15분, 포기율 12%, 가동률 100%
진단: 모든 목표 실패. 다음 단계로.

“1명은 턱없이 부족하네. 그럼 다음.”

2. 직원 = 2명

시뮬레이션 결과: 평균 대기 8분, 포기율 7%, 가동률 98%
진단: 모든 목표 실패. 다음 단계로.

“조금 나아졌지만, 여전히 목표 미달이야.”

3. 직원 = 3명

시뮬레이션 결과: 평균 대기 4분, 포기율 4%, 가동률 85%
진단: 모든 목표 성공.

“찾았네! 모든 조건을 처음으로 만족시키는 최소 인원은 3명이야. 그럼 탐색은 여기서 멈춰. 시스템은 이렇게 보고하겠지.”

루나는 결과 보고서의 형태를 그려 보였다.

recommended_staff_count: 3

“아하! 그러니까 그냥 무작정 계속하는 게 아니라, 조건을 만족하는 첫 번째 숫자를 찾으면 바로 멈추는구나.”

솔라의 얼굴이 환해졌다. 하지만 그녀는 곧 자신의 다이어그램 끝에 적어둔 질문을 떠올렸다.

“그런데 언니, 만약에… 매장 공간이 좁아서 최대 5명까지만 일할 수 있다는 제약이 있다면 어떡해? 3명, 4명을 넘어 5명까지 확인했는데도 계속 실패하면?”

이것이 바로 솔라가 생각한 ‘무한 루프’의 공포였다.

루나는 고개를 끄덕이며 솔라의 질문을 받았다. “아주 중요한 지점이야. 만약 우리가 정한 최대 인원인 5명까지도 목표를 달성하지 못했다고 가정해 보자.”

루나는 목록을 이어 나갔다.

4. 직원 = 4명 … 실패 5. 직원 = 5명 (최대 인원)

시뮬레이션 결과: 평균 대기 6분, 포기율 5.5%, 가동률 92%
진단: 실패. 최대 인원 도달. 탐색 종료.

“자, 5명으로도 실패했어. 우리가 정한 탐색 범위 안에는 답이 없었던 거야. 이럴 때 시스템은 억지로 ‘6명’ 같은 숫자를 만들어내지 않아.”

대신 루나는 완전히 다른 형태의 보고서를 그렸다.

recommended_staff_count: null
capacity_sufficient: false

“결과는 이렇게 나와. ‘추천 인원 없음’. 그리고 ‘수용력 부족’이라는 명확한 진단을 내리는 거지. 여기서 끝이 아니야. 왜 실패했는지 알려주기 위해 최대 인원이었던 5명의 시뮬레이션 결과, 즉 ‘평균 대기 6분’ 같은 실패 증거를 함께 보여주는 거야.”

그제야 솔라는 모든 조각이 맞춰지는 것을 느꼈다. 시뮬레이션의 역할은 어떻게든 정답을 창조하는 마법 상자가 아니었다. 정해진 규칙과 한계 안에서 목표 달성 여부를 검사하고, 그 결과를 있는 그대로 보여주는 정직한 ‘진단 도구’였다.

“알겠다. 이 시스템은 답을 모를 때 ‘모른다’고 말할 줄 아는 거였네. 추측해서 숫자를 던지는 게 아니라, ‘여기까지 찾아봤는데, 우리가 정한 목표를 만족하는 답은 없었습니다’라고 명확하게 진단해 주는 거구나. 성공 보고서든, 실패 보고서든 둘 다 의사결정에 필요한 중요한 정보인 거고.”

솔라는 더 이상 ‘무한대’의 가능성을 걱정하지 않게 되었다. 성공이든 실패든, 탐색의 끝에는 항상 명확한 진단이 기다리고 있었다. 솔라는 루나가 그린 두 종류의 보고서를 물끄러미 바라보았다. 하나는 명쾌한 숫자를, 다른 하나는 단호한 실패 선언을 담고 있었다.

“좋아. 이제 보고서가 어떻게 나오는지는 알겠어. ‘3명’이라는 추천을 받거나, ‘수용력 부족’이라는 진단을 받거나. 그런데 언니, 이 보고서를 받아든 사람은 이걸로 뭘 해야 하는 거지? ‘3명’이라고 나왔으면 그냥 3명을 배치하라는 자동 명령인 걸까? ‘수용력 부족’이라고 나오면 이 매장 오픈은 그냥 포기해야 하는 거고?”

숫자를 ‘찾는’ 방법은 알았지만, 그 숫자를 ‘사용하는’ 방법에 대한 새로운 질문이 떠올랐다.

3장: 숫자는 명령이 아닌 운영안이다

솔라는 책상 위에 두 개의 가상 보고서를 나란히 두고 펜 끝으로 톡톡 건드리고 있었다. 하나는 시뮬레이션이 성공적으로 답을 찾은 경우였다. 선명한 제목 아래 ‘추천 인원(recommended_staff_count): 3’이라는 결론이 적혀 있었다. 다른 하나는 실패 보고서였다. ‘추천 인원: 없음(null)’, 그리고 그 아래에 ‘수용력 부족(capacity_sufficient: false)’이라는 붉은색 진단이 명시되어 있었다.

솔라는 이 두 보고서를 바탕으로 최종 운영안을 작성해야 했다. 그녀는 새 문서 파일을 열고 키보드 위에 손을 올렸다. 하지만 첫 문장을 쓰지 못하고 망설였다. ‘3명’이라고 나온 보고서에 대해서는 ‘시뮬레이션 결과, 3명 배치가 최적입니다.’라고 쓰면 될까? ‘수용력 부족’이라고 나온 경우는? ‘현 매장 구조로는 운영이 불가능합니다.’라고 단정하면 되는 걸까? 뭔가 너무 기계적이고 단편적인 결론 같았다. 숫자를 찾는 법을 알게 되자, 이제는 그 숫자의 무게가 솔라를 짓눌렀다.

“언니, 이것 봐.”

고민하던 솔라가 옆자리의 루나를 불렀다. 루나는 솔라가 띄워놓은 빈 문서와 그 옆의 두 보고서를 번갈아 보았다.

“보고서를 어떻게 써야 할지 모르겠어. 시뮬레이션이 ‘3명’이라는 답을 줬는데, 이걸 그대로 ‘3명을 투입하세요’라는 명령처럼 전달하는 게 맞나 싶어. ‘수용력 부족’은 더 심각하고. ‘이 매장은 열면 안 됩니다’라는 사형선고 같잖아.”

솔라의 말에는 지난번과 다른 종류의 막막함이 묻어 있었다. 이제 그녀는 시뮬레이션이 어떻게 답을 ‘찾는지’는 이해했지만, 그 답을 어떻게 ‘사용해야’ 하는지 몰랐다. 계산된 숫자는 그 자체로 완결된 사실처럼 보였고, 그 무게를 감당하며 인간의 언어로 번역하는 일이 어렵게 느껴졌다.

루나는 솔라의 화면을 잠시 들여다보더니, 고개를 끄덕였다. 그리고는 솔라의 책상에서 깨끗한 메모지 한 장을 가져와 전혀 다른 양식을 그리기 시작했다. 맨 위에는 ‘신규 매장 운영안 최종 검토서’라고 썼다.

“솔라, 네가 지금 쓰려는 보고서의 최종 독자가 누구일까? 아마 현장 경험이 풍부한 본사 슈퍼바이저겠지. 그 사람은 시뮬레이션 숫자를 맹목적으로 따르는 사람이 아니야. 오히려 그 숫자를 중요한 참고 자료로 삼아서 더 나은 결정을 내리는 사람이지.”

루나는 메모지에 몇 가지 항목을 더 적어 넣었다.

신규 매장 운영안 최종 검토서 (판교점)

시뮬레이션 진단 결과:
- [ 여기에 시뮬레이션 보고서 내용을 기입 ]
현장 맥락 및 특이사항 (Supervisor’s Notes):
- 인근에 대규모 오피스 단지가 있어 평일 점심시간 수요가 폭증할 가능성.
- 경쟁사 매장이 300m 거리에 새로 입점 예정.
- 매장 구조상 특정 위치에서 병목 현상 발생 우려.
종합 검토 의견:
- [ ] 승인
- [ ] 조건부 승인 (의견: )
- [ ] 보류 (재검토 요청 사항: )
최종 결정:
- 운영 인력: __명

“만약 슈퍼바이저가 솔라 네가 만든 보고서를 받는다면, 그들의 머릿속은 이런 프레임으로 작동할 거야. 자, 아까 그 두 가지 경우를 이 검토서에 넣어서 다시 생각해 볼까?”

루나는 첫 번째 성공 보고서, ‘추천 인원: 3명’을 검토서의 1번 항목에 넣는 시늉을 했다.

“시뮬레이션은 ‘3명’을 추천했어. 평균적인 상황에서는 이게 가장 효율적인 숫자라는 강력한 신호지. 하지만 슈퍼바이저는 2번 항목을 보며 생각할 거야. ‘아, 이 매장 옆에는 오피스 단지가 있었지. 시뮬레이션의 평균 수요 예측보다 점심시간에 손님이 훨씬 몰리겠구나. 3명으로는 어림도 없겠는데? 점심 피크 타임에는 1명을 더 추가해서 4명으로 운영하고, 나머지 시간은 3명으로 운영하는 탄력적인 안이 필요하겠어.’ 이렇게 말이야.”

솔라의 눈이 동그래졌다. ‘3’이라는 숫자는 사라지지 않았다. 대신 절대적인 명령에서 유연한 기준점이자 논의의 시작점으로 그 역할이 바뀌었다.

“그럼, 실패 보고서는?”

솔라가 ‘수용력 부족’이라고 적힌 두 번째 보고서를 가리키며 물었다.

“이것도 마찬가지야. 슈퍼바이저는 1번 항목에 ‘수용력 부족’이라는 진단을 확인하겠지. 하지만 그걸 보고 바로 ‘이 매장은 포기’라고 결정하지 않아. 오히려 ‘왜 수용력이 부족할까?’를 파고들 거야.”

루나는 검토서의 다른 항목들을 짚어가며 설명했다.

“‘아, 최대 인원 5명을 넣어도 평균 대기시간 5분 목표를 달성 못 하는구나. 그런데 이 매장은 위치가 너무 좋아서 포기하기 아까워. 그렇다면 목표를 수정해볼까? 오픈 초기에는 대기시간 목표를 7분으로 완화하고, 대신 고객들에게 할인 쿠폰을 제공하는 건 어떨까? 아니면, 매장 구조를 바꿔서 병목 현상을 해결하면 5명으로도 가능하지 않을까?’ 이런 식으로 말이야. 실패 진단은 끝이 아니라, 새로운 질문을 던지는 출발점이 되는 거지.”

그제야 솔라는 모든 조각이 맞춰지는 것을 느꼈다. 시뮬레이션의 결과는 자동 배치 명령이나 사형선고가 아니었다. 그것은 인간의 더 깊은 통찰과 경험을 이끌어내기 위한, 아주 잘 만들어진 ‘의제’였다. 숫자는 인간의 판단을 대체하는 것이 아니라, 오히려 인간의 판단을 더 정확하고 창의적인 방향으로 돕는 역할을 했다.

“알겠다…!”

솔라는 낮게 탄성을 질렀다.

“시뮬레이션 보고서는 정답지가 아니라 문제지였구나. 우리가 풀어야 할 진짜 문제를 가장 명확하게 보여주는. 그래서 슈퍼바이저 같은 전문가가 보고 ‘음, 이 문제를 풀려면 이런 것들을 더 고려해야겠군’ 하고 생각하게 만드는 거였어.”

솔라는 루나가 건네준 검토서 양식을 잠시 바라보다가, 다시 자신의 키보드로 손을 옮겼다. 아까와는 달리 망설임이 없었다. 그녀는 이전에 쓰려던 무미건조한 문장들을 모두 지우고 새로운 문장을 써 내려가기 시작했다.

이것은 더 이상 단순한 결과 전달이 아니었다. 시뮬레이션의 진단을 바탕으로, 최종 의사결정자가 현명한 판단을 내릴 수 있도록 돕는 잘 짜인 ‘운영안’ 초안이었다.

To: 운영 총괄 슈퍼바이저

Re: 판교점 신규 매장 운영안 제안

1. 시뮬레이션 기반 인력 분석 결과

시나리오 A (기본 수요 모델): 평균 대기 5분, 포기율 5%, 가동률 90% 이하 목표를 모두 만족하는 최소 인원은 3명으로 진단되었습니다. 이는 표준 운영의 효율적인 기준점으로 삼을 수 있습니다.

시나리오 B (매장 최대 수용 인원 5명 제한): 동일 목표 하에 시뮬레이션한 결과, 5명을 투입해도 평균 대기시간 목표(6.2분)를 달성하지 못하여 **‘수용력 부족’**으로 진단되었습니다.

2. 검토 및 후속 조치 제안

(시나리오 A 관련) 추천된 3명은 평균적인 상황을 가정한 것이므로, 실제 운영 계획 수립 시 인근 오피스 단지의 점심 피크 타임 등 국소적인 수요 변동을 고려한 인력 증원 계획(예: 피크 타임 +1명)을 추가로 검토해야 합니다.

(시나리오 B 관련) ‘수용력 부족’ 진단은 현재의 목표와 제약 조건 하에서는 운영이 어렵다는 의미입니다. 따라서, ① 대기시간 목표를 7분으로 현실화하거나, ② 매장 내 동선 개선을 통해 처리 용량을 높이는 방안을 우선적으로 논의할 것을 제안합니다.

위 분석을 바탕으로 최종 운영안을 확정해 주시기 바랍니다.

문서를 완성한 솔라는 화면을 루나에게 보여주었다. 루나는 보고서를 조용히 읽어 내려가더니, 솔라를 보며 희미하게 미소 지었다. 숫자를 찾는 것에서 시작된 여정은, 마침내 그 숫자를 인간의 지혜와 연결하는 마지막 다리를 완성하며 끝을 맺었다.