기업용 웹·앱 개발 비용은 어떻게 결정되는가

견적서를 두 장 받아 놓으면 대개 같은 곳에서 막힙니다. 금액이 다르다는 것은 보이는데, 왜 다른지가 보이지 않습니다. 낮은 쪽이 효율적인 설계 덕분인지 범위를 좁게 잡은 결과인지, 높은 쪽이 더 많은 일을 담은 것인지 여유를 크게 잡은 것인지 가를 근거가 없습니다.

빌드업웍스도 고객에게는 견적을 내는 여러 곳 중 하나입니다. 그래서 아래에 적은 확인 항목은 저희 견적서에도 똑같이 적용하시면 됩니다. 특정 업체를 가려내기 위한 기준이 아니라, 모든 견적을 같은 축에 올려놓기 위한 기준입니다.

같은 요구사항이 같은 범위를 뜻하지는 않습니다

요구사항 한 줄은 업체마다 다른 범위로 읽힙니다. 문장이 같아도 그것을 만들 수 있는 형태로 풀어내는 과정에서 서로 다른 가정이 들어가고, 견적은 문장이 아니라 그 가정 위에서 계산됩니다.

“재고를 관리할 수 있어야 한다”는 한 줄을 예로 들어 보겠습니다. 한쪽은 이 문장을 품목과 수량을 입력하고 수정하는 화면 하나로 읽을 수 있습니다. 다른 쪽은 입고·출고·조정 이력이 각각 남고, 창고별로 수량이 나뉘고, 담당자와 관리자가 볼 수 있는 범위가 다르고, 지금 쓰는 엑셀 데이터를 옮겨 오고, 발주 쪽과 수량을 주고받는 구조까지로 읽을 수 있습니다.

둘 중 어느 쪽도 요구사항을 어긴 것이 아닙니다. 그 문장이 차이를 담고 있지 않았을 뿐입니다. 그리고 두 해석 사이의 작업량 차이는 문장의 길이 차이보다 훨씬 큽니다.

받는 쪽에서 이 격차를 줄이는 방법은 문장을 길게 쓰는 것이 아니라 가정을 드러내게 하는 것입니다. 각 업체가 그 한 줄을 무엇으로 읽었는지가 견적서에 적혀 있는지 확인하면 됩니다. 적혀 있지 않다면 그것부터 물어보는 것이 금액을 묻는 것보다 먼저입니다.

개발 비용을 움직이는 다섯 가지 변수

개발 비용을 실제로 움직이는 것은 화면의 개수가 아니라 역할·권한의 복잡도, 외부 시스템 연동, 기존 데이터의 이관 상태, 요구되는 보안 수준, 그리고 만든 뒤의 운영 주체입니다. 견적서를 나란히 놓았을 때 이 다섯 축에서 서로 다르게 잡혀 있다면 금액 차이의 상당 부분은 거기서 설명됩니다.

① 사용자 역할과 권한의 복잡도 — 같은 데이터를 보는 사람이 한 종류인지 여러 종류인지가 작업량을 크게 가릅니다. 역할이 하나면 화면 하나로 끝나지만, 역할이 늘어나면 누가 무엇을 보고 무엇을 고칠 수 있는지를 정의하고, 화면마다 그 규칙을 적용하고, 규칙이 실제로 지켜지는지 확인하는 일이 따라붙습니다. 외부 협력사나 고객사 계정까지 들어오면 조직 경계를 넘는 권한 설계가 추가됩니다. 견적서에서는 역할의 종류가 몇이고 각 역할이 무엇을 할 수 있는지가 적혀 있는지를 봅니다.

② 외부 시스템 연동의 개수와 방식 — 연동은 개수보다 상대편의 상태가 비용을 결정합니다. 상대 시스템이 외부에서 데이터를 읽고 쓸 수 있게 통로를 열어 둔 경우가 있는데 이를 흔히 API라고 부릅니다. 이 통로가 있고 사용법이 문서로 정리돼 있는 상대와, 담당자만 아는 데이터베이스를 직접 읽어야 하는 상대는 같은 “연동 1건”이 아닙니다. 상대 시스템의 응답이 느리거나 실패했을 때 무엇을 어떻게 되돌릴지, 양쪽 데이터가 어긋났을 때 어느 쪽을 맞는 것으로 볼지까지 정해야 실제로 쓸 수 있는 연동이 됩니다. 견적서에서는 연동 대상의 이름과 연동 방식, 그리고 실패했을 때의 처리가 적혀 있는지를 봅니다.

③ 기존 데이터의 이관 상태 — 지금 쓰는 데이터가 얼마나 정리돼 있는지가 이관 비용을 결정합니다. 같은 거래처가 표기만 다르게 여러 번 들어 있거나, 한 칸에 여러 정보가 섞여 있거나, 필수 항목이 비어 있는 상태라면 옮기기 전에 정리하는 일이 먼저 필요합니다. 이 정리를 누가 하는지는 요청서에 없으면 견적서에도 잡히지 않습니다. 그러면 나중에 양쪽 모두 상대가 할 것이라고 생각하고 있었던 상황이 됩니다. 저희 견적서에서도 이 칸이 비어 있다면 같이 물어보셔야 하는 자리입니다. 견적서에서는 이관 대상의 범위와 정리 작업의 주체가 적혀 있는지를 봅니다.

④ 요구되는 보안 수준 — 보안은 있고 없고가 아니라 정도의 문제이고, 그 정도가 곧 작업량입니다. 통신 구간 암호화와 기본적인 접근 통제는 어느 시스템에나 들어가지만, 저장 데이터 암호화·감사 로그(누가 언제 무엇을 했는지의 기록)·비밀정보 관리(접속 키와 비밀번호를 코드 밖에 따로 보관하는 것)·접근 권한의 주기적 검토가 요구되면 설계와 검증이 함께 늘어납니다. 우리가 어느 수준을 요구해야 하는지는 다루는 정보의 종류로 정합니다. 사내 직원만 보는 데이터인지, 고객의 개인정보가 들어가는지, 결제나 금융 정보가 오가는지 — 이 셋 중 어디인지만 정해서 모든 업체에 똑같이 알려 주시면 됩니다. 이것을 알려 주지 않으면 업체마다 다른 수준을 가정하고, 그 차이가 그대로 금액 차이로 나타납니다. 규제 대응이 필요한 업종이라면 요구 수준을 정하는 일 자체가 별도 단계가 됩니다. 견적서에서는 어느 수준까지가 포함이고 어디부터가 별도인지를 봅니다.

⑤ 만든 뒤 운영을 누가 맡는지 — 구축 견적과 운영 비용은 대개 별개 항목이고, 이 점은 저희 요금 구성에서도 같습니다. 시스템은 인도된 다음에도 서버가 돌아가고, 취약점 조치가 나오고, 사용 중에 고칠 것이 생깁니다. 이 일을 만든 쪽이 이어서 맡는지, 고객사 내부가 맡는지, 아무도 정하지 않았는지에 따라 총 지출은 크게 달라집니다. 견적서에서는 인도 이후의 범위가 어디까지 포함인지를 봅니다.

그래서 역할이 여럿이고 연동이 있는 시스템에서는 「역할별로 이 연동이 어떻게 보이는가」 같은 항목이 따로 생깁니다. 견적서에서 이런 조합이 언급돼 있는지를 보면, 그 업체가 요구사항을 어느 깊이까지 읽었는지가 드러납니다. 화면 개수가 같은 두 시스템의 견적이 크게 갈리는 이유가 대개 여기에 있습니다.

화면 수로 견적을 내면 어긋나는 이유

화면 개수를 단위로 개발 견적을 산정하면 실제 작업량과 어긋납니다. 화면은 눈에 보이고 세기 쉬워서 견적의 단위로 자주 쓰이지만, 실제 작업량은 화면 뒤에서 처리되는 규칙의 양에 더 가깝습니다.

같은 목록 화면이라도 조건이 붙으면 다른 일이 됩니다. 로그인한 사람의 역할에 따라 보이는 행이 달라져야 한다면 그 판단 규칙이 필요합니다. 목록에서 상태를 바꿀 수 있다면 어떤 상태에서 어떤 상태로 갈 수 있는지의 규칙이 필요합니다. 두 사람이 같은 항목을 동시에 고쳤을 때 무엇을 남길지도 정해야 합니다. 화면 개수는 하나 그대로인데 그 안의 일은 여러 배가 됩니다.

반대 방향도 있습니다. 비슷한 구조의 관리 화면 여럿은 개수만큼 늘어나지 않습니다. 공통 구조를 한 번 만들어 두면 나머지는 훨씬 짧게 붙습니다. 그래서 화면 수만 놓고 보면 어떤 견적은 비싸 보이고 어떤 견적은 싸 보이는데, 그 인상이 실제 작업량과 반대인 경우가 자주 생깁니다. 화면 수 대신 「이 화면을 보는 사람의 종류가 몇인가」를 세어 보십시오. 작업량은 화면 수보다 이 숫자에 훨씬 가깝게 따라갑니다.

화면 목록을 요청서에 넣는 것 자체는 도움이 됩니다. 다만 그것만 보내면 각 업체가 화면 뒤의 규칙을 각자 다르게 가정하게 되고, 견적이 갈리는 원인이 그 가정 차이에 그대로 놓입니다.

견적서에서 먼저 확인할 항목

견적서를 비교할 때는 총액보다 먼저 볼 항목이 있습니다. 앞의 다섯 변수를 실제 견적서에서 찾아보는 방법이 아래입니다. 이 항목들이 적혀 있는지 여부만 확인해도 두 견적이 같은 일을 말하고 있는지가 상당 부분 드러납니다.

• 제외 항목이 명시돼 있는가 — 포함 목록만 있고 제외 목록이 없는 견적서는 경계가 열려 있는 상태입니다. 무엇이 들어가는지보다 무엇이 안 들어가는지가 나중에 문제가 됩니다.
• 변경 요청을 어떻게 처리하는가 — 만드는 도중에 요구가 바뀌는 일은 정상입니다. 그때 어디까지가 합의된 범위 안의 조정이고 어디부터가 추가 작업인지, 그 판단을 어떤 절차로 하는지가 적혀 있어야 합니다.
• 기존 데이터 이관이 어디까지인가 — 옮기는 대상, 정리 작업의 주체, 옮긴 뒤 맞는지 확인하는 방법이 각각 적혀 있는지 봅니다.
• 인도 이후의 범위가 무엇인가 — 하자 대응 기간(인도 후 일정 기간 동안 발견된 결함을 추가 비용 없이 고쳐 주는 범위와 기간), 그 기간에 대응하는 범위, 그 이후의 운영을 어떤 형태로 이어가는지를 봅니다. 구축 금액에 운영이 포함되지 않는 것 자체는 흔한 구성이고, 문제가 되는 것은 그 사실이 적혀 있지 않은 경우입니다.
• 산출물과 권리가 정리돼 있는가 — 소스 코드와 데이터가 누구의 것인지, 인도되는 것이 무엇인지, 사용된 외부 서비스의 계정이 누구 명의인지를 봅니다.
• 검수 기준이 있는가 — 무엇을 충족하면 완료로 보는지가 없으면 완료 시점에 대한 판단이 서로 달라집니다.
• 전제 조건이 적혀 있는가 — 고객사가 언제까지 무엇을 제공해야 하는지가 견적의 전제인 경우가 많습니다. 이 전제가 어긋나면 일정과 비용이 함께 움직입니다.

이 항목들이 비어 있다고 해서 그 견적이 부실하다는 뜻은 아닙니다. 요청서에 그 내용이 없었다면 견적서에도 없는 것이 자연스럽습니다. 비어 있는 칸을 발견했다면 그것은 되물을 자리를 찾은 것입니다.

견적서를 실제로 맞춰 볼 때는 한 장의 표로 정리하면 빠릅니다. 세로에 앞의 다섯 변수를, 가로에 받은 견적서를 놓고 각 칸에 그 견적서가 그 항목을 어떻게 잡았는지를 옮겨 적습니다. 한쪽에만 적혀 있는 항목이 금액 차이의 후보이니, 비어 있는 쪽에 그 항목을 되물어 답을 채운 뒤에 총액을 봅니다. 다섯 칸 중 셋 이상이 비어 있는 견적서는 아직 비교할 대상이 아니라 되물을 대상입니다.

낮게 나온 견적이 나중에 커지는 세 가지 형태

낮게 시작한 견적이 최종 지출에서 커지는 경우에 자주 나타나는 형태는 세 가지입니다. 세 형태 모두 누군가의 의도를 전제하지 않습니다. 견적서에 적히지 않은 일이 나중에 비용으로 나타나는 구조일 뿐이고, 그래서 견적서를 읽는 단계에서 미리 볼 수 있습니다.

첫째, 범위가 좁게 해석돼 있던 경우입니다. 같은 문장을 최소 구성으로 읽으면 금액은 낮게 나옵니다. 만들고 보니 실제 업무에 쓰려면 권한 구분이나 이력 관리가 필요하다는 것이 드러나고, 그 부분이 추가로 잡힙니다. 이 형태는 견적서의 포함 범위 서술이 요청서보다 짧을 때 미리 보입니다.

둘째, 변경 처리가 건별 추가로 쌓이는 경우입니다. 초기 금액이 낮게 시작하고 진행 중 요청이 하나씩 별도로 붙으면 최종 지출은 처음 비교했던 금액과 멀어집니다. 이 형태는 변경 처리 절차가 견적서에 없을 때 미리 보입니다. 절차가 있다는 것은 추가 비용이 없다는 뜻이 아니라 언제 왜 늘어나는지를 양쪽이 같은 기준으로 판단한다는 뜻입니다.

셋째, 운영이 포함되지 않았던 경우입니다. 인도 시점에 비용이 끝나는 시스템은 없습니다. 인도 이후를 누가 맡을지가 정해지지 않은 채 시작하면, 그 자리는 내부 인력의 시간이나 별도 계약으로 나중에 채워집니다. 이 형태는 인도 이후 범위가 견적서에 없을 때 미리 보입니다.

세 형태의 공통점은 견적을 받는 시점에 이미 확인할 수 있었다는 것입니다. 필요한 것은 총액의 비교가 아니라 각 견적서가 같은 범위를 말하고 있는지의 확인입니다.

요구사항 정리에 담아야 할 것

견적의 정확도는 요청서의 길이가 아니라 요청서가 담은 정보의 종류로 결정됩니다. 화면 목록보다 다음 항목들을 정리해 보내는 편이 해석 차이를 훨씬 크게 줄입니다.

1. 업무 흐름 — 지금 이 일이 어떤 순서로 이루어지는지를 사람과 순서 중심으로 적습니다. 어디서 시작해 누구를 거쳐 어디서 끝나는지, 중간에 승인이 있는지가 들어가면 좋습니다.
2. 사용자 역할 — 이 시스템을 쓰게 될 사람의 종류와 각자 해야 하는 일을 적습니다. 역할 목록은 권한 설계의 출발점이라 작업량 판단에 가장 크게 영향을 줍니다.
3. 연동 대상 — 함께 써야 하는 외부 시스템의 이름과, 그 시스템에서 무엇을 가져오거나 보내야 하는지를 적습니다. 상대편에 API가 있는지 모르는 상태라면 모른다고 적는 편이 낫습니다.
4. 기존 데이터의 상태 — 지금 데이터가 어디에 어떤 형태로 있는지, 정리가 필요해 보이는 부분이 있는지를 적습니다. 샘플 몇 줄을 함께 보내면 해석 차이가 크게 줄어듭니다.
5. 필수와 선택의 구분 — 없으면 못 쓰는 것과 있으면 좋은 것을 갈라 둡니다. 이 구분이 있으면 예산 안에서 무엇을 먼저 만들지에 대한 제안이 돌아오고, 없으면 전부 필수로 가정한 금액이 돌아옵니다.
6. 예산 범위와 반드시 포함돼야 하는 항목 — 예산 범위를 알려 주면 각 업체가 그 안에서 무엇을 넣고 무엇을 뒤로 미룰지를 제안하게 되므로 비교 축이 오히려 정리됩니다. 예산을 감추면 서로 다른 크기의 그림이 돌아와 비교 자체가 성립하지 않는 경우가 많습니다. 예산에만 맞춘 제안이 걱정된다면 반드시 포함돼야 하는 항목을 함께 적어 주시면 됩니다.

요구사항에 AI가 들어 있다면 한 가지를 더 갈라 두는 편이 좋습니다. 이미 있는 AI 모델을 업무 시스템에 붙이는 일과 모델 자체를 새로 만들거나 학습시키는 일은 필요한 역량도 비용 구조도 다릅니다. 빌드업웍스가 직접 하는 것은 전자이고, 모델 개발과 학습, 데이터 사이언스 컨설팅, 커스텀 알고리즘 개발은 파트너를 연결해 드립니다. 각 업체가 어느 쪽을 전제로 견적을 냈는지 다르면 그 항목만으로 금액이 갈립니다. 저희가 직접 하는 범위와 하지 않는 범위는 웹·앱 개발에서 우리가 하는 일과 하지 않는 일에 정리돼 있습니다.

요구사항을 어디서부터 적어야 할지 막막하다면 1분 업무 시스템 진단에서 업무 영역과 필요한 범위를 먼저 좁혀 보실 수 있습니다. 범위가 확정되는 과정 자체를 보고 싶으시다면 설계·견적이 확정되는 단계에서 각 단계의 산출물을 확인하실 수 있습니다.

빌드업웍스의 금액은 요금 페이지에 공개돼 있습니다

빌드업웍스의 구축 금액은 등급별 시작가와 범위 차등을 포함해 요금 페이지에 그대로 공개돼 있습니다. 이 글에 금액을 옮겨 적지 않은 이유는 단순합니다. 같은 숫자를 두 곳에 적으면 한쪽이 갱신될 때 다른 쪽이 남고, 남은 쪽이 검색 결과에 먼저 나가는 일이 생기기 때문입니다. 실제 숫자는 등급별 범위와 시작가에서 확인하십시오. 한 가지 덧붙이면, 요금 페이지의 숫자는 시작가이고 그 이상 규모는 별도 견적입니다. 그래서 이 글의 첫 번째 형태 — 범위 해석에 따라 최종 금액이 달라지는 구조 — 는 저희 견적에도 그대로 해당합니다. 정확한 범위와 비용은 이 글에 적은 다섯 변수를 함께 정리한 뒤 상담에서 확정합니다.