운영시스템과 언어의 동향에 대한 개인적인 생각

RisaPapa의 이미지

제목: 운영시스템과 언어의 동향에 대한 개인적인 생각
작성:RisaPapa

<OS>
현재의 운영시스템 분야는 약동적으로 변화되고 있고 리눅스, 윈도우, 매킨토시등 서로의 분야에서 입지를 확고히 하면서 새로운 시장개척과 사용자 확보에서 치열한 경쟁을 하고 있다. 매킨토시의 경우 최근들어 서버로 사용해도 리눅스이상의 퍼포먼스를 내고 있어 새로운 서버 운영시스템으로도 인정을 받기 시작하고 있다. 그리고 최근에 임베드시스템 분야에서는 리눅스와 윈도우가 치열한 경쟁을 하고 있고 신생 OS들도 시장 공략에 참여하고 있다. 마이크로 소프트가 임베드 시장 공략을 위해 일본산 운영시스템인 트론과 손을 잡고 리눅스와 한판 승부를 걸고 있기도 하다. 앞으로 5년이내에 운영시스템 분야에서는 재미로운 현상이 발생할 것이고 운영시스템의 성숙단계에서는 아주 흥미로운 결과를 가져올 것이라고 생각한다.

운영시스템은 주로 일반 사용자가 많이 사용하는 데스크톱 환경과 서버용도 두가지로 크게 나누어 질것이다. 서버 시장에서만 이야기를 하자면 일반적으로 리눅스가 한판 승부에서 어느정도 선점적인 지위에 서 있는 것은 명백하다. 서버 렌탈 호스팅용의 운영시스템에도 리눅스가 많이 사용이 되지만 렌탈 호스팅 서버의 분야에서는 FreeBSD가 아직도 강세를 나타내고 있는 듯하다. 또한 고가 서버 렌탈 호스팅 분야에서는 아직도 솔라리스가 선호의 대상이 되는 듯하기도 하다. 그러나 서버의 사용이 일반화 되면서 공간을 나누어 사용하는 사용자 보다 서버 한대를 모두 사용하는 서버 렌탈분야가 활성화 되면서 서버 운영시스템으로는 리눅스가 점점 일반화 되어가는 느낌이 든다. 최근에 매니어들이 Power Mac G5를 사용하여 서버를 구축하여 사용하는 것을 보았는데 놀랄만한 성능을 내고 있기도 하다. Win2000서버에서 아파치나 여러 언어들을 튜닝해서 테스팅해보면 성능면에서는 리눅스나 Win2000서버는 비슷하다는 생각이 든다. 실질적인 벤치마크를 해보아도 그렇게 차이는 나지 않는다. 아마 대부분이 같은 환경의 하드웨어라면 서버의 성능면에서는 비슷하다는 결론을 내리게 된다.

리눅스도 상용화가 활발해지면서 인스톨되는 소프트가 점점 윈도우보다도 더 많아 지는 것 같다. 물론 필요한 것들만 인스톨하고 필요한 대몬만 사용하고 튜닝하면 사이즈를 아주 작게도 구성을 할 수가 있기도 한데 이렇게 튜닝하려면 시간이나 경비적인 이유로 디폴트로 인스톨해서 사용하는 사용자들이 거의 대부분이라는 생각이 든다. 그러면서 서버의 종합적인 성능도 차츰 떨어져가는 것이 걱정스럽다. 지난 10월 말부터 11월 초에 있었던 일본 오사카 리눅스2003과 오픈소스 컨퍼런스에 출품(FastCGI관련과 GIS분석용 PHP모듈)하고 여러 강연을 들으면서 이러한 리눅스의 거대화에 따른 성능의 저하에 대한 걱정스런 의견을 많이 들었다. 그런 이유에서인지 미러클리눅스(www.miraclelinux.com) 벤더의 요시오카씨의 강연에서 거대해지는 리눅스 운영시스템에서 커넬과 메모리 관련 소스튜닝과 프로그래밍 기법에 의한 서버 성능의 저하방지 방법등이 주목을 받았고 많은 참가자가 있었다. 그에 의하면 과거의 소프트와 현재의 소프트들을 하드웨어와 실행시간을 비교해 현재의 소프트들의 실행 시간이 너무도 느리다고 말하고 그 이유를 CPU의 스피드는 현저하게 빨라졌는데 메모리에 데이터가 올라가고 메모리와 통신하는 스피드는 전혀 개선되지 않았기 때문이라고 단정하고 이러한 것을 프로그래밍과 튜닝으로 개선하는 방법과 툴을 소개했다. 운영시스템의 거대화는 많은 개발자들과 시스템 엔지니어들이 걱정하는 안건임에는 틀림이 없는 듯하다.

아무튼 운영시스템에서 금후 5년의 판도가 어떻게 날것인지 아주 궁금해진다.

<Language & Interface>
일반 프로그래밍 분야에서 시스템이나 애플리케이션에서 아직도 C/C++은 기본인듯 하다. 자바가 많이 사용이 되면서 일반 애플리케이션에서도 자바가 많이 사용되기도 하는데 버츄얼 머신상에서 움직이는 이유로 스피드면에서는 조금 걸림돌이 되기도 한다. 그외 GUI분야에서는 스크립언어인 TCL/TK라는 언어도 사용이 되는 듯하다. 웹분야의 개발언어는 유행이나 상업적인 마케팅에 의해서 많은 변화가 있었다. 초창기에 C/C++나 Perl로 CGI를 사용했는데 이제는 많이 줄었다. 그러나 아직도 FastCGI인터페이스에서 C/C++과 펄의 성능을 능가하는 언어는 없는 듯하다. CGI의 결정적인 단점인 오버헤드 문제로 아파치등의 웹서버 모듈방식의 언어가 3,4년전부터 아주 각광을 받아오면서 PHP가 급격히 웹개발언어로 자리를 잡아왔다. 자바도 초창기에는 CGI로 개발을 하기도 했는데 FastCGI와 같은 원리의 서블릿이라는 것이 일반화 되고 JSP가 일반화 되면서 급격히 자바로 웹개발을 하는 사이트가 늘어갔고 수많은 API를 제공하므로서 강력한 웹 개발 언어로 자리를 잡았다. 그외 파이썬, TCL, Ruby등등 수많은 언어로 웹이 개발되기도 한다. 그러나 일반적인 개발 언어는 PHP>JAVA>PERL>C>PHYTHON>TCL 순인것 같다. 많은 사람들이 C언어로 웹을 개발하는 바보가 있는냐고 반문을 할지 모르지만 아직도 C언어로 개발되는 사이트는 많고 자주 본다. 이유는 아직도 프로그래밍 언어로 가장 사용자수가 많은 것이 C언어이기 때문이다.

웹에서 인터페이스는 이제 모듈방식언어나 ASP방식이 기본이 되어 가는 듯하다. CGI방식은 부하가 많이 걸리지 않는 곳에서는 앞으로도 계속해서 사용될 것이지만 점점 사용이 줄어들 것이다. 최근들어 FastCGI의 개발자 메일링리스트가 아주 활발한데 금후 FastCGI도 주목을 받게 될 인터페이스로 예상이 된다. 이유는 일반 모듈방식이나 ASP의 경우에는 오버헤드의 문제점은 없지만 한번 실행이 될 때마다 실행 시키기위해서 실질적으로 필요한 함수만 로드되는 것이 아니라 필요없는 함수까지도 일단 모두 로드되기 때문에 그만큼 손실이 발생하기 때문이다. 예를 들어 5K정도의 PHP스크립을 실향 시키기 위해서 2MB정도의 PHP모듈을 로드해야만 하기 때문이다. FastCGI에서 펄과 PHP의 차이점이 이것이다. 펄의 경우에는 필요한 함수만 처음에 컴파일이 되어 메모리에 로드되지만 PHP는 PHP모듈자체가 모두 로드되고 실행시에도 그만큼 손실이 발생하게 된다. 펄과 PHP를 FastCGI에서 실행해 보면 현저하게 PHP의 스피드가 떨어지는 것이 이러한 이유에서이다. 펄 역시 실행시키기 위해 로드되는 바이트수가 꽤 되는데 더 퍼포먼스를 향상시키기 위해서는 C언어를 사용하면 로드되는 바이트수가 현저하게 줄어 들고 그로인해 스피드도 많이 개선되기도 한다. FastCGI가 요즘 주목을 받기 시작하는 이유는 점점 통신 스피드가 빨라지고 사용자 수가 급격히 많아져서 모듈방식의 언어나 ASP로 처리해도 한계에 다달하는 경우가 많이 발생하기 때문이다. 또 모듈방식으로 개발했을 경우 부하를 분산시키려고 해도 마땅한 해결책을 찾기가 힘들고 로드밸런서를 도입하려면 적어도 천만원대의 하드웨어 비용이 들어간다. 현재 PHP도 FastCGI로 작동을 하고 지원을 하고 있는데 이유는 이러한 분산 시스템을 쉽게 구축할 수가 있기 때문이다. 아직까지도 웹에서 가장 안정적인 인터페이스는 CGI이기 때문에 이 CGI에 오버헤드만 해결해 주는 FastCGI방식이 CGI처럼 안정적이기 때문에 최근에 IIS에서 PHP를 운영할 때에 FastCGI방식을 추천하는 이유이기도 하다.

PHP는 앞으로도 계속해서 발전할 것이고 FastCGI방식도 안정적으로 작동을 하기 때문에 분산시스템에서도 그 힘을 발휘하리라고 본다. 또한 대기업들도 PHP에 뛰어들고 있기 때문에 세계적으로도 웹개발언어로 확고히 자리를 잡을 것이고 대부분의 사이트가 PHP상에서 돌아갈 것이라고 예상이 된다. 그리고 PHP의 FastCGI를 이용한 분산시스템 구축도 각광을 받는 분야로 정립이 될 가능성을 내재하고 있기도 하다. 한국의 많은 개발자들이 PHP의 수 많은 공개 소스로 인해 비관을 하기도 하는데 다른 언어들도 마찬가지라고 생각을 한다. 사실 C언어의 경우에는 더 이상 개발될 것이 없을 정도로 거의 대부분이 개발이 되었고 모두 공개가 되었다는 생각이 든다. 물론 펄도 마찬가지이다. 앞으로 더많은 공개소스가 나올 것이고 PHP5 안정버전이 나오게 되면 자바 API개념의 클래스를 사용하는 것처럼 더욱더 쉽게 사용을 할 수가 있고 더욱더 활성화 될것이라고 예상이 된다.

펄은 현재 5.8.1버전까지 나와 있는데 FastCGI가 활성화 될경우에는 이전의 CGI로 펄을 사용할 정도까지는 되지 못해도 새롭게 많이 사용될 언어가 되리라고 생각이 된다. 현재 모드펄이 어느정도 안정적으로 작동이 되고 있지만 메모리를 많이 사용하는 문제점이나 사용하기에 조금 어렵다는 이유로 경원시 되고 있기는 하다. 5.8.0버전은 아주 실패한 버전으로 생각이 된다. 이유는 유니코드 지원으로 인해 많은 변화가 있었고 이것으로 인해 많은 버그를 생성해낸 버전이다. 5.8.1버전은 대부분의 모듈과 라이브러리를 컴파일해서 테스트를 해보면 5.8.0버전에서 있었던 버그들이 많이 개선이 되었고 특히 메모리 리크 버그가 개선이 되어 아주 안정적이다. 아직까지 펄은 세계적으로도 범용언어이고 Perl/TK에의한 GUI개발에서 부터 시스템 관리툴 그외 웹어드민등 기본 시스템 소프트들이 아직도 펄에 의해서 많이 개발되고 있다. 차후 펄을 기본으로 하는 버추얼 머신인 패럿의 동향이 주목되고 있기도 하다.

자바는 1.4.X버전에서 많은 스피드의 향상이 있었고 톰캣의 현재 안정버전인 4.1.29버전에서의 서블릿과 JSP의 실행 스피드가 놀랄만큼 향상이 있었다. 모바일환경에서도 점점 자바의 성능이 향상이 되고 있기도 하다. 모바일 환경에서는 BREW라는 새 언어도 있는데 금후 모바일 환경에서의 경쟁언어로 부각할 것이라고 생각된다. PHP와 함께 자바는 계속해서 발전할 것이고 엔터프라이즈 기반에서는 지금 보다도 더욱더 자바의 입김이 세어질것이라고 생각을 한다. 스피드면에서 향상이 되었지만 운영시스템과 마찬가지로 자바 역시 서버에서는 점점 복잡해지고 로드되는 기본 라이브러리(클래스)가 많아 지고 거대해지면서 스피드의 발목을 잡게 되는데 이러한 해결책이 시급하다는 생각이 된다. 자바 FastCGI를 사용해서 꼭 필요한 클래스만 로드해서 사용할수도 있는데 현재 일본의 코나미의 게임서버에서 퍼포먼스를 위해서 사용이 되고 있다는 소문을 들었다. 자바 분야 역시 FastCGI에 의한 퍼포먼스 튜닝도 재미있는 분야라고 생각한다.

C/C++는 현재의 CPU구조가 변하지 않는한 그 확고한 자리는 영원할것이다. 웹분야에서는 특히 FastCGI에서의 성능은 환상적이다. 최근들어 일본의 모바일 분야에서 급격히 증가하는 억세스수를 감당하지 못해서 여러 방법을 모색하고 있는데 현재로서 이것을 간단하게 해결할 수 있는 유일한 수단이 FastCGI상에서 C/C++로 개발하는 것이다. 모바일 업체에서 이러한 분야의 기술을 한국에서 많이 가지고 있다면 외화 획득에도 한 몫을 할 것이라고 생각된다.

** 개인적으로 많이 관여하는 분야와 개발에 참가하는 분야에 대해서 생각나는 대로 적어 보았습니다. 현재는 주로 리눅스와 FreeBSD기반의 미들웨어와 서버개발 그리고 PHP/JAVA/C등의 API(함수)를 개발하고 있습니다. 가끔 바쁠 때는 PHP/JAVA/C/PERL로 웹이나 모바일 분야의 개발도 하고 있습니다. 아직 윈도우용 액티브펄은 5.8.1 버전이 나오지 않았는데 개인적으로 액티브펄보다 더 많은 라이브러리(GDBM_File, DB_File, GD, ImageMagick, Net-SSL, DBD-MySQL, DBD-Oracle, DBD-PG, TK등등 대부분의 모듈을 지원)를 지원하는 펄 디스트리뷰션을 작성했는데 관심이 있으신분들은 쪽지 주시면 개인적으로 다운로드할 수있도록 하거나 필요한 분이 많이 계시면 다음주에 이곳에 업로드해 놓겠습니다.

죠커의 이미지

G5는 사양이나 가격이나 그럴만 하지 않나요? (..)

64bit cpu는 pc환경에서 찾기 힘들텐데요. 스펙도 1.6GHZ부터 시작하고 가격도 300만원 내외의 컴퓨터니깐요.

펄 FastCGI가 PHP보다 빠르다는 것은 흥미롭네요. FastCGI가 좋다는 건 들었지만 그 정도였는지

choissi의 이미지

Quote:
웹에서 인터페이스는 이제 모듈방식언어나 ASP방식이 기본이 되어 가는 듯하다. CGI방식은 부하가 많이 걸리지 않는 곳에서는 앞으로도 계속해서 사용될 것이지만 점점 사용이 줄어들 것이다. 최근들어 FastCGI의 개발자 메일링리스트가 아주 활발한데 금후 FastCGI도 주목을 받게 될 인터페이스로 예상이 된다. 이유는 일반 모듈방식이나 ASP의 경우에는 오버헤드의 문제점은 없지만 한번 실행이 될 때마다 실행 시키기위해서 실질적으로 필요한 함수만 로드되는 것이 아니라 필요없는 함수까지도 일단 모두 로드되기 때문에 그만큼 손실이 발생하기 때문이다. 예를 들어 5K정도의 PHP스크립을 실향 시키기 위해서 2MB정도의 PHP모듈을 로드해야만 하기 때문이다.

RisaPapa님, 말씀하신 대로 php를 실행하기 위해서는 2메가 정도의
모듈이 로딩 되어야 한다고 쳐도.. 이것은 처음 실행할 때의 문제이지
이미 한번 로딩 된후라면 그리 문제될 내용이 아니라고 봅니다.

또 공유 라이브러리이기 때문에 아파치의 prefork 방식으로 인해
여러 프로세스가 실행되어도 실제로 점유하는 메모리는 그리 많지 않습니다.

Quote:
PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND
3677 nobody 9 0 9956 9956 7720 S 0 0.0 1.9 0:02 httpd
3678 nobody 9 0 10040 9.8M 7736 S 0 0.0 1.9 0:02 httpd
3679 nobody 9 0 10184 9.9M 7736 S 0 0.0 1.9 0:02 httpd
3680 nobody 9 0 10056 9.8M 7728 S 0 0.0 1.9 0:02 httpd
3681 nobody 9 0 9980 9980 7740 S 0 0.0 1.9 0:02 httpd
3694 nobody 9 0 10012 9.8M 7728 S 0 0.0 1.9 0:02 httpd
3695 nobody 18 0 9928 9928 7736 S 0 0.0 1.9 0:02 httpd
3696 nobody 9 0 10004 9.8M 7736 S 0 0.0 1.9 0:03 httpd
3697 nobody 9 0 10036 9.8M 7720 S 0 0.0 1.9 0:02 httpd
3698 nobody 9 0 9928 9928 7756 S 0 0.0 1.9 0:02 httpd
3699 nobody 9 0 10004 9.8M 7736 S 0 0.0 1.9 0:03 httpd
3705 nobody 9 0 9816 9816 7728 S 0 0.0 1.9 0:02 httpd
3706 nobody 9 0 10048 9.8M 7732 S 0 0.0 1.9 0:02 httpd
3707 nobody 9 0 10056 9.8M 7736 S 0 0.0 1.9 0:02 httpd
3734 nobody 9 0 9904 9904 7716 S 0 0.0 1.9 0:02 httpd
3735 nobody 9 0 9968 9968 7732 S 0 0.0 1.9 0:02 httpd
3832 nobody 9 0 9988 9988 7728 S 0 0.0 1.9 0:02 httpd
3833 nobody 9 0 9976 9976 7732 S 0 0.0 1.9 0:02 httpd
3834 nobody 9 0 10012 9.8M 7736 S 0 0.0 1.9 0:03 httpd
8983 nobody 9 0 9664 9664 7724 S 0 0.0 1.8 0:00 httpd

위의 인용은 제가 운영하는 서버의 정보인데 아파치 개별 데몬이
10메가 정도 되어도 공유하는 부분이 7메가 이상이어서 실제 개별 데몬이
점유 하는 메모리 공간은 3메가정도 입니다.

울랄라~ 호기심 천국~!!
http://www.ezdoum.com

blacknblue의 이미지

2메가,5메가짜리 윈도우용 apm 만드신분 아닌가요?
여기서 보게 되네요..

반갑습니다.

이한길의 이미지

오랫만에 리사파파님의 글을 읽게 되는 군요... 너무 반갑습니다.

저는 Gentoo라는 리눅스 베포판을 사용합니다. 직접 빌드하는 것에 매력을 느낀것이 아니라 원하는 만큼만 구성하고 사용할 수 있다는 것을 좋아합니다. 대부분의 리눅스 배포판이 비대한 것에 비해 젠투를 사용하면 깔끔한 환경의 구축이 가능합니다. 처음에는 모든것을 처음부터 구성하는 방법을 고려했지만 그렇게 하는 것은 많은 노력과 시간이 소모되는 일이기에 그만 두었습니다. 하지만 젠투의 스테이지3의 압축을 풀면 대충 그런 효과를 거둘 수 있습니다. 그 뒤로는 emerge와 같은 젠투의 리눅스 패키지 관리 프로그램을 사용하지 않고 필요한것 몇가지만 직접 빌드하면 되니까요. 물론 커널도 그렇게 해야겠지요. 하지만 아직까지는 이보다 이상적인 리눅스 환경을 구성하는 방법이 없는 것 같네요. 여기서 제가 이상적이라 하는 것은 구성하는데 드는 노력과 결과 모두에 대한 이야기 입니다.

하지만 앞으로 데스크탑 환경에 있어서 MS의 입지는 쉽게 줄어들지 않을 거라는 생각이 듭니다. 일반 사용자들의 경우 OS는 윈도우즈만 있는 줄 아는 경우도 허다하며 또 다른 OS가 있는 줄 알고 설치를 시도하다가도 또 설치를 성공했더라도 곧 포기 하고 맙니다. 편리성을 추구하기 때문이지요. 하지만 서버쪽은 조금 다르다고 생각됩니다. 제가 만든 sqlDBMS가 필요없는 PHP게시판을 테스트하는데 일반 계정과 어느분이 잠시 사용할 수 있도록 해주신 계정과 제 개인 컴퓨터와 너무나 큰 속도 차이를 보였습니다. 제 개인 컴퓨터와 일반 제 홈페이지 계정 속도는 비슷했는데 어느분이 잠시 사용할 수 있도록 해주신 계정은 사양이 상당히 낮음에도 훨씬 빠른 속도를 보였습니다. 여쭤본 결과 리눅스를 사용하는데 특별히 튜닝한 것도 없고 필요없는것을 모두 제외했다는 것이었습니다. 단적인 예긴 하지만 저는 리눅스의 서버 시장의 가능성은 충분하다고 보고 있습니다. 또 메인 커널만으로는 힘들다 하더라도 레드햇사같은 곳이 유료로 전환하고 본격적으로 시작을 하겠다고 선언 한 이상 충분하다고 보여집니다.

제는 가끔 개인적으로 C++을 대체할 만한 바이너리 코드 생성이 가능한 객체 지향 언어가 필요하다는 생각입니다. 사실 C++을 접한지 그렇게 오래되지도 않았고 제대로 된 프로그래밍을 해보지도 않았지만 C++은 위험적인 요소나 불필요한 요소를 많이 포함하고 있다고 생각됩니다. 제가 말하는 위험적인 요소는 프로그램 설계를 할때 후에 유지 보수면을 함께 고려하는 것이 쉽지 않고 한번 결정한 것으로 인해 유지보수를 할 수 없어 페기할수밖에 없는 최악의 상황이 나오지 않을까 하는 염려입니다. 아직까지 실력이 부족한 탓인지도 모르겠습니다. 반면에 C의 구문은 상대적으로 단순하고 특별히 고려해줄 필요가 없습니다. 하지만 C++에 비하면 재활용성이 아무리 고려를 하고 구상을 해도 많이 떨어지는 것 같습니다. 두 언어 모두 현재 널리 쓰이고 다른 언어가 굳이 필요할 만큼 나쁘지는 않지만 개선의 여지가 있고 약간 개선되었으면 하는 바램이 있습니다.

개인적으로 자바를 윈시 코드로 컴파일 가능하고 시스템 프로그래밍이 가능해진다면 더욱 널리 쓰이지 않을까 하는 생각도 해봤습니다. 그래서 GCJ에 관심을 갖기도 했습니다. 하지만 그렇게 된다면 더이상 자바 테크놀러지가 아닌 자바 신텍스를 따라한 다른 랭귀지가 되겠지요. 아무튼 자바는 신텍스부터 매우 잘 설계된 언어이며 JVM위에서 속도가 개선된다면 어플리케이션 부분까지도 사용이 가능하다고 생각됩니다. 물론 지금도 안되는 것은 아니지만요...

----
먼저 알게 된 것을 알려주는 것은 즐거운 일이다!
http://hangulee.springnote.com
http://hangulee.egloos.com

우수한의 이미지

이제 ocaml을 공부하려고 하는 초보입니다.
혹시 ocaml로 작성되고 컴파일된 바이너리를 FastCGI에 올려서 사용할 수는 없을까요?

--[추가]--
켁! 한밤에 자다 일어나 뜬금없는 질문을 했네요. :oops:

우수하지 않아요. '우수한'은 옛날 만화 CityHunter에서 따와서 쓰던 별명. ;-)

redbaron의 이미지

RisaPapa wrote:
제목: 운영시스템과 언어의 동향에 대한 개인적인 생각
작성:RisaPapa

<OS>
운영시스템은 주로 일반 사용자가 많이 사용하는 데스크톱 환경과 서버용도 두가지로 크게 나누어 질것이다. 서버 시장에서만 이야기를 하자면 일반적으로 리눅스가 한판 승부에서 어느정도 선점적인 지위에 서 있는 것은 명백하다. 서버 렌탈 호스팅용의 운영시스템에도 리눅스가 많이 사용이 되지만 렌탈 호스팅 서버의 분야에서는 FreeBSD가 아직도 강세를 나타내고 있는 듯하다. 또한 고가 서버 렌탈 호스팅 분야에서는 아직도 솔라리스가 선호의 대상이 되는 듯하기도 하다. 그러나 서버의 사용이 일반화 되면서 공간을 나누어 사용하는 사용자 보다 서버 한대를 모두 사용하는 서버 렌탈분야가 활성화 되면서 서버 운영시스템으로는 리눅스가 점점 일반화 되어가는 느낌이 든다. 최근에 매니어들이 Power Mac G5를 사용하여 서버를 구축하여 사용하는 것을 보았는데 놀랄만한 성능을 내고 있기도 하다. Win2000서버에서 아파치나 여러 언어들을 튜닝해서 테스팅해보면 성능면에서는 리눅스나 Win2000서버는 비슷하다는 생각이 든다. 실질적인 벤치마크를 해보아도 그렇게 차이는 나지 않는다. 아마 대부분이 같은 환경의 하드웨어라면 서버의 성능면에서는 비슷하다는 결론을 내리게 된다.

아무튼 운영시스템에서 금후 5년의 판도가 어떻게 날것인지 아주 궁금해진다.

<Language & Interface>
일반 프로그래밍 분야에서 시스템이나 애플리케이션에서 아직도 C/C++은 기본인듯 하다. 자바가 많이 사용이 되면서 일반 애플리케이션에서도 자바가 많이 사용되기도 하는데 버츄얼 머신상에서 움직이는 이유로 스피드면에서는 조금 걸림돌이 되기도 한다. 그외 GUI분야에서는 스크립언어인 TCL/TK라는 언어도 사용이 되는 듯하다. 웹분야의 개발언어는 유행이나 상업적인 마케팅에 의해서 많은 변화가 있었다. 초창기에 C/C++나 Perl로 CGI를 사용했는데 이제는 많이 줄었다. 그러나 아직도 FastCGI인터페이스에서 C/C++과 펄의 성능을 능가하는 언어는 없는 듯하다. CGI의 결정적인 단점인 오버헤드 문제로 아파치등의 웹서버 모듈방식의 언어가 3,4년전부터 아주 각광을 받아오면서 PHP가 급격히 웹개발언어로 자리를 잡아왔다. 자바도 초창기에는 CGI로 개발을 하기도 했는데 FastCGI와 같은 원리의 서블릿이라는 것이 일반화 되고 JSP가 일반화 되면서 급격히 자바로 웹개발을 하는 사이트가 늘어갔고 수많은 API를 제공하므로서 강력한 웹 개발 언어로 자리를 잡았다. 그외 파이썬, TCL, Ruby등등 수많은 언어로 웹이 개발되기도 한다. 그러나 일반적인 개발 언어는 PHP>JAVA>PERL>C>PHYTHON>TCL 순인것 같다. 많은 사람들이 C언어로 웹을 개발하는 바보가 있는냐고 반문을 할지 모르지만 아직도 C언어로 개발되는 사이트는 많고 자주 본다. 이유는 아직도 프로그래밍 언어로 가장 사용자수가 많은 것이 C언어이기 때문이다.

웹에서 인터페이스는 이제 모듈방식언어나 ASP방식이 기본이 되어 가는 듯하다. CGI방식은 부하가 많이 걸리지 않는 곳에서는 앞으로도 계속해서 사용될 것이지만 점점 사용이 줄어들 것이다. 최근들어 FastCGI의 개발자 메일링리스트가 아주 활발한데 금후 FastCGI도 주목을 받게 될 인터페이스로 예상이 된다. 이유는 일반 모듈방식이나 ASP의 경우에는 오버헤드의 문제점은 없지만 한번 실행이 될 때마다 실행 시키기위해서 실질적으로 필요한 함수만 로드되는 것이 아니라 필요없는 함수까지도 일단 모두 로드되기 때문에 그만큼 손실이 발생하기 때문이다. 예를 들어 5K정도의 PHP스크립을 실향 시키기 위해서 2MB정도의 PHP모듈을 로드해야만 하기 때문이다. FastCGI에서 펄과 PHP의 차이점이 이것이다. 펄의 경우에는 필요한 함수만 처음에 컴파일이 되어 메모리에 로드되지만 PHP는 PHP모듈자체가 모두 로드되고 실행시에도 그만큼 손실이 발생하게 된다. 펄과 PHP를 FastCGI에서 실행해 보면 현저하게 PHP의 스피드가 떨어지는 것이 이러한 이유에서이다. 펄 역시 실행시키기 위해 로드되는 바이트수가 꽤 되는데 더 퍼포먼스를 향상시키기 위해서는 C언어를 사용하면 로드되는 바이트수가 현저하게 줄어 들고 그로인해 스피드도 많이 개선되기도 한다. FastCGI가 요즘 주목을 받기 시작하는 이유는 점점 통신 스피드가 빨라지고 사용자 수가 급격히 많아져서 모듈방식의 언어나 ASP로 처리해도 한계에 다달하는 경우가 많이 발생하기 때문이다. 또 모듈방식으로 개발했을 경우 부하를 분산시키려고 해도 마땅한 해결책을 찾기가 힘들고 로드밸런서를 도입하려면 적어도 천만원대의 하드웨어 비용이 들어간다. 현재 PHP도 FastCGI로 작동을 하고 지원을 하고 있는데 이유는 이러한 분산 시스템을 쉽게 구축할 수가 있기 때문이다. 아직까지도 웹에서 가장 안정적인 인터페이스는 CGI이기 때문에 이 CGI에 오버헤드만 해결해 주는 FastCGI방식이 CGI처럼 안정적이기 때문에 최근에 IIS에서 PHP를 운영할 때에 FastCGI방식을 추천하는 이유이기도 하다.

PHP는 앞으로도 계속해서 발전할 것이고 FastCGI방식도 안정적으로 작동을 하기 때문에 분산시스템에서도 그 힘을 발휘하리라고 본다. 또한 대기업들도 PHP에 뛰어들고 있기 때문에 세계적으로도 웹개발언어로 확고히 자리를 잡을 것이고 대부분의 사이트가 PHP상에서 돌아갈 것이라고 예상이 된다. 그리고 PHP의 FastCGI를 이용한 분산시스템 구축도 각광을 받는 분야로 정립이 될 가능성을 내재하고 있기도 하다. 한국의 많은 개발자들이 PHP의 수 많은 공개 소스로 인해 비관을 하기도 하는데 다른 언어들도 마찬가지라고 생각을 한다. 사실 C언어의 경우에는 더 이상 개발될 것이 없을 정도로 거의 대부분이 개발이 되었고 모두 공개가 되었다는 생각이 든다. 물론 펄도 마찬가지이다. 앞으로 더많은 공개소스가 나올 것이고 PHP5 안정버전이 나오게 되면 자바 API개념의 클래스를 사용하는 것처럼 더욱더 쉽게 사용을 할 수가 있고 더욱더 활성화 될것이라고 예상이 된다.

펄은 현재 5.8.1버전까지 나와 있는데 FastCGI가 활성화 될경우에는 이전의 CGI로 펄을 사용할 정도까지는 되지 못해도 새롭게 많이 사용될 언어가 되리라고 생각이 된다. 현재 모드펄이 어느정도 안정적으로 작동이 되고 있지만 메모리를 많이 사용하는 문제점이나 사용하기에 조금 어렵다는 이유로 경원시 되고 있기는 하다. 5.8.0버전은 아주 실패한 버전으로 생각이 된다. 이유는 유니코드 지원으로 인해 많은 변화가 있었고 이것으로 인해 많은 버그를 생성해낸 버전이다. 5.8.1버전은 대부분의 모듈과 라이브러리를 컴파일해서 테스트를 해보면 5.8.0버전에서 있었던 버그들이 많이 개선이 되었고 특히 메모리 리크 버그가 개선이 되어 아주 안정적이다. 아직까지 펄은 세계적으로도 범용언어이고 Perl/TK에의한 GUI개발에서 부터 시스템 관리툴 그외 웹어드민등 기본 시스템 소프트들이 아직도 펄에 의해서 많이 개발되고 있다. 차후 펄을 기본으로 하는 버추얼 머신인 패럿의 동향이 주목되고 있기도 하다.

C/C++는 현재의 CPU구조가 변하지 않는한 그 확고한 자리는 영원할것이다. 웹분야에서는 특히 FastCGI에서의 성능은 환상적이다. 최근들어 일본의 모바일 분야에서 급격히 증가하는 억세스수를 감당하지 못해서 여러 방법을 모색하고 있는데 현재로서 이것을 간단하게 해결할 수 있는 유일한 수단이 FastCGI상에서 C/C++로 개발하는 것이다. 모바일 업체에서 이러한 분야의 기술을 한국에서 많이 가지고 있다면 외화 획득에도 한 몫을 할 것이라고 생각된다.

** 개인적으로 많이 관여하는 분야와 개발에 참가하는 분야에 대해서 생각나는 대로 적어 보았습니다. 현재는 주로 리눅스와 FreeBSD기반의 미들웨어와 서버개발 그리고 PHP/JAVA/C등의 API(함수)를 개발하고 있습니다. 가끔 바쁠 때는 PHP/JAVA/C/PERL로 웹이나 모바일 분야의 개발도 하고 있습니다. 아직 윈도우용 액티브펄은 5.8.1 버전이 나오지 않았는데 개인적으로 액티브펄보다 더 많은 라이브러리(GDBM_File, DB_File, GD, ImageMagick, Net-SSL, DBD-MySQL, DBD-Oracle, DBD-PG, TK등등 대부분의 모듈을 지원)를 지원하는 펄 디스트리뷰션을 작성했는데 관심이 있으신분들은 쪽지 주시면 개인적으로 다운로드할 수있도록 하거나 필요한 분이 많이 계시면 다음주에 이곳에 업로드해 놓겠습니다.

그냥 몇가지 잡상(ㅋ)을 공유하고자 하는 의미에서 인용하여 답글을 달아봅니다.

TRON에서 언급하셨는데..앞으로의 컴퓨팅의 대세라고 불리는 소위 "유비쿼터스 컴퓨팅"의 핵심적인 요소가 바로 RTOS..즉 TRON Class의 OS입니다.

전에 언젠가 동경대의 사카무라 켄 교수의 "유비쿼터스 컴퓨팅"에 대한 책을 읽은 적이 있는데..

많은 부분에서 공감을 불러일으키는 글이였습니다. (최근엔 대한민국 국영 TV에서 이를 주제로 방영도..)

그리고 개인적으로 향후 10-15년 정도를 좌우할 것으로 보이는 "그리드"라는 것에 관심이 있어 강연을 들어본적이 있습니다.

결론적으로 BackEnd는 그리드가 그리고 FrontEnd에는 "유비쿼터스"가 득세를 할꺼라고 생각합니다. 물론 모든 End를 Linux가 잡아 갈 수도 있지만..

현실적으로 많이 힘들꺼라고 생각되고...BackEnd, 즉 그리드 분야도 완전히 장악하지 못하리라고 생각됩니다. 이런 저런 논문을 찾고 강연을 듣고 글들을 찾아보고 생각을 정리해본 결과..

결국, Linux의 위치는 유비쿼터스와 그리드를 이어주는 MiddleEnd 단을 장악하지 않을까 합니다. 구지 Linux가 아니라도 x86기반의 자유로운 OS면 되겠지요...(BSD 계열이건 머건....) 그것도 아마 64bit 컴퓨터의 시대와 비슷하게 그 시대가 올 듯 합니다.

언어와 인터페이스 분야라면 현재도 많은 기술들이 개발되고 있는 분야라서.. 최신/유행이란 단어자체가 크게 의미가 없는 분야라고 생각합니다.

처음에 CGI란 단어를 들었을때는 그것이 C인줄 알았고.. CGI란것을 개념을 잡았다 싶었을때는 Perl이 대세였습니다만.. 올라가니 어느세 ASP,PHP고..이제는 주변에서 저보고 Java를 하라고 종용합니다.

그리고 주변의 많은 사람들로부터 C를 하라고 3년간 종용받았습니다.(울먹) 그리고 아르바이트겸 해서 PHP/ASP를 익혔고 각종 서버툴들 덕분에 Perl을 약간 접하고 이런저런 수업 과제로 Java와 C++, C#을 배우고 있습니다. 하지만 역시나 말씀하신대로..기본은 C와 C++인듯 합니다. (개인적으로 매우 공감합니다)

이것이 근 5년간 격은 변화입니다. 무엇이든 최신이라던가 유행이라던가 라고하기에는 조금 조심스러워 지는 분야가 아니겠습니까?(인터넷이란 각자의 개성이 튀는 곳이라서..)

최신이라는 것이 의미없다는 이유는 C와 C++을 일정수준 이상 다룰수 있게된다면 다른 언어를 흡수하는 것은 그다지 어렵지 않다고 생각합니다. (저의 경우 신택스와 단순구현을 흡수하는 것도 힘듭니다만..ㅋㅋ) 중요한건 기존의 개념위에 새로운 개념(or 구조, 지식 등의 단어로 대체가능한..)을 쌓아올리는게 중요하고 그런 노력들이 이루어져야 한다는 것입니다. 예로드신 FastCGI가 그런 좋은 예가 되겠지요.

역시나 개인적인 취향과 이바닥(쿨럭)의 흐름으로 봐서..Ruby가 한번 득세를 할 듯 합니다. 현재까지 Ruby가 진출한 분야, 그리고 그동안 이룩한 성과를 보았을때..향후 스크립팅 언어를 Python,Perl과 천하삼분지대계를 실현할지도..모르겠습니다. ^^;;(Perl이 위, Python이 오, Ruby가 촉..인가요? 세력권으로만 보자면..)

인터페이스 방식은 제 주변에는 모듈방식은 점점 줄어드는 것 같습니다. 되려 범용성(막쓰기 쉽다는 의미로..)에서 CGI쪽이 다시 각광을 받을지도 모르겠습니다. 말씀하신대로 극단의 "퍼포먼스"가 요구되는 분야가 점점 늘어가고 있고..그렇다는 것은 곧 하드웨어의 대폭적인 세대교체의 시대가 오고 있다는 의미가 될지도 모르겠습니다.

PHP는 뭔가 승패의 기로라고 생각합니다. 4에서 5로의 이전이 순조로와야..앞길이라는 것이 보장되겠지요. 일반적인 경험에 의한 "편견"에 의하면 PHP란 것 자체가 웹에 너무 특화된 감이 있어 조금 불만인 감이 있습니다. ^^;;

결론은 Ruby 만세..(ㅋ)
---
송지석님 덕분에 철자수정이 가능해졌..(쿨럭)

aeronova의 이미지

Quote:
역시나 개인적인 취향과 이바닥(쿨럭)의 흐름으로 봐서..Ruby가 한번 득세를 할 듯 합니다. 현재까지 Ruby가 진출한 분야, 그리고 그동안 이룩한 성과를 보았을때..향후 스크립팅 언어를 Python,Perl과 천하삼분지대계를 실현할지도..모르겠습니다. ^^;;(Perl이 위, Python이 오, Ruby가 촉..인가요? 세력권으로만 보자면..)

논외의 질문이라서 죄송합니다.

ruby가 python에 비해 가지는 장점이 무엇인지요?
python이 못하는데 ruby만이 할 수 있는 그런 예도 좋구요.

얕은 지식으론 둘다 상당히 비슷한 능력(scripting,OOP..)을 가졌고 적용되는 분야 또한 많이 겹칠 것이라 생각됩니다.

현재 python에 만족하고 있지만 ruby 이야기는 잘 들어보기 힘들어서요.

It's better to burn out than to fade away. -- Kurt Cobain.

redbaron의 이미지

aeronova wrote:

논외의 질문이라서 죄송합니다.

ruby가 python에 비해 가지는 장점이 무엇인지요?
python이 못하는데 ruby만이 할 수 있는 그런 예도 좋구요.

얕은 지식으론 둘다 상당히 비슷한 능력(scripting,OOP..)을 가졌고 적용되는 분야 또한 많이 겹칠 것이라 생각됩니다.

현재 python에 만족하고 있지만 ruby 이야기는 잘 들어보기 힘들어서요.

파이썬에 대해 잘 알지 못해서 깊이있는 답변은 힘들지 몰라도..

보신대로 "분야"와 "비슷한 능력"은 비슷합니다.

먼저 언어자체(인터프린터 프로그램)로만 보자면 파이썬은 대단히 실용적인 언어입니다. 개념이나 문법등등에서 Ruby가 아니였으면 저도 python을 선택했겠지요.(취미로써의 언어로..)

일단.. Ruby는 후발주자..라는 장점을 가지겠죠. 국내에서는 그 저변이 "극히" 열악한 형편이지만..일본(예전)에서 개발되고 지금은 세계적으로 뻗어나가고 있고..Debian이나 FreeBSD 쪽에서 적극 채용(일본식 표현)되고 있는 듯합니다.

언어적 특징이라면 Python보다 조금 더 "사용하기 쉽게" 객체지향화 된 것이고 조금 더 Perl을 닮아 있습니다. Python이 Perl을 닮았다고 말하기는 힘들겠지요.. :)

각 언어의 장단점에대해서는 뭐라고 말씀드리기 힘듭니다. 두 언어가 겹치는 분야가 너무 많기때문에..실제 해외 Ruby 커뮤니티에서도 종종 나오는 말이.. Python이 있는데 "왜 Ruby를 사용하나?"입니다... :shock:

그런 질문에 관해서라면..그냥 Ruby도 충분히 "프로그래밍의 재미"를 느낄수 있기때문에..라고 뿐 다른 구체적인 대답은 힘듭니다.. :D

(뭔가 구체적인 답변을 드리지 못해 죄송..)

nohmad의 이미지

ruby는 흔히 perl의 텍스트 처리 능력 위에 OO를 쌓아놓은 언어라고들 합니다. 이 두가지면 스크립트 언어에 필요한 것은 다 갖춘 것 아닌가요? :)

ruby의 약점이라고 하면, 일본에서 개발되어 상대적으로 문서가 적고, 영어에 익숙한 사용자들에게 약간의 거리감을 준다는 점인 것 같습니다

미국에 있느냐 없느냐는 생각보다 중요한 문제입니다. 대부분의 중요한 개발은 영어권에서 이루어지는 것을 감안하면 말입니다. 토발즈도 현재 미국에 있고, 파이썬의 귀도 반 로썸도 미국에 있습니다.

파이썬의 Guido Van Rossum을 보면, 개발자 컨퍼런스를 돌아다니며 홍보 대사 역할을 하고, 본인이 직접 어플리케이션 개발에 뛰어들어 파이썬 개발자들에게 하나의 귀감이 되고 있습니다. 펄의 Larry Wall도 숱한 명언들을 남기며 으픈소스 진영의 열광적인 지지를 얻어냈지요.

ruby의 창시자는 너무 학자 스타일이랄까, 그래서 우수한 특징을 가졌음에도 상대적으로 홍보기회가 적어 덜 알려진 게 아닐까 하는 개인적인 생각입니다.

파이썬의 장점은 일단 이미 크게 대중화되어 win32 환경에서 VB를 위협할 정도의 강력한 지원세력들의 존재(win32 환경에서는 이미 perl을 제낀 것 같습니다), C API와의 매끄러운 결합, 인터랙티브 인터프리터를 함께 배포하는 전략(저는 이것이 언어 진입의 초기 장벽을 깨는데 있어 상당히 중요한 역할을 한다고 생각합니다) 같은 걸 들 수 있을 것 같습니다.

파이썬이든 루비든 일정한 사용 수준에 도달하는 것이 크게 어렵지 않기 때문에 꼭 하나를 배제하는 택일을 할 필요는 없을 것 같습니다. 하나를 깊이 들어가면 다른 하나도 배우는데 크게 어렵지 않을 것 같습니다.

morning의 이미지

오랫만에 리사파파님의 내공이 실린 글 잘 읽어 보았습니다.
좋은 글을 읽고 저도 나름대로 간단한 개략적 느낌을 적어봅니다.

[OS]
앞으로 중요성은 나날이 줄어 들 것으로 생각합니다.
물론 이 뒤에는 OS개발자들의 노고는 더욱 늘어난다는 것을 전제 됩니다.
OS 들이 각자 단점을 보안하고 개선하다 보면
결국 비슷한 성능, 특징을 갖게 될 것이라고 생각합니다.
항상 논란이 되는 OS와 DBMS 성능 테스트를 한다는 것이
좋은 근거가 된다고 생각합니다.
비로 일부이긴 하지만 임베디드 솔루션을 개발하면선
어떤 OS를 선택할까 고민 할 수 있는 시대도 왔구요.

[어플리케이션]
지금 대부분의 OS에서 돌아가는 프로그램들의 역활이 비슷하죠.
서버라면 DBMS, 웹서버, 소켓 서버, 파일 서버..
PC라면 웹브라우즈, 문서 편집기, 그래픽 편집기, 멀티 미디어 기기...
더 눈여겨 볼 것은 동일한 이름의 어플리케이션이 각기 다른 OS에서
구동되는 모습을 더욱 자주 볼 수 있다는 것입니다.

[개발 수단]
개발 언어 선택도 참 '프리'합니다.
서버쪽에서 C로 제작하던 것을 C++, Python, Perl...로 바꿀 수 있고
가장 빈번한 웹프로그램의 경우를 보면 PHP, ASP, JSP, Perl, C... 거의 취향에
가까운 선택을 할 수 있습니다.

재미난 이야기를 하나하면,
제가 직장다니던 시절에 PHP애호가 여서 PHP로
클러스터링과 로드밸런싱(서버 생존유뮤, CPU, 메모리, 접속자, 네트워 사용량 모두 체크해서...)도 짜보았습니다.

[결론?]
특별한 결론은 없고 그냥 느낌을 적었는데 구지 결론을 내면,
'기획과 설계가 중요하다.' 뭐 대충 이런이야기 입니다.

조르바와 함께 춤을....

송지석의 이미지

redbaron wrote:

전에 언젠가 동경대의 다카무라 켄 교수(이름이 정확히 기억이..)의 "유비쿼터스 컴퓨팅"에 대한 책을 읽은 적이 있는데..
사카무라 겐 교수입니다.
음. 위키였으면 참 좋겠다는 생각이 드는...