Younghoe.Info (final edition)

* 본 글은 월간마소 네이버 뉴스케스트에 기고한 글입니다.

‘스티브 잡스처럼 되려면 개발자 아닌 아키텍트의 길을 가라’라는 기사가 있다. 이 기사뿐 아니라 인터넷에 올라온 의견을 보면 개발자와 아키텍트를 대결 구도로 쓴 내용이 많다. 이분법으로 개발자와 아키텍트를 나누는 일에 대해 유익한 점과 그렇지 않은 점에 대해 이야기를 꺼내 보려고 한다. 우선 양분해서 이로운 점은 무엇일까? 개발자와 아키텍트가 다루는 문제 사이에는 분명 다른 면이 있다. 넓은 의미에서 개발자가 아키텍트를 포함한다고 생각하지만, 일반적으로 개발자라고 하면 코드수준에서 고민해야 한다. 당면 과제가 돌아가는 코드와 눈에 보이는 화면이기 때문에 개발자는 미세한 문제까지 고민한다. if 문의 미묘한 차이에 따라 프로그램은 완전히 다르게 동작하고 UI 컴포넌트가 어떤 화면의 어느 위치에 존재하느냐에 따라 사용자는 전혀 다른 프로그램을 만나기 때문이다. 그래서 개발하려는 프로그램이 커지면 모두가 ‘세세한 내용까지 관심을 두는’ 개발자여서는 곤란하다. 누군가는 세세한 의견을 조율하고, 성격이 다른 코드 조각을 엮어내는 조정자가 필요하다. 그 사람은 개발자 사이에서 조정할 수도 있고, 개발자와 사용자 사이에서 중재하기도 한다. 또, 같은 사용자라고 해도 모든 사용자마다 다른 화면을 제공할 수 없어서 사용자 역할에 따라 적절한 무리를 만들고, 요구사항을 수렴하여 평균적인 화면과 기능으로 합의를 이끌어야 한다. 이처럼 일반적인 개발자와는 구분되는 시각과 역할을 가진 이가 필요하고, 아키텍트란 이름이 흔히 쓰인다.

 

그렇다면 이들의 구분이 유익하지 않은 경우는 무엇일까? ‘구분 짓는 행위’는 일종의 생각하는 기법이다. 앞서의 구분이 서로 다른 역할의 필요성을 드러내기 위함이었는데, 간혹 개발자와 아키텍트를 나누는 글의 바탕에 ‘직업의 귀천’을 깔아두는 내용을 발견한다. 인용한 글에서도 아키텍트의 중요성을 부각하기 위해 ‘단순 용역을 담당하는 개발자’라는 표현을 사용했다. 나는 아키텍트 양성이 중요하다는 말에 왠지 거부감을 느낀다. 그렇다면 개발자 양성은 중요하지 않은가? 설마 우리 곁에 훌륭한 개발자가 많아서 아키텍트가 필요하다 생각하는가? 내 경험으로는 과거 아키텍트 양성(?) 효과인지 훌륭한 개발자는 부족한데 반해 피상적인 지식을 갖춘 아키텍트는 부족하지 않았다. BA나 AA라고 하지만 일반적인 업무처리만 생각하고 수년 혹은 수십 년간 이어온 고객사의 특수성에 대한 분석은 내 일이 아니라는 사람, DA라고 하지만 실상은 단일 DBMS를 위한 DB 모델링 외엔 이야기를 나누기 어려운 사람, TA라고 하지만 타겟 프로그램이 웹 환경인데 웹에 대해서는 잘 모르는 사람을 만날 수 있다. 

 

교육 사업을 하는 사람이 ‘아키텍트를 키워야 한다’고 주장하는 경우를 흔히 본다. 분명히 아키텍트를 키우는 일은 의미 있는 일이고, 반드시 교육이 필요하다. 그러나 과연 아키텍트 교육이 개발자 교육과 구분해서 다룰 문제인가? 그리고 우리 사회에서 개발자 교육은 충분히 존재하는가? 대학 교육은 실무와 엄청난 거리감이 있다. 그나마 존재하는 학원이나 교육기관이 초보적인 기술 교육을 제공하지만, 다음 단계를 나아가려고 하면 교육 프로그램을 찾기 어렵다. 아키텍트 교육은 성격상 MBA 과정처럼 사례 연구 형태가 적합하다고 생각한다. 현장에서 쓰이는 상세 기술과 설계 기법에 대한 일반화도 되어 있지 않은 상태에서 서로 다른 경험치를 가진 참가자 사이에서 충분한 소통이 가능할까? 설사 그렇게 아키텍트를 양성했다고 해도 그들이 그려내는 그림을 실현할 준비된 개발자는 충분한가?

개빈 킹이 Seam을 모호한 이름으로 바꿨던 일 이후 오랜만에 후속 이야기를 담을 포스트를 봤다. Seam(JSR-299)과 Spring(JSR-330)의 만남이다. Toby 에게 미끼를 던진 셈인데 별 반응이 없었다. 알고 보니 고열로 고생하고 있었다. 아쉽다고 했더니만, 역시나 하루 만에 글 썼다. 스스로 표준에 관심이 없다곤 하지만 산업 표준 특성상 최종 결과가 만들어지기까지 꽤 긴 이력을 갖는데, Dependency Injection 표준화? 를 보면 해박함을 알 수 있다.

Toby형과 마찬가지로 JSR의 결과에는 관심이 전혀 없다. JSR이야 JCP에 가담하는 업체(vendor)가 흥행을 꾀할 수는 있다. 하지만, 노련한 자바 개발자라면 Java 7 정도나 관심이 있지 않을까? 특히나 JEE를 구성하는 JSR은 시시하면서 복잡하기 이를 데 없다.

차분히 생각해보니 일터에서 표준을 고민하거나 만드는 역할을 맡는다. 헉! 그런 처지에 말조심하지 않는 경솔한 태도라니.

조직 표준이라 할 EA(Enterprise Architecture)를 강조하는 사람이 많다. 특히 학계 교수님이 많다. 그리고, 2, 3년 전 한바탕 EA 바람이 불고 갔다. 대규모 기업은 의례 EAMS나 메타 시스템 정도는 기본이다. 안을 들여다보면 참조 모델이 수십 개고, 표준 가이드가 수십 개다. 취지도 좋고, 내용도 나쁘지 않다. 하지만, 2, 3년 세월이 흘렀는데 처음 내용 그대로다. 초심을 잊지 말아야 하는데, 초심은 잃고 처음 만든 내용만 세월에 고스란히 낡아간다.

이런 현실을 경험하는 일은 행운이다. 그래서, 기술자로서 관심을 두는 멋진 기술과 기법 나아가 아귀가 딱딱 맞는 아카데믹한 체계를 버릴 수 있다. 비록 내가 만든다고 하더라도 주인은 다른 사람이다. 유지보수를 담당할 운영자가 편안하게 느낄 수 있어야 한다. 그들 삶에 조금이나마 도움을 주어야 한다. 굳이 욕심을 부리자면 그들이 미래에도 경쟁력을 갖도록 동지애를 갖고 새로운 흐름을 수용할 수 있게 도울 수 있으면 충분하다. 물론, 말처럼 쉽지 않다. :)

Toby 형이 읽어보라고 권장한 링크다.


생생하고 절절한 글을 또 찾아볼 수 있다. 충분히 성장 동력일 수 있는 '공부병기'가 왜 아내에게 고통스런 삶을 안겨주는 장본인이어야 할까?

이런 개발자를 대할 때면, 사실 개발자가 아니더라도 철저한 생활인을 대할 때면 고개를 숙일 수 밖에 없다. 겉으로 아닌 척 해봐야 소용 없으니까. 그 치열함에 대면 누구^[각주:1] 말대로 난 듣보잡이다. 치졸한 감정과 게으름, 수지타산을 떨쳐 버리고 홀연히 이상 혹은 우아함을 추구할 공력이 내게는 없다. 막연한 추측이지만, 분명 T사에는 열정이 넘치고 뛰어난 개발자가 많이 있을 듯 하다.

그런데 세상엔 다른 부류의 개발자도 많다. 그저 유행을 쫓아 곳곳에 기웃거리는 이도 있고, 쿼리 하나 못 짜고 디버깅도 못하는 점을 부끄러워 하지 않는 개발자도 흔히 볼 수 있다.

그렇다면, T사 핵심 개발자와 쿼리 하나 제대로 못 짜는 개발자 삶의 질은 극명한 차이를 보일까? T사 핵심 개발자는 병기에 가까운 헌신에 대한 보상을 충분히 받을까? 그렇다면 인용한 글을 보지 못했으리라. 개발자에게 적합한 보상이 이뤄지는 세상은 언제 올까?

낮에는 프로젝트 중반에 고객과 개발자 사이에 갈등이 표출되는 광경을 보다가, 밤에는 제안 작업을 하느라 고객 설득을 위한 문서를 작성한다. 그러는 중에 사랑하지 않으면 떠나라에서 개발자와 고객에 대해 언급하는 이야기들을 화두로 해서 생각을 옮겨둔다.

이 책 전체에서 가장 인상적인 부분은 35, 36쪽에 걸쳐서 나온 내용이다.


무릎을 칠만한 절묘한 예시다. Hz와 RPM은 보통의 14살 아이에게 흥미롭지 않고, 사업가에게도 그렇다. 발췌한 글이 나오는 부분의 제목은 '적절한 표현으로 말하기'이다. 종종 ISP에 참여를 권하는 선배들도 같은 맥락이다. 엔지니어 시각으로는 고객이 정말 원하는 것을 설계하고 만들기가 어렵다. 96쪽에서 여기에 대해 말하고 있다.


위 표현에 대한 예시로 본인 경험을 들었다. 하던 작업을 마무리 하고 싶은데, 쌩뚱맞은 차트를 계속보여주는 리더를 보며 시간 낭비라고 투덜거리는 모습. 아타깝게도 이 글을 쓰기 직전 산출물 교육을 하고 왔는데, 자신과 관계 없는 내용이라고 여기는 1/3 정도 개발자는 발표자료 대신에 아무것도 놓여있지 않은 책상표면을 보는 것을 택했다. 이런 상태이거나 막 벗어나려는 상태라면 누구를 위해 일하는지 기억하라(146쪽)를 읽어보시라. 관리자의 성공과 여러분의 성공을 분리하지 말라. (148쪽) 한발 더 나아간 상황이라면 다음 말에 귀를 기울일 필요가 있다.


내 수준에 어울리는 실천지침이라서 가까운 시일내에 실천하기로 마음 먹었다.

202쪽을 보면 개발자 관점이 아니라 고객 관점에서 비슷한 현상을 되짚어 볼 수 있다. 고객은 개발자를 두려워하고, 자기가 하는 프로젝트에 대해 편하게 말해줄 사람을 찾으려 한다는 것!

예전에 어떤 프로젝트에서 PM이 개발자의 말을 통역(?)해주는 일을 무척 고마워했다. 책 내용을 조금 더 보자.


민망한 내용이지만 사실 자주 목격한다. 자주 범하고 있는지도 모르지만, 사실 자신의 실수는 잘 보이지 않는다.

사랑하지 않으면 떠나라! - 차드 파울러 지음, 송우일 옮김/인사이트