[숨고] Sr. Backend Engineer 공고 분석

이 자리가 왜 생겼을까요

1하게 될 업무

• 서비스 하나 이상의 오너를 맡아 도메인 모델, API 계약, 데이터 스키마를 결정합니다.

  이렇게 볼 수 있어요

  구현에 더해 서비스의 경계와 계약을 정하는 역할을 맡습니다. 맡았던 서비스에서 스키마나 API 계약을 바꾼 결정과 그 영향을 사례로 정리해 두면 이 업무와 바로 이어집니다.

• 주요 설계 결정은 ADR로 기록하고, 대안과 트레이드오프를 문서로 공유합니다.

  이렇게 볼 수 있어요

  설계 결정을 문서로 남기는 방식이 업무에 들어 있습니다. 대안을 비교해 결정한 문서를 써 봤다면 결론만 적기보다 어떤 대안을 왜 버렸는지까지 적는 편이 정확합니다.

• 무중단 스키마 전환과 대용량 데이터 마이그레이션을 롤백 가능한 단계로 설계하고 실행합니다.

  이렇게 볼 수 있어요

  롤백 가능한 단계라는 조건이 붙어 있습니다. 마이그레이션을 몇 단계로 나눴고 단계마다 되돌릴 방법을 어떻게 남겼는지를 함께 설명해야 이 조건에 맞습니다.

• 이벤트 기반 처리(Kafka, RabbitMQ)의 중복·순서·유실 문제를 설계 단계에서 다룹니다.

  이렇게 볼 수 있어요

  중복·순서·유실 문제를 사후에 고치지 않고 설계 단계에서 막아야 하는 업무입니다. 멱등성이나 재처리 전략을 처음 설계할 때부터 반영한 사례가 이 업무와 가장 가깝습니다.

• 코드 리뷰와 배포 후 지표·로그 확인으로 변경의 안전망을 만들고, 코딩 에이전트를 워크플로에 붙여 쓰되 산출물은 본인이 검증하고 책임집니다.

  이렇게 볼 수 있어요

  공고의 AI 개발 환경 항목은 시니어에게 이 환경을 쓰는 데서 나아가 환경 자체를 설계하는 역할을 기대한다고 적었습니다. 에이전트에 넘길 작업과 검증 기준을 팀에 정해 봤다면 그 기준을 실제로 적용한 예 하나가 그 역할을 보여 줍니다.

• 장기적으로는 레거시 아키텍처 전환 로드맵을 그려 실행하고, 서비스 신뢰성 지표(SLI/SLO)와 관측성을 개선하며, 반복 작업의 AI 에이전트·스킬 자산화와 LLM 기반 제품 기능 설계·운영을 맡습니다.

  이렇게 볼 수 있어요

  공고는 이 항목들을 장기 업무로 적었고, 레거시 아키텍처 전환은 로드맵을 그리는 단계부터 맡습니다. 아키텍처 전환을 계획 단계부터 맡아 본 경험은 단계별 일정과 결과를 함께 정리해 두어야 면접에서 설명하기 쉽습니다.

2자격 요건

• 백엔드 언어(Python, Java, Kotlin, Node.js, Go 등) 하나 이상으로 7년 이상 개발했고, Python과 Python 웹 프레임워크 기반 개발에 거부감이 없어야 합니다.

  이렇게 볼 수 있어요

  같은 팀 Backend Engineer 공고는 같은 언어 목록에 3년 이상을 요구하고, 이 공고는 7년에 서비스 오너 역할을 붙였습니다. 스택의 Python 웹 프레임워크는 Falcon·FastAPI·Flask 셋입니다. 장기 업무에는 레거시 아키텍처 전환 로드맵이 있어 다른 언어가 주력이어도 Python 서비스의 구조를 판단하는 일이 따라옵니다. 주력 언어로 맡은 서비스와 기간을 자세히 적고 Python으로 해 본 작업도 함께 밝힐 수 있습니다.

• MSA 환경에서 대규모 데이터·트래픽을 다루는 백엔드를 개발·운영한 경험이 필요합니다.

  이렇게 볼 수 있어요

  같은 팀 Backend Engineer 공고에서는 우대 사항이던 MSA 경험이 이 공고에서는 자격 요건입니다. 다룬 트래픽과 데이터 규모를 숫자로 적어 두면 이 요건이 말하는 대규모 환경을 겪었는지가 바로 드러납니다.

• 서비스 하나 이상을 설계부터 운영, 개선까지 책임져 본 경험이 필요합니다.

  이렇게 볼 수 있어요

  이 팀의 서비스 오너는 도메인 모델과 API 계약, 데이터 스키마를 직접 정하고 주요 결정을 ADR로 남깁니다. 책임졌던 서비스가 있다면 운영 기간과 함께 그 서비스에서 내린 설계 결정과 버린 대안을 말할 수 있어야 이 요건과 업무가 같은 사례로 설명됩니다.

• REST API를 설계·개발해 본 경험이 필요합니다.

  이렇게 볼 수 있어요

  REST API 설계 경험은 업무에 적힌 API 계약 결정과 이어집니다. 설계한 API 하나를 골라 계약을 바꿀 때 기존 호출 쪽과의 호환을 어떻게 지켰는지 정리해 두면 면접에서 바로 꺼낼 수 있습니다.

• MySQL을 인덱스·락·실행계획 수준까지 이해하고 MongoDB를 사용해 본 경험이 필요합니다.

  이렇게 볼 수 있어요

  MySQL의 이해 수준을 인덱스, 락, 실행계획으로 구체적으로 적었습니다. 실행계획을 보고 쿼리를 바꾼 사례나 락 경합을 푼 사례가 이 요건에 대한 답이 됩니다.

• 무중단 스키마 변경이나 데이터 마이그레이션을 설계하고 실행해 본 경험이 필요합니다.

  이렇게 볼 수 있어요

  업무는 무중단 스키마 전환과 대용량 마이그레이션을 롤백 가능한 단계로 나눠 설계하는 일로 적혀 있습니다. 직접 설계한 마이그레이션이 있다면 단계마다 문제가 생겼을 때 어디로 되돌릴 수 있었는지까지 설명할 수 있는지가 이 요건의 핵심입니다.

• 테스트 코드 작성이 몸에 배어 있고, 장애 상황에서 로그·APM으로 원인까지 도달해 본 경험이 필요합니다.

  이렇게 볼 수 있어요

  같은 팀 Backend Engineer 공고에서 APM·로그 기반 장애 분석은 우대 사항이고, 이 공고는 원인까지 도달해 본 경험을 필수로 요구합니다. 이 팀 스택의 Datadog·NewRelic·Bugsnag 같은 도구에서 어떤 신호로 원인을 좁혔는지 장애 하나를 골라 순서대로 설명할 수 있어야 합니다. 테스트 습관은 업무의 코드 리뷰·배포 후 지표 확인과 함께 변경의 안전망을 이루는 부분입니다.

• AI 코딩 도구를 상시로 쓰며 AI가 만든 코드는 검증 루프를 거쳐 올리고, 다양한 직무의 동료와 협업하며 서로를 존중하는 문화를 함께 만들 수 있어야 합니다.

  이렇게 볼 수 있어요

  AI 도구 사용과 협업 태도가 함께 필수입니다. 검증 루프를 팀 규칙으로 만든 경험이 있다면 시니어에게 기대하는 역할과 바로 이어집니다.

3우대 사항

• MSA 환경에서 서비스 분리나 도메인 경계 재설계를 주도한 경험, 대용량 트래픽·실시간 처리 시스템 설계·운영 경험을 우대합니다.

  이렇게 볼 수 있어요

  도메인 경계를 다시 그린 경험은 서비스 오너 업무와 이어집니다. 무엇을 기준으로 나눴고 나눈 뒤 무엇이 달라졌는지를 쓰면 서비스 분리 경험의 범위가 분명해집니다.

• AWS 인프라 운영, 컨테이너·쿠버네티스 기반 배포 환경(ArgoCD, GitOps) 운영, 자동화와 CI/CD 파이프라인 구축·운영 경험을 우대합니다.

  이렇게 볼 수 있어요

  같은 팀 Backend Engineer 공고의 같은 우대는 쿠버네티스 배포 환경 운영까지이고, 이 공고는 AWS 인프라 운영과 CI/CD 파이프라인 구축을 더했습니다. ArgoCD는 Git 저장소에 적은 배포 상태를 클러스터에 맞추는 GitOps 도구입니다. 스택에는 GitHub Actions와 Bitbucket Pipelines가 함께 적혀 있습니다. 파이프라인을 직접 만들었는지 운영만 맡았는지를 나눠 적으면 시니어에게 기대하는 범위와 비교하기 쉽습니다.

• APM·로그 기반 장애 분석과 성능 개선 경험(Datadog, Sentry, Bugsnag 등)을 우대합니다.

  이렇게 볼 수 있어요

  필수 요건의 장애 원인 분석을 성능 개선까지 넓힌 우대입니다. Datadog이나 Sentry로 병목을 찾아 응답 시간을 줄인 사례라면 개선 전후 숫자를 함께 적을 수 있습니다.

• AI 에이전트 워크플로(커스텀 스킬·훅·서브에이전트, MCP 서버 구현, 코드 리뷰·배포 자동화)를 직접 구성하거나 LLM 기반 기능(RAG, 에이전트, 프롬프트·모델 평가셋 운영, 비용·지연 최적화)을 프로덕션에 올려 본 경험을 우대합니다.

  이렇게 볼 수 있어요

  공고에서 팀원은 이 팀이 설계부터 배포 점검까지 함께 만든 30여 개 스킬 위에서 개발한다고 소개했습니다. 직접 만든 자동화를 팀이 함께 쓰게 된 경험이 있다면 이 팀의 방식과 가장 가깝습니다.

• 개인정보 보호와 보안 요구사항(ISMS 등)을 반영한 시스템 설계 경험을 우대합니다.

  이렇게 볼 수 있어요

  같은 팀 Backend Engineer 공고의 같은 우대에는 ISMS라는 이름이 없습니다. ISMS는 정보통신서비스 부문 전년도 매출 100억 원 이상이나 하루 평균 이용자 100만 명 이상 같은 기준에 들면 의무가 되는 정보보호 관리체계 인증입니다. 인증 심사의 통제 항목이 개발 쪽에 설계 요구사항으로 내려오는 경우가 많습니다. 접근 통제나 암호화 같은 인증 항목에 맞춰 설계를 바꾼 경험이라면 어떤 항목을 왜 바꿨는지가 이 우대와 연결됩니다.

• 주니어 멘토링, 코드 리뷰 문화 정착, 기술 문서 체계 구축 경험을 우대합니다.

  이렇게 볼 수 있어요

  판단 기준을 팀에 남기는 시니어 역할과 이어지는 우대입니다. 만든 문서나 리뷰 규칙이 팀에서 어떻게 쓰였는지 적을 수 있습니다.

4기타 사항

• 게시일 : 2026년 9월 11일
• 고용형태 : 정규직(수습 3개월)
• 근무지 : 서울특별시 강남구 테헤란로 133 HK스퀘어 11-12층 (역삼동, 한국타이어빌딩)
• 경력 조건 : 경력 7년 이상
• 학력 조건 : 해당 내용은 원본 공고에서 확인되지 않습니다.

쓰는 기술

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

• Python
• Falcon
• FastAPI
• Flask
• MySQL
• MongoDB
• Redis
• Elasticsearch
• Kafka
• RabbitMQ
• gRPC
• REST
• Kubernetes
• ArgoCD
• Git
• GitHub
• Bitbucket
• GitHub Actions
• Bitbucket Pipelines
• Datadog
• NewRelic
• Bugsnag
• Claude Code
• GitHub Copilot
• Slack
• Confluence
• Jira
• AWS

전형과 지원

숨고 공고는 대부분 서류 전형, 1차 인터뷰, 2차 인터뷰, 처우 협의, 최종 합격 순서를 적었고 공고에 따라 레퍼런스 체크와 과제가 붙습니다. 채용 담당자가 블로그에 단계별 진행 방식을 자세히 공개해 두어 인터뷰 형식과 소요 시간까지 미리 알 수 있습니다.

지원 전 준비할 것

1. 1

   설계 결정 문서

   직접 쓴 ADR이나 설계 문서 하나를 골라 비교한 대안과 버린 이유를 정리합니다.

2. 2

   마이그레이션 단계

   무중단으로 진행한 스키마 변경이나 데이터 이전 하나를 단계별로 나누고 각 단계의 롤백 방법을 적어 둡니다.

3. 3

   팀에 남긴 기준

   리뷰 규칙, 테스트 원칙, 자동화 스킬처럼 내가 만들어 팀이 함께 쓰게 된 것을 골라 쓰임새를 정리합니다.