IT 컨설팅블로그 글
IT 시스템 구축 프로젝트는 어디서 시작할까?
IT 시스템 구축 전 업무 목표, 현황, 요구사항, 담당자와 프로젝트 범위를 점검합니다.
IT 시스템 구축은 제품이나 개발 도구를 고르기 전에 어떤 업무 문제를 해결할지 확인하는 일에서 시작합니다. 현재 일이 어떻게 처리되는지, 누가 불편을 겪는지, 무엇이 달라지면 성공으로 볼지를 알아야 필요한 기능과 범위를 정할 수 있습니다.
‘통합 시스템이 필요하다’는 요청도 아직 출발점일 수 있습니다. 이 글에서는 업무 목표·현황·요구사항·담당자·범위를 착수 전에 정리하는 방법을 설명합니다. 특정 제품의 도입 효과나 전산가이의 실제 고객 성과를 가정하지 않습니다.
1. 요청한 기능을 업무 문제로 바꿔 봅니다
처음 나온 기능 이름을 바로 개발 목록으로 확정하기보다 그 기능이 필요한 상황을 확인하세요. 언제 누가 어떤 정보를 찾고, 어디서 처리가 지연되거나 다시 입력되는지 구체적인 업무 사례를 모읍니다.
예를 들어 ‘대시보드가 필요하다’는 요청은 진행 상태를 확인하기 위해 여러 문서를 대조하는 문제에서 나왔을 수 있습니다. 이는 설명용 가상 예시입니다. 실제로는 사용자와 자료를 확인해 원인을 검증해야 하며, 화면 하나를 추가하는 것이 적절한 해결책인지도 아직 열어 두어야 합니다.
| 처음 나온 요청 예시 | 먼저 확인할 질문 | 모을 자료 |
|---|---|---|
| 대시보드가 필요하다 | 누가 무엇을 판단하려는가? | 현재 보고 자료와 판단 과정 |
| 엑셀을 없애고 싶다 | 어떤 입력·계산·공유가 불편한가? | 사용 파일과 반복 작업 |
| 승인을 자동화하고 싶다 | 예외와 승인 책임은 어떻게 되는가? | 승인 단계와 반려 사례 |
| 데이터를 통합하고 싶다 | 기준 데이터와 중복은 무엇인가? | 시스템별 항목·연결 관계 |
서비스를 만들기 전에 문제와 사용자의 맥락을 이해한다는 관점은 GOV.UK의 Discovery 단계 안내에서도 참고할 수 있습니다. 정부 서비스 지침을 모든 기업 프로젝트의 의무 절차로 적용한다는 뜻은 아닙니다.
2. 현재 업무와 데이터를 함께 확인합니다
업무의 시작과 종료, 담당자 간 전달, 사용하는 자료, 예외 처리를 정리합니다. 문서상 절차와 실제 처리 방식이 다른 부분도 확인하세요. 불편하다는 의견만 모으기보다 실제 자료와 처리 사례를 함께 보면 논의할 대상을 구체화할 수 있습니다.
데이터는 입력 위치와 관리 책임, 기준으로 삼을 원본을 확인합니다. 같은 이름의 항목이라도 부서마다 뜻이 다를 수 있습니다. 필요한 자료를 검토할 때는 접근 권한과 공개 범위를 확인하고, 일반 회의 자료에 비밀번호·토큰·불필요한 개인정보를 포함하지 않습니다.
3. 목표·범위·책임을 확인 가능한 문장으로 남깁니다
‘효율을 높인다’는 목표만으로는 완료 여부를 판단하기 어렵습니다. 어떤 업무를 어떤 조건에서 처리하고 누가 결과를 확인할지 적어 보세요. 실제 측정 자료가 없다면 개선율이나 절감 금액을 임의로 채우지 말고, 앞으로 확인할 기준과 측정 방법을 정합니다.
이번에 포함할 업무와 제외할 업무, 연동과 데이터 이전의 경계를 함께 기록합니다. 아직 모르는 항목은 가정과 확인 책임자를 표시하세요. 모든 내용을 확정한 것처럼 보이게 만드는 것보다 불확실성을 드러내는 편이 다음 판단에 도움이 됩니다.
| 착수 자료 | 포함할 내용 | 다음 판단 |
|---|---|---|
| 문제·목표 정리 | 대상 사용자, 실제 사례, 기대 변화 | 해결할 문제의 우선순위 |
| 현황·데이터 목록 | 업무 단계, 자료, 담당·권한 | 변경·연동·이전의 영향 |
| 범위·검수 기준 | 포함·제외·가정, 확인할 행동 | 구현과 검수의 경계 |
| 책임·의사결정 | 승인자, 업무 담당, 운영 책임 | 미정 항목의 확인·승인 경로 |
4. 작은 검증과 다음 단계의 조건을 정합니다
모든 기능을 한 번에 확정하기 어려우면 핵심 업무 흐름이나 불확실한 연동부터 확인할 수 있습니다. 검증할 질문과 결과를 정하고, 어떤 결과일 때 다음 단계로 진행할지 합의하세요. 시연 화면이 있다는 사실과 실제 업무·데이터·권한 검증이 끝났다는 사실은 구분해야 합니다.
운영과 인계도 착수 때 검토할 항목입니다. 누가 내용을 바꾸고 계정을 관리하며 오류를 접수할지 정리합니다. 웹 기반 시스템의 화면 검수 항목은 홈페이지 오픈 전 QA 체크리스트를 참고하되, 실제 업무와 데이터·권한에 필요한 검수를 별도로 더해야 합니다.
프로젝트 착수 체크리스트
자주 묻는 질문(FAQ)
요구사항을 완벽히 정리해야 시작할 수 있나요?
처음부터 모든 내용을 확정할 필요는 없습니다. 다만 확인된 사실과 가정·미정 항목을 구분하고, 누가 어떤 자료로 언제 확인할지 남겨야 합니다. 불확실한 내용을 확정 범위처럼 전달하지 마세요.
솔루션이나 개발 기술부터 선택해도 되나요?
후보를 조사할 수는 있지만 업무·데이터·권한·운영 조건을 확인하기 전에 최종 선택을 고정하면 필요한 조건을 놓칠 수 있습니다. 선택 기준을 정리하고 실제 업무 흐름으로 적합성을 확인하세요.
외부에 맡기면 내부 담당자는 없어도 되나요?
외부 제공자가 업무의 모든 판단을 대신할 수는 없습니다. 실제 업무를 설명할 담당자, 범위와 결과를 승인할 사람, 운영할 책임을 내부에서 확인해야 합니다. 제공자와의 역할 경계도 함께 정리하세요.
전체 일정은 언제 확정하는 것이 좋나요?
범위·연동·자료 준비·검토와 승인 조건을 확인하면서 구체화해야 합니다. 근거 없이 기간을 단정하기보다 주요 의존 관계와 미정 항목을 기록하고, 단계별 산출물과 검토 일정을 협의하세요.
핵심 정리
IT 시스템 구축의 시작점은 기능 목록보다 업무 문제와 판단 기준입니다. 현황과 데이터를 확인하고, 범위·책임·검수 기준·불확실성을 정리한 뒤 다음 단계의 검증 대상을 정하세요.
현재 요청을 한 문장으로 적고 ‘왜 필요한가’, ‘무엇을 확인해야 하는가’를 덧붙여 보세요. 바로 구현할 항목과 먼저 조사할 항목을 구분하는 데 도움이 됩니다.
착수 전에 확인할 항목을 함께 정리해 보세요
해결하려는 업무 문제와 현재 사용하는 자료, 필요한 변화와 미정 항목을 비밀정보 없이 정리해 전산가이 문의하기로 전달해 주세요. 확인된 사실을 바탕으로 논의할 범위와 다음 작업을 구체화할 수 있습니다.