맡고 있는 역할은 무엇인가요?
저는 Public Cloud 환경에서의 아키텍처 설계와 구축을 맡고 있습니다. 현재는 Secure Public Cloud를 위한 표준 아키텍처 설계, 랜딩존 구축, 거버넌스 수립 등 다양한 클라우드 전환 프로젝트를 리드하고 있습니다. 쉽게 말하면, 단순히 서버를 만드는 것을 넘어, ‘왜 이 구조여야 하는가’에 대한 명확한 기준을 설계하고, 실제 환경에 적용되도록 돕는 역할입니다.
어떤 팀에서 일하고 있나요?
저희 팀은 Azure 기반의 Public Cloud 랜딩존 구축, 기술 검증, Legacy 시스템 전환, 보안·운영 리스크 관리 등, KT의 클라우드 환경 전환 전반을 설계하고 책임지는 팀입니다. 국내외 다양한 이해관계자들과 함께, 기술적으로 신뢰할 수 있는 클라우드 전환을 이끌어내는 것이 저희의 미션입니다.
지금까지의 커리어 여정을 소개해주세요.
IT 업계에 몸담은 지 어느덧 15년 차입니다. 초기에는 시스템 엔지니어로서 OS, 스토리지, 네트워크를 다뤘고, 이후 Private Cloud 전환 프로젝트의 PM 및 아키텍트, 최근에는 AWS 기반 Public Cloud 아키텍처 설계·구축까지 수행해왔습니다. 이처럼 다양한 기술과 환경을 경험하며, 기술 전환이 단순한 이전(migration)을 넘어 서비스의 미래를 설계하는 일이라는 걸 체감하고 있습니다.
아키텍처라는 직무의 매력은 무엇인가요?
설계한 구조가 실제 서비스로 구현되고, 그 결과 고객이 안정적으로 이용할 수 있을 때 오는 묵직한 성취감이 있습니다.
늘 새롭고 복잡한 기술 속에서 “정답은 없지만, 최선은 있다”는 태도로 끊임없이 고민하고 설계하는 과정이 이 직무의 가장 큰 매력입니다.
아키텍처가 되기 위해 필요한 역량은 무엇일까요?
아키텍처는 ‘올라운더’가 되어야 합니다. 특정 기술만 깊이 아는 것도 중요하지만, IT 전반을 넓게 이해하는 역량이 필수입니다. 또한 다양한 이해관계자들 사이에서 요구사항을 조율하고, 기술적으로 실현 가능한 방향을 제시할 수 있어야 하죠. 늘 새로운 기술에 민감하고 유연한 태도가 중요합니다.
가장 인상 깊었던 프로젝트는 무엇인가요?
현재도 진행 중인 Secure Public Cloud 프로젝트입니다. 국가별 데이터 주권과 보안 이슈를 고려해 한국형 소버린 클라우드를 구축하는 이 프로젝트는, KT를 비롯한 10여 개 부서, 외부 파트너 등 약 60명이 함께 만들어가고 있는 대형 프로젝트입니다. 저는 기술 총괄로서 전체 아키텍처를 설계하고, 각 이해관계자와의 조율 및 커뮤니케이션을 담당하고 있습니다. 기술과 기술이 아닌 것의 경계에서 끊임없이 균형을 잡는 일이죠.업무 속 ‘갈등’ 상황은 어떻게 풀어나가시나요?
기술, 보안, 서비스 부서의 관점은 모두 다릅니다. 누구나 자신이 맡은 영역이 가장 중요하다고 생각하죠. 그럴 때일수록 넓은 시각으로 전체를 바라보고, 요구사항의 우선순위를 정리한 뒤 기술적으로 가장 효율적이면서도 현실적인 방법을 제시하려 합니다. 아키텍처 설계는 타협이 아닌, 조율의 미학이라고 생각합니다.
Secure Public Cloud 프로젝트에서 가장 많은 논의가 필요했던 기술 요소는 무엇이었고, 그 과정을 어떻게 조율하셨나요?
기밀컴퓨팅 환경에 우리가 일반적으로 서비스하는 SW / Managed Service를 적용하는 것이었습니다. 고객 관리키를 통한 보안 개념도 포함되어 검토가 필요했죠. 정답은 없기에 수많은 테스트를 우직하게 진행했고, 결과를 바탕으로 효율적인 형상을 구현해내는 끈기와 인내심, 그리고 빠른 판단이 중요했습니다.
랜딩존 구축 과정에서 KT 내부 시스템과 Azure 환경 간의 기술적 충돌이나 제약을 경험한 사례가 있다면 소개해 주세요.
랜딩존은 고객 환경에 맞는 거버넌스와 표준을 수립하고 적용해야 하기에 Custom이 많이 필요한 영역입니다. Azure의 기본 환경만으로는 KT 같은 엔터프라이즈 기업의 요구사항을 모두 충족할 수 없었고, 결국 KT 표준을 하나하나 커스터마이징하며 만들어야 했습니다.
대형 프로젝트에서 기술 총괄로서 가장 어려웠던 의사결정은 무엇이었고, 어떤 기준으로 판단하셨나요?
KT는 다양한 클라우드 환경을 사용하고 있어, 각 부서의 기준과 표준이 충돌하는 경우가 있었습니다. 모든 환경을 수용할 수 없기에, “사용자가 인지하지 않고 신경 쓰지 않는 거버넌스/표준으로 랜딩존을 구축하자”는 기준으로 판단했습니다.
국가별 데이터 주권을 고려한 아키텍처 설계에서 가장 까다로웠던 보안 정책이나 기술적 조치는 무엇이었나요?
데이터 암복호화 시 CMK + mHSM을 사용하는 부분이 가장 까다로웠습니다. 민감한 영역이라 높은 수준의 운영을 위해 많은 테스트와 경험이 필요했고, 다양한 시도를 통해 안정적인 운영 방안을 마련했습니다.
기술 외적인 요소가 설계에 영향을 준 사례가 있다면 말씀해 주세요.
회사 전략이 급변하면서 CSP 업체 변경이 발생한 적이 있습니다. 기존 설계를 일부 재활용할 수 있었지만, 핵심 기술이 달라지면서 전체 설계를 다시 세밀하게 구성해야 했던 경험이 있습니다.
Private Cloud에서 Public Cloud로 전환하는 과정에서 인상 깊었던 기술적 전환 사례나 고객 반응이 있다면 공유해 주세요.
작년에 On-prem. 환경에서 사용하던 서비스를 MSA 기반 컨테이너 환경과 Managed Service를 활용한 Public Cloud로 전환했습니다. 서비스 담당자의 “장애도 없고, 잘한 것 같아요”라는 반응이 가장 기억에 남습니다.
요구사항 우선순위를 정리하는 과정에서 의견 충돌을 조율했던 사례가 있다면 소개해 주세요.
프로젝트 일정상 양보할 수 없는 상황이 발생했을 때, 아키텍처는 “어떻게 해야 해?”에 대한 답을 주는 역할을 합니다. 명확한 우선순위 선택과 리스크 대응 방안을 제시하며, 이해관계자 간의 조율을 이끌어냈습니다.
15년간의 커리어 중, 기술 설계자로서 가장 큰 실패 혹은 시행착오를 겪었던 순간은 언제였고, 그 경험이 현재 업무에 어떤 영향을 주었나요?
실패한 적은 없습니다.
마지막으로, 이 직무에 도전할 후배들에게 한마디 한다면?
재미있는 일입니다. 겁내지 말고 도전하세요. 기술이 곧 사람이 되고, 사람이 기술을 바꾸는 현장에 함께할 수 있습니다.
