IT 담당자가 없을 때 먼저 해야 할 세 가지
개발회사를 찾기 전에 내부에서 정리해야 할 최소한의 내용
사내에 IT 담당자가 없어도 시스템 개발을 시작할 수 있습니다. 기술 사양은 개발 파트너와 함께 정하면 됩니다. 다만 무엇을 바꾸고 싶은지, 누가 사용할지, 무엇을 먼저 할지는 회사 안에서 먼저 정리해야 합니다. 이 세 가지만 있으면 상담의 질이 달라집니다.
개발회사부터 찾으면 왜 어려워질까
반복되는 수작업을 줄이려고 시스템을 만들기로 했습니다. 인터넷에서 개발회사 세 곳을 찾아 문의를 넣었습니다.
그런데 회사마다 묻는 것이 다릅니다. 한 곳은 원하는 기능 목록을 달라고 하고, 다른 곳은 지금 쓰는 프로그램이 무엇인지 묻고, 또 다른 곳은 예산부터 알려 달라고 합니다.
답변을 하다 보니 회사마다 조금씩 다르게 설명하게 됩니다. 돌아온 견적과 기간은 크게 다릅니다. 그런데 무엇을 기준으로 비교해야 할지 모르겠습니다.
이 상황에서 흔히 "우리가 IT를 몰라서 그렇다"고 생각하게 됩니다. 하지만 지식이 부족한 것이 원인은 아닙니다.
진짜 원인은 순서에 있습니다. 해결할 문제와 사용자, 우선순위가 정리되지 않은 상태에서 개발 방법과 견적부터 물었기 때문입니다. 개발회사도 그 정보가 없으면 각자의 방식으로 빈칸을 채워 추측할 수밖에 없습니다. 그래서 답이 제각각으로 돌아옵니다.
준비한다고 해서 모든 것이 정확해지지는 않습니다. 다만 준비할수록 견적과 일정의 불확실성이 줄어듭니다. 아래 세 가지가 그 준비의 최소 단위입니다. 순서대로 읽으시면 됩니다.
1. 만들고 싶은 기능보다 해결할 문제를 정리합니다
처음부터 상세한 기능 목록을 만들 필요는 없습니다. 그건 개발 파트너와 함께 하는 일입니다. 먼저 다음 다섯 가지에 답해 보시면 됩니다.
- 지금 어떤 업무에서 문제가 생기고 있는가
- 누가 가장 크게 불편을 겪고 있는가
- 지금은 그 일을 어떤 방법으로 처리하고 있는가
- 시간이 얼마나 들고, 실수는 얼마나 생기는가
- 시스템이 생기면 무엇이 달라져야 하는가
같은 요청도 이 답이 있느냐 없느냐에 따라 이렇게 달라집니다.
오른쪽 문장에는 기술 용어가 하나도 없습니다. 그런데도 개발회사는 이 문장만으로 무엇을 만들어야 할지 절반은 이해합니다. 중요한 것은 정확한 용어가 아니라, 지금의 불편과 원하는 변화를 구체적으로 말하는 것입니다.
2. 사용자와 가장 중요한 업무 흐름을 정리합니다
시스템은 기능을 모아 놓은 것이 아니라, 사람이 일하는 순서를 바꾸는 도구입니다. 그래서 두 번째로 정리할 것은 누가, 어떤 순서로 일하는가입니다.
- 누가 이 시스템을 사용하는가
- 어떤 순서로 업무가 진행되는가
- 그 업무는 무엇을 계기로 시작되는가
- 마지막에 무엇이 남아야 하는가
- 승인, 알림, 수정, 취소 과정이 필요한가
- 관리자와 일반 사용자가 볼 수 있는 범위가 다른가
화면을 그릴 필요는 없습니다. 이 정도의 문장이면 충분합니다.
- 영업 담당자가 새 고객을 등록합니다.
- 관리자가 담당자를 지정합니다.
- 담당자가 상담 내용을 기록합니다.
- 계약 가능성이 높아지면 팀장에게 알림이 갑니다.
네 줄이지만 여기에는 사용자 세 종류, 권한 차이, 알림 조건이 모두 들어 있습니다. 복잡한 화면 설계보다, 일이 흘러가는 순서를 적는 편이 먼저입니다.
3. 예산·일정·우선순위와 결정하는 사람을 정합니다
개발 범위는 예산과 일정에 따라 달라집니다. 그래서 세 번째로 정할 것은 이번에 실제로 가능한 조건입니다.
- 쓸 수 있는 예산의 범위
- 반드시 끝나야 하는 시점과 그 이유
- 첫 번째 버전에 꼭 있어야 하는 기능
- 나중에 추가해도 되는 기능
- 프로젝트 책임자, 최종 승인권자, 자료와 의견을 전달할 담당자
예산은 밝히는 편이 낫습니다
예산을 알려주면 비싸게 부를까 걱정되어 숨기는 경우가 있습니다. 그런데 예산을 모르면 개발회사는 범위를 정할 기준이 없습니다. 그래서 넉넉하게 잡거나 최소한으로 잡게 되고, 결국 비교하기 어려운 견적이 돌아옵니다. 정확한 금액이 아니라 범위여도 괜찮습니다. "이 정도 안에서 할 수 있는 것을 알고 싶습니다"라는 말이면 충분합니다.
기능은 세 단계로 나눕니다
| 구분 | 판단 기준 |
|---|---|
| 반드시 필요함 | 이 기능이 없으면 시작할 수 없습니다 |
| 있으면 좋음 | 편리하지만 첫 번째 버전에는 없어도 됩니다 |
| 나중에 검토함 | 실제로 써 본 뒤에 필요한지 판단합니다 |
첫 번째 버전은 완성된 제품이 아니라 실제로 써 보면서 확인하기 위한 작은 시작입니다. 한 번에 모든 기능을 만드는 것보다, 끝까지 완성할 수 있는 작은 범위를 먼저 정하는 편이 안전합니다. 나머지는 써 본 다음에 정해도 늦지 않습니다.
어떤 방식으로 만들지는 아직 정하지 않으셔도 됩니다. 기성 제품을 도입하는 편이 나은 경우도 있고, 코드를 쓰지 않는 도구로 충분한 경우도 있고, 새로 만들어야 하는 경우도 있습니다. 이건 문제와 조건을 본 다음에 정하는 일입니다. 먼저 방식을 정해 놓고 문제를 맞추면 대개 비용이 늘어납니다.
개발회사에 전달할 최소 자료
앞의 세 가지를 한 장으로 정리하면 그대로 상담 자료가 됩니다. 완성된 요구사항 정의서가 아니어도 괜찮습니다. 문서, 슬라이드, 표 어느 형식이든 상관없습니다.
| 항목 | 적을 내용 |
|---|---|
| 배경 | 왜 지금 이 프로젝트를 시작하려 하는가 |
| 문제 | 해결하려는 불편은 무엇인가 |
| 사용자 | 주로 누가 쓰는가, 몇 명인가 |
| 현재 방식 | 지금은 그 일을 어떻게 처리하는가 |
| 원하는 흐름 | 바뀐 뒤에는 어떤 순서로 일하게 되는가 |
| 필수 기능 | 이번에 반드시 있어야 하는 것 |
| 참고 사례 | 비슷하다고 느낀 서비스나 화면 |
| 희망 일정 | 언제까지, 왜 그때까지인가 |
| 예산 범위 | 이번에 쓸 수 있는 범위 |
| 담당자 | 연락 담당자와 최종 승인권자 |
| 기존 시스템 | 연결해야 하는 프로그램이 있는가 |
| 개인정보·보안 | 다루는 정보와 지켜야 할 조건 |
이 표에서 가장 자주 비어 있는 칸은 기존 시스템과 개인정보·보안입니다. 그리고 나중에 일정과 비용을 가장 크게 바꾸는 것도 이 두 칸입니다. 지금 쓰는 프로그램에서 자료를 가져와야 하는지, 고객의 개인정보를 다루는지만 미리 적어 두셔도 도움이 됩니다.
좋은 개발 파트너는 무엇을 질문할까
이 준비물은 개발회사를 고르는 기준으로도 쓰입니다. 상담에서 상대가 무엇을 먼저 묻는지 보시면 됩니다.
- 왜 지금 이 시스템이 필요한가
- 실제 사용자는 누구인가
- 지금은 그 업무를 어떻게 처리하는가
- 첫 번째 버전에서 무엇을 확인하려 하는가
- 내부에서 결정은 누가 하는가
- 공개한 뒤 운영과 수정은 누가 맡는가
- 개인정보와 보안에서 지켜야 할 조건은 무엇인가
기능과 금액을 빠르게 제시하는 것이 나쁜 신호는 아닙니다. 다만 사업의 목적과 실제 업무를 먼저 이해하려는 회사가 이후에 범위를 함께 조정하기 쉽습니다. 견적 금액이 회사마다 크게 갈리는 이유는 견적이 회사마다 두세 배씩 차이 나는 이유에서 따로 정리했습니다.
상담 전 체크리스트
개발회사에 연락하기 전에 이 열 개를 확인해 보시면 됩니다. 전부 채우지 못해도 괜찮습니다. 채워진 칸이 많을수록 상담이 짧아지고, 돌아오는 답이 서로 비교 가능해집니다.
- 해결하려는 문제를 한두 문장으로 말할 수 있다
- 가장 불편을 겪는 사람이 누구인지 안다
- 지금 그 일을 어떻게 처리하는지 설명할 수 있다
- 시스템이 생긴 뒤의 업무 순서를 네다섯 줄로 적었다
- 반드시 필요한 기능과 나중에 해도 되는 기능을 나눴다
- 이번에 쓸 수 있는 예산의 범위가 있다
- 언제까지 필요한지, 그 이유가 있다
- 사내 책임자와 최종 승인권자가 정해져 있다
- 기존에 쓰는 프로그램과 연결이 필요한지 확인했다
- 다루는 개인정보와 보안 조건을 적어 두었다
자주 묻는 질문
IT 담당자가 없어도 시스템 개발을 의뢰할 수 있나요?
가능합니다. 기술 사양은 개발 파트너와 함께 정하는 부분입니다. 회사 안에서 정해야 하는 것은 해결할 문제, 사용자, 우선순위 세 가지이고, 이건 업무를 아는 분이 가장 잘 아는 내용입니다.
개발회사에 문의하기 전에 무엇을 준비해야 하나요?
위의 한 장짜리 자료면 충분합니다. 배경, 문제, 사용자, 현재 방식, 원하는 흐름, 필수 기능, 일정, 예산 범위, 담당자를 적으시면 됩니다. 형식은 자유롭게 하셔도 됩니다.
개발 예산을 미리 정해야 하나요?
정확한 금액이 아니어도 범위는 있는 편이 좋습니다. 예산을 모르면 개발회사가 범위를 정할 기준이 없어서, 서로 비교하기 어려운 견적이 돌아옵니다. 범위를 밝히면 그 안에서 가능한 방법을 제안받을 수 있습니다.
요구사항 정의서가 없어도 상담할 수 있나요?
상담할 수 있습니다. 정의서는 상담을 거쳐 함께 만드는 문서에 가깝습니다. 다만 문제와 사용자, 우선순위가 정리되어 있으면 첫 상담에서 나오는 이야기의 깊이가 달라집니다. 이 부분은 요구사항을 정하지 못한 채 개발을 시작하면 생기는 일에서 더 자세히 다뤘습니다.
좋은 개발회사는 어떤 질문을 하나요?
기능과 금액보다 목적과 업무를 먼저 묻습니다. 왜 필요한지, 누가 쓰는지, 지금은 어떻게 하는지, 첫 번째 버전에서 무엇을 확인할지를 물어보는 회사라면 이후 범위를 조정하기도 수월합니다.
완벽한 기획서보다 명확한 문제 정의가 먼저입니다
정리하면 이렇습니다. IT 담당자가 없어도 프로젝트는 시작할 수 있습니다. 기술 사양은 개발 파트너와 함께 구체화하면 됩니다. 다만 해결할 문제와 우선순위는 회사 안에서 정해야 합니다. 이건 밖에서 대신 정해 줄 수 없는 부분입니다.
그리고 작게 시작하시면 됩니다. 작은 첫 번째 버전은 덜 만든 제품이 아니라, 판단을 위한 자료입니다. 실제로 써 본 뒤에 다음을 정하면 되돌릴 일이 줄어듭니다.
무엇을 만들어야 할지는
아직 명확하지 않아도 괜찮습니다.
지금 하고 계신 업무와 해결하고 싶은 문제부터 이야기해 주세요.
첫 번째 버전의 범위를 함께 정리해 드립니다.
상담은 60분 무료이고, 준비물은 없습니다. 영업 전화는 하지 않습니다.
따뜻한기술 · 진석개발
사람을 위한 따뜻한 디지털 경험을, 따뜻한기술이 만듭니다.
※ 본문의 고객관리·영업 담당자 사례는 여러 상담에서 자주 보이는 형태를 각색한 예시이며, 특정 고객사나 프로젝트의 내용이 아닙니다.
※ 이 글의 판단 기준은 따뜻한기술의 상담 경험을 기준으로 한 것이며, 업계 통계나 조사 결과가 아닙니다. 개발 기간과 비용은 범위·연동·보안·검수 조건에 따라 달라지므로 일반적인 수치를 제시하지 않았습니다.