Daria Shevtsova 님의 사진, 출처: Pexels
프로젝트와 기획
코드스테이츠에서 제공하는 3 번의 섹션 기간을 통해 수강생들은 기술, 소위 말해 스택을 습득하게 됩니다. 그리고 이렇게 배운 스택을 프로젝트에서 본격적으로 활용하게 되죠. 프로젝트 안내에서는 새로운 기술 스택에 섣불리 도전하기보다 가급적 그동안 배운 것들을 복습하기를 권장하고 있습니다.
대신 프로젝트에서 기술 스택의 사용 외에 추가적으로 해야하는 것이 있습니다. 바로 기획이라는 단계입니다. 우리가 만들고자 하는 서비스는 무엇이며, 이를 구현하기 위해 어떤 기능들이 필요한지, 또 어떤 스택을 사용했는지 등등, 기획을 통해 우리는 만들고자 하는 서비스를 구체화하고, 또 개발 단계에서 필요한 문서들을 작성하게 됩니다. 프로그래밍을 실제로 진행하기 전 미리 청사진을 그리는 과정인 것이죠.
따라서 기획을 통해 우리는 하고자 하는 것들을 명료하게 설명할 수 있어야 합니다. 이 단계가 충분하지 않을 경우 프로그래밍을 진행하면서 수시로 난관에 봉착하게 되죠. 반대로 잘 된 기획은 프로그래밍 단계를 한층 수월하게 하고, 명확하게 해야할 바를 알려주는 가이드가 됩니다.
기획의 어려움
프로젝트를 기획하면서 처음 겪게 되는 난관은 아마 아이템을 선정하는 과정일 겁니다. 꼭 하고 싶은 아이템이 있어서 어려움을 겪는 경우도 있다고 하던데, 저는 반대로 뚜렷한 아이템이 없어서 어려움을 겪은 케이스입니다.
물론 아이디어 정도는 미리 준비해두긴 했었죠. 실제로 First Project 에서는 제가 낸 아이디어를 바탕으로 팀원들과 함께 살을 붙여 서비스를 구현했었으니까요.
문제는 아이디어라는 것이 그렇지만, 여러 팀원들과 이야기를 나누어보면 구멍이 숭숭 보인다는 것입니다. '이렇게 하면 될 것 같은데' 를 생각만 하는 것과, 실제로 되게 하기 위해서 고민을 하는 것은 전혀 다른 과정이기 때문이죠. 게다가 이 과정을 거쳐 기획을 잘 마쳐도 프로그래밍 단계에 들어서면 다시 구멍을 발견하게 됩니다.
그래서 철저하게 기획을 해야 하면서도 마주하는 여러 문제 상황들에 있어서 유연하게 대처하는 마음가짐이 필요합니다. 필요한 것이 있다면 논리적으로 팀원들을 설득하고, 반대로 팀원의 논리에서 부족한 부분을 보충해나가야 하죠. 의견 충돌이 있다면 적극적으로 설득하되, 한 번 결정이 났다면 최선을 다해 결정된 방향으로 진행해야 합니다.
사실 의견 충돌이 나는 경우가 제일 어려운 상황이라고들 합니다. 특히 어느 한 쪽이 틀리지 않고 두 의견 모두가 나름의 타당성을 가지고 있을 때가 그렇죠. 기획이라는 건 명백하게 정답이 존재하는 영역이 아니거든요.
특히 가장 어려운 상황은 의견 충돌보다도, 어찌저찌 결정을 내렸는데 그 결정이 결국 잘못된 결정이었을 때일 겁니다. 개인적으로는 이런 상황이 생기면 빠르게 수정을 진행하되, '거봐, 이게 맞잖아' 라는 식의 태도는 지양해야 한다고 생각하는 편입니다. 어떤 것을 결정하는 것은 곧 팀 모두의 결정이기 때문입니다. 이러한 점 또한 기획 단계에서 보다 철저하게 검증하고 의견을 나누는 것이 중요한 이유이기도 합니다.
남은 2 주 간의 일정
기본적인 기능의 구현은 어느 정도 마무리가 되었습니다. 기능 구현이 빠르게 진행된 만큼 개인적으로는 이번 주 안에 디자인을 마무리하면 어떨까 싶은 생각을 합니다. 최소한 주말까지 (기능의 추가 이외에는) 디자인을 완성해 배포까지 마무리해둔다는 계획이죠. 그러면 기능을 추가적으로 구현한다 해도 부담이 덜할 거라고 생각합니다.
클라이언트를 담당한 두 프론트엔드 팀원 분들이 각자의 영역에 필요한 디자인을 담당하는 만큼, 백엔드를 맡은 저와 팀장님이 랜딩페이지를 맡는 것으로 이야기가 되었습니다. 지난 주말 동안 이래저래 코드를 만져봤는데, 진짜 열심히 복습해야 겠다는 생각이 들더라구요. 매일의 수업을 따라가기에 급급해서 복습에 소홀했던 CSS 를 다시 열심히 찾아봐야겠습니다.
