• 고소장 봉투의 마치 기자가 찍어주었으면 하는 고소내용
• 평가 기간의 자기 어필
• 수를 써서 다수를 내편으로 반드는 행위 
• 편을 가르고 적을 만들어 우리의 단합을 하는 행위
• 선의의 결과를 위해 때로는 불사해야하는 악의적인 행동

이런 혼란스러운 세상에서 우리는 얼마나 올바른 가치판단을 할 수 있을까

4년 전에 쓴 글 이었다.

시장 현황과 성장성 🚀

웹 접근성(Web Accessibility)은 최근 전 세계적으로 중요성과 시장 규모가 크게 성장하는 분야입니다. 왜 그럴까요? 우선 법적·제도적 압력과 거대한 잠재 시장이 있습니다. 미국을 예로 들면, 장애인을 포함한 소비자들이 한 해 5,000억 달러(한화로 약 650조 원 이상)를 지출하고 있어 기업 입장에서 무시할 수 없는 거대 시장으로 떠오르고 있습니다 . 전 세계적으로는 약 10억 명이 어떤 형태로든 장애를 갖고 있으며 고령 인구 증가로 이 숫자는 계속 늘고 있죠 . 따라서 웹 접근성을 확보하지 않으면 이 거대한 사용자층을 놓치는 셈입니다.

법적 측면에서도 접근성 미준수로 인한 소송과 제재가 늘고 있습니다. 예컨대 미국에서는 *“웹사이트 접근 불가”*를 이유로 하루 11건씩 소송이 제기되고 있고, 상위 500개 온라인 소매 기업 중 412곳이 최근 4년간 최소 1건 이상의 소송을 당했다고 해요 . 우리나라에서도 관련 법규가 강력합니다. 「장애인차별금지 및 권리구제 등에 관한 법률」(장차법) 제21조와 「지능정보화 기본법」 제46조, 제47조 등에 의해 공공·민간 모든 웹사이트에 접근성 준수가 의무화되어 있습니다 . 만약 개선 명령을 받고도 정당한 사유 없이 불이행하면 최대 3천만 원의 과태료까지 부과될 수 있습니다 . 즉, 이제 웹 접근성은 선택이 아닌 필수인 시대가 되었습니다.

이러한 흐름 덕분에 웹 접근성 관련 시장은 꾸준한 성장세입니다. 글로벌 리서치에 따르면 디지털 접근성 서비스 시장은 2024년 약 35억 달러에서 연 평균 15% 이상 성장해 2033년 102억 달러에 이를 전망이라는 보고도 있습니다. 국내 시장도 공공기관뿐 아니라 금융, 의료, 이커머스 등 민간 분야까지 접근성 컨설팅 수요가 확대되고 있어요. 팬데믹을 거치며 온라인 서비스 이용이 폭발적으로 늘었고, 고령화로 사용자층의 다양성이 커지는 만큼 접근성 개선의 필요성도 커졌습니다 . 쉽게 말해 *“접근성을 신경쓰지 않으면 비즈니스 기회를 놓칠 뿐만 아니라 법적 위험까지 진다”*는 인식이 퍼지고 있죠 .

요약하면, 웹 접근성 컨설팅 시장은 지금이 적기입니다. 사회적 요구와 법규, 그리고 기업들의 관심이 맞물려 있으니, 이 분야에 뛰어드는 것은 성장 가능성이 매우 큰 사업이라고 할 수 있습니다.

컨설팅 업무 내용과 절차 🔍

그렇다면 웹 접근성 컨설팅은 실제로 무슨 일을 하고, 어떻게 진행될까요? 컨설팅의 주요 업무 단계를 순서대로 살펴보겠습니다:

1. 진단 및 평가: 먼저 대상 웹사이트나 앱의 접근성 현황을 꼼꼼히 검사합니다. 국제 표준인 WCAG 2.x (한국형 웹 콘텐츠 접근성 지침, KWCAG) 기준에 따라 각 페이지의 문제점을 찾아내지요. 자동 평가 도구와 수동 검사(전문가 검수, 보조공학 기기로 테스트 등)를 병행합니다. 이 단계에서 시각·청각·지체 장애인 등 여러 유형의 장애 관점에서 문제가 되는 요소(예: 대체텍스트 미제공, 영상 자막 누락, 키보드로 조작 불가한 메뉴 등)를 식별합니다 . 그 결과를 정리해 접근성 감사(Audit) 보고서를 작성해요.
2. 개선 가이드 제시: 진단 결과를 토대로 개선 방안 가이드라인을 제공합니다. 개발자나 디자이너, 콘텐츠 관리자 등이 이해하기 쉽게 코드 수정 예시, 디자인 수정 권장사항, 웹 표준 준수 방법 등을 제시하지요 . 예를 들어 “이미지에는 적절한 대체텍스트를 넣으세요”, “키보드로 포커스가 이동되도록 스크립트를 조정하세요” 등의 구체적인 조언을 합니다. 경우에 따라 프로토타입 시연이나 예시 코드를 함께 제공하여 개발팀이 개선 작업을 원활히 할 수 있도록 돕습니다.
3. 교육 및 워크숍: 필요하다면 고객사 담당자 교육도 컨설팅의 일환으로 이뤄집니다. 웹 접근성의 중요성 및 기술적인 원리를 이해시키고, 개발자/디자이너들이 직접 접근성 이슈를 발견하고 해결할 수 있도록 역량 강화를 지원합니다 . 예컨대 스크린리더 사용법, ARIA 활용법, 색 대비 체크 방법 등을 교육하죠. 교육은 온사이트 워크숍이나 온라인 강의 형태로 진행될 수 있습니다.
4. 수정 지원 및 자문: 실제 개발팀이 사이트를 수정하는 동안 옆에서 조언자 역할을 합니다. 코드 리뷰를 해주거나 질문에 답하면서 개선 작업 전 단계에서 시행착오를 줄일 수 있게 도와줍니다 . 때로는 컨설턴트가 직접 일부 코딩 지원을 하기도 하고, UX 관점에서 디자인 리뷰를 제공하기도 해요. 프로젝트 관리 측면에서 일정 내 품질 개선이 이루어지도록 점검하는 역할도 수행합니다.
5. 검수 및 인증 준비: 고객사가 수정 작업을 완료하면, 다시 한 번 최종 점검을 합니다. 초기 발견 문제들이 잘 해결됐는지, 새로 생긴 이슈는 없는지 재검수하고, 부족한 부분이 있으면 추가 개선을 권고합니다. 정부 인증(품질마크) 획득이 목표인 경우, 공인 인증 심사 기준에 맞춰 사전점검을 해주는 것이 중요합니다 . 예를 들어 품질인증 심사에서 요구하는 준수율 95% 이상을 달성하도록 1차, 2차 모의평가 형태로 지원하지요. 모든 준비가 끝나면 공식 인증 심사에 대비한 서류 작업이나 시연 자료 준비도 도와줍니다.

이러한 절차를 거치면 최종적으로 접근성 품질인증 마크 획득(해당되는 경우)이나 내부 가이드라인 정립, 사용자 경험 향상 등의 결과를 고객이 얻게 됩니다.

컨설팅이 제공하는 구체적 산출물로는:

• 접근성 평가 보고서 (현황 진단 결과 및 문제 리스트)
• 개선 가이드 문서 (문제별 해결 방법, 우선순위)
• 교육 자료 (발표 자료, 매뉴얼 등)
• 추적 표(Excel 등): 문제 해결 과정을 관리하는 로그
• 최종 개선 결과 보고서 (얼마나 개선되었는지 측정 결과)
• (인증 목표 시) 인증 신청 서류 및 대응 자료

등이 있습니다. 프로젝트 완료 후에도 원하면 주기적인 재점검 서비스나 추가 자문 계약으로 이어지기도 합니다.

요약하면, 웹 접근성 컨설팅은 단순히 진단하고 끝이 아니라 개선 과정 전반에 함께하며, 교육과 변화관리까지 포괄하는 서비스라고 할 수 있습니다.

수익 모델과 사업 구조 💰

이제 “이 사업, 어떻게 돈을 벌까?” 하는 수익모델 관점으로 볼게요. 웹 접근성 컨설팅의 수익원은 주로 다음과 같습니다:

• 프로젝트 기반 컨설팅 수수료: 가장 기본은 개별 프로젝트 계약으로 받는 컨설팅 비용입니다. 예컨대 A기업 홈페이지 접근성 개선 프로젝트를 계약하여 정해진 기간 동안 컨설팅을 제공하고 그 대가로 프로젝트 비용을 받는 것이죠. 프로젝트 규모에 따라 수백만 원에서 수천만 원대까지 다양합니다. 진단만 수행하는 간이 프로젝트 vs. 진단+개선 지원+인증까지 풀패키지에 따라 과업 범위가 달라지고 비용도 커집니다.
• 교육 및 워크숍 수입: 접근성 관련 교육 프로그램을 별도로 유료 제공할 수도 있습니다. 하루짜리 교육, 정기 세미나, 사내 워크숍 등으로 강의료를 받는 것이죠. 직접 개발자/디자이너들을 교육해주는 서비스는 컨설팅의 부가가치로 추가 판매 가능합니다. 예를 들어 “접근성 코딩 마스터 과정 2일 – 1인당 N만원” 식으로 패키지를 만들어 수익모델로 삼을 수 있어요.
• 제품/도구 판매 또는 솔루션 연동: 자체 개발한 자동 검사 도구나 모니터링 솔루션이 있다면 이를 구독형으로 제공하거나, 컨설팅과 연계해 판매할 수도 있습니다. 아직 스타트업 단계라면 자체 솔루션까지는 없겠지만, 추후 가능성을 열어두세요. 해외에는 자동화 테스트 플랫폼을 구독형 서비스로 제공하는 예도 있고, 국내에서도 접근성 모니터링 시스템을 월 이용료 형태로 제공하는 시도가 있습니다. 예컨대 *“월간 리포트 제공 서비스”*로 매달 일정 요금을 받는 식입니다.
• 사이트 구축/개발 연계 수익: 컨설팅을 하다 보면 *“그럼 수정 작업까지 해주시면 안 되나요?”*라는 요청을 받을 수 있습니다. SI(System Integration) 쪽 역량이 있다면 개발까지 패키지로 수주하여 추가 수익을 낼 수도 있어요. 다만 컨설팅 본연의 중립성을 유지하기 위해 직접 개발까지 하면 이해상충 우려가 있긴 하지만, 소규모 개선(예: HTML 수정)은 컨설팅 계약에 추가 옵션으로 넣어도 무방합니다. 접근성 코딩 전문 인력을 두고 개발 용역까지 제공하면 서비스 폭이 넓어지죠.
• 유지보수/리테이너 계약: 프로젝트 종료 후에도 정기 점검이나 상담을 위한 리테이너 계약을 맺어 지속적인 수익을 창출할 수 있습니다. 예를 들어, “월 1회 접근성 스캔 및 리포트 제공, Q&A 지원 – 월정액 N만원” 같은 모델입니다. 최근엔 구독형 컨설팅이라고 해서, 1년 단위로 계약 맺고 정해진 횟수로 모니터링 및 개선 권고를 해주는 형태도 관심을 받고 있어요. 이러면 일회성에 그치지 않고 안정적인 수익 흐름을 만들 수 있습니다.
• 공공 입찰 프로젝트: 정부나 공공기관의 접근성 평가 용역 입찰에 참여해 수주하는 방법도 있습니다. 나라장터 등을 통해 정기적으로 *“웹 접근성 평가 및 개선 용역”*이 올라오는데, 이를 따내면 프로젝트별 예산을 확보하게 되죠. 공공 사업은 절차가 까다롭지만 한 번 성공하면 레퍼런스로 신뢰를 얻고, 연속 수주할 기회도 있습니다.

요컨대, **기본 컨설팅 fee + 부가서비스(교육, 유지보수 등)**의 조합으로 매출을 구성하게 됩니다. 수익구조 다변화가 중요한데, 초반엔 주로 프로젝트 수임이 핵심일 것이고, 규모가 커지면 제품 개발이나 상시 서비스로 확장할 수 있습니다. 또한 파트너십으로 수익을 올릴 수도 있는데요, 예를 들어 개발사나 에이전시와 협력해서 웹 접근성 파트만 하청받는 방식도 가능합니다.

초기에는 인력의 맨파워에 의존하는 컨설팅 수익이 주겠지만, 장기적으로는 지속적인 서비스 모델을 만들어가는 것을 목표로 하면 좋겠습니다.

전문성 확보와 관련 자격 🎓

웹 접근성 컨설턴트로서의 전문성은 어떻게 증명하거나 강화할 수 있을까요? 다행히 법적으로 요구되는 필수 자격증은 없습니다. 하지만 관련 지식과 신뢰를 보여주기 위해 몇 가지 권장 자격과 학습 방법이 있습니다.

• 웹접근성 전문가 자격증: 국내에는 민간자격으로 “웹접근성 전문가” 자격(1급/2급/3급) 제도가 있습니다. 과학기술정보통신부 산하 기관에서 일정 수준을 갖춘 사람들에게 발급하는 민간자격인데요 , 있다면 업계에서 전문성을 인정받는 데 도움이 될 수 있습니다. (예: UA Lab 등의 기관에서 시험 실시) 아직 공인 국가자격은 아니지만, 그래도 이 분야에 대한 지식과 실무 능력을 공식적으로 검증받았다는 신호가 되죠. 응시료와 시험이 있고 3급(주니어)부터 1급(최고)까지 등급이 나눠져 있으니, 차근차근 준비해볼 만합니다.
• 국제 전문 자격: 해외의 *IAAP(국제 접근성 전문협회)*에서 주관하는 CPACC, WAS, CPWA 같은 국제인증이 있습니다. CPACC는 접근성 기초 전반, WAS는 전문기술 역량, CPWA는 두 가지를 합친 자격이지요. 영어로 시험을 보아야 하고 비용도 들지만, 글로벌 기업과 일하거나 최신 동향을 따라가는 데 도움이 됩니다. 우리나라에서도 이 IAAP 자격을 보유한 컨설턴트들이 점차 늘고 있어요. 국제 인증은 필수는 아니지만 글로벌 스탠더드에 맞는 역량을 쌓았다는 점을 어필할 수 있습니다.
• 관련 전공/경력: 공식 자격보다 중요한 건 실제 웹 기술 및 장애인 IT에 대한 이해입니다. 컴퓨터공학, 디자인, 정보통신 등 관련 전공 지식이 있으면 좋고요 . 경력 면에서는 웹 퍼블리셔, 프론트엔드 개발자, UX 디자이너 등으로 일하며 쌓은 경험이 큰 자산입니다. 접근성 컨설팅 자체가 아직 신생 분야라 *“~년 이상 경력자”*를 구별하긴 어렵지만, 웹 개발/테스트 경력이 풍부하면 신뢰도가 높아집니다 . 만약 그런 경력이 부족하다면, 오픈소스 프로젝트 참여나 **자원봉사 (시각장애인 웹 사용 테스트 도우미 등)**로 경험을 채우는 것도 방법입니다.
• 지속적인 학습: 접근성 표준과 기술은 계속 진화합니다. WCAG 업데이트(예: WCAG 2.1, 2.2 등)나 ARIA 신기술, 보조공학 기기의 발전 등을 따라잡으려면 꾸준히 공부해야 해요. 국내 커뮤니티로는 NIA 주관 웹 접근성 캠프나 **널리(NULI)**와 같은 포털의 접근성 블로그, 그리고 카카오나 네이버 등에서 공개하는 가이드 문서들이 있습니다. 해외 자료로 WebAIM, W3C WAI 사이트, Deque나 LevelAccess 등의 블로그도 추천합니다. 시간 날 때마다 세미나 참석, 스터디 참여, 관련 컨퍼런스(예: CSUN Assistive Tech Conference 같은) 등을 통해 최신 정보를 접하세요.
• 케이스 스터디와 실습: 책과 이론만으로는 한계가 있으니, 직접 여러 사이트를 평가해보는 연습을 권합니다. 유명 사이트를 골라 접근성 평가를 해보고 개선 방안을 써보는 거죠. 이런 포트폴리오를 만들어 두면, 첫 고객을 만날 때 *“이렇게 개선해드릴 수 있습니다”*라고 보여줄 사례가 생깁니다.

한 가지 더, 열정과 커뮤니케이션 능력도 중요한 자산입니다. 컨설턴트는 기술 전문가이면서도 고객을 설득하고 교육하는 소통가여야 하거든요 . 그러니 프레젠테이션 스킬, 문서 작성 능력도 같이 길러두시면 좋습니다. 정리하면 공식 자격 + 실무경험 + 지속학습의 삼박자로 전문성을 키워나가세요.

접근성 진단 도구와 활용 🛠️

“어떤 도구를 써서 웹 접근성 진단을 하나요?” 처음 시작할 때 많이들 궁금해하십니다. 효과적으로 일을 하려면 자동화 도구 + 수동 검증 기법을 적절히 조합해야 합니다. 주요 도구와 활용법을 소개합니다:

• 자동 평가 도구 (웹): 대표적인 것이 WAVE라는 온라인 툴입니다. 사이트 URL을 입력하면 이미지에 대체텍스트가 없는지, 헤딩 구조가 올바른지 등 기본적인 접근성 오류를 검사하고 시각적으로 표시해줍니다 . 보고서를 저장하거나 개발자용 브라우저 확장으로 사용할 수도 있죠. 그 외에 axe (Deque Systems 제공), Lighthouse (Chrome 내장) 등의 도구도 널리 쓰입니다. 자동 도구는 빠르게 많은 페이지를 훑어볼 때 유용하고, 반복 검사를 자동화하는 데 좋습니다. 다만 자동 도구로는 한계가 있어요. 예를 들어 문맥에 맞는 대체텍스트인지는 사람 판단이 필요하고, 전체 접근성 이슈의 20~50% 정도만 자동 검출된다고 보시면 됩니다 . 따라서 **“자동 검사 결과 + 전문가 수동 점검”**이 필수예요.
• 국내 지원 도구: 과거엔 NIA에서 KADO-WAH라는 한국형 자동 평가 도구를 제공했는데, 현재는 서비스 종료되었습니다 . 대신 WA 검사마법사(웹접근성 평가마법사) 같은 온라인 체크 도구를 활용할 수 있어요 . 또한 네이버 널리(NULI) 사이트에서 추천하는 도구 목록을 찾아볼 수 있는데, PC웹은 WAVE를, 모바일 앱의 경우 Android 접근성 스캐너 등을 소개하고 있습니다 . 모바일 앱 접근성 진단에는 구글의 TalkBack, 애플의 VoiceOver를 직접 켜서 테스트하는 방법이 기본적이고요 .
• 보조공학 기기 및 브라우저 툴: **스크린리더(Screen Reader)**는 시각장애인 사용자 관점의 테스트에 꼭 필요합니다. PC에서는 **NVDA (무료)**나 **JAWS (유료)**를 사용해 보고, 모바일은 앞서 말한 VoiceOver(iOS), TalkBack(Android)을 써봅니다 . 또한 키보드만으로 웹사이트 탐색해보는 것도 중요하죠 (Tab키로 이동 등). 색상 대비 분석기도 빼놓을 수 없는데, Color Contrast Analyzer 같은 툴을 쓰면 텍스트와 배경색의 명도대비가 WCAG 기준(4.5:1 등)을 충족하는지 체크할 수 있어요. HTML/CSS Validator로 마크업 오류를 잡는 것도 간접적인 접근성 개선에 도움 됩니다.
• 전문가용 종합 플랫폼: 나중에 사업이 확장되면 종합 접근성 관리 플랫폼을 도입하거나 개발 고려할 수도 있습니다. 해외 상용 솔루션으로 Level Access, Siteimprove, Monsido 등이 있는데, 크롤링을 통해 대규모 사이트를 지속 모니터링하고 대시보드로 보여주는 툴입니다. 국내에서는 큰 기업들이 자체적으로 이런 걸 구축하기도 하지만, 스타트업 단계에서는 비용이 부담되니 우선 오픈소스와 무료 도구들을 잘 활용하시면 충분합니다.
• 체크리스트와 표준 문서: 이건 소프트웨어라기보다 문서 도구인데요, 검수 체크리스트(Excel이나 Google Sheet로 제작)를 미리 만들어 두면 체계적으로 수동 점검을 할 수 있습니다. KWCAG 지침 24개 항목(또는 세부 체크포인트 50여 개)을 행으로 두고, 페이지별로 준수/불가 여부를 기록하는 식이죠. 이걸 활용하면 고객에게 “어느 항목이 얼마나 지켜졌는지” 정량적으로 보여줄 수 있어 유용합니다.

도구는 어디까지나 보조 수단이고, 컨설턴트의 판단과 경험이 가장 중요합니다. 자동화 결과를 맹신하기보다는, 왜 이게 문제인지 설명할 수 있는 눈을 기르는 게 필요하죠 . 처음에는 다양한 툴을 다뤄보면서 익숙해지고, 나중엔 자신만의 Toolkit을 구성해 효율을 높이면 됩니다.

공공기관 사업 절차 및 품질인증 📑

웹 접근성 컨설팅을 하다 보면 공공부문 일을 접하게 될 가능성이 큽니다. 공공기관은 법적으로 웹 접근성을 반드시 지켜야 하므로, 전문 컨설팅 수요가 많거든요. 여기서 알아둘 키워드는 **“품질인증(Web Accessibility Certification)”**입니다.

웹 접근성 품질인증 마크는 과학기술정보통신부 지정 인증기관이 웹사이트를 심사하여 접근성 수준을 공인 인증해주는 제도입니다. 공공기관 웹사이트나 민간 기업 중에서도 인증을 원하는 곳이 이를 신청하지요. 심사는 전문가 심사 + 사용자 심사로 이루어지고, 모든 평가항목 평균 95점 이상 등을 충족하면 인증마크를 줍니다. 이 마크는 초록색 타원형 안에 “WA (Wheelchair)” 로고가 들어있는데, 한 번쯤 보셨을 거예요  .

예를 들어 아래 그림이 과기정통부 WA 웹접근성 품질인증 마크입니다. 이런 마크를 받으면 해당 사이트는 1년간 인증이 유효하며, 정부 공인 **“접근성이 우수한 사이트”**로 대외적으로 인정받습니다 (품질인증 현황은 공개되어 누구나 조회 가능). 인증을 받았다는 건 단순히 지침만 통과한 게 아니라 장애인 당사자 평가까지 합격했음을 뜻합니다 .

공공기관은 매년 웹 접근성 자체점검을 하고 결과를 보고할 의무도 있고, 중요한 사이트들은 이 품질마크를 획득하도록 권고됩니다. 그래서 컨설팅 시 **목표를 “품질인증 받기”**로 정하는 경우가 많아요. 이때 절차는 대략 다음과 같습니다:

• 사전 준비: 기관이 인증 심사를 신청하면, 심사 비용(사이트 규모에 따라 몇 백만 원)과 서류를 제출합니다. 컨설팅하는 입장에선 신청 전에 미리 사이트를 점검해서 심사 통과 가능 수준까지 끌어올리는 게 핵심이죠.
• 1차 전문가 심사: 접근성 전문가들이 사이트를 분석하여 점수를 매깁니다. 보통 KWCAG 2.1 기준 24개 검사 항목에 대해 체크하고, 평균 95% 이상이어야 1차 통과 . 컨설턴트는 이 과정에서 심사단의 지적사항을 예측해 대비해야 합니다.
• 2차 사용자 심사: 시각장애인 등 장애인 평가단이 실제 이용 테스트를 합니다. 1차를 통과한 사이트만 2차를 진행하는데, 여기서도 평균 95% 이상 만족해야 최종 합격이에요 . 사용자 심사는 화면낭독기로 주요 기능 (예: 회원가입, 검색 등)을 수행해 보는 방식입니다. 컨설턴트는 장애인 테스트 과정에서의 애로를 최소화하도록 UI를 다듬는 걸 지원합니다.
• 인증 획득: 심사에 합격하면 인증서와 마크 이미지를 받습니다. 이를 사이트에 게시할 수 있고, 기관 입장에선 법적 요건 준수 및 사회적 책임 이행 실적으로 어필하게 되죠. 인증 결과는 웹와치(WebWatch)나 한국웹접근성인증평가원 같은 공식 사이트에 공시됩니다. (참고로 2025년 6월 기준 누적 15,000건 이상의 인증이 부여되었어요 .)

컨설팅 사업자로서 알아둘 것은, 자체적으로 인증을 부여할 순 없고 정부 지정기관을 통해야 한다는 점입니다. 현재 국내 인증기관은 몇 곳 없는데, 대표적으로 앞서 언급한 **웹와치(주)**와 한국웹접근성인증평가원(WA.or.kr) 등이 과기정통부 지정을 받아 활동 중입니다 . 우리 회사가 직접 인증기관이 되려면 정부의 지정을 받아야 하는데, 이는 엄격한 요건(전문인력, 평가체계, 전국 지원망 등)이 있어 단기간엔 쉽지 않습니다. 현실적으로는 우리가 컨설팅으로 사이트를 준비시킨 뒤, 인증기관 심사를 받도록 연계하는 형태가 일반적입니다.

또한 공공 웹 접근성 컨설팅 사업 절차는 일반 민간과 약간 다를 수 있습니다. 공공 프로젝트는 입찰 공고 -> 제안서 제출 -> 협상/계약 순으로 가며, 가격은 산정가이드에 따라 책정합니다. 이때 회사측 필요한 서류로 사업자등록증, 직접생산확인서, 중소기업확인서 등 각종 증빙을 요구할 수 있어 미리 준비해야 하고요. 계약 단계에서는 보안서약, 청렴계약 서약, 개인정보보호 서약 등 문서들도 종종 필요합니다. 또한 발주처와 산출물 수준 합의를 명확히 해야 해요. 예컨대 “결과보고서에 몇 개 페이지를 상세 분석할 것인지, 수정 제안은 어느 범위까지 포함인지” 등을 제안서 단계에서 협의해두는 것이 좋습니다. (뒤에서 견적/계약 파트에서 더 상세히 다룰게요.)

마지막으로, 법적 준수 의무에 대해 한 번 더 강조하면: 앞서 언급했듯 2008년~2013년 사이 단계적으로 법 적용 범위가 넓어져서, 현재는 대부분 기관과 기업이 접근성 준수 의무자입니다 . 혹시 고객이 *“우린 의무 대상 아니지 않나요?”*라고 물으면, *“장애인 차별금지법상 모든 사업자가 준수해야 합니다. 미준수시 시정명령과 과태료 가능성이 있습니다”*라고 안내해 주세요 . 실제로 2023년에는 한 시각장애인이 서울 시내 45개 병원을 상대로 접근성 소송을 제기한 사례도 있고 , 사회 분위기가 점점 엄격해지고 있습니다. 이런 맥락을 알고 컨설팅하면 고객 설득력이 훨씬 높아지겠죠?

고객 확보와 설득 전략 🎯

사업을 하려면 고객을 어떻게 유치하고 설득할지가 중요합니다. 접근성 컨설팅은 아직 모르는 분들도 많아서, 교육과 마케팅을 겸해야 할 때가 많아요. 몇 가지 전략을 말씀드릴게요:

• 법적 의무와 리스크 강조: 위에서 말한 법적 의무를 먼저 상기시키는 게 효과적입니다. *“안 지키면 불법입니다”*만큼 강력한 동기는 없거든요. 특히 공공기관이나 대기업일수록 **컴플라이언스(준법)**를 중시하므로, 관련법 조항과 처벌 규정 등을 근거로 설명하면 경각심을 갖습니다 . “이미 국내에서도 소송 사례가 발생하고 있습니다”, “시정 명령 불응 시 최대 3천만원 과태료 대상입니다” 이런 식이죠. 다만 부정적 요소만 말하면 부담스러워하니, 긍정적 효과도 함께 어필해야 합니다.
• 시장과 잠재고객 강조: 접근성을 개선하면 사업적으로도 이득이라는 점을 설득해야 해요. “노인인구, 장애인 인구 포함하면 귀하의 서비스 잠재고객이 20~30% 늘어납니다”, “미국에서는 장애인 소비자의 연간 소비가 5천억 달러에 달하는데 국내도 고령자 구매력을 무시 못합니다” 등 데이터로 뒷받침하면 설득력이 높아집니다. 또 *“접근성은 결국 사용성 개선이라서, 장애가 없는 사용자에게도 웹사이트 이용 편의가 향상됩니다”*라고 알려주세요. 예를 들어, 모바일 환경에서 일시적으로 손이 불편한 상황이나 밝은 햇빛 아래 화면이 잘 안 보이는 경우에도 접근성이 좋은 사이트는 더 잘 쓰일 수 있거든요. 이런 보편적 UX 향상 측면을 강조하면 경영진에게도 긍정적으로 다가갑니다.
• 기업 이미지와 CSR: 접근성을 챙기는 기업이라는 건 사회적 책임(CSR)과 포용성 측면에서 이미지 향상을 가져옵니다. ESG 경영이 화두인 요즘, *“우리 회사는 모두를 위한 서비스를 만든다”*는 메시지는 브랜딩에 도움이 되죠. 실제로 접근성 품질마크를 획득한 기업들은 보도자료를 내기도 하고, 대외 홍보에 활용합니다. 고객에게 *“인증을 따면 언론홍보나 공신력 제고에 활용할 수 있다”*고 알려주세요. 투자 유치나 공공사업 참여시에도 접근성 인증 여부를 가점 요인으로 보는 경우가 생기고 있어서, 장기적으로 경쟁우위 확보 수단임을 인지시킵니다.
• 무료 진단 및 사례 제시: 초기 영업 단계에서는 부분적인 무료 진단 서비스를 미끼로 활용할 수 있습니다. 예를 들어 *“귀사 홈페이지 주요 페이지 2~3개를 무료로 점검해 간략 리포트를 드리겠다”*고 제안해 보세요. 결과를 보여주면서 *“이런 문제들이 지금 있다. 저희가 도와드리면 100% 개선하고 인증까지 받게 해드리겠다”*고 이어가면 훨씬 현실감 있게 다가옵니다. 또한 동종 업계의 사례를 들면 설득이 수월합니다. “○○은행도 작년에 저희 컨설팅 후 인증 획득했습니다”, “△△공공기관은 접근성 개선 후 이용자 만족도가 향상됐습니다” 등 레퍼런스를 보여주는 거죠. 처음엔 실적이 없으니 가상의 케이스스터디나 해외 사례라도 언급하면서 전문성을 부각하세요.
• 전략적 네트워킹: 웹 접근성에 관심 있는 커뮤니티나 행사에 적극 참여해 네트워크를 넓히는 것도 고객 확보에 도움 됩니다. 예를 들어 한국시각장애인연합회나 장애인단체 행사, 웹 개발자 컨퍼런스 등에 가서 우리 서비스를 알리는 거죠. 또 웹 에이전시, SI업체들과 제휴를 맺고 그들이 프로젝트 딸 때 접근성 파트너로 함께 투입되는 모델도 고려해볼 만합니다. 이런 파트너십은 혼자 직접 영업하는 것보다 수월할 수 있어요.
• 온라인 콘텐츠 마케팅: 블로그나 SNS에 접근성 관련 유용한 정보를 꾸준히 발신하면 전문업체로 인식되어 고객 문의로 이어질 수 있습니다. 예컨대 “누구나 쉽게 하는 웹 접근성 자가진단 5가지 팁”, “최근 본 웹 접근성 개선 우수사례 소개” 같은 글을 올려보세요. 검색을 통해 들어온 사람들이 곧 잠재 고객입니다. 콘텐츠를 통해 교육도 해주고 자연스레 *“도움이 필요하면 연락주세요”*를 어필하는 거죠.
• 제안시 태도: 마지막으로 실제 영업미팅이나 제안자리에선 너무 기술적 용어만 나열하지 말고, 고객 입장에서의 가치를 강조하세요. “귀사의 고객 누구도 소외되지 않게 하는 것”, “선도기업 이미지 구축”, “개발팀 업무 효율 증진” 등 해당 조직에 무엇이 이득인지 맞춤형으로 이야기하는 겁니다. 그리고 과장된 약속은 금물이에요. 접근성을 한 번에 100% 완벽히 만드는 건 어려울 수 있으니, *“현 상태에서 최선을 다해 개선하고, 앞으로 지속 개선 체계를 마련해드리겠다”*는 현실적인 접근이 신뢰를 줍니다.

결국 고객을 설득하는 핵심은: 법적 리스크 해소 + 사업적 이득 + 사회적 가치 이 세 박자를 모두 보여주는 것입니다. 그러면 대부분의 담당자들은 고개를 끄덕이기 마련이지요.

경쟁사 현황 및 차별화 🏆

현재 국내 웹 접근성 컨설팅 시장의 플레이어들은 몇 가지 부류로 나뉩니다. 대표적인 경쟁/참고 업체를 살펴보고, 우리가 어떻게 차별화할지 생각해볼게요:

• 전문 컨설팅 회사: 웹 접근성만을 전문으로 하는 컨설팅 업체들이 있습니다. 예를 들어 **웹와치(WebWatch)**는 정보접근성 분야에서 가장 유명한 민간기관으로, 과기정통부 지정 품질인증기관이기도 합니다 . 또 한국웹접근성인증평가원(WA.or.kr)도 비슷한 역할을 하지요. 이들은 인증 업무까지 겸하기 때문에 평가 권위가 높습니다. 민간에서는 SNC Lab, 웹소울랩(Web Soul Lab), 수지소프트, Headers 같은 업체들이 컨설팅과 교육을 제공하고 있어요 . 이들 회사는 대체로 자동 진단 솔루션이나 자체 방법론을 내세우며, 10년 이상 경력의 컨설턴트를 보유한 곳도 있습니다. 프로젝트 레퍼런스도 꽤 많아서 우리 입장에선 벤치마킹 대상이자 경쟁상대가 되겠죠.
• 종합 IT기업/에이전시: 네이버나 카카오 같은 대형 IT기업은 내부 접근성 전문팀을 갖추고 있지만 외부 컨설팅 시장에 직접 나오진 않습니다(내부 서비스 개선에 집중). 대신 SI 대기업(예: 삼성SDS, LG CNS 등)이 공공 웹사업을 할 때 자체적으로 접근성 진단인력을 두거나, 우리 같은 전문업체에 하청 주기도 합니다. 또 웹 에이전시 중에는 접근성 분야에 특화한 곳도 있는데, 예를 들어 어떤 에이전시는 *“우리 접근성 퍼블리싱 가능합니다”*를 강점으로 내세워 사이트 구축 사업을 유치하기도 합니다. Strictly 접근성 컨설팅만 하는 건 아니지만 관련 서비스를 포트폴리오로 갖고 있는 경쟁자라고 볼 수 있죠.
• 테스트 전문업체: 기능 테스트(QA)를 주력으로 하는 테스팅 전문 기업들도 접근성 테스트를 서비스로 제공합니다. 예컨대 테스트웍스(TestWorks) 같은 AI/데이터라벨링 기업이 시각장애인 테스터 커뮤니티를 활용해 접근성 사용자 테스트 사업을 하기도 했어요. 이런 업체들은 사용자 테스트에 강점이 있지만, 개선 컨설팅까지는 깊게 안 하는 경우도 있어 협업 내지 경쟁이 가능합니다.

우리의 차별화 전략은 다음을 고민해볼 수 있습니다:

• 전문화 vs. 원스톱: 경쟁사들이 모두 잘하진 못하는 틈새를 찾는 것이 중요합니다. 예를 들어, 일부 업체는 진단까진 훌륭한데 개선 구현 지원이 약할 수도 있습니다. 그렇다면 개발 실무 출신 컨설턴트를 내세워 *“우리는 코드 레벨까지 책임지는 컨설팅”*을 강조하는 겁니다. 반대로 어떤 고객은 인증 취득만 원할 수도 있는데, 그럴 땐 인증 대비 경험을 강조해야 하고요. *“원스톱 서비스”*를 차별화 포인트로 내세우거나, 반대로 *“특정 산업 분야 전문”*으로 갈 수도 있습니다. 가령 금융 웹 접근성 특화라든지, 모바일 앱 접근성 전문 같은 식이죠.
• 가격 경쟁과 가치 경쟁: 신규 사업자로서 초기에 가격 경쟁력을 갖출 수 있습니다. 고정비가 적으니 공격적으로 견적을 제시하면 일부 시장을 뚫을 수 있겠지만, 너무 저가로 가면 지속성이 없으니 가성비 좋은 서비스라는 이미지를 심는 게 좋습니다. 예를 들어 “대기업 수준 컨설팅을 합리적 비용에 제공” 같은 메시지요. 다만 장기적으로는 가격보다는 결과물의 질과 관계로 승부해야 합니다. 고객 맞춤형 대응이나 빠른 피드백 등 작은 회사만의 강점을 부각하세요. 대형사는 관료적일 수 있으니, 우리는 *“더 발로 뛰고 챙겨준다”*는 인식을 주면 신뢰를 쌓을 수 있습니다.
• 기술 도구의 활용: 만약 자체적인 자동화 스크립트나 도구를 개발할 역량이 있으면 큰 차별화 포인트가 됩니다. 예를 들어 “자체 개발한 크롤러로 수백 페이지를 단시간에 진단” 해준다거나, “AI를 활용한 접근성 이미지 자동 대체텍스트 제안 기능 제공” 같은 식입니다. 초기엔 이런까지는 어려워도, 오픈소스를 커스터마이징해서 우리만의 프로세스에 녹여내면 경쟁사보다 효율적이면서도 저렴한 서비스를 제공할 수 있겠죠.
• 인증 파트너십: 만약 우리 회사 이름으로 공인 인증을 직접 줄 수 없다면, 공인 인증기관과 협력 관계를 잘 맺어두는 것도 차별화입니다. 예를 들어 웹와치 등과 MOU를 맺고 “사전 컨설팅 거친 사이트는 인증 심사시 우선 검토” 같은 부가혜택을 만들 수 있다면 고객이 선호하겠죠. 아니면 학계 전문가(예: 대학 연구실)와 연결해 *“최신 연구 기반 컨설팅”*을 강조할 수도 있고요.
• 컨설턴트의 역량: 무엇보다 사람이 자산인 사업입니다. 우리 팀에 누가 있는지를 어필하세요. “WA 전문가 1급 자격 보유자 X명, 관련 경력 평균 10년” 이런 식입니다. 아직 인력이 적다면, 어드바이저로 외부 전문가를 자문위원으로 모셔 명망을 빌릴 수도 있습니다. 경쟁사 대비 젊고 열정적인 팀이라는 이미지를 주는 것도 방법입니다. 기술 트렌드에 밝고 고객 말에 귀 기울이는 친밀한 파트너로 자리매김한다면 꾸준히 선택받을 거예요.

정리하면, 경쟁사를 철저히 연구하여 그들의 강점은 따라가고 약점은 우리 강점으로 만들면 됩니다. 초기엔 작은 성공사례 하나하나가 중요하니, 한 프로젝트 한 프로젝트를 최상의 품질로 완수하며 레퍼런스를 쌓으세요. 그러면 자연스럽게 입소문과 신뢰가 생겨 우리만의 입지를 구축하게 될 것입니다.

프로젝트 견적 및 계약 실무 팁 📑

마지막으로, 실제 컨설팅 프로젝트를 수주하고 수행할 때의 견적 산정과 계약 노하우를 공유해 드릴게요. 이 부분은 엑셀에 정리된 상세 질문들(견적 방법, 리스크 버퍼, 계약서 주의사항 등)을 토대로 현실적인 조언을 드리겠습니다.

1. 적정 리소스 산정 방법과 견적 항목 📐

“이 일을 하려면 사람/시간 얼마나 필요하지?” 견적의 출발점이죠. 접근성 컨설팅에서는 주로 Man-Month(인/월) 기준으로 투입공수를 산정합니다. 고려 요소는 다음과 같아요:

• 업무 난이도: 대상 사이트의 규모와 복잡도에 따라 다릅니다. 예를 들어 단순한 홈페이지 vs. 복잡한 전자정부 시스템은 난이도가 다르겠죠. 페이지 수, 서비스 기능 수, 멀티미디어 콘텐츠 양 등을 파악해 난이도를 평가합니다. 일반적으로 페이지 템플릿 종류와 주요 기능 시나리오를 기준으로 검사 포인트 수를 산출하면 비교가 됩니다.
• 인력 숙련도: 투입할 컨설턴트의 경력과 숙련도에 따라 같은 작업도 소요 시간 차이가 납니다. 고경력자는 빠르게 평가하지만 인건비가 비싸고, 주니어는 저렴하지만 더 오래 걸릴 수 있죠. 적절히 인력 조합(예: 시니어 1 + 주니어 1)을 고려하세요. 견적 산정 때 이를 반영해 평균 인건비를 계산합니다.
• 필요 역할 및 수량: 프로젝트에 필요한 역할들을 정의합니다. 접근성 진단 전문가, 보조공학 테스트 요원(시각장애인 테스터 등), 개발 코드 리뷰어, 프로젝트 매니저(PM) 등이 있을 수 있죠. 작은 프로젝트는 한 사람이 여러 역할을 할 수도 있지만, 큰 프로젝트는 역할별로 배치합니다. 그런 뒤 각 역할별 투입 인력 수와 기간을 책정합니다.
• TO/MM/턴키 여부: 일의 성격도 고려됩니다. 단순 자문 형태(Time & Material)이냐, 완료물 기준 턴키(일괄) 계약이냐에 따라 리스크 버퍼가 달라져요. 컨설팅은 보통 턴키에 가깝습니다. 한 번 계약하면 목표 달성까지 완료물 책임지는 형태라, 견적에 리스크 완충분을 넣어야 합니다 (뒤에 설명). 만약 시간단위 과금 T&M이라면 실제 소요만큼만 과금하지만, 국내에선 이런 형태는 드물고 거의 일괄 계약입니다.
• 부가 서비스 포함 여부: 접근성 교육, 가이드 문서 제작, 인증 대응 지원 등 부가항목을 포함하면 당연히 추가 인력·기간이 들죠. 예를 들어 교육 1회 진행하려면 강사 준비시간, 자료 작성 시간 등이 필요하므로 별도 산정합니다.

이렇게 고려해서 **총 인월(Person-Month)**을 계산한 뒤, 내부 단가(한 명 한 달 투입시 가격)를 곱하면 인건비가 나옵니다. 여기에 **간접비(재경비)**와 **마진(이윤)**을 더해 최종 견적이 됩니다 . 견적서에는 일반적으로 주요 작업 항목과 수량, 단가를 명시합니다. 예를 들어:

• 접근성 진단: 20일 × 1명 = 20일
• 개선 컨설팅: 10일 × 1명 = 10일
• 보고서 및 인증준비: 5일 × 1명 = 5일
• 교육 세션: 1회 (8시간)

이런 식으로 항목별 인력·시간을 적고, 합산 인건비를 계산합니다. 그리고 간접비, 이윤은 항목으로 따로 표시하거나, 항목별 단가에 녹여넣을 수 있습니다.

견적서에는 보통 무엇을 쓰나?

견적 요청 단계에서 고객에게 보내는 견적서는 항목별 금액을 보여줍니다. 주요 항목으로:

• 인건비 (혹은 작업별 세부 비용)
• 간접비 (재경비)
• 이윤(기술료)
• 부가세

등을 명시해서 총액을 제시하지요. 또는 간단히 *“총 N만원 (VAT별도)”*만 쓰고, 상세는 내부 자료로 갖고 있을 때도 있습니다. 하지만 투명성 측면에서 항목을 적어주는 게 좋아요. 추후 협상이나 내부 결재에서도 왜 이 금액인지 설명이 되거든요.

2. 빠른 견적 대응을 위한 팁 ⚡

**“견적 좀 대략 얼마나 나오나요?”**라는 문의가 오면, 컨설팅 특성상 상세 견적서는 며칠 걸리지만 대략적인 답은 빨리 주는 게 좋습니다. 현재 링키지랩팀은 답변에 2~3일 걸린다고 하는데, 이것도 꽤 빠른 편이지만 즉답을 요구하는 경우도 많습니다. 빠르게 대응하려면 내부 표준 단가표나 유사 사례 데이터베이스를 가지고 있는 것이 도움됩니다.

예를 들어, “10개 페이지 규모의 간이 진단 컨설팅 = 약 500만원”, “대규모 공공기관 전체 사이트 컨설팅 = 2천만원 이상” 등 패키지별 기준 견적을 만들어 두세요. 과거 수행했던 프로젝트들을 정리해서 페이지 수 대비 평균 비용 같은 지표를 산출해두면 문의 시 활용하기 편리합니다.

또 하나는 신속한 정보 파악인데요. 문의 단계에서 최소한 알아야 할 내용을 미리 리스트업해 두고, 전화를 받으면 빠르게 질문해보는 겁니다. “대상 웹사이트 규모는 어떻게 되나요? 주요 서비스 기능은? 모바일 앱 포함인가요? 인증 마크까지 원하시는지?” 등등. 이런 Q&A 체크리스트에 따라 정보를 받으면, 그 자리에서 대략 머릿속 계산이 가능합니다.

내부적으로는 견적 산정 엑셀 템플릿을 준비해 놓으세요. 항목별 인원·기간을 넣으면 자동으로 금액 계산되고, 간접비/이윤도 산출되게 해둡니다. 그러면 1차 견적안을 금방 만들 수 있습니다. 2~3일씩 걸리는 건 내부 승인 프로세스 때문일 수 있으니, 그 부분도 최적화하면 좋아요 (예: 일정 금액 이하 견적은 팀장 재량 승인).

요약하면: 표준단가, 과거사례DB, 질의체크리스트, 자동계산 툴 이 4가지를 갖추고 있으면 견적 문의에 실시간 대응하는 데 큰 도움이 됩니다.

3. 여유 리소스와 리스크 버퍼 관리 🔒

프로젝트 계획에는 항상 오차와 돌발상황이 생기기 마련입니다. 그래서 **여유 리소스(버퍼)**를 어느 정도 포함해야 안전한데요, 적정 비율은 얼마나일까요?

일반적으로 투입 인력 대비 1020%**의 여유 인원을/시간을 잡는 걸 권장합니다. 예를 들어 2명×2개월(총4인월) 프로젝트라면 **0.50.8인월 정도 추가 여유를 두는 식이죠. 이 버퍼는 여러 리스크 대응용입니다:

• 담당 컨설턴트의 질병/사고 등의 대체 인력 필요 상황
• 고객 측 지연 (자료 전달이 늦다든가, 피드백이 느려지는 경우)
• 추가 요구사항 증가 (중간에 작업 범위 늘어나는 경우)

버퍼 인력은 꼭 투입 안 되더라도 대기할 수 있게 내부 리소스를 관리하면 좋습니다. 말이 쉽지, 소규모 팀은 여유 인력이 없을 수도 있잖아요. 그래서 현실적으로는 초기 일정 산정 시 살짝 넉넉하게 잡는 방식으로 버퍼를 마련합니다. 예컨대 실제 8주 걸릴 일이라도 10주 계획으로 제시한다든지, 1명이 할 일을 1.2명몫으로 견적 넣는다든지 합니다.

특히 내부 결정 지연 등 경험적 리스크에 대비해 평균 10% 정도는 버퍼로 항상 보라고들 합니다. 예전 프로젝트들을 돌아보면 일정 지연 요인들이 있었을 텐데, 그때 얼마나 추가 시간이 들었나 평균내 보는 것도 방법이에요.

또 버퍼의 형태도 고민인데, 인력 추가 vs 기간 연장 둘 중 하나입니다. 기간 버퍼를 둘 것인가, 인원 버퍼를 둘 것인가. 기간 버퍼는 딜리버리가 조금 지연돼도 안에서 흡수하는 거고, 인원 버퍼는 누군가 추가 투입되는 거죠. 계약상 납기일이 중요하다면 기간 버퍼를 작게 하고 대신 필요시 인원을 늘려서 맞추는 편이 낫습니다. 반대로 인력 증원이 어려운 상황이면 애초에 기간에 여유를 주세요.

버퍼를 견적서에 노출하나? 대부분 직접적으로 적시하지는 않습니다. “비상시 투입 인력” 이런 건 안 적고, 내부적으로만 계산해두죠. 고객에게는 그 부분까지 투명하게 말할 필요는 없지만, 협의 시 “혹시 일정 문제 생겨도 리커버리 계획을 갖추고 있다” 정도로 안심시켜주면 됩니다.

4. 재경비와 수익률 구성 💵

견적 금액 구성에서 재경비(간접비)와 이윤 설정은 회사 수익성과 직결된 부분입니다. 일반적으로 소프트웨어 사업 대가산정 기준을 참고하면 좋은데요, 정부 가이드라인에 따르면 컨설팅/운영 단계의 제경비율을 최근 **직접인건비의 140150%**까지 상향하라는 권고가 있습니다 . 예전엔 110120% 수준이었는데 업계 현실화를 위해 높인 거죠. 이 말은, 만약 순수 인건비(투입 인건비 총액)가 1,000만 원이면 재경비를 1,400만 원까지 책정해도 된다는 뜻입니다. 재경비에는 회사 운영비, 임대료, 장비비, 관리비 등이 다 포함되니 너무 낮게 잡으면 손해입니다.

그 다음 **이윤(기술료)**인데요, 이것은 인건비+재경비 합계의 20% 내외로 정하는 게 보통입니다 . 소프트웨어 사업에선 20%를 기준으로 하지만, 컨설팅 특성이나 계약 형태에 따라 10%로 줄이기도 하고 15% 정도로 타협되기도 합니다. 영업 전략상 처음 진입이라 마진 적게 가져가겠다 하면 10%만 붙일 수도 있고, 우리 전문성에 프리미엄 받겠다 하면 20% 이상도 가능하죠. 다만 공공시장에선 가이드라인을 따르는 게 무난합니다.

예시로 견적을 계산해보면:

• 직접 인건비: 1,000
• 재경비 (140%): 1,400
• 직접인건비+재경비 = 2,400
• 이윤 (20%): 480
• 합계 = 2,880 (+ 부가세 별도)

이런 식이 됩니다. 부가세 10%를 합하면 총 계약금액이죠.

내부적으로는 어느 부분에서 수익을 낼지 결정해야 합니다. 인건비는 실제 인력비용 지급으로 거의 나갈 테니, 재경비와 이윤이 회사 이익으로 남습니다. 소규모 기업은 재경비를 많이 못 붙이는 경우도 있어요. 왜냐면 발주처에서 “이 회사 간접비가 왜 이렇게 높냐” 물을 수 있거든요. 그래서 적당히 조절도 필요합니다. 초기엔 재경비 100~120% 수준으로 낮춰주고, 대신 인건비 단가를 높게 산정하는 방법도 있습니다. 혹은 재경비는 0으로 하고 이윤만 크게 붙이는 회사도 있긴 한데, 이는 권장되진 않습니다(구성요소별 균형이 안 맞으면 의아해 하니까요).

결론적으로: 적정한 재경비와 이윤은 업계 표준에 맞추되 우리 원가구조를 고려해야 합니다. 무턱대고 남들만큼 붙였다가 가격 경쟁에서 밀리면 곤란하고, 또 너무 박하게 견적 내면 남는 게 없어요. 보통 **순수익 10~15%**는 남도록 설계하는 게 건강합니다. 이후 실제 집행하면서 예산을 절약하면 그만큼 추가 이익이 나는 거죠.

Tip: 공공 계약서엔 재경비와 이윤이 명시되기도 하니, 그 수치가 정부 지침 범위 내인지 확인하세요. 현재는 재경비 최대 150%, 이윤 최대 20% 정도로 보시면 됩니다 .

5. 납품 결과물 수준 협의와 범위 관리 📋

결과물(SOW, Scope of Work) 협의는 계약 전에 꼭 명확히 해야 합니다. 언제, 어떻게 이 얘기를 하느냐도 중요하죠. 이상적인 것은 제안서 제출 단계에서 이미 납품물의 수준을 박아두는 것입니다. 예를 들어:

• “진단 결과보고서는 문제 리스트와 개선 권고까지 포함하며, 1회에 한해 고객 피드백을 반영한다.”
• “개선 가이드 문서는 KWCAG 2.1 항목별 설명과 사례 코드를 포함한다.”
• “인증 취득 보장을 위해 2차례 사전 검증 서비스를 추가 제공한다.”

이런 식으로 구체적으로 적시해 놓습니다. 그래야 나중에 “이것도 해주세요, 저것도 포함인 줄 알았다” 하는 분쟁을 줄일 수 있습니다.

만약 제안 단계에서 확정 못 했다면, 계약 직전에라도 합의서나 과업 명세서에 이 내용을 넣어야 합니다. 보통은 계약서 본문+제안서를 세트로 효력을 갖게 하니 제안서에 잘 써두는 게 좋아요.

언제 협의하는 게 좋나? 너무 이른 단계부터 세부 산출물을 박으면 우리의 제안이 창의적으로 보이지 않을까 걱정될 수 있습니다. 하지만 *납품 수준(Level of Deliverables)*은 고객도 궁금해하는 부분입니다. 특히 접근성 보고서를 받아봤던 경험이 있는 고객은 *“어느 정도 깊이로 분석해주나”*를 묻기도 해요. 그러니 초기 미팅에서 고객 니즈 파악하면서 자연스럽게 “어떤 결과를 기대하시는지” 물어보세요. 그에 맞춰 우리의 제공 수준을 설명하면 됩니다.

예컨대 고객이 “구체적인 코드 레벨 수정지침까지 원한다” 하면 우리는 *“네, 소스코드 예시까지 담긴 가이드 문서를 드립니다”*라고 답하고, 만약 “그냥 이행 여부 확인용 리포트면 된다” 하면 그에 맞춰 힘조절을 합니다. 중요한 건 과소/과대 제공하지 않고 딱 맞춤형으로 하는 거예요.

또 협의 방법으로는, 기존 샘플 결과물을 보여주는 게 효과적입니다. 우리가 과거에 만든 보고서나 가이드 일부를 예시로 주면서 *“이런 식으로 드릴 예정”*이라고 하면 고객이 이해하기 쉽습니다. *“결과물 예시를 보고 서로 기대치를 맞추자”*는 접근이지요.

Scope 관리 측면에선, 제안서 범위를 넘어서는 요구가 나올 때 단호하게 **변경관리(Change Request)**를 하셔야 합니다. 계약서에 “범위 외 추가 작업은 별도 협의” 문구를 넣어두고, 고객이 새로운 요구를 하면 추가 견적 또는 범위조정 얘기를 바로 꺼내세요. 처음엔 관계 생각해서 무조건 들어주다 보면 나중에 감당 못 하니, 협의 시기부터 선을 긋는 것이 서로에게 좋습니다.

6. 초기 견적 버퍼 및 네고(가격 협상) 전략 💸

견적에는 종종 네고(가격 할인) 여지를 남겨두는 것이 현실적입니다. 많은 발주처가 “조금 깎아줄 수 없나” 한 마디 하는 문화가 있거든요. 그렇다면 처음부터 적정 버퍼를 얹어 견적 제시하고, 협상 후 최종 우리가 원하는 금액에 수렴되도록 하는 게 좋겠죠.

적정 버퍼 수준은 일반적으로 총액의 5~15% 정도입니다. 이를테면 우리가 1억 원은 받아야겠다 싶으면 1억1천만 원쯤 부르고 10% 깎아주는 식이죠. 너무 버퍼를 크게 잡아 30~40% 높게 불렀다가 “말도 안 되게 비싸네” 하고 바로 탈락할 위험도 있으니 주의해야 합니다.

특히 공공 입찰은 예정가격 대비 얼마나 할인이냐를 평가하는 경우가 많아서, 처음부터 실가격을 써내야 할 때도 있습니다. 그 경우엔 버퍼보다 우리 최소 마진을 확보하는 금액으로 딱 제출하고, 협상보다는 기술평가 점수로 승부해야겠지요.

민간 프로젝트 네고 팁: 먼저, 고객이 가격을 깎으려 할 때 대신 범위를 조정하거나, 조건을 붙여 대응하는 게 좋습니다. “금액을 내리길 원하시면, 보고서 깊이를 줄여서 요약본으로 드릴게요”, “교육 세션을 빼고 견적을 다시 드리겠습니다” 등등. 이렇게 give & take를 하면 고객도 함부로 깎지 못하고, 혹 깎이더라도 우리 리소스 투입이 줄어들어 손해를 상쇄합니다.

만약 꼭 할인을 해야 한다면, 표준 할인 사유를 만들어 두세요. 예: “첫 거래 할인 5%”, “연계 미래 사업 고려 10% 특별할인” 이런 명목을 붙이면 내부 수익규정에도 합리화되고, 고객에게도 특별대우 받는 느낌을 줍니다. 그리고 할인 한계를 정해두고 그 이상은 확실히 거절해야 합니다. “저희도 인건비가 있어서 이 이하로는 어렵습니다” 솔직히 말하는 것도 때론 통합니다.

초기 견적 버퍼를 너무 타이트하게 안 잡으면, 혹시 네고 없이 계약되더라도 추후 리스크 대응 재원으로 활용할 수 있으니 안전장치가 됩니다. 이 버퍼를 *“네고 대비 용도”*뿐만 아니라 예상치 못한 추가 일에 쓰는 거죠.

한편 네고만 신경쓰다 본질을 잃으면 안 됩니다. 견적 협상 시 가격 얘기만 하기보다는, 우리 서비스의 가치를 재강조하며 가격을 정당화하는 게 중요해요. “물론 비용은 조금 부담이시겠지만, 저희가 들인 공수만큼 확실한 결과를 드릴 겁니다”, “이 부분은 투자라고 생각하시면 이후 유지보수 비용이 줄어들 거예요” 등 설득을 곁들이세요. 그러면 깎더라도 덜 깎거나, 못 깎더라도 납득하고 진행하게 됩니다.

7. 리스크별 버퍼 산정 로직 🎛️

프로젝트 리스크마다 별도의 완충 전략이 필요합니다. 경험적으로 자주 발생하는 리스크와 그에 대한 버퍼 적용 방법을 예로 들어볼게요:

• 의사결정 지연 (고객 측): 가장 흔합니다. 보고서를 드렸는데 검토에 2주 걸린다거나, 교육 일정을 내부 조율하느라 한 달 밀린다거나 하는 식이죠. 이럴 땐 일정 버퍼가 필수입니다. 프로젝트 총기간의 10~20% 정도를 추가로 잡아, 이러한 지연을 흡수하게 합니다. 만약 제때 안 끝나더라도 우리의 다른 프로젝트 일정과 안 겹치게 완충하는 거죠.
• 요구 변경/추가: 중간에 고객이 새로운 페이지를 또 봐달라거나, 모바일 앱도 포함해달라는 등 스코프 확장 위험이 있습니다. 이를 대비해서는 기획 단계 버퍼가 필요합니다. 제안서에 어느 정도 서비스/페이지 수 산정치를 넉넉히 기입하거나, 아예 **“추가 페이지 N개까지는 서비스”**라고 명시해두는 것도 방법입니다. 그 “N개”를 버퍼 잡아두는 거죠.
• 품질 리스크: 혹시 결과가 기준에 못 미칠 경우 추가 작업 리스크도 고려합니다. 예컨대 첫 진단 때 놓친 문제가 뒤늦게 발견되면 다시 보고서를 고쳐야 할 수도 있죠. 그래서 검수 단계에 버퍼 기간을 좀 넣고, 내부 QA체크 시간을 확보합니다. 인력 버퍼 측면에선 크로스체크 인원을 추가로 잠깐 투입하는 것도 좋은 전략입니다 (동료 컨설턴트가 한 번 훑어보는 등).
• 인력 손실: 담당자가 갑자기 빠지게 되는 최악의 경우 대비입니다. 작은 회사일수록 타격이 커요. 대체 가능한 인력 한 명을 애초에 파트타임이라도 걸쳐놓는 게 중요합니다. 프로젝트 투입은 안 하더라도, 최소한 상황 인지하고 있게 해서 사고 시 바로 메우도록 하죠. 비용 버퍼로는 인력 교체에 따른 ramp-up 기간(새로운 사람이 익숙해지는 기간)을 1~2주 추가 가정해 두는 게 좋습니다.
• 기술적 예측 불가: 예를 들어, 고객 사이트가 특수한 기술로 만들어져 있어서 검사 툴이 안 먹힌다거나, 서버 접근 권한 문제로 애로사항이 생길 수 있습니다. 이런 건 알기 어렵지만, 이전 경험으로 비춰 항상 약간의 예비시간을 두세요. 컨설팅 범위에 *“기술적 환경 설정 기간 포함”*이라고 해서 1주 버퍼 넣어둔다든지, 계약서에 “예상치 못한 기술적 이슈 발생 시 양측 협의” 조항을 넣어 책임을 분담시키기도 합니다.

버퍼 적용은 평균치에 의거하라는 게 제 경험입니다. 프로젝트 여러 개 해보면 “항상 이만큼 모자라더라” 하는 감이 옵니다. 그 평균 %만큼을 미리 더해 놓으면 대체로 맞아 떨어집니다. 물론 프로젝트마다 다르니, 상황별로 가변적용 해야 하고, 안 썼다고 클라이언트한테 돌려줄 필요는 없지만 내부 효율을 높이는 방향으로 쓰면 되겠죠.

결정적으로, 버퍼를 너무 많이 넣어서 경쟁사 대비 가격이 확 뛰면 수주를 못할 수 있으니, 경험을 쌓아 정확도를 높이는 것이 최선입니다. 초반엔 살짝 보수적으로 넣고, 나중엔 데이터 기반으로 최적화하면 될 거예요.

8. 지체상금(딜레이 페널티)의 일반 수준 ⚖️

계약서에 자주 등장하는 지체상금(딜레이에 대한 페널티)에 대해 궁금하실 텐데요. 일반적으로 공공 계약에서는 *“지연 1일당 계약금액의 0.1%”*를 지체상금으로 정하고, 최고 10% 한도로 부과합니다 . 예를 들어 1억짜리 계약이 10일 지연되면 0.1%씩 10일 = 1%, 즉 100만원을 위약금으로 내는 식이죠. 민간 계약도 이를 참고해 정하는 경우가 많습니다.

이 수치는 업종과 계약에 따라 조금씩 다를 수 있지만, 웬만하면 0.1%/일, 상한 10% 룰이 보편적입니다 . 건설 쪽은 다른 기준도 있지만, IT 용역은 이게 맞습니다. 만약 계약서 초안에 지체상금 관련 조항이 없다면, 우리가 굳이 넣자고 할 필요는 없고요(😅). 대신 있으면 과하지 않게 협상하세요. 아주 가끔 “1일 1%” 이런 무리한 조항을 넣는 발주처도 있는데, 그건 말도 안 되는 수준이라 꼭 수정해야 합니다.

실무적으로는, 납기일을 어길 상황이 오지 않도록 하는 게 1차 목표지만 불가피하면 미리 사전에 양해와 연장 승인을 받는 것이 중요합니다. 보통 계약상대방도 바로 지체상금 물리기보단 연장 계약이나 일부 인수인계로 해결하려 하니까요. 우리의 책임이 아닌 지연(예: 고객 측 승인 지연)이라면 서면으로 증빙을 남겨두고, 필요 시 지체상금 면제를 요청할 수도 있습니다.

한 가지 팁: 계약서에 “상호 협의 하에 납기 조정 가능” 같은 문구가 있으면 좋습니다. 그러면 지연사유서 제출하고 일정 바꿔 지체상금을 피해갈 수 있거든요. 처음부터 넣기 어려우면, 최소한 천재지변이나 발주처 귀책의 경우 면제 조항이라도 포함하도록 하세요.

일반적인 수준을 알았으니, 계약 협상 시 이 부분은 표준대로 하되 너무 엄격하지 않게 가져가시면 됩니다.

9. 계약서 작성 시 필수 점검 요소 📝

계약 단계에서는 법적 문서 검토에 신경 써야 합니다. *“용역 수주사 관점에서 계약서에 꼭 챙겨야 할 것”*들을 정리해볼게요:

• 범위와 산출물 명시: 앞서 이야기한 **업무 범위(Scope)**가 계약서(또는 첨부 제안서)에 정확히 담겨야 합니다. “무엇을 제공하고 무엇은 제외인지” 분명해야 추후 분쟁을 막습니다. 특히 산출물 개수, 형태, 버전 횟수 등을 특정해두면 좋아요 (예: 보고서 2부, 프린트+PDF, 수정요청 1회 한정 등).
• 일정과 납기: 착수일과 완료일을 명시하고, 주요 마일스톤(중간보고 등)이 있으면 날짜를 넣습니다. 그리고 지체상금 조건을 확인해야겠죠. 가능한 한 **완료일 정의를 “최종 보고서 제출일”**로 하는 등 우리에게 유리하게 쓰면 좋습니다. 인수인계나 검수기간 같은 게 포함되면 그 기간 산정도 명확히 하세요.
• 대금 지급 조건: 언제 얼마를 지급받는지가 핵심입니다. 선금/중도금/잔금 비율, **지급시점(검수 후 30일 이내 등)**을 확인하세요. 소규모 사업이면 검수 완료 후 일괄 지급이 많고, 큰 계약이면 보통 30:40:30 같은 분할이 가능합니다. **계약금(선금)**을 가능한 확보하도록 협상해보세요. 또 부가세 포함여부도 계약서에 정확히 해야 나중에 분쟁 없습니다.
• 비밀유지 조항: 고객이 주는 자료나 우리가 만든 결과물에 대한 비밀 유지(NDA) 조항이 들어가는데, 통상적인 범위인지 봅니다. 만약 “향후 5년간, 위반 시 손해배상 무한책임” 이런 과도한 게 있으면 완화 요청하세요. 그리고 우리 측도 레퍼런스 공개 여부를 물어볼 필요 있습니다. 종종 계약서에 *“성과물은 발주처 소유이며, 사전 승인 없이 외부 공개 불가”*라 적히는데, 우리는 나중에 이 프로젝트 했다고 포트폴리오 소개하고 싶잖아요. 그래서 “외부 공개는 협의 하에 가능” 정도로 해두면 좋습니다.
• 지식재산권(IP) 귀속: 작성한 문서나 자료의 저작권 귀속을 정합니다. 일반적으로 발주처에 귀속하는 경우가 많지만, 우리가 만든 표준 가이드나 툴이 있다면 그건 우리 지식재산으로 남겨야 합니다. 계약서에 “납품물에 포함된 컨설팅사의 기존 축적 산출물에 대한 권리는 컨설팅사에 유보된다” 같은 문구를 넣어두면 안전합니다.
• 보증 및 책임한계: “본 용역 결과의 정확성에 대해 컨설팅사는 객관적 기준으로 성실히 노력하나, 향후 발생하는 모든 문제를 완전히 배제하는 것을 보증하지 않는다” 등 책임 제한을 달아두는 게 좋습니다. 만약 이 계약으로 개선했는데 이후에 장애인단체가 문제제기하면 다 우리 책임인가? 그건 아니거든요. 그래서 *“컨설팅 결과 이행 여부는 고객의 책임”*이라는 식으로 명시하는 게 우리를 보호합니다. 또한 손해배상 책임 한도도 보통 계약금액 한도로 넣습니다.
• 분쟁 해결: 혹시 분쟁시 관할 법원을 어디로 할지 쓰는데, 통상 발주처 소재지로 적힙니다. 큰 신경 쓸 부분은 아니지만 알아두고, 분쟁 발생 시 상호 원만히 협의 노력 조항 정도 확인하면 됩니다.
• 계약서 첨부물: 제안서, 과업지시서, 과금 산출내역서 등이 첨부 문서로 언급되는데, 우리가 제출한 최종 제안서가 첨부되는지 확인하세요. 그리고 그 우선 순위도 명확히 해야 합니다(계약 본문과 상충 시 어떻게 되는지). 보통 계약서 본문>제안서 순으로 효력을 두는데, 가끔 헷갈릴 땐 “상충 시 협의한다”로 씁니다.
• 기타 요구 서류: 계약 체결 시 필요 서류 리스트도 챙겨야 합니다. 예를 들면 사업자등록증 사본, 통장사본, 인감증명, 사용인감계, 보험증권(책임보험) 등이 필요할 수 있어요. 공공기관일수록 서류가 많습니다. 미리미리 준비해서 계약 지연 안 되게 합시다.

항목이 많아 보이지만, 결국 계약서는 우리의 권리와 의무를 결정짓는 문서이니 꼼꼼히 읽어보고 필요한 건 넣고 과한 건 빼도록 협상해야 합니다. 가능하면 법률 자문도 받을 수 있으면 좋고요. 처음엔 어려워도 하나하나 체크리스트로 챙기다 보면 나중엔 익숙해질 거예요.

10. 계약 단계 주요 담당자와 R&R 🤝

계약하고 나면, 또는 그 전후로 프로젝트 주요 담당자들 간에 **Roles & Responsibilities(R&R)**를 확실히 하는 게 중요합니다. 누가 무엇을 책임지는지 정해야 나중에 혼선이 없거든요. 몇 가지 직무별 R&R 사례를 들어볼게요:

• 프로젝트 매니저 (PM): 우리 쪽 PM과 고객 측 PM이 있을 텐데, 일정 관리, 커뮤니케이션 채널을 주로 담당합니다. 우리 PM은 내부 팀 조율, 산출물 퀄리티 검수, 진행 상황 보고를 책임지고, 고객 PM은 자료 제공, 내부 조율, 피드백 취합을 책임지는 식으로 역할을 나눌 수 있죠. 계약 시 “연락 창구는 ○○부 △△과 ○○○대리로 한다” 이런 식으로 명시해두면 서로 공식 라인이 정해집니다.
• 접근성 컨설턴트/분석가: 실무 작업 담당자로, 사이트 진단과 보고서 작성이 주역할입니다. 우리 컨설턴트가 수행하지만, 고객 측에서도 협업 담당자(예: 웹마스터나 개발자 한 명)를 붙여주면 커뮤니케이션에 좋아요. 계약 Kick-off 미팅 때 서로 소개하고, “기술 문의는 누가 답해주나요? 콘텐츠 관련 문의는?” 정해두면 효율적입니다.
• 개발팀/디자인팀: 개선 실행은 보통 고객사 개발팀이 하지만, 컨설팅 범위에 코드 수정 지원이 포함되기도 하죠. 만약 우리가 개발 리소스를 일부 제공한다면 누가 어느 부분까지 수정 권한 갖는지 분명히 해야 합니다. 보안 이유로 우리에겐 read-only 접근만 준다든지, 아니면 개발사 직원이 붙어서 우리 가이드대로 코딩한다든지 모델을 정해요. 그리고 디자인 시안 검토도 이슈입니다. 개선하려면 디자이너가 새로 화면을 그려야 할 수도 있는데, 그건 고객 디자이너 몫인지 우리의 서비스인지 구분해둬야 합니다.
• 품질보증 담당(QA): 큰 프로젝트면 QA 인원이 별도로 있기도 합니다. 접근성 개선 후 실제 사용자 테스트나 재검증을 책임지죠. 우리 팀 내에서 한다면 역할 분담 필요하고, 고객 측 품질부서가 있다면 협업합니다. *“1차 점검은 컨설팅사, 최종 검수는 발주처”*처럼 책임분담을 문서에 써놓으면 나중에 합격/불합격 판정에 이견 없겠죠.
• 임원/의사결정자: CEO나 임원은 직접 일하지는 않지만 승인 단계에서 중요합니다. 예산 승인, 결과 최종 승인 등에 관여하니, 그 분들이 원하는 보고 포맷이나 지표가 있다면 미리 파악해두세요. 예를 들어 “CEO께는 요약보고서 1페이지짜리도 드리면 좋겠다” 이런 요구가 있으면 계약 시점에 확약하는 게 아니라 나중에 좋은 관계 위해 서비스로 하기도 합니다.

R&R은 문서화해서 프로젝트 킥오프 때 서로 공유하는 게 좋습니다. 계약서에까지 상세 쓰진 않더라도, 내부적으로는 RACI 차트(Responsible, Accountable, Consulted, Informed) 같은 것으로 정리해보세요.

중요한 건 누락된 역할 없이 모두 assign되어야 하고, 중복된 책임으로 인한 충돌이 없게 하는 겁니다. 예컨대 “최종 품질 승인: 발주처 ○○팀장” 한 명으로 못박으면, 나중에 실무 담당자가 OK해도 그 윗분이 퇴짜놓는 사태를 줄일 수 있죠.

11. 견적서 내부 승인 포인트 및 리뷰 🌐

우리 내부에서도, 현업 담당자가 작성한 견적서를 윗선에서 검토하고 승인하는 단계가 있을 겁니다. 이때 컨펌/반려의 주요 포인트는 무엇일까요?

• 마진 확보 여부: 가장 먼저 경영진은 이 프로젝트가 돈이 남는 장사인지 봅니다. 앞서 말한 재경비/이윤 등 고려해 수익률이 너무 낮으면 반려될 수 있어요. “고생해서 하려는데 이익이 5%밖에 안 남아? 어렵다” 이런 판단이죠. 따라서 견적 올릴 때 목표 마진을 명시하고, 그게 확보됐는지 보여줘야 합니다.
• 리스크 커버 여부: 윗분들은 경험상 어떤 리스크가 있을지 알고 있으니, 견적/계획에 그 대비가 담겼나 살핍니다. “이 기간에 인력 빠지면 어쩌지? 백업 계획 있나”, “고객이 요구 추가하면 어쩌지? 버퍼 넣었나” 같은 거죠. 그래서 버퍼 포함 근거나 가정 조건을 내부 설명 메모에 적어 제출하면, 승인자들이 안심합니다.
• 시장가격 벤치마크: 내 견적이 시장 시세에 맞는지도 검토합니다. 너무 높으면 수주 실패 위험, 너무 낮으면 덤핑 우려니까요. 그래서 경쟁사 동향이나 유사 사업 사례금액을 비교해볼 필요가 있습니다. 내부 보고 때 “유사 규모 최근 수주 사례는 5천만원” 이런 참고를 달아두면 승인자가 판단하기 수월해요.
• 내용의 정확성과 빠진 부분 확인: 견적서에 수치나 항목 오류가 없는지, 혹시 누락된 비용(예: 출장비, 툴 구매비 등)이 없는지도 체크합니다. 현업 담당자도 놓칠 수 있으니, 내부 리뷰어가 이 관점에서 봐줘야 해요. “우리가 사용자 테스트 한다 했는데 테스터 비용이 안 들어갔네?” 이런 걸 잡아내는 거죠.
• 계약 조건 검토: 금액 외에도 **계약조건(페널티나 지불조건)**이 타당한지 살핍니다. 혹여 무리한 조건을 우리가 받아들이는 건 아닌지, 필요시 계약 협상 때 수정 권한을 챙겨둬야 합니다. 예컨대 “지체상금 0.5%/일 조항은 수용 불가, 0.1%로 협상 필요” 이런 코멘트를 달 수도 있죠.

현업 견적 담당자에게 피드백할 때 이런 점들을 주로 이야기하게 됩니다. 특히 신입이나 견적 경험 적은 직원이 만든 견적서는 과소산정되기 쉽습니다. 빠뜨린 일, 너무 긍정적 일정 가정 등이 문제죠. 그래서 피드백으로 “여기 테스트 서버 구축기간 빼먹었네, 1주 추가”, “인건비 너무 낮게 잡았어, 최근 우리 평균단가 적용하자” 등을 줍니다.

내부 승인 프로세스는 회사마다 다르겠지만, 작을 땐 대표가 직접 검토하고 클수록 영업/견적위원회 같은 게 있을 수도 있어요. 중요한 건 근거와 투명성입니다. 산정 근거를 명확히 해두면 승인도 술술 됩니다.

12. 외주(하도급) 활용 시 비용 설계 🏗️

프로젝트 일부를 외부 프리랜서나 전문 업체에 외주 줄 때도 있겠죠. 이때는 외주비용 책정과 관리 포인트가 따로 있습니다:

• 외주 필요 판단: 먼저, 언제 외주를 쓸지 결정해야 합니다. 우리 인력이 부족하거나, 특정 전문 영역(예: 청각장애인 사용자 테스트)에서 외부 도움이 필요한 경우, 혹은 일시적으로 작업량이 폭증할 때 고려합니다. 외주를 쓰면 비용은 늘지만 유연성을 얻습니다. 단, 퀄리티 통제가 관건이라 꼭 필요한 부분에만 써야 합니다.
• 외주 단가 산정: 프리랜서나 다른 업체의 제안 단가가 올 때, 그것이 우리 목표 마진을 초과하면 곤란합니다. 예를 들어, 고객에게 100만원 받고자 하는 작업을 외주가 90만원 불러버리면 남는 게 없죠. 그래서 협상이 필요합니다. 우선 시장 시세를 알고 있어야 해요. 접근성 진단 프리랜서 보통 일당 얼마, 사용자 테스트 1인당 수당 얼마나 등 표준 단가를 조사해 두세요. 그 지식을 바탕으로 외주사와 네고합니다.
• 범위 축소 고려: 만약 외주 견적이 너무 높아 우리의 마진을 잠식하면, 작업 범위를 조정하는 방법이 있습니다. 예를 들어 “그럼 외주사 당신들은 이 부분까지만 하고, 나머지는 우리가 할테니 비용을 낮추자” 하는 겁니다. 또는 “사용자테스트 10명 말고 5명만 진행해주세요” 등 스콥을 줄여 단가를 맞추는 거죠.
• 품질과 비용의 균형: 가장 저렴한 외주를 찾는 게 답은 아닙니다. 품질도 담보해야 해요. 그래서 우선 신뢰할 만한 외주사 풀을 만들어 놓는 게 좋아요. 과거 협업해보니 잘하더라 하는 분들, 혹은 업계 평판 좋은 업체들 리스트를 갖고, 우선 그들과 견적 논의하세요. 약간 비싸도 품질 좋은 외주가 결과적으로 우리 손이 덜 가고, 고객 만족도도 높여줍니다.
• 계약 구조: 외주와의 계약은 가급적 우리 수주 계약 이후 체결하도록 일정 조율합니다. 괜히 우리가 계약 못 따면 외주 계약도 취소되는 상황을 미리 대비해야죠. 또 지불 조건도 우리 쪽 수금 일정에 맞춰주는 게 중요합니다. 우리가 돈 못 받았는데 외주비 먼저 나가면 현금흐름에 문제 생기니까요.
• 커뮤니케이션: 외주 인력을 쓸 경우 고객에게 어느 선까지 공개할지도 고민입니다. 우리 직원처럼 일하게 할지, 아니면 외주 참여 사실을 알릴지. 상황에 따라 다르지만, 투명하게 말해도 무방한 경우 그냥 소개하고 같이 회의하는 게 효율적입니다. 대신 최종 산출물 및 대외 커뮤니케이션 창구는 항상 우리가 컨트롤해야 합니다. 외주가 고객과 직접 소통하며 범위 밖 요구를 받으면 곤란하거든요.
• 검수와 책임: 외주 작업 산출물은 우리가 다 재검수해야 합니다. 책임은 최종 우리가 지니까요. 따라서 외주 관리 비용(관리자의 시간)도 고려해야 하고, 퀄리티 문제가 생기면 어떻게 할지 계약에 명시하세요. “재작업 요구 시 응한다” 정도는 받아두어야 합니다.

핵심은, 외주를 쓰더라도 우리의 목표 이익과 품질 기준을 지키는 선에서 활용해야 한다는 것입니다. 잘만 활용하면 사업 레버리지가 생기지만, 통제 실패하면 수익도 떨어지고 신뢰도 위험해집니다.

13. MM(Man-Month) 대안 모델 사례 ⚖️

전통적으로 인월(MM) 기준 견적을 많이 쓰지만, 혹시 다른 방식은 없을까 궁금할 수 있어요. 업계에서 시도된 대안 모델 몇 가지와 그 장단점을 소개하며 마무리하겠습니다:

• 시간 기반(Time-based) 과금: 시간당/일당 요금으로 청구하는 모델입니다. 예를 들어 “컨설턴트 1시간당 10만원, 총 100시간” 이런 식이죠. 장점은 투명하고 유연하다는 겁니다. 일 한 만큼만 받으니 고객도 수긍하기 쉽고, 범위 변경 시 시간 추가로 대응하면 됩니다. 하지만 단점으로 고정된 산출물 보장이 어렵고, 효율이 떨어질 수 있습니다. 고객이 “좀 더 해달라” 하며 시간을 계속 쓰게 할 우려도 있고, 우리로서도 생산성 향상을 해도 남는 게 없는 구조일 수 있어요. 국내에선 주로 **컨설팅 회사(맥킨지 같은)**가 이런 T&M 방식을 쓰는데, 웹 접근성 분야에선 많이 정착되진 않았습니다.
• 고정 가격(Fixed-Fee) 모델: 범위를 정해서 정액으로 계약하는 것입니다. “이 사이트 컨설팅 1,000만원에 해드립니다.” 이렇게요. 고객 입장엔 예산을 명확히 할 수 있어 좋고, 우리 입장엔 효율적으로 하면 남기는 구조라 동기부여가 됩니다. 단, 범위 초과 리스크는 모두 우리 부담이라는 단점이 있습니다. 그래서 스코프 정의가 완벽해야 하고, 중간에 늘어나는 요구를 잘 통제해야 하죠. 대부분의 턴키 계약이 이 형태인데, 사실 MM 기반 견적도 결과적으로는 Fixed-Fee 계약으로 귀결되는 게 많습니다.
• 성과 연동(Payment by Results): 결과에 따라 대금을 조정하는 모델입니다. 예를 들어 “접근성 인증 실패 시 20% 페널티”, “사용자 만족도 X점 이상이면 보너스 지급” 등 성공 여부에 따라 인센티브/페널티를 거는 것이죠. 장점은 고객에게 성과 보장 느낌을 주어 계약 승낙을 이끌기 쉽다는 점이에요. 우리도 성공하면 보너스를 받으니 동기부여가 되고요. 하지만 접근성은 수치화가 애매한 부분이 있어 객관적 기준 잡기가 어렵습니다. 또 혹여 우리 잘못 아닌 이유로 성과 미달되면 억울하겠죠. 현실적으로는 “인증 취득 실패 시 일부 환불” 정도 조건 거는 사례가 가끔 있습니다. 우리 서비스에 자신 있고 성공률이 높다면 고려해볼 만하지만, 위험 부담은 있다는 걸 기억해야 합니다.
• 구독형(Subscription) 모델: 앞서 살짝 언급했지만, 아예 월 정기료로 컨설팅 서비스를 제공하는 방식입니다. “월 100만원에 계속 모니터링 및 컨설팅 해드립니다” 같은 거죠. 장점은 지속적 수익이 생기고 고객 입장엔 비용을 분산할 수 있다는 것. 단점은 초기 투입 리소스 대비 수익이 적게 들어올 수 있다는 겁니다. 첫 1~2달은 집중 진단해야 하는데 정액으로 받으면 손해일 수 있거든요. 그래서 기간과 서비스를 잘 설계해야 합니다. 예컨대 1년 약정으로 하되 처음 2달은 집중 컨설팅, 이후 10달은 라이트한 모니터링으로 부담 균형을 맞추는 식입니다. 이 모델은 관계가 길어져 락인 효과도 있지만, 고객이 단기 성과를 체감하기 어려우면 중간에 해지할 위험도 있어요.

각 모델의 장단점을 표로 비교해보면 아래와 같습니다 (요약):

• MM기준: +익숙함/명확한 인력기준, -범위관리 어려움/비용 예측 어려움 (고객입장)
• 시간과금: +유연성, -성과물 불명확
• 고정가: +예측가능, -리스크는 업체 부담
• 성과연동: +고객신뢰↑, -측정 및 공정성 어려움
• 구독형: +지속수익, -초기투입 대비 수익안맞을 수

실제로 국내에서 가장 많이 쓰는 건 여전히 MM 기반 산정 후 Fixed Fee 계약입니다. 보수적인 발주문화 때문이죠. 하지만 우리 서비스에 혁신을 주고 싶다면 일부 고객에 한해 구독형이나 성과보증제를 도입해볼 수도 있습니다. 예를 들어 처음 거래인 고객에 “첫 프로젝트 결과 만족 못하면 일부 환불 보장” 같은 파격을 내세워 신뢰를 얻는 전략도 생각해볼 만해요.

이글은 ChatGPT가 작성하고 deute 가 검토했습니다.

난 목요일까지 판교에서 근무를 하다가, 제주로 복귀하여 금요일은 제주 사옥에서 근무를 한다. 항상 약간 들뜬 마음이 드는 금요일이지만, 마음을 다잡고 업무에 집중하려 한다. 이곳에서는 날 찾는 사람이 많지는 않아서, 밀린 업무들을 처리하기 좋기 때문이다.

이곳에는 수십 명의 개발자들이 한 공간에서 근무를 하고 있다. 의논하는 소리도 가끔 들리긴 하나, 보통은 키보드 소리와 마우스 소리가 많이 나곤 한다.

갑자기 11시가 되자 적막이 흘렀다. 키보드 치는 소리조차 나지 않더라. 22분이 넘어서야 갑자기 웅성웅성하고, 키보드 치는 소리가 들렸고, 사람들이 삼삼오오 식사를 하러 가는 것 같았다. 아내에게 결과를 카톡으로 보냈지만 가지 않았다. 나 같은 사람이 한둘이었겠는가?

2016년 12월에 경험하면서 이런 일이 또 있을까? 그럴 리 없겠지 싶었다. 그런데 또 일어났다. 이쯤 되면 세 번째도 가능할 것 같았다. 세 번째는 없길 바란다.

오늘 난 아들에게 아침에는 오일러를 이야기 했지만, 저녁에는 탄핵을 설명해야 할 것 같다. 어떤 식으로 설명해야 할지 난감하지만, 하긴 해야 할 것 같다

회사에서 좋은 기회를 주어서 짧은 학창시절을 경험하게 되었고, 그 과정에서 해외 연수를 다녀오게 되었다.

참고로 아래의 회고는 동기들의 코멘트와 사진을 인용한 것이 매우 많음을 미리 밝혀둔다. 인용은 해도 생각의 부분은 내 생각을 담으려 애썼다.

연수 개요

• 연수 기간 : 2023년 11월 18일 ~ 24일 
• 연수 지역 : Manhattan, New York, Unite State of America
• 연수 참여인원 : KAIST AIM 58기 14명, 책임교수 3명, 담당자 1명
• 방문 기업 : Lippincott, Bloomberg, Howard Hughes Corp. FiscalNote, New York University

방문기업 회고

Lippincott

– https://lippincott.com/

1943년 설립된 세계적인 브랜드 메이킹회사이며, 특히 Corporate Identity라는 표현을 처음 사용한 회사이다.

세계의 수많은 회사의 기업 브랜딩 아이덴티티를 만들어낸 회사이며, 특히 한국에서는 삼성 및 SK의 CI 변경을 주도했다고 하여 눈길이 갔다.

회사의 브랜드가 구성원 및 고객들에게 설득력 있게 다가갈 수 있도록 클라이언트와 심층 인터뷰를 진행하고 데이터 기반의 의사결정을 통하여 CI를 개발하는 모습이 상당히 흥미로웠다.

또한 CI만 만들어내는 것이 아닌 통합 디자인 가이드 및 회사의 모든 디자인 전략을 세우는 리포트를 만들어 내는 것이 인상적이었다.

1. 리핀컷의 시니어 디자이너 마이클 게린의 회사소개 2. 방문기념 사진

Bloomberg

– https://www.bloomberg.com/

1981년 창업한 경제 전문 미디어 그룹으로 98개국 4만 명을 고용하고 있는 세계의 경제정보를 제공하는 기업이다.

“블룸버그 단말기 없이는 세계에서 트레이드를 할 수 없다”라고 평가받고 있으며, 블룸버그의 단말기 사용금액은 1인당 연간 약 3,000만 원으로 고가라고 한다.

동기분들의 회사에서도 다량 사용하고 있고, 각 부서에서 라이센스 하나라도 더 따내는 것이 이슈라고 할정도(특히 금융권, 투자 쪽)

블룸버그에서만 근무경력 30년인 이한창 분석가의 소개로 회사투어와 “Bloomberg Introduction” , “Al/ML in Bloomberg” , “New Energy Finance” 등 3가지 주제에 대한 강의가 이루어졌다.

예를 들면 운항 중인 선박의 화물 운송 정보를 실시간으로 알 수 있고, 그 물자의 흐름을 통해 투자의 방향을 설립하는데 도움을 줄 수 있다.

즉 돈이 되는 정보라면 무엇이든 가리지 않고 고객에 제공한다. 방대하고 정밀한 정보에 매우 놀랐다.

다만 시스템이 커맨드 기반으로 되어있었고(GUI도 제공한다), 이쁨을 추구하지는 않아서 도전 점이 생길지도 모르겠다는 생각도 했다.

1. 선박 운용 정보(저 선박들에 담긴게 무엇인지 알 수 있다면 투자에 활용할 수 있겠지..) 2.전 세계 발전 시설 정보(원료의 흐름 산업의 흐름을 볼수 있을 듯) 3.기업인 정보(사찰수준이었다)

4. 방문기념사진

Howard Hughes Corp.

https://www.howardhughes.com/

미국의 전설적인 비행사이자 억만장자인 하워드 휴즈(아이언맨의 모델이라고…)의 정신을 잇는 회사로, 단순히 건물만 짓는 것이 아닌 우리가 어떤 공간에서 어떻게 살 것 인가를 고민하는 것에 중점을 두는 부동산 개발 회사이다. “Live, Work, Play, Learn, Worship, Grow”라는 가치 아래 텍사스, 하와이, 뉴욕등의 미국 여러 곳에서 부동산 개발을 진행 중에 있다. 특히 뉴욕의 수산시장과 항구를 재개발하여 전통을 해치지 않으면서, 이용자들이 그 안에서 다양한 커뮤니티를 이루며 즐길 수 있도록 여러 요소들을 고민한 흔적들을 실제의 공간을 방문하면서 느낄 수 있었다.

최근 개인적으로 공간을 어떻게 구성하면 가치 있게 만들 수 있을까라는 질문을 자주 하게 되었는데… 많은 도움이 되었다고 생각한다.

도중 준비 중인 Playground (작은 놀이터 + pub)를 둘러보게 되었는데, 아이디어가 막 샘솟기도 했다.

1. 뉴욕지사장 Andrew Schwartz의 the seaport 설명 2. Howard Hughes의 소개 발표 3. The Seaport 전경 

FiscalNote

https://fiscalnote.com/

피스컬노트는 글로벌 정책 및 시장 정보를 제공하는 선도적인 기술 제공업체이다. 피스컬노트는 AI 기술, 실행 가능한 데이터, 전문가 및 동료 인사이트를 고유하게 결합해 고객이 정책을 관리하고 규제 개발을 해결하며 글로벌 위험을 완화할 수 있게 지원한다. 최근 뉴욕 증권거래소에 상장되어 10억 달러 이상의 가치를 인정받았다. 한국계 미국인인 팀황 CEO가 직접 NYU에 방문하여 회사의 소개와 비전 그리고 특히 기업의 조직문화의 고민점과 사례들을 설명해 주었으며, 특히 조직의 가치를 운영하는 방법의 7가지는 매우 인상적이었다.

1. FiscalNote의 CEO의 팀황의 강의 2. FiscalNote의 현황 및 비전 3. FiscalNote에서 조직의 가치를 운영하는 방법 

New York University

뉴욕대 방문은 이틀에 걸쳐 진행되었으며, 하루는 간호대방문, 하루는 경영대학원 방문 그리고 양일간 모두 교수님들의 강의를 듣는 것으로 진행되었다.

첫날은 NYU의 이혜옥 교수님의 알츠하이머의 연구를 통한 어떻게 삶을 건강하게 영위할 것 인가의 주제로 강의를 들을 수 있었다. 알츠하이머의 위험요소에 음주, 비만, 흡연, 부정적인 사고가 있다고 말씀하셨는데… 일단 흡연을 멀리하고 긍정적인 사고를 항상 노력하기로 했다.

다른 날은 KAIST 경영대학 백용욱 교수님의 “불확실성의 세계에서의 혁신전략”이라는 주제로 강의를 들을 수 있었다. 기업의 혁신의 방법 중 사내 기업 설립(CIC)과, CVC(기업주도형 벤처캐피털)의 방법과 장단점, 그리고 진행 시 고려해야 할 점의 주제로 강의를 들었다. 단순히 방법론보다는 기업이 어떻게 미래에 투자하는가의 관점에서 해석이 되었던 것 같았고, 특히 지금 내가 다니고 있는 기업에서 투자를 가치 있게 하는 방법에 대한 많은 고민을 할 수 있게 해 주었다.

일행 중 누군가가 뉴욕에서 이 정도 시설의 건물에 탁 트인 전망을 볼 수 있는 NYU 건물을 찾기 힘들 것 같다고 할 정도로 멋진 뷰를 자랑하는 회의실에서 강의가 진행되었다.(돈을 버는 학과라 그렇다고들…), 추수감사절 직전이라 들어가 보지는 못했고 겉에서 바라보는 경영대학(NYU Stern)도 일단 멋졌다.

1. NYU 이혜옥 교수님 2. KAIST 경영대학 백용욱 교수님

Tour and Social Networking

우선 TV나 영화에서만 보던 여러 곳을 방문 그리고 감상할 수 있었다. 배를 타고 자유의 여신상을 볼 수 있었고, 허드슨 야드의 엣지 전망대에서 뉴욕의 전경을 위에서 즐길 수 있었다. 아침에는 센트럴 파크에서 산책을 하는 호사를 누리기도 했으며, 생각보다 아담한 타임스퀘어는 그냥 매일 돌아다녔던 것 같다. 아내가 열광할 MoMA 미술관에서 피카소와 모네 등의 작품을 감상했으며, 삼성페이와 빅스비를 개발 총괄하신 이인종 전 삼성전자 부사장이 우리의 일정 중 잠시 가볍게 참석하여 여러 이야기를 들을 수 있는 기회도 주어졌다.

밤마다 동기 형님들과 시차가 적응이 안 된다는 핑계로 3교시(AIM과정에서 술자리를 이렇게 부른다.)를 개최하여 다양한 주제로 많은 이야기를 나눌 수 있었다. 모두들 각 회사의 핵심 임원답게 여러 회사의 좋은 점들을 배울 수 있었다.

1. 타임스퀘어 2.자유의 여신상 3. 이인종 전 삼성전자 부사장과의 기념사진

회고

• 회사방문에서 느껴진 게 공통적으로 사람의 장점을 잘 끌어낸다는 느낌이었다. 환경적으로 또 업무 부여할 때 각각의 개성을 많이 고려하는 것이 느껴졌다.
• 동기분들의 역량이 사뭇 대단하게 느껴졌다. 특이 이번 기수는 경영 관리 분야의 전문가가 많아서 해당분야에 많은 것을 배울 수 있었다.
• 빅 테크 기업 방문이 없어서 아쉬웠으나… 오히려 더 좋기도 했다. 새로운 관점을 많이 볼 수 있었다.
• 영어 강의가 생각보다 많았고 알아듣느라 고생했다. 영어 + 시차적응은 거의 고문 수준이었다.
• 왜 미국이 트렌드를 선도하는지 아주 조금이나마 알게 된 것 같다. 일단 생각이 규모가 다르다.
• 미국은 크다. 먹을 것도 크다. 1인분 다 못 먹어서 자존심 상한다.
• 마리화나 냄새는 별로다.
• 16시간 비행은 많이 힘들다. 제공하는 영화는 모두 본듯하다.

2022년의 성과를 정리하고 새로운 계획을 수립하는 정신없어 하는 순간에 내 눈에 들어온 카트라이더 서비스의 종료로 인해 난 아무 일도 할 수 없었다. 잠시 환기가 필요했을지도 모른다.

카트라이더 베타테스트를 한참 즐기던 중 넥슨에 입사하게 되었고 난 카트 웹 홈페이지의 프론트 담당자가 되었다. 카트라이더는 폭발적인 인기를 받으며 트래픽이 급증하고 있었다.

마침 카트라이더 버전2의 소식이 들려왔고, 높아지는 트래픽을 감당할 수 있게 난 공부하던 CSS로 레이아웃을 구성하는 시멘틱 웹페이지를 구성하여 적용했다. 그때 팀장님이 새로운 시도를 응원한것도 한 몫 했다. 그 결과 아마도 대한민국 게임 웹사이트 중 최초의 웹 표준과 시멘틱 HTML을 구현한 사례일 것이라고 확신한다. 페이지의 용량의 효율을 증명하기 위해 두 개의 버전으로 만들기도 했다(아마도 1/10이었던가…)

시류에 편승해서 많은 성장과 좋은 기회들이 이루어졌다고 생각하는 부분이 이 부분이었다. 난 좋은 시절을 만나고, 좋은 게임을 만나 그리고 좋은 동료들을 만나 지금의 나로 되었다고 생각한다.

그 시절 즐겁게 점심시간마다 카트를 실행해서 달리던 웹 개발팀이 생각난다. 그때는 일도 노는 것 처럼 했고, 정말 즐거웠다.

넥슨도 새로운 카트라이더도 모두 잘되면 좋겠다. 물론 그때의 형들 누나들 동생들도 모두말이다.

다시 일하러 가자.