스타트업 출신 개발자로 네임드 기업에서 AI와 살아남기

2025년을 돌아보면, 그냥 ‘바빴다’는 말로는 도저히 설명할 수 없습니다.

올해 저는 어느덧 8년 차 개발자가 되었고, 작은 스타트업을 떠나 개발자 동료가 정말 많은 네임드 기업에서 새로운 도전을 시작했습니다.

솔직히 말해, 이 환경 자체가 저에게는 완전히 새로운 세계였어요. 7년 동안은 소규모 스타트업에서 ‘내가 모든 걸 직접 해내야 하는’ 구조 속에 있었습니다. 하지만 올해는 수십 명의 개발자가 함께 일하는, 체계적인 팀과 정교한 프로세스 한가운데에 섰죠.

그 순간부터 저는 자연스럽게 이런 생각을 하기 시작했습니다.

“여기서도 내가 살아남을 수 있을까?”

그런 관점에서 돌이켜보면, 올해 제가 했던 건 단순 ‘버티기’가 아니었습니다. 살아남기 위해 정말 필사적으로 발버둥 쳤던 한 해였어요.

개발 실력만으로는 밀어붙일 수 없다는 사실을 인정해야 했고,

새로운 조직문화와 커뮤니케이션 방식, 더 높은 기준,

그리고 무엇보다 ‘AI라는 거센 폭풍’을 온몸으로 맞아야 했습니다.

그래서 이번 글에서는 저처럼 변화 속에서 허덕였던 분들이 조금이라도 공감할 수 있도록, 그리고 앞으로의 시대에서도 잘 살아남을 수 있도록, 제가 몸으로 부딪치며 배운 노력과 작은 깨달음들을 솔직하게 나눠보려 합니다.

혹시 지금 여러분도 불안한 마음으로 막연히 “앞으로 괜찮을까?”라는 생각을 하고 있다면, 오늘 이 글이 아주 작은 힌트라도 되었으면 좋겠습니다.

PART 1. 스타트업 개발자가 네임드 기업에서 살아남는 방법

커뮤니케이션 능력이 더없이 중요하다

이번 이직 전까지 저는 매우 작은 스타트업에서 일을 해왔습니다. 같이 일하는 개발자가 많아봤자 6~7명 남짓이었고, 대부분 초기 서비스를 만들어가는 과정이었습니다. 자연스럽게 기획부터 참여했고, DB 설계, 인프라 구성, API 설계와 개발, 관리자 페이지 제작, 운영·유지보수까지 서비스 개발 전반을 거의 혼자 커버할 수 있는 환경이었습니다.

그러다 보니 제 역량도 넓고 얕지만 전체를 아우르는 형태로 확장되었고, 타 직군과의 커뮤니케이션에서도 큰 문제를 겪은 적이 없었습니다. 오히려 저는 소통이 나의 강점이라고 착각하고 있었습니다.

하지만 이미 오랜 서비스가 운영되고 있는 네임드 기업에 들어와 보니, 제가 커뮤니케이션에서 얼마나 약점이 많은지 뼈저리게 알게 되었습니다. 백엔드 파트 내 수많은 동료의 PR 리뷰 코멘트, 설계 과정에서의 깊은 토론, 기획과 정책에 대한 의견 조율 등 모든 과정이 이전과는 완전히 다른 깊이와 복잡도를 가지고 있었습니다. 어떻게 말해야 하는지, 어떤 방식으로 설득해야 하는지 감을 잡지 못했고, 그 상태로 3개월이 순식간에 지나갔습니다.

수습 기간은 무사히 넘겼지만, 그 이후 결제 관련 중요한 태스크를 맡았다가 정책을 잘못 이해해 큰 손실이 날 뻔한 적까지 있었습니다. 일정조차 지키지 못했고, 회사 입장에서는 시간과 인력 리소스를 낭비한 셈이 되어 버렸습니다. 그 시기에는 제 커리어 전체에 의문이 생길 정도로 큰 충격을 받았습니다.

그렇게 깨달았습니다. 큰 조직은 일하는 방식 자체가 완전히 다르다는 것을. 이곳은 혼자 다 이해했다고 생각하고 개발해서는 절대 안 되는 환경이었습니다. 모르는 것은 적극적으로 묻고, 완전히 이해될 때까지 확인하고, 관련자 모두에게 더블체크 받고, 작은 변경이라도 여러 직군과 함께 조율해야, 제 일을 제대로 한 것입니다.

처음에는 회사가 나와 맞지 않는다고 생각했습니다. 하지만 서비스 규모가 크고 레거시가 깊은 조직에서는 이런 방식이 필연적으로 발생할 수밖에 없다는 사실을 점차 받아들이게 되었습니다. 개발, 코드 수정, 배포 어느 하나 마음대로 하기보다, 전체 팀 관점에서 순서는 맞는지, 놓친 리스크는 없는지 먼저 판단해야 했습니다. 넓은 관점에서 보면 이것도 결국 커뮤니케이션 능력이라는 생각이 들었고요.

지금은 제 역할에서 최선을 다하며, 제가 맡은 일이 동료들의 작업 흐름에 방해되지 않도록, 그리고 어떤 문제도 생기지 않도록 꾸준히 노력하고 있습니다.

단순 개발 역량보다 눈치, 센스, 배려가 훨씬 중요하다

큰 조직에 들어와서 정말 크게 느낀 점이 하나 더 있습니다. 생각보다 개발 실력 자체보다 소프트 스킬이 훨씬 더 중요하다는 사실이었습니다. 왜냐하면 같은 개발팀 안에서만 협업하는 게 아니라, 사업실이나 QA팀, 운영팀 등 정말 많은 이해관계자와 함께 일하게 되거든요. 팀마다 일하는 방식도 다르고, 업무 우선순위를 바라보는 관점도 다르다 보니, 어떤 식으로 요청해야 하고 어떤 타이밍에 이야기해야 일이 매끄럽게 풀리는지, 모든 것을 몸으로 배우게 됐습니다.

한번은 이런 일이 있었어요. 배포 후 모니터링을 하면서 운영팀의 지원이 꼭 필요한 태스크가 있었는데, 제가 개발과 배포 준비에만 매몰돼서 운영팀 리소스를 미리 요청하는 걸 완전히 잊어버린 겁니다. 사실은 배포 일정을 잡을 때부터 운영팀과 먼저 커뮤니케이션하고, 어떤 시간대에 누가 지원할 수 있는지 확인해야 했는데, 그 과정을 통째로 스킵해버린 거죠.

결국 배포 직전에 운영팀에 급하게 사정을 전했는데요. 다행히 도움받아 큰 문제 없이 마치기는 했습니다. 하지만 이때 진짜 크게 배웠습니다. ‘내 파트만 보고 일을 처리하면 절대 안 되는구나’, ‘전체 관점에서 보고 필요한 건 미리미리 준비해 두는 게 얼마나 중요한가’를 뼈에 새겼죠.

그 이후로는 제가 원래 그런 일을 좋아하는 타입은 아니지만, 타팀 분들과의 관계를 조금씩 더 다져가려고 노력하고 있습니다. 가벼운 커피챗이라도 해보고, 평소 어떤 부분을 어려워하는지 듣기도 하고, 제 일정을 잡을 때는 어떤 팀의 리소스가 필요한지 먼저 리스트업해둡니다. 그리고 꼭 미리 연락을 드려요. 이 과정 자체가 제가 하는 일을 훨씬 수월하게 만들어주더라고요. 무엇보다 서로 신뢰가 쌓이니까, 작은 요청 하나도 더 자연스럽게 주고받을 수 있게 됐습니다.

‘시스템’과 ‘프로세스’라는 옷 입기

이전에는 주로 초기 팀에서 일을 해왔기 때문에, 사실 전체 시스템이 제대로 갖춰지지 않은 상태에서 시작하는 경우가 대부분이었습니다. 협업 문화라는 것도 처음부터 만들어진 것이 아니라, 일하면서 하나씩 직접 쌓고 정착시키는 과정이 오히려 자연스러웠어요. 특히 백엔드 중심으로 일하다 보니, 코드 리뷰나 코드 컨벤션처럼 여러 명이 함께 일할 때 필요한 룰들이 느슨했던 것도 사실입니다. 당장 서비스가 돌아가는 게 더 급했으니까요.

그런데 이번에 규모가 큰 회사에 오고는 완전히 다른 세계를 경험했습니다. 타 팀에 업무를 요청할 때도 일정한 약속, 즉 프로토콜이 있습니다. 어떤 양식으로 요청해야 하는지, 어느 단계에서 누구에게 먼저 공유해야 하는지, 언제까지 무엇을 준비해야 하는지가 다 정해져 있었죠. 그 흐름을 정확히 따라야만 일들이 자연스럽게 움직입니다.

새로운 프로그램을 사용하고 싶어도 바로 쓸 수 있는 게 아니라, 결제 문서를 올리고 승인을 받아야 합니다. 처음에는 이런 시스템과 프로세스가 정말 갑갑하게 느껴졌습니다. “이걸 굳이 문서로 또 올려야 하나?”, “이 절차만 없으면 바로 일할 수 있을 텐데…” 하는 생각을 수도 없이 했어요. 솔직히 시간 낭비라고 느낀 적도 많았습니다.

하지만 결국 받아들였습니다. 회사 규모가 커질수록 누가 어떤 권한을 갖고 무엇을 사용할 수 있는지가 명확하게 정리되어 있어야 합니다. 그게 팀을 보호하는 장치이기도 하더라고요. 모두가 각자 방식으로 일하기 시작하면 오히려 더 큰 혼란이 생기는 구조라는 걸 점점 이해하게 됐습니다.

그래서 요즘은 조금 더 센스를 발휘하려고 합니다. 필요한 프로그램은 미리미리 결제를 올려두고, 승인까지 걸리는 시간을 감안해 일정도 여유 있게 잡습니다. 꼭 결제가 필요하지 않을 것 같은 경우에는 미리 담당자에게 확답을 받아두고, 불필요하게 대기하는 시간을 만들지 않으려 해요. 결국 중요한 건 시스템과 프로세스를 거스르지 않으면서, 그 안에서 최대한 효율적인 흐름을 만드는 것이더라고요.

이제는 그 방식이 꽤 잘 맞는 편입니다. 오히려 한 번 세팅해 두면 예측 가능한 흐름 속에서 안정적으로 일할 수 있다는 점이 장점이라는 것도 깨달았고요.

대규모 트래픽에 대한 경험

스타트업에서 일하면서 개인적으로 가장 아쉬웠던 부분이 하나 있었습니다. 바로 대규모 트래픽을 직접 다뤄본 경험이 거의 없었다는 점이었어요. 이건 “하고 싶다”고 해서 할 수 있는 경험이 아니고, 회사가 가진 트래픽 규모에 따라 자연스럽게 정해지는 부분이니까요.

그래서 이번에 DAU 30만이 넘는 서비스를 다룬 건 저에게 정말 큰 도전이었습니다. 이 정도 규모에서는 아주 작은 기능 하나 추가하는 것도 조심스럽습니다. 사소한 부분만 놓쳐도 예기치 않은 장애로 이어질 수 있기 때문에, 더더욱 디테일하게 체크하고 설계해야 했습니다.

또 서비스가 MSA 형태의 여러 도메인으로 나뉘어져 있다 보니, 각각 서비스가 어떤 역할을 하는지 익히는 것부터 만만치 않았습니다. 처음에는 진짜 정신이 하나도 없었어요. 어떤 도메인에서 어떤 이벤트가 발생하고, 그게 어디로 전파되고, 어느 팀이 어떤 부분을 담당하는지 하나하나 이해하는 데 많은 시간이 필요했습니다.

CS 대응을 할 때는 더 복잡했습니다. 특정 문제가 발생하면 정책을 먼저 확인하고, 그 정책이 서비스 여러 개와 어떻게 연결돼 있는지 파악해야 하고, 복잡한 DB 구조와 의존관계까지 모두 살펴봐야 했습니다. 알아야 할 게 너무 많아서 처음엔 진짜 막막하다는 생각이 들 정도였어요.

하지만 그만큼 얻은 것도 컸습니다. 유지보수성을 고려한 디자인 패턴 적용부터 CPU 사용량을 생각한 코드 작성, 쿼리 성능을 높이기 위한 튜닝까지…. 지금 돌이켜보면 백엔드 엔지니어로서 이보다 더 좋은 학습 환경이 없었다는 생각이 듭니다. 이런 경험은 단기간에 얻을 수 있는 게 아니라, 트래픽 규모가 큰 서비스에서 직접 부딪혀야만 배울 수 있는 것들이거든요.

그래서 저는 이런 경험들을 그냥 흘려보내지 않으려고 합니다. 실수했던 부분, 배웠던 패턴, 개선했던 과정들을 모두 꾸준히 기록해 두고 있어요. 시간이 지나면 이 모든 것이 제 커리어에서 정말 큰 자산이 될 것 같다는 확신이 있습니다.

PART 2. AI 시대에 살아남는 방법

AI Tool이라는 신세계를 마주하다

솔직히 얘기하면, AI 도구가 이렇게 급속도로 퍼질 줄은 정말 상상도 못 했습니다. 처음엔 그저 하나의 유행처럼 스쳐 지나갈 줄 알았어요. 제가 AI를 처음 접한 것은 아마 Copilot이었던 것 같습니다. 그때만 해도 성능이 지금과는 비교도 되지 않을 정도로 제한적이어서 그저 간단한 예시 코드만 참고하는 수준이었습니다. 그 때문에 크게 관심을 가지지 않고, “아직은 멀었구나”라는 생각이 더 컸습니다.

그러나 GPT와 클로드 같은 모델들이 점점 발전하기 시작하면서 상황이 조금씩 달라지기 시작했습니다. 처음에는 저도 AI를 아주 부분적으로만 사용했습니다. 기술 검토를 해보거나, 설계 아이디어가 막힐 때 가볍게 물어보는 정도였죠. 제가 놓친 관점이 있는지 확인하고, 문서를 더 이해하기 쉽게 정리해달라는 정도로만 활용했습니다.

그런데 모델들이 업그레이드될수록 상황이 확확 바뀌기 시작했습니다. 어느 순간부터는 “이거 꽤 쓸 만한데?”라는 생각이 들 정도로 업무에 실질적인 도움을 주더라고요. 특히 코드 구현을 설계할 때, 좋은 패턴을 참고해야 할 때, 새로운 기술을 적용할 때, 이 모두를 충분히 검토하도록 지원해 주는 역할을 하기 시작했습니다. 마치 사수와 동료 사이 어딘가 보조 엔지니어가 하나 생긴 느낌이랄까요.

이 과정에서 작업 생산성도 자연스럽게 올라갔습니다. 반복 작업이나 문서 작성, 리뷰 포인트 정리 같은 부분은 AI에게 맡기다 보니, 저는 더 중요한 문제 해결에 집중할 수 있었거든요. “AI를 잘 쓰면 정말 좋은 보조 도구가 될 수 있겠구나”라는 생각이 들었고, 그 이후부터는 제 업무 흐름 안에 AI가 자연스럽게 녹아들기 시작했습니다.

물론 그때도 몰랐습니다. 이것이 단순한 도입 테스트 정도가 아니라, 제가 일하는 방식 전체를 바꿔버리는 시작점이 될 줄은 정말 상상도 못 했으니까요.

AI 도구로 생산성을 높이다

AI 도구 중에서 제 업무와 사고방식에 가장 큰 충격을 준 건 단연 Cursor였습니다. 아쉽게도 회사 보안 정책 때문에 실제 업무에는 적용하지 못했지만, 개인적으로 간단한 사이드 프로젝트를 만들면서 처음 Cursor를 제대로 사용해봤을 때의 경험은 지금도 잊기 어려워요.

정말로 코드를 일일이 짤 필요가 없었습니다. 그냥 자연어로 설명만 해줬는데, 마치 옆에 앉은 누군가 뚝딱뚝딱 코드를 만들어주는 느낌이 들더라고요. 당연하지만, 오류도 있었고, 제 지시 사항을 제대로 이해하지 못하는 경우도 여러 차례 있었습니다. 하지만 그럴 때마다 “이 부분은 이런 의도다”라고 다시 설명해 주고 apply 버튼만 누르면, 그 방향으로 코드를 고치고 프로젝트를 계속 완성해 가는 모습을 보였습니다.

그러자 갑자기, 서늘한 두려움이 느껴졌습니다. “아, 이거 진짜 곧 일이 크게 바뀌겠구나.” 그런 직감이 강하게 들었습니다.

Cursor가 불러온 화제가 끝나기도 전에, Claude Code라는 CLI 기반 도구가 등장하면서 이 흐름은 거의 전 세계적인 붐으로 번졌습니다. 개발자 커뮤니티 전체가 크게 출렁였고, 저 역시 이 흐름을 거스를 수 없겠다는 감각이 들었습니다. 그래서 회사 업무에서도 어떻게든 LLM 기반 도구를 적용하려고 정말 부지런히 애를 썼습니다.

물론 개인정보나 보안 이슈 때문에 사용할 수 없는 도구들도 많았습니다. 하지만 사용할 수 있다고 판단되는 건 전부 시도해 봤습니다. Claude, Gemini CLI, JetBrains IDE에서 지원하는 AI Assistant, Junie 등 가능한 건 다 직접 테스트하고, 일에 적용할 수 있는 부분을 계속 찾아 나갔습니다.

어느 순간부터는 단순히 AI 도구 하나를 쓰는 수준이 아니라, LLM을 활용한 개발 방법론 자체가 발전한다는 걸 느꼈습니다. “이걸 어떻게 써야 가장 효율적일까?”, “LLM에게 어떤 식으로 설명해야 원하는 설계를 얻을까?” 같은 고민을 하면서 제 개발 방식도 자연스럽게 달라지기 시작했어요.

솔직히 말하면, 회사 분위기는 그저 핫한 도구를 한 번 써보는 정도에 머무르는 느낌이 강했습니다. “편하면 쓰고 아니면 말고” 같은 기조라고 해야 할까요. 하지만 저는 포기하지 않았습니다. 어떻게든 업무에 AI를 적용해 생산성을 높이고, 반복 작업을 줄이고, 더 중요한 문제에 집중할 시간을 확보하려고 했습니다. 이런 변화는 앞으로 선택이 아니라 필수가 될 것이라는 직감이 있었기 때문에, 더 적극적으로 움직일 수밖에 없었습니다.

AI를 동료로 받아들이다

예전처럼 LLM에 단순히 질문을 던지고, 답변받고, 이를 업무에 적용하는 방식은 거의 사용하지 않습니다. 그 방식은 너무 느리고, 매번 주도적으로 모든 단계를 챙겨야 하기에 효율이 떨어졌습니다. 이제 저는 본격적으로 에이전트를 사용하며, 제가 하는 업무 프로세스 하나하나에 에이전트가 자연스럽게 들어오도록 꾸준히 시도하고 있습니다.

가장 먼저 자동화를 시도한 건 테스트 코드였습니다. 제가 직접 테스트 코드를 작성하는 대신 스펙을 정리해 에이전트에게 설명하고 맡겨봤습니다. 어떤 의도인지, 어떤 상황을 검증해야 하는지, 어떤 조건을 만족해야 하는지 하나씩 설명해 줬더니, 마치 제가 짰을 법한 테스트 코드를 거의 완성된 형태로 만들어주더라고요. 이 경험 이후로 생산성은 최소 30% 이상은 올라간 것 같습니다.

이제는 처음처럼 질문하고 답을 받는 방식이 아니라, 전체 맥락과 작업 목적을 설명한 뒤 “이 테스트 코드를 작성해라”라고 위임해 두고, 저는 더 중요한 작업을 먼저 처리합니다. 작업이 다 끝나면 에이전트가 알람을 보내주기 때문에, 그때 가서 검수만 하는 식으로 업무 방식 자체가 완전히 달라졌습니다.

이런 경험이 쌓이다 보니, 지금은 AI를 하나의 ‘도구’가 아니라 진짜 동료처럼 받아들이는 마인드셋이 생겼습니다. 그래서 동료에게 하듯 더 잘 이해시키고 더 잘 협업하고 싶어 여러 방법론을 직접 적용해 보고 있습니다. BMAD나 SDD 같은 새로운 개발 방식을 실제 업무 프로젝트에 적용해 보면서, 개발의 패러다임 자체가 바뀌고 있다는 사실을 강하게 체감하고 있습니다.

특히 역할을 나눈 여러 에이전트를 활용하는 BMAD 방법론이 제게 정말 잘 맞습니다. 최근에는 Gemini CLI에 BMAD 개발 환경을 구성해서 사용하고 있고요.

이제 저는 프로젝트 전체 구조나 변경 사항이 있을 때 ‘Architect 에이전트’와 논의합니다. ‘Fullstack Developer 에이전트’에는 실제 구현을 맡겨두고, 중간중간 의견을 주거나 설계 방향을 얘기하며 작업을 이어갑니다. 마치 진짜 팀원들과 일하는 것처럼 대화를 주고받으며 프로젝트를 완성해 가는 방식입니다.

그래서 전체 스펙을 잡는 게 제 업무의 70%를 차지하고, 나머지 구현은 에이전트가 계획한 대로 코드를 만들어줍니다. 저는 검수와 수정, 품질 관리에 집중하며 프로젝트의 큰 방향을 책임지는 역할을 합니다. 개발이라는 업무에서 “내가 손으로 직접 짠 코드의 양”보다 “내가 스펙을 얼마나 정확히 정의했는가”가 훨씬 중요한 시대로 넘어가고 있다는 생각이 듭니다.

마치며

돌이켜보면 2025년은 제게 그 어떤 때보다 변화가 극심했던 한 해였습니다. 완전히 다른 규모의 조직에서 새로운 협업 환경을 익히고, AI라는 거대한 파도 안에서 살아남기 위해 발버둥 치다 보니 어느 순간 시간이 훅 지나 있더라고요. 그런데 이렇게 회고를 해보니, 그 과정들이 결국 저를 더 단단하게 성장시켜 주었다는 생각이 듭니다.

2026년의 방향도 결국 AI일 것입니다. “AI를 동료로 받아들인다”는 건 말은 쉬운데, 실제로는 생각보다 훨씬 큰 마인드셋 전환이 필요하거든요. AI도 실수합니다. 제 말을 잘못 이해할 때도 많고, 엉뚱한 방향으로 답을 줄 때도 있습니다. 그래서 더더욱 함께 일을 잘할 방법을 고민해야 하고, 어떤 설명이 AI에게 가장 자연스럽게 이해되는지 실험해 보려 합니다.

이제는 모두 거부할 수 없는 흐름 위에 올라탔다고 생각합니다. 앞으로는 코드를 짜는 능력 그 자체의 의미는 점점 줄어들 가능성이 높습니다. 오히려 기본 지식에 충실한 상태로, 직접 경험한 문제 해결 과정과 배운 것을 얼마나 잘 정리하고 활용하는지가 훨씬 중요한 역량이 될 것 같습니다.

그렇게 2026년에는 이 흐름 속에서 더 단단해지고, 더 똑똑하게 일할 수 있는 개발자가 되고 싶습니다.

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.