테크 플랫폼 개발자의 현실: 최고의 동료와 대규모 서비스, 그리고 끝없는 성장 압박

테크 플랫폼 개발자의 현실: 최고의 동료와 대규모 서비스, 그리고 끝없는 성장 압박#

국내 개발자 채용 시장을 이야기할 때 빠지지 않는 회사들이 있다.

네이버.

카카오.

쿠팡.

배달의민족.

그리고 라인, 토스, 당근처럼 자체 서비스를 중심으로 거대한 사용자 기반과 기술 조직을 구축한 회사들이다.

한때 개발자 커뮤니티에서는 네이버, 카카오, 라인, 쿠팡, 배달의민족의 앞글자를 따 네카라쿠배라는 표현이 널리 사용됐다.

이 표현 자체는 지금도 통용되지만, 2026년의 개발자 시장을 설명하기에는 조금 좁다.

오늘날에는 특정 회사 다섯 곳보다는

대규모 사용자를 가진 기술 중심의 플랫폼·프로덕트 기업

이라는 범주로 보는 편이 더 정확하다.

우리는 매일 검색한다.

메신저를 사용한다.

상품을 주문한다.

음식을 배달시킨다.

콘텐츠를 본다.

결제한다.

지도에서 장소를 찾는다.

이 과정 상당 부분이 거대한 플랫폼 위에서 이루어진다.

이들 서비스는 단순한 웹사이트나 모바일 앱이 아니다.

수천만 사용자가 동시에 사용하는 사회적 인프라에 가깝다.

그 시스템을 만드는 개발자 역시 단순히 화면 하나를 만드는 사람이 아니다.

대규모 트래픽과 방대한 데이터, 복잡하게 연결된 시스템을 다루는 엔지니어가 된다.

SI 개발자가 고객의 성을 지어주는 전문 용병이고, 스타트업 개발자가 미지의 영역을 탐험하는 개척자, 대기업·금융권 개발자가 이미 구축된 거대한 성을 안정적으로 운영하는 수비대라면 플랫폼 기업의 개발자는 이미 거대한 도시를 운영하면서 동시에 새로운 도시를 계속 확장하는 건설자이자 운영자에 가깝다.

이미 엄청난 사용자가 존재한다.

서비스를 멈출 수 없다.

그런데 계속 새로운 기능을 만들어야 한다.

기존 시스템을 유지하면서 새로운 기술도 도입해야 한다.

바로 이 모순이 플랫폼 개발의 재미이자 어려움이다.

1.1 플랫폼 기업은 무엇이 다른가#

플랫폼 기업의 가장 큰 특징은 직접 만든 서비스가 곧 회사의 핵심 사업이라는 것이다.

SI에서는 고객이 요구한 시스템을 만든다.

대기업 사내 IT에서는 회사의 업무를 지원하는 시스템을 만드는 경우가 많다.

플랫폼 기업에서는 개발팀이 만드는 소프트웨어 자체가 상품인 경우가 많다.

검색 결과가 늦게 나오면 사용자가 떠난다.

추천 알고리즘이 나쁘면 매출이 떨어진다.

결제가 실패하면 바로 매출 손실로 이어진다.

앱이 느려지면 고객센터에 문의가 폭주한다.

개발 품질이 곧 사업 성과와 연결된다.

그래서 개발 조직의 영향력이 상대적으로 큰 편이다.

1.2 첫 번째 장점: 뛰어난 동료에게서 배우는 속도가 빠르다#

플랫폼 기업의 장점을 이야기할 때 자주 등장하는 표현이 있다.

최고의 복지는 동료다.

다소 과장된 표현처럼 보일 수도 있지만 개발자에게는 꽤 현실적인 이야기다.

예를 들어 며칠 동안 해결하지 못한 동시성 문제가 있다고 해보자.

서비스에서 간헐적으로 중복 주문이 발생한다.

로그를 아무리 봐도 원인을 찾기 어렵다.

시니어 개발자가 코드를 함께 살펴본다.

그리고 질문한다.

"이 요청이 동시에 두 번 들어오는 상황은 고려했나요?"

그 순간 문제의 방향이 완전히 바뀐다.

단순 버그라고 생각했던 문제가

  • Race Condition
  • Lock
  • Transaction
  • Idempotency
  • 메시지 처리 방식

과 연결되어 있다는 것을 깨닫는다.

혼자 공부했다면 며칠 또는 몇 주가 걸릴 내용을 짧은 대화를 통해 이해할 수도 있다.

이것이 좋은 동료가 주는 힘이다.

1.3 코드 리뷰는 검사가 아니라 지식 전달 과정이다#

성숙한 개발 조직에서 코드 리뷰는 단순히

"버그 있나 확인해주세요."

라는 절차가 아니다.

설계와 사고방식을 공유하는 과정이다.

예를 들어 이런 코드가 있다고 해보자.

for (User user : users) {
    if (user.getStatus().equals("ACTIVE")) {
        sendMessage(user);
    }
}

리뷰에서는 단순히 문법을 지적하는 것보다 다음과 같은 질문이 나올 수 있다.

ACTIVE 사용자를 조회하는 책임이 여기 있어야 할까요?

데이터베이스에서 처음부터 활성 사용자만 가져오는 것이 비용 측면에서 더 낫지 않을까요?

메시지 발송에 실패하면 재시도는 어떻게 처리하나요?

동일 사용자에게 메시지가 중복 발송될 가능성은 없나요?

코드 열 줄이 시스템 설계에 대한 토론으로 확장된다.

좋은 코드 리뷰를 반복해서 경험하면 개발자는 단순히 코드를 작성하는 방법보다 왜 이런 구조를 선택하는지 설명하는 능력을 배우게 된다.

1.4 하지만 모든 코드 리뷰가 이상적인 것은 아니다#

플랫폼 기업이라고 모든 팀이 완벽한 개발문화를 가진 것은 아니다.

팀마다 다르다.

리더마다 다르다.

서비스 상황에 따라서도 다르다.

리뷰가 지나치게 오래 걸릴 수도 있다.

취향 차이가 기술적 논쟁으로 포장될 수도 있다.

시니어의 의견에 사실상 반대하기 어려운 팀도 있을 수 있다.

따라서

플랫폼 회사에 가면 무조건 최고의 개발문화를 경험한다.

라고 생각하는 것은 위험하다.

결국 회사보다 중요한 것은 실제 입사하는 팀의 문화다.

1.5 두 번째 장점: 진짜 대규모 시스템을 경험한다#

개인 프로젝트에서 사용자가 1만 명이라면 꽤 성공한 서비스다.

하지만 대형 플랫폼에서는 상황이 다르다.

사용자가 수백만 또는 수천만 명이다.

상품이 수억 개일 수도 있다.

로그 데이터가 하루에 수십억 건 쌓일 수도 있다.

하나의 API가 초당 수만 번 호출될 수도 있다.

이 정도 규모에서는 개발 방식 자체가 바뀐다.

1.5.1 작은 비효율이 거대한 비용이 된다#

API 응답이 50ms 느려졌다고 가정해보자.

작은 서비스에서는 큰 문제가 아닐 수 있다.

하지만 수천만 번 호출되는 API라면 서버 사용량과 사용자 경험에 의미 있는 차이가 생길 수 있다.

데이터베이스 쿼리 하나가 조금 비효율적이다.

개발 환경에서는 문제가 없다.

운영 환경에 들어가면 CPU 사용률이 급격하게 상승한다.

그래서 플랫폼 개발자는 자연스럽게 다음을 생각하게 된다.

  • 캐시
  • 비동기 처리
  • 메시지 큐
  • 데이터 파티셔닝
  • 샤딩
  • 부하 분산
  • 장애 격리
  • 서킷 브레이커
  • 데이터 정합성
  • 관측 가능성

개발 교재에서 보던 개념이 실제 문제가 된다.

1.6 세 번째 장점: 기술을 사용하는 것에서 기술을 만드는 단계로 갈 수 있다#

작은 조직에서는 오픈소스를 가져와 사용하는 것이 일반적이다.

플랫폼 기업에서는 어느 순간 기존 기술로 해결하기 어려운 문제를 만난다.

트래픽이 너무 크다.

데이터가 너무 많다.

기존 도구가 회사 환경과 맞지 않는다.

그때 내부 플랫폼이나 도구를 직접 만들기 시작한다.

카카오는 공식 기술 사이트를 통해 자체 개발한 도구와 오픈소스 라이브러리를 공개하고 있고, 2026년에도 if(kakao)를 통해 내부 기술과 개발 경험을 지속적으로 공유하고 있다.

쿠팡 역시 별도의 엔지니어링 블로그를 운영하면서 AI, 데이터, 인프라, 모바일과 같은 다양한 영역의 개발 경험을 공개하고 있으며 자체 머신러닝 플랫폼을 구축해 검색, 추천, 수요예측 등의 모델을 운영해왔다.

개발자는 이런 환경에서

오픈소스를 사용하는 개발자

에서

플랫폼과 도구를 만드는 개발자

로 성장할 기회를 얻을 수 있다.

1.7 2026년 플랫폼 기업의 중심은 AI로 빠르게 이동하고 있다#

몇 년 전 플랫폼 기업의 기술 경쟁력을 설명할 때는 흔히 다음 기술들이 등장했다.

  • MSA
  • Kubernetes
  • Kafka
  • 대규모 데이터 처리
  • 추천 시스템
  • 검색 엔진

현재도 중요하다.

하지만 여기에 AI가 빠르게 추가되고 있다.

네이버는 2026년 AI 검색 기능을 확대하고 있으며, 세종 데이터센터를 기반으로 NVIDIA와 함께 대규모 AI 인프라 확대를 추진하고 있다.

우아한형제들 역시 AI를 일부 개발자만 사용하는 도구가 아니라 회사 전체 업무에 확장하는 방향으로 움직이고 있으며, 실제 서비스와 사내 시스템에 RAG, LLM, AI 도우미 등을 적용하는 사례를 지속적으로 공개하고 있다.

플랫폼 개발자에게 이제 AI는 별도의 전문 분야만은 아니다.

백엔드 개발자도 AI 서비스를 연결한다.

프런트엔드 개발자도 AI UX를 고민한다.

데이터 개발자는 LLM 학습과 평가 데이터를 다룬다.

인프라 개발자는 GPU와 AI 워크로드를 운영한다.

AI가 기존 개발 영역 안으로 들어오고 있다.

1.8 AI가 코드를 잘 만들어도 플랫폼 엔지니어가 필요한 이유#

AI가 코드 작성 속도를 크게 높이면 이런 의문이 생긴다.

"대규모 플랫폼에서도 개발자가 예전만큼 많이 필요한가?"

하지만 규모가 커질수록 단순 코드 작성보다 어려운 문제가 많아진다.

AI에게

"Kafka consumer 만들어줘."

라고 요청하면 코드는 쉽게 만들 수 있다.

하지만 다음 질문은 훨씬 어렵다.

메시지 순서를 반드시 보장해야 하는가?

중복 처리는 어떻게 할 것인가?

consumer가 장애 나면 어떻게 복구하는가?

처리량이 10배 증가하면 어떻게 확장할 것인가?

데이터 유실 가능성을 어느 수준까지 허용할 것인가?

이런 판단은 시스템과 비즈니스를 함께 이해해야 한다.

우아한형제들이 2026년 공개한 기술 콘텐츠에서도 코드 작성이 쉬워질수록 시스템 전체를 이해하고 트래픽과 데이터에 대한 기술적 판단을 내리는 엔지니어링 역량의 중요성을 강조하고 있다.

AI 시대에 플랫폼 엔지니어의 가치는 코드 생산량보다 판단의 품질로 이동하고 있다.

1.9 네 번째 장점: 데이터가 의사결정의 언어가 된다#

대규모 플랫폼에서 새로운 기능을 배포하면 수많은 사용자가 반응한다.

그래서

"제가 보기에는 이게 더 좋은 것 같습니다."

만으로 중요한 의사결정을 하기 어렵다.

실제로 사용자가 어떻게 행동하는지 확인해야 한다.

예를 들어 검색 결과 화면을 바꾸고 싶다고 하자.

단순히 디자인을 바꾸고 끝나는 것이 아니다.

일부 사용자에게 새로운 화면을 제공한다.

기존 화면과 비교한다.

사용자가 어떤 결과를 클릭하는지 확인한다.

검색 이후 구매나 이용 행동이 달라지는지 본다.

이것이 실험 기반 개발이다.

1.10 개발자는 코드뿐 아니라 지표를 보게 된다#

플랫폼 개발자는 자신이 만든 기능의 결과를 데이터로 확인할 수 있다.

새 추천 알고리즘을 배포했다.

클릭률이 올라갔다.

API를 최적화했다.

응답 시간이 줄었다.

앱 시작 속도를 개선했다.

사용자 이탈이 감소했다.

이런 경험이 반복되면 개발자의 관점이 바뀐다.

처음에는 이렇게 생각한다.

"기능 구현 완료했습니다."

경험이 쌓이면 질문이 달라진다.

"이 기능이 실제 사용자 행동을 바꿨나요?"

이 차이가 단순 구현 개발자와 프로덕트 엔지니어를 나누는 중요한 기준 중 하나다.

1.11 다섯 번째 장점: 기술을 공유하는 문화가 강하다#

국내 대형 테크 기업의 특징 가운데 하나는 자신들의 개발 경험을 외부에 공개한다는 것이다.

카카오는 공식 기술 블로그와 if(kakao)를 운영한다.

우아한형제들은 기술 블로그를 통해 백엔드, 데이터, 인프라, AI, 프런트엔드 등 다양한 실제 개발 사례를 지속적으로 공개하고 있다. 2026년에도 AI 활용과 시스템 개발 사례가 활발하게 올라오고 있다.

쿠팡도 별도의 엔지니어링 블로그를 통해 인프라와 머신러닝, 제품 개발 경험을 공유한다.

이런 문화는 회사의 기술 브랜딩만을 위한 것은 아니다.

개발자가 자신이 했던 일을 글로 정리하려면 다음 질문에 답해야 한다.

왜 이 문제가 발생했는가?

왜 이 기술을 선택했는가?

다른 방법은 없었는가?

결과는 어땠는가?

결국 글을 쓰는 과정 자체가 엔지니어링 경험을 정리하는 과정이 된다.

1.12 첫 번째 단점: 뛰어난 동료가 심리적인 압박이 될 수 있다#

좋은 동료는 개발자를 빠르게 성장시킨다.

하지만 동시에 이런 생각을 하게 만들기도 한다.

"나는 왜 이것도 모르지?"

이전 회사에서는 자신이 가장 잘하는 개발자였을 수도 있다.

그런데 새로운 팀에 들어왔더니 상황이 달라진다.

옆자리 개발자는 오픈소스 프로젝트에 직접 기여한다.

다른 개발자는 네트워크 문제를 패킷 수준에서 분석한다.

또 다른 개발자는 JVM 내부 동작을 설명한다.

회의에서 처음 듣는 기술 용어가 계속 등장한다.

어느 순간 생각한다.

"내가 여기 들어온 게 실수 아니었을까?"

이런 감정을 흔히 가면 증후군이라고 표현한다.

1.13 모든 것을 알 필요는 없다#

여기서 중요한 사실이 있다.

대규모 플랫폼을 한 명이 모두 이해하는 것은 사실상 불가능하다.

검색 전문가가 결제 시스템까지 최고 수준으로 알 필요는 없다.

백엔드 엔지니어가 머신러닝 모델 내부를 모두 이해할 필요도 없다.

플랫폼 조직의 강점은 모든 사람이 모든 것을 아는 것이 아니다.

서로 다른 전문성을 가진 사람들이 협업한다는 것이다.

그래서 좋은 플랫폼 개발자가 되려면 모든 분야를 공부하기보다

자신의 전문 영역은 깊게 이해하고,

다른 영역과 협업할 정도로 넓게 이해하는 것이 중요하다.

1.14 두 번째 단점: 입사 문턱이 높다#

테크 플랫폼 기업은 지원자가 많다.

회사 입장에서는 많은 지원자 가운데 실제 문제를 해결할 수 있는 개발자를 찾아야 한다.

그래서 채용 과정이 여러 단계로 구성되는 경우가 많다.

  • 서류
  • 코딩 테스트
  • 과제
  • 기술 면접
  • 시스템 설계
  • 협업 및 경험 인터뷰

회사와 직무, 경력 수준에 따라 방식은 크게 달라진다.

따라서

네카라쿠배에 가려면 알고리즘만 잘하면 된다.

라고 생각하는 것은 위험하다.

1.15 알고리즘보다 더 중요한 것은 문제 해결 과정이다#

코딩 테스트는 중요한 평가 수단이 될 수 있다.

하지만 경력이 쌓일수록 면접에서는 실제 경험에 대한 질문의 비중도 커진다.

가장 심각했던 장애는 무엇이었나요?

원인을 어떻게 찾았나요?

왜 그 데이터베이스를 선택했나요?

다시 설계한다면 무엇을 바꾸겠습니까?

트래픽이 10배 증가하면 어떻게 대응하겠습니까?

이런 질문에는 외워서 답하기 어렵다.

실제로 문제를 해결해본 경험이 필요하다.

따라서 플랫폼 기업을 준비한다면 알고리즘 공부만큼 다음 경험도 중요하다.

  • 실제 서비스 개발
  • 장애 분석
  • 성능 개선
  • 데이터베이스 설계
  • 네트워크 이해
  • 테스트
  • 배포
  • 시스템 설계

1.16 시스템 설계 능력이 중요한 이유#

사용자가 열 명인 서비스를 만드는 방법과 천만 명이 사용하는 서비스를 만드는 방법은 다르다.

예를 들어 질문이 나온다.

"대규모 알림 시스템을 설계해주세요."

단순히 API를 만들겠다고 답하는 것으로 끝나지 않는다.

어떤 질문부터 해야 할까?

사용자는 몇 명인가?

초당 몇 건을 발송하는가?

실시간이어야 하는가?

순서를 보장해야 하는가?

중복 발송은 허용되는가?

실패하면 재시도하는가?

데이터는 얼마나 보관하는가?

이 질문을 통해 문제의 조건을 정의하고 아키텍처를 만든다.

중요한 것은 하나의 정답을 맞히는 것이 아니다.

선택한 구조의 장점과 단점을 설명하는 능력이다.

1.17 세 번째 단점: 거대한 레거시는 어디에나 존재한다#

플랫폼 기업이라고 항상 새로운 코드만 작성하는 것은 아니다.

서비스가 오래될수록 코드도 오래된다.

한때 최고의 설계였던 코드가 현재는 레거시가 된다.

10년 동안 기능이 추가됐다.

수많은 개발자가 거쳐 갔다.

서비스와 서비스 사이의 의존성이 생겼다.

처음에는 간단했던 구조가 점점 복잡해진다.

그 결과 개발자는 새로운 기능보다 기존 코드를 이해하는 데 더 많은 시간을 사용할 수도 있다.

1.18 플랫폼 기업의 레거시는 왜 더 어려울 수 있는가#

스타트업의 레거시는 급하게 개발해서 복잡해진 경우가 많다.

대규모 플랫폼의 레거시는 다른 이유로 복잡해질 수 있다.

당시에는 합리적인 결정이었다.

그런데 서비스가 100배 성장했다.

회사 조직이 바뀌었다.

기술도 바뀌었다.

처음 설계한 사람이 퇴사했다.

새 시스템과 계속 연결됐다.

이런 역사가 수년간 겹친다.

그래서 코드 한 줄을 수정하기 전에 과거의 의사결정을 이해해야 할 때도 있다.

좋은 개발자는 레거시를 무조건 나쁜 코드라고 보지 않는다.

먼저 질문한다.

"왜 이렇게 만들어졌을까?"

1.19 네 번째 단점: 규모가 커지면 자신도 작은 부품이 될 수 있다#

서비스 전체 사용자는 수천만 명이다.

그런데 내가 담당하는 기능은 극히 작을 수도 있다.

예를 들어 검색 서비스를 담당하지만 실제 역할은

특정 검색 결과의 랭킹 품질을 개선하는 것이다.

결제 서비스를 담당하지만

특정 결제수단 하나만 담당할 수도 있다.

업무의 깊이는 매우 깊다.

하지만 전체 제품을 직접 움직이고 있다는 느낌은 약할 수 있다.

스타트업에서

"서비스 전체를 내가 만들었다."

라는 경험을 하던 개발자라면 플랫폼 조직에서 답답함을 느낄 수도 있다.

1.20 반대로 매우 깊은 전문가가 될 수 있다#

업무 범위가 좁다는 것은 반드시 단점이 아니다.

하나의 문제를 수년 동안 파고들 수 있기 때문이다.

예를 들어

  • 검색
  • 추천
  • 광고
  • 결제
  • 물류
  • 메시징
  • 데이터베이스
  • Kubernetes
  • 머신러닝 플랫폼
  • Observability

같은 분야를 깊게 다루다 보면 국내에서도 손꼽히는 전문가가 될 수 있다.

따라서 플랫폼 기업은 제너럴리스트보다는 깊은 스페셜리스트로 성장하기 좋은 환경이 될 수도 있다.

1.21 다섯 번째 단점: 성장 압박은 실제로 존재할 수 있다#

개발자의 성장이 빠른 조직에서는 역설적으로 멈춰 있는 것이 더 불안해질 수 있다.

동료가 새로운 기술을 발표한다.

다른 동료가 오픈소스 프로젝트를 만든다.

기술 블로그 글이 올라온다.

내가 모르는 기술이 계속 등장한다.

자극이 된다.

하지만 어느 순간 스트레스가 될 수도 있다.

"퇴근하고도 공부해야 하나?"

"나는 왜 저 사람만큼 못하지?"

"계속 이렇게 공부해야 개발자로 살아남을 수 있나?"

성장 문화는 사람에 따라 큰 동기부여가 될 수도 있고 피로가 될 수도 있다.

1.22 플랫폼 기업이라고 반드시 경쟁적인 것은 아니다#

모든 플랫폼 기업이 내부 경쟁이 극심하다고 일반화하기도 어렵다.

회사의 평가 제도도 다르고 팀 문화도 다르다.

성과를 개인 단위로 강하게 비교하는 조직도 있다.

팀 성과를 중요하게 보는 곳도 있다.

따라서

"테크 기업은 모두 서로 경쟁하면서 밤늦게까지 일한다."

라는 이미지는 현실을 지나치게 단순화한다.

중요한 것은 실제 조직의 평가 방식과 업무 문화다.

1.23 워라밸 역시 회사 이름으로 판단할 수 없다#

플랫폼 기업에서 일한다고 항상 야근하는 것은 아니다.

반대로 항상 자유로운 것도 아니다.

서비스 장애가 발생하면 밤에도 대응해야 하는 팀이 있다.

24시간 운영되는 서비스를 담당하면 온콜이 존재할 수도 있다.

서비스 출시 직전에는 업무량이 늘어날 수 있다.

반면 자동화가 잘 되어 있고 운영 프로세스가 안정적인 팀은 상당히 예측 가능한 업무 환경을 가질 수도 있다.

그래서 입사 전에는 다음을 확인하는 것이 좋다.

  • 온콜이 있는가
  • 장애 대응은 어떻게 하는가
  • 야간 배포가 있는가
  • 배포 자동화가 되어 있는가
  • 휴가 중 업무 연락이 있는가

이 질문이 회사 이름보다 실제 생활을 더 잘 보여준다.

1.24 2026년 플랫폼 개발자에게 가장 중요한 변화#

AI가 개발 과정에 깊이 들어오면서 단순히 코드를 빨리 작성하는 능력의 희소성은 낮아지고 있다.

대신 다음 능력의 가치가 커지고 있다.

  • 문제 정의
  • 아키텍처 판단
  • 데이터 이해
  • AI 결과 검증
  • 시스템 운영
  • 성능 최적화
  • 장애 대응
  • 제품 이해
  • 보안
  • 비용 최적화

우아한형제들의 최근 기술 사례에서도 AI에게 구현을 맡기더라도 전체 구조와 넓은 맥락은 결국 사람이 관리해야 한다는 경험이 공유되고 있다.

결국 AI 시대의 플랫폼 개발자는

코드를 많이 작성하는 개발자

보다

복잡한 시스템에서 올바른 결정을 내리는 엔지니어

에 가까워지고 있다.

1.25 어떤 사람에게 플랫폼 기업이 잘 맞을까#

플랫폼 기업이 모든 개발자의 최종 목적지는 아니다.

하지만 다음 성향의 개발자에게는 매우 좋은 환경이 될 수 있다.

1.25.1 기술의 깊이를 파는 것이 재미있는 사람#

단순히 프로그램이 작동하면 만족하는 것이 아니다.

왜 빠른지 궁금하다.

왜 느린지 궁금하다.

프레임워크 내부가 어떻게 동작하는지 궁금하다.

이런 개발자는 복잡한 플랫폼 환경에서 많은 것을 배울 수 있다.

1.25.2 어려운 문제를 좋아하는 사람#

사용자가 많아질수록 문제도 어려워진다.

동시성.

분산 시스템.

데이터 정합성.

성능.

장애.

완벽한 정답이 없는 문제들이 계속 등장한다.

이런 문제를 만났을 때 스트레스보다 호기심이 먼저 생기는 사람에게 잘 맞는다.

1.25.3 뛰어난 동료에게 자극받는 사람#

자기보다 잘하는 사람을 보면 기가 죽는 사람이 있다.

반대로 생각하는 사람도 있다.

"저 사람에게 배울 수 있으니 좋다."

후자의 성향이라면 뛰어난 개발자가 많은 환경이 매우 강력한 성장 촉진제가 된다.

1.25.4 실제 사용자가 있는 제품을 좋아하는 사람#

내가 만든 기능이 실제로 사용되는 것을 보고 싶다.

사용자 데이터를 확인하고 싶다.

사용자의 피드백을 기반으로 개선하고 싶다.

이런 개발자에게 플랫폼 기업은 매력적이다.

서비스가 이미 존재하기 때문에 자신의 변경이 실제 사용자에게 어떤 영향을 미치는지 관찰할 수 있다.

1.26 반대로 어떤 사람에게는 잘 맞지 않을까#

다음과 같은 개발자는 플랫폼 조직에서 스트레스를 받을 수 있다.

기술 공부 자체에 큰 관심이 없다.

복잡한 시스템보다 단순한 개발을 선호한다.

끊임없는 변화가 피곤하다.

다른 사람과 기술적으로 토론하는 것을 부담스러워한다.

업무와 기술 공부를 철저하게 분리하고 싶다.

제품의 일부가 아니라 전체를 직접 통제하고 싶다.

이 경우 회사의 명성만 보고 들어간다면 기대와 현실의 차이가 클 수 있다.

1.27 플랫폼 기업에 들어가기 위해 무엇을 준비해야 할까#

주니어라면 특정 프레임워크 하나를 완벽하게 외우는 것보다 기본기를 탄탄하게 만드는 것이 중요하다.

프로그래밍#

언어 자체를 제대로 이해한다.

자료구조와 알고리즘#

문제를 효율적으로 해결하는 방법을 익힌다.

운영체제#

프로세스와 스레드, 메모리의 기본을 이해한다.

네트워크#

HTTP와 TCP/IP의 기본 구조를 이해한다.

데이터베이스#

인덱스와 트랜잭션, 동시성을 이해한다.

개발 경험#

실제 서비스를 만들어보고 운영해본다.

경력 개발자라면 여기에 하나가 추가된다.

자신이 해결한 문제를 깊게 설명할 수 있어야 한다.

1.28 기술 이름보다 문제를 이야기할 수 있어야 한다#

이력서에 다음처럼 적는 것은 쉽다.

Kubernetes 사용

Kafka 사용

Redis 사용

하지만 면접에서는 질문이 이어진다.

왜 Kafka를 사용했나요?

RabbitMQ는 검토했나요?

Kafka 장애가 발생하면 어떻게 되나요?

메시지 중복을 어떻게 처리했나요?

트래픽은 얼마나 됐나요?

결국 중요한 것은 기술 이름이 아니다.

그 기술을 왜 선택했고 어떤 문제를 해결했는가다.

이것은 플랫폼 개발자 커리어 전체에서 중요한 기준이다.

1.29 플랫폼 기업에서도 물경력은 가능하다#

유명한 테크 기업에 입사한다고 자동으로 뛰어난 개발자가 되는 것은 아니다.

몇 년 동안 단순 운영 업무만 할 수도 있다.

특정 내부 도구만 사용해 외부 시장에서 활용하기 어려운 경험이 쌓일 수도 있다.

업무 자체를 외부 솔루션 업체가 하고 내부에서는 관리만 할 수도 있다.

그래서 회사 이름보다 중요한 질문이 있다.

나는 실제로 어떤 문제를 해결하고 있는가?

유명 기업의 로고보다 이 질문에 대한 답이 장기적인 경쟁력을 결정한다.

1.30 최고의 커리어는 최고의 회사 이름이 아니다#

SI에서는 다양한 프로젝트를 경험한다.

스타트업에서는 제품 전체와 사업을 경험한다.

대기업·금융권에서는 안정성과 거대한 시스템을 경험한다.

플랫폼 기업에서는 대규모 사용자와 깊은 기술 문제를 경험할 가능성이 높다.

각 환경에서 얻는 것이 다르다.

그래서 플랫폼 기업이 개발자 커리어의 최종 목적지라고 생각할 필요는 없다.

어떤 개발자는 플랫폼 기업에서 경험을 쌓고 창업한다.

어떤 개발자는 스타트업 CTO가 된다.

어떤 개발자는 자신의 전문 분야를 깊게 파고든다.

어떤 개발자는 더 안정적인 기업으로 이동한다.

중요한 것은 회사 이름이 아니라 그곳에서 무엇을 얻을 것인지 알고 들어가는 것이다.

1.31 거대한 플랫폼의 문을 두드리기 전에#

테크 플랫폼 기업은 매력적인 환경이다.

뛰어난 동료가 있다.

대규모 시스템이 있다.

실제 사용자가 있다.

깊은 기술적 문제가 있다.

좋은 보상을 받을 가능성도 있다.

하지만 대가도 존재한다.

기술적 난도가 높다.

배워야 할 것이 많다.

거대한 레거시를 만나기도 한다.

업무가 매우 전문화될 수 있다.

자신보다 뛰어난 사람들과 끊임없이 비교하게 될 수도 있다.

따라서 입사를 목표로 하기 전에 스스로에게 질문해볼 필요가 있다.

나는 개발 기술 자체를 깊게 파는 것을 좋아하는가?

어려운 문제를 만나면 피하고 싶은가, 해결하고 싶은가?

뛰어난 동료를 경쟁자로 보는가, 배울 수 있는 사람으로 보는가?

내가 만든 코드가 수백만 명에게 영향을 주는 책임을 감당할 수 있는가?

그리고 마지막 질문이 중요하다.

나는 유명한 회사에 들어가고 싶은 것인가, 어려운 문제를 해결하는 개발자가 되고 싶은 것인가?

두 목표가 같을 수도 있다.

하지만 반드시 같은 것은 아니다.

좋은 플랫폼 기업의 진짜 가치는 회사 로고가 아니다.

대규모 시스템과 뛰어난 동료 사이에서 수많은 어려운 문제를 만나고, 그것을 해결하면서 자신이 이전에는 다룰 수 없었던 수준의 문제를 다룰 수 있는 개발자로 성장하는 데 있다.

결국 이 거대한 플랫폼에서 가져가야 할 가장 큰 자산은 유명 회사의 경력 한 줄이 아니다.

더 큰 문제를 더 깊게 생각하고 해결할 수 있는 엔지니어링 능력이다.

#관련 참고 도서#

개발자라고 다 같은 개발자가 아니다#

SI, 스타트업, 대기업, 빅테크, 게임회사 등 개발자가 일하게 되는 다양한 환경의 차이와 커리어 선택 기준을 현실적으로 다루는 개발자 커리어 가이드입니다.

단순히 코딩 기술을 배우는 데서 그치지 않고, 어떤 회사와 조직에서 어떤 방식으로 성장해야 하는지, 좋은 개발 문화를 어떻게 구별하는지, '코더'가 아닌 '엔지니어'로 성장하려면 무엇이 필요한지를 살펴봅니다. 신입·주니어 개발자가 첫 직장을 선택하거나 이직 방향을 고민할 때 참고하기 좋은 내용으로 구성되어 있습니다.

교보문고에서 전자책 보기

이 페이지의 목차