WISEIN을 회고하며
한 줄 요약: 처음 올라보는 벽이었지만, 발판으로 만들고 성장했다!
WiseIN : 사내 질문-답변 및 정보 공유 게시판
https://drive.google.com/file/d/1StWomudtwidbAGWLvdteZjv3COANMUYK/view?usp=drivesdk
처음 기획한 의도
- 부장님의 말씀: Common Util은 사용만 하게 되니, 실제로 만들어 보는 경험을 해 보아라
- 나의 계획: Util만 만드는 것보다, 3년차 미만끼리 다 같이 모여서 작은 토이 프로젝트를 해 보자.
목적
- 금융권이다 보니 레거시한 환경에서 일할 수밖에 없다. 보다 최신 스택에 대한 경험을 해 보자.
- 구성원 결속력 강화
- 회사에 도움이 되는 기획을 해 보자.
WiseIN은 사내 프로젝트로, 사내 질문-답변을 골자로 한 웹 프로젝트였다.
처음 시작은 부장님께서 술자리 중 던지신 이야기였다. Common 쪽은 만드는 일보다 사용하게 되는 일이 많으니, 저연차끼리 만나서 한번 만들어 보라는.
하지만 그것만 하기에는 조금 아쉬웠다. 바퀴만 만든다는 생각이 들었다. 이 바퀴를 만들었을 때 어디로 여행을 가는지 알게 되면, 과정이 더 재밌을 텐데.
기왕 만드는 것, 우리 회사 안에서 사용될 법한 재미있는 프로덕트를 만들면 어떨까? 하는 생각까지 닿았고, 머리를 맞대기 시작했다.
기획 의도는 단순하였다. 원거리에서 파견 근무하는 경우가 많은 만큼 질문과 답변을 토대로 성장하는 개발 분야의 주요한 성장 루트를 놓치고 있다는 생각이 들었다.
사용하는 툴도 도메인 특성을 반영하고 있어, 그 사이트에서는 오랜 기간 써 왔지만 사이트에 처음 가는 사람은 낯선 툴이 되는 경우가 많았다. 오래 사용된 툴이라 검색해도 많은 자료가 나오지 않았다. 이 부분은 경험한 사람이 주로 대답해 줄 수 있을 듯했다.
또한 파견 근무지가 전반적으로 비슷한데, 어디에 어떠한 음식점이 있는지를 대화를 토대로만 알게 되다 보니 아쉽다는 생각이 들었다.
이러한 정보들을 비대면-비동기적으로 통신할 수 있는 사이트가 있으면 어떨까! 하는 생각이 들어 기획하게 되었다.
무엇을 했는가?
기획 / 설계 / 디자인
기획 단에서는 사용자가 회사 내 구성원인 만큼 구성원들에게 전반적인 사이트 필요 기능에 대한 의견을 받아 정리하고, 어떤 부분에 어떤 것들을 배치할지 UI/UX에 대해 고민하였다.
화면 구상한 디자인은 Framer로 제작하여, 해당 툴 안에서 소스를 받아볼 수 있으므로 빠르게 화면에 대한 퍼블리싱이 가능하도록 처리하였다.
이후 아키텍처 설계에 있어서는 Spring Boot와 JSP, Vanila JS, Maria DB를 선택하였다.
스프링 부트를 선택한 이유는, 스프링 환경 설정 등이 한두 명의 경험이 전부가 될 것 같고 환경 설정에 시간을 쓰기보다 개발에 보다 시간을 쏟았으면 해서 선택하였다.
그리고 화면의 경우, 화면 단위 설계를 토대로 한 게시판당 한 명의 기능을 담당하기 위해, 그리고 커먼 유틸 제작에 방점이 있는 만큼 화면 개발 허들을 일정 부분 감소시키기 위해 JSP를 선택하였다.
또한 제이쿼리와 같은 다른 라이브러리에 의존하지 않고 오롯이 JS만 사용하는 경험을 토대로 모던 JS에 대한 익숙함을 키우기 위해 Vanila JS를 선택하였다.
DB의 경우 오라클과 MySQL 사이에서 크게 고민했는데, 그 이유는 도메인 특성상 오라클을 사용하는 곳이 많았기 때문이다.
하지만 우리는 이후 해당 사이트를 사내에서 정보 공유성 페이지로 사용하고자 했고, 이럴 때 오라클을 사용하게 되면 라이센스 비용에 대해서 걱정해야 했다.
따라서 해당 비용이 없는 Maria DB로 최종적인 결정을 내리게 되었다.
기능
- 회원 가입 및 인증 / 정보 수정
- 회원 가입, 비밀번호 찾기, 회원정보수정 (이미지 등록)
- 맛집 게시판 CRUD
- 네이버 지도 API 활용 맛집리뷰 등록, 폐업 메일 신고
- 파일 유틸
- 커먼 유틸 제작팀
- 디자인 및 기획, 문서
- 프로젝트 매니지먼트
나는 크게 회원 기능 / 맛집 게시판 / 공통 유틸 : 파일 / 공통 JS 유틸 / 디자인 및 기획, 문서 및 프로젝트 매니지먼트를 맡아 진행하였다.
1. 회원 기능
먼저 회원의 경우, 스프링 시큐리티 인증 처리를 토대로 한 세션 기반의 회원 기능을 구현하였다.
화면을 JSP로 선택한 만큼 세션 기반의 인증 처리를 구현하였으며, 시큐리티 인증을 토대로 화면 접근 등에 대한 권한을 부여하였다.
또한 다른 팀원 분이 제작해 주신 메일 모듈을 토대로 인증 키를 발송해 메일 인증과 임시 비밀번호를 발급받을 수 있도록 하였고, 이미지를 등록할 수 있는 url 기반 파일 서버를 연결하여 회원 이미지를 로딩할 수 있도록 처리하였다.
2. 맛집 CRUD
카카오 지도 API를 베이스로 한 맛집 게시판을 구현하였다.
해당 게시판은 카카오 지도에서 맛집을 검색하고, 원하는 곳을 선택해서 별점을 토대로 추천 게시글을 남길 수 있는 기능이다.
맛집 게시판을 구현할 때 겪었던, 후기 0개일 때의 맛집 비활성화 처리에 대해서는 게시글을 작성할 예정이다.
또한 맛집이 폐업했을 경우, 관리자에게 메일을 보낼 수 있는 기능을 만들어 두었다.
메일을 수신한 관리자는 메일 안의 버튼을 누르게 되면 해당 맛집을 Hidden 처리할 수 있게 된다.
1차 계층 형식의 게시판이라 고민을 많이 했는데, 그 당시 할 수 있었던 최선의 방안으로 구현했던 것 같다.
기회가 된다면 더 좋은 방법이 있을지 리팩토링을 해 보고 싶은 부분 중 하나이다.
3. 파일 유틸: TOAST 연동 / 회원 프로필 사진 업로드
NHN에서 구현한 TOAST UI 에디터를 가지고 와서 게시글 에디터로 사용하였다.
TOAST를 선택한 이유는 다음과 같았다.
- 마크다운 문서로 작성 및 미리보기가 가능하다는 점
- 타 에디터 프로그램에 비해 훨씬 최신화된 업데이트를 지원하고 있었음
- React, Vue 등의 클라이언트 단 리팩토링 시 빠른 전환이 가능하도록 이미 지원이 되어 있음
에디터의 파일 업로드 기능을 변경하여 파일 서버 통신 - 우리 쪽 서버 통신 기능을 추가하고, 게시글에 사진을 첨부할 수 있게 처리하였다.
파일 테이블은 게시판의 종류와 게시글 번호, 파일 서버에 올라간 url을 담아서 관리하도록 했다.
이때 고민하게 된 문제가, 사진 업로드 시 파일 서버 통신 후 → 우리 쪽 파일 테이블에도 행이 추가된다는 것이었다.
파일 테이블 사진 관리 로직은 다음과 같다.
- 게시글 업로드 전 랜덤 해시를 토대로 DB에 쌓이게 하고,
- 게시글 업로드 후 해당 파일들의 해시를 업로드 된 글 번호로 업데이트하는 방식이다.
이 경우 생기는 문제점은 업로드되지 않은 이미지가 계속해서 테이블에 남아 있다는 것과, 해당 이미지는 글에 사용되지 않음에도 불구하고 파일 서버에 업로드되어 있다는 점이다.
또한 비슷한 문제가 이미 업로드된 글에도 남아 있는데, 글을 수정할 때 삭제한 이미지의 경우 똑같이 사용되지 않는 이미지가 테이블에 남아 있고, 파일 서버에도 남아 있게 된다.
이 부분은 TBD인데, 회원 사진 업로드의 경우 업로드시 DEL_YN이 Y로 업데이트되도록 해 두었으나, 게시판은 그렇지 못하다.
따라서 이 부분에 대해서는 글 업로드 시 실제로 사용하고 있는지를 글에서 체크해, 해당 파일 UUID가 존재하지 않을 경우 DEL_YN을 Y로 업데이트하려고 한다.
또한 해시일 경우 / DEL_YN가 Y로 업데이트된 지 일주일이 지난 것의 경우 배치를 토대로 이미지 서버의 사진을 삭제하고 싶다.
지금 생각한 로직의 성능 부하에 대해서도 계속 생각이 꼬리를 물어서, 파일 유틸도 리팩토링을 해 보고 싶은 부분 중 하나이다.
4. 공통 JS 유틸
공통 JS의 경우 회사 과장님께 도움 요청을 드리고, 사용하시는 프로젝트의 Common 쪽 파일을 받았다.
구현이 어떻게 되어 있는지는 보지 않은 채로 타이틀만 가지고 와서 배분해 구현해 보았다. 여러모로 재미있는 경험이 된 것 같다.
이걸 만들 때는 ChatGPT가 없었는데… 있었을 때의 결과물도 궁금해서 다 같이 한번 더 해 보자고 제안하고 싶은 부분이긴 하다.
다들 그렇게 즐거워하지 않으실 수도 있지만….. (ㅋㅋ같이 공부해요!!!)
5. 디자인 및 기획, 문서 및 프로젝트 매니지먼트
여기는 사실 좀 새로운 부분이었다. 전반적인 디자인이나 기획에 대해서 정리하면서, 현재 회사 업무 내에서 고민해보지 못했을 부분들에 대해 고민해 볼 기회를 가졌던 것 같다.
가령, 화면을 그리는 툴에서 퍼블리싱을 위해 어떤 것까지 대응을 해 주면 좋을지, dim 처리의 경우에도 어떤 식으로 하면 사용자가 더 편리할지, 이 팝업의 사이즈는 어떻게 되어야 하는지, 모바일에서 대응하기 위해서는 어떤 식으로 버튼 배치를 하는 게 더 좋은지 등…
웹 프로덕트를 만드는 사람으로써 해 보면 좋을 법한 UI/UX적 고민들을 할 수 있는 시간이었다.
또한 전반적인 일정 관리를 맡게 되면서, 누구에게 어떠한 것을 할당하면 그 사람이 좋아할지 / 잘해낼 수 있을지, 또한 언제까지 어떤 아웃풋을 기대할 수 있는지에 대한 아웃라인을 정할 수 있다는 것도 재미있는 부분이었다.
무엇이 힘들었지만, 그로 인해 얻었는가?
여태 좋은 것만 이야기한 듯해 고백하자면… 사실은 힘겨운 부분도 존재했다.
물론 프로덕트를 만들면서 좋은 부분만 있을 수는 없을 것이다. 하지만 초행길이라서 피할 수 있었던 문제를 피하지 못한 것들이 꽤나 존재했던 것 같다.
원래 계획으로는 모두 회사 병행이 있는 만큼 빠르게 기능을 정리하고 배분해 3~6개월 내로 마무리하는 것이 목표였다.
그런데 중도에 함께 진행하던 분이 갑작스럽게 퇴사를 하고, 그 분이 담당하던 업무적인 부분과 사이드 프로젝트 부분을 함께 도맡게 되면서 일정 관리에 차질이 생기기 시작했다.
지속적인 야근으로 저녁 식사를 하고 퇴근하는 일이 잦았는데, 프로젝트 일정 배분과 관리, 내 몫의 코딩을 병행해야 했다.
또, 내 일정에 대해서만 차질이 생기면 나만 밤을 새우면 됐지만, 팀원 두 분의 정보처리기사 병행이 묶여 있었다.
이 분들께는 일정을 과중해 쥐여드리기가 죄송했고, 또한 정보처리기사 취득 자체가 회사 업무에도 영향이 있는 부분이기 때문에 더욱 강요할 수 없었다.
하지만 마침표를 찍고 싶었다. 중간에 포기하는 일은 모두에게 아쉬움만이 될 뿐이고, 또한 성취감도 떨어질 것이라는 생각을 했다.
앞에 놓인 벽은 넘어뜨리면 발판이 된다는 말을 잊지 않는다.
이번 기회에 겪었던 것들로 나는 다음 번 과제에 있어서 더 좋은 발판을 가지게 되었다고 믿는다.
그 발판을 위해, 다시금 이 벽을 겪지 않도록 복기해 보려고 한다.
무엇을 하면 더 좋았을까?
앞서 언급한 것처럼 중간중간 멤버들의 급작스러운 하차, 정보처리기사 준비 등으로 일정이 많은 부분 딜레이되었던 것이 사실이다.
나는 팀원들이 이 프로젝트보다 해당 부분들을 삶에서 더 주요하게 가져가기를 원했기에, 프로젝트에 억지로 집중하도록 만들고 싶지 않았다. 따라서 주간 회의는 매주 진행하였지만, 타이트하게 일정을 삼지는 않았다.
다만, 점차 프로젝트가 루즈해짐을 느끼고, 기능 단위를 좁힌 부분들이 존재한다.
이렇게 보다 작은 기능 개발의 완성을 타깃 삼게 되면서 여러 가지의 아쉬운 점이 있었으나,
개인적으로 가장 아쉽게 여긴 부분은 프로젝트 기간을 할당하는 것과 기술적 구조를 전달하는 것의 미진함이었다.
프로젝트 기간 할당의 미흡함
첫 번째, 프로젝트 기간을 할당하는 것에 있어서는, 전체 구조를 생각했을 때 1년이 걸릴 프로젝트라고 생각하지 않는다.
회사와 수험 등의 일정을 고려하고도, 나머지 시간을 효율적으로 사용하지 못한 듯해 아쉬움이 있었고, 기간 할당에서 내가 구조적으로 못 잡고 넘어간 것은 크게 두 가지 원인이라는 파악을 했다.
1. 요구사항 세분화가 필요했으나 진행하지 못함
- 기능 단위로 쪼개는 것: 단위와 통합 테스트를 거치는 과정에 있어서 가장 필요한 선작업임에도 불구, 개략적인 요구사항만을 작성함
2. 요구 사항 세분화를 통한 WBS를 작성하지 못함
- 해당 문서의 존재 여부를 알지 못했음
- 누구에게 어떤 기능을 할당해야 할지 알지 못했음 (두 번째 기술적 구조 전달과 연결)
상기 두 가지 지점이 프로젝트의 큰 pain point 였던 것 같고, 완성까지 1년이 걸리게 된 이유인 것 같다.
기술적 구조 전달의 미흡함
두 번째, 기술적 구조를 전달하는 것에 있어서도 두 가지의 아쉬운 점을 가지고 있다.
1. 전체적인 구조를 잡는 것이 미흡했음
- 구현을 기능 단위별로 할당하다 보니 구조적 통일성이 되어 있지 않음 → 어디에서는 A 방식으로 구현되어 있으나 어디에서는 B 방식으로 되어 있는 등
2. 구성 인원의 기술 역량 파악과 맞는 배분을 하지 못함 & 역량을 성장시키기 위한 정확하고 빠른 방법론을 제시하지 못함
이는 나 또한 지식적으로 미흡했던 부분 때문에 일어난 일 같아 공부에 대한 각성도 되었다.
NEXT?
그러나 포기하지 않고 완성했다는 것에 작은 의의를 가지고 있으며, 기획부터 자동 배포까지 경험해 보았다는 점을 이번 프로젝트의 가장 큰 소득으로 삼고 싶다.
와이즈인은 제법 힘든 프로젝트였지만, 나에게는 성장 경험이었다.
함께했던 팀원 분들이 지금까지도 대장님이라는 호칭으로 불러 주시는데, 믿고 따라 주신 것이 감사하고, 함께 성장할 수 있었음에 더더욱 감사하다.
노력이 전부라고 생각하지 않는다. 배움에 있어 당연히 동반되는 것을 노력이자, 도전이라고 생각한다.
앞으로도 더 좋은 윈윈을 위해서 정진해야지. 다짐해 본다.