백엔드 코드를 처음 들여다봤을 때, 폴더 구조부터 살펴봤습니다.controller, service, repository. 레이어드 아키텍처 특유의 3계층 구조가 눈에 들어왔고, MVC로 프론트 개발을 해온 입장에서 그나마 낯익었습니다. "아, 이 정도는 알겠다" 싶었는데, 문제는 그 옆에 있던 다른 폴더들이었습니다.port, adapter, in, out. 같은 기능인데 파일이 왜 이렇게 많지? 싶을 정도로 인터페이스가 난무했고, 처음엔 그냥 "백엔드는 원래 파일이 많구나" 하고 넘어갔습니다. 이후 AI한테 물어보니 헥사고날 아키텍처를 적용한 거라고 했습니다.그 이후로 개념을 잡으려고 여러 글을 찾아봤는데, 다들 설명이 너무 이론적이라 솔직히 읽어도 머릿속에 잘 안 들어왔습니다. 결국 코드 뜯어보고 AI..

요즘 백엔드 공부를 조금씩 하고 있습니다.프론트만 하다 보면 API가 왜 그렇게 설계됐는지, 백엔드 개발자가 왜 그렇게 말하는지 맥락을 놓칠 때가 있더라고요. 그게 좀 불편해서 시작하게 됐습니다. 앞으로 아래 주제들을 하나씩 정리해볼 예정입니다.헥사고날 아키텍처스프링부트 어노테이션스프링부트 생명주기DI, IoCDB 낙관적 락, 비관적 락

잘 돌아가던 Next.js 프로젝트에 작은 기능 하나를 추가하려던 순간, 엉뚱한 곳까지 'use client' 지시어가 번져나가는 경험 다들 한 번쯤 있으실 겁니다. 그저 버튼 하나에 onClick을 달았을 뿐인데, 그 컴포넌트는 물론이고 부모, 부모의 부모까지 줄줄이 클라이언트 번들에 포함되어 버리는 거죠.원인을 파악해 보면 십중팔구 클라이언트 경계를 처음부터 잘못 그어놓은 문제였습니다.오랜 기간 CSR 기반의 SPA에 익숙해져 있던 우리에게, 컴포넌트는 오직 '역할'로만 나뉘는 단위였습니다. 헤더, 카드, 모달, 폼. 하지만 React Server Components(이하 RSC)가 안정화되고 Next.js App Router가 기본 선택지가 되면서, 컴포넌트를 나누는 축이 하나 더 생겨버렸습니다. ..

잘 돌아가던 프로젝트가 어느 날 갑자기 빨간 줄을 뿜어내며 빌드에 실패한 경험 다들 한 번쯤 있으실 겁니다. 코드는 단 한 줄도 건드린 적이 없는데 말이죠. 원인을 파악해 보면 십중팔구 새로 설치한 패키지와 기존 패키지 사이의 의존성 충돌이나 알 수 없는 버전 꼬임 문제였습니다. 오랜 기간 Yarn을 사용해 오면서 패키지 설치 속도 자체에는 큰 불만이 없었습니다. 하지만 프로젝트 덩치가 커지고 추가되는 라이브러리가 많아질수록 이런 의도치 않은 패키지 버전 충돌 버그를 겪는 빈도가 잦아졌습니다. 원인 모를 런타임 에러에 시달리다 결국 node_modules 폴더를 통째로 지우고 캐시를 날린 뒤 다시 설치하는 소모적인 작업에 점점 지쳐갔죠. 우리는 이 문제의 근본적인 원인이 기존 패키지 매니저들이 가진 느슨..