쵸코쿠키의 연습장

우리 일상의 중요한 부분으로 자리 잡은 대화형 애플리케이션들, 가상 비서부터 챗봇, 음성 기반 인터페이스에 이르기까지, 이러한 시스템들과의 상호작용이 어떻게 이루어지는지 궁금해 하신 적이 있나요? 이 글에서는 사용자가 이러한 시스템과 상호작용할 때 무슨 일이 발생하는지, 사용자 입력이 어떻게 처리되어 대형 언어 모델(LLM)에 전달되는 명령어로 변환되고, 응답이 생성되어 사용자에게 다시 제시되는지에 대한 기술적인 측면을 탐구할 것입니다. 이 과정을 간소화하여 기술적인 배경이 없는 독자들도 이해할 수 있도록 설명할 것입니다. 일상에서 우리는 다양한 형태로 대화형 애플리케이션과 상호작용합니다. 목소리로 "오늘 날씨가 어때?"라고 물을 수도 있고, 텍스트 메시지를 보내거나 버튼을 클릭할 수도 있습니다. 이러한..

데이터 웨어하우스는 이제 기존의 IT 인프라를 벗어나 운영되고 있습니다. 업계는 끊임없이 발전하고 있으며, 완벽한 솔루션은 없습니다. 날로 진화하는 데이터 관리 환경에서 데이터 웨어하우스와 데이터 레이크 간의 해묵은 경쟁 관계는 마침내 해소되고 있습니다. 이제 더 이상 둘 중 하나를 선택하는 문제가 아니라, 기업과 IT에 막대한 이익을 가져다주는 현대적이고 통합된 구성 요소로서 데이터 웨어하우징을 활용하는 것입니다. 이 블로그는 데이터 웨어하우징에 대해 깊이 연구하고, 데이터 웨어하우징이 정보 스토리지의 영원한 타이탄으로서 어떻게 성장하고 있는지를 조명합니다. 먼저 데이터가 현대 비즈니스의 원동력이 된 과정을 살펴보고, 데이터 웨어하우스와 데이터 레이크라는 용어의 의의와 사용법을 이해하는 것이 탐구의 토..

현대 제품 개발에서 가치 흐름을 이해하는 것은 우리의 작업 방식을 최적화하고 고객에게 가치를 제공하는 데 매우 중요합니다. 가치 흐름은 토요타와 린 제조 운동을 시작으로 수십 년 동안 린 사고의 중심 원칙이었으며, 현재 산업 전반에 걸쳐 널리 채택되고 있습니다. 그럼에도 불구하고 많은 기업은 여전히 가치 흐름의 잠재력을 최대한 활용하여 조직 변화를 주도하고 효율성과 효율성을 높여야 합니다. 대신 팀 속도나 프로덕션 파이프라인 속도와 같은 측정 기준에 좁게 초점을 맞출 수 있으며, 엔드 투 엔드 시스템에 대한 전반적인 그림을 놓칠 수 있습니다. 현대 제품 개발에서 가치 흐름을 이해하는 것은 우리의 작업 방식을 최적화하고 고객에게 가치를 제공하는 데 매우 중요합니다. 가치 창출 경로를 매핑함으로써 프로세스에..

쇼피몽 서비스 업무 흐름 마이크로서비스들 간의 동기 및 비동기 연동 기능을 구현해서 고객이 상품을 구매하는 쇼핑몰 시스템의 주요 프로세스를 구현하고 테스트해 보았습니다. 이 쇼핑몰 시스템의 여러 업무 중 상품 구매를 위한 프로세스를 구현합니다. 이 프로세스를 좀 더 자세히 설명하면, 구매자가 상품구매를 위해 구매할 상품과 수량을 입력하면 Account 서비스로 구매자에 해당하는 주소정보를 조회해서 가져옵니다. Product 서비스로 구매하려는 상품의 가격정보를 조회해서 가져옵니다. 구매자가 가져온 주소와 상품의 가격을 확인하고 최종 구매를 결정하면, 이 정보가 배송 서비스로 전달됩니다. 이 상품 구매 프로세스를 동작하게 하기 위한 각 서비스간의 동기 및 비동기 방식의 연동 기능을 구현하고 테스트합니다. ..

업무기능 추가 Account에 간단하게 아이디와 이름, 주소와 이메일 주소만을 갖는 간단한 객체로 설계하고 구현을 해보았습니다. 모델이 코드로 어떻게 구현되는지 또 어떻게 테스트해 볼 수 있는지 이해할 수 있었습니다. 그래서 이번에는 Account Domain Model 전체로 확장해서 구현하고 테스트를 해보았습니다. 초기 하나의 문자열 정보로 관리했던 주소는 주소와 우편번호로 구체화하여 별도 객체로 분리하였습니다. 또한 쇼핑몰 서비스를 사용하는 회원은 판매자, 구매자로 회원 유형을 분리하였고, 또한 판매나 구매 실적에 따라 등급이 부여될 수 있어야 하므로 별도 MembershipLevel을 추가합니다. 따라서 초기의 간단했던 Account는 화면과 같이 Account, Address, Membertyp..

Swagger를 활용한 API 명세 & 테스트 Swagger는 간단한 설정으로 프로젝트에서 지정한 URL들을 HTML화면으로 확인할 수 있게 해주는 오픈소스 프로젝트입니다. 특히 REST API를 만드는 경우 주소나 파라미터가 변경되더라도 그 변경된 소스를 그대로 참조 문서로 만들어줍니다. 따라서 API가 수정되더라도 이 API를 이용하는 개발자는 문서를 참조하고 또 쉽게 테스트를 할 수 있습니다. 따라서 Swagger를 통해 API를 테스트하기 위해 pom.xml 파일에 화면과 같이 추가합니다. Config 패키지에 SwaggerConfig 클래스 스프링 부트 프로젝트에 추가하였습니다. 마지막으로 Application의 Swagger 어노테이션을 추가합니다. 소스코드가 변경되었으니 프로젝트를 다시 Bu..

Spring Boot Project 생성 실제 소스코드를 구현하기 위해 Spring Boot 프로젝트를 생성하고 Maven에 의존성, 즉 Dependency를 추가합니다. 이렇게 프로젝트를 만들고 개발을 위한 설정이 끝나면 구현을 위한 소스코드 패키지의 구조를 정의하고, 이후 하나씩 구현을 진행합니다. Spring Boot 프로젝트는 New - Starter Project를 선택하면 New Spring Starter Project 화면이 출력되는데, 이 화면의 Name, Location, Group, Artifact를 화면과 같이 입력합니다. 그리고 Next 버튼을 누르면 프로젝트의 Dependency를 추가하는 화면으로 전환되는데, Spring Boot Version을 선택합니다. 프로젝트에서 사용할 ..

개발환경 구축 마이크로서비스를 구현하기 위해 오픈소스를 활용한 개발환경을 구축해보도록 하겠습니다. 개발환경은 JDK, STS, Lombok, Maven의 순서로 설치를 합니다. 본 강의의 실습을 위해 JDK와 STS를 설치합니다. 그리고 자바에서 도메인 객체를 만들 때 프로퍼티에 대한 Getter, Setter 그리고 ToString, 생성자들을 객체마다 반복적으로 만들어야 합니다. 이런 반복적인 코드들을 어노테이션 선언만으로 자동 생성해 주는 라이브러리인 Lombok도 설치합니다. 그리고 Build 도구는 Maven을 사용합니다. JDK 설치 JDK는 오라클 사이트의 다운로드 메뉴에서 자신의 운영체제와 맞는 버전을 다운로드 받아서 설치합니다. 실습에 사용하는 컴퓨터는 64비트 운영체제로, 64비트용 J..

쇼핑몰 서비스 업무 흐름 쇼핑몰 서비스의 업무 흐름은 가장 기본적인 구매자의 제품 구매 사례 관점에 대해 알아보겠습니다. 구매자는 구매하고자 하는 상품과 구매 수량을 입력해서 상품을 주문하고, 주문한 상품의 배송상태를 확인합니다. 식별한 마이크로서비스들 간의 업무 흐름으로, 먼저 구매자는 상품 구매를 하기 위해서 화면을 통해 구매하려는 상품과 구매 수량을 입력합니다. 구매 정보가 입력되면 Account 서비스로 구매자 이름으로 입력된 사람이 회원인지 아닌지 확인합니다. Account 서비스에 구매한 상품의 배송을 위한 주소를 가져와 상품을 배송 받을 주소로 설정합니다. 그리고 구매하기 위해 입력한 상품 이름으로 Product 서비스에서 해당 상품의 가격이 얼마인지 요청해서 전달 받은 후 입력한 구매수량에..

애그리게잇 도메인 객체의 관리는 객체의 생명주기 동안 무결성을 유지하고 생명주기 관리를 위해 객체의 관계가 복잡해지는 것을 최소화하는 것이 중요합니다. 따라서 업무상 관련 있는 객체들을 묶어 경계를 명확히 정의해서 객체 간 관계가 복잡해지지 않도록 생명주기 전 단계에서 도메인 객체의 무결성을 유지할 수 있게 해주는 Aggregate을 정의해야 합니다. Aggregate은 업무상 관련 있는 객체들을 모아 경계를 명확히 정의하여 객체 간 관계를 복잡하지 않게 합니다. 생명주기 상의 전 단계에서 도메인 객체의 무결성을 유지할 수 있게 해주는 패턴입니다. 한마디로 표현하면, 데이터 변경의 단위로 다루는 연관된 객체의 묶음입니다. Aggregate은 1개 이상의 Entity로 구성됩니다. 그 중 한 Entity는..

헥사고날 아키텍처 전술적 설계는 이전 차시에서 헥사고날 아키텍처로 설명했던 마이크로서비스의 가장 안쪽의 도메인 모델을 설계합니다. 그 다음은 도메인 모듈, 그리고 마이크로서비스를 설계를 합니다. 이 헥사고날 아키텍처는 고유한 비즈니스의 개념을 표현하는 도메인 모델과 UI, 데이터베이스 등의 기술을 분리합니다. 도메인과 기술의 분리는 빠르게 변화하는 기술의 변경과 대체를 쉽고 빠르게 수행할 수 있습니다. 그럼 모델링을 하기에 앞서 모델 패키지 구조를 Model, Repository, Service로 구성하고, 그리고 실제 도메인 모델이 그려질 다이어그램이 위치합니다. Domain 안의 Model이라는 패키지 안에는 도메인 모델을 구성하는 Entity, 값 객체, 표준 타입의 도메인 모델들이 위치합니다. 이..

마이크로 서비스 내부 설계를 위한 전술적 설계 및 주요 개념 마이크로서비스는 도메인의 개념을 명확하고 자세히 표현하는 도메인 모델링을 통해 코드로 구현합니다. 즉, 전술적 설계란 전략적 설계를 통해 도출된 마이크로서비스의 내부를 상세히 설계하는 활동입니다. 전술적 설계는 도메인 주도 설계 개념에 나오는 용어로 비즈니스의 고유한 활동을 정확하게 모델링하는 설계 패턴과 방법입니다. 설계자는 이 절차와 다양한 기법들을 활용해서 개발하려는 서비스의 개념과 동작을 모델로 표현합니다. 이 전술적 설계의 진행 절차와 방법은 이전의 전략적 설계를 통해 식별했던 6개의 마이크로서비스로 구성된 쇼핑몰 시스템을 예제로 설명을 드리도록 하겠습니다. 마이크로 서비스의 내부 구조 마이크로서비스를 표현하는 6각형의 도형이 있습니다..

엔티티 / 애그리게잇 이 entity라는 것은 이벤트 수행 결과를 표현하는 데이터, 저장하는 데이터입니다. 이 entity aggregate 이름은 노란색 스티커에 작성해서 command과 도메인 이벤트 짝의 위쪽에 살짝 겹치도록 붙이게 됩니다. 이렇게 command, 도메인 이벤트에서 entity aggregate을 찾는 동안 새로운 도메인 이벤트를 발견할 수 있습니다. 이런 경우도 발견하는 즉시 모델링 공간 내의 흐름에 맞는 위치에 작성해서 붙이면 됩니다. change account command와 account changed 도메인 이벤트의 account에 대한 변경 요청과 변경이 수행되었다는 이벤트의 짝으로 account로 작성해서 붙일 수 있습니다. 마찬가지로 request purchase와 p..

이벤트 스토밍 이벤트 스토밍은 도메인 이벤트를 찾는 활동으로 시작을 했습니다. 도메인 이벤트를 동작하게 하는 command를 찾는 활동에 대해 알아보겠습니다. 커맨드 command는 도메인 이벤트를 발생시키는, 즉 도메인 이벤트를 동작하게 하는 명령입니다. 이 command의 이름은 change account, request shipment와 같이 명령어의 형태로 작성을 합니다. 찾은 command의 이름은 파란색 스티커에 작성을 해서 이 command과 연관된 도메인 이벤트의 왼쪽에 붙입니다. account changed라는 도메인 이벤트를 동작하게 하는 만드는 command으로 change account를 적어서 account changed 스티커의 왼쪽에 붙입니다. 이 방법으로 account reg..

쇼핑몰 서비스 이 쇼핑몰 서비스는 상품을 판매하는 사람과 구매하는 사람을 이어주는 서비스입니다. 이 서비스는 판매자가 상품을 온라인으로 팔기 위해 쇼핑몰 서비스에 상품을 등록합니다. 이 상품이 필요한 사람이 상품을 주문하면 판매자는 구매한 사람에게 상품을 배송합니다. 이후 구매자가 상품을 받으면 구매를 확정하는 일반적인 쇼핑몰 서비스입니다. 이 서비스의 사용자는 상품 판매자와 상품 구매자로, 상품 판매자는 판매하고자 하는 상품을 쇼핑몰 서비스에 등록합니다. 판매가 된 상품을 구매자에게 발송하는 업무 그리고 상품 구매자는 상품 판매자가 등록해놓은 상품을 구매합니다. 상품이 도착하면 최종 구매를 완료하게 됩니다. 이벤트 스토밍은 도메인의 이벤트를 찾는 것으로부터 시작합니다. 이 도메인 이벤트를 찾을 때에는 ..

전략적 설계 설계를 진행하면서 계속해서 개념들이 쌓여 설계가 점점 커지게 되면 중요한 것과 덜 중요한 것들을 찾아서 분할을 해야합니다. 소프트웨어를 개발하려고 하는 큰 도메인을 논리적으로 분리해서 핵심, 지원, 일반 서브도메인으로 나눕니다. 서브도메인에서 바운디드 텍스트를 도출하게 되는데 이때 서브도메인과 바운디드 컨텍스트는 1:1 또는 1:N으로 도출이 될 수 있습니다. 이렇게 찾아진 컨텍스트들 간의 관계를 찾아 컨텍스트 맵을 그릴 수 있습니다. 최종적으로 마이크로서비스를 도출할 수 있습니다. 효과적인 설계에 대한 요구 소프트웨어의 전반적인 목적은 특정 도메인의 일이 더 잘 동작하도록 하는 데 있습니다. 따라서 소프트웨어는 도메인을 정확히 구현해야 된다고 말씀을 드릴 수 있습니다. 도메인 주도 설계는 ..

도메인 모델의 표준 패턴 다이어그램과 같은 도메인 모델을 그리기 위해서 알아야 될 도메인 모델의 표준 패턴에 대해 알아보도록 하겠습니다. 전술적 설계를 위한 모델 주도 설계의 내비게이션 맵으로 도메인 모델을 위해 사용하는 표준 패턴과 각 패턴과의 관계를 나타낸 그림입니다. 이런 표준 패턴을 사용해서 도메인 모델링을 하게 되면 다른 사람의 업무, 다른 팀의 업무를 쉽게 이해할 수 있는 설계의 체계를 가져갈 수 있습니다. 따라서 훌륭한 도메인 모델을 개발하기 위해 화면과 같은 표준 패턴에 대해 이해를 하고 있어야 됩니다. 계층형 아키텍처와 도메인 모델의 표준 패턴, 도메인을 표현하기 위한 표준 패턴 중 전술적 설계에서 반드시 이해해야 되는 패턴들이 있습니다. 계층형 아키텍처 소프트웨어를 만들 때 개발되는 시..

컨텍스트 매핑 여러 개의 Bounded Context들은 비즈니스의 문제 해결을 위해 상호 간에 연동이 필요하게 되됩니다. 이런 경우 두 Bounded Context 사이에 선을 그려서 두 Bounded Context가 관계를 갖고 있다는 것을 표시합니다. 서로 다른 Bounded Context를 담당하는 팀에서는 각각의 유비쿼터스 언어를 정의해서 사용하게 됩니다. 이 선은 두 Bounded Context가 갖고 있는 각각의 유비쿼터스 언어 사이의 통역, 번역을 의미한다고 할 수 있습니다. Bounded Context 사이의 관계를 찾아 매핑할 때 두 Bounded Context 사이의 선이 어떤 종류의 관계인지를 찾는 것이 매우 중요합니다. 두 영역 간의 경계와 그 사이의 관계를 잘 정의합니다. 시간에..

도메인 주도 설계 소프트웨어에서 효과적인 설계는 매우 중요합니다. 도메인 주도 설계에서는 설계를 효과적으로 수행할 수 있도록 마이크로서비스를 식별해내는 전략적 설계와 식별된 마이크로서비스의 내부를 상세히 설계하는 전술적 설계로 설계를 두 개의 단계로 설명하고 있습니다. 상세한 설계에 들어가기에 앞서 전략적 설계를 수행합니다. 전략적 설계는 마이크로서비스 도출을 위해서 비즈니스 상 전략적으로 중요한 것을 찾아 중요도에 따라 이를 나누는 방법을 설명하고 있습니다. 전략적 설계 이런 전략적 설계를 수행하기 위해 중요한 두 가지가 있는데, 첫 번째는 도메인의 주요 개념을 정의하고 도메인 간의 경계를 식별하는 Bounded Context가 있습니다. 그리고 두 번째는 프로젝트를 수행하는 모든 팀원이 공통으로 사용..

소프트웨어 본질 소프트웨어 본질은 해당 소프트웨어 사용자들을 위해 복잡한 도메인에 관련된 문제들을 해결하는 데 있습니다. 복잡한 도메인을 소프트웨어로 구현하기 위해서는 해당 도메인을 바르게 이해해야 되는데, 도메인 전문가와 개발자 등 프로젝트에 참여한 모든 구성원들은 도메인의 올바른 이해를 위해 많은 노력을 해야 됩니다. 그러나 보통의 프로젝트에서는 비용과 일정, 인력 등 리소스 관리를 중요시하고 있습니다. 특히 개발자들도 도메인에 대한 이해보다는 UI, Framework, DB 등 최신 기술을 습득하고 적용하는 것에만 관심이 많은 것이 사실입니다. 그러므로 도메인의 문제를 해결할 수 있는 올바른 소프트웨어를 개발하기 위한 도메인 주도 설계에 대해 알아보겠습니다. 도메인 주도 설계 도메인이란 비즈니스나 ..