품질과 일정 사이에서
냉정과 열정 사이
고민의 시작
큰 조직을 리딩할 때 일정은 대부분 팀장님들이나 구성원들이 잘 지켜줬었던 것 같다. 그래서 그때는 품질에 대한 이야기만 주야장천 했었던 것 같다. 또, 업무 지식이 담당자에 비해 많이 부족한데 다양한 업무 영역에 대해서 공유를 받다 보니 일반적인 개선안에 대해서만 많이 언급했던 것 같다(이러한 언급으로는 명명규칙, 메서드 추출, SOLID, 가독성 등이 있다).
지금은 그때에 비하면 매우 작은 조직을 맡고 있다. 이 조직에서는 더 이상 회의만 하는 역할이 아니고 종종 실제로 내가 쿼리, 코드 등을 작성하고 배포도 해야 한다. 이 작은 조직에서도 2가지 중요한 장기 과제가 진행 중이다. 하나는 물류관리(WMS Warehouse Management System)이고, 다른 하나는 이커머스의 상품구조 개선을 위한 과제이다. 이 외도 운영성 업무, 데이터 추출(ODS, DW, Lake)을 하는 일도 진행 중이다. 작년에는 이벤트 부하 대응, 오류 수정, 운영 요청 처리에 집중할 수밖에 없어서 주요한 2개에 과제에 대해서 많은 관심을 가지고 함께 하지 못했다. 이제 주요한 2개의 과제는 이제 오픈을 앞두고 있다. 이런 상황에서 이 과제들에 대해서 의견을 주다 최근에 느낀 점에 대해서 글을 써 보려고 한다.
왜 품질에 집중하는 것으로 시작했나?
지금 재직 중인 케이타운포유(https://kr.ktown4u.com/)에 22년 6월 합류하기 전에 15년가량 된 커머스 시스템을 운영하는 조직에서 5년 가까이 일을 했다. 그러다 보니 다양한 버그를 봤고, 새로운 기능 추가 시 생각보다 많은 리소스가 소요되는 것을 경험했고, 수정을 할 때 예기치 않은 곳에서 영향을 받아 오류나 장애로 이어지는 것을 경험했다. 기술부채가 적절하게 관리되지 않으면 초반에는 경쟁력이 있을지 몰라도 후에는 변경 비용 증가로 경쟁력이 떨어지는 것을 경험한 것이었다(좋은 설계/품질의 주요한 이점은 향후 변경 비용 감소이다).
그럴 즈음 "프로젝트에서 제품으로"라는 책을 작년 3,4월 정도에 봤다. 이 책에 다양한 이야기가 있지만 초반의 내용은 내게 아래와 같이 이해되었다.
사업 초기에는 무엇보다 빠르게 기능을 추가하는 것이 중요하다. 그렇지 않으면 경쟁에서 진다.
이러다 보면 기술부채가 누적됨(당장의 속도를 위해 품질 개선을 하지 않아 생기는...)
여기서 기술부채가 관리되지 않으면 위기 상황이 생길 수 있다(개인정보 누출 사고, 점진적인 생산성 저하 등)
끝까지 기술부채를 관리하지 못한다면 파산하게 된다.
여기서 어려운 점이 기술부채를 인식하고 바로 제거를 할 것인지? 당장의 사업 성장을 위해서 부채를 더 질지에 대한 결정이라고 생각한다. 우리만 사업을 하는 게 아니라 경쟁자가 있기 때문에 속도를 무시할 수 없다.
위 그림은 마틴 파울러가 설명한 설계체력가설(Design Stamina Hypothsis)에 약간의 주석을 추가한 것이다.
설계수익선(design payoff line) 이전에는 파란색(좋은 설계가 없이 구현 경우)이 주황색(좋은 설계를 갖는 구현)에 비해 생산성(누적 기능 cumulative functionality)이 높다. 하지만 설계수익선을 지나면 좋은 설계가 없는 경우는 생산성이 급격하게 줄고, 좋은 설계를 가진 경우는 생산성이 지속적으로 유지되는 것을 볼 수 있다.
따라서 적절한 때(설계수익선 이전) 부채를 상환하지 않으면 어려움을 겪게 된다는 것이다. 이 이론에 내 경험을 더해서 나는 좋은 설계의 중요성을 여러 차례 발표했었다. 그리고 케이타운포유에 합류한 이후에도 이 점을 강조했다. 그래서 짝프로그래밍, 코드리뷰, TDD, 리팩터링 등의 중요성에 대해서 구성원들에게 강조했고, 이를 위한 스터디, 세미나 등을 진행해 왔다. 앞으로도 계속할 예정이고...
지금은 어떤가?
나는 1~2년 전 설계체력가설 그래프에 너무 크게 공감을 했었다. 그런데 지금 와서 생각해 보니 한 가지 문제가 있다.
지속 가능한 생산성을 보이는 좋은 설계를 우리가 만들 수 있는 역량이 되는가를 감안해야 한다
는 것이다. 충분한 역량이 없거나 과도한 품질을 한 번에 이루려면 일정이 너무 늘어지고, 결과물 또한 원하는 수준에 못 미친다고 느껴지기 시작했다.
이런 생각에 도달하게 된 것을 최근에 내가 이런저런 발표나 인터뷰에서 많이 사용하는 은유를 통해 정리해 보겠다.
"자전거 배우기"
"자전거 배우기"는 어떻게 하면 코드리뷰, TDD 등을 잘할 수 있냐는 질문에 답을 하며 사용하기 시작했다(내가 생각해 낸 은유가 아니라 나도 어디서 보거나 들은 것 같다).
구글에서 "자전가 배우기"를 입력하면 나오는 이미지 중에 하나다. 자전거를 배울 때 우리는 책을 완독하고 자전거를 타기 시작하지 않는다. 약간의 설명을 부모님에게 듣고, 뒤에서 부모님이 잡아주면서 넘어질까 두려워하며 배운다. 다들 경험했겠지만 "아빠 절대 놓으면 안 돼"라고 부탁을 하고, 또 아버지는 "알았어 절대 놓지 않을게"라고 답을 한다. 근데 현실은 아이가 잘 타는 것 같고 위험한 상황이 아니면 아버지는 살짝 손을 놓는다. 그러다 아이는 자기 혼자 타고 있는 것을 발견하고 그 후에 혼자 자전거를 타게 된다. 이제 내가 말하는 "자전가 배우기" 은유이다. 즉 새로운 기술을 배울 때 책을 정독하고 시작하기보다 조금씩 할 수 있는 만큼 실천하며 배우는 것을 시작하자라는 것이다. 그러다 엔간히 하는데 더 잘하고 싶으면 책을 정독하며 더 깊이 배울 수 있다는 것이다. 이 은유를 TDD, 리팩터링, 코드리뷰 등을 어렵게 생각하는 분들에게 쉽게 시작하시길 바라는 마음에 말씀드리곤 했다.
한 가지 첨언하자면
"배우는 기술이 어렵다면 쉬운 문제를 풀면서 기술을 연마해야 하고, 문제가 어렵다면 최대한 쉬운 기술로 어려운 문제에 집중하며 풀어야 한다"
이렇게 "자전거 배우기" 방식으로 역량을 증대하며 업무를 수행하다 보면 어려운 문제가 발생하기도 한다. 품질을 중시하고 역량 증대를 중시하다 보니 일부 구성원들은 잘하기 위해 너무 많은 시간을 사용해서 회사가 원하는 일정을 못 맞추는 경우도 있었다. 설계 원칙, 고객 경험 등을 너무나 중요하게 생각한 나머지 일정을 너무 크게 잡거나 꼭 필요할 시 확신이 없는 일도 필요할지도 모른다는 가정하에 진행하여 일정을 소모하는 것이었다. 애자일 관련 많은 용어 중 나는 YAGNI라는 말을 좋아한다. 필요할 것이라고 예상한 추상화, 성능 최적화, 고도의 고객 경험 등은 실제로는 필요 없을 것이라는 말이다. 딱 "머피의 법칙"과 같다. 우리가 예상한 변경은 실제로 일어나지 않아서 이를 위해 추가한 추상화는 그저 우리 시스템의 복잡도만 증가시켜서 우리가 작업 속도를 더디게만 하는 것이다. 예전에 매우 높은 성능을 요구하는 시스템을 개발하면서 처음부터 캐시를 적용해서 복잡도가 증가해서 애를 먹었던 기억이 있다. 지금 생각해 보면 정말 캐시가 그렇게 많이 필요했었나 싶다. 그저 Redis에서 조회수, 좋아요 수 등을 위한 카운트 캐시만으로 충분했을 것 같다.
우리는 저금을 해야 한다.
좋은 설계, 높은 성능, 최고의 고객 경험. 모두 우리 시스템에 꼭 필요한 중요한 속성이다. 하지만 이를 위해서는 비용이 필요하다. 부채를 질 수도 있다. 아니면 투자를 받을 수도 있다.
어떻게 하면 투자를 받을 수 있을까?
우리 상황에서 투자는 경영진이나 타직군의 지원/후원 정도로 생각할 수 있다. 이를 위해서 우린 먼저 바로 돈을 벌 수 있는 일을 해야 한다. 또 그들의 어려움을 해결해 줘야 한다. 매일 하는 반복적인 업무를 자동화해 준다면 그들이 보다 중요한 일에 노력을 기할 수 있게 되고, 회사는 더 많은 이익을 거둘 수 있을 것이다.
이렇게 조금은 우리 생각에 덜 중요한 일을 해서 저금을 하면(돈을 벌면) 그 돈을 종잣돈으로 더 큰일 할 수 있다. 우리가 벌어야 하는 돈은 매출액, 영업이익만이 아니다. 경영진이나 타직군의 신뢰도 우리가 더 큰 일을 위해 벌 수 있는 투자금이다. 그들에게 신뢰를 얻어야 한다. 적은 자본으로 큰 일을 하기보다 작은 일을 여러 차례 수행하며 경험을 쌓고, 또 신뢰와 자본을 쌓으면 더 큰일 더 잘할 수 있다고 생각한다.
"시험 치르기"
지금까지 제일 중요한 일을 제일 먼저 한 번에 하지 말고, "자전거 배우기"처럼 점진적으로 수행하고, 신뢰와 투자를 쌓자는 이야기를 했다. 이제부터는 이 일을 수행하는 우리가 가져야 할 주의사항 한 가지를 말해 보려 한다.
고교 때 시험을 치르면서 이런 생각을 누구나 한 번은 해 봤을 것이다.
"아... 1시간짜리 시험을 봐서 80점을 받았는데 30분만 더 있었다면 100점을 받았을 텐데"
품질을 강조하면 누구나 잘하려고 시간을 들인다. 그러다 보면 종종 일정을 못 맞추는 경우가 있다. 어떤 게 맞을까? 일정을 못 지키더라도 품질(점수)을 얻어야 할까? 아니면 어떻게 해야 할까?
나는
일정 내에서 얻을 수 있는 것이 내가 얻을 수 있는 품질(점수)
이라고 생각한다. 학교 때 어떤 시험은 오픈북으로 진행한다. 답이 다 들어 있는 책을 보면서 시험을 치를 수 있게 해 준다. 심지어 대학 때 그런 시험은 시간도 매우 넉넉하게 줬었다. 그런데 그 시험에서도 성적 차이가 난다.
내가 만들 수 있는 품질은 시간이 아니라 내 역량에 달려있다. 즉 내 역량이 충분하다면 시간 내에 높은 품질을 만들 수 있다. 만일 정해진 시간에 내가 원하는 품질이 나오지 않아 아쉽다면 더 역량을 쌓아서 다음에는 주어진 시간에 더 잘하도록 노력하는 게 맞아 보인다. 우린 학비를 내고 회사를 다니는 것이 아니라 월급을 받고 회사를 다니기에 더욱 그렇다.
품질이 먼저인가? 일정이 먼저인가?
"실리콘 밸리를 그리다"라는 책을 보면 우선순위를 결정하는 방법에 대한 내용이 있다.
제일 돈을 많이 벌 수 있는 중요한 일이지만 많은 리소스가 들어가는 일
적은 리소스가 들어가지만 적은 돈을 버는 일
중간 규모의 일
이 책에서는 보통 이렇게 나눠질 것이다. 비교적 짧은 시간에 비교적 높은 수익을 낼 수 있는 일들(비용, 리소스를 각각 최대 5라고 하면 각각이 3,4 정도인 것을 먼저 하는)을 먼저 해서 수익을 만들어 더 높은 수익을 낼 수 있는 일을 하는 것이 동일한 기간 동안 가장 큰 수익(5,500)을 낸다는 것을 보여준다. 가장 중요하고 높은 수익을 내는 일(제일 중요한 일)을 제일 먼저 하는 것이 동일한 기간 동안 가장 수익이 낮고(4,500), 가장 빨리 끝낼 수 있는 일의 수익이 그다음(5,000)이었다.
그럼 우리도 초기에 일정을 준수하며 수익(회사에 기여, 경영진/타직군의 신뢰)을 내는 것으로 시작해서 정말 큰 수익을 낼 수 있는 중요한 일을 우리가 얻은 수익을 투자로 활용해서 진행하는 것이 좋을 것 같다.
케이타운포유이 인재 채용
react 기반 프런트엔드 경력 개발자: 채용공고문
ODS, DW, Lake를 활용한 데이터 분석가: 채용공고문
AWS 기반의 DevOps 엔지니어: 채용공고문
그리고 훌륭한 java, spring 기반의 백엔드개발자
를 채용합니다.
관심있는 분들에 제가 메일(msbaek@ktown4u.com)주시면 됩니다.
