아키텍트로 전향하고픈 엔지니어가 알아야 할 사항

이 글을 읽는 개발자 혹은 엔지니어분들은 해당 직무에서 꽤 오랫동안 일해 왔고, 개발 시 필요한 라이브러리 및 모듈에 대해서는 이미 잘 알고 계십니다. 개발 시 발생하는 버그도 디버깅을 통해 다 해결해봤지요. 담당하는 개발 모듈의 세계를 넘어서 더 큰 그림을 보려면 준비해야 할 것이 무엇인지 본 글에서 다룰려고 합니다.

마인드셋의 전환 - “어떻해”에서 “왜”와 “무엇”으로

가장 중요한 점은 관점의 변화입니다. 엔지니어는 주어진 문제를 해결하기 위해 “어떤 기술”을 사용하여 어떻게 구현할 것인가?에 집중합니다. 그러나 아키텍트는 아래의 질문에서 시작해야 합니다.

1. 비즈니스 목적(Why?): 이 시스템이 왜 필요하지? 비즈니스 목표를 달성하기 위해 가장 중요한 것은 무엇이지?
2. 트레이드 오프: 모든 기술적 결정에는 대가가 따릅니다. A라는 프레임워크를 선택했을 때 포기해야 하는 B는 무엇이지?
3. 지속 가능성: 이 구조가 시장 트렌드가 바뀌는 3년 뒤에도 유지가 가능할까?

현실에서는 요구사항을 해소하기에 바쁘긴합니다. 그럼에도 아키텍트가 되려면 “이 요구사항이 전체 시스템의 정합성을 해치지는 않는가?”에 대한 답변을 끊임없이 고민하는 습관을 가져야 합니다.

기술적 깊이와 넓이의 균형

아키텍트는 모든 것을 다 알아야 한다는 압박감을 가질 수 있습니다. 그러나 핵심은 “넓게 알되, 특정 분야에 대해서는 누구보다 깊은 통찰력을 가지는 것”입니다.

그러기 위해서는 첫째, 폭넓은 기술 스택을 탐색해야 합니다. 현 시장에서 많이 쓰고 있는 기술 스택에 대해서 이해해야 합니다. (e.g. Springboot/Java, Python, Nodejs 등)

둘째, 인프라에 대한 이해가 있어야 합니다. AWS, Azure, GCP와 같은 클라우드 환경 및 On-premise 환경에 대한 이해가 필수입니다.

셋째, 데이터 아키텍처를 이해해야 합니다. RDBMS를 넘어 NoSQL과 데이터 파이프라인에 대한 이해가 있어야 합니다.

추가로, 아키텍트는 코딩에 손을 떼면 안됩니다. 어떤 기능을 구현해야 하는 관점보다는 실제 구현의 어려움을 이해하기 위해 프로토타이핑이나 핵심 모듈 개발에 참여해야 하기 때문입니다. 기술적 깊이와 논리없이 입으로만 일하면 엔지니어분들께 신뢰를 얻지 못합니다.

아키텍처 결정

아키텍트의 가장 중요한 산출물은 코드가 아니라 “결정” 입니다.

왜 이 데이터베이스를 선택했는지, 왜 MSA(Microservices Architecture)를 선택했는지등을 기록으로 남겨야 합니다. 이렇게 해야 나중에 멤버가 변경되었을 때나 히스토리를 파악할 때 결정적인 자산이 됩니다.

이런 의사 결정을 할때는 감이나 트렌드에 의존하는 것이 아니라, 명확한 기준(비용, 성능, 개발 생산성, 인력 수급 등)을 바탕으로 결정해야 합니다.

실 업무를 하게 되었을 때, 현실적인 벽에 부딪히기도 합니다. 상급자의 지시나 고객의 무리한 요구가 있을 수 있지요. 그런 상황에서 기술적 근거를 바탕으로 논리적으로 설득 할 수 있는 강력한 무기가 됩니다.

기술과 비즈니스의 가교

아키텍트 역량의 50% 이상이 “소프트 스킬”입니다. 일반적인 엔지니어 분들이 가장 힘들어 하는 부분이기도 하죠. 그 이유는 아래와 같습니다.

• 시각화 능력: 복잡한 시스템을 이해관계자(기획자, 경영진, 엔지니어, 현업)가 이해할 수 있도록 그림으로 표현해야 합니다.
• 설득의 기술: 엔지니어에게는 기술적 비전을 제시하고, 경영진에게는 기술 투자가 가져올 비즈니스 가치(비용 절감, 장애 감소, 비즈니스 확장 등)를 설명해야 합니다.
• 중재자 역할: 프론트 엔드와 백엔드 간의 인터페이스 갈등, 개발팀과 인프라팀 간의 여러 갈등을 해결하는 능력이 필요합니다.

각 환경에 따른 전략

우리가 일하는 IT는 여러 분야로 나눠져 있습니다. 크게 SI, 스타트업/서비스, 레거시 현대화로 나눠보면 각 환경의 특수성을 고려한 전략이 필요합니다.

• SI: 고객사에서 제공하거나 사용하는 표준 프레임워크의 제약 안에서 어떻게 유연한 설계를 할 것인가가 관건입니다. 여기서는 “표준 준수”와 “성능 최적화” 사이의 균형이 필요합니다.
• 스타트업/서비스: 빠른 출시(Time-to-Market)가 우선입니다. 아키텍트는 처음부터 완벽한 설계를 하기보다는, 나중에 확장하기 쉬운 “점진적 아키텍처”로 설계해야 합니다.
• 레거시 현대화: 많은 기업들이 노후화된 시스템을 현대화하려고 합니다. 이때 점진적 전환 전략을 제시할 수 있어야 합니다.

자기계발과 네트워킹

아키텍트로의 전환은 단기간에 이뤄지지 않습니다. 고전과 신간의 기술 서적을 병행해서 읽으면서 공부를 해야 합니다. 또한 오픈 소스에 기여하거나 커뮤니티 활동을 하면서 최신 트렌드를 파악하고 연습을 해보는 것도 중요합니다. 제일 좋은 것은 주변에 시니어 아키텍트가 있다면 멘토로 삼아 그들의 의사결정 과정을 옆에서 지켜보는 것이 가장 빠릅니다.

끝으로,

아키텍트는 완벽한 정답을 내놓는 사람이 아닙니다. 변화하는 비즈니스 환경에 맞춰 시스템을 가장 적절한 방향으로 이끄는 “나침반” 같은 존재이기에 아래의 사항이 중요합니다.

• 더 큰 그림을 보는 것
• 기술과 비즈니스 간의 격차를 해소하는 것
• 제품이 고객의 요구 사항을 실제로 충족하는지 확인 하는 것

이는 기술, 의사소통, 발표, 멘토링이 필수적이라는 것을 의미합니다.

엔지니어에서 아키텍트로 성장하기 위해서는 기술적 탁월함을 기본으로 하되, 비즈니스를 이해하고 이해관계자와 소통하는 능력을 키워야 합니다. 아키텍트는 코드가 아닌 시스템 전체의 건강함을 책임지기에, 이런 시각을 지니고 있다면 이미 아키텍트의 길에 들어선 것입니다. 가장 중요한 것은 열린 마음과 끊임없이 배우고자 하는 호기심이니까요.