기업 컨설팅 첫 미팅에 완성된 요구사항서는 필요 없다

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

요구사항서를 쓰다가 첫 상담을 두 번이나 미뤘습니다

빈칸을 없애려다 중요한 질문까지 놓친 경험

기업 컨설팅 업체에 처음 연락할 때는 완성된 요구사항서가 있어야 한다고 생각했습니다. 그래서 현업 인터뷰, 기능 목록, 예상 일정, 예산 범위까지 한 문서에 넣으려 했는데 담당 부서마다 표현이 달랐고, 문서를 수정하는 동안 첫 미팅은 두 번이나 미뤄졌습니다. 정작 우리에게 필요한 것은 문서의 완성도가 아니라 현재 어떤 업무에서 시간과 비용이 새고 있는지 확인하는 일이었습니다.

처음 작성한 문서는 24페이지였지만 컨설턴트가 실제로 오래 질문한 부분은 세 가지뿐이었습니다. 누가 가장 불편한지, 문제가 얼마나 자주 발생하는지, 그대로 둘 경우 어떤 손실이 생기는지였습니다. 반대로 화면 구성이나 세부 기능처럼 열심히 적어 둔 내용은 진단 결과에 따라 대부분 달라졌습니다. 이 경험 이후 저는 첫 상담 자료를 정답 문서가 아니라 대화를 시작하는 가설로 취급합니다.

• 문제 상황: 월말 보고서를 만들 때 네 부서의 데이터를 수작업으로 합쳤습니다.
• 영향 범위: 담당자 세 명이 매달 약 이틀씩 반복 작업에 투입됐습니다.
• 기존 대응: 공용 양식을 만들었지만 입력 기준이 달라 재작업이 계속됐습니다.
• 원하는 변화: 보고서 작성 시간을 줄이고 숫자의 출처를 추적하고 싶었습니다.

첫 미팅 자료에는 ‘무엇을 구축할 것인가’보다 ‘어떤 문제가 반복되고 있는가’를 먼저 적는 편이 질문의 질을 높였습니다.

서비스를 구매한다는 관점부터 바꿨습니다

기업 서비스는 물건처럼 정해진 규격만 확인하고 사는 대상과 다릅니다. 서비스의 기본 개념을 살펴봐도 생산과 소비가 맞물리는 특성이 강조됩니다. 컨설팅 역시 고객이 정보를 얼마나 솔직하고 빠르게 제공하느냐에 따라 결과가 달라지므로, 첫 문서는 납품 사양서보다 협업의 출발점에 가깝습니다.

제가 실제로 가져간 것은 네 장짜리 문제 메모였습니다

긴 제안요청서 대신 준비한 최소 자료

세 번째 일정에서 저는 24페이지 문서를 내려놓고 네 장짜리 메모만 가져갔습니다. 첫 장에는 해결하고 싶은 문제, 두 번째에는 현재 업무 흐름, 세 번째에는 관련 시스템과 데이터, 마지막 장에는 예산과 일정의 제약을 적었습니다. 모르는 항목은 억지로 채우지 않고 ‘확인 필요’라고 표시했는데, 오히려 컨설턴트가 불확실한 지점을 빠르게 찾아 질문했습니다.

특히 효과가 좋았던 것은 업무 흐름을 전문적인 프로세스 표기법 대신 평범한 문장으로 적은 일이었습니다. ‘영업 담당자가 엑셀을 메일로 보낸다 → 운영 담당자가 형식을 고친다 → 팀장이 숫자를 다시 확인한다’처럼 작성했습니다. 덕분에 회의에 참석한 사람 모두가 같은 장면을 떠올렸고, 기업 솔루션이 필요한 구간과 단순한 규칙 변경으로 해결할 구간을 구분할 수 있었습니다.

1. 한 문장 문제 정의: 누구에게 어떤 불편이 생기는지 함께 씁니다.
2. 현재 흐름 5~7단계: 사람, 파일, 승인, 시스템 이동을 순서대로 적습니다.
3. 증거 두 가지: 처리 시간, 오류 건수, 문의량처럼 확인 가능한 수치를 붙입니다.
4. 제약 조건: 개인정보, 기존 계약, 사용 불가능한 기술, 마감일을 공개합니다.
5. 미정 항목: 결정권자가 누구인지와 추가 확인이 필요한 내용을 숨기지 않습니다.

기능명보다 실제 자료 한 건이 더 유용했습니다

‘대시보드가 필요하다’는 요구만 적었을 때는 원하는 결과가 서로 달랐습니다. 그래서 개인정보를 제거한 월간 보고서와 오류가 발생한 입력 파일을 한 건씩 보여줬습니다. 컨설턴트는 이를 보고 실시간 대시보드보다 데이터 입력 규칙을 먼저 통일해야 한다고 진단했습니다. 실제 샘플은 추상적인 기능 목록보다 업무의 예외와 품질 문제를 빨리 드러냈습니다.

단, 원본 고객 정보나 직원 개인정보를 그대로 전달해서는 안 됩니다. 이름과 연락처를 가리고 식별 번호를 임의 값으로 바꾼 뒤, 파일을 열람할 사람과 보관 기간도 확인했습니다. 보안 검토가 끝나지 않았다면 화면을 공유하는 대신 구조만 설명하는 샘플을 새로 만드는 편이 안전합니다.

첫 미팅에서 요구사항보다 운영 장면을 먼저 보여줬습니다

회의 60분을 네 구간으로 나눠 써본 방식

첫 상담은 소개와 회사 설명만 듣다 끝나기 쉽습니다. 저희도 첫 15분 동안 회사 연혁과 솔루션 기능을 듣고 있었는데, 준비한 문제를 검증할 시간이 줄어드는 것이 보였습니다. 이후에는 회의 초대장에 진행 순서를 미리 적고 컨설팅 업체에도 같은 구조로 대화를 요청했습니다. 그 결과 한 시간 안에 다음 조사 대상과 담당자까지 합의할 수 있었습니다.

업무 시연에서는 정상적인 사례만 보여주지 않았습니다. 입력 형식이 다른 파일, 승인이 지연된 건, 담당자가 자리를 비웠을 때의 처리 방식도 함께 설명했습니다. 기업 솔루션은 정상 흐름보다 예외 상황에서 운영 부담이 커지기 때문에, 평소에는 어떻게 일하는가와 함께 업무가 꼬이면 누가 수습하는가를 묻는 업체가 더 신뢰할 만했습니다.

• 문제를 들은 뒤 곧바로 특정 제품부터 권하는지 살펴봤습니다.
• 현업 사용자와 시스템 관리자의 관점을 따로 질문하는지 확인했습니다.
• 구축 이후 교육, 문의 접수, 데이터 수정 책임까지 묻는지 기록했습니다.
• 모르는 부분을 추정으로 단정하지 않고 추가 진단 항목으로 남기는지 봤습니다.

부서가 섞일수록 공통 언어가 필요했습니다

저희 회의에는 운영, 영업, 재무, 정보보안 담당자가 함께 들어왔습니다. 각 부서는 같은 ‘고객 처리 완료’라는 표현도 서로 다르게 이해했습니다. 여러 전문 분야를 연결하는 접근이 왜 필요한지는 융합연계전공 사례를 다룬 기사에서도 간접적으로 확인할 수 있습니다. 기업 컨설팅에서도 부서별 용어를 하나의 업무 기준으로 번역하는 과정이 솔루션 선택만큼 중요했습니다.

회의 중에는 ‘고객 등록’, ‘처리 완료’, ‘긴급 요청’처럼 해석이 갈린 단어를 별도 목록에 적었습니다. 각 용어의 조건과 책임 부서를 한 줄로 합의하자 이후 제안서의 범위도 훨씬 선명해졌습니다. 요구사항서를 먼저 완성했다면 이런 차이를 문서 안에 감춘 채 견적만 비교했을 가능성이 큽니다.

견적은 총액보다 가정과 제외 범위를 읽어야 했습니다

비슷한 금액의 제안서가 전혀 다른 이유

상담 후 받은 두 제안은 총액 차이가 크지 않았지만 포함된 일이 달랐습니다. 한 업체는 현업 인터뷰, 업무 진단, 개선안 설계, 결과 보고회를 모두 포함했고 다른 업체는 솔루션 설정과 사용자 교육만 포함했습니다. 제목에 ‘컨설팅’이 적혀 있어도 실제 산출물은 다를 수 있으므로 가격 숫자만 나란히 놓는 비교는 의미가 없었습니다.

제가 경험한 중소 규모 프로젝트에서는 하루 워크숍이 부가세 별도 150만 원 안팎, 2주 진단이 약 700만 원대, 설정과 연동을 포함한 실행 단계가 수천만 원으로 제시됐습니다. 이는 저희 사례의 견적일 뿐 표준 가격은 아닙니다. 참여 인원, 데이터 정비 수준, 외부 시스템 연동, 보안 요구, 지방 출장 여부에 따라 금액은 크게 달라집니다. 따라서 전화로 ‘대략 얼마인가요?’만 묻기보다 같은 범위와 조건을 전달한 뒤 견적을 받아야 합니다.

• 포함 범위: 인터뷰 횟수, 대상 부서, 분석할 데이터, 교육 인원을 확인합니다.
• 산출물: 보고서, 프로세스 도식, 설정 문서, 관리자 매뉴얼의 형태를 적습니다.
• 제외 범위: 데이터 정제, 추가 개발, 라이선스, 출장비, 유지보수 비용을 분리합니다.
• 변경 기준: 요청이 늘었을 때 추가 비용을 계산하는 단위와 승인 절차를 확인합니다.
• 검수 조건: 무엇을 충족해야 작업 완료로 보는지 측정 가능한 문장으로 바꿉니다.

견적서에서 가장 먼저 볼 문장은 총액이 아니라 ‘본 금액은 다음 조건을 가정한다’와 ‘포함하지 않는다’였습니다.

처음부터 연간 계약을 선택하지 않았습니다

저희는 진단, 설계, 실행을 한 번에 계약하지 않고 첫 단계의 산출물과 중단 조건을 나눴습니다. 다만 무조건 작은 계약이 정답이라는 뜻은 아닙니다. 시스템 전환 기한이 고정돼 있거나 여러 공급사의 책임을 하나로 묶어야 하는 프로젝트는 통합 계약이 효율적일 수 있습니다. 중요한 것은 계약 규모가 아니라 각 단계에서 무엇을 확인한 뒤 다음 비용을 집행할지가 보이는가입니다.

도입 후 만족도를 가른 것은 담당자와 기록 방식이었습니다

컨설턴트의 명성보다 함께 일할 사람을 확인했습니다

제안 발표에는 경력 많은 책임자가 참석했지만 실제 업무는 다른 구성원이 맡는 경우가 있었습니다. 첫 프로젝트에서는 이 차이를 확인하지 않아 같은 설명을 반복했고 의사결정이 늦어졌습니다. 다음 계약부터는 제안 단계에서 실제 수행 책임자, 주간 회의 참석자, 기술 문의 담당자, 부재 시 대체 인력을 구분해 달라고 요청했습니다.

담당자의 역량은 자격증 개수보다 질문과 기록에서 드러났습니다. 좋은 담당자는 현업의 말을 바로 기능으로 번역하지 않고 사실, 해석, 미확인 사항을 나눠 적었습니다. 회의가 끝난 뒤에는 결정 사항과 남은 쟁점을 짧게 공유했으며, 고객이 해야 할 작업에도 담당자와 기한을 붙였습니다. 이런 운영 습관이 있는 기업 서비스는 문제가 생겨도 책임 공방보다 해결에 집중하기 쉬웠습니다.

1. 실제 투입 인력의 이름과 역할을 제안서 또는 착수 문서에 남깁니다.
2. 회의록에는 결정, 보류, 요청, 위험을 구분해 기록합니다.
3. 요청 창구는 메신저, 이메일, 업무 도구 중 하나를 기준 채널로 정합니다.
4. 주간 회의 전에 변경 요청과 비용 영향을 먼저 확인합니다.
5. 산출물 파일은 고객도 접근할 수 있는 위치에 버전별로 보관합니다.

사용자 반응은 교육 당일보다 2주 뒤에 물었습니다

교육 직후 설문에서는 대부분 만족한다고 답했지만 실제 사용 단계에서는 다른 문제가 나왔습니다. 로그인 과정이 번거롭거나 기존 엑셀의 예외 값을 옮기지 못해 사용을 포기하는 사람이 생겼습니다. 그래서 2주 뒤 사용자 다섯 명과 15분씩 이야기하며 최근 처리한 업무를 직접 보여 달라고 요청했습니다. 말로 듣는 만족도보다 마지막 로그인 시점, 기능별 사용 빈도, 우회 작업의 존재가 더 정확했습니다.

장점도 분명했습니다. 보고서 작성 시간이 줄었고 담당자가 바뀌어도 처리 이력을 찾기 쉬워졌습니다. 반면 초기 데이터 정리에 예상보다 시간이 많이 들었고, 자동화 규칙을 바꿀 때마다 관리자 검토가 필요했습니다. 솔루션 도입 효과와 새로 생긴 운영 비용을 함께 기록해야 실제 투자 가치를 과장하지 않을 수 있습니다.

• 도입 전후의 처리 시간은 같은 종류의 업무끼리 비교합니다.
• 사용자 수보다 주간 활성 사용자와 핵심 기능 사용률을 확인합니다.
• 줄어든 수작업뿐 아니라 새로 생긴 검수와 관리 시간을 계산합니다.
• 불만을 말하지 않는 사용자에게도 기존 방식으로 돌아간 이유를 묻습니다.

완성 문서 없이 시작해도 되는 범위에는 선이 있습니다

법적·보안 요건이 강하면 먼저 확정해야 할 항목

요구사항서를 완성하지 않아도 된다는 경험은 모든 프로젝트에 그대로 적용되지 않습니다. 개인정보, 금융 정보, 의료 정보처럼 민감한 데이터를 다루거나 입찰 절차를 따라야 하는 사업은 법무·보안·조달 기준을 먼저 문서화해야 합니다. 접근 권한, 데이터 보관 위치, 파기 시점, 재위탁 가능 여부처럼 사고 발생 시 책임에 영향을 주는 조건은 ‘상담하면서 정하자’고 미뤄서는 안 됩니다.

기존 시스템을 중단할 수 없는 전환 프로젝트도 예외입니다. 허용 가능한 중단 시간, 복구 목표, 데이터 이관 검증 방식, 실패 시 되돌리는 절차는 계약 전에 합의해야 합니다. 일정이 촉박할수록 기능 문서를 줄일 수는 있어도 안전과 책임의 기준까지 줄여서는 안 됩니다. GMDW 같은 전문 서비스 기업과 상담할 때도 이 항목들은 첫 미팅 메모에 별도 표시하는 편이 좋습니다.

• 법령이나 내부 규정 때문에 반드시 지켜야 하는 조건이 있는지 확인합니다.
• 외부 반출이 금지된 데이터와 마스킹 가능한 데이터를 구분합니다.
• 장애가 발생했을 때 업무가 견딜 수 있는 시간을 숫자로 적습니다.
• 기존 공급자와 신규 컨설팅 업체의 책임 경계를 표시합니다.
• 입찰 평가처럼 모든 업체에 동일하게 제공해야 할 정보는 사전에 고정합니다.

문서가 없어도 된다는 말이 준비가 없어도 된다는 뜻은 아닙니다

완성된 요구사항서 대신 필요한 것은 문제를 보여주는 증거와 의사결정 구조였습니다. 현업 인터뷰를 잡을 수 없고, 데이터 담당자가 누구인지 모르며, 예산 승인자가 회의에 참여하지 않는 상태라면 컨설턴트도 정확한 범위를 만들기 어렵습니다. 최소한 내부 책임자 한 명, 실제 사용자 두세 명, 확인 가능한 사례 한 건은 준비해야 상담이 영업 소개에 그치지 않습니다.

반대로 요구사항과 검수 기준이 이미 법적 계약 문서로 확정된 공공 입찰, 반복 구매, 규격형 솔루션 갱신이라면 완성 문서가 효율적일 수 있습니다. 제가 겪은 방식은 문제가 아직 흐릿하고 여러 부서가 얽힌 맞춤형 기업 컨설팅에 특히 잘 맞았습니다. 표준 제품 구매나 고위험 시스템 전환까지 같은 방식으로 단순화하지 않는 것, 그것이 이 후기에서 다루지 못한 가장 중요한 경계입니다.

1. 문제가 탐색 단계라면 짧은 문제 메모로 대화를 시작합니다.
2. 책임과 안전에 관한 조건은 첫 상담 전에도 문서로 고정합니다.
3. 업체의 질문을 통해 미정 항목을 찾되 최종 결정은 내부 책임자가 내립니다.
4. 프로젝트 유형이 규격 구매에 가까우면 정식 요구사항서의 효율을 다시 평가합니다.