이 플랫폼은 사용자들이 자신이 키우는 식물에 대한 정보를 공유하고, 다른 사용자들과 함께 공유하며 감상할 수 있는 SNS 서비스입니다. 각 사용자는 자신의 프로필을 생성하여 자신이 키우는 식물에 대한 정보를 공유할 수 있으며, 서비스 내에서 다른 사용자들이 업로드한 식물에 대한 정보를 볼 수 있습니다.
사용자와 관련된 데이터베이스를 설계하면서 테이블을 정규화하기 위해 노력했습니다. 이를 통해 데이터의 중복을 최소화하고 무결성을 향상시키는 방법으로 데이터베이스를 최적화했습니다.
Follow 테이블은 사용자 간의 팔로우 관계를 효율적으로 관리할 수 있도록 설계했습니다. Follow 테이블은 Primary Key로 사용될 필드와 팔로우한 회원을 식별하는 필드, 그리고 팔로우를 받은 회원을 식별하는 필드로 구성되어 있습니다. 이렇게 팔로우 관계를 별도의 테이블로 분리함으로써 Member 테이블에서 사용자 정보와 팔로우 관계를 각각 저장할 수 있었습니다.
팔로우 관계의 변경은 Follow 테이블에서 처리되므로 Member 테이블의 사용자 정보는 영향을 받지 않습니다. 팔로우 관계의 추가, 삭제, 업데이트 등의 조작은 Follow 테이블에서 이루어지며, Member 테이블은 사용자 정보에 대한 일관성을 유지할 수 있었습니다. 이를 통해 팔로우 관계의 변경이 간단하고 효율적으로 이루어질 수 있었습니다.
마찬가지로, Like 테이블은 좋아요 관련 정보를 효율적으로 저장하기 위해 설계되었습니다. Primary Key로 사용될 필드와 좋아요를 받은 게시물을 식별하는 필드, 그리고 좋아요를 한 회원을 식별하는 필드가 포함되어 있습니다. Like 테이블을 통해 Member 테이블과의 관계를 설정하여 좋아요 관계를 효율적으로 관리할 수 있었습니다.
정규화를 적용하면서 성능과 설계 사이의 트레이드 오프를 고려한 테이블 설계를 통해 데이터의 중복을 최소화하고 일관성을 유지할 수 있었습니다. 이는 사용자와 관련된 데이터를 효율적으로 저장하고 처리하는데 도움이 되었습니다.
애플리케이션 배포 이후 특정 기능이 동작하지 않는 문제가 발생했습니다. 스택 트레이스(stack trace)를 분석하면서 데이터베이스간 문법 차이로 인해 발생하는 문제라는 것을 파악했습니다. 기존의 네이티브 쿼리가 로컬환경의 H2 DB에서는 동작했지만 MySQL을 사용하는 RDS 환경에서는 동작하지 않은 것입니다.
해당 문제를 해결하기 위해 JPQL(Java Persistence Query Language)을 활용하였고, 방언(Dialect)을 활용하여 데이터베이스 벤더에 독립적인 쿼리를 작성할 수 있었습니다.
JPQL을 사용하여 쿼리를 개선한 결과, RDS와 로컬에서 같은 쿼리로 문제 없이 시스템을 동작시킬 수 있었습니다. 이렇 JPA를 활용하여 특정 벤더에 종속적인 코드를 개선한 경험을 통해 방언이라는 개념을 이해할 수 있게 되었습니다.
프로젝트를 진행 했을 때, 개발한 API 에 대한 문서를 일일이 작성하여 공유하고 있었습니다. 그러나 이러한 방식은 실제 엔드포인트와 문서의 일치를 보장하기 어려웠고 불필요한 커뮤니케이션으로 시간을 낭비하는 문제가 있었습니다. 이에 따라 API 문서화 기술을 적용하기로 결정했습니다.
API 문서화 도구를 결정할 때 Swagger와 Spring Rest Docs를 고려했습니다. Swagger는 널리 사용되는 API 문서화 도구로 사용하기 쉽고 다양한 기능을 제공하는 장점이 있습니다. 그러나 Swagger 사용시 API 스펙을 정의하기 위해 비즈니스 로직이나 도메인 모델에 Swagger에 종속된 코드가 어노테이션 등의 형태로 삽입되어야 합니다. 따라서 POJO(Plain Old Java Object)에 대한 규약을 위반한침투적인 코드가 발생한다는 단점이 있습니다. Spring Rest Docs를 Swagger와 비교해 보았을때 이러한 문제를 해결할 수 있는 장점이 있었습니다.
Spring Rest Docs를 적용하면 테스트와 문서의 통합이 가능해집니다. 테스트 케이스에서 정의한 API의 입력과 기대 출력은 자동으로 문서에 반영되어 API의 실제 동작과 문서 간의 일관성을 유지하고, 문서의 현행화를 보다 쉽게 할 수 있었습니다. 이를 통해 스프링이 지향하고 있는 핵심 철학인 POJO를 지키며 개발할 수 있었습니다.
또한 코드의 변경이 발생할 때마다 테스트 케이스를 수정하고 실행하면 API 문서도 자동으로 업데이트되어 테스트 커버리지와 문서화의 일치성을 지속적으로 유지할 수 있었습니다. 이는 코드 변경에 따른 문서 업데이트의 번거로움을 줄이고 실수를 방지하는 데 도움을 주었습니다.
Spring Rest Docs의 적용 과정에서는 처음에는 일부 어색한 부분이 있었지만, 점차 익숙해지면서 문서화 작업에 큰 도움을 주었습니다. 특히 프론트엔드 개발자와의 의사소통을 간소화하고 협업을 원활하게 만들어주었습니다. 프론트엔드 개발자들은 테스트 케이스와 문서를 통해 필요한 API를 쉽게 파악하고 이해할 수 있었고, 필요한 정보를 빠르게 확인할 수 있었습니다. 이로 인해 불필요한 질문과 오해를 줄이고, 개발 과정에서 생길 수 있는 혼란을 최소화할 수 있었습니다.