Skip to content
←

Split View: FDE 온보딩 90일 — 파악, 단독 티켓, 주도 미션의 세 달

✨ Learn with Quiz
|

FDE 온보딩 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 완전 가이드 시리즈

The First 90 Days as an FDE — Mapping, Solo Tickets, and a Led Mission

Why the 90 Days Must Be Designed

A regular engineer's onboarding has one layer: adapt to the new company's codebase and people. An FDE's onboarding has two. You are learning your own company's product and organization while simultaneously adapting to the systems and people of the customer you cover. Because two unfamiliar environments overlap, walking in without a plan means that three months later you have taken root in neither.

So the first quarter should be designed, not drifted through. The 90-day frame below is not copied from any company's program; it is a construct generalized from the structure of the FDE role. The skeleton has three stages: month one is mapping, month two is solo tickets, month three is a led mission. Fix each month's goal in one sentence and the weekly checklists follow naturally.

The principle underneath is the trust account. At a customer site, an FDE's voice comes not from the title but from accumulated trust, and trust accumulates not from one big win but from the repetition of small promises kept. The purpose of designing the 90 days is not a flashy debut; it is opening this account without going negative. Conversely, a bad first impression made in month one charges interest for the rest of the engagement. Every item in the checklists below is, in the end, a deposit into this account.

Month One — Map the Environment, the Product, and the People

The goal of the first month is not results; it is a map. The accuracy of the map you draw here sets the speed of the following two months.

  • Week 1 — a full census of access. VPN, SSO, code repositories, the ticket system, and the paths into customer environments: check every account one by one and turn whatever does not work into a request list. Install your own product from scratch using only the documentation. Where the install blocks you is exactly where it blocks customers.
  • Week 2 — the technical map of the customer environment. Draw the customer's system architecture as a diagram yourself, read the deployment path and the last three incident writeups. The parts you cannot draw become your question list.
  • Week 3 — the people map. Sort out who at the customer decides, who actually uses the product, and who will be the champion on your side. Write down your own company's escalation path while you are at it. Meetings are still for observing at this stage.
  • Week 4 — ticket shadowing. Watch a senior colleague handle tickets end to end, build an inventory of the runbooks that exist, and compile a glossary of the customer's abbreviations and vocabulary.

The trap of month one is impatience. Skip the mapping because you want to show something quickly, and the speed you gain in month two returns as an accident in month three.

Month Two — Handle Tickets Alone

The goal of the second month is the first deposit in the trust account. Completeness matters more than size.

  • Weeks 5 and 6 — take low-risk tickets solo. Record the entire handling process, and run the customer communication yourself with a supervisor on CC. Whether the interim update went out when promised matters more than how fast you solved it.
  • Weeks 7 and 8 — raise the ticket difficulty one notch and join incident response as a secondary. Pick one ticket you handled and write a recurrence-prevention proposal. That document often becomes your first quick win.

The trap of this month is hunger for speed. Trust accumulates from the regularity of communication, not the quickness of resolution. A delay that was announced in advance does not drain trust; a fast fix that arrives after radio silence leaves anxiety behind.

Month Three — Lead a Mission

The goal of the third month is to lead one small thing from start to finish.

  • Weeks 9 and 10 — pick a two-week-sized project, one integration or one migration, and lead it. Before starting, write the success criteria down and agree on them with the customer. A project started without a criteria document can never truly be declared finished.
  • Weeks 11 and 12 — execute, then leave a retrospective. Run a regular customer meeting alone, and pay your onboarding debt forward by fixing the onboarding docs where you got stuck. The amount by which the next person's 90 days shrink is your contribution.

What Should Be Visible When the 90 Days End

At the three-month mark, three questions reveal whether the onboarding worked. First, can you draw your customer's system diagram from a blank page? Second, can you explain that customer's stakeholder map — who decides, who uses? Third, when an incident report arrives, do you already know what your first 30 minutes look like?

If any of the three is blurry, go back to month-one mapping for that area alone. Onboarding is a circuit, not a straight line, and rewinding to a weak segment is itself the normal trajectory. The goal of month three is not to be perfect; it is to be someone who knows precisely where their own gaps are.

If all three have answers, onboarding is done. If the third is blurry, the next post is exactly that story: the incident diagnosis playbook.

Practice by Doing

The feel of those 90 days can be rehearsed in simulation first.

  • FDE Career RPG — starting at low levels and earning access and trust is a miniature of onboarding month one.
  • FDE Curriculum Roadmap — pre-check the technical items of your month-one map as a checklist.

FDE Complete Guide series