강승현입니다

개떡같이 말해도 찰떡같이 답변하는 RAG - 한글 문서는 왜 파싱부터 다른가

CODe_ — Fri, 27 Mar 2026 20:43:12 +0900

TL;DR: RAG 파이프라인에서 파싱은 문서를 깨끗한 텍스트로 바꾸는 첫 단계다. 영어는 공백으로 단어가 나뉘지만, 한글은 조사와 어미가 어근에 달라붙어 형태소 분석 없이는 제대로 된 토큰화가 불가능하다. 파싱을 대충 넘기면 한 문단 중간에서 청크가 잘려 맥락이 끊기고, 조사가 붙은 채로 임베딩되어 벡터 거리가 벌어지며, "배포"를 검색해도 "배포를"이 포함된 문서가 누락된다.

파싱, 대충 해도 되지 않을까

RAG를 처음 만들 때, 대부분의 튜토리얼은 영어 PDF 몇 장을 LangChain에 넣는 것으로 시작한다. 코드 몇 줄이면 문서가 벡터로 변환되고, 질문을 던지면 답이 나온다. "생각보다 쉬운데?" 싶다.

그런데 사내 위키를 넣으려고 하면 이야기가 달라진다. Confluence에서 가져온 문서에는 HTML 태그가 잔뜩 섞여 있고, 표는 파싱 과정에서 행·열 구조가 사라지고 셀 안의 숫자만 나열된다. 거기에 한글이라는 변수가 더해진다. "배포 절차"를 검색하면 "배포를", "배포에서", "배포했던" 같은 조사 붙은 표현은 매칭이 안 되는 상황이 벌어진다.

결국 파싱은 RAG 파이프라인에서 가장 먼저 마주하는 단계이면서, 가장 과소평가되는 단계이기도 하다. 이 글에서는 파싱이 왜 중요한지, 한글에서는 왜 유독 까다로운지, 그리고 어떤 도구를 쓸 수 있는지 정리한다.

RAG 파이프라인에서 파싱의 위치

RAG의 오프라인 인덱싱 파이프라인은 다섯 단계로 나뉜다.

문서 수집 → 파싱 → 청킹 → 임베딩 → 벡터 저장

그림 1 : RAG 오프라인 인덱싱 파이프라인에서 파싱의 위치. 파싱은 문서 수집 직후, 청킹 직전에 위치한다. 비정형 문서(HTML, PDF 등)를 깨끗한 텍스트로 변환하는 역할이며, 이 단계의 품질이 후속 단계 전체에 영향을 준다.

파싱(Parsing)이 하는 일은 비정형 문서에서 깨끗한 텍스트를 뽑아내는 것이다. 다만 문서를 가져오는 방식에 따라 파싱의 무게가 달라진다.

사내 위키를 예로 들면, HTML을 통째로 가져오는 방법만 있는 것은 아니다. Confluence REST API는 storage format(XHTML 기반)이나 렌더링된 본문을 직접 반환하고, Notion API는 블록 단위의 JSON 구조를 준다. API로 가져오면 네비게이션이나 푸터 같은 노이즈가 애초에 포함되지 않기 때문에 HTML 태그를 일일이 걷어내는 작업이 크게 줄어든다.

그렇다고 파싱이 필요 없어지는 것은 아니다. API 응답이든 HTML이든, 텍스트를 정제하는 과정은 공통으로 필요하다.

문서 구조 처리: HTML이면 태그를 정리하고, API 응답이면 JSON/XHTML에서 본문을 추출한다. 어느 쪽이든 제목 계층(<h1>~<h6> 또는 heading 블록)은 보존해야 한다
노이즈 필터링: HTML 경로에서는 네비게이션, 광고, 푸터를 제거한다. API 경로에서는 이 작업이 대부분 불필요하다
인코딩 처리: 깨진 문자, 특수 문자를 정규화한다. 특히 레거시 한국어 문서에서 흔한 EUC-KR 인코딩은 UTF-8로 변환하지 않으면 파싱 전체가 깨진다
텍스트 정제: 연속 공백 제거, 줄바꿈 정리 등 텍스트를 깔끔하게 만든다

여기서 중요한 점이 하나 있다. HTML 태그를 무분별하게 제거하면 오히려 문맥이 깨진다는 것이다. <h2> 태그를 제거하면 제목과 본문이 뒤섞여 "배포 절차"라는 제목 아래의 내용이 다른 섹션의 내용과 합쳐져버린다. 제목 태그를 마크다운 헤딩(##)으로 변환하는 것이 단순 제거보다 낫다.

파싱이 엉망이면 이후 과정도 엉망이 된다. 제목과 본문이 하나로 합쳐진 텍스트를 청킹하면 한 청크 안에 서로 다른 주제가 섞이고, 그 상태로 임베딩하면 "배포 절차"와 "모니터링 설정"이 같은 벡터 공간에 놓인다. 검색할 때 "배포"를 입력해도 모니터링 문서가 함께 올라오는 식이다. 파이프라인에서 가장 앞에 있기 때문에, 여기서 생긴 오류는 뒤에서 복구할 수 없다.

여기서 중요한 점이 하나 있다. HTML 태그를 무분별하게 제거하면 오히려 문맥이 무너진다는 것이다. <h2> 태그를 제거하면 제목과 본문이 뒤섞여 "배포 절차"라는 제목 아래의 내용이 다른 섹션의 내용과 합쳐져버린다. 제목 태그를 마크다운 헤딩(##)으로 변환하는 것이 단순 제거보다 낫다.

암튼 그래서 파싱이 엉망이면 이후에 기대하는 결과가 나오지 않을 것이다. 청킹 경계가 의미 단위와 맞지 않게 되고, 임베딩 벡터가 왜곡되며, 검색 결과는 쓸모없어진다. ~~(AI가 그림에서 쓰레기라고 표현했다..)~~ 파이프라인에서 가장 앞에 있기 때문에, 여기서 생긴 오류는 뒤에서 복구할 수 없다.

영어와 한글, 토큰화부터 다르다

파싱의 핵심 단계 중 하나가 토큰화(Tokenization)다. 텍스트를 의미 있는 단위로 쪼개는 것이다. 여기서 영어와 한글의 근본적인 차이가 드러난다.

영어는 단순하다. 공백으로 자르면 된다.

"I read a book" → ["I", "read", "a", "book"]

단어 사이에 공백이 있고, 공백이 곧 토큰 경계다. 물론 영어에도 복수형(-s), 과거형(-ed) 같은 변화가 있지만, 공백 분리만으로도 대부분의 NLP 태스크에서 충분히 작동한다.

한글은 다르다. 공백으로 자르면 이런 결과가 나온다.

"나는 책을 읽었다" → ["나는", "책을", "읽었다"]

얼핏 보면 괜찮아 보인다. 하지만 "나는"은 "나"(대명사) + "는"(조사)이 합쳐진 것이고, "책을"은 "책"(명사) + "을"(조사), "읽었다"는 "읽"(어간) + "었"(과거 시제 선어말어미) + "다"(종결어미)다.

한글은 교착어(Agglutinative Language)다. 어근에 조사와 어미가 결합해서 하나의 어절을 이룬다. "책"이라는 단어 하나가 "책이", "책을", "책에", "책으로", "책에서", "책이었던", "책이라면", "책에서부터" 등 수많은 표면형으로 변한다.

그림 2: 영어와 한글의 토큰화 차이. 영어는 공백 분리만으로 의미 단위가 나뉘지만, 한글은 공백으로 나눠도 조사와 어미가 어근에 붙어 있다. 형태소 분석을 거쳐야 "나/는", "책/을", "읽/었/다"처럼 의미 단위로 분리된다.

이 차이가 RAG에서 실제로 문제를 일으킨다.

먼저 BM25 검색을 보자. BM25(Best Matching 25)는 단어의 출현 빈도와 문서 길이를 기반으로 관련도를 계산하는 키워드 검색 알고리즘이다. 벡터 검색과 함께 RAG에서 가장 많이 쓰이는 검색 방식이기도 하다. 문제는 BM25가 토큰 단위로 매칭한다는 것이다. 사용자가 "배포"를 검색하면, 문서에 있는 "배포를", "배포에서", "배포했던"은 다른 토큰으로 취급되어 매칭이 안 된다. 형태소 분석 없이 공백 기반으로 BM25를 돌렸을 때와 형태소 분석기를 적용했을 때 검색 F1 점수가 0.667에서 0.798로 올라간다(공개 한국어 QA 벤치마크 기준이며, 도메인에 따라 편차가 있다). 여기서 놓치기 쉬운 점이 하나 있다. 검색 쿼리에도 동일한 형태소 분석기를 적용해야 인덱스와 매칭이 일관된다는 것이다. 문서만 분석하고 쿼리는 공백으로 자르면 효과가 반감된다.

임베딩에서도 문제가 있다. 현대 임베딩 모델은 서브워드 토큰화(Subword Tokenization)를 쓰기 때문에 공백 분리에 직접 의존하지는 않는다. 하지만 한글에서는 BPE(Byte Pair Encoding) 과분절 문제가 발생한다. "우두머리"가 "우두"+"머리"로 쪼개져 의미가 파괴되는 식이다. 형태소 경계를 미리 알려주면 이 문제를 완화할 수 있다.

물론 text-embedding-3 같은 최신 임베딩 모델은 한국어를 이전보다 훨씬 잘 처리한다. 벡터 검색만 사용하는 소규모 RAG라면 형태소 분석 없이도 어느 정도 작동하는 경우가 있다. 하지만 BM25를 함께 쓰는 하이브리드 검색에서는 형태소 분석이 여전히 필수이고, 임베딩에서도 정제된 텍스트를 넣는 것이 노이즈가 섞인 원문을 그대로 넣는 것보다 결과가 안정적이다. 벡터 검색 단독으로 시작하고, BM25를 추가하는 시점에 형태소 분석을 도입하는 것도 합리적인 접근이다.

다른 언어는 어떨까

한글만 유독 까다로운 것은 아니다. 다른 언어들도 각자의 파싱 난이도를 가지고 있다.

일본어는 세 가지 문자 체계(히라가나, 가타카나, 한자)가 섞여 있고, 단어 사이에 공백이 거의 없다. "東京タワーに行きました"처럼 한자와 가나가 연속으로 이어진다. 별도의 분절기(MeCab-IPAdic 등)가 필수다.

중국어도 단어 사이에 공백이 없다. "我去北京了"에서 "我/去/北京/了"로 분절해야 한다. jieba 같은 분절 라이브러리를 쓴다. 다만 한 글자가 독립적 의미를 가지는 경우가 많아 분절 실패의 영향이 한글보다는 적다.

독일어는 복합어가 유명하다. "Donaudampfschifffahrtsgesellschaft"(도나우 증기 선박 항해 회사)처럼 단어를 끝없이 붙여 쓴다. 복합어 분해(decompounding)가 필요하다.

한글의 특수한 점은 공백은 존재하지만, 공백 단위가 의미 단위가 아니라는 것이다. 일본어와 중국어는 공백 자체가 없어서 분절이 필요하다는 게 명확하다. 독일어는 복합어를 제외하면 공백 분리가 잘 작동한다. 반면 한글은 공백이 있어서 "그냥 공백으로 자르면 되겠지"라는 착각을 유발한다. 결국 형태소 분석이라는 추가 단계를 거쳐야 한다는 점을 인식하는 것 자체가 첫 번째 과제다.

한글 파싱을 위한 도구들

한글 RAG 파이프라인에서 파싱은 크게 두 레이어로 나뉜다. 문서에서 텍스트를 추출하는 문서 파싱 레이어와, 한국어 텍스트를 정제하는 형태소 분석 레이어다.

문서 파싱

문서를 가져오는 경로에 따라 도구가 달라진다.

API 기반 (Confluence, Notion 등)

위키 플랫폼이 API를 제공한다면 가장 깔끔한 경로다. LangChain의 ConfluenceLoader는 Confluence REST API를 통해 페이지 본문을 직접 가져온다. NotionDBLoader도 마찬가지다. API 응답은 이미 구조화되어 있어서 HTML 태그를 직접 다룰 일이 줄어든다. 다만 Confluence Cloud와 Server/DC는 API 엔드포인트가 다르므로 환경에 맞게 설정해야 한다.

HTML 직접 파싱

API가 없거나 HTML을 직접 처리해야 하는 경우에는 BeautifulSoup4가 기본이다. lxml 파서를 쓰면 빠르고, html5lib을 쓰면 브라우저와 동일하게 해석한다. 주의할 점은 동일한 잘못된 HTML에 대해 파서마다 다른 결과를 만든다는 것이다.

# pip install beautifulsoup4 lxml
from bs4 import BeautifulSoup

html = "<h2>배포 절차</h2><p>서버에 접속하여...</p>"
soup = BeautifulSoup(html, "lxml")
# 태그를 전부 제거하지 말고, 구조를 보존하면서 텍스트를 추출한다
for tag in soup.find_all(["h1", "h2", "h3"]):
    tag.string = f"\n## {tag.get_text()}\n"
text = soup.get_text(separator="\n")

비정형 문서 (PDF, DOCX 등). Unstructured.io는 PDF, 이미지, DOCX 등 다양한 포맷을 파싱하는 라이브러리다. partition_html(url="...") 하나로 웹 페이지를 구조화된 요소(제목, 본문, 목록 등)로 분해한다. 다만 오픈소스 버전의 한국어 지원 완성도는 영어보다 낮다. 특히 스캔 PDF에서는 OCR 품질을 별도로 검증해야 한다.

다이어그램과 구조화된 비텍스트 데이터. 텍스트와 HTML만 파싱하면 끝이 아니다. 사내 위키에는 Mermaid, PlantUML, draw.io 같은 다이어그램이 포함되어 있는 경우가 많고, 이 안에 담긴 정보가 오히려 핵심인 경우도 있다. 아키텍처 구조도, 배포 흐름도, 시스템 간 연결 관계 같은 내용이 텍스트가 아닌 다이어그램에만 존재하는 경우다.

이런 데이터는 100% 원본 그대로 저장하기 어렵지만, 검색 대상으로 포함시키려면 텍스트로 변환하는 과정이 필요하다. 접근 방식은 포맷에 따라 다르다.

Mermaid, PlantUML: 코드 기반 다이어그램이라 원본 코드 자체를 텍스트로 보존하면 된다. graph TD; A-->B 같은 코드에 노드명과 관계가 그대로 담겨 있어서 별도 변환 없이도 검색에 걸린다
draw.io: XML 기반이라 다른 접근이 필요하다. Confluence에서는 API로 .drawio 첨부파일을 다운로드한 뒤, XML을 파싱하여 노드 목록과 연결 관계를 텍스트로 추출한다. 이때 draw.io 특유의 플레이스홀더(%name% 등)를 실제 텍스트로 치환하는 과정을 거쳐야 의미 있는 결과가 나온다

다이어그램 파싱은 일반 텍스트 파싱과 달리 표준 도구가 거의 없다. 포맷별로 파서를 직접 구현해야 하는 경우가 대부분이다.

형태소 분석이란

HTML에서 텍스트를 추출한 다음, 한국어에서는 형태소 분석(Morphological Analysis)이라는 추가 단계가 필요하다.

형태소는 의미를 가지는 가장 작은 언어 단위다. "읽었다"를 예로 들면, "읽"(동사 어간) + "었"(과거 시제) + "다"(종결어미)로 나뉜다. 이 세 조각 중 하나라도 빠지면 원래 의미가 달라지거나 성립하지 않는다. 형태소 분석기는 이 작업을 자동으로 해주는 도구다. 어절을 입력하면 형태소 단위로 쪼개고, 각 조각이 명사인지 조사인지 어미인지 품사 태그를 붙여준다.

from kiwipiepy import Kiwi

kiwi = Kiwi()
tokens = kiwi.tokenize("나는 책을 읽었다")
for token in tokens:
    print(f"{token.form}/{token.tag}")
# 나/NP  는/JX  책/NNG  을/JKO  읽/VV  었/EP  다/EF

위 결과에서 NNG는 일반 명사, JKO는 목적격 조사, VV는 동사 어간이다. 이렇게 품사가 분리되면 조사를 떼어내고 "나", "책", "읽" 같은 핵심 의미만 뽑아낼 수 있다. RAG에서 형태소 분석이 필요한 이유가 여기에 있다. "배포를", "배포에서", "배포했던"이 전부 "배포"라는 같은 어근을 공유한다는 걸 알아야 검색에서 매칭이 된다.

형태소 분석기 선택

형태소가 뭔지, 왜 필요한지 알았으면 이제 도구를 고를 차례다. Python에서 쓸 수 있는 한국어 형태소 분석기는 여러 개가 있고, 속도·설치 난이도·정확도에 차이가 있다.

Kiwi(kiwipiepy)는 C++ 기반으로 빠르고, 대부분의 환경(Python 3.8~3.11)에서 pip install kiwipiepy로 설치된다. 오타 교정, 사용자 사전 추가도 지원한다.

Mecab-ko는 속도가 가장 빠르다. 10만 건 처리 시 약 6초로, Kkma의 432초와 비교하면 72배 차이가 난다. 단, Windows에서 설치가 까다롭고 Java가 아닌 C++ 기반이라 별도 바이너리가 필요하다.

Okt(Open Korean Text)는 KoNLPy 패키지에 포함되어 있어 접근성이 좋다. stem=True 옵션으로 어간 추출도 가능하다. 다만 JVM이 필요하다는 점이 걸린다.

형태소 분석 결과를 검색에 쓰려면

이제, 분석 결과를 검색에 쓸 수 있는 형태로 가공해야 한다.

먼저 핵심 키워드 추출을 해야한다. 형태소 분석 결과에서 의미를 담고 있는 품사만 골라낸다. 명사(NNG, NNP), 동사 어간(VV), 형용사 어간(VA) 정도를 추출하고, 조사(JKS, JKO 등)와 어미(EP, EF 등)는 버린다.

from kiwipiepy import Kiwi

kiwi = Kiwi()

def extract_keywords(text):
    """의미 있는 품사만 추출하여 키워드 리스트를 반환한다."""
    keep_tags = {"NNG", "NNP", "NNB", "VV", "VA", "SL"}  # 일반적인 시작점. 도메인에 따라 조정 필요
    tokens = kiwi.tokenize(text)
    return [t.form for t in tokens if t.tag in keep_tags]

extract_keywords("배포 절차를 확인하고 서버에 접속했다")
# → ["배포", "절차", "확인", "서버", "접속"]

"배포 절차를 확인하고 서버에 접속했다"에서 조사("를", "하고", "에")와 어미("했다")가 빠지고, "배포", "절차", "확인", "서버", "접속"만 남는다. 이 키워드로 BM25 인덱스를 만들면 "배포"를 검색했을 때 "배포를"이 포함된 문서도 매칭된다.

다음은 텍스트 정규화다. 검색 결과의 일관성을 위해 불필요한 공백, 문장부호 주변 공백, 연속된 특수문자를 정리한다.

import re

def normalize_text(text):
    """검색 품질을 위한 텍스트 정규화."""
    text = re.sub(r"\s+", " ", text)           # 연속 공백 → 단일 공백
    text = re.sub(r"\s*([.,!?;:])\s*", r"\1 ", text)  # 문장부호 주변 정리
    text = text.strip()
    return text

형태소 분석기도 만능은 아니다

형태소 분석기를 붙이면 모든 문제가 해결될 것 같지만, 실무에서는 형태소 분석기 자체가 문제를 일으키는 경우도 있다.

요기요는 가게명 검색에 형태소 분석기를 적용했다가 "형태소 분석기가 답이 아니다"라는 결론에 도달했다. 원인은 세 가지였다. 첫째, 형태소 분석기는 문법에 맞는 텍스트에 특화되어 있어서 "맛닭꼬" 같은 가게명을 제대로 분석하지 못했다. 둘째, 형태소 분석은 서로소 분할(disjoint segmentation)이라서 음절을 공유하는 패턴을 잡지 못했다. 셋째, 사전에 없는 외래어, 줄임말, 신조어에 대응이 불가능했다. 요기요는 결국 N-gram 방식으로 전환했다.

사내 위키에서도 비슷한 문제가 생길 수 있다. 팀명("플랫폼TF"), 프로젝트명("마이그레이션v2"), 내부 약어("PGW", "CS팀")는 형태소 분석기의 사전에 없다. 사용자 사전을 추가하면 어느 정도 대응 가능하지만, 조직이 바뀔 때마다 사전을 갱신해야 하는 운영 부담이 생긴다.

그렇다고 형태소 분석을 안 하면 되느냐 하면, 그것도 아니다. 앞서 본 것처럼 BM25 검색 품질이 20% 가까이 차이 난다. 결국 형태소 분석은 기본으로 적용하되, 고유명사와 내부 용어에 대해서는 사용자 사전이나 N-gram을 병행하는 것이 현실적인 접근이다.

속도도 고려해야 한다. 문서가 수만 건이라면 Kkma는 현실적으로 쓸 수 없다. Mecab이나 Kiwi처럼 빠른 분석기를 쓰되, 정확도가 아쉬운 부분은 하이브리드 검색(BM25 + 벡터 검색)으로 보완하는 전략이 실무에서 많이 쓰인다.

마무리

이 글은 RAG 파이프라인에서 "파싱"이라는 단계를 짚어보기 위해 쓴 글이다. 처음에는 대충 이해하고 넘어갔던 부분인데, 정리하면서 한글 문서가 왜 영어와 다른 접근이 필요한지 명확해졌다.

실제로 직접 구현하면서 느낀 점은, 텍스트 파싱보다 다이어그램 파싱이 더 까다롭다는 것이다. Confluence 위키에는 draw.io 도면이나 Mermaid 흐름도가 곳곳에 있었는데, 버리기엔 핵심 정보가 너무 많았다. 앞서 정리한 방식대로 포맷별 파서를 직접 만들었고, 추출한 텍스트에 형태소 분석까지 적용해서 BM25 검색 대상에 포함시켰다. 100% 완벽한 변환은 아니지만, "이런 다이어그램이 있었다"는 것을 검색으로 찾을 수 있게 된 것만으로도 충분한 가치가 있었다.

참고자료

kt cloud, "AI RAG 파싱 전처리 최적화", kt cloud 기술 블로그, 2025. https://tech.ktcloud.com/entry/2025-09-ktcloud-ai-rag-parsing
Park et al., "An Empirical Study of Tokenization Strategies for Various Korean NLP Tasks", AACL, 2020.
Marker Inc. Korea, "Korean BM25 Tokenizer Benchmark with AutoRAG", GitHub, 2024. https://github.com/Marker-Inc-Korea/AutoRAG-example-korean-embedding-benchmark
Lee et al., "MoB: Morphological Boundary-aware Subword Tokenization", EACL, 2026.
LangChain, "BSHTMLLoader". https://python.langchain.com/docs/integrations/document_loaders/bshtml
BeautifulSoup4, "Differences between parsers". https://www.crummy.com/software/BeautifulSoup/bs4/doc/
Unstructured.io, "Partitioning". https://docs.unstructured.io/open-source/core-functionality/partitioning
Kiwi, "kiwipiepy 공식 문서". https://bab2min.github.io/kiwipiepy/
Ahn et al., "Benchmarking Korean Morphological Analyzers", Applied Sciences, 2023.
KoNLPy, "API Reference, konlpy.tag". https://konlpy.org/ko/stable/api/konlpy.tag/
정승한, "요기요 검색에서 형태소 분석기의 한계와 극복", 요기요 기술블로그, 2024. https://techblog.yogiyo.co.kr/요기요-검색에서-형태소-분석기의-한계와-극복-3da53beb6ea5

개떡같이 말해도 찰떡같이 답변하는 RAG - 텍스트 임베딩 이해하기

CODe_ — Tue, 24 Mar 2026 00:12:46 +0900

TL;DR: 임베딩은 텍스트에 의미 좌표를 부여하는 기술이다. 문서를 통째로 넣지 않고 청킹으로 잘라야 검색 품질이 올라가며, 차원은 높다고 무조건 좋은 것이 아니다. 768~1,024차원에서도 최신 모델은 충분히 강력하고, MRL로 차원을 유연하게 조절할 수 있다

벡터 DB에 텍스트를 넣으려면

사내 위키를 기반으로 RAG(Retrieval-Augmented Generation) 시스템을 처음 만들 때, 첫 번째 관문은 임베딩이었다. "텍스트를 벡터로 바꾼다"는 설명은 이해했지만, 실제로 어떤 모델을 써야 하는지, 문서를 어떻게 자르는지, 차원은 얼마로 설정해야 하는지 물음표가 줄줄이 이어졌다.

RAG 파이프라인의 구조는 단순하다. 문서를 적당한 크기로 자르고(청킹), 각 청크를 벡터로 변환해(임베딩) 벡터 DB에 저장한다. 사용자가 질문을 던지면 질문도 같은 방식으로 임베딩(Embedding)한 뒤, 벡터 DB에서 가장 가까운 청크들을 꺼내 LLM (Large Language Model)에 전달한다.

이 글에서는 임베딩이 어떤 원리로 작동하는지, 청킹 전략은 어떻게 선택하는지, 차원 선택에 어떤 함정이 있는지, 그리고 2026년 기준 주요 모델을 어떻게 비교할 수 있는지 정리한다.

코사인 유사도나 벡터 같은 개념은 머리 아프니까 다음 게시물에서 좀 더 자세히 이야기하고, 이번 글에선 임베딩에 대해 이야기한다.

텍스트를 숫자로 바꾸는 기술

컴퓨터는 텍스트를 모른다

컴퓨터는 텍스트 자체를 이해하지 못한다. 텍스트를 숫자로 변환해야만 연산이 가능하다. 가장 단순한 방법은 원-핫 인코딩 (One-Hot Encoding)이다. 어휘 사전에 있는 단어 수만큼 차원을 만들고, 그 단어의 번호 위치에만 1을 채운다.

원-핫 인코딩을 풀어서 설명하면 이렇다. 어휘 사전에 10만 개의 단어가 있을 때, "고양이"가 사전의 7,302번째 단어라면 10만 개짜리 배열에서 7,302번 위치만 1이고 나머지는 전부 0이다. 단어 하나를 표현하는 데 10만 개 숫자를 쓰는 셈이다.

이 방식의 첫 번째 문제는 공간 낭비다. 단어 하나에 10만 차원 벡터가 필요하다. 두 번째, 더 큰 문제는 의미를 담지 못한다는 것이다. "고양이"와 "강아지"의 벡터 거리가 "고양이"와 "냉장고"의 거리와 같다. 어느 자리에 1이 있느냐만 다를 뿐, 비슷한 의미라는 정보가 숫자에 전혀 반영되지 않는다.

임베딩이란 의미 좌표다

임베딩은 이 한계를 극복하기 위해 등장했다. 고차원 희소 벡터 대신, 수백~수천 차원의 밀집 벡터(Dense Vector)로 텍스트를 표현한다. 핵심은 의미가 비슷한 텍스트를 벡터 공간에서 가깝게 배치한다는 것이다.

GPS 좌표로 비유하면 이해하기 쉽다. 서울(37.56, 126.97)과 인천(37.45, 126.70)은 좌표가 가깝기 때문에 지리적으로도 가깝다는 것을 알 수 있다. 임베딩도 마찬가지다. "배포 롤백"과 "서비스 되돌리기"는 임베딩 공간에서 가까이 위치한다. 좌표만 봐도 의미의 근접성을 계산할 수 있다.

두 벡터가 얼마나 가까운지는 코사인 유사도(Cosine Similarity)로 측정한다. -1부터 1까지 값을 가지며, 1에 가까울수록 의미가 비슷하고 -1에 가까울수록 반대 의미다. 0은 연관성이 없음을 뜻한다.

원-핫에서 문장 임베딩까지

임베딩 기술은 빠르게 진화했다. 2013년 Word2Vec이 등장하면서 단어 수준의 의미 임베딩이 가능해졌다. "왕 - 남성", "여성 = 여왕"이라는 벡터 연산이 실제로 작동하는 것을 보여줬다.

2018년 BERT가 등장하면서 문맥을 고려한 임베딩이 본격화됐다. 같은 "배"라는 단어도 "배가 아프다"와 "배를 탄다"에서 다른 벡터를 가지게 됐다. 현대 임베딩 모델들은 단어 수준을 넘어 문장 전체, 혹은 여러 문장으로 이루어진 청크를 하나의 벡터로 표현한다.

API로 임베딩 생성하기

OpenAI의 text-embedding-3-small 모델로 임베딩을 생성하는 방법은 간단하다.

아래 코드는 두 텍스트를 임베딩하고 코사인 유사도를 계산하는 예시다. 결과를 보면 의미가 비슷한 텍스트끼리는 높은 유사도 점수가 나오고, 무관한 텍스트와는 낮은 점수가 나오는 것을 확인할 수 있다.

from openai import OpenAI
import numpy as np

client = OpenAI()

def get_embedding(text: str, model: str = "text-embedding-3-small") -> list[float]:
    response = client.embeddings.create(input=text, model=model)
    return response.data[0].embedding

def cosine_similarity(a: list[float], b: list[float]) -> float:
    a, b = np.array(a), np.array(b)
    return float(np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b)))

emb1 = get_embedding("배포 롤백")
emb2 = get_embedding("서비스를 이전 버전으로 되돌리기")
emb3 = get_embedding("오늘 점심 메뉴")

print(cosine_similarity(emb1, emb2))  # 예: 0.87 (유사)
print(cosine_similarity(emb1, emb3))  # 예: 0.12 (무관)

반환된 벡터 길이는 1,536개의 부동소수점 숫자다. 이 숫자들이 텍스트의 의미 좌표가 된다.

중요한 제약이 하나 있다. 문서를 저장할 때와 검색 쿼리를 임베딩할 때 반드시 같은 모델을 써야 한다. 모델마다 벡터 공간이 다르기 때문에, 다른 모델로 만든 벡터는 비교가 불가능하다. 모델을 바꾸면 저장된 모든 벡터를 재임베딩해야 한다.

임베딩 공간에서의 텍스트 배치. 의미가 비슷한 텍스트(배포 롤백, 서비스 되돌리기)는 벡터 공간에서 가깝고, 무관한 텍스트(오늘 점심 메뉴)는 멀리 위치한다. 실제로는 1,536차원 이상이지만 이해를 위해 2D로 단순화했다. 코사인 유사도가 높을수록 두 점 사이의 각도가 작아진다.

문서를 임베딩하기 전에, 자른다

왜 자르는가

긴 문서를 통째로 하나의 벡터로 만들면 두 가지 문제가 생긴다.

첫째, 모델의 토큰 제한이 있다. text-embedding-3-small의 최대 입력 길이는 8,191 토큰이다. 수백 페이지짜리 문서는 물리적으로 들어가지 않는다.

둘째, 문서 전체를 하나의 벡터로 압축하면 특정 주제의 신호가 희석된다. "시스템 배포 절차"와 "장애 대응 매뉴얼"이 섞인 긴 문서를 하나의 벡터로 만들면, "배포 오류 처리" 같은 쿼리에 이 벡터가 적절히 응답하지 못한다.

청킹 (Chunking)은 문서를 검색에 적합한 크기로 분할하는 과정이다. 어떻게 자르느냐에 따라 RAG 검색 품질이 크게 달라진다.

주요 전략

내가 고민 했던 전략은 크게 3가지였다.

전략	특징	적합한 상황
고정 크기	단순하고 빠름. 문장 경계를 무시할 수 있음	빠른 프로토타입
재귀적 분할	문단, 문장, 단어 순서로 경계를 지키며 분할	범용적으로 쓰임
의미적 청킹	ML 모델로 의미 경계를 탐지해 분할	주제 전환이 잦은 문서

다음 그림을 보고 좀 더 이해를 도울 수 있을 것이다.

얼마나 잘라야 하나

청크 크기를 너무 작게 잡으면 검색 정밀도는 높아지지만 맥락이 부족해 단편적인 답변이 나온다. 반대로 너무 크게 잡으면 여러 주제가 하나의 청크에 섞여 검색 정밀도가 떨어진다.

오버랩(Overlap)은 인접 청크가 일부 텍스트를 공유하도록 겹치는 설정이다. 청크 경계에서 문장이 끊겨 맥락이 손실되는 문제를 완화한다.

실무에서 권장하는 시작점은 400~512 토큰 청크 크기에 10~20% 오버랩이다. 도메인과 문서 특성에 따라 조정이 필요하므로 실제 쿼리로 검색 품질을 측정하면서 튜닝하는 것이 맞다.

재귀적 분할 코드 예시

LangChain의 RecursiveCharacterTextSplitter는 범용적으로 쓰기 좋다. 분할 우선순위는 단락(\n\n) → 줄바꿈(\n) → 문장(. ) → 단어 순서다. 각 청크가 chunk_size를 넘지 않을 때까지 더 세밀한 구분자로 재귀적으로 시도한다.

from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,        # 최대 토큰 수 (문자 기준이므로 조정 필요)
    chunk_overlap=64,      # 인접 청크 간 겹치는 문자 수
    separators=["\n\n", "\n", ". ", " ", ""],
)

docs = splitter.create_documents([long_document_text])

for i, doc in enumerate(docs[:3]):
    print(f"[청크 {i+1}] 길이: {len(doc.page_content)}자")
    print(doc.page_content[:100])
    print("---")

위 코드를 실행하면 각 청크의 길이와 앞부분을 확인할 수 있다. 실제로 돌려보면서 문장이 어색하게 잘리지 않는지, 한 청크에 너무 많은 주제가 담기지 않는지 눈으로 확인하는 과정이 중요하다.

wiki-rag를 만들 때는 프로토타이핑 속도를 우선했다. 어떤 전략이 최적인지 비교할 여유 없이, 문서당 약 400자 단위로 분할하고 오버랩 구간을 넣는 방식으로 시작했다. 문장이 청크 경계에서 잘릴 수 있기 때문에 오버랩은 필수였다. 완벽한 전략은 아니었지만, 빠르게 동작하는 파이프라인을 먼저 만들고 이후에 검색 결과를 보면서 조정하는 접근이 실무에서는 더 현실적이었다.

배포와 롤백 두 주제가 섞인 문서를 세 전략으로 나눈 결과. 고정 크기는 "CI에서"처럼 문장 중간을 자르고 주제 경계도 무시한다. 재귀적 분할은 문장이 끝나는 지점에서 자르고 오버랩으로 경계 맥락을 보존한다. 의미적 청킹은 주제가 바뀌는 지점을 감지해서 각 청크가 하나의 주제를 온전히 담도록 나눈다.

차원이 높으면 무조건 좋을까

차원이 높은 것만 쓰면 되겠다

내가 이 개념을 공부할 때 이런 생각을 했다. 물리적으로 시스템 리소스만 문제 없다면 계속 차원을 늘려도 되지 않을까? 차원이 높을수록 더 세밀한 표현이 가능하고, 그러면 검색 성능도 높아질 것이다. text-embedding-3-small(1,536차원)보다 text-embedding-3-large(3,072차원)가 당연히 좋을 것이다.

하지만 이 생각은 부분적으로만 맞다. 실제로 차원이 다른 모델을 비교해보면 유의미한 차이가 있긴 하다. 하지만 그 차이가 차원 자체에서 오는지, 모델 아키텍처와 훈련 데이터에서 오는지를 구분하지 않으면 잘못된 결론에 이른다.

차원을 올려도 성능은 안 따라온다

모델 성능 비교 표를 보면 자주 마주할 수 있는 단어가 있다. MTEB(Massive Text Embedding Benchmark)는 검색, 분류, 클러스터링 등 다양한 태스크를 종합 평가하는 벤치마크다. MTEB 점수를 보면 차원 증가에 따른 성능 향상이 일정하지 않다.

384차원에서 768차원으로 올라가는 구간에서는 성능이 눈에 띄게 향상된다. 하지만 1,024차원에서 3,072차원, 4,096차원으로 올라가는 구간에서는 같은 차원 증가 대비 향상이 급격히 줄어든다.

더 주목할 만한 사실이 있다. BAAI의 BGE-base 모델은 768차원이지만, OpenAI ada-002(1,536차원)보다 MTEB 점수가 높다. 차원이 아니라 훈련 품질과 아키텍처가 성능을 결정한다는 뜻이다.

차원이 두 배면 비용도 두 배다

차원이 두 배가 되면 비용도 두 배가 된다.

저장 비용부터 보면, Float32 기준 벡터 하나의 크기는 차원 수 × 4 바이트다. 100만 개 벡터를 저장할 때 차원별 메모리는 다음과 같다.

차원	100만 벡터 메모리(Float32)
384	약 1.5G
1,536	약 6GB
3,072	약 12GB
4,096	약 16GB

검색 속도도 차원에 비례한다. 쿼리 벡터와 저장된 벡터 간 거리 계산은 O(N × D) 복잡도를 가진다. 차원(D)이 두 배면 계산량도 두 배다. 수백만 건 이상의 벡터를 다루는 환경에서는 무시할 수 없는 차이다.

모든 문서가 비슷하게 멀어진다

차원이 높아질수록 모든 점 간 거리가 비슷해지는 현상이 있다. 이를 고차원에서 거리가 무의미해지는 현상(차원의 저주, Curse of Dimensionality)이라 부른다.

저차원에서는 가장 가까운 이웃과 가장 먼 이웃 사이의 거리 차이가 뚜렷하다. 하지만 차원이 높아질수록 모든 점이 서로 비슷한 거리에 위치하게 되고, "가장 가까운 문서"를 찾는 의미가 흐려진다.

단, 임베딩 벡터는 실제로 저차원 다양체(Manifold) 위에 분포한다고 알려져 있다. 텍스트의 의미 공간 자체가 저차원이기 때문에, 고차원 벡터로 표현하더라도 실질적인 정보는 저차원 구조에 집중된다. 이론적 최악보다는 실무에서 양호하게 작동하는 이유다.

차원을 줄여도 성능을 지키는 법

마트료시카 표현 학습(MRL, Matryoshka Representation Learning)은 큰 임베딩 안에 작은 임베딩이 중첩된 구조로 모델을 훈련하는 방식이다. 러시아 전통 인형 마트료시카에서 이름을 따왔다.

앞쪽 차원일수록 더 중요한 정보를 담도록 훈련하기 때문에, 전체 벡터의 앞부분만 잘라 사용해도 품질이 크게 떨어지지 않는다. OpenAI의 text-embedding-3 시리즈가 MRL을 적용한 대표적인 모델이다.

text-embedding-3-large를 256차원으로 줄여 사용해도 이전 세대 모델 ada-002의 1,536차원보다 성능이 높다는 것이 OpenAI의 발표다. MRL 덕분에 비용과 성능 사이의 균형을 유연하게 조정할 수 있다.

아래 코드는 API에서 dimensions 파라미터로 차원을 직접 지정하는 예시다. 같은 모델을 쓰되 차원만 줄이면 저장 비용을 낮추면서 의미 품질은 상당 부분 유지할 수 있다.

from openai import OpenAI

client = OpenAI()

# 기본 1,536차원
full_emb = client.embeddings.create(
    input="배포 롤백 절차",
    model="text-embedding-3-small"
)

# MRL로 256차원으로 축소
small_emb = client.embeddings.create(
    input="배포 롤백 절차",
    model="text-embedding-3-small",
    dimensions=256   # 앞쪽 256차원만 사용
)

print(f"전체 차원: {len(full_emb.data[0].embedding)}")   # 1536
print(f"축소 차원: {len(small_emb.data[0].embedding)}")  # 256

차원 증가에 따른 성능(로그형 곡선)과 비용(선형 증가) 비교. 384차원에서 768차원 구간에서 성능 향상이 크고, 이후 성능 향상이 크게 둔화된다. 비용은 차원에 비례해 선형으로 증가하기 때문에, 768~1,024차원이 성능 대비 비용의 적정 구간으로 알려져 있다.

어떤 모델을 고를 것인가

MTEB 벤치마크 읽는 법

MTEB는 검색, 분류, 클러스터링, 재순위 등 다양한 태스크를 종합 평가한다. 종합 점수를 보면 전반적인 품질을 파악할 수 있지만, RAG를 만든다면 Retrieval(검색) 태스크 점수를 더 중요하게 봐야 한다.

한국어 문서를 다룬다면 MIRACL, MKQA 같은 다국어 벤치마크 점수도 확인하는 것이 좋다. 영어 기준 MTEB 점수가 높아도 한국어 성능이 낮은 모델이 있다.

상용 API 비교(2026. 03 기준)

모델	제공사	차원	MTEB 점수	가격 ($/100만 토큰)
text-embedding-3-small	OpenAI	1,536	62.3	$0.02
text-embedding-3-large	OpenAI	3,072	64.6	$0.13
gemini-embedding-001	Google	3,072	68.3	별도 과금
Cohere Embed v4	Cohere	1,024	65.2	$0.10
Voyage-3-large	Voyage AI	1,536	66.8	$0.06

오픈소스 모델 비교

모델	제공사	차원	MTEB 점수	라이선스
BGE-M3	BAAI	1,024	63.0	MIT
Qwen3-Embedding-8B	Alibaba	4,096	70.6	Apache 2.0
E5-Mistral-7B	Microsoft	4,096	66.6	MIT

Qwen3-Embedding-8B의 70.6은 2026년 3월 기준 오픈소스 모델 중 최상위 수준이다. 다만 8B 파라미터 모델을 자체 서빙하려면 GPU 인프라 비용과 운영 부담을 함께 고려해야 한다.

text-embedding-3-small을 선택하는 이유

처음 RAG를 구현하는 상황이라면 text-embedding-3-small을 권장한다. 세 가지 이유가 있다.

첫째, $0.02/100만 토큰이라는 가격은 경쟁 모델 대비 압도적이다. text-embedding-3-large와 비교해 약 6.5배 저렴하면서 MTEB 점수 차이는 2.3점에 불과하다. 근데 회사에서 구현한다면, 회사에서 지원 해주는 모델인지 확인부터 해보자. 내 경우엔 선택지가 많지 않았다.

둘째, 한국어 성능이 이전 세대 ada-002 대비 크게 향상됐다. MIRACL 한국어 벤치마크에서 ada-002 대비 두 자릿수 이상 향상됐다고 알려져 있다.

셋째, MRL 지원으로 256차원부터 1,536차원까지 자유롭게 조절할 수 있다. 프로토타입에서는 작은 차원으로 빠르게 실험하고, 프로덕션에서 필요한 차원으로 확장하는 방식이 가능하다.

프로토타이핑 과정에서 로컬 모델을 직접 돌려보기도 하고 OpenAI 모델을 사용해보기도 했다. 로컬 모델은 리소스를 너무 많이 차지해서 부담스러웠고, 임베딩 API 비용 자체가 그렇게 비싸지 않았기 때문에 결국 OpenAI를 선택했다. MTEB 같은 정량 지표와 다국어 지원 여부를 우선 기준으로 삼았다.(로컬에서 돌릴 땐 노트북 쿨러 소리 때문에 날아가는 줄 알았다..)

다만, 모델을 고르는 것보다 중요한 것이 있었다. 아무리 좋은 모델을 써도 문서의 품질 자체가 낮으면 검색 결과도 낮다. AI가 이해하기 쉬운 구조의 문서를 작성하는 것이 모델 선택보다 더 직접적으로 검색 품질에 영향을 줬다. 결국 임베딩 모델은 문서의 의미를 추출하는 도구일 뿐, 의미 자체는 문서에 있어야 한다.

마무리

wiki-rag를 만들면서 생긴 질문들에서 혼자 공부하다가 글을 발행하게 됐다. 앞으로 순차적으로 포스팅을 할텐데 청킹, 차원, 모델 선택까지 각 단계에서 선택이 필요하다는 것을 알게 됐다.

임베딩은 텍스트에 의미 좌표를 부여하는 기술이다. 그리고 그 좌표 위에 RAG 검색의 나머지가 세워진다. 어떤 LLM을 쓰느냐보다, 문서를 어떻게 자르고 어떤 임베딩 모델을 고르느냐가 검색 품질을 더 직접적으로 결정한다. 난 요즘 한 사람이 작성하는 문서가 아니라 다양한 사람이 다양한 도구(draw.io, mermaid...)를 사용해서 작성하는 문서를 어떻게 RAG에서 검색이 잘 되게 할 지 고민하고 있다.

차원에 대한 막연한 불안이 있다면 한 가지만 기억하면 된다. 좋은 모델은 낮은 차원에서도 충분히 강력하고, MRL로 차원을 줄여도 품질이 크게 떨어지지 않는다. 768~1,024차원에서 시작해서 실제 검색 결과를 보며 조정하는 것이 가장 실용적인 접근이다.

다음 단계는 검색된 청크를 얼마나 잘 쓰느냐다. 코사인 유사도 검색 이후에 Reranking을 적용하거나, 하이브리드 검색으로 키워드 기반 검색을 결합하는 방법이 실무에서 자주 쓰인다는 점을 알아두자.

카드 정지는 성공했는데, 고객에게 알림이 안 갔다고요? – MSA 환경의 설계 딜레마

CODe_ — Sat, 15 Mar 2025 17:26:47 +0900

나무위키 - 딜레마

금융 시스템에서 알림 발송 실패 시 어떻게 해야 할까?

금융권 시스템에서 카드 분실 및 정지 프로세스처럼 고객에게 필수 알림을 전달하는 상황이 있습니다.

최근 카드 결제 시스템을 설계하며 흥미로운 고민을 마주하게 되었는데요.

카드 도난 분실 신고 및 카드 정지 또는 해제와 같은 프로세스는 고객 보호와 금융 사고 예방을 위해 필수적으로 빠르게 처리되어야 하는 업무입니다.

또한, 고객에게 처리 결과에 대한 알림이 발송되지 않으면 금융 감독원 민원 등 중요한 규제 이슈로 이어질 수 있기에 알림의 중요성이 높습니다.

그런데 알림 발송을 처리하는 UMS는 별도의 시스템으로, 발송 성공을 항상 보장하지는 않습니다.

이럴 때 메시지 발송 실패가 메인 비즈니스 처리에도 영향을 줘야 하는지 고민하게 됩니다.

(ex. 중요한 알림이 발송 실패하면 비즈니스도 실패하게 할 것인가?)

왜 카드 정지 알림이 중요한 걸까?

카드 분실이나 도난 시, 고객은 매우 불안한 상황에 처합니다. 이때 카드가 즉시 정지되었다는 알림 메시지를 받으면 고객은 안심할 수 있죠.

만약 알림을 받지 못했다면 고객은 실제 카드가 제대로 정지되었는지 의심하게 되고, 결국 불안감 때문에 고객센터로 직접 전화하거나 민원을 제기할 가능성이 있습니다.

최악의 경우, 금융감독원 민원으로까지 이어져 회사 차원에서 부담이 되는 상황도 생길 수 있죠.

그렇기 때문에 금융권에서는 고객 알림을 단순한 안내 메시지가 아니라 고객과의 신뢰 및 규제 기관 대응이라는 중요한 문제로 바라봅니다.

메시지 발송 실패를 시스템 처리 실패로 봐야 할까?

실무를 하다 보면 이런 고민이 꽤 자주 발생합니다.

위에서 설명한 이유처럼 고객에게 메시지가 전달되는 것은 중요하기에 비즈니스가 실패했다고 봐야 하는 입장도 있죠.

반대로, 핵심 업무의 중요성을 고려하면 알림 발송 실패 때문에 카드 정지 처리 자체가 실패해서는 안 된다는 의견이 대다수일겁니다.

만약 메시지 발송 시스템 장애로 인해 카드가 즉시 정지되지 않으면, 훨씬 더 심각한 피해가 발생할 수 있기 때문이죠.

실제로 카드 도난 사고가 발생한 상황에서 메시지 발송 실패로 정지가 되지 않으면 고객의 피해뿐 아니라, 회사에 매우 큰 법적, 재정적 책임 문제로 돌아올 수 있습니다.

즉, 알림 발송 실패로 정지 프로세스 자체를 실패로 처리하는 로직은 오히려 더 큰 문제를 발생시킬 위험이 크죠.

이 문제는 결국, 업무 로직과 부가 로직의 결합도를 어떻게 관리해야 하는지에 대한 본질적인 문제로 바라볼 수 있습니다.

의견 충돌 사례

UMS 발송 관련 로직은 모든 클라이언트에서 필요한 부분이기에 공통 라이브러리에서 관리하고 있습니다.

그래서 이 주제로 공통 라이브러리(유틸 클래스)를 관리하는 두 동료의 견해 차이가 뚜렷했고 두 의견에 모두 공감되어 정말 난처했었습니다.

동료A

금융 시스템은 메시지 발송 실패 상황을 대비해야 한다
재발송 로직을 마련하고, 필요시 수동 발송까지 가능한 백오피스도 필요하다
금융감독원 민원 발생 시 소명 가능한 자료가 필요하기에 재처리를 했다는 것을 남겨두는 것이 중요하다

동료B

이 요구사항은 서비스마다 중요도가 달라 마이너한 문제다
발송 재시도 여부나 허용 지연 시간이 비즈니스마다 다르기 때문에 공통 라이브러리에 구현하면 복잡성이 증가한다(이미 너무 많은 것들을 공통화했기에 좀 더 신중해져야 한다)
모든 상황을 커버하기 위해 공통 유틸로 관리하면, 설정과 관리 비용이 지나치게 높아질 수 있다
알림 발송에 실패하면 실패한대로 두고 대응하면 된다

두 가지 입장 모두 현실적이고 합리적이라고 느꼈습니다.

먼저 동료A가 말한 내용은 현실적인 금융 시스템의 상황과 매우 밀접한 의견이었는데요.

금융 산업은 안정성과 신뢰성은 물론이고, 특히 규제기관(금융감독원) 대응이라는 비즈니스적인 문제까지 고려해야 하기에 재발송 로직과 백오피스를 준비해야 한다는 주장이 설득력 있다고 느꼈습니다.

반면 동료B가 말한 부분도 공감이 됐습니다. 공통 유틸이 너무 많은 부분까지 공통화하거나 지나치게 복잡해지면 결국 서비스마다 불필요한 옵션까지 고민하게 되는 오버헤드를 유발할 수 있으니까요.

실제로 모든 서비스를 하나의 공통 규격으로 해결하기 어렵고, 서비스마다 민감도와 긴급성이 다르기 때문에 공통화된 접근이 지나치게 복잡성을 높일 수도 있지요.

제 생각은, 업무 로직과 부가 로직을 철저히 분리하되, 최소한의 공통 대응을 가능하게 하는 구조로 결론 내는 게 가장 현실적이고 이상적인 설계라고 생각이 들었고 결국 이 문제는 기술적 설계 문제일 뿐만 아니라, 금융권 특유의 비즈니스 리스크 관리 측면에서도 중요하게 다뤄야 하는 이슈라는 생각도 들었습니다.

기존의 공통 유틸 상황과 현실적인 고민

현재 사용하고 있는 공통 유틸인 UmsSendUtil.send() 메서드는 메시지 발송을 1회만 간편하게 처리할 수 있게 제공하고 있습니다.

발송에 실패하면 클라이언트에서 간단한 예외 처리만 할 수 있도록 CheckedException을 구현하게 해두었어요.

만약 재처리까지 공통으로 지원하려면 복잡성이 크게 증가하게 되죠.

// 기존 공통 유틸 사용법
public void doSomething() {
  try {
    UmsSendUtil.send(message);
  } catch (UmsException e) {
    // 실패 시, 예외 처리
  }
}

만약, 재처리 옵션을 공통 유틸에서 제공해 준다면 아래와 같이 바뀔 수 있겠네요.

public void doSomething() {
  // 개선된 옵션 제공 예시
  UmsSendOptions options = UmsSendOptions.builder()
    .retryEnabled(true)             // 자동 재발송 여부
    .maxRetryCount(3)               // 최대 재발송 횟수
    .retryInterval(Duration.ofMinutes(1)) // 재발송 간격
    .alertOnFinalFailure(true)      // 최종 실패 시 담당자 알림
    .businessCritical(true)         // 업무 긴급성 설정
    .build();

  UmsSendUtil.send(message, options);
}

이렇게 옵션을 제공하면, 각 마이크로서비스(클라이언트)에서는 자신들의 업무 성격과 상황에 맞게 알림 발송 로직을 유연하게 선택할 수 있습니다.

하지만 동시에, 이러한 옵션 제공으로 인해 서비스별로 알림 발송 실패에 대한 고민의 폭이 더 넓어질 수도 있습니다.

이러한 고민들 말이죠.

재처리가 필요한 비즈니스인가?
몇 번 재시도할까?
수동 처리는 누가, 언제 하지?
재시도하게 되면 지연 발송이 될 수 있을 텐데, 지연발송 되어도 괜찮은가?

재처리 로직이 쉽지 않은 이유

동료B의 부담도 쉽게 공감할 수 있었던 이유가, UMS 발송 실패 시 재처리 기능은 간단해 보이지만, 실제로 아키텍처적으로는 생각보다 쉽지 않은 문제이기 때문입니다.

재발송 기능을 구현할 때 반드시 고민해야 하는 복잡성이 존재합니다.

가령, 재발송 기능을 구현하려면 어떤 방식으로든 메시지를 다시 처리할 수 있는 메커니즘이 필요합니다. 단순히 메소드 호출을 반복하면 자칫 시스템 부하나 장애 확산 위험도 생기기에, 보통은 메시지 큐나 이벤트 드리븐을 하게 됩니다.

하지만 아래와 같은 고민을 필수적으로 거쳐야만 합니다.

원자성을 보장하려면 어떻게 해야 할까?
이벤트가 유실되지 않게 하는 방법은 뭐가 있을까?
재처리를 시도하다가 장애가 발생하면 해당 이벤트는 어디다 쌓아야 할까?

그래서 아웃박스 패턴도 사용해 볼 것이고, 에러 로깅이나 담당자가 즉각 대응할 수 있도록 알림 프로세스도 설계해야 하죠.

이러한 기술적이고 아키텍처적인 운영적인 고민들이 동반되기에, 재처리 기능은 단순히 "옵션 하나 추가"의 문제가 아니라 시스템의 복잡성 증가로 이어질 수 있다는 점을 분명히 인지해야 합니다.

(주된 주제는 아니기에 여기서는 짧게 설명했지만 하나하나 규모가 큰 것들이죠..)

제 생각은요

지금까지 이야기를 기술적 관점으로만 좁혀서 바라보면, 발송 실패 시의 재처리, 장애 대응과 같은 기술적인 접근에만 머무를 수 있습니다.

하지만 좀 더 넓은 시각에서 바라보면 기술적 고려 이전에 더 중요한 아래의 질문들을 던져야 합니다.

이 알림 발송 재처리 기능이 과연 우리 비즈니스에 정말로 중요한가?

왜냐면 각 마이크로서비스마다 제공하는 업무의 성격과 중요도가 근본적으로 다르기 때문이죠.

첫째, 이 알림 메시지는 정말 긴급한 업무인가?
예컨대 카드 도난 분실과 같이 즉각적인 처리가 중요한 경우에는 재처리와 즉시 알림이 필요합니다. 그러나 단순히 안내성 메시지라면 재발송이 필요하지 않을 수 있습니다.
둘째, 발송 실패 시 업무를 중단할 만큼 중요한 메시지인가?
만약 발송이 지연되는 경우 더 큰 피해를 초래할 위험이 있다면 재처리 로직이 필수겠죠. 하지만 마케팅 메시지와 같은 알림은 단순히 실패로 끝내도 업무에 큰 영향이 없습니다.
셋째, 지연 발송이 허용 가능한가? 허용한다면 얼마나?
긴급성이 높은 알림은 1분 이내 재발송을 요구할 수 있지만, 그렇지 않은 업무는 몇 시간 이후 발송되어도 문제가 없을 수 있습니다. 지연 발송을 허용할 수 있는 기준이 명확히 정의되어야 합니다.

결국 더 넓은 관점에서는 모든 서비스를 하나의 기술적 해결책으로 접근하는 것이 아니라, 서비스마다 메시지 발송 실패가 미치는 비즈니스적 영향과 민원 대응 가능성, 고객 만족도와 리스크 수준까지도 모두 함께 고려하여 최적의 설계를 결정해야 합니다.

정리하자면, 업무 프로세스는 명확하게 핵심 로직과 부가 로직을 나누고, 공통 유틸에서는 최소한의 옵션과 로그를 제공하는 방식으로 지원해야 한다고 생각합니다.

즉, 공통 유틸에서 재처리 옵션을 제공하는 이유는 기술적 편리함 때문이 아니라, 각 서비스가 자신들의 비즈니스 성격과 현실적인 요구사항에 따라 메시지 처리 방식을 자유롭게 선택하고, 그 결과에 책임질 수 있게 하기 위함입니다.

마무리

실무를 하다 보면 이와 같은 딜레마(트레이드오프) 상황에 종종 노출되곤 합니다.

이 글에서 말씀드리고 싶었던 것은, 작은 기술적 이슈가 결국 프로젝트 전체의 비즈니스 리스크나 고객 신뢰도 문제로 확대될 수 있다는 것이며, 중요한 건 기술적 완벽성이 아니라, 기술이 비즈니스에 어떤 가치를 줄 수 있는지를 명확히 바라보는 넓은 시각이죠.

종종 기술에만 매몰되는 제 자신을 보며 아직 갈 길이 멀다는 것을 체감합니다.

이번 글이 여러분이 시스템 설계 시 더 넓은 시야와 현실적인 판단력을 가질 수 있도록 작은 도움이 되었으면 좋겠습니다.

영어 공부하다 딴짓하기

CODe_ — Sun, 2 Mar 2025 22:19:22 +0900

출처 픽사베이

프롤로그

2025.02.02 - [Degrees] - 심장뛰는 석사 입학 준비

심장뛰는 석사 입학 준비

프롤로그: 인생에서 석사라는 학위가 필요할까?저는 공부에 흥미도 없었고 딱히 잘하지도 못했습니다. 겨우 대학에 진학하고 나서야 공부에 재미를 느끼기 시작했고, 제가 좋아하는 분야가 무

imksh.com

위 글에 이은 두번째 글입니다. 어느덧 영어를 준비한 지 1개월이 되었고, 그동안 느낀 솔직한 후기를 남겨봅니다.

또한, 개발자가 영어 공부를 하면 이 능력을 어떤식으로 활용하는지 들려드리겠습니다.

토플 준비에 관심이 있거나, 그저 개발자가 영어 공부 할 때 어떤 식으로 능력을 활용하는지 궁금하신 분들께 후루룩 읽기 쉬운 글이 되길 바랍니다.

다시 바빠진 일상

토플 현강에 1개월 동안 참여했고, 월/수/금 강남에 위치한 영어 학원을 다니고 있습니다.

학원을 가는 날엔 오후 6시 20분쯤 퇴근하여 오후 7시에 시작하는 수업에 참여합니다. 그리고 10시쯤 수업이 끝나면 집으로 돌아가 늦은 저녁을 먹습니다.

평소 같았으면 야근을 하고 퇴근할 시간인데, 그 시간 동안 영어 수업을 듣다 보니 업무에 쏟는 시간이 줄어들었어요.

절대적으로 투자하는 시간이 줄다보니, 업무에 대한 압박이 높아졌고 학원을 가지 않는 날에 더 몰입해서 일하기도 하고 더 오래 야근을 하기도 합니다. 하지만 여전히 시간이 부족해서 주말을 활용해서 업무를 해야겠다는 생각을 했습니다.

또한 출근, 퇴근 길, 화장실에 머무르는 시간에 항상 휴대폰으로 단어를 외우기 시작했습니다.

인스타그램과 같은 SNS 앱에 사용제한을 걸어두고 일상생활에 영어를 공부하는 비중을 올려갔어요.

일상 스케줄 표

주말에는 미뤄진 일들을 처리해야 합니다. 블로그 글도 써야 하고, 커뮤니티 운영, 회의, 커피챗, 헬스 등 평일에 소화하지 못한 일들을 쳐내기에 바쁘죠.

주변 동료들은 저를 보고 "고시생"이라고 부르기 시작했습니다. 시도 때도 없이 계속 단어를 외우고 있거든요.

학원 수업은 어땠나?

수업 후기

솔직히 첫 수업부터 막막함을 느꼈습니다. 이미 기초(문법)가 되어 있다는 가정 하에 진행된다는 느낌이 강했어요.

또한 회사에서 출발하기 전 10~15분 정도 간식을 섭취하고 수업을 듣는데, 졸음이 밀려와 화가 날 때도 있었습니다.

명확한 목표가 있어서 그런지, 스스로 조는 모습을 마주할 때면 수업에 집중하지 못해서 답답했거든요.

토플은 총 4과목으로 구성되어 있습니다.

토익과 동일하게 Reading, Listening을 비롯해 Speaking, Writing 과목도 있습니다.

Speaking, Writing 과목이 단순히 말하고 쓰는 것이 아니라 Reading과 Listening 실력이 뒷받침되지 않으면 무조건 실패할 수밖에 없다고 생각됐어요.

말하기 위해 수십줄의 지문을 읽어야 하고, 그 지문을 기반으로 토론하는 두 사람의 대화를 듣고, 말을 하거나 글로 써야 하거든요.

영알못인 제겐 "와.. 이걸 어떻게 해..?"라는 생각이 들게 했습니다.

그리고 5분이 넘어가는 리스닝을 듣다 보면 집중력이 흐려지고 정신이 혼미해지기 시작합니다..

그래도 선생님께서 재밌게 수업을 해주셔서 중간중간 몰입되게 만들어 주셨어요. 농담하는 시간마저도 수업에 포함된 것처럼 스토리텔링이 되었고, "역시 1타 강사는 다르구나"라는 생각이 들었어요.

수강생 나이대

연령대는 얼핏 액면가로 봤을 땐, 제가 제일 나이가 많아 보였어요.

다들 대학생 느낌이 물씬 났습니다.

각자의 다른 목표와 이유로 학원에 왔겠지만, 상대 평가로 점수를 매기는 과목에선 모두 경쟁자이기에 제 승부욕을 자극하기도 했습니다.

그리고 저는 부모님 돈이 아니라 제 돈으로 결제했잖아요? 제가 제일 강할 겁니다.

개인 공부

개발자가 개발이나 해야지

단어 암기 페이지 제작

학원에서는 매일 50개의 영어단어 시험을 치릅니다.

[영어단어 - 뜻]으로 구성된 단어장을 보고 단어와 뜻을 외우기만 했었는데요, 시대가 변한 건지 토플이 이런 건지는 모르겠으나 아래 사진처럼 [영어단어 - 뜻 - 유사어] 형태로 구성된 단어장이었습니다.

단어 시험은 문제에 나오는 영어 단어만 보고 유사한 뜻을 가진 영어단어를 고르는 방식으로 시험을 칩니다.

학창 시절에는 그냥 선생님이 제공해 주는 단어장을 보고 쓰고, 말하고, 눈으로 보며 단어를 외웠어요.

하지만 하나의 영어 단어에 엮여있는 모든 유사어를 다 외웠는지 스스로도 알기 어려웠기에 빠르게 외울 수 있고, 확실하게 외울 수 있는 나만의 단어 외우는 방식이 필요했어요.

지금은 어엿한 개발자가 되어 간단한 웹페이지 정도는 AI를 이용해 20분이면 배포까지 할 수 있는 시대가 되었죠.

그래서, "단어를 효율적으로 외우는 페이지를 만들자"라는 생각을 합니다.

별다른 설계 없이 아래처럼 무작정 페이지를 만들었어요.

유사어를 외우기 위한 웹페이지 제작

실제 단어 시험처럼 4지선다 중에서 유사한 단어를 고르는 페이지를 만들었어요.

근데, 스스로 기능을 테스트하며 신기한 점이 있었습니다. 처음 보는 단어의 경우, 해당 영어 단어를 먼저 보지 않고, 본능적으로 의미를 보고 정답을 선택하더라구요.

그래서 첫 사이클은 한글 뜻과 영어 단어를 매칭시키는 암기를 진행하게 됩니다.

오답인 경우 정답이 노출됨

오답의 경우 정답이 노출되고 그 단어를 한번 더 기억할 수 있게 구현했습니다.

정답을 한 번 맞힌 단어라면 두 번째 사이클로 들어가게 되는데요, 두번째 사이클에는 한글 뜻이 노출되지 않도록 만들었어요.

두번째 사이클은 한글 뜻이 노출되지 않음

그럼 영어 단어만 보고 유사한 단어를 선택해야 하죠.

이렇게 두 번째 사이클까지 정답을 맞히면 그 단어는 초기화하기 전까지 더 이상 노출되지 않습니다.

암기 프로세스

그래서 여러 테스트를 거친 후, 이러한 프로세스로 정착하게 하게 됩니다.

영어단어 암기 프로세스

외운 단어는 먼저 암기 완료 사이클로 진입하여 더 이상 노출되지 않게 되고, 외우지 못한 단어는 계속 첫 번째 또는 두 번째 사이클에 남게 되겠죠.

구현과 배포는 어떻게?

개발자라면 가장 궁금해할 부분이 아닐까 생각이 됩니다.

Python3, Flask, Html/CSS, Javascript를 활용했고, 뼈대가 되는 스켈레톤 코드는 ChatGPT 4o를 활용했습니다.

배포의 경우 vercel을 이용했고 github에 커밋푸시를 하게 되면 vercel에 자동 배포하는 파이프라인입니다.

커밋 룰, 클린코드.. 등 다 좋지만 누군가에게 공개할 것도 아니고, 극한의 시간 활용을 위해 이런 부분까진 신경쓰지 않기로 했습니다.

단어 페이지 Github

형상 관리는 Github에서 private-repository로 관리하고 있구요.

욕심내서 신기능을 적용하다가 버그가 발견되어 롤백하기도 했습니다.

개인적으로 영어 발음을 해주는 기능이 정말 좋았는데요. 아래와 같은 코드를 구현했습니다.

function playPronunciation(word) {
    const utterance = new SpeechSynthesisUtterance(word);
    utterance.lang = 'en-US';
    speechSynthesis.speak(utterance);
}

    // ✅ 페이지 로드 시 자동으로 유사어 발음 실행
window.onload = function() {
    setTimeout(function() {
        playPronunciation('{{ question.synonym }}');
    }, 300); // 0.3초 딜레이 후 실행
};

토플은 스피킹 과목도 있기 때문에 영어 발음도 중요한데요, 처음 보는 단어를 읽을 때 잘못 발음하여 외울 수 있는데 위 코드를 이용해 영어 발음을 들으며 암기할 수 있었습니다.

단어가 노출될 때, 보기에 나와있는 단어 버튼을 클릭했을 때, 의도적으로 발음 버튼을 눌렀을 때 해당 함수를 호출하여 영어 발음을 들려줍니다. 개인적으로 정말 마음에 드는 기능 중 하나라고 생각합니다.

하나 귀찮은 점은 아직 스프레드파일을 직접 추출해서 repository에 넣어줘야 한다는 점입니다.

시간적 여유가 생기면, 스프레드시트 API를 활용해 입력한 값을 읽어와 처리할 생각입니다.

그럼 저는 단어를 스프레드시트에 입력하기만 하고 특정 API를 호출해 단어 목록을 다시 읽어오기만 하면 되겠죠.

다시 구현한다면?

Python, Flask 없이 그냥 html, css, javascript만 활용할 것 같습니다.

꼭 서버를 띄우지 않아도 정적 파일만으로 작동시키는 거죠.

지금은 Flask를 이용하고 있고, 최소한의 서버 통신을 하고 있긴 하지만..

가끔 연결이 끊기면 다시 로딩하는 부분이 불편하다고 느꼈습니다.

특별히 거창한 기능이 없기에 기존 기능을 javascript만으로도 대체할 수 있을 것 같네요.

하여간, 개발자들이란..

개발자들이란..

제가 이 페이지를 만들었을 타이밍에 저와 함께 토플을 준비하고 계시는 분도 똑같이 뭔갈 만들었더라구요.

토플 Writing 과목을 위한 훈련 페이지

Python, Streamlit을 이용해 빠르게 UI를 구성하고 기능을 만드셨습니다.

토플 Writing에서는 사용한 단어 갯수도 중요한데요, 보통 150개 이상의 단어를 사용해야 하기에 내가 작문할 때 몇 개의 단어를 사용했는지 카운팅 하는 기능과 문제를 랜덤 하게 출제하는 기능을 구현하셨어요.

또한 시간도 중요하기에 타이머 기능을 함께 넣어 실제 시험과 같은 환경에서 훈련할 수 있도록 디테일한 구현을 해뒀습니다.

둘 다 똑같은 이야길 했는데, 역시 영어보다 개발이 더 재밌다는 말을 남겼습니다.

부족한 어휘력 보충하기

학원에서 시험을 위한 단어를 외우고 있긴 하지만, 저는 더 많은 어휘를 습득해야 한다고 생각했습니다.

그래서 말해보카라는 어플을 사용하며 프리미엄 회원을 결제했고 매일매일 단어를 습득하고 있습니다.

이 어플에 대한 설명은 이미 너무나 많은 글이 있고, 글을 보는것보다 체험판 기간을 활용해 직접 사용해보는 것을 권장드립니다.

백번 말로 듣는 것 보다 직접 해보는 게 빠를 거예요.

말해보카 4인팟 추천드립니다

말해보카 어플에는 사용자의 학습 데이터 기반으로 다양한 시각 자료를 보여주는데요.

아래 사진처럼 제 어휘력이 어느 정도인지 보여주기도 합니다.

어휘력은 실제 영어 실력과 무관합니다

토플을 공부하면서 가장 크게 느낀 것은, 단순히 어휘를 암기했다에서 끝나는 게 아니라 직접 입 밖으로 그 단어를 내뱉어야 한다는 것입니다.

그냥 암기만 해두면, 그 단어를 리딩이나 리스닝할 때 이해할 수야 있겠지만 작문을 하거나 스피킹을 할 때는 전혀 활용하지 못한다는 치명적인 약점이 있었거든요.

그래서 한글로 된 문장을 보고, 내가 번역가가 됐다는 느낌으로 영어 문장을 내뱉는 것을 계속 연습하고 있습니다.

마무리

영어 공부를 빙자한 개발자들의 토이 프로젝트 아티클일지도 모르겠네요.

아무튼, 개발을 전혀 몰랐더라면 지금처럼 효율적으로 공부하지 못했을 것 같습니다.

업무와 동시에 학원도 다니고 과제에 치여 살다 보니, 곧 번아웃이 올 것 같은 조짐이 보이네요.

직접 문제를 풀다 보니 이거 2개월 준비로는 어림도 없겠다는 생각이 듭니다.

주변 이야기를 들어보니 유학을 다녀오셨거나, 이미 영어가 익숙하신 분들은 짧게는 며칠, 길게는 한 달 정도 공부하면서 100점 이상을 받았다고 하더라구요.

둘 다 해당되지 않는 제겐 최소 4개월은 필요하겠다고 생각이 들었습니다.

그리고 제일 어려운 것은 멘탈싸움이라고 생각합니다.

계속 공부하며 체력적으로 정신적으로 지치다 보니, "내가 석사를 그렇게 원했던가?" 하는 생각도 문득문득 들곤 합니다.

해보고 후회하는 것이
안해보고 후회하는 것보다 낫다

그냥 딱 이 말만 다시 새기고, 오늘 하루도 힘겹게 넘겨보려 합니다.

제네릭이 작동하지 않는다

CODe_ — Sat, 15 Feb 2025 14:24:53 +0900

출처 픽사베이 - 글과 관련 없음

해당 글에서 등장하는 코드는 Github에서 확인할 수 있습니다.

playgroundddd/notifier at main · CODe5753/playgroundddd

sample. Contribute to CODe5753/playgroundddd development by creating an account on GitHub.

github.com

프롤로그

개발을 하다 보면 제네릭(Generic)과 다형성(Polymorphism)을 자연스럽게 조합해 사용하게 됩니다.

특히, Spring 환경에서는 제네릭을 사용한 의존성 주입(DI)을 활용하여 다양한 객체를 동적으로 주입할 수 있는데요.

하지만 여기에는 예상치 못한 제네릭과 런타임 타입 매칭의 충돌이 발생할 수 있습니다.

이번 글에서는 실무에서 겪었던 일이며, "Notifier라는 인터페이스를 제네릭하게 만들었는데, 왜 자식 DTO를 처리하지 못할까?"라는 문제를 해결하는 과정을 살펴보면서, 유연한 설계를 어떻게 할 수 있는지 고민해 볼 수 있습니다.

이번 아티클은 아래 독자에게 유용할 수 있습니다.

Spring Boot에서 타입 기반 매칭을 활용하는 분
유지보수성이 높은 코드 구조를 고민하는 분

정확한 타입 매칭과 유연한 타입 매칭의 차이를 이해하고, 적절한 구현 방식을 선택하는 과정을 배우고 싶은 분들에게 추천합니다.

문제상황

문제가 발생했던 AS-IS 코드

카드 결제가 발생하면 받는 문자메세지

위 사진처럼, 고객의 결제가 발생하고 결제가 완료되면 완료되었다는 알림을 고객에게 보내는데요.

이 때 결제 방식이나 기능에 따라 UMS인지 어플을 통한 알림인지가 달라집니다.

UMS(Unified Messaging System)는 통합메시징 서비스를 뜻합니다. SMS, MMS, 이메일, 카톡 알림 등을 포함하여 이야기합니다.

코드를 하나씩 살펴볼게요.

제네릭을 이용한 Notifier 인터페이스와 구현체

public interface Notifier<T> {
    void send(T request);
}

이 인터페이스는 특정 타입의 DTO를 처리하는 역할을 합니다.

결국 고객에게 UMS던 앱 알림이던, 알림을 보내는 기능을 구현하려는거라 Notifier라는 인터페이스와 발송이라는 기능을 명시해 두었습니다.

알림을 보내기 위한 DTO는 자체적으로 구현하는 것이 아니라 라이브러리에서 제공받아 사용하기 때문에 유연한 구조 설계가 필요했거든요.

알림을 보내는 구조가 다른 새로운 DTO가 추가되더라도 구현체만 구현하기 위함이었습니다.

@Slf4j
@Component
public class UmsNotifier implements Notifier<UmsReqDto> {

    @Override
    public void send(UmsReqDto request) {
        log.info("[UMS Notifier] Sending message: " + request.getMessage());
        // 문자 발송 로직
    }
}

@Slf4j
@Component
public class AppNotifier implements Notifier<AppNotiReqDto> {

    @Override
    public void send(AppNotiReqDto request) {
        log.info("[App Notifier] Sending message: " + request.getMessage());
        // 앱 알림 발송 로직
    }
}

위처럼 구현해 두면, UMS 발송을 위해서는 Notifier의 구현체를 호출하지 않아도 됩니다.

메서드 파라미터로 넘기는 객체의 타입에 따라 알아서 클래스가 지정이 될 거거든요.

아래에 코디네이터를 보여드리면서 설명을 이어갈게요.

Notifier 빈을 주입해서 호출해 주는 유연한 코디네이터

@Component
public class NotifierCoordinator {
    private final Map<Class<?>, Notifier<?>> notifierMap;

    // 빈에 등록된 Notifier 구현체를 Map에 등록
    public NotifierCoordinator(List<Notifier<?>> notifiers) {
        this.notifierMap = notifiers.stream()
                .collect(Collectors.toMap(
                        this::getGenericType, // 제네릭 타입 자동 추출
                        Function.identity()
                ));
    }

    @SuppressWarnings("unchecked")
    public <T> void send(T request) {
        Notifier<?> notifier = notifierMap.get(request.getClass());

        if (notifier != null) {
            Notifier<T> selectedNotifier = (Notifier<T>) notifier;
            selectedNotifier.send(request);
            return;
        }

        throw new IllegalArgumentException("No suitable notifier found for " + request.getClass().getSimpleName());
    }

    
    private Class<?> getGenericType(Notifier<?> notifier) {
        // Notifier의 제네릭 타입을 가져옴
    }
}

NotifierCoordinator는 다양한 DTO 타입을 처리할 수 있도록 Notifier를 동적으로 매칭하는 역할을 합니다.

DTO 타입에 관계없이 Notifier를 찾아 실행할 수 있는 구조에요.

실제 사용은 이렇게

등록된 Dto라면 아래 코드처럼 코디네이터의 send만 호출하면 서비스 코드에서는 어떤 Notifier를 호출해야 하는지 신경 쓰지 않아도 됩니다.

@Slf4j
@Service
@RequiredArgsConstructor
public class PaymentService {

    private final NotifierCoordinator notifierCoordinator;

    public void payment() {
        log.info("payment method");

        // Do something...

        notifierCoordinator.send(new UmsReqDto("memberId", "message"));
    }
}

문제 발생: 라이브러리의 업데이트, 그리고 새롭게 생성된 DTO

어느 날, 평화로운 오후였던 것 같아요..

알림 발송을 위한 DTO는 자체적으로 구현하는 것이 아니라 라이브러리에서 구현되어 오는 것이라 말씀드렸는데요, 얼마 전 새로운 DTO가 추가되며 새로 애플리케이션을 구동할 때 런타임 에러가 발생했습니다.

바로, UmsReqDto를 상속받는 자식 클래스가 등장했거든요.

public class SmsReqDto extends UmsReqDto {
    public SmsReqDto(String message, String recipient) {
        super(message, recipient);
    }
}

public class EmailReqDto extends UmsReqDto {
    private String emailSubject;

    public EmailReqDto(String message, String recipient, String emailSubject) {
        super(message, recipient);
        this.emailSubject = emailSubject;
    }

    public String getEmailSubject() {
        return emailSubject;
    }
}

"코디네이터에서 부모인 Notifier<UmsReqDto>를 잘 찾아줄테니 작동 잘 되겠다~" 라고 생각했었으나, 사실 그렇지 않았습니다.

클라이언트에서 SmsReqDto를 사용하는 코드만 구현하고 앱을 구동했으나 Notifier에서 빈을 찾지 못하는 문제가 있어 앱 자체가 실행이 안됐습니다.

문제 분석

왜 Notifier<UmsReqDto(부모)>가 Notifier<SmsReqDto(자식)>를 처리하지 못할까?

자식 객체니까 당연히 처리되어야 하지 않나.. 라고 생각했고 제네릭의 공변&불변 문제인가? 라고 생각했었지만, 이건 크게 연관 없는 개념이었고, 결국 아래와 같은 이유라는 것을 알게 되었습니다.

Map<Class<?>, Notifier<?>>의 키 조회 방식

현재 코디네이터의 notifierMap에서 클래스 타입(Class<?>)을 키로 사용하고 있기 때문에,
자식 클래스가 부모 클래스로 처리되려면 부모-자식 관계를 고려한 탐색을 해야 하지만, Map.get()은 정확한 키 매칭만 수행하기 때문에 실패하는 거였어요.

notifierMap.get(request.getClass()); // 정확한 매칭만 가능 (부모-자식 관계 인식 불가)

코디네이터에는 위와 같은 코드로 클래스를 찾아서 가져오고 있었습니다.

정리하자면,

➡ SmsReqDto.class와 UmsReqDto.class는 Map<Class<?>, ?>에서 별개의 키로 취급됨
➡ SmsReqDto.class로 조회하면 UmsReqDto.class 키에 매핑된 Notifier를 찾을 수 없음

즉, 유연성이 부족한 원인은 정확한 타입 매칭만 허용했기 때문이라고 볼 수 있어요.

코드 개선

부모-자식 관계의 클래스도 허용되도록 코드를 변경하여, 유연성을 확보해야겠다는 결론을 내렸습니다.

아래처럼 코드를 변경해 줬어요.

@Slf4j
@Component
public class NotifierCoordinator {

    // 생략

    @SuppressWarnings("unchecked")
    public <T> void send(T request) {
        for (Map.Entry<Class<?>, Notifier<?>> entry : notifierMap.entrySet()) {
            if (entry.getKey().isAssignableFrom(request.getClass())) {
                Notifier<T> selectedNotifier = (Notifier<T>) entry.getValue();
                selectedNotifier.send(request);
                return;
            }
        }
        throw new IllegalArgumentException("No suitable notifier found for " + request.getClass().getSimpleName());
    }
    
    // 생략
}

isAssignableFrom()의 동작 방식

isAssignableFrom() 메서드는 클래스 간의 상속 관계를 활용하여 타입을 비교하는 기능을 제공합니다.

System.out.println(UmsReqDto.class.isAssignableFrom(SmsReqDto.class)); // true
System.out.println(SmsReqDto.class.isAssignableFrom(UmsReqDto.class)); // false

A.class.isAssignableFrom(B.class)는 B가 A의 하위 클래스라면 true를 반환하는 것이죠.

즉, UmsReqDto.class.isAssignableFrom(SmsReqDto.class)는 true가 되어 SmsReqDto를 UmsReqDto의 Notifier로 매칭할 수 있는 거죠.

결론

이번 개선을 통해, 타입 매칭을 보다 유연하게 만들면서도 유지보수성을 높이는 방향으로 수정할 수 있었습니다.

비교 항목	정확한 타입 매칭	유연한 타입 매칭
요청 객체 타입	Map.get()으로 정확히 일치하는 타입만 조회	isAssignableFrom()을 사용하여 부모-자식 관계까지 탐색
자식 클래스 지원	❌ (자식 클래스는 부모 Notifier를 찾을 수 없음)	✅ (부모 Notifier를 사용할 수 있음)
성능	O(1) 조회 (빠름)	O(N) 탐색 (느릴 가능성 있음)
유지보수성	제한적 (각 타입별 Notifier가 필요)	유연함 (부모 타입 Notifier로 범용 적용 가능)

성능적 관점에서는 사실 서비스에 영향을 줄만한 정도는 아니어서 크게 고려하진 않았습니다.

결국, 수많은 사람과 협업하고 하나의 레포에서 코드를 구현하는 입장에서, 의도한 DTO에 맞게 코디네이터에서 Notifier를 유연하게 찾으면 되는 것이고, Notifier가 올바른 메시지를 발송하기만 하면 되니까요.

지금 제 업무는 같은 회사 개발자뿐 아니라, 다양한 회사의 개발자(SI 업체)와 협업하고 있어요.

Java, SpringBoot가 생소한 동료들부터 개발보다는 도메인 지식이 뛰어난 분들도 계시거든요.

이런 환경에서는 구체적으로 "이 땐 이걸 호출하세요 저 땐 저걸 호출하세요"라는 가이드를 드리는 것보다, "DTO만 명시해두고 그냥 호출하세요!" 라고 하는 것이 문제가 발생해도 제가 직접 제어하기도 쉽고, 앞단 비즈니스에만 집중해서 구현할 수 있도록 환경을 마련해 주는 것이 프로덕트 런칭을 위해 빠른 길이라는 생각을 했습니다.

이번 개선을 통해 단순히 코드의 동작 방식만이 아니라, 협업 환경에서 유지보수성과 확장성을 어떻게 고려해야 하는지도 다시 한번 고민해볼 수 있었던 계기였습니다.

석사 각

CODe_ — Sun, 2 Feb 2025 00:00:20 +0900

출처 픽사베이

프롤로그: 인생에서 석사라는 학위가 필요할까?

저는 공부에 흥미도 없었고 딱히 잘하지도 못했습니다. 겨우 대학에 진학하고 나서야 공부에 재미를 느끼기 시작했고, 제가 좋아하는 분야가 무엇인지 알게 되며 흥미가 생겼어요.

그러나 대학생때도 학문 자체를 이해하고 공부하기 보다는 성적 따내기에 급급해서 요령대로 암기하고 공부하고를 반복해서 결국, 나쁘지 않은 학점으로 졸업하게 됩니다.

처음 석사를 고민했던 건 2020년이었습니다. 졸업을 앞두고 더 깊이 공부하고 싶은 마음이 들었지만, 머릿속 계산기가 자동으로 돌아가기 시작했어요. 취업이 늦어지면 돈을 버는 속도도 느려질 테고, 사회에 나가는 시기도 늦어지고, 결혼도, 커리어도, 계획했던 삶의 흐름도 달라질 수 있겠다는 생각이 들었습니다.

그래서 현실적인 선택을 했습니다. 공부보다 일을 택했고, 석사보다는 경력을 쌓는 길을 걸어갔어요. 그리고 시간이 지나면서 알게 됐습니다. 선택을 미뤘다고 해서, 고민이 사라지는 건 아니라는 걸요.

시간이 지나면서 제 가치관도 변했습니다. 타인과 비교하는 삶보다는 그냥 내가 원하는 삶을 살기로 말이죠.

석사라는 학위가 제 삶에 얼마나 큰 영향을 미칠지 모르겠습니다. 시간도 노력도 들어가겠지만 그런거 신경 안쓰고 그냥 하고싶으니까 하기로 했습니다.

이 아티클까지 걸어오신 누군가를 이해시키고 납득시키고 싶지만.. 이번 글에서 만큼은 시작하게 된 논리가 없을 수도 있겠네요.

살다 보면 그런 순간이 있지 않나요? 이게 득이 될지 실이 될지 그런 계산적인 사고를 하기도 전에 그냥 몸이 이끌려서 하는것들요.

저는 적어도 지금 이 과정이 저한테는 그렇게 느껴집니다.

앞으로의 시리즈로 작성되는 아티클들은, 단순히 제 여정이 궁금하신 분들을 비롯해서 꼭 석사가 아니더라도 가슴뛰는 일들을 두고 어떻게 해야할지 고민중이신 분들께 조금이나마 희망과 열정을 줄 수 있는 글이 될 수도 있겠습니다.

지금이 맞는 타이밍일까?

석사를 하기로 결심한 순간, 모든 게 명확해질 줄 알았습니다. 그런데 현실은 그렇지 않았습니다. 마음을 정했지만, 여전히 고민은 남아 있었습니다.

이 선택이 정말 내 인생에 의미가 있을까?

살면서 중요한 결정을 할 때마다 불확실성은 따라오기 마련입니다. 그리고 불확실성이 커질수록 ‘지금이 과연 맞는 타이밍일까?’라는 고민은 점점 더 커졌습니다.

가장 큰 걱정은 "시간" 이었습니다. 석사를 시작하면 최소 2~3년은 투자해야 하는데, 하루하루가 빠듯한 일상 속에서 공부를 위한 시간을 따로 확보할 수 있을지 자신이 없었습니다. 결국 퇴근 후나 주말을 활용해야 하는데, 그러다 보면 지칠 수도 있을 것이고, 끝까지 해낼 수 있을까 하는 불안도 컸습니다.

‘이걸 하는 게 맞을까?’라는 생각이 들 때마다, 반대로 ‘하지 않으면 어떨까?’라는 질문도 던져봤습니다. 석사를 하지 않는다면, 저는 지금처럼 현실과 타협하며 바쁜 일상 속에서 틈틈이 공부를 이어갈 것입니다. 하지만 그렇게 쌓아가는 배움은 체계적이지 않고, 제한적인 경험에 머물러 있을지도 모릅니다. 그리고 몇 년 후, 저는 여전히 같은 고민을 하고 있을 가능성이 높았습니다.

시간 외에도 현실적인 고민은 또 있었습니다.

이 과정이 나에게 실질적인 도움이 될까?

커리어적으로, 기술적으로, 혹은 삶의 방향에서 석사가 주는 이점이 확실할까? 석사 학위가 곧바로 제 가치를 증명해 주지는 않을 것입니다. 하지만 한 가지 확신할 수 있는 점은, 이 과정 자체가 저를 성장하게 만들 것이라는 사실이었습니다. 한국이라는 환경을 벗어났기에, 새로운 환경에서 배우고, 도전하고, 고민하는 경험이 쌓이면 결국 저의 깊이가 달라질 것이라 믿고 있습니다.

그렇게 다시 한 번 고민 끝에 내린 결론은 단순했고, 완벽한 타이밍은 없다는 것을 알게 되었습니다. 어떤 도전에서도 늘 불안하고, 부족하고, 망설여지기 마련입니다. 하지만 중요한 것은, 그럼에도 불구하고 한 걸음 내딛는 것입니다.

가장 큰 걸림돌: 어학성적

가장 먼저 해야 할 일은 지원 요건을 확인하는 것이었습니다. 저는 미국의 조지아 공대 OMSCS 과정을 목표로 삼았고, 학부 전공자라면 비교적 수월하게 지원할 수 있는 프로그램이지만, 외국인 지원자에게는 영어 성적이라는 필수 조건이 있었습니다.

그 기준은 토플(TOEFL) 100점인데요, 숫자로 보면 단순한 기준일지도 모르지만, 저에게는 꽤 큰 벽처럼 느껴졌습니다.

사실 저는 영어를 그리 잘하는 편이 아닙니다. 학창 시절에는 시험을 위한 공부를 했고, 실무에서 영어를 쓸 일도 거의 없었습니다. 문서를 읽고 간단한 이메일을 작성하는 정도였지, 영어로 깊이 있는 논의를 해본 경험은 없었습니다. 하지만 석사를 하려면, 영어로 강의를 듣고, 과제를 수행하고, 토론을 해야할 수도 있습니다. 단순히 점수를 따는 것이 아니라, 이 환경에서 버틸 수 있을 만큼의 실력을 갖춰야 했습니다.

이전까지 고민하던 것과는 차원이 다른 현실적인 벽이었습니다. 이 학교를 목표로 삼고, 석사를 한다고 결심한 순간부터, 어학 성적을 만들기 전까지는 아무것도 시작할 수 없다는 사실이 와 닿았습니다.

고민할 시간도 아깝다는 생각이 들었습니다. 그렇게 석사를 결심한 지 이틀 만에 주말에 바로 학원을 찾아갔습니다. 상담을 받고, 학습 계획을 짰습니다. 제가 가진 유일한 장점은 행동력이거든요..

아무튼 그래서 다음 주부터 학원을 다닙니다.

사실 처음엔 ‘혼자 공부할 수 있지 않을까?’라는 생각도 들었습니다. 문제집을 사서 유형을 익히고, 인터넷 강의를 찾아보는 방식으로요. 하지만 현실적으로 제가 혼자 이 모든 걸 감당할 만큼의 노하우도 없었고, 그럴 자신도 없었습니다. 석사를 도전하기로 한 이상, 결과를 만들어야 하니까 제대로 된 방법을 선택하는 것이 맞다고 판단했습니다.

아주 예전에 학창 시절엔, 이전까지 저는 늘 고민하고, 비교하고, 망설이면서 시간을 흘려보냈습니다. 하지만 이번만큼은 다르게 해보고 싶었습니다. 일단 시작하고, 과정 속에서 해결해 나가기로요.

완벽한 준비가 끝난 다음에 움직이는 것이 아니라, 움직이면서 준비하는 것을 선택해봤습니다.

그럼에도 불구하고

어쩌면 이런 학위가 없어도, 영어 공부 없이도 살 수 있는 길이 있겠죠.. (지금 삶도 좋으니까요)

그냥 지금처럼 실무에서 경험을 쌓고, 필요할 때마다 그때그때 배우면서 가는 것도 나쁘지 않을지도 모릅니다.

생각해 보면, 저는 지금까지 늘 최소한의 노력으로 최대한의 결과를 내려는 태도로 살아왔을지도 모르겠네요. 대학 시절에도 성적을 따기 위한 공부에 집중했고, 실무에서도 당장 필요한 기술을 익히는 방식으로 해결해왔거든요.

석사가 단순히 학위 하나를 더 얻는 과정이라면, 저는 관심이 없었을 겁니다. 하지만 이 과정은 단순한 학위 이상의 의미를 가진다고 생각해요.

지금껏 해보지 않았던 방식으로 도전해 보고 싶었습니다.

혼자 할 수 없는 것들을 배우고, 익숙하지 않은 환경에서 살아남아 보고 싶었습니다. 그리고 그 과정에서 내가 어디까지 성장할 수 있는지 직접 확인해 보고 싶더라구요.

마무리

앞으로 2개월간 근사치 점수에 도달할 수 있을지 확인해볼 생각입니다.

희망이나 기대가 아니라, 객관적인 수치로 냉정하게 스스로를 평가할 예정입니다.

만약 기준을 넘지 못한다면, 그땐 인정하고 그에 맞는 현실적인 선택을 해야 할지도 모르겠습니다.

저는 이 석사 카테고리가 졸업까지 끝까지 연재되길 바라고 있지만, 어이없게도 연재하지 못할 수 있습니다.

하지만 늘 그래왔듯이, 일단 해보고, 안되면 그 때 가서 생각해보겠습니다.

여러분들도, 하고 싶은 일이 있다면, 망설이는 시간보다 부딪혀보는 시간이 조금이라도 더 많았으면 좋겠습니다.

개발자를 꿈꾸는 예비 고등학생에게 감히 조언을 해보았다

CODe_ — Sun, 19 Jan 2025 19:14:31 +0900

서론

개발자분들이나 취준생분들이라면 한 번쯤 "개발에 관심 많은 후배들에게 어떤 이야기를 해줄 수 있을까?" 고민해본 적이 있을 거예요. 저도 비슷한 경험을 했어요.

얼마 전, 카카오뱅크에 특별한 손님들이 찾아왔습니다. 바로 이제 막 고등학교에 입학하는 SW마이스터고 학생들이었어요. 약 80명의 학생들 앞에서 20분간 발표를 하게 되었죠. 평소처럼 개발자나 취업 준비생을 대상으로 하는 발표와는 완전히 달랐어요. 아직 실무 경험이 없는 학생들에게 어떤 이야기를 전해야 할까? 어떤 방향으로 접근해야 더 의미 있는 시간이 될까? 짧은 시간 안에 고민이 많았어요.

이 글에서는 발표 준비 과정에서 어떤 고민을 했는지, 눈높이를 맞추기 위해 어떤 노력을 했는지, 그리고 발표 이후 교장선생님의 후기까지 흥미로운 경험을 나누려고 합니다. 기술적인 내용이 아니라, 누구나 편하게 읽을 수 있는 이야기라서 부담 없이 읽으실 수 있을 거예요.

2주 뒤에 발표 가능해요?

1월 2일, 연초의 바쁜 업무 속에서 한 통의 연락을 받았습니다. 카카오뱅크에 SW마이스터고 학생 80명이 견학을 온다는 소식이었어요. 행사를 주관하는 부서에서 20분짜리 발표를 맡아줄 수 있냐고 요청하셨죠.

사실 저도 그때 알게 됐는데, 이 행사는 꽤 급하게 결정된 일정이었어요. 담당 부서에서도 행사 준비로 분주한 분위기였고, 저 역시 발표를 준비할 시간이 고작 2주밖에 없었습니다. 게다가 행사일인 1월 17일은 목요일. 평소처럼 업무에 치이면서도 발표를 어떻게 준비해야 할지 고민이 많았어요.

시간이 많다면 멋진 발표 자료를 만들 수도 있었겠지만, 현실적으로 새로운 걸 거창하게 만들 여유는 없었습니다.
"그럼, 최대한 짧은 시간 안에 준비할 수 있는 주제를 찾아야겠다."

그렇게 떠오른 것이 제 학창 시절이었어요.

중학생 때의 경험, 대학생 때의 고민들… 남들과 조금은 달랐던 제 학창 시절을 떠올리면서 "이거라면 하루 안에 발표 준비가 가능하겠다!" 싶었습니다.

그렇게 발표를 맡았고, 제 주말은 또다시 사라졌습니다.

내가 예비 고등학생이라면 뭘 듣고 싶을까?

발표 준비를 하면서 가장 먼저 떠오른 질문은 "내가 예비 고등학생이라면 어떤 이야기를 듣고 싶을까?" 였어요.
여태까지 수십 번 발표를 해봤지만, 대상이 예비 고등학생이라는 점은 저에게도 새로운 도전이었습니다.

사실, 제 학창시절을 회상하기엔 꽤 오랜 시간이 흘러 희석되었고, 그리고 요즘 고등학생들이 어떤 관심사를 가지고 있는지, 어떤 세대인지 전혀 감이 오지 않더라고요.

그렇다고, 제가 하고싶은 얘기만 하는 발표를 하고 싶진 않았어요.

또한 SW마이스터고 출신의 개발자분들과 멘토링 경험이 있긴 했지만, 그 학교에 다니는 학생들이 실제로 어떤 고민을 하고, 어떤 환경에서 공부하는지에 대한 구체적인 정보는 없었어요.
결국 학생들의 눈높이를 이해하기 위해 정보 조사가 필요하다고 판단했죠.

마침 평소 고등학생들과 교류가 많고 해커톤을 주최하는 대표님과 친분이 있어서 연락을 드렸습니다.

정말 감사하게도, SW마이스터고 졸업생분의 현실적인 경험담을 들을 수 있었어요.
저는 인문계 고등학교를 나왔기 때문에 마이스터고에 대한 이야기가 정말 생소했지만, 덕분에 학생들의 학업 방식, 학교 분위기, 국가지원 프로그램 등 다양한 이야기를 접할 수 있었죠.

구체적인 내용은 주관적이라 모두 공개하긴 어렵지만, 학생들이 어떤 상황에서 공부하고 있을지 어느 정도 감을 잡을 수 있었어요.

마이스터고 학생분들은 수능이라는 전국 고등학생들이 치뤄야하는 공통된 학업이 아닌, 소프트웨어라는 다소 구체적인 공부를 하게 되겠죠.

이론적 지식뿐 아니라 다양한 실습을 통해 결과가 바로 나오는 분야이다 보니 누가 잘하는지가 더 돋보인다고 생각합니다.

저 또한 학창 시절에 경험해 보았는데요, 부끄럽지만, 이때 자만의 길로 빠져서 헤어나오는데 오래 걸렸던 경험도 있었답니다.

그들이 겪을지도 모르는 그 상황이나 감정, 어떻게 대처하면 좋을지에 대해 준비하게 되었고 제목은 "우리는 언젠가 개구리가 된다"라는 제목으로 정했습니다.

우리가 많이 들어본 "우물 안 개구리"에 대한 이야기이죠.

공감대를 어떻게 형성하면 좋을까?

짧은 발표에도 유대감이 있다는 사실 알고 계신가요? 제 개인적인 생각입니다만, 발표자와 발표를 듣는 청중 사이에 유대감이 높을수록 호응이나 집중력이 올라간다고 생각합니다. 그래서 와다다 하고 싶은 말을 쏟아내기보다는 도입부에서 발표에 좀 더 집중할 수 있도록 관심이 생길만한 키워드나 경험을 이야기하려고 준비했습니다.

저는 고1로 올라가던 시절에 게임을 정말 좋아했어요. 여러분도 그렇지 않았나요?

메이플스토리

네 그래서 게임 이야기를 꺼냈습니다.

무슨 게임인지 아냐고 물었더니 모두가 알고 있더라구요.. 역시 세대를 거스르는 메이플..

저는 게임을 잘하진 않았습니다. 지금도 그렇지만 정말 즐기기만 하는 즐겜유저거든요.

중학교 1학년 때, 반복적인 사냥만 하던 방식에 지루함을 느꼈고 갑자기 매크로를 만들겠다는 생각을 합니다(?)

그땐, 구글링이나 코딩, IDE라는 기본적인 용어도 모른 채 "매크로를 만들래!"라는 집념 하나로 help 파일 하나를 보고 공부를 하기 시작합니다.

마치 백과사전처럼 언어 사용법에 대한 help 파일이 있었고, 색인 기능으로 내가 필요한 기능을 찾고 Example을 보고 하나씩 테스트해가며 기능을 만들어갔어요.

이런 식으로 익숙한 이야기로 시작해서, 청중이 발표자의 이야기를 자신과 연결하여 듣게 되기 때문에 게임이라는 공통 관심사를 활용한 것이 긍정적인 효과를 발휘했습니다.

우물에 빠졌던 중학생

그때 당시, 중고등학교에서 개발을 할 줄 안다는 것은 엄청난 능력이었습니다. 친구가 거의 없다시피 했던 제게, 게임을 좋아하는 친구들이 관심을 보였고, 누군가는 자기가 필요한 기능을 만들어 달라고 이야기하면서까지 말을 걸어왔습니다. 그렇게 친구들도 점점 많아졌고 말 없고 소심했던 제가 조금씩 변할 수 있는 계기가 되기도 했어요.

갑작스럽게 제 능력을 인정받은 탓이었을까요? 조금은 자만했던 시절이었던 것 같습니다.

제대로 된 원리를 이해한 것이 아니라 툴에 의존하고 필요한 기능만 뽑아 쓰던 시절이었거든요. 친구들에겐 빈 껍데기였던 이 모습을 들키기 싫어서 할 줄 모르는 것도 할 줄 안다고 거짓말 쳤던 기억도 있습니다.

결론적으로, 원리를 이해하지 못하면 환경이 바뀌었을 때 아무것도 할 수 없게 됩니다.

응용을 전혀 할 수 없는 것이죠.

그래서 학생 여러분께 툴러(툴만 다루는 것)였던 제 과거를 이야기하면서 기초 학습의 중요성에 대해 이야기했습니다.

학생분들은 현재 학업을 통해 기본기를 다지고 있는 과정에 있기에, 눈에 보이는 성과를 내는 것도 중요하지만, 그보다 더 중요한 것은 언제 어디서든 흔들리지 않는 기초를 다지는 것이라고 말이죠.

학생분들이 단기적인 인정보다는 더 긴 호흡으로 성장할 수 있기를 바랐습니다.

다른 우물도 존재한다

결국 제가 계속해서 말하고자 했던 "우물"은 "환경"을 뜻했습니다.

학창 시절에 컴퓨터를 잘 다루기도 했고 모두가 저보고 잘한다고 말해서 제가 1등인 줄 알았지만, 환경이 달라지니 그렇지가 않더라구요.

해커톤이나 각종 대회에 참가했지만, 입상조차 하지 못했던 순간
프로젝트에서 능력 부족으로 기한 내에 구현을 마치지 못했던 순간
대회장에서 옆 팀의 수준을 보고 감탄만 하고 있었던 순간
대학생이 되어 나보다 훨씬 뛰어난 동기를 마주했던 순간

이런 경험을 하면서 처음으로 깨달았습니다. 세상에 나보다 뛰어난 사람이 많다는 것을 느꼈던거죠.

그때의 괴리감은 엄청났습니다. 갑자기 제가 바닥으로 추락한 기분이었거든요.

하지만 이 과정이 없었다면, 저는 여전히 작은 우물 안에서 스스로를 최고라고 착각한 채 머물러 있었을 것입니다.

익숙한 환경에서 벗어나지 않으면, 자신의 실력을 객관적으로 볼 기회가 없습니다.
늘 속해 있던 우물에서 한 걸음만 나와도, "내가 알고 있던 세계가 전부가 아니었구나" 를 깨닫게 됩니다.

학생들도 지금은 "고등학교라는 우물" 안에서 성장하고 있을 것입니다.
하지만 그 안에서만 머문다면, 실력이 성장할 기회를 놓칠 수도 있습니다.

그래서 저는 발표에서 "스스로의 우물을 넓히는 방법" 을 이야기했습니다.

해커톤, 개발 커뮤니티, 스터디 그룹을 활용해 더 넓은 세상을 경험할 것
스스로의 실력을 객관적으로 바라보며 겸손한 태도를 가질 것

지금 있는 환경에서 만족하지 않고, 계속해서 더 넓은 세계를 탐색해야 한다는 메시지를 전달하고 싶었습니다.

열등감이라는 감정에 솔직해지기

자신보다 잘하는 사람을 보면 자연스럽게 열등감을 느낍니다.
때로는 자격지심이 들고, 상대적으로 박탈감을 느낄 때도 있습니다.

그 감정이 든다고 해서 이상한 것이 아닙니다. 오히려 너무나 당연한 감정입니다.

하지만 중요한 것은, 그 감정을 어떻게 다루느냐입니다.

저는 발표에서 이런 이야기를 전했습니다.

열등감을 부정하지 말고, 성장의 원동력으로 삼으세요.

대부분의 사람들은 자신만의 학습 방법이 있다고 생각합니다. 하지만 한 가지 방식만 고집하다 보면, 성장의 기회를 놓칠 수도 있습니다. 잘하는 사람을 보면 단순히 부러워하는 것이 아니라, 그들이 어떻게 공부하고, 어떻게 사고하는지 따라 해 보는 것이 중요합니다.
이건 과거의 저에게도 해주고 싶은 말이기도 합니다.

저도 과거엔 저만의 방식으로 공부를 하다가 도저히 성적이 오르질 않아서 소위 잘하는 친구들의 학습 방식을 따라 해봤는데, 비로소 이렇게 공부하는 거였구나 하고 깨달았던 시절이 있었습니다.

이 경험을 통해 저는 변화라는 것이 결국 내가 옳다고 믿는 것들을 하나씩 내려놓고, 다양한 시도를 할 때 찾아온다는 것을 배웠습니다.

시간 관계상 이렇게까지 구체적으로 전달드리진 못했지만, 핵심적인 내용은 전달드릴 수 있었습니다.

지금의 우물을 발전시키는 방법

이 주제는 새로운 하나의 발표가 될 정도로 방대한 내용이라 잠깐 언급만 하고 넘어갔어요.

발표 내내 "다른 우물도 보셔야 해요!"라는 메세지를 전달했지만, 지금 속해있는 우물에서 다 같이 성장하는 방법도 있다는 걸 말씀드리고 싶었거든요.

새로운 환경을 경험하는 것도 중요하지만, 현재 속한 환경을 더 나은 곳으로 만드는 것 역시 큰 의미가 있습니다.

오히려, 다른 우물로 옮기는 것보다 훨씬 어려운 도전이라고 생각합니다.

이것은 저 역시 고민하고 있는 과제입니다.
더 넓은 시야를 가지는 것도 중요하지만, 현재 속한 환경을 성장의 발판으로 삼는 방법에 대해 늘 고민하고 있습니다.

하지만 언젠가 "지금 있는 우물을 어떻게 더 발전시킬 것인가" 라는 주제로 더 깊이 이야기할 기회가 있으면 좋겠습니다.

발표가 끝나고

발표가 끝나고 교장선생님께서 발표자에게 찾아와 명함을 건네주셨습니다.

"너무 좋은 내용을 전달 주셔서 감사하다"며 학교 근처에 오거든 꼭 연락 달라고 하시더라구요.

제 기억 속 교장선생님은 늘 먼 존재였습니다.

학창 시절에는 단 한 번도 개인적으로 대화를 나눈 적이 없었고, 늘 무대 위에서만 보이는 분이었습니다.

그런데 이번에는 조금 다르게 보였습니다.
단순히 먼 존재가 아니라, 하나의 그룹을 이끄는 리더처럼 느껴졌습니다.
학생들을 이끄는 사람으로서 많은 책임을 짊어진 분이라는 생각이 들었기 때문일까요.

이렇게 발표는 마무리되었습니다.

주말 하루를 투자해 발표 자료를 만들었고, 시간이 촉박했던 만큼 자료의 완성도보다는 전달하고자 하는 메시지에 집중했습니다.

연습할 시간도 없었고, 대본 없이 발표를 진행했기에 생각보다 매끄럽지 못했던 부분도 있었습니다.
하지만 결국 중요한 것은 학생들에게 무엇을 남길 수 있느냐라고 생각했습니다.

부디 이번 발표가 예비 개발자로 성장할 학생들에게 작은 도움이 되었길 바랍니다.

여담

모든 행사가 끝나고 돌아가는 길에 저와 함께 발표를 했던 분과 행사를 주관하신 부서의 동료께서, 제 블로그 글을 봤다며 먼저 인사해 주셔서 감사했습니다. 아마 아래의 글을 보신 것 같더라구요.

실제로 최종 합격하신 분들 중에 아래의 글을 보고 오시는 분들이 꽤 계시는 것 같아 뿌듯하기도 하면서, 블로그 글을 작성할 때 신중히 작성해야겠다는 생각을 하게 된 하루였습니다.

2023.12.10 - [후기/경험] - 채용 한파에 카카오뱅크 최종 합격 후기

채용 한파에 카카오뱅크 최종 합격 후기

서론 2023년 12월, 카카오뱅크 결제코어개발팀 백엔드 개발자로 합류하게 되었습니다.넥슨 코리아 퇴사와 동시에 쉬는 기간 없이 입사를 결정했고, 이 아티클이 등록되는 시점엔

imksh.com

4가지 사건으로 바라본 2024년

CODe_ — Sun, 5 Jan 2025 16:24:41 +0900

교토 이네후나야 - 직접촬영

서론

2024년은 도전과 성찰, 그리고 성장으로 가득했던 한 해였습니다. 금융 도메인으로의 이직, 이력서 강의의 성공적인 런칭, 인간관계 속에서의 깨달음, 그리고 철학적 사고를 통해 제 자신을 더 깊이 들여다보는 과정을 거쳤습니다. 이 글에서는 제가 경험한 주요 사건들을 하나씩 돌아보며, 그 안에서 얻은 배움을 나누고자 합니다.

경험 없던 금융권으로 경력 이직

2023.12.10 - [후기/경험] - 채용 한파에 카카오뱅크 최종 합격 후기

채용 한파에 카카오뱅크 최종 합격 후기

imksh.com

2023년 12월, 저는 카카오뱅크로 이직하며 금융 도메인이라는 새로운 환경에 발을 들였습니다. 금융은 다른 도메인과 달리 비즈니스 구조가 매우 복잡하고, 법적 규제와 개인 정보 관리 같은 요소까지 더해져 도메인 지식의 중요성이 업무 전반에 절실히 요구되는 분야였습니다.

제가 맡은 역할은 새로운 기술을 도입하거나 설계된 시스템을 검토하며, 비즈니스 요건과 기술적 안정성이 조화를 이루는지를 판단하는 일이었습니다. 입사 당시, 약 100명이 참여하는 대규모 프로젝트가 설계를 마치고 개발 단계로 넘어가려는 상황이었습니다. 저는 입사 후 한 달 만에 기존 설계를 분석하며 구조적 오류를 발견했고, 유관 파트와 논의 끝에 설계를 재구성하는 과정에 기여했습니다. 이 과정에서 기존 설계에 담긴 구성원들의 노력을 존중하며, 동시에 제 논리가 맞는지 끊임없이 검증하고 증명해야 했습니다.

금융 개발의 기존 관습과 새로운 시도

금융권 개발 환경에서는 SI(System Integration) 프로젝트에서 자주 사용하는 비즈니스 흐름 중심의 개발 방식이 익숙하게 자리 잡고 있었습니다. 이러한 방식은 업무 프로세스나 요구사항에 따라 코드를 순차적으로 작성하는 형태로, 종종 복잡한 비즈니스 로직이 하나의 메서드에 밀집되거나 추상화가 부족한 경우가 많았습니다.

이러한 관행 대신, 저는 Java와 Spring Boot 스택을 활용해 코드의 가독성과 유지보수성을 높이고자 고민했습니다. 코드를 더 직관적이고 명확하게 작성하는 방법을 도입하면서, 팀 내에서 효율적이고 표준화된 개발 방식을 구축하려 노력했고 지금도 구성원들과 함께 고민하고 적용하고 있습니다.

코드리뷰 문화의 도입

제가 입사했을 당시 팀에는 코드리뷰 문화가 전무했습니다.(여기서 말하는 코드리뷰는 PR, MR을 이용한 코드리뷰를 의미합니다) 코드리뷰 없이 작업이 진행되다 보니 코드 품질이나 팀원 간 코드 스타일의 일관성에 문제가 있었습니다. 저는 입사 직후부터 코드리뷰 문화를 도입해야 한다고 판단했고, 이를 직접 제안했습니다. 지금까지도 대부분의 소스코드를 제가 직접 리뷰하며 코드 수정 아이디어를 제시하고 있습니다.

처음에는 코드리뷰와 새로운 개발 방식에 익숙하지 않았던 구성원들도 시간이 지나며 이를 점차 받아들였고, 서로의 작업을 피드백하며 배우는 문화를 형성할 수 있었습니다. 제 판단을 믿고 지지해준 구성원들 덕분에, 1년 전과는 비교할 수 없을 만큼 함께 성장했습니다.

이 과정에서 가장 크게 깨달은 점은, 기술적인 변화는 결국 사람과의 신뢰 속에서 이뤄진다는 사실이었습니다. 새로운 방식을 도입할 때 가장 중요한 것은 논리적으로 설득하는 것뿐만 아니라, 그 변화가 팀의 성장과 성공에 실질적인 도움이 될 것임을 모두가 체감하게 만드는 일이었습니다.

또한, 코드리뷰를 통해 각자의 강점을 코드에 자연스럽게 녹여낼 수 있었고, 각 구성원이 "더 나은 코드"를 고민하며 지속적으로 성장할 수 있는 기반을 마련했다는 점에서 큰 보람을 느꼈습니다.

인프런 이력서 강의 런칭

2024년 4월, 저는 인프런에서 이력서 강의를 기획하고 준비하기 시작했습니다. 높은 업무 강도 속에서도 퇴근 후와 주말 시간을 활용해 강의를 제작하며, 번아웃이 두 번 이상 찾아올 정도로 힘든 시기를 겪었어요. 촬영 중에는 자신감이 떨어지고 흔들리는 순간도 많았습니다.

그럼에도 포기하지 않고 끝까지 완성할 수 있었던 건 러닝메이트로 함께했던 세 분 덕분이었습니다. 그분들의 지지 덕분에 끝까지 포기하지 않고 강의를 완성할 수 있었습니다. 그렇게 만들어진 강의는 성공적으로 런칭되었고, 현재는 약 500명 이상의 수강생이 참여하며 평점 5.0을 유지할 수 있었습니다. 또한 운이 좋게도, 인프랩과의 협업을 통해 기존 강의들보다 더 많은 수강생을 유치할 수 있었고, 그 과정에서도 큰 보람을 느꼈습니다.

영향력

강의를 시작하며 예상치 못했던 순간 중 하나는, 수강생들의 합격 소식을 들을 때 찾아오는 행복이었습니다. 어떤 수강생이 "강의를 듣고 준비한 덕분에 원하는 회사에 합격했다"는 소식을 전해왔을 때, 그 순간의 행복은 말로 표현하기 어려웠습니다. 단순히 강의를 만든 사람으로서가 아니라, 누군가의 인생에서 작은 도움을 줄 수 있었다는 사실이 큰 감동으로 다가왔거든요.
이런 순간들은 강의를 준비하며 겪었던 어려움과 번아웃마저 잊게 만들 만큼 소중한 경험이라고 생각합니다.

책임감

시간이 지나며 강의를 수강하는 분들이 점점 늘어나면서, 저에게는 책임감이라는 무게도 함께 커졌습니다. 수강생들이 기대하는 것은 단순히 정보 전달이 아니라, 실질적으로 도움이 되는 내용과 방향성입니다. 그 기대에 부응하기 위해 강의 내용을 꾸준히 점검하고, 추가적인 자료를 제작하며, 강의 이후에도 질문에 답변하며 소통하려고 노력했습니다.

운영 중인 디스코드 채널

수강생들의 성취와 만족도가 높아질수록 제가 해야 할 역할도 더욱 명확해졌습니다. 단순히 지식을 전달하는 것을 넘어, 각자가 더 나은 길을 찾을 수 있도록 돕는 길잡이 역할이 중요하다는 것을 깨달았습니다.

이력서 강의는 단순히 콘텐츠를 제작하는 과정이 아니었어요. 사람들과 연결되고, 그들의 성취를 함께 기뻐할 수 있는 너무도 소중한 시간이었답니다. 강의를 시작할 때는 번아웃과 불안감 속에서 힘들었던 순간도 많았지만, 수강생들의 합격 소식과 따뜻한 피드백은 제가 앞으로도 계속 이 길을 걸어가야 하는 이유가 되어 주었어요.

지금은 기술적인 콘텐츠를 제작하기 위해 고민을 이어가고 있습니다. 앞으로도 이런 방식을 통해 더 많은 사람들에게 도움을 줄 수 있기를 기대하고 있습니다.

강의 런칭 이후, 강사로서의 활동

강의를 성공적으로 런칭한 이후, 제 삶은 또 다른 방향으로 바쁘게 움직이기 시작했습니다. 부트캠프, 교육기관, 출판사 등 다양한 곳에서 협업 제안을 받으며 강사와 멘토로서의 활동이 본격화되었죠. 강의가 끝난 뒤에는 조금은 여유가 생길 거라 기대했지만, 실제로는 일정이 더 빽빽해졌습니다.

때로는 번아웃의 경계에서 줄타기를 하는 것 같은 순간들도 있었지만, 그만큼 보람 있는 일들도 많았습니다. 무엇보다도 수강생들과의 만남과 소통이 저를 끊임없이 배우게 하고 성장하게 했어요.

강의를 수강한 분들 중 일부는 구체적이고 열정적인 질문들을 보내오곤 했습니다. 질문의 깊이나 방향은 모두 달랐지만, 그 안에는 각자 진지하게 고민하고 노력해온 흔적이 담겨 있었어요. 이런 질문들에 답을 하다 보면 저 자신도 다시금 배움을 정리하고, 때로는 새로운 관점을 발견하게 되었습니다.

특히, 수강생들의 질문을 통해 "내가 놓치고 있던 부분은 무엇일까?"를 자주 돌아보게 되었고, 단순히 강사로서 지식을 전달하는 역할을 넘어 그들의 성장을 진심으로 응원하는 제 자신을 발견할 수 있었습니다.

기관마다 다른 학습 분위기와 태도

강의를 통해 다양한 기관과 협업하면서, 기관마다 수강생들의 학습 태도나 분위기가 서로 다르다는 점도 흥미롭게 다가왔습니다. 어떤 곳에서는 수강생들이 서로 협력하며 적극적으로 질문을 주고받는 모습을 볼 수 있었고, 또 어떤 곳에서는 조용하지만 내면적으로 깊이 고민하며 학습에 임하는 분위기가 느껴지기도 했습니다.

이런 차이들을 경험하며, 저는 단순히 강의를 전달하는 방식뿐만 아니라, 각 기관과 수강생들의 특성에 맞춰 내용을 어떻게 조율해야 할지 고민하게 되었습니다. 앞으로는 이러한 경험을 바탕으로 더 시너지를 낼 수 있는 선택을 하고, 수강생들이 더 많은 것을 얻어갈 수 있는 환경을 만들어가고 싶습니다.

강사라는 역할에 대한 깨달음

강사로서의 활동은 단순히 지식을 전달하는 것에 그치지 않는다는 점을 매 순간 느꼈습니다. 수강생들에게 필요한 것은 단순한 정보가 아니라, 그들이 스스로 고민하고 성장할 수 있도록 돕는 길잡이 역할이었어요.

때로는 질문에 답을 주기보다, 그들이 스스로 답을 찾을 수 있는 방향을 제시하는 것이 더 큰 도움이 된다는 것을 깨달았습니다. 강사로서의 역할은 단순히 알려주는 사람이 아니라, 함께 고민하고 성장을 돕는 동반자와 같다는 생각이 들었어요.

이처럼, 강사 활동은 제게 또 다른 배움과 성장의 시간이었습니다. 수강생들의 질문과 성장은 제가 다시 배우고 고민할 수 있는 계기가 되었고, 다양한 기관에서의 경험은 앞으로 더 나은 방향을 고민하게 만들었습니다.

앞으로도 강사로서 수강생들이 더 나은 길을 찾고 성장할 수 있도록, 그 길의 동반자로 함께 걸어가고 싶습니다. 아직은, 이 경험들이 저 자신을 더 깊고 단단하게 만들어주는 과정이 되리라 생각합니다.

인간관계에서 성숙해지기

2024년은 기술적인 성장뿐만 아니라, 제 자신과 인간관계를 깊이 돌아볼 수 있었던 해였습니다. 그동안 바쁜 일상 속에서 기술에 대한 FOMO(Fear of Missing Out)를 느끼며 끊임없이 공부를 이어왔지만, 정작 저 자신과 가치관에 대해 깊이 고민할 시간을 가지지 못했다는 것을 깨달았습니다.

[가장 젊은 날의 철학] 목차

그 계기 중 하나가 바로 가장 젊은 날의 철학이라는 책이었습니다. 이 책은 나 자신, 인간관계, 그리고 삶의 방향성에 대한 질문을 던지며, 제가 스스로를 돌아보고 정리할 수 있는 기회를 제공해주었습니다.

인간관계와 나를 둘러싼 관계에 대해

지난 몇 년간의 인간관계를 돌아보면, 저를 힘들게 하고 무너지게 했던 관계도 있었지만, 반대로 저를 성장시키고 의지할 수 있도록 해준 견고한 관계도 있었습니다. 또한, 이러한 경험 속에서 저는 "사람은 바꿀 수 있다!"라는 생각이 어쩌면 나의 오만일 수 있었다는 사실을 깨닫게 되었습니다. 사람은 강한 계기와 동기가 없다면 본성을 쉽게 바꾸지 않는다는 점을 다시금 확인하게 되었고, 동시에, 제가 얼마나 부족한 사람이었는지도 돌아보게 되었고, 결혼이라는 제도를 단순히 추상적으로만 생각했던 과거와 달리 더 구체적으로 고민해보는 계기가 되었습니다.

커뮤니티에서 만난 분들 덕분에 저는 많은 응원과 격려를 받을 수 있었습니다. 강의를 SNS에 공유해주시거나 진심 어린 후기를 남겨주시며 저를 응원해주신 분들의 따뜻함이 정말 감동이었습니다. 그분들의 행동을 통해 “나도 과연 이렇게 행동할 수 있었을까?”라는 질문을 스스로에게 던지게 되었고, 감사함과 존경의 마음을 느낄 수 있었습니다.

올해 저는 내가 무엇을 좋아하고 싫어하는지, 어떤 방향으로 나아가고 싶은지 진지하게 고민하기 시작했습니다. 예전에는 단기적인 목표를 세우고, 눈앞의 성취를 이루는 데 집중했다면, 이제는 삶을 더 거시적으로 바라보려 합니다. 현실적인 여건을 고려하면서도, 나만의 방향성을 가지고 살아가기 위해 고민하는 시간이 많아졌습니다.

앞으로도 저는 저를 둘러싼 관계를 더 소중히 여기고, 함께 성장할 수 있는 방향을 찾아가고 싶습니다. 아직 부족하지만, 조금씩 나아지는 모습을 통해 더 나은 관계와 삶을 만들어가길 기대합니다.

마무리

2024년은 도전과 성취, 그리고 인간관계와 자기 성찰을 통해 많은 성장을 이룰 수 있었던 해였습니다.

아직 저는 배워야 할 것도 많고, 성장해가야 할 길도 많이 남아있습니다. 그럼에도 지금까지 저와 함께해 주신 분들, 그리고 앞으로 인연을 맺게 될 분들께 미리 감사의 마음을 전하고 싶어요. 앞으로도 함께 할 수 있기를 바라며 한층 더 성숙해지도록 하겠습니다.

여러분의 2024년은 어떤 모습이었나요? 한 해를 돌아보며 감사했던 순간들과 배운 점들을 떠올려보시면 좋을 것 같아요. 내년에도 서로의 성장을 응원하며, 더 멋진 도전을 이어가길 진심으로 응원하겠습니다.

퇴사를 고민하는 주니어에게,

CODe_ — Sat, 9 Nov 2024 20:23:40 +0900

출처: 픽사베이

프롤로그

취업이 너무나도 어려운 시기에 개발자 취업을 꿈 꿔왔던 멘티가 있었습니다. 결국 치열한 노력 끝에 취업에 성공하여 기쁜 소식을 전해줬어요. 하지만 몇 개월 후, 제게 다시 연락을 해왔습니다. "힘들다, 퇴사하고 싶다"라는 지쳐있는 이야기를 말이죠.

저는 몇 가지 제 경험과 가치관에 대해 이야기를 해주었습니다. 대기업 공채 입사 이틀만에 퇴사를 결심한 이야기부터, 이직을 한 순간까지 어떻게 버텼는지, 그 과정에서 스스로 느낀 점들에 대해서요. 우리가 살아가는 길에는 많은 선택지가 있지만, 퇴사나 이직은 특히나 어렵고 고민되는 선택지 중 하나일 겁니다.

이 글은 퇴사라는 단어와 가까워지기 시작한, 혹은 아직은 멀게 느껴지지만 언젠가는 퇴사를 고민하게 될지도 모를, 4년차 이하의 개발자들을 위해 썼습니다. 조금 철학적일 수 있지만, 고민의 순간마다 스스로의 감정을 조금 더 명확하게 바라보고, 스스로가 진정 원하는 것을 찾는 데에 이 글이 작은 도움이 되기를 바랍니다.

퇴사를 고민하는 이유들

저 역시 누구나 꿈에 그리던 대기업의 공채로 입사했지만, 단 이틀 만에 퇴사를 결심했던 경험이 있습니다. 많은 사람들이 대기업에서의 안정적인 커리어를 꿈꾸기에, 제 결정을 이해하지 못했지만, 그 때 당시 저에게는 나름대로의 이유가 있었습니다.

저는 일의 양이 많고 스스로 몰두할 수 있는 환경에서 성장을 느끼며 만족감을 얻는 사람이었어요. 그런데 입사했던 기업에서는 모든 것이 시스템적으로 잘 갖추어져 있었고, 퇴근 후에는 일에 대한 부담이 전혀 없었어요. 주변 사람들은 그것을 좋은 환경이라 이야기했지만, "이러다 성장이 멈추는 것이 아닐까?" 하는 두려움이 들었습니다. 그래서 저는 과감하게 퇴사(이직)를 결심했고, 2년 동안 이직을 준비하면서 진정 제가 원하는 환경을 찾아갔습니다.

이 경험을 통해 깨달은 것은, 퇴사를 고민하는 이유가 다른 사람들의 관점에서 쉽게 이해되지 않을 수 있다는 점 입니다. 그리고 자신의 가치관에 맞지 않는 환경에서 억지로 버티는 것이 결코 바람직하지 않다는 것이죠.

주니어 개발자들이 퇴사하는 이유는 다양합니다. 저처럼 성장이 멈춘 것 같은 느낌을 받을 수도 있고, 기대와 다른 회사 문화나 업무 스타일에 부딪힐 수도 있을 것입니다. 혹은 사수의 부재처럼 적절한 피드백이나 지도가 부족해 막막함을 느낄 수도 있죠. 그 이유가 무엇이든, 여러분의 고민을 존중합니다. 이제, 여러분의 다양한 고민들을 조금 더 객관적으로 바라보고 분석해보려 합니다.

감정을 분석하기

퇴사를 고민하게 만드는 감정이나 사례들을 구체적으로 나열해 보세요. 단순히 피로감에서 오는 건지, 성장의 한계를 느끼는 것인지, 아니면 전혀 다른 문제 때문인지 알아보는 과정이 필요합니다. 이때 가장 중요한 것은 감정에 휘둘리지 않고 자신의 고민을 명확하게 바라보는 것입니다. 구체적인 질문을 스스로에게 던져보세요.

"어떤 순간에 퇴사하고 싶다고 느꼈지?"
"내가 원하는 환경은 어떤 모습이지?"

이런 질문을 던지다보면, 퇴사가 단지 감정에서 비롯된 결정인지, 진정한 욕구와 목표에서 비롯된 결정인지를 구분하게 됩니다. 퇴사가 근본적 해결책이 될지 아니면 다른 방향으로 해결할 수 있을지 판단할 수 있게 되죠. 결국, "나는 어떻게 살고 싶은가?"라는 질문에 이르게 될 겁니다. 나에게 진정한 행복과 의미를 주는 것은 무엇인지 찾아가는 과정을 피할 수 없게 돼요.

당신은, 어떻게 살고 싶은가?

"어떻게 살고 싶은가?"라는 질문에 저는 "행복하게"라고 답합니다. 이 대답은 사실 저의 퇴사 기준을 비롯한 많은 선택의 중심에 있습니다. 직장은 우리가 많은 시간을 보내는 곳이기에, 직장에서의 경험이 삶의 행복에 깊이 연결됩니다. 직장이 저의 행복 기준과 멀어진다면, 저는 퇴사를 고민할 수밖에 없습니다.

지금의 제 행복을 지키기 위한 필수 요소는 크게 3가지입니다.

건강, 자기 효능감, 그리고 성장이죠.

건강을 해친다면

어른들이 늘 “건강이 가장 중요하다”고 말할 때, 20대인 저는 그 중요성을 실감하지 못했습니다. 사실 20대는 누구나 비교적 건강하고, 제 몸이 튼튼하다는 믿음이 있었죠. 불과 몇 년 전까지만 해도 “한 살이라도 어릴 때 열심히 구르자!”라는 생각으로 살았습니다. 건강을 크게 신경 쓰지 않았고, 밤을 새워가며 일에 몰두하고, 몇 달간 수면을 줄여가며 필요한 공부를 이어갔습니다.

그러나 반복되는 무리 속에서 신체뿐 아니라 정신도 지쳐가며 건강의 중요성을 새삼 깨달았습니다. 건강을 지키지 못한다면, 어떤 좋은 직장이나 커리어 목표도 의미가 없다는 것을요. 몸이 지치면 의욕을 잃기 쉽고, 정신적인 소진이 지속되면 자존감과 삶의 만족감 또한 떨어지게 됩니다. 만약 직장에서 과도한 스트레스나 정신적인 소진이 반복돼 건강이 위협받는다고 느껴진다면, 퇴사를 고려할 것입니다. 아직은 하루 12시간씩 일하거나 주말이 없어도 행복하지만요.

자기 효능감이 없다면

자기 효능감: 어떤 상황에서 적절한 행동을 할 수 있다는 기대와 신념 - 출처 위키백과

저는 일에서 가치와 의미를 찾고 싶습니다. 자기 효능감은 내가 중요하다고 느끼는 역할을 맡아 내 역량이 충분히 발휘되고 있다는 믿음에서 비롯됩니다. 이는 단순히 결과물로만 나타나는 것이 아니라, 나의 존재와 기여가 회사와 조직에 기여하고 있음을 느끼는 과정에서 얻어지는 것입니다. 자기 효능감이 살아 있는 환경에서 일할 때, 저는 성장의 원동력을 얻게 됩니다.

성장이 없다면

마지막으로, 저는 끊임없이 배우고 조금씩 나아가는 삶을 원합니다. 성장이라는 것은 눈에 보이지 않을 때도 많고, 당장 결과가 나오지 않아 답답하게 느껴질 때도 있습니다. 하지만 시간이 지나 돌아보면, 작은 노력들이 쌓여 어느새 성장한 자신을 발견하게 됩니다. 주니어 개발자라면 당장의 성장이 보이지 않아 고민할 수도 있지만, 지금의 경험들이 쌓여 큰 성장을 이루게 될 것임을 믿고 나아가길 권합니다. 저는 이러한 성장의 과정이 저의 행복을 이루는 중요한 부분이라고 생각합니다.

이 세 가지가 회사에서 모두 충족될 때, 저는 안정적인 삶을 살고 있다고 느낍니다. 회사가 이 기준을 충분히 충족하지 못하고 제 삶의 방향과 어긋난다면, 저는 퇴사를 고민할 수밖에 없습니다. 퇴사는 단순히 어려움을 피하는 것이 아니라, 제가 원하는 삶과 가치를 지키기 위한 중요한 선택이기 때문입니다.

퇴사를 결심했다면

깊은 고민 끝에 퇴사를 결심하게 됐다면, 그 결정이 진정한 자기 이해와 가치에 기반한 것인지 점검해 보는 과정이 필요합니다. 퇴사는 한 번 결정하면 되돌리기 어렵고, 새로운 환경도 항상 기대에 부응하지 않을 수 있습니다. 퇴사를 더욱 신중하고 후회 없는 선택으로 만들기 위해, 다음과 같은 질문들을 스스로에게 던져보세요.

지금의 환경에서 내가 더 배울 수 있는 것은 없는가?

이 질문은 지금 직장에서 자신이 간과하고 있는 배움의 기회를 되돌아보게 합니다. 예를 들어, 현재 업무가 다소 단조롭다고 느낄 수 있지만, 프로젝트를 다른 관점에서 접근하거나, 특정 기술을 더 깊이 파고들 기회로 삼을 수도 있습니다. 만약 사수나 선배가 있다면, 그들의 노하우를 배우기 위해 의도적으로 질문을 많이 던져보는 것도 하나의 방법입니다. 현재 회사에서 얻을 수 있는 마지막 배움이 무엇인지 탐색해 본다면, 떠나기 전 성장할 수 있는 기회를 최대한 활용할 수 있습니다.

내가 퇴사를 통해 기대하는 변화는 무엇인가?

단순히 현재의 불만에서 벗어나기 위함인지, 아니면 새로운 기회를 통해 특정한 성장을 목표로 하는지 자신에게 물어보세요. 예를 들어, 만약 "지금 회사에서 내가 성장하지 못하고 있다고 느낀다"는 이유라면, 구체적으로 어떤 성장을 기대하는지를 정리해보세요. 기술적 역량을 높이고 싶은지, 더 큰 책임을 맡고 싶은지 등, 구체적인 목표를 세우면 이직할 회사에서 무엇을 중점적으로 찾아야 할지도 명확해집니다.

다음 회사에서도 비슷한 문제에 직면한다면, 나는 어떻게 대응할 것인가?

모든 회사에는 어려움이 있으며, 새로운 곳에서도 예상치 못한 문제가 생길 수 있습니다. 예를 들어, 현재 회사에서 상사와의 소통이 어려웠다면, 다음 회사에서도 비슷한 문제를 겪을 가능성을 염두에 두어야 합니다. 이때는 그저 회피하기보다는, 다음 환경에서는 내가 어떻게 적극적으로 소통을 개선하고 갈등을 조율할 수 있을지 미리 대비해 보세요. 이렇게 하면 반복적인 문제에 더 성숙하게 대응할 수 있습니다. ~~마치 연애처럼요.~~

지금 떠나는 것이 나의 경력에 도움이 될까?

경력 초반에는 여러 회사를 경험하는 것도 좋지만, 너무 자주 이직하면 일관성이 떨어질 수 있습니다. 예를 들어, 프로젝트가 끝나기 직전이라면, 프로젝트를 완수하고 성과를 만들어 경력에 추가하는 것도 좋은 선택일 수 있습니다. 직장에서 한 경험이 경력에 어떤 식으로 도움이 되는지를 생각하고 떠날 시점을 조율해 보세요.

퇴사의 달콤함

이직할 회사가 정해지지 않은 상태에서 퇴사를 결심하는 것은, 특히 커리어 초반의 주니어 개발자들에게 큰 용기가 필요한 일입니다. 현재의 일을 내려놓고 잠시 쉬고 싶은 마음은 충분히 이해됩니다. 그동안 몰아쳤던 업무와 새로운 환경에 적응하느라 쌓인 피로를 떠올리면, 일단 쉬고 싶다는 생각이 자연스럽게 듭니다. 퇴사 후 잠시라도 아무런 부담 없이 쉴 수 있다면 그만큼 달콤한 휴식은 없을 겁니다.

그러나 단지 ‘쉼’만을 위해 퇴사를 결정한다면, 그 달콤함이 영원히 지속되지는 않을 수 있습니다. 시간이 지날수록 재취업에 대한 부담이 슬며시 다가오고, 점점 압박감으로 변할 가능성이 큽니다. 쉬는 동안 충분히 회복하더라도, 커리어 공백에 대한 불안과 경제적인 부담이 동시에 찾아오면서 또 다른 스트레스를 유발할 수 있기 때문입니다.

따라서 쉼이 필요하다고 느끼더라도, 퇴사 후 어떤 방향으로 나아갈지 구체적인 목표와 계획을 세워보세요. 예를 들어, 퇴사 후 3개월 동안은 필요한 기술을 배우거나, 새로운 직장에 도전할 준비를 하며 자기계발에 집중할 수 있을 겁니다. 이렇게 단순한 휴식 이상의 계획을 세워두면, 잠시 멈추더라도 이후의 목표로 인해 막연한 불안감에서 벗어날 수 있습니다.

쉼은 나를 재정비하는 소중한 시간입니다. 다만, 그 시간이 나에게 어떤 의미로 남을지에 대한 고민이 없다면, 달콤했던 쉼은 곧 재취업에 대한 부담으로 바뀔 수 있다는 것을 명심하시기 바랍니다.

에필로그

퇴사를 고민한다는 것은 어쩌면 지금의 자리에서 충분히 행복하지 않다고 느끼는 것일지도 모릅니다. 하지만 퇴사는 누구에게나 큰 결정이며, 특히 커리어 초반에 내리는 퇴사 결정은 그 무게가 더욱 크게 다가올 수 있습니다. 이 글을 통해 스스로의 감정을 조금 더 명확히 바라보고, 내가 진정으로 원하는 것이 무엇인지 되돌아볼 수 있는 계기가 되었기를 바랍니다.

앞으로도 길 위에서 수많은 선택지가 여러분 앞에 놓일 것입니다. 때로는 현재의 환경에서 스스로를 발견할 수 있을 것이고, 때로는 새로운 환경에서 진정한 성장을 이루게 될 것입니다. 어느 쪽이든, 중요한 것은 스스로의 감정과 목표에 솔직하게 귀 기울이며 자신만의 방향을 찾아가는 것입니다. 자신을 이해하고, 그에 맞는 선택을 할 수 있는 힘을 기르며 나아가는 그 여정 자체가 여러분의 커리어를 더욱 빛나게 할 겁니다.

때로는 흔들리고, 때로는 불안해질 수도 있겠지만, 그 과정을 통해 자신이 원하는 삶과 커리어에 조금 더 가까워지길 응원합니다.

"서류합격률 4%를 탈출하는 개발자 이력서 작성법" 강의를 출시했습니다. 신입, 경력 모두를 대상으로 강의가 제작되었으니 이력서 작성이 막막하거나 잦은 서류 탈락을 하고 계시다면 이 강의 수강을 추천드립니다.

서류합격률 4%를 탈출하는 개발자 이력서 작성법 강의 | 강승현 - 인프런

강승현 | 최근 개발자의 서류 합격률은 한 자릿수에 불과합니다. 100명 이상의 이력서를 멘토링한 경험을 바탕으로, 지원자들이 놓치고 있는 이력서 작성의 치명적 실수를 분석했습니다. 이제,

www.inflearn.com

리더가 MSA 전환을 하자고 했다. 그리고 처참히 실패했다.

CODe_ — Sun, 27 Oct 2024 17:32:20 +0900

출처 픽사베이

서론

이 글은 리더, 경영진, 그리고 실무 개발자들을 대상으로 합니다. MSA 전환을 고려하거나 이미 추진 중인 조직의 이해관계자들이, 전환 과정에서 발생할 수 있는 문제와 그 해결 방안을 이해하는 데 도움이 되기를 기대합니다.

마이크로서비스 아키텍처(MSA)는 현재 많은 조직에서 주니어 개발자 채용 공고에도 우대사항으로 언급될 만큼 널리 채택되고 있는 아키텍처 패턴입니다. 그러나 MSA 전환은 단순한 기술 도입 이상의 도전으로, 조직 내 모든 구성원의 협력과 상당한 노력이 필요합니다. 기술적인 변화를 성공적으로 이루기 위해서는 단순히 시스템 구조를 변경하는 것만으로는 충분하지 않습니다. 조직의 문화, 비즈니스 전략, 그리고 운영 모델 전반에 걸친 변화가 필요하며, 이러한 변화는 경영진의 확고한 의지와 실무진의 기술적 역량, 그리고 다양한 부서 간의 긴밀한 협력을 통해서만 이루어질 수 있습니다.

이 글은 MSA의 기본 개념에 대한 사전 지식이 필요하며, 기존 모놀리틱 아키텍처 기반의 대규모 시스템을 MSA로 전환하는 과정에서 발생할 수 있는 실패 요인들을 실무진과 경영진이 마주하는 기술적, 비즈니스적 난관을 중심으로 비판적으로 이야기합니다.

배경

이 글에서 등장하는 배경은 픽션입니다

회사의 기술 리더는 최신 기술 트렌드와 시스템의 확장성을 강조하며 MSA 전환을 추진했습니다. 기존의 모놀리틱 시스템은 유지보수가 어렵고 새로운 기능 추가 시 전체 애플리케이션을 재배포해야 하는 문제들이 있었습니다. 리더는 이러한 문제를 해결하고자 MSA로의 전환을 강력히 주장했고, 경영진도 이에 동의하여 전사적인 프로젝트가 시작되었습니다.

그러나 프로젝트가 진행되면서 예상치 못한 여러 난관에 직면하게 되었습니다. 각 서비스 간의 의존성 관리 문제, 복잡한 트랜잭션 관리, 그리고 전사적인 협력이 부족해지는 등의 문제가 연이어 발생했습니다. 외부 부서의 지원은 불충분했고, 각 팀은 자신의 업무에만 집중하며 협업이 원활히 이루어지지 않았습니다. 또한, 기술적인 난이도와 학습 곡선이 높아 일부 팀원들은 새로운 기술 스택에 적응하기 어려움을 겪었습니다.

경영진은 초기 계획보다 비용이 더 많이 들고 프로젝트가 지연되자 점차 불안해졌고, 이러한 불확실성은 실무진의 사기 저하로 이어졌습니다. 프로젝트 설계 전, MSA 전환 경험이 있는 SI 업체와도 계약했지만, 실제 코드 작성을 담당한 계약업체 실무진의 기술 수준이 기대에 미치지 못해 코드의 확장성과 유지보수성이 떨어지는 문제가 발생했습니다. 계약업체 실무진들은 프로덕트를 완성하는 것에만 집중했기 때문에 코드의 품질이 낮아졌고, 이는 프로젝트의 장기적인 성공 가능성을 더욱 낮추는 요인이 되었습니다. 결국, 경영진은 프로젝트 중단을 고려하기에 이르렀고, 실무진은 계속되는 업무 변화와 과도한 요구, 데드라인 압박에 지쳐 퇴사를 선택하는 사람들도 생겨났습니다.

이러한 가상의 시나리오를 바탕으로 MSA 전환에서 실패할 수 있는 다양한 요인들을 나열하고 구체적으로 어떤 상황인지 전달합니다.

MSA 한 입

마이크로서비스 아키텍처(Microservices Architecture)는 대형 애플리케이션을 여러 개의 독립적인 작은 서비스로 분리하여 관리하는 방식입니다. 각 서비스는 특정 기능을 수행하며, 독립적으로 개발, 배포, 확장이 가능합니다.

기존 모놀리틱 아키텍처에서는 모든 기능이 하나의 거대한 애플리케이션에 통합되어 있어 새로운 기능 추가나 수정 시 전체 애플리케이션을 다시 배포해야 하는 비효율성이 존재했습니다.

반면, MSA에서는 각 기능이 독립적인 서비스로 나뉘어 있어 개별적으로 개발 및 배포가 가능하여 확장성과 유지보수 측면에서 훨씬 유리합니다. 이러한 이점을 기대하며 많은 기업이 MSA를 도입하기 시작했습니다.

그러나 MSA 전환은 단순한 기술 도입을 넘어, 조직 전반의 문화적 변화를 요구하기도 합니다. 팀 단위의 자율성과 책임감 강화, 서비스 간 명확한 경계 설정(의존 분리), 배포와 모니터링의 자동화 등 다양한 요소들이 함께 고려되어야 합니다.

설계부터 잘못된다면

어? 순서 보장 안돼요?

기존 모놀리틱 아키텍처에서는 트랜잭션 관리가 비교적 단순했지만, MSA로 전환하게 되면 분산된 서비스 간 트랜잭션 관리를 위한 부담이 증가합니다. 각 서비스가 독립적으로 운영되기 때문에 기존의 일관된 트랜잭션 관리가 어려워지고, 이를 해결하기 위해 분산 트랜잭션을 위한 SAGA 패턴, 이벤트 드리븐 아키텍처 등 복잡한 설계를 도입해야 합니다.

특히, 이러한 패턴들은 실시간으로 발생하는 대규모 트래픽에 대응할 수 있도록 충분히 성숙된 상태에서 적용되어야 하며, 이는 시스템의 신뢰성과 안정성을 보장하는 데 중요한 요소로 작용합니다.

또한, 데이터 일관성 유지 역시 큰 도전 과제입니다. 모놀리틱 환경에서는 단일 데이터베이스를 사용하여 일관성을 유지하기가 상대적으로 용이했으나, MSA 환경에서는 각 서비스가 독립적인 데이터베이스를 가지므로 데이터 동기화와 일관성을 유지하기 위한 전략이 필수적입니다. 이를 해결하기 위해 데이터 이벤트 소싱이나 CQRS(Command Query Responsibility Segregation)와 같은 패턴을 적용할 수 있지만, 이러한 패턴의 적용에는 높은 기술적 이해와 경험이 요구됩니다. 더 나아가, 비즈니스에 대한 높은 이해만으로는 데이터 정합성 문제가 발생할 수 있는 리스크를 내포하고 있습니다. 기술적인 이해도가 부족할 경우 각 서비스 간 데이터 불일치나 동기화 실패로 인해 비즈니스적인 문제로 확산될 가능성도 존재합니다.

또한, MSA 전환에 필요한 다양한 스택(Redis, Kafka, k8s 등)이 어떻게 작동하는지에 대한 이해도 필수적입니다. 각각의 특성과 사용 방법을 정확히 이해하고 있어야 효과적으로 설계를 진행할 수 있기 때문이죠. 그러나 이러한 기술을 단기간에 충분히 습득하고 응용하는 것은 쉽지 않으며, 이로 인해 설계 단계에서 결함이 발생할 위험이 존재합니다.

캐시가 죽으면? 디비도 죽으면? 서버도 죽으면?
쿠버네티스도 죽으면?

또한, 오버 엔지니어링 문제도 고려해야 합니다. MSA는 각 서비스의 독립성을 보장하기 위해 다양한 Fallback 메커니즘을 도입해야 할 때가 많습니다. 예를 들어, 서버가 다운되거나, 데이터베이스가 실패하거나, 캐시가 손실될 경우, 이벤트가 유실될 경우 등 이를 대비한 여러 계층의 Fallback을 설계하게 되는데, 이러한 과정을 적정선에서 절제하지 못하면 오버 엔지니어링으로 이어질 수 있습니다. 즉, 복잡성을 무작정 높이는 것이 아니라, 비즈니스 가치와 기술적 필요성을 균형 있게 고려하여 최적의 솔루션을 도출하는 것이 중요합니다. 이러한 역량 또한 결국 MSA에 대한 깊은 이해와 연관있죠.

유관 부서가 협조를 안해준다

우리 팀도 바빠서요
지금은 어렵네요

대규모 프로젝트일수록 유관 부서의 협조는 필수적입니다.

각 부서 간 의존성이 크기 때문에, MSA 전환 과정에서 다른 부서의 적극적인 지원이 없으면 프로젝트 성공 가능성이 낮아질 수밖에 없습니다. 특히, 부서 간 의사소통의 원활함이 전환의 성패에 큰 영향을 미칩니다.

MSA 전환은 단순히 개발 부서의 문제로 그치지 않고, 운영, 보안, 인프라, 코어 등 다양한 부서와의 긴밀한 협력이 요구됩니다. 만약 이러한 부서 간의 협업이 원활하지 않을 경우, 서비스의 독립성과 자율성이 오히려 프로젝트의 발목을 잡는 요인이 될 수 있습니다.

쉽게 말해, 우리에겐 당장 필요한 정보인데, 유관 부서에서는 중요 업무가 아니어서 제공 우선순위가 낮아지는 상황말이죠. (나만 급한 상황)

특히 외부 조직의 협조를 이끌어내기 위해서는 그들에게도 동기를 부여하는 것이 중요합니다. 우리에게는 MSA 전환이 큰 성과일 수 있지만, 외부 조직에게는 그저 부가적인 업무로 인식될 수 있기 때문에 우선순위가 낮아질 가능성이 큽니다.

이를 해결하기 위해 MSA 전환을 전사적인 목표로 설정하고, 서포트하는 조직에도 혜택이 돌아가도록 설계하는 방법을 고려해야 합니다. 이러한 역할은 주로 경영진의 적극적인 개입과 지원을 통해 이루어질 수 있으며, 이를 통해 조직 전체의 협력을 이끌어내는 것이 필수적입니다.

따라서 조직 내에서 명확한 책임 분담과 협업 구조가 필요하며, 이를 위한 커뮤니케이션 도구와 절차를 마련해야 합니다.

다른 부서는 왜 공감하지 못하는가

개발자들은 MSA의 장점인 독립적 배포와 확장성을 충분히 이해할 수 있지만, 비개발 부서에서는 이러한 기술적 이점을 쉽게 공감하지 못할 수 있습니다. 특히 고객에게 가시적인 변화가 없는 상황에서는, 신규 개발이 지연되거나 기존 업무가 지체될 경우 MSA 전환이 불필요한 업무로 인식될 가능성이 큽니다. MSA로의 전환은 비개발 부서에게는 비용 증가, 일정 지연, 복잡성 증가로 느껴질 수 있으며, 이러한 부정적 인식을 변화시키기 위해서는 경영진과 비개발 부서에게 기술적 전환이 가져올 장기적인 비즈니스 가치를 명확하게 전달해야 합니다.

결국, 경영진의 지원이 필수적입니다. 경영진은 기술적 전환이 단기적인 비용 증가와 리소스 할당 문제를 수반할 수 있음을 이해하고, 이를 통해 얻을 수 있는 장기적인 비즈니스 이점에 대해 충분히 납득해야 합니다. 경영진 간에도 상호 설득이 필요하며, 특히 큰 규모의 전환일수록 전사적인 협조가 중요합니다. 이러한 협조는 경영진이 직접 이끌어내야 하며, 이를 위해서는 MSA의 도입이 조직의 비즈니스 목표 달성에 어떻게 기여할 수 있는지에 대한 명확한 비전과 구체적인 계획을 제시할 필요가 있습니다.

하지만, 말이 쉽지 타 부서의 공감을 바라는 것은 현실적으로 많이 어렵습니다.

고독한 싸움을 하는 여러분을 응원합니다.

비용 을 구체적으로 고려했는가

한 달에 5억이라고?

기존 모놀리틱 구조에서는 특정 서비스에 트래픽이 몰리더라도 전체 애플리케이션을 확장해야 했습니다. 반면, MSA는 각 서비스를 개별적으로 확장할 수 있으므로 클라우드 환경에서의 비용 효율성을 기대할 수 있습니다. 하지만 이러한 확장은 클라우드 서비스 사용에 따른 비용 관리의 복잡성을 수반합니다. (AWS 비싸요)

MSA의 특성상 각 서비스가 별도의 인프라 자원을 필요로 하게 되고, 이는 곧 클라우드 자원 사용의 증가로 이어질 수 있습니다. 이러한 비용은 각 서비스의 사용 패턴, 스케일링 요구사항, 데이터 처리량 등에 따라 크게 달라질 수 있으며, 예측이 어려운 경우도 많습니다.

또한, MSA는 각 서비스의 독립성을 보장하기 위해 여러 개의 데이터베이스와 네트워크 인프라를 필요로 하며, 이는 운영비용의 증가를 초래할 수 있습니다. 클라우드를 사용한다면 운영 비용 예측의 정확성을 높여야 하며, 온프레미스 환경도 함께 고려해야 합니다.

클라우드 비용을 정확히 예측하고 이를 경영진에게 설득하는 과정은 MSA 전환의 중요한 과제 중 하나입니다. 비용 절감이 아닌 비용 증가로 이어질 수 있는 부분을 간과한다면 경영진의 신뢰를 잃을 수 있으며, 이는 프로젝트의 중단으로 이어질 수 있습니다. 또한, Kubernetes(K8s)를 사용한다고 해서 무작정 확장하는 것은 Silver Bullet이 아닙니다. 확장 전략은 신중하게 계획되어야 합니다.

수레를 끌 힘이 있는 조직인가

MSA 전환의 성공 여부는 리더의 경험과 실무진의 기술적 역량에 크게 의존합니다. 일부 기업은 MSA 경험이 풍부한 리더를 TF 리더로 선출하고 소수의 숙련된 인원으로 TF 조직을 구성하여 성공적인 MSA 전환을 이끌어냅니다. 그러나 리더와 실무진 모두 경험이 부족하거나 외부 컨설팅에만 의존한다면 성공 가능성은 매우 낮다고 생각합니다. MSA 전환에는 기술적 지식뿐만 아니라, 팀원 간의 원활한 협력, 문제 해결을 위한 사고, 다양한 도구와 기술 스택의 이해 등 복합적인 역량이 요구되기 때문이죠.

SI와의 계약도 신중해야 합니다. 리더들이 아무리 경험이 풍부하고 솔루션 프로덕트가 많다고 해도, 실제 코드를 구현하는 실무진은 그렇지 않을 수 있거든요.
시간이 지나 계약이 종료되고 SI는 떠나고, 유지보수나 기능 확장이 어려운 대환장 파티가 열릴 수 있습니다.

실무진은 대규모 프로젝트의 트래픽 처리, 트랜잭션 관리, 배포 전략, 모니터링 등 다양한 기술적 도전 과제를 해결할 수 있는 역량을 갖춰야 하며, 이를 위한 교육과 학습도 필수적입니다. 또한, 기술적 역량 외에도 각 서비스의 비즈니스 가치를 이해하고 이를 기반으로 최적의 기술적 결정을 내릴 수 있는 비즈니스적 역량도 중요합니다. 기본적으로, 실무진의 역량을 강화하고, 내부적으로 MSA 전환을 주도할 수 있는 전문가를 양성하는 것이 필요합니다.

구현 디펜던시

아, 또 변경됐어요?
아, 또 추가됐어요?

기존 하나의 서비스를 A와 B 두 개의 서비스로 나눈 상황을 가정해 봅시다. B 서비스는 "회원이 보유한 카드 정보 조회" API를 제공해야 하지만 아직 구현되지 않았고, A 서비스는 이 정보를 필요로 합니다. 따라서 A 서비스는 B 서비스가 완성되기 전까지 모킹된 응답을 사용하게 되며, 이후 요건이 변경되면 모킹을 수정하고 A 서비스도 다시 구현해야 합니다.

이러한 의존성 문제는 서비스 간의 설계와 구현의 일관성을 유지하는 데 큰 도전 과제가 되죠. 서비스 간 의존성으로 인한 이러한 복잡성은 프로젝트 진행 속도를 크게 저하시킬 수 있으며, 서비스가 많아질수록 이러한 문제는 더 악화됩니다.

더욱이 서비스 간 의존성이 복잡해지면, 잦은 요건 변경과 의존성 문제로 인해 하나의 업무에 집중하기 어려운 환경이 조성될 수 있습니다. (안그래도 바쁜데 여기저기서 업무들이 동시다발적으로 치고 들어오는 상황을 떠올려보세요)

구현 중에도 새로운 요구사항을 반영하고, 모킹된 데이터를 실제 서비스로 변경하며 이를 조율해야 하는 등의 이슈가 발생할 수 있는거죠. 이를 해결하기 위해서는 서비스 간 명확한 역할 및 상호작용 규칙을 정의하고, 초기 설계 단계에서 잠재적인 비즈니스 변경 사항이나 미래 기능 확장 가능성을 고려하여 API 포맷을 신중하게 설정해야 합니다. 한 번 설계가 됐다면 추후에 "아 나중에 이 상품이 추가된다면?" 같은 생각은 하지 않는 것이 모두에게 행복한 길일 수 있습니다.

결국 리더는, 실무진들의 업무를 효과적으로 관리할 수 있는 체계를 구축해야 합니다. 또한, 설계 단계에서 실질적인 대안을 마련하여 변경이 필요할 때의 혼란을 줄이는 것이 중요합니다.

흔들리는 경영진, 퇴사하는 실무진

저도 실패할까 봐 무서워요
(by. 경영진)

위와 같은 이유들로.. MSA 전환 과정에서 리더는 예상치 못한 리스크에 직면할 수 있습니다. 리더의 불확실한 결정은 실무진의 불안감을 가중시키며, 이는 프로젝트의 사기 저하로 이어질 수 있습니다.

특히 MSA 전환은 초기 단계에서 비용과 복잡성이 증가할 수 있어 리더 또는 경영진이 기대한 성과를 단기간 내에 달성하기 어렵다는 점에서 불안감을 초래할 수 있죠. 이러한 상황에서 리더나 경영진이 명확한 비전과 일관된 지원을 제공하지 못한다면, 실무진은 프로젝트의 방향성에 의문을 가지게 되고, 이는 사기 저하로 이어질 수 있습니다.

~~(좋게 표현해서 사기저하이고 퇴사할 수도 있습니다)~~

경영진의 확고한 지원과 실무진의 사기 유지는 프로젝트 성공의 중요한 요소입니다. 이를 위해 경영진은 MSA 전환의 장기적 목표와 이에 따른 성과를 명확히 제시하고, 실무진이 이를 달성하기 위한 명확한 역할과 책임을 부여해야 합니다. 또한, 실무진이 기술적 도전 과제를 해결할 수 있도록 필요한 리소스와 지원을 아끼지 않아야 하며, 이를 통해 실무진의 자율성과 책임감을 고취시켜야 합니다.

결론

MSA 전환은 많은 장점을 제공하지만, 이를 성공적으로 이루기 위해서는 기술적 역량, 조직 내 협력, 명확한 비즈니스 목표 설정 등이 필수적입니다. 충분한 준비와 경험이 없다면 MSA 전환은 실패할 가능성이 높습니다.

실무진의 기술적 역량 강화뿐 아니라, 리더나 경영진의 명확한 지원, 부서 간 협력 강화가 필수적으로 뒷받침되어야 합니다.

또한, 기술적 도전 과제를 해결하기 위한 체계적인 계획 수립, 각 부서 간의 원활한 의사소통, 비용에 대한 명확한 이해와 관리 등 여러 요소들이 종합적으로 작용해야 합니다.

즉, 단순히 기술적 전환을 넘어, 조직 문화와 운영 방식 전반에 걸친 변화를 수반해야 합니다. 성공적인 MSA 전환을 위해서는 조직 내 모든 구성원이 그 가치를 이해하고, 이를 달성하기 위해 함께 노력하는 환경이 조성되어야 할 것입니다.

지금도 어디선가 MSA 전환에 힘쓰고 있는 모든 실무진과 리더들을 응원합니다.

서류합격률 4%를 탈출하는 개발자 이력서 작성법 강의 | 강승현 - 인프런