개발자의 물경력은 어떻게 만들어지는가

SoftyChoco2025년 5월 23일Less than 1 minute

개발자의 물경력은 어떻게 만들어지는가 관련

처음 개발을 시작했을 때를 떠올려 봅시다. 그때는 코드를 짜는 것 자체가 재미있고, 화면에서 무언가가 “돌아가는 것”만으로도 짜릿한 경험을 하지 않으셨나요? 그때는 기술 하나하나가 신기했고, 새로운 기술을 접할 때마다 호기심이 솟았습니다. 그러나 시간이 흐르고 '업무'를 하게 되면서 점차 본질이 흐려지기 시작했습니다. 왜 이 기술을 익혀야 하는지보다는 어떤 기술이 더 유명하고 좋아 보이는지, 그리고 이력서에서 더 가치 있어 보이는지를 중요하게 생각하죠. 이력서에 적을 키워드가 많아지는 것이 곧 성장의 척도처럼 느껴지고, 실제로 그 기술로 어떤 문제를 해결했는지는 뒷전으로 밀리는 경우도 많습니다. 그렇게 바쁘게 일하던 우리는 왜 성장하지 못했을까요?

오너십(Ownership): 성장의 제약을 풀자

처음 개발자가 되었을 때의 마음을 기억하시나요?

처음 개발을 시작했을 때를 떠올려 봅시다. 그때는 코드를 짜는 것 자체가 재미있고, 화면에서 무언가가 “돌아가는 것”만으로도 짜릿한 경험을 하지 않으셨나요? 작은 기능 하나를 만들어 내가 생각한 대로 동작할 때 느끼던 성취감. 그때는 기술 하나하나가 신기했고, 새로운 기술을 접할 때마다 호기심이 솟았습니다.

그러나 시간이 흐르고 '업무'를 하게 되면서 점차 본질이 흐려지기 시작했습니다. 왜 이 기술을 익혀야 하는지보다는 어떤 기술이 더 유명하고 좋아 보이는지, 그리고 이력서에서 더 가치 있어 보이는지를 중요하게 생각하죠. 이력서에 적을 키워드가 많아지는 것이 곧 성장의 척도처럼 느껴지고, 실제로 그 기술로 어떤 문제를 해결했는지는 뒷전으로 밀리는 경우도 많습니다. 그렇게 “Kafka는 써봤어?”, “Terraform은?”, “MSA는?” 같은 질문들이 반복되었죠.

물론 기술의 습득이 중요하지 않다는 것은 아닙니다. 개발자는 결국 기술로 말하는 직업이니까요. 그러나 그보다 더욱 중요한 것은 그 기술이 '무엇을 위해' 쓰였으며, '어떤 문제를 해결하기 위해' 사용했는지입니다. 그렇게 성장이 멈췄다고 느끼는 개발자들 가운데 많은 경우가 기술 자체는 열심히 익혔지만, 정작 **'문제를 해결하는 경험'**은 제대로 쌓지 못한 경우입니다.

바쁘게 일하는데 왜 성장하지 못했을까?

기술은 수집했지만, 문제는 놓쳤다

개발자로 일하다 보면 어느 순간부터 성장이 멈췄다는 느낌이 들곤 합니다. 예전에는 기술만 공부해도 할 수 있는 것이 많아진다고 생각했는데, 시간이 갈수록 꼭 그렇지만은 않은 것 같습니다. 게다가 매일 바쁘게 일하고 있는데도 제자리에 멈춰 있는 듯한 느낌이 들죠. 새로운 업무도 해봤고 기술도 꾸준히 공부했는데도 말이에요.

이런 상황이 자주 발생하는 사람이 대표적인 **'기술 수집가'**라고 할 수 있습니다. 기술 수집가들은 새로운 기술이 나오면 재빨리 따라 배우고 여기저기 다양하게 사용해 봅니다. 그렇게 이력서에 적을 수 있는 기술 키워드는 하나둘씩 늘어나지만, 정작 그 기술을 왜 선택했는지, 어떤 문제를 해결했는지에 대한 맥락은 없는 경우가 많습니다. 예를 들어 MSA를 구축해 봤다고 말하지만, 정작 그 기술이 왜 필요한 상황이었는지, 그래서 어떤 문제를 해결했는지 명확하지 않은 것이죠. 오히려 오버엔지니어링(over-engineering)이 되어 비용과 복잡도만 올라가는 경우가 많습니다.

이렇게 문제 해결보다는 단순히 '기술을 적용했다'는 결과만 남기며, 기술을 쓰기 위한 기술, 이력서를 채우기 위한 프로젝트만 반복하다 보면 결국 '일은 하고 경력은 쌓이는데 성장은 없는' 상황이 벌어집니다.

문제 해결 능력이란 무엇일까?

우리가 흔히 이야기하는 '문제 해결 능력'은 결국 어떤 기술을 선택했고 그것을 어떻게 적용했는지 설명할 수 있는 능력입니다. 문제를 정의하고, 그 문제에 가장 적절한 해답이 무엇인지 고민하는 과정이라고도 할 수 있죠. 이러한 과정 없이 기술만 쌓는 일은 마치 지도 없이 걸어가는 것과 같습니다. 결국 어디로 가야 하는지 방향을 잃어버리고 맙니다.

문제 해결 능력이란 단순히 코드를 잘 짜는 능력이 아닙니다. **'왜 이 작업을 해야 하는지', '현재 상황에서는 무엇이 더 중요한지', '어떤 선택이 더 나은 방향인지'**와 같은 질문을 스스로 던지고, 그에 대한 답을 찾아가는 과정에서 생겨나는 능력입니다. 이러한 과정을 겪다 보면 기술은 문제 해결을 위한 도구로써 자연스럽게 따라옵니다.

그렇게 기술 자체는 성장의 출발점이 될 수 있지만, 그것만으로는 목적지에 도달할 수 없습니다. 문제를 해결하고자 하는 목적 없이 기술만을 쌓아 봤자 언젠가 한계에 부딪히게 됩니다.

물경력은 어떻게 만들어지는가?

문제를 해결한 것이 맞나요?

주니어 때는 기술에 집중하는 시간이 많습니다. 프로그래밍 언어의 문법이나 프레임워크의 구조, 협업 도구 사용법 등 기초 역량을 쌓기 위한 '학습 중심'의 시간이 꼭 필요하죠. 그런데 이 시기를 지나서도 이전과 같은 방식으로 일하고 있다면, 어느 순간부터는 '기술은 꾸준히 배우는데도 성장하지 못하는' 느낌이 찾아옵니다. 이 단계에서 반드시 이루어져야 하는 전환점은, 바로 '기술 중심 성장'에서 '문제 중심 성장'으로 관점을 바꾸는 것입니다.

기술 중심 성장은 새로운 언어나 도구를 배우고 익히는 데 초점이 맞춰져 있습니다. 그러나 문제 중심 성장은 '무엇이 문제인지', '어떻게 해결할지', 그리고 '왜 이 선택이 맞는지' 고민하는 데서 시작합니다. 같은 기술을 사용하더라도 문제 해결에 초점을 맞추는 사람은 전혀 다른 경험과 성장을 얻게 됩니다.

그러니 만약 기술은 늘었지만 성장이 느껴지지 않는다면, 어쩌면 기술을 위한 기술만 쌓아왔기 때문은 아닌지 점검해 보세요. 경험은 많지만 문제 해결 경험이 없는 상태, 이것이 바로 우리가 흔히 말하는 '물경력'의 가장 큰 특징 중 하나이기 때문입니다.

시장은 기술보다 '맥락'을 요구한다

특히 최근 몇 년 사이, 개발자 시장이 변하고 있습니다. 기술 키워드만으로는 어필이 점점 어려워지고, 이제는 “이 기술로 어떤 문제를 어떻게 해결했는가?”를 설명할 수 있는 사람이 더 강력한 인재로 평가받고 있습니다. 단순히 “MSA 경험 있음”, “Kafka 사용 경험 있음”만으로는 충분하지 않다는 뜻이죠. 이제는 왜 그 기술을 선택했는지, 또 어떤 다른 옵션이 있었으며, 그 선택이 팀과 사용자에게 어떤 영향을 주었는지까지 말할 수 있어야 합니다.

이런 질문에 대답하지 못하는 사람은 아무리 많은 기술을 써봤다고 해도 문제를 '해결'한 것이 아니라 단순히 '누군가 시킨 작업'을 한 것이 전부입니다. 그리고 그렇게 반복된 단순 작업은 결국 성장의 흔적이 없는 경력, 즉 물경력이 되고 맙니다.

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

오너십(Ownership)이란 무엇일까?

그렇다면 이러한 상황은 어떻게 극복할 수 있을까요? 제가 제안하는 것은 '오너십(Ownership)'을 가지는 것입니다.

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

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

개발자에게 기술은 도구입니다. 따라서 그 도구 자체에만 집중하면, “무엇을 위해 만들고 있는가”라는 질문은 자연스럽게 멀어지게 됩니다. 반면, 오너십 중심 사고는 출발점부터 다릅니다. 기술보다 앞서 있는 문제 자체에 관심을 가지고, 그 문제를 해결하는 과정에서 어떤 기술이 필요한지를 고민하게 만듭니다.

예를 들어, 기술 중심 사고는 이렇게 작동합니다.

“마이크로서비스는 도입해 봤으니까… 요즘 Kafka 많이 쓴다고 하던데 그걸 써보자.”

실제 상황이나 필요에 따라 기술을 결정하는 것이 아니라, 개인의 흥미나 관심도로 기술을 결정하는 것입니다.

그러나 오너십 중심 사고는 다릅니다.

“우리가 겪고 있는 서비스의 병목은 어디서 발생했을까? 사용자 입장에서는 어떤 지점이 가장 답답할까? 그 문제를 해결하려면 어떤 구조가 필요할까?”

이처럼 사용자의 실제 불편과 문제를 해결하기 위해 고민하게 됩니다.

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

태도를 바꾸면 시야가 달라진다

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

만약 내가 만든 서비스에서 장애가 발생했다면 오너십 있는 개발자는 단순히 에러를 고치는 데 그치지 않습니다. 왜 이런 문제가 발생했는지, 어떻게 해야 다시 같은 문제가 생기지 않을지, 더 나아가 사용자 입장에서 이 문제가 어떤 경험으로 이어질지 진지하게 고민합니다.

이렇게 오너십은 **'내 것처럼 생각하는 태도'**에서 출발합니다. 이 태도를 가지면 기술 선택에도 맥락이 생기고, 협업 과정에도 적극적으로 참여하며, 단순한 티켓 처리자의 역할에서 벗어나 문제를 주도적으로 해결하는 주체로 성장하게 됩니다. 어렵게 느껴진다면 정말 내가 만들고 싶은 서비스를 만드는 과정을 상상해 보세요. 발견한 문제를 해결하기 위해 무엇이라도 해볼 것 같지 않나요?

오너십은 실무에서 이렇게 드러난다

1. 티켓 단위 vs 흐름 단위

업무를 '티켓 단위'로만 바라보면, 내가 맡은 기능만 구현하면 끝이라고 생각하기 쉽습니다. 요구사항에 따라 코드를 작성하고 테스트를 거쳐 배포하는 일련의 과정이라고요. 이 과정 자체가 틀린 것은 아니지만, 여기서 끝나면 오너십이 개입할 여지가 거의 없습니다.

반대로 업무를 '흐름 단위'로 바라보면 생각은 달라집니다. 이 기능이 어떤 맥락으로 필요해졌는지, 앞뒤로 어떤 서비스와 연결되는지, 사용자가 어떤 흐름 안에서 이 기능을 경험할 것인지 먼저 고민하게 될 것입니다. 단순히 개별 기능을 중심으로 작업하는 것이 아니라, 사용자 경험의 전체 흐름 속에서 작업의 의미를 찾는 것, 이것이 바로 오너십의 시작입니다.

2. '왜'를 묻는 습관

오너십은 항상 질문에서 시작됩니다. **“왜 이 기능이 필요할까?”, “왜 이 방식으로 구현해야 하지?”, “왜 지금 이 시점에 진행하는 걸까?”**와 같은 질문들이죠. 모두 단순한 호기심이 아닌 업무의 맥락을 더 깊이 이해하려는 시도입니다.

반대로 '왜'를 묻지 않는 개발은 쉽게 행동합니다. 시킨 대로 작업하고, 문서에 따라 구현하며, 피드백이 오면 고치는 방식이죠. 겉보기에는 문제없이 돌아가지만, 이 상태에서는 문제를 주도적으로 발견하거나 개선 방향을 제안할 여지가 없습니다.

'왜'라고 묻는 태도는 내가 지금 무엇을 만들고 있는지, 그것이 어떤 맥락 안에서 존재하는지를 스스로 확인하게 만듭니다. 이런 태도가 자리 잡힐수록 자연히 더 나은 방향으로 문제를 개선하고 싶은 마음이 듭니다.

3. 기술 선택의 맥락

요즘은 어떤 기술을 선택했는지가 아니라, 왜 그 기술을 선택했는지가 더욱 중요하다고 했습니다. 오너십 있는 개발자는 특정 기술을 선택할 때 팀의 역량과 프로젝트의 규모, 사용자 요구 등을 모두 함께 고려합니다.

예를 들어, 단지 “NestJS가 핫하니까”라는 이유로 백엔드 프레임워크를 고른다면, 이는 문제를 해결하기 위한 결정이 아닙니다. 실제 서비스의 요구사항과 팀의 경험 수준, 인프라의 복잡성 등을 충분히 저울질한 다음 기술을 선택하는 것이야말로 문제를 해결하는 선택입니다.

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

4. 사용자에 대한 관심

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

내가 만든 기능이 실제 사용자에게 어떤 불편을 줄 수 있을지, 어떤 상황에서 혼란을 겪게 될지를 미리 상상해 보는 것. 이것이 바로 사용자 중심 사고로 오너십의 핵심 부분이기도 합니다.

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

오너십을 기르는 방법

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

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

예를 들어, 아래와 같은 행동들은 누구나 바로 실천해 볼 수 있습니다.

업무를 할 때, 스스로 '왜' 이 작업이 필요한지 생각하고 정의해본다
전체 업무 흐름 속에서 내가 맡은 작업의 위치와 맥락을 이해하려고 노력한다
작업을 진행하기 전/후로 사용자 입장에서 사용 시나리오를 상상해 본다
문제가 발생했을 때 단순히 기술 수정에 그치지 않고 본질을 되짚어 본다

이런 행동은 작고 단순해 보이지만, 꾸준히 실천하면 자연스럽게 '내 일'이라는 감각이 만들어집니다. 그 감각이 차곡차곡 쌓이다 보면 결국 오너십이라는 태도로 이어지죠. 성장은 쌓아둔 지식에서 오는 게 아니라 생각과 고민을 거쳐 적절한 상황에 지식을 활용할 때 비로소 만들어집니다.

협업과 커뮤니케이션의 확장

마지막으로, '오너십을 가진다'는 말은 혼자 모든 것을 책임지겠다는 뜻이 아닙니다. 오히려 협업과 커뮤니케이션의 질을 더 높이겠다는 의미여야 합니다. 문제가 생겼을 때, 다른 팀에게 적극적으로 의견을 물어보거나, 내가 잘 모르는 도메인에 대해 먼저 질문하는 태도를 가져 봅시다. 이는 단순한 질문을 넘어서는 문제 해결을 위한 능동적인 움직임입니다.

또한 협업 과정에서 단지 전달받은 내용을 그대로 구현하는 것이 아니라 요구사항에 대해 되묻고 더 나은 방향을 먼저 제안하는 것도 중요한 태도입니다.

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

결국 오너십은 태도에서 시작하지만, 행동과 소통으로 완성됩니다. 스스로 질문하고, 주변과 연결되며, 사용자에 대한 책임감을 느끼는 그 순간. 비로소 '기술자'에서 '문제 해결자'로 성장할 수 있습니다.

마치며: 어떻게 다시 성장할 수 있을까?

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

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

오너십은 그렇게 태도로부터 시작합니다. 내가 만든 제품이라는 생각, 내가 만든 기능의 결과에 책임을 느끼는 감각. 이러한 감각이 생기면 기술을 대하는 시선도, 업무를 대하는 방식도 변하게 됩니다. 단순히 '내가 대표라고 생각하고 열심히 하자'라는 식의 막연한 말이 아닙니다. 문제를 발견하고, 해결하며, 그 경험을 내 성장으로 연결하는 주도적인 태도를 가지자는 것입니다.

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

개발자의 물경력은 어떻게 만들어지는가