시스템기획서에 데이터구조를 제안할 때 여러 안을 준비해야 할까?

지금까지 팀이 이룩해 온 업적을 따라잡기 시작한 지 시간이 제법 지났습니다. 처음에는 문서를 읽고 빌드를 만져보기를 반복하며 여러 가지 정보를 얻었고 그러는 사이에 빌드를 망가뜨리기도 했습니다. 시간이 조금 더 지나고 제가 기여할 수 있을 것 같은 부분을 찾아 제 방식대로 일을 하기 시작했습니다. 이 때 걱정한 점은 지금까지 팀에서 일을 시작해 진행해 온 방식과 제가 일을 시작해 진행하는 방식 사이에 차이가 있어 서로 충돌하거나 제가 엉뚱한 방법으로 일을 해 그 결과를 보는 사람들이 ‘뭐임???’ 같은 반응을 하게 만드는 것입니다. 그런 사례가 없지는 않았지만 그럭저럭 저에게 편한 방법으로 일하기 시작했지만 아직 까지는 누군가의 심기를 크게 거스르고 있지는 않은 것 같습니다.

제멋대로 일하는 방법 중 하나에는 회의록 페이지를 아무 데나 만드는 것이 있습니다. 가령 지난 여러 팀에서 회의록을 만드는 경로가 약속 되어 있는 경우가 거의 대부분이었습니다. 컨플루언스 어딘가의 페이지 트리에 회의록을 만들기로 미리 약속 되어 있고 회의에 참여한 누군가가 잊지 않는 한 그 아래 회의록이 만들어집니다. 종종 회의록에는 날짜와 주제 뿐 아니라 그 회의에 누가 참석했는지 기입하도록 강제할 때도 있었는데 종종 팀에 처음 오셔서 아직 사람들 이름을 기억하지 못하는 분이 회의록을 기록하시거나 너무 많은 사람들이 들어와 사실상 회의로써 의미를 상실한 회의의 회의록을 작성해야 할 때 어려움을 겪기도 합니다. 한동안은 저 역시 그런 규칙을 잘 지켰지만 어느 날 곰곰이 생각해보니 마일스톤 목표 하나하나를 수행해 가면서 나오는 여러 회의록은 회의록 무더기에 함께 섞여 있기에는 그 속성과 용도가 상당히 다르다는 생각을 했습니다. 마일스톤 단위의 아주 크지 않은 목표를 달성하기 위해 협업 부서와 나눈 자잘한 이야기, 단순한 결정 따위를 모두 회의록으로 만들어 공유하곤 했는데 이런 회의록은 거창하게 프로젝트 전체의 회의록이 쌓여 있는 무더기에 이들을 추가하기 보다는 자잘한 회의록은 이 회의록이 영향을 주는 문서 하위에 놔 두는 편이 개발해 나가면서 회의록을 더 빨리 찾을 수 있었고 또 개발에 필요한 문서와 페이지 트리 상에서 가까운 위치에서 회의록을 찾을 수 있어 더 좋았습니다.