읽는 시간: 14분
안녕하세요, Frontend Platform Engineer로 일하고 있는 정석호입니다. 제가 입사 이후 직무명이 Frontend DevOps Engineer에서 Frontend Productivity Engineer를 거쳐 지금의 Frontend Platform Engineer가 되기까지, 어떤 변화가 있었는지 이야기 나눠보려고 해요.
이 글은 비슷한 길을 고민하는 프론트엔드 플랫폼분들께 조금이나마 도움이 되리라는 마음으로 적어보는 개인적인 경험담이에요.
왜 직무명이 바뀌었을까?
처음 회사에 합류했을 때, 제 역할은 Frontend DevOps Engineer였어요. 생소하실 수도 있는데, 주로 배포 파이프라인을 만들고 인프라를 확장하며 관리하는 역할이었죠.
1년 정도 지난 뒤에는 Frontend Productivity Engineer로 이름이 바뀌었는데, 단순히 배포뿐 아니라 개발자가 더 효율적으로 일할 수 있도록 여러 도구나 환경을 지원하는 쪽으로 무게중심이 옮겨갔거든요.
그리고 2023년 4월부터는 Frontend Platform Engineer로 자리매김하게 되었어요. 이제는 인프라나 생산성 도구 제공을 넘어, 프론트엔드를 위한 ‘플랫폼’을 만들고 전반적인 개발 경험과 서비스 안정성을 챙기고 폭발적인 영향력을 줄 수 있는 힘을 만드는 단계로 성장한 거예요.
조직의 필요에 따라 업무 범위가 넓어지면서 자연스럽게 이름도 바뀌게 되더라고요. 그럼 각각의 역할이 어떤 일을 했는지, 어떻게 달라졌는지 살펴볼게요.
ㅤ
2. Frontend DevOps Engineer
(2021년 5월 - 2022년 5월)
제가 처음 맡은 직무였어요. 당시 주로 했던 일은 다음과 같았어요:
모노리포 Monorepo 배포 파이프라인 최적화
기존에는 병렬 처리를 대강 하는 수준이었는데, 각 패키지가 변경될 때만 빌드를 트리거하도록 동적 병렬화를 도입했어요. 이 덕분에 빌드 시간과 리소스를 크게 줄일 수 있었죠.
배포 시스템 구축
CI/CD 툴만으로는 서비스 하나하나 배포하기가 쉽지 않았는데, 파이프라인을 잘 다듬어서 원하는 서비스만 골라서 올릴 수 있게 개선했어요.
CSR에서 SSR로 전환
프론트엔드 서비스의 렌더링을 CSR(Client Side Rendering)에서 SSR(Server Side Rendering)으로 바꾸는 마이그레이션을 시도했어요. 성능 개선이 필요했는데, 이 덕분에 사용자 경험이 훨씬 나아지는 씨앗이 심어졌습니다.
Terraform을 활용한 인프라 코드 관리
AWS 환경을 손으로 관리하면 실수가 잦고 재현이 어려운 편인데, Terraform을 도입해서 코드로 모든 구성을 관리했어요. 새로운 도메인 추가나 리소스 프로비저닝이 훨씬 안정적으로 변했죠.
이 시기에 가장 많이 느낀 건 ‘프론트엔드도 DevOps 관점에서 보면 임팩트 낼 수 있는 부분이 많구나’ 였어요. 배포를 병렬화하면서 프론트엔드 릴리즈 사이클이 얼마나 유연해질 수 있는지를 직접 경험했으니까요. 하지만 팀 규모가 작아서, 하나의 사람에게 요구되는 일이 많았어요. 인프라 세팅도 해야 하고, 배포 파이프라인도 짜야 하고, 때로는 CI 재시작을 손으로 하는 일도 잦았죠. 그래도 매일이 새로운 도전이었고, DevOps라는 이름이 주는 책임감을 온몸으로 느끼면서 성장할 수 있었던 시간이었어요.
ㅤ
3. Frontend Productivity Engineer
(2022년 5월 - 2023년 4월)
1년쯤 지났을 무렵, 팀에서는 ‘프론트엔드 개발자에게 단순 배포 파이프라인만 주는 게 과연 충분할까?’라는 질문을 던졌어요. 프론트엔드 개발 속도와 퀄리티를 동시에 챙기려면, 개발자가 편리하게 작업할 수 있는 환경과 도구를 지원해야 한다고 판단했던 거죠. 그래서 Frontend Productivity Engineer로 바뀌었어요.
주요 업무 내용은 이랬습니다:
개발 생산성 향상을 위한 환경 개선
CI Agent에서 빌드하는 것보다 개발자 로컬 머신(M1 Max)이 훨씬 빠르더라고요. 그래서 로컬에서 빌드된 결과물을 개발 서버로 바로 배포할 수 있는 파이프라인을 만들었어요. ‘로컬 빌드 → 원격 배포’ 워크플로우가 도입되면서, 코드 수정 후 배포 대기 시간이 대폭 줄었죠.
개발 환경 분기 기능 도입
서비스 개발을 할 때마다 브랜치를 만들고 로컬에서 확인하는 게 번거로웠는데, 각 개발자가 개인 서버처럼 쓸 수 있는 분기 환경을 제공하기 시작했어요. 버전 관리도 쉬워졌고, PR(풀 리퀘스트) 이전에 화면을 실제로 확인할 수 있고, 개발자별로 각자 할당받은 환경에서 테스트하다보니 개발서버를 점유하게되는 문제를 피할 수 있게 되었어요.
이 단계에서는 ‘개발자가 불편함 없이 코드를 짤 수 있도록 돕는 것’이 핵심이었어요.
개발자마다 선호하는 에디터나 로컬 환경이 모두 다르기에, 균일한 생산성을 보장하기가 쉽지 않았죠. 하지만 여러 시행착오 끝에 개발자 경험(Developer Experience, DX)을 의식한 도구와 환경을 제공하면서, 더 빠르고 안정적으로 서비스를 준비할 수 있었어요.
이 시기를 돌아보면, “프론트엔드를 다루는 건 단순한 코드 작성만이 아니다”라는 걸 깨달았어요. 개발자가 불편함 없이 일할 수 있는 환경이 곧 서비스 완성도와 팀 생산성을 좌우하더라고요.
4. Frontend Platform Engineer
(2023년 4월 - 현재)
지금은 Frontend Platform Engineer라는 타이틀 아래, 인프라와 개발 생산성 뿐만 아니라 프론트엔드 자체에 임팩트를 주기 위한 플랫폼을 구축하고 있어요. 말 그대로 ‘프론트엔드의 기반이 되는 모든 것’에 영향력을 미치는 단계라고 생각하시면 돼요.
주요 업무는 다음과 같아요:
통합형 프론트엔드 플랫폼 기획 및 운영
CSR, SSR, React Native 등 다양한 기술 스택을 아우르는 플랫폼을 기획했어요. 단순히 라이브러리를 제공하는 수준이 아니라, 서비스 특성에 따라 최적의 렌더링 방식을 선택하고 쉽게 적용할 수 있도록 각 플랫폼의 개발 가이드와 마이그레이션 자동화를 제공했죠.
서비스 안정성과 성능 보장
다양한 플랫폼으로 넘어가면서 플랫폼의 신뢰성이 중요해졌어요. 그래서 런타임 모니터링, 성능 지표 수집, 오류 알림 등을 플랫폼에 녹여서, 개발자가 쉽게 확인하고 개선할 수 있도록 도왔어요.
플랫폼 기반 CLI 툴과 JSCodeShift 제공
새로운 프로젝트를 시작할 때, 복잡한 설정 없이도 빠르게 시작할 수 있는 CLI와 마이그레이션 스크립트를 마련했어요. 예를 들면, Web에서 RN으로 이사가기위한 자동화 스크립트나, RN 서비스 배포 커맨드 툴 등을 제공해서, 신규 서비스가 빠르게 가동할 수 있도록 지원하고 있어요.
지금 팀 규모가 어느정도 많이 늘어나면서, 조직 차원에서 프론트엔드 플랫폼 전반을 설계하고 확장하는 중요성이 더욱 커졌어요.
‘플랫폼이 곧 프론트엔드의 경쟁력’이라는 인식이 확산되면서, 제 역할은 개발자가 단순히 코딩에만 집중하는 게 아니라, 올바른 플랫폼 위에서 혁신적인 경험을 제공할 수 있도록 돕는 방향으로 진화했어요.
ㅤ
직무명 변화가 주는 시사점
기대치는 어떻게 달라졌을까?
단계별로 아래처럼 역할과 기대가 달라졌어요!
DevOps 단계: 릴리즈 파이프라인과 인프라 세팅이 주된 기대였어요.
Productivity 단계: 여기서는 ‘개발자가 불편함 없이 일할 수 있는 환경’을 구축하는 데 초점이 맞춰졌죠.
Platform 단계: 이제는 ‘프론트엔드 생태계 전반을 위한 기반’을 책임져야 해요. 단순히 도구를 제공하는 수준이 아니라, 전략적 관점에서 플랫폼을 기획하고 운영하는 역할이었어요.
역량과 시야가 어떻게 넓어졌을까?
초기에는 Jenkins, GitHub Actions, CircleCI 같은 CI 도구와 Terraform으로 인프라 구성하는 기술 위주였어요. Productivity 단계에서는 로컬 개발 환경, CI/CD 워크플로우, QA 파이프라인 등 개발자 경험 전반에 대한 이해가 필요했어요. Platform 단계에 오니, 기술 스택 넘어 서비스 아키텍처와 사용자 경험, 모니터링 전략, 그리고 마이그레이션 전략까지 고려해야 했어요.
이처럼 직무명이 바뀐다는 건 단순히 타이틀만 바뀌는 게 아니었어요. 팀과 회사가 해당 역할에 바라는 바가 달라지고, 그에 따라 요구되는 역량과 관점이 확장되더라고요.
ㅤ
정리
프론트엔드 분야에서 DevOps, Productivity, Platform이라는 키워드를 달고 일해본 경험은 제게 큰 자산이 되었어요. 혹시 여러분도 ‘이 직무가 내게 맞을까?’ 고민하고 있다면, 제가 겪었던 변화 과정을 참고해 보면 어떨까요?
처음에는 작은 팀에서 배포 파이프라인을 만들며 기술적인 자신감을 쌓을 수 있어요. 그다음 단계에서는 개발자의 고충을 직접 듣고, 생산성을 올리는 데 중점을 둘 수 있어요. 마지막 단계에서는 회사 전반의 프론트엔드 경험을 좌우하는 플랫폼을 설계하고 운영하게 되죠.
물론 정답은 없어요. 회사마다 상황이 다르고, 팀의 목적도 다르니까요. 하지만 제 경험을 통해 ‘프론트엔드에도 이렇게 다양한 커리어 패스가 있다’는 걸 알아두시면, 방향을 정하는 데 작은 힌트가 되지 않을까 싶어요. 여러분들도 자신만의 여정을 그려보시면서, 어떤 길이 있었고 지금 어디쯤 있는지 상상해보면 재미있을 거예요!
주의: 이 글은 제 개인적인 경험을 바탕으로 작성되었습니다. 회사나 조직마다 사정이 다르니, 참고만 해주세요.
저와 함께 지속적으로 성장하면서 어려운 문제를 많이 풀어보고 싶다면?