개발자가 새 회사에 빠르게 적응하는 3가지 방법

안녕하세요.

프롭테크 플랫폼에서 백엔드 개발자로 근무 중인 3년 차 백엔드 개발자 정정일입니다.

이직은 누구에게나 쉽지 않은 일입니다. 새로운 코드베이스, 낯선 팀 문화, 모르는 비즈니스 도메인… 저 역시 새 회사에 합류했을 때 막막했습니다.

오늘은 제가 새로운 회사에 합류하면서 어떻게 적응해 나갔는지, 그 과정에서 시도해본 방법들을 공유하려 합니다.

입사 이튿날부터 온보딩 문서를 조금씩 업데이트하기 시작했고, 일주일 만에 시스템 아키텍처를 그려봤으며, 1.5개월 만에 모니터링 시스템을 구축할 수 있었습니다.

물론 특별한 능력이 있어서가 아니라, 시행착오를 겪으며 조금씩 해나간 결과라고 생각합니다.

첫 출근날의 선택: 소비자인가, 생산자인가

새 회사 첫 출근날, 누구나 긴장하면서도 설레는 마음으로 사무실 문을 엽니다. 저 역시 마찬가지였습니다.

저는 2025년 3월 새로운 팀에 합류하게 됐고 지금은 9월이니 벌써 6개월이 지나게 됐네요.

입사 당시에 온보딩 담당자분께서 건네주신 문서들은 다음과 같았습니다.

• 회사 소개서
• 백엔드 온보딩 가이드
• 기술 스택 문서
• 개발 환경 셋업 가이드

온보딩 문서를 읽으면서 든 생각은 이랬습니다.

“아, 이 부분은 업데이트가 안 됐네?” “이 기술은 언제 추가된 거지? 문서에는 없는데…” “시스템 전체 구조가 한눈에 보이는 다이어그램이 있으면 좋겠다”

온보딩 문서가 완벽하지 않았습니다. 그런데 이건 당연한 일입니다. 문서는 항상 코드보다 뒤처지기 마련이고, 모든 것을 담을 수도 없습니다.

여기서 저는 두 가지 선택지를 마주했습니다

1. 소비자로 남기: 문서를 읽고, 부족한 부분은 직접 물어보면서 알아가기
2. 생산자로 전환하기: 내가 배운 것을 문서에 추가하면서 알아가기

저는 2번을 선택했습니다.

전략 1: 온보딩 문서를 직접 개선해보기 - 소비자에서 생산자로

입사 이튿날, 첫 PR

입사 당일, 온보딩 문서를 읽으면서 발견한 것들을 메모했습니다. 그리고 다음 날, 첫 PR을 올렸습니다.

1
2
3
4

# 추가된 내용
- Tech Stack: Spring Boot, Kotlin, MySQL, Redis, ...
- 인프라: AWS, GCP (병행 사용 중)
- 모니터링: AWS CloudWatch 사용중

“입사 다음날 PR을 올린다고?” 부담스럽게 느낄 수도 있는데, 저도 처음엔 망설였습니다. 하지만 이렇게 접근하니 생각보다 자연스러웠습니다

• “이 부분이 틀렸어요” (X)
• “이 부분이 궁금해서 알아봤는데, 제가 이해하고 있는게 맞을까요?” (O)

온보딩 문서 개선은 비교적 안전하게 시작할 수 있는 기여였습니다.

• 코드에 직접 손대지 않아도 됨
• 실수해도 큰 문제가 되지 않음
• 팀에 도움이 될 수 있음
• 내가 배운 것을 정리하는 과정

작지만 꾸준하게

입사 후 몇 주간, 저는 매일 조금씩 문서를 개선했습니다

• 3월 11일: Tech Stack 추가
• 3월 12일: AWS Lambda 추가
• 3월 14일: DDD 설계 관련 내용 추가 (애그리게이트 vs 도메인 서비스)

제게는 ‘완벽함’보다 내가 지금 이해하고 있는 부분에 대한 ‘정돈’ 이 중요했습니다. 하루에 한 줄이라도, 내가 배운 것을 문서에 추가해 나갔습니다.

이렇게 하니 좋았던 점

1. 빠른 학습: 문서를 “읽기만” 하는 것보다 “쓰면서” 배우니 이해가 더 빨랐습니다
2. 능동적 자세: 질문할 때도 “이거 뭐에요?“가 아니라 “이렇게 이해했는데 맞나요?“로 바뀌었습니다
3. 팀에 기여: 다음 신입 개발자가 조금 더 수월하게 온보딩할 수 있게 됐습니다
4. 신뢰 획득: 팀원들께 좋은 인상을 드릴 수 있었던 것 같습니다

전략 2: 이해를 위해 그려보기 - 그림으로 시스템 파악하기

입사 1주일, 여전히 막막

입사 일주일 차, 저는 여전히 전체 시스템 구조를 완전히 파악하고 있진 않았습니다. 이는 사실 당연하기도 합니다. 운영중인 서비스의 전체적인 흐름을 일주일만에 파악하긴 어려우니까요.

• “레거시 서비스가 MSA를 호출하기도 하나?”
• “AWS SQS는 어떤 서비스들이 컨슘하고 이벤트를 발행하고 있나?”
• “Elastic Search는 어떻게 사용되고 있는거지?”

코드를 보면서 조각조각 이해는 되는데, 전체 그림이 그려지지 않았습니다.

그래서 시도했습니다: “직접 그려보자.”

Draw.io와의 사투

주말에 Draw.io를 열고, 제가 이해한 시스템을 그리기 시작했습니다.

[Client] → [API Gateway] → [User Service] → [MySQL]
                         → [Match Service] → [Redis]
                         → [Payment Service] → [외부 PG API]

처음에는 단순하게 시작했습니다. 그리고 하나하나 추가해나갔습니다:

• 각 서비스 간 통신 방식 (REST API)
• 데이터베이스 연결
• 외부 API 연동
• 메시지 큐 (SQS)

막히는 부분은 질문하고, 답을 들으면 다시 그림에 반영했습니다.

검증 과정

그리고 시스템 아키턱처를 추가하는 PR을 올렸습니다.

“이 PR의 항목은 다음과 같습니다!

• 백엔드 시스템 아키텍처 추가

혹시 수정이 필요하거나 개선할 점이 있다면 말씀해주시면 감사하겠습니다! 검토해 주셔서 감사합니다! 😊”

완벽한 다이어그램을 만들려는 게 아니라, 내가 이해한 것을 공유하고 피드백받기 위한 수단으로 활용했습니다.

이렇게 하니 좋았던 점

1. 전체 시스템 이해: 그리는 과정에서 자연스럽게 전체 구조가 머릿속에 그려졌습니다
2. 구체적인 질문: “이 부분이 어떻게 되나요?“가 아니라 “A와 B는 이렇게 연결되는 게 맞나요?“처럼 구체적으로 물을 수 있었습니다
3. 팀의 반응: 다이어그램이 없었던 팀이라 필요해하셨던 것 같습니다
4. 살아있는 문서: 이후 시스템이 변경될 때마다 계속 업데이트할 수 있었습니다

실제로 4월에 모니터링 시스템을 구축한 후, 다이어그램에 Metrics 서버를 추가했고, 8월에도 새로운 서비스가 추가되면서 계속 갱신했습니다.

전략 3: 빠르게 기여할 수 있는 것 찾기

온보딩 문서를 개선하고, 시스템 아키텍처를 그리는 것도 좋지만, 실제로 팀에 도움이 되는 것을 만들어낼 수 있다면 더 좋을 것 같았습니다.

팀의 Pain Point 파악

입사 후 처음 몇 주간, 회의와 일상 대화에서 반복적으로 나오는 키워드들을 메모했습니다:

• “지금 장애가 나면 CS가 오기 전까진 알 수 가 없어요…”
• “로그를 확인하는데 너무 오래걸려요”

모니터링 시스템에 개선이 필요하다는 신호였습니다.

내가 할 수 있는 것 찾기

3년 차 개발자로서, 모든 걸 다 잘할 수는 없습니다. 하지만 내가 비교적 해볼 수 있는 것을 찾을 수는 있었습니다.

제 경우

• 인프라/DevOps 경험이 조금 있음
• Grafana, Loki, Tempo, Prometheus 스택을 구축해본 경험이 있음
• 쿠버네티스 운영 경험이 있음 (이건 나중에 쿠버네티스 구축 및 도입으로 이어집니다)
• 회사 비즈니스 로직은 아직 모름

“내가 빠르게 기여할 수 있는 건 모니터링 시스템 개선일 것 같다”

입사 1.5개월, 모니터링 시스템 구축

3월에 입사해서 4월에 모니터링 시스템을 구축했습니다

• OpenTelemetry로 통합 관측성 구축
• Prometheus, Loki, Tempo, Grafana 스택 구성
• 모든 서비스에 일관된 메트릭 수집

이 과정은 이전 블로그 글(서비스 장애는 사용자가 알려주지 않아도 알아야한다 - 사내 모니터링 시스템 구축기)에서 자세히 다뤘습니다.

협업 문화 개선

모니터링뿐 아니라, 온보딩 과정에서 느낀 다른 pain point들도 개선했습니다:

Git 전략 도입 및 문서 추가 (4월 2일)

• Git Flow 소개 및 브랜치 전략 문서화
• Git commit 컨벤션
• 브랜치 전략
• PR 규칙
• 이슈/PR 템플릿 추가 (협업의 기준 마련)

PR Auto Code Review, Test Coverage 추가 (4월 4일)

• Jacoco, dekekt, review dog
• CI/CD 환경 구축 가이드
• Self-hosted Runner 가이드

백엔드 개선과제 추가 (8월)

• 팀이 해결해야 할 기술 부채와 개선 과제 정리

이렇게 하니 좋았던 점

1. 빠른 신뢰 획득: 팀원들께서 신뢰해주시는 것 같았습니다
2. 명확한 역할: 팀 내에서 제 강점과 역할이 조금씩 명확해졌습니다
3. 성취감: 실제로 팀에 도움이 되는 걸 만들었다는 만족감이 있었습니다
4. 학습 기회: 실제 프로덕션 환경에서 경험을 쌓을 수 있었습니다

실천 팁: 지금 당장 시도해볼 수 있는 것들

저도 처음엔 막연했지만, 이렇게 해보니 도움이 됐습니다.

1. 첫 주: 메모하고 정리하기

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# 나의 온보딩 노트 (첫 주)

## 궁금한 것들
- [ ] 레거시 서비스가 MSA를 호출하기도 하나?
- [ ] AWS SQS는 어떤 서비스들이 컨슘하고 이벤트를 발행하고 있나?
- [x] Elastic Search는 어떻게 사용되고 있는거지?

## 추가하면 좋을 것 같은 문서
- AWS Lambda 사용처 (현재 문서에 없음)
- 환경변수 설정 가이드

## 개선 아이디어
- Git commit 메시지 컨벤션이 명확하지 않음
- PR 템플릿이 있으면 좋을 것 같음

매일 이렇게 메모하고, 정리해서 문서에 추가합니다.

2. 첫 달: 그려보기

시스템을 이해하기 위해 그려보세요:

간단한 버전부터 시작

[Client] → [Backend] → [DB]

점진적으로 확장

[Client]
  ↓
[API Gateway]
  ↓
[Service A] → [DB A]
[Service B] → [DB B]
  ↓
[External API]

도구 추천:

• Draw.io (무료, 웹 기반)
• Excalidraw (손그림 스타일)
• Mermaid (코드로 다이어그램 그리기)

3. 둘째 달: 빠르게 기여하기

팀의 pain point를 파악하고, 내가 빠르게 해결할 수 있는 것을 찾으세요.

체크리스트:

• 팀에서 자주 나오는 불편함은 무엇인가?
• 그중에서 내가 해결할 수 있는 것은?
• 작게 시작할 수 있는가?
• 팀의 우선순위와 일치하는가?

예시:

• 반복 작업 자동화 스크립트
• 문서화 (특히 암묵지의 문서화)
• 개발 환경 개선
• 테스트 코드 추가
• 코드 리뷰 개선 (리뷰 가이드, 체크리스트)

마치며

많은 개발자들이 팀 적응을 “회사가 나를 어떻게 도와주는가” 의 문제로 생각하는 경우들이 간혹 계신 것 같습니다. 물론 회사가 좋은 온보딩 프로그램을 제공하는 것도 중요하지만

“빠른 적응은 회사의 지원만으로는 충분하지 않다. 나의 능동적인 자세도 필요하다.” 싶습니다.

• 문서가 부족하면? → 내가 조금씩 추가해본다
• 시스템이 복잡하면? → 내가 그려본다
• 팀에 문제가 있으면? → 내가 해결할 수 있는 것을 찾아본다

이렇게 온보딩에 임하니

1. 비교적 빠르게 적응할 수 있었습니다
2. 팀에 조금이나마 도움을 줄 수 있었습니다
3. 자연스럽게 신뢰를 얻을 수 있었던 것 같습니다
4. 무엇보다, 성장할 수 있었습니다

문서도 코드처럼 계속 진화하고 개선되어야 한다 생각합니다. 그리고 그 개선은 신입부터 시니어까지 모두가 함께 해나가는 것인 것 같구요.

여러분도 다음 회사에 입사하게 되면, 온보딩 문서에 추가하면 좋을 것 같은 점을 발견하신다면 PR을 올려보시는 건 어떨까요.

“첫 PR이 꼭 버그 픽스일 필요는 없지 않을까 싶습니다. 문서 개선도 첫 걸음으로는 충분한 기여라고 생각합니다. ㅎㅎ”

이 글이 새로운 환경에 적응하고 계신 개발자분들께 조금이나마 도움이 되기를 바라며 이만 글을 마치겠습니다.

긴 글 읽어주셔서 감사합니다.