소프트웨어 디자인 개선을 위한 비대면 협업
실전 시스템 수준 리팩토링 사례 6회
데이터 쓰임새 관찰과 표기 이후에 데이터 쓰임새에 대해 파악한 내용을 관련 개발자와 함께 소통했습니다. 대면소통 이전에 한 가지 원칙이 있었는데 오늘은 이를 다뤄보겠습니다.
효과적인 회의를 준비하는 과정에서 배운 협업
요즘 코로나 국면으로 '비대면' 이라는 표현을 자주 쓰지만, '비대면' 자체가 중요한 것은 아닙니다. 실제로 이 글에서 다루려는 협업 방식은 코로나 이전인 2018년 중국에서 일할 때도 효과를 톡톡히 봐서 popit 글로 남긴 이력이 있습니다. 다만, 당시에는 중점이 개인취향을 인정한 협업이나 협업도구로 개발조직의 협업 문화 부분에 있었습니다.
돌아보니 사실 이러한 협업 방법을 고안해낼 수 있었던 것은 오랜 컨설턴트 기간에 대규모 조직에서 늘상 행하던 회의 경험인 듯 합니다. 컨설턴트 다시 말해 '을'이었던 저는 IT관련 의사결정을 내릴 때, 항상 '고객사' 주요 이해관계자와 함께 결정을 내려야 했습니다. 보고서와 회의가 필연적인 상황이죠. 당시 제 눈에는 대부분이 회의에 훈련이 되어 있지 않다는 인상을 받았습니다. 생각해보면, 저보다 나이가 위인 분들은 토론을 배우며 자란 세대가 아니죠. 사회적으로 토론하는 분위기가 만들어진 것은 인터넷 등장 이후가 아닌가 싶기도 합니다.
아무튼 그래서 저는 회의를 철저히 준비했습니다. 제가 참석하는 회의는 항상 아젠더가 있고, 참여자도 결정권을 갖는 동시에 회의 중에 초점을 잃지 않기 위해 제가 진행자 역할을 자임했습니다. 그러면서 의사 결정 이전에 쟁점에 대해 소통하고 갈등을 드러내는 것이 얼마나 중요한지 몸으로 배우는 시기가 컨설턴트 커리어 내내 있었습니다.
협업 시스템으로 정보를 수집하고 쟁점을 찾기
쟁점에 대해 소통하고 갈등을 드러내는 일은 어쩌면 문제 정의라고 부를 수도 있을 듯 합니다. 소프트웨어 공학에서는 문제 정의를 요구사항 수집이라고 부르기도 합니다. 외주개발관행이 드러가 있는 낡은 표현이 아닐 수가 없습니다. 그래서 저는 문제 정의가 확장성 있는 표현이라 생각합니다. 물론, 현장에서는 문제 정의라는 말보다 더 구체적이고 친숙한 표현을 쓰셔야겠지만, 뭐라고 부르든 쟁점을 통해 갈등을 드러내는 일은 매우 중요합니다.
이 과정에서 필연적으로 개인의 작업이 필요합니다. 누군가는 정보를 수집하고, 분석하고, 가정을 세우고 쟁점을 드러내야 회의에 알맹이가 있겠죠. 저는 2017년 dooray라는 도구를 소개 받았을 때, 협업을 점차 퍼뜨리기 좋은 수단이라고 생각했습니다. JIRA, Trello 같은 기존 도구와 비슷한 듯 하면서도 메일 UI와 같아 대부분의 사무직 종사자라면 거부감이 적을 것이라는 생각에서 였습니다.
그렇게 5년 정도 직업 일상에 써오면서 자연스럽게 묻어난 협업 방식이 실전 시스템 수준 리팩토링 시리즈 배경에 깔려 있습니다. 2회에서 클래스도를 그리기 전에 테이블을 찾을 때, 바로 협업 시스템에서 해당 테이블을 접근 방법을 알고 있는 개발자와 소통하여 데이터를 보기 시작했습니다. 3회의 프론트 개발자의 피드백은 바로 그 협업 시스템에서 대화한 기록이구요. 4회의 화면 이미지 또한 개발자가 협업 시스템에 붙여준 내용을 기반으로 했죠. 5회에도 보면 개발자와 같은 단어에 대해 다른 인식을 갖고 있는 현실을 확인하는 과정이 있는데, 이때도 기록이 자연스럽게 남는 협업 시스템의 효과는 뛰어납니다.
비대면으로 소프트웨어 디자인 대화하기
다시 비대면이라는 표현을 꺼내겠습니다. 요즘 코로나 일상에서 그 단어가 주는 느낌이 유효할 수 있다 생각합니다. 앞선 예에서 제가 의사소통을 통해 얻은 정보나 깨달음을 대면 소통을 통해 얻을 수도 있습니다. 다만, 지식 노동이 대부분이기 때문에 차분히 앉아서 생각하고 기록하는 편이 유리합니다. 그러나가 간혹 누군가에게 물어서 빨리 찾을 수 있는 정보를 발견하면 도움을 청해야 합니다. 우리는 팀이니까요!
예를 들어, 개발을 하지 않은 제가 앱을 돌아다니면서 '이건가? 저건가?' 추정하는 방법보다는 개발자가 자신이 만든 화면을 찾는 것이 훨씬 생산성이 높은 것은 설명할 필요가 없습니다. 거꾸로 제가 의도하는 내용을 온전히 동료나 부하직원에게 맡기면 불필요한 검토와 전달 과정이 뒤따르니 분석 성격의 일은 의도를 가진 사람이 직접하는 것이 좋습니다. 이렇게 개별 작업을 몰입을 하고, 질문은 쉽게 할 수 있어야 한다고 전제하면 SNS의 멘션을 활용하여 특정인에게 아무때나 답해줘도 되는 질문을 올리는 이른바 '비동기 소통'은 동료의 작업 흐름을 방해하지 않는 장점이 또 있습니다. 저에게는 이미 습관으로 자리 잡힌 방법이라 부지불식간에 드러나기도 하겠지만, 여러분에게 알리고 싶은 의도도 있어서 실전 시스템 수준 리팩토링 시리즈 과정에서 지속적으로 비대면으로 소프트웨어 디자인 개선에 대해 대화하는 내용이 포함되었고, 앞으로도 포함될 것입니다.
지금까지 개괄적인 설명을 했고, 아래는 협업 시스템 활용을 전제한 후에, 소프트웨어 디자인 개선 관련해서 앞선 연재 과정에서 유효했다고 느낀 비동기 소통하는 노하우를 몇 가지 공유합니다.
비슷한 내용은 병기해서 표현하기
비대면 소통은 서로 눈빛을 보면서 '내 말을 듣고 있나' 파악하는 감지능력과 비언어적 수단을 써서 신호(지루하다, 못 알아 들었다 등)를 보내는 역량을 제거한 소통입니다. 마차 차와 포를 떼고 장기를 두는 것처럼 전달력이 떨어지죠.
그래서, 맥락을 정교하게 표현하기 위한 노력을 들일수록 효과가 높습니다. 그중 하나는 함께 봐야 하는 요소를 붙여두는 것입니다. 두레이 편집 화면에서는 표를 이용했더니 두 개의 이미지를 병렬해서 볼 수 있네요. 화면 이미지와 클래스도를 나란히 두면서 어떤 화면에서 어떤 데이터가 쓰이는지 표시했습니다.
색깔을 바꿔서 데이터 중복 사용이나 충돌을 기대하며, 화면과 클래스도를 병기했습니다. 그러다가, '모든 화면에 대해 다 해봐야 하나?'는 생각이 들 때 즈음 이제 되었다는 감이 왔습니다.
개선의 여지가 분명해 보이는 것들이 작업 와중에 느껴졌습니다. 쭉 훑어보는 것의 효과는 증명하기 어렵지만, 꽤 매력적인 방법이란 생각이 듭니다.
피드백을 위해 대화 이어가기
비대면이고 비동기이더라도 댓글을 드문 경향이 있습니다. 그래서, 당장 내가 집중하는 내용이 아니더라도 댓글에는 빠르게 회신을 해서 피드백을 촉진할 수 있습니다. 피드백이 만들어내는 촉진 효과는 마치 축구에서 티키타카를 하는 듯한 속도감과 신나는 기분을 만들어 주기도 합니다.
댓글 시간을 보니 서로 다른 라이프스타일이 엿보이기도 합니다.
데이터 쓰임새 관점에서 개선이 필요한 항목 도출하기
다시 돌아가서 제가 쭉 작업을 하다가 '이제 되었다'라고 완료 시점을 알게 된 것은 바로 데이터 쓰임새 개선을 위한 항목을 보여 이를 기록했을 때입니다.
이렇게 기록해두는 방식을 백로깅(backlogging)이라고 부르기도 합니다. 일단 필요한 작업을 기록(log)해두고, 적절한 작업 주기(sprint 등)에 일을 시작하기 위함이죠. 비즈니스 우선순위 혹은 개발팀의 우선순위를 조정하기 위해 실행 전에 일단 기록하고 공유하는 것이 백로그의 가치입니다.
하지만, 이 경우는 소프트웨어 디자인 프로젝트 백로그인데, 이 시리즈의 동기가 된 시스템 수준 리팩토링 프로젝트 작업 항목으로 기록해두는 것입니다. 언제 이것을 하게 될지는 팀이 모여서 리팩토링 목표와 진도를 정할 때 결정합니다.
