프로그래밍 기록장

문자열 코딩테스트, 유형이 아니라 "도구"로 정리하기 (Java)

yolang — Mon, 6 Jul 2026 12:41:54 +0900

문자열 관련 문제는 여러 코딩테스트에서 빈번하게 등장한다.

이 글은 내가 실제로 풀고 틀린 문제들을 근거로 정리한 것이다. 문제를 "유형"으로 나열하는 대신, 어떤 도구로 푸는지 + 어디서 자주 틀리는지를 중심으로 묶었다.

이 글에서 다루는 문제 (전부 직접 풀며 틀렸던 것)

문자열 다루기 기본 — 문자열이 길이 4 또는 6이고 전부 숫자인지 판별 → 길이·문자 조건을 정규식으로 묶기
중요한 단어를 스포 방지 — 스포 처리된 단어 중 '중요한 단어' 수 세기 → 공백 파싱 함정
[3차] n진수 게임 — n진수로 이어붙인 문자열에서 특정 위치의 숫자 뽑기 → += 누적 함정

1. 문자열 도구 상자

언제 String 메서드, 언제 Pattern + Matcher?

이게 문자열 문제에서 가장 먼저 하는 판단이다. 기준은 딱 하나다.

매칭의 위치(인덱스)나 캡처 그룹이 필요 없다면 → String 메서드로 끝낸다.

인덱스나 그룹을 꺼내야 한다면 → Pattern + Matcher를 쓴다.

대부분의 문자열 문제는 String에 있는 메서드로 충분하다.

str.matches("[0-9]+");      // 전체가 패턴과 일치하는지 (부분 아님, 전체)
str.replaceAll("\\s+", " "); // 정규식으로 치환
str.split("\\s+");           // 정규식으로 분리 → String[]
str.substring(2, 5);         // 부분 문자열
str.indexOf('a');            // 위치 찾기
str.toUpperCase();           // 대소문자 변환

이 메서드들은 편하지만 원본에서의 위치를 알려주지 못한다. split은 잘린 조각만 돌려주고 인덱스를 잃어버린다. 그래서 "이 단어가 원본 몇 번째 인덱스에 있나"가 필요하면 Matcher를 써야 한다.

Pattern p = Pattern.compile("\\S+");
Matcher m = p.matcher(text);
while (m.find()) {
    m.group();   // 매칭된 문자열
    m.start();   // 원본에서의 시작 인덱스
    m.end();     // 끝 다음 인덱스
}

핵심은 Matcher가 문자열을 잘라서 새로 만드는 게 아니라, 원본 위에서 위치만 짚어준다는 점이다. 그래서 m.start()/m.end()가 원본 인덱스와 일치한다. 뒤의 스포 방지 문제에서 이게 왜 중요한지 나온다.

인덱스 추출 vs 캡처 그룹 — Matcher를 쓰는 두 이유

Matcher가 필요한 상황은 사실 두 갈래로 나뉜다. 이 둘은 다른 개념이라 구분해두면 좋다.

(1) 매칭 위치(인덱스) — start()/end()로 원본에서의 위치를 얻는다. 매칭된 조각이 원본 어디에 있는지를 알아야 할 때 쓴다. 뒤의 스포 방지 문제가 정확히 이 경우다(단어 위치로 hidden[]을 검사해야 함).

(2) 캡처 그룹 — 정규식 안에 ( )로 부분을 묶어두고 group(1), group(2)로 그 조각을 따로 꺼낸다. 하나의 매칭을 여러 필드로 분해할 때 쓴다. 예를 들어 2025-09-10 같은 날짜를 연·월·일로 쪼갠다면 이렇게 쓸 수 있다:

Matcher m = Pattern.compile("(\\d+)-(\\d+)-(\\d+)").matcher("2025-09-10");
if (m.find()) {
    int year  = Integer.parseInt(m.group(1)); // 캡처 그룹 1 → 2025
    int month = Integer.parseInt(m.group(2)); // 캡처 그룹 2 → 9
    int day   = Integer.parseInt(m.group(3)); // 캡처 그룹 3 → 10
}

참고로 같은 패턴을 반복 사용할 거면 Pattern.compile()을 한 번만 해두고 재사용하는 게 좋다(compile은 비교적 무거운 작업이다). String.matches()도 내부에서 매번 compile하므로, 루프 안에서 같은 패턴을 검사한다면 Pattern을 미리 만들어 두자.

알아두면 좋은 정규식 조각

조각	의미
`\d` / `\D`	숫자 / 숫자 아님
`\s` / `\S`	공백 / 공백 아님
`\w` / `\W`	영문·숫자·밑줄 / 그 외
`+` `*` `?`	1번 이상 / 0번 이상 / 0 또는 1번
`{4}` `{2,4}`	정확히 4번 / 2~4번
`[abc]` `[^abc]`	a·b·c 중 하나 / 그것들 제외
`\|`	또는
`^` `$`	문자열 시작 / 끝

자바에서는 \가 두 번 이스케이프되므로 "\\d", "\\S+"처럼 백슬래시를 두 개 쓴다.

StringBuilder — 문자열을 "쌓을" 때

자바의 String은 불변(immutable)이다. 그래서 반복문에서 +=로 이어붙이면 매번 새 문자열을 통째로 복사한다. 길이 n짜리를 n번 붙이면 O(n²)가 되어 버린다. 문자열을 반복해서 쌓을 때는 반드시 StringBuilder를 쓴다.

StringBuilder sb = new StringBuilder();
for (...) sb.append(x);   // O(n) 누적
String result = sb.toString();

char 산술

문자는 정수처럼 연산된다. 아스키 코드 기반이라 이런 계산이 가능하다.

char c = 'c';
int idx = c - 'a';        // 2 (a부터 몇 번째인지)
char up = (char) (c - 32); // 'C' (소문자 → 대문자)
int d = '7' - '0';        // 7 (문자 숫자 → 정수)

2. 내가 실제로 틀린 함정들

함정 1. 길이·문자 조건을 부등호도 좋지만 정규식도 가능

문자열 다루기 기본은 문자열이 길이 4 또는 6이면서 전부 숫자인지를 판별한다.

if (s.length() != 4 && s.length() != 6) return false;
return s.matches("[0-9]+");

이런 조건은 부등호로 적어도 좋지만 정규식으로도 가능하다.

matches는 문자열 전체가 맞아야 하므로 {4}, {6}이 곧 길이 제약이 되고, 문자 종류([0-9])까지 한 번에 표현된다.

return s.matches("[0-9]{4}|[0-9]{6}");  // 숫자 4개 또는 숫자 6개

교훈: 길이 같은 수치 조건도 부등호로 나누기보다 정규식 {n}으로 표현하면 사이값 실수가 사라지고, 문자 종류 검사까지 한 번에 묶을 수 있다.

함정 2. 수동 파싱의 인덱스 off-by-one (선행 공백)

메시지에서 스포 처리된 단어 중 '중요한 단어' 수를 세는 중요한 단어를 스포 방지에서, 처음엔 end 인덱스를 직접 움직이며 공백을 찾는 방식으로 파싱했다. 채점에서 딱 2개만 틀렸는데, 시간이 아주 짧게 실패해서(=시간초과 아님) 작은 입력의 엣지임을 알 수 있었다.

원인은 파싱 시작점이었다. 인덱스 1부터 검사를 시작해서 인덱스 0을 경계로 검사하지 않았고, 그래서 메시지가 공백으로 시작하면 첫 단어가 "here"가 아니라 " here"(앞 공백 포함)로 잘렸다. 그러면 이 단어가 뒤쪽 평문 "here"와 문자열이 달라져 매칭에 실패한다.

제한사항엔 "공백은 연속해서 등장하지 않습니다"는 있었지만 선행 공백을 금지하는 문구는 없었다. 명시적으로 배제되지 않은 케이스는 테스트에 나온다.

해결은 파싱을 직접 짜지 않고 \S+ 매처에 위임하는 것이었다. \S+는 정의상 공백이 아닌 문자에서만 시작하므로, 앞·뒤·연속 공백이 몇 개든 단어의 진짜 시작을 짚는다. 오프바이원이 생길 자리 자체가 사라진다.

교훈: 파싱은 인덱스를 손으로 굴리지 말고 split·\S+ 같은 검증된 도구에 맡긴다. 꼭 직접 짜야 하면 앞공백·뒷공백·한 글자 단어·경계 인덱스(0과 n-1)를 반드시 손으로 돌려본다.

함정 3. 반복문에서 String += → O(n²)

n진수로 0, 1, 2, …를 이어붙인 문자열에서 특정 위치의 숫자를 뽑는 [3차] n진수 게임을 이렇게 통과는 시켰는데, 시간 2327ms / 메모리 381MB로 아슬아슬했다.

String total = "";
for (Integer i = 0; i < m * t; i++) {
    total += Integer.toString(i, n);   // 매 반복마다 total 전체를 복사 → O(n²)
}
String answer = "";
for (int idx = 0; idx < total.length(); idx++) {
    if (idx % m == (p - 1)) {
        answer += total.substring(idx, idx + 1);  // 여기도 += 누적
        ...
    }
}

문자열이 불변인데 +=로 계속 쌓으니 붙일 때마다 전체 복사가 일어난다. StringBuilder로 바꾸면 극적으로 빨라진다. 그리고 진법 변환은 직접 나눗셈을 돌릴 필요 없이 Integer.toString(값, 진수)가 해준다(반대는 Integer.parseInt(문자열, 진수)).

class Solution {
    public String solution(int n, int t, int m, int p) {
        int need = p + (t - 1) * m;              // 마지막으로 필요한 위치 + 1
        StringBuilder total = new StringBuilder();
        for (int i = 0; total.length() < need; i++)
            total.append(Integer.toString(i, n)); // n진수 변환은 내장 메서드로
        StringBuilder answer = new StringBuilder();
        for (int i = 0; i < t; i++)
            answer.append(total.charAt(p - 1 + i * m));
        return answer.toString().toUpperCase();   // 10~15 → A~F
    }
}

두 가지를 고쳤다. total·answer를 StringBuilder로 바꿔 O(n) 누적으로 만들었고, 필요한 길이(need)까지만 생성해 불필요한 반복도 줄였다. 세 입출력 예 모두 동일하게 통과한다.

효과는 채점에서 그대로 드러났다. 원래 코드가 최악 2327ms / 381MB였는데, 이 버전은 가장 무거운 테스트에서도 10~15ms / 91MB로 떨어졌다. 대략 150배 빨라지고 메모리도 4배 가까이 줄었다. 입력이 작은 케이스에선 둘 다 1ms 미만이라 티가 안 나지만, 문자열이 길어질수록 +=의 복사 비용이 제곱으로 커진 게 수치로 확인된다.

교훈: 문자열을 반복해서 쌓으면 무조건 StringBuilder. 진법 변환은 Integer.toString(값, 진수) / Integer.parseInt(문자열, 진수)를 기억하자.

3. 유형별 접근과 대표 문제

각 유형이 결국 어떤 도구로 환원되는지 한 줄로 정리하고, 실제 풀이를 근거로 연결한다.

검증(validation) — "형식이 맞나?"

문자열 전체가 규칙에 맞는지 확인하는 유형. matches 한 방이면 끝난다. 길이·문자종류를 정규식 안에 녹이는 게 핵심.

대표 문제: 문자열 다루기 기본 (12918) → s.matches("[0-9]{4}|[0-9]{6}")

파싱/토큰화 + 치환/마스킹 — "쪼개서 분류한다"

공백이나 구분자로 단어를 나누고, 각 단어를 조건에 따라 분류·집계하는 유형. 인덱스가 필요하면 \S+ 매처, 아니면 split. 그리고 분류 결과는 Set/Map으로 관리한다. 특히 "A 집합에는 있고 B 집합에는 없는 것"은 set.removeAll()로 표현한다.

대표 문제: 중요한 단어를 스포 방지 (468370)

이 문제는 서술이 "왼쪽부터 클릭해 공개"라는 절차처럼 보이지만, 실제로는 순서와 무관한 집합 연산으로 붕괴된다. 답 = (스포 단어 집합) − (평문 단어 집합)의 크기. 단어의 원본 인덱스로 스포 여부를 판정해야 해서 Matcher의 start()/end()를 썼다(캡처 그룹이 아니라 위치가 필요한 경우다).

boolean[] hidden = new boolean[message.length()];
for (int[] r : spoiler_ranges)
    for (int i = r[0]; i <= r[1]; i++) hidden[i] = true;

Set<String> spoiler = new HashSet<>(), normal = new HashSet<>();
Matcher m = Pattern.compile("\\S+").matcher(message);
while (m.find()) {
    boolean sp = false;
    for (int k = m.start(); k < m.end(); k++) if (hidden[k]) sp = true;
    (sp ? spoiler : normal).add(m.group());
}
spoiler.removeAll(normal);   // 평문에도 등장한 단어 제거
return spoiler.size();

진법 변환 + 문자열 빌드 — "숫자를 문자열로 쌓는다"

진법을 바꿔가며 문자열을 길게 만드는 유형. Integer.toString(값, 진수)로 변환하고, 누적은 StringBuilder로 한다. +=를 쓰는 순간 O(n²)로 터진다(실측으로 2327ms → 15ms 차이가 났다).

대표 문제: [3차] n진수 게임 (17687)

마무리

문자열 문제는 알고리즘 난이도보다 요구사항을 정확한 조건으로 줄였는가 + 파싱을 안전하게 했는가에서 승부가 갈린다. 도구 선택은 "인덱스/그룹이 필요한가"로 갈리고, 실수는 대개 경계값·공백 파싱·+= 누적에서 나온다. 이 세 가지 함정만 의식해도 카카오 1~2번류에서 시간과 정확도를 같이 챙길 수 있다.

Settings는 신뢰 범위(trust boundary)다: fail-fast

yolang — Mon, 4 May 2026 21:16:27 +0900

FastAPI를 이용해 ML serving을 실습하면서 pydantic를 이용한 fail-fast 설계에 대해 공부했다.

핵심은 Settings를 trust boundart로 만들어 외부 입력을 부팅 시점에 한 번에 검증하고 그 후로는 코드 어디서나 신뢰하는 것이다.

이 글은 그 원리와 pydantic_settings의 세 가지 도구가 어떻게 이 원리를 구현하는지 정리한다.

앱은 환경마다 다르게 동작해야 한다.

- 개발 환경: localhost:5432 DB

- 스테이징: staging-db.internal:5432

- 프로덕션: prod-db.internal:5432

이것을 하드코딩하지 않고 외부에서 주입받기 위한 가장 흔한 방법은 환경변수다.

하지만 만약 config 검증이 입력 시점에 이뤄지지 않고 사용 시점에 일어나면 생기는 일을 보자.

가장 원시적인 방법 - os.getenv

이것을 사용하면 가장 큰 문제는 환경변수가 무조건 문자열이라는 점이다. 따라서 설정이 늘어날수록 전부 타입 변환을 해줘야 한다.

import os

DB_HOST = os.getenv("DB_HOST", "localhost")
DB_PORT = os.getenv("DB_PORT", "5432")
MAX_BATCH_SIZE = os.getenv("MAX_BATCH_SIZE", "8")
  
if MAX_BATCH_SIZE > 10:  # ← 항상 False! "8" > 10 비교 (str vs int)
      ...
      
      
MAX_BATCH_SIZE = int(os.getenv("MAX_BATCH_SIZE", "8"))
FP16 = os.getenv("FP16", "true").lower() == "true"  # bool 변환 직접

그리고 만약 변수를 잘못 입력했을 경우 부팅 시점에 잡히지 않고 진행되었을 때 문제가 발생할 수 있다.

예를 들어 위처럼 MAX_BATCH_SIZE가 타입변환이 되지 않았을 때 문자열과 숫자를 비교하면서 검증이 제대로 이뤄지지 않는 문제가 생긴다.

이것을 해결하는 원칙은 Trust Boundary이다.

Trust Boundary(신뢰 범위)를 정확하게 설정하여

외부 입력은 한 곳에서 받고, 한 곳에서 검증한다.
통과한 객체는 코드 어디에서나 신뢰한다.
부팅 시점에 모든 검증을 완료한다. ➡️ fail-fast

이를 구현하기 위한 pydantic_settings의 세 가지 도구가 있다.

1. BaseSettings

2. env_prefix

3. @model_validator

1. BaseSettings

BaseSettings는 trust boundary 자체를 만든다.

pydantic_settings의 BaseSettings는 BaseModel을 상속하는데 이것은 결국 BaseModel의 검증 능력을 그대로 쓸 수 있다는 뜻이다.

Field(ge=1, le=100) — 숫자 범위
Literal["cuda", "cpu"] — 허용 값 제한
@field_validator, @model_validator — 커스텀 검증
SecretStr — 비밀번호 로그 노출 방지

즉 BaseSettings는 검증 엔진(BaseModel) + 환경 변수 loader 다.

이를 통해 풀려고 하는 문제는 "앱의 설정값을 어디서, 어떻게 읽을 것인가"였다.

from pydantic_settings import BaseSettings, SettingsConfigDict

class Settings(BaseSettings):
	db_host: str = "localhost"
	db_port: int = 5432              # ← 자동으로 int 변환
	max_batch_size: int = 8          # ← 자동 변환 + 잘못된 값이면 부팅 시 폭발
	fp16: bool = True                # ← "true"/"1"/"yes" 알아서 처리

settings = Settings()  # ← 이 한 줄에서 모든 검증 끝

BaseSettings를 사용하면 아래와 같은 3가지 이점이 있다.

1. 타입 자동 변환: "5432" → 5432, "true" → True

2. 부팅 시점 검증 (fail-fast): 잘못된 값이면 Settings() 호출에서 즉시 Fail

3. 타입 안전: 이후 코드에서 settings.db_port는 항상 int라고 신뢰 가능

이와 같은 설계를 통해 외부 주입 데이터에 대한 방어선을 구축할 수 있다.

2. env_prefix

env_prefix는 모든 env 환경변수에 같은 prefix를 적용한다.

이를 사용하는 이유는 환경변수 네임스페이스를 분리하기 위해서다.

많은 충돌 문제는 네임스페이스로 푼다.

- 파이썬 모듈: import os vs import myapp.os

- 자바 패키지: com.company.utils vs org.apache.utils

- CSS BEM:. button vs. modal__button

- DB 스키마: public.users vs analytics.users

환경변수도 이의 연장선이라고 보면 된다.

env_prefix로 분리하게 되면 결론적으로는 해당 앱에 대한 설정을 다른 설정과 독립시킬 수 있다.

1. 시스템 충돌 방지: 시스템 PATH와 SERVING_PATH 분리

2. 앱 격리: 다른 앱은 OTHERAPP_PORT을 쓰니까 충돌 없음

3. 출처 추적: env | grep SERVING_ 한 줄이면 타깃 앱 설정만 분리

# config.py
  class Settings(BaseSettings):
      model_config = SettingsConfigDict(env_prefix="SERVING_")
      model_path: Path = Path("/models/model.pt")

3. @model_validator

이름 그대로 model와 관련된 모든 데이터를 검증할 수 있는 데코레이터이다.

여기서 model은 필드들을 담고 있는 객체 전체의 상태와 구조를 뜻한다.

이 @model_validator를 쓰는 이유는 타입시스템으로는 표현하지 못하는 비즈니스 규칙을 코드로 강제하기 위함이다.

@model_validator는 "이 list와 저 dict 사이엔 이런 관계가 있어야 한다"를 표현한다.

Validators

Most of the time, the input data will be a dictionary (e.g. when calling UserModel(username='...')). However, this is not always the case. For instance, if the from_attributes configuration value is set, you might receive an arbitrary class instance for th

pydantic.dev

before, after의 기능이 다른데

@model_validator(mode='before') 일 경우

각 데이터가 있는지, 키 이름을 변환하거나 한 필드를 여러 필드로 분리할 때 여기서 처리한다.

@model_validator(mode='after') 일 경우

이미 필드들은 검증이 끝났다고 가정하고 필드들 간의 관계를 검증할 때 사용한다.

아래 예시를 보면 password와 password_repeat이 일치하는지 검사한다.

from pydantic import BaseModel, model_validator

class Settings(BaseSettings):
    target_classes: list[str] = ["class_a", "class_b"]
    confidence_thresholds: dict[str, float] = {"class_a": 0.5, "class_b": 0.5}

    @model_validator(mode="after")
    def validate_thresholds_match_classes(self) -> 'Settings':
        missing = set(self.target_classes) - set(self.confidence_thresholds.keys())
        if missing:
            raise ValueError(f"thresholds에 누락된 클래스: {missing}")
        return self

이 3가지가 다 모여서 하는 일은 fail-fast 즉,

"앱이 잘못된 설정으로 부팅되는 것을 막는다"

[프로그래머스] 2025 카카오 하반기 2차 - 선인장 숨기기 (java)

yolang — Sat, 25 Apr 2026 10:07:00 +0900

프로그래머스

SW개발자를 위한 평가, 교육의 Total Solution을 제공하는 개발자 성장을 위한 베이스캠프

programmers.co.kr

2025 카카오 하반기 2차 - 선인장 숨기기

주제: 2차원 슬라이딩 윈도우

문제: 선인장 구역이 가능한 늦게 비를 맞도록 하기

변수:
- 세로 m, 가로 n
- 선인장 구역 세로 h, 가로 w
- 빗방울이 떨어지는 순서대로 좌표를 담은 2차원 정수 배열 drops

동일 조건 처리:
- 가장 왼쪽 위칸의 좌표

시간복잡도:
- 완전탐색시 (m-h+1)*(n-w+1)*h*w

- 최악의 경우(h=m/2, w=n/2): 연산량 약 156억 번 -> 1초(1억 번) 기준

- 슬라이딩 윈도우 최적화 시: O(m * n) -> 50만 번으로 0.01초 내 해결

<슬라이딩 윈도우 구현>

[단조 큐(Monotonic Deque) 구현 규칙]

- 유의점: 덱에는 실제 값이 아닌 '인덱스'를 저장하며, 초기 배열은 MAX_VALUE로 세팅(비 안 온 칸 방어)

반복문:
1. 쓸모없는 값 제거 (Tail): 덱의 뒤(tail)에서부터, 새로운 값보다 '크거나 같은(>=)' 값을 모두 제거

➡️ 정렬을 유지하며, 현재 값보다 늦게 떨어질 빗방울은 최소값 후보에서 영구 배제

2. 새로운 값 삽입 (Tail): 덱의 뒤에 현재 인덱스 삽입

3. 만료된 값 제거 (Head): 현재 윈도우 범위를 벗어난 인덱스를 덱의 앞(head)에서 제거

4. 결과 저장: 윈도우 크기가 채워진 시점부터 덱의 맨 앞(head) 인덱스의 값을 해당 구간 최소값으로 기록

각 열에 대해 적용 후, 그 2차원 배열을 갖고 행에도 적용

[최적화 방법]

- 처음에는 슬라이딩 윈도우를 다 돈 후에 답을 찾았는데

- 행 별 슬라이딩 윈도우를 돌면서 답을 바로 업데이트 하는 방법이 있었다.

class Solution {
    public int[] solution(int m, int n, int h, int w, int[][] drops) {
        int[] answer = new int[2];
        int[][] T = new int[m][n];
        int[][] R = new int[m][n];
        int[][] C = new int[m][n];
        
        for(int r=0; r<m; r++){
            for(int c=0; c<n; c++){
                T[r][c] = Integer.MAX_VALUE;
            }
        }
        
        for(int i=0; i<drops.length; i++){
            int r = drops[i][0];
            int c = drops[i][1];
            
            T[r][c] = i+1;
        }
        
        
        for(int r=0; r<m; r++){
            int[] deque = new int[n];
            
            int head = 0;
            int tail = 0;
            for (int c = 0; c < n; c++) {
                while(head < tail && T[r][deque[tail-1]] >= T[r][c]){
                    tail--;
                }
                
                deque[tail++] = c;
                
                if(deque[head] <= c - w){
                    head++;
                }
                
                if (c >= w - 1) {
                    R[r][c - w + 1] = T[r][deque[head]];
                }
            }
        }
        
        int maxVal = -1;
        int ansR = 0, ansC = 0;
        
        for(int c = 0; c < n; c++){
            int[] deque = new int[m];
            
            int head = 0;
            int tail = 0;
            for (int r=0; r<m; r++) {
                while(head < tail && R[deque[tail-1]][c] >= R[r][c]){
                    tail--;
                }
                
                deque[tail++] = r;
                
                if(deque[head] <= r - h){
                    head++;
                }
                
                // 윈도우가 완성된 즉시 최댓값 갱신 (메모리에 배열 C를 쌓지 않음)
                if (r >= h - 1) {
                    int currentMin = R[deque[head]][c];
                    int currentR = r - h + 1;
                    int currentC = c;
                    
                    if (currentMin > maxVal) {
                        maxVal = currentMin;
                        ansR = currentR;
                        ansC = currentC;
                    } else if (currentMin == maxVal) {
                        // Tie-breaking: 행이 작거나, 행이 같으면 열이 작은 것
                        // 세로로 돌기 때문에 필요한 분기
                        if (currentR < ansR || (currentR == ansR && currentC < ansC)) {
                            ansR = currentR;
                            ansC = currentC;
                        }
                    }
                }
            }
        }
        
        
        return new int[]{ansR, ansC};
    }
}

AI 생산성 올리는 방법 - AI는 칭찬을 좋아한다는 걸 안다.

yolang — Thu, 19 Feb 2026 08:45:40 +0900

AI 시대에 이미 알고 있었던 내용 말고 흥미로운 사실이 있어서 적어보려고 한다.

AI 프롬프트를 제작할때

1. Few-shot Prompting (예시 제공)

원하는 결과물의 '좋은 예시'와 '나쁜 예시'를 함께 줘서 AI가 모방하도록 하라.

2. Chain of Thought (생각의 사슬)

"답변하기 전에 단계별로 생각 과정을 설명해줘"라고 지시하여 AI가 소리 내어 사고하도록 하라. (단순히 답만 내는 것보다 추론 능력이 향상됨)
기본적으로 요즘 AI는 사고 과정을 보여줘서 Chain of Thought를 쓴다고 생각했는데, Deep Research 같은 연구 말고는 명시하지 않는 이상 잘 이용하지 않는다고 한다.
쓴다 해도 명시적인 CoT보다는 Hidden CoT 여서 사용자에게 보이지 않는다.
영상에서는 명시적으로 보이게 해서 사용자가 어디가 잘못되었는지 코칭 하는 방향을 제시한다.
이거는 결국 LLM이 이전 단어들을 갖고 다음 단어를 예측하는 기계여서 전체 과정을 사고하게 하면 성능이 좋아지는 원리였다.

이 2가지는 알고 있었다.

3. Reverse Prompting (역방향 프롬프팅)

"작업을 시작하기 전에, 더 필요한 정보가 있다면 나에게 질문해줘"라고 지시하라.
AI가 멋대로 정보를 지어내지(Hallucination) 않고, 완벽한 결과를 위해 필요한 데이터를 사용자에게 되묻게 만드는 핵심 기술입니다. (영상에서는 이를 'Table Stakes', 즉 기본 요건이라고 표현합니다.)

4. 페르소나 부여

예: "너는 냉전 시대 러시아 올림픽 심판이야. 아주 엄격하게 점수를 깎아줘"라고 구체적인 태도와 역할을 지정하라.

이 2가지 새로웠는데, 어떤 일을 새롭게 시작하는 사람에게 알려주듯 AI에게 알려주면 더 일을 잘한다는 전체적인 내용있었다.

새로운 일을 시작하는 사람에게

1. 일에 대한 소개

2. 일에 대한 좋고 나쁜 예시

3. "언제든 질문을 해 달라"

이런식으로 소개하지 않는가. 그거를 그대로 AI에게도 적용하면 되는 것이었다.

AI는 사람이 칭찬받는 걸 좋아하는 걸 안다.

따라서 페르소나 부여에서 오히려 가혹한 페르소나를 부여하면 칭찬만 하던 AI가 돌변했다..ㅋㅋㅋ

요즘 인지의 외주화(Cognitive offloading) 에 대해서도 걱정했었는데

영상에서는 AI가 결국 사용자의 거울이라며, 내가 일을 대신해 주길 바라면 그거를 도와줄거고

만약 내가 비판적이고 날카로운 사고를 하고 싶으면 그거를 도와줄거라고 했다.

따라서 사용하기 나름이라는 것이다. 그리고 사용하고 싶은 방향을 AI에게 충분히 설명하는 것이 중요했다.

Java Arrays 유틸리티 클래스 정리

yolang — Tue, 11 Nov 2025 15:00:06 +0900

import java.util.Arrays;

모든 메서드가 static으로 인스턴스 생성이 불필요하다.

Arrays는 배열을 위한 필수 유틸리티 클래스이다.

Arrays를 사용하면 아주 편리한 배열 관련 기능을 쓸 수 있다

정렬

Arrays.sort(arr);

출력용

Arrays.toString(arr);
Arrays.deepToString(arr2);


int[] arr = {1, 2, 3};
System.out.println(arr);                    // [I@15db9742 (주소)
System.out.println(Arrays.toString(arr));   // [1, 2, 3] ✅

int[][] arr2 = new int[][]{{1, 2, 3}, {4, 5, 6}};
System.out.println(Arrays.deepToString(arr2)); // [[1, 2, 3], [4, 5, 6]]

배열 비교

int[] arr1 = {1, 2, 3};
int[] arr2 = {1, 2, 3};

arr1 == arr2;                    // false (참조 비교)
Arrays.equals(arr1, arr2);       // true (내용 비교) ✅


Arrays.deepEquals(arr1, arr2);  // 다차원

변환

Arrays.asList(arr);             // 배열 → 리스트
Arrays.stream(arr);             // 배열 → 스트림

복사

Arrays.copyOf(arr, length);
Arrays.copyOfRange(arr, from, to);

int[] arr = {1, 2, 3, 4, 5};
int[] copy = Arrays.copyOf(arr, 3);        // [1, 2, 3]
int[] range = Arrays.copyOfRange(arr, 1, 4);  // [2, 3, 4]

값 채우기

(원래 있던 값까지 전부 대체)

int[] arr = new int[5];
Arrays.fill(arr, 10);
// [10, 10, 10, 10, 10]

Arrays.fill(arr, 1, 3, 99);  // 인덱스 1~2만
// [10, 99, 99, 10, 10]

이진 탐색(정렬되어 있어야 함)

Arrays.binarySearch(arr, key);

Java ArrayList, 배열 서로 변환하기

yolang — Tue, 11 Nov 2025 13:57:37 +0900

Java에는 여러가지 배열이 있다.

코딩테스트에서 자주 쓰는거는 그냥 배열([]), ArrayList 정도 될거 같다.

그 2개의 가장 큰 차이점은 고정 크기이냐 가변 크기이냐의 차이다.

그냥 배열은 고정 크기로 크기를 바꿀 수 없다.

ArrayList는 동적 할당을 하여 크기를 바꿀 수 있다.

배열은 어떻게 선언/할당할까

여기 보다시피

크기만 정해서 빈배열을 만들거나

정식 방법과 약식 문법이 있다.

약식 문법은 선언할때만 가능하여 할당 할때는 사용할 수 없다.

ArrayList는 어떻게 선언/할당할까

List.of와 Arrays.asList를 사용해서 리스트를 할당할 수 있는데

List.of는 null 값을 처리하지 못한 다는 것을 기억하자.

만약 ArrayList를 배열로 바꾸고 싶으면

이렇게 2가지 방법이 있다. 인자로 넘겨주는거는 타입 정보이다.

타입을 알려줄테니 크기는 알아서 맞게 할당해서 반환하라는 거다.

Sticky Session vs Stateless 아키텍처(Redis, JWT)

yolang — Tue, 11 Nov 2025 12:47:40 +0900

Stateless 아키텍처가 무엇인지 궁금했었다.

Load Balancer를 공부하며 Sticky Session에 대해 알게 되었고,

요즘에는 Sticky Session 대신 어떤 것을 더 선호하는지 알아보자.

Stick Session(Session Affinity)

출처: 네이버

Affinity는 친밀감을 뜻한다.

Session Affinity는 말 그대로 세션을 특정 서버에 붙여두는 것을 뜻한다.
서버가 세션 데이터를 로컬 메모리에 저장하기 때문에
같은 사용자의 요청을 같은 서버로 보내야
저장된 세션에 접근이 가능하다.

보통 이것을 쿠키로 구현하는데

Duration-based cookie(기간 기반)
Application-based cookie(애플리케이션 기반)

항목	Duration-based	Application-based
쿠키 생성	ALB	애플리케이션
쿠키 이름	AWSALB (고정)	커스텀 (예: SESSIONID)
만료 시점	시간 기반	애플리케이션 로직
로그아웃 처리	불가능	가능
구현 난이도	쉬움	보통
유연성	낮음	높음

(AWS SAA 강의에 나오길래 정리해봤다.)

하지만 요즘은 마이크로 서비스 아키텍처를 구성하며 Sticky Session을 쓰지 않는 방향으로 바뀌고 있다.

Sticky Session을 사용했던 이유는 특정 서버의 메모리에 세션이 저장되어 있어

사용자의 요청이 무조건 "그" 서버로 가야 했었다. 즉 서버를 늘리더라도 기존 사용자는 새로운 서버를 쓰지 못한다.

하지만 어떤 서버가 죽어도 다른 서버는 작동되는 것을 목적으로 하는 마이크로 서비스 아키텍처에서

Sticky Session처럼 서버의 메모리에 세션이 저장되어 있으면

특정 서버가 죽으면 그 서버의 세션 정보가 사라져 해당 서버 사용자들이 로그아웃 됨
다른 서버들은 정상 작동하지만, 세션 정보가 없어 해당 사용자 처리 불가능

즉, 수평 확장이 어렵고, 서버 간 부하 불균형이 발생할 수 있다. (고가용성을 달성하기 어렵다.)

따라서 Redis/DynamoDB 사용하여 중앙에서 관리하도록 하거나,

JWT를 사용하여 Stateless 하도록 하는 것이다.

Redis/DynamoDB

(DynamoDB는 AWS의 noSQL 서비스다.)

Redis나 DynamoDB를 사용하면 여기에 세션을 저장해 둔다.

사용자 로그인 → 서버 1 → Redis에 세션 저장

다음 요청 → 서버 2로 가도 OK → Redis에서 세션 읽어옴

또 다음 요청 → 서버 3으로 가도 OK → Redis에서 세션 읽어옴

이런 식으로 Redis에서 중앙관리를 하기 때문에 어떤 서버로 가도 상관없게 만들 수 있다.

JWT

Jwt 토큰을 사용하면 완전 stateless로 구현이 가능하다. 이거는 아예 서버에 세션 저장을 안 하는 방법이다.

사용자 로그인 → 서버가 JWT 토큰 발급 (서버에 저장 안 함)

다음 요청 → 서버 2 → JWT 검증만 함

또 다음 요청 → 서버 3 → JWT 검증만 함

마치 신분증을 들고 다니면서 서버에서는 검증만 하는 구조이다.

하지만 전부 장점만 있는 건 아니다.

Redis 세션 관리 시 단점

만약 redis가 다운되면 전체 서비스 세션이 불가해진다.
redis를 조회하는 오버헤드가 발생한다.
redis를 운영하는 인프라 비용이 발생한다.
데이터 일관성 문제가 발생할 수 있다.
- 서버 1에서 세션을 업데이트하는 동시에 서버 2가 읽으면 문제가 발생할 수 있다. (Race condition)

JWT의 단점

즉시 무효화가 불가능하다. (토큰 탈취가 가능할 수 있다.)
상태 변경이 반영되지 않는다. (토큰 만료까지 기다려야 함.)

이것을 어느 정도 보완하는 하이브리드 방식을 이전 프로젝트 때 사용했다.(현업에서도 가장 많이 쓰이는 거 같다.)

JWT + Redis 블랙리스트

여기서 JWT는 access token과 refresh token을 함께 사용한다.

핵심은

Access Token 재발급 시에만 Redis를 확인한다.
로그아웃 하면 Refresh Token을 Redis에 블랙리스트에 등록한다.

따라서 Access Token이 유효할 때는 JWT의 강점인 stateless 한 상태를 유지할 수 있다.

redis를 거칠 필요 없이 바로 검증만 진행하는 것이다.

하지만 Access Token이 만료되었을 때 Refresh Token이 유효한지 Redis로 확인한 후 발급한다.

Pure JWT의 문제점

로그아웃해도 토큰이 만료될 때까지 유효하다.

Access Token(15분)은 그렇다 치고,

Refresh Token(7일)까지 계속 작동한다.

→ 로그아웃이 의미가 없다

Redis 블랙리스트로 개선

Refresh Token을 블랙리스트에 등록하여

더 이상 새 Access Token을 발급받을 수 없게 한다.

→ Access Token 만료(15분) 후 완전 차단

→ "즉시 무효화"는 아니지만 "짧은 시간 내 무효화" 달성

이렇게 요즘은 무상태 인증을 통해 서버를 수평확장하는 것이 더 유리한 상황이다.

Sticky Session을 사용하면 구현이 간단하고 추가 인프라가 불필요하지만 확장성이 떨어진다는 점을 알고

각 Redis를 이용한 세션, JWT만 쓴 방법, 그리고 JWT+ Redis를 쓰는 방식의 장단점을 알고 있으면 좋을 거 같다.

TLS, Let's encrypt 와 cert-manager

yolang — Mon, 10 Nov 2025 17:44:12 +0900

저번 프로젝트를 진행할때 cert-manager와 Let's encrypt를 썼었다.

HTTPS를 위해 꼭 필요한 SSL/TLS에 대해 일단 알아보자.

SSL/TLS

우선 SSL(Secure Sockets Layer)를 업그레이드 한것이 TLS(Transport Layer Security)이다. (무려 1999년에)
모두 client와 서버간 암호화를 위해 만들어진 통신 프로토콜이다.
HTTPS의 S도 이 TLS를 이용해 Secure 한다는 뜻이다.
SSL은 현재 쓰이지 않고 TLS를 쓰지만 관용적으로 그냥 TLS 대신 SSL라고 부르기도 한다.
(현실에서 SSL를 거의 TLS 의미로 계속 쓰고 있는 듯 하다)

TLS Handshake, 인증서

TLS 암호화 통신을 하려면

↓

TLS Handshake 필요하고

↓

TLS Handshake에서 서버 인증 필요한데

↓

그래서 인증서 필요하다

TLS Handshake는 다음과 같이 이루어진다.

1. 클라이언트 Hello - (실제로 hello 이렇게 보낸다. ㅋㅋㅋ)

이때 TLS 버전, 무작위 바이트 문자열(랜덤값), 그리고 클라이언트가 지원하는 암호화 스위트 목록을 보낸다.

2. 서버 hello

이때 바로 인증서와 서버가 선택한 암호화 스위트, 서버가 생성한 무작위 바이트 문자열(랜덤값)을 보낸다.

3. 키 교환

클라이언트는 서버의 인증서를 검토해 신뢰하는 CA(certificate authority)인지, 도메인의 소유자가 맞는지 확인한다.
확인 후 클라이언트, 서버 각자 랜덤값과 교환된 키 값을 이용해 세션 키를 생성한다.

4. 클라이언트에서 'Cipher Spec'를 전송하고 이후로는 암호화 하여 통신된다.

(제가 한번 캡처해 봤습니다.)

인증서 발급 수단

자 그러면 이제 인증서를 발급 받는 수단에 대해서 정리해보자.

우선 개인이 가장 쓰기 만만한 것이 Let's encrypt이다.

특징으로는

무료다.
유효기한이 90일이다.
Domain Validation만 지원한다. (즉, 도메인을 소유하고 있는지만 체크하고, 실제 기업인지 이런것들은 확인하지 않는다)

우선 본인 도메인을 사서 서버에서 직접 발급을 받아야 하는데 단점이 아까 특징에서 보이다시피 유효기간이 90일이라 계속 갱신해줘야한다.

그래서 사용하는 것이 certbot 또는 쿠버네티스 환경에서는 cert-manager이다.

이전 프로젝트에서 실수했던 점이 쿠버네티스 환경인데 certbot을 사용해 인증서를 발급받고 secret으로 등록해서 90일 후에 재갱신해야하는 비효율적인 설계를 했었다. (완전 바보)

일반 서버 환경에서는 certbot을 사용해 자동 재갱신을 하도록 할 수 있고,

쿠버네티스에서는 cert-manager를 통해 알아서 관리하도록 할 수 있다.

따라서 정리하면 Let's encrypt는 인증서를 발급하는 기관이라고 보면 되고,

cert-manager는

인증서의 기한이 만료되지 않도록 관리하고

인증서를 새로 발급 받고

kubenetes secret에 등록하며

여러가지 일을 하는 전담 직원이라고 보면 좋을거 같다.

참고 자료:

https://docs.tosspayments.com/resources/glossary/tls

https://aws.amazon.com/ko/compare/the-difference-between-ssl-and-tls/

프로그래머스: 지게차와 크레인

yolang — Mon, 10 Nov 2025 16:08:58 +0900

프로그래머스

SW개발자를 위한 평가, 교육의 Total Solution을 제공하는 개발자 성장을 위한 베이스캠프

programmers.co.kr

구현 문제처럼 보이는 BFS 문제였다.

문제 요약

이 문제는 알파벳 블록을 특정 수단을 이용하여 제거하고 남은 컨테이너의 수를 구하는 문제이다.

입력으로는 전체 블록들의 배치와

각 회차별 수단과 제거 알파벳이 주어진다.

(["A", "BB", "A"])

알파벳이 한번만 나오면 지게차를 사용하고 (예시: A)

두번 나오면 크레인을 사용한다. (예시: AA)

지게차를 사용할 경우 외부에서 접근 가능한 블록들만 제거가 가능하다.

단, 순차적으로 지게차를 이용해 제거하고 접근 가능한 블록을 연쇄적으로 제거하는 것이 아닌

각 회차별 딱 그 시점에서 제거 가능한 블록들만 제거 가능하다.

위와 같은 상황에서 오직 주황색 C만 제거가능하다.

해결 알고리즘

크레인을 사용할 경우
- 해당하는 알파벳 갯수를 세면서 그 자리를 0으로 채워넣는다
지게차를 사용할 경우
- 크레인을 사용했을때 0으로 처리된 부분들이 외부와 연결되는지 확인하는 BFS를 실행한다. - cleanUp
- 이후 외곽인지 체크 후 0으로 채워 넣으며 갯수를 센다.
  - 외곽인지 체크하는 방법은 위, 아래, 양 옆으로 이동했을 때 외부인지 확인하는 방법을 사용했다.

TroubleShooting

여기서 내가 했던 실수는 다음과 같다.

BFS 구현시 visited를 queue에서 poll 하자마자 검사하지 않았다는 점
- 이것이 상당한 성능 저하를 불러왔다. 나는 그 다음 이동할때 검사를 했는데 그렇게 되면 중복처리되는 경우가 발생한다.

다음과 같은 상황일때, poll 하자 마자 visited 검사를 하지 않으면 두번째 3에서도 주변 탐색을 진행하게 된다.

그럼 불필요한 for문을 돌게 되는것이다.

그리고 코드를 더 빠르게 하는 방법은

String 대신 char 쓰기
int[] 대신 boolean[] 쓰기

정도 있을거 같다.

char를 사용했을때, 모든 초기값은 0이라는 사실을 기억하자.

Throughput과 IOPS 차이

yolang — Fri, 7 Nov 2025 14:51:57 +0900

정의부터 살펴보자

IOPS는 Input/Output Operations Per Second를 의미한다.

초당 수행할 수 있는 입출력 작업 횟수를 나타낸 것이다.

반면에 Throughput은 한국말로 처리량이다.

초당 전송할 수 있는 데이터의 양을 나타낸다.

IOPS는 빈도를 나타내고 Througpht은 양을 나타낸다.

비유로 이해해보자.

만약 고속도로에 작은 차가 많이 있다면 높은 IOPS에 낮은 Throughtput를 의미하고

큰 트럭들이 적게 있다면 낮은 IOPS에 높은 Throughtput를 의미한다.

현실에서는 어떤 상황에서 각각이 중요할까?

만약 큰 파일을 읽어야 한다면 당연히 Throughput이 중요할 것이다.

반면에 데이터베이스 쿼리를 많이 해야한다면 IOPS가 중요하다.

수학적으로 본다면

Throughput = IOPS x Block Size로 표현할 수 있다.

클로드에게 실제 사례를 알려달라고 했다.

IOPS 중심 워크로드:

1. 데이터베이스 (OLTP)
특징:
     - 많은 작은 쿼리
     - 랜덤 읽기/쓰기
     - 4KB ~ 16KB 블록

   예: MySQL, PostgreSQL
   필요: 높은 IOPS ★★★★★

2. 이메일 서버
특징:
     - 많은 작은 메시지
     - 랜덤 접근

   필요: 높은 IOPS ★★★★★

3. 가상 머신 부팅 볼륨
  특징:
     - 많은 작은 파일 읽기
     - 랜덤 패턴

   필요: 높은 IOPS ★★★★☆

Throughput 중심 워크로드:

1. 비디오 스트리밍
   특징:
     - 큰 파일 순차 읽기
     - 연속된 데이터 전송

   필요: 높은 Throughput ★★★★★

2. 빅데이터 분석 (Hadoop, Spark)
   특징:
     - 대용량 파일 스캔
     - 순차 읽기/쓰기

   필요: 높은 Throughput ★★★★★

3. 로그 수집 - (의외로 대용량이구만)
   특징:
     - 연속 쓰기
     - 큰 데이터 블록

   필요: 높은 Throughput ★★★★☆

4. 백업/복원
   특징:
     - 대용량 전송
     - 순차 접근

   필요: 높은 Throughput ★★★★★