공공 웹서비스 개편 회의에서는 대개 첫 화면, 메뉴, 디자인 시안부터 이야기합니다. 그러나 시민이 신청을 끝내지 못하거나, 담당자가 바뀐 뒤에도 이전 직원의 관리자 권한이 남는 문제는 화면을 예쁘게 만드는 과정에서 해결되지 않습니다. 공공 웹서비스 접근성과 보안 개발 요구사항은 시민과 운영자가 서비스를 끝까지 사용할 수 있도록 흐름을 정하는 일에서 시작해야 합니다.
핵심은 기준을 많이 나열하는 데 있지 않습니다. 시민이 어떤 정보로 판단하고, 어디에서 입력하며, 오류가 나면 어떻게 고치는지 정리해야 합니다. 동시에 운영자가 누가 올린 콘텐츠를 관리하고, 누가 개인정보를 열람하며, 문제가 발견됐을 때 누가 수정할지도 함께 정해야 합니다.
안내 사이트와 신청 서비스는 출발점이 다릅니다
기관 소개, 사업 안내, 공지 게시가 중심인 사이트라면 시민이 정보를 찾고 읽는 과정이 첫 기준입니다. 모바일 화면에서 메뉴를 찾을 수 있는지, 키보드만으로 이동할 수 있는지, 이미지와 영상에 담긴 핵심 내용도 전달되는지를 봐야 합니다. 특히 운영자가 올리는 공고문, 이미지, 첨부 문서가 이용을 막지 않도록 등록 화면과 작성 안내까지 개발 범위에 넣는 편이 좋습니다.
교육 신청, 시설 예약, 민원 접수처럼 개인정보와 처리 절차가 있는 서비스는 범위가 더 넓습니다. 로그인과 본인 확인, 신청서 입력, 오류 수정, 결과 조회가 시민의 이용 흐름입니다. 운영자에게는 강좌 등록, 정원 변경, 신청자 조회, 처리 상태 변경이 업무 흐름이 됩니다. 이 둘을 분리해 적어두면 “신청 기능을 만든다”는 모호한 요구가 실제 화면, 권한, 기록 관리 항목으로 바뀝니다.
예를 들어 주민 교육 신청 사이트라면 시민은 공고를 읽고 조건을 확인한 뒤 신청하고 결과를 봅니다. 한편 담당자는 강좌를 열고 정원을 조정하며 신청자를 확인합니다. 이때 접근성은 글자 크기나 색 대비만 뜻하지 않습니다. 보조기기나 키보드를 쓰는 사람도 검색, 신청, 입력 오류 수정, 결과 확인을 마칠 수 있어야 합니다. 보안도 별도 장비의 이름보다 신청자 정보를 누가 볼 수 있고 언제 권한을 잃는지가 더 가까운 문제입니다.
업체 상담에서는 선언보다 수정 과정을 확인합니다
“접근성을 준수한다”, “보안 개발이 가능하다”는 답만으로는 업체를 비교하기 어렵습니다. 좋은 답변은 어떤 이용 장면을 검토하는지, 발견한 문제를 어떤 결과물로 남기는지, 수정 뒤 누가 다시 확인하는지까지 연결합니다. 기관은 상담 전에 서비스 대상, 핵심 업무, 기존 시스템, 다루는 개인정보와 첨부파일 종류 정도를 한 장으로 정리해 두면 충분합니다.
그다음 업체에는 다음 네 가지를 물어보면 됩니다.
- 시민이 검색, 신청, 조회, 첨부파일 확인을 끝내기 어려운 화면을 어떻게 찾아내고 고치는가?
- 관리자별로 볼 수 있는 정보와 할 수 있는 일을 어떻게 나누며, 담당자 이동이나 퇴직 때 권한은 어떻게 정리하는가?
- 파일 업로드, 입력값, 외부 시스템 연결에서 오류나 비정상 요청이 생기면 어떻게 막고 기록하는가?
- 오픈 전과 운영 중 문제를 발견했을 때 점검 결과, 수정 범위, 재확인 일정은 누가 관리하는가?
답변에 화면 목록, 사용자 역할, 점검 방법, 수정 산출물이 함께 나오면 비교하기 쉽습니다. 반대로 모든 기관에 같은 인증, 솔루션, 점검 횟수만 제시하거나 콘텐츠 등록과 계정 관리의 주체를 비워 둔다면 요구사항을 더 구체화할 필요가 있습니다. 특정 점검을 한 번 받았다는 사실만으로 운영 품질까지 보장되지는 않습니다.
오픈 이후 바뀌는 콘텐츠와 권한까지 범위에 넣습니다
접근성은 개발 완료 화면만 검사해서 유지되지 않습니다. 운영자가 스캔한 공고문을 올리거나, 이미지 안에만 신청 조건을 적거나, 영상에 핵심 안내를 넣고 설명을 생략하면 시민의 이용은 다시 어려워질 수 있습니다. 따라서 관리자 화면에는 필요한 입력 안내를 넣고, 운영 매뉴얼에는 게시물과 첨부파일을 올릴 때 확인할 항목을 남겨야 합니다.
보안도 개발 단계의 약점을 줄이는 일과 운영 중 권한을 관리하는 일이 이어져야 합니다. 부서 이동 뒤 계정을 끊는 절차, 관리자 권한을 정기적으로 확인하는 방법, 장애나 의심스러운 접근이 생겼을 때 연락할 담당자를 정하지 않으면 시스템은 시간이 지날수록 관리하기 어려워집니다. 기존 행정 시스템과 연결한다면 데이터가 오가지 않을 때 시민에게 무엇을 보여줄지, 내부에서는 누가 조치할지도 미리 합의해야 합니다.
공공기관에 적용되는 접근성 지침과 개발보안 요구는 중요한 기준이지만, 필요한 점검 범위와 외부 검토 여부는 사업 유형, 개인정보 처리 방식, 기관 내부 규정에 따라 달라집니다. 그러므로 특정 인증이나 도구를 목표로 삼기보다, 우리 서비스의 시민 이용 흐름과 운영 흐름에서 생길 수 있는 실패를 먼저 적어보는 편이 낫습니다.
새 사업의 첫 회의에서는 메뉴 구조보다 “시민이 끝내야 하는 일 세 가지”와 “운영자가 관리해야 하는 정보 세 가지”를 먼저 써보십시오. 그 목록을 업체에 보여주고, 각 흐름에서 접근성 문제와 보안 문제가 생겼을 때 어디까지 고치겠다는 답을 받으면, 오픈 뒤의 이용 불편과 운영 부담을 줄일 수 있습니다.
