Big Tech에서 일하며 배운 것: Frontend Engineer의 성찰
Source: Dev.to
소개
빅테크에서 일하는 것은 언제나 일종의 “새로운 세계로 가는 문”처럼 느껴집니다. 코드를 작성하면서 기술, 제품, 그리고 대규모 영향을 생각하게 됩니다. 수백만 명의 사용자를 지원하는 고트래픽 환경에서 수년간 일한 뒤, 배움은 명백한 것보다 훨씬 더 깊다는 것을 깨달았습니다.
빅테크에서는 기능을 단순히 “동작하게” 만들지 않습니다. 각 컴포넌트, 엔드포인트, 쿼리, 렌더링은 모두 효율적이고 예측 가능해야 합니다. 이는 개발자로서 사고 방식을 바꿔줍니다:
- 폴백, 재시도, 타임아웃, 관측성, 복원력을 고려한다.
- 변경하기 전에 측정한다 (Lighthouse, Web Vitals, 실험, A/B 테스트).
- 새로운 것을 구현하기 전에 스파이크, POC, 그리고 팀과의 아키텍처 결정을 진행한다.
- 지연 시간이 곧 UX라는 것을 이해한다.
그저 실행자가 아니라 미래와 규모를 고민하는 엔지니어가 됩니다.
디자인 시스템
예전에는 디자인 시스템을 멋진 문서와 컴포넌트 정리 정도로만 보았습니다. 이제는 인프라라는 것을 알게 되었고, API와 데이터베이스만큼이나 필수적입니다. 수십 개 팀이 같은 인터페이스를 사용한다면 일관성, 접근성, 효율성이 매우 중요해집니다.
- 컴포넌트는 안전하고, 안정적이며, 테스트 가능해야 한다.
- 접근성 (WCAG)은 선택 사항이 아니라 기본이다.
- 디자인 시스템을 발전시키면 전체 회사가 성장한다, 팀만이 아니라.
- 컴포넌트를 “제품 안의 제품”처럼 설계한다.
배운 점
- 사용자가 눈치채기 전에 버그를 해결한다.
- Sentry, Amplitude, LogZ, Datadog, Clarity 같은 도구는 오류가 언제든 발생한다는 것을 보여주지만, 차별점은 탐지·조사·해결 속도에 있다.
- 기능을 전달하기 전에 대시보드를 만드는 것이 필수이며, 데이터는 모두의 언어다 (엔지니어링, 제품, 디자인).
메트릭과 테스트
- “메트릭이 없는 코드는 어두운 곳에 있는 코드다”.
- 잘못된 흐름 하나가 실제 손실을 초래하는 환경에서는 테스트가 “있으면 좋은 것”이 아니라 필수가 된다.
- 높은 커버리지는 중요하지만 유용한 테스트가 훨씬 더 중요하다.
- 잘 작성된 테스트는 릴리즈를 가속화하고, 지연시키지 않는다.
- E2E는 유닛 테스트를 대체하지 않으며, 유닛 테스트는 통합 테스트를 대체하지 않는다.
- 수동 QA는 동작을 검증하지만, 기술적 품질을 검증하지는 않는다.
지속적인 피드백
- 피드백은 PR 리뷰, RFC, 기술 정렬, 회고, 리파인먼트, 페어링에서 일어난다.
- 이는 개발자와 사람으로서 빠르게 성장하도록 만든다.
- 피드백은 공격이 아니다; 1:1은 매우 중요하다.
- 코드 리뷰는 공감 + 의도의 연습이다.
- 팀에서 생각을 크게 말하는 것은 정렬을 만들고 부채를 방지한다.
- 결정을 내리는 것만큼 결정을 전달하는 것도 중요하다.
학제간 협업
함께 일하는 팀:
- 제품
- 디자인
- 백엔드
- 데이터
- QA
- 이해관계자
- 엔지니어링
아무도 혼자서 모든 것을 전달하지 않는다. 이 현실은 다음을 배우게 한다:
- 범위 협상하기.
- 비기술자에게 기술적 커밋을 설명하기.
- 트레이드오프하기.
- 비즈니스의 실제 우선순위를 이해하기.
영향 측정
당신의 작업은 다음으로 측정된다:
- 얼마나 오류를 줄였는가.
- 얼마나 사용자 경험을 개선했는가.
- 얼마나 다른 팀의 속도를 높였는가.
- 얼마나 비용을 절감했는가.
- 사용자에게 얼마나 고통을 없앴는가.
코드는 수단일 뿐; 최고의 인재들이 가진 가장 큰 차별점은 오너십이었다:
- 요청받기 전에 문제를 잡는다.
- 사용자에게 신경 쓴다.
- 장기적인 관점을 가진다.
- 자신이 만든 것이 미치는 영향을 이해한다.
- 진정으로 협업한다.
- 직함 없이도 방향을 제시한다.
빅테크는 큰 사고를 가르친다
그런 환경에서 일하면 세계관이 바뀝니다:
- 제품의 우선순위를 이해한다.
- 진정한 규모와 마주한다.
- 기술적으로 성숙해진다.
- 엔지니어링 규율을 갖춘다.
- 좋은 결정을 내릴 수 있는 맥락을 만든다.
- 자율성을 키운다.
- 복잡한 시스템을 단순화하는 법을 배운다.
이 경험이 자동으로 더 나은 엔지니어가 되는 것은 아니지만, 스스로가 되도록 요구하는 환경에 당신을 놓아준다.
이 경험을 통해 다음을 훨씬 더 잘 이해하게 되었다:
- 규모
- 아키텍처
- 협업
- 제품
- 영향
- 책임
- 진정한 엔지니어링
그리고 가장 중요한 점:
기술은 코드에 관한 것이 아니다. 기술은 규모에 맞게 문제를 해결하는 것이다.