취미(부업…)로 만든 Flutter 앱에 fastlane + GitHub Actions로 배포 자동화를 붙였다. 결과부터 말하면, Android는 실제로 Google Play internal 트랙 업로드까지 완주해 파이프라인이 로컬 기준으로 완전히 검증됐다. iOS는 아직 Apple Developer 계정(돈…ㅠㅠ) 확인 단계에서 멈춰 있어 문법 검증까지만 마친 상태다 한쪽은…
기존 커맨드 패턴의 한계 이전 버전(V5)에서는 커맨드 패턴 기반의 서블릿을 사용했다. 각 URL 경로마다 별도의 서블릿 클래스를 만들고, 이를 ServletManager에 일일이 등록해야 했다 이 방식에는 두 가지 명확한 단점이 있다 기능이 수십 개로 늘어난다면? 클래스 파일과 매핑 코드가 함께 폭발적으로…
리플렉션이 필요한 이유 커맨드 패턴으로 서블릿을 구현할 때 흔히 부딪히는 두 가지 불편함이 있다 기능 하나당 클래스 하나 – 클래스가 폭발적으로 늘어난다 반면 아래처럼 하나의 컨트롤러에 여러 기능을 모을 수 있다면 훨씬 깔끔해진다 URL 경로 /site1이 들어오면 site1() 메서드를 이름으로…
왜 분리가 필요한가? 이전 버전의 HttpRequestHandler를 보면 문제가 바로 보인다 home(), site1(), site2(), search() 같은 서비스 로직이 서버 코드 안에 직접 박혀 있다. 다른 프로젝트에서 이 서버를 재사용하려면? 이 로직들을 전부 갈아엎어야 한다. 재사용이 불가능하다. 해결책은 명확하다. 서버가 해야 할…
왜 객체로 만드는가 HTTP 메시지는 명확한 규칙을 가진다 이 규칙이 존재한다는 것은 구조화할 수 있다는 의미다. 문자열을 매번 직접 파싱하는 대신, HttpRequest, HttpResponse 객체로 캡슐화하면 코드의 복잡도가 극적으로 줄어든다 HttpRequest – 요청 파싱 생성자에서 BufferedReader를 받아 시작 라인 → 헤더…
2편까지 만든 서버는 어떤 URL로 요청이 오든 항상 같은 HTML을 응답했다. 실제 웹 서버는 URL 경로에 따라 다른 화면을 보여준다. 이번에는 /, /site1, /site2, /search 각 경로에 맞는 응답을 돌려주는 URL 라우팅을 구현한다 구현할 라우팅 스펙 GET / 홈 화면…
1편에서 만든 HttpServerV1은 요청을 순차적으로 처리했다. 첫 번째 요청이 5초 걸리면 두 번째 요청은 5초를 기다려야 했다. 실제 서비스라면 절대 용납할 수 없는 구조다. 해법은 단순하다. 요청마다 별도의 스레드를 할당하면 된다 구조 변경 V1의 구조는 메인 스레드가 연결 수락과 요청…
HTTP는 결국 TCP 위에서 동작하는 텍스트 프로토콜이다. 즉 다음과 같은 흐름이다 소켓을 열고, 텍스트를 읽고, HTTP 규약에 맞춰 응답을 쓰면 된다 HTTPServerV1 서버를 실행한 후 브라우저에서 http://localhost:12345에 접속하면 된다 설계 포인트 BufferedReader와 PrintWriter를 선택한 이유 HTTP는 텍스트 기반 프로토콜이다. 바이트…
3편에서 커맨드 패턴을 도입해 명령어마다 독립적인 클래스를 만들었다. 그런데 CommandManagerV3의 execute()를 보면 아직 한 가지 거슬리는 부분이 남아 있다 명령어를 찾고, null이면 처리하고, 아니면 실행한다. 로직 자체는 맞지만 null 체크가 흐름을 끊는다. 이상적인 코드는 이렇다 명령어를 찾고, 바로 실행한다. 이…
2편에서 채팅 서버의 기능을 완성했다. 그런데 CommandManagerV2의 execute()메서드를 다시 보면 마음이 불편하다. if-else가 5개 들어서 있고, 새 명령어가 생길 때마다 이 덩어리 안에 코드를 끼워 넣어야 한다. 이번에는 커맨드 패턴(Command Pattern)을 도입해 이 문제를 깔끔하게 해결한다 문제 정의 문제는 두…