경력은 쌓는 게 아니라, 맥락을 비우지 않는 기술이다

May 30, 2026

5 min read

2 views

86%

능력이 있는데도 막히는 이유

왜 어떤 사람은 이미 웹 백엔드, 클라우드, 스타트업 실무, 중상급 영어까지 갖췄는데도 다음 단계로 넘어가는 데 어려움을 겪을까? 그리고 왜 어떤 시스템은 분명 기본 동작이 정해져 있는데, 아주 작은 입력 하나, 예를 들면 undefined 같은 값 하나 때문에 그 기본 동작이 통째로 사라질까?

이 둘은 전혀 다른 이야기처럼 보인다. 하나는 사람의 경력 문제이고, 다른 하나는 UI 컴포넌트의 동작 문제다. 그런데 둘은 같은 질문을 건드린다. 기본값은 언제 작동하고, 언제 사라지는가?

경력 개발도, 소프트웨어 설계도, 결국은 기본값 위에 특수한 예외를 얹는 일이다. 문제는 예외를 다루는 방식이 잘못되면, 기본값이 조용히 지워진다는 점이다. 경력에서 이 기본값은 성장의 여지, 신뢰, 이식 가능한 역량이고, 코드에서는 자동 생성된 속성, 일관된 동작, 예측 가능한 UX다.

진짜 어려운 것은 더 많은 것을 하는 일이 아니라, 기본 동작이 살아 있는 상태로 예외를 설계하는 일이다.

경력의 함정: 일이 많아질수록 성장도 자동으로 늘어날 것이라는 착각

스타트업에서 주니어인데도 경력에 비해 더 많은 업무를 맡는 사람은 흔하다. 백엔드도 하고, 클라우드도 보고, 배포도 만지고, 때로는 고객 대응이나 장애 대응까지 떠안는다. 겉으로 보면 굉장히 강한 사람처럼 보인다. 실제로도 상당히 강하다. 하지만 여기에는 은근한 함정이 있다. 업무량의 증가가 곧 경력의 선형적 상승을 보장하지는 않는다는 점이다.

왜냐하면 경력은 단순히 일을 많이 했다는 사실로 축적되지 않기 때문이다. 경력은 사실상 세 가지 층위로 쌓인다. 첫째는 작업량, 둘째는 패턴 인식, 셋째는 전이 가능한 판단력이다. 스타트업에서 많은 일을 하다 보면 첫째는 빠르게 늘어난다. 하지만 둘째와 셋째는 자동으로 따라오지 않는다. 오히려 맥락이 너무 자주 바뀌면 패턴이 흩어진다.

예를 들어, 오늘은 배포 실패를 잡고 내일은 IAM 권한 문제를 해결하고 모레는 API 병목을 최적화한다고 하자. 각각은 훌륭한 경험이다. 그런데 이 경험들이 “문제 해결의 원리”로 묶이지 않으면, 머릿속에는 사건만 남고 구조는 남지 않는다. 그 결과 이력서에는 많은 단어가 쌓이지만, 면접에서 설명할 수 있는 판단의 축은 얇아진다.

이것은 개발 실력의 부족이 아니라, 맥락 압축의 실패다. 같은 일을 많이 했다는 사실보다, 그 일을 통해 어떤 원리로 문제를 분해했고, 어떤 우선순위로 판단했고, 어떤 기준으로 트레이드오프를 선택했는지가 중요하다. 경력은 일이 아니라 설명 가능한 선택의 축적이기 때문이다.

기본 동작이 지워질 때, 시스템은 조용히 망가진다

UI 컴포넌트의 예는 놀라울 만큼 이 문제를 선명하게 보여준다. 기본적으로는 라벨이 적절한 for 속성을 자동으로 갖고 있어야 한다. 그런데 htmlFor={undefined}를 넣는 순간, 단순히 “값이 없는 상태”가 아니라 자동으로 생성되던 기본 동작 자체가 제거된다. 즉, 명시하지 않은 것과 명시적으로 비워 둔 것이 같지 않다.

이 차이는 생각보다 크다. 개발자는 종종 undefined를 “그냥 기본값 쓰세요” 정도로 받아들인다. 하지만 시스템은 그렇게 친절하지 않다. 어떤 곳에서는 undefined가 기본값을 보존하지만, 어떤 곳에서는 그 값 자체가 하나의 강한 신호가 되어, 자동 계산을 끊어 버린다. 즉, 빈 값은 중립이 아니라 명령이 될 수 있다.

이건 코드만의 문제가 아니다. 팀에서도 마찬가지다. “그건 알아서 해”라고 말하는 것과 “아직 결정하지 않았으니 기존 방식을 유지해”라고 말하는 것은 완전히 다르다. 전자는 기본 동작을 남겨 두는 말처럼 들리지만, 실제로는 책임을 지우는 무책임한 예외가 될 수 있다. 후자는 기본값을 존중하면서 의사결정의 여지를 남긴다.

여기서 중요한 통찰은 이것이다. 예외를 표현하는 방식이 기본값을 살릴 수도, 죽일 수도 있다. 잘 설계된 시스템은 특수한 상황을 허용하면서도 보편적 흐름을 유지한다. 반대로 잘못 설계된 시스템은 작은 오버라이드 하나로 전체의 지능을 없앤다. 경력도 같은 방식으로 무너진다. 너무 많은 예외 업무가 쌓이면, 원래의 성장 경로가 작동하지 않는다.

경력 개발의 진짜 문제는 부족함이 아니라 오버라이드다

많은 사람은 자신이 부족해서 다음 단계로 못 간다고 생각한다. 영어가 부족한가, 포트폴리오가 약한가, 알고리즘이 약한가, 대기업 경험이 없어서 그런가 하고 스스로를 의심한다. 하지만 실제로는 정반대인 경우가 많다. 문제는 역량 자체보다, 지금의 삶과 업무가 너무 많은 부분을 임시 처리 상태로 바꾸고 있다는 것이다.

스타트업에서 주니어가 여러 역할을 맡으면, 당장은 생존력이 올라간다. 문제는 이 생존력이 지나치게 유용해서, 본인의 학습 구조를 잠식한다는 데 있다. 매번 급한 일을 처리하는 사람이 결국 가장 필요한 것은 더 많은 급한 일 처리 능력이 아니라, 기본값을 회복하는 능력이다.

이걸 제품 비유로 보면 쉽다. 어떤 앱이 사용자에게 너무 많은 옵션을 주면 사용자는 자유를 얻는 대신 혼란을 겪는다. 반대로 좋은 앱은 기본 설정이 대부분의 상황에서 충분히 훌륭하고, 예외는 명시적으로 선택할 수 있게 한다. 경력도 마찬가지다. 당신의 현재 업무가 모든 것을 커버하는 만능 모드처럼 보일수록, 장기적으로는 자신의 정체성과 학습 경로가 희미해질 위험이 있다.

그래서 중요한 질문은 “나는 더 많은 일을 할 수 있는가”가 아니라, “나는 기본값을 유지한 채 예외를 처리하는 구조를 갖고 있는가”이다. 예외가 기본을 대체하기 시작하면, 사람은 유능해져도 성장하지 못한다. 항상 필요할 때만 불려 나가는 문제 해결사는 되지만, 다음 단계에서 요구하는 설계자나 리더는 되기 어렵다.

경력의 정체는 능력의 부족보다, 반복되는 예외가 기본 경로를 덮어버릴 때 발생한다.

진짜 성장하는 사람은 예외를 제어하는 사람이다

이제 두 이야기를 하나로 묶을 수 있다. 좋은 개발자는 기본 동작 위에 예외를 얹되, 그 예외가 기본을 파괴하지 않도록 설계한다. 좋은 경력 설계도 마찬가지다. 다양한 일을 해내되, 그 일이 자신의 핵심 역량과 장기 방향을 지우지 않게 관리해야 한다.

이 관점에서 경력의 핵심은 스펙이 아니라 경계 설정이다. 어떤 업무를 맡을지, 어떤 문제를 깊게 파고들지, 어떤 종류의 반복을 줄일지, 무엇을 자동화할지, 무엇을 문서화할지, 무엇을 위임할지. 이 모든 선택은 결국 “내 기본값을 지킬 것인가”라는 질문으로 수렴한다.

한 가지 강력한 프레임은 이것이다. 당신의 경력을 기본 경로와 예외 경로의 설계 문제로 보라.

기본 경로: 가장 자주 반복되는 일, 핵심 역량, 정체성을 형성하는 업무
예외 경로: 긴급 대응, 한시적 지원, 돌발 문제 해결, 비정형 업무
위험 신호: 예외 경로가 너무 자주 실행되어 기본 경로를 학습할 시간이 사라지는 상태
성장 신호: 예외를 처리한 뒤 그것이 다시 기본 경로로 흡수되어, 다음엔 더 적은 비용으로 해결되는 상태

이 프레임은 단순하지만 강력하다. 성장하는 사람은 예외를 많이 겪는 사람이 아니라, 예외를 구조화하여 기본값으로 환원하는 사람이다. 오늘 해결한 장애가 내일의 운영 문서가 되고, 오늘의 삽질이 다음 분기의 자동화로 바뀌고, 오늘의 불안한 대응이 내일의 체크리스트로 굳어진다. 이 과정이 있어야 경력이 쌓인다.

Key Takeaways

많은 일을 한다고 해서 경력이 자동으로 쌓이지는 않는다. 중요한 것은 사건의 개수가 아니라, 그 사건이 어떤 판단 원리로 묶이는가이다.
undefined는 때때로 중립이 아니라 오버라이드다. 개발에서도 삶에서도, “아무것도 하지 않음”과 “기본값을 없앰”은 전혀 다를 수 있다.
당신의 경력을 기본 경로와 예외 경로로 나눠서 보라. 예외가 기본을 잠식하고 있다면, 단기적으로는 유능해 보여도 장기 성장에는 불리하다.
반복되는 예외는 문서화, 자동화, 위임의 후보다. 매번 새로 대응하는 문제는 언젠가 구조로 바꾸어야 한다.
다음 단계로 가는 사람은 더 많이 버티는 사람이 아니라, 맥락을 회수하는 사람이다. 일이 끝난 뒤 “무엇을 배웠는가”를 한 줄 원리로 정리하는 습관이 필요하다.

예외를 잘 다루는 사람만이 기본값을 가진다

우리는 종종 경력을 “얼마나 많은 것을 해봤는가”로 착각한다. 하지만 실제로는 그 반대에 가깝다. 오래 가는 사람은 많은 예외를 겪은 사람이 아니라, 예외를 통해 기본 구조를 더 단단하게 만든 사람이다. 시스템도 그렇고, 커리어도 그렇다. 좋은 설계는 예외를 인정하면서도 기본을 살아 있게 만든다.

그러니 다음에 당신이 너무 많은 일을 맡고 있다고 느낄 때, 단순히 “내가 더 강해져야 하나”라고 묻지 말자. 대신 이렇게 물어보자. 이 일은 내 기본 경로를 강화하고 있는가, 아니면 조용히 덮어버리고 있는가? 내 경력은 지금 예외 처리 능력을 키우는 방향으로 가고 있는가, 아니면 예외에 의해 기본값이 삭제되는 방향으로 가고 있는가?

이 질문을 던질 수 있게 되는 순간, 경력은 더 이상 우연한 업무의 누적이 아니다. 그것은 의도적으로 설계된 시스템이 된다. 그리고 그때부터 진짜 성장이 시작된다.