저도 코던데요

며칠전에 "여러분야파기"란 글을 쓰고 나서 둘러보다 보니 써니님이 "이어쓰기놀이"에 재미(?)있는 글타래를 모아놓으셨고 "저는 여전히 코더(coder)입니다"에서 언급한 malefic님의 "꼭 그래야만 하는걸까요"에서 특히

그런데 그 책에서 말하는 훌륭한 알고리즘, 제대로된 프로그램, 이런 것들이 과연 현업에서 사용할 수 있는 지침이 될까요?

저는 그렇지 않은 것 같습니다.

제대로된 리스트를 작성하는데 시간을 쓰느니 MFC의 CList를 쓰거나, STL의 List를 쓰는 것이 훨씬 나은 걸요...

과연 진정한 프로그래머의 길은 구글 이나 MS 입사시험(?)에나 나온다는 이상무쌍한 알고리즘 찾기나

수수께끼 풀이에만 있는 걸까요?

라는 부분을 보고 이전에 하고 싶었던 말을 하나 써 볼까 합니다.

우선 "코더로서 적응해 간다는 것"에서 언급했던 TnC 면접 문제이야기를 해야 할 것입니다. 가끔 왜 이런 것을 질문하느냐, 소팅이 뭐가 중요하냐란 질문을 받곤 합니다. 그런경우 저의 답은 이렇습니다.

천만명이 시험을 봤습니다. 0점부터 100점까지 점수를 받았겠죠. 석차를 내야 합니다. 소팅에 대한 이해가 없는 사람은 그냥 DBMS상에서 "ORDER BY 점수" 하고는 차례대로 석차를 붙여 줄껍니다. 이론적으로 nLogn에 할 수 있겠죠. 비싼 써버 사달라고 해서 구현하면 되긴 하죠. 매번 소팅 안하고 필드를 만들어서 기록해 두는 것을 생각해 내는것만으로도 대단하다고 해야 할껍니다. 가끔 점수가 잘못 입력되어 정정해야 할 일이 있을 텐데 뭐 매번 소팅할껍니다. 응시자가 1억명이 안넘은 것에 감사하겠죠.
허나 저는 이것을 n에 풀 수 있어요. 점수가 끽해야 101개 밖에 없자나요. 각 점수별로 몇명있는지 카운팅 하면 점수만으로 몇등인지 알 수 있어요. 수정상황? 어떻게 하면 될지 대충 상상이 되지 않나요? 대단한 생각도 아니죠. 이런 생각은 Data Structure(데이터구조) 수업시간에 제대로 들은 사람이라면 충분히 할 수 있는 거죠.

컴퓨터가 뭐냐고 한다면 그저 계산을 빠르게 하는 기계일 뿐입니다. 사람보다 엄청나게 빠르게 가감승제를 빨리 할 뿐입니다. 반대로 빨리 하는 것이 컴퓨터의 숙명이기도 하구요. 그리고 지시를 내리는 것은 사람입니다. 사람이 어떻게 명령을 내리냐에 따라서도 상당한 차이가 발생하죠. 언어라는 것이, 가령 영어학원에 좀 다니면 영어는 할 수 있지만 소설을 쓸 수 있는 가는 또다른 것이 되듯, 뭐 PHP로 코딩 가능한 사람이야 충분히 구할 수 있고 아무나 데려와도 1년동안 학원 보내주면 할 수 있을 것입니다. 그러나 회사의 제품을 좀더 좋게 만들 수 있는 사람을 찾아야 할 것이고 결국 면접을 제대로 통과한 사람은 없었지만 이런 것들을 중요시 했던 분위기는 제품에 좋은 영향을 주었다고 자신합니다.
자신이 프로그래머 나부랭이라고 한다면 자기가 컴퓨터에게 무슨 일을 시키고 있는가에 대한 이해는 반드시 있어야 한다고 생각합니다. 다시는 어셈블리어를 짤 일이 없다고 해도 메모리가 어떻게 운영되고 하드에선 대체 어떻게 데이터를 들고 오며 락을 걸면 시피유는 어떻게 미쳐버리는 가에 대한 이해는 필요할 것입니다. 이런 지식들이 있어야 꼴딱꼴딱 숨넘어 가는 시스템을 세상에서 구할 수 있습니다.

CS 4년동안 배우는 것이 정말 쓸모없는 것이라면 대학들은 다 문닫는 것이 맞겠죠. 코딩이랑 전혀 상관 없을 것 같은 컴퓨터 구조 같은 과목조차 모두 다 필요한 지식입니다. 모든 지식들을 다 쓰지 못할 수는 있겠습니다만(특히 전공 선택쯤 되면) 적어도 기초필수로 배우는 것은 항상 따라다녀야 할 지식들입니다. 암기식으로 소팅에는 버블, 인서션, 셀렉션, 퀵, 머지가 있다고 외우고 있는 것은 물론 의미 없습니다. 각각들이 뭔지를 정확히 알고 있어야 지금 상황에서 뭘 써야 하는지를 선택할 수 있습니다.

STL의 List나 Hash 관련 라이브러리들은 정말 강력합니다. 많은 프로그래머들이 고심해서 조이고 닦고 해서 만든 거죠. 많은 사람들이 그냥 가져다 쓰면 되는 툴이라고 생각합니다만 라이브러리가 그런 것은 아닙니다. 그저 자주 나오는 문제에 대해 타이핑 또 할 필요없이 가져다 쓸 수 있는 코드일 뿐입니다. 그런 형태의 데이터 구조를 써야 한다고 판단하는 것은 똑같이 해야 한다는 것입니다. 현재 다루어야 하는 데이터의 특성은 어떨까, 그리고 이것을 통해 어떤 특성을 가진 데이터 구조를 사용해야 할까. 더불어 그 라이브러리를 쓸때 어떤 식으로 붙여줘야 가장 잘 동작할까. 이런 것들을 고민해야 합니다. 임의의 데이터 찾는데 Hash가 좋다고 그 템플릿을 무조건 쓰는 사람들이 있습니다. 키가 특수하다면 어레이가 훨씬 좋을 수 있고, 또한 Hash가 뭔지에 대한 이해가 있어야 Hash Function을 디자인 하고 버킷 수를 지정할 수 있습니다.

이미 주어진 툴들이 많은데 왜 밑바닥 부터 고민하느냐고 생각할 수 있습니다. 당장 프로그램을 내일까지 완성해야 하는데 그런 쓰잘데기 없는 고민을 하냐고 말할 수도 있습니다. 허나 이런 상황을 여러번 겪는다고 생각해 봅시다. 단박에 생각한다고 문제가 쉽게 해결되지는 않습니다. 하지만 계속 조금씩 더 생각을 하고 노력하다 보면 언젠가는 좀더 프로그램이 안정해 지고 빨리 퇴근할 수 있게 되거나 더 기능을 추가해서 단가를 올릴 수 있겠죠.
아르바이트를 쓸때는 저조차도 잡생각(?)하고 있으면 경고를 하겠죠. 빨리 완성하라고. 사실 주는 부분도 금방 버릴 부분입니다. 장기간 사용해야 할 부분이고 정직원으로 계속 일할 사람이라면, 반대로 생각없이 들고오면 혼낼껍니다.

신기술, 중요하죠. 새로운 언어를 습득하고 새로운 개념을 배우고 새로운 툴의 사용법을 익히는 것은 중요합니다. 허나 본질의 이해를 놓치고 그것만이 중요하다고 이야기 한다면 문제가 있는 것으로 보입니다. 그것만큼이나 중요하고 "여러분야 파기"글에서도 언급했듯이 본질의 이해를 통해 새로운 것을 좀더 빠르고 정확하게 습득할 수 있습니다.

~~~~~

'G'회사에서 낸다는 이상한 문제들에 대해서도 언급해 봅시다. 몇가지 문제를 보고 이놈의 회사는 수수께끼만 내는거 아닌가란 생각을 할지도 모르겠습니다. 그러나 그 회사의 검색을 통해 문제들을 많이 찾아 보십시오. 단순히 수수께끼 책 몇권 읽는 다고 절대 합격할 수 없습니다. 사실 그 수수께끼들 조차 원래 의도는 다른데 있을 것입니다.

참고로 그 회사의 면접문제들을 보고 대체 의도가 뭔지를 발견하는 것은 합격 확률을 높이는 방법 중 하나랍니다. :)

~~~~~

글들을 보다가 마치 아키텍터는 코딩 안하는 것처럼 언급이 되어 있던데, 뭐 컴퓨터 앞에서 C코드를 작성하지 않을 수 있습니다만, 저는 언어의 차이일 뿐이라고 이야기 합니다. 누군가는 Java로 프로그래밍을 하지만 누군가는 UML로 할 뿐입니다. 뭐 누군가는 술로 하구요.
더불어, 제가 태어나기도 전부터 프로그래밍을 하셨고 정말 아키텍터라 불리실 분들도 C 코딩을 하는 경우도 있습니다. 취미생활 제외하고도, 자신이 생각하기에 정말 중요한 부분이다라고 생각이 들고 직접 손봐야 하는 곳이라고 판단된다면 손을 대죠.
훌륭한 아키텍터는 자신의 산출물이 완성되는 순간 각 부분이 어떻게 통신을 하고 있고 이쯤에선 이런 알고리즘과 데이터 구조를 사용하고 있을 것이라는 모습이 눈에 선할 것이라는 것이 저의 생각입니다. (컨설턴트 말구요 아키텍터요;;;)

~~~~~

알고리즘도 모르면 코더도 아니냐?라고 하신다면 그건 아닙니다. 코더의 정의에 그런게 들어 있을리 없죠. 좀더 잘하는 방법에 관한 것입니다. 뭐 높은 연봉을 받는 방법이라고 할수도 있고 자기만족도를 높이는 방법이라고도 할 수 있습니다. 시간은 세이브 못합니다. 효율적이 되면 일의 양이 늘어서 결국 시간은 같은거 같아요. 또한, 저런 방법만 있는 것도 아닙니다. 높은 연봉을 받는 방법으로 다른 방법도 많으니까요.

(RSS 구독자 분들은 제외하고) 링크를 타고 흘러 흘러 여기까지 오신 분이라면 이런 저의 인생관(?)도 들어 볼만하다란 생각으로 적어봅니다. 그리고 "써니님의 블로그"에 요즘 주옥같은 글들이 올라오고 있는 듯 합니다. 미투로 도배중인 제 블로그보단, 저 블로그 강력 추천합니다.