팀이 더 잘 일하게 만드는 개발자가 되기까지

2024년을 돌아보며

2024년은 제게 중요한 전환점이 된 해였습니다.

개발자로서, 한 조직의 구성원으로서, 그리고 한 개인으로서 어떤 기준으로 행동하고 선택해야 하는지 많이 고민했습니다.

특히 “무엇을 할 것인가”보다 “왜 그것을 하는가” 를 더 자주 물었습니다. 올해 배운 것을 리더십, 자동화, 본질, 학습이라는 네 가지 주제로 정리합니다.

리더십과 팀워크

올해 제가 정리한 리더십은 단순합니다.

리더는 혼자 일을 잘하는 사람이 아니라, 팀이 더 잘 일할 수 있도록 돕는 사람입니다. 그래서 리더는 조직 안에서 서포터에 가까운 역할이라고 생각합니다.

앞으로 리더십이 필요한 역할을 맡는다면 다음 원칙을 지키고 싶습니다.

• 구성원이 재미와 동기를 느낄 수 있는 환경을 만든다. 선택권을 주고, 맡은 일의 책임도 분명하게 나눈다.
• 실패 비용을 줄인다. 자동화와 좋은 작업 방식으로 같은 실패가 반복되지 않게 만든다.
• “내가 좋다고 생각해서”가 아니라 실제 Pain Point를 해결하기 위해 행동한다.
• 결정을 오래 미루지 않는다. 틀린 결정에서도 배움을 남기면 다음 선택을 더 낫게 만들 수 있다.

이 생각은 자동화에 대한 관심으로 이어졌습니다. 팀이 반복되는 문제에 덜 흔들리게 만드는 것도 서포터의 역할이라고 보았기 때문입니다.

자동화와 설득

올해 조직 안에서 Pain Point를 찾아 여러 자동화를 만들었습니다. OpenAPI 기반 Mock 서버, Pull Request 확인 도구, Electron App 빌드와 GitHub Release 자동화가 대표적인 사례였습니다.

처음에는 반복 작업과 실수를 줄이는 장점에 집중했습니다. 하지만 자동화가 항상 바로 환영받는 것은 아니라는 점도 배웠습니다.

좋은 자동화라도 구성원이 왜 필요한지 이해하지 못하면 신뢰를 얻기 어렵습니다. 그래서 자동화에는 설명과 설득이 필요합니다.

왜 필요한지, 어떤 문제를 줄이는지, 얼마나 도움이 되는지를 함께 보여줘야 합니다.

지금은 영향이 작고 당장 도움이 되는 것부터 시작합니다. 실행 결과를 지표나 숫자로 확인한 뒤, 배운 것을 다음 자동화에 반영합니다.

작은 실행이 다음 실행을 더 낫게 만들 때 자동화도 복리로 쌓입니다.

작게 나누고 다시 조합하기

어떤 코드가 변화에 잘 대응하는지 고민했고, 나름의 기준을 얻었습니다.

원칙을 가지고 더 나눌 필요가 없는 크기까지 나눈 뒤, 필요한 형태로 다시 조합하는 코드가 바꾸기 쉬웠습니다.

함수형 프로그래밍을 좋아하는 이유도 여기에 있습니다. 작은 순수 함수는 이해하고 검증하기 쉽고, 다시 조합하기도 쉽습니다. Radix UI와 Shadcn UI를 좋아한 이유도 비슷했습니다. 기능을 작은 단위로 나누고 필요한 모습으로 조합할 수 있었습니다.

작게 나누면 빠르게 시도할 수 있습니다. 실패하더라도 영향을 줄이고 다시 돌아올 수 있습니다.

그래서 코드 리뷰와 설계에서도 먼저 나눌 수 없는 단위가 무엇인지 생각하게 되었습니다.

기술보다 원칙을 먼저 보기

REST API, GraphQL, gRPC는 서로 다른 도구지만 비슷한 질문을 다룹니다.

데이터를 어떤 약속으로 정리하고 전달할 것인가.

중요한 것은 특정 기술을 많이 아는 것보다 팀이 함께 이해할 수 있는 원칙을 세우는 일이라고 생각합니다. 원칙이 약하면 같은 기술을 쓰더라도 사람마다 다르게 해석합니다. 기능을 더할 때마다 의사소통 비용도 커집니다.

반대로 원칙이 분명하면 처음에는 조금 느려 보여도 장기적으로 더 빠르게 바꿀 수 있습니다.

올해는 무조건 빨리 만드는 것보다 원칙을 지키는 일이 더 빠른 길이 될 때도 있다는 것을 배웠습니다.

실행에서 배운 것을 남기기

많은 조직이 실행에는 집중하지만, 결과를 살피고 다음 행동을 바꾸는 과정은 쉽게 놓친다고 느꼈습니다.

일을 하다 보면 실패는 생깁니다. 그래서 중요한 것은 실패를 모두 피하는 것이 아니라, 작게 실행하고 결과에서 배워 더 나은 선택으로 이동하는 일입니다.

조직이 커질수록 한 번의 결정 비용이 커지고 피드백을 받는 속도도 느려집니다. 프로젝트가 어려워진 이유를 충분히 배우기 전에 다음 결정으로 넘어갈 수도 있습니다.

그래서 가능한 한 작고, 서로 잘 협력할 수 있는 단위로 일하는 것이 중요하다고 생각했습니다. 작은 팀은 중요한 신호를 빨리 확인하고, 배운 것을 다음 실행에 반영하기 쉽습니다.

학습하는 조직은 실패에서 지식을 남기는 조직입니다. 그 지식이 같은 실수를 줄이고 다음 실행의 출발점을 높입니다.

비즈니스는 가치를 주는 일

비즈니스는 단순히 돈을 버는 일만은 아니라고 생각합니다.

가장 중요한 질문은 “사람들이 필요로 하는 가치를 제공하는가” 입니다.

좋은 회사는 소수만 누리던 가치를 더 많은 사람이 쓸 수 있게 만듭니다. 생산 방식을 바꾸어 가격을 낮추거나, 기술로 접근하기 쉽게 만들기도 합니다.

충분한 가치를 제공하면 수익은 그 결과로 따라온다고 생각합니다. 그래서 “어떻게 이익을 얻을까”보다 “어떻게 더 큰 가치를 줄 수 있을까”를 먼저 묻고 싶습니다.

회사에서 팀으로 일하는 개발자도 같습니다. 동료와 사용자에게 어떤 편의와 가치를 더 줄 수 있을지 계속 고민해야 합니다.

다음 목표

2024년의 배움을 바탕으로 두 가지에 집중하려 합니다.

1. 비즈니스를 직접 경험하기

   기술과 비즈니스를 따로 보지 않고, 사용자의 문제를 더 잘 해결하는 선택을 제안하는 개발자로 성장하고 싶습니다.

2. 사람에게 실제 가치를 주는 제품에 기여하기

   기술적인 성취에서 끝나지 않고, 더 많은 사람의 문제를 줄이는 제품과 서비스를 만들고 싶습니다.

마무리하며

2024년은 제 개인적, 직업적 철학을 다지는 한 해였습니다.

가장 크게 남은 문장은 이것입니다.

“돈을 쫓기보다, 어떤 가치를 줄 수 있는지 생각하라.”

무엇을 받을지보다 무엇을 줄 수 있을지 먼저 생각하는 것.

개발자로서, 그리고 동료로서 오래 가져가고 싶은 마음가짐입니다.