개발일지 1. 모듈 간 데이터 전송
모듈 간 독립성 유지를 위한 컴파일 타임 다형성의 응용
2020. 10. 07.
언제 쓰기 시작했는지 기억이 나지 않는 오래된 글이다. 개발 일지를 새로 하나 쓰고 싶은 기분이 들어 글을 써보려는데 임시 저장된 글이 있어 확인해보니 개발일지 5번인 게 아닌가. 문득 서랍을 열어보니 이 발행되지도 못한 글이 나타났다. 언젠가 마무리는 지었던 것 같은데 결국 올리진 않았었구나. 아쉽기도 하니 마지막으로 한 번만 훑어보고 올리고선 새 글을 쓰러 간다.
그렇다고 갑자기 6번 글을 내놓을 순 없으니 찬찬히 묵혀뒀던 다른 글도 시간 날 때 살펴보고 올릴까 싶다. 떡국 좀 더 먹은 내가 지나갔던 나를 덧씌워 없애지 않도록 가급적 그대로 올리긴 하겠지만, 신경을 아예 끌 순 없어 조금씩 고치기도 할 것 같다. 이래서야 언제 쯤 오늘 쓰기 시작할 글이 올라갈지는 잘 모르겠네.
2016. 12. XX.
기왕 브런치를 쓰기로 한 거 옛날 얘기만 쓸 게 아니라 현재 개발하면서 겪게 된 경험 같은 것들을 기록으로 남겨도 좋을 것 같다는 생각이 들어 개발일지를 쓰려고 한다. 물론, 코드를 쓰거나 하는 것은 당연하게도 여러 블로그 서비스들이 훨씬 더 좋은 점들이 많기 때문에 여기서 그렇게 구체적인 내용을 다룰 생각은 없고, 다만 겪어가는 과정에서 발생하는 일들을 일기처럼 남기는 게 좋을 것 같다. 개발도 결국 사람이 하는 일이고 세상 일은 다 비슷비슷하게 돌아갈 테니 지금 내가 겪는 일들을 앞으로도 겪을 가능성이 없잖아 있겠지. 사실 오늘 쓰려는 내용도 이미 내가 많은 친구들, 선후배들과 만나고 같이 '코딩 생활'을 해보면서 많이 겪어봤던 일들의 답습에 대한 내용이다.
제목과 부제는 일지에서 서술하려는 어떤 경험을 얻게 된 계기 그 자체를 쓸 것이다. 글의 내용으로는 그것들을 구현하는 과정에서 내가 얻은 경험들, 예를 들면, 내가 동료들과 협업하면서 어떤 구현이 왜 필요한지에 대해 주장한 방식이나 그를 납득시키고 관철하게 됐거나 그 반대의 사례들이 주를 이룰 것 같다. 커버에 걸릴 사진은 브런치에 올라오든 글들의 특성 상 '태'가 중요한데, 관련된 코드의 일부를 대충 가져와서 붙이는 정도라도 해두면 좀 있어 보이겠지 싶다.
본론에서 얘기를 풀어나가는 데에 필요하다면 테크니컬한 부분에 대해서도 기술하긴 하겠지만, 딱히 특정한 내용에 대해서 깊이 있게 쓰고 싶은 생각은 없다. 그런 부분은 내가 굳이 할 필요 없이 구글에 검색만 해보더라도 내용이 많이 나오기도 할 뿐더러 내가 해야겠다 생각이 들면 그건 아마 블로그에 따로 정리해서 쓰지 않을까 싶기도 하고. 그래도 정 쓰고 싶으면 개발일지보단 다른 제목을 달고 쓰지 않을까 싶다. 그럼, 개발일지에 대한 소개는 이쯤 하고 이번 글의 본론으로 들어가자.
요즘은 진행 중인 프로젝트 코드를 다시금 리팩토링하는 중이다. 진행 중인 프로젝트라는 것은 석사 생활을 시작하면서 메인 업무로써 할당된 프로젝트인데, 3학기를 마친 지금까지도 계속 잡고 있으니 여태까지 작업해온 것들 중 가장 길게 잡고 있는 프로젝트인 셈이다. 이 프로젝트는 불과 6개월 전, 내가 대대적으로 리팩토링이란 칼을 꺼내들기 전까진 C++의 탈을 쓴 C였고, 그마저도 어떤 조직에서의 표준을 따르는 구현 방식이랄 것도 없는 막무가내식으로 구현된 프로젝트였다. 뭐, 지금도 그렇게 훌륭하게 조직화됐다고 말하기 어려운 것이, 리팩토링을 했음에도 점진적으로 변해 가던 요구 사항에 기민하게 적응해내지 못했기 때문이다. 이번에 다룰 내용은 그로써 무너진 모듈화에 대한 신뢰를 어떻게 다시 일으켜 세우려고 노력했는지에 대한 것이다.
프로젝트 초기, 투입된 구성원들 가운데 나를 제외한 모두가 단순히 C를 이용해 코딩하는 것에 익숙한 상태였다. 뿐만 아니라 결과만 나오면 된다는 식으로 구현을 했기 때문에 모듈화와 확장성에 대한 고려같은 것들은 크게 기대하기도 힘든 상황이었다. 이를 테면, 만약 어떤 함수가 있을 때 그 함수 내부의 코드는 왜 이런 것인지, 그 목적이 무엇인지 바로 납득할 수 없음은 물론, 변수명에도 규격이랄 것을 기대할 수 없는 코딩계의 무법천지였다. 이곳에선 그저 여기 저기서 요구되는 기한에 맞춰 결과물이 생산되기만 하는 것을 1차적 목표로 삼고 움직였다.
물론 많은 사람들이 이미 해왔던 것처럼, 이런 형태로 코딩해서 결과를 얻는 것이 불가능한 것은 아니었고 여러 사람들이 그 위에서 갖은 노력을 한 덕분에 다행스럽게도 프로젝트는 성공적으로 진행되었다. 비록 코드가 엉망이어서 무언가 새로운 것을 구현하는데 있어서 코드를 어디에 작성해야하는지 매번 고민하고 이전에 사용했던 로직을 중복으로 구현하게 되는 일도 꽤 있었지만, 이를 이용한 실험 결과는 좋은 방향으로 나타났고 당장 논문을 쓰기에는 큰 문제는 없었다. 당연히 이쯤 얘기했으면 알겠지만, 문제는 논문을 다 쓴 뒤 추가적인 아이디어들을 구현하고자 할 때 나타났다.
필요한 기능을 찾는 것에서 시간이 걸리고, 간단한 인자 값을 변경하는 것이 곧 프로젝트를 다시 빌드하는 것을 의미할 정도로 모든 것이 엮여있는 상태였다. 어떻게든 새로운 아이디어의 검증에 필요한 기능을 구현해내는 것이 가능하기야 했지만, 대학원생 일이라는 것이 워낙 잡다한 덕분에, 일주일 쯤 다른 일을 하다가 돌아와보면 이전에 구현했던 것들이 어떻게 구성되어 있는지를 이해하기 위해 다시 모든 것을 이해하는 시간이 더 많이 필요했다.
그런 식으로 1년이 지나자 프로젝트는 초기에 그러했던 것마냥 간단한 프로그램이 아니게 되었고 더 이상 기존처럼 때에 따라 즉시 필요한 것만 어떻게든 구현한다는 간단한 설계 방식으로는 해결이 안 된다는 것을 동료들 모두가 이해하게 되었다. 이쯤 되니 이 프로젝트 위에 추가적인 확장을 해나가려면 제대로 된 기틀이 마련되어야 한다는 것과 그를 위해 한 템포 쉬더라도 리팩토링을 하는 것이 당연한 인식으로 받아들여졌다. 때를 계속 기다리고 있던 나는 바로 모든 작업을 중단하고 리팩토링을 수행하겠다고 선언했다.
지금 생각하면 이 당시에 어떻게든 동료들을 객체 지향의 세계로 빨리 끌어들이고 공동 설계 작업을 시작했어야 했는데, 리팩토링은 내가 나서서 다 해버리고 다른 이들은 그 와중에 원래의 프로젝트 위에서 요구된 부분 구현이나 개선 작업 등을 하고 있었다. 당연히 이 작업들이 개별적으로 이뤄지는 것은 그만큼 힘든 과정이었지만, 당시의 나는 빠르게 리팩토링을 끝내고 그동안 이뤄질 작은 개선 정도는 바로 병합시켜버릴 수 있을 것 같았다. 그니까 바로 그렇게 생각한 지점이 문제였다.
내가 일을 내 주제에 맞지 않게 크게 벌려서 완수를 못했다는 얘긴 아니다. 리팩토링은 나름 성공적으로 마쳤고, 각 동료들이 추가 작업한 부분도 전부 병합해냈다. 이제 우리의 프로젝트는 객체 지향적인 구조라고 부를 법한 형태를 갖췄다고 말할 수 있게 됐다. 위에서 언급한 문제는 전혀 다른 곳에 있었는데, 그러고 났더니 동료들이 받아든 코드가 하루 아침 새에 전혀 모르는 코드가 되었다는 것이다. 당시 동료들의 말을 인용해 그들의 기분을 설명하자면, 그들은 자신의 코드가 거의 암호화된 것으로 느껴졌다고 했다.
동료들은 객체 지향에서 흔히 얘기하는 정보 은닉의 개념이 전무했다. 이는 즉, 어떤 클래스의 어떤 멤버는 private으로 접근 권한이 제한되어서 getter를 써야만 데이터의 값에 접근할 수 있고, 그렇게 가져와야만 한다는 것을 이해할 수 없는 것이다. 또 어떤 멤버가 getter를 이용해 얻는 것 가능한데 set이 불가능한 경우라든가 그 반대의 경우에 대해서도 왜 그렇게 해야만 하는지 납득하질 못했다. 본인들이 여태까지 해오던 방식대로 데이터를 얻지 못하고 익숙하지 않은 방식으로 돌아가도록 만들어뒀으니 그들 입장에서 보자면 딱 암호화란 표현이 딱 걸맞다.
이런 와중에 객체 지향이 원래 이렇네 저렇네 같은 원리원칙적인 얘기를 늘어놓는 것은 여태까지 겪어온 여러 상황에서처럼 당장의 이해에 큰 도움이 되지 않을 것이라 생각했다. 그럼에도 적당히 필요한 개념 정도는 설명을 해봤으나 동료들은 예상대로 그런 일들을 쉽게 납득하질 못했다. 지난 몇 년간 그들이 익혀온 방식에선 전혀 필요없던 일이었던 부분이니 당연한 것이었다. 해서, 일단 만들어진 것은 만들어진 것이니 새로운 방식을 익혀보기도 할 겸 코딩하면서 손에 익혀보라고 타이르면서 반년의 시간을 지내보았다.
그렇게 반년을 지나오는 과정에서 나는 여태까지의 연구실 생활 중 가장 연구 진척이 없는 한 학기를 보내야 했다. 그렇게 된 여러 문제가 있었지만 가장 큰 문제는 프로젝트가 커져가면서 리팩토링하며 설계한 방식에서 벗어난 것이었다. 리팩토링을 진행할 땐 프로젝트가 시작한지 1년이나 지나서야 시작했기 때문에 시기가 상당히 늦었다고 생각했다. 그래서 이 정도 시기면 충분히 꽉 조여진 형태의 틀을 갖춘 채로 설계해도 괜찮겠다 싶었다. 하지만 여전히 우리의 프로젝트는 다양한 방식으로 커져갔고 앞으로도 더욱 확장될 가능성이 있었다. 그러다보니 동료들이 객체 지향적인 방법으로 데이터들을 접근하는 것이 어렵다고 불평하는 것을 떠나, 나 조차도 더욱 다양해진 데이터들을 접근하고 관리하는 것들을 틀에 끼워맞추기가 어려웠다. 쉽게 말해, 확장성이 부족했던 것이다.
갓 리팩토링이 끝난 초기 상황에서의 문제
그 설계 형태를 간단히 설명하면 어떤 식으로 확장성이 부족했는지 이해할 수 있을 것이다. 우선 특정 모듈에서 다른 모듈로 데이터가 연결되고자 할 때 그 사이에 생성되는 데이터들이 건너가도록 돕는 DataBridge라는 추가적인 모듈을 두고자 했다. A라는 모듈에서 B라는 모듈에 데이터를 전달하기 위해서 A가 B를 알아야 하는 (혹은 반대인) 종속적인 관계를 회피하는 것이 목적이었다. 또한 개별적인 모듈들의 비동기적 처리 시에 따라오게 되는 '필요 데이터의 부재'와 같은 예외적인 상황에 대한 해결 방안들을 DataBridge에서 책임지도록 함으로써 모듈은 그 자신이 수행하고자 하는 일만 담당하도록 역할을 구분하는 것에 도움이 될 것이라 생각했다.
간략화한 설계 모듈. Module A와 Module B가 DataBridge A to B를 통해 단방향 연결되어 데이터 전송이 가능하다.이를 구현하기 위해 A에서 만들어진 데이터는 모두 DataBridge에 기록되고 이것의 접근 권한만 B로 전달하도록 하였다. 이로써 실질적인 모든 데이터는 DataBridge가 소유하고 보존하게 됐다. 리팩토링을 막 해낸 당시엔 이로써 정확히 1:1 관계에서 오는 상호 종속성을 해소할 수 있었다. 그러나 그와 동시에 동료들이 어려워한 부분도 정확히 이 부분이었다. 위와 같이 DataBridge를 통한 간접적인 데이터 교환 방식이 사실 코드의 직관성을 해치는 모양새이긴 하다. 더불어, DataBridge라는 추가적인 모듈을 코딩하는 것이 모든 형태의 모듈 간 데이터 전달에 있어 반드시 요구됐기 때문에 DataBridge 구현에 요구되는 인터페이스들에 대해 숙지해야 한다는 점도 구태여 말하자면 번거로운 장애물이었다.
가령 C라는 모듈을 새로 만들고자 한다면 C를 위한 DataBridge를 추가로 구현해야 한다. 나는 개인적으로 종속성 해소를 위해 이 정도는 감수할만한 것일 수 있다고 여겼고, 그런 부분에선 동료들을 설득할 용의도 있었기에 열심히 이렇게 구현해야만 하는 당위를 설득해가며 서너달 동안 이 방식을 유지하였다. 물론 나는 설계 당사자이기 때문에 그런 방식이 당연하다고 여겼던 면도 없잖아 있다. 하지만 다른 동료들은 사실 상 전혀 새로운 방식을 거의 강요당한 것이기 때문에 어느 정도의 반감도 있었던 것 같고, 그 방식에 맞지 않게 코딩하면 어쩌나 하는 불안감도 있었던 것 같다. 그럼에도 어떻게, 여차저차해서, 모두들 이러한 구현 방식에 적응하여 코딩해나갔다.
새로운 문제의 발발
그렇게 행복하게 진행됐으면 좋았겠으나, 이번엔 데이터의 획득 위치를 결정하는 것이 오히려 이전에 비해 불분명하다는 문제가 나타났다. 만일 모듈 C가 요구하는 데이터의 일부가 기존에 이미 A에서 B로 넘어가는 데이터였다면 이 데이터를 어디에서 가져와야 옳은가 하는 것이 이번에 대두된 문제다. 처음엔 단순히 이런 경우가 적을 것이라 생각해서 A-B간의 연결체인 DataBridgeAtoB와 C를 잇는 개념의 연결체, DataBridgeABtoC를 두기로 하였다. 그리고 거기엔 무거운 원본 데이터들의 사본 대신 원본들을 보관하는 컨테이너에 대한 접근자를 두는 방식으로 이를 해결하고자 했다. 이는 애초에 DataBridge를 모듈의 일종이라 정의한 개념에 근거했고 이 정도의 확장에는 잘 들어맞는 듯 보였다.
Module C가 데이터를 얻어올 수 있도록 우회하여 처리한 방편.안타깝게도 이러한 해결 방식은 또 다른 파생 문제를 낳았는데, DataBridgeABtoC와 같은 다단계 DataBridge의 구현에서 데이터 자체를 중복으로 보존하지 않으려고 나눠가졌던 접근자를 갖게 만들자는 규칙이 오히려 데이터의 소유권에 혼란을 가중시킨 것이다.
DataBridge를 구현하는 입장에선 자신이 전달할 데이터에 대해서 원본을 직접 저장할지, 아니면 접근자를 두는 식으로 구현해야 할지 결정해야 했다. 또한 데이터를 갖다 쓰는 입장에서도 원하는 데이터를 가진 DataBridge가 원본을 가졌는지, 접근자를 통해 접근하는지를 직접 확인해서 코딩해야 한다는 문제가 있었다. 이런 식으로 데이터를 제공하는 측도, 사용하는 측도 모두 결정해야 하니 코드 작성에서 오는 피로감을 가중시켰다.
그와 더불어 프로젝트의 요구 사항도 점점 다채로워지다보니, 기존과 달리 모듈 A가 만들어낸 데이터들을 탐내는 모듈이 한 두개가 아니게 되었다든가, 어떤 모듈이 브릿지로부터 얻고자 하는 데이터들 중 요구하는 건 한 두개에 불과하더라도 전체에 브릿지가 소유/간접 접근 가능한 데이터 전체에 접근할 수 있는 과다한 접근 권한을 얻게 됐는데 이를 제어할 수단이 없다든가 하는 등의 문제들이 나타났다.
이런 문제들을 DataBridge라는 방식에 끼워맞추려면 추가해야할 불필요한 소스 파일과 코드들이 한 둘이 아니었고 결국 DataBridge를 이용한 방식으로썬 확장에 어려움이 있어 새로운 방식으로의 데이터 접근이 가능한 방안이 필요했다.
여러 문제점들을 안고 있는 데이터 전달 로직을 수정해야만 한다는 것은 두말 할 것 없었지만, 그보다 더 큰 문제는 동료들이 작금의 문제에 봉착하게 된 원인으로 모듈화와 설계하는 과정 그 자체를 지목하게 된 것이었다. 기존엔 데이터를 어떻게 전달해야하는지에 대한 고민 없이 잘만 구현했는데 지금은 위에서 언급한 문제들과 다투느라 제대로 코딩할 수 없게 된 것 아니냐는 것이다. 이럴 바엔 전역변수를 쓰는 게 낫지 않겠냐는 주장을 되받아치는데에 그럴 경우 종속성이 너무 심해진다는 말을 반복하는 것은 점점 힘을 잃어가는 듯 했다. 이대로 가다간 정말로 다시 전역 변수가 난무하게 될 것 같은 불안감이 스멀스멀 기어올라왔다. 어떻게든 동료들에게 모듈화된 설계 방식을 고려하고 그를 구현하는 것이 확실하게 더 의미가 있는 작업이 되리라는 것을 각인시켜야만 했다.
다시, 이번엔 혼자 내달리지 않도록
다시 학기를 마치고 방학이 됨과 동시에 본격적으로 2차 리팩토링을 수행하기로 하였다. 첫 리팩토링 과정에서 설계 진행에 있어 동료들이 배제된 채로 진행하는 것이 결국 갇힌 생각에 머무르게 한 것이 아닌가 싶어 이번엔 전체적으로 동료들의 객체 지향적 사고를 이끌어올리면서 설계를 동반하는 방식을 취하기로 하였다. 같이 설계하는 과정을 거치면서 실제로 코딩하는데 있을 법한 불만 사항들을 빠르게 정리하고 의견 합치를 이룬 뒤에 코드를 수정하고 개선시키면, 모든 동료들이 회의 과정에서 이해한 내용대로 코딩할 수 있게 될 것이란 생각이었다.
설계를 위한 회의를 소집하고, 기존의 DataBridge에서 발생한 문제들을 먼저 짚어나갔다. 우리가 여태까지 구현했던 모듈들을 회로도마냥 그려뒀던 그림으로 각 모듈을 가시화해서 모든 동료들이 프로그램에 대해 단 하나의 설계 형태를 생각할 수 있도록 했고, 그 위에서 데이터들이 전달되는 과정이 실제로 구현이 어떤 식으로 이뤄졌는가를 확인하는 과정들을 거쳐갔다. 그리고 동료들에게 이러한 구현들을 할 땐 나름의 패턴이 있어서 우리가 흔히 겪는 여러 종류의 일들이고, 심지어 그에 대한 해결법이 이미 있어서 그를 적용한 것일 뿐임을 확인시키는 과정들을 거쳤다.
설명을 마치고 여러 의견들을 주거니 받거니 하다보니 여태껏 구현한 결과에 대해서 동료들 간에 잘 공유되도록 하지 못했던 것이 문제인가 싶었다. DataBridge를 제대로 받아들이지 못했던 동료들에게 기존의 DataBridge가 갖는 한계를 구체적으로 설명하는 과정에서 그 본연의 목적을 다시금 설명하고 데이터 흐름이나 코드의 로직을 설명하게 됐는데, 그러자 동료들은 초기에 내가 DataBridge를 구현하면서 고려했던 부분들을 생각해내곤 왜 이것이 모듈로써 동작하는 것에서 한계에 부딪혔는지 스스로 이해했다.
스스로 깨닫는 것이 가능했던 것은 둘러모여 얘기만 몇 시간 해본 덕이라기보단, 요즘 들어서 연구실에 객체 지향에 관련된 책들을 읽는 분위기가 된 것이 사고 전환에 큰 몫을 했기 때문이다. 아무것도 모른 상태보단 기초적인 이론이라도 알고 난 후였기 때문에 좀 더 이해가 쉽지 않았으려나 싶다. 아마 이런 회의들을 몇 번 더 거치면 와닿지 않는 예문만 읽고 그치는 것에 비해 훨씬 더 빠르게 객체 지향적인 생각에 도달할 수 있지 않을까 하는 기대감이 좀 생긴다만 앞으로도 계속 이렇게 될런지는 잘 모르겠다.
문제점들을 다 짚고난 후엔 어떤 방향으로 개선할 것인지에 대한 회의로 바로 이어졌다. 사실 모듈 간 종속성을 해결하는 새 방안에 대해선 이미 개인적으로 생각해 온 방식이 있었기 때문에 이는 회의라기보단 내 아이디어를 제시하고 거기에 의견을 듣는 정도였다. 안 그래도 교수님은 논문을 낼 계획을 잡고 계신 마당에 리팩토링을 하는데 주어진 시간이 충분치 않을 것이 뻔했고, 조교 업무만 마무리 지으면 바로 이 문제를 해결할 수 있도록 틈틈이 생각해왔었다. 더구나 시간이 갈수록 DataBridge가 불편하다고 불평을 해대는 통이니 어떻게 고쳐야할지 생각을 안 할래야 안 할 수도 없었다. 이런 상황이었던만큼 구현 그 자체를 위해선 딱히 회의를 할 필요가 없었다. 예외가 발생할 상황들이나 어떤 식으로 구현해야 할지 정도는 개인적으로 고민해서 직접 구현하면 완벽하진 않더라도 구현은 될 것이었다.
하지만 동료들의 직접적인 참여도나 내부 구현에 대한 이해도를 높이고자 큰 틀에서 그것을 설명하고 구체적인 부분들에 대한 규칙들을 같이 정의하도록 하였다. 동료들이 직접 구현에 조금이라도 의견을 내도록 하는게 목적이었다. 이전에 구현된 DataBridge의 경우처럼 혼자서 이해하라고 했다간 또 너무 크게 쌓아 올려진 결과에 질려버릴 게 분명했다. 회의에 임하는 동료들의 기본적인 태도는 전체적인 구현 자체에 대한 이해는 잘 되진 않아도 맥락에 대한 납득은 된다는 느낌이었다.
너무 과한 정도의 불필요한 인터페이스는 제거하고 누락된 것들은 추가했으며 명명은 모두 납득할 수 있는 방식으로 처리하는 등의 일을 했다. 회의로 진행하기엔 사실 너무 사소한 일들이니 동료들이 점차 코드 자체에 익숙해지면 각자 작업한 결과에 대해서 리뷰를 진행하고 피드백하는 방식으로 전환하는 것이 더 좋을 것 같았다.
그렇게 회의를 마친 뒤 실제로 개선된 구현물이 나오는 것은 그리 오래 걸리진 않았다. 그를 코드에서 이용하는 방식은 모두 회의에서 결정한 내용을 토대로 구현하였다. 이것을 구현하는 것은 또 하다 보니 내가 도맡아하긴 했는데, 내가 제안한 방식이었던지라 내용을 잘 이해하고 있던 것이 나이기 때문만은 아니었다. 우선 빠르게 회의해둔 결과물이 모두의 머릿 속에서 구름처럼 사라져버리기 전에 구현된 결과물을 눈으로 직접 마주하게 만들 의도가 더 컸다.
구현 직후, 동료들에게 구현 원리를 설명하는 시간을 가지면서 개선된 형태의 매커니즘에 대한 이해도를 높이려고 했다. 하지만 가장 빠르게 결과가 나오도록 구현해내는 것이 목적인 상황에서 그 모든 구현 원리를 설명하고 이해할 시간을 갖는 것도 무리거니와 아직 C++라는 언어 자체에 대한 숙련도가 낮은 동료들에게 당장 새로운 개념을 설명한다고 했을 때 그들이 곧장 이해하는 것도 어려워보였다.
설명하는 중간중간 듣고 있는 동료들의 어두운 낯빛들을 살피다보니 사실 상 이번 설계가 잘 받아들여지리라는 보장이 없는 상태에서 벌써부터 이론적인 면을 이해하라고 설명하는 것이 너무 섣부른 것 같기도 하여 한 시간 즈음 지나서 일방적인 설명을 멈췄다. 그리곤 새로운 코드의 간략한 작동 방식과 이를 이용해 기존에 DataBridge를 이용해 구현되었던 잔재들을 대체하는 작업을 동료들과 분배하여 작업하기로 하였다. 작업을 분배한 뒤 문제점이 드러나면 그 때 다시 조율한다는 정도만 얘기하고 회의는 마무리할 수밖에 없었다.
이번에도 새삼 느끼지만 준비가 안 된 사람들을 상대로 뭔가를 이해시키려는 생각은 너무 과욕인 것 같으니 다음에 비슷한 일이 생기면 이번처럼 구구절절 말하기보단 당장 일을 할 수 있을 정도로만 짧게 가르쳐주고, 나중에 좀 더 구체적인 부분에 대한 이해를 필요로 하면 그 때에 가서야 따로 시간을 갖고 설명해주는 것이 좋겠다 싶다.
이렇게 회의도 해보고 설명도 해보고 한 결과는 사실 아직 잘 모르겠다. 즉각적인 효과가 나타날 것을 기대하고 한 것이 아니긴 하지만 무엇보다 동료들이 개선할 의지를 스스로 갖지 않으면 효과가 있을리가 만무하기 때문이다. 뭐, 개선의 의지가 있었다면 진작에 이런 문제는 지난 학기에 고쳐졌어야할 부분이 아닌가 싶기도 하지만 이런 생각은 섣불리 프로젝트의 복잡함에 대한 문제를 남탓으로 돌리는 것은 아닌가 싶기도 해서 곧 고개를 가로젓게 된다. 이번 결과도 역시 시간이 어느 정도 흘러야 제대로 평가해볼 수 있겠지만, 자평을 확실히 내릴 수 있기 전까진 이전처럼 방치해두기 보다 지속적으로 정상적인 협업이 가능하게 되도록 노력해보아야 할 것 같다.
