Instagram4j - Maven Dependency
com.github.instagram4j instagram4j 2.0.7
자세히 보기 →JAVA
IT/코딩
IT/코딩 자료를 다루는 공간입니다.
JAVA
초보 개발자를 위한 Thread Safe와 동기화 완벽 가이드
1. 멀티스레드(Multi-Thread) 환경과 공유 자원의 이해 Java 기반의 웹 애플리케이션 프레임워크를 다룰 때 스레드(Thread)의 개념을 이해하는 것은 매우 중요합니다. 웹 서버(WAS)는 다수의 클라이언트 요청을 효율적으로 처리하기 위해 '스레드 풀(Thread Pool)'을 운영하며, 각각의 요청마다 독립적인 스레드를 할당하여 병렬로 작업을 수행합니다. 동시에 수많은 사용자가 접속하더라도 지연 없이 서비스를 이용할 수 있는 것은 이러한 멀티스레드 아키텍처 덕분입니다. 그러나 여러 스레드가 프로세스 내부의 '공유 자원(Shared Resource)'에 동시에 접근하여 수정 작업을 수행할 때, 데이터의 일관성이 깨지는 심각한 동시성 문제가 발생하게 됩니다. 2. 실무 장애 사례 분석: 비동기화 Map 객체 사용의 위험성 실제 서비스 운영 중 자주 발생하는 대표적인 동시성 장애 예시를 살펴보겠습니다. 다음 코드는 이벤트 참여 시 사용자의 휴대폰 번호 중복을 체크하는 로직 중 일부로, Thread-Safe하지 않은 멤버 변수를 사용하여 심각한 데이터 꼬임 현상이 발생한 사례입니다. [문제의 소스코드: JSP 내 필드 선언 및 비동기 객체 사용] param; %> 장애 발생 메커니즘: Step 1: 사용자 A의 요청을 처리하는 스레드-1이 실행되어 param 변수에 A의 휴대폰 번호를 저장합니다. Step 2: 스레드-1이 중복 체크 로직을 수행하기 직전, 사용자 B의 요청을 처리하는 스레드-2가 거의 동시에 실행되어 param 변수의 내용을 B의 정보로 덮어써 버립니다. Step 3: 제어권을 되찾은 스레드-1은 원래 A의 데이터를 검증해야 하지만, 이미 덮어씌워진 param 내의 B 정보를 읽어 가 검증을 완료합니다. 결과: 사용자 A에게 \"이미 참여한 휴대폰 번호입니다\"라는 엉뚱한 예외 메시지가 출력되며 결제, 이벤트 참여 등 비즈니스 로직 전반에 치명적인 데이터 정합성 붕괴가 발생합니다. 3. Thread Safe(스레드 안전) 확보를 위한 핵심 솔루션 Thread Safe란 멀티스레드 프로그래밍에서 어떤 함수나 변수, 혹은 객체가 여러 스레드로부터 동시에 접근되어도 프로그램 실행에 아무런 문제가 없고 의도한 대로 동작함을 의미합니다. 이를 달성하기 위해 자바 환경에서 제공하는 몇 가지 안전장치를 활용할 수 있습니다. 방법 1: 암묵적 락(Intrinsic Lock) - synchronized 활용 가장 기본적이고 직관적인 동기화 방법은 synchronized 키워드를 사용하는 것입니다. 하나의 스레드가 해당 임계 영역(Critical Section)에 진입하는 순간 락(Lock)을 획득하여 다른 스레드의 접근을 차단합니다. public class SafeCounter { private int count = 0; // 한 번에 단 하나의 스레드만 본 메서드를 실행할 수 있도록 제어 public synchronized void addCount() { count++; } } 방법 2: 동시성 컬렉션(Concurrent Collection) 활용 단순히 Map의 동기화가 목적이라면, 무거운 synchronized 블록을 전체 메서드에 적용하는 것보다 성능상 월등히 우수한 ConcurrentHashMap을 사용하는 것이 권장됩니다. // 내부적으로 분할 락(Lock Striping)을 사용하여 멀티스레드 환경에서도 높은 성능과 안전성을 유지 Map safeMap = new ConcurrentHashMap<>(); 방법 3: 지역 변수(Local Variable)의 사용 극대화 가장 근본적인 해결책은 공유 자원 자체를 만들지 않는 것입니다. 스레드마다 고유하게 할당되는 '스택(Stack)' 영역 내에 지역 변수를 선언하여 사용하면 스레드 간 자원 공유를 원천적으로 차단할 수 있습니다. 4. 결론: 안정적인 웹 서비스를 위한 개발자의 자세 애플리케이션의 아키텍처가 점차 분산 환경 및 마이크로서비스로 고도화됨에 따라 동시성 제어 기술은 백엔드 개발자의 필수 소양이 되었습니다. 개발 시 단일 사용자 접속 테스트(Local QA) 단계에서는 발견되지 않는 동시성 버그는 실서비스 배포 시점에 트래픽 폭증과 함께 대형 장애로 이어지기 쉽습니다. 스스로 작성한 코드에서 여러 스레드가 경쟁 상태(Race Condition)에 놓일 가능성이 있는지 항상 의심하고, 적절한 동기화 도구와 디자인 패턴을 활용하여 견고하고 안전한 소프트웨어를 설계하시기 바랍니다.
자세히 보기 →JAVA
Java를 활용한 개인정보(이름) 마스킹 로직 가이드
개인정보 보호의 핵심: Java를 활용한 이름 마스킹 로직 완벽 가이드 개인정보 보호는 현대 디지털 환경에서 기업과 개발자가 반드시 준수해야 할 중요한 의무입니다. 특히 사용자의 이름과 같은 민감한 정보는 유출 시 심각한 문제를 야기할 수 있어, 데이터를 안전하게 보호하기 위한 강력한 조치가 필요합니다. 이 글에서는 Java를 이용한 이름 마스킹(Masking) 로직을 상세히 설명하고, 보안 및 규제 준수(예: GDPR, PIPA)를 위한 실용적인 구현 전략을 제시합니다. 이름 마스킹의 중요성과 기본 원칙 이름 마스킹은 개인을 식별할 수 있는 정보를 부분적으로 가려내어 익명성을 확보하는 기술입니다. 이는 데이터베이스, 로그, 보고서 등 다양한 환경에서 개인정보의 노출을 최소화하는 데 사용됩니다. 효과적인 이름 마스킹은 다음과 같은 원칙을 따릅니다. 부분 공개: 사용자에게 일부 정보는 노출하여 인지 가능성을 유지하되, 전체 식별은 어렵게 합니다. (예: 홍*동) 비가역성: 마스킹된 정보는 원본으로 복구할 수 없어야 합니다. 일관성: 동일한 원본 데이터는 항상 동일하게 마스킹되어야 합니다 (필요에 따라). 유니코드 지원: 다국어 이름 처리를 위해 유니코드 문자열을 정확히 다루어야 합니다. Java로 구현하는 이름 마스킹 로직 아래 Java 코드는 개인의 이름을 효과적으로 마스킹하는 범용적인 로직을 구현합니다. 이 로직은 한 글자, 두 글자, 그리고 세 글자 이상의 이름에 대해 각각 다른 마스킹 규칙을 적용하여 실용성을 높였습니다. public static String maskName(String name) { if (name == null || name.isEmpty()) { return name; } int length = name.codePointCount(0, name.length()); // 한 글자 if (length == 1) { return name; } // 두 글자 if (length == 2) { int firstEnd = name.offsetByCodePoints(0, 1); return name.substring(0, firstEnd) + "*"; } // 세 글자 이상 int firstEnd = name.offsetByCodePoints(0, 1); int lastStart = name.offsetByCodePoints(0, length - 1); StringBuilder sb = new StringBuilder(name.length()); sb.append(name, 0, firstEnd); for (int i = 1; i 김) 두 글자 이름 처리: '이름'과 같은 두 글자 이름은 첫 글자만 남기고 나머지를 '*'로 마스킹합니다. (예: 김철 -> 김*) 세 글자 이상 이름 처리: '홍길동'과 같은 세 글자 이상 이름은 첫 글자와 마지막 글자를 유지하고 중간 글자들을 '*'로 마스킹합니다. (예: 홍길동 -> 홍*동, 대한민국 -> 대**국) StringBuilder 활용: 문자열을 반복적으로 수정할 경우 `StringBuilder`를 사용하는 것이 `String`의 불변성으로 인한 성능 저하를 방지하여 효율적입니다. 결론 및 추가 고려사항 이름 마스킹은 개인정보 보호의 필수적인 부분이며, 위에서 제시된 Java 로직은 다양한 이름 길이에 대응하며 유니코드 문자열을 안전하게 처리할 수 있는 견고한 솔루션입니다. 개발자는 이 로직을 활용하여 애플리케이션의 개인정보 처리 방식을 강화하고, 법적 규제 준수에도 기여할 수 있습니다. 추가적으로, 마스킹된 데이터는 개발 및 테스트 환경에서 활용될 수 있으나, 민감한 정보를 완전히 제거하거나 암호화하는 다른 보안 기법(예: 토큰화, 암호화)과 함께 고려하여 전반적인 데이터 보안 전략을 수립하는 것이 중요합니다.
자세히 보기 →JAVA
Java Thread-Safe 간략 메모
public class ThreadSafeTest { // 여러 스레드가 공유하는 상태(Shared State) // 동기화 없이 동시에 접근하면 Race Condition 발생 가능 private int number = 0; public void method() { // Thread Safe 하지 않음 // 공유 멤버변수를 읽고 수정하므로 동기화 필요 this.number = this.number + 1; this.number++; // Thread Safe // 지역변수는 각 스레드마다 독립적으로 생성되므로 동기화 필요 없음 int number = 0; number++; // Thread Safe 하지 않음 // 이유는 method_a()가 공유 멤버변수를 변경하기 때문 method_a(); // Thread Safe // method_b()는 지역변수만 사용하므로 여러 스레드가 동시에 호출해도 안전 method_b(); } // Thread Safe 하지 않음 // 공유 멤버변수를 변경함 public int method_a() { this.number++; return this.number; } // Thread Safe // 지역변수만 사용하며 공유 상태를 변경하지 않음 public int method_b() { int number = 0; number++; return number; } // Thread Safe // synchronized로 동기화하여 안전하게 공유 상태를 변경 public synchronized int method_c() { number++; return number; } // Thread Safe // synchronized block으로 동기화하여 안전하게 공유 상태를 변경 public int method_d() { synchronized (this) { number++; return number; } } } [이 게시물은 이재민님에 의해 2026-03-04 13:54:05 개발에서 이동 됨]
자세히 보기 →JAVA
진수 변환 함수 (62진수 까지)
진수 변환, 왜 필요할까요? 숫자의 진법 변환은 컴퓨터 과학과 프로그래밍에서 매우 기본적인 동시에 중요한 개념입니다. 일반적으로 우리는 10진수를 사용하지만, 컴퓨터는 2진수를 기반으로 작동하며, 때로는 16진수나 8진수가 데이터를 표현하거나 디버깅하는 데 유용합니다. 더 나아가, 고유 ID 생성, 짧은 URL 구현, 데이터 압축 등 다양한 응용 분야에서 10진수 이상의 고유한 문자를 사용하는 고진수 변환이 필요할 때가 있습니다. 자바(Java)에서는 기본적으로 2진수, 8진수, 16진수 변환을 위한 메서드를 제공하지만, 36진수 (숫자 + 소문자 알파벳)를 넘어서는 62진수 (숫자 + 소문자 알파벳 + 대문자 알파벳)와 같은 고진수 변환은 직접 구현해야 합니다. 이번 글에서는 2진수부터 62진수까지 모든 양수 및 음수에 대해 범용적으로 동작하는 최적화된 진수 변환 유틸리티 클래스를 소개합니다. NumberUtil: 2 ~ 62 진법 변환 유틸리티 다음은 주어진 long 타입 숫자를 원하는 진수로 변환하는 `numberToBase` 메서드를 포함하는 `NumberUtil` 클래스입니다. 이 메서드는 0부터 9까지의 숫자, 'a'부터 'z'까지의 소문자, 'A'부터 'Z'까지의 대문자를 활용하여 최대 62진수까지 표현할 수 있도록 설계되었습니다. package com.example.util; public final class NumberUtil { private static final char[] DIGITS = { '0','1','2','3','4','5','6','7','8','9', 'a','b','c','d','e','f','g','h','i','j', 'k','l','m','n','o','p','q','r','s','t', 'u','v','w','x','y','z', 'A','B','C','D','E','F','G','H','I','J', 'K','L','M','N','O','P','Q','R','S','T', 'U','V','W','X','Y','Z' }; /** * 주어진 10진수(long)를 2에서 62 사이의 지정된 진수로 변환합니다. * 음수도 정확하게 처리하며, 변환된 결과는 String 형태로 반환됩니다. * * @param num 변환할 10진수 숫자 (long 타입) * @param radix 목표 진수 (2 이상 62 이하) * @return 지정된 진수로 변환된 숫자의 문자열 표현 * @throws IllegalArgumentException radix가 2 미만이거나 62 초과일 경우 발생 */ public static String numberToBase(long num, int radix) { if (radix 62) { throw new IllegalArgumentException("radix는 2 이상 62 이하만 가능합니다."); } if (num == 0L) { return "0"; } boolean negative = (num < 0L); long value = negative ? -num : num; // 음수 처리 // long 타입의 최대 자릿수는 64비트이므로, 2진수 기준 최대 64자리 + 부호(-)를 고려하여 버퍼 크기를 65로 설정합니다. char[] buffer = new char[65]; int index = buffer.length; // 버퍼의 끝에서부터 채워나가기 위한 인덱스 while (value != 0L) { // 현재 값을 radix로 나눈 나머지가 해당 진법의 한 자릿수가 됩니다. buffer[--index] = DIGITS[(int)(value % radix)]; // 값을 radix로 나누어 다음 자릿수를 계산합니다. value /= radix; } if (negative) { buffer[--index] = '-'; // 음수인 경우 맨 앞에 '-' 추가 } // 버퍼의 index 위치부터 (buffer.length - index) 길이만큼의 문자열을 생성하여 반환합니다. return new String(buffer, index, buffer.length - index); } // 간단한 테스트를 위한 main 메서드 (선택 사항) public static void main(String[] args) { System.out.println("10 (2진수): " + numberToBase(10, 2)); // 1010 System.out.println("10 (16진수): " + numberToBase(10, 16)); // a System.out.println("61 (62진수): " + numberToBase(61, 62)); // Z System.out.println("1000 (36진수): " + numberToBase(1000, 36)); // rs System.out.println("-10 (2진수): " + numberToBase(-10, 2)); // -1010 System.out.println("0 (10진수): " + numberToBase(0, 10)); // 0 System.out.println("long.MAX_VALUE (62진수): " + numberToBase(Long.MAX_VALUE, 62)); // 예상 출력: 1L9g41L7g61 } } 코드 설명: DIGITS 배열: '0'부터 '9', 'a'부터 'z', 'A'부터 'Z'까지 총 62개의 문자를 포함하는 배열입니다. 이 배열의 인덱스가 각 진수의 숫자에 해당합니다. 예를 들어, DIGITS[10]은 'a'를 의미하며, 이는 10진수의 10을 표현합니다. radix 유효성 검사: 진수는 최소 2 (2진수)부터 최대 62까지 가능하도록 제한합니다. 유효하지 않은 값이 입력되면 `IllegalArgumentException`을 발생시킵니다. 0 처리: 입력 `num`이 0일 경우, 즉시 "0"을 반환하여 불필요한 계산을 방지합니다. 음수 처리: 입력 `num`이 음수일 경우, `negative` 플래그를 true로 설정하고 `value`를 양수로 변환하여 계산합니다. 최종 결과에 '-' 부호를 추가하는 방식으로 처리합니다. 변환 로직: `char[] buffer`는 변환된 진수 문자열을 저장할 임시 공간입니다. `long` 타입의 최대 자릿수를 고려하여 충분한 크기(65)로 할당합니다. `while (value != 0L)` 루프는 `value`가 0이 될 때까지 반복됩니다. `value % radix` 연산을 통해 현재 진법의 가장 낮은 자릿수(나머지)를 얻습니다. 이 값은 `DIGITS` 배열의 인덱스로 사용되어 해당하는 문자를 찾습니다. `buffer[--index]`를 통해 `buffer`의 끝에서부터 문자를 채워나갑니다. 이 방법은 변환된 숫자가 역순으로 계산되기 때문에 나중에 문자열을 생성할 때 순서를 뒤집을 필요 없이 바로 사용할 수 있게 합니다. `value /= radix` 연산을 통해 다음 자릿수를 계산하기 위해 `value`를 `radix`로 나눕니다. 결과 반환: 모든 계산이 끝난 후, `index`부터 `buffer.length - index` 길이만큼의 문자 배열을 이용하여 새로운 `String` 객체를 생성하여 반환합니다. 이 방식으로 효율적으로 문자열을 구성합니다. 활용 예시: 이 `NumberUtil` 클래스는 고유 ID 생성 시스템, URL 단축 서비스, 데이터 인코딩/디코딩 등 다양한 곳에서 유용하게 활용될 수 있습니다. 특히 62진수는 숫자, 소문자, 대문자를 모두 사용하여 같은 길이의 문자열로 더 많은 정보를 표현할 수 있어 매우 효율적입니다.
자세히 보기 →JAVA
Redis Session 개념 및 로직 설명
Redis Session의 핵심 컴포넌트 이해: Filter, Request, Manager, Session 서버를 여러 대 두는 분산 환경에서 '세션 관리'는 서비스의 안정성을 결정짓는 핵심 요소입니다. 단순히 Redis를 연결하는 것을 넘어, 내부적으로 세션이 어떻게 생성되고 관리되는지 그 메커니즘을 이해하는 것은 장애 대응과 성능 최적화에 큰 도움이 됩니다. 오늘은 Redis Session 구조의 뼈대를 이루는 4가지 핵심 컴포넌트의 역할과 상호작용 로직을 정리해 보겠습니다. 1. RedisSessionFilter: 표준 세션을 Redis로 전환하는 스위치 역할: 모든 HTTP 요청의 흐름을 제어하는 진입점 이 컴포넌트는 서블릿 필터(Servlet Filter)로서, 애플리케이션으로 들어오는 모든 요청을 가장 먼저 처리합니다. 기존의 톰캣(Tomcat) 같은 WAS가 관리하던 로컬 세션 메커니즘을 Redis 기반으로 갈아끼우는 역할을 수행합니다. JSESSIONID 대신 Redis에서 사용할 SESSIONID를 쿠키에 넣는 작업을 하고, 해당 쿠키를 기반으로 세션을 공유합니다. 동작 로직:HttpServletRequest를 가로채 Redis 전용 래퍼 객체로 감쌉니다.요청이 완료되는 시점에 세션의 최종 상태를 확인하고, 변경 사항이 있다면 이를 Redis 데이터베이스에 반영(Commit)하도록 지시합니다. 2. RedisSessionRequest: 세션 조회 로직의 재정의 역할: 애플리케이션과 Redis 저장소 사이의 중개자 개발자가 코드상에서 request.getSession()을 호출할 때, 실제로 동작하는 것은 바로 이 래핑된 요청 객체입니다. 동작 로직:사용자의 요청에 포함된 세션 쿠키(Session ID)를 분석합니다.로컬 메모리가 아닌 외부 저장소(Redis)에서 세션 데이터를 찾아오도록 로직이 설계되어 있어, 서버가 바뀌어도 동일한 세션을 유지할 수 있게 합니다. 3. RedisSessionManager: 세션 데이터의 생명주기 관리 역할: 실질적인 Redis CRUD 및 영속성 담당 Manager는 이름 그대로 세션의 생성, 저장, 조회, 삭제를 총괄하는 컨트롤러입니다. Redis와의 직접적인 통신은 대개 이 계층을 통해 이루어집니다. 동작 로직:직렬화 및 저장: 세션 객체를 Redis에 저장 가능한 형태(바이트 배열 등)로 변환하고, 적절한 만료 시간(TTL)을 부여합니다.조회 및 복원: Redis에 저장된 데이터를 가져와 다시 Java 객체 형태로 복구합니다.네트워크 지연이나 Redis 연결 오류 등에 대한 예외 처리를 담당하는 핵심 지점이기도 합니다. 4. RedisSession: 분산 환경에 최적화된 데이터 모델 역할: 사용자 정보를 담는 저장소이자 변경 감지 모델 표준 HttpSession 인터페이스를 구현한 클래스로, 실제 사용자의 로그인 정보나 상태값이 저장되는 곳입니다. 동작 로직:Dirty Check: 세션 내부의 속성(Attribute)이 변경되었는지 실시간으로 추적합니다.데이터가 실제로 변경된 경우에만 Redis에 다시 쓰는 방식을 채택하여, 불필요한 네트워크 트래픽과 Redis의 I/O 부하를 최소화합니다. 실무 운영을 위한 한 마디 Redis 세션을 도입할 때 가장 흔히 겪는 문제는 '객체 직렬화' 관련 오류입니다. 세션에 담기는 모든 객체는 반드시 직렬화가 가능해야 하며, 클래스 구조가 변경될 경우 세션 복원 과정에서 에러가 발생할 수 있습니다. 따라서 세션에는 가급적 가볍고 직렬화에 안전한 데이터 위주로 담는 것이 운영 측면에서 유리합니다. 또한, 세션 만료 시간 설정 시 Redis의 TTL과 애플리케이션의 세션 타임아웃 설정이 일치하는지 반드시 확인해야 세션이 예상보다 일찍 끊기는 현상을 방지할 수 있습니다. [이 게시물은 이재민님에 의해 2026-03-04 13:56:31 설정 가이드에서 이동 됨]
자세히 보기 →JAVA
외부 라이브러리 없이 구현하는 효율적인 파일 업로드: request.getParts() 활용법
웹 애플리케이션을 개발하다 보면 프로필 사진 업로드나 문서 첨부 같은 파일 업로드 기능은 필수적으로 들어가게 마련입니다. 예전에는 Apache Commons FileUpload 같은 외부 라이브러리를 사용하는 것이 당연시되었지만, 서블릿 3.0 표준이 등장하면서 상황이 완전히 바뀌었습니다. 이제는 복잡한 설정 없이도 자바 표준 API인 HttpServletRequest.getParts()를 통해 아주 우아하게 파일을 주고받을 수 있게 되었죠. 오늘은 실무에서 바로 적용할 수 있는 getParts() 사용법과 주의사항을 깊이 있게 다뤄보겠습니다. 1. 왜 request.getParts()를 사용해야 할까? 가장 큰 이유는 표준성과 간결함입니다. 라이브러리 의존성을 줄이는 것은 프로젝트의 가벼움을 유지하고 보안 취약점 관리 측면에서도 매우 유리합니다. 의존성 제거 : pom.xml이나 build.gradle에 별도의 라이브러리를 추가할 필요가 없습니다.직관적인 API : Part 인터페이스를 통해 파일명, 크기, Content-Type 등을 쉽게 가져올 수 있습니다.성능 최적화 : 서블릿 컨테이너(Tomcat 등) 레벨에서 직접 처리하므로 데이터 처리 효율이 높습니다.기본 API : 톰캣에 가장 최적화된 로직으로 동작합니다. 2. 기본 설정: @MultipartConfig request.getParts()를 사용하기 위해서는 서블릿에 멀티파트 데이터를 처리할 준비가 되었다고 알려줘야 합니다. 이때 사용하는 것이 @MultipartConfig 어노테이션입니다. @WebServlet("/upload") @MultipartConfig( fileSizeThreshold = 1024 * 1024 * 1, // 1MB (메모리에서 처리할 임계치) maxFileSize = 1024 * 1024 * 10, // 10MB (파일 하나당 최대 크기) maxRequestSize = 1024 * 1024 * 15 // 15MB (전체 요청 최대 크기) ) public class FileUploadServlet extends HttpServlet { // ... 구현부 } 이 설정이 없으면 getParts()를 호출했을 때 멀티파트 요청이 아니라는 예외가 발생할 수 있으니 반드시 체크해야 합니다. 3. 실무형 구현 코드: request.getParts() 이제 실제 컨트롤러(서블릿) 단계에서 파일을 어떻게 처리하는지 코드로 살펴보겠습니다. protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { // 저장 경로 설정 (실제 서버 경로 혹은 외부 저장소) String uploadPath = "C:/uploads"; File uploadDir = new File(uploadPath); if (!uploadDir.exists()) uploadDir.mkdir(); // 1. 모든 Part 가져오기 (파일뿐만 아니라 일반 텍스트 데이터도 Part로 전달됨) Collection parts = request.getParts(); for (Part part : parts) { // 2. 파일인 경우만 필터링 (파일명이 존재하는 경우) String fileName = getFileName(part); if (fileName != null && !fileName.isEmpty()) { // 3. 파일 저장 part.write(uploadPath + File.separator + fileName); System.out.println(fileName + " 저장 완료!"); } } } // 헤더에서 파일명을 추출하는 헬퍼 메서드 private String getFileName(Part part) { String contentDisp = part.getHeader("content-disposition"); for (String content : contentDisp.split(";")) { if (content.trim().startsWith("filename")) { return content.substring(content.indexOf("=") + 2, content.length() - 1); } } return null; } 실제 사례 Tip: 실제 상용 서비스에서는 위 코드처럼 파일명을 그대로 저장하면 보안 위험(Path Traversal)이 있거나 파일명 중복 문제가 발생할 수 있습니다. 저 같은 경우 실무에서 UUID.randomUUID()를 활용해 파일명을 치환하고, DB에는 원본 파일명과 저장 파일명을 따로 관리하는 방식을 선호합니다. 4. 핵심 체크포인트 파일 업로드는 보안과 직결되는 문제입니다. 구글이 강조하는 신뢰성(Trustworthiness)을 높이기 위해 다음 사항을 꼭 고려하세요. 확장자 검증: 클라이언트 측 검증은 필수지만, 서버 측에서도 허용된 확장자(jpg, png, pdf 등)인지 반드시 재검증해야 합니다.파일 크기 제한: 무분별하게 큰 파일이 업로드되면 서버 리소스가 고갈됩니다. @MultipartConfig의 설정을 통해 원천 봉쇄하세요.저장 위치 분리: 업로드된 파일이 실행 권한을 가지지 않도록 WAS의 웹 루트(Web Root) 외부 경로에 저장하는 것이 보안의 정석입니다. 결론 request.getParts()는 현대적인 자바 웹 개발에서 가장 깔끔한 파일 업로드 해결책입니다. 라이브러리에 의존하지 않고 표준 API를 깊이 있게 이해하고 사용하는 것만으로도 여러분의 코드는 한층 더 견고해질 것입니다. 오늘 다룬 내용을 바탕으로 더 안전하고 효율적인 파일 업로드 로직을 구축해 보시기 바랍니다. 출처 및 참고: Oracle Java EE 7 Documentation - Interface Part [이 게시물은 이재민님에 의해 2026-03-04 13:53:30 개발에서 이동 됨]
자세히 보기 →JAVA
서비스 확장을 위한 세션 클러스터링(Session Clustering) 분석과 선택 가이드 (톰캣 vs Redis)
서비스 확장을 위한 세션 클러스터링(Session Clustering) 분석과 선택 가이드 웹 서비스 규모가 커지면 단일 서버만으로는 트래픽을 감당하기 어려워집니다. 여러 대의 서버로 부하를 분산하는 스케일 아웃(Scale-out) 과정에서 반드시 해결해야 할 과제가 바로 세션 관리입니다. 사용자가 A 서버에서 로그인한 뒤 다음 요청이 B 서버로 전달될 때, 로그인 정보가 공유되지 않으면 서비스 연속성이 끊기게 됩니다. 이러한 세션 불일치 문제를 해결하여 어떤 서버로 접속하더라도 동일한 상태를 유지하게 하는 기술이 세션 클러스터링입니다. 실무에서 주로 검토되는 두 가지 방식인 Tomcat 자체 복제와 Redis 공유 저장소 방식을 비교하여 최적의 설계 방향을 제시합니다. 1. Tomcat 세션 복제 방식 (Session Replication) Tomcat의 클러스터링 기능을 활용하여 각 WAS(Web Application Server)가 세션 데이터를 서로 복제하여 공유하는 방식입니다. 구조: 모든 서버가 동일한 세션 정보를 나누어 가집니다. 별도의 외부 데이터베이스가 필요 없습니다. 장점: 초기 인프라 구축 비용이 낮고 설정이 비교적 간단하여 소규모 시스템에 적합합니다. 단점: 서버 수가 늘어날수록 복제에 필요한 네트워크 트래픽과 메모리 사용량이 기하급수적으로 증가합니다. 통상적으로 4~5대 이상의 서버 구성에서는 성능 저하가 뚜렷하게 나타납니다. 현재 사용 여부: 확장성 한계로 인해 대규모 트래픽을 처리하는 현대적인 마이크로서비스 아키텍처(MSA)나 클라우드 환경에서는 거의 사용되지 않습니다. 2. Redis 기반 세션 저장소 방식 (Session Storage) 세션 데이터를 외부의 고속 메모리 데이터베이스인 Redis에 저장하고, 모든 서버가 이를 공유하는 방식입니다. 구조: 애플리케이션 서버는 세션 데이터를 직접 보유하지 않고(Stateless), 필요할 때마다 Redis에서 읽어옵니다. 장점: 서버 대수와 상관없이 일관된 성능을 유지하며 확장성이 매우 뛰어납니다. 서버 장애 시에도 세션 데이터가 유실되지 않아 사용자 경험이 안정적입니다. 단점: Redis 인프라를 별도로 운영해야 하며, Redis 자체의 가용성(High Availability)을 확보하기 위한 추가 설정(Sentinel, Cluster 등)이 필요합니다. 현재 사용 여부: 트래픽 변동이 잦고 확장이 빈번한 대다수의 현대적 웹 서비스에서 표준으로 채택하고 있습니다. 3. Tomcat 세션 복제 vs Redis 세션 저장소 비교 분석 비교 항목 Tomcat 세션 복제 Redis 세션 저장소 확장성 낮음 (서버 증가 시 노드 간 복제 오버헤드 급증) 매우 높음 (Scale-out에 최적화) 데이터 일관성 복제 시차에 따른 불일치 가능성 존재 중앙 관리 방식으로 즉각적인 일관성 보장 자원 효율성 모든 서버에 동일 세션을 중복 저장 (메모리 낭비) 필요할 때만 조회하여 메모리 효율적 운영 환경 고정된 수의 소규모 서버군에 적합 클라우드 및 오토 스케일링 환경에 최적화 4. 세션 클러스터링 설계의 핵심 선택 기준 성능과 확장성 면에서 Redis를 활용한 방식이 실무적으로 훨씬 유리합니다. 특히 트래픽에 따라 서버가 자동으로 생성되고 삭제되는 클라우드 환경(Auto Scaling)에서는 서버 간 직접 복제 방식이 구조적으로 불가능에 가깝습니다. 시스템을 '상태가 없는(Stateless)' 구조로 설계하여 관리 포인트를 외부 저장소로 일원화하는 것이 장기적인 안정성 측면에서 올바른 방향입니다. 5. 왜 Redis인가? 최근의 서비스 환경은 트래픽 변화에 따라 서버 대수를 유동적으로 조절하는 Auto Scaling이 기본입니다. 서버가 수시로 생성되고 소멸되는 환경에서, 서버끼리 데이터를 주고받는 방식은 구조적으로 결함이 생길 수밖에 없습니다. 상태가 없는(Stateless) 애플리케이션 서버를 지향하는 현대 설계 철학에도 Redis 방식이 완벽히 부합합니다. 6. 도입 시 고려해야 할 위험 요소 Redis 방식을 도입할 때 주의할 점은 단일 장애점(SPOF) 문제입니다. 세션 저장소인 Redis에 장애가 발생하면 전체 서비스의 로그인이 마비됩니다. 따라서 실제 운영 환경에서는 반드시 Redis를 이중화하거나 클러스터로 구성하여 물리적 장애에 대비해야 합니다. 반면, Tomcat 복제 방식은 구현은 쉬워 보이지만 서버가 늘어날수록 관리가 불가능해지는 '성능의 덫'에 빠지기 쉽습니다. 따라서 초기 단계부터 미래의 확장성을 고려한 설계가 필요합니다. 결론 안정적인 웹 서비스 운영을 위해서는 서버 간 의존성을 낮추고 데이터 관리 주체를 명확히 분리하는 것이 중요합니다. 인프라 관리 부담이 조금 있더라도 Redis 기반의 세션 클러스터링을 구축하는 것이 서비스 신뢰도와 향후 확장성을 보장하는 가장 확실한 길입니다.
자세히 보기 →DEVELOPMENT
Base64를 사용하는 이유
Base64 인코딩이 필요한 이유 파일, 이미지, PDF와 같은 데이터는 대부분 바이너리(Binary) 형태로 저장됩니다. 하지만 인터넷이나 JSON, XML과 같은 텍스트 기반 환경에서는 바이너리 데이터를 그대로 전달하기 어려운 경우가 있습니다. 이때 사용하는 대표적인 방법이 Base64 인코딩(Base64 Encoding)입니다. 왜 Base64를 사용할까? 예를 들어 Windows의 파일 하나를 다른 서버로 전송해야 한다고 가정해 보겠습니다. C:\Windows\System32\keyboard.drv 이 파일은 단순한 문자열이 아니라 수많은 바이트(byte)로 이루어진 바이너리 데이터입니다. 만약 이 데이터를 문자열(String)로 억지로 변환해서 전송하면 어떻게 될까요? 일부 바이트가 문자로 해석되지 못할 수 있습니다. 문자 인코딩(UTF-8, EUC-KR 등)에 의해 데이터가 변경될 수 있습니다. 결과적으로 원본 파일을 완벽하게 복원할 수 없게 됩니다. 즉, 바이너리 데이터를 일반 문자열처럼 처리하면 원본이 손상될 가능성이 있습니다. Base64의 동작 원리 Base64는 바이너리 데이터를 손실 없이 안전한 문자열로 변환하는 인코딩 방식입니다. 전송 과정은 다음과 같습니다. 원본 파일(Byte[]) │ ▼ Base64 인코딩 │ ▼ 문자열(String) │ ▼ 네트워크 전송 │ ▼ Base64 디코딩 │ ▼ 원본 Byte[] 복원 이 과정을 거치면 파일의 내용이 변경되지 않으므로 원본을 그대로 복원할 수 있습니다. 바이너리 데이터 읽기 먼저 파일을 바이트 배열(byte[])로 읽어 보겠습니다. public static void main(String[] args) throws IOException { File file = new File("C:/Windows/System32/keyboard.drv"); FileInputStream fin = new FileInputStream(file); ByteArrayOutputStream bos = new ByteArrayOutputStream(); byte[] buffer = new byte[1024]; int read; while ((read = fin.read(buffer)) != -1) { bos.write(buffer, 0, read); } fin.close(); byte[] data = bos.toByteArray(); System.out.println(data.length); } 예를 들어 원본 파일의 크기가 2,000Byte라면 출력 결과 역시 2,000Byte가 됩니다. 왜 String으로 바꾸면 문제가 생길까? 바이트 배열은 문자 데이터가 아닙니다. 그런데 아래와 같이 문자열로 변환하면, String text = new String(data); Java는 현재 문자 인코딩(UTF-8 등)을 이용하여 바이트를 문자로 해석하려고 합니다. 하지만 바이너리 파일은 원래 문자 데이터가 아니므로 일부 바이트가 다른 문자로 변환되거나, 복원할 수 없는 형태로 변경될 수 있습니다. 즉, 문제의 원인은 byte가 signed이고 char가 unsigned라서가 아니라, 문자 인코딩 규칙을 적용하기 때문입니다. Base64를 사용하면? Base64는 바이너리 데이터를 문자로 안전하게 표현하도록 설계된 인코딩 방식입니다. Java에서는 매우 간단하게 사용할 수 있습니다. Base64 인코딩 String base64 = Base64.getEncoder().encodeToString(data); 입력은 byte[], 결과는 String입니다. Base64 디코딩 byte[] restored = Base64.getDecoder().decode(base64); 입력은 String, 결과는 byte[]입니다. 주의할 점 Base64는 압축 기술이 아닙니다. 오히려 데이터를 문자열로 표현하기 위해 약 33% 정도 크기가 증가합니다. 예를 들어 원본 파일 : 2,000 Byte │ ▼ Base64 인코딩 │ ▼ 약 2,668 Byte 즉, Base64의 목적은 용량을 줄이는 것이 아니라, 바이너리 데이터를 손실 없이 문자열로 안전하게 전달하는 것입니다. 정리 파일, 이미지, PDF 등은 바이너리(byte[]) 데이터이다. 바이너리 데이터를 일반 String으로 변환하면 문자 인코딩 때문에 데이터가 변경될 수 있다. Base64는 바이너리 데이터를 안전한 문자열로 변환하는 인코딩 방식이다. 전송 후 Base64를 디코딩하면 원본 byte[]를 그대로 복원할 수 있다. Base64는 압축이 아닌 인코딩이므로 데이터 크기가 약 33% 증가한다.
자세히 보기 →