SW개발자....4

<SW개발자....4>

Taekkyung Lee2011. 11. 14.에 수정  -  공개

이택경
twitter :@kyung88
email : taekkyung{앳}primer.kr

* 이글은 주관적이고 일반화의 오류가 있을수 있다는 점, 그리고 1995년~2003년 기간에 치중되어 현재는 상황이 다를수 있다는점 참고하시고 보시기 바랍니다....

4. 다음에서 SW개발이란.. 

지난회에 이어서..


5) 다음에서 느낀 SI 개발자와 온라인서비스 개발자의 차이점외

앞에서도 이야기했듯이 다음에서 다양한 형태의 개발들을 했었습니다.
초기에는 SI 개발관련한 외부인력들을 빼더라도 다음내에 SI 개발자들이 온라인서비스 개발자들보다 더 많았었고, 한메일 서비스가 본격화되면서 회사의 비젼을 온라인서비스쪽으로 굳히면서 상당수 SI 개발자들을 온라인서비스 개발에 투입을 했습니다.
이때만 하더라도, 아직 초기단계라 SI 개발자들과 온라인서비스 개발자들간에 크게 차이는 없었습니다만, 향후에 시간이 한참 지난뒤 각각 보다 전문화된 구조가 되고 나서는 SI 개발자를 온라인서비스 개발에 투입할때 약간의 시행착오와 장점/단점이 보이더군요.
외부에서 SI 개발을 했던 경력자를 구인하여 온라인서비스 개발에 투입했을때도 비슷한 모습을 보였던것 같습니다.

- SI 개발자
기본적으로 SI 개발은 외부회사의 요구사항에 맞추어 프로젝트를 진행하고 계속회서 회의를 하기에 기본적으로 이러한 커뮤니케이션 능력을 갖춘경우가 많습니다.
SI 개발자가 온라인서비스 개발에 투입되면 서비스 기획자들이 이런면에서 좋아하기도 합니다.
반면에 단점이라면, 온라인서비스의 특성상 잦은주기의 업데이트가 생명이라 SI 프로젝트의 싸이클보다 더 빨라야 하는데 그부분에 익숙하지 못한점입니다. 
SI 프로젝트경우 더 많은 개발요구사항에 더 긴 싸이클을 갖는데 비해, 온라인 서비스는 더 적은 개발요구사항에 더 짧은 싸이클을 갖는 경우가 많죠.
싸이클로 본다면 패키지 > SI 프로젝트 > 온라인서비스 순으로 길지 않나 싶습니다.
물론, 온라인서비스도 서비스나름 차이가 크지만요.

- 온라인서비스 개발자
SI 개발자와 반대로 내부에서 개발자간의 커뮤니케이션에만 치중하는 개발자도 있고, 개인차가 있긴 하지만 일부는 서비스 기획자와 커뮤니케이션을 진행하지만 커뮤니케이션에 훈련이 덜된 경우도 있습니다.
반면에 장점이라면, 노련한 서비스 개발 경력자의 경우 온라인서비스의 특성을 잘 이해하여 서비스기획에 도움을 줄수도 있고 (때론 기획을 주도하기도), 또한 복잡한 비즈니스로직을 가지는 인트라넷시스템에 비해 일반 사용자들을 위한 보다 단순하면서도 대용량 서비스에 적합한 개발에 익숙한다는 점입니다.

- 패키지 개발자, ASP 개발자
초기의 다음의 개발자/엔지니어 조직이 모두 합쳐서 20명이내로 그렇게 크지 않았기에, 별도의 패키지 개발자나 ASP(Application Service Provider 요즘으로 보면 일종의 SaaS) 개발자가 따로 있지는 않았습니다.
패키지 개발의 경우 SI 개발자들중 일부가 일정기간동안 SI개발대신 패키징쪽에 집중을 했었는데, 아마 패키지 개발전문이라면 온라인서비스 개발자처럼 역시 외부 커뮤니케이션 기회가 적을테고, 프로젝트 싸이클은 제일긴편에 속하며, 대신 아키텍쳐나 기타 기술적인측면의 완성도가 높아질 가능성이 크지 않을까 싶습니다.
ASP 개발의 경우도 기존 온라인서비스 개발자들이 겸임해서 한메일 소스코드를 서비스별로 버젼콘트롤 하면서 개발했기에, 온라인서비스 개발과 비슷하다고 보면 되겠습니다. 

개발자가 맡은 시스템 모듈에 따라서도 차이점들이 있습니다. 

- 코어부분을 맡은 개발자는 아무래도 서비스 기획자와 직접 커뮤니케이션하기보다는 다른 개발자가 그 모듈을 이용하기에 그쪽과 커뮤니케이션할 확률이크고, 서비스보다는 기술적인 이해도를 더 필요로 합니다.

- 반면에 어플리케이션쪽 개발자는 서비스에 대한 높은 이해도가 요구되며, 경우에 따라서는 기획에 참여하기도 해야하고, 서비스 기획자와의 커뮤니케이션이 활발해야하죠.

그외 Windows 클라이언트쪽 개발, 웹 프론트엔드쪽 개발, Windows/Unix계열 서버 백엔드쪽 개발 등에 따라 차이도 있고, 또한 Windows 플랫폼에서 주로 개발하는 개발자냐 Unix/Linux 플랫폼에서 주로 개발하는 개발자냐에 따른 개발철학과 스타일의 차이들이 각각 있습니다.
게임쪽 개발자는 직접 매니징해본적은 없지만 또 많이 다른 성향을 가지고 있는듯 하더군요.

다음내에서도 그당시 포털서비스와 쇼핑몰사업부 (현 디앤샵)의 문화적인 차이가 있었고 (개발차원보다는 전반적인 조직차원에서), NHN도 네이버쪽 포털서비스와 한게임사업부간의 문화적인 차이는 다음내의 조직차이보다 더 큰것으로 알고 있습니다.
역시나, HW주력회사와 SW패키지주력 회사, 인터넷서비스 주력회사, 그리고 온라인게임 주력회사간에는 각각 상당한 갭이 있다는 점이죠.

앞에서도 이야기했듯이 개발자의 특성중 하나가, 연봉도 중요하지만 인정받고 본인이 좀더 주인공이 될수있는 조직을 선호하는 경향이 많기에, 개인차가 있긴 하지만 능력있는 개발자일수록 대기업 전산실처럼 지원하는 형태의 개발보다는 SW패키지나 인터넷/온라인게임서비스처럼 좀더 주도적으로 참여할수 있는 조직을 선호하는듯 합니다.

6) 다음에서의 SE팀/인프라본부

다음에 있으면서 느꼈던점은 그당시 국내에 전문 시스템엔지니어(SE)층이 약하다는 점이었습니다.
24시간 인터넷서비스를 전문으로 하기위한 기술과 운영능력은 분명히 개발자와의 영역과는 다른 부분이 있는데, 네트웍 설정이나 튜닝/UPS등 전산센터 셋업 및 관리/24시간 모니터링등이 초기부터 필요했던 부분이지요. 
이러한 부분은 작은조직에서는 개발자가 겸임하는 경우도 많긴 하지만, 다음의 경우 대규모 서비스를 준비하기위해서는 별도로 전문화된 조직이 필요하다는 생각하에 본격적인 포털서비를 하기 이전단계인 비교적 초기부터 관련조직들을 셋업해나갔습니다.

처음에 ISP(Internet Service Provider) 출신 후배를 스카웃해서 이부분을 주로 맡겼었고, 곧바로 SE팀을 셋업하고, 향후엔 인프라본부를 셋업하고 CTO와 별개로 CIO(Chief Information Officer라기 보다는 Chief Infra Officer) 조직을 셋업했었습니다. 
인프라본부는 서버를 설치하고 시스템 튜닝업무를 맡는 SE팀, 네트워크 아키텍쳐 계획/설정/튜닝 및 침입탐지/보완관련된 네트워크팀, 서비스 개발시 DB 스키마 설계 및 튜닝관련된 전문 DBA(DataBase Administrator)들로 구성된 DB기술팀, 개별 시스템의 부하와 장애등을 모니터링하는 시스템운영팀, 사내 인트라넷 시스템을 개발하고 관리하는 MIS팀등으로 구성되었으며, IDC(Internet Data Center) 관련된 운영과 서버관련된 결정 및 구매까지 총괄하는 조직이죠.
전산센터 관리쪽은 1999년에 논현동에 데이콤 IDC센터가 국내최초로 오픈되면서, 그쪽으로 다음 서버들도 입주하게 되어 상대적으로 부하가 줄게 되었습니다.

일반적으로 성능 최적화업무를 진행할때는 개발쪽에서 진행할때 효과적인 부분도 있지만, Kernel/파일시스템/DB관련 파리미터 최적화만으로도 효과를 볼때도 있습니다. 
개발과 시스템튜닝 두가지가 병행된다면 더 큰 효과를 볼수도 있구요.
시스템 엔지니어링 조직은 단순한 서버관리업무만 수행하는 역할이 아닌 이렇게 다양한 업무에서 전문운영이 되어야하는 조직이고, 마치 코어부분을 맡은 개발자처럼 다른 개발자와 또는 다른 시스템 엔지니어와의 커뮤니케이션이 주가 됩니다.

국내에서는 시스템 엔지니어링을 단순 지원업무로 인식하고 대우도 그리좋지 않은면이 있는데 (에전의 미국경우에는 시스템엔지니어링의 연봉이 개발자의 약 85~90% 수준이라는 자료를 본적이 있습니다) 관련된 인식도 바뀔필요가 있고, 대규모 서비스나 클라우딩 서비스등에서 전문 시스템엔지니어링은 우대해야하지 않을까 싶습니다.
최근 국내 SW위기론과 함께 개발자 부족에 대한 경각심이 일어나는 와중에 이러한 시스템 엔지니어에 대해서도 다시 한번 생각해봐야겠지요.
항상 나중에서야 뒤늦게 위기론 이야기하지 말구요.

7) 다음의 기술조직 

ㄱ. 커리어 패스

다음이 본격적으로 포털서비스를 하면서 조직이 대규모화되고 거기에 맞추어 많은 개발자/엔지니어들이 구인되고 관련된 기술조직도 나날이 커가는 와중에, 기술자들을 위한 비젼차원에서 한때 고민했던것이 해외처럼 나이가 40,50이 되어도 관리자가 아닌 실전에서 개발하고 시스템을 튜닝하는 구조를 한번 만들어보자였습니다.
다음은 직급은 없고 직책만 있었는데, 팀원->팀장->본부장 이런 관리자코스외에도 초급-시니어-구루(Guru)의 기술전문코스를 만들어보면 어떨까하는 아이디어들도 나왔었구요. 앞에서 언급했듯이 관리보다는 개발자체에 더 집중하고 싶어하는 개발자들을 고려했던 부분이지요.
시도는 몇번 했었지만 역시나 한계는 보였습니다. 
결국 생태계의 문제인데, 다음내에서 그런 조직이 제대로 갖추어진다고 할지라도 기술자들이 다음내에서 평생직장을 다닌다는 보장이 없는데 이들이 만약 나이 50에 구루 개발자/기술자로 있다가 타직장으로 옮긴다면 받아줄곳이 있을까? 싶은 의문이 들더군요.
어떻게보면 변호사나 의사같은 전문직종의 경우 자영업외에도 종합병원에서도 나이가 들더라도 직접 일을 하는 경우가 많은것에 비해 (물론 업무를 보조하는 사람들은 있습니다만), 한국사회의 다른 일반회사들은 대부분 나이가 들면 웬지 관리자가 되어야할것 같은 분위기가 많죠. 예를들어 프리젠테이션 자료도 밑의 부하직원이 보조하고 본인이 직접만드는것이 아니라 밑의 직원을 다 시키는 일종의 관료적인 사회적 분위기라 할까요.

ㄴ. 프레임워크와 아키텍쳐의 완성도

전편에서도 말했듯이 개발자의 로망중 하나가 완성도 높은 아키텍쳐이다 보니 가끔은 개발프레임워크에 너무 빠지는 경우도 있었습니다.
물론 완성도 높은 아키텍쳐 자체가 나쁠것은 없습니다만, 사용자에게 시기 적절한 업데이트를 통해 양질의 서비스를 제공해야하는 온라인서비스의 특성상 너무 아키텍쳐에 시간을 할애하는것은 목적과 수단의 우선순위가 뒤바뀔때도 있었습니다.
물론 서비스에 따라 아키텍쳐에 더 신경을 써야하는 경우도 있었고, 일종의 실험적인 서비스라 언제 내릴지 모르는데 아키텍쳐에 너무 신경을 쓰는것이 오버일때도 있구요.

ㄷ. 커뮤니케이션 능력

한때는 커뮤니케이션능력을 개발자의 주요평가항목으로 삼겠다고 공언하며 커뮤니케이션능력을 강조했던적이 있었습니다.
일부 코어부분을 맡은 개발자를 제외하고는 대다수 개발자가 서비스 기획자와 긴밀하게 협력하여 서비스를 개발하고 업데이트해나가야하는 상황에서 커뮤니케이션 능력이 떨어지면 결국 맡은 서비스의 개발결과도 떨어질수 있기 때문이었죠.
본인의 개발능력도 중요하지만 더 중요한것은 회사내에서 그 개발능력을 얼마나 제대로 쓰고 있느냐하는 부분이니깐요.

ㄹ. 조직의 구성

조직구성할때 항상 고민하는 부분중 하나가 버티컬하게 서비스별로 조직할것이냐? 아니면 직능별로 풀을 만들어 조직할것이냐? 아니면 하이브리드냐?등의 숙제죠.
다음의 경우는 몇번 시행착오를 겪었지만 주로 서비스별로 버티컬한 조직위주로 운영을 했었습니다. 아무래도 온라인서비스란것이 밀착형으로 계속해서 관심을 가지고 업데이트해나가야하는데 풀에서 개발자를 지정하고 다시 교체하고 하는것은 바람직하지 않다고 보았기 때문이죠.
물론, 일부 마이너한 서비스경우 풀에서 배정되기도 했었고, 또한 한서비스에 오랫동안 있다보면 질릴수도 있기에 몇년뒤엔 순환형태로 다른 서비스로 배치되는 경우도 있었죠.
네이버의 경우 한때 풀형태로 운영했던걸로 아는데, 외부에서 듣기론 나름 장점도 있었지만 단점중 하나가 서비스에 대한 애착이 적다는 점이었습니다.
SI 프로젝트와는 달리 우리회사의 서비스이긴 하지만 그래도 SI 프로젝트처럼 지속성이 떨어지고 오너십이 상대적으로 적기 때문이죠.
어떤 조직이든 장단점이 있지만 온라인서비스의 경우는 좀더 밀착형인 버티컬 구조가 맞지 않을까 싶은 개인적인 생각입니다.

ㅁ. 서비스기획에서의 개발자의 역할

전문적인 서비스기획자 직종은 상대적으로 늦은 시기에 생겨났기에, 다음초기에는 컨텐츠가 아닌 기능성 서비스일경우 주로 개발자가 세부기획을 맡았던 경우가 많았습니다.
사실 페이스북도 그렇고 많은 온라인서비스들의 초기기획은 개발자나 개발출신이 맡았던 경우가 꽤 되지요.
시간이 지나면서 전문 서비스기획자들이 생겨나면서 어느정도 역할분담이 분할되었고, 역시 기능성 서비스나 기술과 관련이 많은 서비스기획의 경우는 서비스기획자가 관련기술에 대해 잘이해하는 컴퓨터 파워유저출신의 기획자이거나 아니면 개발자가 기획에 어느정도 참여해야 제대로된 서비스가 나오곤 했었습니다.
일부 서비스의 경우 팀장이나 본부장을 개발출신이 맡기도 했었구요.

ㅂ. 개발자/기술자에 대한 대우

전산출신들이 창업한 포털등 인터넷서비스업체들의 경우 상대적으로 타업체에 비해서는 개발자 입김이(?) 센편이라고 봅니다. 
각 업체마다 차이는 있지만 다음 경우에도 내부에서 서비스 기획자나 타직종 사람들이 개발자만 우대해서 역차별받는다는 이야기가 나올때도 있었고, 다른 인터넷업체들도 비슷한 이야기가 나온적이 있는것으로 압니다.
물론 개발자 입장에서는 대우가 기대에 못 미친다는 생각도 있을수 있겠지만요. 
그러다보니 국내에서 경쟁력있는 개발자는 상대적으로 포털서비스업체나 온라인게임업체나 기타소수의 SW개발업체에 집중되어 있고, 최근에 SW위기론과 맞물려 급한대로 대기업에서 스카웃해가는 타켓개발자들도 주로 이쪽이 된겁니다.

ㅅ. 이직과 문화적 차이

포털이나 인터넷서비스업체에서 처음 일했던 사람들경우 개발자가 아니더라도 다른 대기업으로 이직했을경우, 연봉외에 다른 조직문화나 코드측면에서는 만족도가 떨어지는것 같았습니다.
대기업이나 다른업체에서 일을 하다온 경력자의 경우 다시 다른 대기업으로 좋은조건(연봉)으로 이직할경우는 나은 편인것 같긴 합니다만, 포털과 인터넷서비스업체들간에도 문화적차이가 있지만 다른 업종이나 기존대기업 계열사의 경우 더 큰 문화적차이를 느끼는것 같더군요.
개발자 경우에도 예전에 몇몇 친구는 제가 보기에 도저히 일반 대기업스타일이 아니라 "다음을 그만두는것은 말리지 않겠는데, 꼭 그회사에 가야겠느냐? 거긴 우리 경쟁사가 아니지만 너무 당신과 코드가 안맞을것 같다. 차라리 경쟁사가 코드가 더 맞을것 같다" 라고 했었지만 결국 그쪽 대기업으로 갔다가 한두달내에 다시 돌아오겠다고 한경우도 몇명 본 기억이 나네요.

5. 국내 SW 개발자 생태계는 어떻게 구축되어야 할까?

마지막으로 다음을 벗어나 이야기해보죠.

요즘 SW위기론 이야기가 자주 나오는데, 결국 국내 SW 개발자 생태계 문제가 아닌가 싶습니다.
이부분은 국내의 경제-산업-교육-사회 전반에 걸친 복합적으로 얽힌 이슈이기에 어디서부터 어떻게 풀어야할지 저도 솔직히 감이 오지는 않습니다.
다방면적인 노력이 있어야할것 같은데 원론적인 이야기일수 있지만 개인적으로 느끼는점 몇가지만 나열해봅니다.

일단 본질적인 차원으로는 업체에서 SW개발자가 제대로된 대우를 받는경우가 많아져야겠죠.
연봉같은 금전적인 측면도 중요하겠지만, 전편에서 언급했던 개발자 특성들처럼 개발자가 인정받고 주도적으로 일할수 있는 분위기가 되고, 필요한 신기술을 익힐수 있는 교육시간도 어느정도 보장된다면 보다 창의적인 SW개발이 가능한 분위기가 되지 않을까 싶습니다.
물론 이것을 위해서는 이러한 분위기가 생산성 측면에서 결국 기업에 도움이 된다는것을 기업들이 인정해야할테구요.
또는, 기존기업이 아닌 스타트업에서 SW개발자가 성공적인 벤처기업으로 같이 커나갈수 있는 분위기가 되던가요.
두가지가 같이 병행될 필요가 있겠습니다.

사회적인 차원에서는 SW개발자에 대한 인식도 어느정도 바뀌어야할테고 (더 크게는 이공계에 대한 인식) 지적재산권등 무형의 자산가치에 대한 인정이 보다 많이 되어야할것 같습니다. 단순한 SW 불법복제차원 문제를 떠나 SI 프로젝트등도 정당한 댓가가 지불이 되어야할테구요. 
단순히 학력과 경력연차만이 SW개발 비용지표가 아닌, 능력에 따른 제대로된 지불이 필요하겠습니다.

교육적인 차원에서는 비단 SW개발자만의 문제는 아닌 국가적인 차원의 문제로 보입니다만..
위의것들이 해결된다면 컴퓨터관련학과가 현재보단 인기학과가 될순 있겠죠.
학생들이 부담하기엔 너무나 큰 금액인 등록금은 또다른 해결해야할 숙제로 보입니다.
"사"자 돌림 전문직이나 공무원에 대한 국내의 광적인 선호는 현재의 청년실업률과 미래의 실직에 대한 부담감에서 생긴 방어본능적인 차원이 강한듯하구요.

대학교 컴퓨터관련학과의 교육과정을 보면 앞의 1편에서도 언급했었지만, 프로그래밍 뿐만 아니라 데이타 스트럭쳐를 비롯한 몇몇 기초과목들은 필수로 가르쳐야 하는게 아닌가 싶은 개인적인 생각입니다.
요즘은 상황을 잘 모르겠는데, 제가 재학당시 들었던 이야기는 SDS경우 그당시 향후 많은 개발자(주로 SI 프로젝트 개발 수요였겠지만)가 필요하기에 전산출신으로는 충원이 불가능해 이공계쪽에서 별도로 뽑아 자체교육을 시킨다는 것이었습니다. 요즘은 어떻게 진행되고 있는지 궁금하네요. 
삼성소프트웨어멤버십경우 자체교육과정의 의미보다는 나름 실력있는 개발자들을 모을수 있는 구심점 역할을 하고 그들간에 서로 peer-to-peer learning을 할수있다는 점에선 의미가 있었다고 봅니다. 실제로 삼성 소프트웨어 멤버십출신중에 뛰어난 개발자들도 많이 보았구요.
다만, 삼성의 예비 취업생 모집성격이 강해, 좀더 오픈되었더라면 싶은 아쉬움이 있습니다.
최근의 NHN의 경우 SW 아카데미를 추진중인데, 제가 작년에 관계자에게 듣기로는 SW개발에 뜻을둔 열정적인 비전공자 출신으로 진행해본 결과 상대적으로 NHN의 평균신입개발자보다 좋은 퍼포먼스를 보인것에 고무되어, 주로 비전공자 출신에 초점을 두어 확대하는것으로 압니다. 일단, 삼성소프트웨어멤버십과 달리 NHN에 바로 입사하는것이 아닌 오픈된 모델이라는 점은 바람직해보입니다.

결국, SW개발자 생태계를 위해서는, 일부는 닭이 먼저냐 달걀이 먼저냐는 숙제들도 있고 다방면적으로 풀어야할 숙제가 많은것 같습니다.

이상으로 <SW개발자..> 4편을 마지막으로 마칩니다.