
IN SOPT 31기의 대미를 장식하는 '앱잼'을 끝으로, 31기 웹파트 YB로서 솝트의 한 기수 활동을 모두 마쳤다. 사실 솝트에 들어오기 전 많은 고민들이 있었다. 당시의 나는 웹FE를 좋아했지만 권태기(?)를 겪고 있었다. 내 실력은 정체되어있는데, 이 분야는 워낙 급변하는 생태계였기 때문이다. 특히 같은 시기에 참여하고 있던 프로젝트에서 iOS 앱 개발을 통해 객체지향 프로그래밍을 경험해보면서, 비교적 자유도가 높은 웹 개발에 대해 회의적이게 되었던 것 같다. 하지만 매주 세미나를 듣고, 과제를 수행하면서 그동안의 걱정들이 나의 편협한 시각으로부터 비롯되었다는 것을 깨달았다.
이 질문에 대한 답을 얻는 것이 내가 IN SOPT 웹파트를 지원하게 된 첫번째 이유였다. 이 고민은 개발자 뿐만 아니라 기획자들도 마찬가지로 하는 고민이라고 생각한다. 웹 서비스들은 항상 '왜 모바일이 아니라 웹 서비스로 기획했느냐'라는 질문에 대해 확고한 정당성을 내놓아야만 했다. 이러한 화두는 웹 파트 첫 세미나의 주제였고, 솝트는 이 질문에 '웹 접근성'이라는 답을 내놓는다.

웹이 모바일과 달리 '설치'라는 허들을 넘지 않아도 이용할 수 있고, 스크린 리더를 사용해 모두가 차별없이 이용할 수 있는 이유는 웹이 이러한 표준을 내세웠기 때문이다. 이 개념을 처음으로 접한 나는 웹 개발이 사명감을 가지는 분야라는 것을 알았다. 내가 모르던 웹의 면모를 알게되니 웹 개발이 다시금 흥미롭게 느껴졌고, 첫주차 과제로 작성한 나의 아티클은 솝트 공식 블로그의 첫 글로 기재되기도 했다.
웹 접근성에 대한 '내' 생각
https://velog.io/@sopt_official/%EC%9B%B9-%EC%A0%91%EA%B7%BC%EC%84%B1%EC%97%90-%EB%8C%80%ED%95%9C-%EB%82%B4-%EC%83%9D%EA%B0%81
IN SOPT에서 두번째로 얻어가고자 한 것은 '좋은 코드'였다. 좋은 개발자가 되려면, 어느 코드가 좋은 코드인지에 대한 어느 정도의 분별력을 가지고 있어야 한다고 생각했다. 과감히 휴학을 단행하고 솝트에 참여하게 된 것도 더이상 학업에 치이며 구현에 급급한 코드로만 개발하는 것이 아니라, 효율적으로 코드 짜기 위해 좀 더 많은 시간을 투자하고 싶었기 때문이다.
좋은 기회로 5주차 합동 세미나에서 웹 리드를 맡게 되었다. 본격적인 앱잼 프로젝트에 앞서 클라이언트/서버/디자인이 함께 리디자인된 서비스를 구현해보는 시간을 가졌는데, 처음 리드를 맡다보니 프로젝트 세팅이나 컨벤션 등을 어떻게 정해야할지 몰라 어려움을 겪기도 했다. 하지만 세팅을 위해 다양한 프로젝트들도 참고해보고, 중간발표를 통해 파트원들의 피드백도 들으면서 팀원들에게 좋은 개발환경을 구축해주고자 노력했다.
대표적인 예로는 브랜치 컨벤션이 있다. 처음에는 단순히 비즈니스 로직과 UI를 분리한다는 목적으로 API-페이지명, UI-페이지명으로 브랜치를 명명했는데, 이렇게하면 pr 단위가 너무 방대해지고 서로의 진행상황을 공유하기 어려웠다. 따라서 중간발표 이후에는 깃헙 이슈를 발행하고, feature/#이슈번호로 명명해 브랜치를 이슈 단위로 생성하는 것으로 컨벤션을 재정비했다. 또 pr을 올릴 때에는 close #이슈번호로 구현이 완료된 이슈를 닫는 것으로 했다.

좋은 코드란 '이유있는 코드'이다. 왜 이런 코드로 구현했는지에 답하지 못한다면 좋은 코드가 아니라는 것을 이 과정에서 깨달았다. 짧지만 합동세미나 리드를 맡으면서 스스로도 많은 성장을 할 수 있었고, 나를 포함한 클라이언트 모두가 앱잼에서도 자신있게 참여할 수 있도록 만반의 준비를 도운 것 같아 뿌듯했다.
github 솝딜리버리
https://github.com/SOPT-FROZEN/client

앱잼에서 팀을 선택하는 나름대로의 몇 가지 기준이 있었다. 우선은 Deep한 서비스를 개발하고 싶었다. 웹 프론트엔드가 경험할 수 있는 챌린징한 기술이 있기를 바랐고, 장기적으로 릴리즈에 시간을 쏟을 만큼 규모가 있는 프로젝트였으면 했다. 또한 내가 기획 의도에 공감할 수 있는 서비스여야 했다. 개발자는 개발자로서 뿐만 아니라 사용자로서도 피드백을 전달할 수 있고, 그래야만 내가 애정을 가지고 프로젝트에 참여할 수 있다고 생각했기 때문이다.
이런 점들에 있어서 온사이즈는 내가 딱 원하던 서비스였다. 크롬 익스텐션이라는 챌린징한 기술을 경험해볼 수 있고, 내가 평소에 온라인 쇼핑을 하면서 가지고 있던 Paintpoint를 정확히 잡아냈기 때문에 충분히 설득력있는 서비스라고 생각했다. 무엇보다 크롬 익스텐션이라는 생소한 개념으로 웹 서비스여야만 하는 이유를 풀어낸다는 점에서 더욱 매력적으로 다가왔다. 웹 개발자로서 솔직히 말한다면, 이러한 정당성있는 웹 서비스가 많아져서 웹 사용성에 기여해주기를 바랐다.
역시나 익스텐션 개발은 쉽지 않았다. 레퍼런스가 적었기 때문에 초반부터 세팅에 난항을 겪었다. 다행히 크롬에 공식문서가 잘 되어있어서 익스텐션에 익숙해지는 데에는 별 무리가 없었지만, 라우팅이 안되는 등 확실히 기술적 제약이 많았다. 그렇게 앱잽 기간 5주 중에 3주는 공부와 세팅에 시간을 쏟아야했다. 이 기간 동안에 웹 리드 개발자가 피나는 노력을 해주었다.
리드를 도와 초반 세팅을 어떻게 해야할지를 함께 고민했다. Next.js 사용 여부에 대한 논의가 나왔는데, routing이 안되는 익스텐션의 특성상 상태관리로 페이지 전환을 해주어야 했기 때문에 결국 React로 익스텐션과 웹사이트를 한 레포에서 개발하기로 했다. 하지만 익스텐션과 웹사이트 개발을 한 레포에서 하게 되면 구조도 복잡해질 뿐더러 프로그램이 무거워질 것으로 예상해, 익스텐션과 웹사이트 레포를 분리하면 어떻겠냐고 제안을 했고, 내 의견이 채택되어 익스텐션은 React로, 웹사이트는 Next로 개발하게 되었다.
하지만 레포를 분리한다고 단점이 없는 것은 아니었다. 바로 익스텐션과 웹사이트가 상태를 공유할 수 없다는 단점이 있었다. 그중에서도 사용자의 로그인 상태를 공유할 수 없다는 큰 단점이 있었는데, 이를 localStorage를 사용하여 해결하였고 결국 성황리에 데모데이 시연까지 할 수 있었다.
앱잼기간 동안 리드의 역할이 얼마나 중요한지 깨달았다. 우리 웹 팀원 전부가 많은 노력을 기울였지만, 특히 리드 개발자가 많은 노력을 해준 덕분에 모두가 성장할 수 있었다. Next부터 React Query까지, 처음 써본 기술들이었지만 리드의 도움으로 단기간 내에 익숙해질 수 있었다. 하지만 리드에게 많은 짐을 지운것 같아 미안했고, 앞으로의 릴리즈 기간 동안에는 다른 팀원들도 살펴보면서 우리 팀 리드를 닮아가야겠다고 다짐했다.
또 한가지 아쉬웠던 점은 개발 일정 안배였다. 5주라는 기간이 있었지만 사실상 본격적으로 개발한 기간은 2주에 불과했다. 일정이 밀리는 바람에 배포를 기간내에 하지 못하기도 했다. 앞으로는 데드라인이 없는 만큼 팀원과 함께 개발 스케줄을 구체적으로 짜고, 이를 다른 파트와도 공유하여 릴리즈에 차질이 없게끔 할 것이다.
개발을 하면서 익스텐션과 웹사이트 간 데이터 공유를 위해 localStorage로 많은 것을 해결했었다. 이 부분에 대해서 데모데이 날 멘토로 오신 TEO님께서 많은 조언을 해주셔서 감사했다. 멘토님께서 해주신 조언들을 바탕으로 팀원들과 회고를 진행해 IndexedDB나 위젯기반 프로그래밍의 도입도 고려해보고 리팩토링도 진행할 예정이다.
github 온사이즈
https://github.com/OWN-SIZE/onsize-website
데모데이날 많은 사람들이 우리 부스에 와서 온사이즈를 체험해보고, 써보고 싶다는 얘기도 많이 들었고 서비스에 대해 많은 칭찬을 들었다. 유종의 미를 거둔 것 같아 뿌듯했다. 하지만 사실 이제부터가 시작이다. 우리 서비스가 릴리즈까지 되기 위해서는 앱잼 기간에 부족했던 점을 돌이켜보고, 앞으로 더 달려나가야 한다.
솝트는 나에게 웹 개발 인생의 2막을 열어준 고마운 존재이다. 이 곳에서 만난 모두가 정말 좋은 사람들이었고, 하나같이 다 열정적인 사람들이었기에 배울 점도 많았다. 이런 솝트에 들어올 수 있어서 정말 감사하다고 생각한다. 앞으로의 내 커리어에 있어서도 솝트에서의 추억과 경험들은 끝까지 잊지 못할 것 같다.