뱅크샐러드 AI Native Server Engineer

뱅크샐러드는 데이터 ​서비스로 ​유저들의 ​삶을 이롭고 ​풍요롭게 합니다.

뱅크샐러드의 미션은 유저가 ​자신의 ​정보를 언제 ​어디서나 쓸수 있는 ​환경을 만들고, ​유저 ​이익이 극대화된 ​디지털 ​경험을 ​설계하는 것입니다. 우리는 ​사람들에게 ​가장 중요한 가치인 ​'돈'과 ​'건강' ​분야에 특히 집중하고 ​있습니다.

혁신적인 생각을 ​담은 ​제품을 끊임없이 ​내는 회사가 ​스타트업이라고 ​생각합니다.

우리는 자동 가계부(2017), ​금융 통합 ​조회 (2018), 소비 기반 카드 추천(2018), 대출 비교 서비스(2019), 신용 점수 올리기(2019), 금융 비서 (2020), 마이데이터 (2022), 무료 유전자 검사(2023), 건강 맞춤 보장 분석 (2024), 샐러드 게임(2025), 최저금리 알리미(2025)를 국내 최초로 출시하며 혁신성을 입증해 왔습니다.

최근 2년간 월 매출은 800% 성장하였고 월 경상 이익(BEP)을 돌파하여 지속가능성과 안정성을 확보하였습니다. 금융과 건강을 아우르는 데이터 시너지를 바탕으로 금융업으로 확장해 나감으로써 5년 뒤에는 디지털 금융 지주 회사, 10년 뒤에는 정보를 회사의 핵심 자산으로 각종 사업을 확장해 나가는 데이터 지주 회사가 되고자 합니다.

한계 없이 문제를 해결하는 문화, 데이터를 가장 안전하게 잘 활용하는 프로세스를 함께 만들고, 제품과 비즈니스에서 실질적 성과를 만들고자 하는 도전 정신 충만한 동료들과 함께하고 싶습니다.

포지션 상세

주요업무

뱅크샐러드 AI Native Engineer는 이렇게 일합니다.

뱅크샐러드의 AI Native Engineer는 AI 기반 개발 도구를 활용해 생산성을 극대화하고, 제품 개발에 투입되어 기존 개발 프로세스를 효율화합니다. 단순한 기능 구현에만 머물지 않고, AI 도구를 적극적으로 적용하여 코드 품질과 개발 속도를 높이고, 팀 전체의 효율성을 제고하는 데 중점을 둡니다. 또한, 비즈니스 임팩트를 고려한 설계를 논의하고, 고가용성의 안정적인 서비스를 만들기 위해서 고민하고 있습니다.

새로운 기술이나 아키텍처를 도입할 때도 단순히 트렌드를 좇기보다는 현재 팀의 문제를 가장 효과적으로 해결할 수 있는 기술을 신중하게 선택합니다.

우리는 장기적으로 안정적이고 확장 가능한 시스템과 지속 가능한 개발 문화를 만드는 것을 더 중요하게 생각합니다. 엔지니어들은 언제든지 자유롭게 의견을 주고받으며 함께 성장하고 있습니다.

시장상황에 맞는 빠른 제품 개발과 개선, 높은 품질이 보장된 개발을 위해서 우리는 아래와 같은 프로세스와 문화를 유지하고 끊임없이 개선하고 있습니다.

[프로덕트 스펙 작성 및 검토]

개발 전 기획 단계부터 명확한 비즈니스 로직을 정리하고, 요구사항이 누락되거나 비효율적이지 않은지 미리 검토하여 개발 과정에서 발생할 수 있는 문제를 최소화합니다.

[테크 스펙 문서화와 협업]

시스템 설계 단계에서부터 명확한 기술 스펙을 작성하여 동료 엔지니어들의 리뷰를 받습니다. 이 과정에서 시스템 구조, 성능 최적화, 보안 이슈 등을 미리 논의하여 보다 탄탄한 기반 위에 개발을 진행합니다.

[활발한 코드 리뷰 문화]

다양한 관점과 경험을 가진 동료 엔지니어들의 활발한 코드 리뷰를 통해 코드 품질을 지속적으로 높이고, 개인뿐 아니라 팀 전체의 기술 역량 성장을 도모합니다.

이러한 체계적이고 명확한 프로세스를 통해 서버 엔지니어들은 안정적이고 유지보수가 쉬운 코드를 자신감 있게 작성하며, 복잡한 문제에 높은 집중력으로 몰입할 수 있는 환경을 만들고 있습니다.

AI 시대의 선두에서 혁신을 만들어갑니다.

뱅크샐러드 Tech 조직에는 전담 Data AI & Productivity팀이 존재하며, 전사적 생산성 향상과 시스템 최적화를 위해 AI 기술을 적극적으로 활용하고 있습니다.

단순히 외부의 AI 도구를 도입하는 수준을 넘어, 우리가 가진 데이터와 도메인에 최적화된 독창적인 금융 AI AGENT를 개발하여 실질적인 성과를 만들어 나가고 있습니다.

[지속적인 최신 AI 기술 연구 및 적용]

MCP(Model Context Protocol)를 활용한 데이터와 AI 기반 개발 워크플로우 개선 AI 지원 기반 코드 리뷰 및 자동화된 테스팅 시스템 구축

AI 기술의 활용은 이제 시작 단계에 불과하지만, 뱅크샐러드는 끊임없는 도전과 실험을 통해 업계 최고 수준의 AI 활용 역량을 쌓아가고 있습니다. AI Native Engineer로서 AI 시대의 혁신적인 서비스와 개발 문화를 함께 만들어갈 동료를 찾고 있습니다.

뱅크샐러드 서버 챕터의 엔지니어는 이렇게 일하고 있어요.

[체계적인 기술 문서화와 협업 중심의 코드 리뷰]

뱅크샐러드 서버 엔지니어는 Tech Spec 문서를 기반으로 코드 작성 전 기술적 설계 사항을 문서화하고, 다양한 엔지니어들과 피드백을 주고받으며 품질을 높이고 있습니다. 이를 통해 문제 발생을 예방하고, 명확한 구조와 로직을 미리 설계하여 개발 효율을 높이고 있습니다. 키워드: Tech Spec, 기술 설계 문서화, 코드 리뷰 문화, 예방적 품질 관리

[안정성과 성능 최적화를 위한 인프라와 프로세스]

AWS EKS 기반의 Kubernetes 환경과 MSA 구조를 적극적으로 활용하여, 트래픽 급증 상황에서도 유연하고 빠르게 대응할 수 있는 인프라를 구축했습니다. Kafka, Redis, Aurora MySQL 등 다양한 분산 기술을 적용해 고성능·고가용성의 서비스 환경을 안정적으로 유지하고 있습니다. 키워드: Kubernetes(EKS), Kafka, SQS, Redis, Aurora MySQL, 분산 아키텍처, 고가용성, 트래픽 대응

[데이터 기반의 성과 검증과 A/B 테스트]

서버 엔지니어는 개발된 기능의 성과를 데이터 분석과 A/B 테스트를 통해 정량적으로 측정합니다. 단순히 기능 구현에 그치지 않고, 비즈니스 임팩트를 직접 확인하며 제품의 성과를 지속적으로 개선합니다. 키워드: 데이터 기반 의사결정, A/B 테스트, 제품 성과 측정, 지속적 개선

[마이데이터, 금융, 헬스케어 데이터 전문성과 도메인 이해]

마이데이터 사업자로 금융과 건강 데이터를 다루는 업계 최고 수준의 도메인 전문성을 가지고 있습니다. 사용자의 금융 행동과 건강 데이터를 결합하여 개인 맞춤형 서비스로 높은 사업적 성과를 내고 있으며, 뱅크샐러드만의 고유한 비즈니스 경쟁력을 만듭니다. 키워드: 마이데이터, 금융 데이터, 건강 데이터, 도메인 전문성, 개인 맞춤형 서비스, 차별적 경쟁력

[혁신적이고 독창적인 AI 활용 및 자동화]

전담 Data-AI&Productivity팀과 함께 서버챕터의 서버 엔지니어는 AI 코딩 어시스턴트를 활용한 개발 생산성 향상 및 AI가 결합된 서비스 개발, 서비스 운영 효율화에 적용하기 위한 다양한 노력과 시도를 하고 있습니다. 키워드: AI coding assistant 활용, 서비스 운영 효율화

[문제 해결 중심의 개발 문화]

서버 엔지니어는 단순히 주어진 업무를 수행하는 것을 넘어서, 실제 사용자에게 가치를 전달하기 위한 기술적 문제 해결에 끊임없이 몰두합니다. 동료들과의 적극적인 협업을 통해 더 나은 창의적 해결책을 찾아 적용하며, 다양한 직군과의 자율적이고 긴밀한 협업을 통해 기술적 문제를 해결하고 제품 성장을 이끕니다. 키워드: 문제 정의와 해결, 주도적 협업, 사용자 중심 사고, 실행 중심 문화

[지속 가능한 개발 환경과 성장 중심의 문화]

정기적인 회고와 1:1 미팅을 통해 개인의 기술적 성장과 팀의 협업 방식을 지속적으로 점검하고 개선합니다. 심리적 안정감을 바탕으로 자유롭게 의견을 나누며, 엔지니어 개인과 팀, 회사 모두가 함께 성장해서 고객에게 가치를 전달할 수 있는 지속 가능한 개발 문화를 만들어가고 있습니다. 키워드: 정기 회고, 1on1, 심리적 안정감, 지속 성장이 가능한 개발 문화

뱅크샐러드 AI Native Server Engineer는 이러한 업무들을 주로 수행합니다.

[AI 기반 개발 생산성 향상과 반복 작업의 자동화]

AI 개발도구를 활용해 반복적인 운영 작업을 자동화하고, AI 코드 리뷰와 동료 엔지니어의 코드 리뷰를 통해서 개발 생산성과 품질을 극대화합니다. 더 나은 개발 환경 개선을 위해서 Data AI & Productivity 팀과 지속적으로 개선방안을 찾고 적용합니다. 키워드: AI 자동화, 개발 생산성, 코드 리뷰 자동화, 운영 효율화

[고성능 고가용성 서비스 개발]

대용량 트래픽과 복잡한 금융 로직을 안정적으로 처리하는 API 및 백엔드 서비스를 개발합니다. 마이데이터, 대출 중개, 신용카드 혜택 계산, 보험 진단 등 고성능이 요구되는 금융 도메인 문제를 해결하며, 동시성 처리, 분산 트랜잭션, 성능 최적화 등 기술적 도전이 풍부한 환경에서 일합니다. 키워드: Go, Kotlin, Python, 고성능, 고가용성, 분산처리, 동시성 처리

[Kubernetes(EKS) 기반의 클라우드 인프라 운영]

AWS EKS 기반의 Kubernetes 환경에서, 확장 가능하고 안정적인 서비스 인프라를 구축하고 운영합니다. 모니터링 시스템을 통해 트래픽 변화와 성능 이슈를 실시간으로 대응하며, 장애 상황에서도 높은 가용성을 유지합니다. 키워드: Kubernetes, AWS EKS, 클라우드 네이티브, 서비스 가용성, 실시간 모니터링

[Clean Architecture 및 MSA 구조]

Clean Architecture와 MSA 구조를 기반으로 책임이 명확하게 분리된 확장 가능한 코드베이스를 유지합니다. 기술 부채를 줄이기 위한 정기적인 리팩토링과 코드 품질 개선을 주도적으로 실행합니다. 키워드: Clean Architecture, MSA, 확장성, 코드 품질

[다양한 데이터 처리 기술 활용]

Redis, Aurora MySQL, Kafka 등을 통해 서비스 간 안정적인 실시간 데이터 처리를 구현합니다. Redis 기반의 분산 캐싱과 Aurora MySQL을 활용한 대용량 트랜잭션 처리로 고속 응답성과 확장성을 확보하고, 대용량 트래픽 서비스를 안정적으로 운영하고 개선합니다. 키워드: Kafka, Redis, Aurora MySQL, 분산 캐싱, 실시간 데이터 처리, 대용량 트랜잭션

[데이터 기반 개발과 A/B 테스트를 통한 성과 검증]

개발된 서비스의 임팩트를 데이터 분석과 A/B 테스트를 통해 정량적으로 검증합니다. 사용자의 금융 활동 데이터와 건강 데이터를 분석하여 개인 맞춤형 서비스의 정확도를 지속적으로 개선합니다. 키워드: 데이터 기반 의사결정, A/B 테스트, 성과 측정, 개인화 추천, 데이터 분석

[CI/CD 파이프라인을 통한 자동화된 배포]

GitHub Actions를 활용한 CI/CD 파이프라인을 운영하여 배포 주기를 단축하고 안정성을 확보합니다. 배포 자동화를 통해 반복 작업을 최소화하고, 서비스 품질을 지속적으로 관리합니다. 키워드: GitHub Actions, CI/CD 자동화, 서비스 안정성, 서비스 품질

자격요건

이런 경험과 역량을 갖추신 분들과 여정을 함께하고 싶어요.

• 5년 이상의 개발 경험과 그에 준하는 역량을 보유하신 분
• AI 기반 개발도구 (Cursor, Claude Code, Copilot 등)를 실무 적용하여 생산성과 품질을 개선한 경험과 기술전파에 열정이 있는 분
• Go, Java/Kotlin 중 하나 이상의 프로그래밍 언어를 이용해 서버를 개발해보신 분
• 특정 언어나 기술 스택에 얽매이지 않고, 프로젝트에 가장 적합한 기술을 유연하게 선택하고 제안할 수 있는 분
• 제품 기획, 디자인, 데이터 분석 등 다양한 직군의 동료들과 적극적으로 소통하며 협업한 경험을 보유한 분
• 복잡한 문제를 논리적으로 분석하고 명확하게 의사결정을 내릴 수 있는 분
• 명확하고 효율적인 코드 작성과 적극적인 코드 리뷰를 통해 품질을 관리하고 동료와 함께 성장한 경험이 있는 분

우대사항

이런 경험을 보유하신 분들을 우대하고 있어요.

• Kubernetes 환경에서 컨테이너 기반의 서비스를 배포 및 운영해본 경험이 있는 분
• 데이터를 활용한 서비스 성과 분석, 의사결정 및 개선 활동을 주도하거나 참여한 경험이 있는 분
• 실제 사용자 기반의 대용량 서비스를 개발하고, 운영하며 문제를 해결한 경험을 가진 분
• 복수의 프로젝트를 동시에 이끌고, 일정과 우선순위를 관리하며 프로젝트를 성공한 경험이 있는 분
• 빅데이터 인프라를 활용한 대규모 데이터 처리 및 분석, 서비스 개발 경험을 보유한 분
• 마이데이터, 금융 또는 헬스케어 분야의 데이터를 다뤄본 경험이 있거나 관심이 많은 분
• 뱅크샐러드 서비스에 애정이 많은 사용자에서 개발자로 서비스에 기여하고 싶은 분

면접 질문 대비

Q1. "뱅크샐러드는 단순히 AI 도구를 쓰는 것을 넘어, 팀 전체의 생산성을 높이는 'AI Native' 문화를 지향합니다. 병태님이 구축하신 'AI 기반 개발 워크플로우'가 구체적으로 기존의 비효율적인 프로세스를 어떻게 해결했는지, 그리고 그 방식이 동료들에게 전파되었을 때 어떤 피드백이나 변화가 있었는지 'Tech Spec(기술 설계)'의 관점에서 설명해 주시겠습니까?"

• 저는 슬롯 게임 서버 개발 시, AI 도입의 가장 큰 장애물이 LLM의 맥락(Context) 유지 한계임을 발견했습니다.
• 뱅크샐러드에서도 강조하는 Tech Spec과 유사하게, 에이전트가 우리만의 아키텍처와 비즈니스 규칙을 이해하도록 돕는 것이 생산성의 핵심이라 판단했습니다.

• 이를 해결하기 위해 cursor-rules를 기반으로 구조화된 컨텍스트 파일 체계를 수립했습니다.
• 구체적으로는 공통 로직인 데코레이터 패턴이나 API 규격을 명세화하여 AI가 언제든 참조하게 했고, 그 결과 일관성 있는 코드를 생성할 수 있었습니다.

• 이러한 시도는 개인의 성과를 넘어 팀 내 공유 세션으로 이어졌고, 동료들이 실제 생산성 향상을 체감하며 사내 AI TF가 구축되는 계기가 되었습니다.
• 결과적으로 기존 4주 소요되던 개발 기간을 3주로 단축하며 비즈니스 타임투마켓을 개선할 수 있었습니다.

Q2. "병태님은 Java/Kotlin 기반의 MSA 구조에서 Kafka와 Redis를 활용해 분산 시스템을 구축하고 운영한 경험이 있으십니다. 뱅크샐러드의 '최저금리 알리미'나 '대출 비교'처럼 대량의 금융 데이터 트래픽이 일시적으로 몰리는 환경에서, 시스템 전반의 고가용성(High Availability)을 유지하기 위해 'Redis 기반 분산 캐싱'이나 'Kafka를 통한 비동기 처리'를 어떻게 전략적으로 활용하셨는지 사례를 들어 설명해 주시겠습니까?"

• 대량의 트래픽 환경에서 고가용성을 유지하기 위해, 저는 **강한 정합성이 필요한 '잔액 처리'는 동기(Sync)**로, **결과적 정합성으로 충분한 '부수 로직'은 Kafka를 통한 비동기(Async)**로 설계하는 하이브리드 전략을 취했습니다.

• 슬롯 게임 서버 개발 당시, 유저의 잔액 차감은 즉시 응답을 주어 UX를 보호하되, 미션 달성이나 포인트 지급 이벤트는 Kafka로 발행하여 서버 간 결합도를 낮췄습니다.
• 이 고정에서 메시지 유실을 막기위해 Transactional Outbux 패턴을 적용하여 DB 커밋과 이벤트 발행의 원자성을 확보했고, 턴슈머 장애 시에도 재처리가 가능하도록 설계하여 데이터 정합성을 유지하며 높은 TPS를 달성할 수 있었습니다.

• 이러한 구조는 뱅크샐러드의 금융 알림 서비스처럼 트래픽이 몰리는 시점에도 핵심 금융 트랜잭션을 안정적으로 처리하고, 부하를 유연하게 분산시키는 데 기여할 수 있을 것입니다.

Q3. "병태님은 새로운 기술이나 아키텍처를 도입할 때 동료들에게 전파하고 설득하는 능력이 뛰어나다고 하셨습니다. 만약 뱅크샐러드에서 기존의 레거시 로직을 MSA나 새로운 기술로 전환해야 하는 상황이라면, 'Tech Spec' 문서에 어떤 항목들을 중점적으로 기술하여 동료들의 신뢰를 얻으시겠습니까? 특히, 기술적 화려함보다는 '현재 팀의 문제를 가장 효과적으로 해결하는가'를 중시하는 뱅크샐러드의 관점에서 본인만의 문서화 노하우를 말씀해 주세요."

• 뱅크 샐러드에서 제가 Tech Spec을 작성한다면, 가장 먼저 **왜 지금 이 변화가 필요한가?**에 대한 비즈니스적 가치를 정량적으로 정의하겠습니다.

• 구체적으로는 첫째, 현상 분석을 통해 현재의 높은 결합도가 신규 기능 출시 속도에 미치는 병목을 수치화하겠습니다.
• 둘째, MSA 전환 시 얻을 수 있는 생산성 이점과 함께, 분산 트랜잭션 관리나 네트워크 비용 같은 기술적 부채를 가감 없이 작성하여 동료들과 리스크를 사전 공유하겠습니다.

• 특히 저는 단계적 전환 전략을 선호합니다.
• 모든 것을 한 번에 바꾸기보다, 도메인 영향도가 적은 영역부터 AI 도구를 활용해 마이그레이션 POC를 빠르게 진행하고, 그 결과를 문서에 첨부하여 동료들의 신뢰를 얻겠습니다.
• 이러한 아이디어 제안은 단순히 기술적 만족이 아니라, 팀의 개발 속도를 높여 유저 이익을 극대화한다는 뱅크샐러드의 미션에 기여하기 위함입니다.

Q4. "병태님은 Java/Kotlin 환경에서 MSA 아키텍처 개선과 신규 게임 개발을 주도하셨습니다. 특히 슬롯 게임 로직의 공통화(템플릿화)를 위해 '데코레이터 패턴'을 도입하셨는데요, 뱅크샐러드와 같은 복잡한 금융 로직 환경에서 '비즈니스 로직의 순수성'을 유지하면서도 외부 변화(DB, API 등)에 유연하게 대응하기 위해 병태님만의 Clean Architecture 적용 노하우가 있다면 무엇인가요?"

• 저의 설게 철삭은 도메인 모델의 순수성 유지와 명확한 레이어별 책임 분리입니다.

• 구체적으로는 Presentation 레이어는 사용자 인터페이스와 웹 프로토콜을 담당하고,
• Application 레이어는 비즈니스 유스케이스를 구현하며 트랜잭션 경계를 관리합니다.
• 실제 핵심 로직은 Domain 레이어에서 수행하도록 하여 비즈니스 변화에 민감하게 대응할 수 있도록 합니다.

• 특히 뱅크샐러드처럼 외부 연동이 많은 환경에서는 **의존성 역전 원칙(DIP)**을 철저히 지킵니다.
• DB나 외부 API 호출은 인터페이스를 통해 추상화하여 도메인 로직이 기술 스택에 오염되지 않게 합니다.
• 과거 슬롯 게임 개발 시 데코레이터 패턴을 도입해 핵심 로직을 건드리지 않고도 다양한 게임 옵션을 유연하게 확장했던 것처럼,
• 뱅크샐러드에서도 복잡한 금융 정책을 견고하고 깔끔한 코드로 유지해 나가겠습니다.

Q5. "병태님은 이력서에서 '개발자별 편차를 줄이고 개발 기간을 표준화하여 생산성을 향상했다'는 성과를 내셨습니다. 만약 뱅크샐러드에서 '최저금리 알리미' 서비스의 전환율을 높이기 위한 새로운 로직을 개발했다면, 이 로직이 실제 유저에게 긍정적인 가치를 주었는지 엔지니어링 관점에서 어떻게 데이터를 측정하고 검증하시겠습니까?

• 저는 뱅크샐러드의 데이터 기반 의사결정 문화에 맞춰, 새로운 로직과 기존 로직을 A/B 테스트 형태로 배포하여 성과를 정량적으로 검증하겠습니다.

• 먼저 엔지니어링 관점에서 두 로직의 응답 속도와 처리량을 실시간으로 비교하겠습니다.
• 응답 속도가 늦어지면 유저 이탈로 이어지기 떄문입니다.
• 동시에, 새로운 로직이 실제로 '대출 비교 전환율'과 같은 비즈니스 임팩트를 주었는지 데이터를 통해 분석하겠습니다.

• NHN에서 테스트 커버리지를 51%까지 끌어올려 안정성을 확보했던 것처럼, 새로운 로직에 대해서도 철저한 단위 테스트와 통합 테스트를 선행하겠습니다.
• 만약 A/B 테스트 중 예기치 못한 에러율 상승이 감지되면, 롤백 프로세스를 수행해 유저에게 미치는 악영향을 최소화하여 점진적으로 마이그레이션을 수행하겠습니다.

시스템 디자인 면접 준비

들어가기 전에 앞서

• 논리적 설계 역량과 트레이드오프 판단 능력을 검증하는 자리
• 뱅크샐러드는 데이터와 안정성을 중요시하는 문화
• 왜 이 구조가 효율적이고 안정적인지를 뱅크샐러드의 4대 평가 기준에 맞춰 설명

준비 전략을 짜보자!

1. 성능(Performance) : 지연 요인 최소화

• 지연 요인 식별 :
  • 외부 금융사 API 호출 (timeout)
  • 무거운 DB 쿼리
  • 분산 트랜잭션의 락(Lock) 경합 등
• 최적화 방안 :
  • 비동기 병렬 처리 : 유저에게 즉각 응답이 필요 없는 알림이나 미션 처리는 Kafka를 활용해 후순위로 미뤄 메인 스레드의 지연을 줄이자

2. 확장성(Scalability) : 트래픽 증가 대응

• 한계 지점 : 단일 DB 쓰기 성능 한계 (Write IOPS), 특정 서비스의 CPU 병목
• 설계 전략 :
  • MSA 분리 : MSA 구조에 맞춰 서비스를 도메인 단위로 쪼개어 독립적인 스케일 아웃이 가능하게 디자인
  • Kafka 파티셔닝 : 대량의 이벤트가 몰릴 때 userId 기반 파티셔닝을 통해 컨슈머를 수평 확장하는 전략

3. 효율성(Efficiency) : 단순하고 경제적인 구조

• 복잡도 완화 : 무조건 새로운 툴을 도입하기보다 뱅크샐러드가 이미 사용중인 AWS EKS, Aurora MySQL, Redis를 최대한 활용해 인프라 비용과 관리 공수를 줄이는 구조를 제안
• AI 레버리지 : Tech Spec 단계에서 AI 에이전트를 활용해 다양한 아키텍처 대안 중 가장 비용 효율적인 모델을 시뮬레이션하고 결정하겠다는 점을 강조

4. 안정성(Reliability) : 장애 격리 및 복구

• 장애 전파 차단 : 외부 연동 지점에 Circuit Breaker를 배치하여 파트너사의 장애가 우리 시스템으로 전파되는 것을 막는 모습 표시
• 데이터 보장 : Transactional Outbox 패턴을 활용해 데이터를 안전하게 활용. DB 커밋과 이벤트 발행의 원자성을 보장하여 데이터 유실이 없음을 증명해야 함

실전 팁

• 1. 질문부터 시작하자
  • 초당 트래픽(TPS)은 어느 정도 인가요?
  • 데이터의 실시간성이 중요한가요, 결과적 정합성으로 충분한가요?
• 2. 트레이드오프를 말하자
  • 이 방식은 성능은 좋지만 저장 비용이 비싸다. 하지만 현재 트래픽 규모에서는 이 비용을 감수하고 사용자 경험을 챙기는 것이 비즈니스 임팩트가 더 크다라는 판단의 근거를 제시하자.

모의 질문 1. "뱅크샐러드의 '유전자 검사 결과 알림' 서비스에 수만 명의 유저가 동시 접속하여 결과 조회를 요청하는 상황입니다. 병태님이 화이트보드에 그리신 이 시스템에서 가장 먼저 병목이 발생할 지점은 어디라고 예상하시며, 이를 해결하기 위해 어떤 '캐싱 전략'과 '조회 최적화'를 적용하시겠습니까?"

• 수만 명의 동시 접속이 예상되는 상황에서 가장 먼저 병목이 발생할 지점은 DB의 읽기 IOPS 입니다.
• 이를 해겷기 위해 다음과 같은 3단계 전략으로 설계하겠습니다.

• 1. 읽기 부하 분산
  • 우선 MySQL의 Reader Replica를 다중화하여 메인 DB의 부하를 분산하겠습니다.
• 2. 전략적 Pre-caching
  • 알림 발송 직전, 분석 완료 이벤트를 소비하여 조회 확률이 높은 최신 결과값들을 Redis에 미리 적재(Warm-up) 하겠습니다.
• 3. CQRS를 통한 구조적 확장
  • 트래픽이 지속적으로 증가할 경우, 명령과 조회 모델을 분리하는 CQRS 패턴을 도입하겠습니다.
  • 조회 전용 데이터 저장소를 구축하여, 복잡한 조회 로직이 메인 트랜잭션 DB의 안정성에 영향을 주지 않도록 설계하겠습니다.

이러한 설계를 통해 오류가 발생해도 개별 조회 서비스에만 국한되도록 안정성을 확보하고, 트래픽 변화에 유연하게 대응하는 확장성을 갖추겠습니다.

꼬리 질문 1. "병태님, CQRS까지 도입하면 시스템의 복잡도가 상당히 높아집니다. 만약 운영팀 인력이 부족하여 '효율성'을 극대화해야 한다면, CQRS를 도입하기 전 단계에서 'Redis의 데이터 만료 정책(TTL)'이나 'Application 레벨의 로컬 캐시'를 어떻게 조합하여 시스템을 더 단순하게 유지하면서도 트래픽을 버텨내시겠습니까?"

• 시스템 구조를 최대한 단순하게 유지하면서 성능을 극대화하기 위해, Redis 단독 사용보다 Local -> Distributed 계층형 캐시 전략을 제안하겠습니다.

• Local (Caffeine)
  • 각 API 서버 인스턴스의 로컬 메모리에 가장 빈번히 조회되는 유전자 데이터를 캐싱합니다.
  • 네트워크 IO 없이 즉시 응답하므로 응답 속도를 매우 끌어올릴 수 있습니다.
• Redis
  • 로컬에 없는 데이터는 Redis에서 조회합니다.
  • 이는 여러 서버 간의 공유 캐시 역할을 수행합니다.
• 데이터 동기화 전략
  • 데아터의 정확성을 위해, 데이터 수정 발생 시 Kafka 브로커를 활용해 모든 인스턴스에 '특정 유저 캐시 삭제' 이벤트를 전파 하겠습니다.
• 효율성 최적화
  • 모든 데이터를 캐싱하기 보다는 메모리 효율을 위해 TTL을 짧게 설정하고, 자주 조회되는 상위 유저 위주로 관리하여 복잡한 CQRS 도입 없이도 트래픽 폭주를 안정적으로 방어하겠습니다.

꼬리 질문2. "병태님은 위 설계안을 Tech Spec 문서로 작성해 팀원들에게 공유했습니다. 그런데 동료 중 한 명이 '로컬 캐시 도입은 데이터 정합성 관리가 너무 복잡해서 반대한다. 성능이 조금 느리더라도 Redis만 쓰자'라고 강하게 주장합니다. 이때 병태님은 어떻게 소통하여 최선의 결론을 도출하시겠습니까?"

• 저는 동료의 '정합성 복잡도'에 대한 우려를 충분히 경청하고 존중하겠습니다.
• 다만, 서비스의 성장세를 고려하여 지속 가능한 확장성을 확보하는 것도 중요하다고 생각합니다.

• 우선, 기술적 복잡도는 캐시 레이어를 인터페이스화 하여 List 형태로 주입받는 구조를 제안하겠습니다.
• 이렇게 하면 비즈니스 로직은 캐시의 종류를 몰라도 되므로 코드 복잡성을 줄일 수 있습니다.

• 그런 다음, 객관적인 판단을 위해 부하 테스트 지표를 제시하겠습니다.
• 'Redis 단독 사용 시, 10만명, 로컬 캐시 병행 시 50만 명'이라는 가용량 수치를 보여주며, 우리 서비스가 곧 도달할 임계치를 함께 논의하겠습니다.

• 결과적으로 제가 옳음을 증명하기보다, 데이터와 설계 구조를 바탕으로 팀이 함께 최선의 엔지니어링 의사결정을 내릴 수 있도록 돕고 싶습니다.