웰컴토스트 약점 찾기 무한 루프 🔁
레퍼런스는 냅다 캡쳐
프로젝트 마무리 과정
프로젝트에 대해 받은 피드백
앞으로 남은 작업
일정 관리 복기
12월 5일 시작한 개인 프로젝트가 지난 18일 수요일 끝났다. 이제 잠시 11월에 진행했던 팀 프로젝트를 개선하고, 두 프로젝트의 README*를 모두 완성할 계획이다. 다가오는 금요일 마루360에서 하는 팀플 발표*도 잘 준비해야 한다. 기획 기간을 제외하면, 개인 프로젝트는 2주간 개발을 진행했다. 앞으로 개선할 점이 남았지만, 공식 종료 기념으로 이번 주 프로젝트를 어떻게 마무리 했는지 적어보려고 한다. 또 발표 전후로 받았던 피드백들과, 이어서 어떤 작업을 진행할지 간단히 정리해보자.
*완성한 README
팀 프로젝트
개인 프로젝트
*팀 프로젝트
발표 영상
내가 2주간 만든 프로젝트의 결과물은 연동 스크립트와 관리자 페이지이다. ‘웰컴토스트’ 서비스를 이용하려는 사용자의 앱이 연동할 때 스크립트와 연동후 토스트 메시지를 관리, 편집할 수 있는 페이지를 만들었다. (DB는 Supabase를 처음 사용해보았다. Serverless 구조를 택한 덕분에 프론트엔드에 집중할 수 있었다.) 최소한의 핵심 기능은 지난 주 모두 완성했기 때문에, 이번 주의 핵심 키워드는 안정화였다. 내가 만드는 프로젝트는 여러 서비스에 주입될 코드로 동작하는 것이기 때문에, 다양한 환경과 웹사이트 여건에서 안정적으로 동작이 되어야 했다. SDK로써 마땅히 갖추어야 할 조건이었는데, 이전 프로젝트들에서는 경험해보지 못한 새로운 사고와 책임감에 대해 생각해보게 된 시간이었다. 내가 만든 웹사이트 하나가 잘 되면 끝나는 것이 아니니까.
최종 시연 이전에, 테스트를 진행해볼 수 있는 여러 옵션을 알아봤다. (지금 이 글이 담긴) 내 블로그, 동기가 만든 웹사이트에 연동해보고, Framer, Oopy, webflow가 제공하는 템플릿 웹페이지를 활용할 수 있는 방법을 알아봤다. (테스트를 도와준 동기 분께 감사🙏) 테스트를 한다는 것은 내가 만든 결과의 취약점을 드러내고 직면해야하는 순간을 의미했다. 어찌보면 꽤나 본능을 거스르는 일이었다. 또 화려한 기능을 선보이고 싶은 욕심도 버려야하고. 하지만 여러 케이스를 고려하기 위해 시도한 점이 좋은 시도였다고 생각한다. 덕분에 놓친 부분과 개선점을 발견할 수 있었다.
예를 들어, 토스트 메시지 적용을 위해 엘리먼트 id가 사전에 심어져 있어야 하는데 이것 자체가 허들일 수 있었다. 특히 리액트 기반 애플리케이션에서는 id를 잘 활용하지 않기도 하고… 그럼에도 결론은 id를 통해 토스트 메시지를 적용하는 방향을 유지했다. id의 역할은 토스트 메시지로 강조할 특정 DOM 요소를 탐색하기 위한 기준이 되는 것인데, CSS 복합 선택자 혹은 XPath 등의 대안 보다 안정적인 역할을 해낼거라 보았기 때문이다. 테스트가 도움이 되었던 건, 이렇게 이슈를 미리 파악하고 나만의 합리적인 결정을 빨리 할 수 있었던 부분이었던 것 같다. 그외에도 테스트를 해보면서 ‘연동한 웹사이트에 사용자가 모바일로 진입하더라도 자연스럽게 보일까, 강조할 타겟 DOM 요소에 애니메이션 효과가 있다면?’ 등 어찌보면 당연한데 놓쳤던 케이스도 고려할 수 있었다. 조만간 이외에도 테스트 결과의 신뢰를 높일 수 있게, 테스트 코드를 적극적으로 활용해보면 좋겠다.
프로젝트 막바지에 들어서니 시간 관리가 더 중요해졌다. 3일 남은 시점에서 몇 가지 아쉬운 점들이 있었다. 조급한 마음에 새벽 작업까지 하다 보니, 평소 지키던 아침 루틴이 무너졌다. 운동도 못하고… 가급적 하루를 일찍 시작하는 것에 스스로 동기부여를 받는데 이번에는 마음이 급했다. 새벽 작업은 집중력도 떨어지고 생산성도 좋지 않았다. 앞으로는 기존 루틴을 잘 지켜야겠다.
테스트를 주로 하다보니, 예상치 못한 버그가 발생하고 최적화 과정에서 생각보다 많은 시간을 쓰게 되었다. 계획대로 안 될 때도 있지만, 계획을 세우는 것 자체가 의미 있으니 끝까지 시간 계획은 놓치지 말아야겠다는 생각으로 계속 계획을 잡고 수정하고를 반복했던 것 같다. 주말에는 특히 배포 작업이 예상보다 느리게 진행됐다. 배포와 관련된 이슈들을 처음 겪다 보니 빌드나 배포 관련 지식을 추가로 학습하면서 진행했다. 도메인 연결이나 DNS 설정에만 2시간을 썼는데, 시간이 길어지다보니 이게 지금 중요한 작업이 맞는지 의문이 들었다. 시연을 위해 지금 당장 급한 일은 아닐 수 있다는 생각도 했지만, 배포 환경에서의 에러도 수정하고 배포된 환경에서 시연하기 위해 작업을 이어서 하는게 좋겠다 판단했다. 이렇게 우선순위 파악은 마지막까지도 중요한 일이었다.
2주간의 구현 결과를 시연하며 부트캠프 기간 내 개인 프로젝트의 공식 일정은 종료했다. 동기들과 바닐라코딩 내에서 간단히 시연하는 시간을 가졌다. 짧은 기간 내에 동기들이 만들어낸 프로젝트 결과물이 대단하다는 생각도 들고, 부트캠프의 공식 일정이 모두 끝났다는 것에 여러 생각이 겹치기도 했다. 시연은 5분 내외로 진행했고, 나는 사전에 연동하고 토스트 메시지 설정을 완료한 웹페이지들과 어드민 페이지를 이용해서 직접 토스트 메시지를 편집하는 과정으로 시연을 진행했다. 주요 피드백은 이러했다.
먼저, “스크립트가 CSR(Client Side Rendering) 애플리케이션 환경에도 대응이 되어 있는가?”라는 질문을 받았다. 답은 ‘No’였고, 렌더링 방식을 고려해서 설계하지 못했다. 현재는 SSR(Server Side Rendering) 애플리케이션에 최적화 되어 있다. 의도대로라면, DOM에 강조할 타겟 요소가 있다면 토스트 메시지가 적절하게 띄워져야 한다. 이를 수행할 스크립트 실행이 SSR 방식의 웹사이트에서는 페이지 전환 후에 매번 발생하는 반면, 리액트 등 CSR 웹사이트는 스크립트가 최초 1번 실행되었다. CSR의 경우 최초에 스크립트가 실행될 때 현재 DOM에 타겟 요소가 없다면 제 역할을 하지 못 한다. DOM의 변화에 따라 스크립트 실행을 제어할 수 있도록 개선하기로 결정했다. 더 많은 웹사이트에 SDK를 제공할 수 있도록!
그리고 역시 “엘리먼트 id를 심어서 기준을 삼는 방식은 비개발 직군에게 어려운 UX일 수 있다는 점”도 피드백으로 주셨다. 개발자 도움 없이 웹사이트에 토스트 메시지를 띄울 수 있다는 점이 강점일 수 있는데 여전히 개발자 의존하는 부분이 있을 수 있다는 내용이었다. 이 부분은 탐색의 안정성과 편의성 측면에서 트레이드 오프가 있다고 여전히 생각되는 점이다. 더 쉽게 만들 수 있는 방법을 고민해봐야겠다.
혼자서 프로젝트를 이끌면서 매 순간 고민하고 결정하는 과정의 연속이었는데, 그 과정에서 많이 배웠다. 특히 장애물을 만났을 때 해결책을 찾아내는 방법을 훈련했던 것 같다. 결국 회사에서도 일하는 모습이 이런 점과 비슷할 수 있겠다 어렴풋이 짐작할 수 있었다.
다만 아쉬운 점도 있다. 기본 기능을 다 만들고 나서 다음 단계를 빨리 정하지 못하고 우왕좌왕했다. 경험이 부족해서인지 다음 스텝을 결정하는 게 쉽지 않았고, 리팩토링에도 생각보다 많은 시간을 쏟았다. 신기한 건, 프로젝트 마감 당일에는 이미지 업로드 같은 기능을 몰입해서 빠르게 만들었는데 그 이후로는 그만한 속도가 안 나온다는 거다. 역시 마감이 없으니 의지만으로는 부족했나 보다. 앞으로는 스스로 마감일을 정해두고, 그걸 지키면서 움직여야겠다는 생각이 든다.
이제 실제 사용자들을 받아볼 준비를 할 예정이다. 분명 여러 오류가 발생하겠지만, 이런 부분은 미리 잘 설명해두는게 필요하겠다. 완벽한 상용화가 목적이 아니라, 실제 현업처럼 사용자 피드백을 받고 기능을 런칭하고 개선하는 것에 의미를 두려고 한다.