어느덧 개발자들 사이에서 JPA같은 ORM 기술은 언어를 가리지 않고 선택이 아닌 필수 교양이 되었다. 개발자 면접에서도 영속성 컨텍스트의 원리나 N+1 문제의 해결책을 묻는 것이 당연한 코스가 되었다. 하지만 문득 의문이 들었다. 당연하게 믿고 있는 이 도구가 사실은 레거시가 되어가지 않을까? 1. ORM은 왜 대세가 되었을까?ORM을 배우는 이유는 명확했다. 지루하고 반복적인 CRUD 쿼리 작성을 자동화하여 개발 효율을 높이고, 테이블 중심이 아닌 객체지향적인 사고로 비즈니스 로직을 구현하기 위함이다. 하지만 지금은 AI가 코딩하는 시대다. 과거에는 수십 개의 컬럼을 매핑하고 쿼리를 짜는 것이 '고비용 작업'이었지만, 이제는 AI에게 스키마만 던져주면 최적화된 SQL과 DTO 매핑 코드를 1초 만에 ..
나는 회사에서는 자바와 스프링을 주로 쓰는 백엔드 개발자로 일하지만, 개인적인 사이드 프로젝트에 대한 관심이 꾸준히 있었다. 그래서 개발 속도가 빠르고 유지보수가 편한 기술 스택을 따로 알아보고 공부하기 시작했다. 그러다가 Supabase와 Next.js로 프로젝트들을 만들기 시작했고, 개발 속도 측면에서는 꽤 만족스러웠다. Supabase와 Vercel을 사용하면 서버비용 0원으로 시작할 수 있었고 서버 관리 부담도 거의 없어서 꽤 괜찮다고 생각했다. 프리티어를 넘는 트래픽이 오면 25달러와 20달러 정도는 충분히 낼 만한 프로젝트가 되리라 착각하기도 했다. 하지만 현실은 달랐다.프리티어를 겨우 넘었을 뿐인데 매달 약 50달러의 비용이 발생했고, MAU가 크게 늘지 않으면서 이 고정비가 계속 유지되었다..
최근 코드를 보다 보니 문득 드는 생각이 하나 있었다.“왜 이렇게 Exception catch가 숨어있지?” 백엔드 코드를 짜다 보면, 서비스 로직이라는 게 있고, 그 외의 ‘도구적인 작업’들이 있다.DB를 쓰거나, 외부 API를 호출하거나, 캐시를 쓰거나, 이벤트를 전송하는 그런 것들.근데 문제는... 이런 도구적인 부분에서 너무 과도한 예외 처리를 해버린다는 거였다. 물론 의도는 좋았다. 장애가 안 나게 막으려는 거니까.근데 이게 꼭 좋은 건 아니라는 생각이 들었다.왜냐면 예외를 그 자리에서 catch하고, 자체적으로 fallback을 처리해버리면그건 서비스 로직 바깥에서 서비스 로직을 대신 결정해버리는 셈이었으니까. 예를 들어보자.DB 저장이 실패했을 때, 외부 API 호출이 실패했을 때그 상황에서..
의존 역전에 대한 고찰객체지향의 가장 큰 장점은 의존 방향을 우리가 원하는 대로 제어하기 쉽다는 점이다. 예를 들어 A → B 구조에서 B의 변동 가능성이 클 경우, A → I ← B 형태로 구조를 바꿔서 A를 변화와 확장으로부터 보호하는 것, 그게 핵심이다. 여기서 중요한 건 A와 I가 같은 바운더리 안에 있어야 한다는 점이다. 왜냐하면 I는 A가 원하는 인터페이스이기 때문이다. 그런데 의존을 역전시켰다고 하면서 I와 B를 같은 바운더리에 위치시키는 경우가 종종 보이는데 이는 의존 역전에 대한 오해다. 의존 역전의 본질은 인터페이스를 사용했다는 것 자체가 아니라, 변동에 대한 제어 주도권을 역전시켜 가져왔다는 점이다. 마이크로서비스에서의 의존역전MSA의 기술적 성장은 안정화되어 가고 있지만, 개발자들의..
Next.js + Vercel 환경에서 한글 검색 구현기: 삽질기부터 직접 bigram 구현까지Next.js + Vercel 환경에서 한글 검색 기능 구현이 의외로 골치 아픈 일이었고 이를 정리하기 위해서 공유합니다. 1) LIKE 검색? 간단하지만 성능에 불안 요소처음엔 누구나 WHERE title LIKE '%검색어%'로 시작합니다.간단하죠. 하지만 다음과 같은 문제가 있습니다:인덱스를 타지 못해 데이터가 많아지면 검색 속도가 확 느려짐전체 스캔이 발생해 비용이 비쌈단순 포함 검색이라 의미 기반 검색 불가그래서 바로 포기했습니다. 2) PostgreSQL tsvector? …한글 형태소 분석은 미지원PostgreSQL의 tsvector + to_tsvector 조합은 풀텍스트 검색을 위해 매우 강력한..
WebRTC는 Web Real-Time Communication의 약자로, 웹 브라우저 간에 실시간으로 오디오, 비디오, 데이터 스트림을 주고받을 수 있도록 지원하는 기술이다. WebRTC를 통해 사용자는 플러그인 없이 웹에서 직접 영상 통화, 파일 공유, 게임 등 다양한 실시간 커뮤니케이션 서비스를 구현할 수 있다. WebRTC는 P2P(Peer-to-Peer) 기술을 사용하여 두 클라이언트 간의 직접적인 연결을 제공한다. 이를 통해 데이터가 서버를 거치지 않고 바로 전송되어 지연을 줄이고 네트워크 부하를 줄이는 장점이 있다.Peer-2-Peer에서도 서버가 필요한 이유: 시그널링 서버WebRTC는 Peer-to-Peer 연결을 사용하지만, 실제로 P2P 연결이 성립되기 위해서는 시그널링(Signali..
Null이라는 개념을 만든 것이 "백만 달러짜리 실수"라는 일화를 한 번쯤 들어봤을 텐데, 그만큼 Null과 NullPointerException(이하 NPE)은 많은 개발자들을 괴롭히고 애플리케이션에 문제를 야기시킨다. 그래서 Null을 다루지 않기 위한 여러 가지 방법을 사용하는데, 대표적인 방법으로 Null Object Pattern을 사용하여 Null을 대신할 객체(이하 Null Object)를 만들어 둔다. 나쁘지 않은 방법이다. 특히 특정 객체에 대한 Null 문제가 아니라 객체의 속성이나 필드가 Null인 케이스를 방어해 두기도 좋다. 그러다 보면 보이게 되는 코드들이 맹목적인 Null 방어 코드들이다. 마치 Null만 막으면 애플리케이션이 안전해진다고 착각한다. Null을 다루는 코드는 위..
개발을 처음 시작하면서 적당한 언어를 배우고 나면 따라오는것이 객체지향 프로그래밍(이하 객체지향)에 대한 개념이다. 그리고 객체지향을 집중적으로 공부하다보면 마치 객체지향은 '정답'이고 절차지향은 '오답'이라는 생각에 갇히게 된다. 개발자 사이에 이런 분위기가 전반적으로 깔려 있는것도 사실이다. 열심히 객체지향을 공부하고 Spring 환경의 실무 코드를 보고 있으면 마치 엄청난 안티패턴들이 실무에 자리잡고 있지 않은가 한탄하게 된다. 내가 공부했던 객체지향은 어디에 적용되어있는가? 라는 회의감도 빠지게된다. 공부한 이상적 패턴과 현실의 괴리감에 고통스럽기도 하다. 언젠간 이러한 구조를 객체지향적으로 바꿔야겠다는 다짐도 하게된다. 신기한건 실무에 있다보면 내 주도하에 시작된 프로젝트도 결국 비슷하게 절차적..