제가 웹 에이전시(web agency)에서 근무할 때, 개발팀에는 전문 디자이너들이 만들어낸 이미지를 웹 페이지로 변환하는 전문 엔지니어 그룹이 휘하에 있었습니다. 보통 코더(coder)라고 불리웠는데, 최근 웹 UI가 많이 발전하고 있고 그에 따라 고급 기법들을 많이 사용하기 때문에 이제는 '웹 UI 전문가'라고 불러주는게 옳겠죠. 하여간, 개발팀 내에 프로그래머들 중 초급 엔지니어들을 코더(coder)라고 부르기도 하니까 호칭 상의 혼동이 발생하는 경우가 많았습니다. 그래서, 고민하다 퍼블리셔(publisher)라고 불러 주기로 했습니다. 코더라는 표현 자체가 전문가라는 느낌을 살리지 못하니까..
그런데, 개발자 혹은 프로그래머 그룹 중에는 여전히 코더(coder)가 존재합니다. 코더라는 역할 자체가 아예 없을 수는 없습니다. 꼭 나쁜 것만은 아니거든요. 문제는 조직이 발전하기 위해서는 당연히 조직에 속한 개인이 성장해야 합니다. 개인이 성장하지 못하는 조직이 커나가는 방법은 뻔합니다. 발전하지 못하는 개인을 조직에서 제외하는 것이지요. (이런 주장을 실천에 옮긴 사람 중에서 가장 유명한 분이 바로 잭 "나이프" 웰치 회장님이죠.)
코더는 소프트웨어 엔지니어가 거쳐가는 중간 단계여야 합니다. 개인과 조직 모두를 위해서 말입니다. 그런데, 늘 문제는 대다수의 코더들이 자신이 결단코(!) 프로그래머라고 여긴다는 것이죠. 얼굴을 맞대고 일하는 입장에서 냉정한 비판을 하기는 어렵지만, 간접적으로 깨달음(?)을 촉구할 수는 있을 겁니다. 그래서, 제 나름의 주관적인 기준을 제시해 볼까 합니다. 아래의 모든 기준을 만족해야 하는 것은 아닙니다. 어떤 항목들은 프로그래머를 뛰어넘는 기준이 될 수도 있습니다. 어쨋든, 제 주관적인 기준이니까요~
What You Can & Can not
- 프로그래밍 언어를 하나 이상 알고 있다.
> 하지만 언제 어떤 프로그래밍 언어를 사용해야 하는지는 모른다.
- 타인이 작성한 코드를 해석할 수 있다. 인터넷에서 샘플 코드를 찾을 수 있다.
> 하지만 그걸 더 나은 코드로 개선하지 못한다.
- 함수, 객체, 클래스, 나아가 추상 클래스의 개념은 이해한다.
> 그런데, 언제 인터페이스를 사용해야 하는지는 모른다.
- 프레임워크를 사용해서 개발해 봤다.
> 프레임워크를 설계하는 법은 모른다.
- 타인에 제공하거나, 공개 소스 기반의 라이브러리를 써봤다.
> 하지만, 스스로가 직접 만들어 재사용하는 라이브러리가 없다.
- 왠만한 요구사항에 대해서는 바로 프로그램을 구현할 수 있다.
> 구현하기 전에 어떻게 구현할 지 서술하라고 하면 못하겠다.
- 다양한 프로그램을 실제로 구현해 봤다.
> 그런데, 컴포넌트 설계서 따위는 작성해 본 적이 없다.
- 분석/설계라던가 방법론에 대해서 어렴풋이 들어봤거나 실무에 적용해 봤다.
> 혼자서 설계하라고 하면 포기하고 집에 간다 혹은 싸운다.
- UML을 학습해 본 적이 있다.
> 막상 실무에서는 거의 쓰지 않는다.
- 동료 프로그래머들과 문제 해결에 대한 토론도 자주하고, 조언도 구한다.
> 그런데, 막상 내 코드를 보여 주거나, 코드를 가지고 토론하지는 않는다.
- 디자인 패턴이라던가 리팩토링 개념이 무언지를 안다.
> 알기는 하는데 실제로 써본 게 별로 없거나 왜 쓰냐고 물으면 답을 못하겠다.
- MVC 모델, 웹 2.0, 클라우드 컴퓨팅 등 최신 기술 트렌드에 민감하다.
> 하지만, 그런 시스템의 단점을 말하라면 모르겠다.
- 프로그래머이니까, 내가 잘 쓰는 언어를 가지고 왠만한 문제는 해결 가능하다.
> 그런데, 두 가지 이상의 언어로 구현하라면 못한다.
혹시 여러분이 생각하시는 다른 기준이 있으신가요?
P.S 간단 요약 : 당신의 머리(뇌)로 코드를 작성하신다면 프로그래머, 손이나 발로 작성하신다면 코더!
http://sunnykwak.egloos.com/3954669[퍼옴]
그런데, 개발자 혹은 프로그래머 그룹 중에는 여전히 코더(coder)가 존재합니다. 코더라는 역할 자체가 아예 없을 수는 없습니다. 꼭 나쁜 것만은 아니거든요. 문제는 조직이 발전하기 위해서는 당연히 조직에 속한 개인이 성장해야 합니다. 개인이 성장하지 못하는 조직이 커나가는 방법은 뻔합니다. 발전하지 못하는 개인을 조직에서 제외하는 것이지요. (이런 주장을 실천에 옮긴 사람 중에서 가장 유명한 분이 바로 잭 "나이프" 웰치 회장님이죠.)
코더는 소프트웨어 엔지니어가 거쳐가는 중간 단계여야 합니다. 개인과 조직 모두를 위해서 말입니다. 그런데, 늘 문제는 대다수의 코더들이 자신이 결단코(!) 프로그래머라고 여긴다는 것이죠. 얼굴을 맞대고 일하는 입장에서 냉정한 비판을 하기는 어렵지만, 간접적으로 깨달음(?)을 촉구할 수는 있을 겁니다. 그래서, 제 나름의 주관적인 기준을 제시해 볼까 합니다. 아래의 모든 기준을 만족해야 하는 것은 아닙니다. 어떤 항목들은 프로그래머를 뛰어넘는 기준이 될 수도 있습니다. 어쨋든, 제 주관적인 기준이니까요~
What You Can & Can not
- 프로그래밍 언어를 하나 이상 알고 있다.
> 하지만 언제 어떤 프로그래밍 언어를 사용해야 하는지는 모른다.
- 타인이 작성한 코드를 해석할 수 있다. 인터넷에서 샘플 코드를 찾을 수 있다.
> 하지만 그걸 더 나은 코드로 개선하지 못한다.
- 함수, 객체, 클래스, 나아가 추상 클래스의 개념은 이해한다.
> 그런데, 언제 인터페이스를 사용해야 하는지는 모른다.
- 프레임워크를 사용해서 개발해 봤다.
> 프레임워크를 설계하는 법은 모른다.
- 타인에 제공하거나, 공개 소스 기반의 라이브러리를 써봤다.
> 하지만, 스스로가 직접 만들어 재사용하는 라이브러리가 없다.
- 왠만한 요구사항에 대해서는 바로 프로그램을 구현할 수 있다.
> 구현하기 전에 어떻게 구현할 지 서술하라고 하면 못하겠다.
- 다양한 프로그램을 실제로 구현해 봤다.
> 그런데, 컴포넌트 설계서 따위는 작성해 본 적이 없다.
- 분석/설계라던가 방법론에 대해서 어렴풋이 들어봤거나 실무에 적용해 봤다.
> 혼자서 설계하라고 하면 포기하고 집에 간다 혹은 싸운다.
- UML을 학습해 본 적이 있다.
> 막상 실무에서는 거의 쓰지 않는다.
- 동료 프로그래머들과 문제 해결에 대한 토론도 자주하고, 조언도 구한다.
> 그런데, 막상 내 코드를 보여 주거나, 코드를 가지고 토론하지는 않는다.
- 디자인 패턴이라던가 리팩토링 개념이 무언지를 안다.
> 알기는 하는데 실제로 써본 게 별로 없거나 왜 쓰냐고 물으면 답을 못하겠다.
- MVC 모델, 웹 2.0, 클라우드 컴퓨팅 등 최신 기술 트렌드에 민감하다.
> 하지만, 그런 시스템의 단점을 말하라면 모르겠다.
- 프로그래머이니까, 내가 잘 쓰는 언어를 가지고 왠만한 문제는 해결 가능하다.
> 그런데, 두 가지 이상의 언어로 구현하라면 못한다.
혹시 여러분이 생각하시는 다른 기준이 있으신가요?
P.S 간단 요약 : 당신의 머리(뇌)로 코드를 작성하신다면 프로그래머, 손이나 발로 작성하신다면 코더!
http://sunnykwak.egloos.com/3954669[퍼옴]
