먼저 이글은 http://zine.standardmag.org/200802/20 와 같은 내용임을 알려 드리며 다시한번 테스트 해본 결과입니다.

크로스브라우징으로 인해 시간낭비 및 생각하지 않던 것들때문에 야근을 하는 경우가 종종 발생하죠. 참 안타까운 현실입니다.
알려진 크로스브라우징 팁 가운데 DTD의 선택도 중요한 부분을 차지 하고 있다는건 여러 글들을 통해 접했으리라 생각합니다.
그래서 DTD에 따른 박스크기 변화를 다시한번 테스트해 보았습니다.

테스트 박스는 공통적으로 width = 150px / height = 100px / padding = 30px / border = 3px 값을 주었을때 입니다.

먼저 DTD를 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> 로 했을 경우에 결과입니다.
소스는 다음과 같습니다.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Untitled Document</title>
<style type="text/css">
body { margin:30px; }
#wrap { width:150px; height:100px; padding:30px; border:3px solid #ccc; font-size:12px; }
</style>
</head>

<body>
<div id="wrap">테스트 크로스 브라우징</div>
</body>
</html>


dtd_html.gif

보 시는 바와 같이 파이어폭스를 제외한 IE6 / 7 은 지정한 가로/세로 값으로 보여지며 border 과 padding 값을 포함하고 있는 반면 파이어폭스는 지정한 가로/세로 값에서 border 값과 padding 값이 추가된 사이즈로 박스가 보여집니다. 


다음은 DTD 가 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 로 했을 경우 입니다.

소스는 다음과 같습니다.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Untitled Document</title>
<style type="text/css">
body { margin:30px; }
#wrap { width:150px; height:100px; padding:30px; border:3px solid #ccc; font-size:12px; }
</style>
</head>

<body>
<div id="wrap">테스트 크로스 브라우징</div>
</body>
</html>

dtd_xhtml.gif

이처럼 DTD에 따라 각 브라우저 별로 다르게 보임을 알수 있습니다.

오페라와 사파리(3.1) 역시 파폭과 동일하게 DTD와 관계없이  padding 값과  border 값만큼 지정한 박스보다  커짐을 알수 있었습니다.

dtd_xhtml_opera.gif 

dtd_xhtml_safari.gif

역시 IE만 혼자 노는걸 알수 있군요.. 참고 되셨으면 좋겠네요..^^

'개발도 하냐?' 카테고리의 다른 글

톰켓을 사용하는데 필요한 20가지 Tips  (0) 2008.12.26
웹 퍼블리셔란?  (0) 2008.12.20
제프리 젤드만의 웹표준 가이드  (0) 2008.12.20
OpenID php 구현  (0) 2008.12.19
중앙부처 사이트 웹 표준 안 지킨다  (0) 2008.12.12
9609002472.jpg
제프리 젤드만의 웹표준 가이드
웹 디자이너와 개발자, 그리고 사용자를 위한 올바른 선택(2ed)

제프리 젤드만 (Jeffrey Zeldman) 은 누구인가?
제프리 젤드만은 최초의 웹디자이너 중 한 명이고 전문가들 사이에서 강력한 영향력을 지녔습니다.

1995년 전 아트 디렉터이자 카피라이터인 그는 최초로 가장 영향력 있는 개인 웹 사이트 중의 하나 (www.zeldman.com)을 만들었고웹 디자인의 방법과 원칙에 대한 유명한 튜토리얼을 쓰기 시작했습니다.

1998년 마이크로소프트와 넷스케이프에서 각각 자기들의 브라우저에서 같은 기술을 지원하도록 설득한 기초 연합인 The Web Standards Project(www.webstandards.org)를 공동 설립했습니다. 같은 해 A List Apart(www.alistanart.com) 'for people who make websites' (웹 사이트를 만드는 사람들을 위하여)를 만들기 시작했습니다. 그리고 이 분야해서 가장 존중 받고 영향력 있는 잡지가 되었다고 합니다. (책 저자 소개 일부...)


웹표준과 저작 프로그램
제프리 젤드만의 웹표준 가이드에서는 이렇게 쓰여져 있습니다.

브 라우저 전쟁의 절정이었던 시점에서 개발된 어도비(이전의 매크로미디어)사의 드림위버너 Golive처럼 시장을 장악한 전문가용 비주얼 에디터들은 3.0과 4.0 브라우저에 최적화된 마크업과 코드를 생성하여 브라우저의 비호환 문제를 처리했습니다.

브 라우저가 비표준이고 유효하지 않은 HT<L 태그로 실행될 때 드림위버와 GoLive는 브라우저가 원하는 대로 태그를 만들어 주었습니다. 각 브라우저가 자신들만의 호환성 없는 DOM이 있거나 독자적인 스크립트 언어로 작동된다면, 드림위버나 GoLive는 그것에 따라서 코드를 만들었습니다.

이런 방식을 사용한 드림위버와 GoLive가 마크업과 코드를 직접 사용하는 개발자들보다 더 잘못했다는 것은 아닙니다. 2장에서 설명한 바와 같이 표준이 개발되는 중이었고, 브라우저들이 지원을 제대로 하지 않을 때라서 사이트 제작자도 어쩔 수 없었습니다. '원하는 대로 주라'는 말은 그때는 말이 됐지만 이제는 적절한 전략이 아닙니다. 브라우저가 표준을 지원하자 드림위버나 GoLive 같은 프로그램들도 같이 변하게 되었습니다. 이제는 프로그램들도 표준을 지원합니다.

전문 비주얼 웹편집의 선두 주자인 드림위버로 만든 사이트의 표준화 지원과 접근성을 향상시키는 노력의 일환으로 매크로 미디어의 기술자들과 같이 일하기 위해 2001년 WaSP의 Dreamweaver Task Force 가 생겨났습니다.
이 그룹의 주요목표는 아래와 같습니다.

* 드림위버는 '격이 다른'유효한 마크업을 만들어야 한다(유효한 마크업은 반드시 표준 태그와 요소만 사용해야 하고 에러가 없어야 한다.)
* 드림위버는 유효한 DTD를 추가하여 XHTML과 HTML 버전을 선택할 수 있게 해줘야 한다 (DTD-Document Type Definition은 브라우저에게 어떤 종류의 마크업으로 웹 페이지를 만들었는가를 알려준다.)
* 드림위버는 문서의 DTD를 엄격히 따르고, 이에 따라서 마크업과 코드를 만들어야 한다.
* 드림위버는 모두에게 접근성 있는 웹 문서를 사용자가 쉽게 만들 수 있게 해야한다.
* 드림위버는 CSS2를 정확하게 표현하여 CSS로 만들어진 페이지가 드림위버의 비주얼 환경에서 작동이 되어야 한다.
* 드림위버는 사용자의 허락 없이 inline 스타일을 추가하여 유효한 CSS 레이아웃을 방해아지 않아야 한다.
* 사용자가 드림위버로 만든 페이지가 유효하고 높은 수준의 접근성을 이룰 수 있다는 믿음을 가질 수 있어야 한다.

이 목표들에 더해서 추가적인 목표들이 2002년 5월 드림위버 MX가 출시되면서 생겨나게 되었습니다.
드림위버 MX를 만드는 데 도움을 주었던 Dreamweaver Task Force는 제품을 평가 하면서 아래 사실들을 발견하게 되었습니다.

* 훌류한 유효한 마크업을 생산해 냈다.
* 사용자가 접근성 있는 사이트를 만들 수 있게 도와주었다.
* (CSS배치에 다소 문제점이 있긴 하지만) 적합한 수준의 정확도로 CSS2를 표현했다.
* CSS 레이아웃을 해치지 않았다.
* 유효한 XHTML 과 CSS(자동으로 표준지원 검사를 하여)사용을 권장했다.
* 웹표준을 중요하게 생각하고 장려했다.

개인 적으로도 드림위버를 웹표준 저작 툴로 추천하는 바입니다.
참고로 외국에서 실시된 설문조사에서 가장 많이 사용하는 웹저작 툴로도 드림위버를 꼽고 있습니다.
http://webdesign.about.com/gi/pages/poll.htm?linkback=http://webdesign.about.com/b/a/253457.htm&poll_id=2822610066

물론 우리나라에서는 에디터플러스도 많이 사용되긴 하지만, 위에 설문조사에서 보듯이 웹퍼블리셔들이 선호하는 저작 프로그램임은 사실인거 같습니다.

'개발도 하냐?' 카테고리의 다른 글

웹 퍼블리셔란?  (0) 2008.12.20
DTD에 따른 브라우저 박스크기변화  (0) 2008.12.20
OpenID php 구현  (0) 2008.12.19
중앙부처 사이트 웹 표준 안 지킨다  (0) 2008.12.12
ERP, ISP, ITA ?  (0) 2008.11.29
OpenID 그까이꺼 (1)

February 21, 2007 at 8:44 pm · Filed under WebDevelopment, WebStandard

약속했던 대로, OpenID 구현에 대한 이야기입니다.
이번은 JanRain의 라이브러리를 이용한 초간단 OpenID Provider 제작편입니다.
JanRain의 라이브러리는 원래 Python으로 구현되었습니다만, 현재는 여러 언어로 포팅되어있지요. Ruby, Perl, PHP, DotNet, Java, ColdFusion 등이 가능합니다.
여기에서는 PHP Library를 이용하겠습니다.
주의 : php 4.3 이상. Bcmath, GMP 패키지 등이 설치되어 있어야 합니다.
MySQL의 경우에는 innoDB를 사용합니다.

1) 설치
Pear Installer가 지원된다면
pear install http://www.openidenabled.com/resources/downloads/php-openid/pear/Auth_OpenID-1.2.1.tgz

로 설치하면 간단 끝.
만약 경로를 따로 제어하고 싶다거나, 혹은 Pear를 쓸 수 없는 환경이라면, 그냥 다운로드 받아서 적당한 곳에 풀어주면 됩니다.

2) 구조
압축을 풀면 여러가지 디렉토리가 있는데, 실제적으로 중요한 곳은 /Auth입니다. 이 안에, OpenID 컨슈머와 프로바이더 모두를 위한 클래스들이 들어있습니다.
실제로 PHP4로 제작되어 있기 때문에 클래스 내부 코드들이 완벽한 OO 스타일을 유지하고 있다고 말하기는 어렵습니다. 코드들은 거의 미로수준. 게다가, 은근히 도큐먼트가 부실해서…

3) 구현
OpenID는 프로바이더와 컨슈머 사이에서 키를 발급하고 조회하는 메커니즘으로 운영됩니다. 발급된 키를 관리하는 방법은 여러가지가 있는데, 예를 들어, 메모리 세션을 이용하거나, 파일 세션, 혹은 DB 세션등을 이용하기도 하지요. 여기에서는 MySQL을 Store로 사용하겠습니다.

우선, 필요한 파일들을 include해야겠지요?
[php]
require_once(’Auth/OpenID.php’);
require_once(’Auth/OpenID/Server.php’);
require_once(’Auth/OpenID/MySQLStore.php’);
[/php]
내부적으로 다른 인클루드 파일들을 요구하기 때문에, include_path에 아까 설치한 Library위치를 포함시켜두면 좋겠습니다. (아니면 ini_set(’include_path’,) 를 설정하던가요.)

그리고 PEAR::DB를 이용한 DB커넥션을 Store로 사용할 것이므로 DB인스턴스를 만들어서 선언해줍니다.

[php]
$dsn = “mysqli://openid:password@localhost/openid”;
$connection = DB::connect($dsn);
[/php]

그리고는 MySQL을 이용하는 Store 객체를 반환받아야겠지요.

[php]
$store = new Auth_OpenID_MySQLStore($connection, ’setting’, ‘association’, ‘nonce’);
// $store->createTables();
[/php]

도큐먼트에 보면, 2번째 파라미터부터는 optional하다고 되어 있고, null값일 경우 default 정의된 테이블 이름으로 생성된다고는 되어있습니다만, 무엇의 문제인지 null값을 넣으면 제대로 생성되지 않더군요. 그리고 createTables()메쏘드를 실행해줍니다. 위에서는 주석처리해놓았는데, 사실 한번 테이블이 생성되면 저 메쏘드는 필요없어지기 때문입니다. 물론 여러번 실행시켜도 문제가 되지는 않습니다. (내부적으로 rollback)

이제, 해당 Store를 사용하는 OpenID Server 객체를 만들어야겠지요. 만약 다른 DB Store나 혹은 File Store를 쓰고 싶다면 해당 Store 클래스로부터 만들어진 객체를 $store로 넣어주면 됩니다.
[php]
$server =& new Auth_OpenID_Server($store);
[/php]

이제, 이 만들어진 Server 객체에 OpenID Request를 넘겨주면 되는데, 이 Request는 대개 Get메쏘드로 넘어온 값을 가지고 Request객체를 만들어 주면 됩니다.

[php]
//$value는 대개 Get으로 넘겨받은 OpenID request문자열입니다. 서버 구현에 따라 이 부분은 달라질 수도 있으니 알아서…
$request = Auth_OpenID::fixArgs($value);
$request = $server->decodeRequest($request);
[/php]

이 Request 객체의 멤버중에 mode라는 멤버가 있습니다. 이에 따라 해당 작업을 해주면 됩니다.

[php]
switch($request->mode) {
case ‘checkid_immediate’:
…
break;
case ‘checkid_setup’:
…
break;
default:
…
break;
}
[/php]

특별한 문제가 없는 한, association mode는 라이브러리에서 알아서 처리해줍니다. 물론 발급되는 키값을 바꾸거나 하고 싶다면 이 부분을 고쳐줘야겠지요. 어쨌거나, 특별히 고칠 부분이 없다면, 위의 default부분에, 아래의 코드를 넣는 것만으로 충분합니다. 이것은 user정보와는 상관없는 기본적인 handshake 단계의 통신이기 때문에 사실 건드릴 것도 별로 없는 셈이죠.
[php]
$response =& $server->handleRequest($request);
$webresponse =& $server->encodeResponse($response);
foreach ($webresponse->headers as $k => $v) {
header(”$k: $v”);
}
header(header_connection_close);
print $webresponse->body;
exit(0);
[/php]

checkid_setup과 checkid_immediate의 경우에는 프로바이더의 사용자 시나리오에 따라 복잡한 과정들이 처리되어야 하는데, 예를 들자면, 사용자가 인증을 허용하는지 여부등에 따라 반환되어야 하는 값이 달라져야겠지요.

만약 모든 조건이 클리어하다면, (예를 들어, Consumer사이트가 trustRoot에 포함되어 있고, 사용자가 해당 Consumer사이트로의 인증을 허락했다면…)
[php]
$response =& $request->answer(true);
$webresponse =& $server->encodeResponse($response);
foreach ($webresponse->headers as $k => $v) {
header(”$k: $v”);
}
header(header_connection_close);
print $webresponse->body;
exit(0);
[/php]
로 끝.

만약 Simple Registration Extended를 지원한다면, openid.sreg.required / openid.sreg.optional 의 형태(php에서는 openid_sreg_required / openid_sreg_optional 이라는 해쉬값으로..)로, 필요한 사용자의 데이터를 요구하게 됩니다. 이 경우에는,
[php]
$response->addField(’sreg’, 요구필드이름, 해당 데이터);
[/php]
형태로 추가해주면 되지요.(물론 $server->encodeResponse()전에..)

Provider의 사용자 시나리오에 따라서는, 로그인처리, 인증여부처리, 요구필드에 대한 허가 처리 등이 필요한 경우도 있을 수 있습니다. 그런 경우에는 Ajax나 혹은 일반 Form 형태로 사용자 브라우저에서 처리를 받은 후에, 현재 호출된 URL로 다시 redirect해주면 됩니다. (OpenID Request는 Get값으로 이루어지므로… 물론 처리페이지까지 OpenID Request들을 전달해서 그 페이지에서 처리하는 방법도 있겠지요.)

만약 올바른 요구와 답변이 아닐 경우에는,
[php]
$response =& $request->answer(false);
$webresponse =& $server->encodeResponse($response);
foreach ($webresponse->headers as $k => $v) {
header(”$k: $v”);
}
header(header_connection_close);
print $webresponse->body;
exit(0);
[/php]
로 해주면 됩니다.

나머지는 라이브러리에서 다 알아서 해주니까, Provider 개발자가 고민할 부분은, 사용자 시나리오를 어떻게 운영할 것인가.. 하는 부분이겠죠?

이상으로 OpenID 그까이꺼 만드는 법 Provider편 초간단 설명.

물론, 남의 라이브러리를 의지하지 않고, 프로토콜만 가지고 직접 구현할 수도 있겠습니다만, 뭐 굳이 그럴 필요 있나요?

Consumer편은 더 간단합니다만, 다음 기회에. 사실 Provider는 굳이 여러 곳에서 만들 필요는 없어요. 공연히 사용자에게 불편만 줄 뿐. 실상 Cyworld나 Naver Blog같은데서 지원하면 깨끗이 정리될 문제입니다만, 그럴 생각들은 없는 것 같고… (OpenID Provider라면 당연히 자사의 서비스에 Consumer도 붙여야 체면이 서겠습니다만… 과연 N이나 S가 그럴 것인지? ^_^)

----------------------

OpenID 그까이꺼(2)

February 23, 2007 at 4:03 am · Filed under WebDevelopment, WebStandard

이번에는 Consumer 구현입니다.
지난번에 이야기한 건 Provider편이었죠? 많은 부분 Provider와 겹치므로 슬쩍 새 창으로 띄워서 컨닝해가면서 따라오세요.
역시 마찬가지로 PHP 4.3.0 이상, bcmath나 gmp가 설치되어 있다고 가정하고, MySQL은 InnoDB를 사용합니다.
또한, 이미 OpenID Library가 설치되어있고 경로에 추가되어있다고 가정합니다.

Consumer편은 더 쉽습니다. 설명할 게 없을 정도.

일단, 세션스토어로 MySQL을 사용할 예정이니 Provider편과 마찬가지로 MySQLStore 객체를 만듭시다.

[php]
$connection = DB::connect($dsn);
$store = new Auth_OpenID_MySQLStore($connection, ’setting’, ‘association’, ‘nonce’);
//$store->createTables();
[/php]

물론, 최초 실행시에는 createTables()를 해줘야합니다.

만약 MySQL대신 다른 Store를 이용하고 싶다면 다른 Store 클래스로 객체를 만드시면 됩니다. Factory 패턴이기 때문에 따로 신경안써줘도 되는건 OO 공부하신 분들이면 다 아실테지요.
[php]
$store = new Auth_OpenID_FileStore($store_path);
[/php]
예를 들어 파일패스를 스토어로 쓰고 싶다면 이렇게 해주면 된다는 말씀.

이제 만들어진 스토어 객체로 Consumer 객체를 만듭시다.
[php]
$consumer = new Auth_OpenID_Consumer($store);
[/php]

일반적인 시나리오에서는, 사용자는 Consumer 사이트에 와서 자신의 OpenID를 Form으로 입력하겠죠. 어쨌거나 인증하고자 하는 OpenID값을 Consumer 객체에 던져주기만 하면 됩니다.

[php]
$openid = $_POST[’login_openid’]; // 뭐, 예를 들자면.. 이런 식이겠죠:)
$auth_request = $consumer->begin($openid); //오픈아이디 서버와 association을 시도하고 그 결과를 돌려줍니다.
if($auth_request) {
//success;
} else {
//fail;
echo “Authentication Fail”;
}
[/php]
$auth_request가 true이면 정상적으로 association이 이루어졌다는 뜻입니다. 만약 false라면 인증에 실패했다는 메시지를 사용자에게 보여주면 되겠죠?

association이 성공적으로 이루어졌다면 이제, 해당 openid에 대한 인증을 시도하면 됩니다.

[php]
$trust_root = ‘http://consumer.com’;
$process_url = ‘http://consumer.com/afterAuth’;
$redirect_url = $auth_request->redirectURL($trust_root, $process_url);
header(”Location: “.$redirect_url);
[/php]
$trust_root는 Provider에게 이 인증시도가 어떤 Consumer로부터 시도된 것인지 신뢰여부를 판단하게 해주는 일종의 키값이 됩니다. 완벽하진 않지만, trustroot와 인증시도 도메인간에 도메인이 다를 경우 피싱시도로 파악해서 인증을 거부하거나 할 수 있도록 하지요. 반대로, trustroot로 인정된 도메인의 경우에는 따로 지정하지 않는 한, 인증을 자동보장한다거나 하는데 쓰일 수 있겠지요.

$process_url은 OpenID Provider가 인증을 처리하고 난 후 그 결과값을 되돌려받을 Consumer 사이트의 url입니다.

위의 코드가 실행되면, $redirect_url이 되돌려집니다. $redirect_url은 Provider의 인증처리 페이지에 인증 Request를 Get 메쏘드로 전달하는 형태이지요. 즉, 이렇게 만들어진 $redirect_url로 redirect시켜주기만 하면 됩니다.

만약 단순한 인증으로 끝나지 않고, Simple Registration Extension를 이용해 사용자 정보를 얻어오길 원한다면
[php]
$auth_request->addExtensionArg(’sreg’, 요구필드타입, 요구필드이름리스트);
[/php]
를 redirecURL메쏘드 실행전에 실행시켜주면 됩니다.
요구필드타입은 required/optional이구요, 비록 required라고 해도 Provider에서 반드시 정보를 제공한다는 보장은 없으니(Simple Registration Extension를 지원하지 않거나, 사용자가 정보제공을 거부하거나…), required로 요구한 필드의 되돌아오는 값이 없다해도 에러는 아니라는 점.
그외에, policy_url을 이용해, 어떤 필드들을 왜 요구하는지 설명을 알려줄 수도 있지요.
요구필드로 현재 Simple Registration Extension 에 정의된 필드는,
nickname, email, fullname, dob, gender, postcode, country, language, timezone

의 8 가지인데요, 주의할 점은 각각의 필드의 리턴값은 RFC와 ISO에 정의된 표준 스펙이라는 겁니다. 그러니까, country를 알려달라고 요구해도, “Korea”라든가 “대한민국”같은 형식으로 돌아오지는 않는다는 거지요.
각각의 필드에 대한 스펙 및 Simple Registration Extension에 관한 더 자세한 설명은,
여기를 참고하세요.

에.. 하여튼간에, 실제로 Simple Registration Extension을 이용하려면,
[php]
$auth_request->addExtensionArg(’sreg’, ‘policy_url’, ‘http://consumer.com/policy’);
$auth_request->addExtensionArg(’sreg’, ‘required’, ‘email’);
$auth_request->addExtensionArg(’sreg’, ‘optional’, ‘nickname’);
$auth_request->addExtensionArg(’sreg’, ‘optional’, ‘gender’);
$redirect_url = $auth_request->redirectURL($trust_root, $process_url);
header(”Location: “.$redirect_url);
[/php]
처럼 하면 된다는 말씀.

이제 인증 요청이 끝났습니다. redirect를 통해 Provider에게 GET 메쏘드로 인증요청을 했으니 나머지는 Provider와 사용자간에 나름의 과정을 통해 인증여부가 회신되겠지요?

전에 지정해둔 $process_url로 회신이 돌아옵니다.

다음은 $process_url에서 GET으로 돌아온 회신에 대한 처리부분입니다.

[php]
$response = $consumer->complete($_GET);
switch($response->status) {
case Auth_OpenID_CANCEL :
// 사용자가 인증을 취소했을 때의 처리
break;
case Auth_OpenID_FAILURE :
// 무언가의 문제로 인해 인증이 실패했을 때의 처리(인증을 요구한 openid가 없다든가..)
break;
case Auth_OpenID_SUCCESS :
// 인증성공!!
break;
}
[/php]

인증은 모두 끝났습니다. 간단하죠? :)
만약 Simple Registration Extension을 사용했을 경우, 요구했던 필드값들을 구해야겠죠?

[php]
$sreg = $response->extensionResponse(’sreg’);
echo $sreg[’email’];
[/php]

이걸로 진짜 끝.

간단하죠?

그러니까 OpenID 지원하는게 뭐 대단한 것도 아닌거에요. 무슨 코어모듈을 고쳐야 한다거나 하는 작업이 있을리도 없으니까, Consumer 지원하는 건 어려운 일이 아니에요. 물론 Provider가 되려면 좀 더 복잡한 작업이 필요하긴 합니다만, Provider는 많을 필요도 없고요.
OpenID의 의의를 이해하신다면, 별 특징이나 기능도 없는 Provider가 늘어나는 건 그저 사용자들에게 불편만 주고 OpenID의 장점을 전혀 못살리는 멍청한 짓이기도 하지요.
delegation을 이용하면 어떤 Provider를 쓰든 상관없는 거니까요. (오히려 Simple Registration Extension을 지원안하는 Provider라면 편의성이 떨어지는 셈이니 이용에 고민을 해봐야겠지요. 물론 보안문제가 아직 완벽하게 해결된 것은 아니므로 SRE를 믿느냐는 좀 다른 이야기긴 합니다만.)

국내에서 OpenID를 이야기하는 사람들이 많아지긴 했습니다만… 뭐랄까, 실제 개발자들에게는 그런 뜬구름잡는 이야기보다는 간단한 샘플소스에 대한 설명 하나가 더 필요한 시점아닐까 하는 생각이 드네요. 정말로 OpenID를 널리 퍼뜨리게 하고 싶다면요. 혹은, 그냥 기술적 우위를 뽐내는 걸로 만족하는 거라면 또 다른 이야기겠지만요.


'개발도 하냐?' 카테고리의 다른 글

DTD에 따른 브라우저 박스크기변화  (0) 2008.12.20
제프리 젤드만의 웹표준 가이드  (0) 2008.12.20
중앙부처 사이트 웹 표준 안 지킨다  (0) 2008.12.12
ERP, ISP, ITA ?  (0) 2008.11.29
iabf 에서 사용하는 기본 css  (0) 2008.11.23

중앙부처 사이트 웹 표준 안 지킨다

디지털타임스 | 기사입력 2008.08.28 08:03


본지조사, 파이어폭스ㆍ오페라 사용때 30% 이상 중대오류

정부가 웹 표준 준수 방침을 밝히고 있지만 중앙부처 사이트부터 웹 표준을 지키지 않고 있는 것으로 확인됐다. 이에 따라 웹 표준 수준을 높인`인터넷익스플로러(IE) 8'이 출시되면 혼란이 우려된다는 지적이 일고 있다.

본지가 최근 43개 중앙정부사이트를 대상으로 파이어폭스와 오페라 브라우저의 사용 가능여부를 조사한 결과 30% 이상(파이어폭스 34%, 오페라 30%)의 사이트가 메인 화면 깨짐이나 메뉴가 작동이 안 되는 등의 문제가 발생했다.

청 와대와 대통령 직속기관, 정부 15개 부처와 18개 청을 대상으로 메인화면의 내용과 메뉴의 작동여부, 표본조사를 통한 페이지 이상을 확인한 결과 파이어폭스 사용시 15개 사이트가 중대한 이상을 보였으며 오페라는 13개 사이트에서 이상이 발견됐다. 약간의 글자 깨짐 등 사소한 이상현상을 합할 경우 웹 표준과 브라우저 호환성이 떨어지는 사이트는 50%에 달했다.

감사원 사이트의 경우 메인 화면의 상당수 메뉴가 작동하지 않아 사이트를 거의 사용할 수 없었으며 국토해양부, 국가보훈처 사이트 등도 메인 화면에 이상이 나타나고 일부메뉴를 사용할 수 없었다. 관세청, 방위사업청, 병무청 등도 IE가 아닌 다른 브라우저로는 주요 서비스를 이용할 수 없었다.

특히 웹 표준 준수지침을 마련한 주무부처인 행정안전부의 경우 고객센터 페이지에 이상이 있는 것으로 나타나 체면을 구겼다.

이같은 오류현상은 웹 표준을 준수하지 않고 마이크로소프트(MS)의 인터넷익스플로러에만 적합하도록 사이트를 제작했기 때문이라는 게 업계의 지적이다.

최 근 정부가 웹 표준에 관한 지침을 공지하고 준수 대책을 발표했지만 모두 권고 수준이어서 각 부처 웹사이트 담당자들의 변화를 이끌어내지 못하고 있다는 분석이다. 관계자들은 해당 부처 책임자들이 웹 표준에 대한 인식이 부족하고 사이트개발 후 웹 표준에 대한 테스트도 이뤄지지 않고 있다고 지적했다.

한 전문가는 "인터넷 익스플로러의 세계시장 점유율이 70%대인 것을 감안할 때 20%를 넘는 브라우저를 지원하지 못하는 것은 장기적으로 해외인터넷 사용자들의 사이트 이용을 제한, 우리 인터넷 환경을 고립시키는 것"이라고 말했다. 또 다른 전문가는 "MS는 하반기 출시할 익스플로러 8.0 버전에서 웹 표준 수준을 높인다는 계획인데 국내 사이트들이 이를 따라가지 못한다면 큰 혼란이 올 수 있다"고 우려했다.

강진규기자 kjk@

'개발도 하냐?' 카테고리의 다른 글

제프리 젤드만의 웹표준 가이드  (0) 2008.12.20
OpenID php 구현  (0) 2008.12.19
ERP, ISP, ITA ?  (0) 2008.11.29
iabf 에서 사용하는 기본 css  (0) 2008.11.23
산출물관리지침(한국전산원)  (0) 2008.10.11
ERP/ISP/ITA 모두 경영정보시스템(MIS)분야에서 등장하는 주제입니다.
MIS분야가 해결하고자 하는 중심 이슈 중 하나는 "IT를 어떻게 조직 목적/전략에 부합시킬 것인가"라는 명제인데 위의 개념들은 모두 그런 목
적 배경 하에서 등장했습니다.

ERP는 약간 scope이 다르니 따로 떼어놓고 생각하는 게 좋고, ISP/ITA를 같이 비교를 하는 것이 좋습니다.

ERP는 쉽게 이야기해서 조직 내 흩어진 DB들을 하나로 통합하자는 계획을 세우는 것입니다. 그래서 조직의 가치사슬 상의 모든 프로세스들이 각자
의 DB가 아닌 통합 DB에 데이터를 저장하고 활용함으로써 데이터의 중복도 방지하고 데이터의 분석도
용이하게 하는 목적이 있습니다. DB통합의 목적은 딱히 한가지로 정의할 수 없지만 궁극적으로는 조직 전략의사결정을 지원하여 조직의 목적을 달성하
도록 하는 데 있습니다.
(ERP 참고 : http://ees.khu.ac.kr/iee/ees9/main0.html)

ISP는 80년대 말 James Martin의 정보공학방법론을 시초로 하여 지금까지 가장 많이 사용되어 온 정보화전략계획 방법론입니다.
여기서는 조직의 다양한 차원에서 현황을 분석하고 이를 바탕으로 미래 모델을 제시하고 정보화이행계획을 수립하게 됩니다.

ITA는 오늘날 EA(Enterprise Architecture)라는 용어로 더 많이 사용되고 있습니다.
그리고 ISP와 비교했을 때 상응하는 용어는 정확하게는 ITA가 아니라 EAP(Enterprise Architecture)가 됩니다.
EAP에서 수행하는 작업은 ISP와 유사하나, EAP는 ISP에 비해 "관리적 측면"에서 더 보완된 개념입니다.

ISP에서 도출된 산출물들은 조직의 방향성을 이끌어 내기위한 재료이지, 그것 자체를 관리하는데 초점을 두지 않습니다.
하지만, EAP를 통해 도출된 산출물들을 EA라는 틀(프레임워크라고 합니다.)에 담아 체계적으로 정리하고, 각각의 산출물 간 상호관계를 파악하는 데 중점을 둡니다. 그리고 그렇게 정의된 현재의 EA(AS-IS EA)를 미래의 EA(TO-BE EA)로 바꿔가는 이행계획을 수립함으로써 IT가 조직목적에 부합될 수 있도록 합니다.

따라서, EAP에서 나온 산출물들을 EA프레임워크에 정리한 것이 조직의 아키텍처(Enterprise Architecture)가 되는 것이고, 이 아키텍처를 잘 관리함으로써 ISP와는 다른 여러가지 유익을 얻을 수 있습니다. 이 아키텍처의 관리를 위해 EAMS Enterprise Architecture)라는 시스템이 사용되는 것도 ISP와의 차이라고 할 수 있습니다.

EA는 IT가 조직목적에 부합하도록 하는 본래의 목적 이외에도, 조직 내 업무 프로세스 관리, 정보자원관리, 데이터 관리, 물리적 자원관리 등 종합적인 자원관리 도구로도 사용할 수 있고, 조직 내 투자프로세스와 연동시키면 투자관리 지원도구로도 사용될 수 있고, 나가아가서는 조직 개편이나 기업 간 M&A 같은 조직 차원의 변화관리에도 사용될 수 있습니다. EA는 조직을 모든 차원에서 투명하게 들여다 볼 수 있는 청사진인 셈입니다.

'개발도 하냐?' 카테고리의 다른 글

OpenID php 구현  (0) 2008.12.19
중앙부처 사이트 웹 표준 안 지킨다  (0) 2008.12.12
iabf 에서 사용하는 기본 css  (0) 2008.11.23
산출물관리지침(한국전산원)  (0) 2008.10.11
PLT 6 마르미 III 개발 방법론  (0) 2008.10.11 
http://www.iabf.or.kr//Lab/share/css/base.css


@charset "euc-kr";

/*

 * default definition

 */

body {

	margin: 0;

	padding: 0;

	font-size: 0.75em;

	line-height: 1.5em;

	/*

	font-family: Dotum, "돋움", sans-serif;

	*/

	font-family: "Malgun Gothic", "Lucida Grande", Tahoma, Verdana, AppleGothic, UnDotum, sans-serif;

}

* html body {

	/*

	font-size: 12px;

	*/

}

form {

	margin: 0;

	padding: 0;

}

hr {

	display: none;

}

p, div, th, td, select, input {

	color: #333;

}

a:link, a:visited {

	color: #555;

	text-decoration: none;

}

a:active, a:hover {

	color: #777;

	text-decoration: none;

}

img, 

input.type-image {

	border: 0 none;

}

input.type-text, 

textarea {

	border: 1px solid #ddd;

	background: #fff;

	padding: 1px;

}

input.type-text:hover, 

input.type-text:focus, 

textarea:hover, 

textarea:focus, 

select:hover, 

select:active {

	background-color: #ffd;

}

input, select, textarea {

	vertical-align: middle;

	font-size: 1em;

	color: #333;

}

select {

	font-size: 11px;

	font-family: Dotum, "돋움", sans-serif;

}

span.button, 

img.button, 

a.button {

	cursor: pointer;

	vertical-align: middle;

}

'개발도 하냐?' 카테고리의 다른 글

중앙부처 사이트 웹 표준 안 지킨다  (0) 2008.12.12
ERP, ISP, ITA ?  (0) 2008.11.29
산출물관리지침(한국전산원)  (0) 2008.10.11
PLT 6 마르미 III 개발 방법론  (0) 2008.10.11
웹표준준수 실무개발 방법론  (0) 2008.10.01
정보시스템 개발 방법론에 따른 산출물 관리 지침
산출물관리지침.pdf

'개발도 하냐?' 카테고리의 다른 글

ERP, ISP, ITA ?  (0) 2008.11.29
iabf 에서 사용하는 기본 css  (0) 2008.11.23
PLT 6 마르미 III 개발 방법론  (0) 2008.10.11
웹표준준수 실무개발 방법론  (0) 2008.10.01
웹표준 준수사항 몇가지  (0) 2008.10.01
PLT 6 마르미 III 개발 방법론
 
개요
최근 인터넷의 폭발적인 성장과 함께 이기종 컴퓨터 사이의 연동 기술의 발전으로 이를 이용한 소프트웨어에 대한 수요가 폭발적으로 증가하고 있다.  이와 같은 변화에 능동적으로 대처하기 위해서는 고품질의 소프트웨어를 적기에 공급할 수 있는 새로운 개발 방법이 필요하다.  컴포넌트 기반 시스템 개발 방법은 위와 같은 품질과 수요에 대한 요구사항을 모두 만족시킬 수 있는 유일한 대안으로 제시되고 있는 새로운 시스템 개발 패러다임이다.
 
한국전자통신연구원은 기존의 정보공학 및 구조적 방법을 기반의 마르미(MaRMI, Magic and Robust Methodology Integrated)와 객체지향 기반의 마르미-II 방법론에 이어, 학계 및 산업계와 협력하여 컴포넌트 기반의 마르미-III 개발 방법론을 개발하였다.  마르미-III는 컴포넌트의 개발 및 컴포넌트 기반의 시스템 개발에 필요한 작업과 작업 수행에 필요한 기법 및 작업별 산출물을 정의하고, 작업에 따른 상세한 개발 절차와 지침을 제공한다.
 
History
 
마르미
마르미-II
마르미-III 버전 1.0
마르미-III 버전 2.0
개발 기간
1994. 10. ~ 1997. 9.
1995. 11. ~ 1998. 10.
1999. 7. ~ 2001. 6.
2001. 7. ~ 2003. 6
지원 방법
구조적 방법, 정보공학
객체지향방법
컴포넌트 기반
컴포넌트 기반
특징
국제표준 수용(ISO12207)
개발공정의 계층화/상세화
산출물의 간소화
UML 기반
반복적/점진적 개발
위험관리
EJB 기반
아키텍처 중심
마르미-II 메타모형 공유
COM+, CORBA 지원
프로젝트/품질관리 지원
사용자 방법론 개발/조정 지원
구성
마르미-D 절차서
마르미-D 기법서
마르미-D 산출물양식집
마르미-D 적용사례집
마르미-P 절차서
마르미-P 기법/산출물
마르미 전자매뉴얼
마르미-II 개요서
마르미-II 절차서
마르미-II 기법서
마르미-II 양식정의서
마르미-II 전자매뉴얼
DEBUT (UML 모형화 도구)
DEBUT 사용자지침서
DEBUT 튜토리얼
마르미-III 개요서
마르미-III 절차서
마르미-III 기법서
마르미-III 양식정의서
마르미-III 적용사례서
마르미-III 개요서
마르미-III 절차서
마르미-III 기법서
마르미-III 양식정의서
마르미-III 적용사례서
 
특징
-         컴포넌트 기반 시스템 개발 지원
-         UML 모형화 표준 사용
-         유스케이스 기반 개발
-         아키텍처 중심
-         반복적, 점진적 개발
-         구체적이고 실용적인 방법론
-         마르미, 마르미-II 와 일관성 유지(방법론 메타모형 공유)
 
구성
마르미-III는 절차서, 기법서, 양식정의서 및 적용사례서로 구성되어 있다.  개발 공정은 컴포넌트 개발 공정과 이미 개발된 컴포넌트를 활용하여 시스템을 개발하는 공정으로 구분할 수 있는데, 마르미-III는 컴포넌트 기반 시스템 개발 공정을 중심으로 컴포넌트 개발 공정을 함께 기술하였다. 개발 절차는 크게 계획단계, 아키텍처단계, 점진적개발단계, 인도단계의 4개 단계로 이루어져 있고, 각 단계는 논리적으로 서로 연관된 작업을 하나로 묶은 활동으로 구성되어 있다.  각 작업은 하나 이상의 산출물을 만들어 내며, 이를 위한 상세한 세부 절차가 정의되어 있다.  산출물을 위한 양식은 양식정의서에 정의되어 있다.
 
계획단계
Ø        계획 단계의 작업을 체계적으로 수행하기 위한 구체적인 계획을 수립하여, 이에 대한 의사결정자, 관련자, 사용자에게 추진을 보고한다.
Ø        개발 시스템의 비전, 목표, 및 범위를 결정한다.
Ø        사용자 요구사항 및 관련 자료를 수집한다. 경우에 따라서는 시스템의 배경에 대한 명확한 이해를 획득하기 위해 비즈니스 모형을 작성하고 현행시스템을 분석한다.
Ø  유스케이스  및 개념 모형의 작성을 통해 시스템의 범위를 정의하고 프로토타이핑을 통한 사용자의 검증을 수행한다.작성된 모형을 기반으로 전체 프로젝트의 규모 및 소요비용 추정하고 타당성 분석을 수행한다.
Ø        시스템을 개발하기 위한 추진 계획 및 품질보증계획을 수립하여 프로젝트계획서를 작성하고 사용자와 의사결정자에게 승인을 받는다.
 
아키텍처단계
Ø        개발할 시스템에 대한 사용자의 요구사항을 충분히 이해하고 요구사항을 명확히 하기 위해 사용자 요구사항에 대한 분석 작업을 수행한다
Ø        이를 바탕으로 컴포넌트를 식별하여 비즈니스 아키텍처 및 응용 아키텍처를 정의한다.
Ø  아키텍처 프로토타이핑을 통해 실제 구현 가능한지 아키텍처를 검증하고 점진적 개발단계에서 수행을 위한 상세한 개발계획을 수립한다.
 
점진적개발단계
Ø         개발 전체 범위를 미니프로젝트 단위로 분할하고 이를 수행하기 위한  계획을 수립한다.
Ø         해당 미니프로젝트 내에서 구축할 유스케이스를 구현 관점에서 보완한다.
Ø         보완된 유스케이스를 바탕으로 아키텍처를 구현 관점에서 보완한다.
Ø         개발할 컴포넌트의 내부를 구현관점에서 설계한다. 클래스도, 협력도를 중심으로 내부를 설계하며, 필요 시 다른 다이어그램을 활용할 수 있다.
Ø         클래스 및 컴포넌트를 구현하고 데이터베이스, 사용자 인터페이스 등을 설계하고 구축한다.
Ø         아키텍처 단계에서 개발된 사용자지침서 초안을 기반으로 사용자지침서를 개발한다.
Ø         테스트계획서를 바탕으로 통합테스트를 수행하여 각 컴포넌트를 통합할 때와 이전 미니프로젝트에서 개발된 컴포넌트 시스템과 통합할 때 발생할 수 있는 오류를 제거한다.
Ø         각 미니프로젝트에서 유스케이스를 개발하고 나면 사용자의 검토를 받아 요구사항을 만족하는지 확인한다.
Ø         계획된 모든 미니프로젝트를 수행하고 나면 통합된 시스템의 기능성 및 성능이 사용자 요구사항을 만족하는지 확인하기 위한 시스템테스트를  수행하고 본 단계의 수행결과를 평가한다.
 
인도단계
Ø        개발자 환경에서 개발된 결과물을 컴포넌트인 경우에는 컴포넌트 리포지터리에, 컴포넌트 기반 시스템인 경우에는 실제 시스템이 운영될 사용자 환경에 설치한다. 기존에 운영되고 있는 리포지터리나 시스템이 있을 경우 신규 시스템으로 전환하여 원활한 운영이 가능하도록 한다.
Ø        개발된 컴포넌트 또는 시스템에 대하여 최종적으로 사용자 요구사항과의 일치 여부에 대하여 승인을 얻고 프로젝트의 모든 전달물을 사용자에게 전달하고 인계한다.
Ø        본 단계는 사용자의 업무에 영향을 주게 됨으로 사용자의 적극적인 참여가 필수적이며, 사용자는 인수와 함께 시스템을 운영할 수 있도록 준비하여야 한다.
 
기대 효과
-         개발조직 내 체계적인 컴포넌트 기반 개발 및 관리 절차 확립
-         사례 예시와 절차 묘사의 단계적 상세화를 통한 이해도 증진에 따라 쉽게 조직에 적용 가능
-         최신 정보기술 동향의 지속적인 반영을 통한 방법론의 유용성 유지
-         지속적인 보급 및 확산을 통한 국내 소프트웨어 개발업체의 산업 경쟁력 향상

[출처] 마르미 III 개발 방법론|작성자 후루꾸

'개발도 하냐?' 카테고리의 다른 글

iabf 에서 사용하는 기본 css  (0) 2008.11.23
산출물관리지침(한국전산원)  (0) 2008.10.11
웹표준준수 실무개발 방법론  (0) 2008.10.01
웹표준 준수사항 몇가지  (0) 2008.10.01
검색결과의 Visualization  (0) 2008.09.24

웹표준화와 웹접근성 강화에 대한 이슈가 커지고 있다. 오는 4월 11일(차주 금요일) '장애인 차별금지 및 권리구제를 위한 법률'이 시행되고, MS의 Internet Explorer 8은 그동안 문제가 많았던 CSS 렌더링 엔진을 자사 제품중(IE 5.5, 6, 7) 가장 완성도 있는 표준 지원 엔진으로 바꿔놓았다. 애플은 자사의 'Safari' 웹브라우저를 윈도우용으로 출시하였고, 최근에는 웹표준기술 테스트인 Acid3를 통과했다는 소식을 전했다. 오페라 역시 'Safari'와 같은 날 Acid3를 통과했고, 모바일 시장(휴대폰, PDA 등에 탑재되는 미니 브라우저 시장)에서의 강세를 이어가고 있다.

바야흐로 2008년은 웹표준의 전환점이 될 것으로 보인다. 그동안 은비까비가 들려주는 옛날 옛적 이야기쯤으로 치부하던 웹 실무자들도 조금씩 관심을 보이기 시작했고, 해야겠다는 생각을 하기 시작했다. 며칠전 사내 웹표준 세미나 이후 계획되어 있던 프로젝트가 곧바로 웹표준 개발로 전환되는 쾌거(!)를 이룬 것이다. 적어도 두시간 가까이 목말라가며 떠들었던 내 작은 수고가 헛되지만은 않았던 것일까.

그런데 바로 고민거리가 생겼다. 해야한다고 이연사 목청 높여~ 외쳤으나 정작 'How?'에 대한 해답을 확실히 주지 못한것이다. 세미나 직후 웹표준 개발로 선회한 프로젝트를 담당하신 기획자분이 내게 왔고, 어떻게 해요... 라고 물으시는데 참 미안해지더라. 지금까지는 웹표준을 위해서 웹퍼블리셔들이나 개발자들이 표준기술을 익혀왔고, 디자이너나 플래셔들에게는 접근성에 대한 이해를 구해왔었다. 하지만 사실 기획자를 통한 개발 프로세스의 적절성 논의에서부터 필요하다면 새로운 개발 프로세스가 필요하지 않을까 하는 생각을 하게 되었다.


한국소프트웨어진흥원에서 발표한  '실전 웹 표준 가이드(2005)'에 보면 마지막 챕터에 표준 개발 프로세스를 자세히 설명하고 있는데 이를 먼저 소개해보고, 김철수님의 웹 표준 개발 후기를 통한 문제점과 개선점 등을 고민해 보겠다.

실전 웹 표준 가이드의 '실전 표준 개발 프로세스'

기존 웹 개발 프로세스는 일반적으로 Waterfall 방식이라고 불리우는 선형적이고 밀어내기식의 프로세르를 따르고 있다.

사용자 삽입 이미지

실전 웹 표준 가이드 p183

쉽게 말해 '기획 → 시안 → 스토리보드 → 디자인 → 코딩 → 프로그래밍/디버깅'으로 이어지는 방식인데 전문적인 지식이 없더라도, 또는 프로젝트가 진행중인 새로운 인력이 투입이 되더라도 별도의 교육이 필요하지 않는 비교적 쉽고 단순한 방법이다. 때문에 웹개발 초기부터 도입이 쉬웠고 아직까지도 크게 변하지 않고 적용되고 있다.

이 방법의 문제는 ① 업무의 병목현상 ② 의존적 스토리보드 ③ HTML문서구조화의 어려움 ④ 개별 역활 중심의 프로세스를 통한 업무 과중을 들 수 있습니다.

  1. 업무의 병목현상
    Waterfall 방식은 선행 프로세스가 지연될 경우 전체 프로세스의 지연으로 이어진다. 즉, 기획이 늦어지면 디자인과 코딩, 개발이 차례로 늦어지는 문제가 생긴다. 코딩까지 완료된 시점에서 기획이나 디자인이 변경되면 재코딩이 이루어지는 것도 병목현상에 한 몫 하게 된다. 아울러 프로세스상 뒤에 위치한 코딩이나 개발 인력의 프로젝트의 초기 참여율이 낮고, 둘 이상의 프로젝트에 참여하게 되면서 집중도를 낮춰 전체적인 생산성을 떨어뜨리는 경우가 생긴다.
  2. 의존적 스토리보드
    스토리보드는 웹개발의 시작이고, 밑그림입니다. 그만큼 중요하죠. 문제는 디자이너나 개발자들이 지나치게 스토리보드에 의존적이라는 것입니다.

    3. “스토리보드에는 그에 대한 지시사항이 없는 걸요” - 아주 기본적인 에러확인 로직을
    스토리보드에 없다는 이유만으로 개발하지 않은 프로그래머의 반문
    “저는 스토리보드에 그려진 대로 그린 것 뿐인데요...” – 디자인이 참신하지 못하다는
    지적을 받은 디자이너의 변명
    “어째서 스토리보드에 있는 그대로 하지 않았지?” – 발전적 창의성을 적용한
    프로그래머/디자이너를 인정하지 않는 기획자의 질책

    위의 예는 의존적 스토리보드의 문제점을 제대로 보여주고 있죠. 이로 인해서 기획자는 스토리보드를 수백장씩 상세하게 기술해야만 하는 업무적 과중을 느끼게 됩니다. 웹디자이너에게는 스토리보드를 그대로 Photoshop에 그려내는 '오퍼레이터'와 같은 수동적인 자세를 가지는 것도 문제가 됩니다. 또한, 전체 프로세스를 한 눈에 보여주지 못한 수백장의 스토리보드는 개발자에게 별로 도움이 되지 못합니다.

  3. HTML문서 구조화의 어려움
    HTML문서를 코딩하는 일은 관례적으로 웹디자이너의 역활로 지정되어 온 경우가 많습니다. 규모가 커지고, 웹디자이너의 부담을 줄이기 위해서 'HTML코더'라고 불리우는 직군이 생겼지만 상대적으로 낮은 대우와 평가를 받아왔습니다. 때문에 웹디자이너가 코딩을 하든, 웹개발자가 하든, 별도의 코더가 하든 HTML문서가 제대로 '구조화'되지 못하는 문제가 생기게 된 것입니다.

  4. 개별 역활 중심의 프로세스를 통한 업무 과중
    기획자나 디자이너, 개발중 어느 한 직군(역활)을 중심으로 프로세스를 개선하거나 정리할 수 있습니다.
    기획자 중심의 프로세스는
    사용자 삽입 이미지

    실전 웹 표준 가이드 p191

     
    이 될 것이고, 디자이너 중심의 프로세스는
    사용자 삽입 이미지

    실전 웹 표준 가이드 p189


    이 됩니다. 프로그래머 중심의 프로세스 역시
    사용자 삽입 이미지

    실전 웹 표준 가이드 p190


    의 절차를 갖게 됩니다. 어느경우라도 XHTML 구조화(마크업)와 CSS 디자인이라는 표준 기술 영역을 포함해야 하기 때문에 업무 과중이 문제가 됩니다. 특히 과거처럼 웹디자이너에게 마크업과 CSS디자인을 맡기게 되면, 시각적인 디자인과 논리적인 디자인의 차이로 인해 오히려 좋지 않은 영향을 끼칠 수 있을 것입니다.

웹 표준 가이드에서는 위와 같은 기존 프로세스의 문제점을 지적하고 '웹퍼블리셔 중심의 개선된 모델'을 제안하고 있습니다.

사용자 삽입 이미지

실전 웹 표준 가이드 p193


보기엔 상당히 복잡해 보이지만 단순히 HTML 코딩만을 위해서 'HTML 코더'를 두었던 것과 달리 웹 표준 기술에 대한 전문성을 가진 '웹퍼블리셔'라는 직군을 포함시키면서 기획자나 디자이너, 개발자가 가질 업무의 과중을 덜어냄과 동시에 전체 프로세스의 효율성을 높이고 있다고 볼 수 있습니다.

이제 여기서 실제로 위의 프로세스를 실무에 적용했던 김철수님의 후기를 살펴보겠습니다.

김철수님의 'Storyboard - 표준 스토리보드 구상기'

김철수님은 웹 2.0 에 따른 Ajax 사용등을 고려하면서 새로운 스토리보드의 필요성을 느끼셨다 합니다. 그리고 앞서 소개해 드린 '실천 웹 표준 가이드'의 '웹퍼블리셔 중심의 개발 프로세스'를 받아들여 프로젝트에 적용하는 노력을 해 주셨습니다. 특히 김철수님은 웹퍼블리셔에게 XHTML, CSS, JS와 같은 웹 표준 기술의 전문성과 더불어 프로젝트의 실무적인 조율 능력이 필요함을 지적하고 있습니다. 그리고 다음은 김철수님께서 실제로 적용한 방법이다.

방법은 이러했다. 우선 전체가 모여 프로세스 플로우를 짜기 시작했다. 이때 사실상 전반적인 기획과 분석과 설계가 같이 진행되어서 대략 2개월 정도가 걸렸다. 그 다음에는 컨텐츠 명세서를 간단히 작성하고 곧바로 퍼블리셔를 임명하여 HTML 코딩 작업에 들어갔다. 그 산출로 나온 CSS를 디자이너가 실시간으로 확인하면서 디자인 작업을 했고, 개발자는 DB 개발과 서버 프로그램 개발을 진행했다.

그리고 다음과 같은 문제점들을 나열했습니다.

첫째, 전체가 모여 프로세스 플로우를 맞추는 것이 매우 힘든 일이었다.

둘째, 컨텐츠 명세서를 작성하는 것이 쉽지 않았다.

셋째, 퍼블리셔의 작업을 충분히 해낼 사람이 없었다.

넷째, CSS를 잘 다루는 디자이너가 없었다.

아무래도 새로운 프로세스를 직군별로 설득하고 이해시키는 일이 쉽지 않았을 것이며, 새롭게 등장한 컨텐츠 명세서를 어떻게 해야하는지 기준도 없는 상태에서 진행하기란 쉽지 않았을 것이다. 그리고 웹 표준 기술을 제대로 숙지하고 적용할 수 있는 전문적인 웹퍼블리셔의 부재는 어제 오늘의 문제가 아니고, CSS 디자인과 같은 웹 표준 기술이 요구되는 작업을 디자이너가 하기에는 무리가 있었을 것이다. 이러한 문제가 있었지만 김철수님은 나름의 노하우를 익히셨고 다음과 같이 공개해 주셨다.

하나, 사이트맵 대신 모듈맵을 만든다.

둘, 모듈 단위로 HTML을 작성한다.

셋, 최종사용자의 UX를 먼저 확정한 뒤 서버 프로그램을 시작한다.

넷, 텍스트 기반으로 먼저 만들고 나중에 세세한 디자인 요소를 삽입한다.

다섯, 위키 방식으로 모두가 개발 소스에 접근하여 수정할 수 있도록 한다.

자세한 설명은 김철수님 블로그에서 직접 확인해 볼 수 있는데, 간단히 코멘트를 하자면 전체 프로세스를 모듈화 하는 것이 중요해 보인다. 과거처럼 거대한 프로젝트를 수백장의 스토리보드에 다 담아 내는 것이 아니라, 기능별로 모듈화된 페이지를 고려하고, 그에 맞는 명세서나 차트를 만들어 개발자와 디자이너에게 전달한다. 그리고 텍스트 기반(XHTML 마크업)의 프로토탑입 설계를 함께 진행하여 디자인 이후에 있을 오류를 최소회 시켜야 한다. 또한, 개발 팀원간의 소통을 위한 도구로 '위키(wiki, 누구나 접근하여 쓰고, 지우고, 수정할 수 있는 시스템)'를 제안하고 있다. 제 의견으로는 'Trac' 의 사용을 추천해 드립니다.'Trac'는 '위키'시스템과 '포럼' 형태를 모두 가지고 있고, 버전관리와 연동이 되기 때문에 프로젝트 게시판으로 사용하기 좋은것 같습니다.


개량형 '웹퍼블리셔 중심의 웹 표준 개발 프로세스'


위 표는 '실전 웹 표준 가이드'와 김철수님의 후기를 읽은 뒤에 살짝 고민을 덧붙여 변형을 가해 본 것이다. 가이드에서도 밝혔고, 나 역시 미리 밝혀두는 것이지만 이러한 웹 표준 프로세스라는 것이 아직은 정형화 되어 있지 못하고, 객관적인 장단점이 불분명한 상태이다. 따라서 프로젝트의 성공 여부를 보장해주지 못한다. 다만, 웹 표준을 준수하는 웹 개발을 할라치면 이러한 고민과 적용이 필요하지 않을까 해서 시작된 것이고, 이렇게 나의 의견까지 덧붙이게 된 것이다.

'개량형'이라고는 했지만 '실전 웹 표준 가이드'에서 소개하는 내용과 크게 다르지는 않다. 용어가 일부 변경('코딩' 보다는 '마크업'이라는 용어로, 일부는 김철수님의이 제안하신 것)되었고, 프로세스가 약간은 더 복잡해졌다고 볼 수 있다. (없던 화살표가 생겼다!) 풀어서 서술하자면 다음과 같다.

  • 기획자 : 기획자는 '실전 웹 표준 가이드'에서 제안하는 것과 같이 기획문서를 '프로세스 플로우'와 '컨텐츠 상세화'로 구분하여 작성한다. 차이가 있다면 '프로세스 플로우'와 함께 게시판이나 회원가입/로그인과 같이 모듈화가 가능한 것들에 대한 모듈 명세서 또는 모듈 맵이 함께 작성된다. 그리고 이것은 개발자에게 전달되어 프로젝트 전반에 대한 설계와 프레임 개별 모듈에 대한 설계를 할 수 있도록 한다.
  • 디자이너 : 디자이너는 기획/분석 단계에서 만들어진 아이디어를 통해 시안과 스타일 가이드(문서 또는 준하는 이미지 파일)를 만듭니다. 그리고 기획자의 컨텐츠 상세화 문서(기존의 스토리보드로 생각하면 쉬울것 같다)를 받아 화면 디자인을 시작한다. 여기서 완성된 스토리보드를 가지고 시안을 만들지 않는다는 것은 중요합니다. '실전 웹표준 가이드'나 김철수님이 지적했듯이 상세한 스토리보드는 디자이너의 창의력을 둘러싸는 장벽이 될 위험요소가 있습니다. 때문에 기획/분석 단계에서 나온 아이디어나 컨셉 등 필요한 만큼의 적은 정보만으로 시안을 잡아 디자이너로 하여금 충분히 창의력을 발휘할 수 있도록 해야 합니다.
  • 개발자 : 개발자는 기획/분석 단계에서 나온 아이디어와 컨셉을 통해 기술적 이슈(HTML문서의 DTD, 인코딩, 폼 영역의 ID값 등)에 대한 개발 가이드를 작성하여 퍼블리셔에게 전달합니다. 그리고 기획자로부터 '프로세스 플로우'와 '모듈 맵'을 전달받아 시스템 설계와 모듈 단위의 개발 준비를 시작합니다. 이후 퍼블리셔로부터 마크업이 완료된 XHTML문서를 받아 프로그래밍과 디버깅 작업을 진행합니다.
  • 퍼블리셔 : 퍼블리셔는 기획자로부터 '컨텐츠 상세화 문서' 또는 '페이지 명세서'를 받아 XHTML 마크업을 시작합니다. 이때 개발자로부터 받은 '개발 가이드'를 바탕으로 XHTML 문서의 Doctype 설정, 인코딩 설정, 공통  ID값 등을 결정하거나 적절치 않을시 재논의하여 적용하도록 합니다.(한 번 결정된 Doctype이나 인코딩은 개발 과정에 쉽게 바꾸기가 어려우므로 반드시 확실히 결정을 하고 넘어가도록 합니다.) XHTML 마크업이 완료되면 개발자에게 전달하여 프로그래밍이 진행될 수 있도록 합니다. 이후 디자이너로부터 받은 '스타일 가이드'와 '화면 디자인(PSD 파일)'을 통해 XHTML 문서에 CSS 디자인을 시작합니다. 다음으로 개발자와 소통하며 완료된 페이지를 '퍼블리싱'하면서 CSS 오류 등을 잡아내는 '디버깅' 작업을 진행합니다. 마지막으로 기획자와 함께 '표준화 준수 확인'작업을 하게 되는데 '실전 웹 표준 가이드'에서는 이를 퍼블리셔의 역활로 두었으나 제 경험상 '내가 작업한 것을 내가 테스트 하는 것은 실효성이 적다'였습니다. 다시말해 내 실수를 내가 찾아내는게 쉽지 않았다라는 겁니다. 프로세스대로 디자이너와 개발자가 표준에 맞춘 일정을 따라주었다면 최종적으로 퍼블리셔의 웹 표준 기술(XHTML, CSS, DOM, JS 등)에 의한 크로스 브라우징과 접근성 문제 등이 주요 이슈로 나타날 수 있는데 이를 퍼블리셔 스스로 검증하기란 쉽지 않습니다. 따라서 애초에 기획자에게 책임을 지우는 것이 좋다는 생각을 해봤습니다. 그리고 단계적으로는 최종 단계이긴 하나 기획자는 프로젝트가 진행되는 가운데 지속적으로 디자이너와 개발자, 퍼블리셔가 표준을 준수하고 있는지를 검증해야 합니다.

특별히 부연 설명을 드리고 싶은 것은 위 표에서도 나타나 있듯이 양쪽화살표로 되어 있는 굵은 선 프로세스들입니다. 퍼블리셔를 중심으로 기획자와 퍼블리셔, 디자이너와 퍼블리셔, 개발와 퍼블리셔가 지속적으로 커뮤니케이션을 이루도록 되어 있습니다. 또 한가지 기획자와 퍼블리셔가 같은 색 영역으로 묶여 있음을 보실 수 있습니다.

김철수님도 쓰셨듯이 웹 표준 개발 프로세스에서 기획자와 퍼블리셔의 협력은 굉장히 중요해 보입니다. 1차적으로 과거의 스토리보드가 세부화된 개별 문서와 XHTML 문서로 만들어집니다. 이렇게 만들어진 XHTML문서는 디자인이 입혀지기 전에 1차적으로 프로세스 테스팅을 가질 수 있다는 장점이 있습니다. 일종의 프로토타입을 만드는 것입니다. 버튼이 빠져 있거나 페이지가 잘못 연결되어 있거나 추가되는 페이지등을 사전에 고려하여 디자인 이후에 생길 수 있는 추가 작업을 줄일 수 있습니다.

디자이너가 CSS를 다루지 않는 것도 김철수님의 경우와 다릅니다. HTML이나 CSS도 모르면서 웹을 어떻게 하냐는 소리를 하곤 했지만 사실 웹디자이너에게 전문적인 수준의 XHTML과 CSS를 강요할수만은 없다고 생각합니다. (현실적으로 불가능에 가깝습니다.) 때문에 CSS 디자인 역시 퍼블리셔의 영역 안에서 해결해야 한다고 생각합니다. 실제로도 대부분의 퍼블리셔들이 시멘틱한 마크업과 CSS 작성은 자신들의 영역이라고 생각하면서 공부하고 있습니다.

아울러 개발자들이 텍스트로만 이루어진 XHTML 문서를 통한 개발에 적응할 수 있어야 한다고 봅니다. 개발 영역에서는 MVC모델이라는 것이 확실히 자리잡고 있지만 아직도 많은 경우에 XHTML문서 내에 직접 프로그래밍을 입히는 경우가 많습니다. 이 경우 XHTML문서와 서버측 스크립트 언어, CSS 등이 뒤섞여 유지보수가 매우 어려워질 수 있고, 위의 개발 프로세스도 적용하기 힘들 수 있습니다.

저는 가능하면 현재의 프로세스(Waterfall) 에서 크게 변형을 가하고 싶지는 않았습니다. 갑작스러운 변화는 오히려 효율성 측면에서 마이너스 효과를 가져올 수 있기 때문입니다. 따라서 위 표를 보면 초록색 프로세스를 중심으로 기획자는 기획문서를 만들어서 개발자와 디자이너에게 주고, 디자이너는 퍼블리셔에게 PSD를 주고, 퍼블리셔는 마크업이 완료된 XHTML문서를 건네게끔 되어 있습니다. 이는 기존의 프로세스와 크게 다르지 않습니다. 그러면서도 상호간의 커뮤니티를 강조하고 있고, 전문적인 웹퍼블리셔의 인력 확보에 포커스를 두고자 합니다.(이 부분은 구인이든 교육이든 사내에서 해결을 해야할 것으로 보임) 따라서 디자이너가 어렵게 CSS를 다루지 않아도 되고, 개발자 역시 초기 단계에서 문제가 될 만한 것들을 퍼블리셔와 미리 확실하게 집고 넘어가는 과정을 필수적으로 포함시킴으로써 개발 후에 생길 문제를 최소화 하는데 신경을 썼습니다.

지금까지 웹 표준화 프로젝트를 위한 '웹 표준 개발 프로세스'를 고민해 보았습니다. '실전 웹 표준 가이드'의 제안과 김철수님의 '표준 스토리보드 구상기'는 이미 충분히 좋은 자료가 되고 있습니다. 여기에 저의 부족한 경험과 고민을 덧붙여 약간 변형된 모습까지를 보여드렸습니다. 이미 더 좋은 방법으로 프로젝트를 진행하고 계실 분들도 계실 것이고, 더 나은 생각을 가지신 분들도 계실텐데 저에게 지적과 함께 좋은 의견을 주셨으면 감사하겠습니다.

'개발도 하냐?' 카테고리의 다른 글

산출물관리지침(한국전산원)  (0) 2008.10.11
PLT 6 마르미 III 개발 방법론  (0) 2008.10.11
웹표준 준수사항 몇가지  (0) 2008.10.01
검색결과의 Visualization  (0) 2008.09.24
FLEX  (0) 2008.09.22
웹표준 준수사항 몇가지
조건 :  HTML 4.01 Transitional

1) 자바스크립트 지시자나 스타일시트 지시자에 타입정보가 꼭 필요하다.
<script language="JavaScript" type="text/javascript">
<style type="text/css" >

2) img,  map 태그등에 모두 alt 속성이 필요하다.

3) td는 background 속성을 지원하지 않으므로 스타일 시트형태로 표현한다.
<td style="background-image:url('/img/img.gif');"></td>

4) table은 height 속성을 지원하지 않는다.
<table height="100%"> <-- 에러

5) tr은 colspan, height 속성을 지원하지 않는다.
<tr height="30" colspan="2"> <-- 에러

6) body태그는 2개이상있으면 안된다.
body에 onLoad때문이라면 body태그대신
<script language="JavaScript" type="text/javascript">
window.onload = funcName(arg1,arg2);
</script>
형식으로 한다.

7) 스타일시트 font-family 에 한글 parsing이 안되는 문제가 있다
font-family:돋움 의경우 font-family:Dotum 으로 변경한다.

8) 스타일시트 선언은 <head> 안에서 해줘야한다. <body> 안에서 선언하면 에러 -_-
<head>
<link href="./style.css" rel=stylesheet type='text/css'>
</head>

9) html 안에 bgcolor나 width,height값을 %단위로 속성 삽입시 코텐션빠지면 에러
<td height="1" colspan="2" bgcolor="#ffffff"></td>
<table width="100%">
위와같이 "" 또는 '' 로 감싸줘야한다.

10) form 태그가 table 안에 있으면 에러 table을 감싸고 있어야한다. table 안에 있으면 에러
<form>
<table><tr><td></td></tr></table>
</form>
또한 form태그안에는 name속성과 action 속성이 모두 존재해야한다.
<map 태그역시 table 바깥에 위치해야함

11) 이미지서브밋에 width, height, border 속성을 쓰면 에러.
<input type="image" src="images/button_search.gif" align="bottom">
위와같이 align 속성은 쓸수 있음

13) url 쿼리스트링의 경우 & 기호는 다음과같이 인코드해주어야한다.
& + amp; (html 에디터에서는 안보이네요 -_-)
& a m p ; (띄어쓰기 붙혀서..)
<a href="/dir/file.php?id=111& a m p ;pwd=222">xxxxxxxx</a>

14) img태그나 기타 태그 속성중에 align="absmiddle" 는 비표준 middle 로 수정

15) 스타일을 표현할때 width, height 값에 px 안붙이면 에러, 색상코드에 # 안붙이면 에러
style="width:10px;height:20px;#FFFFFF;"

16) hidden 태그경우 <table 안에 들어있으면 에러.. 즉 form 안에 table 밖에 위치
즉 form태그 안에 table태그 밖에 위치해야함

17) body태그에 leftmargin="0" topmargin="0" marginwidth="0" marginheight="0" 부분 있으면 에러
style="margin:0px;" 형태로 바꿔준다.

18) 자바스크립트 변수에 html 닫힘태그 쓸때는 escape문자로 표현한다.
<a href='url'>url<\/a>

19) 플래쉬 삽입
<object type="application/x-shockwave-flash" data="<?=$IndexImg?>/index_main.swf" width="260" height="487">
    <param name="movie" value="<?=$IndexImg?>/index_main.swf">
    <param name="quality" value="high">
</object>
플래쉬 태그에 classid나 codebase를 쓰면 에러. 다만 js형태로 밖으로 빼놓으면 에러 못찾음 -_-;;

20) 주석에 + 기호달면 에러
<!-- ----------- + ---------------- -->
위의 형태 에러남..

21) DocType를 페이지 맨상단(html태그 밖)에 정의해야함
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

22) TEXT-DECORATION 의 스타일 표현형태
TEXT-DECORATION: none
TEXT-DECORATION: yes(x) -> TEXT-DECORATION: underline

'개발도 하냐?' 카테고리의 다른 글

PLT 6 마르미 III 개발 방법론  (0) 2008.10.11
웹표준준수 실무개발 방법론  (0) 2008.10.01
검색결과의 Visualization  (0) 2008.09.24
FLEX  (0) 2008.09.22
CSS 레이아웃기초  (1) 2008.02.02

+ Recent posts

티스토리툴바