한빛출판네트워크

저자: 데이브 크로스, 역 서성용

서론

사람들에게 펄이 다목적 프로그래밍 언어라는 것을 납득시키려는 노력과는 상관 없이 대다수의 프로그래머들이 갖는 첫 번째 펄과의 접촉은 CGI 프로그램에 대한 경험을 통해 이루어지며 이는 누구도 부인할 수 없는 사실이다. 작은 웹 사이트를 가지고 있는 사람이라면 어느날 갑자기 자신의 웹사이트에 방명록, 폼메일 스크립트나 히트 카운터가 필요하다고 생각할 수도 있다. 그렇지만 이들은 프로그래머가 아니기 때문에 프로그램을 개발하기 보다는 이미 웹에 올라간 스크립트를 찾아보는 경우가 더 많다.

이때 참고할 스크립트는 많다. Google에서 "CGI scripts"를 검색 해보자. 필자는 대략 2백만 개의 결과를 얻었다. 여기서 첫 번째 검색 결과 페이지에서 눈에 띠는 "Matt"s Script Archive"와 "CGI Resource Index"처럼 잘 알려진 사이트이다. 대부분의 웹사이트 운영자는 이 사이트 중 하나를 방문할 것이고, 필요한 스크립트를 찾아 자신의 사이트에 설치할 것이다. 이보다 더 간단한 것이 있을까? 여러분도 잘 알겠지만 웹은 자신의 노력여하에 따라 필요한 자료를 얼마든지 쉽게 구할 수 있다.

그렇지만 이 기사에서는 필자가 위에서 묘사했던 것처럼 스크립트를 참고하는 것이 항상 장밋빛이 아님을 보여줄 것이다.

CGI 스크립트 품질

구글이 검색 결과를 출력할 때 고려하는 중요 요소는 주어진 사이트에 대한 링크 수이다. 주어진 웹 페이지로 수많은 링크가 연결되어 있다면, 구글은 그것이 잘 알려진 페이지이기 때문에 구글의 방문객들이 그 사이트를 맨 처음 방문하고 싶어할 것이라고 생각한다.

필자가 이전 단락에서 "잘 알려진"이라고 말한 것에 주목하라. "유용한" 이나 "가치있는"이 아니다. 그러면 이 단어들에 대해 잠시 생각해보자. 필자가 서론에서 언급한 사람은 프로그래머가 아니다. 그렇다면 확실하게 펄 프로그래머도 아니라는 말이다. 그렇기 때문에 이들이 인터넷에서 다운받은 펄 코드의 가치를 판단할 수 없는 것은 어쩌면 너무 당연한 일일 수도 있다.

따라서 "가장 인기있는" 사이트란 말은 자기 만족을 가장 많이 달성한 사이트라는 것을 의미한다. 가장 잘 알려진 사이트는 검색 엔진에서 검색했을 때 첫 번째 목록에 나온다. 그렇기 때문에 상당수의 사람들이 그 사이트에서 스크립트를 다운 받는다. 따라서 가장 인기있는 사이트가 최고 품질의 스크립트를 보유하고 그 결과 그 인기있는 사이트는 마침내 보다 더 많은 인기를 얻게 되리라는 것은 누구든 예상할 수 있다.

하지만 어떤 시점에서든 품질 제어 과정은 고려사항에 들어가야 한다.

		CGI Programming with Perl, 2nd Edition

좋다. 엄격히 말해 아까 한 말은 진실은 아니다. 만약 특정 사이트에서 다운 받은 스크립트가 제대로 동작하지 않는다면 찬사는 떠나고 그 사이트의 스크립트도 인기를 잃는다는 것은 당연한 사실이다. 하지만 문제가 더 미묘해서 모든 사이트에서 이와 같은 조짐이 보이지 않는다면 어떻게 될까? 아래 목록은 몇몇 잠재적인 문제들에 대해 간단하게 언급하였다.

• open 콜의 결과를 검사하지 않는 것. 이것은 예상하는 파일이 존재하고 적절한 퍼미션을 갖고 있을 경우 잘 동작한다. 그러나 그 파일이 존재하지 않으면? 혹은 존재하지만 CGI 프로세스가 그 파일에서 읽거나 그 파일에 쓸 수 있는 퍼미션을 갖고 있지 않다면?
• 불충분한 CGI 파라미터 파싱 코드. CGI 파라미터 파싱은 잘못하기 쉽지만 잘 하기는 어려운 것 중의 하나이다. 대부분의 경우를 처리하는 파서 함수를 작성하는 일이 쉽기는 하지만 GET과 POST 요청을 그 함수가 모두 처리하는가? 다중 관련 값들을 가진 키들은? 그리고 파일 업로드를 정확하게 처리하는가?
• 안전성 결여. CGI 프로그램 설치는 인터넷에 접속한 사람 모두가 서버에 있는 프로그램을 실행하도록 허가하는 것이다. 허가를 허락하는 것이 때로는 정말 위험한 일이 될 수도 있기 때문에 보안 관련 사항에 대해 미리 알고 있는 것이 좋다. 물론 사람들이 항상 HTML 폼에서만 스크립트를 실행한다면 문제가 발생할 소지는 아주 작을 것이다. 하지만 크래커는 그렇지 않다. 크래커는 스크립트의 취약점을 발견하기 위해 스크립트에 파라미터를 위한 "흥미로운" 집합을 발표할 것이다. 갑자기 폼 메일 스크립트는 중요한 시스템 파일들의 사본을 크래커에게 보내는데 사용된다.
  
  또한 이러한 스크립트는 웹에서 얻을 수 있으므로 크래커들은 소스 코드를 쉽게 얻을 수 있다. 그들을 스크립트를 얻은 후 스크립트에 있는 불안정한 점을 찾아내 악용한다. 최근 한 친구의 웹 사이트를 크래커가 공격했는데 접근 로그에 남겨진 자취에는 잘 알려진 CGI 스크립트와 관련된 수많은 호출을 발견할 수 있었다.
  
  이와 같은 이유 때문에 풋내기 웹 마스터가 사용할 CGI 스크립트를 작성할 때에는 특히 보안에 조심해야 한다.

불행하게도 사실 이런 종류의 문제가 대부분의 유명한 CGI 스크립트 저장소에서 다운받은 스크립트에서는 흔하게 일어난다는 것이다. 이것을 보고 스크립트 저자들이 고의로 크래커들에게 서버에 접근을 주기 위해 노력한다고는 말할 수 없다. 1994년 펄 5가 소개된 이후로 많은 사람들이 사용하기 시작했으며 많은 CGI 스크립트 제작자들은 현재의 기법에 맞춰 스크립트를 최신의 것으로 유지하지 않아왔다는 것도 그 증거다. 이외에도 제작자들이 자신의 스크립트가 오래되었는지를 알고 새롭고, 개선된 버전을 만들었지만 다른 사람들이 여전히 이전 버전을 배포하고 있는 경우다.

좋은 예제 설정하기

이러한 스크립트를 내려받는 사람들이 대개 프로그래머는 아니다. 그렇지만 이런 사람들도 가끔씩 프로그램 작동 방식을 바꾸고 싶다거나 심지어 자신만의 CGI 스크립트를 작성하고 싶을 때가 있을 것이다. 이때, 이들은 이미 가지고 있는 스크립트를 새로운 스크립트를 작성할 때에 참고할 예제로 사용할 것이다. 따라서 원래의 스크립트에 나쁜 프로그래밍 기법이 포함되어 있다면 이러한 것들은 새로운 스크립트에 그대로 복사될 것이다. 그래서 필자는 공개적으로 배포된 어떤 프로그램이든지 가능한 한 최고의 프로그래밍 기법을 따르는 것이 좋다고 생각한다.

스크립트 품질 체크 리스트

이제 확실히 우리는 문제를 갖고있다. 이전에도 필자는 이러한 스크립트를 내려받고 설치하는 사람들은 코드 품질에 대한 판단을 내릴 자질이 없는 사람들이라고 말했다. 몇몇의 의심스러운 스크립트가 있다는 가정 하에, 이런 사람들이 웹에서 발견해낸 특정 스크립트를 사용할지 말지를 알 수 있도록 어떻게 지원 받을 수 있겠는가?

대답하기 어렵지만 잘 만들어진 스크립트를 알아볼 수 있는 단서가 없는 것은 아니다.

• 그 스크립트가 -w와 strict를 사용하는가? 대다수의 펄 전문가들은 어떠한 수준의 복잡도를 가진 펄 프로그램을 작성할 때 이러한 도구를 사용할 것을 추천한다. 이 도구들은 펄 프로그램을 보다 강건하게 하며 이것들 없이 펄 프로그램을 배포하는 사람은 누구든지 자신들이 생각하는 만큼 펄을 많이 알고 있는 것은 아니다.
  
  
• 스크립트가 펄의 오염(taint) 모드를 사용하는가? 웹 브라우저에서 외부 자료를 받아들이는 것은 위험한 일이다. 어떤 것을 얻을지 절대로 확신할 수 없기 때문이다. 만약 -T를 프로그램 계획 라인에 추가한다면, 펄은 오염 모드로 간다. 이 모드에서 펄은 외부 소스에서 오는 어떤 데이터든 신뢰하지 않는다. 따라서 이 데이터는 사용 전에 명백하게 체크해야 한다. -T를 사용한다는 것은 제작자가 적어도 CGI 보안 문제에 대해 생각하고 있다는 표시이다.
  
  
• 스크립트가 CGI.pm을 사용하는가? 펄 5.004 이후로, CGI.pm은 표준 펄 배포판의 일부분에 포함되어 있다. 이 모듈은 CGI 프로토콜의 다양한 부분을 다루는데 필요한 여러 개의 함수도 포함하고 있다. 여기서 가장 중요한 것은 아마도 param 일 것인데, 이것은 CGI 파라미터를 추출해내기 위한 질의 스트링의 파싱을 다룬다. 많은 CGI 스크립트들이 자신의 CGI 파라미터 파싱 루틴을 작성하는데, 빠진 기능이 있거나 버그가 있다. CGI.pm 에 있는 것은 여러 해 동안 수천개의 스크립트에서 잘 시험되었다. 그런데 그것을 다시 만들 이유가 있을까?
  
  
• 스크립트는 얼마나 빨리 갱신되는가? 스크립트가 CGI.pm을 사용하지 않는 한 가지 이유는 그 모듈이 펄 배포판에 추가된 이후로 업데이트가 되지 않은 것 일수도 있다. 이는 일반적으로 나쁜 징조라고 볼 수 있다. 따라서 항상 최신으로 유지되는 스크립트를 찾아야 한다. 만약 몇 년 동안 새로운 버전의 스크립트가 나오지 않았다면 그것은 피해야 한다.
  
  
• 지원은 얼마나 좋은가? 어떠한 프로그램이든지 지원되지 않는다면 한정적으로 사용할 수밖에 없다. 프로그램 지원을 어떻게 얻는가? 제작자의 이메일 주소가 있는가? 혹은 지원 메일링 리스트가 있는가? 제작자나 메일링 리스트로 이메일을 보내서 얼마나 빨리 응답을 얻는지를 보라.

물론 이러한 규칙들에도 예외는 있다. 하지만 만약 스크립트가 이것들의 대부분에서 나쁘게 평가된다면 그래도 이 스크립트를 꼭 사용해야 하는지에 대해 다시 한번 생각해 봐야 할 것이다.

nms - 새로운 CGI 프로그램 저장소

지금까지는 기존 CGI 프로그램 저장소들에 대해 아주 부정적으로 말했기 때문에 이제부터는 약간 긍정적으로 입장을 바꾸어 보겠다. 2001년 여름, London Perl Mongers의 한 그룹이 흔히 사용되는 것들을 대체할 수 있는 새로운 CGI 프로그램 모음을 작성하는 과정에서 무엇을 포함해야 할지를 고민했다. 몇몇 토론 후에, nms 프로젝트가 탄생되었다. Nms라는 이름은 원래 기존 저장소중 하나를 비난한다는 내용을 의미했으나, 그때까지 약어로 된 이름이 흔하게 사용되고 있었기 때문에 우리는 그 이름을 계속해서 쓰기로 했다.

nms 의 목표는 아주 단순하다. 우리는 다음과 같은 사항을 이행하는 CGI 프로그램의 모음을 제공하길 원했다.

• 기존 CGI 스크립트로서 사용하기에 쉬운(혹은 보다 쉬운)
• 최고의 프로그래밍 기법을 사용하고
• 안전하고
• 버그가 없을 것(최소한 지원은 잘 되어야 함)

우리는 프로그램을 Matt"s Script Archive에 있는 프로그램에 기반을 두기로 했다. 이것은 Matt Wright 스크립트가 현재 나와있는 것들 중에서 최악이기 때문이 아니라, 단지 그것들이 가장 흔하게 사용되는 것이기 때문이다. 스크립트는 Matt의 스크립트를 위한 즉각적인 대체물로 만들기로 규칙을 정했다. 이것은 Matt의 스크립트를 사용하는 것으로부터 기존 데이터를 갖고 있는 사람이라면 누구나 대체물을 받아 단순하게 예전 스크립트 자리에 그것을 놓기만 해도 된다는 것을 의미한다. 이것은 물론, Matt의 스크립트 내부 작업에 우리가 친숙해져야 한다는 것도 의미한다. 그러나 이것은 실제로 내가 예상했던 것보다는 어렵지 않았다. Matt의 대부분의 스크립트들은 간단했다. 그것은 실제로는 단지 복잡한 폼메일, 방명록 그리고 웹 게시판일 뿐이었다.

때때로 우리가 추구하는 목적이 서로 상충되기도 하였다. 초기에는 가능한 한 사용하기 쉬운 스크립트를 만드는 것이 어떠한 CPAN 모듈에 의존하지는 않는다고 결정했다. 우리 스스로는 오직 표준 펄 배포판의 일부에 딸려오는 모듈만을 사용할 것을 강제했다. 이렇게 한 이유는 우리의 대상 관객이 CPAN 모듈에 대해 아무것도 알지 못할 수 있거나 그것이 설치가 쉽다는 것을 발견하지 못할 것이기 때문이다. 사용자 대다수는 아마도 새로운 모듈을 설치할 수 없으며 많은 경우 그들은 서버에 텔넷 접근도 할 수 없는 호스팅 된 서버에서 웹 사이트를 운영하고 있을 것이다. 우리가 그들에게 추가 모듈을 설치하도록 요구하는 것은 우리 프로그램을 훨씬 더 적게 사용하게 될 것이라 생각된다. 이것은 물론 최고의 프로그래밍 기법을 사용한다는 우리의 목표에 어긋나는데, 많은 경우에 우리가 사용하는 기능을 구현한 CPAN 모듈이 있기 때문이다. 이것의 가장 좋은 예제는 폼메일로 이메일 모듈중의 하나를 이용기보다는 sendmail과 직접 소통함으로써 이메일을 교환한다. 이러한 경우에서, 사람들이 CPAN에 의지하지 않고 우리의 스크립트를 사용하도록 하는 것이 최고의 기법을 따르는 것보다 더 중요하다고 결정했다.

nms 는 SourceFore 프로젝트이다. http://nms-cgi.sourceforge.net에서 최신 버전을 얻을 수 있고, CVS 최신 버전을 수용할 수 있을 정도로 본인이 용감하다고 느낀다면 프로젝트 페이지인 http://sourceforge.net/projects/nms-cgi/에서 최신 버전을 얻을 수 있다. 두 페이지 모두 nms 메일링 리스트로 링크되어 있다. 두 개의 리스트가 있는데, 하나는 개발자를 위한 것이고 다른 하나는 지원 질문을 위한 것이다. 이 외에도 프로젝트와 관련된 추가적인 질문도 대답해줄 FAQ도 있다.

다음은 nms에서 이용할 수 있는 스크립트 목록이다

• Countdown 특정일까지의 시간을 카운트 다운
• Free For All Links 간단한 웹 링크 데이터베이스
• Formmail 웹 폼에서 이메일을 보냄
• Guestbook 간단한 방명록 스크립트
• Random Image 무작위로 이미지를 보여줌
• Random Links 목록에서 무작위로 선택된 링크를 보여줌
• Random Text 텍스트에서 무작위로 선택된 부분을 보여줌
• Simple Search 간단한 웹 사이트 검색 엔진
• SSI Random Image SSI를 이용하여 무작위로 이미지를 보여줌
• Text Clock 시간을 표시함
• Text Counter 텍스트 카운터

필자는 이것이 바로 "진행중인 작업" 이라는 점을 강조해야만 한다. 우리가 그것들의 작동 방식에 기뻐하는 동안, 우리는 보다 많은 사람들이 그 코드를 보고 있다는 점을 언제나 이용할 수 있다. Matt 의 스크립트를 우리 것과 비교할 때 알 수 있는 한가지 장점은 그것들이 다수의 웹 사이트에서 여러 해 동안의 테스팅을 가졌다는 점이다.

도움 요청

이제 우리는 사용자들에게 권장할 수 있는 잘 짜여진 CGI 프로그램 소스를 갖게 되었다. 더 이상 무엇이 필요한가? 물론 이 기사를 쓰는 전체적인 초점은 보다 많은 사람들에게 도움을 요청하기 위함이었다. 언제나 할 일은 많이 있다. :-)

• 동료 집단의 검증 그동안 스크립트와 관련하여 아주 만족스러운 일을 해왔다고 생각하지만, 명예 때문에 한 것은 아니다. 보다 많은 사람들이 스크립트를 들여다볼수록, 버그를 비롯하여 불안정한 점들을 잡아낼 가능성이 높아진다. 스크립트를 다운 받아 자세히 살펴보고 버그를 발견했다면 개발자 메일링에 보내라.
  
  
• 테스팅 우리는 많은 플랫폼에서 가능한 한 많은 설정으로 스크립트를 테스트하지만, 언제나 한 두 가지 정도는 놓치기 마련이다. 시스템에 스크립트를 설치해서 문제가 발생한다면 언제라도 우리에게 알려주기 바란다.
  
  
• 문서화 우리의 문서화는 기존 저장소들의 문서화보다도 훨씬 좋아질 수 있다고 생각한다. 이것으로 돕고 싶다면 우리에게 연락하기를 바란다.
  
  
• 옹호 이것은 가장 중요한 요소이다. 부디 알고 지내는 모든 사람에게 nms에 대한 이야기를 하기 바란다. 다른 CGI 스크립트들을 사용하고 있는 사람들을 만나는 장소에서도 그들에게 잠재적인 문제를 설명하고 어디에서 nms 스크립트를 얻을 수 있는지 보여주어라. 이러한 스크립트를 작성해오면서, 우리는 그것들이 가능한 한 널리 노출되는 것이 중요하다고 느낀다. 만약 nms를 촉진하기 위한 생각이 있다면, 우리에게 알려주기 바란다.

잠시동안 오직 이러한 것들만이 이용할 수 있는 잘 작성된 안전한 CGI 프로그램이라고 주장하지는 않았지만, 나는 펄 공동체가 사람들에게 지적해 줄만한 잘 알려지고 신뢰받는 CGI 프로그램들의 모음이 필요하다고 생각한다. 여러분의 도움과 함께 그것은 바로 내가 nms가 되기를 원하는 것이다.