ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 네이버형 프로그래머? 구글형 프로그래머?
    TIP 2008. 12. 15. 22:48
    반응형

    2008/12/15 18:33
    원문 링크 : 링크

    Written by 안재우(Jaewoo Ahn), 닷넷엑스퍼트(.netXpert)

     

    우선 오해가 있을까봐 미리 밝혀두자면, 이 글에서 얘기하고 있는 것이 네이버나 구글의 프로그래머, 즉 네이버나 구글에서 일하는 프로그래머를 말하는 것이 아닙니다. 사실 좀 더 정확하게 하자면 네이버형 프로그래머’, ‘구글형 프로그래머가 맞습니다.

     

    네이버 프로그래머 이야기

    최근 프로젝트를 하는 동안 이런 저런 개발자들을 만나면서, 참으로 흥미로우면서도 염려가 되는 측면들을 발견했습니다. 물론 이 사람들이 우리나라 모든 개발자의 모습은 아니겠지만, 초급 개발자도 아닌 나름 몇 년 이상의 개발 경력을 가지고 있는 사람들이라는 점이 많은 걱정을 하게 만듭니다.

     

    걱정의 발단은.. 개발자들의 수준을 파악하기 위해 간단한 테스트 과제를 낸 것이었습니다. 뜬금없이 무슨 알고리즘을 구현하라는 것처럼 아카데믹(?)한 것도 아니고, 실제 실무에서 가장 많이 사용하는 과제로.. 기본적인 개념만을 파악하고 있다면 충분히 해결이 가능한 과제였습니다. 또한 테스트의 목표 자체가 과제를 100% 해결하는 것은 아니었습니다. 아무리 실력이 있는 사람이라도 제한된 시간 내에 라이브 코딩으로 만들어내라고 시키면 완성하는 것이 쉬운 일은 아니거든요. 단지 개념은 가지고 있고, 해결해나가는 과정이 올바르다면.. 완성하지 못하더라도 통과를 시키려고 했습니다.

     

    흥미로운 것은.. 테스트에 참가한 대다수의 사람들이 문제를 듣고 나서 아무런 시작을 하지 않고, 브라우저를 띄우더니 네이버 사이트로 가더군요. 네이버가 벼라 별 지식이 다 있다고는 알고 있습니다만, 테스트 과제가 그대로 있지는 않을 텐데.. 상당히 의아했습니다.

     

    이 개발자들이 네이버에서 검색을 시도한 이유는 무엇일까요? 요즘은 데브피아와 같은 개발자 커뮤니티 사이트 대신에.. 네이버 지식인에서 물어보는 게 대세인데.. 제가 시대의 흐름을 파악하지 못하고 있는 걸까요? 아니면 네이버 까페나 블로그에 답이 있는 것일까요?

     

    하여간 결과적으로..

    네이버 사이트를 열심히 뒤지던 사람들은 100% 문제를 하나도 해결하지 못한 채 테스트에 합격하지 못했습니다. 완성도는 떠나서 중간 과정에서마저도 전혀 진도를 나가지 못하더군요. 테스트 시간의 평균 90%는 네이버 사이트에서 검색을 하는데 소모되었습니다.

    개인적으로 저는 이러한 유형의 사람들을 네이버 프로그래머라고 부르기로 했습니다.

     

    구글 프로그래머

    제가 아는 사람 중 J씨는 라이브 코딩의 대가입니다. 속도도 빠를 뿐만 아니라, 라이브 코딩으로 만들어내는 코드의 품질 자체도 생각보다 나쁘지 않습니다.

    J씨가 라이브 코딩을 하는 방법은.. 작성해야 하는 코드의 뼈대는 자신이 직접 다 만들어 놓습니다. 하지만 세부적인 구현부분, 즉 실제로 코딩을 해야 하는 경우에는 구글에서 정확한(!) 키워드 검색을 던져서 바로 참조 가능한 코드 조각들을 찾아낸 다음, 일일이 입력하는 대신에 이를 자신이 만든 뼈대 안에 채워 넣는 방식을 사용합니다.

    물론 당연히 개념 파악을 하고 있기 때문에, 예제를 단순히 그대로 Copy & Paste하는 것이 아니라 붙이면서 자신의 코드에 맞게 수정해야 할 것은 전부 수정합니다.

     

    저 역시 간혹 트러블 슈팅이나 Workaround가 필요할 때에는 구글 검색을 많이 사용합니다. 이런 것들은 수많은 사람들의 경험에서 나온 지식이 절대적으로 도움이 되니까요. 심지어 MSDN에 있는 내용이지만 MSDN에서 직접 검색하기 보다는, 구글에서 검색해 본 다음 결과로 나온 MSDN 사이트로 이동하는 경우가 점점 많아지더군요.

     

    그런데, 안타깝게도 이런 경우에 해당 키워드를 네이버에 던져 넣어서는 원하는 답을 전혀 찾을 수 없었습니다. 물론 어떻게 하다 보면 찾을 수 있을지도 모르지만, 네이버에서 검색을 하느라 낭비하는 시간에 차라리 직접 코드를 작성하는 것이 빠를 테니까요.

     

    하여간 이렇게 구글에서 자신의 구현에 필요한 코드 예제를 찾는 유형의 사람들을 저는 구글 프로그래머라고 부르기로 했습니다.

     

    네이버 프로그래머와 구글 프로그래머의 차이

    전자의 경우에는 아예 구현의 방향 자체를 모르고 있거나 기초적인 개념 자체가 원래부터 없기에 구현을 어떻게 해야 할지를 아예 생각하지 않는 경우가 대부분입니다. 그에 따라 누군가가 구현의 방향을 가르쳐주거나 남이 해놓은 구현 방식을 답습하는 방식을 작업을 수행하게 됩니다. 게다가 원리를 이해하게 체득하기 보다는 사용법만을 일시적으로 익혔다가 금새 까먹어 버리기 때문에, 분명히 자기가 해봤던 내용인데도 하지 못하는 경우가 생기는 것입니다(최소한 저는 그 사람들이 해본 적이 없으면서 해봤다고 거짓 주장을 하는 것은 아니길 바랍니다).

    후자의 경우에는 구현의 방향은 알고 있되, 코드를 작성(정확하게는 타이핑)하는데 불필요한 시간을 낭비하거나 검증을 위해 시행 착오를 줄이는 대신, 코드를 보다 효율적으로 작성하는데 필요한 정보(혹은 코드)를 찾아내서 활용하는 경우입니다. 자기 자신이 그 코드를 작성할 수도 있지만, 작성하는데 걸리는 시간과 귀찮음을 줄이기 위한 것이지요.

     

    검색 엔진의 위험성

    예전에 TV에서 있었던 어떤 프로에서, 사람들이 인터넷 환경에 의존하면서 생기는 위험성들을 지적한 적이 있습니다. 인터넷, 특히 검색 엔진이 너무 많은 것을 처리해주면서 사람들이 자기 스스로 해야 하는 일들을 멀리함으로써 두뇌의 퇴보를 가져온다는 내용이었던 것 같습니다.

    사실 굳이 인터넷이나 검색엔진에 국한된 것은 아닙니다. 가장 단순한 예를 들 때, 자기와 친한 사람들의 전화번호를 다 외우는 경우도 점점 드물어집니다. 어차피 핸드폰에 입력되어 있으니, 굳이 외울 필요가 없어지는 것이지요. (그러다 백업을 해두지 않은 상태에서 핸드폰을 분실하거나 핸드폰이 고장 나면 대략 낭패이지만..)

     

    개발에 있어서도 자신이 판단하고 생각해야 할 내용을 검색에 의존하는 경우가 많아집니다. 하지만 분명히 구분해야 할 것 중 하나는.. 생활에 필요한 정보를 검색에서 찾는 것은 맞지만, 직업 상의 정보, 그것도 정보가 아닌 판단이 필요한 것을 검색에 의존한다는 것은 개발자로서의 역할과 의무 자체를 내던져버리겠다는 것과 마찬가지 얘기입니다. 개발자는 개발자이지, 개발 정보 검색자가 아니기 때문입니다.

     

    재미있는 예를 한가지 들어보면, 이 글을 보시는 여러분들의 경력이나 기반 지식이 어떤지 모르겠지만.. 여러분에게 임베디드 하드웨어 장비에 정해진 동작 명령어를 전달하는 소켓 통신 프로그램을 작성하라는 과제가 떨어졌다고 가정해 봅시다. 수행 가능하시겠습니까? 과제의 난이도는 어떻다고 생각합니까? 과제를 완수(구현 및 테스트까지 포함)하는데 얼마나 걸릴 것 같습니까?

     

    답은 물론 사람 따라 다를 것입니다. 사실 경력 햇수와는 상관없이, 소켓 프로그래밍의 경험이 있는 C/C++ 프로그래머에게는 별로 어려운 일이 아니겠지만, ASP만 다뤄온 웹 프로그래머에게는 상당히 어렵게 느껴질 수도 있을 것입니다.

     

    재미있는 예라고 한 이유는.. 이 과제를 프로그래밍 경험이 전혀 없으며, 프로그래밍 언어 자체도 배워본 적도 없는 사람이 1개월 만에.. 그것도 C++ 코드로 완수했기 때문입니다. 그렇다고 해서 그 사람이 대단한 천재도 아니고, 그냥 일반적인 4년제 대학을 나온 평범한 사람입니다. 어떻게 했냐고 물어보니, “인터넷에서 소켓 통신 예제 검색해보니깐 다 나오던데요?”라고 답을 하더군요. 자신이 한 것은 자기의 임베디드 하드웨어에 맞는 명령어를 사전에 정의해놓고, 그것만을 사용해서 통신하도록 한 것 밖에 없었다고 합니다. 그 외 개발툴에서 코드를 작성하고, 컴파일/빌드하는 방법을 배우는데 시간이 좀 걸렸다더군요.

     

    물론 이 사람은 정상적인 개발자가 아닙니다. C/C++의 문법이나 정확한 내용에 대해서는 전혀 모르고, 소켓 통신 모듈을 작성한 것뿐입니다. 하지만 개발 정보를 검색할 수 있는 능력은 갖추고 있기에, 개발 정보 검색자 수준의 개발자라면 그 지위가 위태할 수도 있겠다는 생각이 듭니다. 이 얘기대로라면 일반인들도 검색 좀 잘하고, 개발 툴 사용법만 알면 얼마든지 개발을 할 수 있다는 얘기가 됩니다.

     

    또한 검색에서 위험한 것 중 하나는.. 검색을 통해 나오는 정보가 모두 정확하지는 않다는 것입니다. 예전에도 계속 강조했었지만, 출판되어서 나오는 책에서도 틀린 내용이 있는 경우도 많은데.. 온라인 상의 정보가 가지는 정확성은 더욱 더 떨어질 수 밖에 없습니다. 심지어 데브피아와 같은 커뮤니티 사이트 등에서 강좌라고 올려놓은 정보들도 가끔 엉터리 정보를 담고 있는 경우가 많습니다. 근본적으로는 정확하지 않은 정보를 올리는 작성자에게도 문제가 있지만, 무조건 정보를 맹신하는 사용자들도 문제입니다.

     

    바람직한 검색의 대상

    무엇인가를 구현한다고 할 때, 구현을 하기 위해 필요한 정보는 대략 다음과 같을 것입니다.

           전체적인 구현의 방향

           구현을 하기 위해 필요한 기술이나 기법

           구현(또는 해당 기술/기법에 대한) 예제

           코딩 시 각 라이브러리에 대한 레퍼런스

     

    이 중에서 ①번의 경우에는 절대 검색을 통해서 얻을 수 있는 정보는 아닙니다. 단편적인 키워드 검색 몇 개로 해결이 될 수 있는 내용이 아니라, 개발자로서 자신이 가진 지식을 총동원해서 판단을 내려야 하는 것입니다. 또한 그 판단을 내려야 하는 것은 다른 사람이 아닌 자기 자신이 되어야 합니다. 물론 초보 시절에는 다른 사람의 판단에 따라야 할 수도 있지만, 어느 정도 경험을 해본 사람이라면 이 정도 판단은 자기가 내려야 합니다.

    ②번의 경우는 어느 정도는 검색을 통해 얻을 수도 있습니다만, 역시 단순한 검색보다는 종합적인 판단이 필요한 부분입니다.

     

    , ④번부터는 분명히 검색의 영역입니다. 사실 이것을 머리 속에 다 담아 두려고 노력하는 것이 미친 짓입니다. ③번(구현 예제)의 경우, 각종 커뮤니티 사이트나 네이버, 구글 등에서 검색을 해보면 좋은 결과를 얻을 수 있습니다. 검색 결과가 MSDN과 같은 공식적인 사이트이거나, 나름 유명한 개발자의 블로그라면 정확성도 더 커질 것입니다. 특히 검색을 다니다보면, 알찬 정보를 제공하고 있는 사이트나 블로그를 스스로 습득하게 될 것입니다.

     

    ④번(레퍼런스)은 절대적으로 MSDN과 같은 제작사의 레퍼런스의 영역입니다. 예를 들어 특정 API에 대한 세부 정보는 검색 엔진에서 검색해야 할 것이 아니라, 도움말에서 검색해보는 것이 맞습니다. 그럼에도 불구하고, 최근 테스트를 해본 개발자의 상당 수는 레퍼런스 검색이 필요한 상황에서 MSDN 도움말을 띄우지도 않더군요.

     

    맺음말

    사실 이 글을 쓰게 된 동기는 서두에서 밝혔던 것처럼, 네이버 프로그래머가 너무 많더라는 것입니다. 그것도 초보자 시절이라면 이해를 하지만, 나름 몇 년의 개발 경력을 가졌으며 유수의 회사를 거쳐왔다는 사람들이 그렇다는 것은 이해할 수 없는 부분이었습니다.

    심지어 차라리 모르는 것은 낫지만, 사실과 전혀 반대되는 내용으로 엉터리로 얘기하는 사람들도 있었습니다. 그 개발자가 꽤 오랜 경력을 가지고 있었으니, 그 조직의 개발자들은 모두 그 사람이 하는 얘기가 다 맞는 얘기인 것으로 알게 되었을 것입니다.

     

    제가 지나친 생각을 하는 것인지도 모르겠지만, 과연 그 사람들이 수행한 프로젝트들이 정말 정상적으로 잘 되었을까라는 걱정이 듭니다. 저는 최근 모 IT맨이 사직서를 쓰면서 이슈가 된 우리나라의 열악한 IT 현실보다도 이러한 상황이 더 걱정이 되네요. 부디 제가 만난 네이버 프로그래머들이 극소수였기를 빕니다.
    반응형

    댓글

Designed by Tistory.