삽질탐방기

2026 Microsoft AI Tour Seoul 다녀왔습니다..

그니_ — Sun, 29 Mar 2026 23:16:20 +0900

3월 26일, 코엑스에서 열린 마이크로소프트 AI 투어 서울에 다녀온 후기

왜 갔냐면요

솔직히 말하면, 반강제로?

현재 다니는 회사에도 M365 Copilot이 도입되어 있는데, 막상 쓰라고 하면 뭘 어떻게 써야 하는지 막막했다. 회사에서도 AX(AI Transformation)를 연일 강조하고 있고, "AI 안 쓰면 뒤처진다"는 분위기가 팽배한데... 정작 현업에서 어떻게 녹여내야 할지는 감이 안 왔다.

그러던 중 MS AI Tour 세션 리스트를 봤는데, 특정 세션들이 내 환경에 너무 딱 맞았다:

폐쇄망 환경에서의 Agent 활용
다중 서버 모니터링 자동화
비개발 직군의 AI 접근성

"이건 가야겠다" 싶었다.

현장 분위기

아침 일찍 도착했는데, 이미 사람들이 꽤 많았다. 코엑스 오디토리움 쪽 전체가 MS 부스로 덮여 있었고, 입구부터 시작되는 등록 부스에서 뱃지를 받고 들어가니 키노트 홀이 나왔다.

가장 먼저 눈에 들어온 건 케이터링. 조식과 중식을 제공하고, 커피와 다과가 종일 구비되어 있었다. 역시 빅테크 행사는 다르구나 싶었다. 작은 거지만 이런 디테일이 참석자 경험에 큰 영향을 준다.

부스 존에서는 다양한 체험 코너가 있었다:

나만의 Agent 만들기 데모
Agent를 활용한 실시간 서버 모니터링 체험
이미지 생성 체험
Copilot Studio로 워크플로우 자동화 구축

개발자뿐 아니라 비개발 직군도 쉽게 접근할 수 있도록 구성된 게 인상적이었다.

키노트: "Building South Korea's AI Frontier"

스콧 거스리(Scott Guthrie) MS 클라우드&AI 수석 부사장이 직접 왔다. 조원우 한국마이크로소프트 대표와 함께 기조연설을 진행했는데, 핵심 메시지는 명확했다:

"AI 도입은 더 이상 실험 단계가 아니다. 이제는 측정 가능한 비즈니스 성과로 전환해야 할 때다."

단순히 AI 툴을 쓰는 게 아니라, 조직의 운영 방식 자체를 재설계해서 지속 가능한 성장을 이끌어내자는 이야기였다.

실제 사례로 KT, 현대백화점, 현대오토에버 등의 도입 사례가 소개됐다. 특히 현대백화점의 HEYDI(쇼핑 큐레이션 AI 서비스)가 월 9,000건에서 8만 건으로 상호작용이 증가했다는 이야기는 꽤 충격적이었다.

보면서 느낀 건, 이제 정말 모든 워크플로우가 에이전트 기반으로 재편되고 있다는 것이다. 기획 → 개발 → 테스트 → 배포 → 모니터링, 각 단계에서 에이전트가 보조하거나 아예 자동화한다. 사람은 최종 의사결정과 크리에이티브한 부분에 집중하고, 반복적인 작업은 위임한다. "에이전트로 시작해 에이전트로 끝난다"는 말이 과장이 아니었다.

키노트에서 인상 깊었던 에피소드가 하나 더 있었다. 이세돌이 AI 에이전트를 활용해 18분 만에 바둑 에이전트를 만든 이야기. 한때 AI에게 역사적인 패배를 당했던 그가, 이제는 AI를 활용해 자신만의 AI를 만드는 시대가 됐다. "도메인 전문가 + AI 활용 능력"의 조합이 얼마나 강력한지 보여주는 사례였다.

들었던 세션들

1. 인프라 관리를 위한 AI 도구 Agent 활용

내가 가장 기대했던 세션. 현재 폐쇄망 환경에서 운영/개발을 하고 있는데, Agent를 어떻게 활용할 수 있을지 궁금했다.

중앙 관리 콘솔에서 자연어로 쿼리하면 각 서버의 상태를 종합해서 보여주는 데모였다.

예를 들어:

"지난 1시간 동안 CPU 80% 이상인 서버 보여줘"
"디스크 사용량 90% 넘는 서버에 알림 설정해"

이런 게 가능하다는 거다. 기존에는 Grafana + Prometheus 조합으로 대시보드 만들고, 알림 룰 직접 짜고... 했는데, 이제는 자연어로 그냥 말하면 된다.

2. M365 Copilot Wave 3 소개

Wave 3의 핵심은 Work IQ. 사용자의 업무 컨텍스트를 이해하고, Word/Excel/PowerPoint/Outlook 등 앱 전반에서 개인화된 경험을 제공한다.

Copilot Cowork라는 기능도 소개됐는데, 목표를 설정하면 이메일/캘린더/문서 등 M365 전반의 데이터를 기반으로 멀티스텝 작업을 계획하고 실행해준다. 아직 Frontier Program 사용자 대상 선 제공이라 실제로 써보진 못했지만, 데모 보니까 꽤 쓸만해 보였다.

3. Microsoft Fabric을 활용한 데이터 분석

이건 좀 생소했는데, 들어보니 꽤 강력한 플랫폼이었다.

Microsoft Fabric은 한마디로:

Azure Data Factory + Synapse Analytics + Power BI를 하나로 통합한 SaaS 기반 엔드투엔드 데이터 분석 플랫폼

데이터 수집(Data Factory) → 엔지니어링(Synapse) → 분석(Power BI)까지 하나의 UI에서 가능하다. 기존에는 각각 따로 설정하고 연결해야 했는데, Fabric에서는 OneLake라는 단일 데이터 레이크에 모든 워크로드가 데이터를 저장/공유한다.

현업에서 데이터 파이프라인 구축할 때 제일 골치 아픈 게 각 서비스 간 연결인데, 이걸 많이 줄여줄 것 같았다.

생소했던 기술/개념 정리

1. 하네스 엔지니어링(Harness Engineering)

세션 중에 "하네스 엔지니어링"이라는 용어가 나왔는데, 처음 듣는 개념이라 찾아봤다.

Harness(하네스)는 원래 말을 통제하기 위한 고삐·안장 등의 장비를 뜻한다. 찾아보니 하네스 엔지니어링은 AI 에이전트가 프로덕션에서 안정적으로 동작하도록 에이전트 외부 환경을 설계하는 분야라고 한다. 2026년 2월 Mitchell Hashimoto(HashiCorp 창시자)가 명명했고, OpenAI Codex 팀이 사람이 직접 작성한 코드 0줄로 100만 라인 프로덕트를 만든 사례를 공개하면서 본격적으로 주목받은 것 같다.

프롬프트 엔지니어링이 "AI에게 뭘 시킬지"에 집중한다면, 하네스 엔지니어링은 "AI가 똑바로 일할 수밖에 없는 환경을 어떻게 만들지"에 집중하는 느낌이다. AGENTS.md 같은 규칙 파일, 린터를 통한 아키텍처 제약 강제, 실패 시 방지책을 쌓는 피드백 루프, 고위험 작업의 사람 승인 같은 것들이 구성요소로 보인다. 인상적이었던 건 핵심 원칙인데, "완벽한 하네스를 미리 설계하지 말고, 에이전트가 실수할 때마다 그 실수가 재발하지 않도록 시스템을 추가하라"는 것이었다. 프롬프트를 고치는 게 아니라 구조적으로 재발을 막는다는 점이 기존 접근과 다르다고 느꼈다.

2. Microsoft Fabric

Data Factory, Synapse, Power BI 각각 설정	단일 플랫폼에서 통합 관리
서비스 간 데이터 복제 필요	OneLake에서 단일 카피로 공유
각 서비스별 라이선스	단일 용량 기반 과금
복잡한 파이프라인 연결	드래그앤드롭 수준의 통합

데이터 엔지니어, 데이터 과학자, 비즈니스 분석가 모두가 하나의 플랫폼에서 협업할 수 있다는 게 핵심이다.

3. M365 + Copilot + Azure 연계

이건 원래 알고는 있었는데, 실제 데모를 보니까 연계 수준이 생각보다 깊었다.

Outlook에서 메일 작성 중 → Copilot이 관련 문서 자동 첨부 제안
Teams 미팅 중 → 실시간 요약 + 액션 아이템 추출
Excel 데이터 분석 → 자연어로 피벗 테이블 생성

각 앱이 개별적으로 AI 기능을 제공하는 게 아니라, Microsoft Graph를 통해 전체 업무 컨텍스트를 공유하면서 일관된 경험을 제공한다는 점이 인상적이었다.

재미있었던 것들

Zava - MS의 가상 회사

MS에서 이런 세미나를 할 때 Zava라는 가상의 회사를 만들어서 데모에 활용한다.

이런 방식을 "페르소나 시나리오" 또는 데모용 가상 기업(Demo Tenant)이라고 부른다고 한다. 실제 고객 데이터를 노출하지 않으면서도 현실적인 시나리오를 보여줄 수 있어서 B2B 솔루션 데모에서 자주 쓰인다는데 몰라서 검색했음..ㅎㅎ;

데프콘 등장

연예인 데프콘이 세미나에 왔다ㅋㅋ. 유튜브 촬영인 것 같았는데, 테크 쪽에 관심 많은 것으로 알고 있어서 여기서 보니 신기했다. 예전에 IT 관련 방송도 했던 것 같은데, 이런 행사에도 오는구나.

느낀 점

1. 에이전트로 시작해 에이전트로 끝난다

MS AI 팀의 프로젝트 데모를 보면서 느낀 건, 이제 정말 모든 워크플로우가 에이전트 기반으로 재편되고 있다는 것이다.

기획 → 개발 → 테스트 → 배포 → 모니터링, 각 단계에서 에이전트가 보조하거나 아예 자동화한다. 사람은 최종 의사결정과 크리에이티브한 부분에 집중하고, 반복적인 작업은 에이전트에게 위임하는 구조.

세상이 정말 빠르게 바뀌고 있다.

2. 그래도 사람의 개입은 필연적

재미있었던 건, 최근 AWS 장애 사례를 언급하면서 "AI에 전권을 부여하고 맹신하지 말라"는 메시지를 던진 것이다.

이걸 예로 들면서 Human-in-the-loop의 중요성을 강조했다. 에이전트가 아무리 똑똑해도 최종 승인과 예외 상황 대응은 사람이 해야 한다는 이야기.

이건 현업에서도 마찬가지다. 자동화 파이프라인 만들 때 롤백 조건이나 수동 승인 게이트를 빼먹으면 나중에 큰 사고로 이어질 수 있다.

3. 도메인 몰라도 뭔가를 만들 수 있는 시대

이제는 특정 도메인을 몰라도 어떻게든 해결할 수 있는 시대다.

전문 지식이 없어도 AI를 어떻게 활용하느냐에 따라 다양한 프로젝트를 진행할 수 있다. 물론 깊은 이해가 있으면 더 좋겠지만, 시작의 진입장벽이 현저히 낮아졌다는 건 분명하다.

예전에는 "저 분야는 내 영역이 아니야"라고 선을 그었던 것들도, 이제는 "일단 AI한테 물어보고 시작해보자"가 가능해졌다. 좋은 시대인 것 같다.

회사에 적용할 수 있을 것들

폐쇄망 에이전트 모니터링 PoC: 세션에서 본 자연어 기반 서버 모니터링 방식을 참고해서, 기존 Grafana/Prometheus 환경에 LLM 연동 검토. 온프렘 LLM(Ollama 등) + 사내 메트릭 데이터 조합으로 "CPU 80% 넘는 서버 보여줘" 같은 자연어 쿼리 가능한지 PoC
반복 업무 자동화 후보 리스트업: 에이전트 데모 보면서 느낀 건, 결국 "사람이 반복하는 일"을 찾아서 자동화하는 게 핵심. 팀 내 반복 업무(배포 체크리스트, 장애 대응 초동 조치, 정기 리포트 생성 등) 리스트업하고 자동화 우선순위 정리
Human-in-the-loop 프로세스 점검: AWS 장애 사례 언급 들으면서, 우리 자동화 파이프라인에도 수동 승인 게이트나 롤백 조건이 제대로 있는지 점검 필요

마무리

하루 종일 돌아다니느라 다리는 아팠지만, 꽤 알찬 시간이었다. 특히 폐쇄망 환경에서의 에이전트 활용 세션은 바로 현업에 적용해볼 만한 인사이트를 얻었다.

무료 행사인데 퀄리티가 이 정도면... 역시 빅테크는 다르다. 내년에도 열리면 또 가야겠다.

https://www.hankyung.com/article/202603268484g

MS, 서울서 AI 투어 개최…韓 기업 코파일럿 도입 성과 공개

MS, 서울서 AI 투어 개최…韓 기업 코파일럿 도입 성과 공개, 홍민성 기자, IT/과학

www.hankyung.com

엘라스틱서치 index_closed_exception 트러블슈팅

그니_ — Sun, 29 Mar 2026 20:22:09 +0900

발단

기존 스프링 앱에서 돌고 있던 스케줄 잡을 Quartz로 이관하는 작업을 맡게 됐습니다. 기존 앱을 내리기로 했고, 해당 잡을 Quartz로 옮기는 게 제 담당이었습니다.

기존 코드를 뜯어보니 특정 예외를 로그도 없이 그냥 삼키고 있는 부분이 있었고, 관련 내용이 팀 내에 공유된 적도 없었습니다.

이관하면서 로깅을 제대로 붙이고 나서야 매일 새벽 특정 시간대에 아래 에러가 간헐적으로 발생하고 있었다는 걸 처음 알게 됐습니다.

org.elasticsearch.ElasticsearchStatusException:
  Elasticsearch exception [type=index_closed_exception, reason=closed]

서비스 영향은 없었고 다음 실행에서 자연스럽게 복구되고 있었지만, 매일 같은 시간대에 반복된다는 게 신경 쓰여서 원인을 파악하기로 했습니다.

원인 파악

에러 메시지를 보면 항상 특정 인덱스가 closed 상태라고 나왔습니다. 처음엔 단순 타이밍 문제인가 싶었는데, 날짜를 보니 항상 동일한 시점의 인덱스였습니다.

저희는 ILM(Index Lifecycle Management)을 사용하고 있었고, warm 전환 시 인덱스가 일시적으로 close 상태로 전환됩니다. 바로 그 타이밍에 스케줄 잡이 해당 인덱스를 건드리면서 에러가 발생한 것이었습니다.

index_closed_exception 자체는 ILM 외에도 수동 close, 디스크 부족, 노드 복구 과정 등 다양한 원인으로 발생할 수 있습니다. 다만 "매일 같은 시간대에, 항상 특정 일수가 지난 인덱스" 라는 패턴이 명확하다면 ILM을 먼저 의심해보는 게 좋습니다.

여기서 한 가지 더 확인한 게 있는데, 저희 검색은 alias를 통해 이루어지고 있었고 이 alias가 전체 인덱스를 바라보고 있었습니다. 쿼리에 시간 범위 필터가 있더라도 ES는 alias 하위 인덱스 전체에 요청을 브로드캐스트한 뒤 각 샤드에서 필터링하는 방식으로 동작합니다. 즉, 필터 조건과 무관하게 오래된 인덱스도 검색 대상에 포함됩니다.

정리하면 이렇습니다.

[ILM] warm 전환 → 인덱스 close 상태 진입
      ↓
[Quartz] alias 검색 → 전체 인덱스 브로드캐스트
      ↓
[충돌] close 상태 인덱스 접근 → index_closed_exception
      ↓ ILM poll interval(기본 10분)마다 반복
[완료] 모든 롤오버 완료 → 이후 정상

매일 같은 시간대에 발생한 이유는 인덱스가 생성된 시간 기준으로 ILM이 트리거되기 때문입니다. 간헐적으로 여러 번 실패하는 경우는 인덱스 사이즈나 세그먼트 수에 따라 close 작업 자체가 오래 걸리는 케이스로, 그 시간 동안 잡이 연속으로 실패하는 것이었습니다. warm 전환 시 force merge가 함께 설정된 경우라면 수 분 이상 걸릴 수도 있습니다. (저희는 이 부분까지는 확인하지 못했습니다.)

대응

ILM 정책 수정도 검토했지만 영향 범위가 넓고, 해당 잡이 서비스에 직접적인 영향을 주는 게 아니었기 때문에 애플리케이션 레벨에서 처리하는 방향을 택했습니다.

index_closed_exception은 일시적인 상태이고 다음 실행에서 자연스럽게 복구되기 때문에, catch 후 INFO 로깅하고 skip하는 방식으로 처리했습니다.

처리방식에 대한 코드 처리는 하기와 같습니다.

try {
    SearchResponse response = client.search(searchRequest, RequestOptions.DEFAULT);
} catch (ElasticsearchStatusException e) {
    if (isIndexClosedException(e)) {
        log.info("[ScheduleJob] ES index temporarily closed (ILM rollover). Skipping. index={}", targetIndex);
        return;
    }
    throw e;
} catch (IOException e) {
    log.error("[ScheduleJob] ES search failed", e);
    throw new RuntimeException(e);
}

private boolean isIndexClosedException(ElasticsearchStatusException e) {
    return e.getMessage() != null
        && e.getMessage().contains("index_closed_exception");
}

index_closed_exception은 항상 400 BAD_REQUEST로 오기 때문에 status 조건을 함께 체크하면 오탐 가능성을 줄일 수 있습니다.

주의할 점은 index_closed_exception만 명시적으로 구분해야 한다는 것입니다. 아래처럼 넓게 catch하면 다른 에러도 같이 묻힙니다.

// 모든 exception을 핸들링해버리기에 취지와 맞지 않음.
} catch (Exception e) {
    log.info("에러 무시");
}

// ElasticsearchStatusException에서 index close 케이스만 처리.
} catch (ElasticsearchStatusException e) {
    if (isIndexClosedException(e)) {
        log.info("...");
        return;
    }
    log.error("[ScheduleJob] Unexpected ES error", e);
    throw e;
}

다른 선택지

1. ignore_unavailable 옵션

closed 인덱스를 검색 대상에서 자동으로 제외해줍니다. 다만 데이터 누락이 발생해도 에러가 나지 않기 때문에 집계 정합성이 중요한 경우라면 적합하지 않습니다.

searchRequest.indicesOptions(
    IndicesOptions.fromOptions(true, true, true, false)
);

2. 재시도 로직

close 상태가 짧게 끝나는 케이스라면 재시도로도 해결할 수 있습니다.

for (int i = 0; i < 3; i++) {
    try {
        return executeSearch();
    } catch (ElasticsearchStatusException e) {
        if (isIndexClosedException(e) && i < 2) {
            log.info("[ScheduleJob] Retrying... ({}/3)", i + 1);
            Thread.sleep(3000);
            continue;
        }
        throw e;
    }
}

3.alias 검색 대상 범위 제한

alias가 전체 인덱스를 물고 있는 구조라면, 실제로 필요한 범위의 인덱스만 검색 대상으로 지정하는 방식으로 개선할 수 있습니다. 충돌 자체를 원천 차단할 수 있지만 인덱스 설계 변경이 수반되므로 영향 범위를 충분히 검토해야 합니다.

마무리

이번 케이스의 핵심은 두 가지였습니다. ILM warm 전환 시 발생하는 일시적인 close 상태, 그리고 alias 검색이 필터 조건과 무관하게 전체 인덱스를 브로드캐스트한다는 점입니다.

그리고 한 가지 더 — 로그 없이 예외를 삼키는 코드는 생각보다 오래 살아남습니다. 이관이나 리팩토링 작업이 이런 히스토리를 수면 위로 올리는 계기가 되기도 합니다.

[성능개선] MongoDB 쿼리 최적화로 30% 성능 향상시키기: batchSize와 쿼리 조건 개선

그니_ — Sun, 3 Aug 2025 16:07:00 +0900

저는 그동안 RDBMS나 Elasticsearch처럼 익숙한 시스템들을 주로 다뤄왔고, MongoDB는 이번 프로젝트에서 처음 사용하게 되었는데요. 이 MongoDB는 실제 서비스에 등록된 사용자 데이터를 비롯한 여러 데이터들을 보관하는 용도로 사용되고 있습니다.

로그수집기내에서는 이 데이터를 조회해 메모리에 캐시(Map 형태)로 적재해두고, 이후 수집된 로그 파일들에서 특정 필드를 기준으로 MongoDB의 데이터를 조인하듯 매핑해 메타데이터를 추가합니다. 그렇게 가공된 로그는 Kafka → Logstash → Elasticsearch로 이어지는 파이프라인을 타게 됩니다.

MongoDB는 여기서 메타데이터의 원천 역할을 하고 있는 셈입니다. 이 캐시 적재 작업은 매일 새벽 한 번 실행되고 있었고, 수년간 큰 문제 없이 잘 돌아가고 있었습니다. 하지만 차세대 개발을 준비하며 기존 로직을 하나하나 살펴보는 과정에서 성능 병목 가능성이 있는 포인트를 발견했고, 직접 실험을 해보며 개선 작업을 진행해보기로 했습니다.

그 결과 약 1000만 건의 데이터를 처리하는 데 걸리는 시간을 17초에서 12초로 약 32% 단축할 수 있었고, 이번 글에서는 그 개선 과정을 공유하려고 합니다.

로컬 테스트 환경 구성

테스트 데이터를 준비하기 위해 Docker로 MongoDB 환경을 구성했습니다. 간단한 docker-compose.yml 설정은 다음과 같습니다

version: '3.8'

services:
  mongo:
    image: mongo:8.0
    container_name: mongo-sample
    ports:
      - "27017:27017"
    volumes:
      - mongodb_data:/data/db
    restart: unless-stopped

volumes:
  mongodb_data:

데이터는 1000만 건의 고객 정보를 시딩하기 위해 아래 Java 프로그램을 작성했습니다

public class CustomerSeeder {
    public static void main(String[] args) {
        try (MongoClient client = MongoClients.create("mongodb://localhost:27017")) {
            MongoCollection<Document> collection = client
                    .getDatabase("example")
                    .getCollection("customer");

            int total = 10_000_000;
            int batchSize = 10_000;
            List<Document> batch = new ArrayList<>(batchSize);

            for (int seq = 0; seq < total; seq++) {
                String customerNo = String.format("CS%07d", seq);
                String userId = String.format("U%07d", seq);

                Document document = new Document()
                        .append("customerNo", customerNo)
                        .append("userId", userId);

                batch.add(document);

                if (batch.size() >= batchSize) {
                    collection.insertMany(batch);
                    batch.clear();
                }
            }

            if (!batch.isEmpty()) {
                collection.insertMany(batch);
            }

            System.out.println("생성 완료");
        }
    }
}

이 코드는 customerNo와 userId 필드로 구성된 1000만 건의 문서를 생성하고, userId에 인덱스를 추가했습니다. 모든 userId는 null이 아닌 고유 값(U0000000 ~ U9999999)입니다.

기존 로직 분석

기존 시스템은 매일 새벽 1000만 건의 고객 데이터를 MongoDB에서 조회해 Java 메모리 캐시(HashMap)에 적재했습니다. 사용된 쿼리는 아래 테스트 코드에서 확인할 수 있습니다.

package org.example;

import com.mongodb.client.*;
import org.bson.Document;
import org.junit.jupiter.api.BeforeAll;
import org.junit.jupiter.api.Test;
import java.util.HashMap;
import java.util.Map;
import static com.mongodb.client.model.Projections.include;

public class MongoCacheLoaderTest {
    private static MongoCollection<Document> collection;

    @BeforeAll
    static void setup() {
        MongoClient client = MongoClients.create("mongodb://localhost:27017");
        MongoDatabase db = client.getDatabase("example");
        collection = db.getCollection("customer");
    }

    /* 기존 쿼리: 10,000,000건, 소요 시간: 17743ms */
    @Test
    void 기존_작성된_쿼리_및_캐시_초기화방식() {
        long start = System.currentTimeMillis();
        Map<String, String> cacheMap = new HashMap<>();

        MongoCursor<Document> cursor = collection
                .find(new Document("userId", new Document("$ne", null)))
                .projection(include("userId", "customerNo"))
                .iterator();

        while (cursor.hasNext()) {
            Document document = cursor.next();
            String userId = document.getString("userId");
            String customerNo = document.getString("customerNo");

            cacheMap.put(userId, customerNo);
        }

        long end = System.currentTimeMillis();
        System.out.printf("기존 쿼리: %,d건, 소요 시간: %dms%n", cacheMap.size(), (end - start));
    }
}

로컬 환경(Mac)에서 이 쿼리를 실행했을 때 약 17.7초가 소요되었습니다. 1일 1회 실행되는 작업이라 큰 문제는 없었지만, 성능을 개선할 여지가 있다면 의미 있는 작업이라고 판단했습니다.

문제점 발견

MongoDB 문서와 구현부의 로직들을 확인하며 파악한 문제점으 아래와 같았습니다.

$ne: null 조건의 비효율성
- $ne 연산은 인덱스를 효율적으로 활용하지 못할 수 있으며, 불필요한 풀 컬렉션 스캔을 유발할 가능성이 있습니다.
기본 batchSize (101)의 한계
- MongoDB Java 드라이버의 기본 batchSize는 101로, 많은 네트워크 왕복을 유발하여 성능 병목이 발생할 수 있습니다.
try-with-resources 미사용
- 기존 코드에서는 커서에 대한 리소스 해제가 누락되어 있었고, 자원 누수 가능성을 고려하면 try-with-resources 구문을 활용하는 것이 안정성 측면에서도 바람직합니다.

성능 개선 시도

다음 세 가지를 개선했습니다.

- $ne: null 필터 제거: 서버 측 필터링을 제거하고 클라이언트(Java)에서 null 체크를 수행했습니다.
- try-with-resources 적용: 커서 리소스를 안전하게 해제하기 위해 try-with-resources 구문 추가 (AutoCloseable)
- batchSize 조절: batchSize를 10,000으로 설정해 네트워크 호출 횟수를 대폭 줄였습니다.
  - 실제 환경에 맞춰 메모리를 고려해 1000 ~10000건의 사이즈로 구성

개선된 코드는 아래 테스트 코드에서 확인할 수 있습니다

package org.example;

import com.mongodb.client.*;
import org.bson.Document;
import org.junit.jupiter.api.BeforeAll;
import org.junit.jupiter.api.Test;
import java.util.HashMap;
import java.util.Map;
import static com.mongodb.client.model.Projections.include;

public class MongoCacheLoaderTest {
    private static MongoCollection<Document> collection;

    @BeforeAll
    static void setup() {
        MongoClient client = MongoClients.create("mongodb://localhost:27017");
        MongoDatabase db = client.getDatabase("example");
        collection = db.getCollection("customer");
    }

    /* 개선 쿼리:  10,000,000건, 소요 시간: 11967ms */
    @Test
    void 개선된_쿼리_및_캐시_초기화방식() {
        long start = System.currentTimeMillis();
        Map<String, String> cacheMap = new HashMap<>();

        FindIterable<Document> cursor = collection
                .find()
                .projection(include("userId", "customerNo"))
                .batchSize(10000);

        try (MongoCursor<Document> it = cursor.iterator()) {
            while (it.hasNext()) {
                Document doc = it.next();
                String userId = doc.getString("userId");
                String customerNo = doc.getString("customerNo");

                if (userId != null) {
                    cacheMap.put(userId, customerNo);
                }
            }
        }

        long end = System.currentTimeMillis();
        System.out.printf("개선 쿼리: %,d건, 소요 시간: %dms%n", cacheMap.size(), (end - start));
    }
}

결과

개선된 쿼리를 로컬 환경에서 실행한 결과, 처리 시간이 17.7초에서 12.0초로 약 32% 단축되었습니다.

마무리하며

이번 작업은 단순한 쿼리 하나도 어떤 조건이 인덱스에 영향을 주고 실행 계획이 어떻게 달라지는지, 실제로 데이터를 넣고 explain()으로 실행 계획을 확인하며 하나하나 실험해 본 과정이었습니다.

작업을 하면서 다음과 같은 인사이트가 확실히 남았습니다

쿼리 조건 하나로 인덱스가 무력화될 수 있다
batchSize 조정만으로도 눈에 띄는 성능 차이를 만들 수 있다
커서를 안전하게 닫는 습관은 성능보다도 안정성 측면에서 중요하다

그리고 무엇보다도, 기능이 '돌아가기만 하면 됐다'가 아니라 혹시 더 나을 수는 없을까? 를 계속 의심하고 실험해보는 태도가 백엔드 개발자에게 꼭 필요하다는 걸 다시금 느꼈습니다.

비슷한 환경에서 MongoDB를 사용하는 분들께도, 이 사례가 작은 힌트라도 되었으면 합니다.

Apache HTTPD 버전 업그레이드 중 MPM 이슈와 해결 과정

그니_ — Sun, 20 Jul 2025 23:02:51 +0900

최근 회사에서 보안 취약점 점검 결과, Apache HTTPD 버전 업그레이드를 진행해야 했다. 기존에 사용하던 버전은 2.4.5x였고, 2025년 초 기준으로 2.4.6x 버전으로 올려야 하는 과제가 주어졌다. 사내 환경은 httpd, Nginx, Tomcat 등등 이외에도 다양한 웹/WAS 서버로 구성되어 있는데, 서비스 영향도를 고려해 영향도가 적은 서버부터 업그레이드를 시작했다.

기존엔 nginx를 주로 쓰다보니 httpd 버전 업그레이드는 처음 해보는 작업이었다. 게다가 금융권 폐쇄망의 온프레미스 환경이라 설정 및 배포에 제약이 많았다.

평소 Docker로 편하게 작업하던 터라, 사전에 준비된 설치 파일을 하나하나 업로드 후 빌드해야 하는 상황이 좀 아쉬웠다. 폐쇄망이라 외부 레포지토리 접근도 안 되고, 모든 의존성을 미리 준비해야 하니 정신없었다.

이슈 발생: MPM 모듈 문제

업그레이드를 위해 소스 파일을 다운로드하고, 아래와 같은 configure 명령어로 빌드를 진행 후 설치를 진행했다. (참고로, 이 설정은 실제 환경과 다르며, 오류 상황을 재현하기 위해 임의로 구성한 것이다.)

./configure --prefix=/home/web/httpd \
            --enable-so \
            --enable-ssl \
            --with-included-apr \
            --enable-mpms-shared=all
            
            
make && make install

그런데 서버가 시작되지 않고 아래와 같은 에러 로그가 떴다.

AH00534: httpd: Configuration error: No MPM loaded.

로그를 보니 MPM(Module Process Model) 모듈을 로드하지 못했다는 메시지였다. Apache HTTPD는 요청 처리 방식을 결정하는 MPM 모듈을 필수로 로드해야 하는데, 이게 제대로 설정되지 않은 게 문제였다.

원인 파악

Apache HTTPD는 MPM을 통해 프로세스와 스레드 처리 방식을 정의한다. 주요 MPM은 prefork, worker, event 세 가지로, 각각의 특징은 아래 표와 같다.

prefork	프로세스 기반, 안정성과 CGI 호환성이 높지만 성능은 상대적으로 느림
worker	스레드 기반, 메모리 효율이 좋고 고성능을 제공
event	최신 방식, 비동기 Keep-Alive를 지원해 성능과 확장성이 뛰어남

우리 환경은 성능 최적화를 위해 event MPM을 주로 사용하고 있었다. 그런데 --enable-mpms-shared=all 옵션으로 모든 MPM을 공유 모듈로 빌드했음에도, httpd.conf 파일에서 어떤 MPM도 로드되지 않은 상태였다. 확인해보니 prefork, worker, event 모듈이 모두 주석 처리되어 있어 서버가 MPM을 선택하지 못한 상황이었다.

해결 방법

해결법은 생각보다(?) 간단했다. httpd.conf 파일에서 event MPM 모듈을 명시적으로 로드하도록 설정하면 됐다. 아래는 해결 과정이다.

1. httpd.conf 파일을 열어 MPM 관련 설정을 확인한다.

2. event MPM 모듈을 로드하도록 아래 줄을 추가하거나, 주석 처리된 부분의 주석을 해제한다.

LoadModule mpm_event_module modules/mod_mpm_event.so

3. 다른 MPM 모듈(prefork, worker)은 충돌 방지를 위해 주석 처리하거나 제거한다.

#LoadModule mpm_prefork_module modules/mod_mpm_prefork.so
#LoadModule mpm_worker_module modules/mod_mpm_worker.so

4. 설정을 저장한 뒤 서버를 재시작한다.

/home/web/httpd/bin/httpd -k restart

이렇게 하니 서버가 정상적으로 시작됐다!

배운 점

이번 이슈를 통해 몇 가지 교훈을 얻었다.

MPM 설정 점검 필수: httpd.conf에서 MPM 모듈을 명시적으로 로드하지 않으면 이런 에러가 발생한다. 빌드 옵션과 설정 파일을 꼼꼼히 확인해야 한다.
폐쇄망의 고충: 온프레미스 폐쇄망 환경에서는 설치 파일과 의존성을 미리 준비하는 게 중요하다.
로그: 에러 로그는 문제의 원인을 찾는 데 최고의 단서다. 메시지를 보고 바로 MPM 설정을 점검할 수 있었다.

앞으로 비슷한 작업을 할 때는 빌드 옵션과 설정 파일을 더 꼼꼼히 확인해야겠다는 생각이 든다. 이 글을 읽는 분들도 MPM 관련 에러가 발생한다면, httpd.conf에서 모듈 로드 설정을 먼저 확인해보시길 추천한다!

ChatGPT 채팅 삭제, 크롬 확장 프로그램으로 자동화하기

그니_ — Fri, 28 Mar 2025 00:44:41 +0900

ChatGPT를 쓰다 보면 대화 기록이 계속 사이드바에 남게 됩니다. 삭제하려면 수동으로 하나씩 지워야 하고, 대화량이 많아질수록 꽤 번거로운 작업이 됩니다.

저는 ChatGPT를 자주 사용하는 편인데, 개인적으로 채팅 목록을 깔끔하게 정리하고 싶어서 직접 확장 프로그램을 만들어보기로 했습니다.

프론트엔드 쪽은 따로 경험이 없어서 처음부터 혼자 구현하긴 어려웠고, 기본적인 구조와 접근 방식은 ChatGPT에게 도움을 받아 시작했습니다.
그 후 실제 DOM 구조나 동작을 보면서 디버깅하며 필요한 부분을 수정해가며 완성한 형태입니다.

이름은 chatgpt-chat-remover입니다.

주요 기능

전체 삭제: 기존 채팅 목록 전체를 선택해 한 번에 삭제할 수 있습니다.
선택 삭제: 원하는 대화만 체크해서 개별 삭제할 수 있습니다.

참고: 이 확장 프로그램에서 사용하는 삭제 방식은 실제 데이터를 완전히 삭제하는 것이 아니라, ChatGPT 백엔드 API를 통해 is_visible: false로 설정하여 UI에서 해당 채팅을 숨기는 방식입니다.
이는 ChatGPT 자체의 기본 삭제 동작과 동일합니다.

작동 방식

content.js에서는 ChatGPT DOM 구조에 접근해 각 채팅 항목에 체크박스를 삽입하고, 상단에 컨트롤 버튼 UI를 추가합니다.
선택된 채팅 ID들을 모아서 백엔드 API로 PATCH 요청을 보내 is_visible: false로 처리합니다.
accessToken은 script 태그 내부 문자열을 대상으로 JSON 파싱을 통해 추출합니다.
(window.__reactRouterContext.streamController.enqueue(...) 내부 구조 사용)
상태 저장은 window 객체의 플래그 변수(chatRemoverAllSelected, chatRemoverObserverInitialized)를 사용해 간단히 처리합니다.
MutationObserver를 사용해 ChatGPT의 SPA 구조에서도 UI가 바뀔 때마다 체크박스와 버튼이 다시 삽입되도록 구성했습니다.

동작 영상

개발 중 겪었던 어려움

1. CORS 우회 문제

ChatGPT 백엔드 API(https://chatgpt.com/backend-api/conversation/{id})에 직접 요청을 보내는 구조이기 때문에, 크롬 확장 프로그램의 권한 범위에서 안전하게 동작하도록 구성해야 했습니다.

2. accessToken 추출

기존 웹 서비스처럼 토큰이 쿠키나 스토리지에 저장되어 있지 않고, React 내부 함수의 인자로 넘어오기 때문에 해당 스크립트에서 문자열을 직접 파싱해야 했습니다. 이 과정에서 JSON이 이중으로 인코딩되어 있어, 디버깅하며 처리 순서를 하나씩 정리해 나갔습니다.

향후 계획

더 이상의 기능 추가는 예정되어 있지 않습니다.
현재 상태에서 필요한 기능은 모두 구현되어 있고, 실제 사용 환경에서도 목적에 부합하기 때문입니다.

마무리

ChatGPT 채팅을 주기적으로 정리하거나, 불필요한 대화 목록을 깔끔하게 지우고 싶은 분들에게는 꽤 실용적인 도구입니다.

현재 이 확장 프로그램은 Chrome Web Store에 등록 완료 후 검토 중입니다.
심사가 완료되면 설치 링크도 함께 업데이트할 예정입니다.

배포 전이긴 하지만, 로컬에서 크롬 확장으로 직접 설치해서 사용하기에도 가볍고 직관적인 구조입니다.
필요하신 분들은 직접 적용해보시거나, 내부 코드 참고하셔도 좋을 것 같습니다.

소스코드는 아래 GitHub에서 확인하실 수 있습니다.
https://github.com/kgggh/chatgpt-chat-remover

GitHub - kgggh/chatgpt-chat-remover: ChatGPT 채팅 기록을 손쉽게 삭제할 수 있는 크롬 확장 프로그램

ChatGPT 채팅 기록을 손쉽게 삭제할 수 있는 크롬 확장 프로그램. Contribute to kgggh/chatgpt-chat-remover development by creating an account on GitHub.

github.com

업데이트 (2025.3.31 월)
해당 확장 프로그램이 오늘부로 크롬 웹 스토어에 정식 등록되어, 이제 누구나 다운로드 후 바로 사용하실 수 있습니다!
Chrome 웹 스토어에서 설치하기

ChatGPT Chat Remover - Chrome 웹 스토어

Select and delete multiple chats in ChatGPT.

chromewebstore.google.com

Spring Boot 3.4.3에서 Auto-configuration이 동작하지 않는 문제 해결

그니_ — Sun, 9 Mar 2025 18:10:50 +0900

문제 상황

Spring Boot 3.4.3에서 라이브러리를 개발하면서 META-INF/spring.factories에 EnableAutoConfiguration을 등록했지만, 자동 설정이 적용되지 않았습니다......

문서를 찾아보니 Spring Boot 2.7 Release Notes와 Spring Boot 3.0 Migration Guide에서 관련 내용을 다루고 있었습니다.

원인 분석

Spring Boot 2.7에서 변경된 Auto-configuration 등록 방식

기존에는 spring.factories에 자동 구성 클래스를 쉼표로 구분하여 등록했지만, Spring Boot 2.7부터는 새로운 방식이 추가되었습니다.

기존 방식: spring.factories에서 org.springframework.boot.autoconfigure.EnableAutoConfiguration 키 아래 등록하는 방식
새로운 방식: META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 파일에 한 줄씩 등록
Spring Boot 2.7에서는 두 방식 모두 사용할 수 있었으며, 중복이 있을 경우 자동으로 정리

Spring Boot 2.7에서는 호환성을 위해 기존 방식과 신규 방식으로도 등록할 수 있었습니다.

Spring Boot 2.7 Release Notes

Spring Boot helps you to create Spring-powered, production-grade applications and services with absolute minimum fuss. - spring-projects/spring-boot

github.com

Spring Boot 3.0부터 기존 방식 제거

Spring Boot 3.0부터는 spring.factories에서 EnableAutoConfiguration 키를 이용한 등록이 삭제되었습니다.

Spring Boot 2.7에서는 spring.factories와 AutoConfiguration.imports 두 방식이 모두 가능
Spring Boot 3.0부터는 AutoConfiguration.imports만 지원

Spring Boot 3.0 Migration Guide

Spring Boot helps you to create Spring-powered, production-grade applications and services with absolute minimum fuss. - spring-projects/spring-boot

github.com

변경 사항 정리

Spring Boot 버전지원 방식

2.6 이하	spring.factories 만 지원됩니다.
2.7	spring.factories + AutoConfiguration.imports (둘 다 사용 가능)
3.0 이상	AutoConfiguration.imports 만 지원됩니다. (spring.factories 삭제)

Spring Boot 3.x에서는 기존 spring.factories 방식이 더 이상 동작하지 않습니다.

이제는 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 파일을 작성해 사용해야 합니다.

해결 방법

기존 방식 (Spring Boot 3.x에서 지원되지 않음)

resources/META-INF/spring.factories

org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
com.gnnny.deadlock4j.spring.boot.autoconfigure.DeadlockBusterAutoConfig

새로운 방식 (Spring Boot 3.x에서 적용 가능)

resources/META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports

com.gnnny.deadlock4j.spring.boot.autoconfigure.DeadlockBusterAutoConfig

Spring Boot 3.x부터는 spring.factories에 등록하는 방식이 아예 동작하지 않습니다.

AutoConfiguration.imports 파일을 만들고, 여기에 한 줄씩 등록하면 해결됩니다.

결론

Spring Boot 3.x에서는 기존 spring.factories 방식이 더 이상 지원되지 않습니다.

3.x 이상버전에선 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 파일을 사용해야 합니다.

역시 안될땐 문서를 찾아보기.....ㅎㅎ

참고 문서

Spring Boot 3.0 Migration Guide

Spring Boot helps you to create Spring-powered, production-grade applications and services with absolute minimum fuss. - spring-projects/spring-boot

github.com

Spring Boot 2.7 Release Notes

Spring Boot helps you to create Spring-powered, production-grade applications and services with absolute minimum fuss. - spring-projects/spring-boot

github.com

Java에서 Thread.UncaughtExceptionHandler 활용하기

그니_ — Thu, 27 Feb 2025 12:03:33 +0900

Java에서 Thread.UncaughtExceptionHandler란?

최근에 스프링 프레임워크를 사용하지 않고 프로젝트를 진행하면서 Thread.UncaughtExceptionHandler의 필요성을 몸소 체감하게 되었습니다.

기존에는 스레드 내부에서 개별적으로 예외를 처리하는 방식이 일반적이라고 생각했는데, 여러 개의 스레드에서 발생하는 예외를 효과적으로 관리하기 위해서는 보다 체계적인 접근이 필요하다는 것을 깨달았습니다.

주로 프레임워크를 사용하다 보니, 다들 아시다시피 제공해주는 @RestControllerAdvice 같은 어노테이션을 활용해서 예외를 처리하는 것이 일반적이었습니다.

하지만 이번 프로젝트를 진행하면서 프레임워크의 예외 처리 기능 외에도 Thread.UncaughtExceptionHandler를 이용하면 보다 근본적으로 스레드 단위에서 예외를 다룰 수 있다는 점을 알게 되었습니다.

보통은 try-catch를 사용해서 예외를 개별적으로 처리하지만, 모든 스레드에 일일이 try-catch를 적용하는 것은 현실적으로 어렵습니다. 이럴 때 Thread.UncaughtExceptionHandler를 사용하면 스레드에서 발생하는 예외를 한 곳에서 처리할 수 있습니다.

//이 메서드는 특정 스레드에서 발생한 미처 처리되지 않은 예외를 감지하여 처리하는 핸들러를 설정할 수 있습니다. 만약 명시적으로 설정된 핸들러가 없을 경우, 해당 스레드가 속한 ThreadGroup의 기본 핸들러가 동작합니다.
public void setUncaughtExceptionHandler(Thread.UncaughtExceptionHandler eh)

setUncaughtExceptionHandler 예제 코드

public class UncaughtExceptionTest {
    public static void main(String[] args) {
        Thread thread = new Thread(() -> {
            throw new RuntimeException("예외 발생~~~~~~");
        });

        thread.setUncaughtExceptionHandler((t, e) -> {
            System.out.println("예외 발생 스레드: " + t.getName());
            System.out.println("예외 메시지 " + e.getMessage());
        });

        thread.start();
    }
}

처음에는 try-catch 없이도 예외를 감지하고 처리할 수 있다는 점에서 흥미를 느꼈습니다. 그런데 프로젝트를 진행하면서 여러 개의 스레드가 동시에 실행될 때 예외 처리를 개별적으로 하는 것이 비효율적일 수도 있겠다는 생각이 들었습니다.

그래서 공통적으로 처리할 수 있는 방법이 있을까 찾아보다 보니 Thread.setDefaultUncaughtExceptionHandler를 활용하면 app 전체에서 스레드 예외를 일괄적으로 처리할 수 있다는 점을 알게 되었습니다.

// 해당 메서드는 특정 스레드에 대해 별도의 핸들러가 설정되지 않았을 경우, 모든 스레드에 대해 적용되는 기본 예외 처리 핸들러를 설정합니다.
public static void setDefaultUncaughtExceptionHandler(Thread.UncaughtExceptionHandler eh)

setDefaultUncaughtExceptionHandler 예제 코드

public class GlobalExceptionHandler {
    public static void main(String[] args) {
        Thread.setDefaultUncaughtExceptionHandler((t, e) -> {
            System.out.println("[Global] 예외 발생 in " + t.getName());
            System.out.println("[Global] 예외 메시지: " + e.getMessage());
        });

        Thread thread1 = new Thread(() -> { 
        	throw new RuntimeException("Thread1 에러~~!"); 
        });
        Thread thread2 = new Thread(() -> { 
        	throw new RuntimeException("Thread2 에러~~!"); 
        });
        
        thread1.start();
        thread2.start();
    }
}

이 방법을 적용했더니, 스레드 개별 예외 처리를 신경 쓰지 않아도 한 곳에서 모든 예외를 관리할 수 있어 유지보수가 훨씬 편리해졌습니다. 특히, setDefaultUncaughtExceptionHandler를 활용하면 새롭게 생성되는 모든 스레드에서 자동으로 예외가 감지되므로, 일일이 setUncaughtExceptionHandler를 설정할 필요가 없습니다.

Thread.UncaughtExceptionHandler 언제 활용하면 좋을까?

활용하면 좋은 경우

멀티스레드 환경에서 예외 로깅이 필요할 때
예외 발생 시 슬랙, 디스코드, 이메일 등으로 알림을 보낼 때

굳이 안 써도 되는 경우

단순한 싱글스레드 애플리케이션에서는 try-catch로 충분할 때
Spring Boot의 @ControllerAdvice, @ExceptionHandler를 활용하면 더 직관적인 예외 처리가 가능할 때

Thread.UncaughtExceptionHandler 는 Java의 멀티스레드 환경에서 중앙 집중식 예외 처리를 할 수 있는 강력한 기능입니다. 이번 프로젝트를 진행하며 멀티스레드 환경에서 발생하는 예외를 체계적으로 관리하는 것이 얼마나 중요한지 다시 한 번 깨닫게 되었습니다.

[참고]

https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html

Thread (Java Platform SE 8 )

Allocates a new Thread object so that it has target as its run object, has the specified name as its name, and belongs to the thread group referred to by group, and has the specified stack size. This constructor is identical to Thread(ThreadGroup,Runnable,

docs.oracle.com

IntelliJ 특정 버전 JDK 21 사용 시 컴파일 오류

그니_ — Sat, 22 Feb 2025 02:43:04 +0900

문제 환경

IDE 버전: IntelliJ IDEA 2023.1
Java 버전: JDK 21

이슈 발생

최근 작업을 하다 파라미터로 TimeUnit 타입을 전달해야 하는데 하기 이미지와 같이 컴파일이 안되는 상황이었다.

java.util.concurrent.TimeUnit 관련해서 컴파일 오류가 발생했다. 왠지 느낌상 버전 이슈인가..?? 싶어 찾아보니, StackOverFlow와 jetbrains issue를 확인해보니 같은 문제를 겪고 있는 사람들이 좀 있었다.

https://stackoverflow.com/questions/77551293/intellij-idea-jdk-21-issue-with-java-util-concurrent-package-timeunit-class

IntelliJ IDEA + JDK 21 issue with java.util.concurrent package - TimeUnit class not available

I have an issue when I am trying to use TimeUnit class from java.util.concurrent. It happens with Oracle JDK 21.0.1 (configurations are below) + IntelliJ IDEA 2023.1.5 (Community Edition) - the lat...

stackoverflow.com

https://youtrack.jetbrains.com/issue/IDEA-333976/Some-java-classes-in-OpenJDK-21-are-not-accessible s

JDK 21: Cannot access class 'TimeUnit'. Check your module classpath for missing or conflicting dependencies : KT-62389

Compile code with compiler 1.9.10, JVM target 20, JRE 21+9-b212.1 (JBR) and got issue: Kotlin: Cannot access class 'TimeUnit'. Check your module classpath for missing or conflicting dependencies Kotlin: Type mismatch: inferred type is java.util.concurrent.

youtrack.jetbrains.com

해결 방법

찾아보니 해결 방법은 두가지였다.

IntelliJ IDEA를 최신 버전으로 업그레이드하기
- 혹시라도 인텔리제이가 JDK 21을 완벽히 지원하지 않는다면 최신 버전으로 올리면 해결할 수 있다.
  - 공식적으로 2023.2.2 realease 버전부터 해당건 이슈가 해소된걸로 확인된다.
JDK 버전을 다운그레이드하기
- 나는 지금 당장 JDK 21까지 써야 할 이유가 없어, 그냥 JDK 17로 내려서 해결하기로 했다
- 간단하게 JDK를 17로 바꾸는 방법은 다음과 같다:
  - File → Project Structure → Project SDK를 17로 변경
  - Modules → Dependencies에서 JDK 17로 설정
  - Gradle/Maven 사용 시 해당 설정도 JDK 17로 변경

결론적으로 JDK 17로 내리니까 문제가 해결됐다. 역시나 버전 이슈였던걸로.... 추후 ide 버전업을....ㅎ

[spring] gradle build fail

그니_ — Wed, 18 Oct 2023 15:27:56 +0900

intellij로 spring 프로젝트를 신규 생성했는데 빌드가 실패하는 상황이 발생했습니다.

해당 프로젝트 버전은 하기와 같았습니다.

version

spring-boot - 3.1.4
java - 17

해당 에러

A problem occurred configuring root project 'token-bucket'.
> Could not resolve all files for configuration ':classpath'.
   > Could not resolve org.springframework.boot:spring-boot-gradle-plugin:3.1.4.
     Required by:
         project : > org.springframework.boot:org.springframework.boot.gradle.plugin:3.1.4
      > No matching variant of org.springframework.boot:spring-boot-gradle-plugin:3.1.4 was found. The consumer was configured to find a library for use during runtime, compatible with Java 11, packaged as a jar, and its dependencies declared externally, as well as attribute 'org.gradle.plugin.api-version' with value '8.3' but:
          - Variant 'apiElements' capability org.springframework.boot:spring-boot-gradle-plugin:3.1.4 declares a library, packaged as a jar, and its dependencies declared externally:
              - Incompatible because this component declares a component for use during compile-time, compatible with Java 17 and the consumer needed a component for use during runtime, compatible with Java 11
              - Other compatible attribute:
                  - Doesn't say anything about org.gradle.plugin.api-version (required '8.3')
          - Variant 'javadocElements' capability org.springframework.boot:spring-boot-gradle-plugin:3.1.4 declares a component for use during runtime, and its dependencies declared externally:
              - Incompatible because this component declares documentation and the consumer needed a library
              - Other compatible attributes:
                  - Doesn't say anything about its target Java version (required compatibility with Java 11)
                  - Doesn't say anything about its elements (required them packaged as a jar)
                  - Doesn't say anything about org.gradle.plugin.api-version (required '8.3')
          - Variant 'mavenOptionalApiElements' capability org.springframework.boot:spring-boot-gradle-plugin-maven-optional:3.1.4 declares a library, packaged as a jar, and its dependencies declared externally:
              - Incompatible because this component declares a component for use during compile-time, compatible with Java 17 and the consumer needed a component for use during runtime, compatible with Java 11
              - Other compatible attribute:
                  - Doesn't say anything about org.gradle.plugin.api-version (required '8.3')
          - Variant 'mavenOptionalRuntimeElements' capability org.springframework.boot:spring-boot-gradle-plugin-maven-optional:3.1.4 declares a library for use during runtime, packaged as a jar, and its dependencies declared externally:
              - Incompatible because this component declares a component, compatible with Java 17 and the consumer needed a component, compatible with Java 11
              - Other compatible attribute:
                  - Doesn't say anything about org.gradle.plugin.api-version (required '8.3')
          - Variant 'runtimeElements' capability org.springframework.boot:spring-boot-gradle-plugin:3.1.4 declares a library for use during runtime, packaged as a jar, and its dependencies declared externally:
              - Incompatible because this component declares a component, compatible with Java 17 and the consumer needed a component, compatible with Java 11
              - Other compatible attribute:
                  - Doesn't say anything about org.gradle.plugin.api-version (required '8.3')
          - Variant 'sourcesElements' capability org.springframework.boot:spring-boot-gradle-plugin:3.1.4 declares a component for use during runtime, and its dependencies declared externally:
              - Incompatible because this component declares documentation and the consumer needed a library
              - Other compatible attributes:
                  - Doesn't say anything about its target Java version (required compatibility with Java 11)
                  - Doesn't say anything about its elements (required them packaged as a jar)
                  - Doesn't say anything about org.gradle.plugin.api-version (required '8.3')
                  
      ...
      ....

원인

콘솔에 찍힌 에러를 번역하여 분석해보니 spring-boot 3.1.4의 호환성 문제였습니다. 이전 프로젝트 진행하며 gradle version과 java sdk version을 17 -> 11로 다운그레이드 한게 원인이었습니다.

Incompatible because this component declares a component, compatible with Java 17 and the consumer needed a component, compatible with Java 11

해결방법

java version을 11 -> 17로 변경하면 됩니다. local java version은 건들지 않고, intellij에서 build시에만 반영토록 version을 변경합니

다.

Settings(command +) -> Build, Execution, Deployment > Gradle > Gradle JVM 변경

번외

프로젝트의 호환성 문제가 아닌 순수하게 gradle의 호환성 문제이면 알맞는 java version을 맞춰주면 됩니다.

[mac] 문제가 발생했기 때문에 컴퓨터를 종료했습니다. 경고창 뜨는 경우 대처법

그니_ — Thu, 7 Sep 2023 19:37:06 +0900

어떠한 이유로 하단의 이미지와 같은 경고창이 전원을 켤때 마다 매번 뜨는 경우에 대한 대처법에 정리해보고자 합니다.

저는 USB-C 케이블 모니터를 뽑다가 재시동 된 후 전원을 켤때 마다 경고창이 뜨는 상황이었는데, 이러한 문제가 생기는 이유는 소프트웨어 또는 하드웨어 문제가 발생하여 생기는 경우라고 합니다.

apple 공식 사이트의 고객지원을 참고해서 보면, 하단과 같이 가이드를 해줍니다.

출처 - 애플 https://support.apple.com/ko-kr/HT200553

결국엔 시도하다 안되면 백업 후 macOS를 재설치 해야 되는 상황이 펼쳐지죠.........

그렇지만 좀더 쉽게 접근하는 방법이 있습니다. 방법은 간단합니다.

터미널을 엽니다.
명령어를 입력 후 라이브러리 > 로그 디렉토리로 이동합니다.
DiagnosticReports 디렉토리를 찾아 하위 파일과 함께 삭제합니다.(다시 생성되므로 삭제해도 무방)
삭제 확인 후 맥을 재부팅 합니다.

cd Library/Logs
rm -rf DiagnosticReports

로그 디렉토리

DianosticReports 로그

디렉토리 및 파일 삭제

위의 방법대로 순서대로 시도해보면 정상적으로 부팅이 되며 경고창이 더이상은 뜨지 않는걸 확인 할수 있습니다!

이렇게 어떠한 문제로 인해 지속적으로 경고창이 뜨는 상황에 대처하는 방법에 대해 다뤄 보았습니다.

도움이 되셨길 바라며 긴글 읽어 주셔서 감사합니다.