S/W 외주 제작 A-Z 가이드 (웹사이트, 모바일 앱, 윈도우즈 프로그램, ERP, RPA)

 

💡 본 문서는 우리 회사에서 S/W 를 만들때 도움이 되실거에요! (웹사이트, 모바일 앱, 윈도우즈 프로그램, ERP, RPA)
💡 처음 S/W를 개발하려고 할 때 전문인력이 없어서 어디서부터 시작해야 할지 막막하신 분들을 위하여 작성했어요!

 

< 위커프에서 우리 회사의 모든 데이터를 관리하고 업무를 자동화하세요. - https://www.weekerp.com >

 

안녕하세요, 위커프 팀 강민준입니다. 🙂

종종 저희 팀에게 홈페이지 제작을 여쭤보시는 분들이 계셔서
계약의 시작부터 종료까지 발생할 수 있는 이슈를 포함한 A-Z 까지의 전체! 가이드를 작성했습니다.

먼저 들어가기 앞서 커스터마이징을 구축을 경험하신 위커프 고객사 분들께서 종종 홈페이지 제작 의뢰를 주시는데, 위커프 팀은 위커프 개발에만 집중하고자 일반 웹페이지 제작 의뢰는 수행하지 않고 있습니다. 😭

저희의 작업 공유 스타일이나 일을 진행하는 방식을 좋아해주셔서 추가 의뢰를 제안해주신 것으로 생각하며, 항상 감사드리는 마음으로 과업에 임하겠습니다. 더욱 노력하여 고객사 분들께 시간을 선물할 수 있는 한 해가 되도록 하겠습니다.

프로젝트의 수행 과정을 전체적으로 풀어서 기록하였으니, 부담 없이 즐겨주세요!

 

Q. 누가 우리 S/W을 만들어주나요?

또 업체는 어디서 찾을 수 있나요?

 

웹 페이지를 외주용역 형태로 제작하기 위해서는 이를 대신 만들어주는 업체를 찾아야합니다.

이러한 용역업체는 시장에서 두가지 용어로 부르고 있습니다.

• SI (system integrator) 업체
• 웹 에이전시

실제 프로젝트를 발주하는 입장에서 SI와 웹 에이전시는 큰 차이는 없으며

일반적으로 SI는 시스템 통합이라는 뜻인 만큼 ERP 등 큰 규모의 S/W를 개발하는 경우통상적으로 SI 업체로 칭합니다.

 

본문에서는 통칭하여 웹 프로젝트를 맡아 수행하는 업체를 SI 혹은 SI업체로 언급하며, 우리가 만들고자하는 웹페이지, 모바일 앱 등은 “서비스”로 통칭합니다.

Q. 어떤 절차로 프로젝트를 수행하나요?

계약을 시작할 때 부터 계약의 종료까지 시작부터 종료까지 6~7단계로 구성되어 있습니다.

너무 많은것 같지만 첫 단추를 잘 끼우신다면 이후 일은 더욱 가속화가 붙는 경험을 하실 수 있으며

간단한 프로젝트를 진행하더라도 아래 절차에 따라 진행하시는 것을 권장합니다.

 

 

💡 모바일 앱 서비스나 다른 S/W도 모두 같은 흐름을 따르며, 배포 과정만 상이합니다.

1. 서비스 기획

서비스 기획은 만들고자 하는 서비스 혹은 제품의 방향이 합치하도록 우리회사와 SI 업체의 생각을 정렬시키기 위한 준비 단계를 의미합니다. 본 과정은 아래 설계문서를 통해 구체화 할 수 있습니다.

• 와이어프레임
• 메뉴구조도
• 정보구조도
• 제안요청서(RFP)

본 단계에 가장 중요한 점은 SI 업체의 이해를 돕기위한 문서를 얼마나 상세히 잘 작성했느냐에 따라 이후 단계의 속도가 매우 가파르게 차이가 나고, 커뮤니케이션 리소스를 크게 절감할 수 있습니다.

사용하면 좋은 툴

• Figma
• Power Point

대표적인 UI 툴인 Figma를 통해 작업하는 것을 권장드리며 요즘은 SI 업체도 Figma를 통해 디자인 산출물을 전달하기 때문에 처음부터 Figma로 작업하신다면 편리하게 이후 작업을 수행하실 수 있습니다.

 

하지만 Figma가 익숙치 않으시다면 파워포인트를 통해서 우리가 만들고자하는 서비스의 흐름과 화면의 구성을 대략적으로 표현해주신다면 큰 도움이 됩니다.

 

최소한 와이어프레임과 제안요청서(RFP)는 꼭 작성하시는 것을 권장드립니다.

 

💡 왜 와이어프레임과 RFP가 필요할까요?

 

프로젝트 규모에 따라 다르지만,  우리가 와이어프레임, RFP를 작성하지 않는다면 과업을 정리하기 위한 목적으로 SI 업체 측에서  작성하며 아래와 같은 문제가 야기됩니다.

• 커뮤니케이션 비용 증대
• 기획과정 추가 필요 (작은 프로젝트는 대개 견적서 상에 없지만 다른 견적에 녹아들어 산정됩니다.)
• 훌륭한 사용자의 경험이 아닌 SI 업체의 공수를 줄일 수 있는 방향으로 기획할 우려

서비스의 생김새를 표현하는 와이어프레임과는 다르게

제안요청서(RFP)는 SI업체와 분쟁 시 과업의 범위를 판단하기 위한 법적 제반자료로 사용됩니다. 또한, 프로젝트의 예산, 목적 등을 글로 서술할 수 있는 유일한 문서이며 “프로젝트 하면서 이것만큼 은 꼭 지켜주세요!” 라고 하는 요구사항을 기록할 수 있는 문서이기에 작성이 필요합니다.

프로젝트 규모에 따라 

서비스 기획에서 자료가 전달되면 다양한 플랫폼에서 업체를 모색하실 수 있습니다.

• 구글검색
• 프리모아
• 크몽

각기 다른 개발사에게 견적을 요청하시고, 3번 이상 미팅을 해보시는 것을 권장드립니다.

- 좋은 업체를 고르는 팁

다 필요없고 좋은업체만 있으면 장땡

 

제 경험상 마무리까지 완벽한 좋은 업체는 처음 컨택을 하는 방법부터 다릅니다.

1. 우리의 기획서를 읽어보고 컨택한 업체 (메일 내용에 기획서 내용이 상세히 담깁니다. 당연하다고 생각할 수 있는 절차지만, 이거 안보고 일단 미팅 요청하는 업체가 생각보다 많습니다. 이는 SI 업체 분들도 그럴만한 사정이 있으셔서 그렇긴 합니다..)
2. 킥오프 미팅에서 질문을 잘 받아주고, 질문에 대한 답변이 이해되는 업체
3. 향후 프로젝트 미팅일정 등 프로젝트 수행 방식이 명확한 업체 (요청하지 않아도 먼저 보고 하는 업체는 상상 속 업체입니다.)

3. 계약 단계

계약에서는 일반적으로 아래와 같은 내용이 포함됩니다.

• 보수
• 과업종료 일정
• 과업의 범위 (위 절차 중 배포 등이 포함되는지 여부 판단필요)
• 산출물(중간, 최종인도물)의 정의
• 지식재산권 침해 금지 조항
• 비밀유지 조항
• 지체 상금의 규정 및 납입 형태
• 하자보수 (하자보수는 종료 단계에서 다루겠습니다.)

여기서 강조하고 싶은 포인트 과업의 범위와, 산출물, 지체상금인데요

먼저 과업의 범위는 명확하게 기재해야합니다.

 

💡 (x) 위커프 웹 화면 개발

(o) 기획물에 따른 웹사이트 클라이언트 측 개발(html, css, js, ts, tsx 등 소스코드 포맷의 확장자를 갖는 파일)

 

 💡 (x) 위커프 서버 개발

(o) 서버 설계도 및 제안서에 따른 웹사이트 API 문서화 및 상기 API를 호환하는 Java Spring 서버 구축

이러한 부분을 발주하는 우리입장에서 알기가 힘든데, SI 업체 측에 이러한 부분을 상세시 요구하시는 것이 차 후 분쟁예방에 큰 도움이 됩니다.

 

 

다음은 산출물 입니다.

 

최종산출물에는 우리가 받야아하는 문서와 파일을 전부 명시 해야합니다. 또한, 과업 형태에 따라 다르지만 소스코드는 반드시 받으시는 것을 권장드립니다.

1. API 명세서, 데이터베이스 모델링 설계도, 정보구조도 등 설계 혹은 기획에 사용된 문서
2. 프로젝트에 사용된 모든 소스코드
3. 프로젝트에 사용된 모든 디자인 파일
4. (필요하다면) 배포 서버가 SI 업체의 서버라면 배포에 N년간 컨트롤할 수 있는 권한

💡 산출물에서 1번처럼 최종단계가 아닌 중간에 완료된 문서는 프로젝트 진척 현황을 파악하기 위해 중간산출물로 정의하시는게 좋습니다.

 

지체상금의 예시는 아래와 같습니다.

 

예시

• 총 프로젝트 금액 = 1천만원
• 지체 상금 비율 = 1/1000
• 하루 늦을 때 마다 = 1만원 배상

특히 지체상금에서 제가 강조하고 싶은 사안은

S/W 분쟁을 다루는 관련 법령은 건설용역업에 기초하여 법이 재정됐다는 사실입니다.

 

지체상금은 건설용역업에서 상관례로 부과했던 지체상금의 비율인 1/1000을 넘어가는 경우에는

법원에서 이를 감액하여 지체상금을 판결하며 위약의 개념이 아닌 손해배상의 격으로 보아 아무리

많이 밀렸고, 높은 지체상금 비율을 설정했더라도 총 보수의 30/100 이상은 배상 받지 못하는 것이 일반적입니다.

 

따라서 총 총 발주 금액에 30/100을 넘지 못하고, 해당 30/100이 넘는 지체가 발생한 경우 경우

본 과업을 환불처리하는 것이 상관례에 해당합니다.

 

💡 다만, S/W는 30/100으로 설정하면 이도 저도 못하는 일정 딜레이가 심하니 과업 중간에 환불 할 수 있는 조항을 계약조항에 반드시 포함해야 합니다.

 

- 이게 제일 궁금하시죠? 얼마에 우리 프로젝트를 발주할까? 💵

기대하게 해드렸는데 죄송합니다. 당연히 정답이 없습니다.

다만, 아래와 같이 향후 우리가 웹사이트를 관리할 것인가? 몇명의 사용자 수를 기대하는가?

에 대한 물음과 함께 개발의 강도를 정의하여 가장 돈이 많이드는,

개발 과정의 예산을 가늠할 수 있습니다.

 

우리가 만들고자 하는 서비스가 웹서비스인 경우에는 아래 제반요소를 판단해보시고

이외에 AI가 포함된 서비스, ERP, 모바일 앱 등 웹이 아닌 경우에는 “개발강도높음”으로 간주하세요.

파악해야하는 제반요소

• 하루에 들어오는 사용자 수는 얼마로 추측 혹은 목표하는가?
  • 많음 +5점
    • B2C는 일반고객을 타겟으로 하기에 여하를 불문하고 “많음”에 해당하는 것이 바람직
    • B2B는 일일 거래량 1,000건 이상부터 해당
  • 보통 +3점
    • B2B의 경우 일 거래량 300~1,000건인 경우 “보통”으로 규정
  • 적음 +1점
    • B2B의 경우 일거래량 300건 이하인 경우 “적음”으로 규정
• 자사가 서비스를 구축하는 목적이 온라인 홍보가 아닌 제품구매, 주문 등 인터넷 상에서 이뤄질 수 있는 전자상거래 행위 혹은 유사한 IT 서비스를 운영하기 위함인가?
  • YES → +4점
  • NO → 0점
• 개발 과업에서 구축한 모든 소스코드의 형태는 향후 자사에서 관리할 수 있도록 양도와 조치가 필요한가?
  • YES → +3점
  • NO → 0점
• 향후 개발자 채용 계획이 있는가?
  • YES → +5점
  • NO → 0점
• 우리회사 내부에서만 이용하는 웹사이트인가?
  • YES → +2점
  • NO → 0점

12점 초과 → 개발 강도 높음

7점 ~ 12점 → 개발 강도 중간

7점 미만 → 개발 강도 낮음

 

개발 강도 높음

→ 웹페이지 구축 기준, 견적 1천 5백만 원 이상

→ 반드시 주변 개발자 지인에게 부탁하셔서 도움을 구하시길 권장합니다.

→ 본문에서 다루는 설명만으로는 부족합니다.

→ 개발 언어, 개발 방식, 서버 운영방식 등을 어떠한 것이 존재하는지 학습해야하고

→ 이에 따라 예산이 수백만 원~수천만 원 단위씩 차이가 날 것입니다.

→ 선행되지 않는 경우 제대로 된 서비스가 나오지 않을 확률이 매우 높습니다.

 

개발 강도 보통

→ 웹페이지 구축 기준, 견적 5백만 ~ 1천 5백만 원

→ 여러 SI 업체를 만나면서 금액을 구체화해도 괜찮습니다.

→ 본문에 해당하는 내용을 통해 프로젝트를 진행하시면 좋겠습니다.

→ 단, 우리가 목표하는 바가 커머스나 플랫폼 같은 IT 서비스인 경우

→ “소스코드 양도 여부”와 “향후 개발자 채용 계획”을 다시 평가해보세요.

 

개발 강도 낮음

→ 웹페이지 구축 기준, 추산견적 5백만 원 이하

→ 대개 홍보(랜딩)페이지의 과업범위에 해당할 것으로 추측합니다.

→ 소스코드보단 CI, BI 등 디자인 파일이 더욱 중요하며

→ 한달 이내에 과업이 종료되는 경우가 많습니다.

→ 본문에 해당하는 내용에서 기획 부분만 신경 쓰시고, 프로젝트를 진행하시면 좋겠습니다.

4. 개발 단계

개발단계에서는 무엇보다 프로젝트를 매니징할 수 있는 힘이 중요합니다.

위에서 설명한 개발 강도가 높은 상황에서는 전문적인 인력없이 프로젝트를 매니징하긴 어렵습니다.

 

💡 저희는 자사 개발인력이 없어요. 개발강도가 높으면 아무방법도 없을까요?

 

프로젝트 규모가 3천~4천만원이 넘어가는 경우 예산의 10~15% 를 별도로 분배하여

이해관계가 상충되지 않는 다른 업체의 전문관리 인력을 섭외하는 것이 안전한 방법입니다.

 

그렇지 않고 2천~3천만 원에 달하는 금액인 경우에는 자사에서 매니징 할 수 있도록

학습이 필요하다고 생각하며, 더 좋은 개발업체를 찾을 수 있도록 공을 들여야 합니다.

 

이후, 개발 강도가 보통 이상이라면 대개 설계 작업을 먼저 진행합니다. 이 때는 기획에서 부족한 부분을 보완하고 데이터베이스 모델링, API Document 설계 등을 포함한 산 출물이 정의됩니다.다만 이러한 부분은 모두 SI 업체에서 수행해야하는 과업의 범위이니 발주사인 우리는 딱 한 가지만 잘하면 됩니다.

 

💡 매주 1회는 반드시 미팅하자.

 

위 문장의 요지는 우리는 반드시 % 단위로 진척율을 파악하고 있어야 함을 의미합니다.

- (위커프 자랑) 위커프 팀이 커스터마이징을 할 때 일하는 방식은?

💡 위커프 서비스를 사용한 건에 한하여 원하시는 ERP, CRM 을 직접 구축해드리고 있습니다.

 

위커프 팀이 일하는 방식은 간단합니다.

1. 과업을 시작하기 전에 고객의 요구사항을 바탕으로 과업을 N단계로 분리합니다.
2. 고객사가 요청하지 않아도 이후 2~3일 마다 과업의 진척을 % 단위로 보고합니다.

<실제 고객 메일 사례>

 

또한, 고객사 메일에 대해 24시간 이내에 회신하고 48시간 이내에 구체적으로 답변합니다.

(맞습니다. 위커프가 아직은 부족하지만, 저희의 일하는 방식은 상상 속의 동물임에 틀림없습니다.)

5. 테스트 단계

직접 한명의 사용자가 되어 서비스를 검수하는 과정을 의미합니다.

프로젝트 규모(=개발 강도)에 따라 단위테스트, 통합테스트와 같은 테스트 방법에 기초하며

QA작업과 흔히 알려진 해킹기법을 시도해보는 작업을 진행합니다.

 

본 과정은 충분히 사용자의 입장에서도 검수할 수 있는 부분이니

만들어진 사이트를 구석구석 잘 사용해보는 것이 중요합니다.

 

이후 최종산출물의 경우 위 산출물 양식에서 정의한 바와 같이

모든 산출물을 빠짐없이 수령하고 체크하는 과정입니다.

 

💡 다만, 이 글을 읽은 우리는

1. 이미 중간 산출물도 잘 받았을 것 이고,
2. 체크도 지속적으로 이뤄졌기 때문에 본 과정에서는 크게 체크할게 없어야 함을 기억해주세요.

6. 배포 단계

배포는 서비스의 개발이 끝났으며 이제 상용화를 위해 온라인상에 공개하는 단계입니다.

SI 업체와 계약의 형태에 따라 배포는 선택사항으로 분류될 수 있습니다.

 

특히 온라인 IT 서비스 업체의 경우 서버의 원격접속 등 보안 상 이유로

배포를 과업에서 제외하고 자사에서 직접 배포를 하는 경우가 일반적입니다.

 

여기서 잠깐 서버 국룰에 대해서 설명드리면,

WEB, WAS, DB 3Tier 구조라고 하여, 하나의 웹서비스를 구동하기 위해서는

24시간 상시 가동되는 각기다른 서버 3개가 필요합니다.

• 웹 서비스 → 서버 3개 필요
• 앱 서비스 → 서버 2개 필요
• 윈도우즈(PC) 서비스 → 서버 2개 or 3개 필요
• 기업 내부용 웹 서비스 → 서버 2개 or 3개 필요
• (복합) AI 서비스를 웹과 앱에서 운영하는 경우 → 최소 서버 4개 필요

💡 가용성과 보안 상의 이유로 여러 대의 서버를 구동하는 것이 일반적인 방법입니다.

 

웹 사이트 기준

배포를 SI 업체에서 진행하기로 결정했다면, 개발 강도에 따라 다르지만, 보통 소스코드를 구동시킬 서버는 발주사에서 직접 제공합니다. 카페24, 닷홈 등 저가형 호스팅을 사용하는 형태로 운영하거나, AWS를 사용하시는 것도 좋습니다.

 

IT 서비스 기업이 아닌 이상 SI 업체에서 발주사 명의로 카페24, 닷홈에 가입하여 아이디와 비밀번호 를 SI 업체에 전달한다면 SI 업체는 서버 셋팅을 포함하여 배포 과업을 진행하게 됩니다. 이는 저가형 프로젝트의 일반적인 방법입니다.

 

모바일 앱 기준

백엔드 서버가 별도로 구축되기 때문에 위 웹 사이트 기준을 그대로 포함하면서 구글 플레이스토어, 애플 앱스토어에 등록하고 다운받을 수 있는 형태까지를 포함하는 것이 일반적인 배포과정입니다.

7. 종료 단계

계약의 종료 과정이며, 여기서 계약서 상에 N번 수정에 대한 내용을 포함하는게 좋습니다.

수정은 크게 2가지로 분류됩니다.

1. 당초 요구사항을 반영하지 못하여 수정이 필요한 경우
2. 서비스 기능 동작에 문제가 있어 수정이 필요한경우

여기서 1번 이슈가 발생했다면 우리는 큰일났음을 걱정하셔야 합니다.

상호 간의 책임 떠넘기기가 시작될 것이며, 원만하게 조율하는 것 이외에는 방법이 없습니다.

 

이를 계약서 조항 내에 구체적인 수정 범위와 횟수를 명시하여 약간은 방어할 수 있으나

일반적으로 수정 범위는 아래와 같은 것이 포함되기 때문에 1번은 대처방안이 없습니다.

• 레이아웃 변경 (거의 없음)
• 이미지 변경 N회 (혹은 N 기간동안)
• 문구 변경 N회 (혹은 N 기간동안)
• 오탈자 수정

2번은 하자보수의 개념으로 포함되기 때문에 이는 SI 업체 측 책임이며 수정 요구를 하신다면

대개 수정해주시니 걱정하지 않으셔도 됩니다.

 

하지만 개발인력이 있는 입장에서도 하자보수와 관련한 건은 요청하기가 매우 번거롭습니다.

개발인력이 없는 경우 SI 업체에 하자보수를 요청하는 것은 큰 부담으로 작용할 것 입니다.

 

따라서 제가 권고 드리는 방안은

💡 계약서의 과업 기간 내에 반드시 최종 검수기간을 포함하시는 것을 권장합니다.

프로젝트 종료 이후에 아예 연락하지 않는다고 생각하시면 편합니다.

 

따라서 하자보수가 없을 정도로 검수를 잘 수행하시는 것이 가장 우수한 방법이며,

만일을 대비하여 계약서 내에 간단한 글자 수정, 레이아웃 수정 3회 등 수정에 관련한 조항을 포함하는 것이 좋습니다.

또, 약정된 방법으로 종료일 이후 1년간 오탈자 등 수정 요청시 회당 5만원으로 약정하는 등

SI 업체에서 제시하는 금액에 따라 추가로 하자보수 금액을 계약할 수 있으니 이점 참고바랍니다.

마치며

긴 글 읽어주셔서 감사드립니다.

IT 프로젝트에서 발생할 수 있는 리스크를 미리 관리하시고 우수한 성과 있으시길 바라겠습니다. 😊

• 추가로 궁금하신 사안을 위커프 메일(help@weekerp.com)을 통해 알려주신다면 답변과 함께 아래 Q&A에 추가하겠습니다.
• 클라이언트가 요청하지 않아도 2~3일 마다 % 단위로 클라이언트에 보고가 가능한 SI 업체가 있다면 위커프(help@weekerp.com)로 연락주세요. 저희는 위에서 설명한 이유로 많은 SI 프로젝트를 수행하지 않고 있기에 클라이언트 소개를 담당하겠습니다.

위커프는 업무자동화를 코드 없이 구축하고, 백엔드 리스한 형태로 API 및 API에 따른 트리거를 지원하기에 일부 백엔드 작업을 빠르게 구축할 수 있습니다. SI 업체분들과 장기적인 협업을 기대합니다.

(Q & A)

Q. 요즘 AWS 많이 쓰는데 왜 쓰나요? 뭐가 좋은가요?

AWS의 강력한 힘은 트래픽에 따른 유연한 확장성과 서버 관리를 하지 않아도 되는 관리 비용의 절감입니다.

 

넷플릭스와 같은 거대한 사용자 트래픽을 감당할 수 있는 글로벌 서버를 지원하며 자사 개발 인력이 모든 서버의 설정을 직접 변경하고, 설정할 수 있습니다. 실제로 서버를 설정하는 영역에서 매우 높은 자유도를 자랑합니다.

 

또한, 주기적인 업데이트를 통해 “서버”라는 개념에서 필요한 모든 것을 모아놓은 서비스이기에 마땅한 대체재가 없으며 강력한 자유도를 통해 서비스의 규모가 영세할 때도 사용할 수 있고, 넷플릭스처럼 글로벌 서비스를 하더라도 처음부터 끝까지 사용할 수 있는 풀커버 서비스입니다.

 

관련하여 국내 인력을 채용하더라도 퍼블릭 클라우드 중 AWS 를 다룰 수 있는 인력이 가장 많기도 합니다.

다만, 개발의 강도가 보통 이하이고 IT 서비스가 아닌 경우, AWS는 오히려 사치일 수 있습니다.

자유도가 높은 만큼 설정해야할 제반사안이 많고 이는 곧 구축비용의 증대로 이어집니다.

따라서 이는 SI업체와 상의하셔 선택하시는 게 가장 좋은 방법이며 IT 서비스를 운영하실 계획이시라면, 확장성을 고려하시어 AWS를 선택하시는 것을 추천드립니다.