현장의 언어로 시작하기 — 학원 운영 SW 기획, 첫 미팅에서 배운 것

학원 운영 관리 시스템을 만들기로 한 첫 미팅 자리. 테이블 건너편의 원장님은 커피를 한 모금 마시고 이렇게 말했다. "수강생 관리랑 스케줄, 그리고 정산을 한 번에 할 수 있으면 좋겠어요." 짧고 명료한 문장이었다. 그리고 나는 그 문장을 받아 적지 않았다.

"한 번에"라는 말의 무게

기획을 처음 할 때 가장 빠지기 쉬운 함정은, 고객의 요청을 기능 목록으로 번역해 버리는 일이다. "수강생 관리" → 학생 CRUD. "스케줄" → 캘린더. "정산" → 결제 모듈. 받아 적고 나면 일이 명확해진 기분이 든다. 그런데 그 명확함은 가짜다.

원장이 말한 "한 번에"는 세 개의 기능을 합치라는 뜻이 아니라, 지금 세 군데로 흩어진 업무 때문에 매일 똑같은 정보를 세 번 입력하고 있다는 비명에 가깝다. 학생이 한 명 등록되면 출석부에 적고, 엑셀 스케줄에 반영하고, 수기 장부에 수강료를 또 적는다. "한 번에"는 기능 통합이 아니라 중복 입력의 고통이었다. 이걸 구분하지 못하면, 우리는 엑셀 세 개를 화면 세 개로 옮긴 시스템을 만들고 만다.

요청을 받지 말고, 하루를 따라가라

그래서 나는 첫 미팅에서 기능을 묻는 대신 다른 걸 부탁했다. "원장님 출근하시는 아침 9시부터, 퇴근 전까지 하루를 그냥 옆에서 지켜봐도 될까요?"

이게 이번 주에 얻은 가장 큰 교훈이다. 기획자는 요청을 수집하는 사람이 아니라, 문제를 발굴하는 사람이다. 사람들은 자기가 매일 하는 일을 정확하게 설명하지 못한다. 너무 익숙해서 어떤 단계는 생략하고, 어떤 불편은 "원래 그런 거"로 받아들여 아예 입에 올리지도 않는다.

실제로 하루를 따라가 보니, 원장이 미팅에서 한 번도 언급하지 않은 장면들이 쏟아졌다.

• 상담 전화를 받으면서 동시에 빈 시간대를 확인하느라 엑셀 두 개를 번갈아 띄우는 모습
• 결석한 학생의 보강을 잡아주려고 다른 반 정원을 손가락으로 세는 모습
• 월말에 미납자를 추리려고 장부와 입금 내역을 한 줄씩 대조하는 모습

이 중 어느 것도 "수강생 관리, 스케줄, 정산"이라는 세 단어에는 담겨 있지 않았다. 정작 시스템이 풀어야 할 진짜 문제는 말로 표현되지 않은 그 틈새에 있었다.

솔루션이 아니라 가설을 들고 돌아온다

미팅이 끝날 무렵, 원장님이 기대 섞인 얼굴로 물었다. "그래서 엑셀을 다 대체할 수 있는 거죠?"

여기서 솔직히 고백하면, "네, 물론이죠!"라고 답하고 싶은 충동이 강했다. 그게 그 자리에서 가장 듣기 좋은 말이니까. 하지만 첫 미팅에서 솔루션을 약속하는 건, 아직 보지도 않은 환자에게 처방전을 써주는 것과 같다. 그래서 나는 약속 대신 이렇게 말했다.

"엑셀을 대체하는 게 목표가 아닐 수도 있어요. 원장님이 엑셀로 무엇을 하시는지를 먼저 보고, 그중 진짜 아픈 지점부터 풀어드리는 게 순서일 것 같습니다. 다음에 뵐 때는 제가 답이 아니라 질문 몇 개를 더 들고 올게요."

데모를 만들거나 와이어프레임을 그리는 건 그다음 일이다. 화면을 먼저 그리면, 우리는 그 화면을 정당화하기 위해 현장을 끼워 맞추게 된다. 순서가 거꾸로다. 관찰이 먼저, 가설이 그다음, 화면은 맨 나중이다.

그날 내가 사무실로 들고 온 건 기능 명세서가 아니라 검증해야 할 가설 몇 줄이었다.

• 가설 1. 가장 큰 고통은 "기능 부재"가 아니라 "중복 입력"이다.
• 가설 2. 스케줄과 정산은 별개 기능이 아니라, 출석이라는 한 사건에서 파생된다.
• 가설 3. 원장이 말한 우선순위와 실제 시간을 가장 많이 쓰는 업무는 다르다.

이 가설들은 2주차 인터뷰에서 하나씩 깨지거나 단단해질 것이다. 그게 기획의 진짜 시작이다.

같은 실수를 피하려는 분들께

첫 미팅을 앞두고 있다면, 다음 세 가지만 기억해도 절반은 성공이다.

• 고객의 단어를 기능으로 번역하지 말 것. "한 번에"가 무엇으로부터의 해방인지 되물어라.
• 회의실이 아니라 현장에서 정보를 얻을 것. 사람은 자기 일을 설명하는 데 서툴다. 행동을 관찰하라.
• 첫 미팅에서 솔루션을 약속하지 말 것. 가지고 돌아와야 할 건 처방전이 아니라 잘 벼린 질문이다.

이 글에서 얻어갈 것

• 고객의 요청은 기능 명세가 아니라, 말로 다 못 한 고통의 신호다.
• 요구사항은 회의실에서 수집하는 게 아니라 현장의 하루를 따라가며 발굴한다.
• 첫 미팅의 산출물은 솔루션 약속이 아니라 검증 가능한 가설이어야 한다.