첫 출근

애자일을 시작한 계기

첫 출근 날이었다.

모든 것이 새롭고, 설렘과 긴장감이 동시에 느껴지는 하루였다. 회사 분위기는 그동안 경험했던 일본의 전통적인 회사들과는 사뭇 달랐다. 좀 더 자유롭고 유연한 느낌이 강했다. 외국계 기업이라 다양한 국적의 사람들이 함께 일하면서 각국의 문화가 섞여 있었기에, 그만큼 자유로운 분위기가 형성된 것 같았다. 처음엔 적응이 안 되었지만, 그런 다양성이 오히려 매력적으로 다가왔다.

내 포지션은 백엔드 엔지니어로, 레벨은 중간 정도로 입사하게 되었다. 나를 이끌 매니저는 인도인이었고, 그는 소니에서 20년 이상 근무한 베테랑이었다. (그가 일했던 소니의 플레이스테이션 팀 얘기를 들을 때마다 괜히 설렜다.) 함께 일하는 동료들은 일본인, 영국인, 한국인, 러시아인 등 국적과 문화가 다양한 사람들이었다. 이곳에서 새로운 배움을 얻고 싶다는 기대감이 가득했다.

첫 업무는 버그 수정이었다. 시스템을 이해하려면 우선 버그부터 고치는 게 좋다고 해서 맡겨진 작업이었다. 사실 버그 수정은 간단했지만, 시스템 전반을 파악하는 것이 더 큰 과제였다. 시스템은 마이크로서비스 아키텍처로 구성되어 있었고, 이 구조를 처음 접하는 나로서는 분석하는 데 어려움이 있었다. 각 서비스가 어떻게 연결되어 있고, 어떤 식으로 데이터를 주고받는지 파악하는 데 꽤 애를 먹었던 기억이 난다. 버그를 수정하면서 서비스 간의 연결 고리를 찾고, 시스템이 어떻게 구성되어 있는지, 각 모듈이 어떻게 상호작용하는지를 조금씩 이해해 나갔다.

그러던 중 첫 번째 큰 과제를 받았다. REST API에 새로운 기능을 추가하는 일이었다. 기간은 2주로 주어졌고, 기능 구현 외에도 기본 설계서와 상세 설계서 작성, 해결 방안 도출, 영향도 분석 및 최종 리뷰까지 모두 완료해야 했다. 이를 위해 기본 설계서를 작성해서 보고를 올렸는데, 뜻밖의 문제가 발생했다.

당시 회사의 CTO는 마이크로소프트 출신 엔지니어였고, 회사의 모든 시스템은 마이크로소프트 스타일을 따라가고 있었다. 그런데 CTO가 내게 “이건 요청한 적이 없는데 왜 했냐?”라고 물었다. 나는 순간 당황했고, 매니저를 바라보며 “제가 받은 업무 요청은 이거였습니다”라고 되물었다. CTO와 매니저 간 대화를 듣고 보니, CTO는 이 업무를 위해 필요한 자료와 요구사항을 매니저에게 전달했지만, 그 자료가 나에게 전달되지 않은 것이었다. 나는 제대로 된 정보 없이 전혀 다른 방향으로 해결 방안을 제시한 꼴이 된 셈이었다.

결국 CTO와 직접 대화를 하면서 필요한 설명을 다시 듣고 업무를 시작하게 되었다. 하지만 기간 연장은 없었다. 엄격하기로 소문난 CTO의 성격은 결코 소문에 그치지 않았다. 그렇게 다시 작업을 시작하면서도 나는 일본의 직장 문화와 업무 스타일에 대해 많이 배우게 되었다.

업무는 마이크로소프트식 애자일 방식을 따르고 있었지만, 완벽한 애자일은 아니었다. 회사 내에서 각 포지션 별로 불만들이 존재했다. 대표는 개발 속도가 느리다는 점을 지적했고, CTO는 업무 진행 상황을 제대로 파악하기 어렵고 버그가 많다는 불만을 가졌다. 반면, 엔지니어들은 업무량이 너무 많아 힘들다고 토로했다. 특히 회사 솔루션의 버그는 좀처럼 해결되지 않았고, 버그 목록은 Redmine 시스템에 수백 개나 기록되어 있었다. 말 그대로, 끝이 보이지 않는 숫자였다.

이런 상황에서 새로운 기능이 계속 추가되고 있었고, 기존의 안정성과 지속 가능한 가치를 동시에 제공해야 하는 상황에서 리스크는 점점 커졌다. 혼란스럽고 복잡한 상황이었지만, 어떻게든 적응하려 애썼다.

입사 후 4~5개월쯤 지나자, 나는 진지하게 퇴사를 고민하기 시작했다. 가장 큰 문제는 나의 매니저였다. 매니저의 업무 이해도가 너무 낮았고, 매니저가 회의에서 파악하지 못한 내용을 나에게 따로 설명을 요구하는 경우가 많았다. 회의 시간이 두 배로 늘어나면서 정작 실질적인 업무를 할 시간이 줄어들었고, 요청한 정보가 제대로 전달되지 않아 업무에 차질을 빚는 일이 많았다. 이런 상황이 반복되면서 나는 지칠 수밖에 없었다.

결국 나는 바로 위의 매니저가 아닌, 다른 개발 리더에게 면담을 요청했다. 그리고 내가 느끼는 불만과 함께 퇴사하고 싶다는 의사를 전달했다. 개발 리더는 이 문제를 곧바로 CTO에게 보고했고, 결과적으로 매니저는 다른 팀으로 발령되었고 나는 매니저 역할을 겸하게 되었다. 내가 더 잘할 수 있을 것 같다는 의견을 피력한 덕분이기도 했지만, 상황이 이렇게 될 줄은 몰랐다.

그렇게 나는 팀의 업무를 관리하면서 개발도 병행하게 되었다. 말 그대로 업무량이 두 배로 늘어난 셈이었다. 하지만 그때 나는 별다른 불만이 없었다. 한국에서 일할 때는 야근 수당을 받아본 적이 없었지만, 일본에서는 분 단위로 야근비를 제공했기 때문이다. 한 달에 300시간이 넘는 시간을 일하며 피곤하기는 했지만, 가난했던 유학생 시절을 생각하면 돈을 더 벌 수 있다는 점에 만족했다.

하지만 내가 매니저가 되었다고 해서 회사의 문제가 단번에 해결된 것은 아니었다. 각 이해관계자들의 불만은 여전히 남아 있었고, 개발 속도도 크게 나아지지 않았다. 사실 개발 속도를 측정하는 것 자체가 애매한 일이었다. 업무의 난이도나 기능의 복잡성이 모두 다르기 때문에, 단순히 코드 양이나 기능 개수로 평가할 수 있는 게 아니었다.

그러던 어느 날, 회사에 다닌 지 6개월 차에 접어들었을 때, CTO가 나에게 물었다. “스크럼 들어본 적 있어?”

그 한마디가 내 인생의 2막을 여는 시작이었다.

스크럼이라는 말을 듣자마자 머릿속에 새로운 개념들이 떠올랐다. 그동안 개발 속도를 높이려면 어떻게 해야 할지 고민했던 문제에 대한 답이 될 수도 있겠다는 생각이 들었다. 그동안의 업무 방식은 효율적이지 않았고, 각자 불만만 가득한 상태였다. 스크럼은 팀의 협업을 개선하고, 투명한 업무 진행을 가능하게 할 방법이었다.

그 후 CTO와의 긴 대화 끝에 우리는 스크럼 도입을 시도해 보기로 결정했다. 모든 것이 순조로울 것이라고 생각하지는 않았다. 새로운 방식으로 일을 진행하는 데는 도전이 필요했고, 팀원들 역시 새로운 시스템에 적응해야 했다. 하지만 회사의 현재 상황에서는 변화를 시도해 볼 가치가 충분하다고 생각했다.

스크럼을 도입하는 과정은 쉽지 않았지만, 그 도전 속에서 나는 또 다른 배움과 성장을 경험하게 되었다. 그리고 그것이 내가 그토록 바라던 자유롭고 효율적인 업무 환경을 만드는 첫걸음이 되었다.