기능결정회의라 쓰고, 혼란의 시작이라 읽는다.

우리는 각자의 리서치를 바탕으로 구체적인 기능을 확정하기로 목표했다. 그러나 현실은, 이상과 꽤 멀리 떨어져 있었다. 일차적으로, 우리는 구글 스프레드시트에 정리했던 단계별 Task와 Needs를 확인하고, 기존 방안 업그레이드를 위한 리서치 내용을 공유했다. 다양한 방안과 레퍼런스들이 등장했다. 

작업 스프레드시트 내용 일부/@AOAS

위의 이미지에는 작대기가 그어져 있지만, 일단 모든 가능한 안들을 펼쳐놓고, 우리 서비스의 가치제안과 가장 일맥상통하는 방안들로 우리의 기능에 대해 논의를 진행했다. 근데 이 과정이 생각보다 쉽지 않았던 것이, 일부에게는 백엔드 단에서의 구조를 완전히 이해하고 있지 못해서 우리가 생각한 기능들이 어떻게 구현될지 가늠하기 어려웠기 때문이다. 일부가 생각하기에 구현하기 어려울 것 같아 보이는 일들이, 가만히 뜯어보면 사실 연결되어 있어 한 번에 손쉽게 해결될 수도 있는 문제들이기도 했다. 그런데 그러한 지식을 모두가 동시에 공유하고 있지 못하니 커뮤니케이션 코스트가 생길 수밖에 없었다. 이 과정이 다소 분위기를 다운시켰다. 이 논의는 곧, 이 서비스의 형태가 단독 웹페이지 형태가 될 것이냐, 크롬 확장 프로그램이 될 것이냐의 문제로 이어졌다. 엄밀히 말하면, 구글시트를 가져가느냐 마느냐의 문제였는데, 크롬 확장 프로그램에 대한 이해도가 낮아서 논점을 제대로 캐치하지 못했다. 각각이 명확하게 어떤 차이가 있고, 작동되도록 구현하는 데 있어서 구체적으로 어떤 과정으로 이어질 지 몰라서, 입장 표명이 어려웠다. 

 

조제의 리드 하에, 정리할 겸 그려진 우리 서비스의 데이터베이스 모델링

 

다들 뚜렷한 넥스트 액션에 대한 확신이 없는 상태에서, 의사결정에 어려움을 느꼈다. 복잡함을 견디지 못한 끝에 일단 우리 서비스의 데이터 관계 구조도가 슥삭 그려졌다. 생활코딩 데이터베이스2 수업을 듣고 있었는데, 이날 적용된 내용은 '관계형 데이터베이스 모델링'이었다. 그 부분 아직 보지 못해서 나는 살짝 흐름을 따라가기 바빴다. 눈치껏 대략 이해할 수 있었고, 이 회의 이후 생활코딩에서 찾아보면서 내가 눈치껏 이해한 내용이 얼추 맞았다는 것까지 파악했다. 아 배움이 정말 끝이 없구나, 했다. 우리는 다음 회의 시간에 좀 더 조사 후에, 어떤 방식으로 서비스를 만들 것인지 결정하고, 그에 따라 기능을 정리해보자고 했다.