서론

SSAFY 공통 프로젝트를 마무리하고 회고를 적으면서 동아리에서 진행했던 쩝쩝박사도 배포가 되었는데, 여기에 대한 회고도 간단하게라도 적어야하지 않을까? 라는 마음으로 작성했다.

개발

개발 시작에서 배포까지 꽤나 지연된 프로젝트다보니 생각보다 기억나는 부분이 꽤 적다. 그럼에도 배포가 완료되어서 이 과정과 중간에 생긴 이슈를 작성해봤다.

프로젝트 시작

2022년 7월부터 개발을 시작했는데, 이전부터 기획이 진행되어 와이어 프레임이 나온 상태에서 BE 인원이 먼저 API 개발을 진행할 수 있도록 먼저 인원이 투입되었다. 당시 5명으로 시작했다. 당시 동아리에서 쓰지 않던 JPA를 사용하기로 했고, 그에 따라 엔티티 설계에 시간이 조금 들었다.

엔티티 설계를 담당한 인원이 정말 잘했는데, 엔티티 설계와 기능 하나를 개발한 뒤에 취업에 성공하면서 한두달 가량 뒤에 빠지게 되었다. 취업을 축하하면서 4명의 팀원으로 프로젝트를 이어갔고, 나는 다른 팀원과 함께 로그인 & 유저를 담당하여 개발을 진행했다.

Spring Security

특히 Spring Security를 사용해보자는 이야기에 반감을 표했으나, 결국 Spring Security를 사용해서 진행하게 되었다. SNS 로그인을 제외한 유저 부분을 내가 맡기로 했는데, 지금 생각해보면 그 때 Spring Security를 쓰자는 말을 뜯어 말렸어야 했지 않았을까.

당시에 Spring Security는 생각보다 인터넷에 있는 자료들은 버전이 낮아 변경된 문법이 많았다. 개발을 진행하면서 다른 사람이 Spring Security를 사용할 것까지 생각하면 문서화도 진행해야 했기 때문에 시간이 꽤나 오래 걸렸다. 심지어 당시에 장기 현장 실습을 나가 있어서 해가 떠있는 동안에는 회사에서 개발하고 해가 지면 집에서 Spring Security 공부를 했었다. 8월 쯤엔 2주가량 2~4시간 정도 자면서 회사에 나가고 밤엔 공부 및 개발을 하는 생활을 하다보니 많이 예민해졌던 기억이 난다.

동아리에서 보통 프로젝트를 6개월 정도로 진행했고, 쩝쩝박사도 마찬가지였다. 그래서 보통 1달 정도로 API 개발을 어느 정도 완성하고 이후 클라이언트를 투입하고 클라이언트 쪽에서 부족한 요구사항에 대한 유지보수 및 버그 픽스 등을 진행하는게 일반적이었다. 하지만 새로운 기술에 대해 공부와 병행하며 도입하니 API 개발 자체가 2달 정도로 지연되어 다른 클라이언트 트랙에 미안한 마음이 꽤 들었다.

API 완성

그렇게 2달 정도 바득바득 하고 나니 API 같은 윤곽이 잡혔다. 기본적인 기능이 제공되었고, 유저와 리뷰 같은 서로 의존성이 존재하는 기능 간의 연결도 완성됐다. 다만 상점 API 개발에 있어서 저작권 및 요금에 대해 기획과 잦은 마찰이 있어서 메인 기능이 제일 늦춰지는 문제가 있었다.

로그인 기능에 FE가 붙으면서 당시에 Refresh Token에 대해서 많이 찾아보고 고민했다. Refresh Token을 어디 저장해야 하는가? 그러면 세션과 다른 점이 뭘까? Refresh Token을 탈취 당한다면? 꼬리에 꼬리를 물면서 당시 Refresh Token에 대해서 주변에 물어보러 다니고 많이 고민했다. 그 과정에서 Refresh Token에 대한 개념 뿐만 아니라 어떤 개념을 깊게 고민하고 각각의 견해에 대해 생각하는 방법에 대해 많이 배웠다.

뿐만 아니라 이메일 인증을 처리하면서 안드로이드 측의 요청으로 Firebase의 Dynamic Link를 사용해서 디바이스에 따라 리다이렉션을 별도로 지정했다. 원래는 JS를 통해 리다이렉션을 구성했지만, 브라우저에서 자동 리다이렉션을 막는다는 것을 보고 변경하게 되었다.

개발 지연

그렇게 API의 기본적인 윤곽이 잡히고, 장기 현장 실습을 진행하는 동안 프로젝트가 뭔가 이상해졌다. 로그인 연결 이후 별 다른 API 사용이 보이지 않고, API에 대한 수정 요청이나 문제 제기가 이뤄지지 않았다. 지금 생각하면 아마 당시 BE 인원의 수가 많아 별도의 프로젝트를 추가로 진행했는데, 나머지 클라이언트 트랙이 다른 프로젝트에 투입되면서 쩝쩝박사 프로젝트에 큰 힘을 못쓴 것으로 생각된다.

거기에 당시 나는 장기 현장 실습에서 기초 교육이 마무리되고 실무에 투입되었다. 새로운 과제가 계속 주어졌기 때문에 지연되고 있는 프로젝트에 신경 쓰지 못했다. 1주마다 진행했던 프로젝트 회의에선 API가 완성된 채로 별도의 유지보수 요청이 없었기 때문에 우리끼리 API를 보수하면서 진행했다.

거기에 우리 동아리는 교내 동아리인 만큼 시험 기간에 대해 휴식 기간을 잠깐씩 가졌는데, 대부분 졸업반이고 실습 활동을 하는 인원이 대부분이라 BE는 별도의 휴식을 진행하지 않았다. 원래는 이게 실습 등 다른 활동과 병행하면서 뒤쳐진 진도를 따라가기 위함이었는데, 개발이 지연되면서 오히려 우리가 질문하면 시험 기간에 겹쳐 2주 간 기획이나 디자인에 대한 답변을 얻지 못하기 일쑤였다.

결국 내가 현장 실습을 했던 6개월이라는 시간 동안 프로젝트는 완성되지 못했고, 개발 인원의 불만만 키운 채 다음 단계로 나아가질 못했다.

그대로 프로젝트 인원 전체가 프로젝트와 함께 동결되었다.

1차 해동

여기서 사실 API는 4개월 차쯤 서로 코드를 보고 문제점을 찾아 유지보수 하는 작업도 거의 끝났고, 인원들이 갈피를 못잡기 시작했다. 분명 실제로 작동하게 되면 문제가 생길텐데, Swagger로만 작업하고 있으니 더 이상 진행하지 못하고 불안하기만 했다.

거기에 6개월이 지나고, 나를 포함한 2명이 현장 실습이 종료되었지만 나머지 2명이 현장 실습을 시작했다. 시간이 계속 지연되면서 다른 동아리원이 안된다고 생각했는지 클라이언트 측에서 API를 사용하려 했는데, 또 다른 인원을 통해서 내 귀에 API가 기획과 달라 사용하기에 불완전하다는 이야기가 들렸다.

문제가 무엇인지 살펴보았다. 동아리에 별도로 기획 팀이 없다보니 디자인 팀이 아이디어가 아닌 세부 기획을 같이 진행했다. 와이어 프레임에서 화면 설계로 넘어오면서 디자인이 수정되었고, 그에 따라 기획이 조금씩 변경된 것이다. 클라이언트 입장에선 디자인된 화면으로 컴포넌트를 개발하니, API가 기획가 맞지 않은 상태였다.

그래서 API와 기획이 다른 부분을 찾아 하나씩 기능을 수정해나갔는데, 여기서 새로운 문제가 생겼다. 디자인 측에서 디자인을 이렇게 해보고 저렇게 해보면서 기능이 생겼다 사라졌다 했다. API 개발하는 입장에선 1~2주씩 들여서 개발하고 있으면 해당 기능이 사라지고, 해당 페이지에서 필요한 API를 다 추출해서 완성했다고 생각했는데 필요한 API가 생기기도 했다. 한 번은 어떤 기능인지 이해가 되지 않아 질문을 남겼는데, 답변보다 기능 삭제가 빨리 이뤄진 경우도 있었다.

1차 배포

결국 디자인은 계속 수정되고, API도 완성 상태에서 계속 미완성 상태로 내려갔다. 그런 상황이다보니 전체적으로 리딩할 사람이 필요하다고 생각했는지 새로운 인원을 투입했다. PM으로 투입된 인원은 개발이 지연되는 이유에 대해 의견을 받았고, 나는 가감없이 기획 변경으로 인한 API 변경을 1순위, 인력 공백에 따른 개발 및 리뷰 지연을 2순위로 뽑았다.

기획 변경에 대한 불만이 꽤 많았는지 하루는 날을 잡았다. 기획을 보면서 1차 배포 전까지 기획 변경이 없이 진행할 수 있도록 의견을 교환했다. 나는 내가 이럴 줄 몰랐는데, 개발자가 안된다고 말했다의 주인공이 됐다.

예를 들면, 유저가 이메일, 아이디, 비밀번호, 닉네임을 모두 수정할 수 있게 화면이 구성된 경우가 있었다. 아이디가 변경되는 이유는 유저 검색 시 자신을 더 잘 표현할 수 있는 아이디가 필요하다는 이유였다. 이 경우 회원에 대한 고윳값이 하나도 남지 않아, 로그인 뿐만 아니라 DB에 남는 이력에 대해서 어떤 회원이 어떤 회원인지 알 수가 없었다. 이외의 비슷한 상황에 대해 의견을 전달해야 했다.

이외에도 이번엔 몇 개월의 시간을 더 가지고 1차 배포를 진행하기로 했기 때문에 기간 상 실행할 수 없는 기능에 대해서도 할 수 없다는 의사를 비췄다.

그렇게 다시 개발이 진행되는듯 싶었으나, 현장 실습으로 인한 인원 공백 등의 문제와 함께 다시 클라이언트가 참여하기 힘들어지면서 회원 측 기능을 완성하고 다시 프로젝트가 동결됐다.

Production 배포

이후 나머지 2명의 현장 실습도 종료됐다. 현장 실습이 6개월 정도니 프로젝트 시작한지 약 1년 정도 된 것이다. 그동안 나는 SSAFY에 들어갔고, 다른 프로젝트 인원 1명도 나중에 알고 보니 나와 같은 기수로 입과했다고 한다. 다른 인원은 취업했다는 소식도 들렸다.

간간히 API 사용과 API 유지보수 요청이 있었지만 전체적인 프로젝트는 진행되지 못했고, 프로젝트 회의도 간격이 길어지다가 그만하게 되면서 사실상 프로젝트를 끝내려고 했다.

그런데 프로젝트를 Production 배포할 것이란 소식과 함께 다시 개발하러 일어나라는 소식을 받는다. QA 시트를 준비하고, SSAFY를 가고 다른 일을 하면서 직접 참여는 못했지만 QA 소식에 대해 들을 수 있었다.

그렇게 SSAFY를 진행하거나 취업한 인원이 끌어올려져 다시 API 유지보수를 진행했다. 해동된 캡틴 아메리카 마냥 알고 있던 API를 담당 인원은 어디 가고 새로운 인원과 합을 맞춰 프로젝트를 진행했다. 그리고 약 한 달 만에 프로젝트 Production 배포까지 설정하여 배포가 이뤄졌다.

그렇게 1년 6개월간 냉동 해동을 반복해 흐물흐물해진 프로젝트가 끝이 났다. 생각보다 API를 수정할 내용은 없었고 이렇게 한 달 만에 배포할 수 있는 내용이란 것이 제일 충격이었다.

후기

실패에 대한 후기

6개월짜리 프로젝트가 1년 반이 걸리면서 누가 봐도 규모에 비해 너무 많은 시간이 소요된 프로젝트가 됐다. 그렇다고 완성도가 그렇게 뛰어난지 잘 모르겠다. 냉정히 프로젝트에 실패라는 타이틀을 걸 수도 있을 것이다.

하지만 실패에 대한 회고도 필요하다고 생각한다. 실패를 실패로 두기 보단 왜 실패했는지 찾아보고 배울 점을 배우고 고칠 점은 고쳐야 한다.

프로젝트를 이끌어 나가는 건 누구

프로젝트를 진행하면서 수평적인 구조가 오히려 아쉬웠다. 제대로 PM이 있는 것도 아니고, BE를 리딩하는 인원이 다른 프로젝트와 병행하면서 프로젝트에 대해서 제대로 토의가 이뤄지지 못했다. 결국은 BE 팀원들의 의견을 모아 목소리를 낼 필요가 있었는데, 수평적인 구조에 갇히고 다른 트랙을 잘 모른다는 점에 갇혀서 제대로 된 의견 교환이 이뤄지지 못했다.

그렇다면 프로젝트는 누가 어떻게 이끌어 가는가. 결국은 우리 모두라는 말을 할 수밖에 없다. 일방적인 의견은 언젠간 부러지고 만다. 우리는 의견의 마찰이 필요하다. 부딪혀서 더 단단한 의견을 만들어야 한다. 이번 프로젝트는 그런 점이 너무 부족했다.

기획자와 한판 승부

프로젝트가 지연되고 여러 번 재기동하면서 부딪힌 문제는 기획, 디자인과의 견해차였다. 기획 내지 디자이너는 대개 정확히 어떤 구조로 프로젝트가 구성되는지 모른다. 이를 설득하고 타협점을 찾아내는 것이 필요하다.

하지만 처음 기획과 부딪히는 것은 힘든 일이다. 여러 번 개발하면서 경험이 쌓인 것이 아니라면 확답을 주기도 힘들고, 업무 영역을 침범하는 행위인지도 걱정된다. 그렇지만 기획과 부딪히면서 제일 중요한 부분은 서로서로 모른다는 점이다. 되는 것과 안 되는 것을 구분하고, 불필요한 수정에 드는 시간 소요를 줄이기 위한 과정이다. 그러니 다음엔 힘껏 부딪힘에 두려워하지 말아야 겠다고 생각이 든다.

기술적으로 아쉬운 점

프로젝트 중간에 SSAFY에 참여하면서 프로젝트에 유지보수에 집중하면서 기능적으로 아쉬운 부분이 많이 남았다.

유저 프로필 Presigned URL

유저의 프로필을 업로드하는 API가 있는데, 이에 대해 단순히 이미지 파일을 전송하는 API를 구성했다. 이런 이미지 전송 API는 이미지의 크기가 클수록 커넥션이 오래 걸릴 뿐만 아니라 이를 리사이징 하는 과정이 서버에 꽤 큰 부하가 가해진다.

그래서 클라이언트에서 미리 적절한 이미지로 수정하여 Presigned URL로 버킷에 올리고 서버에 알려 부하를 피할 수 있는데, 이 부분을 개발 당시 고려하지 못했다.

Dynamic Link 서비스 종료

프로젝트 당시에 JS로 자동 리다이렉션이 종료되어 Dynamic Link를 사용한다고 얘기했는데, QA 당시 유지보수를 위해 문서를 확인하면서 Dynamic Link가 곧 종료된다는 것을 확인했다. 프로젝트 기간이 너무 길어짐에 따라 연결된 서비스가 먼저 종료되는 것이다. 이에 따른 추가적인 유지보수가 필요할텐데 제대로 진행하지 못해 아쉬운 부분이 많이 남는다.

최종 후기

프로젝트를 마무리하면서 드는 생각은 회의감이었다. 약 3년에서 4년가량의 동아리 활동을 지속했고, 특히 쩝쩝박사는 1년 반이라는 시간이 소요된 프로젝트였다. 하지만 소위 말하는 누군가의 멱살 캐리로 당장 끝날 프로젝트가 이렇게 지연됐다는 것이 안타까움을 많이 느꼈다. 특히 이전 동아리 프로젝트도 API를 완성 후 클라이언트 미완성으로 미배포 종료되었는데, 이번에도 거의 비슷한 양상이라 더욱 안타까운 것 같다.

이젠 SSAFY에서 프로젝트를 진행하고, 취업 준비에 본격적으로 들어가면서 더 이상 동아리에서의 프로젝트가 힘들 것 같다. 이번에 쩝쩝박사를 끝낸 인원이 동아리의 다음 프로젝트를 잘 이끌 것이라고 생각한다. 회고에 적은 일 이외에도 크고 작은 일이 몇 번 있었는데, 시간이 오래되면서 어렴풋이 기억난다. 여러모로 아쉬움이 많이 드는 프로젝트였다.