런코리치(RunCodeRich) : 달리고 코딩하며 경제를 보다.

1. 왜 지금 '옛날 기술'을 공부해야 할까?신입 개발자나 최신 프레임워크 위주로 공부한 분들에게 JSP 기반의 Controller 구조는 마치 박물관에서나 볼 법한 유물처럼 느껴질 수 있습니다. 하지만 현실은 다릅니다. 국가 망을 지탱하는 공공기관 시스템, 거대 기업의 레거시(Legacy) 인프라, 혹은 오랫동안 안정적으로 운영되어 온 금융권 프로젝트에 투입되면 우리는 여전히 10년, 20년 된 코드들과 마주하게 됩니다.현대적인 Spring MVC나 Spring Boot의 근예(Roots)가 바로 여기서 시작되었기에, 이 구조를 이해하는 것은 단순히 과거를 공부하는 것이 아니라 "웹 서비스가 어떻게 발전해 왔는가"를 깨닫는 과정입니다. 오늘은 언젠가 반드시 마주할 그 이름, JSP Model 1과 Mo..

1. 서론: 'S' 하나에 울고 웃는 웹의 세계우리가 매일 주소창에 입력하는 http://.... 하지만 어느 순간부터 구글 크롬은 주소창 옆에 빨간색 경고 표시와 함께 "이 사이트는 안전하지 않습니다"라는 무시무시한 문구를 띄우기 시작했습니다. 반면, 잘 관리된 사이트들은 주소창 옆에 예쁜 초록색 자물쇠와 함께 https://로 시작하죠.단순히 알파벳 'S(Secure)' 하나가 붙었을 뿐인데, 왜 전 세계 브라우저는 이토록 유난을 떠는 걸까요? 특히 데이터를 상품으로 팔아야 하는 우리 같은 API 개발자들에게 HTTPS는 선택이 아닌 '생존'의 문제입니다. 오늘은 그 속사정을 깊숙이 파헤쳐 보겠습니다.2. HTTP의 치명적인 약점: 뚫려 있는 편지봉투HTTP(HyperText Transfer Prot..

안녕하세요, 런코리치(Run-Code-Rich)입니다."내 기술로 회사 밖에서도 돈을 벌 수 있을까?" 개발자라면 누구나 한 번쯤 꿈꾸는 '경제적 자유'의 핵심은 결국 나의 노동력을 복제하는 시스템을 만드는 것입니다. 블로그 애드센스 수익도 좋지만, 개발자에게는 더 강력한 무기가 있습니다. 바로 사용자의 문제를 해결해 주고 직접 결제를 받는 수익형 웹 서비스(Micro-SaaS)입니다.오늘은 2026년 현재 가장 효율적인 기술 스택과, 실제로 돈이 되는 3가지 비즈니스 모델을 통해 '코드로 돈 버는 법'을 디버깅해 보겠습니다.1. 2026년, 왜 '마이크로(Micro)'에 집중해야 하는가?거대한 플랫폼의 시대는 가고, 특정 집단의 가려운 곳을 긁어주는 니치(Niche) 마켓의 시대가 왔습니다. 1인 개발..

1. 왜 '비상금'이 투자의 승패를 결정할까?투자는 '심리전'입니다. 내가 당장 쓸 돈이 없어서 주식 계좌를 들여다보기 시작하면, 주가가 조금만 흔들려도 공포에 질려 '손절' 버튼을 누르게 됩니다. 비상금은 단순히 노후 자금이 아니라, 내 투자 자산이 충분히 익을 때까지 기다려줄 수 있는 '시간'을 사는 돈인 것입니다.심리적 안정감: 하락장에서도 "내 생활비는 따로 있어"라는 자신감이 생깁니다.기회비용 확보: 시장이 과도하게 빠졌을 때(소위 '줍줍' 타이밍), 비상금이 있다면 오히려 추가 매수의 기회로 삼을 수 있습니다.2. 비상금, 얼마가 적당할까? (3-6-9 법칙)사회초년생이라면 본인의 월평균 지출액을 먼저 파악해야 합니다.최소 권장: 월 지출액의 3배 (갑작스러운 경조사나 병원비 대비)안정 권장:..

안녕하세요! 오늘은 웹 개발과 시스템 설계에서 자주 언급되는 Page-centric(페이지 중심) 방식에 대해 깊이 있게 다뤄보려 합니다. 최근 컴포넌트 기반 개발(Component-driven)이 대세가 되면서 상대적으로 덜 주목받는 듯하지만, 사실 우리가 사용하는 많은 프레임워크와 최적화 기법의 뿌리에는 이 '페이지 중심' 사고방식이 자리 잡고 있습니다.1. Page-centric의 핵심 정의Page-centric은 애플리케이션의 구조, 데이터 페칭, 그리고 사용자 경험을 '하나의 독립된 페이지(URL)'를 최소 실행 단위로 보고 설계하는 방식을 말합니다.과거의 웹이 단순히 HTML 문서를 전달하는 방식이었다면, 현대의 Page-centric은 "사용자가 진입하는 특정 지점(Entry Point)에서..

현대 백엔드 시스템에서 특정 시간에 리포트를 생성하거나, 주기적으로 유효 기간이 만료된 데이터를 정리하는 등의 '배치성 작업'은 필수적입니다. Spring 프레임워크는 이러한 요구사항을 아주 간단하게 해결할 수 있도록 @Scheduled 어노테이션을 제공합니다. 하지만 단순히 어노테이션을 붙이는 것과, 운영 환경에서 안정적으로 동작하는 스케줄러를 만드는 것은 천지차이입니다. 오늘은 기초부터 실무 레벨의 고급 설정까지 상세히 파헤쳐 보겠습니다. 1. 스케줄링의 심장: @EnableScheduling과 기본 설정Spring Boot에서 스케줄러를 사용하기 위한 첫 단추는 활성화 설정입니다. 메인 애플리케이션 클래스나 설정 클래스(@Configuration)에 @EnableScheduling을 추가해야 합니다..

스프링 개발자에게 @Transactional은 공기 같은 존재입니다. 하지만 이 공기가 가끔 멈출 때가 있습니다. 데이터가 수정되지 않거나, 에러가 났는데 롤백이 되지 않아 DB 데이터가 꼬이는 현상은 주니어부터 시니어까지 누구나 겪을 수 있는 공포입니다.실제 개발할 때도 트랜잭션이 필요한 부분에서 적용되지 않거나, 전 과정이 하나의 트랜잭션으로 묶여 전부 진행될 때까지 테이블에 락이 걸리는 등의 문제가 발생하는 경우도 많은 것 같습니다. 트랜잭션의 개념을 정확하게 익히고, 때에 따라서 적용할 수 있으면 좋겠습니다.오늘은 @Transactional이 작동하지 않는 모든 가능한 시나리오를 상세한 예시와 함께 정리해 보겠습니다.1. 프록시의 한계: 내부 호출 (Self-Invocation)가장 흔하면서도 고..

백엔드 개발자라면 프로젝트 설계 단계에서 반드시 마주하는 난제가 있습니다. 바로 "세션(Session)으로 갈 것인가, JWT(Token)로 갈 것인가?"입니다.과거에는 세션이 당연한 정석이었지만, 최근에는 너도나도 JWT를 사용하는 추세입니다. 하지만 유행이라고 해서 무조건 JWT가 정답은 아닙니다. 오늘 두 방식의 차이점을 뼈 때리는 팩트와 함께 완벽히 비교해 보겠습니다.1. 한눈에 보는 비교표구분세션 (Session)JWT (JSON Web Token)저장 위치서버 메모리 또는 DB클라이언트 (브라우저, 앱)상태 유지Stateful (상태 유지)Stateless (무상태)확장성낮음 (서버 간 공유 설정 필요)높음 (서버가 늘어나도 무관)보안 제어서버가 세션을 강제 만료 가능유효 기간 전까지 만료 불..

지난 포스팅에서 다룬 세션(Session) 방식은 서버가 사용자의 상태를 기억해야 하는 'Stateful'한 특성이 있었습니다. 하지만 서버가 늘어나고 마이크로서비스(MSA)가 대세가 되면서, 서버가 상태를 저장하지 않고도 인증을 수행할 수 있는 JWT(JSON Web Token)가 현대 인증의 표준으로 자리 잡았습니다.오늘은 JWT가 무엇인지, 왜 쓰는지, 그리고 어떻게 구현하는지 아주 상세하게 파헤쳐 보겠습니다.1. JWT란 무엇인가?JWT는 당사자 간에 정보를 JSON 객체로 안전하게 전송하기 위한 개방형 표준(RFC 7519)입니다.Stateless(무상태): 서버는 토큰을 발행만 할 뿐, 서버 메모리에 저장하지 않습니다.Self-Contained(자가 수용적): 토큰 자체가 사용자의 정보와 유효..

웹 서비스를 개발하면서 가장 먼저 마주하는 거대한 벽은 바로 '인증'입니다. 인증의 방식에는 여러 가지가 있습니다. 대표적으로 쿠키, 세션 등입니다. 각 인증 방식별로 특징을 정확히 안다면, 언제 어떤 인증방식을 활용하는 것이 좋은지에 대한 판단이 가능할 것입니다. 오늘은 세션에 대해 알아볼 것입니다. "어떻게 하면 사용자가 로그인했다는 사실을 서버가 계속 기억하게 할 수 있을까?"라는 질문에 대한 가장 고전적이면서도 강력한 해답은 바로 세션(Session)입니다.오늘 이 포스팅에서는 세션의 동작 원리부터 실제 구현, 보안 위협 대응, 그리고 실무 설정까지 단 하나도 빠뜨리지 않고 상세히 다루어 보겠습니다.1. HTTP의 한계와 세션의 탄생우리가 사용하는 HTTP 프로토콜은 Stateless(비연결성)..