-

일기를 시작하며
6월에 설레는 마음으로 첫 삽을 떴지만, 연이은 팀 프로젝트들로 인해 잠시 멈춰있던 이 프로젝트에 최근에서야 온전히 집중할 수 있게 되었다. 텅 비어있던 패키지들은 이제 각자의 역할을 다하는 수많은 클래스들로 채워졌고 Swagger 화면 속 API 목록들은 지난 시간 동안의 치열했던 고민의 증거처럼 느껴진다. 지금은 견고하게(?) 완성된 백엔드 서버에 React라는 새로운 옷을 입혀주는 작업을 하고 있다. 잠시 숨을 고르며 기능 구현 너머에 있던 나의 성장과 고민의 순간들을 기록해 본다.
가장 뜨거웠던 고민의 순간들: 나의 트러블슈팅 기록
단순히 기능을 완성하는 것보다, 하나의 문제를 통해 더 깊은 원리를 이해하게 되었던 순간들이 이번 프로젝트의 진짜 수확이었다.
- "이게 최선일까?" 라는 질문이 가져온 전체 리팩토링 처음에는 모든 API가 miniHomepageId를 기준으로 동작했다. 기능은 됐지만 어딘가 모르게 불편했다. "사용자 입장에서 이게 맞나?" 라는 작은 의문은 결국 /users/{userId}/mini-homepage 라는 더 직관적이고 RESTful한 구조로 API 전체를 뒤엎는 대공사로 이어졌다. 단순히 코드를 수정하는 것을 넘어 사용자의 관점에서 API를 설계하는 법을 배운 첫 번째 전환점이었다.
- 보이지 않는 벽, Spring Security와의 사투 JWT 인증을 구현하고 마주친 NullPointerException은 나를 가장 괴롭혔던 문제였다. @AuthenticationPrincipal에 User를 넣으면 될 것이라는 단순한 예상은 계속해서 나를 좌절시켰다. 포기하지 않고 Spring Security의 동작 원리를 파고든 끝에, 프레임워크가 User가 아닌 표준 UserDetails 인터페이스를 통해 인증 객체를 관리한다는 사실을 알게 되었다. 컨트롤러에서 UserDetailsImpl을 받아 getUser()로 User 객체를 꺼내는 코드를 작성했을 때 나는 단순히 에러 하나를 해결한 것이 아니라 프레임워크의 추상화 너머에 있는 진짜 동작 원리를 이해하는 즐거움을 느꼈다.
- '닭과 달걀' 문제, DB와 JPA 사이에서 길을 찾다 회원가입 기능에서 만난 createdBy cannot be null 에러는 나를 또 다른 깊은 고민에 빠뜨렸다. 코드는 분명 save() 이후에 setCreatedBy()를 호출하는데 왜 DB는 값을 받지 못하는 걸까. 문제의 본질은 DB 스키마의 NOT NULL 규칙과, ID가 생성되어야만 createdBy 값을 알 수 있는 JPA의 동작 방식이 서로 충돌하는 '닭과 달걀' 문제에 있었다. 이 문제를 해결하기 위해 **DB 스키마의 제약조건을 현실적인 비즈니스 로직에 맞게 수정(ALTER TABLE)**하고 서비스 로직에서 트랜잭션의 힘을 빌려 최종 일관성을 보장하는 방법을 택했다. 이 경험을 통해 JPA와 데이터베이스 스키마가 어떻게 상호작용하는지 몸으로 체득할 수 있었다.
그래서, 지금 내가 만든 것
두 달간의 여정 끝에, 나는 이제 단순한 기능 목록이 아닌 각자의 책임과 역할이 명확한 하나의 유기적인 시스템을 만들었다.
- 견고한 아키텍처: user, board, profile 등 도메인별로 명확하게 분리된 패키지 구조는 앞으로 어떤 기능이 추가되더라도 길을 잃지 않을 튼튼한 기반이 되어줄 것이다.
- 객체지향적인 설계: 서비스에 몰려있던 복잡한 권한 확인 로직을 엔티티가 스스로 처리하도록 책임을 위임하면서 내 코드는 더 이상 절차적인 스크립트가 아닌 각 객체가 살아 움직이는 작은 생태계가 되었다.
- 완성된 핵심 기능: JWT 기반의 인증 시스템부터, 쌍방 관계를 다루는 일촌, 페이징과 상세 권한이 적용된 게시판과 댓글까지 싸이월드의 핵심적인 사용자 경험을 책임지는 백엔드 API 구현을 모두 완료했다.
앞으로의 계획: 더 높은 곳을 향하여
백엔드의 뼈대를 완성한 지금, 나의 다음 목표는 명확하다.
- 프론트엔드 연동 완성: 현재 진행 중인 React 연동 작업을 마무리하여 내가 만든 API가 실제 사용자 화면에서 어떻게 살아 움직이는지 눈으로 확인하고 개선점을 찾을 것이다.
- 남은 기능 구현: 싸이월드의 감성을 완성할 BGM, 사진첩 기능을 추가하여 프로젝트의 완성도를 높일 것이다.
- 세상에 내보내기 (배포): AWS EC2와 RDS를 학습하여 내 컴퓨터에서만 돌아가던 이 프로젝트를 세상의 모든 사람이 접속할 수 있는 실제 서비스로 배포하는 경험을 완성하고 싶다.
이 프로젝트는 나에게 단순히 기술을 나열하는 이력서 한 줄이 아니라 '왜?'라는 질문의 중요성과 문제 해결의 즐거움을 알려준 값진 성장 기록이다. 앞으로도 이 경험을 발판 삼아 끊임없이 고민하고 성장하는 개발자가 될 것이다.


ps. 얼른 배포해서 링크 여기저기 뿌리고 일촌 맺고싶다... 함께해 내 싸이월드
'Diary > 회고' 카테고리의 다른 글
[커널아카데미] 백엔드 개발 부트캠프 12기 24주차 - RESTful API란? (0) 2025.09.06 [커널아카데미] 백엔드 개발 부트캠프 12기 19주차 (0) 2025.08.04 [커널아카데미] 백엔드 개발 부트캠프 12기 18주차 - AI 토이 프로젝트(2) (0) 2025.07.27 [커널아카데미] 백엔드 개발 부트캠프 12기 17주차 - AI 토이 프로젝트 (0) 2025.07.20 [커널아카데미] 백엔드 개발 부트캠프 12기 16주차 - 좋은 개발자 (0) 2025.07.13 댓글
- "이게 최선일까?" 라는 질문이 가져온 전체 리팩토링 처음에는 모든 API가 miniHomepageId를 기준으로 동작했다. 기능은 됐지만 어딘가 모르게 불편했다. "사용자 입장에서 이게 맞나?" 라는 작은 의문은 결국 /users/{userId}/mini-homepage 라는 더 직관적이고 RESTful한 구조로 API 전체를 뒤엎는 대공사로 이어졌다. 단순히 코드를 수정하는 것을 넘어 사용자의 관점에서 API를 설계하는 법을 배운 첫 번째 전환점이었다.