설탕빵의 설탕공방도서 아키텍트 첫걸음에서 발췌
[서준호, Toss Lab, Inc, CTO, JANDI 서비스 개발 총괄]
AI 시대에 아키텍츠의 역할은 크게 변화했다.
단순히 시스템을 잘 설계하는 것을 넘어, 기술의 흐름을 읽고 이에 유연하게 대응할 수 있는 구조를 얼마나 빠르게 만들 수 있느냐가 중요하다.
과거는 아키텍트의 역할이 서버, 네트워크, 애플리케이션처럼 분리되었지만,
지금은 클라우드 환경으로 전환되며 그 경계가 점점 모호해지고 통합적으로 바뀌고 있다.
이제는 개별 시스템의 전문성보다 전체 아키텍처를 통합적으로 바라보며 설계할 수 있는 역량이 더 중요해졌다.
클라우드에서의 아키텍처는 구성을 넘어 비용 최적화, 보안 전략, 자동화, 데이터 흐름까지 아우르는 설계가 필요하다.
AI를 활용한 자동화와 모니터링은 이제 기본 전제가 되었고,
클라우드 기반의 빠른 실험과 검증 과정에서도 AI가 핵심 인프라가 되었으며,
전략적인 비용 관리 역시 AI 기술을 통해 가능해졌다.
기술 부채 또한 "나중에 해결하자"는 접근이 통하지 않는 시대다
기술 부채는 서비스 속도를 늦추는 가장 큰 원인이며,
AI처럼 빠른 실험과 전개가 요구되는 시대에는 선제적 대응이 곧 운영 효율이다.
과거 아키텍처가 "어떤 기술을 선택할지 결정하는 역할" 이었다면,
이제는 문제를 빠르게 해결할 수 있는 구조를 설계하고,
실험과 실행의 속도를 끌어 올릴 수 있는 사람이 되어야한다.
중요한 것은 처음부터 완벽한 설계를 목표로 하지 않아도 된다.
가능한 단순한 형태에서 실제 트래픽을 받아보며 병목을 발견하고,
쪼개고 개선하는 과정을 반복하며 진화하라
"Fall Fast, Learn Faster"
작은 실패를 빠르게 경험하고, 그것을 바탕으로 구조를 탄탄하게 만들어가는 것,
실무에서 더 효과적인 접근법이다.
또한 시스템은 결국 전부 연결되어 있다는 관점에서 생각하는 연습이 중요하다.
처음에는 특정 기술이나 컴포넌트만 깊이 파는데 집중하지만,
운영하다 보면 DB 성능 문제 하나가 네트워크 지연을 야기하고,
곧 사용자 경험으로 이어지는 것을 자주 보게 된다.
초기부터 관찰 가능성을 고민하면 좋다.
문제가 생긴 다음에 로그를 붙이고 모니터링을 달기 시작하면 늦는다.
초기부터 서비스가 '무엇을 보고 있고, 어떤 기준으로 이상을 감지하며, 어떤 데이터를 기반으로 판단할 수 있게 할 것인지'에 대한 설계를 함께 가져가야한다.
과거 운영 초기에 겪었던 큰 장애 중 하나는 시스템 자체의 결함이 아닌,
문제의 원인을 제대로 파악할 수 없었던 것이 더 큰 리스크였다.
마지막으로 기술 스택은 중요하지만, 그보다 더 중요한 것은 '무엇을 해결하기 위해 이 시스템을 설계하는가'이다.
기술은 결국 도구에 불과하다.
도구 자체 보다는 그 도구를 어떤 의도로, 어떤 방향으로 써나가는지가 훨신 중요하다.
아키텍트라는 역할은 기술보다는 목적에 집중하는 사람이다.
그 목적을 이루기 위해 가장 합리적이고 유연한 길을 설계하는 것이 아키텍트의 역할이다.