설계라는 이름의 배움 – 내가 만난 두 명의 아키텍트

2001년 초반, 사회에 첫발을 내딛은 나는 운 좋게도 회사의 전략 과제 중 하나를 맡게 되었다. 캐나다와 한국의 연구업체에서 각각 1년간 개발한 리눅스 기반의 스마트폰 플랫폼 프로젝트였고, 나의 임무는 그 결과물을 파악하고 인수해 양산화 준비를 하는 것이었다. 

막 입사해 경험이 부족한 신입에게는 꽤 중대한 역할이라 두려움도 컸지만, 그동안 열정적인 커뮤니티 활동과 꾸준히 쌓아온 개발 프로젝트 실력을 믿고 내심 기대와 근거 없는 자신감이 있었다. 그렇게 캐나다로 날아갔다. 그리고 그곳에서 한 아키텍트를 만났다.

그의 이름은 칩 왕(가명), 중국계 교수 출신으로 프로젝트의 아키텍트를 맡은 사람이었다. 그와의 첫 미팅을 기억한다. 프로젝트 인수 회의 첫날, 그는 나를 회의실로 안내했고, 벽 한쪽을 가득 채운 화이트보드 앞에서 전체 플랫폼 구조를 설명하기 시작했다. 무엇보다 인상적이었던 건 그의 설계 전달 방식이었다.

그는 단순히 소스 코드나 API 목록 위주가 아닌 설계 의도, 구성 요소 간의 인터랙션, 디자인 패턴, 제약 조건, 구현상의 트레이드오프까지 한 장면 한 장면을 그리듯이 설명했다. 한 장의 아키텍처 다이어그램 위에 수많은 고려와 판단이 쌓여 있다는 걸, 그때 처음 실감했다.

처음엔 그저 다이어그램 하나일 뿐이라고 생각했다. 

그러나 그의 설명이 시작 되면서 나는 그것이 단순한 기능 구성도가 아니라, 고민의 흔적과 선택의 역사가 담긴 작품이라는 걸 느꼈다. 모듈 간의 관계, 추상화된 계층 구조, 데이터 흐름의 방향성, 그리고 예외 상황을 처리하기 위한 백업 로직까지 그의 설명은 단순한 문서가 아니라 이야기였다.

무엇보다 인상 깊었던 것은 그의 태도였다. 그는 친절했고, 전문적이었으며, 무엇보다 유쾌한 사람이었다. 아직 미숙한 나를 배려해 여러 번 설명을 반복해 주었고, 내가 던진 엉뚱한 질문에도 성실히 답해 주었다. 

특히 인상 깊었던 건, 그가 설계 설명 중간 중간에 말했던 “이건 우리가 꼭 고려해야 하는 실패 조건이야”, “여기엔 숨은 병목이 있어, 작은 이슈처럼 보여도 나중에 커진다”는 말들이었다. 그는 단순한 구현이 아니라 상품화와 유지보수 문제까지 내다보는 시야를 가지고 있었다.

그 만남은 단순한 기술 전수가 아니라, 소프트웨어 아키텍트라는 존재가 어떤 사람이어야 하는지를 보여주는 살아 있는 생생한 깨달음의 현장이었다. 몇 주의 시간이 흘러 귀국행 비행기 안에서 처음으로 이런 생각을 했다.

‘나도 그 사람처럼 되고 싶다. 그렇게 성장하고 싶다’

그는 단순히 뛰어난 아키텍트가 아니었다. 지식과 경험을 나눌 줄 아는 전문가, 그리고 사람을 대하는 태도에서 따뜻함과 책임감을 가진 진짜 아키텍트였다. 그와의 짧은 만남은 내 커리어의 방향을 바꾸었다. 

그 전까지는 ‘무엇을 만들 것인가’가 내 관심의 전부였다면, 그 이후로는 ‘어떻게 만들고, 왜 그렇게 만들어야 하며, 그것이 어떤 영향을 주는가’를 생각하게 되었다. 그리고 지금까지도 내가 설계를 문서화할 때, 동료에게 설명할 때 또는 후배를 멘토링할 때마다 나는 무의식 중에 그 사람을 떠올린다.

돌이켜 보면 그것은 단지 한 프로젝트의 인수 과정이 아니라, 내 삶의 방향을 바꾸는 소프트웨어 아키텍트라는 직업에 대한 첫 통찰의 기회였다. 기술은 공유되어야 하고, 설계는 이유를 담아야 하며, 사람을 위한 배려가 기술만큼 중요하다는 걸 그가 가르쳐주었다. 그리고 나는 여전히 그 길 위에 있다. 

언젠가 누군가가 나를 보고 “저 사람처럼 되고 싶다.”라고 생각해 준다면, 그건 아마 그때 그가 내게 남긴 영향이 다음 세대로 이어지는 순간일 것이다.

다른 만남 - 닫힌 설계, 닫힌 마음

캐나다에서 돌아온 뒤, 나는 곧바로 동일한 임무를 안고 한국의 연구 업체를 찾아갔다. 국내 유수 대학의 교수와 연구소 출신들이 그 프로젝트를 주도했다. 

겉보기엔 전문성이 높고 조직적이었지만, 며칠 동안 협업하면서 나는 점점 실망했다. 시스템 소프트웨어, 특히 리눅스 커널이나 드라이버 수준의 코드는 수준이 높았지만, 중점을 두었던 애플리케이션 플랫폼 설계는 많이 아쉬웠다.

설계 문서는 단순했고, 설명은 생략되어 있었으며, 설계의 이유나 대안적 접근의 고민이 없었다. “왜 이렇게 설계하셨나요?”라는 질문에 돌아온 답은 대부분 “그게 익숙해서요” 혹은 “그게 맞지 않나요?”였다. 피드백을 주면 “이건 원래 그렇게 하는 겁니다”라는 식의 반응이 많았고, 토론은 방어로 이어졌다. 열린 설계가 아니라, 닫힌 고집이 설계를 지배하고 있었다.

그 경험은 솔직히 유쾌하지 않았다. 단순히 기술 수준의 차이 때문이 아니었다. 언어의 장벽이 있었던 캐나다 아키텍트에게서 느꼈던 공유와 배려, 통찰과 여백 같은 것들이 이곳에서는 느껴지지 않았기 때문이었다. 

그들은 코드를 구현하고 있었지만, 프로젝트를 ‘수행’하고 있을 뿐, 함께 성장하는 ‘과정’을 만들고 있지는 않았다. 칩 왕은 설계를 사람과의 협업을 위한 언어로 생각했고, 이쪽에서는 설계를 정답처럼 고정된 산출물로 여겼다. 기술 그 자체보다 기술을 대하는 방식의 차이가 조직의 성숙도를 결정짓는다는 사실을 그제야 체감하게 되었다.

그때 처음으로 나는 기술보다 더 중요한 것이 있다는 걸 느꼈다. 그것은 바로 태도와 관점 그리고 설계에 담긴 철학이었다. 한 줄의 코드보다 왜 그 코드를 그렇게 써야 했는지를 설명할 수 있는 힘. 아키텍트란 단지 ‘잘 만든 것’을 자랑 하는 사람이 아니라 ‘왜 그렇게 만들었는지’를 조용히 말해줄 수 있는 사람이라는 것을 그제야 깨달았다.

돌이켜보면 그 경험은 불편했지만, 나에겐 또 하나의 큰 배움이었다. 그것은 ‘우수함’과 ‘성숙함’은 다르다는 것, 그리고 기술적 수준이 같아도 조직과 문화, 태도에서 오는 차이가 어떤 결과를 만드는지에 대한 인식이었다. 그 경험은 내게 불편했고 아쉬웠지만 동시에 아주 강렬한 교훈이었다.

설계란 도면을 만드는 일이 아니라 공동의 목표를 향한 사고를 구조화하는 과정이라는 사실을 나는 두 사람을 통해 배웠다.

‘엘리베이터를 타라’는 조언

몇 해 전, 나는 AWS re:Invent 행사에서 그레고 호페 ^{Gregor Hohpe} 를 만나 얘기를 나눴다. 그는 한창 『Platform Strategy』라는 책을 탈고하고 있었는데, 아키텍트에 대해 의견을 들었다.

 『소프트웨어 아키텍트 엘리베이터』(에이콘, 2022)라는 책에서도 말했지만, 그는 아키텍트를 “엘리베이터를 타고 엔진룸과 펜트하 우스 사이를 오가는 사람”이라 정의한다. 위로는 경영진과 비즈니스 전략을 이해하고, 아래로는 개발자들과 기술의 언어로 소통하는 사람, 그게 아키텍트라는 것이다. 

‘좋은 아키텍트는 복잡함을 숨기는 것이 아니라, 복잡함을 관리 가능한 구조로 바꾸는 사람이다.’ 단지 기술 스택을 많이 알고 있는 것이 아니라, 조직과 시스템의 ‘구조’를 이해하고 설계하는 능력이 진짜 아키텍트의 자산이라 말한다.

너무 이상적으로 들릴 수 있다. 특히 아키텍트의 직군 구분이 분명하지 않은 한국의 IT 현실에서 위아래로 소통하는 게 쉬운 일은 아닐 것이다. 게다가 위계적인 조직 문화는 아키텍트의 역할 확대를 제한하는 데 한 몫한다. 

그는 아키텍트가 ‘엘리베이터를 타며’ 기술과 비즈니스를 연결해야 한다고 말하지만, 한국에서는 경영진과 개발자 사이의 소통이 중간 관리층에 의해 단절되는 경우가 많고 충분한 권한이 주어지지 않아 어려움이 많다. 이는 아키텍트가 비즈 니스 전략을 기술적 결정에 반영하기 어렵게 만든다.

기술, 비즈니스, 사람을 이어주는 역할을 하려면 커뮤니케이션과 팀워크가 중요하다. 경영진에게 클라우드와 오픈소스, 새로운 기술이 주는 효과를 비즈니스 언어로 설명하는 것이 신뢰를 얻는 데 큰 도움이 된 경우를 실제로 본 적이 있다. 

이렇게 개발자와 경영진 사이를 오가며 양측의 언어를 번역하고, 전략적 결정을 기술적 실행으로 연결해야 한다. 끊임없이 배우고, 질문하며, 엘리베이터를 타고 엔진룸과 펜트하우스를 오가는 여정을 즐기길 바란다. 

그리고 지금, 당신에게 전하고 싶은 말 

나는 종종 나와 같은 꿈을 꾸는 후배 개발자들을 만난다. 그들은 나에게 묻는다. “어떻게 하면 아키텍트가 될 수 있나요?” 나는 이렇게 답한다. 

“좋은 코드를 넘어서, 좋은 대화를 시작하면 어떨까요?”

 아키텍트는 폭넓은 경험과 지식, 통찰이 필요하지만 사람과 구조를 연결하는 사람이니, 시스템만 보지 말고 사람을 보라고 말한다. 팀의 흐름, 조직의 제약, 사용자 경험의 본질까지 생각하는 연습을 해 보길 조언한다. 

한국에서 아키텍트로 성장하는 길은 쉽지 않다. 정형화된 커리어 트랙도, 명확한 멘토도 부족하다. 하지만 그렇기 때문에 당신의 경험이 바로 길이 될 수 있다.

작은 서비스 하나의 구조를 개선하는 데서 시작해도 좋다. 코드 리뷰를 통해 설계의 목적을 설명하는 연습을 해 보자. 커뮤니티와 문서화를 게을리하지 말고, 기술적 결정을 말로 풀어내 보라. 그리고 내가 틀릴 수 있다는 가정하에 좋은 대화를 해보자. 

내가 그때의 그를 닮고 싶었던 것처럼, 이러한 태도는 누군가 당신을 닮고 싶어 하는 아키텍트로 만들어 줄 것이다. 내가 칩 왕을 닮고 싶은 것처럼 당신을 닮고 싶은 아키텍트로 만들어 줄 것이다.

위 글은 『아키텍트 첫걸음』 한국어판 특별 부록에서 발췌하였습니다.