첫 입사 당시 가장 기대했던 부분은 실무에서 작성되는 코드였다. 막상 실무 코드를 처음보는 것에 설레였지만 확인했을 때 무척 당황했었다. 변수나 함수명은 명확하지 않았고, 컴포넌트는 목적에 따라 쪼개지지 않아 1000줄 가까이 된 코드도 분명히 존재했다.
라이브러리 버전은 당연히 말할 것도 없었고 신입이였지만 내 눈에도 아쉬운 부분들이 보였다. 당시에 나는 최신 라이브러리 활용과 흐름을 기반으로 학습되어 있는 상황인지라 개발 환경이 레거시인 거 자체에 혼란스러웠다.

물론 그 때는 경험과 실력이 부족했던 때라 넓은 시야로 바라보는 능력은 부족했었다. 문서화는 많이 되어 있지는 않았지만 그 때 당시에 이렇게 할수 밖에 없었는지에 대해 설명하며 납득할 수 있는 지점들이 생겨났다.

코드작성에 대한 의사결정은 당연히 존재한다.

전부터 느꼈지만 요즘에 더 많이 느끼는 건, '왜 이렇게 설계했어요?', '왜 이렇게 작성했어요?'와 같은 당시 초기 의사결정에 대한 궁금증이다.

최근에 사내에서 테스트코드 환경을 구축하는데 팀원과 많은 의견을 주고받고 보편화된 모범사례를 적용하기 보다는 우리의 상황에 맞는 환경을 구축하기에 애썼다. 그리고 이 과정에대한 문서화도 진행했다. 하지만 그 프로젝트를 맡는 일은 더 이상 없었고, 다른 개발자분이 맡게 되었다.
그럼 이 과정은 무의미했던걸까??

내 대답은 그렇지않다이다..

다시 첫 회사로 돌아가보자. 첫 회사에서 팀 개편으로 인해 팀을 옮겼다. 어느 정도 기술적흐름이 보이던 시기라 궁금한게 많았다. 더더욱 이전 팀에 비해 규모가 커서 기술적으로 도입되었던 부분이 많았다. 예를 들어 과거에 MSA기반 아키텍쳐에서 다시 모놀리식 구조로 돌아왔다던가, Storybook을 기반한 UI설계, 모노레포 등이 그 예시였다. 또한 이런 기술적 결정은 나름 내가 팀을 옮기기 바로 직전에 마이그레이션된 부분이라 더 흥미로웠다.

하지만 금새 흥미가 떨어졌다. 이 기술적 결정 과정이나 이유에 대해 크게 관심있거나 이해하는 분들이 생각보다 없었다. 단순 지엽적인 부분이 아니고 큰 축을 차지하는 부분인데도 모르는 사람이 존재했다.

내가 더 아쉬웠던 상황은 이 부분을 그냥 모르고 지나가려하는 태도였다. "이 부분은 다른 분에게 여쭤보고 확인해볼게요", "이 부분에 대해 잘 아시는 분은 없지만 저도 이건 좀 아쉬워요."와 같은 답변을 기대하기는 어려웠다.

개발자는 지속적으로 바뀌지만 그 의사결정 기록은 남는다.

현재로 돌아와 다시 이야기하지만, 나는 내가 구축한 테스트 환경을 더 이상 손대지 않는다. 그럼에도 ADR(Architectural Decision Records)과 같이 의사결정에 대한 문서화는 남겨둔다. 그래야 이후 개발자가 설계에 대한 맥락을 이해하고 더 좋은 방향으로 개선점까지 생각해낼 수 있지 않을까 한다.

AI가 발전한다해도 우리의 의사결정과 이에 대한 근거를 확인하고 검토하는 과정은 위임할 수 없다. 또한 이에 대한 책임은 개발자에게 있다.

구성원들은 퇴사하고, 우리의 기억은 점점 흐려지고, 논의 되었던 내역은 잊혀져간다.

새로 팀에 합류하게 되면 궁금한 부분이나 눈에 띄는 부분들이 무조건 있을 것이다. 이런 팀원들을 위해서 디테일적인 요소는 없다하더라도 최소한의 의사결정 문서화를 해놓는 것이 좋지 않을까?

"역사를 잊은 민족에게 미래는 없다"라는 말이 있지 않은가.. 과거의 역사이자 의사결정 속에 얻은 학습과 교훈이 있다면 후에 더 발전있는 환경을 구축할 수 있을 것이다.