하루를 마무리 하기 전, 오늘 있었던 일들을 잔잔히 되짚어봅니다.
성공과 실패의 모든 요소에서 '배울 점'을 찾아내어 기록하고,
더 성장하는 내일의 나를 위해 'action plan'을 세웁니다.
오늘 TIL에 기술 스택 조사에 대한 내용을 좀 정리하면 좋았을텐데ㅎㅎ
사실 나만의 논리를 만들지는 못했고 또 노아님과 이야기하면서 서비스 범위에 대한 조정이 발생할 것 같아 스크럼 책 1~2장을 읽은 내용에 대해 간략히 정리해본다.
이미지 출처: https://www.nachhilfe-team.net/studitipps/scrum/
스크럼 책에서 가장 인상깊었던 점을 2가지 꼽으라면 아래와 같다.
(1) 한마디로 정의하기
(2) 시스템 개발 산업의 특성으로 인한 '경험주의적 공정 제어 모델'의 유효성
사실 직장생활을 하다 보면 대표를 포함한 상사가 '좋은 방법론'에 대해서 이야기하고 또 이를 조직에 적용하기 위해 여러 노력을 하는 상황을 맞닥뜨리곤 한다.
나 역시 다녔었던 회사마다 적어도 한 번 이상씩 그런 일들이 발생했었던 것 같고 실제 조직원으로서 새로운 방법론을 받아들이기 위한 워크샵에 참여하기도 했다.
하지만 모-두가 다 알고 있듯이 새로운 방법론(그것이 인사나 경영과 관련된 것이건, 또는 사업과 직접적으로 연관된 것이건)을 조직에 설파한다고 하여 모든 방법론이 성공적으로 이식되는 것도 아니고 모든 조직이 성공적으로 변화하는 것 또한 아니다.
만약 이러한 방법론이 모든 조직에 다 유효했다면 우리가 속한 조직들은 성공궤도를 달리며 역동적이고 소위 '다닐 맛 나는 회사'로서 위상을 단디 잡고 있어야 한다.
하지만... '한마디로 정의하기', 그리고 '경험주의적 공정 제어 모델'의 유효성이 마음에 남은 이유 역시 내가 속해있었던 조직에서 경험했던 해프닝(?)들 때문이 아닐까? ㅎㅎ
물론 지금까지 다녔던 회사들이 다행스럽게도 나에겐 '다닐만 한 곳'들이긴 했지만, 그럼에도 불구하고 '새로운 방법론들이 성공적으로 이식되었고, 그로 인해 조직이 변화하였는가?' 라고 자문했을 때 '안타깝게도 그렇지 않았다'는 답이 떠올랐다.
그런 의미에서 오늘 스크럼 책의 초반부밖에 읽지 않았는데 '왜 우리 조직이 여러 좋은 방법론을 가져오고 또 조직을 변화시키기 위해 차용하려 했음에도 불구하고 실패할 수 밖에 없었는지'에 대한 실마리를 발견한 것 같아서 신기했다.
하나. 스크럼을 한 마디로 정의하면?
피드백을 좀 더 일찍, 좀 더 자주, 좀 더 많이, 좀 더 지속적으로 주고받기
둘. 경험주의적 공정 제어 모델
불완전하게 정의되어 예상 못한 결과를 만들어내는 프로세스를 빈번하게 검사, 적응하는 방식을 통해 프로젝트를 제어
빈번하고 직접적인 테스트, 즉각적인 수정을 요하는 업무에 적합
시스템 개발 산업이라는 도메인에 처음 발을 들인 나로서는 '애자일'이라는 개념 조차 굉장히 생소하고 또 적응하기 힘든 것 중에 하나였다.
모든 컨설팅 산업이 '워터폴' 방식을 차용하지는 않겠으나 어찌되었건 내가 몸담았던 컨설팅 회사에서는 철저하게 계획적이고 해당 일정과 사전 계획을 따라가서 용역을 납품하는 업무 프로세스가 진행되었기에 나 역시 근 3년 가까운 시간 동안 워터폴에 익숙해져있을 수 밖에 없었다.
그 회사 대표님이 한 때 강력하게 주장하고 또 조직에 이식시키려고 했던 문화가 바로 도요타의 린 생산 방식이었다.
벌써 7년 가까이 지난 이야기이기에 어렴풋하게나마 기억나지만 조직원들의 반발이 굉장했던 것으로 기억한다.
그 반발은 사실 억지스러운 것도 아니었고 굉장히 설득력있고 또 논리적이었기 때문에 무엇이 옳고 그르다를 신입인 나로서는 판단할 수도 없었고 그저 상황이 흘러가는 대로 몸을 맡길 수밖에 없는 (;;) 그런 위치에서 팽팽한 기싸움(?)을 목격하고 있었다.
물론 그 방식 자체가 틀린 것도 아니고 나쁜 것도 아니었으나, 조직에 적합했는지는 아직도 의문이긴 하다.
그 때는 생각하지 못했으나, 오늘 스크럼 책을 읽으면서 상황을 반추해보니 각 도메인의 특성에 따라 적합한 공정 방식이 분명하게 존재한다는 점을 깨달았다.
아직 나는 시스템 개발 산업이라는 분야에 대한 이해도가 높지는 않다. 하지만 메가테라 과정을 통해 개발 영역을 알아가다 보니 개발 프로세스가 반복된다고 하여 모든 결과물이 틀에 찍은 듯이 동일하지 않다는 점에 대해선 분명하게 인식하고 있다.
그러다보니 결과물이 일정 수준 이상 동일하게 산출되어야 하거나, 통제가 가능한 범위에서 과거의 프로젝트 방식이 유효하게 적용될 수 있는 프로젝트라면 워터폴 방식이 유효할 수 있겠으나 시스템 개발 산업은 그렇지 않기 때문에 스크럼 방식이 유효하고 또 적절하다는 점을 알게 되었다.
즉, 어떤 방법이 '좋아서'가 아니라, 해당 산업의 특성으로 인해 '적합도'가 높기 때문에 유효한 것. 우리는 이를 간과한 채 소위 '좋다는 방법'을 여기 저기 차용하고 또 붙이려고 노력하는 것은 아닌지...
단순히 조직의 변화를 위한 영역이 아닌 나의 '학습' 영역에 대해서도 생각해보았다.
나는 구조화된 자료나 정해져 있는 분량의 학습자료가 없는 상태에서 공부하는 것을 어려워하는 사람이라는 것을 메가테라 과정에 참여하면서 새롭게 깨달았다.
개발이 유독 어렵게 느껴지는 이유는 새로운 기술을 급작스럽게 맞닥뜨리게 되고, 또 정해져있는 범위나 구조화된 자료가 아닌 방대한 양의 자료들 속에서 내게 필요한 영역을 선별해서 공부해야 하기 때문이다.
물론 다른 공부도 크게 다를바가 없긴 하겠지만, 적어도 직전 회사에서 장관 고시나 법령에 따른 사업을 기획할 때에는 주어진 범위나 틀이 분명했기에 그런 점에서 차이점이 있는 것 같다.
오늘 포트폴리오 관련 기술 스택을 조사하면서도 범위와 종류가 모호하다고 느껴졌기에 유의미한 산출물이 나오지 않았다고 생각한다.
이럴 때일수록 우선은 내가 통제 가능한 범위를 정하고 종류를 한정하여 조사를 한 뒤에 스크럼에서 말하는 빠른 피드백을 통해 범위나 종류를 조정하는 것이 필요하겠다.
오늘 남은 시간은 '백엔드'와 관련된 기술 중 Spring이라는 종류에 한정지어 자료를 조사하고 연관된 키워드가 있으면 해당 키워드를 리스트업 하려 한다.
할 수 있는 것 부터 빠르게 하는 것 역시 스크럼의 특징 중 하나이기에...ㅎㅎ
오늘 책에서 읽은 내용들을 머리로만 이해하지 말고 지금 이 순간 내가 하는 일에 적용하자.
수고했다 샨티!
