Page History
우리팀이 복잡한 도메인문제를 해결하기 위해 적용한 액터모델 사용사례를 소개합니다.
사용
구현 서비스
- 광고집행을 할 여력없는 사장님을 위한 간편집행 캠페인 서비스
- 3천개 이상의 롱테일 구간 커머스 사장님이 이용중
기술을 소개하기전 이 기술이 이용된 주요 도메인 단어를 먼저 소개하고 이어가보겠습니다.
우리는 도메인이 부족한 상태에서 도메인 주도개발과 함께 그것을 함께 학습해가며 이후 필요로하는 기술스택을 고민했으며
프로적트에서 작동하고 수익을 내는 영역에 기여를 하고 이미작동중인 액터모델을 LLM에게 분석의뢰를 시도해보았습니다.
캠페인
완성해 나갔으며
이미 작동중인 액터모델로 작성된 코드를 LLM에게 분석의뢰를 시도해 코드의 가치를 설명하게끔 시도를 해보았습니다.
| Note |
|---|
GPT에 의뢰한 사용된 프롬프트는 이 Style이 이용되었습니다. 이 Style이후 컨텐츠는 GPT 작성컨텐츠입니다. |
완성된 서비스
- 광고집행을 할 여력없는 사장님을 위한 간편집행 캠페인 서비스
- 3천개 이상의 롱테일 구간 커머스 사장님이 이용중
| Note |
|---|
선거 캠페인과 광고캠페인을 특징을 설명해 |
캠페인
미국의 선거 캠페인과 광고 캠페인은 매우 다른 목적을 미국의 선거 캠페인과 광고 캠페인은 매우 다른 목적을 가지고 있지만, 사용하는 전략이나 기법에서는 많은 유사점이 있습니다. 미국에서는 이 두 영역이 서로 영향을 주고받으며 진화해왔고, 특히 광고 마케팅 기법이 정치 캠페인에 깊이 스며들면서 현대 정치의 얼굴을 바꾸었다고 할 수 있습니다.
...
이것을 런칭하고 런칭회고를 하고나니 비단 광고플랫폼에서만 활용되는것이 아닌 성숙한 개발문화가 되기위해서도 사용되어야할 중요 단어인것같습니다.
...
- 코파일럿 플러그인이 이용되었으며 전체를 분석하기위해 MSA로 구성된 프로젝트를 멀티모듈로 모았습니다. ( InteliJ + 코파일럿 )
📋
...
프로젝트 구성 요약과 이것은 MSA인가?
서비스명 | 역할 요약 |
|---|---|
| 사용자 프론트에 필요한 기능을 제공하는 API |
| 발송 스케줄링, 도메인 명령 트리거 처리 |
| 회원정보, 장바구니 등의 원시 데이터 수집 |
| 외부 이벤트 수신 (광고조회, 클릭 등) |
| 수집 데이터를 안전하게 저장 |
| 이벤트를 저널 형태로 DB 기록 |
| 사전 세그먼트 분석 (배치 기반) |
| Elasticsearch 기반 실시간 세그먼트 필터전처리기 |
| 발송 대상을 적절히 분배 |
| 발송 실행, 실패 재시도, 비용 정산 처리 |
| 단순 채널별 전송 전담 (DB 미사용) |
| 내부 운영툴 (지표 확인, 정산 관리 등) |
- 생각보다 많은 기능서비스가 존재합니다. ( 이 기능분류 역시 GPT에 의뢰후 정리시도)
- 로컬 올인작동및 디버깅이 모놀리식에서 원래 가능했던 부분이지만 MSA 구성을 시도하면서 파편화가 되고 한방작동 방법을 잃게되는 순간 MSA가 아닌 파편화 시스템이 되버립니다.
- 도커의 도움을 받아 Local All In 디버깅환경을 먼저 구성하였습니다. - MSA구성이 파편화시스템이 안되게 하기위해서는 IaC와 함께 중요한부분입니다.
MSA 아키텍처를 통해 클린아키텍처로 구현한다와~ MSA의 구성요소로 분리되었다는 다른개념으로 가끔 이것을 구분하지 못해 MSA를 잘못해석하는 경우가 있습니다. 여기서 소개되는 어플리케이션 구조는 Kafka를중심으로 MSA에요구하는적합한구성요소로분리구성시도가되었다로설명하는것이맞으며 Java코드로 작성되었습니다. 이것이 MSA냐 아니냐?의 논쟁은 소모적일수 있으며 MSA는 아키텍처는 완성된 그자체가 아니라~ 디벨롭된 공간과 개발문화가 함께 지속 성장하면서 지속도전해야하는 여지로 남겨둡니다. 그러한 관점에서 모놀리식에서 MSA로 한방에 가는것이 아닌 중간 단계인 SOA가 존재하고 이것을 이해하는것은 중요하며 초기 국내IT 대부분은 MSA보다는 전자방식을 통해 성공해왔으며 국내 써밋에서의 MSA의 성공사례는 나이스하지만~ 알려지지 않은 실패사례가 훨씬더 많을것으로 추정해봅니다.
추가 참고 자료 : SOA VS MSA
| Note |
|---|
광고플랫폼으로 각 저장소별기능은 그림과 같습니다. 이것은 MSA의 구성요소관점에서 적합한지? 또는 개선사항이 없는지 분석해? |
✅ 현재 구조의 장점 요약
| 항목 | 설명 |
|---|---|
| 역할 분리 우수 | 각 서비스는 단일 책임 원칙(SRP)을 따르며, 기능별로 잘 분리되어 있음 |
| ETL/분석 흐름 있음 | collector → recoder → analyst → processor 라는 전형적인 데이터 파이프라인 흐름이 존재 |
| 확장성 고려 | distributor, sender, postman 등 발송단을 세분화하여 부하 분산에 유리 |
| Elastic 기반 필터 처리 | 실시간 타겟팅/세그먼트 처리를 위해 processor에 Elasticsearch 도입은 적절함 |
| 비용 처리까지 고려 |
|
✅ 개선 요약
| 항목 | 현재 상태 | 개선 제안 |
|---|---|---|
| 이벤트 흐름 | 일부 동기 호출 가능성 | Kafka 등 메시징 기반 비동기 구조 |
| 명명 규칙 | recoder 등 오탈자 존재 | recorder 등 명확한 명칭 정비 |
| 세그먼트 분석 | 배치/실시간 나뉨 | 명확한 소스/목적 구분 필요 |
| 운영툴 | 내부 확인 용도만 명시 | 관측/로깅/보안 기능 분리 고려 |
| 워크플로우 관리 | CommandCenter 단일 | 복잡도 따라 Workflow Engine 고려 가능 |
쿠폰생성기
작업자 : 주디
소개 : 카페24 API의 쿠폰처리부분의 제공 TPS가 극단적으로 적은수준으로 제공되 실패없이 호출하려고 적용되었습니다. Cafe24 API중 금액관련 API는 대부분 몰별 TPS가 1이하의 제약이 있습니다. 이 제약을 고려하지 않으면 서비스 API는 장애를 뿜어내게 됩니다. 동시성이란? 한꺼번에 여러개를 처리할수 있는 처리능력도 중요하지만 그것보다 오류없이 안정적으로 제어를 하는영역이 더많은 기술스킬을 요구하게됩니다.
...