몇개월간 준비했던 졸업 작품 프로젝트 Dandi 전시가 끝났다.

기획

프로젝트를 진행하면서 가장 어려웠던 점은 기획이었다. 팀원은 iOS 개발자, 디자이너, 서버개발자(나)로 이뤄졌고 기획자는 없었다. 따라서, 팀원 3명이서 함께 기획을 했어야 했다. 전문적인 기획 프로세스가 있을텐데, 우리는 그냥 부딪혔다. 각자 여러 주제들을 가져오고 토의하고 날씨에 따른 옷 기록/공유 라는 주제로 최종 결정했다.

기획의 어려움

12월부터 기획을 시작했고, 큰 주제는 동일했지만 세부적인 기획이 지속적으로 변경되었다. 변경되는 과정에서, 어떻게 기획을 더 좋게 디벨롭 시킬지 고민하는 것이 어려웠다. 새로 적용하려는 것이 사용자에게 좋을지, 사용자에게 불필요하고 귀찮은 작업일지 판단하는 것이 쉽지 않았다.

결국 우리의 프로젝트이다

최종 전시 1달 전인 4월 말에 프로젝트의 중간 전시가 있었다. 중간 전시를 평가하시는 다수의 교수님들은 좋은 평가를 하셨다. 하지만, 한 분이 우리 서비스에 공감을 하지 못하셨다. 근본적으로, 우리가 해결하려는 문제에 대해 공감하지 못하셨고 문제에 대한 해결 방식으로 다른 것을 제시하셨다. 또한, AI를 해야한다는 피드백을 하셨다. 12월부터 기획을 하고 2월부터 개발했던 프로젝트가 부정 당하는 듯했다. 팀원들과 교수님을 열심히 설득하려했지만, 교수님은 설득되지 않으셨다.

많이 속상했다. 하지만, 내 마음보다는 팀원들의 마음이 더 신경쓰였다. 나이와 권위가 비례된다고 생각하는 사람은 아니지만, 제일 연장자로써 속상함을 표현하기보단 중심을 잡고 팀원들을 케어해야겠다는 생각이 들었고 팀원들과 대화를 많이 하려고 했다.

사실, 매년 학부에서 진행되는 졸업 작품 프로젝트에 대한 이야기를 들어보면 빈번하게 있는 일이다. 교수님의 강한 피드백으로 낙심하는 일. 여기서 프로젝트의 전체적인 방향이 바뀌어 버리는 일도 허다했다. 하지만, 해당 교수님을 제외한 많은 사람들이 우리가 해결하려는 문제에 대한 많은 공감을 해줬다. 또한, 우리들의 생각을 더 믿기로 했다.

기록

개발일지

개발은 2월부터 시작했다. 이번 프로젝트를 하면서 꾸준하게 개발일지를 작성하는 것을 목표로 했다. 하지만, 2개월 동안은 3개의 개발일지를 작성하고 남은 2개월은 개발 일지를 작성하지 못했다. 졸업작품 개발을 진행하면서 학교 수업과 과제들을 해냈어야 했다. 사실 핑계라고 생각한다. 개발일지를 작성하는 방식을 다르게 가져갔어야 했다. 개발과 기록을 어느정도 병행했어야 했다. 개발을 진행하면서 소주제에 대한 글을 병행적으로 작성하는 것은 이제 익숙하다. 하지만, 개발일지는 그런 소주제의 글들이 합쳐져서 1개월 가량의 개발 과정을 적는 것이다. 따라서, 1개월의 마지막에 개발일지를 한꺼번에 쓰려고 했던 점이 문제였던 것 같다.

졸업작품 개발 글

하지만, 소주제에 대한 글은 16개로 꽤나 작성했다. 4개월의 개발 기간동안 개발일지까지 졸업작품과 관련한 19개의 글을 작성했다. 내가 처음 접해보는 기술, 개선, 설계적인 고민들에 대해서는 모두 기록하려 했다.

개발

개발적인 부분은 아쉬운 점이 많았다. 생각보다 구현해야 할 기능이 많았고 기능을 구현하는데 급급하다보니 내가 좋은 개발을 했는가에 대한 확신이 들지 않았다.

아키텍처

많은 것들을 시도해보려 했지만 결과적으로 새로운 아키텍처 적용밖에 하지 못했던 것 같다. 이전 프로젝트에서는 계층형 아키텍처를 사용했지만, 이번에는 헥사고날 아키텍처를 사용해보았다. 레이어드 아키텍처에서 헥사고날 아키텍처로의 전환기를 작성했었다. 하지만, 프로젝트를 완성하는 과정에서 아키텍처에 대해 더 느낀 점들이 있어 다시 리뷰하는 글을 작성해보려 한다.

작은 새로운 변화들

이전 프로젝트와 작은 다른 점은 아래들과 같다.

• FeignClient
• Apple OAuth
• S3 LocalStack
• Log4j2(이전 프로젝트에서는 Logback)
• Swagger(이전 프로젝트에서는 RestDocs)
• 외부 API 호출 캐싱

기술을 선택할 때, 그냥 사용하는 것이 아니라 대체 기술들과 비교하면서 근거를 통해 기술 채택을 하려고 했다.

참조 관계

이전 프로젝트에서는 객체 참조, 패키지 참조들이 조금은 무분별하게 이뤄졌다. 그래서 이번에는 이 참조 관계를 조금 견고히 하려고 했다. 객체의 경우에는 함께 조회되는 경우에만 객체 참조 관계를 맺도록 했다. 패키지 참조는 참조가 한 방향으로만 흐르도록 했다. 요구 사항에 따라 양방향 참조가 발생하는 것은 DI와 이벤트 방식을 통해 해결했다.

개선사항

아직 하지 못한 것이 많다. 멀티 모듈로의 전환, S3 보안 설정, Controller, Service의 책임 분리, QueryDSL로의 전환, 쿼리 분석 등.

이건 앞으로 계속해서 개선해나가야겠다.

협업

갈등 해결

클라이언트 개발자와 갈등을 겪은 적이 있다. 하지만, 갈등이 더 커지기 전에 빠르게 대화하면서 해결할 수 있었다. 각자가 처한 상황과 생각이 다르기 때문에 갈등을 발생할 수 밖에 없다. 이때 갈등을 외면하지말고 대화를 통해 해결하는 것이 참 중요한 것 같다.

나는 개발하는 기계가 아니라 함께 개발을 하는 사람이다.

너무 REST와 HTTP 기본 규약에 집착을 했다. 사실 API 변경에 응하면 팀원은 더 쉽게 개발할 수 있고, 서버에 성능적인 문제도 없을 뿐더러, 변경을 하는데 드는 시간도 크지 않았다. 하지만, 나는 그깟 기본 규약들을 무조건 지키려고 했다. 이런 규약과 같은 것을 넘어서, 앞으로는 크리티컬 한 문제가 발생하는 것이 아니거나 지금 할 일들이 그렇게 많지가 않다면 최대한 열린 자세로 요청을 검토해야겠다. 규약이라는 것이 중요하지만, 그것보다 더 중요한 것은 팀원과 협업을 잘 해나가는 것을 깨달았다.

마치며

몇개월 간, 졸업작품을 준비하며 정말 많은 고민과 노력을 했다. 나 자신에게 고생했다는 말을 하고 싶다. Dandi 끝난 프로젝트가 아니라 계속 앞으로 개선시켜 나가야겠다. Dandi를 통해 더 성장했고 앞으로 더 많이 성장하자.

마지막으로, 함께 해준 팀원들에게 나 때문에 속상한 일이 있었을 수도 있었을텐데 함께 해줘서 고맙고 영광이었다는 말을 하고 싶다.