Show Cover Slide

개발조직을 도메인 기반으로 구조화하고, 채용 기준을 설계한 사례

새로운 서비스를 전개하기 위해
개발조직의 도메인을 구조화하고, 채용 기준과 인터뷰 흐름까지 설계한 사례입니다.
기술자를 뽑은 것이 아니라 문제를 해결할 수 있는 흐름을 사람으로 완성한 과정이었습니다.

문제 인식

회사는 무인화 전략을 실현하고자 했지만
내부에 이를 담당할 전담 개발조직이 없었고,
어떤 역할이 필요한지조차 명확하지 않은 상태였습니다.
직무 정의 없이 사람을 뽑는 방식으로는
조직이 확장되더라도 기술 내재화가 어렵다고 판단했습니다.

나의 설계 철학

저는 채용을 “사람을 선택하는 일”이 아니라
문제를 해결할 수 있는 구조를 사람으로 완성하는 설계 작업이라고 생각합니다.
기술력보다 중요한 것은
비즈니스 맥락을 이해하고 기술로 풀어낼 수 있는 사고 방식입니다.

설계 방향

• 조직을 4개 도메인으로 구조화
  → 서비스 플랫폼 / 데이터 플랫폼 / 디바이스 / 운영

• 외부 사례와 직무 정의를 분석하여, 비즈니스에 맞는 역할 정의를 재구성
  → 기존 시장 언어가 아니라 우리의 전략과 맞는 JD 재구성

• 인터뷰 구조와 평가 기준을 명문화
  → 반복 질문을 모듈화하고, 기술역량이 아닌 문제해결력 중심으로 설계

• 온보딩 구조까지 포함한 채용 이후 흐름까지 설계
  → 합류 이후에도 방향성에 맞는 성장이 가능하도록 체계 구성

결과

• 역할 정의를 기준으로 한 다수의 인재를 적합한 도메인에 배치
• 비즈니스 이해 기반 기술 인재 확보
• 전담 개발조직 구성 완료 → 자체 기술 내재화 기반 마련
• 도메인 중심 조직 구조로 향후 서비스 확장 시에도 유연한 재배치 가능

정리하며

기술조직은 기술로만 구성되지 않습니다.
올바른 역할 정의, 맥락 중심의 평가 기준, 구조화된 온보딩이 있어야 비로소 기술이 조직 안에 자리 잡을 수 있습니다.

우리의 팀은 약 6개월에 걸쳐 완성되었고, 그 이후 4개월 만에 첫 서비스를 시장에 런칭했습니다.

• 서비스 개발부터
• 서드파티 공급사와의 계약,
• 운영 대행 프로세스 설계,
• 고객 전달까지의 흐름을 내부에서 자체적으로 완결했습니다.

그 결과, 약 150명의 고객이 우리의 서비스를 직접 경험할 수 있었습니다.
큰 성장은 아니었지만, 짧은 시간 안에 문제를 인식하고, 구조화하고, 실행한 이 일련의 과정 자체가 의미 있는 성과라고 생각합니다.

저는 이 경험을 통해, 기술조직도 하나의 플랫폼처럼 설계될 수 있다는 확신을 얻었습니다.

그리고 앞으로도 저는, 기술을 채택하기 전에 사람과 구조를 먼저 설계하는 일에 가장 많은 시간을 들일 예정입니다.