개인, 기관 또는 단체에서 의뢰하는 웹사이트의 견적 문의에 대응하다 보면 견적을 어떻게 요청해야 하는지 어려워하는 경우가 있습니다. 신규 웹사이트를 제작하려는 경우, 기존 웹사이트를 좀 더 나은 모습으로 바꾸려는 경우, 웹사이트는 이미 보유했지만 필요한 부분을 고치고 싶은데 스스로 할 수 없어 도움이 필요한 경우까지 다양한데요. 대표적으로 발생하는 상황을 바탕으로 좀 더 편하고 빠르게 견적을 문의하는 방법을 안내해드리겠습니다.
우린 아무런 홍보 채널이 없는데… 웹사이트를 만들어야 하나요?
왜 만들어야 하는지 생각하고 홈페이지의 필요성을 결정하세요! 신규로 단체가 설립되었거나, 기성 조직이라도 IT 기반 마케팅/커뮤니케이션 영역에 전혀 관심을 가지지 않다가 무언가를 하려고 했을 때 가장 먼저 ‘어떤 목적을 가지고 이것을 시작하려고 하는가’를 생각해 보아야 합니다.
이제 막 시작한 조직이 저렴한 비용으로 존재감을 드러내거나 홍보를 해야 하는 경우를 살펴보겠습니다. 활동내역에 대한 안내와 고객과의 접점을 찾기 위한 수단으로 웹사이트 구축보다 먼저 SNS 페이지나 임대형 블로그 운영, 무료 웹사이트 제작 솔루션과 같은 저렴하지만 효과적인 방식을 고려해 볼 수 있습니다. 비유적으로, 출퇴근을 위해 저렴한 비용으로 구매할 차량이라면 연비가 좋아야 하고, 출력이 조금 낮더라도 크기가 작아 주차비나 수리비와 같은 운영 비용이 적게 드는 경차가 스포츠카나 SUV보다 나은 선택이 될 수 있는 것처럼 말입니다.
각각의 장/단점이 있지만 현재 시점에서 조직의 구성 상태와 투입 가능한 인적/물적 자원을 검토할 수 있는 여력이 없어서 어떤 방식을 취해야 할지 모르겠다면, 우선 ‘구축에 관한 컨설팅’을 요청할 수 있습니다. 범위와 결과물에 따라 비용에 차이가 있지만, 문제를 해결하기 위한 원론적인 부분부터 함께 고민할 수 있기 때문입니다. 이에 따라 정확한 방향으로 작업이 가능하며, 모호한 내용을 가지고 무리하게 사업을 진행하는 것보다 오히려 비용을 절약할 수 있습니다.
블로그나 SNS로 운영하고 있었는데, 이젠 우리의 가치를 담은 웹사이트가 필요합니다!
사이트를 완성했을 때 모습과, 운영할 때 꼭 필요한 기능이 무엇인지 고민해보세요! 기존에 블로그, SNS 페이지 등의 마이크로 사이트로 운영하던 매체가 있었지만 디자인, 레이아웃, 기능적 한계를 느껴 새로운 매체가 필요한 경우, 또는 새롭게 만들어진 기관이나 단체이지만 고유한 사업방식을 가지고 이를 온라인에서도 특정하게 적용해야 하는 경우입니다. 예를 들면 아래와 같은 경우가 있을 수 있겠지요.
- 보유한 콘텐츠에 특정한 형태와 정보가 있어서 독립적인 포맷으로 노출되어야 할 필요가 있거나
- 고유한 레이아웃을 통해서 조직이나 사업의 성격을 드러내고 싶은 경우
- 캠페인 성격을 지녀 아이덴티티가 확고히 드러나는 매체가 필요한 경우
이럴 때 사이트가 필요할 수 있습니다. 더 나아가 4. 사업의 방식이 온라인을 통해 알려지고, 정보가 수집되며 사업의 프로세스가 웹사이트를 이용하는 사업방식이라면 더더욱 고유의 웹사이트가 필요할 것입니다.
‘어떠한 목적을 위해 웹사이트를 만드는가’라는 질문에 어떤 답변할지 확인했다면 ‘어떤 모습의 웹사이트를 만들 것인가’를 찾아보는 과정이 필요합니다.
모방은 창조의 어머니라는 말이 있듯이 내가 원하는 모양, 형태, 구성 등과 유사한 사이트 또는 이상적인 모습을 가진 다른 사례를 찾아보는 것이 실마리가 될 수 있습니다. 미리 준비된 벤치마킹 자료 및 참고가 될 만한 웹페이지와 같은 정확한 사례조사 자료는 추후 과업을 의뢰할 때 훨씬 빠른 의사소통과 방향성 수립에 큰 도움이 됩니다.
이렇게 준비된 사례조사 자료를 토대로 실제 제작할 웹사이트의 ‘메뉴(Sitemap)’를 구성해 봅니다. 메뉴는 보통 내부에 존재하는 콘텐츠로 접근할 수 있는 경로구조의 집합을 말합니다. 이와 비슷하게 인식되지만 다른 개념으로 ‘정보구조(IA, Information Architecture)’가 있습니다.
IA와 메뉴는 비슷할 수도, 완전히 다를 수 있습니다. IA를 통해 정의된 콘텐츠의 구조를 일목요연하게 사용자에게 제공하는 것이 바로 메뉴이기 때문입니다. 따라서 좀 더 쉽게 접근하기 위해 원하는 형태의 메뉴 구조를 인지하기 편한 트리(tree) 형태로 정의한 뒤 클라이언트와 개발 주체가 함께 확인합니다.
이후에 각 메뉴가 연결될 페이지 또는 기능 요소를 정의해 이를 구체화하거나 실현할 방식을 각 개발 주체가 가진 고유의 방법론이나 기술력으로 제공하게 됩니다.
따라서 신규 사이트 제작을 위한 견적을 의뢰하기 전 레퍼런스나 참고 웹사이트의 자료들로 구성된 ‘사례조사’ 내역과 이를 통해 도출된 ‘메뉴구조’를 문서화하고, 나아가서 메뉴별 페이지나 요소가 수행해야 할 ‘기능’을 정의한 문서를 견적 의뢰할 때 전달하면 더욱 정확한 투입인력에 대한 범위와 기간 산정이 가능합니다.
단 1) 이러한 ‘정보구조(IA)’에 포함될 개별 콘텐츠가 미리 준비되어 있는가에 대한 판단과 2) 이를 생산 및 운용, 관리할 인력자원이 확보되어 있는지를 충분히 고려해야 합니다. 웹사이트는 연료를 넣으면 자동으로 움직이는 기계가 아니라 지속적인 운영과 콘텐츠의 생산 관리가 필요한 유기체와 유사하기 때문입니다.
예를 들어 웹사이트에 한 개의 게시판을 추가할 때는 단순히 문서를 올려두는 공간의 분할에 그치는 것이 아닙니다. 이 공간에 등록할 자료를 지속적으로 생산할 주체가 있는지 여부를 먼저 고려해야 합니다.
웹사이트를 이미 운영하는데 필요한 것들을 좀 더 만들거나 수정해서 쓰고 싶어요
무엇으로 만들었는지, 어떤 일을 어느 범위까지 의뢰할지 알려주세요! 이미 위와 같은 절차와 시간을 들여 웹사이트를 운영하기 시작했습니다. 그런데 실제 운영을 시작한 이후로 미처 고려하지 못했던 부분에서 새롭게 필요한 것을 발견했습니다. 새롭게 부임한 총 책임자의 이력을 변경해야 하거나, 캠페인 신청접수를 받는 게시판을 별도로 만들 일이 생길 수도 있습니다. 신규 사업에 대한 메인페이지 배너를 만들어야 하는데 내부에는 그래픽 작업을 할 수 있는 사람이 없습니다…
이미 개발해 사용 중인 웹사이트의 지속적인 ‘운영’에 필요한 업무를 행하는 것을 ‘운영-유지보수‘ 업무라고 칭합니다. 보통 웹사이트의 개발 이후 정상적인 계약을 체결해 진행했다면 계약에 명시된 기간 범위 내로 진행되는 ‘하자보수’ 기간이 담보됩니다. 하자보수는 계약 시, 또는 사전 개발계약에서 약속했던 기능의 정상적인 작동이 되지 않아 이를 수정해야 하는 경우와 그래픽 오류, 오·탈자 수정 정도의 현상유지 업무를 통칭합니다.
반면 운영-유지보수 업무는 이와 달리 미리 수행하기로 약속되었던 범위인지 아닌지에 따라 구분됩니다. 계약에 명시되지 않은 추가적인 과업이나 기능변경, 수정개발이 필요하거나 웹사이트의 정상적인 운영을 위해 필요한 기술적 용역이 필요하다면 우선 현재 웹사이트가 어떤 상황인지 파악해야 합니다.
- 웹사이트의 위치: 웹호스팅 서비스 / 웹서버 보유 / 클라우드 서버 등
- 개발언어: ASP / PHP / JSP 등
- 사용된 프로그램 또는 프레임워크: 단순 HTML / 오픈소스CMS기반 / 상용CMS기반 등
- 내부 가용자원: 웹 담당자 존재 유·무와 담당자의 웹 관련 이해도 수준
웹사이트를 개발한 주체와 운영-유지보수 업무를 의뢰하는 주체가 다른 경우에는 개발되어 있는 웹사이트의 구조를 알 수 없는 경우가 많으므로, 최소한 위 정보를 함께 제공해 ‘설계분석’의 가능 여부부터 판단하는 것이 좋습니다(이는 웹사이트 담당자의 관련 이해도가 낮다면 쉽게 준비하기 어려운 자료이므로 웹사이트 구축을 완료한 당시에 해당 정보를 정확하게 입수해 두는 것이 좋습니다).
설계분석이란 구조를 파악하고 수정을 요청하는 부분의 위치를 찾아 원하는 기능이나 형태를 구현하는 것이 가능한지 여부를 확인하는 일차적 단계입니다. 개발 주체가 사용한 방법론이나 프로그램을 운영-유지보수 주체가 잘 이해하고 있는 경우에는 설계분석에 드는 비용과 시간이 절약될 수 있습니다. 따라서 기존 개발업체의 성격과 비슷한 수정 주체를 찾는 경우가 일반적입니다.
그러나 최초의 개발방식과 환경이 일반화되어 있지 않거나 라이선스를 별도로 가진 상용 소프트웨어로 구축된 경우, 코드를 분석하고 재조립하는 것 자체가 매우 어렵거나 불가능할 수 있습니다. 이런 경우 웹사이트를 새롭게 만드는 것이 수정하는 것 더욱 비용을 절감하기도 합니다. 따라서 기존 웹사이트에 대한 정보를 정확하게 파악하고 있는 것이 중요합니다.
설계분석이 가능하고, 진행될 수 있다면 원하는 기능의 추가나 수정을 위해 어떤 곳에 무엇이 필요한지 설명할 수 있는 자료를 준비해야 합니다. 이는 웹사이트를 새로 만들 때의 방식과 유사합니다. 원활한 이해를 위해 사전에 준비한 유사사례를 제시하거나 절차와 로직(Logic)을 일반화시켜 의뢰를 받는 주체가 해석할 수 있는 형태의 문서를 준비하면 됩니다.
그래서, 얼마예요?
1. 견적서의 구성
개발을 담당하는 주체의 방법론에 따라 다소 차이가 있지만, 웹사이트의 구축/수정에 관한 내용은 모두 사람이 수행하는 일이기 때문에, 가장 많은 비중을 차지하는 것이 바로 투입 인력에 관한 ‘인건비’ 입니다. 인건비는 수행하는 인력의 기술 수준에 따라 비용에 차등을 주는 것이 일반적이며, 사업 발주처와 수행 주체 간 협의에 의해 최종 결정됩니다.
하지만 국내에서는 보통 한국소프트웨어산업협회 SW기술자 노임단가를 기준으로 하는 경우가 많습니다. 해당 노임단가는 지급되는 임금을 말하며, 실제 견적서는 투입인력에 대한 제경비와 발생 매출에 대한 부가가치세를 포함하므로 위 단가표에 30~120%의 비용이 함께 추가됩니다.
이와 다른 방식으로 개발이 필요한 기능의 기능점수(Function Point, FP)를 이용한 견적 방식이 있습니다. FP 견적방식은 개발이 필요한 기능을 일괄 목록화하고 개별 기능에 주어진 점수를 부여해 이를 개발언어와 방식, 난이도, 위험에 따른 안정성 담보 등급에 따라 보정계수를 적용해 최종 산출하는 방식입니다.
개념 자체는 매우 합리적이지만 실제 기능목록을 측정하는 방식이 일반화되어 있지 않고 견적을 냈을 때 기존 인건비 산정방식에 비해 매우 높은 비용 차이가 발생한다는 한계가 있습니다. 실제 실무에 적용하기보다는 공공 영역에서 사업비용 및 예산 타당성을 측정할 때 주로 사용하는 편입니다.
마치며
지금까지 웹사이트뿐 아니라 일반적인 소프트웨어 개발에서 사용되는 개발 프로세스를 일반화해 적용할 때 사용할 몇 가지 사례를 들어 보았습니다. 사업범위나 성격에 따라 위 내용과 다른 방식의 접근방법이 사용될 수도 있지만, 가장 중요한 것은 ‘목적’에 따른 ‘기능’의 정의와 이를 ‘운영/관리’할 자원이 충분한지를 고려해야 한다는 점입니다.
우리의 프로젝트는 UX와 UI에 앞서 이를 사용할 대상인 고객 또는 사용자에게 올바르고 정확한 ‘콘텐츠’를 전달하는 매개를 만드는 것이라는 점을 항상 마음에 두고 있어야 할 것입니다.
원문: 슬로워크 / 필자: 김명직
