TL;DR
사무실 이전 요구사항 인터뷰는 부서별 희망사항을 모으는 자리가 아니라, 업무 조건을 좌석·회의·집중·보관·설비·보안 요구로 변환하는 과정입니다. 이전 TF는 인터뷰 전에 대상 부서, 공통 질문, 답변의 활용 범위, 최종 확인자를 정하고 같은 양식으로 기록해야 설계 입력값의 우선순위를 비교할 수 있습니다.
자유 의견만 받으면 요청의 배경과 필수 조건이 섞여, 설계 단계에서 다시 확인하는 일이 늘어납니다. 먼저 목적과 질문 항목을 정한 동일 양식으로 인터뷰해야 요구사항을 정리하기 쉽다는 요구사항 분석 가이드의 원칙을 적용할 수 있습니다. 2021 소프트웨어사업 요구사항 분석·적용 가이드 이 원칙은 사무실 이전 전용 규칙이라기보다, 요청의 근거와 변경 이력을 남기기 위한 실무적 적용입니다. 요구사항 추적성 관련 안내
인터뷰 전에 TF가 고정할 네 가지
인터뷰를 시작하기 전, TF는 각 부서에 무엇을 약속하는지 명확히 알려야 합니다. 모든 요청이 그대로 반영된다는 인상을 주기보다, 이전 공간의 조건을 판단하기 위한 자료 수집이며 건물 조건과 전체 조직의 우선순위를 함께 검토한다는 점을 안내하는 편이 좋습니다.
- 대상 범위: 이전 대상 조직, 상주·비상주 인력, 외부 상주 인력 여부를 구분합니다.
- 답변 기준 시점: 현재 상태만 묻지 말고, 이전 후 예상되는 업무 방식과 조직 운영 변화를 같은 기준으로 답하게 합니다.
- 인터뷰 참석자: 부서의 실제 업무 흐름을 아는 담당자와 최종 우선순위를 확인할 수 있는 책임자를 구분합니다.
- 결과 활용 범위: 답변이 좌석 운영, 회의공간, 보관공간, 방문객 동선, 전기·통신·공조 조건 검토에 사용됨을 사전에 공유합니다.
조직도, 부서별 인원 및 근무 형태, 현재 좌석 운영 현황은 인터뷰 전에 취합해 두는 편이 좋습니다. 이렇게 하면 인터뷰 시간을 인원 재확인에 쓰지 않고, 실제 불편과 업무 흐름을 확인하는 데 집중할 수 있습니다.
사무실 이전의 전체 의사결정 순서와 인터뷰 결과를 어느 시점에 설계 조건으로 확정할지 확인하려면 사무실 이전 설계 착수 전 결정 순서를 함께 검토할 수 있습니다.
부서장에게 같은 순서로 물을 질문
질문지는 ‘무엇이 필요합니까’로 끝나면 안 됩니다. 요청이 발생하는 업무 장면, 빈도나 시점, 함께 일해야 하는 상대, 허용할 수 없는 제약을 순서대로 확인해야 합니다. 부서마다 답변 표현은 달라도, TF가 비교할 항목은 같아집니다.
| 확인 영역 | 인터뷰 질문 | 설계 입력값으로 바꾸는 방법 |
|---|---|---|
| 현재 불편 | 업무가 지연되거나 방해받는 장면은 무엇인가 | 소음, 시선, 이동, 보관, 대기 문제로 분류 |
| 협업 관계 | 즉시 협의해야 하는 부서·역할은 누구인가 | 인접 배치 필요, 회의공간 접근성, 동선 조건으로 기록 |
| 집중 업무 | 방해를 줄여야 하는 업무와 발생 조건은 무엇인가 | 집중좌석, 조용한 회의공간, 분리 필요 여부로 정리 |
| 외부 방문 | 방문 목적, 응대 과정, 동행 필요 여부는 무엇인가 | 접견 위치, 대기, 출입 동선, 안내 필요 조건으로 전환 |
| 자료·장비 | 상시 사용하는 장비와 보관해야 하는 자료는 무엇인가 | 전력, 통신, 설치 위치, 보관 방식, 반출입 조건으로 분류 |
| 보안 | 공개하면 안 되는 업무·자료와 접근 제한 대상은 무엇인가 | 구역 분리, 출입 권한, 화면 노출, 보관 통제 조건으로 기록 |
‘회의실이 부족하다’는 답변만으로는 공간 조건을 정하기 어렵습니다. 어떤 인원이 어떤 목적의 대화를 하는지, 외부인이 참여하는지, 주변에 들리면 안 되는지, 즉시 사용해야 하는지를 추가로 확인해야 합니다. 마찬가지로 ‘개인 공간이 필요하다’는 요청도 고정 좌석 요구인지, 짧은 집중 업무를 위한 공간 요구인지, 민감한 통화를 위한 분리 요구인지를 나누어 기록합니다.
요청을 설계 언어로 번역하는 기준
인터뷰 원문은 보존하되, 설계 검토용 목록에는 요청의 종류와 우선순위를 분리해 적습니다. 특히 ‘선호’와 ‘업무상 필수’를 같은 칸에 두면 부서 간 조정이 어려워집니다.
| 구분 | 기록할 내용 | TF의 확인 질문 |
|---|---|---|
| 필수 조건 | 업무 중단, 보안 노출, 장비 운영 문제를 막기 위한 조건 | 충족하지 못하면 어떤 업무 문제가 생기는가 |
| 우선 조건 | 생산성 또는 협업에 큰 영향을 주는 조건 | 다른 대안으로 보완할 수 있는가 |
| 선호 조건 | 분위기, 개인 습관, 부서별 이용 선호 | 전체 공간 원칙과 충돌하는가 |
| 보류 항목 | 정보가 부족하거나 책임자 판단이 필요한 조건 | 누가 언제까지 확인할 것인가 |
예를 들어 방문객 응대가 많은 부서는 ‘회의실을 많이 배정해 달라’고 요청할 수 있습니다. TF는 이를 그대로 수량 요구로 옮기기보다, 방문객이 도착한 뒤 안내받고 만나는 과정, 내부 업무구역 통과 필요 여부, 자료 노출 가능성, 응대 담당자의 이동을 확인해야 합니다. 그 결과는 방문객 동선과 보안 구역의 조건이 되며, 특정 공간의 크기나 개수는 이후 전체 계획에서 검토할 항목이 됩니다.
개인정보와 보안 질문의 경계
공간 요구를 파악한다고 해서 구성원의 불필요한 개인정보까지 수집할 필요는 없습니다. 질문지에는 업무 역할, 자료 취급 방식, 장비 조건, 출입 통제 필요성처럼 공간계획에 직접 연결되는 정보만 포함하는 것이 적절합니다. 개인정보는 필요한 최소한으로 수집하고 목적을 넘어 이용하거나 제공해서는 안 된다는 안내를 기준으로 삼을 수 있습니다. 개인정보 포털 안내
따라서 주민등록번호, 건강정보, 노조 가입 여부처럼 공간 요구 판단에 필요하지 않은 정보는 인터뷰 질문에 넣지 않아야 합니다. 개인정보 포털 안내 보안 관련 답변도 개인별 민감정보 대신 ‘외부인 출입 제한 필요’, ‘화면·문서 노출 방지 필요’, ‘잠금 보관 필요’처럼 공간 조건으로 기록합니다.
인터뷰 기록을 외부 수행사와 공유해야 하는 상황이라면, 전달 자료의 범위와 처리 목적을 먼저 정리해야 합니다. 개인정보 처리와 관련된 계약 자료에는 위탁 업무의 목적·범위, 처리기간, 재위탁 제한 등을 문서로 정하는 항목이 제시되어 있습니다. 개인정보 보호 관련 계약 서식 실제 공유 범위와 관리 방식은 조직의 개인정보 담당자와 확인하는 것이 안전합니다.
인터뷰 뒤 요구사항 목록을 확정하는 법
인터뷰 직후에는 부서별 회의록을 보내는 데서 끝내지 말고, TF가 통합 요구사항 목록을 만들어야 합니다. 목록에는 요청 내용뿐 아니라 요청 근거, 영향을 받는 부서, 분류, 우선순위, 확인자, 미결 사유를 함께 남깁니다. 서로 충돌하는 요청은 숨기지 말고 ‘조정 필요’ 항목으로 표시해야 결정권자가 판단할 수 있습니다.
가상 예시로, 영업 부서는 방문객을 업무구역 안쪽에서 응대해야 한다고 답하고, 운영 부서는 외부 방문객의 내부 진입을 제한해야 한다고 답할 수 있습니다. 이때 TF가 둘 중 하나를 임의로 삭제하기보다, 방문 목적별 응대 위치를 구분할 수 있는지, 동행이 필요한 방문인지, 내부 자료 노출 구간이 어디인지를 추가 확인 항목으로 만듭니다. 이후 결정권자가 보안 원칙과 방문 응대 방식을 확정하면, 설계 담당자는 이를 동선과 구역 조건으로 반영할 수 있습니다.
최종 확인 단계에서는 각 부서에 ‘요청이 모두 반영됐는지’를 묻기보다 ‘기록된 업무 조건과 우선순위가 맞는지’를 확인받는 편이 정확합니다. 설계 단계에서 대안이 바뀔 수 있으므로, 인터뷰 결과는 확정 도면이 아니라 판단 근거로 관리해야 합니다.
마무리
사무실 이전 요구사항 인터뷰의 성패는 질문 개수보다 답변을 비교 가능한 공간 조건으로 바꾸는 방식에 달려 있습니다. 동일 질문지로 업무 불편, 협업 상대, 방문객, 보안, 장비 조건을 수집하고, 필수·우선·선호를 구분해 확인 이력과 함께 관리하면 이후 레이아웃 협의에서 재확인해야 할 쟁점을 줄일 수 있습니다. 개인정보는 업무상 필요한 최소 범위만 다루고, 보안 요청은 개인 정보가 아닌 출입·동선·보관·노출 방지 조건으로 전환하는 원칙을 유지해야 합니다.