- 충남대학교 3학년 휴학중.
- 소프트웨어 마에스트로 17기 연수생.
solved.ac hhs2003 | 알고리즘 문제를 즐겨 풉니다. 왜 이 구조가 맞는지, 왜 맞는지, 위험성은 없는지 어디에서 깨질 수 있는지 끝까지 탐구하는 일을 좋아합니다.
엔지니어링에서는 실행 경로가 실제로 어디를 지나가는지 보는 쪽에 관심이 많습니다. 런타임, 메모리, I/O, 컨테이너, 컨트롤러처럼 겉으로는 가려져 있지만 성능과 안정성을 결정하는 층을 좋아합니다.
이 블로그에는 전체적인 개발 회고록을 작성하고 있습니다. 다양한 기술들을 사용하면서 고민했던 흔적들과 의사선택 과정, 트러블 슈팅과정들을 정리하고 있습니다.
알고리즘과 시스템 엔지니어링을 좋아합니다. 정답을 맞히는 데서 끝내기보다, 런타임, 메모리, I/O처럼 실제 실행 경로를 따라가며 원인을 확인하는 과정을 기록하고 있습니다.
목록2026/06 (5)
황현석 일지
Shell Lab 글을 마무리하면서 마지막에 syscall 이야기를 조금 붙였습니다. 처음에는 그냥 fork(), waitpid(), kill() 같은 함수들이 어떻게 커널까지 들어가는지 정리하면 끝이라고 생각했습니다. 그런데 syscall을 정리하다 보니, 새로운 공부를 할 수 있었습니다.POSIX 기준으로 signal handler 안에서 printf를 호출하는 건 안전한 패턴이라고 말하기 어렵다. Shell Lab에서는 sigchld_handler 안에서 printf를 호출하는 식으로 구현했습니다. trace 출력 형식도 맞춰야 했고, 과제 풀이 문맥에서는 그렇게 작성한 코드가 흔합니다. 하지만 그것들은 사실 안티패턴이었습니다. 그리고 문득 궁금해진것은데, printf 가 고작 뭐길래 위험하다는 것..
저는 보통 저작권이 교수님한테 저당잡혀 있는 학교 과제에 대하여 글을 작성하지 않습니다. 과제중에 유일하게 포스팅을 하고 싶었던 주제는 Shell Lab입니다. 다행히, 이미 Shell Lab은 블로그에 글들이 널린 공공재입니다. 학교 과제를 하면서 Shell Lab이 가장 재미있엇습니다. 우선은 코딩이고, 저같은 레벨의 학부생 수준에서는 Low-Level에서 개발할 일이 별로 없어, 더더욱 재미를 느꼇던 것 같습니다. 미루고 미루다가, 거의 10개월이 지난 지금 포스팅을 합니다. 과제를 다시 읽어보게 되서 설렜습니다. Shell Lab은 처음 보면 진입장벽이 높아보입니다. 실제로 Shell Lab은 그 수업을 듣는 학생들의 문맥에서는 요구하는 배경지식이 많은 과제입니다. C 기본 문법만 어느 정도 아는..
회고.이전 글에서는 HWJ에서 C++ WASM runner를 붙이며 겪은 I/O 병목, WASI 전환, 표준 checker fast path 같은 이야기를 정리했습니다. 그때의 결론은 꽤 단순했습니다. 브라우저 안에서 채점을 하려면 모든 것을 WASM으로 밀어 넣는 것이 정답이 아니라, WASM이 필요한 곳과 JavaScript에서 바로 끝내야 하는 곳을 구분해야 한다는 것이었습니다. 이번에는 JavaScript 제출에 대한 고민입니다. 처음부터 지금 구조를 정답으로 잡은 것은 아니었습니다. 출발점은 훨씬 단순했습니다. 브라우저 native V8 JIT로 사용자 JS를 실행하면 빠릅니다. 그런데 온라인 저지처럼 “이 제출이 메모리 제한을 넘었는가?”를 판정하려고 하니, 갑자기 문제가 흐릿해졌습니다. 그래..
회고.안녕하세요. 최근에는 알고리즘 블로그 글을 조금 더 전문적으로 포스팅하고 싶다는 생각이 들었습니다. 단순히 풀이를 적고 끝내는 것이 아니라, 글 안에서 바로 코드를 실행하고 결과를 확인할 수 있으면 좋겠다고 생각했습니다. 그래서 Judge 기능이 달린 Blog를 만들자는 간단한 프로젝트를 진행하고 있었습니다. 프로젝트 명은 HWJ입니다. HWJ는 Hybrid WASM Judge의 줄임말입니다. 지금 만들고 있는 것은 기존 온라인 저지처럼 서버가 모든 테스트를 실행하는 구조가 아니라, 사용자의 브라우저 안에서 Web Worker와 WebAssembly를 이용해 테스트 생성, 정답 실행, 제출 코드 실행, 출력 비교를 위임하는 구조를 만들고 있습니다. 사용자의 어뷰징은 관심이 없습니다. 물론 실제 서비..
회고.처음에는 클라우드 서버를 만들어보겠다는 생각으로 API 서버를 하나 띄우고, Helm으로 KubeVirt 관련 YAML에 값을 주입하면서 VM을 조정하고 있었습니다. 사용자 정보나 상태도 Kubernetes 안에 두기보다는 외부 데이터베이스를 참조하는 구조였습니다. 문제는 KubeVirt를 제어한다고 하면서도, 실제로는 Kubernetes의 동작 방식을 충분히 활용하지 못하고 있었다는 점입니다. KubeVirt가 이미 Kubernetes 위에서 CRD와 controller 패턴으로 동작하는데, 저는 그 위에 다시 별도의 추상 계층을 얹어 명령형으로 제어하려고 했습니다. 결국 이 방식은 제가 이해하고 있는 기술 스택 안에서 Kubernetes를 너무 멀리서, 너무 추상적으로 다루는 접근이었습니다. 그..