We announce this program in Korean only, and the contents are not translated.

CASYS 연구실에서 2026년 겨울학기 인턴 학생을 모집합니다.


진행방식

인턴 프로젝트는 박사/석사 학생의 멘토링으로 진행되며 중간중간 교수님과 2주 혹은 3주에 한 번 개인 미팅을 하는 식으로 진행됩니다.

인턴 프로젝트는 저희 대학원생의 연구에서 필요한 내용으로 만들어집니다. 특정 부분에 대한 구현이나 비교 대상이 되는 시스템의 실험 등이 대표적인 예입니다.

인턴으로 선발된 학생에게는 방학 두 달 동안 매월 50만 원을 지급합니다.

공식 기간은 방학 2달입니다. 하지만 시스템 연구의 특성상 방학이 시작하기 전에 저희 연구실에서 개별 연구 방식으로 미리 준비를 하고 방학이 시작되면 본격적으로 시작하는 방식을 권장합니다.

추가로 봄학기, 가을학기 인턴은 직전 겨울학기, 여름학기 인턴분들에게만 제공할 계획입니다. 따라서 저희 연구실에 관심이 있으시면 이번 기회에 꼭 지원해 주시기 바랍니다.

자격요건

엄격한 자격 사항은 아니나 CS330 운영체제를 수강한 학생을 선호합니다.

지원방법

CASYS 연구실 2026 겨울인턴 연구 주제 10개를 소개합니다.

왼쪽 문서 탭에서 주제를 골라 읽고, 1·2순위를 정해 지원해 주세요.

지원 방법: 메일 제목에 [2026 겨울인턴] 태그를 붙여 희망 주제 1·2순위, 성적표, CV를 yjkwon@casys.kaist.ac.kr 로 보내 주세요. 일부 주제는 별도 지원 요건이 있습니다.


최근 공개된 Qwenputer는 32-bit RISC-V CPU를 transformer layer로 컴파일해 Qwen3.5-4B 안에 직접 삽입한 실험적인 모델입니다. 추가된 layer의 가중치는 학습한 것이 아니라 컴파일러가 계산한 값입니다. 이 CPU는 Gated DeltaNet의 recurrent state를 RAM처럼 사용해 C와 MicroPython 프로그램을 모델의 forward pass 안에서 정확하게 실행합니다. 외부 tool이나 sandbox 없이 모델이 스스로 exact한 계산을 수행한다는 점에서, "모델이 컴퓨터를 사용하는 것"을 넘어 "모델 안에 컴퓨터가 있는 것"이라는 새로운 관점을 보여줍니다. 저희는 이 접근을 출발점으로 두 가지 질문을 스터디하고자 합니다. 첫째, 모델 안에 실행 가능한 컴퓨터가 있으면 모델의 시스템 이해 능력을 높일 수 있을까요? 예를 들어 모델이 컴파일된 회로의 내부 state(레지스터, 메모리)를 텍스트 출력이 아닌 hidden state로 직접 읽도록 학습했을 때, tool 결과를 텍스트로 받을 때보다 프로그램 동작이나 시스템 상태를 더 잘 추론하는지 살펴봅니다. 둘째, 이런 방식으로 어느 수준의 컴퓨터 기능까지 구현할 수 있을까요? 현재의 CPU, 계산기, 파일시스템을 넘어 캐시, 가상 메모리, 인터럽트, 멀티코어 같은 기능을 어디까지 컴파일할 수 있는지 확인합니다. 또 recurrent state 용량, layer 깊이, bf16 수치 정확성, 실행 속도가 각각 어디서 한계를 만드는지 정리합니다. 주요 관심사는 관련 연구와 코드베이스 분석, 컴파일러 기반 기능 확장 prototype 구현, 그리고 fine-tuning/RL 환경에서의 실험 설계와 평가입니다.


본 연구는 cache coherence overhead 가 큰 환경에서 CXL 메모리를 활용하여 이를 완화하는 기법에 대한 연구입니다. Cache coherence overhead는 일반적으로 CPU core 수가 많아질수록 증가하는 것으로 알려져 있습니다. 이전까지는 대부분의 워크로드가 많은 threads를 활용할수록 성능이 증가하는 경향을 보였으나, Intel Xeon 5세대, 6세대 프로세서와 같이 1개의 CPU socket 내의 코어 수가 증가함에 따라 threads수를 최대로 사용할 때 성능이 감소하는 경우가 발견되고 있습니다. 이러한 cache coherence overhead로 인한 성능 저하를 해결하기 위해 CXL 메모리를 사용할 수 있습니다. CXL 메모리는 스펙상으로 250 ns 정도의 latency를 갖는다고 알려져있으며, FPGA 기반의 프로토타입은 그보다 훨씬 더 느린 latency를 보입니다. 저희는 이러한 latency 특성을 이용하여 cache coherence를 완화하는 기법을 연구하고 있습니다. 인턴 학생이 하게 될 업무는 compiler나 정적 코드 분석을 통하여 hot data를 예측하고 이를 runtime 이전에 CXL 메모리에 할당하는 것 입니다. 이 과정에서 compiler 코드 공부, 메모리 관리 기법 구현, CXL 메모리 및 서버를 사용한 실험 등을 경험하게 됩니다.


최근 LLM 모델의 크기가 엄청나게 커지면서 AI 연산을 처리하는 GPU가 더 많은 데이터를 빠르게 처리하는 데 큰 어려움을 겪고 있습니다. 흔히 GPU 내부의 메모리로 사용되고 있는 HBM은 속도는 매우 빠르지만 가격과 면적 문제 때문에 용량을 무한히 늘리기 어렵습니다. 이에 대한 대안으로 현재는 GPU 외부에 위치하는 DRAM이나 network를 사용하고 있는데 이는 데이터를 주고 받는 속도인 대역폭이 느려서 병목 현상이 발생합니다. 최근 주목받고 있는 대안인 HBF는 우리가 흔히 쓰는 SSD 등에 들어가는 NAND 플래시 메모리를 기반으로 합니다. HBF는 HBM보다 훨씬 더 큰 용량을 확보할 수 있으면서도, 외부의 DRAM이나 network 대비하여 GPU 내부에 위치하기 때문에 더 높은 대역폭을 낼 수 있다는 장점이 있습니다. 하지만, NAND 기반인 만큼 쓰기 속도가 읽기 속도보다 극도로 느리다거나 수명의 한계가 있다는 치명적인 단점들도 존재합니다. 저희는 이 HBF를 실제 LLM serving 시스템에 적용할 때 부딪히는 하드웨어적 한계들을 시스템 소프트웨어 기술로 해결하는 연구를 하고 있습니다.


AI agent는 코드 탐색, 파일 수정, 정보 검색, 결과물 생성 등 다양한 작업에서 파일시스템에 접근합니다. 그런데 기존 파일시스템은 사람과 전통적인 컴퓨터 애플리케이션을 위해 설계되었습니다. AI agent는 파일을 접근하는 방식도, 작업의 의미를 이해하고 실패에서 복구하는 능력도 기존 애플리케이션과 다릅니다. AI agent가 사용하기 적절한 파일 시스템은 무엇일까요?

1. API

코딩 agent에게 작업을 시키면 예를 들어 다음의 과정을 거칩니다. grep으로 함수 정의를 검색하고, LLM이 살펴볼 함수를 판단하고, 해당 파일을 읽습니다. 정보가 부족하면 호출되는 함수를 다시 검색하거나 관련 파일을 추가로 읽습니다. 때로는 파일의 n줄을 읽고, LLM이 판단한 뒤 부족하면 다음 n줄을 더 읽는 과정을 반복하기도 합니다. 이처럼 기존 파일 중심의 API는 agent가 원하는 정보를 얻기까지 여러 번의 파일 접근과 LLM 호출을 요구합니다. 이 연구에서는 Agent의 정보 탐색 방식에 적합한 API를 제공하여 이러한 비용을 줄이는 것을 목표로 합니다.

2. Crash consistency

Crash consistency는 시스템이 갑자기 중단되더라도 파일시스템이 일관된 상태로 복구되도록 보장하는 것입니다. 기존 파일시스템은 journaling, copy-on-write, write ordering 등을 통해 이를 보장합니다. 하지만 이 과정에서 적지 않은 중복 쓰기와 동기화 비용이 발생합니다. 그런데 AI agent에게도 정확한 파일시스템 상태를 복원하는 것이 반드시 필요할까요? 예를 들어 코딩 agent는 여러 파일을 반복해서 수정합니다. 중간에 crash가 발생하더라도 agent는 원래 작업의 목적을 이해하고, 남아 있는 상태를 분석하여 작업을 다시 수행할 수 있습니다. 이러한 특성을 활용해 기존 파일시스템에서 지불하던 consistency 보장 비용을 줄일 수 있습니다. 이 연구에서는 어떤 데이터를 보존해야 하는지, 어느 수준의 정보가 있어야 복구할 수 있는지, 불완전한 상태를 어떻게 식별하고 안전하게 복구할 것인지 등을 설계하고 구현합니다.

참고: YoloFS (SOSP’26), Semantic File System (ICLR’25)


전통적으로 고성능 GPU는 CPU와 분리된 전용 메모리를 가지며, 저장장치의 데이터를 GPU에서 사용하려면 파일을 시스템 메모리로 읽어 들인 뒤 다시 GPU 메모리로 복사해야 했습니다. CPU와 GPU가 하나의 물리 메모리를 공유하는 Unified Memory 구조는 내장 그래픽이나 모바일 SoC 등에서 오래전부터 사용되어 왔지만, 주로 저전력·저비용 환경을 위한 것이었고 대규모 연산은 전용 메모리를 가진 GPU의 몫이었습니다. 이 때문에 현재의 파일 I/O 인터페이스와 AI 프레임워크의 데이터 로딩 경로는 분리된 메모리 구조를 전제로 설계되어 있습니다. 그러나 최근 NVIDIA DGX Spark, Apple Silicon, AMD MI300A 등 대용량·고대역폭 Unified Memory를 갖춘 시스템이 등장하면서, 이 구조가 대규모 AI 워크로드의 실행 환경으로 주목받고 있습니다.

Unified Memory 환경에서는 CPU와 GPU가 같은 데이터를 복사 없이 함께 접근할 수 있습니다. 하지만 분리된 메모리를 전제로 한 기존 소프트웨어 스택은 이 구조에 맞지 않는 방식으로 동작하고 있습니다. 파일 데이터를 페이지 캐시와 GPU 버퍼에 이중으로 적재하는 것이 대표적입니다. 또한 운영체제가 관리하는 페이지 캐시를 GPU 런타임이 인지하지 못해 가용 메모리를 잘못 판단하기도 합니다. 실제로 128GB 메모리를 갖춘 DGX Spark에서 모델 로딩 시의 중복 적재로 인해 사용 가능한 메모리가 절반 수준으로 줄어드는 사례가 보고되었습니다. 저희 연구실은 이러한 불일치에서 발생하는 성능 및 자원 효율 문제를 식별하고, Unified Memory에 적합한 파일 접근 방식을 탐색합니다.

본 주제에서는 File-backed memory를 중심으로, 파일을 매핑한 메모리 영역을 CPU와 GPU가 복사 없이 직접 사용하는 파일시스템 API를 연구합니다. 특히 파일 데이터의 빠른 재사용을 위한 페이지 캐시가 메모리를 공유하는 환경에서는 오히려 GPU의 가용 메모리를 잠식한다는 상충 관계에 주목했습니다. 이에 따라 페이지 캐시와 GPU의 메모리 사용을 함께 고려하는 파일시스템 API를 설계하고, 대규모 AI 모델 로딩 등 실제 워크로드에 적용하여 그 효과를 검증하고자 합니다.


Modern data-intensive workloads, such as long-context LLM inference, large-scale graph analytics, vector search, and recommendation, are increasingly bottlenecked by the storage path rather than by compute. When working sets exceed GPU memory, data must spill to CPU memory or NVMe SSD, and the conventional CPU-mediated I/O path (including GPUDirect Storage) suffers from submission overhead, round-trip latency, and parallelism capped by CPU core count. These costs are especially severe for fine-grained, data-dependent access patterns, where per-request latency dominates end-to-end performance and access locations cannot be predicted in advance.

A recent line of work explores an alternative: letting the GPU directly submit I/O requests to NVMe SSDs, bypassing the CPU control plane entirely. Your task is to port well-known workloads onto this feature to build strong baselines and evaluate the performance in real world. This work suits students interested in LLM architectures, GPU programming models, and deep experimentation on real hardware. Participants will gain experience with Linux driver modules, NVMe/PCIe/GDS, CUDA kernel programming, and large-scale systems evaluation. The topics for the winter internship focus more on offloading and retrieval problems based on vLLM or SGLang.


AI Agent는 코드 실행, 파일 및 네트워크 접근, 외부 도구 호출 등 다양한 방식으로 시스템과 상호작용하며 작업을 수행합니다. 이러한 에이전트가 필요한 자원과 권한을 활용하면서도 호스트 시스템이나 다른 작업에 미치는 영향을 제한하려면, 무엇을 어떤 수준으로 격리해야 하는지 이해할 필요가 있습니다. 본 연구에서는 실제 AI Agent와 시스템의 상호작용을 직접 분석하여 격리 요구사항을 도출하고, 컨테이너와 가상머신 기반 샌드박스 등 기존 구현체가 이를 어떻게 지원하는지 조사하고 비교하고자 합니다. 이를 바탕으로 각 접근법의 격리 범위, 실행 성능, 자원 관리 측면의 특성과 한계를 분석하고, AI Agent에 적합한 실행 환경과 새로운 시스템 연구 기회를 탐색할 예정입니다.


최근 AI 및 자율형 Agent의 활용이 확대되면서, 클라우드 환경에서 민감한 사용자 데이터를 처리하고 다양한 외부 프로그램을 실행하는 사례가 증가하고 있습니다. 이러한 환경에서는 침해된 클라우드 인프라가 애플리케이션의 기밀 정보를 탈취하거나, 신뢰할 수 없는 프로그램이 사용자 정보를 무단으로 유출하는 등의 보안 위협이 발생할 수 있습니다. 특히 AI Agent는 외부 데이터와 프로그램을 활용하여 다양한 작업을 수행하므로, 기존 시스템에서 고려하지 않았던 새로운 보안 문제가 발생할 수 있습니다.

기존에는 Confidential Computing이나 소프트웨어 격리 기술 등을 통해 이러한 위협에 대응해 왔습니다. 그러나 기존 기술만으로 다양한 프로그램과 사용자가 함께 동작하는 AI 환경을 안전하게 보호하기에는 한계가 있으며, 보안을 강화할수록 성능이 저하되거나 기존 소프트웨어를 사용하기 어려워지는 문제도 존재합니다.

저희 연구실은 이러한 환경에서 발생하는 보안 문제와 기존 기술의 한계를 분석하고, 보안성, 성능, 호환성을 함께 고려한 새로운 시스템 설계 방안을 탐색합니다. 특히 AI 및 Agent 워크로드의 특성을 고려하여 기존 시스템의 보안 및 성능 문제를 발굴하고, 이를 해결하기 위한 시스템 차원의 연구를 진행하고자 합니다.


인턴은 단순 구현이 아닌, 문제 정의 → 설계 → 구현 → 평가까지의 전체 연구 과정을 경험하게 되며, 실제 시스템 코드와 성능 실험을 통해 연구 결과를 도출하는 것을 목표로 합니다. 시스템, 운영체제, 보안, 또는 컴파일러에 관심 있는 학생들의 지원을 환영합니다.


시스템 분야의 도메인 지식을 활용하여 기존 소프트웨어 테스팅 기법의 한계를 극복하고, 스토리지 소프트웨어 스택의 정합성 검증을 목표로 하는 연구입니다. 파일 시스템 및 데이터베이스는 크래시나 장애가 발생한 뒤에도 저장된 데이터가 유지되고 일관된 상태로 복구된다는 것을 보장해야 하며, 이 보장이 깨지면 데이터 손실이나 손상으로 이어질 수 있어 문제가 심각합니다. 이를 검증하기 위하여 CrashMonkey 등 여러 크래시 일관성 테스팅 및 퍼징 연구가 진행되어 왔습니다. 그러나 기존 연구는 주로 커널의 블록 I/O (BIO) 레벨에서 I/O request를 재배열하는 방식으로 크래시 상황을 만들기 때문에, 저장 장치 내부에서 발생하는 하드웨어 폴트까지는 다루지 못해왔습니다. 이런 상황에서 하드웨어 수준의 폴트를 직접 주입하여 파일 시스템부터 데이터베이스까지의 스토리지 스택이 하드웨어 장애 상황에서도 데이터의 persistence, coherence를 보장하는지 테스트하는 연구를 계획하고 있습니다. 기존 테스팅 기법이 다루는 폴트 범위를 하드웨어 계층까지 넓히고, 그 과정에서 생기는 폴트 모델 정의 및 테스트 공간 확대 문제를 해결하고자 합니다.