어떤 배경이든 절반은 이미 있다
FDE로 전환을 고민하는 엔지니어의 대부분은 백엔드, 데브옵스·SRE, 데이터 엔지니어 중 하나에서 출발합니다. 먼저 좋은 소식부터. 2편의 기술 지도에 그린 8개 도메인을 기준으로 재 보면, 어느 배경이든 절반가량은 이미 채워져 있습니다. FDE는 무에서 시작하는 직무가 아니라 기존 엔지니어링 경력을 현장이라는 좌표계로 옮기는 직무입니다.
나쁜 소식은 비어 있는 절반이 배경마다 다르다는 것입니다. 그래서 전환 준비는 남의 로드맵을 따라가는 것이 아니라 자기 배경의 갭 분석에서 시작해야 합니다. 아래에서 세 배경을 차례로 갑니다. 자기 배경을 찾아 읽되, 다른 배경의 칸도 훑어보면 좋습니다. 팀에 합류하면 그 배경의 동료들과 서로의 갭을 메꿔 주게 되기 때문입니다.
백엔드 엔지니어라면
이미 가진 것 — API 설계와 통합, 데이터베이스, 코드 품질, 그리고 제품 코드를 읽고 고치는 속도입니다. FDE의 결과물이 결국 고객 환경에서 돌아가는 코드라는 점에서, 코드를 빠르고 안전하게 쓰는 능력은 전환의 가장 단단한 밑천입니다. 8개 도메인으로 말하면 데이터베이스는 대체로 실무선, 리눅스는 최소선 언저리에 있습니다.
채워야 할 것 — 인프라 계층입니다. 쿠버네티스와 네트워크는 백엔드 업무에서 플랫폼팀이 대신 해 주던 영역이라 비어 있기 쉽습니다. 그리고 운영 경험. 자기가 만든 서비스의 장애를 새벽에 받아 본 경험이 없다면, 온콜이 있는 팀으로 옮기거나 사이드 프로젝트를 실제로 운영해서라도 채워야 합니다. 마지막으로 낯선 코드베이스 진입 속도 — 남이 만든 시스템을 문서 없이 읽는 훈련은 오픈소스 기여가 좋은 연습장입니다.
데브옵스·SRE라면
이미 가진 것 — 기술 축의 대부분입니다. 리눅스, 네트워크, 쿠버네티스, 관측성, 클라우드까지, 8개 도메인 중 다섯이 업무 그 자체였을 가능성이 높습니다. 장애 대응의 순서 감각, 런북 문화, 비난 없는 포스트모템 같은 운영 규율도 이미 몸에 있습니다. 기술 갭만 보면 세 배경 중 가장 유리합니다.
채워야 할 것 — 방향이 다른 두 가지입니다. 첫째, 제품 코드 작성. 인프라 자동화 스크립트와 제품 기능 코드는 근육이 다릅니다. 고객 요구를 받아 기능을 만들어 내는 경험이 없다면 작게라도 만들어야 합니다. 둘째, 커뮤니케이션의 방향 전환. 지금까지의 대화 상대는 대부분 내부 개발자였지만, FDE의 상대는 외부의 비엔지니어입니다. 내부 위키에 쓰던 문서를 고객에게 보내는 보고서로 바꾸는 훈련이 필요합니다.
데이터 엔지니어라면
이미 가진 것 — 데이터베이스와 SQL은 실무선이고, 파이프라인을 짜며 얻은 데이터 지형 감각이 큰 무기입니다. 고객 환경에서 가장 먼저 부딪히는 일 중 하나가 고객 데이터의 구조와 품질을 파악하는 것인데, 이 일을 업으로 해 온 사람입니다. 데이터 경계와 개인정보 취급의 감각도 이미 있습니다.
채워야 할 것 — 서비스 운영 계층입니다. 배치 파이프라인의 세계와 실시간 서비스의 세계는 장애의 문법이 다릅니다. 네트워크, 인증, 그리고 사용자가 지금 겪고 있는 장애를 실시간으로 진단하는 경험이 상대적으로 비어 있기 쉽습니다. 관측성도 파이프라인 모니터링에서 서비스 모니터링으로 확장이 필요합니다.
공통으로 채워야 할 것 — 고객 앞에 서는 기술
세 배경 모두에서 가장 공통적으로 비어 있는 칸은 기술이 아니라 고객 대면입니다. 구체적으로는 세 가지입니다. 첫째, 말로 하는 데모. 만든 것을 비엔지니어 앞에서 15분 안에 시연하고 질문을 받는 형식은 연습 없이는 안 됩니다. 사내 발표라도 기회를 만들어 횟수를 쌓아야 합니다. 둘째, 나쁜 소식 전달. 5편에서 다룬 기대치 관리는 읽는 것과 하는 것의 거리가 특히 먼 기술입니다. 셋째, 모호한 요구를 스코프 문서로 바꾸는 것. "이런 게 되면 좋겠어요"를 받아서 성공 기준이 있는 한 페이지로 만드는 연습은 사이드 프로젝트의 가상 고객으로도 할 수 있습니다.
그리고 글로벌 포지션을 노린다면 영어는 기술 스택의 일부입니다. 유창함보다 장애 상황에서 정확하게 보고할 수 있는가가 기준입니다.
6개월 전환 로드맵
아래는 2개월 단위로 구성한 일반 가이드입니다. 재직 중 병행을 전제로 했고, 개인의 출발점에 따라 기간은 늘고 줄 수 있습니다.
- 1개월 차와 2개월 차 — 갭 측정과 기반 다지기. FDE 커리큘럼 로드맵으로 자기 위치를 재고, 가장 비어 있는 도메인 두 개를 골라 최소선까지 끌어올립니다. 홈랩을 만들어 작은 쿠버네티스 클러스터 하나를 직접 운영해 보는 것이 여러 갭을 동시에 건드리는 지름길입니다.
- 3개월 차와 4개월 차 — 증거 만들기. 공개 API가 있는 제품 하나를 골라, 가상의 고객 시나리오를 정해 통합 프로젝트를 만듭니다. 결과물은 코드만이 아니라 아키텍처 그림, 성공 기준 문서, 장애 런북까지입니다. 이 산출물이 증거 포트폴리오의 핵심이 됩니다. 병행으로 FDE 엔지니어 키우기 RPG류의 진단 연습을 반복해 낯선 환경의 첫 30분을 몸에 붙입니다.
- 5개월 차와 6개월 차 — 이야기로 바꾸고 지원하기. 기존 경력에서 현장성 있는 에피소드를 골라 상황-행동-결과의 이야기로 다듬고, 포트폴리오와 함께 지원 서류를 만듭니다. 인터뷰 형식과 준비법은 다음 편에서 자세히 다룹니다.
6개월이 지나면 완성된 FDE가 되는 것이 아니라, FDE 팀이 뽑아서 키울 만한 사람이 됩니다. 그것이 이 로드맵의 정직한 목표입니다.
직접 연습하기
전환 준비의 두 축인 갭 측정과 진단 연습을 이 블로그의 도구로 시작할 수 있습니다.
- FDE 커리큘럼 로드맵 — 10개 도메인 65개 스킬로 갭 분석을 하고 진행률을 추적합니다.
- FDE 엔지니어 키우기 RPG — 낯선 환경 진단의 의사결정을 미션으로 반복 연습합니다.
FDE 완전 가이드 시리즈
현재 단락 (1/21)
FDE로 전환을 고민하는 엔지니어의 대부분은 백엔드, 데브옵스·SRE, 데이터 엔지니어 중 하나에서 출발합니다. 먼저 좋은 소식부터. [2편의 기술 지도](/blog/career/...