[KUSITMS 31th] 서울우유 기업프로젝트를 마치며

😃 프로젝트를 마치며....

by qkrtnals 2025. 3. 26. 14:34

⏰ 진행기간 : 2025.02.17-2025.03.13

이렇게 보면 한달 정도의 기간이 있으니 괜찮지 않은가? 라고 생각하실 수 있겠지만 이 시간 내에 기획, 디자인이 나오고 이를 개발까지 진행하기에는 매우매우 부족한 시간이었다 ..

정신없이 개발하느라 중간에 회고한건 고작 한번.. 큐스팅 벌금도 한번 내기..

이제 밋업 프로젝트 들어가기 전에 기업프로젝트 회고를 해보면 좋을 것 같아 기업 프로젝트 과정을 돌아보고자 한다.

📁 프로젝트 소개

팀원 : 기획 2 디자인 2 프론트 2 백엔드 2

프로젝트 : 서울우유_지능형 세금계산서 검증 시스템 구축

팀명 : 음메
팀명의 의미 : 서울우유 하면? 소! 🐄 소가 내는 소리 “음메”는 우유의 시작을 의미하는 가장 직관적인 사운드입니다 🔊 즉, 우리는 서울우유 프로젝트의 본질을 가장 잘 표현하는 팀이라는 뜻

깃허브 링크 : https://github.com/KUSITMS-31th-Seoul-Milk-team2/frontend (자그마치 438 커밋이라는 엄청난 자부심)

🖥️ 기술 스택

Frontend
: react - ts - vite ⇒ esbuild를 이용하여 속도가 빠르다.(cra[create-react-app의 10배]) + 다양한 라이브러리 제공

: styled-component ⇒ 동적스타일링이 가능, css파일 불필요(깔끔한 폴더관리)

: recoil ⇒ react를 만든곳에서 출시한 전용 상태관리 라이브러리(react와 사고방식이 일치) + 비동기 데이터 관리가 간편
(-> 중간에 react version 문제로 zustand로 변경)

Backend

: Java 17 , Spring Boot 3.3.4 , Spring Data JPA , Docker, Github Actions, Swagger, GCP, Oracle DB

📍기획 & 디자인과의 협업

기획이 프로젝트의 첫 초석을 잡는다고 생각하는데 그만큼 팀빌딩이 발표된 아침부터 회의를 진행한 우리 기획들... 항상 프로젝트에서 개발자들끼리만 있는 경우가 많아서 기획을 도맡게 되는 경우가 정말 많았다. 근데 역시 왜 전문가들과 함께 해야하는지 알겠네 화면설계서, 와이어프레임까지 만들어봤는데 처음보는 WBS, UX 라이팅 검증 등 본격적으로 프로젝트를 하는 기분이 들어서 좋았다.

서울우유가 제출을 원하는 서류가 엄청 많았다.

기획자들이 서류 작성하기도 빡셌을텐데 군말 없이 진행해줘 너무 감사했던....

서울우유 과제는 과제를 어떻게 해석하냐에 따라 본사, 대리점 등 다양한 유저 타입이 나올 수 있었는데 우리 팀은 본사에 집중하기로 했고 결과를 스포하자면 좋은 평을 받았다. 아무래도 대리점를 유저로 설정하면 대리점의 업무 강도는 높아질 수밖에 없는게 우려 사항이었던 듯 하다.

기획팀 만큼이나 고생한게 디자인팀인데 짧은 시간인 만큼 개발 시간을 확보해야하다보니 기획 디자인이 엄청 달릴 수 밖에 없었다... 우리 기디 너무 고생했어... 💞

가장 감동했던 포인트는 짧은 시간에 개발을 진행하며 디자인적 요소가 지켜지지 않았던 부분들이 있는데 그 부분들을 장표로 정리해 프론트에게 전달해줬다.

이렇게 확실한 디자인 QA를 받아본건 너무 처음이라 감동을 받고 issue에 깔끔히 정리 후 하나씩 반영을 진행했다. 확실히 전문가의 말을 들어야한다. 다른게 있나? 라는 생각이 들었지만 고쳐두고 보니 엄청 다르다. 내 눈을 믿지 말고 디자이너들 말만 맹신할거다.

결과론적으로 사용성을 제일 많이 고려한 팀이라는 쾌거를 얻게 되었다! (힣 뿌듯행)

💻 개발팀과의 협업

사실 개발팀 3명과는 프로젝트 기간 내내 같이 살았다고 봐도 무방하다.

PM님 수업 하나 다녀오는 동안 300개는 기본으로 찍어버리는 그런 팀이었다. 그래서 회의를 잡지도 않았는데 완벽한 상황 공유가 가능했다. 그리고 나머지 3명한테 고마웠던 점은 자신의 파트가 아니어도, 4** 에러가 나서 프론트에러임에도 백엔드 팀도 함께 달려와서 함께 고민해주던 그 과정이 너무 고마웠다. 제일 웃겼던건 최종 과제 전에 노션이 터져서 노션 502 에러다 라고 했는데 백엔드 둘이 우리 서버 터진 줄 알고 해결해줄라고 후다다닥 달려온게 너무 감동이고 웃겼다 ㅋㅋㅋㅋㅋㅋㅋㅋㅋ

어쩌다보니 프론트엔드 팀은 새벽형 , 백엔드 팀은 아침형이라서 프론트엔드 팀이 새벽에 연동하면서 안되는 부분 톡에 우루루 적어놓으면 백엔드가 일찍 일어나서 싹 고쳐두는 식으로 하니 24시간 풀가동으로 프로젝트가 진행되었다. 팀끼리 아침형 / 새벽형 맞는 것도 엄청 중요한 것 같다는 생각이 들게 되었다.

우리 팀의 메인 기능은 감히 ✅ 업로드 ✅라고 할 수 있는데 이걸 다중 업로드까지 구현해준 우리 팀의 대단함을 느꼈다. API가 정말 프론트엔드 친화적이라는게 느껴지긴했다. (감사하다구요~)

💻 나의 역할

나는 크게
- 레이아웃
- 세금계산서 조회
- 마이페이지
- 로그인
- vercel 배포
- 관리자 : 사용자 관리
를 담당했다.

이 중 제일 힘들었던 건 세금계산서 조회였다. 일단 로직이 엄청 여러번 바뀐 것도 있고 애증의 react-datepicker와의 만남이 이뤄졌다. 이는 한 포스팅을 잡고 적어야할 듯 하다. 아니고선 너무 억울할거다. 그래도 뮤지컬 프로젝트에서도 검색 부분을 맡았었는데 그 때보다 더 많이 성장한 채 검색창을 다시 구현해 볼 수 있어 좋았다.

그리고 로그인은 쿠키가 자꾸 날라가는 에러를 맛봤다.. 이게 문제가 쿠키를 사용해서 인증 로직을 사용하는 순간은 괜찮은데 다른 경로로 넘어가는 순간 실종되는게 문제였다. 결국 마지막 날까지 못고쳐서 이에 대해서는 더 알아볼 필요가 있을 것 같다.

그래서 쿠키 대신 다른 인증 방법을 찾고자 했지만 결국 구현할 시간이 부족해 body 값에 담을 수 밖에 없었다... 이게 젤 아쉬웠던 부분이다. 첫 Auth 로직에 도전한 만큼 완벽하게 구현해내고 싶었는데 문제를 찾아내지 못한게 너무 아쉬웠다. 밋업 때도 꼭 Auth 부분을 맡아서 부족함 없이 Auth 로직을 구현해내도록 성장하고 싶다.

하지만 로그인 화면을 만들면서 floating label(내가 그냥 이름 붙인거다)에 대해 알게 되었으니 좋다. 나는 placeholder가 올라간다고 생각했는데 다른 방식으로 마치 placeholder가 올라가는 것처럼 구현하는게 아직도 너무 신기하다. (placeholder를 움직이려고 하니 절대 안움직이더라.. 이거 때문에 새벽에 자긴했다. )

마이페이지는 userInfo를 가볍게 넣고 , 가벼운 개인정보 수정만이 가능하게 진행을 했다. 원래 모든 프로필을 수정해야하나? 라는 생각이 들었는데 우리가 구현 중인 이 프로젝트는 서울우유 백오피스 웹사이트의 일부분이라는 점을 고려해 개발했다. 보통 기업은 전체 DB에 사원 정보를 넣어두고 이를 관리하는 관리자에게 프로필 변경 요청을 진행한다. 또한 입사할 때 개인정보를 모두 확실하게 받기 때문에 사원이 직접 변경할 건 없을 것이라고 생각해서 , 홈택스 간편로그인 방법, 비밀번호 정도만 수정할 수 있게 했다. 원래는 공동인증서를 자동으로 불러와 인증할 수 있는 로직을 구현하고 싶었으나 시간 관계상 제안 사항으로 남겼다.

또한 비밀번호는 초기에 사용자 계정을 만드는 로직으로 생각한 우리의 플로우 상 전화번호와 동일하게 자동으로 만들도록 제작했다. 그렇기에, 보안의 문제가 크다고 생각이 들어 비밀번호 변경 툴팁을 제작했다. 하지만 이는 신규 사원들에게만 유용한 기능이지 이미 비밀번호를 변경한 사원들한테는 의미가 없다고 생각이 들었다. 그래서 가입한지 3일이 안된 사원들에게만 띄우는 형식으로 진행했다. 이를 누르면 바로 비밀번호 변경으로 이동해서 바로 비밀번호를 바꿀 수 있도록 했다.

앞서 말했듯이 사용자 권한 관리는 사원의 계정을 관리자가 만들어서 제공하는 방식으로 진행했는데 , 관리자가 그만둔 사원의 계정을 삭제하고 , 신규 사원의 계정은 직접 만들어주는 로직을 생각했다. 내가 인턴을 했을때는 내가 직접 회원가입을 하는 것이 아니라 내가 제출한 개인 정보를 가지고 계정을 만들어 ID,PW를 제공받는 식으로 했었어서 이를 생각해봤을 때 관리자가 부서장과 같은 높은 직급이기에 이 로직이 맞다는 생각을 했다. 그래서 전체 DB가 있다는 가정하에 이름과 사번을 입력하고 이를 생성할 수 있도록 했다. 물론 지금 개발을 진행할 때는 전체 사원 DB에 접근할 수 없기 때문에 사원을 만들면 계정이 알아서 만들어지는 형태로 진행했다. (원래 API에는 제한을 뒀지만 개발 진행할 때는 제한을 풀었다.)

레이아웃도 UT 이후에 가장 많이 바뀐 부분이다. 레이아웃이 처음에는 네비게이션 없이 홈을 통해야하는 불편함이 있었는데 네비게이션을 추가하고 , 모달 형태로 마이페이지, 로그아웃 등 개인적인 업무를 모달 내에서 해결할 수 있도록 수정했다. 근데 이는 네비게이션이 생기면서 사용성이 매우 높아졌기 때문에 수정하길 너무 잘한 부분이라고 생각한다.

마지막으로 세금 계산서 조회 상세 페이지이다. 근데 이 부분에서 이미지를 보여주는 컴포넌트가 있는데 이게 마지막에 https 설정을 하고 보안을 높였더니 이미지가 저장되는 부분과 보안이 안맞아서 이미지 조회를 할 수 없었던 점이 아쉬웠다. secure coding을 지켜야했기에 , https는 필수라고 생각했는데 이 부분을 고려하지 않고 개발을 진행한게 아쉬웠다. 심지어 나는 코딩을 할 때 localhost에서 테스트를 하고 main을 배포해둔 형식이었어서 늦은 QA에서 발견된 부분이 너무 아쉬웠다.

그리고 vercel 배포도 새로고침하면 404에러가 나는 터무니 없는 에러가 났는데 이건 같은 고통을 느낀 여러 개발자들이 미리 적어놨더라.. 나도 까먹기 전에 회고를 적을거다.

🧐 프로젝트를 마무리하며 배운점

사실 배운점을 적자 하면 이 포스팅에 적힌 모든 부분을 배웠던 것 같다. 객관적으로 날 생각해봤을 때 프론트엔드 개발 실력이 최고라고 생각하지 않는다. 배울 점이 너무 많은 사람이라고 생각이 드는데 짧은 기간동안 정말 많이 성장했다는 점에서 난 나에게 칭찬을 주고싶다. 모바일 화면을 시간상 구현하지 못해 반응형에 대해 아직 부족하다는 점 , 공통된 컴포넌트가 내 화면에서는 부족해서 상태관리 라이브러리를 공부하긴했지만 아직 써보지 못했다는 점, 그리고 몇몇 아쉬움이 남았던 파트가 있지만 그것보다 많이 배우고 소중한 사람들을 얻어서 좋았다. 개발 기간을 확보해주기 위해 아침점심저녁밤새벽을 가리지 않고 회의해 결과물을 빠르게 넘겨줬던 기획 인우언니 , 수빈언니 / 디자인 은서 , 정민이에게 감사함을 표하고 싶다. 그리고 아침점심저녁밤새벽 잘 때 빼고, 자는 시간을 줄이며 프론트엔드들이 조금이라도 편하게 연동하게 열심히 고민해준 백엔드 호영오빠 ,창현오빠 / 함께 로직 고민해주고 잠 줄여가며 메인인 업로드 로직 담당 해준 용원오빠에게도 감사함을 표하고 싶다! 음메 포에버입니다 😉🐮