관리자가 올리는 컨텐츠가 생명인 프로젝트Hearit은 오디오 기반 IT 학습 플랫폼이다. NotebookLM으로 오디오 콘텐츠를 만들어서 올린다. 당연히 컨텐츠가 핵심이다. 콘텐츠가 안 올라오면 서비스가 죽는다.콘텐츠는 나를 포함한 7명의 팀원이 1개씩, 일주일에 7개씩 올렸다. 근데 어느 순간부터 속도가 줄기 시작했다. 일주일에 3개, 2개... 그러다 어쩔 때는 일주일에 1개만 올라올 때가 있었다.대부분의 팀원들이 콘텐츠를 안 올린 것이다.솔직히 말하면, 귀찮았다원인을 찾아보니 별거 없었다.귀찮아서.다들 바빠지기도 했지만, 솔직히 그게 전부는 아니었다. 콘텐츠 하나 올리는 데 30~40분이 걸렸고, 그 시간 동안 계속 신경을 써야 했다. 집중이 끊기고, 다른 일 하다가 다시 돌아오고, 어디까지 했더라..

“이전에 듣던 지점부터 다시 재생하고 싶어요.”유저 테스트 기간 동안 가장 많이 받은 피드백이었습니다.사용자들은 중간에 멈춘 콘텐츠를 다시 찾는 과정에서 반복적인 불편함을 겪고 있었습니다.이 요구를 그대로 구현하면, 사용자의 상태를 아주 짧은 주기로 지속적으로 저장해야 하는 문제와 마주하게 됩니다.그러나 모든 요청을 즉시 데이터베이스에 기록하는 방식은, 요청 수가 늘어날수록 쓰기 부하와 지연을 빠르게 증폭시키며, 시스템 확장 시 가장 먼저 한계를 드러냅니다.따라서 빈번한 쓰기 요청은 즉시 저장해야 할 대상이 아니라, 조절하고 다뤄야 할 대상이 됩니다.중간에 완충 지점을 두고 불필요한 중복을 제거한 뒤, 의미 있는 시점에 묶어서 저장하는 구조가 필요합니다.더 나아가 서버가 여러 대로 확장되더라도, 모든 인..

프로젝트에서 JPA Auditing 덕분에 @CreatedDate, @LastModifiedDate 덕분에 엔티티 생성·수정 시점을 자동으로 관리할 수 있다!하지만 이 신기방기 편리한 JPA Auditing 을 쓰다보면 불편한 점이 하나 존재했는데 그건 바로 테스트... 시간에 의존하는 로직이 늘어날수록 테스트가 점점 불안정해졌고 “이 테스트가 실패한 게 로직 때문인지, 실행 타이밍 때문인지” 헷갈리는 순간이 많아졌다. 결국 시간 자체를 테스트에서 통제할 수 있어야 한다는 결론에 도달했고 그 과정에서 TestClock 기반의 시간 제어 테스트 인프라를 만들게 되었습니다.문제 상황: JPA Auditing으로 시간고정됨.JPA Auditing을 사용하면 엔티티 저장 시점에 현재 시간이 자동으로 주입됩니다...

EC2 서버를 Git으로 길들이기수동 배포 지옥에서 Pull-based GitOps까지수동으로 관리되던 AWS EC2 서버를GitHub Actions Self-hosted Runner 기반의 Pull-based GitOps 구조로 전환했습니다.사람의 기억과 손에 의존하던 서버 설정 파일을 코드와 시스템의 책임으로 넘기는 과정에 대한 글입니다.1. 자동화가 아니라, ‘신뢰할 수 있는 상태’가 필요하다.프로젝트 초반, ec2 내의 nginx config와 같은 서버 설정 파일 관리는 생각보다 빠르게 혼란스러워졌습니다.돌이켜보면 문제는 기술이 아니라 관리 방식이었습니다.1단계 : 서로 물어보고 확인하기“Nginx 설정 어디 있어요?”“서버 들어가서 /etc/nginx 한 번 봐주세요.”누군가는 알고 있었고, ..

신뢰를 잃은 API 문서, 어떻게 살릴까?얼마 전, API 명세의 사소한 변경 사항을 팀원에게 공유하는 것을 잊은 채 코드를 배포한 적이 있습니다. 그 결과, 안드로이드 팀원은 몇 시간 동안 원인 모를 에러와 씨름해야 했습니다.분명 Swagger 문서에는 필드가 그대로인데, 실제 서버 응답에서는 해당 필드가 빠져 있었기 때문입니다.원인이 제 실수였다는 것을 알았을 때의 미안함은 매우 컸습니다.많은 개발자분들이 비슷한 경험을 해보셨을 겁니다. 이처럼 사소한 실수가 프로젝트 전체에 큰 혼란을 야기할 수 있다는 점에서 정확하고 신뢰할 수 있는 API 문서는 단순한 편의성 이상의 문제입니다.이 글은 바로 그 '신뢰성'과 '편의성'이라는 두 마리 토끼를 모두 잡는 방법에 대한 이야기입니다. Spring Boot ..