기업 채용 분석/힐링페이퍼

[힐링페이퍼] [병원 운영 솔루션] 백엔드 개발자 (B2B SaaS) 공고 분석

미용의료 병원의 운영 전반을 다루는 글로벌 B2B SaaS KOS에서 병원 도메인의 문제를 이해하고 확장 가능한 소프트웨어·데이터 아키텍처로 제품을 개발하는 병원 운영 솔루션 KOS 팀의 백엔드 개발자 공고입니다. 같은 KOS 팀의 프로덕트 디자이너 공고가 병원 업무 흐름을 화면으로 설계한다면, 이 공고는 도메인 주도 설계와 이벤트 기반 아키텍처, 테스트 자동화로 그 도메인을 시스템으로 옮깁니다. 경력 조건은 2년 이상이고 자격 요건은 연차나 기술 이름 대신 코드와 도메인을 대하는 태도를 적었습니다.

이 공고 분석은 2026년 10월 28일에 이뤄졌습니다. 이후 채용이 종료되었을 수 있습니다.

이 자리가 왜 생겼을까요

KOS를 소개한 2023년 힐링페이퍼 블로그 글은 KOS가 복잡한 도메인 로직을 빠르게 개발하고 운영하기 위해 이벤트 기반 구조와 도메인 기반 설계를 쓰고, 도메인 논리에 의한 버그를 줄이려고 TDD에 기반해 개발한다고 설명했습니다. 이 공고도 도메인 주도 설계, 이벤트 기반 아키텍처, 테스트 자동화를 팀이 일하는 방식으로 적고 DDD·이벤트 소싱·CQRS·TDD 경험을 우대합니다. 이 방식들을 실제 서비스에 적용해 본 프로젝트마다 도메인 경계를 어떻게 나눴고 그 결정이 이후 변경을 얼마나 쉽게 만들었는지 밝혀 주세요. KOS 팀이 쓰는 설계 방식을 내 프로젝트에서 어디까지 써 봤는지가 그 설명으로 보입니다.

힐링페이퍼가 지금 어떤 사업에 집중하고 있는지는 힐링페이퍼 채용 분석에서 이어서 볼 수 있습니다.

1하게 될 업무

  • 미용 의료 병원의 도메인과 비즈니스 문제를 깊이 이해하고 이를 해결하는 제품을 개발합니다.

    이렇게 볼 수 있어요

    KOS 팀이 만드는 것은 단순한 고객 관리 툴이 아니라 소프트웨어, 의료 장비, 병원 공간, 인력 운영이 연계된 엔터프라이즈 시스템입니다. 예약이나 고객 관리처럼 화면 뒤에 현장 운영 규칙이 많은 도메인을 맡아 봤다면 그 규칙을 어떻게 모델로 옮겼는지를 이 업무의 사례로 자세히 적을 수 있습니다.

  • 오늘 만든 코드가 내일의 자원이 되도록 복리로 쌓이는 시스템을 설계합니다.

    이렇게 볼 수 있어요

    팀은 코드가 더 빠르게 생산되는 환경일수록 테스트의 가치가 올라간다고 봅니다. 재사용되는 모듈이나 테스트가 쌓여 다음 기능의 개발 기간이 줄어든 경험이 있다면 줄어든 기간을 숫자로 보여 줄 수 있습니다.

  • API 개발을 넘어 소프트웨어와 데이터 아키텍처를 고민하며 확장성을 고려한 제품을 개발합니다.

    이렇게 볼 수 있어요

    회사 블로그의 KOS 소개 글은 병원(Tenant)마다 물리적으로 분리된 네트워크와 개별 데이터베이스를 쓰는 구조를 설명합니다. 고객사가 늘어날 때 데이터와 서비스를 어떻게 나눠 격리했는지 설계해 본 경험이 있다면 KOS의 병원별 분리 구조에 비춰 설명하는 편이 좋습니다.

  • 작지만 강한 ONE 팀에서 고객에게 가치를 전달하기 위한 모든 활동을 합니다.

    이렇게 볼 수 있어요

    이 팀에서는 개발자, PO, 디자이너가 하나의 제품에 몰입합니다. 백엔드 개발 밖에서 고객 병원의 요구를 직접 듣거나 배포 뒤 운영 문의를 처리해 본 경험이 있다면 '모든 활동'이 구체적으로 무엇이었는지 보여 줄 수 있습니다.

2자격 요건

  • 코드를 깊이 이해하는 사람이 결국 더 높은 수준의 시스템을 만든다고 믿어야 합니다.

    이렇게 볼 수 있어요

    팀은 AI를 적극적으로 활용하되 개발 철학과 코어 아키텍처에 대한 깊은 이해를 우선한다고 적었습니다. AI 도구가 만든 코드를 그대로 쓰지 않고 구조를 이해한 뒤 고쳐 쓴 적이 있다면 무엇을 보고 고쳤는지가 팀이 우선한다고 한 아키텍처 이해를 보여 주는 사례입니다.

  • 문제의 본질을 이해하고 답을 찾기 위해 동료의 의견에 집중해야 합니다.

    이렇게 볼 수 있어요

    회사 인재상 Acknowledge that we can be wrong은 자신의 의견으로 결정됐을 때가 아니라 더 좋은 결론에 도달했을 때 토론에서 이긴 것으로 봅니다. 설계 논의에서 동료 의견을 받아 처음 안을 바꾼 경험이 있다면 이 요건과 인재상을 한 사례로 함께 설명할 수 있습니다.

  • 자신의 생각을 말, 글, 그림으로 합리적으로 표현할 수 있어야 합니다.

    이렇게 볼 수 있어요

    회사 핵심가치 Radical Transparency는 결과뿐 아니라 의도와 맥락, 과정까지 공유하는 것입니다. 설계 결정의 이유를 문서나 도메인 모델 그림으로 남겨 다른 개발자가 그 맥락을 이어받은 경험은 요건의 말·글·그림 가운데 글과 그림으로 생각을 표현한 사례입니다.

  • 문제 해결에 필요하다면 자신의 지식과 경험을 내려놓을 수 있어야 합니다.

    이렇게 볼 수 있어요

    팀은 Microservices 패턴이 유행하지만 모듈 관계에 HTTP 요청을 적용하는 것만으로는 오히려 더 많은 문제를 유발할 수 있다고 경계합니다. 익숙하게 써 온 구조가 도메인에 맞지 않아 바꾼 경험이 있다면 무엇을 내려놓고 무엇으로 바꿨는지 꺼낼 수 있습니다.

  • 도구보다 문제에 집중하고 기술보다 도메인을 먼저 이해하려 해야 합니다.

    이렇게 볼 수 있어요

    팀은 DDD 소개에서 코드 구현의 비용이 빠르게 낮아지는 세상에서 진짜 경쟁력은 도메인 이해의 깊이에 있다고 적었습니다. 새 도메인에 들어가 업무 규칙부터 익힌 과정을 기간과 방법으로 설명하면 이 팀이 우선하는 순서를 실제로 따라 본 경험이 드러납니다.

  • 빠르게 실행하고 틀리면 회고하며 더 나은 선택을 반복할 수 있어야 합니다.

    이렇게 볼 수 있어요

    회사는 Keep-Problem-Try 회고를 운영합니다(회사 문서 조직문화). 출시 뒤 잘못된 설계를 회고에서 찾아 다음 버전에서 고친 경험이라면 무엇이 틀렸고 무엇으로 바꿨는지가 함께 있어야 이 요건의 회고 사례가 됩니다.

3우대 사항

  • DDD(Domain Driven Design)에 대한 이해도가 높으면 우대합니다.

    이렇게 볼 수 있어요

    팀은 전술 기법에 매몰되면 도메인 주도 설계의 진짜 가치를 취하지 못한다며 유비쿼터스 언어와 전략적 설계에 집중합니다. 패턴을 적용한 경험보다 도메인 경계를 어떻게 나눴고 그 경계가 이후 변경에 어떤 영향을 줬는지가 이 팀이 강조하는 쪽의 경험입니다.

  • MSA와 분산 메세징 시스템 운영 경험을 우대합니다.

    이렇게 볼 수 있어요

    팀은 분리된 요소들이 비동기 이벤트를 사용해 유연하게 통합되도록 아키텍처를 설계합니다. 메시지 유실이나 순서 문제를 운영 중에 겪고 해결해 본 경험이 있다면 이 구조를 실제로 운영해 본 근거로 쓸 수 있습니다.

  • 이벤트 소싱, CQRS 패턴에 대한 이해와 경험이 있으면 우대합니다.

    이렇게 볼 수 있어요

    회사 블로그의 KOS 소개 글은 동시에 접속한 계정의 다양한 이벤트와 실시간 데이터 변화를 다루려고 소켓 통신과 이벤트 소싱 기반 아키텍처를 만들었다고 설명합니다. 이벤트 소싱을 써 봤다면 어떤 요구 때문에 그 패턴을 골랐는지를 KOS의 사례와 나란히 설명할 수 있습니다.

  • 테스트 주도 개발을 이해하고 경험했으면 우대합니다.

    이렇게 볼 수 있어요

    팀은 자동화된 테스트 케이스를 늘리고 TDD를 적용하며 테스트를 AI와 함께 설계합니다. 테스트를 먼저 쓰고 구현한 프로젝트가 있다면 테스트 범위와 그 뒤 줄어든 결함을 숫자로 적을 수 있습니다.

  • 글로벌 제품이나 SaaS 애플리케이션 운영 경험을 우대합니다.

    이렇게 볼 수 있어요

    회사 블로그에 따르면 KOS는 고객이 원하는 기능을 개별적으로 배포하고 새 버전 배포까지 코드로 자동화했습니다. 고객별로 기능을 따로 배포하거나 설정을 나눠 운영해 본 경험이 있다면 배포 단위를 어떻게 나눴고 무엇을 자동화했는지 밝힐 수 있습니다.

  • 'AI Native 개발에 대한 시도와 적응력이 뛰어나신 분'을 우대하고, 일을 빠르게 더 작게 나누고 자동화하는 것에 빠져 있는 분도 우대합니다.

    이렇게 볼 수 있어요

    팀은 AI 개발 도구로 Claude Code 등을 쓰고 테스트도 AI와 함께 설계합니다. AI 코딩 도구로 작업을 잘게 나눠 자동화한 흐름이 있다면 사람이 직접 검토한 단계가 어디였는지까지 보여 주는 편이 이 팀의 '코드를 깊이 이해하는' 기준과 맞습니다.

4기타 사항

  • 게시일 : 2026년 8월 24일
  • 고용형태 : 정규직
  • 근무지 : 서울특별시 강남구 테헤란로 142 아크플레이스 15층
  • 경력 조건 : 경력 2년 이상
  • 학력 조건 : 해당 내용은 원본 공고에서 확인되지 않습니다.

쓰는 기술

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

  • Java
  • Kotlin
  • TypeScript
  • Spring Boot
  • Spring Webflux
  • Express.js
  • MongoDB
  • AWS
  • Kubernetes
  • Claude Code

전형과 지원

힐링페이퍼 경력 공고는 대부분 서류지원, 직무 인터뷰(온라인), 협업 인터뷰(오프라인), 바레이저 인터뷰(오프라인), 평판조회, 최종합격 순서를 적었습니다. 개발 직군은 공고에 따라 사전 테스트가 붙고, 디자인·마케팅·에디터 공고는 대부분 포트폴리오가 필수입니다(소셜미디어 에디터 공고는 인스타그램 채널 계정).

  • 세 번의 인터뷰

    채용 사이트는 1차 직무 인터뷰를 커리어 경험, 업무, 성과를 중심으로 이야기하는 시간, 2차 협업 인터뷰를 서로 추구하는 문화와 협업 방식을 포괄적으로 이야기하는 시간, 3차 바레이저 인터뷰를 포지션 전문성을 다시 확인하고 회사에 궁금한 점을 묻는 시간으로 설명합니다. FAQ는 1차는 온라인, 2차와 3차는 오프라인으로 진행하되 상황에 따라 바뀔 수 있다고 답합니다.

    이렇게 볼 수 있어요

    2차 협업 인터뷰가 문화와 협업 방식을 다루므로 인재상 절의 여섯 가지와 연결한 사례를 이 인터뷰에서 쓰게 됩니다. 기본 전형에서는 오프라인 인터뷰가 두 번이고, iOS·Android·Analytics Engineer처럼 직무 인터뷰까지 대면인 공고는 세 번입니다. 영어로 쓴 태국 Senior Account Manager 공고는 1차(오프라인)와 2차(온라인 또는 오프라인) 두 번이고 바레이저 인터뷰가 없습니다.

    힐링페이퍼 채용 (인재영입 프로세스·자주 묻는 질문)

  • 바레이저 인터뷰

    채용 사이트는 바레이저(Bar-Raiser)를 '인재영입의 기준을 높이는 사람'으로 '현실에 타협하지 않고 조직 내 최고의 인재만을 영입하는 기준을 유지시키는 역할'을 한다고 설명합니다. 분석 시점 채용 사이트의 경력 공고 34건 가운데 33건이 바레이저 인터뷰를 전형에 적었습니다.

    이렇게 볼 수 있어요

    바레이저 인터뷰는 앞 단계에서 나눈 전문성을 다시 확인하는 자리라서, 직무 인터뷰에서 꺼낸 사례의 숫자와 근거를 한 단계 더 깊게 설명할 자료가 있어야 합니다.

    힐링페이퍼 채용 (인재영입 프로세스)

  • 개발 직군의 사전 테스트

    채용 사이트는 개발 직군에 한해 사전 테스트로 코드 리뷰 테스트나 코딩 테스트를 본다고 적었습니다. 분석 시점에는 백엔드 공고가 서류 뒤에 코드 리뷰 테스트를, 웹 프론트엔드 공고가 직무 인터뷰 안에 코딩 테스트를, Analytics Engineer 공고가 직무 인터뷰와 쿼리 테스트를 함께 적었고, iOS·Android 공고는 콜 스크리닝 인터뷰 뒤 직무 인터뷰를 오프라인으로 진행한다고 적었습니다.

    이렇게 볼 수 있어요

    같은 개발 직군이어도 테스트의 종류와 시점이 공고마다 다릅니다. 백엔드는 코드를 읽고 리뷰하는 능력을, Analytics Engineer는 쿼리 작성을 직접 보므로 준비할 연습도 그에 맞춰 달라집니다.

    힐링페이퍼 채용 (인재영입 프로세스)

  • 포트폴리오

    분석 시점 채용 사이트에서 프로덕트 디자이너와 마케터, 에디터 경력 공고 10건이 서류 지원 때 포트폴리오 제출을 필수로 적었습니다. 그 가운데 퍼포먼스 마케터와 일본 브랜드 마케터·에디터 공고 4건은 '주요 프로젝트별 목표, 전략, 실행 내용, 성과, 본인의 역할을 명확히 기재해 주세요'라고 형식까지 밝혔습니다.

    이렇게 볼 수 있어요

    이 공고들은 프로젝트마다 다섯 항목을 적어 달라고 정했으므로 팀의 결과와 내 역할을 나눠 적어야 마지막 항목인 '본인의 역할'이 비지 않습니다.

    힐링페이퍼 [강남언니] 퍼포먼스 마케터 (그로스 마케터) 공고

  • 결과 안내와 재지원·중복 지원

    FAQ는 전형 결과를 영업일 기준 약 7일 안에 안내하고, 14일 넘게 늦어지면 인재영입팀 메일로 문의하라고 답합니다. 탈락한 뒤에는 지원 시점으로부터 6개월 이후 다시 지원할 수 있고, 다른 포지션에 중복 지원할 수 있으며 내부 검토 뒤 다른 포지션을 추천받을 수도 있습니다.

    이렇게 볼 수 있어요

    같은 직무의 공고가 여럿이면(PO 공고 세 건처럼) 함께 지원할 수 있지만, 회사가 역량에 맞춰 다른 포지션을 제안할 수 있다고 적었으므로 공고마다 업무 항목에 맞춰 이력서의 강조점을 다르게 두는 편이 낫습니다. 최종합격 뒤에는 처우 확인 자료를 낸 다음 오퍼레터를 받습니다.

    힐링페이퍼 채용 (자주 묻는 질문)

  • 병역특례

    강남언니 백엔드·웹 프론트엔드·iOS·Android 공고와 병원 운영 솔루션 백엔드 공고는 첫 줄에 '현재 힐링페이퍼는 병역특례를 지원하지 않아요'라고 적고, 병역특례에 해당하는 사람은 추후 별도 공고가 올라오면 지원해 달라고 안내했습니다.

    이렇게 볼 수 있어요

    이 안내는 분석 시점 채용 사이트 45건 가운데 강남언니 개발 공고 4건과 병원 운영 솔루션 백엔드 공고에만 있었고, AI Foundation·신사업 FDE와 Analytics Engineer 공고에는 없었습니다. 산업기능요원이나 전문연구요원으로 복무하면서 옮기려는 경우 안내가 붙은 공고로는 지원할 수 없습니다.

    힐링페이퍼 [강남언니] 백엔드 개발자 공고

    • 이 공고만 다른 점

    • 이 공고는 서류지원 다음에 코드 리뷰 테스트가 있고, 그 뒤로 직무 인터뷰(온라인), 협업 인터뷰(오프라인), 바레이저 인터뷰(오프라인), 평판조회가 이어집니다.

      기본 전형보다 단계가 하나 많습니다. 팀은 코드를 한 줄씩 작성하는 시간은 줄어도 읽어야 할 순간에 제대로 판단하는 엔지니어로 성장할 수 있다고 적었습니다. 남의 코드에서 도메인 규칙이 어긋난 곳과 테스트가 빠진 곳을 찾아 설명해 보는 연습으로 코드 리뷰 테스트를 준비할 수 있습니다.

    지원 전 준비할 것

    1. 1

      코드 리뷰 테스트 연습

      도메인 규칙이 들어간 남의 코드를 골라 설계 문제, 빠진 테스트, 이벤트 경계를 찾아 근거와 함께 리뷰 코멘트로 써 보는 연습을 합니다.

    2. 2

      DDD·EDA 적용 사례

      DDD나 이벤트 기반 구조를 실제로 적용한 프로젝트 하나를 골라 경계를 나눈 기준, 비동기로 바꾼 지점, 그 뒤 생긴 문제와 해결을 순서대로 정리합니다.

    3. 3

      KOS 소개 글 읽기

      공고에 연결된 KOS 시작 배경 글과 회사 블로그의 병원향 SaaS 시리즈를 읽고 병원별 분리 구조와 개별 배포에 대해 묻고 싶은 점을 적어 둡니다.

    백엔드 개발자 지원을 준비한다면