주니어 개발자에게. "나는 백엔드니까 이것만", "나는 프론트니까 이것만" 하는 선 긋기가 가장 위험하다.
10여 년간 현업에서 일하고 창업까지 거치며 본, 주니어가 흔히 하는 실수와 미리 알면 좋은 것들을 정리한다.
들어가며
2012년부터 개발 일을 하면서, 그리고 시니어가 되어 여러 주니어와 일하면서 비슷한 패턴을 자주 봤다.
실력이 부족해서가 아니라, 시야를 좁게 잡아서 생기는 아쉬움들이다.
이 글은 "이렇게 하면 안 된다"는 잔소리가 아니다.
내가 주니어였을 때, 혹은 함께 일한 주니어들이 "이걸 좀 더 일찍 알았으면" 했던 것들을 모았다.
기술 실력은 시간이 쌓이면 따라온다.
정작 발목을 잡는 건 태도와 시야인 경우가 많다.
주니어 시절의 성장 속도를 결정하는 건 기술 그 자체보다, 자기 영역에 어떻게 선을 긋느냐다.
1. "나는 백엔드니까, 프론트니까" 라는 선 긋기
가장 흔하고, 가장 손해 보는 실수다.
"저는 백엔드라서 프론트는 잘 몰라요", "인프라는 데브옵스 담당이죠" 하고 스스로 벽을 친다.
물론 주력 분야는 있어야 한다. 깊이는 중요하다.
하지만 주력이 백엔드인 것과, 백엔드만 아는 것은 완전히 다른 얘기다.
실제로 일하다 보면 경계는 늘 흐릿하다.
- API 응답이 느리다는 제보 → 원인이 프론트의 불필요한 중복 호출인 경우
- 배포했더니 죽었다 → 코드가 아니라 컨테이너 메모리 설정 문제인 경우
- "왜 CORS 에러가 나죠?" → 백엔드 헤더 설정과 프론트 요청 방식을 둘 다 알아야 풀리는 문제
자기 영역에만 갇히면 이런 문제 앞에서 "제 담당 아닌데요"가 나온다.
반대로 옆 영역을 조금이라도 알면, 문제의 진짜 원인을 더 빨리 찾고 협업에서 신뢰를 얻는다.
깊게 파되, 옆을 볼 줄 아는 T자형 개발자가 되는 게 핵심이다.
백엔드가 주력이어도 프론트가 어떻게 동작하는지, 내 코드가 어떤 인프라 위에서 도는지, 데이터가 어떻게 흐르는지는 알아야 한다.
그게 결국 더 나은 백엔드 개발자를 만든다.
2. 동작하는 코드에서 멈추는 것
주니어 때는 "일단 돌아가면 됐다"는 안도감이 크다. 기능이 동작하면 거기서 끝낸다. 하지만 시니어는 거기서 한 발 더 간다.
- 이 코드는 데이터가 100배 늘어도 괜찮은가?
- 동시에 1000명이 호출하면?
- 이 부분이 실패하면 어떻게 되는가?
N+1 문제가 대표적이다. 개발 DB에선 멀쩡하다가 운영에서 터진다.
"돌아가는 코드"와 "운영에서 버티는 코드"는 다르다.
작성한 코드가 실제로 쿼리를 몇 번 날리는지, 어떤 상황에서 깨지는지 한 번씩 의심하는 습관이 주니어와 시니어를 가른다.
완벽하게 짜라는 게 아니다.
"이게 언제 문제가 될까?"를 한 번 떠올려보는 것만으로도 충분히 다르다.
3. 질문을 두려워하는 것
"이런 걸 물어보면 무시당하지 않을까" 하는 두려움. 주니어가 가장 많이 하는, 그리고 가장 비싼 실수다.
혼자 3시간 헤맬 일을, 적절한 질문 하나로 10분에 끝낼 수 있다.
막힌 채로 시간을 태우는 것이 팀에는 더 큰 손해다.
다만 질문에도 방법이 있다.
- 나쁜 질문: "이거 안 되는데요?"
- 좋은 질문: "A를 하려고 B 방법을 시도했는데 C 에러가 납니다. D까지 확인해봤는데 막혔어요."
무엇을 시도했고 어디서 막혔는지를 정리해서 묻는 것.
이건 상대의 시간을 아끼는 배려이자, 사실 질문을 정리하는 과정에서 스스로 답을 찾기도 한다.
질문을 잘하는 능력은 그 자체로 실력이다.
4. 코드는 짜는 것보다 읽는 시간이 길다
학습할 땐 코드를 '쓰는' 연습만 한다.
그래서 깨끗한 새 코드를 짜는 데만 익숙하다.
하지만 실무의 대부분은 남이 짜놓은 코드, 과거의 내가 짜놓은 코드를 읽고 고치는 일이다.
그래서 두 가지가 중요해진다.
하나는 남의 코드를 잘 읽는 능력. 오픈소스나 회사 레거시를 읽으며 "왜 이렇게 짰을까"를 이해하는 연습이 실력을 크게 키운다.
디자인 패턴을 알면 남의 코드가 더 잘 읽히는 것도 이런 이유다.
다른 하나는 6개월 뒤의 내가 읽을 수 있게 짜는 것.
지금의 나만 아는 영리한 코드보다, 누가 봐도 이해되는 단순한 코드가 좋은 코드다.
변수 이름 하나, 주석 한 줄이 미래의 누군가(주로 나)를 구한다.
5. 기술에만 매몰되는 것
주니어 때는 "어떤 기술을 쓰느냐"에 집착하기 쉽다.
최신 프레임워크, 멋진 아키텍처. 물론 중요하다.
하지만 시간이 지나며 깨닫는 건, 기술은 문제를 푸는 수단이지 목적이 아니라는 것이다.
창업을 해보며 가장 크게 배운 게 이거였다.
아무리 잘 만든 기술도, 사용자가 원하지 않는 문제를 풀고 있으면 의미가 없었다.
"이걸 왜 만드는가", "누구의 어떤 문제를 푸는가"를 묻지 않고 기술만 보면, 열심히 만들고도 쓸모없는 걸 만들게 된다.
좋은 개발자는 "어떻게 만들까"만큼 "이게 정말 필요한가" 를 묻는다.
비즈니스와 사용자를 이해하는 개발자가 결국 더 멀리 간다.
6. 다음 스텝에 한계를 두지 마라
마지막이자 이 글에서 가장 하고 싶은 말이다.
주니어 때 정한 정체성에 스스로를 가두지 마라.
"나는 백엔드 개발자"라는 정의는 지금의 역할일 뿐, 미래의 한계가 아니다.
백엔드로 시작해 데이터로, AI로, 아키텍트로, 혹은 창업으로 갈 수도 있다.
나 역시 백엔드로 시작했지만 프론트, 데브옵스를 거쳐 지금은 데이터·AI를 다루고 있다.
그때마다 "이건 내 영역이 아닌데"라는 생각을 버린 게 다음 문을 열었다.
커리어는 사다리가 아니라 격자(lattice)에 가깝다.
위로만 올라가는 게 아니라, 옆으로도 움직이며 면적을 넓힐 수 있다.
지금 배우는 게 당장 쓸모없어 보여도, 언젠가 예상 못 한 곳에서 연결된다.
스스로에게 "나는 여기까지"라고 선을 긋는 순간, 딱 거기까지만 성장한다.
마치며
정리하면 이렇다.
- 주력은 깊게, 하지만 옆 영역도 볼 줄 아는 T자형으로
- "돌아가는 코드"가 아니라 "운영에서 버티는 코드" 를 고민하기
- 질문을 두려워하지 말고, 대신 잘 질문하기
- 코드는 쓰는 것보다 읽는 시간이 길다는 걸 기억하기
- 기술이 아니라 문제와 사용자 를 먼저 보기
- 그리고 스스로의 다음 스텝에 한계를 긋지 말기
기술은 시간이 쌓이면 따라온다.
정작 성장 속도를 가르는 건 시야와 태도다.
지금 주니어라면, 실력이 부족한 걸 걱정하기보다 시야를 좁게 잡고 있지는 않은지 한 번 돌아보면 좋겠다.
그리고 이건 주니어에게 하는 말이자, 시니어인 나 자신에게도 계속 하는 말이기도 하다.
우리는 모두 어느 영역에서는 여전히 주니어니까.