Category language

도메인 값 객체와 요청 DTO를 분리한 트레이드오프

MemberRegisterRequest 같은 요청 오브젝트를 어느 계층에 둘지 물으면, 개발자가 반사적으로 “애플리케이션 레이어”라고 답한다. DTO는 데이터를 담아 계층 경계를 넘기는 역할이니 서비스 레이어에 두는 것이 자연스럽다는 이유다. 그런데 헥사고날 아키텍처로 회원 등록 기능을 만들 때, 이 오브젝트를 도메인 레이어에 두었다. 결론부터…

App Store 심사 제출을 막은 건 코드가 아니라 빈 필드였다

빌드는 이미 TestFlight에 올라가 있었다. 심사 제출은 그 빌드를 고르고 버튼만 누르면 될 줄 알았다. 그런데 “심사에 추가”를 누르자 두 개의 필드가 비어 있다며 막혔고, 그 앞단에는 App Privacy 설문·연령등급·수출 규정 같은 “답을 정해야 하는” 질문들이 줄지어 있었다. 심사 제출은…

App Store 첫 등록은 CI/CD가 있어도 절반은 수동이었다

CI/CD로 TestFlight 업로드까지 자동화해두고, App Store 첫 등록도 명령어 몇 줄이면 끝날 줄 알았다. 그런데 App ID를 만드는 첫 단계부터 fastlane produce가 막혔고, 결국 웹 UI에서 하나씩 눌러 등록했다. 자동화가 어디서 멈추는지, 그리고 준비 단계에서 나를 붙잡은 사소한 오류들을 순서대로…

Flutter 배포 자동화 파이프라인, 반쪽만 완성해도 안전하게 설계했다

취미(부업…)로 만든 Flutter 앱에 fastlane + GitHub Actions로 배포 자동화를 붙였다. 결과부터 말하면, Android는 실제로 Google Play internal 트랙 업로드까지 완주해 파이프라인이 로컬 기준으로 완전히 검증됐다. iOS는 아직 Apple Developer 계정(돈…ㅠㅠ) 확인 단계에서 멈춰 있어 문법 검증까지만 마친 상태다 한쪽은…

Java로 HTTP 서버 개선기 — 리플렉션 서블릿으로 매핑 자동화하기

기존 커맨드 패턴의 한계 이전 버전(V5)에서는 커맨드 패턴 기반의 서블릿을 사용했다. 각 URL 경로마다 별도의 서블릿 클래스를 만들고, 이를 ServletManager에 일일이 등록해야 했다 이 방식에는 두 가지 명확한 단점이 있다 기능이 수십 개로 늘어난다면? 클래스 파일과 매핑 코드가 함께 폭발적으로…

리플렉션(Reflection)

리플렉션이 필요한 이유 커맨드 패턴으로 서블릿을 구현할 때 흔히 부딪히는 두 가지 불편함이 있다 기능 하나당 클래스 하나 – 클래스가 폭발적으로 늘어난다 반면 아래처럼 하나의 컨트롤러에 여러 기능을 모을 수 있다면 훨씬 깔끔해진다 URL 경로 /site1이 들어오면 site1() 메서드를 이름으로…

Java로 HTTP 서버 만들기 — 커맨드 패턴으로 서버와 비즈니스 로직 분리하기

왜 분리가 필요한가? 이전 버전의 HttpRequestHandler를 보면 문제가 바로 보인다 home(), site1(), site2(), search() 같은 서비스 로직이 서버 코드 안에 직접 박혀 있다. 다른 프로젝트에서 이 서버를 재사용하려면? 이 로직들을 전부 갈아엎어야 한다. 재사용이 불가능하다. 해결책은 명확하다. 서버가 해야 할…

Java로 HTTP 서버 만들기 — 요청과 응답을 객체로 구조화하기

왜 객체로 만드는가 HTTP 메시지는 명확한 규칙을 가진다 이 규칙이 존재한다는 것은 구조화할 수 있다는 의미다. 문자열을 매번 직접 파싱하는 대신, HttpRequest, HttpResponse 객체로 캡슐화하면 코드의 복잡도가 극적으로 줄어든다 HttpRequest – 요청 파싱 생성자에서 BufferedReader를 받아 시작 라인 → 헤더…

Java로 HTTP 서버 만들기 — 스레드 풀로 동시 요청 처리

1편에서 만든 HttpServerV1은 요청을 순차적으로 처리했다. 첫 번째 요청이 5초 걸리면 두 번째 요청은 5초를 기다려야 했다. 실제 서비스라면 절대 용납할 수 없는 구조다. 해법은 단순하다. 요청마다 별도의 스레드를 할당하면 된다 구조 변경 V1의 구조는 메인 스레드가 연결 수락과 요청…