범데이의 개발노트

Windows Cursor 터미널 한글 깨짐, PowerShell 프로필로 해결하는 방법

범데이 — Sun, 21 Jun 2026 23:53:27 +0900

Cursor 터미널과 Git에서 한글이 깨지는 건 대부분 Windows 코드페이지(CP949) 때문이다. PowerShell 프로필에 UTF-8 자동 전환 스크립트를 넣으면 터미널·Git 커밋까지 대부분 같이 해결된다.

절차

1단계: PowerShell 프로필 만들기

경로 (Windows PowerShell 5.1):

C:\Users\<사용자명>\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1

PowerShell 7+(pwsh)라면:

C:\Users\<사용자명>\Documents\PowerShell\Microsoft.PowerShell_profile.ps1

파일이 없으면 새로 만들고, 아래 내용을 넣는다.

if ($Host.Name -eq 'ConsoleHost') {
    try {
        chcp 65001 | Out-Null
        [Console]::OutputEncoding = [System.Text.Encoding]::UTF8
        [Console]::InputEncoding = [System.Text.Encoding]::UTF8
        $OutputEncoding = [System.Text.Encoding]::UTF8
    } catch {}
}

확인 방법: $PROFILE로 경로 확인, Test-Path $PROFILE이 True면 정상 생성.

2단계: Cursor 재시작 후 확인

모든 터미널 종료 (Ctrl+Shift+P → Terminal: Kill All Terminals)
Cursor 재시작 → 새 터미널 열기
아래로 확인

chcp
Write-Output "한글 테스트"

확인 방법: Active code page: 65001이 나오고 "한글 테스트"가 깨지지 않으면 끝.

정리

한글 깨짐의 대부분 원인은 Git이 아니라 Windows 코드페이지(CP949)다.
PowerShell 프로필에 UTF-8 전환 스크립트를 넣으면 터미널·Git 커밋까지 대부분 같이 해결된다.
그래도 커밋 메시지가 깨지면, git commit -F + UTF-8 파일로 우회할 수 있다.

Windows 비밀번호를 잊었을 때 포맷 없이 복구하는 방법

범데이 — Thu, 18 Jun 2026 18:15:45 +0900

회사 보안 프로그램이 주기적으로 비밀번호 변경을 요구해, 해당 프로그램 내에서 멍때리고 새로운 패스워드를 입력했다가..

이후 로그인할때 기억하는 모든 패스워드를 쳐봐도 로그인이 되지 않았다..(ㅠㅠ)

Windows 로그인 비밀번호를 분실했을 때, 포맷 없이 기존 데이터를 유지한 채 CMD 우회법으로 비밀번호를 강제 변경하는 방법이

다. 핵심은 설치 USB 복구 환경에서 접근성 실행 파일(utilman.exe)을 cmd.exe로 교체해, 로그인 화면에서 시스템 권한 CMD를 실행하는 것이다.

배경

다음 상황에서 사용한다.

로그인 화면에서 비밀번호 입력이 막히고, Microsoft 계정 온라인 재설정도 보안 질문 분실 등으로 불가능한 경우
데이터 유실 없이 해결해야 해서 포맷이 선택지가 될 수 없는 경우

원리는 Windows 로그인 화면의 접근성 버튼(utilman.exe)이 로그인 전에도 실행된다는 점을 이용하는 것이다. 이 파일을 cmd.exe로 교체하면 인증 없이 시스템 권한 CMD가 실행된다. 복구 환경(WinPE)은 파일 시스템에 직접 접근할 수 있어 이 교체가 가능하다.

주의: 적용 범위는 로컬 계정에 한정된다. Microsoft 계정의 온라인 인증 방식에는 적용되지 않을 수 있다.

준비물

정상 작동하는 다른 PC 1대 (Windows 설치 USB 제작용)
8GB 이상 USB 메모리
Microsoft 공식 홈페이지에서 받은 Windows 설치 미디어

절차

1단계: 설치 USB로 부팅 후 CMD 진입

잠긴 PC에 설치 USB를 꽂고 부팅한다. 제조사별 부팅 메뉴 키(F12, F11, Del 등)로 USB를 선택한 뒤, 언어 설정 화면에서 Shift + F10을 눌러 CMD를 실행한다.

확인 방법: CMD 창이 뜨면 진입 성공.

2단계: Windows 설치 드라이브 확인

복구 환경 기본 드라이브는 X:\이므로, 실제 Windows가 설치된 드라이브를 찾아야 한다.

c:
dir
# Windows, Users 폴더가 있으면 올바른 드라이브
# 없으면 d:, e: 순으로 탐색

확인 방법: dir 결과에 Windows, Users 폴더가 보이면 해당 드라이브가 맞다.

3단계: utilman.exe 교체

move C:\Windows\System32\utilman.exe C:\Windows\System32\utilman.exe.bak
copy C:\Windows\System32\cmd.exe C:\Windows\System32\utilman.exe

확인 방법: 두 명령 모두 1개 파일이 이동/복사되었습니다 메시지가 나오면 성공. USB를 뽑고 재시작한다.

4단계: 로그인 화면에서 비밀번호 변경

로그인 화면 우측 하단의 접근성 버튼을 클릭하면 시스템 권한 CMD가 열린다.

# 계정 목록 확인
net user

# 비밀번호 변경 (계정명과 새 비밀번호를 입력)
net user [계정명] [새비밀번호]

확인 방법: 명령을 잘 완료했습니다. 메시지가 뜨면 완료. 새 비밀번호로 로그인한다.

5단계: 원상복구 (보안상 필수)

이제 로그인이 잘 될것이다.

로그인 후 반드시 원본 파일을 복원한다.

del C:\Windows\System32\utilman.exe
move C:\Windows\System32\utilman.exe.bak C:\Windows\System32\utilman.exe

확인 방법: dir C:\Windows\System32\utilman.exe로 원본 크기의 파일이 복원됐는지 확인한다. 복원하지 않으면 누구나 로그인 화면에서 시스템 권한 CMD에 접근할 수 있는 보안 구멍이 남는다.

정리

복구 환경 CMD는 로그인 없이 시스템 파일에 접근할 수 있다.
utilman.exe는 로그인 전 실행되므로, 이를 cmd.exe로 교체하면 시스템 권한 셸을 얻을 수 있다.
net user 명령으로 인증 없이 로컬 계정 비밀번호를 변경할 수 있다.
작업 후 반드시 원본 파일을 복원해 보안 구멍을 닫아야 한다.

참고

항목	설명
utilman.exe	Windows 접근성 관리자. 로그인 화면에서도 실행됨
WinPE	Windows Preinstallation Environment. 설치 USB 부팅 시 진입하는 경량 OS 환경
net user	Windows 로컬 사용자 계정을 관리하는 CMD 명령어
적용 범위	로컬 계정에만 적용 가능. Microsoft 계정 온라인 인증 방식에는 적용되지 않을 수 있음

운영 미배포 작업을 보류 브랜치로 분리해 관리하는 방법

범데이 — Thu, 18 Jun 2026 18:05:52 +0900

운영 배포 전 main에만 올린 작업을 취소해야 하는데, 이미 개발 환경 배포 브랜치에는 반영돼서 그쪽은 건드릴 수 없는 상황. 별도 보류 브랜치에 작업을 먼저 백업한 뒤, main에서는 git revert로 되돌리고, 운영 배포 시점에 보류 브랜치를 다시 합치는 방식으로 해결한다.

배경

배포 흐름이 아래처럼 분리된 환경을 가정한다.

feat/* → main → 개발 배포 브랜치 → 개발 환경 배포
feat/* → main → 운영 배포 브랜치 → 운영 환경 배포

작업을 main에 올리고 개발 배포 브랜치까지 merge해 개발 환경에는 이미 반영됐지만, 운영 배포 브랜치에는 아직 merge하지 않은 시점에 다음 배포 일정이 미뤄지는 경우가 있다. 이때 main은 다음 운영 배포 전까지 깨끗한 상태를 유지해야 하므로, 해당 작업만 main에서 제외하면서도 이미 배포된 개발 환경은 그대로 둬야 한다.

단순히 git reset --hard로 되돌리면 이미 push한 공유 브랜치의 히스토리가 삭제돼 위험하다. 대신 히스토리를 보존하면서 변경만 반대로 적용하는 git revert를 쓴다.

준비물

작업이 올라간 main 커밋 해시 (git log main --oneline으로 확인)
작업을 보관할 보류 브랜치 (예: feat/hold) — 없으면 새로 생성
로컬 저장소에 main, 개발 배포 브랜치, 보류 브랜치에 대한 push 권한

절차

1단계: 보류 브랜치에 작업 백업

운영 배포 전까지 작업을 보관할 브랜치로 이동해, main에 올렸던 작업 커밋을 cherry-pick으로 가져온다.

git checkout feat/hold
git cherry-pick <main에 올린 작업 커밋해시>
git push origin feat/hold

확인 방법: git log feat/hold --oneline에 해당 커밋이 보이면 백업 완료.

2단계: main에서만 작업 되돌리기

main을 최신 상태로 받은 뒤, 해당 커밋을 revert한다. 작업 커밋이 여러 개면 최신 커밋부터 하나씩 revert한다.

git checkout main
git pull origin main
git revert <작업 커밋해시> --no-edit
git push origin main

--no-edit은 revert 커밋 메시지를 편집기 없이 기본값으로 바로 쓰겠다는 옵션이다. 머지 커밋을 revert해야 하는 경우엔 부모 브랜치 기준을 지정해야 한다.

git revert -m 1 <머지커밋해시> --no-edit

-m 1은 merge 시 main 쪽(첫 번째 부모) 기준으로 되돌린다는 의미다.

확인 방법: git log main --oneline에 Revert "..." 커밋이 새로 생기고, 해당 변경분이 코드에서 사라졌는지 확인.

3단계: 개발 배포 브랜치는 그대로 둔다

개발 환경에는 이미 반영된 상태이므로 아무 작업도 하지 않는다. 운영 배포 전까지 main → 개발 배포 브랜치 merge 자체를 하지 않는 것이 중요하다. revert가 그쪽에 들어가면 개발 환경에서 해당 기능이 사라질 수 있다.

확인 방법: 개발 배포 브랜치의 최근 merge 로그에 main의 revert 커밋이 포함되지 않았는지 확인.

4단계: 운영 배포 시점에 다시 합치기

운영 배포 일정이 오면, 보류 브랜치를 main에 merge하고, 이어서 운영 배포 브랜치로 merge한다.

git checkout main
git merge feat/hold
git push origin main
# 이후 운영 배포 브랜치로 merge

확인 방법: main에 보류 브랜치의 커밋이 다시 들어왔는지, revert로 빠졌던 변경이 복원됐는지 코드 diff로 확인.

정리

운영 미배포 작업은 처음부터 보류 브랜치에서 진행하고, 배포 시점에만 main으로 merge하는 흐름을 기본으로 삼는다
git revert는 히스토리를 지우지 않고 변경만 반대로 적용하므로, 이미 push한 공유 브랜치에서는 reset --hard보다 항상 안전하다
revert 대상은 내 작업 커밋만이며, 단순히 원격 브랜치를 동기화한 merge 커밋은 되돌릴 필요 없다
브랜치 작업 외에, 프론트엔드 변경이 있었다면 push 전 최소한 빌드 검사(예: pnpm build — 타입 검사 + 프로덕션 빌드)로 컴파일 오류 여부를 확인하는 과정도 함께 거쳐야 한다

eGovFrame 채번 테이블 불일치로 메뉴 ID가 중복된 사례

범데이 — Tue, 16 Jun 2026 19:03:02 +0900

eGovFrame 기반 시스템에서 메뉴 등록 후 웹페이지가 멈추거나 Duplicate Key 오류가 발생했다. 최종 원인은 채번 테이블의 NEXT_ID가 실제 데이터 최댓값보다 작았고, 대상 테이블에 PK 제약이 없어 중복 삽입이 즉시 막히지 않았던 것이다.

증상

관리 화면에서 메뉴 등록·저장 시 오류가 발생하거나, 저장 후 메뉴 트리·특정 페이지가 로딩되지 않는다(먹통)
애플리케이션 로그에 Duplicate entry / Unique constraint violation 류 메시지가 남는다
DB에는 이미 동일 entityId(메뉴 ID) 를 가진 행이 2건 이상 존재할 수 있다
처음에는 애플리케이션 버그·캐시 문제를 의심했으나, 채번 값과 실데이터 불일치 쪽으로 좁혀졌다

어떻게 좁혔나

1) 오류 시점·경로 확인

프로그램 경로(관리 화면 INSERT)에서만 재현되는지, 조회만으로도 깨지는지 구분했다
운영 DB 수동 INSERT·UPDATE 이력이 있는지 확인했다

2) 채번 테이블 vs 실데이터 비교

검증	결과
채번 테이블 NEXT_ID (예: TABLE_NAME = 'MENU_ID')	예: 105
실제 메뉴 테이블 MAX(entityId)	예: 108
프로그램이 다음에 발급할 ID	105 → 이미 존재하는 ID와 충돌

3) 제약조건·중복 데이터 확인

-- PK/UNIQUE 없음 여부 (메타 조회 또는 스키마 확인)
-- 중복 entityId 존재 여부
SELECT entity_id, COUNT(*)
FROM menu_info
GROUP BY entity_id
HAVING COUNT(*) > 1;

PK가 없으면 INSERT 시점에 DB가 막지 못하고, 이후 조회·조인·트리 구성 단계에서 오류가 터질 수 있다

원인

eGovFrame 테이블 기반 채번 동작

EgovTableIdGnrServiceImpl 은 채번 전용 테이블에서 TABLE_NAME 별 NEXT_ID 를 읽고 +1 UPDATE 후 반환한다
blockSize=1 이면 호출마다 SELECT → UPDATE 를 수행한다

<bean name="entityIdGnrService"
    class="egovframework.rte.fdl.idgnr.impl.EgovTableIdGnrServiceImpl"
    destroy-method="destroy">
    <property name="dataSource" ref="dataSource" />
    <property name="strategy"   ref="menuStrategy" />
    <property name="blockSize"  value="1"/>
    <property name="table"      value="SEQ_TABLE"/>
    <property name="tableName"  value="MENU_ID"/>
</bean>

컬럼	역할
TABLE_NAME	채번 대상 식별자 (예: MENU_ID)
NEXT_ID	다음 발급할 ID

불일치가 생긴 경로

운영 중 DB에서 직접 메뉴 행을 INSERT·UPDATE 하면서 entityId 를 수동 지정했다
이때 채번 테이블의 NEXT_ID 는 갱신되지 않았다
실데이터 MAX(entityId) ≥ 채번 NEXT_ID 상태가 되었다
이후 프로그램이 메뉴 INSERT 시 이미 존재하는 ID 를 다시 발급받아 충돌했다

PK 미설정이 증상을 악화시킨 이유

대상 테이블 entityId 에 PK·UNIQUE 가 없으면 중복 INSERT 가 DB에서 즉시 거부되지 않는다
Duplicate Key 는 늦게 드러나거나, 조회 로직이 단건 가정일 때 페이지 전체가 멈춘 것처럼 보인다

해결

1) 채번 값 보정 — 실데이터 최댓값 + 1 로 맞춘다

UPDATE seq_table
SET next_id = (SELECT MAX(entity_id) + 1 FROM menu_info)
WHERE table_name = 'MENU_ID';

2) 중복 데이터 정리 — 위 중복 조회 쿼리로 걸린 행을 업무 규칙에 맞게 병합·삭제한다 (선행 필수)

3) PK 또는 UNIQUE 제약 추가 — 향후 수동·프로그램 경로 모두에서 중복 삽입을 원천 차단한다

4) 운영 DB 직접 수정 가이드 — 수동으로 ID 를 넣을 때는 반드시 채번 테이블 NEXT_ID 도 동기화하도록 Runbook 에 명시한다

정리

eGovFrame 테이블 채번은 SEQ_TABLE.NEXT_ID 만 믿으면 안 된다 — 실데이터 MAX(id) 와 주기적으로 대조한다.
운영 DB 수동 INSERT 후 채번 불일치가 가장 흔한 원인이다 — 수동 작업 시 채번 동기화를 절차에 넣는다.
ID 컬럼에 PK·UNIQUE 가 없으면 중복이 조용히 쌓이고, 조회·트리 화면에서 늦게 터진다.
메뉴·권한·코드처럼 전역 참조되는 ID 는 충돌 시 영향 범위가 넓다 — 등록 실패 로그와 MAX(id) vs NEXT_ID 를 함께 본다.

참고: 발생 오류 유형

레이어	증상
DB	Duplicate entry, Unique constraint violation (PK 설정 후에는 INSERT 시점에 즉시)
애플리케이션	중복 ID 로 인한 메뉴 조회 실패, Null/다건 처리 오류, 페이지 로딩 실패

싱글톤 Bean 공유 상태로 동시 Ajax 응답이 섞인 사례

범데이 — Tue, 16 Jun 2026 18:50:30 +0900

화면에서 API1은 1건, API2는 3건이 내려와야 하는데, Network 탭에서 둘 다 3건으로 보이는 현상이 간헐적으로 발생했다. SQL·파라미터·배포를 의심했지만, 최종 원인은 Spring 싱글톤 Bean이 공유 응답 객체를 동시 요청이 덮어쓴 것이었다.

증상

팝업(또는 특정 화면) 로드 시 Ajax 2개가 동시에 호출된다
API1 응답은 1건이어야 정상인데, Network에서 3건으로 보이는 경우가 있다
API2 응답도 3건이며, API1과 JSON 내용이 완전히 동일하다
드롭다운 등 UI에 같은 라벨·다른 코드값이 여러 건 노출되고, 잘못된 값이 저장될 수 있다
API1·SQL을 단독 호출하면 항상 1건 → DB·SQL·파라미터 문제는 아닌 것으로 보였다

어떻게 좁혔나

1) SQL·파라미터 소거

검증	결과
API1 SQL 직접 실행	항상 1건
curl 등으로 API1 단독 호출	항상 1건
서버 sql.log의 API1 실행 SQL	필터 조건 정상 포함
요청 파라미터 (예: parentId)	정상 전달

2) 결정적 로그

[시각]  POST .../api1.json   → SQL 필터 O, DB 1건
[시각]  POST .../api2.json   → SQL 필터 X, DB 3건  (수 ms 차이)

SQL은 각각 정상인데 API1 Response만 3건 → DB 이후 레이어를 의심했다.

3) 코드 추적

Service·Controller에 인스턴스 필드로 응답 객체를 하나만 두고, API1·API2가 거의 동시에 setResult 하는 구조였다.

원인

싱글톤 + 공유 가변 상태

@Service·@Controller는 기본 싱글톤 → 모든 HTTP 요청이 같은 Bean 인스턴스를 쓴다
요청마다 새 응답 객체를 만들지 않고, 필드 하나에 결과를 넣고 그 참조를 반환했다

@Service
public class SomeService {
    private ApiResponse response = new ApiResponse();  // 모든 요청이 공유

    public ApiResponse getListA(String parentId) {
        List<Item> list = dao.queryA(parentId);  // 예: 3건
        response.setResult(list);
        return response;
    }

    public ApiResponse getListB(String parentId) {
        List<Item> list = dao.queryB(parentId);  // 예: 1건 (필터 적용)
        response.setResult(list);  // 같은 객체를 덮어씀
        return response;
    }
}

경쟁 시나리오 (Race Condition)

Thread-A (API1)                  Thread-B (API2)
───────────────                  ───────────────
DB 조회 → 1건
                                 DB 조회 → 3건
response.setResult(1건)
                                 response.setResult(3건)  ← 덮어씀
return → 클라이언트에 3건      return → 3건

마지막에 setResult한 쪽이 양쪽 HTTP 응답 모두에 반영될 수 있다
API2가 나중이면 API1 Response에도 3건이 나간다 → 두 JSON이 완전히 동일해진다
스레드 스케줄링에 따라 1건/3건이 간헐적으로 바뀌어 보인다

왜 단독 호출은 항상 정상인가

curl·SQL 직접 실행 = 스레드 1개 → 경쟁 없음
화면 로드 = API1·API2 동시 Ajax → 재현 가능

해결

요청마다 새 응답 객체를 생성하도록 변경했다.

private ApiResponse successResult(Object data) {
    ApiResponse response = new ApiResponse();
    response.setResult(data);
    response.setResultCode("OK");
    return response;
}

public ApiResponse getListB(String parentId) {
    List<Item> list = dao.queryB(parentId);
    return successResult(list);
}

Controller의 공유 응답 필드도 제거하고, return service.method(...) 로 직접 반환하도록 수정했다.

정리

SQL 로그 정상 + API Response 비정상이면 DB가 아니라 응답 객체를 만드는 Java 레이어를 본다.
단독 호출 OK / 동시 호출 NG는 스레드 경쟁의 강한 힌트다.
싱글톤 Bean에 요청별 데이터를 인스턴스 필드로 두지 않는다 — 메서드 지역 변수로 생성 후 반환한다.
Ajax를 2개 이상 동시에 쏘는 화면은, 공유 상태 버그가 간헐적으로만 터져 찾기 어렵다 — Network에서 URL별 Response와 sql.log를 반드시 대조한다.

참고: API1 vs API2 (예시)

구분	역할	SQL	예상 건수
API1	드롭다운 목록	필터 적용 (예: 특정 타입만)	1건
API2	부가 정보·안내	필터 없음 (전체 트리)	3건 (예: 상위·중간·하위 코드)

두 API를 항상 동시 호출하는 구조에서, 수정 전에는 API1 응답에 API2 결과가 섞여 잘못된 option이 노출될 수 있었다.

외부망에서만 API가 Empty Response로 끊긴 사례 해결

범데이 — Tue, 16 Jun 2026 18:40:35 +0900

외부망에서만 API 임시저장이 응답 없이 끊겼다. 애플리케이션 로그는 없었고, 내부망에서는 같은 기능이 정상 동작했다.

증상

POST 직후 HTTP 상태·본문 없음 (약 40ms, 타임아웃 아님)
브라우저 Network Timing: Waiting(TTFB) 구간 없음 → 응답 첫 바이트조차 오기 전에 끊김 (아래 참고)
브라우저: ERR_EMPTY_RESPONSE / curl: (52) Empty reply from server
내부망에서는 동일 기능 정상, 외부망에서만 재현

처음에는 폼 null, 임시저장 불러오기, DB 오류를 의심했지만, curl로도 재현되고 body를 줄이면 400 JSON이 돌아와 앱·경로는 살아 있음이 확인됐다. API가 통째로 죽은 상황은 아니었다.

어떻게 좁혔나

1) body 크기로 층 나누기

body	결과
최소 필드만	400 JSON (앱 도달)
실제 신청 form 전체	Empty

2) 필드 하나씩 추가

대표자 변경만, 면적 변경만, 긴 주소만 → 모두 400.

루트에 직영/위탁 운영형태 필드만 넣으면 → Empty.

3) 결정적 테스트

운영형태 코드 값	결과
DIR	Empty
ABC / DI	400 JSON

→ DIR 문자열이 트리거. 필드 이름이나 한글 주소 길이가 아니다.

원인

DIR은 업무 코드다

직영/위탁 운영형태를 구분하는 공통코드
DIR = 직영(Direct) 등, 업무상 정상 코드값 (윈도우 DIR 명령과 무관)
업체 마스터·신청 form에 이미 들어 있어 POST body에 "DIR" 코드값이 포함되어 실림

WAF(웹 방화벽)가 끊는 이유

body를 실행하지 않고 문자열만 검사
"DIR" → directory / path traversal 류 시그니처 오탐
차단 시 403이 아니라 연결만 종료 → Empty Response

내부 OK / 외부 NG

내부망은 WAF를 타지 않거나 정책이 느슨하고, 외부망 인터넷 구간 WAF에서만 막힌다.

해결

공통코드 값 변경. 직영/위탁 운영형태 공통코드에서 DIR 코드값을 WAF에 걸리지 않는 값으로 변경했다. 화면에 보이는 직영/위탁 구분(cdNm 등)은 그대로 두고, POST body에 "DIR" 문자열이 실리지 않게 한 것이 최종 조치다.

(WAF 예외·POST 필드 제거 등도 대안이 될 수 있으나, 이번에는 공통코드 변경으로 해결.)

정리

Empty Response는 앞단 차단 신호 — TTFB* 없이 수십 ms면 WAF·프록시를 먼저 본다.
내부 OK / 외부 NG는 WAF 경로 차이의 강한 힌트.
curl 최소 body vs 전체 body로 문제 필드를 이분할 수 있다.
업무상 정상인 짧은 코드(DIR, NAT …)도 보안 시그니처와 충돌할 수 있다 — 공통코드 설계·WAF 예외·전송 필드 최소화를 함께 검토한다.

* TTFB(Time To First Byte) = 요청을 보낸 뒤 HTTP 응답의 첫 바이트가 도착하기까지 걸린 시간 (Chrome 개발자 도구 Network → Timing의 Waiting 구간과 같다.)

[요청 전송] → [서버·WAF 처리] → [첫 바이트] → [본문 전체]
                              ↑ TTFB

Timing	의미
Waiting(TTFB) 있음	200·400 등 HTTP 응답이 시작됨 (앱·프록시까지 도달)
Waiting(TTFB) 없음	응답 시작 전 연결 종료 → Empty Response, ERR_EMPTY_RESPONSE

이번처럼 TTFB 없이 ~40ms에 끊기면, DB 느림·30초 타임아웃보다 앞단(WAF 등)에서 body 검사 후 차단을 먼저 의심한다.

[Troubleshooting] Maven "was cached in the local repository" — 폐쇄망 빌드 서버에서 캐시된 실패 처리

범데이 — Wed, 3 Jun 2026 10:27:02 +0900

parent POM을 Nexus에 올렸는데도 빌드가 또 실패했다. 원인은 Maven이 이전에 실패한 해석 결과를 로컬 캐시에 저장해두고 계속 실패로 처리하고 있었기 때문이었다.

1. 증상

parent POM을 Nexus에 올리고 다시 빌드를 돌렸는데 또 같은 에러가 떴다.

[ERROR] Failed to execute goal on project my-project:
  Could not resolve dependencies ...
    Failure to find com.github.librepdf:openpdf-parent:pom:1.3.30.jaspersoft.2
    in http://nexus.internal:8081/repository/maven-public/
    was cached in the local repository,
    resolution will not be reattempted until the update interval
    of nexus has elapsed or updates are forced

openpdf-parent는 분명히 Nexus에 올라가 있는데 왜 여전히 실패하는지 이해가 되지 않았다.

2. 원인 — Maven의 네가티브 캐시

Maven은 한 번 원격 레포에서 아티팩트 다운로드에 실패하면, 실패 정보를 로컬 .m2에 캐시한다. 다음 실행 시에는 원격 레포를 다시 조회하지 않고 캐시된 실패를 그대로 사용한다.

이 네가티브 마크 파일이 .m2에 남아 있으면 was cached 메시지가 뜨면서 설정된 인터벌이 지나기 전까지 재시도하지 않는다.

C:\Users\<agent>\.m2\repository\com\github\librepdf\openpdf-parent\1.3.30.jaspersoft.2\
    openpdf-parent-1.3.30.jaspersoft.2.pom.lastUpdated  ← 이게 문제

.lastUpdated 파일에는 실패한 시간과 실패한 URL이 담겨 있다. Maven은 이것을 보고 "이미 실패한 거 알아. 인터벌 안 지났으니 다시 안 찾아."라고 판단한다.

즉, 빌드 에이전트가 Nexus 업로드 이전 시점에 이미 캐시를 만들어둔 것이 문제였다.

3. 해결 — -U 플래그로 강제 업데이트

Maven에 -U (--update-snapshots) 플래그를 추가하면, 캐시된 네가티브 마크를 무시하고 원격 레포를 직접 확인한다. TeamCity Maven Build Step의 Goals에 -U를 추가했다.

# 변경 전
clean package -DskipTests

# 변경 후
clean package -DskipTests -U

-U는 SNAPSHOT 업데이트와 실패한 해석 캐시 무효화 두 가지를 동시에 수행한다.

4. 주의사항

-U는 빌드마다 원격 레포를 업데이트 확인하므로 빌드 에이전트가 완전한 폐쇄망임을 전제로 한다. 원격 접근이 전혀 안 되는 환경이라면 아래 선택지를 사용할 수 있다.

선택지	방법
.lastUpdated 직접 삭제	Get-ChildItem -Recurse -Filter *.lastUpdated \| Remove-Item
.m2 전체 삭제	빌드 에이전트의 캐시를 완전히 초기화 후 재시도
업로드 선행 확인	빌드 시작 전 Nexus에 정상 업로드되었는지 스크립트로 확인

5. 마무리

이 문제는 폐쇄망 환경의 시간 순서 문제다.

빌드 에이전트가 빌드 시도 → 실패 → .lastUpdated 생성
해당 아티팩트를 Nexus에 업로드
다시 빌드 시도 → Maven이 .lastUpdated를 보고 캐시된 실패로 판단 → 또 실패

-U를 주면 Maven이 캐시를 무시하고 Nexus를 직접 조회하므로 이 순환 고리를 끊을 수 있다.

빌드 #4: clean package -DskipTests -U  → 성공

폐쇄망에서 Nexus에 파일을 올린 후에도 빌드가 실패한다면 .lastUpdated 캐시를 먼저 의심한다. -U 하나로 해결된다.

[Troubleshooting] Maven parent POM이 Nexus에 없어서 빌드 실패 — mvn dependency:list의 함정

범데이 — Wed, 3 Jun 2026 10:22:18 +0900

폐쇄망 Nexus에 의존성을 올렸는데도 빌드가 실패했다. 원인은 mvn dependency:list가 parent POM을 출력하지 않는다는 점이었다. 이 함정과 해결 방법을 정리한다.

1. 증상

로컬 .m2에서 의존성을 수집해 Nexus에 올리고 폐쇄망 TeamCity 빌드를 돌렸더니 아래 에러가 떴다.

Could not resolve dependencies for project ...
  Could not find artifact com.github.librepdf:openpdf-parent:pom:1.3.30.jaspersoft.2
    in nexus (http://nexus.internal:8081/repository/maven-public/)

openpdf는 분명히 올렸는데 왜 openpdf-parent가 없다고 할까.

2. 원인 — mvn dependency:list의 함정

Maven 빌드 시 각 아티팩트의 POM을 읽어서 <parent> 태그를 따라 부모 POM도 함께 다운로드한다. 그런데 mvn dependency:list는 실제 빌드에 사용되는 JAR만 출력하고, 모델 해석에 필요한 parent POM은 목록에 포함시키지 않는다.

예를 들어 openpdf JAR를 올렸더라도, Maven이 openpdf.pom을 읽어보면 아래와 같다.

<parent>
  <groupId>com.github.librepdf</groupId>
  <artifactId>openpdf-parent</artifactId>
  <version>1.3.30.jaspersoft.2</version>
</parent>

이 parent POM까지 Nexus에 있어야 빌드가 성공한다. 하지만 mvn dependency:list에는 openpdf-parent가 전혀 나타나지 않는다.

3. 해결 — POM의 parent 체인을 재귀적으로 탐색

수집 스크립트에 Step 4를 추가했다. 이미 수집된 모든 POM 파일을 파싱해서 <parent> 요소를 찾고, 해당 parent POM도 .m2에서 복사한다. 복사한 parent POM에서 또 parent를 찾는 식으로 BFS(너비 우선 탐색)로 체인 전체를 추적했다.

# POM에서 <parent> 정보 추출
function Get-PomParent($pomPath) {
    try {
        $doc = New-Object System.Xml.XmlDocument
        $doc.Load($pomPath)  # [xml] 캐스트 대신 XmlDocument.Load() 사용 (인코딩 안전)
        $node = $doc.DocumentElement.SelectSingleNode("*[local-name()='parent']")
        if (-not $node) { return $null }
        $g = $node.SelectSingleNode("*[local-name()='groupId']").InnerText.Trim()
        $a = $node.SelectSingleNode("*[local-name()='artifactId']").InnerText.Trim()
        $v = $node.SelectSingleNode("*[local-name()='version']").InnerText.Trim()
        if ($g -and $a -and $v) { return @($g, $a, $v) }
    } catch {}
    return $null
}

# BFS로 parent 체인 전체 수집
$seenParents = New-Object 'System.Collections.Generic.HashSet[string]'
$parentQueue = New-Object 'System.Collections.Generic.Queue[object]'

# 이미 수집된 POM에서 parent 목록 추출해서 큐에 넣기
$pomFiles = Get-ChildItem -Path $DEST_DIR -Recurse -Filter "*.pom"
foreach ($pf in $pomFiles) {
    $par = Get-PomParent $pf.FullName
    if ($par) {
        $key = "$($par[0]):$($par[1]):$($par[2])"
        if ($seenParents.Add($key)) {
            $parentQueue.Enqueue([PSCustomObject]@{ GroupId=$par[0]; ArtifactId=$par[1]; Version=$par[2] })
        }
    }
}

# BFS 실행
while ($parentQueue.Count -gt 0) {
    $p = $parentQueue.Dequeue()
    $srcPath = Find-M2Path -base "$M2_DIR\$groupPath\$($p.ArtifactId)" -version $p.Version
    if ($srcPath) {
        Copy-Item -Path "$srcPath\*" -Destination $dstDir -Recurse -Force
        Write-Host "[PARENT] $($p.GroupId):$($p.ArtifactId):$($p.Version)"
        # 복사한 POM의 parent도 큐에 추가
        $copiedPom = Get-ChildItem -Path $dstDir -Filter "*.pom" | Select-Object -First 1
        $par = Get-PomParent $copiedPom.FullName
        if ($par -and $seenParents.Add("$($par[0]):$($par[1]):$($par[2])")) {
            $parentQueue.Enqueue(...)
        }
    }
}

4. 삽질 포인트 — [xml] 캐스트 vs XmlDocument.Load()

처음에는 PowerShell의 [xml]$doc = Get-Content $pomPath로 파싱했는데 Parent POMs copied: 0이라는 결과가 계속 나왔다.

원인은 두 가지였다.

첫째, Get-Content는 파일 내용을 라인 단위 배열로 반환한다. [xml] 캐스트에 넣으면 첫 번째 라인만 파싱되거나 인코딩 문제로 파싱 자체가 실패할 수 있다.

둘째, POM 파일 인코딩이 UTF-8 BOM 없이 저장된 경우 Get-Content의 기본 인코딩(UTF-16 LE)과 충돌한다.

XmlDocument.Load()는 파일 경로를 직접 받아서 XML 선언의 인코딩(<?xml ... encoding="UTF-8"?>)을 자동으로 처리하므로 훨씬 안전하다.

# 위험 (인코딩 문제 가능)
[xml]$doc = Get-Content $pomPath

# 안전
$doc = New-Object System.Xml.XmlDocument
$doc.Load($pomPath)

5. 결과

상태	수
JAR 의존성 (COPY)	169
system scope (LOCAL)	3
Parent POM 수집	55

총 55개의 parent POM이 누락되어 있었다.

이걸 올리고 나서야 폐쇄망 빌드가 정상적으로 진행됐다.

mvn dependency:list만 믿으면 parent POM은 반드시 누락된다. JAR 수집 후 POM을 재귀적으로 파싱해서 parent 체인까지 챙겨야 한다.

[폐쇄망 CI/CD] Maven 의존성을 Nexus에 자동 업로드하기

범데이 — Wed, 3 Jun 2026 10:18:10 +0900

외부 인터넷이 차단된 폐쇄망 환경에서 Maven 프로젝트의 CI/CD를 구축하면서 겪은 의존성 관리 문제와 해결 과정을 정리한다.

1. 배경

회사 보안 규정상 외부 인터넷이 막힌 폐쇄망 서버에 Spring Boot 기반 사내 시스템을 배포해야 했다. TeamCity로 CI/CD 파이프라인을 구성했는데, 빌드 서버가 Maven Central에 접근할 수 없으니 의존성을 어디선가 가져와야 했다.

해결 방향은 세 단계로 정리됐다.

내부망에 Nexus Repository Manager 구축
개발자 PC의 로컬 .m2 캐시에서 필요한 의존성만 추려서 Nexus에 업로드
CI/CD 빌드 서버는 Nexus만 바라보도록 settings.xml 설정

2. 환경 정보

항목	값
Nexus URL	내부망 Nexus 서버 주소
업로드 레포	hosted 타입 레포 (프로젝트 전용)
그룹 레포	maven-public (업로드 레포 포함)
의존성 수집 경로	로컬 임시 수집 디렉터리
총 의존성	172개 JAR + 55개 parent POM

CI/CD 서버의 settings.xml은 그룹 레포만 바라보면 된다. 개별 레포를 일일이 추가할 필요 없이 그룹 하나로 통합 관리한다.

3. 스크립트 구성

작업을 두 단계 PowerShell 스크립트로 분리했다.

cicd/nexus/
├── 01_collect-mes-deps.ps1   # 의존성 수집 (인터넷 연결된 PC에서 실행)
├── 02_upload-to-nexus.ps1    # Nexus 업로드
└── README.md

4. Step 1 — 의존성 수집

mvn dependency:list로 프로젝트 의존성 목록을 추출한 뒤, 각 항목을 로컬 .m2에서 찾아 임시 수집 경로로 복사하는 방식이다.

# mvn으로 의존성 목록 추출
mvn dependency:list "-DoutputFile=C:\temp\my-project-deps.txt" -DincludeScope=test -q

# .m2에서 수집 경로로 복사
foreach ($line in $depLines) {
    $parts      = $line.Trim() -split ":"
    $groupId    = $parts[0]
    $artifactId = $parts[1]
    $version    = $parts[-2]
    $srcPath    = Find-M2Path -base "$M2_DIR\$groupPath\$artifactId" -version $version

    if ($srcPath) {
        Copy-Item -Path "$srcPath\*" -Destination $dstPath -Recurse -Force
        Write-Host "COPY ${groupId}:${artifactId}:${version}"
    } else {
        $missed += ... # 나중에 처리
    }
}

수집 후에는 .lastUpdated, _remote.repositories 같은 불필요한 메타파일을 제거했다. 이런 파일들이 Nexus에 올라가면 이후 빌드에서 문제가 생길 수 있다.

mvn dependency:list는 JAR 아티팩트만 출력하고 parent POM은 누락한다. 이 때문에 빌드가 실패했고 별도 로직으로 해결했다. (다음 포스팅에서 자세히 다룬다.)

4-1. system scope 의존성 처리

pom.xml에 <scope>system</scope>으로 선언된 로컬 JAR는 .m2에 없으므로 systemPath에서 직접 복사했다.

# pom.xml의 system scope 의존성을 systemPath에서 복사
foreach ($dep in $pom.project.dependencies.dependency) {
    if ($dep.scope -eq "system") {
        $path = $dep.systemPath -replace '\$\{project\.basedir\}', $PROJECT_ROOT
        Copy-Item -Path $path -Destination $jarDst -Force
    }
}

5. Step 2 — Nexus 업로드

수집 경로의 파일들을 Nexus REST API(PUT)로 업로드했다.

$url    = "$NEXUS_URL/repository/maven-my-project-deps/$relativePath"
$result = Invoke-WebRequest -Uri $url -Method PUT -InFile $file.FullName `
    -Headers @{ Authorization = "Basic $cred" } -UseBasicParsing

if ($result.StatusCode -eq 201) {
    Add-Content $DONE_LOG $relativePath  # 완료 기록
    Write-Host "OK  $relativePath" -ForegroundColor Green
}

핵심은 재시작 내성 기능이다. 완료된 파일 경로를 upload-done.log에 기록해두고, 재실행 시 이미 올라간 파일은 SKIP한다. 네트워크가 불안정해 중간에 끊겨도 이어서 실행할 수 있다.

6. CI/CD 빌드 서버 설정

TeamCity 빌드 에이전트의 Maven settings.xml에 Nexus 미러 설정만 추가하면 된다.

<settings>
  <mirrors>
    <mirror>
      <id>nexus</id>
      <mirrorOf>*</mirrorOf>
      <url>http://nexus.internal:8081/repository/maven-public/</url>
    </mirror>
  </mirrors>
  <servers>
    <server>
      <id>nexus</id>
      <username>배포용_계정</username>
      <password>패스워드</password>
    </server>
  </servers>
</settings>

7. 결과

172개 JAR 의존성과 55개 parent POM 수집을 완료했고, 전체 Nexus 업로드에 성공했다. 최종적으로 폐쇄망 TeamCity 빌드까지 통과했다.

이후 parent POM 누락 문제와 로그 충돌 문제 두 가지 추가 트러블슈팅이 있었다. 각각 별도 포스팅으로 정리했다.

(parent POM 누락문제 포스팅: https://bumday.tistory.com/294)

(로그 충돌 문제 포스팅: https://bumday.tistory.com/295)

폐쇄망 Maven 빌드에서 의존성 문제의 핵심은 JAR 외에 parent POM까지 챙기는 것이다. mvn dependency:list만 믿으면 반드시 빌드가 깨진다.

[Troubleshooting] Spring Boot 2.3 + JEUS 로그 라이브러리 충돌 해결

범데이 — Tue, 5 May 2026 11:20:45 +0900

Spring Boot 2.3 기반 프로젝트를 JEUS에 배포하는 과정에서 로그 라이브러리 충돌 문제가 발생했다.

특이한 점은 로컬에서 src 폴더를 직접 구동할 때는 아무 문제가 없었다는 것이다. 빌드된 target 폴더를 실행하거나 JEUS에 배포할 때만 문제가 생겼다.

1. 문제 상황

로컬 Smart Tomcat에서 소스(src) 폴더를 직접 지정해 실행하면 정상 동작했다.

그런데 빌드 결과물인 target 폴더를 실행 대상으로 잡거나 운영 서버(JEUS)에 배포하면 Multiple SLF4J bindings 에러와 함께 기동이 실패했다.

SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/.../logback-classic-1.2.3.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/.../log4j-slf4j-impl-2.17.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]

2. 원인 분석

소스 코드 실행과 빌드 결과물 실행의 차이에서 오는 의존성 충돌 문제였다.

src 모드에서는 IntelliJ가 클래스패스를 관리하며 중복된 라이브러리 중 하나에 임의로 우선순위를 두어 실행한다. 덕분에 충돌이 잠복해 있어도 표면에 드러나지 않는다.

반면 Maven이 빌드를 수행하면 pom.xml에 정의된 모든 의존성을 WEB-INF/lib으로 물리적으로 복사한다. 이때 의존성 전이(Transitive Dependency)로 끌려온 log4j-slf4j-impl이 logback과 같은 폴더에 놓이면서 물리적 충돌이 비로소 발생한다.

JEUS는 클래스패스 내 모든 JAR를 엄격하게 검사하기 때문에 중복 바인딩이 발견되면 기동 자체를 거부한다.

3. 해결 방법

빌드 결과물에 불필요한 라이브러리가 포함되지 않도록 강제 조치해야 한다.

방법 1: Provided Scope 활용 (추천)

log4j-slf4j-impl이 어떤 경로로 유입되는지 특정하기 어려울 때 가장 확실한 방법이다. pom.xml에 해당 의존성을 명시하고 배포 시 제외되도록 설정한다.

<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-slf4j-impl</artifactId>
    <version>2.17.1</version>
    <scope>provided</scope>
</dependency>

방법 2: Exclusion 설정

유입 경로를 확인했다면 상위 라이브러리 설정에서 직접 해당 모듈을 제외한다.

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <exclusions>
        <exclusion>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-slf4j-impl</artifactId>
        </exclusion>
    </exclusions>
</dependency>

4. 정리

src 폴더 실행 시 문제가 없다고 해서 의존성이 깨끗한 것은 아니다.

provided 스코프는 "서버가 제공할 것이니 빌드 결과물에는 넣지 마라"는 의미다. 원치 않는 중복 라이브러리가 target에 유입되는 것을 막는 가장 확실한 방법이다.

빌드 후 WEB-INF/lib 안에 두 라이브러리가 공존하는지 확인하는 습관이 필요하다.