개발 팀에 민주적 소통 절차 수립하기
실전 시스템 수준 리팩토링 사례 11회
기부상태 UL로 만들기를 성공하면 무슨 일이 일어날까요? 다르게 표현하면, 기부상태를 가지고 활발한 소통일 벌어지면 무슨 일이 일어날까요? Ubiquitous Language가 생소한 말이죠. 개발자, 기획자, 운영자 등등 서로 다른 배경 지식이나 역할을 가진 사람 가운데서 소통할 수 있는 방법이 Ubiquitous Language입니다.
DB 스키마 개선으로 시작하기
업무 시스템 개발에 익숙한 개발자는 ERD를 기준으로 설계하는데 익숙합니다. 그러한 동료가 비슷비슷한 기능이 상태를 별도로 갖고 있는 부분을 발견하여 개선을 제안합니다. 개선 방식은 여러 가지가 가능하지만, ERD가 익숙한 백엔드 개발자라면 DB 스키마 통합부터 시작하는 일이 자연스럽습니다.
자신의 개선 제안에 많은 동료들이 지지를 보내자 노력을 아끼지 않습니다. 민주적 소통 절차는 분명하게 협업에 탄력과 활기(?)를 불어 넣습니다. 한국 문화를 고려하면 민주적 소통 진행에 있어 꼭 필요한 요소는 디지털 기록입니다. 이때, 지지를 받은 동료는 광장에서 동료들에게 자신의 주장을 관철하기 위해 기록을 남기는 수고를 마다하지 않습니다. 독자분들께 민주적 소통 절차를 인지시켜 드리기 위해 일부러 광장이라는 은유를 사용했습니다. 느껴지시나요? 왜 활기가 필요한지? 공감하시나요? 왜 민주적이라 표현했는지?
UL의 효용성
낯선 UL이란 단어로 글을 시작했으니 UL에 대해 다뤄보겠습니다. 다양한 의견을 갖을 수 있는 민주적 소통에서는 UL이 다양성을 포용하기 위한 수단입니다. 요즘처럼 다기능팀(혹은 마이크로 서비스 조직 혹은 스타트업 서비스 조직)이 흔히 존재하는 상황이라면 더욱 그렇죠.
우리 플랫폼에서 기부는 핵심 비즈니스입니다. 그래서, 개발자가 아닌 사람들도 알아들을 수만 있다면 기부에 대해 말하는 내용에 귀를 기울입니다. 단, 알아들을 수만 있다면 말이죠. 의외로 개발자들은 알아들을 수 없게 말하는 재주(?)가 있습니다. :)
DB 스키마를 앱 사용 상황이나 화면과 엮어서 설명하면, 기획자와 같이 개발자가 아닌 사람들도 이해할 수 있습니다. 암튼, 광장으로 묘사한 우리의 회의에 기획자가 자의에 의해 참석을 했습니다. 평소 동료 개발자와 친밀감을 유지하고, 자주 이야기해서 둘이서 소통이 가능한 상황인 점이 주요하게 작용했으리라 짐작합니다. 기획자는 그 자리를 배우는 자리로 여긴 듯합니다.
민주주의 정치 활동에서 로비가 필요하듯, 사전에 친밀감을 만드는 일도 UL의 한 가지 요소라 할 수 있습니다. 언어는 쓰이지 않으면 효과가 없으니까요. 물론, 동료 개발자가 로비를 했다고 주장하는 것은 아닙니다. 어디까지나 비유입니다. :)
다양한 이해관계 해소의 장
회의록을 보니 그날 나눈 이야기들은 다양한 관저을 포용하고 있었습니다. 기록을 보고 당시 논의를 회상해보니 이력 데이터를 JSON으로 시간과 행위자를 묶어 하나의 필드에 저장하자는 내용이 기억납니다. DDD 값 객체(Value Object)에 대응하는 내용이죠. (개발자 아닌 분들 죄송합니다.) 요즘 RDB들은 JSON 타입 자체를 지원해서 좋습니다.
그리고, ORM 사용시 주의점을 기술이 뛰어난 동료가 설명한 내용도 기억납니다. 그리고, 주니어 개발자가 많은 개발팀 특성에 따라 자동생성하는 식별자가 아니라 사람들이 사용할 식별 번호 혹은 자연키 같은 기본 개념을 논의한 내용도 보입니다. 비슷한 내용이 마스터(원장) 레코드와 거래 레코드라는 전통적인 레코드 분류에 대한 설명도 기록에 남았네요.
비대면 협업 상황에서 디지털로 UL 구현하기
회의 결과로 DB 스키마 업데이트가 발생했습니다. 해당 스키마로 한 차례 더 검토 회의가 있었습니다. 실제로는 한 사람의 동료가 주도한 DB 스키마이지만, 이렇게 민주적 절차로 소통하고 개선을 반영한 내용은 기획자도 관심을 갖습니다. 그래서, 스카마 파일 형태를 개발자 도구에서 읽을 수 있는 타입과 동시에 이미지로 변환되어 두레이 프로젝트 대쉬보드에 올라갑니다. :)
