2025년 4월 29일 새벽에 Alibaba의 Qwen3 가 릴리즈되었다.Technical report 가 공개되지 않고, 블로그로만 공개되었기 때문에 학습이 어떻게 이루어졌는지는 아주 제한적으로 공개되었다.모델은 총 6개로 MoE 모델 2개와 Dense 모델 6개로 구성되었다.MoE 모델은 235B (22B activate), 30B (3B activate), Dense 모델은 32B, 14B, 8B, 4B, 1.7B, 0.6B 의 사이즈다.블로그 글에 따르면 각각 가장 큰 모델만 학습한 뒤, strong-to-weak distillation 을 통해 나머지 모델들을 학습한 것으로 보인다.아마도 base model 들은 pruning 기법들을 통해서 사이즈를 줄인 것 같다. (예상컨데 절반정도씩 줄여나간 것이 아닐까 싶다)사실 technical report 가 공개되지 않아서 학습 방법에 대해서는 아직 확실하게 파악하기 어렵다.그러나 공개된 것 중에 흥미로운 부분이 있었는데, 바로 Hybrid Thinking mode 이라는 것이다.Qwen3 공식 블로그에 따르면 Qwen3 는 thinking, 그러니까 reasoning 이 필요한 어려운 문제나 정확도를 요구하는 task 를 해결할 때에는 test-time reasoning 을 사용하고,빠르게 답변이 필요한 경우에는 think 를 끄고 그냥 답변을 제공하도록 학습되었다.이는 Claude-sonnet-3.7 에서 처음으로 제공했던 방식인데, 내가 알기로 명시적으로 open-source 에서 이를 가능하게 한 것은 처음이다.그렇다면 어떻게 on/off 를 구현했는가? Qwen3 는 두 가지 방법으로 on/off 를 제어하고 있다.유저나 시스템 턴에 , 명령어를 명시적으로 사용하면 thinking 을 제어할 수 있다. 예시를 살펴보자.이에 대한 답변은그리고 옵션 사용한 경우에는이에 대한 답변은, 토큰을 사용하여 reasoning 을 하고, 최종 답변하는 것을 볼 수 있다.아마도 이는 학습 시 thinking 없는 데이터는 를, 있는 데이터는 을 사용하여 학습한 것으로 보인다.즉, 스위치 토큰을 학습에 사용하여, reasoning On/Off 를 제어하는 방법이라고 볼 수 있다.또 다른 방법은 이라는 파라미터를 사용하는 것이다. Qwen3 블로그를 보면 아래와 같은 방법이 나와 있다.과연 옵션을 주면 무엇이 달라지는 것일까?을 보면 Qwen3 의 chat_template 이 있다. 여기서 해당 옵션을 통해 달라지는 부분을 확인할 수 있다.즉 enable_thinking 이 false 인 경우 reasoning 이 없는 reasoning 파트를 assistant indicator 뒤에 강제로 붙여 넣어서, reasoning 이 없는 답변을 생성하는 것이다.이는 reasoning 이 assistant indicator 바로 뒤부터 시작한다는 점을 활용한 것인데, 개인적으로 굉장히 스마트하면서 강력한 방법이라고 생각한다.Qwen3 는 두 가지 방법으로 Hybrid thinking mode 를 구현하였다.첫 번째 방법인 , 명령어는 유저가 API 를 사용하거나 chat 서비스를 활용할 때 명시적으로 제어할 수 있는 방법이지만,학습을 통해 구현되는 것이기 때문에 실제로 를 사용하더라도 reasoning 을 할 가능성이 있다 (확률적으로는 낮겠지만, 어디까지나 가능성은 있다).반면 두 번째 방법인 은 빈 thinking 부분을 강제로 붙여버림으로써 reasoning 을 강력하게 꺼버리는 방법이다아무튼 두 방법 모두 아주 간단하면서도 스마트하게 hybrid think mode 를 구현하였다.이후 모델 학습에 참고해서 사용해 봐야겠다.

안녕하세요. 커뮤니케이션 앱 LINE의 모바 일 클라이언트를 개발하고 있는 Ishikawa입니다.저희 회사는 높은 개발 생산성을 유지하기 위해 코드 품질 및 개발 문화 개선에 힘쓰고 있습니다. 이를 위해 다양한 노력을 하고 있는데요. 그중 하나가 Review Committee 활동입니다.Review Committee에서는 머지된 코드를 다시 리뷰해 리뷰어와 작성자에게 피드백을 주고, 리뷰하면서 얻은 지식과 인사이트를 Weekly Report라는 이름으로 매주 공유하고 있습니다. 이 Weekly Report 중 일반적으로 널리 적용할 수 있는 주제를 골라 블로그에 코드 품질 개선 기법 시리즈를 연재하고 있습니다.이번에 블로그로 공유할 Weekly Report의 제목은 '적절한 거리 유지에 신경 쓰자'입니다.정렬된 목록을 표시하는 UI를 구현한다고 가정해 봅시다. 이 목록 상단에는 의 총 개수를 표시하는 헤더가 있습니다. 다음은 목록 표시 예시입니다.목록 및 총 개수 표시에는 다음과 같은 사양이 있습니다.• 목록에 표시할 수 있는 개수는 처음 100개까지• 100 개를 초과하는 이 있는 경우 총 개수는 "100+"로 표시총 개수가 100을 초과할 때 표시 형식은 다음과 같습니다.이 사양을 구현하기 위해 모델 클래 스 과 및 를 다음과 같이 정의했습니다.한편 UI에서 총 개수를 표시하는 텍스트를 결정하는 로직은 개수가 를 초과하는지 아닌지에 따라 분기됩니다.이 코드에 문제가 있을까요?'+1'만큼의 거리를 유지하자코드를 여러 레이어나 컴포넌트로 나눌 때에는 '어떤 레이어나 컴포넌트가 어떤 정보를 가져야 하는지'를 고려해서 설계하는 것이 좋습니다. 하지만 위 코드는 UI와 리포지터리 레이어 간에 '암묵적인 정보'를 공유하고 있기 때문에 사양을 변경했을 때 버그가 발생하기 쉬운 구조입니다.구체적으로 살펴보겠습니다. 먼저 리포지터리 레이어는 UI의 세부 사항에 대해 알 필요가 없는데요. 라는 주석은 이에 반해 세부 사항을 알리고 있습니다.반대로 UI 측도 리포지터리 레 이어의 세부 사항에 의존하고 있습니다. UI 측에서 를 구하는 로직이 리포지터리 레이어의 ' 를 초과하는 이 있을 경우 보다 큰 목록을 반환한다'는 동작에 의존하고 있기 때문입니다.이 문제를 해결하기 위해서는 다음과 같이 '목록에 다 들어갈 수 없는 이 있는지'를 나타내는 속성을 에 추가하면 됩니다.이렇게 하면 리포지터리 레이어는 UI 세부 사항을 신경 쓰지 않고 모델 클래스의 인스턴스 생성에 집중할 수 있습니다.또한 UI 레이어는 더 이상 에 대한 정보가 없어도 됩니다.그런데 ITEM_LIST_MAX_COUNT는 리포지터리 레이어에 있어도 괜찮을까?관련 정보를 어디에 넣을지에 대해서는 몇 가지 선택지가 있습니다.예를 들어 비즈니스 로직 레이어를 마련하고 그곳에서 를 정의할 수 있습니다. 비즈니스 로직 레이어는 채택하는 아키텍처에 따라 도메인, 서비스, 유스 케이스 등 다양한 형태가 될 수 있습니다.만약 비즈니스 로직 레이어를 만드는 것이 과하다고 생각한다면 모델 클래스에 해당 정보를 넣는 것도 한 가지 방법입니다.다만 이 방법은 '알고리즘 -> 데이터 구조'라는 의존 관계의 방향이 모호해지기 때문에 주의해야 합니다. 특히 기능 고유의 로직을 범용적으로 사용되는 데이터 모델에 포함시키지 않도록 조심해야 합니다.

주요내용25년 5월 소식에서는 다음과 같은 유용한 정보들을 만나보실 수 있습니다.React Compiler RCuseMemo 없이도 성능 최적화를 자동으로 처리해주는 새로운 리액트 컴파일러가 드디어 RC 단계에 도달했다.proposal-record-tuple is withdrawn값 기반 데이터 구조 도입을 목표로 했던 R&T가 철회되고, 더 유연한 대안인 Composite 제안이 새롭게 부상 중이다.Features That Every JavaScript Developer Must Know in 2025알아두면 실무에서 바로 쓸 수 있는 JS 기능들을 사례와 함께 정리한다.LLM-first Web FrameworkLLM이 이해하고 생성하기 쉬운 웹 코드를 위해, 정적·동적 값을 동일하게 다루는 프레임워크를 Revolt 기반으로 설계한 사례를 소개한다.>> FE News 25년 5월 소식 보러가기 FE News란? 네이버 FE 엔지니어들이 엄선한 양질의 FE 및 주요한 기술 소식들을 큐레이션해 공유하는 것을 목표로 하며, 이를 통해 국내 개발자들에게 지식 공유에 대한 가치 인식과 성장에 도움을 주고자 하는 기술소식 공유 프로젝트 입니다. 매월 첫째 주 수요일, 월 1회 발행 되고 있으니 많은 관심 부탁드립니다. 구독하기

안녕하세요. SK텔레콤에서 검색/추천 모델링을 담당하고 있는 김선겸입니다.오늘 Reasoning 모델 기반의 AI 검색 고도화의 주제로 이야기 해 보려고 합니다.AI 검색 이전에는 주로 키워드 매칭이나 임베딩 기반 벡터 유사도를 기반으로 Relevance Score가 높은 Top-N 결과를 사용자에게 제시하는 방식으로 정보를 제공해 왔습니다.이 접근 방식은 빠르고 효율적인 검색을 가능하게 했지만, 질문의 의도나 문맥에 대한 이해가 부족해 사용자가 직접 결과를 해석하고 선택해야 하는 한계를 지니고 있었습니다.특히 복잡한 정보의 연결이나 다단계 추론이 필요한 고차원 질의에서는 이러한 방식의 한계가 더욱 뚜렷하게 드러납니다.이러한 한계를 극복하고자 최근에는 Reasoning 능력을 내재한 대형 언어 모델이 검색 시스템에 통합되고 있습니다.단순히 관련 정보를 나열하는 데 그치지 않고, 사용자의 질문을 단계적으로 분석하고 논리적으로 사고하여최종 답변을 직접 도출하거나 보다 명확한 정보로 정리해 제시하는 형태로 진화하고 있는 것입니다.이번 글에서는 Reasoning 모델의 핵심 개념과 주요 특징을 살펴본 뒤, 대표적인 추론 방식인 Chain-of-Thought(CoT)의 활용법과 이를 기반으로 한 모델 학습 과정에 대해 소개합니다.또한 이러한 Reasoning 기반 언어 모델이 실제 SKT AI 검색 시스템과 어떻게 결합되어 고도화를 이끌고 있는지도 함께 살펴보겠습니다.전통적인 대형 언어 모델(LLM)들이 문맥을 기반으로 한 언어 생성 및 예측에 집중했던 것과 달리,Reasoning 모델은 문제 해결 과정에서 인간의 사고 과정을 모방하여, 더 깊고 체계적인 사고를 가능하게 합니다.Reasoning 모델의 핵심 개념과 특징에 대해 알아보도록 하겠습니다.• None• None CoT는 문제를 한 번에 해결하려고 시도하는 대신, 이를 여러 하위 단계로 세분화하여 단계별로 사고 과정을 전개해 나가는 방식입니다. 이 기법은 모델이 각 단계에서 중간 추론을 명시적으로 수행하게 유도함으로써, 복잡한 문제라도 보다 체계적이고 논리적으로 접근할 수 있도록 만듭니다. 결과적으로 CoT를 적용하면 모델이 인간처럼 "생각을 풀어가는 과정"을 모방하며, 최종 결론에 도달하는 과정을 투명하게 보여줄 수 있습니다.• None ToT는 사고 과정을 단일 경로로 제한하지 않고, 여러 가능한 추론 경로를 동시에 생성하여 탐색하는 접근 방식입니다. 문제 해결을 위해 다양한 가설이나 방법을 고려하고, 각각의 경로를 평가하면서 가장 합리적이고 타당한 답을 선택하는 전략을 취합니다. 이 과정에서 비효율적이거나 부정확한 경로는 가지치기(pruning)하고, 유망한 경로는 더욱 깊게 탐색해 나갑니다. ToT는 CoT보다 훨씬 더 복잡하고 다양한 가능성을 포괄할 수 있으며, 특히 경로 선택이나 탐색 최적화가 중요한 문제 상황에서 강력한 성능을 발휘합니다.• None• None Reasoning 모델은 복잡한 수학 문제, 논리적 추론, 코딩 문제처럼 단일 답변 생성만으로는 쉽게 해결할 수 없는 과제들에 대해 탁월한 성능을 발휘합니다. 이 모델은 문제를 해결하는 과정에서 단계별 사고 과정을 명시적으로 노출함으로써, 단순한 정답 예측을 넘어 보다 깊이 있고 신뢰성 있는 문제 해결을 가능하게 만듭니다. 특히 Reasoning 모델은 다음과 같은 주요 장점을 가지고 있습니다• None Reasoning 모델은 문제를 여러 단계로 분해하고 각 단계에서 검증 가능한 추론을 거치기 때문에, 전체적인 오답률이 크게 낮아집니다. 단순히 직관에 의존하는 답변보다, 체계적으로 축적된 추론을 기반으로 한 답변이기 때문에 정확성이 한층 강화됩니다.• None 모델이 사고 과정을 외부에 투명하게 드러내기 때문에, 사용자는 답변이 어떻게 도출되었는지 구체적인 설명을 확인할 수 있습니다. 이러한 해석 가능성은 특히 고신뢰가 요구되는 분야(예: 의료, 법률, 과학)에서 모델의 활용 가치를 크게 높여줍니다.• None Reasoning 모델은 문제 해결의 각 단계를 점검하는 구조를 가지고 있어, 중간 추론 과정에서 발생할 수 있는 오류나 비현실적인 답변 생성(일명 "환각(hallucination)" 현상)을 줄이는 데 매우 효과적입니다. 이를 통해 모델의 답변 신뢰성과 일관성이 한층 강화됩니다. 결국, Reasoning 모델은 단순 정답 생성 모델을 넘어, "왜"라는 질문에 답할 수 있는 설명력과, 복잡한 문제를 다루는 데 필요한 높은 정확도와 안정성을 함께 제공하는 방향으로 진화하고 있습니다.• None• None 대부분의 벤치마크 결과에서 DeepSeek-R1(Reasoning 모델)이 DeepSeek-V3(Non-Reasoning 모델) 대비 더 높은 성능을 보이는 것을 확인할 수 있습니다. 특히 AIME 2024, Codeforces, GPQA Diamond와 같은 벤치마크에서는 두 모델 간 성능 차이가 두드러지게 나타납니다. 이러한 결과는 수학, 과학, 프로그래밍처럼 추론이 요구되는 도메인에서 Reasoning 모델이 더욱 효과적임을 보여줍니다. 다만, 일부 벤치마크에서는 DeepSeek-R1의 성능이 더 높긴 하지만 그 차이가 크지 않은 경우도 관찰됩니다.• None 비용 효율성과 추론 속도 측면에서 우수한 GPT-4o mini와 GPT-o3-mini를 비교한 결과는 위와 같습니다. 두 모델은 아키텍처와 파라미터 규모에서 차이가 있기 때문에 절대적으로 공정한 비교는 어렵지만, Reasoning 특화 모델인 GPT-o3-mini는 전반적인 성능 면에서 우위를 보였습니다. 특히 수학, 논리, 코드 생성 등 고차원 추론이 요구되는 과제에서는 성능 격차가 더욱 명확하게 드러났습니다.• None GPT-4o mini의 상대적으로 낮은 성능을 고려하여, 동일 계열의 상위 모델인 GPT-4o와 성능을 비교해보았습니다. 그 결과, AIME 및 Codeforces와 같은 고난도 추론 중심의 벤치마크에서는 두 모델 간 성능 차이가 뚜렷하게 나타났으며, 반면 MMLU나 Simple QA처럼 비교적 단순한 언어 이해 과제에서는 GPT-4o mini가 오히려 더 우수한

GPU를 활용한 클라우드 환경에서는 비용 효율적이고 안정적인 운영을 위해 GPU 자원의 성능 지표(Metric)를 정확하게 수집하고 분석할 수 있는 모니터링 시스템 구축이 필수적입니다.특히 GPU 인스턴스는 높은 성능만큼 비용도 상대적으로 높아 효율적인 자원 관리와 비용 최적화가 매우 중요합니다.본 글에서는 이러한 과제를 해결하기 위해 AWS의 GPU 스팟(Spot) 인스턴스(g4dn, g5, g6)를 기반으로 Kubernetes(EKS) NodeGroup을 구성하고,NVIDIA GPU Operator를 통해 GPU 자원을 모니터링하는 PoC(Proof of Concept) 환경을 구축하는 방법을 소개합니다.스팟 인스턴스는 온디맨드 인스턴스 대비 약 70~80%까지 비용을 절감할 수 있지만,모든 리전 및 가용영역(AZ)에서 사용할 수 있는 것은 아니므로, 사전에 각 인스턴스 타입의 비용과 가용성을 확인하는 것이 중요합니다.본 가이드에서는 다음과 같은 작업을 진행하겠습니다.• None AWS에서 GPU 스팟 인스턴스를 이용한 EKS 클러스터 및 NodeGroup 구성이 글을 통해 GPU 기반 클라우드 자원의 효율적인 관리 방안을 확인하고, 비용 효율성을 높이는 실질적인 방법을 익힐 수 있습니다.AWS에서 GPU 스팟 인스턴스를 이용한 EKS 클러스터 및 NodeGroup 구성K8s 클러스터를 생성하기 위해 필수적인 정보를 입력한 cluster.yaml 파일을 생성합니다.eksctl 명령어를 이용하여 K8s 클러스터를 생성합니다.성공적으로 구성이 완료되었다면, 다음 명령어를 통해 kubeconfig를 업데이트하고 노드를 조회합니다.NVIDIA GPU Operator는 Kubernetes 환경에서 GPU 자원을 효율적으로 관리할 수 있도록 지원하는 오픈소스 솔루션입니다.GPU Operator는 NVIDIA 드라이버 설치부터, GPU 자원 할당 및 관리, 성능 모니터링까지의 전체 과정을 자동화합니다.이를 통해 GPU 기반 워크로드의 배포와 관리가 쉬워지고, 운영 효율성을 높일 수 있습니다.• None NVIDIA GPU 드라이버의 자동 설치 및 관리GPU Operator는 Helm을 사용하여 Kubernetes 클러스터에 쉽게 설치할 수 있습니다. 아래와 같은 순서로 진행합니다:모든 Pod가 정상적으로 실행되고 있으면 설치가 성공적으로 완료된 것입니다.Prometheus는 Kubernetes 환경에서 메트릭을 수집하고 저장하는 대표적인 모니터링 시스템입니다.Grafana는 수집된 메트릭을 시각화하여 분석할 수 있게 지원합니다.본 글에서는 Prometheus와 Grafana를 Helm을 사용하여 설치하는 방법을 안내합니다.브라우저에서 http://localhost:9090 으로 접속할 수 있습니다.DCGM 메트릭을 입력하여 정상적으로 조회되는지 확인합니다.Prometheus 로 수집된 메트릭을 시각적으로 확인하기 위해서 Grafana 대시보드를 사용합니다.메트릭에 따라 사전에 정의된 대시보드가 있으며 Grafana 공식사이트에서 조회 후 대시보드 ID를 복사하여 사용하거나, 기존에 사용하는 대시보드를 json 파일로 등록할 수 있습니다.대시보드 ID를 클립보드에 복사합니다.배포한 Grafana에 접속하여 복사한 대시보드 ID를 로드합니다.Grafana에서 NVIDIA DCGM Exporter Dashboard를 가져오면 GPU 사용률, 전력 소비량, 메모리 사용량 등을 시각화할 수 있습니다.값이 조회되지 않는 경우에는 편집 모드로 변경 후 Metrics browser의 메트릭 값을 복사하여 Prometheus 콘솔에서 조회되는지 확인합니다.이제 AWS GPU 인스턴스 환경에서 NVIDIA GPU Operator를 활용하여 GPU 자원 모니터링이 가능합니다.Kubernetes 환경에 구축된 Prometheus와 Grafana를 통해 GPU 성능 데이터를 실시간으로 수집하고 분석할 수 있습니다.본 글에서 구축한 환경은 클라우드뿐만 아니라 On-Premise 환경에서도 활용 가능하며, 이를 통해 GPU 자원의 최적화와 운영 비용의 효율적 관리가 가능합니다.

안녕하세요, Junit-team/junit5, spring/spring-boot, apache/seata, naver/fixture-monkey 등 여러 오픈소스 프로젝트에 기여한 YongGoose입니다.처음에는 오픈소스 기여에 대한 관심을 높이려는 의도로 글을 쓰기 시작했지만, 점점 나의 소중한 자식들(?)을 소개하는 재미가 생기네요.이번 글은 아래의 글의 후속 편입니다. (미리 읽고 오시면 좋습니다)JUnit5에 병렬화를 도입한 이야기 - 클래스 단위저번 글에서는 JUnit의 Vintage 엔진에 클래스 단위의 병렬화를 도입한 것을 설명했습니다.여러 개의 테스트 클래스를 실행할 때는 해당 기능으로 인해 성능 향상을 기대할 수 있지만,만약 하나의 테스트 클래스에 있는 여러 개의 메서드를 실행할 때는 성능 향상을 기대하기 어렵습니다.그로 인해 메서드 단위의 병렬화도 메인테이너님께 제안을 드렸고, 긍정적인 답변을 받아 작업을 하게 되었습니다.메인테이너님의 코멘트에서 볼 수 있다시피 클래스 단위 병렬화에서 사용하던 스레드 풀을 활용하면 쉽게 해결이 되는 듯했습니다.그래서 위 다이어그램과 같이 Runner가 ParentRunner인 경우, 모든 childStatement(메서드)를 스레드 풀을 활용해 비동기로 실행하도록 구현했습니다.하지만, 제 기대와 달리 교착 상태가 발생하였습니다.위 이미지는 Github Actions의 워크플로우 결과 이미지인데 6시간 동안 실행을 한 뒤, 시간이 초과되어 자동으로 실패한 것을 볼 수 있습니다.이때 교착 상태는 클래스와 메서드에서 모두 병렬화를 활성화시키고, 테스트 클래스의 수보다 스레드 풀의 크기가 작을 때 발생하였습니다.클래스와 메서드 단위에서 병렬화를 모두 활성화시키면 다음과 같은 순서로 실행이 됩니다.이때 교착 상태는 테스트 클래스의 개수보다 스레드 풀의 크기가 작을 때 발생했습니다. (동일할 때도 발생했습니다)자세히 디버깅한 결과, 현재 사용 중인 스레드 풀의 특성과 연관하여 교착 상태가 발생한 원인을 확인할 수 있었습니다.실행 순서 중, 2번(각 상위 작업에 대해 실행 시작)을 할 때 하나의 스레드가 할당이 됩니다.그리고 해당 스레드는 모든 하위 작업이 완료되어 상위 작업이 완료가 되면 스레드가 반환이 됩니다.만약 스레드 풀의 크기가 3이고, 테스트 클래스의 개수가 3, 각 하위 메서드의 개수도 3이라면모든 스레드는 상위 클래스가 점유하게 되어 하위 메서드는 작업 큐에만 저장이 될 뿐 실행이 되지 않아 교착상태가 발생하는 것입니다.교착상태가 일어나는 4가지 조건과 함께 더 자세히 설명드리겠습니다.우선, 교착 상태가 일어나는 4가지 조건은 아래와 같습니다.그러면 현재의 상태에 대입해 설명하겠습니다.• None 상호 배제 : 스레드는 한 번에 하나의 작업만 사용할 수 있습니다.• None 점유 대기 : 상위 작업(클래스)은 각각 스레드를 점유한 상태에서 하위 작업(메서드)을 제출하고 완료를 기다립니다.• None 비선점 : 현재 사용 중인 스레드는 점유된 스레드를 강제로 해제하거나 다른 작업에 재할당 하지 않습니다.• None 순환 대기 : 상위 작업(클래스)은 각각 하위 작업(메서드)의 완료를 기다리고, 하위 작업(메서드)은 상위 작업(클래스)이 완료되어 스레드가 반환되기를 기다리고 있습니다.아래의 그림은 다이어그램으로 설명한 그림입니다. (조금 난잡해 보이더라도 순서대로 읽으시면 잘 이해가 될 거라고 생각합니다...)그래서 메인테이너님과 현재 상황에 대해 토론을 한 결과 ForkJoinPool을 사용하기로 결정이 되었습니다.ForkJoinPool은 작업 큐에 작업이 남아있는 경우 스레드가 블로킹되지 않고 다른 작업을 처리하는 특성을 가지고 있습니다.그래서 교착상태가 발생하는 4가지 조건 중, 순환 대기를 해결할 수 있다는 장점이 있습니다.각각의 작업이 서로의 작업의 완료를 기다리고 있는 상태가 순환 대기인데 ForkJoinPool을 활용하여 서로의 작업의 완료를 기다리지 않고 다른 작업을 처리하도록 구현하였습니다.Jupiter 엔진의 경우 이미 병렬화에서 ForkJoinPool을 사용하고 있었습니다.아래의 코드는 ForkJoinPool을 활용해 교착상태를 해결하고 메서드 단위의 병렬화를 구현한 코드입니다.work stealing을 허용하기 위해 Future.get()을 각각 호출한 것을 볼 수 있습니다.아래의 이미지는 교착상태를 해결한 흐름을 나타내는 다이어그램입니다.결과적으로는 6시간 동안 실행을 했던 Github Actions도 정상적으로 완료가 되었고, 스레드 풀의 크기에 상관없이 교착상태가 더 이상 발생하지 않고 정상적으로 실행이 되는 것을 확인했습니다.아래의 공식 문서에서 클래스, 메서드 수준의 병렬화를 스레드 사용 예시와 함께 볼 수 있습니다.이번 글이 올라왔을 때는 아래의 PR이 병합되었을 것이라고 생각합니다. (현재 문서화 작업 마무리 중)대부분의 티스토리, 벨로그 글을 보면 ExtensionContext를 활용해 테스트 간 자원을 공유하는 것을 확인할 수 있습니다.하지만, 이러한 자원 공유는 범위가 병확하지 않아 특정 시점이나 테스트 세션 간 자원 관리가 복잡해질 수 있습니다.아래의 PR은 JUnit 플랫폼에서 자원 공유를 request / session 이라는 두 가지 범위로 나누어 관리할 수 있도록 하는 기능을 추가하고 있습니다.이를 통해 자원을 더 세밀하게 제어하고, 테스트 실행 간의 자원의 재사용성을 높이는 것이 목표입니다.해당 기능은 잘 모르고 사용한다면 기존의 ExtensionContext와 별 다르게 사용할 수 없다고 생각합니다.하지만 잘 알고 사용한다면 자원 공유를 매우 효율적으로 사용할 수 있습니다.각종 tech blog들에서도 분명 해당 기능이 merge가 된 후 배포가 되면 자세히 다룰 것으로 예상합니다.하지만, 문서와 코드를 보고 글을 작성하는 분들보다는 직접 만든 사람이 더 잘 알 것이라고 생각합니다. ㅎㅎ해당 글도 DEVOCEAN와 같이 접근성이 좋은 곳에 외부 기고를 하겠습니다.