[우리 FISA] 클라우드 서비스 개발 - 17주차

프로젝트 2주차 빠이팅

📌 1. 이번 주 목표 (Goals of the Week)

• 카카오맵 API 완성 (FE,BE 모두)
• 메인 Wallet 페이지 소스 분리하기
• 개발 인프라 및 CI/CD 구성하기 (Git Runner 사용)

🛠️ 2. 진행한 작업 (Tasks Completed)

백엔드

• 바우처 사용처 좌표 기반 조회 API 구현
• Entity 통합 하기
• 공공 데이터 포탈의 가맹점 데이터 파이썬으로 DB에 입력하기

프론트엔드

• 지도 중심 좌표 검색 기능 구현
• 반응형 레이아웃 개선

✅ 3. 잘한 점 (What Went Well)

• 계속 충돌이 발생했던 Entity를 통합하자고 제안한 것, 폴더 구조를 가시성 좋게 변경한 것
• 데이터를 직접 찾아서 이를 DB화 하고 조회성능을 측정하고 개선하려고 한 점
• 팀원의 코드를 적극적으로 리뷰하려고 했던 점
• 200만 튜플의 데이터를 카카오맵에서 위치 기반으로 조회하기 위해 MYSQL의 Spartial_index를 고려한 것

⚠️ 4. 어려웠던 점 / 문제 상황 (What Was Challenging)

• Entity 통합하면서 필드가 추가되거나 이름이 변경되어서 수정하는데 어려움을 겪음

• 인프라 환경 구성 당시 온 프레미스에 CD 작업을 해야해서 Git Runner로 해결함.

• Store를 검색할 때 위도와 경도 기반으로 조회하는데 풀 스캔이 발생해서 Point 자료형을 추가하고 인덱스로 성능을 개선함.

• 프로젝트를 하면서 팀원의 성향이 매우 달라서 나는 처음부터 구조를 맞추고 느려도 확실하게 가는걸 선호하지만 팀원은 속도를 추구해서 갈등이 발생했는데, 어떻게 해야할지 모르겠어서 힘들었다

• 팀원간의 실력차가 있고, 역할을 분배해야 할텐데 이게 어렵다

• 스크럼과 리뷰시간을 두기로 했지만, 잘 지켜지지 못했다. 난 이런걸 꼭 해보고 싶은데 강요하긴 어렵기에, 다시 얘기를 해봐야 할 것 같다.

🔁 5. 개선 방안 (Improvements)

• 가시성이 나빴던 폴더 구조를 모두 변경하고, 엔티티를 통합했다.
• 카카오맵 같은 경우 fixed로 button들이 잡혀 있어서 이를 반응형으로 개선하고 검색 범위를 좀 더 넓혀야 할 것 같다.
• 팀원이 특정 기술을 사용할 때 전체적으로 논의를 거쳐서 도입하는게 좋을 것 같다. QueryDsl은 장점이 명확하지만, spring에서 친절하게 지원하고 있진 않아서 설정과 추가파일이 많이 생기는게 단점이다.
• 갈등을 피하지 말고 팀원과 얘기해서 이번주 프로젝트의 방향과 가치관을 확실히 정해야 할 것 같다.

🌱 6. 느낀 점 (Reflection)

개발계 인프라 구성

우리팀은 FISA에서 주신 데스크탑에 개발계 환경을 구성해두었다. 예전에 인턴시절에 개발계 환경을 통해 서로 작업상황을 볼 수 있고 눈으로 테스트 했던게 기억에 남아 이를 계획했다.

우리는 develop 브랜치의 git action으로 CI/CD를 구축해두고, ubuntu에 도커 컴포즈를 사용해서 스프링부트, nginx, next.js,mysql을 세팅해두었다. DB에는 테스트 데이터들을 채워두고 이걸 crontab으로 자동백업하게 두었다. Docker에 띄운 mysql이다 보니 혹시 날아가면 어쩌지 하는 걱정이 있어서 mount해두었지만, 따로 백업을 하도록 구축해두었다.

근데 git action에서 우리 ubuntu를 찾을 수 없는 이슈가 있었다.
게이트 웨이에서 우리 pc로 라우팅되는 경로를 찾을 수 없기 때문이다. 그래서 로컬 피씨에 Git Runner를 설치해두고 CI/CD 파이프라인의 행위 주체를 git action이 아니라 우리 pc환경에서 동작하게끔 설정해두었다.

아직, 팀원들은 개발계가 익숙하진 않지만 내가 개발계를 도입한 이유는
1. 쉽고 빠르다 프로젝트 진행중이다 보니 시간도 매우 중요한 요소이다. 이전에 프로젝트에서 한번 해봤기에, 빠르게 수행할 자신이 있었다.
2. 디벨롭에 머지가 되면 자동으로 CI/CD가 되기 때문에, 짧은 릴리즈를 목표로 하고 스크럼을 통해 작업상황을 공유하는것 뿐만 아니라 개발계를 통해 눈으로 작업상황을 함께 볼 수 있다는 장점이다.
3. 본인 로컬에서는 정상적으로 동작하지만, 실제 배포후 오류가 발생하는 경우가 허다하다. 개발계는 함께 같은 DB를 바라보고 사용함으로써 팀원 모두가 함께 오류를 찾을 수 있고, 더 신경써서 개발할 수 있게 된다.

작업 방식에 대한 가치관 충돌

우리팀은 지난주 갈등을 겪었다. 우리팀은 일단 엔티티가 맞지 않고 따로 본인이 필요한 엔티티를 만들어 머지할때마다 충돌이 발생하는 상황이였다. 나는 설계가 부족하다고 느꼈고 이 단계에 있어서는 시간이 오래걸려도 확실하게 하고 넘어가는 성향인지라, 이 점이 불만이었다. 정답은 없으니까 팀원에게 맞추기를 선택하고 프런트엔드 작업을 수행했다.

또, 우리팀은 애자일 프로세스를 도입하기로 했고, 매일 스크럼과 오후에는 리뷰를 하자고 약속했었다. 하지만 내 시각에선 나나 누군가 오늘 스크럼 하자고 하지 않으면 진행이 되지 않고 잔소리를 하는듯한 느낌이 들어서 점차 피하게 됐다. 이런 상황에서 당연히 분위기는 좋지 않았고 난 회피하기만 했던것같다.

금요일에 오후에 팀원이 얘기를 하자고 제안했고, 우린 스태프룸에서 진솔하게 대화를 했다. 이때의 논점은 남은 두 팀원에게 역할을 어떻게 분배할지 였지만 말 나온 김에 난 내가 가지고 있던 생각을 다 말했다.

개인적으로 이번 프로젝트에서의 차별점을 기술뿐만 아니라 어떤 개발문화로도 가져가고 싶었다. 서로의 코드를 진심으로 리뷰도 하고 기술에 대해 함께 고민하고 얘기하고 테스트도 튼튼하게 짜고 Wiki와 노션을 통해 문서화하면서 짜임새있는 프로젝트를 목표로 했었다. 이렇게 하고 싶었던 이유는 GPT가 너무나 코드를 잘 짜주고 우리팀이 개발이 절대 느리다고 생각이 들지 않았다. 그래서, 내가 지금 짜고 있는 이 코드 다른 사람은 못 짤까? 라는 생각이 많이 드는데 절대 YES라고 말하긴 어려웠다. 그럼 어떤게 우린 차별화 할 수 있을까 하다가 다른 부트캠프인 소프티어 깃허브를 참고 했었고 거기엔 누가 봐도 함께 협업하고 논의했다는것을 한 눈에 볼 수 있었다. 정리하면, 우리가 기술적 차별화를 두는것도 좋지만 미미하다고 생각한다. 이 프로젝트를 다시 꺼내어 봤을때 함께 밤새고 고민하고 기술에 대해 토의하고 이런 과정이 기억되기를 바랬던 것 같다.

그래서 이런 얘기들을 팀원에게 하고, 팀원들도 본인들 코드 짜기도 바쁜데 다른걸 신경쓰기 어려웠다고 했고 나도 수긍했다. 나도 어느정도 욕심을 내려두고 팀의 방향을 맞추기로 했다. 그리고 틀어져있던 엔티티에 대한 불만도 말했는데 모두가 불편을 겪고 있어서 이걸 다시 맞춘뒤 작업하기로 했다.

또 하나의 해결해야할 부분은 현재 우리팀 2명은 백엔드 경험이 없다. 나도 물론 잘하지 않기에, 부족하다고 생각하는것은 아니지만 이 두 팀원이 백엔드를 하고 싶어하고 또 이미 하고 있다. 근데 좀 더 중요한 코어 기능을 원하고 있는데 중요한건 PM과 PL인 우리에게 얘기를 하지 못하고 막내 팀원한테만 얘기를 하고 있어서 목표하는것과 어떤 기능을 하고싶은지 얘기해봐야 할 것 같다. 사실, 나는 gpt가 있어서 누구나 어떤 기능이든 시간을 투자하면 구현할 수 있다고 생각해서 전혀 상관이 없지만 다른 팀원은 걱정이 된다고 해서 함께 얘기하면서 풀어보려고 합니다~

여담이긴 한데, 채널 하나 파서 슬랙으로 알림봇 해두니까 엄청 편해요