[넥스트증권] Backend Engineer (채널 서비스·플랫폼) 공고 분석

이 자리가 왜 생겼을까요

1하게 될 업무

• MTS와 Agent Portal의 API와 백엔드 서비스를 설계·개발하고, 배포 이후 모니터링과 장애 대응까지 서비스 생애주기 전반을 맡습니다.

  이렇게 볼 수 있어요

  채널 계층은 사용자 요청이 가장 먼저 들어오는 곳이라 코어트레이딩·콘텐츠·AI 같은 하위 서비스 어디에서 문제가 나도 장애가 이 계층에서 먼저 보입니다. 운영까지 맡으면 내 코드뿐 아니라 하위 서비스 장애를 1차로 판별하는 일도 따라오기 쉬우므로, 원인이 다른 팀 시스템에 있었을 때 어떻게 확인하고 넘겼는지를 구체적으로 적어야 합니다.

• 여러 도메인과 외부 시스템의 데이터를 사용자 경험에 맞게 연결하고 API 계약과 데이터 흐름을 정의합니다.

  이렇게 볼 수 있어요

  API 계약을 정의하는 일은 화면을 만드는 클라이언트 팀과 데이터를 주는 하위 팀 사이에서 필드, 오류 코드, 버전 정책을 정하는 일입니다. MTS는 앱이라 업데이트하지 않은 옛 버전이 오래 남으므로, 하위 API가 바뀌어도 옛 앱이 깨지지 않게 하위 호환과 폐기 일정을 관리해 본 경험이 이 업무에 직접 쓰입니다.

• 캐시, 비동기 이벤트 처리, 트래픽 제어와 장애 격리로 성능과 안정성을 개선하고, 로그·메트릭·분산 트레이싱으로 병목과 장애 원인을 분석하며 테스트와 운영 자동화로 품질을 높입니다.

  이렇게 볼 수 있어요

  필수 자격요건에 Kafka 중심 분산 이벤트 스트리밍 아키텍처를 직접 구축·운영한 경험이 따로 있어, 비동기 처리가 이 팀의 기본 구조입니다. 요청 하나가 여러 하위 서비스를 거치는 BFF 구조에서는 분산 트레이싱이 어느 구간이 느린지 찾는 가장 직접적인 방법이라, 트레이스로 병목을 찾아 고친 사례에는 구간별 지연 수치가 따라와야 합니다.

• 기획·디자인·클라이언트·코어트레이딩·플랫폼·AI/Data 등 유관 조직과 협업해 요구사항을 구체화하고 기술적 의사결정을 실행합니다.

  이렇게 볼 수 있어요

  채널 계층은 화면 요구와 하위 시스템의 제약 사이를 조율하는 위치라 협업하는 팀이 많습니다. 테크본부장 인터뷰가 소개한 테크 스펙 문서(문제 정의, 목표와 비목표, 아키텍처)가 이런 조율에 쓰이는 도구이므로, 여러 팀의 요구가 부딪칠 때 문서로 결정을 남기고 합의를 끌어낸 경험은 이 업무를 실제로 해 본 이력입니다.

• MTS-BFF: 인증·계좌·거래·시세 API를 화면과 사용자 흐름에 맞게 조합해 MTS-BFF와 Channel API를 설계·개발·운영하고, 캐시 정책·타임아웃·재시도·Circuit Breaker·트래픽 제어로 하위 서비스 장애가 채널 전체로 확산되지 않게 개선하며, API 응답시간과 오류율을 관측해 병목을 개선하고 채널 공통 API 계약과 개발·운영 기준을 정립합니다.

  이렇게 볼 수 있어요

  시세처럼 자주 바뀌는 데이터와 계좌처럼 틀리면 안 되는 데이터를 한 화면에서 조합하므로, 데이터마다 캐시를 쓸지와 만료 시간을 다르게 정하는 판단이 이 분야의 핵심입니다. 하위 서비스 하나가 느려질 때 화면 전체를 실패시키지 않고 일부만 비워 보여 주는 부분 실패 설계를 해 봤다면 Circuit Breaker의 열림 기준과 대체 응답을 어떻게 정했는지까지 적어야 합니다.

• Agent Portal: 시세·종목정보·계좌·자산·주문 API를 활용하는 포털 백엔드와 API 인증·키·권한 체계를 설계·개발·운영하고, Sandbox와 Live 환경의 접근 경계와 API·도구 호출의 권한 검증, 실행 이력·감사 추적 체계를 구축합니다. 제품 범위에 따라 Agent Runtime, Tool 연동, MCP(Model Context Protocol) 기반 통합과 Agent 실행 계층의 기술 구조를 검토하고 구체화하는 확장 업무도 있습니다.

  이렇게 볼 수 있어요

  서울경제가 보도한 오픈 API 서비스, 즉 외부 프로그램이 계좌에 연결해 시세 조회와 주문, 계좌 조회를 처리하는 서비스가 MTS보다 먼저 나올 예정이라 이 분야가 가장 먼저 외부 사용자를 받을 수 있습니다. AI 에이전트가 사람 대신 주문을 내는 구조에서 사고가 나면 키 하나가 어떤 계좌에 어떤 권한(조회만, 주문까지)을 가졌는지, 누가 언제 무엇을 실행했는지를 감사 기록으로 확인해 대응합니다. OAuth 범위(scope) 설계나 API 키 발급·폐기, 호출 이력 감사를 만들어 본 경험이 있다면 이 분야에서 가장 먼저 꺼낼 이력입니다.

• Feed & Community: 프로필·팔로우 같은 소셜 관계와 게시물·이미지·좋아요·댓글 같은 콘텐츠·상호작용 기능을 설계·개발·운영하고, 피드 조회와 콘텐츠 제공 API의 성능과 동시 요청·이벤트 처리 상황의 데이터 정합성을 확보하며, 신고·차단·이미지 필터링 같은 Moderation과 알림 서비스를 연계합니다.

  이렇게 볼 수 있어요

  증권사 커뮤니티에서는 특정 종목을 띄우는 글이나 투자 권유성 게시물이 규제 문제로 이어질 수 있어 Moderation이 단순한 운영 기능에 그치지 않습니다. 프로덕트본부 인터뷰도 금융에서는 작은 표현 하나가 투자 판단에 영향을 줄 수 있어 콘텐츠팀과 컴플라이언스 조직이 긴밀하게 협업한다고 밝혔습니다. 신고·차단 정책을 코드로 옮기고 정책이 바뀔 때 일관되게 적용되게 만든 경험은 이 분야의 대표 이력입니다.

• Trading & Portfolio: 코어트레이딩팀의 국내·해외 주문·체결 코어 API를 연계해 거래 상태를 채널 API로 제공하고, 포트폴리오·보유종목·거래내역 데이터를 조합하며 계좌·연결계좌·간편인증 등 채널단 계좌 기능을 개발합니다. 입출금·환전 흐름을 원장 계열 서비스와 연결하고 API 계약·오류 처리·중복 요청 방지·데이터 정합성 검증으로 연계 안정성을 확보합니다. 원장·체결·정산 같은 핵심 거래 처리는 코어트레이딩팀이 맡고 이 분야는 채널(BFF) 계층과 연계 안정성을 맡습니다.

  이렇게 볼 수 있어요

  코어트레이딩플랫폼팀이 국내 주식 주문·체결, 해외 주식 주문·체결, 환전·자금이체, 계좌·종목/상품 백엔드 공고를 따로 냈고, 이 분야는 그 네 파트의 API를 고객 화면 하나로 묶는 쪽입니다. 주문 버튼을 두 번 누르거나 네트워크 재시도로 같은 요청이 두 번 가는 상황을 채널에서 먼저 걸러야 하므로, 멱등 키로 중복 주문·중복 출금을 막아 본 경험이 이 분야에서 가장 먼저 쓰입니다.

• Market & Discovery: 실시간 시세 API와 WebSocket 등 스트리밍 백엔드를 설계·개발·운영해 대용량 데이터의 지연과 전달 안정성을 개선하고, 종목 상세·트렌딩·관심종목 기능과 종목·콘텐츠 통합검색 API를 개발하며, 탐색 서비스용 데이터 파이프라인을 설계해 데이터 갱신·캐시·검색 결과의 일관성과 조회 성능을 개선합니다.

  이렇게 볼 수 있어요

  실시간 시세는 장중에 종목마다 초당 여러 번 바뀌고 접속자마다 보는 종목이 달라, 연결 수와 구독 종목 수가 곱해지는 만큼 전송량이 늘어납니다. WebSocket 연결을 대규모로 유지하며 구독 관리와 재접속 처리를 해 본 경험이라면 동시 연결 수와 지연 수치가 그 경험을 보여 주는 숫자입니다. 종목 검색은 같은 회사 Backend Engineer(계좌·종목/상품) 공고가 맡는 종목·상품 마스터를 받아 콘텐츠와 함께 보여 주는 구조가 될 수 있습니다.

• Activation Platform: Web/React Native SDK가 호출하는 Analytics API와 사용자 행동 이벤트 수집·적재 파이프라인을 설계·개발·운영하고, 이벤트 스키마 검증·데이터 라우팅·개인정보 마스킹과 중복·누락 대응으로 데이터 품질을 확보하며, A/B 테스트와 Feature Flag의 배정·노출·성과 측정을 지원하고 사용자 Context/Profile 기반 개인화 데이터를 서비스에 제공합니다. 추천 모델·AI 분석은 AI/Data 영역과 협업하고 이 분야는 사용자 Context 관리와 서비스 제공(Serving) 계층을 중심으로 맡습니다.

  이렇게 볼 수 있어요

  같은 회사 Backend Engineer(Data) 공고도 이벤트 수집 서버와 실험(A/B·피처플래그) 플랫폼 운영을 업무로 적었습니다. 그 공고는 AI데이터플랫폼팀에서 레이크하우스 적재와 데이터 신뢰성을 맡고, 이 분야는 앱 SDK 쪽 수집 API와 개인화 데이터를 서비스에 내주는 Serving 계층을 맡습니다. 행동 데이터를 쌓는 일과 서비스에 실시간으로 내주는 일 가운데 어느 쪽 경험이 많은지를 보고 두 공고 가운데 더 맞는 쪽을 고르면 됩니다.

2자격 요건

• 백엔드 엔지니어링 경력이 5년 이상이어야 합니다.

  이렇게 볼 수 있어요

  여섯 분야가 같은 공통 자격요건을 쓰고 '지원 분야의 전문성과 경험을 살펴봅니다'라고 적었으므로, 5년 가운데 지원할 분야(BFF, Open API, 커뮤니티, 거래 채널, 시세·검색, 이벤트·실험)와 가장 비슷한 프로젝트를 자세히 적는 것이 이 연차 조건을 이 공고에 맞게 보여 주는 방법입니다.

• 요구사항 분석부터 설계·개발·테스트·배포·운영까지 백엔드 개발의 전체 생애주기를 경험해 봤어야 합니다.

  이렇게 볼 수 있어요

  테크본부장은 인터뷰에서 직무별 역량 매트릭스에 제품 영향·협업·운영·엔지니어링을 정의하고, 아키텍처 리뷰와 온콜, 장애 대응을 팀의 일상 문화로 만들고 있다고 소개했습니다. 이 회사에서는 운영까지 맡는 것이 개발자 역할의 일부입니다. 운영 단계에서 받은 장애나 사용자 피드백이 다음 설계를 어떻게 바꿨는지까지 이어서 말하면 한 단계만 맡은 경험과 구별됩니다. 합류하면 새 서비스의 출시와 출시 뒤 운영을 함께 맡게 되므로, 직접 만든 서비스를 출시하고 안정화까지 맡은 프로젝트가 이 요건에 가장 가깝습니다.

• Java/Kotlin과 Spring Boot 기반 서비스를 개발할 수 있고, JVM과 Spring 생태계에 대한 깊은 이해와 실무 경험을 갖춰야 합니다.

  이렇게 볼 수 있어요

  'JVM 및 Spring 생태계에 대한 깊은 이해'까지 적혀 있어 프레임워크를 써 본 경험보다 한 단계 아래를 묻는 요건입니다. BFF는 하위 호출을 많이 묶어 스레드·커넥션 풀이 병목이 되기 쉬우므로, GC 튜닝이나 풀 설정으로 지연을 줄인 경험, 코루틴이나 WebFlux로 동시 호출을 다룬 경험이 요건이 말하는 깊은 이해를 보여 줍니다.

• RDB, Redis, Kafka를 활용해 개발해 봤고 데이터 모델링·트랜잭션·캐시·비동기 처리의 특성을 이해해야 합니다.

  이렇게 볼 수 있어요

  채널 계층은 원천 데이터를 직접 갖기보다 하위 서비스 데이터를 캐시하고 이벤트로 받는 일이 많아 세 저장소의 특성을 함께 묻는 것으로 볼 수 있습니다. 캐시와 원천 데이터가 어긋났을 때 무엇을 기준으로 무효화했는지, 메시지 순서와 트랜잭션 경계를 어떻게 맞췄는지를 실제 장애나 설계 사례로 정리한 것이 이 요건의 답이 됩니다.

• Kafka 중심의 분산 이벤트 스트리밍 아키텍처를 직접 구축하거나 운영해 봤어야 합니다.

  이렇게 볼 수 있어요

  요건이 '직접 구축하거나 운영한' 경험을 적었으므로 Kafka를 쓰기만 한 경험보다 운영 판단을 묻습니다. 토픽과 파티션 수를 어떤 기준으로 정했고 컨슈머 지연(lag)이 쌓였을 때 무엇을 했는지를 실제 수치와 함께 정리하면 이 요건에 바로 답이 됩니다.

• 성능·안정성·개발 생산성 사이의 트레이드오프를 판단하고 근거를 설명하며 주도적으로 의사결정하고 실행할 수 있어야 합니다.

  이렇게 볼 수 있어요

  이 회사 테크 스펙 문서가 목표와 함께 비목표를 적게 되어 있는 것처럼, 무엇을 포기했는지를 설명하는 능력을 묻는 요건입니다. 버린 대안과 그 이유를 설명할 수 있는 결정 하나가 인터뷰에서 이 요건을 가장 빨리 보여 줍니다.

3우대 사항

• 마이크로서비스 또는 이벤트 기반 아키텍처를 설계·개발·운영한 경험과 AWS, Kubernetes 등 클라우드·컨테이너 오케스트레이션 환경에서 서비스를 개발·운영한 경험을 우대합니다.

  이렇게 볼 수 있어요

  같은 회사 DevOps Engineer 공고는 시스템 경계(채널계·계정계·대외계)별로 나눈 EKS 클러스터를 설계·구축하고 운영하는 일을 업무로 적었고, 이 공고의 서비스는 그 가운데 채널계 쪽으로 볼 수 있습니다. 원장·체결을 맡는 코어트레이딩팀 서비스를 다른 클러스터에서 호출하게 되는 구조라면, 네트워크 경계와 서비스 간 인증을 다뤄 본 경험은 클라우드 운영 경험 가운데 이 환경과 가장 가까운 부분입니다.

• 로그·메트릭·트레이싱을 활용한 장애 분석, 성능 개선과 재발 방지 경험을 우대합니다.

  이렇게 볼 수 있어요

  BFF 장애는 원인이 하위 서비스에 있는 경우가 많아, 트레이스로 어느 서비스의 어느 호출이 느렸는지 보여 줘야 다른 팀과 재발 방지 대책을 합의할 수 있습니다.

• 지원 분야의 도메인 경험을 바탕으로 복잡한 요구사항을 구체적인 API와 운영 가능한 서비스로 구현할 수 있는 분을 우대합니다.

  이렇게 볼 수 있어요

  증권 도메인이 아니어도 지원 분야의 도메인, 예를 들어 Feed & Community라면 SNS 서비스, Activation Platform이라면 광고·분석 SDK 경험이 이 우대의 도메인 경험에 해당합니다. 요구사항이 모호했던 기능을 API 명세와 운영 지표까지 정해 내놓은 사례를 하나 고르면 설명하기 쉽습니다.

• MTS-BFF 분야는 API Gateway/BFF, 다수 마이크로서비스의 API 조합, 대규모 트래픽 처리와 장애 격리 경험을, Agent Portal 분야는 Open API 플랫폼, AI Agent, LLM Tool/Function Calling, MCP 연동 또는 실행 권한·감사 체계 설계 경험을 우대합니다.

  이렇게 볼 수 있어요

  Agent Portal의 MCP나 Function Calling 경험이라면 LLM이 도구를 부르게 만든 것보다, 증권 API를 도구로 노출하며 주문처럼 위험한 도구에 확인 단계와 권한 제한을 어떻게 걸었는지가 이 분야 업무(권한 검증, 감사 추적)와 직접 이어지는 부분입니다. MTS-BFF 쪽은 하위 서비스 수와 게이트웨이 처리량을 숫자로 밝히면 규모가 전달됩니다.

• Feed & Community 분야는 SNS·커뮤니티·미디어 피드, 소셜 그래프, 콘텐츠 상호작용과 Moderation 연계 경험을, Market & Discovery 분야는 실시간 시세, 스트리밍 데이터 처리, 대규모 연결 관리, 검색·추천 시스템 연계 경험을 우대합니다.

  이렇게 볼 수 있어요

  소셜 그래프 쪽에서 팔로워가 많은 계정의 글을 피드에 펼치는 방식(쓰기 시점 확산과 읽기 시점 조합)을 정해 본 경험이 있다면 그 방식을 고른 이유까지 함께 적을 수 있습니다. 대규모 연결 관리 쪽에서는 장 시작처럼 접속이 한꺼번에 몰리는 순간의 연결 수와 재접속 폭주를 다뤄 본 경험이 이 우대에 해당합니다.

• Trading & Portfolio 분야는 증권·금융 도메인에서 원장 또는 여러 백엔드 시스템을 API로 연계해 채널 서비스를 구축·운영한 경험을, Activation Platform 분야는 Product Analytics(Amplitude·Mixpanel 등), 실험·Feature Flag 플랫폼, 이벤트 스트리밍과 개인화 Serving 경험을 우대합니다.

  이렇게 볼 수 있어요

  Trading & Portfolio 우대의 원장 연계는 은행·카드·핀테크 앱의 계좌·거래 화면 백엔드에서도 하는 일입니다. Amplitude·Mixpanel은 제품 분석 도구라, 이런 도구를 쓰기만 한 경험보다 SDK 이벤트를 받아 실험 배정과 개인화 데이터를 서비스에 내준 경험이 Activation Platform 업무와 가깝습니다.

4기타 사항

• 게시일 : 2026년 9월 21일
• 고용형태 : 정규직
• 근무지 : 서울특별시 영등포구 국제금융로 10 THREE IFC 12층/15층
• 경력 조건 : 경력 5년 이상
• 학력 조건 : 해당 내용은 원본 공고에서 확인되지 않습니다.

쓰는 기술

공고 본문에 적힌 기술만 모은 목록입니다.

• Java
• Kotlin
• Spring Boot
• Kafka
• Redis
• Kubernetes
• Docker
• Airflow
• ELK
• Grafana
• PostgreSQL
• Oracle
• NoSQL
• AWS
• WebSocket
• MCP
• Amplitude
• Mixpanel

전형과 지원

채용 사이트 How We Hire가 밝힌 기본 절차는 서류 접수, 1차 인터뷰, 2차 인터뷰, 처우 협의, 최종 합격의 다섯 단계입니다. 개발·디자인 공고 상당수는 1차 인터뷰 앞에 AI 스크리닝을 더하므로 공고마다 전형 문단을 확인해야 합니다.

지원 전 준비할 것

1. 1

   지원 분야 하나 정하기

   여섯 분야 가운데 경력과 가장 가까운 분야를 하나 정하고, 이력서의 프로젝트 설명을 그 분야의 업무 문장에 맞춰 다시 정리합니다. 공고는 같은 기간 복수 포지션 동시 지원이 제한될 수 있다고 적었습니다.

2. 2

   하위 서비스 장애 대응 사례 고르기

   의존하던 서비스가 느려지거나 멈췄을 때 타임아웃, 재시도, 부분 실패로 피해를 줄인 사례를 설정값과 함께 정리합니다.

3. 3

   API 계약 문서 꺼내기

   직접 정의한 API 명세나 버전 관리 규칙, 오류 코드 체계가 있다면 하나 골라 왜 그렇게 정했는지 설명할 수 있게 준비합니다.