[PetFit] 젝트 활동 1차 리뷰

📌 도입

3개월간 진행했던 젝트(JECT) 프로젝트를 돌아보며, 기술적인 문제 해결부터 협업 과정에서의 의사결정, 그리고 회고를 통해 성장한 부분까지 정리해보았습니다.

특히 카카오 로그인 버그를 해결했던 경험, MVP 기능을 정의하고 우선순위를 조정했던 과정, 리뷰위크를 고려한 개발 전략, 그리고 ADR을 활용해 의사결정 방식을 개선했던 경험이 이번 글의 중심 내용입니다.

📌 기간 내 활동 중 마주한 문제 상황과 해결 과정 (기술, 협업 등)

프로젝트 진행 과정에서 카카오 로그인 버그라는 중요한 문제를 마주했습니다. 원인은 리디렉션 URI의 정의를 잘못했기 때문이었는데, 인증 과정에서 예상하지 못한 흐름이 발생하면서 로그인 플로우가 정상적으로 동작하지 않았습니다.

 

처음에는 단순히 API 호출의 문제라고 생각했지만, 실제로는 리디렉션 URI가 인증 서버와 프론트엔드 애플리케이션 간의 연결을 정확히 보장하지 못한 것이 핵심 원인이었습니다. 이 과정에서 팀 내부에 “인증 과정이 어떻게 이어지는가?”라는 기본적인 흐름에 대한 이해 차이가 존재한다는 것을 깨달았습니다.

 

이를 해결하기 위해 인증 과정 시퀀스 다이어그램을 직접 그려서 공유했습니다. 이 다이어그램을 통해 사용자 → 카카오 서버 → 백엔드 서버 → 프론트엔드로 이어지는 요청-응답 흐름을 시각화했고, 팀원들과 함께 문제 지점을 빠르게 파악할 수 있었습니다. 결과적으로 잘못 설정된 리디렉션 URI를 수정하고, 로그인 과정이 정상적으로 동작하도록 개선할 수 있었습니다.

왼쪽: 로그인/회원가입 프로세스, 오른쪽: 토큰 재발급 프로세스

 

이 경험을 통해 단순히 버그를 해결하는 데 그치지 않고, 팀 전체가 인증 프로세스에 대한 공통 이해를 갖추게 된 점이 큰 성과였습니다.

📌 기획·디자인·개발 과정에서의 고민과 의사결정 기준

저는 프로젝트 전반에서 회의 내용을 기준으로 의사결정을 내리려는 태도를 유지했습니다. 회의에서 논의되는 목적과 목표를 계속해서 상기시키며, 대화가 평행선을 달리거나 진도가 지체될 때는 다시 처음으로 돌아가 “우리가 왜 이 일을 하는가?”를 되짚는 방식으로 접근했습니다.

서비스 구상 시 기획 목표

 

이러한 태도는 기획 단계에서 기능의 필요성을 검토할 때, 디자인 단계에서 UI의 통일성과 UX의 편리성을 고민할 때, 개발 단계에서 구현 방식이나 기술 선택을 결정할 때 모두 중요한 기준이 되었습니다.

 

특히, 처음 MVP 1.0을 구상할 때는 다양한 기능 후보들이 있었지만, 프로젝트 기간이 3개월로 제한되어 있었고 빠른 개발을 통해 실제 유저의 피드백을 얻는 것이 최우선 목표였기 때문에, 우선순위가 낮은 기능은 과감히 제외했습니다.

 

또한 서비스의 초기 목표가 “정보 파편화를 해결하고 편리한 UX를 제공하는 것”이었기에, 기획 단계에서부터 통일성 있는 UI 설계를 중요하게 여겼습니다. 이를 통해 사용자가 기능에 쉽게 접근할 수 있도록 유도했습니다.

📌 프로젝트 진행 중 특히 중요하게 여긴 포인트

프로젝트 초반에 저는 우리 동아리의 특성상 리뷰위크(Review Week)라는 일정이 있다는 점에 주목했습니다. 리뷰위크가 존재하는 특성상, 폭포수 방식으로 진행하기보다는 MVP 1.0, 2.0으로 나누어 단계적으로 개발하는 것이 효율적이라고 판단했습니다.

 

따라서 회의 시간에 “최대한 개발 규모를 작게 쪼개고, 리뷰위크 전에 이미 MVP 한 사이클을 마칠 수 있도록 빠른 개발 방식을 적용하자”라는 의견을 강하게 주장했습니다. 이렇게 하면 리뷰위크 이전에 한 차례 사용자 피드백을 받을 수 있고, 이후에는 개선된 MVP 2.0으로 발전시킬 수 있다는 장점이 있었습니다.

왼: MVP 방식, 오: 폭포수 방식

이러한 접근은 실제로 프로젝트 진행 속도를 빠르게 하는 데 기여했으며, 팀원들도 작은 단위의 개발과 피드백 사이클을 반복하는 것의 필요성에 공감할 수 있었습니다.

[참고] 아래는 해당 경험을 토대로 얻은 인사이트를 정리한 글입니다.
https://dekoms-coding.tistory.com/186

 

 

📌 스스로 부족하다고 느낀 점과 그 개선 과정 및 결과

리뷰위크 이후, 저는 프로젝트를 이어가면서 프로젝트 경험을 갈무리할 필요성을 느꼈습니다. 그래서 팀에 회고 진행을 제안했고, 실제 회의 시간에 KPT 회고를 통해 각자의 피드백을 수집할 수 있었습니다.

 

그 과정에서 저는 제 스스로 부족한 점을 명확히 확인했습니다. 특히 회의 중 의견을 제시할 때 근거가 부족하고 경험적 감각에 의존하는 경우가 많았습니다. 예를 들어, “느낌이 좋지 않다”, “시간을 효율적으로 쓰지 못할 것 같다”, “중간 의사소통 리소스가 더 많이 든다”와 같은 피드백을 자주 했지만, 이는 팀원들에게 설득력 있는 공감대를 형성하기에는 부족했습니다. 결국 제가 주장하는 의견에 대해 스스로도 확신을 갖지 못하는 상황이 종종 발생했습니다.

KPT 회고 피드백 P(Problem) 섹션 중 일부

 

이런 문제를 스스로 인지해왔기에 꾸준히 해결 방안을 고민하는 과정에서 저는 ADR(Architecture Decision Record)이라는 의사결정 기록 방식을 새롭게 접하게 되었고, 이를 활용하여 의견을 정리하고 제시하기 시작했습니다. ADR은 문제 상황, 고려했던 선택지, 최종 결론, 그에 따른 근거를 하나의 문서로 남기는 방식인데, 이를 통해 제 의견을 체계적으로 전달할 수 있었습니다.

[참고] 아래는 해당 방식을 적용하는 과정을 정리한 글입니다. (아직 수정중입니다)
https://dekoms-coding.tistory.com/262
https://dekoms-coding.tistory.com/266

 

결과적으로 이전 KPT 회고에서 팀원들에게 지적받았던 문제, 즉 말할 때 호흡이나 흐름이 일정하지 않고, 전체 맥락을 모른 채 일부만 아는 내용을 근거로 이야기하는 문제를 자연스럽게 개선할 수 있었습니다. 이제는 단순한 감각에 의존하지 않고, 명확한 맥락과 근거를 기반으로 팀원들에게 의견을 전달할 수 있게 되었습니다.

KPT 회고 전체

 

 

이 활동은 젝트에서 진행한 프로젝트입니다.
젝트 공식 홈페이지: https://ject.kr

젝트