티스토리 뷰
첫 멘토링 회고
오늘 LGCNS AM 부트캠프 파이널 프로젝트 첫 멘토링이 있었다. 멘토님은 카카오뱅크 웹서비스 개발팀에 재직 중이신 현업 개발자분이었다. 궁금했던 것들을 진짜 거의 다 물어봤고, 생각보다 훨씬 솔직하게 답해주셔서 인상 깊었다!!
카카오뱅크가 뭐 하는 회사인지부터
나는 카카오뱅크랑 카카오페이를 막연하게 비슷한 서비스라고 생각했었다. 근데 정확히 다르다.
- 카카오페이 → 핀테크 회사. 토스랑 비슷한 포지션
- 카카오뱅크 → 은행. 토스뱅크랑 비슷한 포지션. 제1금융권
은행업 라이선스를 가진다는 게 생각보다 훨씬 큰 차이였다. 하나은행, 국민은행과 같은 레벨이라는 거고, 그만큼 규제가 훨씬 많다.
현업에서 MSA는 어떻게 쓰나
이게 제일 궁금했던 부분이었다.
"모놀리식이 나쁜 게 아니라, 도메인에 맞는 아키텍처를 고르는 게 맞다."
결국 MSA가 나온 이유는 불편함에서 나온 거다. 빌드 한 번에 30분 걸리는 모놀리식 서비스를 경험하면서 "이 기능만 따로 빌드하고 싶다"는 니즈가 쌓여서 마이크로서비스라는 개념이 나온 것.
모놀리식 → MSA 전환은 어떻게 하나
서비스를 운영 중인 런타임에 전환하는 건 생각보다 훨씬 어렵다. 한 가지 방법은 트래픽을 점진적으로 꺾는 것이다.
기존 서비스 [100%] → [50%] → [0%]
신규 서비스 [ 0%] → [50%] → [100%]
1%로 흘려보다가 문제없으면 50%, 그다음 100%로 전환. 기존 소스 코드 "찌꺼기"는 한동안 남아있을 수밖에 없다.
아예 한 번에 서비스를 내리고 전환하는 IPL 작업도 있다. 카카오뱅크도 체크카드 서비스를 이렇게 전환한 사례가 있다고 했다. 토요일 밤 11시 시작, 일요일 아침 9시 오픈 이런식?
코어뱅킹(Core Banking)이란
은행 서비스는 크게 두 레이어로 나뉜다.
- 코어뱅킹 (계정계): 실제 돈이 오가는 곳. 입출금, 이체 처리. 전문통신 방식으로 구성됨
- 채널: 코어뱅킹을 조합해서 비즈니스 로직을 만드는 곳. "26주 적금" 같은 상품이 여기서 만들어짐
전문통신이란 건 JSON처럼 필드 이름이 있는 게 아니라, 고정 길이 문자열로 통신하는 방식이다. "1번~3번 자리 = 계좌번호, 4번~10번 자리 = 금액" 이런 식.
코어뱅킹 쪽에는 도메인 지식(수신/여신 등)이 많이 요구되고, 채널/웹서비스 쪽은 일반적인 기술 스택에 더 가깝다.
클라우드 현황과 규제
금융권에서는 규제상 핵심 시스템을 클라우드에 올리는 데 제약이 있어 온프레미스를 병행하는 경우가 많다. DR(재난복구) 환경 인정 기준이 엄격하기 때문이다. 금융권에서 클라우드를 쓰면서도 규제와 씨름하는 게 실제로 진행 중인 현실이었다.
기술 선택의 논리
"이걸 사용해보고 싶어서 쓴다는 건 실무에서 안 통한다. 이런 단점이 있기 때문에 이 기술이 필요했다는 논리가 있어야 한다."
포트폴리오 프로젝트를 만들 때도 이 관점은 중요하다고 느꼈다.
EKS를 왜 썼냐 → "MSA 서비스의 독립 배포와 스케일링이 필요해서"
Kafka를 왜 썼냐 → "서비스 간 결합도를 낮추고 비동기 처리가 필요해서"
기술의 장단점을 알고, 그 단점을 해결하기 위해 다른 기술을 선택했다는 흐름이 있어야 설득력이 생긴다.
카프카 vs RabbitMQ — 언제 뭘 쓰나
프로젝트 할 때 항상 헷갈렸던 부분인데 오늘 드디어 정리됐다.
핵심 차이는 푸시(Push) vs 풀(Pull)이다.
RabbitMQ는 메시지를 지정된 컨슈머에게 강제로 밀어넣는 푸시 방식이다. 메시지가 전달되면 큐에서 사라진다. 전달 보장이 핵심.
Kafka는 토픽에 메시지를 쌓아두고, 컨슈머가 알아서 당겨가는 풀 방식이다. 데이터가 보존되어 있어서 다른 그룹 ID로 붙으면 같은 데이터를 처음부터 다시 읽을 수 있다.
Kafka 토픽
├── 그룹A (오프셋 1000번까지 소비) → 1001번부터 계속
└── 그룹B (신규 연결) → 0번부터 다시 소비 가능
파티션 개념도 중요하다. 파티션 4개면 컨슈머 4개가 각각 나눠서 처리하는 게 가장 효율적이다. 컨슈머가 3개라면 파티션 하나에 2개가 붙게 되고 처리 불균형이 생긴다. 파티션 수와 컨슈머 수를 짝수로 맞춰주는 게 중요한 이유가 이거다.
EFK 스택이란
로그 수집 아키텍처를 이야기하다가 EFK 스택 설명을 들었다.
원래 ELK 스택이 전통적인 조합이다.
- E (Elasticsearch): 비정형 로그를 인덱싱해서 검색에 특화된 데이터 스토어
- L (Logstash): 어플리케이션에서 로그를 수집해서 Elasticsearch로 보내는 역할
- K (Kibana): 쌓인 데이터를 시각화하는 대시보드
근데 Logstash가 컨테이너 환경에서 너무 무겁다. 몇 백 MB짜리를 모든 컨테이너에 포함시키기가 부담스럽다. 그래서 Logstash 대신 Fluent Bit / Fluentd를 쓰는 게 EFK 스택이다. 쿠버네티스 환경에서는 EFK가 훨씬 적합하다.
그리고 한 가지 재밌는 역사가 있다.
Elastic(Elasticsearch 만든 회사)이 AWS랑 크게 싸운 적이 있다. AWS가 Elasticsearch를 자기들 매니지드 서비스에 올려서 장사를 너무 잘했고, Elastic은 라이선스를 바꿔서 클라우드 벤더가 못 쓰게 막았다. AWS는 그 직전 버전을 포크해서 OpenSearch라는 걸 따로 만들어버렸다.
그래서 지금은 Elasticsearch와 OpenSearch가 별개로 존재한다. 실제로 우리가 쓰게 될 건 OpenSearch 기반 EFK일 가능성이 높다.
Ingress — AWS ALB vs Nginx 중 뭘 써야 하나
쿠버네티스에서 외부 트래픽을 받을 때 Ingress를 쓰는데, 구현체 선택이 늘 헷갈렸다.
Ingress 자체는 "단일 진입점으로 트래픽을 받아서 내부로 라우팅"하는 개념이고, 그 구현체는 여러 가지다.
- AWS ALB Ingress Controller: AWS에서 만든 거라 EKS랑 궁합이 좋다. 설정도 빠르다.
- Nginx Ingress Controller: 직접 컨트롤 가능. AWS 종속 없음.
- Traefik 등 다른 선택지도 있다.
EKS에서 빠르게 띄우려면 ALB가 편하다. 매뉴얼도 많고 AWS 네이티브라 설정이 간단하다. 반면 Nginx는 직접 설정해야 할 게 좀 더 있지만 AWS 외 환경에서도 쓸 수 있고 커스터마이징 폭이 넓다.
AI 도구 사용 현황
멘토님 회사에서는 Claude Code, Codex, Gemini Enterprise 세 가지를 쓰고 있고, 결국 대부분의 개발자들이 Claude로 정착하는 흐름이라고 하셨다. (Claude Sonnet 4.5 기준으로 거의 이길 수 없다고...)
내부망에서 쓸 수 있는 모델은 외부보다 한 버전 느리게 들어오는 편이라고 한다. 규제와 보안 검토 때문에 그렇다고 하셨다
그리고 팀에서 실제로 쓰는 기술들을 쭉 말씀해주셨다!
앞으로의 방향
오늘 멘토링에서 가장 크게 가져가는 건 두 가지다.
1. 기술 선택에는 이유가 있어야 한다 파이널 프로젝트에서 어떤 기술을 쓸지 정할 때, "써봤으니까"가 아니라 "기존 방식의 어떤 한계 때문에 이 기술이 필요하다"는 논리를 먼저 세우기.
2. Kafka 파티션 설계 제대로 해보기 이전 Autonix 프로젝트에서 Kafka를 썼는데 파티션 수를 그냥 대충 정했었다. 컨슈머 수와 파티션 수를 맞추는 이유를 이제 이해했으니, 이번 프로젝트에서는 의도적으로 설계해보기.
이외에도 더 있지만 비밀이다. ㅎㅎ
다음 멘토링이 정말정말 기대된다!!