적어도 과거의 철학 연구에서는 겉보기에는 별로 중요하지 않아 보이는 질문을 던지곤 했다. 이를테면 “모든 목재 부품을 하나하나 교체해 복원한 배”가 여전히 같은 배인지 아는 것이 정말 그렇게 중요할까? 이것은 플루타르코스가 테세우스의 생애에서 제기한 질문으로, 이후 테세우스의 역설로 알려지게 되었다. 더 일반적으로 표현하면, 이 역설은 “모든 구성 요소가 교체된 물체가 근본적으로 여전히 동일한 물체인지”를 묻는다. (테세우스의 배, 위키백과)
기존 모놀리식 애플리케이션에 적용할 때 함수를 그에 상응하는 서비스로 대체하여 본질적으로 애플리케이션을 복원하려는 마이크로서비스에도 같은 질문을 던질 수 있습니다. 함수는 설계상 작으며(또는 작아야 하며), 그 결과로 만들어지는 분리된 서비스에 ‘마이크로’라는 용어가 붙습니다. 이 둘의 차이는 통신 방식의 관점에서 살펴볼 수 있습니다. 모놀리식 애플리케이션에서는 메모리의 특정 주소를 참조하여 함수를 호출합니다. 마이크로서비스 기반 애플리케이션에서는 네트워크의 특정 IP 주소를 참조하여 함수(서비스)를 호출합니다.
개념적으로 둘은 동일하며, 개별 기능 구성 요소를 호출하는 메커니즘만 다릅니다. 이를 다이어그램으로 나타내면 본질적으로 거의 차이가 없고, 모놀리스의 ‘상자’는 단일 서버인 반면 마이크로서비스의 ‘상자’는 전체 데이터 센터라는 점만 다를 것입니다. 하나는 로컬 주소 지정을 사용하고, 다른 하나는 네트워크 주소 지정을 사용합니다. 테세우스의 배를 이루는 목재처럼, 각 기능의 코드는 완전히 동일할 수도 있습니다.
하지만 그 비즈니스 기능은 일관되게 유지되며, 실제로 애플리케이션을 적절히 분해했다면 사용자는 두 방식 사이에서 눈에 띄는 차이를 느끼지 못해야 합니다. 테세우스의 배에 탄 승객의 관점에서는 둘 사이에 아무런 차이가 없다고 볼 수 있습니다. 또한 그래야 합니다.
하지만 철학자들은 더 깊이 파고드는 경향이 있으며, 우리도 그들처럼 그래야 합니다. 모놀리식 애플리케이션과 마이크로서비스 기반 애플리케이션의 차이는 실제로 운영에 매우 중요하기 때문입니다.
네트워크 운영의 복잡화
마이크로서비스는 애플리케이션 개발 프로세스의 여러 측면을 간소화하지만, 그 과정에서 상당한 운영 복잡성을 초래합니다. 마이크로서비스 기반 애플리케이션의 서로 다른 구성 요소를 연결하는 수많은 네트워크 연결로 인해 IP 주소, VLAN, NAT 테이블 등 필요한 다양한 네트워크 특성을 관리하는 데 필연적으로 추가 부담이 발생합니다. 확장성 또한 데이크스트라조차도 골치 아파할 만한 과제가 됩니다. 마이크로서비스 및 부하 분산 서비스의 배치는 네트워크에서 거쳐야 하는 세그먼트 수에 따라 성능에 실질적으로 큰 영향을 미치기 때문입니다.
민감한 데이터 소스에 직접 액세스하는 서비스에 적용되는 보안 정책은 환경 설정이나 세션 상태를 관리하는 다른 서비스를 보호하는 데 필요한 정책과 다르므로, 갑자기 추가 정책이 필요해집니다. 그 결과 형성되는 마이크로 보안 정책망은 더 세분화된 제어와 일종의 우아한 단순성이라는 점에서 마이크로서비스 자체와 동일한 이점을 상당 부분 제공하지만, 동시에 정책이 갑자기 서비스가 아키텍처의 어디에 나타나든 서비스와 함께 이동해야 하므로 운영상 악몽이 됩니다.
배포 역시 단순한 박스 스텝 춤에서 스텝이 훨씬 많고 무대(데이터 센터) 전체를 더 많이 오가야 하는 복잡한 플라멩코로 전환하는 것처럼, 갑자기 기하급수적으로 어려워집니다. 모든 구성 요소를 적시에 제자리에 배치하는 데 필요한 일관성과 예측 가능성을 보장하려면 오케스트레이션과 자동화가 필수적입니다.
애플리케이션에 이러한 네트워크 및 보안 서비스를 제공하는 담당자는 아무리 높은 곳에서 전체를 조망했을 때 같아 보이더라도 그 배가 예전과 같지 않다는 점을 인식해야 합니다. 언뜻 보면 간단해 보입니다. 하나의 애플리케이션을 열 개의 서비스로 대체하기만 하면 됩니다. 짜잔! 테세우스의 배처럼 애플리케이션이 다시 만들어졌습니다. 하지만 운영 관점에서 보면 이 배는 전혀 같지 않습니다. 새 배의 연결부(통합)는 완전히 달라졌으며, 이로 인해 바다(네트워크)와의 마찰이 달라져 배가 더 느리게 항해하게 될 수 있습니다.
마이크로서비스는 아직 부상하는 단계에 있습니다. 아직은 세상을 장악하고 있지 않지만, 테세우스의 배를 해체한 뒤 다시 만드는 것처럼 단순한 문제가 아니라는 점을 인식해야 합니다. 네트워크 및 보안 서비스 운영 팀은 승객(사용자)의 관점이 아니라 철학자의 관점에서 바라봐야 합니다. 네트워크와 보안에 미치는 영향이 완전히 다르기 때문입니다.
작성자 소개
Lori MacVittie는 F5 CTO 오피스의 수석 엔지니어이자 최고 에반젤리스트로, 애플리케이션 딜리버리, 자동화 전략 및 인프라 분야에서 깊이 있는 전문성을 보유하고 있습니다. AI 에이전트를 위한 가드레일을 정의하고, 취약한 멀티클라우드 아키텍처를 분석하며, 확장 가능한 시스템의 한계를 탐구하는 등 복잡한 문제를 명확하게 풀어내는 것으로 잘 알려져 있습니다. 애플리케이션 개발, IT 아키텍처, 네트워크 및 시스템 운영 전반에 걸쳐 30년 이상의 업계 경험을 쌓았습니다. F5에 합류하기 전에는 수상 경력이 있는 기술 편집자로 활동했습니다. MacVittie는 컴퓨터 과학 석사 학위를 보유하고 있으며, 보안, 클라우드 및 엔터프라이즈 아키텍처 분야를 아우르는 다수의 저서를 집필한 작가입니다. 또한 보드게임과 비디오 게임을 열정적으로 즐기며, 치즈에 대해서는 거리낌 없이 확고한 견해를 갖고 있습니다.
Lori Mac Vittie의 다른 블로그 게시물관련 블로그 게시물
성평등을 향한 여정: 사이버 보안 분야에서 성공적인 커리어를 개척하는 방법에 관한 Jenn Gile과의 Q&A
F5의 ‘성평등을 향한 여정’ 시리즈 네 번째 Q&A에서는 Rachael Shah와 NGINX 제품 마케팅 책임자 Jenn Gile이 사이버 보안 직종에 대한 오해를 바로잡고, 사이버 보안 분야의 성별 격차를 해소하기 위한 조언과 그 이점에 대해 이야기합니다.
TLS 검사에서 피터 파커 원칙 다루기
“큰 힘에는 큰 책임이 따른다.” 볼테르와 처칠도 이와 비슷한 말을 남겼지만, 이 문구는 스파이더맨 코믹스에서 벤 삼촌의 말로 가장 널리 알려져 있습니다. 물론 이 문구가 문화적으로 널리 통용되는 이유 중 하나는 TLS 검사를 비롯해 수많은 상황과 주제에 적용할 수 있기 때문입니다.
Venafi와 F5를 통한 머신 아이덴티티 보호
‘머신 아이덴티티’란 간단히 말해 자동화된 프로세스가 자신의 신원을 식별할 수 있도록 하고, 다른 자동화 시스템과 프로세스가 관련 리소스에 적절한 수준의 접근 권한을 부여하도록 하는 방법을 의미합니다. 이 개념 자체는 새로운 것이 아닙니다. 비교적 새로운 점은 이를 구현해야 하는 규모입니다.
마이너와 미니언: 데이터 유출만이 비용을 초래하는 것은 아닙니다
물론 데이터 유출은 더 큰 비용을 초래할 수 있고(적어도 지금은), 실패 사실을 세상에 드러낼 수밖에 없게 합니다(통지 의무가 있으니까요). 하지만 보안을 단순히 데이터 노출 문제로만 봐서는 안 됩니다. 요즘은 데이터가...
내 클라우드에서 나가!
F5의 Jay Kelley가 전하는 최신 소식에는 Microsoft Office 365용 신규 ID 및 액세스 솔루션을 배포할 때 고려해야 할 사항이 정리되어 있습니다.
Shift(웹 앱) 보안 레터
웹 앱 보안을 개발 초기 단계로 앞당기세요. F5 블로그에서 DevOps 파이프라인 초기에 보안을 통합하여 취약점을 예방하고 시간을 절약하는 방법을 알아보세요.