무엇이 개발자를 열심히 일하게 하나요?

최근 저희 팀에 즐거운 소식이 있었습니다. 비즈니스를 지원하고자 제안한 기술 솔루션이 다양한 이해관계자의 검토와 승인을 받아 마침내 개발에 착수하게 된 것입니다. 무엇보다 이번 제안은 비즈니스팀이나 프로덕트 담당자가 아닌, 개발팀 엔지니어들이 주도적으로 머리를 맞대어 만든 아이디어였기에 더욱 뜻깊었습니다.

제가 속한 스쿼드는 글로벌 기업의 테크 조직 중 하나입니다. 이런 글로벌 팀에서 일하다 보면 겪는 어려움 중 하나는 다양한 국가에 분포된 여러 팀과 소통하고 협력하는 일입니다. 특히 저희 조직은 MSA(Micro Service Architecture) 기반으로 다양한 프로덕트를 운영하고 있어, 하나의 기능을 구현하려면 영향받는 모든 프로덕트 팀과 만나 우선순위와 리소스를 조율해야 합니다. 기술적인 내용을 영어로 명확히 전달해야 하는 일 또한 만만치 않아 이번 제안 과정은 정말 쉽지 않은 도전이었습니다. 그래도 여러 차례 제안과 합의로 마침내 새로운 프로젝트를 시작할 수 있게 되었습니다.

기존 업무에 추가로 새로운 프로젝트까지 맡다 보니 업무가 늘어나고 바빠졌지만, 그 누구도 불만을 표시하지 않았습니다. 오히려 개발자들은 즐거워 보이기까지 합니다. 생각해 보면 아무도 개발자에게 ‘아이디어를 내라’고 강요하거나, 여러 팀을 찾아다니며 ‘제안하고 설득하라’고 요청하지 않았습니다. 업무가 늘어나는 것을 좋아할 개발자도 없을 테지만, 이번 프로젝트에서 개발자들은 그 어느 때보다 즐겁게 일하는 것처럼 보입니다.

요즘, 개발자의 동기부여가 어려운 이유

사실 이런 기회는 규모가 큰 조직에서는 흔하지 않습니다. 어느 정도 현대화된 테크 조직이라면 하나의 서비스를 런칭하거나 기능을 구현하기 위한 팀과 역할이 세분화되어 있기 때문입니다.

요즘은 주로 프로덕트를 중심으로 조직이 구성됩니다. 이런 구성에서는 PO(Product Owner)와 PM(Product Manager)으로부터 사용자의 요구사항이 전달됩니다. 그렇게 개발자가 사용자와 직접 소통할 기회는 점점 줄어들고 있습니다. 대부분의 요구사항은 미리 정의된 상태에서 개발자에게 전달되고, 개발자는 이를 받아 수행하는 형태로 업무를 진행하게 됩니다.

이러한 과정에서 개발자들의 의사 결정과 아이디어 참여 기회는 줄어들어 업무가 수동적일 수밖에 없습니다. 더욱이 맡고 있는 업무 영역이 프로덕트의 주요 모듈이 아니라면, 사용자를 위한 직접적인 아이디어 제안은 더욱 어려워질 수 있습니다.

개발자에게 요구사항이 전달되기까지 <출처: 레딧 r/ProgrammerHumor 채널>

이 구조 안에서 개발자들의 동기부여와 주도성은 지속해서 떨어지고 있는 것으로 보입니다. 실제로 제가 여러 팀의 회고나 대화에 참여했을 때도, 이미 많은 개발자가 비슷한 고민을 하고 있다는 것을 알 수 있었습니다. 스크럼 마스터로 일하는 저는 개발자들을 동기부여할 수 있는 아이디어와 문화를 만드는 데 관심이 많지만, 조직과 구조의 제약으로 인해 진짜 동기부여된 팀을 만드는 일은 사실 쉽지 않습니다.

무엇이 개발자를 열심히 일하게 하나요?

궁금합니다. 개발자인 여러분이 일을 할 때면, 무엇이 동기부여를 만들어 주나요? 구체적으로 어떤 요인이 일을 더 잘하고 싶게 하나요? 제가 참고한 몇몇 조사에 따르면, 사람들은 주도적으로 일할 때, 개인이 성장하는 경험을 할 때, 그리고 칭찬과 인정을 받을 때, 더욱 일을 잘하고 싶다 느낀다고 합니다. 모든 사람이 같은 동기부여 요인을 갖고 있지는 않겠지만, 개발자 역시 비슷한 요소로 동기부여될 수 있다고 생각합니다.

무엇보다 최근 저희 팀의 사례로, 저는 개발자가 “내가 하는 일의 의미를 이해하고, 나의 일이 누군가에게 도움이 된다.”라는 사실을 인지할 때, 모두가 더욱 일에 대한 동기부여를 받을 수 있다고 확실하게 느꼈습니다.

이러한 동기부여의 요인을 조금 더 구체화하고, 이를 개발팀에 적용할 수 있는 프로세스와 문화를 만들어 보고 싶었습니다. 그래서 제가 개발자로 일했던 경험을 비롯해 실제로 만난 개발자들의 동기부여 상황과 다양한 사례를 정리해 보았습니다. 그러고 나니 동기부여 요인을 네 가지 항목으로 정리할 수 있었습니다.

개발자 동기부여에 필요한 4가지 요인들

1. 왜 개발해야 하는지 정확히 이해한다

꼭 개발이 아니어도 어떤 일이든 그 일의 목적과 의미를 명확히 이해하는 것은 중요합니다. 예를 들어 시스템 화면에서 버튼 위치를 옮겨달라는 사용자 의견 기반 요청이 있다고 하겠습니다. 개발자는 어떠한 목적과 의도로 그 요청이 왔는지 이해하려고 노력할 필요가 있습니다. 이렇게 개발을 요청한 사용자의 관점에서 목적을 이해해야 주도적인 개발이 가능해지고, 더 나은 아이디어도 제안할 수 있습니다.

2. 누구에게 어떤 가치를 줄 수 있는지 명확하게 인지한다

내가 하는 일이 누군가에게 필요하지 않다고 느낀다면 열심히 일할 이유를 잃어버릴 수 있습니다. 일에 의미를 부여하려면 내 업무가 누구에게, 어떤 가치를 주는지 인지하는 것부터 시작해야 합니다. 예를 들어, 백엔드 개발자가 시스템 배포 프로세스 최적화를 위한 리팩토링을 수행한다면, 이 작업은 최종 사용자에게 직접 보이지 않더라도 같이 일하는 개발자들의 업무 생산성을 크게 높여줄 수 있습니다. 이처럼 내 일이 누구에게 어떤 도움을 주는지 아는 것은 동기부여에 매우 중요합니다.

3. 자율적으로 신뢰받으면서 일하고 있다고 느낀다

내가 하는 개발 업무에 대해 동료들로부터 신뢰받고, 자율적인 환경과 분위기에서 일한다는 느낌은 개발자가 본연의 업무에 더욱 집중하고 열심히 일할 수 있도록 만듭니다. 특히 본인의 의견을 자유롭게 말할 수 있고, 코드 리뷰나 페어 프로그래밍 등 동료와 함께하는 활동으로 심리적 안정감(Psychological Safety)을 얻은 개발팀은 더 뛰어난 퍼포먼스를 내는 팀으로 성장할 수 있습니다.

4. 공헌에 대한 인정과 지속적인 사용자 피드백을 받는다

개발자로서 시간과 노력을 투자한 기능이나 서비스를 누구도 사용하지 않는다면 많이 속상할 것입니다. 개발자로 일할 때는, 내가 개발한 기능이나 서비스가 사용자에게 많이 쓰이고 가치 있다고 느껴질 때보다 보람 있는 것은 없습니다. 사용자의 인지와 그들로부터의 지속적인 피드백은 개발자에게 가장 중요한 의미가 될 수 있습니다. 따라서 꾸준히 상호작용할 수 있는 소통 기회를 많이 만드는 것이 중요합니다.

정리하면, 개발자는 신뢰받는 환경에서 자율적으로 일하며, 가치 있는 일을 한다는 믿음과 공헌을 인정받는 순간으로 지속적인 동기부여를 얻습니다. 이러한 선순환 구조는 결국 개발자 스스로 더욱 열심히 일할 수 있는 원동력이 됩니다. 비단 개발자뿐 아니라 일을 업으로 삼는 모든 사람의 동기부여 요소라고 할 수도 있을 것입니다.

개발자의 진정한 동기부여: 이해관계자와의 상호작용

마지막으로, 개발자로 일하던 저의 과거를 떠올려 보았습니다. 언제 가장 동기부여가 되었고 재미있게 일했었는지를 생각해 본 것이죠. 가장 먼저 일은 힘들었지만, 마음이 잘 맞는 동료들과 함께 같은 목표를 가지고 프로젝트를 진행하던 순간이 떠올랐습니다.

사실, 프로젝트로 큰 성과나 보상이 따랐던 것은 아닙니다. 하지만 “혼자가 아니라 팀으로 함께 일한다는 느낌, 내 업무의 기쁨과 슬픔을 공감해 주는 팀원들의 존재, 모르는 것을 자유롭게 물어볼 수 있는 분위기, 내가 하는 일이 비즈니스에 중요한 의미가 있다는 믿음, 그리고 비즈니스 담당자가 건넨 감사의 한마디”와 같은 요소들이 큰 동기부여를 주었습니다. 그래서 더욱 열심히, 더욱 즐겁게 일할 수 있었습니다.

돌이켜 보면, 그때의 동기부여는 결코 혼자 만들어 낸 것이 아니었습니다. 함께 일했던 동료들과의 관계, 문화와 분위기, 그리고 여러 프로세스가 유기적으로 이어진 점들이 지속적인 동기부여를 만들어 낸 것입니다. 결국, 지속적인 동기부여의 원동력은 개인이 아닌 팀 차원에서 다양한 이해관계자와의 상호작용으로 만들어진다는 사실을 깨닫게 되었습니다.

개발자의 동기부여 사이클 만들기

새로 발견한 동기부여의 요인과 상호작용으로 저는 개발자들이 즐겁고 의미 있게 일할 문화와 프로세스를 만들고 싶었습니다. 그래서 앞서 정리한 네 가지 요인을 팀 안에서 이해관계자들과 어떻게 상호작용하며 개발자의 동기부여를 끌어낼 수 있을지 고민했습니다.

이러한 고민은 저희 개발팀에서 사용하는 애자일의 스크럼(Scrum) 프레임워크를 활용하여, ‘개발자의 동기부여 사이클’을 만들어 적용해 보자는 아이디어로 발전했습니다.

이 동기부여 사이클을 개발자의 관점에서 적용해, 다음과 같은 과정을 구성해 보았습니다.

개발하는 목적과 의미를 이해하는 단계에서 시작해,
내가 하는 개발 작업이 누구에게 어떤 가치를 주는지 인지하며,
주도적으로 개발하며 일할 수 있는 환경을 조성하고,
내가 하는 업무가 중요하다는 것을 이해관계자들이 알아주는 주기적인 프로세스

이렇게 함으로써 개발자가 자신의 업무에 대해 흥미와 즐거움을 느끼도록 만드는 것을 목표로 했습니다.

동기부여 사이클을 스크럼에 적용해 보기

스크럼은 일반적으로 2주 단위 스프린트로, 개발 목표와 계획을 설정하고 작은 단위의 실행 가능한 기능을 개발하는 일을 꾸준히 반복하는 애자일 프레임워크입니다. 하나의 스프린트를 운영할 때는 보통 계획(Planning), 데일리 스탠드업(Daily Stand-up), 리뷰(Review), 회고(Retrospective)와 같은 이벤트(애자일 세레머니)가 각각 목적을 가지고 진행됩니다.

이런 스프린트의 각 이벤트에 개발자의 네 가지 동기부여 요인을 각각 투영하면, 지속적인 동기부여 사이클을 만들 수 있습니다.

1. 스프린트 계획(Sprint Planning)

일반적으로 스프린트 계획 이벤트에서는 PM/PO 또는 개발자가 만든 백로그(개발 항목)의 우선순위와 개발 계획을 논의합니다. 이때 논의는 주로 개발에 필요한 상세 작업 내용과 소요 기간을 중심으로 이루어집니다. 하지만 이 스프린트의 목표(Sprint Goal)를 설정할 때, 개발자가 내가 왜 이 개발을 해야 하고, 개발이 누구에게 도움이 되는지를 명확하게 인지할 수 있는 단계를 포함하면 계획을 더 명확히 세울 수 있습니다.

이를 위해 스프린트에 포함된 백로그는 팀원 각자가 리뷰할 수 있도록 준비하며, 백로그의 생성자는 개발의 목적과 비즈니스 가치에 대해 미리 작성하고 공유하는 것이 좋습니다. 예를 들어, 이번 스프린트에서 선정한 우선순위 높은 백로그가 기술 부채를 해결하는 것이라면, 해당 기술 부채를 개선함으로써 어떤 비즈니스 가치가 생기고 누구에게 도움이 되는지 분명하게 공유해야 합니다.

2. 데일리 스크럼(Daily Scrum)

데일리 스크럼은 팀원들의 개발 진행 상황, 이슈와 장애물을 간략히 공유하는 짧은 타임박스의 이벤트입니다. 이 이벤트는 스크럼 팀에 신뢰와 주도성을 부여할 문화를 만들 가장 생산적이고 효과적인 시간입니다.

이 시간에 개발자는 본인이 맡은 업무에 대한 주도성을 갖고 진행 상황과 다양한 주제를 팀과 공유할 수 있습니다. 또한, 지속적인 공유와 상호작용은 팀 내에서 업무 능력의 향상과 학습을 유도하며, 자유로운 토의로 서로 신뢰를 만들어 문제나 장애물을 효과적으로 해결할 수 있게 돕습니다.

3. 스프린트 리뷰(Sprint Review)

스프린트 리뷰는 하나의 스프린트 기간 내 개발자가 작업한 결과물을 공유하는 세션입니다. 실제 사용자 또는 이해관계자에게 직접적인 피드백을 받을 수 있는 좋은 기회이기도 합니다. 개발자는 이 이벤트로 작업한 내용뿐 아니라 자신의 업무가 비즈니스에 어떤 가치를 제공하는지, 어떤 부분이 개선되는지 설명할 수 있습니다. 이때 공헌에 대한 아이디어를 직접 전달하고 긍정적인 피드백을 받는 선순환 구조를 만들 수 있습니다.

4. 스프린트 회고(Sprint Retro)

마지막으로, 개발자들이 자신의 일을 더욱 즐겁게 할 수 있도록 스프린트 회고를 운영할 수 있습니다. 단순히 잘한 일이나 어려웠던 일을 공유하는 것에서 나아가, 사용자 피드백이나 개선이 필요한 항목을 바탕으로 가치 있는 일을 위한 아이디어를 자유롭게 제안하고 합의하는 시간으로 만드는 것이 중요합니다. 무엇보다 가장 중요한 것은 팀으로서 심리적 안정감을 가지며 서로 격려하고 소통하는 긍정적인 문화입니다. 서로 따봉을 보내는 문화를 토대로, 내가 하는 일의 보상과 재미를 느낄 수 있습니다.

마치며

스크럼(Scrum) 프레임워크는 원래 IT 팀의 프로덕트 개발을 위해 만들어진 개념이지만, 유연한 특성으로 어떤 업무에도 쉽게 조정해 적용할 수 있습니다. 스크럼의 개념을 자신의 업무에 적용해 본다면 분명 더 즐겁고 생산적인 업무 프로세스를 만들 수 있을 것입니다.

지속적인 동기부여로 일을 더 즐겁게 하고 싶다는 욕구는 모두의 바람일 것입니다. 꼭 개발자가 아니더라도, 스스로 동기부여 요소를 찾고 더욱 의미 있게 일할 수 있는 아이디어를 고민해 보는 것은 어떨까요?