오픈비 : 삽질은없다

정보시스템 개발 방법론에 따른 산출물 관리 지침

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

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

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

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

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

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

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

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

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

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

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

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

   실전 웹 표준 가이드 p191

    
   이 될 것이고, 디자이너 중심의 프로세스는
   
   

   실전 웹 표준 가이드 p189

   
   이 됩니다. 프로그래머 중심의중심의 프로세스 역시
   
   

   실전 웹 표준 가이드 p190

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

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

보기엔 상당히 복잡해 보이지만 단순히 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차적으로1차적으로 과거의 스토리보드가 세부화된 개별 문서와 XHTML 문서로 만들어집니다. 이렇게 만들어진 XHTML문서는XHTML문서는 디자인이 입혀지기 전에 1차적으로 프로세스 테스팅을 가질 수 있다는 장점이 있습니다.있습니다. 일종의 프로토타입을 만드는 것입니다. 버튼이 빠져 있거나 페이지가 잘못 연결되어연결되어 있거나 추가되는 페이지등을 사전에 고려하여 디자인 이후에 생길 수 있는 추가추가 작업을 줄일 수 있습니다.

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

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

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

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

웹표준 준수사항 몇가지
조건 :  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

Web 2.0과 엔터프라이즈 시장의 변화와 맞물려 검색 시장 또한 사용자 변화 욕구에 발 맞춰 빠르고 새롭게 진화하게 된다.
현 재 검색 서비스는 제 3세대까지 알려져 있는데, 이들 중 야후와 알타비스타 같이 웹페이지 콘텐츠를 단순 링크하거나 키워드 기반의 검색을 제공하는 인터넷 초창기의 검색을 제1세대 검색으로 분류한다. 이 시기는 정보검색이 키워드 기반 방식으로 접근하여 검색 결과의 정확도와 신뢰도가 낮았다.
이를 보완하기 위해 웹 페이지에 링크된 횟수가 높으면 신뢰도와 정확도 역시 높을 수 있다는 Link Analysis방식의 Page Rank 알고리즘이 등장하게 되었고, 구글은 이 Page Rank 알고리즘을 기반으로 서비스를 시작하게 되었다. 이 시기를 제 2세대 검색이라고 부른다.

그러나 재현율과 정확률에 초점을 둔 새로운 세대의 검색 서비스 출연에도 불구하고 정보의 홍수 속에 사용자는 수많은 garbage data 속에서 원하는 정보를 다시 한번 찾아야 하는 수고를 더해야만 했다. 이를 해결하기 위해 검색업체는 새로운 정보검색 서비스를 시도하게 되었다. 이러한 과정에서 Web2.0 이라는 새로운 트렌드가 등장하며 검색은 사용자 관점에서 UI강화, 문서의 분류와 군집, 지능형, 개인화, 전문검색 등의 형태의 다양한 서비스들이 나타나게 되었다. 이를 ‘검색의 혁명’, 제 3세대 검색 혹은 Search 2.0의 시대라고 부른다.

Search 2.0은 참여와 공유, 분배 기반의 Web2.0과 텍스트 마이닝, 시맨틱 웹 기술이 융합되고, 빠르게 변화하는 비즈니스 환경에 대한 대안으로 부상하고 있는 엔터프라이즈 시장에 적극 대응, SOA(Service Oriented Architecture)의 환경을 지원하며 소프트웨어의 새로운 유통방식이라 할 수 있는 SaaS(Software as a Service) 비즈니스 모델로도 확장하고 있다.

Web 2.0의 RIA, AJAX 등의 기술이 사용자 경험을 향상 시키는 동안 기존 검색기술은 이러한 Web 2.0 트랜드에 대해 대응력 부재를 보이며, 아래와 같은 다양한 문제를 제기하게 되었다.

• 너무 많은 검색의 결과에 대한 가공을 통한 접근성이 떨어짐
• 콘텐츠의 다양화 (UCC, 블로그 등)에 대한 특화되지 못한 검색
• 콘텐츠에서 사용자가 필요로 하는 정보를 추출하지 못함
• 사용자의 경험을 검색에 반영하지 못함
• 누가 검색해도 동일한 검색 결과가 나오는 특화되지 못한 검색
• 개방을 위한 검색과 다른 서비스간 Open API 등을 통한 매시업 연동이 불가함
• 플랫폼으로서의 Web을 지원하기 위한 검색 플랫폼화가 지원 안됨

위와 같은 기존 검색의 문제점으로 인하여, 참여, 공유, 개방의 Web 2.0 환경에서 Search 2.0의 주요 기능들이 새로운 이슈로써 그 중요성이 더욱 증가시키는 계기가 되게 된다.

Search 2.0의 대두

시장 패러다임의 변화와 맞물려 전개된 Web2.0과 엔터프라이즈시장의 환경 변화는 새로운 고객 관점의 요구를 생성하게 되고, 이는 기존 검색 시스템의 새로운 트렌드를 못 좇아가는 기술적 한계성을 더욱 부각시킨다.
특 히 맥아피 교수가 언급한 기업 지식 경영 패러다임으로 가기 위한 6가지 구성요소(SLATES) 중 핵심요소인 ‘Search’는 Web 2.0의 기본 개념과 Enterprise 2.0 관점에서 그 무엇보다 중요한 역할을 차지하고 있기에 Search 2.0의 전면으로의 등장을 더욱 빠르게 전개되게 된다.

또한 대부분의 이용자가 찾는 검색결과와는 다른 ‘너무나 많은’ 정보를 늘어놓는 대다수의 검색 엔진의 불필요한 정보 범람의 난제에 Search 2.0을 전면에 내세운 신규 업체들이 새롭게 도전장을 내밀고 있다.
이 들은 검색어가 들어 있기만 하면 무조건 뽑아다가 나열하는 종래의 단순하고 무분별한 검색 방식에 질서를 부여하고자 한다. 검색된 결과를 순식간에 자동으로 분석해 범주별로 정리해 보여줌으로써 굳이 개별 결과를 일일이 뒤져보지 않아도 필요한 정보를 쉽게 찾을 수 있게 해준다는 개념이다.

의미기반 검색의 경우 Hakia, Powerset은 검색자들이 입력한 질문을 이해해 의미 기반의 검색을 수행할 수 있다. 실제 상대적으로 복잡한 질문에 대해 구글보다 뛰어난 검색 결과를 제공한다. 특히 의약품·법률·재무·과학·문학 같은 집약적 주제 검색에 뛰어나다. 사용자 참여 형태인 Rollyo, Swicki, Del.cio.us는 검색롤이나 북마크 등을 이용자가 서로 공유할 고 사용 할 수 있도록 서비스를 제공하고 있다.

또 한 클러스터링을 특징으로 두고 있는 Vivismo와 Ask는 검색 결과를 언어 및 통계 분석에 근거해 즉각 새로운 범주들로 나누는 검색 기능을 제공하고 있다. 이와 함께 Yahoo Mindset, Collarity 등은 Intent-Driven(사용자 의도 파악)방식과 개인화 검색을 통해 Search 2.0의 선도적인 역할을 수행하고 있다.

위의 사례에서 볼 수 있듯 Search 2.0은 기존 정보검색의 강화된 기능과 텍스트 마이닝, 시맨틱 기술이 복합적으로 적용되어 사용자 참여, 사용자 검색의도 파악, 검색결과의 자동군집, 자동분류, 개인화의 기능을 지원한다. 이러한 검색의 새로운 트렌드는 현재 급변하는 Web 2.0 패러다임과 IT환경에 효과적 대응이 가능하며, 기업 환경의 변화인 Enterprise 2.0의 환경에 적용이 가능하다.


Search 2.0 서비스 기준

Search 2.0에서 서비스의 기준은 첫 번째, 사용자를 위한 관련 콘텐츠에 대한 발견성(Findability)을 높여야 한다. 이는 곧 검색이라는 원초적인 기능과 맞물려 그것을 어떻게 실행하느냐에 중점을 둘 수 있다. 즉 일반적인 정보의 노출이라는 검색 초점에서 벗어나 숨겨진 사용자의도에 따른 진정한 검색 Findability를 보다 쉽게 제공한다는 의미를 두고 있다.
두 번째, 웹 전체 혹은 큰 서브넷에 해당하는 양의 데이터를 검색할 수 있어야 한다. 검색의 결과도 중요하지만 검색을 할 수 있는 범위의 제한을 두지 말아야 한다.
세 번째, 키워드, 구, 질의문, 패러미터 등의 다양한 입력방식으로 검색이 가능해야 한다. 즉, 사용자는 어떤 방식으로도 검색의 접근성을 보장받아야 하는 것이다.
네 번째, 검색의 대상이 되는 콘텐츠를 사용자에 맞춰 가공 및 사용되어야 한다.
다섯 번째, 사용자 요청 시 검색결과를 즉시 제공하여야 한다. 즉, 모든 검색 대상이 되는 콘텐츠는 사용자 중심이다.
여섯 번째, 사용자 참여에 의한 향상된 랭킹, 검색 결과에 대한 향상된 UI등을 제공하여야 한다.

Web 2.0 관점에 입각한 사용자 참여 및 사용자 경험 중시의 구조는 Search 2.0에서도 중요한 서비스 기준 인 것이다. 위에서 언급 한 바와 같이 Web 2.0은 참여, 공유, 개방의 핵심 키워드로 웹의 패러다임을 바꿔나갔다. 이에 Web 2.0에서의 검색은 3S(Store, Search, Sort)에서 4S+1D(3S+Share+Discoverry)로의 Search 2.0 패러다임으로 바뀌게 된다.

곧, 검색이라는 기능이 전면에 중요하게 부각되면서 새로운 서비스로의 환경을 만들고 있는 것이다. 따라서, 사용자 참여 랭킹, 개인화, 플랫폼화, Open API/매시업 등 다양한 Web2.0 요소는 Search 2.0에 담겨 표현되고 있다. 향후 Search 2.0은 Web 2.0 패러다임과 함께 질의전처리, 정보소스의 가공 등을 통한 다양화, 검색 알고리즘의 개선, 혁신적 검색 UI의 적용 등을 통해 발전해 나갈 것으로 예상된다.

Enterprise 2.0 등장

참 여, 공유에 기반한 고객, 시장의 집단 지성은 폐쇄적 기업 조직을 개방적, 창의적인 유연한 조직으로 변화하도록 요구하게 되었다. 이를 바탕으로 하버드대 맥아피교수는 새로운 개념을 제창하게 되는 데 이것이 바로 엔터프라이즈 2.0이다.
엔터프라이즈 2.0은 기업 내부 또는 기업 대 기업 간에 사용되는 새로운 사회적 소프트웨어 플랫폼이라고 정의할 수 있다. 즉, 2.0의 구성요소인 문화, 프로세스, 기술이 기업 내/외부에서 유기적으로 결합하여 새로운 기회를 넘어서는 새로운 가치를 창출하는 것이라고 설명할 수 있다.
이에, 엔터프라이즈 2.0은 SOA, SaaS, Ajax 등, 신기술의 사용과 더불어, 웹 2.0의 핵심도구 중 하나인 소셜미디어와 위키, RSS 등을 이용, 새로운 기업 지식 경영 패러다임으로 가기 위해서는 6가지 구성요소(SLATES)가 필요하였다. 그것이 바로 검색(Search), 연결(Links), 제작(Authoring), 태그(Tags), 확장성(Extension), 신호(Signals) 등이라 할 수 있다.

위와 같이 기존 기업의 비즈니스 목표 달성을 위해 탑다운 방식의 서비스 시스템 구현과 의무적인 참여가 강요되던 기업용 SW환경도 개개인의 자발적인 참여와 공유를 통해 새로운 가치를 창출하는 환경으로 변화하고 있다.
그 대표적인 예가 위에 언급되었던 엔터프라이즈 2.0으로 국내에서는 이제 막 관련 논의가 시작됐지만, 이미 엔터프라이즈 2.0은 세계 주요 IT전문 블로거들이 선호하는 핵심 키워드로 자리잡은 상태다.
엔터프라이즈 2.0은 웹 2.0과 매우 깊은 관련이 있다. 쉽게 풀어서 이야기하자면 “웹 2.0처럼 뭔가 변화가 분명히 발생하고 있는데 그런 것이 기업 솔루션이나 기업 내부 서비스에도 어떤 영향을 끼치지 않을까?”라는 것이다.

즉, 블로그나 위키에서는 이용자가 자유롭게 기사나 메시지, 워크파일을 소프트웨어상에 작성해 늘어놓는 것으로 보고서를 작성하기까지의 프로세스를 가시화할 수 있다. 이와 같이 엔터프라이즈 2.0을 실현하기 위한 플랫폼에서는 종래의 소프트웨어에서 실현이 어려웠던 요건을 웹 2.0으로 활용되고 있는 기술군에 의해 실현하려 한다.
MS의 쉐어포인트(SharePoint)나 IBM의 엔터프라이즈 위키 등, 주요 기업 소프트웨어 벤더에서는 위키나 소셜 북마크 기능을 구비한 그룹웨어나 포털 소프트웨어 등을 올해 안에 발표할 예정이다.

엔 터프라이즈 2.0으로 실현되는 소셜 소프트웨어상 협업의 내용은 극히 인간 중심적인 작업들이다. 게다가 이것들은 기업내외에 존재하는 다양한 이해관계자와의 관계나 작업 프로세스의 과정이 축적되어 있다. 만약 그 연속성이나 관련성이 가시화될 수 있다면 생산성이나 혁신성을 촉진시키는 큰 비즈니스 기회를 기대할 수 있을 것이다.
즉, 기업 내 뿐만이 아니라 고객이나 협력업체간 커뮤니케이션 및 협업을 실현시킬 수 있다면 웹 2.0에도 뒤떨어지지 않는 가치를 얻을 수 있을 것임에 틀림없다. 이에, SOA(Service Oriented Architecture)와 SaaS(Software as a Service)라는 새로운 IT기업 환경의 등장은 엔터프라이즈 2.0 시장의 중심을 이루며 더욱더 발전된 IT 비즈니스 미래를 제시할 것으로 예상된다.


SOA와 SaaS의 등장

기업이 비즈니스 유연성을 확보함으로써 외부 변화에 반응, 빠르게 비즈니스를 바꿀 수 있도록 하는 On-Demand 비즈니스를 구현하기 위해서는 IT시스템의 유연성이 필수적이다.
SOA 는 On-Demand 운영 환경에서 비즈니스 유연성을 가능하게 하는 인프라스트럭처를 제공하는 환경이다. SOA를 적용하여 기업은 비즈니스 환경 변화에 유연하게 대응할 수 있는 시스템을 구축할 수 있고 이를 통해 경쟁력을 높일 수가 있게 되었다. 하지만 기존 IT시스템만으로 이러한 비즈니스 유연성을 만족시키기가 쉽지 않다. 과거와는 달리 요즘의 비즈니스 환경 변화는 기존 IT시스템이 그 변화를 따라가기 어려울 정도로 빠르기 때문에, 기존 IT시스템을 얼마나 유연하게 만들 수 있느냐가 관건이라 할 수 있다.
따라서 전통적인 IT시스템과는 다른 패러다임이 필요하고 이러한 필요사항에서 나온 것이 서비스 지향 아키텍처(Service Oriented Architecture)이다.

즉, SOA는 엔터프라이즈 애플리케이션에 포함된 개별적인 기능들을 동적인 비즈니스 요구 사항에 따라 신속하게 조립 및 재사용할 수 있는 상호 운영이 가능한 표준 기반 서비스로 구성하는 IT전략이다.
애 플리케이션 중심이 아니라 서비스 중심으로 엔터프라이즈 IT를 구성함으로써 SOA를 도용한 각 업체들은 위 그림과 같은 주요 이점을 오늘날 경험하고 있으며, 비즈니스 기회를 극대화하기 위해 새롭고 향상된 서비스를 신속하게 개발, 신뢰할 수 있는 방법으로 전달하고자 서비스 지향 아키텍처(Service Oriented Architecture)를 채택하는 추세다.

지금까지 라이선스, 배급 방법, 파트너에 따라 CD-ROM 형태로 다양하게 구분됐던 소프트웨어 비즈니스 모델이 ‘SaaS(Software As A Service)’의 등장으로 인해 급속도로 변화하고 있다.

‘SaaS’ 는 일반(제품 중심적) 소프트웨어 비즈니스 모델과는 달리 서비스 형태로 제동되는 시스템의 최근 SW업계에서 주목받고 있는 새로운 트렌드다. 요컨대 서버의 컴퓨터상에 소프트웨어를 설치해 두고 사용자는 웹 브라우저를 통해 사용한 만큼 비용을 지불하고 소프트웨어를 서비스로 이용하는 방식이 SaaS다.

위 내용을 한마디로 정의하자면, ‘SaaS는 트랜잭션 기반의 SaaS모델로서 트랜잭션이 발생한 만큼의 비용만 지불하면 되는 종량제식의 서비스’라고 정의 내릴 수 있다. 이에, 최근 불고있는 웹 2.0 바람과 SaaS의 연계성을 고려했을 때 밀접한 관계를 가지고 있으며 앞으로 웹은 해결하는 솔루션이 아닌 솔루션과 솔루션이 조화를 이루는 애플리케이션 위주로 흘러갈 것이다.

이는 가트너의 전망 ‘2011년엔 새로운 기업용 SW 중 25%가 SaaS로 제공될 것이다’나, 향후 수년간 온 디맨드 고객관계관리(CRM)가 연평균 31% 성장해 2010년에는 전체 CRM 시장의 17%를 차지할 것이라는 IDC의 예측은 SW의 미래를 그려볼 수 있게 하는 대목이라 할 수 있다.

이 미 구글, MS, 세일즈포스닷컴, 오라클 등 세계적 기업들도 기존의 소프트웨어 판매 방식에서 벗어나 웹을 중심으로 새로운 전략을 모색하고 있다. 그리고 이러한 기업들의 움직임에 힘입어 점차 SW산업의 범위와 구조는 웹을 중심으로 더 빠르게 확대, 재편될 것으로 전망된다.


엔터프라이즈 시장에서의 Search 2.0

SOA 와 SaaS 시스템의 새로운 등장과 함께 기업에서도 Web 2.0 개념을 도입하여 인터넷 검색 만족도에 버금가는 검색시스템을 구축하려는 욕구가 증가하게 된다. 이는 웹2.0의 주요 개념인 개방, 공유, 참여와 SOA기반의 검색 플랫폼을 통하여 정보 검색, 정보 탐색, 복합 애플리케이션(매쉬업)을 통합하고 경제성과 생산성을 보장하려는 시도로 이어지고 있는데, 그 특징은 아래 같다.

• 다양한 서비스를 지원하는 환경
• 파워풀한 UI 구현 및 서비스
• 숨어 있는 지식정보의 재발견
• 정확하고 신뢰성 있는 검색결과
• 확장성, 유연성 제공
• 높은 경제성, 생산성 달성
• 플랫폼 기반으로 기업이 원하는 다양한 서비스 제공
• 다양하고 화려한 시각화에 의한 사용자 경험과 직관적인 접근
• 가치와 의미있는 정보에 대해서 다양한 접근방법을 통해 정보의 재조명, 재창조 기회 및 공유와 협업 가능하도록 도움
• 임직원/고객의 정보와 참여를 통한 사용자의 검색의도 파악, 의미처리 검색으로 고품질 검색결과를 얻음
• 급변하는 비즈니스 환경에 기업 내외부의 다양한 서비스와의 연결 및 통합(매쉬업)
• 검색 호스팅 및 밸류 애딩을 통한 스위칭 코스트/ 구축일정 단축으로 높은 생산성 달성
  

위와 같이 Enterprise Search 2.0은 급변하는 비즈니스 환경 속에서 다양하게 요구되는 고품질 검색 서비스를 높은 생산성과 경제성을 가지고 제공하는 플랫폼기반의 검색서비스라 정의할 수 있다. 여기서 말하는 플랫폼 기반이란 다양한 콘텐츠(데이터)와 서비스들로부터 정보 검색, 정보 탐색, 매쉬업 등과 같은 검색관련 서비스를 적은 비용으로 빠르게 해 줄 수 있는 개발/운용체계를 말하며 이는 여러 다양한 IT 사업 솔루션과 연동하여 언제 어디서든 최고의 고객 가치를 가져다 줄 것이다.

해외 Search 2.0 사례와 Web 2.0 패러다임을 토대로 한 기업 환경의 변화에서도 알 수 있듯 사용자 관점의 신개념 검색 기술의 등장은 언제나 IT 시장의 이슈로 존재하고 있었다.

Search 2.0 플랫폼을 한마디로 정리하자면, ‘서비스 지향 지능형 검색 플랫폼’이라 할 수 있다. 즉, ‘서비스로서의 검색(Search as a Service)’, ‘지능형 검색(Intelligent Search)’, ‘플랫폼으로서의 검색(Search as a Platform)’, 이 3가지 핵심 기능을 중심으로 사용자에게 최대한의 효과를 줄 수 있는 신개념 검색 플랫폼인 것이다.

검색결과

검색결과는 사용자의 질의에 대한 검색엔진의 결과이다. 보통 랭킹알고리즘의 적용결과를 반영하여 순서대로 보여주고, 검색대상이나 형태에 따라 탭이나 그룹핑하여 보여주는, 요즘 말하는 통합검색 또는 Universal Search라고 하는 것이 검색결과의 일반적인 모습이다.

사용자들은 질의어를 입력하기 전 제공하는 다양한 옵션에 비하여 검색결과를 어떤 순서로 어떻게 보여주는가에 따라서 검색엔진이 좋다 나쁘다를 말하는 경우가 많다.

오늘 이야기 하고 싶은 것은 , 검색결과의 Visualization에 대한 이야기이다.


AMAZNODE : Amazon related Product Search


http://amaznode.fladdict.net/

이 검색서비스는 검색결과가 플래쉬로 만들었다. 왜 이 검색을 Related Product Search라고 하냐 하면, "customers who bought this item also bought" 짧은 영어실력으로 풀어보면, '이 책을 사신 고객이 사신 책' 즉, 내가 찾는 책을 산 사람과 관련이 있는 플래쉬로 선으로 연결해서 보여주는데, 책 한권 한권이 뿅뿅 올라온다.

검색결과의 연관성을 비주얼하게 보여준다는 아이디어는 매우 독창적이기는 하지만, 사실 연관성이 선으로만 연결되는 직관성이 좀 떨어진다.


Blackdogair.com

 www.blackdogair.com

위에서 소개한 Amaznode 검색서비스와 이 서비스 모두 일종의 매쉬업 검색서비스라고 불러야 할 것 같다. 이 서비스 역시 아마존의 내가 산 것을 산 사람이 산 것에 대한 연관관계를 비주얼하게 보여준다.

하지만, Amaznode 서비스에 비해서 훨씬 직관적이다.


Vivisimo

http://www.vivisimo.com

한때 검색업계의 루키로 한참 각광을 받던 서비스이다. 이 서비스는 소위 검색결과의 Clustering이다. 검색결과를 분석해서 몇가지 주제별로 Clustering한다는 것이 이 서비스의 장점이다.

Clustering이라는게 개념은 쉬어보이지만, 생각보다 복잡한 기술이 필요하고, 아직 국내에서도 상용화되기에는 기술의 완성도가 많이 떨어진다고 한다.

개인적으로 검색결과의 비주얼은 결국 이 Clustering이 기반이 되어야 하지 않나 생각된다. 위에서 언급한 2개의 서비스는 '이 물건을 산 사람이 산 다른 물건'이라는 것은 그룹핑이 되고 있으니..


Kartoo.com

http://kartoo.com

비주얼 메타 서치엔진이라고 말하는 검색서비스이다. 정말 검색엔진 결과의 최고봉이 아닌가 생각된다. 위에서 언급한 검색결과의 주제별 Clustering이 최적화되어 플래쉬로 이미지로 구현되고 있다.

예를 들어 autos.yahoo.com은 담고 있는 컨텐츠의 주제를 보험, 회사, 리뷰, 프라이스 등이 포함되어 있다고 비주얼하게 보여주면서 특정 주제를 선택하면, 주제와 관련된 사이트들이 비주얼하게 선으로 연결되어 보여진다.

국내의 온톨로지 및 검색엔진 회사인 솔트룩스(소금과 빛인가..)에서 Kartoo사의 시각화툴인 Visu를 판매하고 있는데, 검색결과 뿐만 아니라 각종 컨텐츠의 비주얼하게 보여주는데 큰 효과가 있어보인다.

Web 2.0과 Ajax
 

 

Web 2.0을 기술적으로 구현하는데 있어서 가장 많이 눈에 띄는 단어는 Ajax이다. Ajax로 개발 했을 경우 궁극적인 모습은 어떠한 클라이언트 사용자의 브라우저, 운영체제, 디바이스 등에 상관없이 웹상에서 Desktop Application 수준의 application을 이용하는 것이라고 할 수 있다. 이미 Google Map, Yahoo Map 등의 Ajax 레퍼런스 사이트들은 웹 브라우저에서 Desktop Application 수준의 화면과 기능을 구현할 수 있다는 여지를 충분히 보여줬다.

 

Ajax로 구현한 화면을 RIA(Rich Internet Application)라고 달리 말할 수 있는데, 이미 2000년부터 이러한 Desktop Application 수준의 UI를 구현하기 위한 많은 노력이 있어왔고, 현재 X-internet 솔루션이라는 이름으로 여러 벤더에서 제품을 출시했고 시장에서 이미 도입된 상태이다. 그 중 가장 안정적이고 화려한 UI를 자랑하는 제품이 이번에 소개하고자 하는 Adobe Flex이고 Flex의 특징이 무엇이며, Flex로 Web 2.0을 어떻게 구현하였는가도 알아보도록 하겠다.

 

Ajax와 Flex

 

 

Web 2.0에서 중요한 기술적 이슈 중 하나가 Rich Client Application이라는 개념일 것이다. 기존의 Web Application의 편리한 배포, 관리, 저렴한 유지 비용 등의 장점과 Desktop Application 수준의 사용자 편의성, 효율적인 데이터 통신, 견고한 아키텍처 구현 등의 장점을 합친 것이 RIA이라 할 수 있고 Web 2.0을 구현하고 UI에 RIA를 적용하기 위해 Google과 Yahoo에서 도입한 기술이 Ajax와 Flex 등이 있다.

 

Ajax는 차세대 웹 어플리케이션을 위한 최선의 대책이 될 수도 있지만, 아직까지 장점만큼 단점도 많이 존재하는 대안이라 볼 수 있다. Javascript + XML이라는 태생적 한계 때문에 생기는 Javascript가 가지는 언어적 한계와 구현의 복잡성, 웹 브라우저별로 상이한 DOM 핸들링 및 메모리 처리방법으로 인한 호환성 문제, Back/Forward, Bookmark등의 사용자 편의성 문제, Ajax를 이해한 제대로 된 기획안 부재와 Flash 수준의 화려한 UI API 부재 등의 단점으로 Ajax로 선뜻 개발을 주도하기가 쉽지 않은 현실이다. 그래서 Ajax의 여러 가지 문제점을 극복하고 Flash 수준의 화면을 보여주는 RIA를 만들어 Web 2.0을 실현하는 최선의 대안이 Flex 이다.

 

Flex 란?

 

Flex는 앞서 말했듯이 RIA를 구축하기 위한 솔루션으로써 정식 명칭은 Flex Presentation Server이다. 기존의 정적이고 수동적인 웹 환경에서 보다 능동적이고 개방적인 WEB 2.0 기술 구현을 쉽게 해주는 스크립트 언어이다. Flex는 데스크탑의 풍부함과 웹의 광범위함을 접목시킨 리치 인터넷 애플리케이션(Rich Internet Applications)의 UI 개발을 태그 및 스크립트로써 구현할 수 있도록 해주는 최적의 솔루션이다.

 

특히 서버 클라이언트 간에 자유롭게 커뮤니케이션 할 수 있는 개발환경을 통해 XML로써 필요한 데이터만을 적시에 서버로부터 가져오고, 특정 클라이언트가 새로운 데이터를 다른 클라이언트와도 손쉽게 공유함으로써 성능 개선뿐만 아니라 양방향 커뮤니케이션이 주는 WEB 2.0 서비스 개발환경이 되는 것이다.

Flex는 최근 출시된 Flash player 8이 주는 우수한 성능과 파일 접근을 비롯한 자바스크립트 인터페이스 API 등의 다양한 API를 제공함으로써 웹 브라우저 안에서 해결하고 있다. 또한 자바스크립트, AJAX 및 ActiveX와 연동하는 인터페이스 API를 제공하고, 웹 서비스, 자바 빈즈 등의 비즈니스 객체들을 호출할 수 있는 서비스를 제공하여 애플리케이션과 연동을 가능하게 한다.

 

Flex는 Flash 기술로부터 탄생했다. 그래서 Flash나 Flex로 구축된 사이트는 비슷한 UI를 가진다. Flex는 Flash의 컴포넌트들을 XML 태그로 표현할 수 있도록 컴포넌트화 하였다. Flash는 Flash8로써 각종 도형과 컴포넌트들을 마우스로써 디자인하는 반면, Flex는 그런 Flash 컴포넌트들을 XML 태그 스크립트를 이용하여 코딩한다.

 

Flex, 어떤 기술이 적용되어 있나?

 

개발언어 측면에서 플렉스는 XML, ECMAScript, CSS, UTF-8 기술요소를 사용한다.

플렉스의 mxml은 'mx'라는 XML 네임스페이스를 사용하며 XML 문법을 따르며, ECMAScript는 플렉스 액션스크립트가 준수하는 표준으로 자바스크립트와 유사하다. 또한 MXML 스타일은 CSS 문법을 지원하고, MXML 파일은 UTF-8로 작성 및 저장되어 서버에서 처리된다.

서버 서비스 측면에서 DOM 레벨 3 이벤트 모델은 플렉스의 이벤트 모델로 사용되며 DOM 트리 구조를 통해 이벤트를 전달한다. 플렉스 애플리케이션은 HTTP 통신뿐 아니라 XML 통신 프로토콜인 SOAP 메시지로 데이터를 송수신할 수 있다. 이외에 플렉스는 자바 애플리케이션 서버에서 작동되며 플렉스에서 자바빈즈 컴포넌트의 메쏘드를 호출하여 결과를 받을 수 가 있다.

Flex 서버는 어떻게 구성되나?

 

Flex의 구성요소는 모두 국제 표준에 기반한 것으로 ActionScript(Javascript), MXML(XML), DOM3 등의 표준 위에 Adobe의 API와 클래스 라이브러리가 추가된 형태이다.  Javascript의 언어적인 단점을 보안한 ActionScript는 강력한 객체지향 언어로 거듭났을 뿐만 아니라, Flash의 기존 버전에서 검증되었던 강력한 라이브러리들을 Flash보다 훨씬 편리하고 쉽게 이용할 수 있는 길을 제공해 준다.

 

MXML은 요즘 웹 어플리케이션 개발 방법론에 부합하게 XML 태그 형식으로 UI를 구성하게 해주는 훌륭한 도구라 할 수 있다. 또한 Flex는 Flash Player가 동작한다면 운영체제, 브라우저, 디바이스를 가리지 않고 실행되 는 완벽한 유비쿼터스 솔루션이라고 할 수 있다. 즉, 한번의 개발로 ActiveX나 JVM등에 관계없이 IE, Firefox, PDA, 핸드폰, 위성 단말기 등 어디에서든지 인터넷으로 같은 어플리케이션을 공유할 수 있게 해주는 미래지향적인 환경을 제공한다.

Flex 도입의 궁극적인 목표는 화려한 UI와 다양한 기능을 가진 Desktop Application수준의 Web Application을 만들어 내는 것에 있다. 이미 많은 다국적 기업과 국내 대기업에서 Flex를 도입해서 기존에 Clinet/Server 환경 기반에서 사용해 왔던 Install 기반의 Desktop Application을 웹으로 전환을 하고, 또 거기에 따른 많은 비용 절감과 높은 사용자 만족도를 가져올 수 있게 되었다

 

 

** Flex 서버 아키텍쳐

 

 

 

Flex는 어떻게 구동되나?

 

사용자가 플렉스로 구현된 사이트로 접속하면 웹애플리케이션 서버에 설치된 플렉스 서버는 MXML 코드를 SWF(플래시 실행파일)로 컴파일해서 사용자PC에 전송되어 플래시플레이어가 이를 보여준다.

사용자의 플래시플레이어에서 구동되기때문에 사용자는 브라우저에 상관없이 동일한 화면을 보게됩니다. 아래는 플렉시 구동절차에 대해 간략히 표현된 그림이다.

 

 

Flex로 구축하였을 때의 장점은?

 

Flex를 통한 Web 2.0 구현시 장점은 사용자 측면과 개발자 측면에서 살펴볼 수 있다.

사용자 측면에서 플렉스는 기본적으로 제공하는 컴포넌트 외에 플래시 컴포넌트 및 사용자 정의 컴포넌트가 있어 사용자에게 편리한 유저인터페이스를 제공할 뿐만 아니라, 플래시플레이어에서 작동하므로 어떤 환경의 클라이언트더라도 동일한 화면을 볼 수가 있다.

플렉스는 한번 로딩되면 그 다음부터는 서버로부터 실행코드를 받을 필요가 없으므로 실행속도가 빠르며 서버에 부하를 적게 준다. 모든 플렉스 컴포넌트는 화면크기에 맞게 자동으로 사이즈를 조절하므로 해상도에 따라 애플리케이션을 따로 개발할 필요가 없다.

개발자 측면에서 플렉스는 표준을 준수하는 XML태그(mxml)과 액션스크립트로 코딩되므로 html 코딩을 이해하는 수준정도면 쉽게 배울 수 있다. 다양한 유저 인터페이스를 기본 컴포넌트로 제공하므로 개발자의 코딩량이 줄어들어 개발속도를 향상할 수 있고, 다양한 방법으로 컴포넌트를 만들 수 있어 코드재사용성이 높아 개발속도를 향상할 수 있다. 기존 시스템 및 다른 애플리케이션과 연동할 수 있는 다양한 방법을 제공한다.

 

맺음말

 

 

Web 2.0과 Flex에 대해 간략하게 알아보았다. 사실 Web 2.0을 설명하는 부분이 너무 빈약하고 Ajax를 너무 비판적으로 설명했지만, Ajax는 단점보다 장점을 많이 이용해야 하는 것이 바람직한 것이고, 단지 Flex는 그러한 단점까지도 극복하게 해준다는 점을 말씀 드리고 싶다.

 

Web as Platform, 사용자 중심/참여, 개방성, Simple&Lightweight, Decentralized, Long Tail, Blog, RSS, tag, Mashup, Internet Clipboard, 개발자 중심 생태계 등 Web 2.0을 설명하기 위해 담고 싶은 말이 너무나도 많지만 간단히 Adobe Flex를 소개하는 자리인지라 태깅정도의 언급만 하고 유저들이 직접 찾아보는 수고를 기대하고 싶다.

 

 

 

 

 

 

플랙스2 의 기본 사용법

http://j2k.naver.com/j2k_frame.php/korean/livedocs.adobe.com/flex/2_jp/docs/Part1_GetStarted.html

 

플랙스2 유저 가이드

http://j2k.naver.com/j2k_frame.php/korean/livedocs.adobe.com/flex/2_jp/docs/Part6_Using_FB.html

 

플랙스2 래퍼런스

http://j2k.naver.com/j2k_frame.php/korean/livedocs.adobe.com/flex/2_jp/langref/index.html

 

플랙스2 개발가이드

http://j2k.naver.com/j2k_frame.php/korean/livedocs.adobe.com/flex/2_jp/docs/Part2_DevApps.html

 

플랙스2 컴퍼넌트의 작성과 확장

http://j2k.naver.com/j2k_frame.php/korean/livedocs.adobe.com/flex/2_jp/docs/Part3_CreateComps.html

 

플랙스2 어플리케이션의 구축과 데프로이

http://j2k.naver.com/j2k_frame.php/korean/livedocs.adobe.com/flex/2_jp/docs/Part7_Build_Deploy.html

 

Flex Data Service 2 to Java

http://j2k.naver.com/j2k_frame.php/korean/livedocs.adobe.com/flex/2_jp/fds2javadoc/

 

액션스크립트 3.0

http://j2k.naver.com/j2k_frame.php/korean/livedocs.adobe.com/flex/2_jp/docs/Part5_ProgAS.html

 

액션스크립트 2.0 -> 3.0 마이그래이션

http://j2k.naver.com/j2k_frame.php/korean/livedocs.adobe.com/flex/2_jp/langref/migration.html

 

제가 주로 쓰는 방법을 말씀드리자면

먼저 gdb <실행화일> -c <core 화일> 하여 디버거를 실행시킨후
아래와 같이 bt(backtrace)명령어로 어떤 함수를 부르다 죽었는지
확인합니다.

(gdb) bt
#0 0xef663628 in fprintf () from /usr/lib/libc.so.1
#1 0x15b0c in fxRslt (gubun=0x56bf0 "1", from=0x57070 "010305",
    to=0x574f0 "010305", loginid=0x57970 "TEST001")
    at /fxMain/SRC/fxWeb/cgi/rslt.c:50
#2 0x1597c in main (argc=1, argv=0xeffff964)
    at /fxMain/SRC/fxWeb/cgi/fxrslt.c:85
(gdb)

보니까 main->fxRslt->fprintf 하다가 죽었군요. 장소는 rslt.c 에 50번째 줄.
이제 frame 명령어로 해당 스택으로 이동합니다. 이후 list 명령어로
소스파일을 확인해봅니다.

(gdb) frame 1
#1 0x15b0c in fxRslt (gubun=0x56bf0 "1", from=0x57070 "010305",
    to=0x574f0 "010305", loginid=0x57970 "TEST001")
    at /fxMain/SRC/fxWeb/cgi/rslt.c:50
50 fprintf(logfile,"GUBUN:[%c] FROM:[%s] TO:[%s] LOGIN:[%s]\n",
(gdb) list
45 loginid[i] = '\0';
46 strcpy(audit_id, loginid);
47
48
sprintf(logfname,"%s/%s.log",FXRSLT_LOGDIR,RSLT_LOGINIT,loginid);
49 logfile = fopen(logfname, "w");
50 fprintf(logfile,"GUBUN:[%c] FROM:[%s] TO:[%s] LOGIN:[%s]\n",
51 gubun[0],from,to,loginid);
52
53 if (ChkDate(from,to)==0) {
54 fprintf(logfile,"Error in ChkDate\n");
(gdb)

그담엔 print명령어등으로 각 변수값을 조사하여 NULL이 있는지 체크해보면
됩니다.
----------------
[스크랩] Java VM Core Dump 분석   조회(41)
 
java 프로그램 | 2005/01/02 (일) 16:17   공감하기(0)  | 스크랩하기(0) 
 
 

대부분의 문제 발생 원인(리스트는 우선 순위가 아닙니다.)
 
1.       해당 어플리케이션이 사용하는 Native 코드 사용시 발생
 
2.       모든 Type 2 JDBC 드라이버는 native DBMS 라이브러리를 사용하므로 이러한 유형의 오류가 발생할 수 있습니다.  이 드라이버가 문제의 원인인지 판별하려면 pure java(Type 4) JDBC 드라이버로 전환합니다.
 
3.       JNI 호출을 사용하여 액세스하는 모든 native 라이브러리도 이러한 유형의 오류가 발생할 수 있습니다.  응용 프로그램에서 이러한 라이브러리를 사용하는 경우 신중하게 조사해야 합니다.  보통 이러한 라이브러리는 응용 프로그램에서 해당 기능을 필요로 하기 때문에 제외시키기 어렵습니다.
 
4.       JVM 자체도 native 프로그램이며 이러한 오류가 발생할 수 있습니다.  JVM이 의심스러운 경우 인증된 다른 JVM 또는 상위 버전을 사용하여 JVM 버그가 오류의 원인인지 파악합니다.  많은 JVM 버그는 JIT 컴파일러 사용과 관련이 있으며 종종 이 기능을 해제하면 이러한 유형의 문제가 해결되기도 합니다.  이 기능을 해제하려면 대개 -Djava.compiler=none 명령 옵션을 사용합니다. 
 
위와 같은 원인 이외에도 발생 원인은 많습니다. Core file이 생성되면 이 Core file을 분석하여 발생원인의 범위를 좁혀 가야 합니다.(발생원인을 좁혀가는 거지 발생원인을 정확히 집어내기는 어렵습니다. – 능력이 출중한 사람은 되겠지요.)
이 문서에서는 Core file 분석 Tool인 dbx나 gdb을 사용하지 않고 각 OS에서 제공하는 Core File분석 툴을 사용 하여 분석하는 방법에 관하여 알아봅니다.
 
참고 : 다음과 같은 경우 Core File이 생성되지 않을 수도 있습니다.
 
•        시스템 또는 사용자 별 ulimit -c(코어 파일의 설정된 크기)를 검사합니다.
•        사용 가능한 사용자 디스크 공간을 검사합니다(예: 디스크 할당량이 있습니까?)
•        Solaris에서는 /etc/system 파일에 다음 매개변수가 있는데 이 값에 따라 코어 파일이 생성되지 않을 수 있습니다. set sys:coredumpsize=0
•        Linux에서는 기본적으로 코더 덤프가 오프로 있습니다.  RedHat Advanced Server 2.1에서는 구성 정보 파일이 /etc/security에 있습니다.  limits.conf라는 파일에서 설정 사항을 확인할 수 있습니다. "core"라는 단어를 찾아보십시오.  0으로 설정되어 있으면 coredump를 만들 수 없습니다.
•        HP OS 설정 커널 매개변수 maxdsiz(max_per_proc_data_size는 사용자 프로세스의 데이터 세그멘트 크기를 늘림) 64M에서 134M 이상으로 변경합니다. 

 
Core File 분석 Tool
다음은 각 OS에서 사용하는 분석 툴입니다.
분석을 위해서는 statck분석 툴과 map분석 툴을 사용합니다.
    Solaris:
        stack 명령 = pstack
        map 명령 = pmap
    IBM의 추가 기능이 있는 AIX 5.2 이상(이전 버전에서는 사용할 수 없음)
        stack 명령 = procstack
        map 명령 = procmap
        참고: http://www-106.ibm.com/developerworks/eserver/articles/AIX5.2PerfTools.html
 
    Linux:
        stack = lsstack
        map = pmap
 
참고: http://sourceforge.net/projects/lsstack/에서 lsstack을 가져와서 Linux 플랫폼에서 빌드할 수 있습니다.
이 명령은 Solaris의 pstack에 해당합니다.
 
http://web.hexapodia.org/~adi/pmap.c에서 pmap 소스를 가져와서 Linux 플랫폼에서 빌드할 수 있습니다.
 
HPUX: 기본 제공 툴은 없으며, GDB, ADB을 사용함.
 
명령어 사용
 
각 명령어의 보다 자세한 옵션 사항은 명령어의 Help을 참조하십시오.
 
Solaris 예
 
/usr/bin/pstack [-F] [pid | core] > [분석내용저장파일명]
 
ex) pstack core2004-10-29 > coreStack.txt
 
/usr/bin/pmap [ -rslF ]  [ pid | core ] > [분석내용저장파일명]
 
Ex) pmap core2004-10-29 > coreMap.txt
 
 
분석
 
coreStack.txt 내용
core 'core' of 20956:   /wwsl/sharedInstalls/solaris/wls70sp2/jdk131_06/bin/../bin/sparc/nativ
-----------------  lwp# 14 / thread# 25  --------------------
 ff369764 __sigprocmask (ff36bf60, 0, 0, e6181d70, ff37e000, 0) + 8
 ff35e110 _sigon   (e6181d70, ff385930, 6, e6180114, e6181d70, 6) + d0
 ff361150 _thrp_kill (0, 19, 6, ff37e000, 19, ff2c0450) + f8
 ff24b900 raise    (6, 0, 0, ffffffff, ff2c03bc, 4) + 40
 ff2358ec abort    (ff2bc000, e6180268, 0, fffffff8, 4, e6180289) + 100
 fe3c68fc __1cCosFabort6Fl_v_ (1, fe4c8000, 1, e61802e8, 0, e9f90420) + b8
 fe3c59f0 __1cCosbBhandle_unexpected_exception6FpnGThread_ipCpv_v_ (ff2c02ac, fe53895c, fe4dc164, fe470ab4, fe4c8000, e6180308) + 254
 fe20a8b4 JVM_handle_solaris_signal (0, 25d5b8, e6180d90, fe4c8000, b, e6181048) + 8ec
 ff36b824 __sighndlr (b, e6181048, e6180d90, fe20a8cc, e6181e14, e6181e04) + c
 ff3684d8 sigacthandler (b, e6181d70, 0, 0, 0, ff37e000) + 708
 --- called from signal handler with signal 11 (SIGSEGV) ---
 e9f90420 Java_HelloWorld_displayHelloWorld (25d644, e6181224, e61819b8, 0, 2, 0) + 30
 00090ae4 ???????? (e6181224, e61819b8, 25d5b8, fe4c8000, 0, 109a0)
 0008dc4c ???????? (e61812c4, ffffffff, ffffffff, 97400, 4, e61811b8)
 0008dc4c ???????? (e618135c, e61819b8, fe4c8000, 99600, c, e6181250)
 0008dc4c ???????? (e61813ec, f76a2f90, e618147c, 99600, c, e61812f8)
 0008ddb4 ???????? (e618147c, f68578b8, 0, 99974, c, e6181388)
 0008ddd8 ???????? (e618154c, e61815c8, e61815cc, 99974, 4, e6181410)

 
굵은 부분이 오류가 발생한 부분을 나타낸다. “--- called from signal handler with signal“을 찾으면 된다. 이 오류가 발생한 메모리 영역이 “e9f90420“ 이다. coreMap.txt 파일에서 이 주소값이 포함되는 범위를 찾아본다.
 
coreMap.txt 내용
E9500000   1184K read
E9680000   1392K read
E9800000   4608K read
E9F60000    136K read/write/exec
E9F90000      8K read/exec         /home/usera/wls70/solaris/projectWork/lib/libhello.so
E9FA0000      8K read/write/exec   /home/usera/wls70/solaris/projectWork/lib/libhello.so
E9FB4000      8K read/write/exec
E9FC0000    120K read/exec         /usr/lib/libelf.so.1
E9FEE000      8K read/write/exec   /usr/lib/libelf.so.1

 
“e9f90420“ 가 포함된 범위에서 사용되는 라이블러리는 “libhello.so“ 임을 알 수 있다.
Core 발생은 주 원인은 “libhello.so“ 일 가능성으로 추측할 수 있다. 
 

GDB 사용하기   개요 gdb [-help] [-nx] [-q] [-batch] [-cd=dir] [-f] [-b bps] [-tty=dev] [-s symfile] [-e prog] [-se prog] [-c core] [-x cmds] [-d dir] [prog[core|procID]]   1.    GDB   GDB같은 디버거의 목적은 다른 프로그램 수행 중에 그 프로그램 ‘내부에서’ 무슨 일이 일어나고 있는지 보여주거나 프로그램이 잘못 실행되었을 때 무슨 일이 일어나고 있는지 보여주는 것이다. GDB는C, C++, Modula-2로 짠 프로그램을 디버그 할 수 있다. 쉘에서 gdb로 GDB를 시작하면 quit로 종료명령을 주기전까지는 터미널로부터 명령라인을 읽어 들인다. help명령을 사용하여 gdb내부에서 도움말을 볼 수 있다. 디버깅을 하기 위해서는 –g옵션을 주고 컴파일/링크 해야 한다. 만약 링크가 libg.a를 찾을 수 없다고 하면서 실패하게 되면, /usr/lib/ligb.a를 갖고 있지 않기 때문이다. 그 파일은 특별한 라이브러리로서 디버깅 가능 C라이브러리이다. libc 패키지에 포함되어 있거나 또는 libc 소스 코드를 받아서 컴파일 하면 생긴다. /usr/lib/libc.a를 /usr/lib/libg.a로 링크 시켜도 된다.   l         코어파일 분석하기   코어파일은 충돌할 당시 프로세스의 메모리 이미지를 덤프한 것이다. 코어파일을 gdb와 함께 사용하여 프로그램의 상태를 조사하고 실패 원인을 규명할 수 있다. 어떤 예기치 않은 일이 발생하여 비정상적인 종료가 발생할 때 운영체계는 디스크에 코어 파일을 남긴다.메모리에 관한 문제는 Checker 패키지를 사용하여 예방할 수 있다. 하지만 메모리 fault를 일으키는 경우에는 충돌하면서 파일을 덤프한다. 코어파일은 일반적으로 프로세스를 실행시킨 현재 작업 디렉토리에 생성되지만 프로그램 내에서 작업 디렉토리를 바꾸는 경우도 있다.   보통 리눅스는 부팅시에 코어 파일을 만들지 않도록 세팅되어 있다. 코어 파일 생성을 가능케 하려고 한다면 그것을 다시 가능케 하는 셀의 내장 명령을 사용한다. 만약C쉘 호환 쉘(tcsh)을 쓰고 있다면 다음과 같이 명령을 내린다. %  limit core unlimited 만약 본쉘류( sh , bash , zsh , pdksh )를 사용하고 있다면, $  ulimit –c unlimited 와 같은 명령을 내린다. 코어파일을 함께 사용하기 위해선 다음과 같이 한다. % gdb program core       l         실행 중인 프로그램 디버깅하기   gdb는 이미 실행중인 프로그램도 디버깅할 수 있게 해준다. 프로세스 실행을 가로채고 조사한 뒤 다시 원래 상태로 실행하도록 할 수 있다. attach명령을 사용하여 실행중인 프로세서에 gdb를 붙인다. attach 명령을 사용하기 위해서는 프로세스에 해당하는 실행 프로그램에 허가권을 가지고 있어야 한다. 예를 들어 프로세스 ID 254번으로 실행 중인 pgmseq 프로그램이 있다면 다음과 같이 한다. % gdb pgmseq % attach 254 다음과 같이 해도 된다. % gdb pgmseq 254   일단 gdb가 실행 중인 프로세스에 부착되면 프로그램을 일시 중지 시키고 gdb명령을 사용할 수 있도록 제어권을 가져온다. break를 사용하여 중지점을 사용할 수 있고 중지점에 이를 때까지 실행하도록 continue 명령을 사용할 수 있다. detach명령을 사용하여 gdb를 실행 중인 프로세스에서 떼어 낸다. 필요에 따라 다른 프로세스에 대하여 attach명령을 사용할 수 있다.   2.    gdb시작하기   % gdb                       - gdb를 먼저 실행 후file이라는 명령으로 program을 부른다. % gdb  program          - 일반적인 방법이다. % gdb  program  core  - 코어파일을 사용할 때 동시에 인자로 준다. % gdb  program  1234  - 실행중인 프로세스를 디버그 하려면 프로세스 ID를 두 번째 인자로 주면 된다. 이 명령은 gdb를 (‘1234’ 란 이름의 파일이 없다면) 프로세스 1234에 접속시킨다.(gdb는 core파일을 먼저 찾는다.)   실행절차 %  gcc  –g  test.c  –o  test %  gdb  test 이 명령을 실행하면 다음과 같은 메시지가 나타난다. % gdb test GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are Welcome to change it and/or distribute copies of it under certain conditions. Type “show copying” to see the conditions. There is absolutely no warranty for GDB.  Type “show warranty” for details. This GDB was configured as “i386-redhat-linux”... (gdb)   3.    많이 사용하는 GDB명령어   list 현재 위치에서 소스 파일의 내용을 10줄 보여준다 list 2, 15 : 소스 파일의2 ~ 15 까지를 보여준다. run 프로그램을 시작한다.(break가 있다면 break까지 실행) run arg : 새로운 인수를 가지고 프로그램을 시작한다. arg는 “*”나 “[…]”를 포함할 수도 있다. 쉘의 사용까지도 확장될 수 있다. “<”,“>” , “>>”같은 입출력 방향 재지정기호도 또한 허용된다. break 특정 라인이나 함수에 정지점을 설정한다. break function : 현재 파일 안의 함수 function에 정지점을 설정한다. break file:function : 파일file안의 function에 정지점을 설정한다. watch : 감시점 설정(감시점은 어떤사건이 일어날 때에만 작동한다) until : 실행중 line까지 실행 clear    특정 라인이나 함수에 있던 정지점을 삭제한다. delete  몇몇 정지점이나 자동으로 출력되는 표현을 삭제한다. next 다음 행을 수행한다. 서브루틴을 호출하면서 계속 수행한다. 호출이 발생하지 않으면 step와 같다. next n : 이를 n번 수행하라는 의미 step 한 줄씩 실행 시킨다. 함수를 포함하고 있으면 함수 내부로 들어가서 한 줄씩 실행시킨다. print print expr : 수식의 값을 보여준다. display 현재 display된 명령의 목록을 보여준다. bt 프로그램 스택을 보여준다. (backtrace) kill 디버깅 중인 프로그램의 실행을 취소한다. file file program : 디버깅할 프로그램으로서 파일을 사용한다. cont continue : 현재 위치에서 프로그램을 계속 실행한다. help 명령에 관한 정보를 보여주거나 일반적인 정보를 보여준다. quit gdb에서 빠져나간다.      4.    gdb 해보기   예제1   % vi test.c       1 #include <stdio.h>       2       3 main()       4 {       5     int i;       6     double j;       7     /*다음은i/2+i의 값을 출력하는 문이다.       8       i가1이면 j는1.5가 되어야 하지만 실제는 그렇지 않다.*/       9     for( i=0; i<5 ; i++){      10         j=i/2+i;      11         printf(“j is %f n”,j);      12     }      13 } % gcc –g test.c –o test % test 실행이 되지 않으면 mv test a.out으로 하여a.out을 실행시킨다. 실행을 시키면 원하는 답이 아니다. 그러면 gdb를 해보자. % gdb a.out (gdb) list        // list는 소스 내용을 10줄씩 보여준다. 1         #include <stdio.h> 2 3         main() 4         { 5         int i; 6         double j; 7         /*다음은i/2+i의 값을 출력하는 문이다. 8         i가1이면 j는1.5가 되어야 하지만 실제는 그렇지 않다.*/ 9         ( i=0; i<5 ; i++){ j=i/2+i;   (gdb) b 9  // break 9 : for 문에 이상이 있다고 판단하여 line 9에 breakpoint를 잡는다. Breakpoint 1 at 0x80483d6: file test.c, line 9. (gdb) r     // run : breakpoint까지 실행된다. Starting program: /home/pllab/chowing/gdb/a.out Breakpoint 1, main () at test.c:9 9  for( i=0; i<5 ; i++){ (gdb) s                           // step : 한줄 실행시킨다. j=i/2+i; (gdb) s 11  printf(“j is %f n”,j); (gdb) p j         // print j : j의 값을 본다. $2 = 0 (gdb) n j is 0.000000 for( i=0; i<5 ; i++){ (gdb) display i (gdb) display j (gdb) n 11  printf(“j is %f n”,j); 2: j = 1 1: i = 1 // 10 line에서 실행 후 i=1일 때, j=1이므로 10 line에서 잘못된 것을 알 수 있다. // 10 line을 j = (double) i/2 + i; 로 고친다. (gdb) quit   예제2   % vi hab.c       1 #include <stdio.h>       2       3 int hab(int x, int y);       4       5 main(void)       6 {       7     int a, b,dab;       8     printf(“정수a, b를 입력하시오”);       9     scanf(“%d %d”,&a,&b);      10     dab = hab(a,b);      11     printf(“n%d + %d = %d n”,a,b,dab);      12 }      13 int hab(int x, int y)      14 {      15     return (x + y);      16 }                                         // 이 프로그램은 이상은 없다. 스택을 보기 위한 것이다. // 여러 곳에서 호출되는 함수 안에서 충돌이 일어날 경우를 생각해 보자. 이 때는 함수가 어디로부터 호출되었는지 그리고 어떤 상황에서 충돌이 일어났는지 파악하고자 할 것이다. backtrace (bt) 명령을 이용하면 충돌이 일어난 시점에서 프로그램의 현재 호출 스택(call stack) 상태를 볼 수 있다. 호출 스택은 현재 함수까지 이르는 호출 목록이다. 함수를 호출할 때마다 보관된 레지스터 값, 함수 전달 인수, 지역 변수 등의 자료를 스택에 push한다. 이렇게 해서 각 함수들은 스택상에 일정 공간을 차지한다. 특정함수에 대하여 스택에서 사용되고 있는 메로리 부분을 스택프레임(frame)이라 부르며 호출 스택은 이러한 스택 프레임을 순서대로 정렬한 목록이다. % gdb hab (gdb) b 10      Breakpoint 2 at 0x8048428: file hab.c, line 10. (gdb) r Starting program: /home/pllab/chowing/gdb/hab 정수a, b를 입력하시오3 4 breakpoint 2, main () at hab.c:10 10       dab = hab(a,b); (gdb) bt         // 현재 스택에 main이 있다. #0  main () at hab.c:10 (gdb) s hab (x=3, y=4) at hab.c:15 15          return (x + y); (gdb) bt         // 지금은 스택에 hab이 있다. #0  hab (x=3, y=4) at hab.c:15 #1  0x8048435 in main () at hab.c:10 (gdb) frame 0 // hab의 상태를 점검하기 위해서 스택 프레임0번으로 이동 #0  hab (x=3, y=4) at hab.c:15 15          return (x + y); (gdb) up           // hab이 어떻게 호출되었는가를 보기 위하여 상위 스택프레임으로 이동 #1  0x8048435 in main () at hab.c:10 dab = hab(a,b); (gdb) finish (gdb) info program     // 프로그램의 실행 상태를 보여 준다. Using the running image of child Pid 12909. Program stopped at 0x804843d. It stopped after being stepped. (gdb) info locals          // 현재 함수 내에서 모든 지역 변수 이름과 값을 출력한다. a = 3 b = 4 dab = 7 (gdb) info variables   // 소스파일 순서대로 프로그램 내에 알려져 있는 모든 변수를 출력한다. (gdb) info address a   // 어떤 변수가 어디에 저장되어 있는지에 대하여 알려 준다. Symbol “a” is a local variable at frame offset -4. // a가 스택프레임 꼭대기로부터4바이트 아래에 놓여 있다는 뜻이다. (gdb) info frame          // 현재 프레임 정보를 보여 준다. Stack level 0, frame at 0xbffff848: eip = 0x804843d in main (hab.c:11); saved eip 0x400301eb source language c. Arglist at 0xbffff848, args: Locals at 0xbffff848, Previous frame’s sp is 0x0 Saved registers: ebp at 0xbffff848, eip at 0xbffff84c   예제3   % vi core.c       1 #include <stdio.h>       2       3 main()       4 {       5     char *bug = NULL;       6       7     strcpy(bug,“debug”);       8     printf(“bug is %s n”,bug);       9      10     return;      11 }      12 % coredebug Segmentation fault // core 파일 생성 % gdb coredebug (gdb) b 7 Breakpoint 1, main () at core.c:7 7           strcpy(bug,”debug”); (gdb) p bug $1 = 0x0          // gdb 에서0x0는 null이다. 즉 번지가 없다. (gdb) s Program received signal SIGSEGV, Segmentation fault. 0x40075434 in ?? ()      // strcpy에서 segmentation fault가 발생한 것을 알 수 있다. // bug에 번지를 할당하면 된다.   % gdb corebug core  // core파일을 이용하면 bug정보가 나온다. GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type “show copying” to see the conditions. There is absolutely no warranty for GDB.  Type “show warranty” for details. This GDB was configured as “i386-redhat-linux”... warning: core file may not match specified executable file. Core was generated by ‘a.out’. Program terminated with signal 11, 세그멘테이션 오류. Reading symbols from /lib/libc.so.6...done. Reading symbols from /lib/ld-linux.so.2...done. #0  strcpy (dest=0x0, src=0x8048490 “debug”) at ../sysdeps/generic/strcpy.c:38 ../sysdeps/generic/strcpy.c: 그런 파일이나 디렉토리가 없음. gdb는 signal 11 번과 함께 코어 파일이 생성되었음을 알려 준다. 여기서는 허가받지 않은 메모리 공간에 읽기, 쓰기를 시도했기 때문에 커널이 프로세스에게 signal 11을 보냈다. 이 시그널로 인해 프로세스는 종료하면서 코어 파일을 덤프한다.   l         기타 기능   gdb는 매우 많은 기능을 가진 프로그램이다.   Breakpoint 중지점을 조건적으로 설정할 수 있다. 즉 어떤 동작이 참일 때만 작동하도록 할 수 있다.  Ex) break 184 if (stace == 0) info break를 사용하면 모든 중지점과 감시점 목록을 보여 주고 그 상태도 보여 준다. disable를 사용하여 작동불능으로 할 수 있고 enable를 사용하여 가능하게 할 수도 있다.     인스트럭션 레벨 디버깅 gdb를 통해 인스트럭션 레벨의 디버깅을 할 수 있으므로 프로그램의 매우 깊은 내부까지 조사할 수 있다. (gdb) disass play      //play함수에 대한 디스어셈블리. (gdb) display/ i $pc   //현재의 인스트럭션을 보여준다. $pc는 gdb내부 변수로서 현재 인스트럭션의 위치를 가리키는 프로그램 카운터이다.   옵션 옵션 이외의 모든 인자는 실행가능 파일과 core 파일(또는 프로세스 ID)로 인식된다. 즉 옵션 플래그 없는 첫번째 인자는 `-se' 옵션과 같고, 두번째 인자는, 존재한다면, `-c' 옵션과 같다(인자가 파일이름인 경우). 많은 옵션에 짧은 형식과 긴 형식이 있는데, 둘다 아래에 설명된다. 긴 옵션은 일부만 써도 애매하지 않으면 인식된다. (당신이 그렇게 하고 싶다면, `-'대신 `+'로 옵션을 나타낼 수도 있다. 우린 일반적 관례인 -를 쓰겠다) 모든 옵션과 명령행 인자들은 순차적으로 처리된다. `-x'옵션을 사용할 경우 순서가 다르면 결과도 다르다. 　　-help, -h : 모든 옵션을 짧은 설명과 함께 보여준다. 　　-symbols=file, -s file : file로부터 심볼 테이블을 읽어들인다. 　　-exec=file, -e file : 적당하다면 실행파일로 file을 사용하여 core dump의 내용을 검사한다. 　　-se=file : file로부터 심볼 테이블을 읽어들이고 또한 실행파일로 사용한다. 　　-core=file, -c file : file을 검사할 core dump로 사용한다. 　　-command=file, -x file : file안의 GDB 명령을 수행한다. 　　-directory=directory, -d directory : 소스 파일 검색 경로에 directory를 추가한다. 　　-nx, -n : 초기화 파일 `.gdbinit'의 명령을 수행하지않는다. 　　　　　　보통 모든 옵션과 인자가 처리된 후 초기화 파일의 명령이 실행된다. 　　-quiet, -q : 도입 메시지와 저작권 메시지를 출력하지않는다. 배치 모드에서도 이들 메시지는                      출력되지않는다. 　　-batch : 배치 모드로 수행한다. `-x' 옵션으로 지정한 파일(.gdbinit' 파일)의 명령들을 수행한 후                종료상태 0으로 종료한다. 　　　　　　파일의 GDB 명령을 수행하던 중 오류가 발생하면 0이 아닌 종료상태로 종료한다. 　　　　　　프로그램을 내려받아서 다른 컴퓨터에서 실행하는 경우등에, GDB를 필터로 사용할 수 있는데 　　　　　　이때 배치 모드가 유용하다. 　　　　　　이 모드가 더 쓸모있도록, GDB하에서 수행되던 프로그램이 종료되면 나오는 Program exited                normally. 이란 메시지가 배치 모드에서는 나오지 않는다. 　　-cd=directory : 현재 디렉토리 대신 directory를 작업 디렉토리로 하여 GDB를 수행한다. 　　-fullname, -f : 이맥스의 서브프로세스로 GDB가 수행될 때 이 옵션이 켜진다. 　　　　　　이 옵션이 켜지면 GDB는 전체 파일이름과 행번호를, 스택 프레임을 디스플레이할 때마다 　　　　　　(프로그램이 정지되는 경우도 여기에 해당된다) 표준적이고 알아볼 수 있는 양식으로 출력한다. 　　　　　　이 양식은 ` 32'뒤에 파일이름, 콜론으로 구분된 행번호와 문자위치, 개행문자가 오는 것이다. 　　　　　　이맥스-GDB 접속프로그램은 ` 32'를 프레임의 소스코드를 디스플레이하란 신호로 사용한다. 　　-b bps : 원격 디버깅에 사용되는 직렬 인터페이스의 회선속도(보오율이나 초당 비트수)를 설정한다. 　　-tty=device : device를 표준입력과 표준출력으로 하여 프로그램을 실행한다