- 90일을 설계해야 하는 이유
- 1개월 차 — 환경, 제품, 사람을 파악한다
- 2개월 차 — 단독 티켓을 처리한다
- 3개월 차 — 미션을 주도한다
- 90일이 끝났을 때 보여야 하는 것
- 직접 연습하기
90일을 설계해야 하는 이유
일반 엔지니어의 온보딩은 한 겹입니다. 새 회사의 코드베이스와 사람에 적응하면 됩니다. FDE의 온보딩은 두 겹입니다. 자사의 제품과 조직을 익히는 동시에, 담당 고객사의 시스템과 사람에도 적응해야 합니다. 낯선 환경이 두 개가 겹치기 때문에, 계획 없이 들어가면 석 달이 지나도 어느 쪽에서도 뿌리를 내리지 못한 상태가 됩니다.
그래서 첫 분기는 흘러가게 두지 말고 설계해야 합니다. 아래의 90일 프레임은 특정 회사의 제도를 옮긴 것이 아니라, FDE 직무의 구조에서 일반화해 구성한 틀입니다. 큰 뼈대는 세 단계입니다. 1개월 차는 파악, 2개월 차는 단독 티켓, 3개월 차는 주도 미션. 각 달의 목표를 한 문장으로 잡아 두면, 매주의 체크리스트가 자연스럽게 따라 나옵니다.
밑에 깔린 원리는 신뢰 계좌입니다. 고객사에서 FDE의 발언권은 직함이 아니라 쌓인 신뢰에서 나오고, 신뢰는 큰 성과 한 번이 아니라 작은 약속을 지키는 반복에서 쌓입니다. 90일 설계의 목적은 화려한 데뷔가 아니라 이 계좌를 마이너스 없이 개설하는 것입니다. 반대로 첫 달의 나쁜 첫인상은 남은 임기 내내 이자를 뗍니다. 아래 체크리스트의 항목 하나하나가 결국은 이 계좌의 입금 행위입니다.
1개월 차 — 환경, 제품, 사람을 파악한다
첫 달의 목표는 성과가 아니라 지도입니다. 여기서 그린 지도의 정확도가 나머지 두 달의 속도를 결정합니다.
- 1주 차 — 접근 권한 전수 조사. VPN, SSO, 코드 저장소, 티켓 시스템, 고객 환경 접속 경로까지 계정을 하나씩 확인하고, 안 되는 것을 목록으로 만들어 요청합니다. 자사 제품을 문서만 보고 백지에서 설치해 봅니다. 설치가 막히는 지점이 곧 고객이 막히는 지점입니다.
- 2주 차 — 고객 환경의 기술 지도. 담당 고객사의 시스템 구성을 직접 다이어그램으로 그려 보고, 배포 경로와 최근 장애 이력 세 건을 읽습니다. 그림이 안 그려지는 부분이 질문 목록이 됩니다.
- 3주 차 — 사람 지도. 고객사에서 누가 의사결정자이고, 누가 실사용자이고, 누가 우리 편이 되어 줄 챔피언인지 구분합니다. 자사 쪽의 에스컬레이션 경로도 같이 정리합니다. 미팅은 아직 참관이 기본입니다.
- 4주 차 — 티켓 섀도잉. 선배가 티켓을 처리하는 과정을 처음부터 끝까지 관찰하고, 존재하는 런북을 목록화하고, 고객사가 쓰는 약어와 용어로 용어집을 만듭니다.
첫 달의 함정은 조급함입니다. 빨리 뭔가 보여 주고 싶어서 지도 그리기를 건너뛰면, 두 달 차에 낸 속도가 세 달 차의 사고로 돌아옵니다.
2개월 차 — 단독 티켓을 처리한다
둘째 달의 목표는 신뢰 계좌의 첫 입금입니다. 크기보다 완결성이 중요합니다.
- 5주 차와 6주 차 — 위험이 낮은 티켓을 단독으로 잡습니다. 처리 과정 전체를 기록으로 남기고, 고객과의 소통은 감독자가 참조로 들어온 상태에서 직접 해 봅니다. 약속한 시점에 중간 보고가 나갔는지가 해결 속도보다 중요합니다.
- 7주 차와 8주 차 — 티켓의 난도를 한 단계 올리고, 장애 대응에 부담당으로 참여합니다. 처리한 티켓 중 하나를 골라 재발 방지 제안을 문서로 만들어 봅니다. 이 문서가 첫 퀵 윈이 되는 경우가 많습니다.
이 달의 함정은 속도 욕심입니다. 신뢰는 해결의 빠르기가 아니라 소통의 규칙성에서 쌓입니다. 늦더라도 예고된 지연은 신뢰를 깎지 않지만, 빠르더라도 무소식 뒤의 완료 보고는 불안을 남깁니다.
3개월 차 — 미션을 주도한다
셋째 달의 목표는 작은 것 하나를 처음부터 끝까지 주도해 보는 것입니다.
- 9주 차와 10주 차 — 통합 하나, 마이그레이션 하나 같은 2주 크기의 프로젝트를 골라 주도합니다. 시작 전에 성공 기준을 문서로 적고 고객과 합의합니다. 기준 문서 없이 시작한 프로젝트는 끝나도 끝났다고 말할 수 없게 됩니다.
- 11주 차와 12주 차 — 실행하고, 회고를 남깁니다. 고객 정기 미팅을 단독으로 진행해 보고, 자신이 온보딩에서 막혔던 지점을 온보딩 문서 개선으로 되돌려 놓습니다. 다음 사람의 90일이 짧아지는 만큼이 내 기여입니다.
90일이 끝났을 때 보여야 하는 것
석 달이 지난 시점에서 스스로에게 세 가지를 물어보면 온보딩의 성패가 드러납니다. 첫째, 담당 고객의 시스템 다이어그램을 아무것도 안 보고 그릴 수 있는가. 둘째, 그 고객사의 이해관계자 지도를 설명할 수 있는가. 누가 결정하고, 누가 사용하는가. 셋째, 장애 신고가 오면 첫 30분 동안 무엇을 할지 정해져 있는가.
어느 하나라도 답이 흐릿하면, 그 영역만 골라 1개월 차의 지도 그리기로 되돌아가면 됩니다. 온보딩은 직선이 아니라 회로여서, 약한 구간을 찾아 되감는 것 자체가 정상 궤도입니다. 석 달째의 목표는 완벽해지는 것이 아니라, 어디가 비어 있는지를 스스로 아는 상태가 되는 것입니다.
셋 다 답이 나오면 온보딩은 끝난 것입니다. 세 번째 질문에 답이 흐릿하다면 다음 글이 정확히 그 이야기입니다. 장애 진단 플레이북으로 넘어갑니다.
직접 연습하기
온보딩 90일의 감각은 시뮬레이션으로 미리 겪어 볼 수 있습니다.
- FDE 엔지니어 키우기 RPG — 낮은 레벨에서 시작해 접근 권한을 얻고 신뢰를 쌓는 구조가 온보딩 첫 달의 축소판입니다.
- FDE 커리큘럼 로드맵 — 1개월 차에 만들 지도의 기술 항목들을 체크리스트로 미리 점검할 수 있습니다.
FDE 완전 가이드 시리즈