‘스티브 잡스처럼 되려면 개발자 아닌 아키텍트의 길을 가라’라는 기사가 있다. 이 기사뿐 아니라 인터넷에 올라온 의견을 보면 개발자와 아키텍트를 대결 구도로 쓴 내용이 많다. 이분법으로 개발자와 아키텍트를 나누는 일에 대해 유익한 점과 그렇지 않은 점에 대해 이야기를 꺼내 보려고 한다. 우선 양분해서 이로운 점은 무엇일까? 개발자와 아키텍트가 다루는 문제 사이에는 분명 다른 면이 있다. 넓은 의미에서 개발자가 아키텍트를 포함한다고 생각하지만, 일반적으로 개발자라고 하면 코드수준에서 고민해야 한다. 당면 과제가 돌아가는 코드와 눈에 보이는 화면이기 때문에 개발자는 미세한 문제까지 고민한다. if 문의 미묘한 차이에 따라 프로그램은 완전히 다르게 동작하고 UI 컴포넌트가 어떤 화면의 어느 위치에 존재하느냐에 따라 사용자는 전혀 다른 프로그램을 만나기 때문이다. 그래서 개발하려는 프로그램이 커지면 모두가 ‘세세한 내용까지 관심을 두는’ 개발자여서는 곤란하다. 누군가는 세세한 의견을 조율하고, 성격이 다른 코드 조각을 엮어내는 조정자가 필요하다. 그 사람은 개발자 사이에서 조정할 수도 있고, 개발자와 사용자 사이에서 중재하기도 한다. 또, 같은 사용자라고 해도 모든 사용자마다 다른 화면을 제공할 수 없어서 사용자 역할에 따라 적절한 무리를 만들고, 요구사항을 수렴하여 평균적인 화면과 기능으로 합의를 이끌어야 한다. 이처럼 일반적인 개발자와는 구분되는 시각과 역할을 가진 이가 필요하고, 아키텍트란 이름이 흔히 쓰인다.
그렇다면 이들의 구분이 유익하지 않은 경우는 무엇일까? ‘구분 짓는 행위’는 일종의 생각하는 기법이다. 앞서의 구분이 서로 다른 역할의 필요성을 드러내기 위함이었는데, 간혹 개발자와 아키텍트를 나누는 글의 바탕에 ‘직업의 귀천’을 깔아두는 내용을 발견한다. 인용한 글에서도 아키텍트의 중요성을 부각하기 위해 ‘단순 용역을 담당하는 개발자’라는 표현을 사용했다. 나는 아키텍트 양성이 중요하다는 말에 왠지 거부감을 느낀다. 그렇다면 개발자 양성은 중요하지 않은가? 설마 우리 곁에 훌륭한 개발자가 많아서 아키텍트가 필요하다 생각하는가? 내 경험으로는 과거 아키텍트 양성(?) 효과인지 훌륭한 개발자는 부족한데 반해 피상적인 지식을 갖춘 아키텍트는 부족하지 않았다. BA나 AA라고 하지만 일반적인 업무처리만 생각하고 수년 혹은 수십 년간 이어온 고객사의 특수성에 대한 분석은 내 일이 아니라는 사람, DA라고 하지만 실상은 단일 DBMS를 위한 DB 모델링 외엔 이야기를 나누기 어려운 사람, TA라고 하지만 타겟 프로그램이 웹 환경인데 웹에 대해서는 잘 모르는 사람을 만날 수 있다.
교육 사업을 하는 사람이 ‘아키텍트를 키워야 한다’고 주장하는 경우를 흔히 본다. 분명히 아키텍트를 키우는 일은 의미 있는 일이고, 반드시 교육이 필요하다. 그러나 과연 아키텍트 교육이 개발자 교육과 구분해서 다룰 문제인가? 그리고 우리 사회에서 개발자 교육은 충분히 존재하는가? 대학 교육은 실무와 엄청난 거리감이 있다. 그나마 존재하는 학원이나 교육기관이 초보적인 기술 교육을 제공하지만, 다음 단계를 나아가려고 하면 교육 프로그램을 찾기 어렵다. 아키텍트 교육은 성격상 MBA 과정처럼 사례 연구 형태가 적합하다고 생각한다. 현장에서 쓰이는 상세 기술과 설계 기법에 대한 일반화도 되어 있지 않은 상태에서 서로 다른 경험치를 가진 참가자 사이에서 충분한 소통이 가능할까? 설사 그렇게 아키텍트를 양성했다고 해도 그들이 그려내는 그림을 실현할 준비된 개발자는 충분한가?
