직장에 들어가면 처음에는 누군가 시키는 일을 한다. 그것은 당연한 일이다. 그런데 몇 년이 지나도 여전히 ‘시키는 일’만 하고 있다면, 그것은 다른 이야기가 된다. 개발자로서 성장하는 사람과 정체되는 사람 사이에는 여러 차이가 있지만, 가장 뚜렷한 차이 중 하나는 조직 안에서 스스로 주도권을 만들어 냈느냐 여부다. 이 글은 ‘시키는 일을 내 일로 만드는 방법’에 대한 이야기다. 수동적으로 일하는 것이 나쁘다는 도덕적 훈계가 아니라, 실제 커리어에 어떤 차이를 만드는지, 그리고 구체적으로 무엇을 하면 되는지를 다룬다.
주도권이 없는 개발자에게 일어나는 일
티켓이 들어오면 처리하고, 스프린트가 열리면 배정된 작업을 하고, 완료하면 기다린다. 이 패턴 자체가 문제는 아니다. 문제는 이 패턴만 반복할 때 일어나는 일이다.
첫째, 역할 정의가 좁아진다. 팀장은 그 사람에게 ‘복잡한 판단이 필요한 일’보다 ‘정해진 작업을 빠르게 처리할 수 있는 일’을 배정하게 된다. 이것이 쌓이면 성과 리뷰에서도 “안정적인 실행자”라는 평가를 받는다. 나쁜 평가는 아니지만, 커리어를 전환하거나 더 복잡한 역할에 도전할 때 약점이 된다.
둘째, 이직 시장에서의 경쟁력이 줄어든다. 면접관들이 자주 묻는 질문 중 하나는 “본인이 주도적으로 시작한 프로젝트나 개선 사례가 있나요?”다. 수동적으로 일해온 사람은 이 질문에서 막힌다. 결과물은 있지만 스토리가 없다. 스토리는 만들어지는 게 아니라, 일하면서 누적되는 것이다.
셋째, 성장이 느려진다. 시키는 일만 할 때는 내가 무엇을 잘 모르는지조차 파악하기 어렵다. 문제를 정의하고 방법을 선택하는 경험이 없으면, 기술 스택이 익숙해져도 판단력은 키워지지 않는다.
주도권을 만드는 첫 번째 단계: 문제를 먼저 보는 습관
주도권은 거창한 제안서를 제출하거나 상사를 설득하는 것에서 시작하지 않는다. 지금 하고 있는 일 안에서 ‘왜’를 먼저 묻는 것에서 시작한다.
예를 들어 특정 API 엔드포인트를 수정하라는 지시를 받았다고 하자. 수동적인 접근은 스펙대로 구현하고 PR을 올리는 것이다. 주도적인 접근은 그 엔드포인트가 어떤 맥락에서 사용되는지, 이번 변경이 다른 호출부에 어떤 영향을 주는지를 먼저 파악한 후, 놓친 엣지 케이스가 있다면 작업 전에 공유하는 것이다. 이 차이가 당장 눈에 보이지 않을 수 있지만, 반복되면 팀장이 그 사람을 바라보는 방식이 달라진다.
실천 방법은 단순하다. 작업을 받을 때 두 가지 질문을 스스로에게 던지는 것이다. ‘이 작업은 어떤 문제를 해결하기 위한 것인가?’ 그리고 ‘이 방식이 최선인가, 아니면 더 나은 선택지가 있는가?’ 두 번째 질문에 대한 답을 항상 제시할 필요는 없다. 그 질문을 습관적으로 갖고 있는 것만으로도 일을 대하는 태도가 달라진다.
작은 소유권을 쌓는 방법
‘소유권(ownership)’이라는 말이 요즘 채용 공고에 자주 등장한다. 많은 회사에서 원하는 인재의 키워드로 쓰이는데, 구체적으로 무엇을 의미하는지는 잘 설명되지 않는다. 현실에서 소유권은 ‘내가 책임지고 끝까지 따라가는 영역을 갖는 것’으로 정의할 수 있다.
처음부터 큰 프로젝트를 맡을 필요는 없다. 작은 영역부터 시작하는 게 현실적이다. 다음은 조직 안에서 실제로 적용할 수 있는 방법들이다.
- 특정 모듈이나 서비스의 담당자가 되기: 팀 내에서 “이 부분은 내가 가장 잘 안다”는 영역을 하나 만들어라. 자발적으로 문서를 정리하거나, 그 영역에서 발생하는 이슈에 먼저 반응하는 것부터 시작할 수 있다.
- 반복되는 불편함을 개선하기: 개발 과정에서 팀이 반복적으로 겪는 불편함이 있다면, 그것을 해결하는 작은 스크립트나 문서를 만들어 공유하라. 규모가 작아도 팀의 생산성에 실제로 기여하면 인지된다.
- 리뷰 품질 높이기: 코드 리뷰에서 단순한 스타일 지적을 넘어, 설계 판단이나 엣지 케이스를 짚는 리뷰를 하라. 리뷰는 기여도가 낮아 보이지만, 좋은 리뷰어는 팀에서 빠르게 신뢰를 얻는다.
- 배포 이후를 챙기기: 기능을 개발하고 머지했다고 끝이 아니다. 배포 이후 실제 지표나 에러 로그를 확인하고, 이슈가 생기면 먼저 파악하는 사람이 되어라. 이 습관 하나가 개발자로서의 신뢰도를 크게 높인다.
이것들은 누구에게 허락을 받아야 할 일이 아니다. 지금 당장 할 수 있는 일들이고, 조직에서 주도권을 인정받는 가장 빠른 경로이기도 하다.
제안하는 개발자가 되는 법
일을 주도적으로 한다는 것의 다음 단계는 아직 존재하지 않는 일을 제안하는 것이다. 많은 개발자가 이것을 어려워하는 이유는 자신의 제안이 기각될까 봐 두려워서이거나, 어떻게 말을 꺼내야 할지 몰라서다.
제안을 잘 받아들여지게 하려면 형식보다 내용이 중요하고, 내용에서는 ‘문제 정의’가 핵심이다. 좋은 제안은 “이것을 하면 좋겠습니다”가 아니라 “현재 이런 문제가 있고, 이로 인해 이런 비용이 발생합니다. 이 방법으로 접근하면 어떨까요?”의 구조를 갖는다.
또한 처음부터 큰 제안을 하지 않아도 된다. 기존 기능의 개선, 테스트 커버리지 확대, 문서 정비처럼 팀장이 리스크 없이 동의할 수 있는 것부터 시작하면 제안하는 근육이 생긴다. 한두 번의 제안이 실제로 실행되고 나면, 더 복잡한 제안도 훨씬 수월하게 통과된다. 신뢰는 누적된다.
제안이 기각될 때는 그 이유를 물어라. “왜 이 방향이 아닌가요?”를 이해하는 것이 다음 제안을 더 잘 만드는 데 도움이 된다. 기각 자체를 실패로 볼 것이 아니라, 조직의 우선순위와 의사결정 기준을 배우는 기회로 볼 수 있다.
조직 언어로 말하기: 기술 vs 비즈니스
주도권을 갖고 싶지만 제안이 잘 통하지 않는다고 느끼는 개발자들의 공통된 패턴이 있다. 기술적인 이유만으로 설득하려 한다는 점이다. “이 쪽이 더 효율적인 알고리즘입니다”, “레거시 코드라 유지보수가 어렵습니다” 같은 말은 개발자들 사이에서는 충분한 이유가 되지만, 조직의 의사결정자에게는 그렇지 않은 경우가 많다.
조직에서 설득력을 갖추려면 기술 언어와 비즈니스 언어를 연결하는 능력이 필요하다. 예를 들어 “이 API 응답 시간을 개선하면 사용자 이탈률을 줄일 수 있습니다”처럼 기술적 개선이 비즈니스 지표에 미치는 영향으로 설명하는 것이다. 직접 연결이 어렵다면 “이 작업을 지금 하지 않으면 나중에 드는 비용”을 언급하는 것도 효과적이다. 기술 부채는 어느 시점에서 반드시 비용으로 전환된다는 것은 경험 있는 관리자라면 이미 알고 있다.
이 능력을 키우는 가장 좋은 방법은 팀장이나 PM이 어떤 지표를 보는지, 어떤 문제에 민감하게 반응하는지를 관찰하는 것이다. 조직의 우선순위를 이해하면, 자신의 기술적 판단이 그 안에서 어떤 위치를 갖는지 알 수 있고, 제안을 만드는 방식도 달라진다.
번아웃 없이 주도권을 유지하는 법
주도권을 강조하면 빠지기 쉬운 함정이 있다. 모든 것을 내 일로 만들려다가 결국 지쳐버리는 것이다. 주도권과 과부하는 다르다. 주도권은 내가 영향을 미칠 수 있는 범위를 의식적으로 선택하는 것이지, 모든 일에 손을 뻗는 것이 아니다.
지속 가능한 주도권을 갖기 위해 필요한 것은 ‘선택과 집중’이다. 지금 내가 가장 잘 할 수 있는 영역, 팀에 실제로 기여할 수 있는 영역에 주도권을 투자하고, 나머지는 신뢰하고 넘기는 것이 필요하다. 모든 문제를 혼자 해결하려 하지 않고, 적절한 시점에 도움을 요청하거나 위임하는 것도 주도권의 일부다.
또한 주도권을 발휘하는 데 있어 결과가 항상 눈에 보이지는 않는다. 제안이 채택되지 않기도 하고, 개선했다고 생각했는데 결과가 기대에 못 미치기도 한다. 이런 상황을 개인의 실패가 아니라 조직 안에서 일하는 과정의 일부로 받아들이는 관점이 장기적으로 주도권을 유지하는 데 도움이 된다.
주도권을 만드는 일은 빠른 성과를 목표로 하는 것이 아니다. 반년, 일 년 뒤 팀 안에서 나의 포지션이 어떻게 달라졌는지를 기준으로 평가해야 한다. 그 변화는 조용하지만, 방향이 맞으면 분명하게 나타난다.
지금 당장 할 수 있는 것 하나
주도권은 한 번에 바뀌지 않는다. 오늘 하나를 다르게 하는 것에서 시작된다. 오늘 처리할 작업 하나를 골라 이런 순서로 접근해 보자.
- 이 작업이 왜 필요한지 한 문장으로 정리해 본다.
- 작업 중 발견한 사소한 개선점이 있다면 PR 설명에 한 줄 추가한다.
- 배포 후 하루 뒤에 결과를 한 번 확인한다.
이 세 가지가 전부다. 이것을 한 달 동안 반복하면, 일을 대하는 방식이 눈에 띄게 달라진다. 팀에서 보이는 방식도 달라진다.
커리어 전환이나 이직을 고민하고 있다면, 또는 지금 있는 조직에서 더 의미 있는 역할을 맡고 싶다면, 누스쿨 커뮤니티와 1:1 멘토링을 활용해 보길 권한다. 실제 현직 개발자, 기획자, 디자이너들이 자신의 경험을 기반으로 구체적인 방향을 함께 고민해 준다. 한 번의 대화가 몇 달의 시행착오를 줄여줄 수 있다.
💬 댓글 0