웹 개발을 여행할 히치하이커를 위한 안내서

Posted at 2008/06/28 23:21// Posted in dev
동아리 회지에 들어갈 용도로 쓴 글입니다.
제목과 맺음말은 모영화 패러디_


Table of Contents
1. 들어가면서 - World Wide Web
2. 개념적인 것과 실제적인 것
3. 쉬어가며 - 필드 얘기
4. 무엇을 공부할까?
5. 개발자가 익혀야 할 개발과 상관없어 보이는 것들
6. 마치면서 - Next Generation
A. 참고[할]자료


1. 들어가면서 - World Wide Web


제가 새내기 때도 그랬지만, 요즘 새내기들은 더욱더 웹에 친숙할 것 같습니다. 제가 새내기 때에는 세이클럽에서 채팅을 하고, 자기 홈페이지를 만들고 했었죠. 요즘이라면 싸이월드에서 미니홈피를 관리하고, 네이버에서 검색을 하고 블로그를 쓰고, 다음에서 카페 활동을 하는 등 다양한 웹 사이트를 이용하겠죠. 하지만, 지금은 너무나 당연하게 생각하는 이런 활동이 처음부터 있었던 것은 아닙니다.

최초의 웹은 1989년 CERN(유럽 입자물리학 연구소)에서 원거리의 연구원끼리 새로운 아이디어나 연구 결과 정보를 효과적으로 공유하고 손실 없이 관리하기 위해 팀 버너스 리(Tim Berners-Lee)에 의해 제안되었습니다. 제가 예전에 했었던 '웹의 이해' 세미나 자료를 조금 발췌해봅니다.

처음 팀에서 웹이라는 용어를 사용한 것은 CERN이 가지고 있는 유연한 조직 구조를 묘사하기 위한 것이었다. 당시 CERN의 조직 구조 안에서는 새로운 인원이 오게 되거나 누군가 새 업무를 맡게 되면 다른 사람들에 의해 그에게 필요한 문서나 장비 등에 대한 정보가 주어지게 되며 이러한 정보들은 좀 더 업무를 효율적으로 수행할 수 있게 하는 원동력이 되었다. 마치 거미줄처럼 엮여 있는 인적 자원들이 서로에게 정보를 공유할 수 있던 것이었다.
여기서 문제는 조직이 커지고 시간이 흐르게 되면 그 안에서 정보가 유실되거나 또는 원하는 정보를 찾지 못할 가능성이 커진다는 점이었다.
이러한 문제를 해결하기 위해 팀은 하이퍼텍스트를 쓰는 Linked Information System을 제안했는데 이 시스템은 트리 구조로 되어 있던 기존의 정보 시스템과 달리 링크에 의존하는 오늘날의 웹과 매우 흡사한 형태를 취하고 있다. CERN의 조직 구조에 빗대어 얘기하자면 각 인원이 자신과 관련 있는 연구를 하고 있는 다른 연구원에 대해서 알고 있는 시스템이다. 원하는 정보를 찾기 위해서는 한 명을 붙잡고 그가 알고 있는 다른 사람에 대한 정보(링크)를 받아낸 다음 그 중에서 원하는 정보를 갖고 있다고 판단되는 사람에게 똑같은 질의(query)를 던지면 된다. 이런 식으로 링크를 따라가면 결국에는 필요한 데이터를 얻을 수 있게 되는 것이다.
웹의 이해 세미나 자료 인용


인용된 내용에서 나오듯이 최초 웹의 형태는 말 그대로 '하이퍼텍스트를 포함한 페이지들의 네트워크' 정도였습니다. 이런 상태라면 자신이 원하는 정보를 찾기가 매우 힘들겠죠. 자신이 원하는 정보를 포함하는 페이지를 정확히 알거나, 그런 페이지를 링크한 페이지를 찾아야 하니까요. 그래서 나온 것이 검색입니다. 초창기 야후나 알타비스타 같은 사이트들은 웹에 있는 페이지들을 수집해서 키워드-주소 형태의 데이터베이스를 구축합니다. 그리고는 키워드로 자신이 원하는 페이지를 찾을 수 있는 검색 인터페이스를 제공합니다.

그리고는 홈페이지 공간 제공(마이홈, 네띠앙 등), 이메일 서비스 제공(다음), 카페를 필두로 한 커뮤니티 서비스(다음), 인터넷 채팅(세이클럽), 인터넷 보드 게임(한게임, 넷마블 등), 개인 미니홈피(싸이월드), 검색의 확장 - 지식검색, 지역검색 등(네이버), 블로그와 카페의 2차 커뮤니티 붐(네이버) 등의 국내 웹의 흐름이 있었습니다. 순서가 정확히는 맞지 않지만 대략적인 흐름은 맞을 거라 생각됩니다.

이런 식으로 계속 발전하여 지금은 리치 어플리케이션이라고 해도 좋을 정도로 풍부한 인터페이스와 사용자 친화적인 페이지(사이트)들도 생기고 있습니다. 구글의 GMail이 대표적인 사례입니다.

왜 굳이 이런 얘기들을 하느냐면 현재의 웹이 있게 된 이유를 알아야 '이런 것들이 왜 이런 형태이구나' 하는걸 알고, 맨땅에 헤딩하는 일 없이 웹 개발자의 길을 걸어온 선배들의 삽질을 물려받아서 그 이상의 것을 해내야 하기 때문입니다. 그리고 역사란 재미있고요:)



2. 개념적인 것과 실제적인 것

이제 개발자스러운 얘기를 좀 해보겠습니다. 제목은 개념적인 것과 실제적인 것의 대조를 이루는 뉘앙스이지만 둘 다 중요하고 밀접하게 연관되어있습니다.

웹은 클라이언트-서버 모델입니다. 간단하게 말하면, 다른 컴퓨터에 있는 페이지를 전송받아서 내 컴퓨터에서 보는 기술인 거죠. 내가 원하는 페이지를 요청하고, 응답받은 페이지를 보여주는 부분이 클라이언트입니다. 반대로 서버는 요청받은 페이지를 - 가공하여 - 응답하는 부분이 되겠죠.

요청(Request)과 응답(Response)은 용어 자체로도 중요합니다. 클라이언트는 요청을 하는 주체이고, 서버는 응답을 하는 주체입니다. 요청이라는 것은 '내가 원하는 페이지를 주세요', '이 아이디와 패스워드를 드릴 테니 나를 로그인시켜주세요', '글을 썼으니 등록해주세요' 같은 요청이 있을 수 있습니다. 물론, 이건 사용자 관점입니다. 응답은 요청에 대한 응답입니다. '여기 페이지 있습니다', '패스워드가 틀린 데요?', '로그인되었습니다', '글을 등록했습니다' 같은 종류가 나올 수 있겠죠. 요청과 응답은 사용자의 활동과 밀접한 관계가 있습니다.

이제 실제적인 것들에 대해서 얘기해보겠습니다. 맨 먼저 얘기했던, 클라이언트-서버 모델에 실제 매칭되는 부분을 생각해봅시다. 클라이언트란 작게 보면 내가 지금 쓰고 있는 Internet Explorer, Firefox 같은 웹 브라우저가 됩니다. 조금 더 크게 생각하면 웹 페이지를 탐색할 수 있는 응용 프로그램/컴퓨터가 되겠죠. 그렇다면, 서버는 어떤 게 될까요? 역시나 작게 보면 HTTP 프로토콜을 통해 페이지에 대한 요청/응답을 처리할 수 있는 응용 프로그램이 됩니다. 흔히들 얘기하는 Apache, IIS(Internet Information Service) 같은 프로그램이 됩니다. 크게 보면 웹 서버를 실행시키는 머신까지 얘기가 되겠네요.

서버에 있는 페이지를 클라이언트에서 보기 위해서 요청과 응답을 하는 방법은 HTTP(HyperText Transfer Protocol)에 정의되어있습니다. 말 그대로 하이퍼텍스트 문서를 주고받기 위한 규약입니다. HTTP에서 요청은 여러 가지가 있지만 우리가 알아야 할 두 가지는 GET방식과 POST방식입니다. 응답은 응답코드로 구분이 되는데, 404 Page Not Found는 여러분도 잘 알고 있으리라 생각됩니다. 일반적으로 정상적인 응답에서는 200번 코드를 반환합니다.

요청과 응답은 실제 웹 개발할 때도 매칭이 됩니다. ASP나 ASP.NET에서는 Request개체, Response개체가 있어서 요청과 응답을 조정할 수 있고, PHP역시 $_REQUEST($_GET, $_POST)라는 개체가 있어서 요청을 읽을 수 있습니다. JSP에서도 request, response라는 개체가 있고요:)

웹 개발자로서 이렇게 개념적인 부분과 실제적인 부분을 매칭시키는 것은 중요합니다.



3. 쉬어가며 - 필드 얘기

잠깐 쉬어가는 의미로 실제 필드에서의 얘기를 잠깐 해보겠습니다. 제 개인적인 경험과 간접 경험을 통한 얘기이므로 실제와는 당연히 차이가 있을 수 있습니다만 흐름을 보는 차원에서 얘기해볼게요.

국내에서 웹 개발자로 취업을 한다면 주로 '웹 에이전시', '포탈', 'SI(System Integration)' 관련 업체로 구분됩니다. 그 외의 경우도 많이 있겠지만(R&D같은 예가 되겠죠. N모사의 웹2.0팀) 크게 보면 이런 형태에서 벗어나지는 않는 것 같습니다.

웹 에이전시의 경우 웹 사이트 제작을 의뢰받아서 제작해서 납품하고 일정수준의 유지보수를 해주는 형태의 일이 대부분입니다. 한 번에 하나의 프로젝트만 뛰는 경우도 있지만, 한 번에 여러 사이트를 제작하는 경우가 더 많습니다. 마감 기일에 맞춰서 제작을 하게 되고 계약 형태에 따라서 다르지만 일정 수준의 기획을 가지고 디자인과 개발을 전담하는 형태가 많습니다. 이러한 구조다 보니까 빠른 개발 능력과 기존 소스&컴포넌트를 재활용하는 능력이 요구됩니다.

포탈의 경우 주로 서비스를 새로 오픈하거나, 기존 서비스를 유지보수, 운영하는 일이 많습니다. 서비스에 따른 유저의 반응을 알기 쉽고 많은 유저를 상대하기 때문에(직접 상대하진 않습니다만) 일정 수준 이상의 '서비스 마인드'를 요구합니다. 더욱이 포탈의 경우 규모가 크기 때문에 대용량 데이터베이스, 확장 가능한 어플리케이션 같은 경험 혹은 능력을 요구합니다. 빠른 응답속도 역시 필요로 하기 때문에 최적화에 중점을 두는 경우가 많습니다. 반면 복잡한 로직을 처리하는 일은 적습니다.

SI는 '시스템 통합'이라고 해서 기업의 전산망을 유지보수하기 좋고, 운영하기 좋고, 관리하기 좋게 통합하는 일입니다. 당연히 그 기업의 업무 프로세스를 파악하는 능력이 크게 요구됩니다. 나은 개발실력보다 업무 프로세스를 파악하는 능력을 더 높게 쳐주는 곳도 많습니다. (S사) 당연히 개발적으로도 복잡한 도메인 로직을 다루는 능력이 요구됩니다. 빠른 응답속도를 크게 고려하지 않아도 되지만, 정확한 데이터 처리가 요구됩니다.



4. 무엇을 공부할까?

실제로 웹 개발자가 되고 싶다거나, 웹 개발에 관심이 많은 사람이 가장 혼란을 겪는 부분이라고 생각됩니다. 웹 관련 기술은 정말 많습니다. 흔히 얘기하는 ASP, PHP, JSP등의 서버측 기술, HTML, JavaScript 등의 클라이언트측 기술 등 많은 기술이 있습니다.

하지만, 가장 중요한 것은 '문제를 해결하는 능력'입니다. 개발자는 문제를 해결하는 사람이고, 우리가 얘기하는 각종 기술들은 문제를 해결할 때 쓰는 도구입니다. 흔히들 빠지기 쉬운 도구만능주의 때문에 어떤 기술이 절대적으로 좋다/나쁘다를 논하는 오류를 범합니다. 도구는 문제를 해결하기 가장 좋은 것을 선택하면 되는거죠 :) 그러기 위해서 도구에 대해 익숙해질 필요가 있습니다. 익숙해지지 않더라도 어떤 게 어떤 경우에 유용한지를 알아야겠죠.

웹 관련 기술을 분류하는 방법은 여러 가지가 있겠지만 크게는 클라이언트측/서버측 이렇게 나눌 수 있습니다. 이렇게 나누는 것은 중요한데 하나의 소스 파일에 클라이언트에서 실행되는 부분과 서버에서 실행되는 부분이 섞여있을 수 있기 때문입니다. 이 코드가 어느 시점에 어디에서 실행되는지를 알아야 소스를 파악하기 쉽고, 구조적인 소스 설계가 가능합니다.

클라이언트측 기술에는 HTML, XHTML 등의 문서(Document)의 내용을 포함하는 Markup Language와 문서의 요소(Element)들을 컨트롤할 수 있는 JavaScript, VBScript등의 Client Side Script가 있고, 요소의 표현 방법을 정의하는 Cascading Style Sheet(보통 스타일시트)가 있습니다. 이 3가지 기술이 합쳐져서 하나의 문서(document)가 됩니다.

이 외에도 브라우저에서 보다 유용한 일을 할 수 있게 내장되어있는 객체들이 있을 수 있습니다. 또한 ActiveX/Applet/Flash의 형태로 브라우저에 포함(embedding)되어 문서와 상호작용을 할 수 있습니다.

서버측 기술은 서버의 플랫폼과 밀접한 관계가 있습니다. 기술 자체는 플랫폼 독립적이나, 실제로는 궁합이 잘 맞는 플랫폼이 있습니다. 그래서 단순히 스크립트 언어만 안다고 해서 효율적인 프로그래밍을 하기는 어렵습니다. 또한, 데이터베이스도 잘 알아둬야 합니다. 사용자 각각에게 다른 서비스를 제공하고, 컨텐츠를 저장하려면 저장공간은 필수죠. 데이터베이스는 이러한 정보를 저장하고 관리하기 쉽게 설게되어있습니다. 데이터베이스를 관리하는 일은 DBA라는 전문적인 포지션이 있으나, 역시나 개발자도 많이 알아둬야 하는 부분입니다.

ASP와 ASP.NET은 MS플랫폼에서 많이 사용되는 기술입니다. 초창기에는 ASP/COM 기술을 사용하여 웹 어플리케이션을 많이 구성했으나 최근에는 .NET 기술들을 사용하여 구성을 많이 하는 편입니다. MS 서버군(BizTalk, ISA, MS-SQL, Exchange 등)과 잘 어울립니다.

PHP는 주로 LAMP라고 하는 Linux/Apache/MySQL/PHP 환경에서 자주 쓰입니다. 오픈소스 프로젝트로만 되어있는 이 구성은 역시나 오픈소스라는 점이 가장 매력적입니다.

JSP는 MS/비MS를 많이 가리지는 않지만 주로 Unix계열에서 같이 쓰입니다. 전체적인 어플리케이션을 Java로 가져갈 때 쓰이고요. Servlet, EJB등의 기술 등과 함께 구성되는 경우가 많습니다.

좀 더 많은 가이드를 해드리고 싶지만, 제 능력의 부족이 크네요:| 사실 개발자로 처음 실무를 접하게 되면 자신이 기술을 선택하기 보다는 주로 구성되어있는 환경에서(어떤 도구를 사용할지가 정해져 있는 상황에서) 일을 하기 마련입니다. 다만, 도구에만 초점을 맞춰서 생각하지 말고 주변 환경(OS/웹 서버/데이터이스 서버 등)을 이해하기 위해 노력해야 하겠습니다.



5. 개발자가 익혀야 할 개발과 상관없어 보이는 것들

앞에서 도구만능주의에 대해 언급하면서, 문제를 해결하는 것에 초점을 맞추자고 얘기했었죠? 지금은 개발만능주의에 대해서 조금 얘기해보고자 합니다.

이렇게 생각하는 사람이 많습니다. '난 개발만 할거야', '개발자가 그런 건 알아서 뭐해?', '나랑은 관련이 없는 얘기야' 등등. 물론 개발자는 개발을 하기 위한 포지션이고, 문제를 해결하는 방법에 대해 노력을 기울여야합니다. 이런데 고객 응대를 시킨다거나, 화장실 청소를 시킨다거나 하는 것은 정말 시간 낭비입니다. 하지만, 사람들과 얘기하고, 기획 능력이나 디자인 감각에 대해서 아무런 관심도 갖지 않은 체 혼자 일하려는 사람도 있습니다.

자신이 해결해야하는 문제가 간단하면 혼자서 다 됩니다. 문제가 좀 어려워지면 개발자끼리의 협력이 필요한 경우도 있습니다. 그리고 문제가 더욱 커지게 되면 다른 포지션에 있는 사람들과 함께 머리를 맞대며 의논해야 하고, 앞으로 나아가야할 방향에 대해서 설득을 시켜야 하고, 스케쥴링을 하면서 왜 이런 스케쥴이 나와야 하는지 설명해야할 때도 많습니다.

이러한 과정에서 자신이 생각하는 바를 정확히 전달할 수 있는 커뮤니케이션 스킬은 필수입니다. 그것이 대화이거나 글이거나 상관없이 자신의 생각을 전달하는 스킬은 생각보다 어렵습니다. 지금부터라도 틈틈이 글을 써보고 토론형식의 대화를 해보는 것도 좋겠죠.

그리고 다른 포지션의 사람들이 어떤 일을 하고, 어떤 관점에서 프로젝트를 바라보는지를 알아야 합니다. 그러기 위해서는 당연히 기획자들이, 디자이너들이 하는 일에 대해 알아야 하겠죠. 또한, 하나의 프로젝트를 향해 가지만 각각 맡은 부분이 다른 경우이기 때문에 다른 포지션에 대해서 알게 되면 전체 프로젝트를 알기 더 쉬워집니다.

마지막으로 개발을 하면서 경험이 쌓이면, 경험이 없는 사람과 같이 일을 하게 됩니다. 그럴 때 그들에게 노하우를 전해주고, 일을 분배하고 사람을 관리하게 되는 능력도 필요합니다.



6. 마치면서 - Next Generation

중구 난방한 글도 끝나가고 있습니다. 여러 가지를 얘기한 거 같은데 제가 얘기하고 싶었던 것을 간단하게 요약해보겠습니다.

* 웹의 역사와 흐름에 대해서 알자.
* 개념적인 것을 알고, 실제 기술에 매칭시켜서 생각하자.
* 개발 외의 것들에도 관심을 갖자.

그리고 마지막으로 하나 더 있습니다. 기술이라는 것은 실제 생활의 형태와 다양한 환경에 영향을 받아서 생기고 발전합니다. 이러한 기술들의 형성 과정을 따라왔다면 앞서 나가야 한다는 것입니다. 조금 관심이 있으신 분들이라면 '웹2.0'이라는 용어를 들어봤을 것 같습니다. 기술적으로 1.0/2.0을 구분한 것이 아니라 현재 기업들의 웹에 대한 접근 형태, 다른 방식의 비지니스 모델 창출 등을 가지고 구분을 했다고 보는 게 더 맞겠죠. 이에 따라 기술이 재편되는 경향을 가지고 있고요. 흐름을 읽었으면, 앞으로의 트렌드를 주도해 나가야 합니다.

Don't panic!



A. 참고[할]자료
링크 : 21세기를 지배하는 네트워크 과학
http://www.yes24.com/Goods/FTGoodsView.aspx?goodsNo=310361&CategoryNumber=001001002001
워낙 유명한 책이라 따로 책소개를 하지 않아도 될 것 같네요. 웹 개발자가 아니더라도 한 번쯤은 읽어보시길 추천합니다. 네트워크의 개념, 생성, 진화 등을 다룹니다.

성공적인 온라인 커뮤니티 구축 전략
http://www.yes24.com/Goods/FTGoodsView.aspx?goodsNo=182347&CategoryNumber=001001003001004
커뮤니티의 기초적인 개념부터 이해하기 좋은 책입니다. 커뮤니티에 관련된 일을 하고 있다면 꼭 읽어봐야하는 책이라고 생각하는데.. 절판입니다 -ㅅ-;;
안산 도서관에는 있네요. 웹 관련 공부하실 분들은 꼭 읽어보세요.

인포메이션 아키텍처 : 웹사이트 설계의 법칙
http://www.yes24.com/Goods/FTGoodsView.aspx?goodsNo=360987&CategoryNumber=001001003001004
싸이월드를 기획했던 이람씨가 쓴 책이죠. 국내서로써 드물게 기획과 개발 프로세스 사이에 있는 '인포메이션 아키텍트'라는 포지션에 대한 내용을 담고 있습니다. 이 것도 추천.

개발 관련 서적은 안넣습니다. 넣기 시작하면 너무 방대해서..

그리고 마케팅쪽 서적도 읽어보면 도움이 많이 됩니다. 많이도 아니고 유명한 몇몇개.. '포지셔닝'이나 '보랏빛 소가 온다(퍼플카우)', '블루오션' 이런 것들이요.

김중태씨의 시맨틱웹 : 웹2.0 시대의 기회 라는 책도 추천을 많이 하더군요. 제목때문에 서점에서 몇장 넘겨보았는데.. 서문에서도 언급하듯이 일반인 대상으로 쓴 책입니다. 그렇다고 얻을게 없는건 아니기 때문에 시간 되면 읽어보려고 합니다.

크리에이티브 커먼즈 라이센스
Creative Commons License
2008/06/28 23:21 2008/06/28 23:21
Tag

http://zeru.kr/blog/trackback/429

댓글을 남겨주세요

Name *

Password *

Link (Your Homepage or Blog)

Comment

Secret