Skip to main content

CTO로서의 첫 2주 기록

· 7 min read
Ryukato
Ryukato
BackEnd Software Developer

들어가며​

현재 회에 합류한 뒤 지난 2주 동안은 조직·프로세스·기술 구조를 빠르게 이해하고 기반을 정비하는 일에 집중했습니다.
CTO로서 ‘지금 무엇을 파악해야 하고, 무엇부터 정비해야 하는가’라는 기준으로 접근했고, 그 과정에서 느낀 점과 실제로 진행한 작업들을 정리해 보았습니다.

1. 팀 & 조직 이해​

👥 팀장/팀원들과의 점심 미팅​

합류 초반에는 사람과 조직의 맥락을 이해하는 것이 가장 중요하다고 생각했습니다.
그래서 팀장 및 팀원들과 번갈아 점심을 가지며 다음과 같은 부분을 자연스럽게 확인했습니다.

  • 팀 분위기와 커뮤니케이션 스타일
  • 각자의 역할과 현재 다루는 업무
  • 팀 단위의 Pain Point
  • 개발 프로세스 상의 병목 구간

특히 팀원들과의 점심 자리에서는 업무 이야기보다 관계를 만드는 데 집중했습니다. 이 부분은 장기적인 신뢰 기반을 만드는 데 도움이 된다고 생각합니다.

2. 채용 및 조직 구성 점검​

📌 추가 채용 필요성 분석​

CTO가 조직을 처음 받으면 필연적으로 “사람이 더 필요한가?”, “현재 인력으로 가능한가?”를 판단해야 합니다.
이를 위해 다음과 같은 기준으로 구조화를 진행했습니다.

  • 팀별 주요 업무 목록 및 업무량(Workload) 분석
  • 현재 인원 대비 Output 및 생산성
  • 부족한 역량/포지션 가시화
  • 채용이 필요한 명확한 Reasoning 정리
    • 더 나은 Output
    • 속도 향상
    • 품질 향상
    • 조직의 지속 가능한 성장

대표와의 논의에서 추상적인 요청이 아닌 근거 기반의 채용 논리를 제공하기 위한 준비 작업이었고, 현재 정리본은 거의 완료된 상태입니다.

3. 개발 환경 및 도구 파악​

🛠 개발 도구 및 인프라 환경 점검​

팀이 실제로 사용 중인 개발 도구들을 전수 조사하고 다음을 정리했습니다.

  • 필수 도구와 선택적 도구 목록
  • 라이선스 필요 여부
  • 빌드/테스트/배포 환경 현황
  • 단기 개선 포인트

특히 도구 문제는 팀 생산성에 직결되는 영역이라 초반에 빨리 확인하는 것이 중요했습니다.

4. 서비스 기능 요청 프로세스 정비​

📝 서비스 기능 요청서(draft) 작성​

현재 다양한 경로로 들어오는 “기능 추가 요청/버그/수정 요청”을 단일 채널로 정리하기 위해
서비스 요청 양식(draft version)을 Confluence 기반으로 작성했습니다.

  • 요청 유형
  • 목적 및 배경
  • 상세 내용
  • 우선순위
  • 릴리즈 희망 일정
  • 영향 범위
  • QA 포인트

조직이 커질수록 이런 정형화된 프로세스는 팀 전체의 효율성을 크게 높입니다.

5. 외부 개발 프로젝트 파악 및 정리​

📂 외부 협력사 프로젝트 전체 구조 파악​

외부 업체와 함께 진행 중인 제품 개발 프로젝트가 있어, 이를 빠르게 재정리했습니다.

  • 기능 목록 정리
  • 외부/내부 이슈 및 질문·답변을 단일 문서로 통합
  • 기능별/버전별 분류
  • PM이 외부 업체와 조율할 때 참고할 수 있는 매핑 구조 생성

특히 프로젝트 초반에는 정리가 안 되어 협업 속도가 느려지는 경우가 많기 때문에, 이 부분을 표준화하는 작업이 중요했습니다.

6. 기술 아키텍처 정비 및 재설계​

🔄 Python → Java 마이그레이션 구조 설계​

현재 Python 기반으로 만들어진 일부 핵심 서비스를 Java/Spring 기반으로 재구축하는 프로젝트가 있습니다.

이를 위해 다음과 같은 구조를 설계하고 구현을 시작했습니다.

🔧 Mono Repo + Multi Module 구조 도입​

  • 공통 Starter Modules 설계
  • 서비스별 모듈 분리
  • API Docs, Actuator 등을 모듈화하여 재사용성 증가

📦 공통 모듈 설계​

  • Database & Redis Starter
  • External API Client 모듈
  • Web Filter / Interceptor 모듈
  • 공통 Exception / Response 구조
  • API 문서 자동화 (springdoc)

마이그레이션은 단순 코드 변환이 아니라, 앞으로 여러 프로젝트가 공유 가능한 표준 구조를 만드는 것이 핵심 목표입니다.

마무리하며​

CTO로서 첫 2주는 ‘문제를 해결하기 위해 뛰어드는 시간’이 아니라
**‘조직을 제대로 이해하고 기반을 다지는 시간’**이라고 생각합니다.

지금은 팀·기술·프로세스의 전체 그림을 파악하고 다음 단계로 넘어갈 준비가 되었습니다.
앞으로는 아래의 부분들을 중심으로 더 깊게 들어갈 계획입니다.

  • 개발 환경 표준화
  • 아키텍처 고도화
  • 품질 관리 체계 정립
  • 빠르고 안정적인 배포 환경 구축
  • Python → Java 전환 가속화

앞으로도 변화 과정을 기록해 보겠습니다.
읽어주셔서 감사합니다 🙌