실무 지향적 개발자, 이론 지향적 개발자 - 프롤로그

IT 직종뿐만 아니고 다른 여러 직종에서도 실무 지향 또는 현장 지향적인 일꾼이 있고 이론 지향적인 일꾼이 있습니다만 일반적으로 직접 만들지 않는 직종이 많기 때문에 티가 잘 안 나는 편인데, 전략 수립 및 설계 개발 및 유지보수, 운영을 모두 구성원이 직접 하는 소프트웨어 개발조직에서는 그 차이가 확연하게 드러납니다.

유세 "현장" : 선거 전략은 탁상공론보다 발로 뛰어야 성공합니다.

둘 중에 어떤 쪽이 좋다는 글을 쓸 건 아닙니다. 둘 다 장단점이 있습니다. 하지만 둘 다 장점보다는 단점이 많습니다. 한쪽으로 치우치는 것은 그래서 안 좋습니다. 둘의 장점만을 흡수하여 체화시킨 개발자가 되어야 합니다. 한쪽으로 치우치게 되면 장점보다는 단점이 많은 개발자로 남게 되고 편협한 사람이 되는 거지요.

장점보다 단점이 많다고 했으니 이어지는 글은 아마도 까는 내용이 주가 되겠네요. 저는 비판에 개안한 사람입니다. "불만이 없으면 발전도 없다"라는 신조로 지금까지 일해왔고 여전히 현재 진행형입니다.

물론 저 자신에게 가장 비판적입니다. 그래야 발전을 하니까요. 오랜 세월을 스스로 비판하면서 살아왔으니 까는 것에는 경지에 이르렀다고 말할 수 있겠습니다. 이렇게 비판하는 것에 개안한 사람이 작심하고 까겠다고 선언했으니 신랄한 독설이 될 수도 있지만 읽는 사람들이 자기가 욕먹는 듯한 느낌을 받게 되면 많이 불편할 테니 최대한 자제하도록 하겠습니다.

그리고 노파심때문에 잡설을 하자면, 실무 지향적, 이론 지향적이라는 상반된 두 가지 성향을 이야기함으로 자칫 잘못하면 이분법적 접근 또는 흑백논리로 느껴질 수 있습니다.

이분법적 접근이나 흑백논리는 매우 좋지 않습니다. 하지만 많은 매체 또는 특히 정치권에서는 자주 애용하는 방법이지요. 현상을 왜곡시키기에 아주 효과적이기 때문입니다.

이런 책이 있군요. 읽어 보진 않았습니다.

예를 들면 정량적 접근으로 100가지의 경우를 설명 또는 주장하면 보는 사람 대부분은 5개를 넘기지 못하고 나가떨어집니다. 저 100가지도 교묘하게 왜곡시키면 전부 다 보는 사람도 나가떨어집니다.

그래서 기억하기도 좋고 선과 악으로 몰아가기도 좋은 이분법적 접근법 또는 흑백논리로 교묘하게 설명 또는 주장을 하는 것이고 많은 사람들이 알게 모르게 이런 조작질에 익숙해졌습니다. 자기도 모르게 이분법적 사고를 합니다.

정말 오랫동안 많은 사람들하고 대화를 하면서 답답함을 많이 느껴왔고 여전히 느끼고 있습니다. 일 뿐만 아니고 세상사라는게 O, X로 나눠질 만한 것은 아무것도 없는데 정말 많은 사람들이 그렇게 사고를 하고 있으니 논리적인 대화가 되기 힘듭니다.

출처: Daum 어학사전

개발자도 사람입니다. 정말 다양한 사람들이 있고 저 사람은 실무적이다. 저 사람은 이론적이다라고 단정 지을 수는 없습니다. 단지 치우쳐 있을 뿐이고 정도의 차이도 다양합니다. 이어지는 제 글도 그중에서 양극단에 치우친 경우를 설명하게 될 것이니 그대로 받아들이지 말고, 정도의 차이가 있을 것이고 양쪽 성향을 모두 가진 사람도 많다는 것을 잊지 마시기 바랍니다.

이 글을 읽는 분이 개발자 또는 개발자가 되려는 사람이라면 앞으로 어떤 자세로 일해야 하는지 참고가 되기를 바랍니다. 또 읽는 분이 관리자라면 혹은 경영자라면 어떤 개발자가 좋은 개발자인지를 판단하는 데 도움이 되기를 바랍니다.

다음 글 부터 이제 제대로 파헤쳐 보겠습니다.