프로젝트 시작 전에...
컴퓨터 그래픽스 팀 프로젝트를 조만간 시작해야 하고, 내일 팀원들에게 내가 개인적으로 추진하고 싶은 프로젝트 주제를 전달할 것인데, 이것이 설사 수용되지 않더라도 여태까지의 경험에 기초할 때 프로젝트를 하는 데 있어 내가 느꼈던 바를 미리 정리해 놓아야 이후에 프로젝트를 끝마쳐서 올바른 회고가 가능하므로 이 문서에서는 미리 나의 의도와 불안한 점을 정리해놓는다.
아이디어 공유
생각의 합치를 위하여
프로젝트에서 제시되는 언어에는 반드시 동상이몽의 여지가 있다. 문서나 회의에서는 다음을 반드시 고려해야 한다. 이 경우 다양한 예제나 일례, 비유를 들지 않으면 백 명의 팀원마다 백 개의 구상이 있을 것이다. 그것의 기술적인 제약 사항, 타협할 수 없는 부분을 명확하게 밝혀 규모 축소형 가정으로 타협하는 일이 없어야 한다.
-
일반적으로 사용하는 용어가 아닌 다른 용어로 적힌 것이 있는가?
사용자 인증
로그인. -
프로젝트에서 고안된 새로운 개념이 있는가?
뉴스들의 사건맥락
뉴스가 제시하는 이슈가 어떻게 전개되고 있는 지를 시간 내림차순으로 기록한 히스토리. -
팀원들이 잘 모를 수 있는, 혹은 도입 의도를 모를 수 있는 학문적 지식이 프로젝트에 사용되는가?
회의에서 이러한 알고리즘이 있음을 차분히 보여주고 더불어 참고할 만한 영상을 함께 제공한다.
이 과정에서, 하위 지식에 대해서도 전반적인 이유와 설명이 필요하다. 이때, "이것이 없으면 무엇이 불편한가", "왜 학자들은 이러한 개념을 고안했는가"를 중심으로 설명하면 수용이 쉽다.
상세한 이학적, 공학적 지식은 그 자체가 필요하지 않은 한 접어두고 전반적인 지식을 주입하는데 집중한다.
모호한 정의를 의도한 경우에는 이 근거나 이유를 반드시 밝혀야 한다. 이러한 의도는 구상 단계에서 해석되어야 하고 이로부터 얻어진 제약사항은 설계에 반영되어야 한다. 즉, 모호함을 의도적으로 상세히 밝힘으로써 이를 설계 제약사항으로 반영하는 것이다. 모호함이 은근슬쩍 구상의 단계를 넘어가서 설계 단계에서도 살아남으면 불안정한 설계의 원인이 된다.
소셜 미디어 포스트
UTF8 한국어 기준 300자 이내의 포스트, 지금은 사진과 영상타입 포스트는 지원하지 않으나, 향후 확장성을 위해 다양한 미디어 타입을 고려한 설계가 요구된다.
설계
실제로 개발에 옮길 수 있을 만큼의 요구사항이 명확하게 밝혀졌다는 것은 어떻게 진단할 수 있는가?
- 개발단계에서 임의적 가정이 필요없어지는 정도 가 기준이 될 수 있을까?
