입사 첫 주에 인프라 다이어그램 한 장 받아 들고 “이거 대체 어디서부터 봐야 하나” 막막했던 기억, DevOps로 이직해보신 분들이라면 다들 공감하실 겁니다. 코드 몇 줄 짜는 것보다 조직의 배포 문화와 암묵적 룰을 파악하는 데 더 오래 걸리는 게 이 직군의 특징이죠. 1주차부터 3개월 차까지 실제로 겪은 온보딩 과정과, 그 시기마다 필요했던 스킬셋을 시기별로 정리해봤습니다.
핵심 요약
1. 1주차는 코드보다 “권한 신청과 문서 파악”에 시간을 더 씁니다. 조급해할 필요 없습니다.
2. 1개월 차부터는 작은 배포 티켓 하나를 스스로 끝까지 처리해보는 게 적응 속도를 결정짓습니다.
3. 3개월 차 이후 필요한 건 특정 툴 숙련도가 아니라, 장애 상황에서 팀에 신뢰를 주는 커뮤니케이션 능력입니다.
1주차: 권한과 문서의 벽
입사 첫날 노트북 세팅하고 나면 바로 코드를 보게 될 거라 생각하시는 분들이 많은데, 실제로는 정반대입니다. AWS든 GCP든 온프레미스든, 권한 신청서를 올리고 승인이 날 때까지 기다리는 시간이 생각보다 깁니다. 보안팀 승인, 매니저 승인, VPN 접속 권한까지 겹치면 3~4일은 그냥 지나가요.
이 기간에 코드를 못 본다고 불안해하지 마시고, 대신 아키텍처 문서와 런북(Runbook)을 훑어보는 데 시간을 쓰는 게 훨씬 남는 장사입니다. 특히 컨플루언스나 노션에 쌓인 “장애 회고록”은 신입 입장에서 조직의 진짜 아픈 지점을 파악할 수 있는 최고의 자료입니다. 공식 아키텍처 다이어그램보다 이게 더 정직한 경우가 많더라고요.
이 시기에 해두면 좋은 것
- 팀 온보딩 문서에 오탈자나 오래된 정보가 있으면 바로 수정 PR 올리기 (첫 기여치고 부담 없고, 존재감도 남길 수 있습니다)
- CI/CD 파이프라인 다이어그램을 직접 손으로 그려보며 이해도 점검하기
- 1:1 미팅에서 “어떤 장애가 제일 자주 나나요”라고 물어보기
1개월 차: 첫 배포 티켓을 혼자 처리하기까지
1개월쯤 되면 슬슬 작은 티켓이 배정됩니다. 로그 포맷 수정, 알람 임계값 조정, 오래된 크론잡 정리 같은 것들이요. 여기서 중요한 건 티켓 난이도가 아니라 혼자 끝까지 배포까지 마무리해보는 경험입니다. 코드 리뷰 받고, 스테이징에 올리고, 모니터링 대시보드로 정상 동작 확인하고, 프로덕션에 반영하는 전체 사이클을 처음부터 끝까지 손으로 돌려보는 거죠.
여기서 실무자들이 잘 안 알려주는 팁이 하나 있는데, 배포 직후 5분보다 배포 후 30분~1시간 사이 지표를 더 유심히 봐야 합니다. 대부분의 장애는 배포 직후가 아니라 트래픽 패턴이 바뀌는 특정 시점(피크 타임 진입, 배치 작업 시작 등)에서 뒤늦게 터지거든요. 매뉴얼에는 “배포 후 모니터링 하세요” 라고만 나와 있지만, 실제로는 이 시간대까지 지켜보는 습관이 생존 스킬입니다.
| 시기 | 주요 업무 | 필요 역량 |
|---|---|---|
| 1주차 | 권한 신청, 문서 파악, 환경 세팅 | 문서 이해력, 질문하는 용기 |
| 1개월 차 | 소규모 티켓 단독 배포 | Git 워크플로우, CI/CD 파이프라인 이해 |
| 3개월 차 | 장애 대응 투입, 온콜 로테이션 합류 | 로그·메트릭 분석, 침착한 커뮤니케이션 |
3개월 차: 장애 대응에 투입되는 시점
보통 3개월 차쯤 되면 온콜 로테이션에 이름이 올라갑니다. 여기서부터는 스킬셋의 결이 완전히 달라져요. 1개월 차까지가 “기존에 짜인 파이프라인을 이해하고 따라가는” 단계였다면, 3개월 차는 “예상 못 한 상황에서 판단하는” 단계입니다.
새벽 3시에 알람이 울렸을 때 제일 중요한 건 툴 숙련도가 아니라 침착함입니다. 로그 몇 줄 보고 원인을 단정 짓기보다, 일단 영향 범위부터 파악하고 팀 채널에 상황을 공유하는 순서가 먼저예요. 신입 시절 흔히 하는 실수가 원인 파악에 몰입하느라 상황 공유를 늦게 하는 건데, 이러면 매니저나 다른 팀원 입장에서는 “얘가 지금 뭘 하고 있는지” 알 수가 없어서 불안해집니다. “확인 중입니다, 5분 뒤 업데이트하겠습니다” 한 줄이라도 먼저 남기는 습관이 신뢰를 쌓는 데 생각보다 큰 역할을 합니다.
시기별 추천 스킬셋 정리
결국 “DevOps 스킬셋”이라고 하면 흔히 쿠버네티스, 테라폼, 젠킨스 같은 툴 이름부터 떠올리는데, 온보딩 단계별로 실제 필요한 우선순위는 다릅니다.
- 1주차~1개월: Git 브랜치 전략, 사내 CI/CD 도구(Jenkins, GitHub Actions, GitLab CI 중 팀이 쓰는 것) 기본 사용법, 사내 문서 검색 및 정리 습관
- 1~2개월: 컨테이너 오케스트레이션 기초(쿠버네티스 또는 ECS), 로그 수집 스택(ELK, Datadog, CloudWatch) 읽는 법, IaC 도구(Terraform, CloudFormation) 리딩 능력
- 3개월 이후: 장애 대응 프로세스(포스트모템 작성법 포함), 온콜 커뮤니케이션, 비용 최적화 관점에서 인프라 보기
여기서 놓치기 쉬운 게 있는데, 3개월 이후 진짜 차별화되는 역량은 특정 툴을 더 깊이 아는 게 아니라 포스트모템(사후 분석 보고서)을 잘 쓰는 능력입니다. 장애 원인만 나열하는 게 아니라, 재발 방지책까지 구체적으로 제시하고 그걸 실제 액션 아이템으로 트래킹하는 사람이 조직 안에서 빠르게 신뢰를 얻습니다.
신입 DevOps가 흔히 하는 착각
“툴을 많이 알수록 빨리 적응한다” — 아닙니다. 조직마다 쓰는 툴 조합과 관습이 다 달라서, 새 툴을 익히는 시간보다 “왜 이 조직은 이 방식을 택했는지” 맥락을 이해하는 시간이 더 오래 걸립니다. 툴 자체는 문서 몇 번 읽으면 따라잡을 수 있어요.
“질문을 많이 하면 무능해 보인다” — 오히려 반대입니다. 1개월 차까지 질문 없이 조용한 신입보다, 맥락 있는 질문을 던지는 신입이 팀 입장에서는 훨씬 안심됩니다. 다만 같은 질문을 반복하지 않도록 메모하는 습관은 필수고요.
“장애 대응은 시니어만 하는 일” — 3개월 차부터는 신입도 온콜에 들어가는 경우가 많습니다. 미리 겁먹기보다, 이 시기가 오기 전에 팀의 장애 대응 프로세스 문서를 미리 정독해두는 게 실질적인 대비입니다.
온보딩 체크리스트
- 1주차 안에 팀의 아키텍처 다이어그램을 직접 손으로 그려서 시니어에게 검증받기
- 1개월 안에 소규모 티켓 하나를 처음부터 끝까지 혼자 배포해보기
- 배포 후 최소 30분~1시간은 모니터링 대시보드를 지켜보는 습관 들이기
- 3개월 전까지 팀의 장애 대응 프로세스와 온콜 매뉴얼을 미리 정독해두기
- 장애 상황에서는 원인 규명보다 상황 공유를 먼저 하는 순서를 몸에 익히기
여기까지 오면 자연스럽게 다음 궁금증이 생기실 텐데요, “그럼 온콜 로테이션에 처음 들어갔을 때 실제로 어떤 순서로 대응해야 하는가”는 다음 글에서 실제 장애 시나리오와 함께 다뤄보겠습니다.
3개월을 돌아보며
온보딩 3개월을 지나고 나서 느낀 가장 큰 깨달음은, 결국 DevOps 적응 속도를 결정짓는 건 기술 스택이 아니라 조직의 암묵지를 얼마나 빨리 흡수하느냐라는 점이었습니다. 툴은 어디든 비슷하지만, 조직마다 “왜 이렇게 하는지”의 맥락은 다 다르거든요.
여러분은 새로운 조직에 합류했을 때 1주차에 가장 막막했던 부분이 무엇이었나요? 그리고 온콜 대응하면서 겪었던 첫 장애, 지금 돌아보면 어떻게 다르게 대응하셨을 것 같으신가요? 댓글로 경험 나눠주시면 다음 글에 반영해보겠습니다.
이어서 읽으면 좋은 글로는 온콜 첫 장애 대응 실전 시나리오와 포스트모템 작성법, DevOps 이직 준비 시 포트폴리오에 꼭 담아야 할 프로젝트 유형을 준비하고 있습니다.
본 포스팅은 개인 경험을 바탕으로 한 정보 전달 목적이며, 조직마다 온보딩 과정은 다를 수 있습니다.