개발자가 성장 정체기를 극복하는 방법

기술 수집가에서 문제 해결자로: 성장의 본질

처음 개발자가 되었을 때의 순수함

개발을 시작했던 그때를 떠올려보세요. 간단한 기능 하나가 제대로 동작할 때마다 느꼈던 성취감, 새로운 기술을 배울 때마다 솟구쳤던 호기심. 그때는 기술 하나하나가 신기했고, 무엇보다 ‘내가 생각한 것을 실현할 수 있다’는 사실 자체가 놀라웠습니다.

하지만 ‘업무’를 시작하면서 점차 본질이 흐려지기 시작합니다. 어느새 “이 기술이 트렌디하니까”, “이력서에 쓰기 좋아 보이니까”라는 이유로 기술을 선택하게 되죠. Kafka, Terraform, MSA 같은 키워드들이 실제 문제 해결보다는 포트폴리오의 화려함을 위한 수단이 되어버리는 겁니다.

기술 수집가의 딜레마

기술 수집가들의 특징을 살펴보면 흥미로운 패턴이 보입니다. 새로운 기술이 나오면 누구보다 빠르게 학습하고, 이력서에 적을 수 있는 키워드도 꾸준히 늘어납니다. 하지만 정작 “왜 이 기술을 선택했는가?”, “어떤 문제를 해결했는가?”라는 질문에는 명확한 답변을 하지 못합니다.

예를 들어, MSA(마이크로서비스 아키텍처)를 도입했다고 하지만, 정작 왜 그 기술이 필요한 상황이었는지, 기존 모놀리식 구조의 어떤 문제점을 해결했는지는 설명하지 못하는 경우가 많습니다. 오히려 오버엔지니어링으로 인해 복잡도와 비용만 증가하는 결과를 낳기도 하죠.

이렇게 기술을 위한 기술, 이력서를 채우기 위한 프로젝트만 반복하다 보면 ‘일은 하고 경력은 쌓이는데 성장은 없는’ 악순환에 빠지게 됩니다.

문제 해결 능력의 진정한 의미

기술보다 중요한 맥락

우리가 말하는 ‘문제 해결 능력’은 단순히 코드를 잘 짜는 능력이 아닙니다. 오히려 “왜 이 작업을 해야 하는지”, “현재 상황에서는 무엇이 더 중요한지”, “어떤 선택이 더 나은 방향인지”와 같은 질문을 스스로 던지고, 그에 대한 답을 찾아가는 과정에서 생겨나는 능력입니다.

이러한 과정을 겪다 보면 기술은 문제 해결을 위한 도구로써 자연스럽게 따라옵니다. 마치 지도를 보고 목적지를 정한 후 최적의 경로를 찾는 것처럼 말이죠.

시장이 요구하는 진짜 역량

최근 개발자 시장의 변화를 주목해보세요. 더 이상 “MSA 경험 있음”, “Kafka 사용 경험 있음”만으로는 어필이 어려워졌습니다. 이제는 그 기술을 왜 선택했는지, 어떤 다른 옵션이 있었으며, 그 선택이 팀과 사용자에게 어떤 영향을 주었는지까지 설명할 수 있어야 합니다.

기술 자체는 빠르게 진화하지만, 문제 해결에 대한 감각이나 사용자에 대한 이해, 의사결정의 맥락을 해석하고 설명하는 능력은 쉽게 변하지 않습니다. 시장은 이제 기술 그 자체보다 그 기술이 쓰인 맥락을 이해하는 사람을 더욱 원하고 있습니다.

물경력: 경험은 많지만 성장은 없는 상태

기술 중심에서 문제 중심으로의 전환점

주니어 시절에는 기술 중심의 성장이 필요합니다. 프로그래밍 언어의 문법, 프레임워크의 구조, 협업 도구 사용법 등 기초 역량을 쌓는 ‘학습 중심’의 시간이 꼭 필요하죠.

하지만 이 시기를 지나서도 같은 방식으로 계속 일한다면 어느 순간부터는 ‘기술은 꾸준히 배우는데도 성장하지 못하는’ 느낌이 찾아옵니다. 이때 반드시 이루어져야 하는 전환점이 바로 ‘기술 중심 성장’에서 ‘문제 중심 성장’으로 관점을 바꾸는 것입니다.

기술 중심 성장은 새로운 언어나 도구를 배우고 익히는 데 초점이 맞춰져 있습니다. 반면 문제 중심 성장은 ‘무엇이 문제인지’, ‘어떻게 해결할지’, ‘왜 이 선택이 맞는지’를 고민하는 데서 시작합니다.

물경력의 핵심 특징

경험은 많지만 문제 해결 경험이 없는 상태, 이것이 바로 우리가 흔히 말하는 ‘물경력’의 가장 큰 특징입니다. 이런 상태에서는 기술적 지식은 풍부하지만, 그 지식을 언제, 어떻게, 왜 사용해야 하는지에 대한 판단력이 부족합니다.

결국 “누군가 시킨 작업”은 잘 수행하지만, 스스로 문제를 발견하고 해결 방안을 제시하는 능력은 개발되지 않는 것이죠.

오너십: 성장의 제약을 푸는 열쇠

오너십에 대한 오해와 진실

흔히 오너십에 대해 말할 때 “돈을 많이 받으면 당연히 오너십이 생기지”라고 합니다. 하지만 오너십은 단순히 책임과 열정을 요구하는 말이 아닙니다. 오히려 문제 중심 성장을 위해 시야를 넓혀주는 개념에 가깝습니다.

제가 말하는 오너십은 일을 어떻게 받아들이고, 문제를 어떻게 해석하는가에 대한 태도입니다. 내가 만든 기능이 사용자에게 어떤 영향을 줄지 끊임없이 고민하는 사람, 기능 하나라도 온전히 나 스스로 만든 제품처럼 생각하는 사람이 바로 오너십을 가진 사람입니다.

기술 중심 사고 vs 오너십 중심 사고

두 가지 사고방식의 차이를 명확히 비교해보겠습니다.

• 기술 중심 사고의 예:
• “마이크로서비스는 도입해 봤으니까… 요즘 Kafka 많이 쓴다고 하던데 그걸 써보자.”
• 오너십 중심 사고의 예:
• “우리가 겪고 있는 서비스의 병목은 어디서 발생했을까? 사용자 입장에서는 어떤 지점이 가장 답답할까? 그 문제를 해결하려면 어떤 구조가 필요할까?”

기술 중심의 개발자들은 도구를 기준으로 사고하고, 오너십을 가진 개발자들은 문제를 기준으로 선택합니다. 이 두 사람은 같은 코드를 짜더라도 전혀 다른 결과를 만들어낼 것입니다.

실무에서 드러나는 오너십의 모습

1. 티켓 단위에서 흐름 단위로

업무를 ‘티켓 단위’로만 바라보면 내가 맡은 기능만 구현하면 끝이라고 생각하기 쉽습니다. 요구사항에 따라 코드를 작성하고 테스트를 거쳐 배포하는 일련의 과정으로만 이해하는 것이죠.

반대로 업무를 ‘흐름 단위’로 바라보면 생각이 완전히 달라집니다. 이 기능이 어떤 맥락으로 필요해졌는지, 앞뒤로 어떤 서비스와 연결되는지, 사용자가 어떤 흐름 안에서 이 기능을 경험할 것인지를 먼저 고민하게 됩니다.

단순히 개별 기능을 중심으로 작업하는 것이 아니라, 사용자 경험의 전체 흐름 속에서 작업의 의미를 찾는 것, 이것이 바로 오너십의 시작입니다.

2. ‘왜’를 묻는 습관의 힘

오너십은 항상 질문에서 시작됩니다. “왜 이 기능이 필요할까?”, “왜 이 방식으로 구현해야 하지?”, “왜 지금 이 시점에 진행하는 걸까?”와 같은 질문들이죠.

이런 질문들은 단순한 호기심이 아닌 업무의 맥락을 더 깊이 이해하려는 시도입니다. ‘왜’라고 묻는 태도는 내가 지금 무엇을 만들고 있는지, 그것이 어떤 맥락 안에서 존재하는지를 스스로 확인하게 만듭니다.

3. 기술 선택에 담긴 철학

오너십 있는 개발자는 특정 기술을 선택할 때 팀의 역량과 프로젝트의 규모, 사용자 요구 등을 모두 함께 고려합니다. 단지 “NestJS가 핫하니까”라는 이유로 백엔드 프레임워크를 고르는 것이 아니라, 실제 서비스의 요구사항과 팀의 경험 수준, 인프라의 복잡성 등을 충분히 저울질한 다음 기술을 선택합니다.

기술은 목적이 아닌 수단입니다. 이 수단을 정확한 맥락 위에 올려놓을 줄 아는 사람이 문제 해결자로 성장할 수 있습니다.

4. 사용자 중심의 관점

오너십을 가진 개발자는 코드 뒤에 있는 사용자를 봅니다. 단순히 기능을 ‘만드는 사람’이 아니라 그 기능을 실제로 쓰는 사람을 바라보는 사람이 되는 것입니다.

예를 들어, 기능은 정상 작동하지만 UI가 애매해 사용자가 헷갈린다면, 그것은 ‘기술적으로 문제없는 기능’이 아닌 실제로 ‘문제를 일으키는 기능’입니다. 오너십 있는 개발자는 이런 부분까지 신경 쓰며, 이런 세심한 태도가 결국 서비스의 품질을 좌우하게 됩니다.

오너십을 기르는 실전 가이드

실무에서 바로 실천할 4가지 행동

거창한 변화가 필요한 것은 아닙니다. 오너십은 실제 업무 현장에서도 얼마든지 조금씩 키워나갈 수 있습니다. 중요한 것은 의식적으로 이러한 ‘태도’를 훈련한다는 마음가짐입니다.

• 업무의 맥락 파악하기: 업무를 할 때 스스로 ‘왜’ 이 작업이 필요한지 생각하고 정의해보세요. 단순히 주어진 티켓을 처리하는 것이 아니라, 그 작업이 전체 서비스에서 어떤 의미를 갖는지 고민해보는 것입니다.
• 전체 흐름 속에서 내 위치 찾기: 전체 업무 흐름 속에서 내가 맡은 작업의 위치와 맥락을 이해하려고 노력하세요. 내 앞과 뒤에 어떤 과정이 있는지, 다른 팀과는 어떻게 연결되는지 파악하는 것이 중요합니다.
• 사용자 시나리오 상상하기: 작업을 진행하기 전후로 사용자 입장에서 사용 시나리오를 상상해보세요. 실제 사용자가 이 기능을 어떻게 경험할지, 어떤 점에서 불편함을 느낄 수 있을지 미리 고민해보는 것입니다.
• 문제의 본질 탐구하기: 문제가 발생했을 때 단순히 기술적 수정에 그치지 않고 본질을 되짚어보세요. 왜 이런 문제가 발생했는지, 어떻게 해야 같은 문제가 재발하지 않을지까지 고민하는 것이 중요합니다.

협업에서 발휘되는 오너십

‘오너십을 가진다’는 말은 혼자 모든 것을 책임지겠다는 뜻이 아닙니다. 오히려 협업과 커뮤니케이션의 질을 더 높이겠다는 의미여야 합니다.

문제가 생겼을 때 다른 팀에게 적극적으로 의견을 물어보거나, 내가 잘 모르는 도메인에 대해 먼저 질문하는 태도를 가져보세요. 이는 단순한 질문을 넘어서는 문제 해결을 위한 능동적인 움직임입니다.

예를 들어 기획이 아쉬울 때, 기획자에게 “그건 기획서에 없었어요”라고 책임을 넘기는 대신 “이렇게 하면 사용자 입장에서 더 편할 것 같아요”라고 의견을 먼저 제시할 수 있는 사람이 바로 오너십을 가진 사람입니다.

성장을 다시 시작하는 마음가짐

초심으로 돌아가기

우리는 처음에 무언가를 만들었을 때 느끼는 성취감과 재미, 그리고 성장을 위해 기술을 배우기 시작했습니다. 하지만 어느 순간부터 기술 그 자체가 성장의 목적이 되어버렸습니다. 처음에는 문제를 해결하기 위해 필요했던 기술을 습득하는 데에만 집중하다 보니 정작 문제까지 뒤로 미룬 채 시간을 흘려보내게 되었습니다.

새로운 관점의 필요성

‘성장이 멈췄다’라는 느낌은 어쩌면 더 이상 기술 키워드만으로는 새로 도약하기 어렵다는 신호이기도 합니다. 이때 필요한 것은 또 다른 기술이 아니라, 문제를 바라보는 관점, 그리고 그 문제를 ‘내 것처럼’ 받아들이는 태도입니다.

오너십은 그렇게 태도로부터 시작합니다. 내가 만든 제품이라는 생각, 내가 만든 기능의 결과에 책임을 느끼는 감각. 이러한 감각이 생기면 기술을 대하는 시선도, 업무를 대하는 방식도 변하게 됩니다.

기술은 끊임없이 발전하겠지만, 변하지 않는 것은 ‘그 기술을 어떤 맥락에서 어떻게 쓸지는 결국 우리가 판단해야 한다’는 점입니다. 성장은 어느 날 갑자기 찾아오지 않습니다. 문제를 바라보는 태도가 바뀌고, 별것 아닌 듯 지나쳤던 요소 하나하나를 주의 깊게 바라보기 시작할 때, 다시 찾아올 것입니다.

여러분은 지금 어떤 문제를 해결하고 계신가요? 단순히 기술을 적용하는 것을 넘어서, 그 기술이 사용자에게 어떤 가치를 제공하는지 생각해보신 적이 있나요? 오늘부터라도 작은 질문 하나씩 던져보세요. 그 질문들이 모여 여러분을 진정한 문제 해결자로 성장시킬 것입니다.