웹표준

2007.02.22 글쓴이 youknowit

[관련 글]

모델 RFP

RFP가 뭔가요?여기 클릭.

웹사이트 발주를 담당하시는 분들은, 이것 저것 고민하실 필요 없이, 다음 사항을 필수 요구 조건으로 제시하시면 좋겠습니다.

  • 한글 엔코딩은 utf-8 을 사용할 것
  • 시작페이지, 1차(first depth) 메뉴의 각 처음 페이지들은 모두 웹표준 준수 여부를 확인할 수 있는 웹표준 검사 링크 XHTML표준 준수 를 페이지 하단 등에 반드시 제시할 것. 물론 검사를 오류 없이 “통과”도 해야겠지요 :)
  • 시각 장애인 용 “별도 페이지”를 만들지 말 것. “텍스트 전용” 페이지도 만들지 말 것. 음성안내 파일을 틀어대지 말 것.
  • 웹사이트 자체를 텍스트 웹브라우저(lynx, w3m 등)로 접속하였을 때 사용에 불편이 없도록 할 것. 텍스트 웹브라우저에서 정상 작동하는지 여부는 이 사이트에서도 확인 가능 함.
  • 단축키 사용 안내 등 “접근성 안내” 페이지 링크를 첫페이지에 반드시 제시할 것. 예시
  • 사이트 로고(logo)를 제외하고는, 글자(text)로 된 내용은 반드시 글자(text)로 제시할 것(글자를 그림 image 로 바꾸어 메뉴를 표시하는 짓을 하지 말 것) — 이 요건을 제시해야 CSS기술을 모르는 “복고풍” 업자를 손쉽게 추려낼 수 있습니다.
  • 페이지 레이아웃은 CSS로 구현할 것(table 태그가 아니라). 그리고, CSS 유효성 검사를 통과할 것. http://css-validator.kldp.org/ 참조.
  • 적어도 세개 이상의 웹브라우저(IE, 파이어폭스 포함), 두개 이상의 운영체제에서 정상 작동 여부를 테스트 할 것
  • 이용자에게 제시하는 문서는 공개된 파일 규격을 사용할 것. 열람이나 편집을 위하여 이용자가 특정 프로그램이나 서비스에만 의존해야 하도록 강제당하지 않아야 함.

자세한 내용은 아래 설명을 참조하시기 바랍니다.

이미 여러분들께서 수정안을 제안해 오셨습니다. 이를 조만간 정리하여 반영하겠습니다. 추가 수정안도 답급의 형태로 남겨주시면 계속 반영해 나가겠습니다. Wiki 형태로 아예 여러분들께서 직접 수정, 편집하는 방식이 궁극적으로는 바람직하다고 생각하는데, 그것은 후니님과 상의해 보겠습니다.

우선, 전체 문서가 간략, 명료하였으면 합니다. 복잡하고 난삽한 RFP가 제시되는 경우, 결국 얼마 안가서 아무도 꼼꼼히 검토하지도, 점검하지도 못하는 채, 여기 저기서 “긁어 붙여” 항목을 채운 문서들이 난무하는 상황이 올까 우려됩니다. 이상적으로는, 이른바 “결제권자”까지도 문서의 대강은 살펴볼 수 있을 정도의 분량과 체제가 유지되었으면 합니다. 다음과 같은 대 주제별로 항목을 나누어 중복, 반복이 없도록 요건을 제시하였으면 좋겠습니다.

  1. 다양한 이용환경 보장
  2. 공정한 경쟁 보장
  3. 표준화 지향
  4. 개인 정보 보호 및 보안 요건
  5. 국어 환경에 관한 기술 요건
  6. 하도급 근절 장치
  7. 납품, 검수에 관한 사항
  8. 공급후 지원에 관한 사항
  9. 개별 발주 주체에 고유한 사항

항목별로 설명드리겠습니다.

1. 이용환경 다양성 보장(diversity of user environment)

장치 중립성(inter-operability)과 정보 접근성(accessibility)은 상당 부분 겹치기도 하지만, 서로 다른 개념입니다. 그 중 하나를 확보한다고 해서 다른 것도 확보되는 것이 아닙니다. 그리고 법적 개념으로서 “평등권”을 동원해도 해결되지 않는 부분이 있습니다. 무엇보다도, 공공 사이트는 정보화에 관한 여러 법규에 규정된 요구사항들을 정확, 충실하게 구현할 의무가 있습니다.

정보화촉진 기본법은 “경제적 차별이 없는 균등한 조건의 보편적 역무”가 제공되도록 할 의무를 정부에 부과하고 있고(제16조의2), 정보격차 해소에 관한 법률은 “장애인·노령자가 편리하게 정보통신서비스를 이용할 수 있도록” 해야함을 규정하고 있습니다.(제7조) 경제적 이유로 고사양 하드웨어, 고비용 소프트웨어를 마련하지 못하는 계층의 이용환경, 장애자의 이용환경, 모바일 이용환경, 통방융합에서 등장하는 다양한 장치를 이용하는 환경, 이 모두를 포섭하는 개념으로 “이용환경의 다양성”을 제안하고자 합니다. 그리고, “표준 준수”와는 달리, 이용환경 다양성 보장은 현행 법규들이 요구하는 내용입니다. (표준화는 법적의무는 아닙니다; “전자거래”의 경우는 표준제정 의무가 있고, 정부가 그것을 해태하고 있지만)

이용환경 다양성 보장은 다음과 같은 세부 항목으로 나누어 볼 수 있습니다.

  • 물리적 장애가 있는 이용자(시각, 기동 장애, 노령자)의 이용편의 보장
    • 시각장애인용 “별도 사이트” 폐쇄. 기본 웹사이트에 시작장애인 지원기능 확보: 기본 웹사이트 자체를 텍스트전용 브라우저(lynx, w3m)로 접속하더라도 대등한 수준의 정보접근, 서비스 이용이 가능하도록 확보
    • “한국형 웹콘텐츠 접근성 지침 1.0” 중 장애인의 접근성 보장에 관한 사항
    • 한국정보문화진흥원의 웹 접근성 평가 도구(KADO-WAH)에 의한 평가, validator 구비
  • 경제적 약자의 이용편의 보장
    • 사이트가 제공하는 모든 텍스트 콘텐츠는 텍스트브라우저로 접근, 이용 가능하게 할 것.
    • 저사양 HW, 무료SW, 저속 접속 환경에서 이용 불편이 없는 대안 제공할 것
  • 연소자(어린이)의 인터넷 이용에 대한 고려 사항들

2. 공정한 경쟁 보장

특정 OS, 특정 프로그램에 종속적인 콘텐츠 제시 방법은 원칙적으로 금지되어야 할 것입니다. 그리고 문서를 hwp로 제공하거나, 특정 상품의 다운로드 링크만을 마련해 두는 것은 공정거래 및 경쟁 촉진에 관한 법규에 위반될 소지가 있습니다. 공공 정보제공을 핑게로 국민으로 하여금 (무료 대안이 있음에도) 유료 소프트웨어 선택을 강제하는 일은 결코 용납될 수 없습니다.(아님, 돈을 주든가!)

한편, 공개SW 진흥 정책은 세계 각국이 추구하고 있습니다. 국가전산망의 안전(국가안보)을 고려하여 공개SW의 확산을 추진하는 것은 정당한 정책목표입니다. 공정경쟁에 관한 국내, 국제법은 모두 국가의 정당한 정책목표 실현을 위한 특별한 조치를 허용하고 있습니다. “리눅스, 말은 들어봤는데, 그거 어디서 구할 수 있지?” 라고 궁금해 하는 이용자가 무수히 많은 현 상황은 정부 정책의 완벽한 실패를 보여 주는 것입니다. 주요 리눅스 배포판들을 요약 설명하고, OpenOffice의 기능을 상용 프로그램과 비교 설명하고, 내려받기 링크들을 일목요연하게 안내하는 종합적인 안내 사이트(공개소스 SW 내려받기 통합안내)를 마련하는 일은 KIPA가 벌써 했어야 하는 일입니다.

  • 웹사이트에 제시되는 문서는 범용성이 있거나, 무료 이용이 가능한 확장자를 사용할 것
  • 프로그램 내려받기 링크는 경쟁법에 저촉되지 않도록 할 것
  • 공개소스 SW 내려받기 통합안내 링크는 반드시 마련할 것
  • 웹 에디터(form filling 용 텍스트 편집기)에 대한 요건

3. 표준화 지향

  • “행정기관 홈페이지 구축 운영 표준지침” 준수
  • “W3C 웹 표준 기술 권고안”에 따른 기술 표준 준수: HTML 4.1 , XHTML1.0, CSS1/2, DOM, ECMA Script, IETF 표준 준수 및 확인(validator) 버튼 구비
  • “정보시스템 구축 운영 기술 가이드라인 2.0”에 따라 성숙성과 안전성이 보장된 기술 제시
  • Firefox 1.x, Safari, Opera 8.x, MS IE 6.0 이후 브라우저 환경에서 모든 기능 사용 가능을 확인

4. 개인정보 보호 및 보안 요건

  • 공인인증서를 사용하는 경우, 일체의 개인정보 요구 금지 (물품 배송 용도로 주소, 성명이 필요한 경우는 예외)
  • 실명확인 요구는 적법한 최소한으로 제한 / 실명확인이 반드시 필요한 경우에도 주민등록번호 외의 대안도 제공할 것
  • 개인정보 및 열쇠글이 네트웍 상에 clear text로 전송되지 않게 할 것.
  • 어떠한 이유로도 이용자가 관리자 권한으로 컴퓨터를 사용해야만 수행가능한 단계를 만들지 말 것

5. 국어환경 관련 기술요건

  • KSX-1005/ISO-10646/유니코드(웹 페이지에서는 UTF-8 추천)를 사용
  • 문서이름 문제(위 요건이 충족되면 이것도 다 해결되는지를 몰라서…)
  • 기타 localization과 관련된 요건들?
  • (euc-kr, uhc, utf-8, etc. 가 웹, 이메일 등에서 혼재 하는 상황은 빨리 정리되어야 할 것이고, 공공 웹사이트가 모범을 보여야 할 것입니다)

6. 하도급 근절 장치

도저히 몇십억을 들인 웹사이트라고는 믿을 수 없는, 천편일률적인 저질 사이트가 판을 치는 이유는 고질적인 하도급 구조에 있다고 생각합니다. 대기업이 수주를 독식하고, 실제로 작업은 거의 “노가다” 수준의 인력이 (반복) 해내고, 그 과정에서 세금은 줄줄 새고…

  • 입찰 참가 자격 완화 / 배상책임 보험제 도입
  • 하도급 내역 사전 공개(Artwork 등 하도급이 불가피 한 영역이 있을 것입니다)
  • 사전 승인된 하도급 이외의 하도급을 한 경우, 위약벌(penalty) 및 추후 응찰금지(blacklist) 제도 도입
  • 제안서 평가의 “계량화” 재검토: 우리 나라의 고질적 약점이 바로 “점수평가제”를 남용하는데 있습니다. 객관성과 공정성을 담보 한답시고, 모든 것을 “점수로 표현”하게 한 다음, 뒷구멍에서 점수를 조작해대는 고질적인 위선과 부조리가 있습니다. 점수화 한다고 해서 평가가 객관적으로 되는 것이 아닙니다. 자신을 속이고 남도 속이려는 시도에 불과할 수도 있습니다.
  • 정성적(qualitative) 평가를 대폭 도입하되, 사업자 선정이 결정되고 나면, 입찰 참가자 모두에게 수주자(successful bidder)가 제출한 제안서의 full details를 공개하도록 하는 것이 진정한 공평함을 확보할 수 있는 한 방법이 될 것입니다.(영업 비밀에 해당하는 부분은 제외해야 겠지만, 그런 부분이 어느정도일지?) 결과를 수치로만 표현하면, 몰상식한 평가를 공격할 꼬투리가 사라지는 폐해가 있습니다. (바로 그렇기 때문에 평가의 계량화에 집착해 왔다고 생각합니다)

하도급 구조를 근절하는데 성공한다면, 규모는 작아도 참신하고 탄탄한 기술력이 있는 업체들이 대형사업에 정당하게 경쟁할 수 있습니다. 그렇게 되어야 우리 나라의 웹사이트들이 다양하고, 창의성 넘치는 고급 사이트들로 바뀔 것입니다. 솔직히 지금은 정통부 사이트에 있는지, 산자부 사이트에 있는지 도무지 구별이 가지 않습니다. 전부 그나물에 그밥입니다. 실제로 일을 한 “인력풀”이 뻔하기 때문입니다. http://kldp.org/node/71081 참조.

7. 납품, 검수에 관한 사항

사업 제안서에는 구체적인 검수 절차, 검수 주체에 대한 제안이 있어야 하고, 그 내용은 실제 계약서에도 반드시 포함되어야 할 부분입니다. 이 점을 RFP에서도 언급할 필요가 있을 수도…

8. 공급후 지원에 관한 사항

위 제1, 3, 4 항목과 관계되는 이용자의 불평이나 bug report에 대한 대응 시한과 대응절차에 대한 상세한 규정이 추가되어야 할 듯합니다.


이상은 거의 대부분 공공 사이트에 공통적으로 적용 가능한 내용일 것입니다. 각 발주 주체에 고유한 요건은 그 다음에 모아서 제시하는 것이 적절할 것입니다.

별첨된 온갖 종류의 복잡한 서식, 반복된 내용 등을 모두 추려내시도록 부탁드리겠습니다. 형식보다는 실질을 추구해야 되지 않겠습니까?

One Pingback/Trackback

  • Yi Jong

    우선 생각나는 것 하나만 첨언합니다.

    페이지 내에 포함되는 오브젝트의 갯수나 한 페이지의 총용량(page weight)에 대한 제한이 있으면 좋겠습니다. 현재는 대부분의 중앙정부 홈페이지는 플래시로 떡칠해놓은 덕분에 사양이 낮은 win98 이용자 같은 경우는 시스템이 다운되어버리기 까지 하는 문제가 있습니다.

    이 문제는 텍스트 기반의 light한 홈페이지가 제공되더라도 기본적인 메인페이지로의 진입 자체가 어렵기 때문에 텍스트 버전 홈페이지의 url을 외우지 않는 한, 접근이 대단히 어렵다는 문제까지 포함됩니다.

    즉 적어도 공공 홈페이지의 대문페이지는 어떤 브라우저에서도 쉽게 접근할 수 있어야 하는데, 여기에는 각종 표준 규약을 준수하는 것 외에도 page weight까지 고려되어야 한다고 생각됩니다.

  • icksss

    개발 자로서 말씀 드리고 싶습니다.

    위에서 언급한 사항을 지키면서 개발 하는것이 분명 맞습니다.

    하지만 RFP를 발주 할때 충분한 비용과 시간을 고려해야 합니다. 전문성이 필요합니다.

    공정한 경쟁의 일환으로 무조건 가격을 다운시키는것이 올바른 방향이라고는 생각치 않습니다.

    비용이 적다면 업체는 보다 싼 인력을 투입할것이고,
    시간이 적다면 투입된 인력은 모든 표준을 외우고 다니지 않는 한 알고 있는 지식으로 개발을 할겁니다.

    제대로된 가격 의 공정한 경쟁이 되야 합니다.
    적절한 비용이 제시되고 있는지 판단 할 수 있는 기준이 필요하다고 생각됩니다.

    • snowall

      현재 상황에서 볼 때 이 의견이 맞다는 점에는 동의합니다.

      하지만, 이것은 문제를 두 부분으로 나눠야 한다고 생각합니다. 공정한 경쟁을 하는 한, 당연히 적은 비용으로 입찰한 업체가 선정되어야 합니다.

      그리고, “표준”을 지켜서 개발하라고 했는데 업체에서 납품한 물건이 표준이 아니라면 그건 당연히 계약 위반이므로 다시 만들도록 하거나, 돈을 지급하지 않아야 합니다.

      물론 여기에서 표준을 지켜서 계약조건대로 개발되었는지 제대로 검수하는 과정이 필요합니다.

      끝으로, 충분한 비용과 시간을 고려해서 발주해야 한다는 점에는 전적으로 동의합니다. 우리나라는 너무 후려치는 것 같아요 -_-;

  • http://www.imsoo.net misol

    ■이용자에게 제시하는 문서는 hwp를 사용하지 말 것(pdf, rtf, txt, html 등 파일 규격이 공개되어 있고, 누구나 열람 가능한 파일 양식을 사용할 것)

    이 부분은 “하지 말것”으로 정의하지 말고 “할 것”으로 정의하면 더 간단히 쓸 수 있지 않을까요?

    ■이용자에게 제시하는 문서는 pdf, rtf, txt, html 등 파일 규격이 공개되어 있고, 세가지 이상의 운영체제에서 추가 비용 없이 열람 가능한 파일 양식을 사용할 것.

    • http://www.imsoo.net misol

      써놓고 보니 더 복잡하네요.;

    • snowall

      “이용자에게 제시하는 문서는 파일 규격이 공개되어, 누구나 열람 가능한 파일 양식을 사용할 것” 정도로 정리하면 될 것 같습니다.
      운영체제의 종류를 제한으로 두는 건 조금 불합리할 수 있습니다. 가령, 윈도우즈XP, 윈도우즈 비스타, 윈도우즈7 등의 3가지 운영체제는 같은 계열이지만 다른 운영체제거든요. 리눅스도 마찬가지로 페도라, 데비안, 수세는 모두 같은 계열이지만 다른 운영체제입니다.

      • 김 현규

        유닉스

        리눅스
        ├────┐
        데비안     레드햇
        │             │
        우분투     페도라

  • http://twitter.com/dotnetpower Moonhyuk Choi

    링크에 녹색 자체가 가독성이 너무 떨어지는것 같은데요? 정상인 저도 눈이 아픈데.. 시각 장애인들이 보기에는 오픈웹 사이트가 피곤할듯 합니다.

  • Anonymous

    안녕하십니까
    상기 글과 관련하여 이후에 예시적으로 정리한
    오픈웹 프로젝트를 위한 모델RFP가 있는지요?

  • http://openweb.or.kr youknowit

    모델RFP를 만들어둔 것은 없고요(프로젝트 마다 커버되야할 내용이 워낙 다르기 때문), 위에 제시한 필수적 포인트들을 준비하시는 RFP에 “추가”하시는 방법으로 대처하시면 될 듯.

  • Pingback: HTML 코딩 이야기 – #1 개념 확인 | 반토막 저장소