Video: AI 시대, 개발자가 알아야 할 아키텍처 용어 8가지
Channel: 코딩하는기술사
Duration: 15m 52s
Source: subtitle (auto, ko)
Transcript:
자, 개발자 여러분, 이렇게 질문 한번 해 보겠습니다. 인기 콘서트 티켓 예매 시스템 한번 설계해 보세요. 지금 머릿속에 가장 먼저 떠오르는 것은 무엇인가요? 혹시 이런 거 아닌가요? 어, 레지스를 써야 되나? 카프카를 넣어야 되나? 어, 좌석에 동시 예매가 되면 안 되니까 분산락을 구현해야 되나? 자, 이렇게 설계 문제를 받으면 우리 개발자들이 흔히 떠올리는 것들입니다. 자, 그런데 아키텍처 설계의 출발점은 이런 특정 기술이 아닙니다. 그래서 오늘은이 시스템을 설계할 때 아키텍트가 어떤 관점과 용어를 기반으로 해서 설계를 하는지 알려 드리겠습니다. 오늘 주제는 개발자가 알아야 할 아키텍처 용어 여덟 가지입니다. 자, 설계 언어입니다. 아키텍트는 시스템을 설계할 때 이런 용어들을 사용합니다. 아키텍처 드라이브, 품질 속성, 아키텍처 텍틱, 아키텍처 스타일과 패턴, 트레이드오프, 아키텍처 de 디c전, 그리고 ADR. 자, 오늘이 강의의 목적은이 용어들을 암기하라는 것이 아닙니다. 시스템을 설계할 때 이런 용어들이 어떻게 사용되고 그리고 또 어떻게 상호 작용을 하는 건지 그 흐름을 이해하는 것이 목적입니다.

그리고 또 하나 지금은 AI가 코딩을 해 주는 시대죠. 그래서 AI에게 일을 시킬 때도 마찬가지입니다. 자, 여기 예시를 보시죠. AI에게 일을 시킬 때 캐시를 좀 넣어 줘. 성능을 좋게 만들어 줘. 자, 이렇게 모하게 일을 시키면 결과도 모하게 나올 수밖에 없습니다. 정확한 설계 언어를 기반으로 AI에게 일을 시키는 것이 필요합니다. 자, 여기 보시면 우리 시스템의 아기텍처 드라이버는 이렇다. 품질 속성은 성능은 피크시 응답이 P95 1초 이내 돼야 되고 가용성은 오픈 직후 대용장 트래픽에도 서비스가 잘 유지돼야 된다. 그리고 제약 사항이 있는데 기존에 포스트레 SQL을 사용해야 되고 환경은 AWS 환경이야. 자 좌석 조회 성능을 위해서 사용 가능한 텍틱을 몇 가지 제한을 해 주고 각 전략이 위에서 말한 품질 속성에서 어떤 트레이드 오프를 만드는지 나한테 알려 줘. 그리고 가용성을 떨어뜨리는 방안은 제외시켜 줘. 자, 앞서 캐시를 넣어 줘. 성능 좋게 만들어 줘. 잘 죽지 않게 만들어 줘. 자, 이렇게 모호하게 요청하는 것보다 정확한 아키텍처 언어로 이렇게 AI에게 일을 시키면 훨씬 구체적이고 정확한 결과를 받을 수 있겠죠.

그리고 이런 용어들은 전 세계 IT 업계에서 수십년간 사용해 온 용어들입니다. 그렇기 때문에 데이터를 기반으로 학습한 AI들도 이런 용어들을 아주 잘 알고 있겠죠. 그래서 정확한 설계 언어를 알고 일을 시키는 것이 중요합니다. 자, 그러면 여덟 가지 용어 하나씩 보겠습니다. 첫 번째 아키텍처 드라이버입니다. 자, 아키텍처 드라이버는 아키텍처의 구조와 주요한 설계 결정에 큰 영향을 미치는 핵심 요인들을 말합니다. 자, 대표적으로 기능 중에서도 아키텍처 구조를 변화시키는 핵심 기능, 그리고 성능, 가용성, 보완성 이런 것과 같은 품질 속성 그리고 미리 정해진 전제를 알려주는 제약상 이렇게 아키텍처 구조에 직접적으로 영향을 미치는 것들을 아키텍처 드라이브라고 하고요. 아키텍처를 어느 방향으로 이끌지 결정한다고 해서 드라이브라고 부릅니다. 자, 그러나 모든 요구 사항이 아키텍처 드라이브가 되는 것은 아닙니다. 아키텍처 드라이브가 될 수 있는 것은 앞서도 말씀드렸지만 아키텍처 구조와 중요한 설계 결정을 바꾸는 요인들입니다.

예를 들어서 동시 접속 10만 명을 견뎌야 한다. 좌석이 두 명에게 팔리면 안 된다. 기존 결제 시스템을 그대로 써야 한다. 자, 이런 것들은 아키텍처에 큰 영향을 미치는 것들이죠. 그래서 아키텍처 드라이브라고 할 수 있습니다. 반면에 회원 등급은 3단계에서 5단계로 늘려 주세요. 관리자 화면에 매출 조회 메뉴를 추가해 주세요. 결제 수단에 간편 결제를 하나 더 붙여야 됩니다. 자, 이런 것은 드라이브가 아닙니다. 왜냐하면 이런 요구 사항들은 아키텍처 구조 변경 없이도 수용 가능하기 때문입니다. 물론이 일이 쉽다는 건 아닙니다. 다시 말씀드리지만 아키텍처 구조를 변경하지 않고도 만들 수 있기 때문에 아키텍처 드라이버가 아닙니다. 자, 다음으로 품질 속성입니다. 어, 앞서 봤던 아키텍처 드라이브의 한 요인이었죠. 자, 그렇지만 아키텍처 할 때 가장 중요하게 사용되는 용어기 때문에 따로 뺐습니다. 자, 품질 속성, 품질 특성 또는 비기능 요구상 여러 가지 용어로 사용됩니다. 자, 품질 속성은 무엇을 하는가가 아니라 그것을 얼마나 잘해야 하는가에 대한 특성인데요.

기능 요구 사항은 여기 보시는 바와 같이 사용자가 상품을 주문할 수 있다. 이렇게 무엇을 하는가를 정의했다면 품질 요구 사항은 사용자가 상품을 주문하는데 주문 요청에 95%가 1초 안에 처리돼야 된다. 이렇게이 기능을 얼마나 잘 처리해야 되는가를 나타내죠. 그래서 기능은 그 기능이 되고 안 되고 품질은 그 기능이 얼마나 잘 되는지 말해 주는 것이고요. 아키텍처에 큰 영향을 미치는 것은 품질 요구 사항입니다. 자, 이렇게 품질 속성, 성능, 가용성, 확장성 이와 같은 품질 속성을 품질 요구 사항으로 만들려면 측정 가능한 형태로 만들어야 됩니다. 자, 여기 보시면 사용자 친화적으로 만들어 주세요. 빠르게 만들어 주세요. 안정적으로 만들어 주세요. 기준이 없죠. 이것을 피크 시간 응답 95%가 1초 이내에 될 수 있도록 해 주세요. 월간 가용성 목표를 99.9%로 해 주세요. 그리고 피크시 초당 5점권 처리가 가능하도록 해 주세요. 성능과 처리량 가용성에 대한 구체적인 요구 사항이죠. 이렇게 품질 요구 사항은 가능한한 측정할 수 있는 형태로 구체화를 해야지만 우리가 설계의 기준으로 쓸 수가 있고 AI가 만들어진 결과물도이 기준으로 검증을 할 수 있는 것이죠.

자, 세 번째 아키텍처 텍틱입니다. 특정 품질 속성을 달성하거나 개선하기 위한 설계 전략이라고 할 수 있습니다. 자, 성능을 높이려면 뭘 해야 되지? 가용성을 좋게 하려면 뭘 해야 되지? 보안을 좋게 하려면 뭘 해야 되지?이 이런 것들을 택틱이라고 하고요. 예를 들어서 성능을 좋게 만들려면 캐시, 병렬 처리, 가용성은 이중화, 페이로버 이런 것들이 텍틱 적 전략이 되는 것이죠. 자, 다만 하나의 텍틱이 품질 속성 하나만 영향을 주는 것은 아닙니다. 가령 캐시를 넣으면 성능은 좋아지지만 일관성에는 영향을 줄 수가 있죠. 우리는 이것을 트레이드오프라고 하고요. 뒤에서 알아보겠습니다.네 번째 아키텍처 스타일입니다. 아키텍처 스타일은 시스템 전체를 어떻게 구조화할 것인가에 대한 큰 틀 방식을 말합니다. 구성 요소를 어떻게 나누고 그것들을 어떤 규칙으로 상호 작용하는지를 결정하는 스타일을 말하는 것이고요. 예를 들어서 레이어드 스타일 클라이언트 서버 이벤트 드립은 마이크로소비스 파이프앤 필터와 같은 것들이 있습니다.

앞서 봤던 텍틱이 특정 품질 속성을 달성하기 위한 전략 수단이라면 아키텍처 스타일은 시스템 전체의 골격 적 구조를 정하는 선택이고요. 그래서 스타일은 시스템 전체에 영향을 미치고 한번 정해지면 바꾸기가 굉장히 어려운 것을 말합니다. 다섯 번째 아키텍처 패턴입니다. 자, 아키텍처 패턴은 반복해서 나타나는이 설계 문제에 대한 널리 검정된 해결 방식을 말합니다. 어, 앞서 봤던 스타일과 비교하면 범위가 조금 더 좁습니다. 스타일이 시스템 전체 구조라면 패턴은 특정 문제 하나를 다루는 것입니다. 예를 들어서 캐시 어사이드 패턴, 서킷 브레이크, CQRS 사과 패턴 이런 식이죠. 자, 그렇지만이 스타일과 패턴은 뭐 많이 혼용되는 부분이 있습니다. 문원과 사람에 따라서 패턴이라고도 하고 아키텍처 스타일이라고도 하고 크게 상관은 없습니다. 자, 정리를 하면 아키텍처 스타일은 시스템의 전체 구조 그리고 아키텍처 패턴은 특정 문제에 대한 해결 해법 그리고 텍틱은 특정 품질 속성을 달성하기 위한 전략 수단을 말합니다.

자, 캐시를 가지고 예를 들어 보겠습니다. 자, 텍틱은 성능이라는이 품질 속성을 만족하기 위한 수단이죠. 자, 전략적으로 무엇을 할 것인가를 정하는 것이고요. 아직까지 어떻게 할지는 없는 거죠. 그래서 택틱은 성능을 위해서 캐시를 두겠다 하는 것이고요. 패턴은 캐시를 두는데 캐시 어사이드 형태로 구성하겠다. 캐시에 데이터가 없으면 데이터베이스에서 읽어서 채운다. 이런 식으로 어떤 구조로이 캐시를 끌게 할 것인가? 널리 검정된 해결 방식인 거죠. 그리고이 캐시 선택에는 대가가 따릅니다. 읽기 성능은 좋아질 수 있지만 데이터가 일관되지 않을 수 있고요. 그리고 캐시 무효화도 따로 설계를 해야 되고 개시로 인한 운영 복잡도 올라갑니다. 이것을 트레이드 오프라고 하죠. 자, 여섯 번째 트레이드오프입니다. 트레이드오프는 앞서 봤던 거와 같이 어떤 장점을 얻는 대신에 치르게 되는 비용이나 단점을 말합니다. 앞서시에서 얻는 것은 응답 속도 향상 원본 데이터베이스 부화 감소죠. 그렇지만 이걸로 인해서 데이터의 일관성캐시 무화의 비용 운영 복잡도가 올라가죠.

그리고 우리가 흔히 알고 있는 MSA 아키텍처는 독립적인 배포 그리고 확장에는 좋지만 이로 인해서 네트워크가 복잡해지고 분산한 트랜잭션이 필요해지고 운영 비용이 올라갈 수 있죠. 자, 이렇게 해서 어떤 아키텍처 전략을 세웠을 때 무조건 장점만 있는게 아닙니다. 아키텍트는 이런 트레이드오프를 감안해서 어떤 걸 취하고 어떤 걸 감수할 수 있는지를 정해야 되는 거죠. 그래서 아키텍처는 좋고 화려한 기술을 고르는 것이 아니라 우리 상황에 맞는 트레이드오프를 판단하고 어떤 것을 감수할지를 결정하는 일이라고 할 수 있습니다. 일곱 번째 아키텍처 디시즌입니다. 앞서 봤던 여러 대안들 그리고 트레이드오프를 비교한 뒤에 내리는 중요한 설계의 결정입니다. 자 이런 대안들이 있습니다. 캐시 없이 DV를 직접 조회하면 장점은 캐시 불일치 문제는 없지만 피크이 데이터베이스에 보화가 가고 그렇다고 로컬 캐시를 적용하면 어 네트워크 호출 없이 아주 빠르지만 인스턴스가 여러대 있을 경우 캐시간 불일치가 발생할 수 있고 레디스 공유 캐시를 사용하면 인스턴스간 캐시를 공유할 수 있고 DV 부활를 감소시킬 수 있지만 레디스 운영 네트워크 호출 비용 캐시 일관성 같은 문제를 감안해야 하는 것이죠.

자, 이렇게 아키텍트는 대안들을 검토해 보고 얻는 것과 잃는 것, 감수해야 하는 것, 트레이드오프를 판단해서 우리 상황에는 레지스 공유시를 선택해서 이것을 얻겠다. 이것은 감수하거나 완화하겠다라는 전략을 세울 수 있는 거죠. 마지막으로 ADR 아키텍처 디시즌 레코드입니다. 앞에서 내린 아키텍처 결정을 기록하는 것입니다. 왜이 결정을 했고 어떤 선택지가 있었고 그래서 무엇을 선택했고 결과적으로 얻는 것과 감소해야 되는 것은 무엇인가? 중요한 아키텍처 결정의 근거를 기록하는 것이죠. 자, 이제이 용어들을 한번 흐름으로 연결시켜 보겠습니다. 우리가 아키텍치를 설계할 때 기본적인 사고 흐름을 말씀드리겠습니다. 처음에 비즈니스, 목표, 요구 사항이 전달됩니다. 그러면 우리는 여기서 아키텍처 드라이브를 식별해야 됩니다. 아키텍처 드라이버로는 핵심 기능, 품질, 속성, 제약 사항이 있었죠. 그리고이 아키텍처 드라이브를 기반으로 해서 여러 가지 설계 대안을 탐색합니다. 이때 아키텍처 텍틱, 아키텍처 스타일, 패턴 등을 조사하고 검토합니다.

그리고 나서 여러 가지 전략 중에서 트레이드 오프를 판단하고 대안들을 고려하는 것이죠. 그리고 우리 상황에 맞는 특정 전략을 선택합니다. 그것을 아키텍처 디시즌으로 결정을 하고 그 결정을 ADR로 기록을 하는 흐름으로 우리 아키텍트들은 설계 사고 체계를 가지고 있어야 됩니다. 물론이 설계 방향이 이렇게 한 방향으로만 흐르는 것은 아니겠죠. 이렇게 가다가 또 다시 드라이브를 검토하거나 추가하거나 할 수 있겠죠. 자, 우리 개발 현실을 좀 보겠습니다. 자, 우리 고객이 이렇게 얘기합니다. 어, 티켓 오픈할 때 사람들이 엄청 몰릴 텐데 이때 서비스가 죽으면 안 됩니다. 그리고 사용자가 너무 오래 또 기다리게 해서는 또 안 돼요. 자, 어떻습니까? 모호하죠. 자, 그러나 고객은 이렇게 모호하게 줄 수밖에 없죠.이 고객의 비즈니스 언어를 우리 아키텍트가 설계 언어로 해석을 해야 되는 것이죠. 여기서 우리는 가용성 목표는 너무 올해는 몇 초인가? 그리고 어떤 구간의 응답을 어떤 빠르기로 응답해야 되는지 이렇게 설계 언어와 기준으로 구체화시킬 수 있어야 합니다.

자, 상황을 한번 드려 보겠습니다. 고객가 회의에서 이렇게 얘기가 나온다고 했을 때 여러분들은 여기서 어떻게 설계 흐름을 잡겠습니까? 자, 보시죠. 콘서트 티켓 예매 시스템 요구 사항 회의입니다. 자, 고객이 이렇게 요구하고 있습니다. 공연과 자석을 조회하고 원하는 자석을 선택해서 결제할 수 있어야 합니다. 평소에는 한산데 티켓 오픈 직후에 수십만 명이 동시에 몰려올 수 있습니다. 같은 좌석이 절대로 두 명 이상에게 팔려서는 안 됩니다. 그리고 사람이 몰려도 서비스가 다운되지 않았으면 좋겠습니다. 그리고 사용자가 너무 오래 기다리지 않았으면 좋겠습니다. 시스템과 결제 시스템은 지금 있는 거 그대로 연등해 주셔야 됩니다. 그리고 데이터베이스는 기존에 포스트의 SQL을 사용해야 되고 인프라는 AWS 기반으로 가야 됩니다. 그리고 앞으로도 다른 공연에도이 시스템을 계속 사용할 예정입니다. 자, 어떻습니까? 고객의이 요구 사항을 바탕으로 여러분들이 아키텍터라면 어떻게 설계를 시작하고 어떻게 기준을 잡으시겠습니까? 또는 어떻게 고객과 협의를 하겠습니까?

한번 생각해 보시죠. 자, 힌트를 조금 드리겠습니다. 이것부터 생각해 보세요. 자, 우리가 본 건 고객의 요구 사항이죠. 그리고 지금까지 우리가 배운 건 아키텍처 용어와 설계 흐름이었죠. 자, 앞서 그 요구 사항에서이 중에서 진짜 아키텍처 드라이버는 무엇일까? 그리고 어떤게 기능이고 어떤게 품질 속성이고 어떤게 제약 사항일까? 그리고 기준이나 측정할 수 없는 즉 모에서 다시 물어보고 협의해야 될 항목은 무엇인가? 그리고 어떤 설계 대안이 있고 그것들은 어떤 트레이드 오프를 가질까?이 관점으로 방금 봤던 요구 사항에서 아키텍처 설계를 시작해 보시죠. 제 채널에서는 아키텍트를 위한 멤버십을 운영하고 있습니다. 소프트웨어 아키텍처의 정통 이론부터 실무 설계, 프로젝트 관리와 리더십 등 아키텍트로 성장하는데 도움이 될 만한 다양한 콘텐츠를 제공하고 있습니다. [음악] AI 시대에는 단순 구현을 넘어서 시스템 전체를 조망하고 판단하는 역향이 더욱 중요해지고 있습니다. 개발에 머무르지 않고 아키텍트로 한 단계 더 성장하고 싶다면 멤버십에서 저와 함께 공부하고 성장해 보시기 바랍니다.

그리고 지금까지 함께 해 주시는 우리 멤버 여러분 늘 감사드립니다. 함께 성장하는 멤버십이 될 수 있도록 계속 고민하겠습니다. 감사합니다.