brunch

You can make anything
by writing

C.S.Lewis

by 스티브 Oct 31. 2019

프로젝트 기획부터 개발까지

백그라운드


입사 후 처음 맡은 미션은 외주에 의해 개발된 홈페이지와 어드민 페이지 리뉴얼 이었다. 개발을 위한 멤버 구성은 디자이너 1(디자인+기획), 개발자(개발+기획), 대표 한명(개발 컨셉 방향 제시) 이었다. 당시 다른 개발자가 한 명 더 합류 하기로 했으나 계획이 무산 되었고, 실질적인 개발은 혼자서 도맡게 되었다. 기존의 개발된 걸 이어서 할지 혹은 새로 만들어서 할지 선택의 상황이 있었고, 최종적으로는 새롭게 다시 만들기로 결정했다.



왜 처음부터 다시 만들었나?


우선, 처음부터 다시 만드는게 오히려 더 빠르다고 판단했다. 기존 서비스에 사용된 기술 대부분은 한 번도 경험 해보지 않은 것들 이었기 때문에 이에 대한 학습 시간이 필요 했다. 설상가상으로, 이 기술들이 어떠한 의도를 가지고 사용 되었는지를 알려줄 사람도, 그리고 문서도 없었다. 외주 개발자의 경우 인수 인계를 위한 일정 잡기도 어려웠고, 컨셉 정도의 문서만 있을 뿐 구체적인 기획, 기술 문서가 존재 하지 않았다. 이러한 점들을 고려했을 때, 차라리 회사의 서비스를 익히면서 내가 설계하고 홈페이지를 만드는 것이 더 빠르다고 생각했다.


두 번째는 유지 관리 측면이다. 스타트업의 특성상, 짧은 기간 내에 다양한 시도를 많이 해보기 마련이다. 그렇다면 기존에 있는 서비스에 수정되거나 추가 해야할 작업이 많다는 의미인데, 이 프로그램에 대한 설계자 혹은 프로그램적으로 이해가 높은 사람이 없는 상황에서 유지보수 하는 건 정말 위험하다고 생각했다.


마지막으로는, 이전 회사에서도 프로그램의 처음부터 끝까지 기획, 설계, 개발까지 하는 과정에 있어서 코어 역할을 했었기 때문에, 할 수 있을 것이라는 자신감도 있었다.



기획자 없이 어떻게 기획을 했나?


기획은 내부 인원으로 충당했다. 전 직장에서 전문적인 기획자는 아니었지만, 일부 참여하며 기획에 대한 이해는 좀 있었다. 그래서 디자이너와 함께 머리를 맞대며 기획을 잡아 나갔다. 사실 기획이라는 것은 완벽하기 어렵다. 회사의 의사결정에 따라 혹은 시장에 따라 수시로 바뀔 수 있는게 기획이기 때문이다. 그래서 현 인프라와 리뉴얼 오픈 시기를 감안해서 최대한 심플 하면서 회사가 고객에게 전달하고자 하는 의도를 녹여내는 데에 초점을 두었다. 물론 부족한 부분도 많아 중간에 수정되는 사항도 있었지만, 같이 일하는 동료들이 모두 적극적으로 참여했기 때문에 힘들지 않게 헤쳐나갈 수 있었다고 생각한다.



혼자서 개발해야 하는 것에 어려움은 없었나?


여러 우여곡절이 있었지만 그 중에 두가지 정도 꼽으라고 한다면, 일단 기술적인 어려움이 있었다. 특히 프론트 쪽은 리액트 라는 기술로 개발했는데, 이는 이 회사에 오면서 처음 사용 해보는 기술 이었다. 전 회사에서 블록체인과 백엔드 쪽을 주로 개발 했었기 때문에, 이 부분은 처음이었다. 별거 아니겠지라고 생각했지만, 기술적으로 리드해줄 사람 없이 혼자서 구글링과 책으로만 개발해야 했기 때문에, 초반에 삽질도 많이 했다. 결국 할 수 있는 건 시간을 더 많이 쓰는 것이었다. 새로운 기술을 팔로업 하기위해 잠을 줄여서 공부를 더 많이 했다. 전 직장에서도 처음 블록체인을 맡았을 때도 그랬듯이, 그 과정이 어렵기는 했지만 하나하나 알아가는 재미는 있었다.


두 번째는 기존 서비스를 이어야 한다는 점이다. 이미 운영되고 있는 서비스와 데이터의 호환성도 유지하면서,  새로운 기능들로 업그레이드 해야 했다. 그래서 데이터베이스를 설계하는 과정에서 매우 애를 먹었던 것 같다. 기존 데이터베이스의 테이블 설계가 어떠한 의도를 가지고 했는지 알 수 있는 방법이 없었기 때문에, 추측으로 밖에 할 수 없었다. 그래서 개발을 하는 중간 중간에 데이터 설계를 바꾸는 과정이 많았고, 이로 인해서 소스코드까지 같이 고쳐야 하는 경우가 많았다. 이러한 점 때문에 처음에 예상했던 시간보다 더 오래 걸렸던 것 같다.



서비스를 처음부터 만들기 위해 무엇 부터 했나?


왜 라는 질문으로 시작을 했다. 나는 개발을 할 때, 왜 이 기능이 필요한지 왜 이렇게 만들어야 하는지를 자주 질문 한다. 이게 서비스에 대한 이해라고 생각하며, 이게 없다면 개발에 대한 애정이 생기 않는듯 하다. 그래서 개발을 하기에 앞서 기획은 상당히 중요하다. 이 부분이 머릿속에 명확하지 않다면 개발의 방향을 잡아가는데에 있어서 힘들다. 내가 개발을 하며 늘 느낀 점은 기획이 명확하지 않다면, 프로젝트가 산으로 갈 수 있다는 점이다. 개발도 하나의 스토리텔링이다. 고객이 홈페이지에 처음 들어와서 마지막에 나가는 순간까지 만족감을 주기 위해서 개발은 유기적인 시나리오가 필요하며 이에 따른 개발이 되어야 한다. 그래서 우리 서비스의 철학은 무엇이고, 고객은 우리의 어떤 점에 열광하는지 등을 동료들과  많이 소통을 했다.



처음 사용하는 기술을 어떻게 서비스까지 적용했나?


모르는 부분은 구글링을 통해 공부를 했고, 가끔 어려움이 있을 때, 주변 개발자에게 자문을 구하는 방식으로 개발을 했다. 가장 공부가 많이 필요했던 부분은 React 였다. 처음에 일주일 정도는 블로그와 유튜브를 참고해서 리액트에 대한 기본적인 개념을 익히고, 예제를 적용시켜 보며 전체적인 흐름을 이해할 수 있었다. 그리고 실직적으로 서비스를 만들어 가며 그때그때 필요한 구체적인 내용 들을 찾아 보며 익혔다.


그리고 일정을 지켜야 한다는 각오로 개발했다. 나는 개발을 할 때, 일정을 상당히 중요시하고 이를 최대한 맞추려고 노력한다. 기업은 전체적인 로드맵을 잡고 개발이 되는 일정에 따라 마케팅을 하고, 투자유치를 하는 등의 여러 일정이 수반될 수 있다. 그렇기 때문에, 시간적인 여유와 개발 인력이 부족했던 상황에 맞게, 일정에 맞출 수 있도록 주요 기능 위주로 서비스를 최소화 하여 개발했고, 결국 원하는 오픈 시기에 비슷하게 맞출 수 있었다. 이후 유지보수 하는 상황에서 힘들었지만, 그래도 오픈 시기를 맞춰 비즈니스에 큰 차질을 일어나지 않아 좋은 선택을 했다고 생각한다.



지금에서 아쉬운점은?


조금 더 많은 소통을 했어야 했다. 커뮤니케이션을 많이 했다고 생각했지만, 그래도 개발해야 하는 시간에 쫓겨, 많이 하지는 못했다. 이러한 점들이 결국 나중에는 문제로 다가왔다. 우리의 서비스가 커머스도 같이 운영 하고 있다 보니 관리 페이지가 서비스에 상당히 중요한 역할을 했다. 이를 실제 사용하는 운영 팀과의 소통이 충분치 않아 개발 후반부에 수정하는 작업이 많았다. 홈페이지와 관리페이지 기획의 포커싱을 9:1 정도로 했었는데, 지금와서 생각해보면 적어도 6:4 정도의 비율로 더 깊은 고민을 했어야 한다는 것을 뼈저리게 느꼈다. 왜냐하면 이로 인해 서비스 오픈 후 관리 페이지에 대한 문제를 많이 겪었고, 대부분의 시간을 여기에 할애했기 때문이다.

작가의 이전글 스타트업 무엇이 좋고 무엇이 안 좋은가?
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari