철수네 소프트웨어 세상 [본점]

소프트웨어와 관련이 있다면 뭐든지 – I no longer work for Microsoft.

Archive for 2월 2009

개발 경험에 관한 Random Thoughts

with one comment

art.oriented  지금까지 작성한 코드는 총 몇 줄

gimmesilver’s blog  경험이 우리에게 주는 것

art.oriented  경험은 당연히 중요합니다

Random thoughts:

  • “경험이 많다.”는 말은 사실 문맥에 따라 엄청나게 다른 말이지 싶습니다만, 아무튼 경험이 중요하다는 말에는 모두가 이견은 없는 것 같습니다. 저도 경험이라는 것은 분명 중요한 것이라 생각합니다.
  • 경험(시간)과 실력의 비례 관계는 n이냐 로그n이냐 혹은 무엇이냐는 이야기로 비유 하기가 힘들다 생각합니다. “경험치”처럼 한 수치로 두는 것은 RPG 겜의 이야기지, 현실에서는 확률의 이야기에 되려 가깝지 않을까 생각됩니다. 통념상 일단 “어떤 경험”을 했을 경우, 그것에 좀 더 실력이 있을 가능성이 크다는 확률을 가정한 뒤에(서류) 면접에서 이를 걸러낼 수 있느냐는 싸움을 하게 되는 것이겠죠. 솔직히 5년차 개발자나 10년차 개발자나 얼마든지 또이또이 할 수도 있는 것이고, 혹은 시간이 지날수록 실력이 일취월장하는 개발자도 얼마든지 있지 않을까요.
  • “약간 의미 전달이…제 경험에서 나온 말입니다.”(object님)에서 두가지
    • “자신이 실수했다고 생각했지만 사실 그건 능력이 부족한 것이죠.” – 이것은 문장상 인과관계가 없어서 요지가 좀 이해가 안갑니다. 실수일 수도 있고 능력이 부족한 것일 수도 있을 것일텐데 왜 능력이 부족한 것일까요.
    • 회사에서는 사람을 줄세워놓고 상위 10%, 1%, 0.1% 이렇게 나누기가 힘듭니다. 학교에서야 석차가 나오니까 0.01%가 되는 것이 불가능하(할 수 있)겠지만, 회사에서는 포커스된 능력과 운이면 0.01%에 준하는 댓가를 얼마든지 이룰 수 있고 그 사람이 전에 0.01%는 커녕 10%에도 못든 사람일 수 있습니다. 그리고 그런 것이 실력으로 대응되기도 하죠. 회사에서 실력 좋은 개발자 탑10안에 든다, 혹은 xx계에서 알아주는 개발자…식이라면 가능하겠습니다.
  • object님의 구글 예처럼 “신입 개발자”로 제한하는 경우에는 말씀대로 사실 경험이라는 요소를 가장 큰 것으로 치지 않습니다. 하지만 간단하게 예를 들어 코덱을 짜는 역할에 10년동안 비디오 코덱만 짜던 친구와 10년동안 다양한 경험을 한 친구 둘을 놓고 본다면(서류상), 전자가 아무래도 눈에 더 들어오겠죠. 회사가 10년동안 다양한 경험을 한 친구가 뭔가 틀에 벗어나는 멋진 결과를 내놓을 수도 있는 등의 리스크를 떠안겠느냐는 이야기는 다른 이야기겠지요.
  • 비슷한 이야기로, 지금 당장 어떤 일을 시켜야하는데, 해본 적이 없고 잘할 능력의 개발자를 뽑을리는 만무합니다. 혹은 Hiring Manager는 최고의 인재로 보이더라도 역할에 과하다면 뽑지 못하고 맞춰서 뽑게 됩니다. 회사생활 1년차 프로그래머와 경력자와는 뽑는 사람의 눈에는 분명 다릅니다.
  • 1년차 3년차 10년차 15년차(숫자보다는 늘어난 경험의 양을 생각하면), 똑같은 것을 하더라도 각자 모두가 경험을 통해서 다시 얻을 수 있는 것은 상당히 다릅니다. 간단히 10년차(경력자)가 1년차(비경력자)때 한 것을 다시 봤더니 새로운 점들이 마구 보인다더라하는 이야기는 흔하죠. 사실 굳이 10년이 아니라도 프로젝트가 끝나고 다시 리뷰를 하더라도 똑같습니다.
  • 그리고 그런 경험에 따라서 나중에 시니어개발자, 데브매니저나 혹은 아키텍트등의 다른 경험의 직책을 가질 수 있습니다. 서로 막 쉽게 바꿔가면서 오갈 수 있는 직책은 아니라 생각됩니다.
  • “아닙니다! 어쩔 수 없다라고 생각하는 바로 그 일이 원래 지금 하고 있는 그 일의 본질입니다.”(agbird님) – 공감합니다. 어딜가나 스케줄의 압박은 어쩔 수 없습니다. 회사의 개발자에게 있어서 “x일동안 xx를 만드시오.”라는 사명은 완벽한 제품을 만들라는 것이 아니기에 삼일을 주던 일주일을 주던 거기에 맞는 코드를 생산해는 역할입니다. 어떤 회사에서 진짜 코딩 잘한 제품(이 무엇인지 모르겠지만)이 시간을 많이 줬기 때문에 나온 결과물이라고 생각치는 않습니다. 제품을 만들어서 사용자에게서 소스코드의 예술성에 따라서 가격을 받을 수만 있다면야, 자기 돈 들여서 예술적인 코드를 충분한 시간을 들여서 만드는 직종도 생기고 하겠지만 말이죠. (다만 문제라면, 삼일이 아닌 불가능한 하루를 주는 경우겠지만, 이는 논지에서 벗어나는 다른 이야기겠죠.)
  • “코딩”만을 잘해서는 30년후에도 비슷한 모습일 수도 있겠습니다만, “개발(development)”을 잘하는 경우는 다른 말이겠죠. 개발을 잘한다는 말도 굉장히 광의의 말이겠지만요.
  • 삽질을 백만번하면 웬만한 포크레인 수준(agbird님)이겠지만, 똑같은 코딩을 백만줄하면 복사기일 수도 있겠습니다.^^ (Copy&Paste 코딩을 하는 개발자 수도 없이 많죠.) 저도 object님의 이야기처럼 “코딩을 몇줄해봤어”라는 질문은 가쉽이지 실력/경험의 가늠자는 아니라고 생각됩니다. 이유는 좀 다른데, 수많은 경험의 무게를 상상하기에는 부족한 질문이기 때문이죠. 이어지는 질문이 제대로 되었다면야^^

이런 이야기를 많이 합니다. “나 저거 얼마든지 만들 자신 있는데.” “저건 나도 만들겠다.” 예 할 수 있죠. 의심 안합니다. 하지만, 만들 수 있다는 것이 중요한 것이 아니라 “개발”이라는 것은 엔지니어링에 관한 이야기라는 점입니다. 엔지니어링에 있어서 축적된 경험이라는 것은 굳이 소프트웨어에 있어서만이 아니라 전반에 있어서 엄청나게 중요한 것이구요.

Advertisements

Written by charlz

2009년 2월 23일 at 오후 5:23

Uncategorized에 게시됨

“잘못 알려진 디자인 패턴의 두번째 원칙”에 작은 댓글하나

with one comment

잘못 알려진 디자인 패턴의 두번째 원칙 « arload – load to architect

의외로 일반론에서 답을 얻는 것이 더 이해하기 쉬울 수 있다는 생각을 해봤고, 댓글하나 급 적어봅니다.

인간이 수용할 수 있는 복잡성에는 한계가 있다. 그 한계는 관점에 따라서 다양한 편차를 보인다. 감성과 같은 복잡성은 컴퓨터가 인간을 따라올 수가 없다. 하지만, 반대로 컴퓨터는 연산장치지만 인간의 뇌는 연산장치가 아니다. 보통 사람이 암산으로 처리할 수 있는 연산의 한계는 컴퓨터의 그것에 비하면 아주 초라하다. 정확성을 요구하는 연산과 같은 관점에서는 인간이 수용할 수 있는 복잡성의 한계치는 아주 낮다. 어느 시점에서 컴퓨터의 지능이 인간의 지능을 뛰어넘게 되는 Singularity(특이점)이 발생한다고들 하지만, 이는 감성의 복잡성을 뛰어넘는 지점을 이야기하는 것은 아닐 것이다.

우리의 몸은 우리가 사는 이런 한계를 보이는 물리적인 세상에 적응/순응된 상태로 존재한다. 때로는 몸은 새로운 도구에 적응하고, 반대로 몸을 보조하기 위해서 도구가 만들어지고, 이렇게 펜듈럼처럼 왔다 갔다 한다. 마샬맥루한이 주장했던 것처럼 모든게 몸의 확장(Extension)이자, 칼세이건이 주장했던 것처럼 사는데 필요한 방향으로 우리의 뇌가 진화해 온 것이다. 팔이 필요에 의해서 4개가 되는 등의 급진적인 변화는 아니지만, 파충류의 뇌에서 언어를 사용할 수 있는 뇌로 자라온 진화(혹은 적응)말이다. 혹은 작게는 문자메시지를 보내는데 어려움이 없는 세대와 있는 세대간의 적응 말이다.

인간은 영적인 존재가 아니다. 텔레파시로 교신하고, 텔레포트하는 존재가 아니다. 물리적인 세상과 아주 가깝게 엮여서 익숙해져 있기 때문에 상상력의 나래를 펼쳐서 기가차게 멋진 것을 구상해도 이 물리적인 한계에 부합하지 않으면 실패하기 쉬울 수 밖에 없다. 아무도 이해하지 못하는 세기를 뛰어넘는 생각을 하는 사람을 천재로 분류하지만, 근대에는 이 물리적인 세상과 타협할 수 있는 새로운 변화를 캐치하는 사람도 천재로 분류하기도 한다. 사람을 연구하는 학문들이 다양한 과학기술과 융합하는 것은 점차 흔한 현상이 되어가고 있는 점도 인간의 물리적인 한계를 접목하는 트렌드와 상관이 없다 할 수 없을 것이다.

서론이 좀 뜬금없었을지 모르지만, 요는 사람이 이해하기 위해서는 물리적인 현실에 가까운 복잡성으로 관리되는 방향이 좀 더 현실적인 방향이라는 것이다.

프로그래밍의 OO(Object Oriented, 객체지향)의 역사에 있어서 클래스 상속(Inheritance)이 예상보다 선전하지 못하고(overrated) 컴포넌트라는 가지치기를 하게 된 이유도 이런 복잡성에 기인할 것이라 생각된다. 컴포넌트라고 하는 “결과가 immutable한 엔티티”를 사용하는 것은 설계시의 계약(Contract)을 통해 만든, 물리적으로 우리가 사용하는 (프로토타입을 포함하는) 부품을 대변한다. 현실에서는 설계시에 상속의 속성을 사용할지언정 물리적인 부품들을 모핑(Morphing)하는 것은 불가능하고, 대체(Replace/Reuse)를 한다. 즉 부품을 갈아끼운다는 이야기다. 부품을 갈아끼우는 것과 비현실 속에서 모양을 마구 바꿔대는 것과의 복잡성의 차이는 꽤 크다. 최소한 일반적인 종사자들이라도 이해하기 쉬운 것이 아니란 것이다. 아버지가 바뀌었다고 자식이 바로 바뀌는 것은 물리적인 현실의 이야기가 아니란 것이다. 그것이 가능했다면 사람들이 이해하는 것이 더 쉬웠고 복잡성을 관리하는 것에도 문제가 없지 않았을까. 한마디로 다양한 복잡성은 물리적인 현실과 가까울수록 관리가 쉬워진다는 것.

초기 OO의 복잡성을 그나마 간직한 C++을 일반 프로그래머들이 제대로 활용하지 못하는 것도 그런 연장선상에 있을 것이다. 이런 저런 예외 상황과 장치와 테두리(규칙)을 만들어서 상속의 복잡성을 관리(Managing)하려고 한 시도들은 이런 것을 배우는 사람에게 있어서 장벽이 될 수 밖에 없지 않을까. 물론 잘 관리된 진화로 훌륭한 언어임에는 틀림 없지만 말이다. (물론 계속 진화하면서 Best Practice를 만들어가면서 사람들의 수준을 높이고 있기 때문에 점차 장벽은 낮아진다고 할 수 있겠다.) 그러니 현실에서는 (이해하기 힘들거나 복잡할 수 있는) 상속을 활용하는 것이 필요한 부분은 이를 이해하고 사용하는 일부 전문가들에게 맡기고 거기서 나온 결과물(프레임웍, 제품, 컴포넌트)를 사용하는 방향으로 권장을 하는 것이라 생각된다. 상속을 잘못 사용하여 벌받는(문제가 생기는) 경우가 조합(Composition)을 잘못 사용하여 벌받는 것보다 아마도 페널티가 많을 확률이 높을 것이란 의미로 말이다.

초보 개발자들이 인스턴스(Instance)라는 개념이 확고히 머릿속에 들어가기 위해서 무단한 노력을 해야되는 것도 물리적인 현실에 있어서는 인스턴스와 객체는 다른 것이 아니기 때문일 것이다. 혹은, 다중 상속은 정말 필요한 경우가 아니면 되도록이면 사용하지 말라고 권장했던 조언들도 물리적인 현실과는 사뭇 다른 그 복잡성을 이해하지 못하면 쓰지 말라는 말일게다. 복잡성만 놓고 보면, 이전 EJB vs POJO의 도래도, 너무 다양해진/맹신되는 패턴에 대한 저항도, 혹은 더 넓게 나아가 애자일이라는 움직임도, 다수가 모두 수용하고 교신할 수 있는 복잡성의 정도가 한계에 다다르면 저항이 생기는 그런 예일 것이다.

여하튼 상속은 최대한 그 복잡성을 관리할 수 있는 한도내에서 사용하도록 진화했고 계속 진화하고 있다. 전에 이해하던 방식의 틀을 벗어나는 복잡성이라면 혼자 이해하면 되는 경우라면 상관 없지만 여러 사람들이 사용하는 어떤 것을 만들고 있는 경우라면(이 시대에는 다수의 경우겠지), 이해에 도움이 되는 방향으로 프로그래밍을 하는 것으로 권장을 하는 것은 당연한 것이지 않을까?

…하는 생각.

Written by charlz

2009년 2월 18일 at 오후 4:48

Uncategorized에 게시됨

%d 블로거가 이것을 좋아합니다: