제29회 IOCCC 2025 수상작 발표

 (ioccc.org)
3P by GN⁺ | ★ favorite | 댓글 1개
  • International Obfuscated C Code Contest(국제 난독화 C 코드 대회)는 가장 창의적이고 예술적이면서도 읽기 힘든 '난독화(Obfuscated)' C 코드를 겨루는 컴퓨터 프로그래밍 대회
  • 2020~2024년 공백 이후 두 번째로 연속 개최된 대회로, 출품 수는 전년과 비슷했으나 출품작 규모와 품질이 역대급 수준 유지
  • Yusuke Endoh, Nick Craig-Wood, Don Yang 세 명이 각각 3개 수상작을 내며 해트트릭 달성, Taiwan 출신 신규 수상자 등장
  • Subleq 컴퓨터, GameBoy 에뮬레이터, patch/diff quine 등 다양한 수상작이 선정되었고, 각 수상작에 Fun challenge 도입
  • 수상작 발표는 Our Favorite Universe YouTube 채널 라이브 쇼로 진행, 차기 IOCCC30은 2026년 말 개최 예정

시작점

  • 2025년 수상 IOCCC 엔트리 링크는 페이지 아래의 수상작 목록에서 확인 가능
  • 각 수상 엔트리의 index.html은 수상 프로그램을 컴파일하고 실행하는 데 필요한 대부분의 정보 제공
  • 수상 소스 코드를 읽으며 작동 방식을 파악하고, 더 자세한 내용은 저자 설명에서 확인 가능
  • 올해 대회의 모든 수상작은 압축 tarball 형태로 다운로드 가능

이번 콘테스트에 대한 일반 비고

  • IOCCC29의 제출량과 제출 품질은 역사적 최고치에 가까운 수준
  • IOCCC28은 4년 공백으로 참가자들이 제출작을 다듬을 시간이 있었고, 그 결과 기록적 제출 수와 평소보다 높은 제출 품질을 끌어냈다는 추측의 대상
  • IOCCC29는 2020~2024년 공백 이후 두 번째 연속 대회였지만, 제출 수는 전년 대회와 비슷했고 전체 제출 품질도 높은 수준 유지
  • IOCCC28 종료 시점부터 신규 제출 마감, 심사 절차, 수상작 선정, 웹사이트 업데이트, Our Favorite Universe 라이브 쇼 제작 절차를 세심하게 문서화
  • 문서화에는 추가 시간과 노력이 필요했지만, 그 결과 IOCCC 운영 방식 전반의 개선 달성
  • IOCCC29 수상작 발표가 Our Favorite Universe YouTube 채널에서 이뤄진 며칠 뒤, 메인 쇼 녹화본을 개별 세그먼트로 분할 예정
  • 각 수상 엔트리의 index.html 상단 근처에는 새 Award presentation 섹션과 YouTube 세그먼트 링크 추가 예정

  • 재미있는 도전 과제 정보

    • 올해 수상작에는 “Judges’ remarks” 섹션 아래 재미있는 도전 과제 추가
    • 특정 수상작의 기능을 파악한 뒤 해당 도전 과제 시도 권장
    • 일부 과제는 다른 과제보다 쉬우며, 어떤 경우에는 prog.c 또는 관련 파일의 대체 버전 제작 요구
    • 어떤 과제는 특정 항목에 대한 설명 작성 요구
    • 특정 수상작의 “A fun challenge” 섹션에서 도전 과제가 still open 상태라면 GitHub pull request 제출로 기여 가능
    • 도전 과제가 닫혀 있더라도 더 나은 해법이 있다고 판단하면 GitHub pull request 제출 가능
    • IOCCC Judges가 더 나은 해법이라고 동의하면 검토 대상
    • 수상작의 재미있는 도전 과제에 더 나은 개선안이 있다면 IOCCC Judges 검토를 위한 GitHub pull request 제출 가능

  • 이번 콘테스트의 규칙과 가이드라인

    • 이번 대회에 적용된 최종 규칙은 2025 rules 버전 29.15 2025-12-02
    • 이번 대회에 적용된 최종 가이드라인은 2025 guidelines 버전 29.08 2025-12-02
    • IOCCC29의 규칙과 가이드라인은 이전 대회 대비 큰 폭의 개편
    • 여러 자원봉사자가 IOCCC Judges에 유용한 편집, 문장 개정, 통합, 전반적 구성 개선을 제공

  • 다음 콘테스트를 향해

    • IOCCC30은 2026년 말 무렵 개막 계획
    • IOCCC30은 비슷한 기간 동안 진행되며 2027년 1분기 말 무렵 종료 계획
    • IOCCC30 개막에 필요한 작업을 수행하면서 IOCCC29 마감 때와 마찬가지로 내부 절차 문서화 계획
    • IOCCC29 수상작 게시 후 약 2~3주가 지나고 2025 디렉터리 트리에 대한 초기 pull requests 일부를 처리한 뒤 IOCCC Judges는 IOCCC vacation 계획
    • IOCCC28 수상작 공개 후에도 IOCCC vacation 계획이 있었지만, mkiocccentry repo의 버그 수정과 개선 처리에 많은 시간이 들어 저장소 안정화 시점에는 IOCCC29 개막 시기 도달
    • 이번에는 post-IOCCC29 IOCCC vacation 종료 후 mkiocccentry repo PRs 작업 계획

일부 수상작에 대한 비고

  • 심사 라운드 최종 세트의 최종 라운드에 오른 제출작에 대해 잠재적 글을 작성하는 과정에서 일부 제출작은 최종 라운드의 마지막 단계에서 제외
  • 남은 여러 엔트리에 대해 추가적인 감탄과 평가 상승
  • 수상작 저자들은 기존 수상 저자 지역에서도 나왔고, IOCCC29에는 새 지역인 Taiwan 출신 jingp49 참여
  • 세 명의 저자가 각각 세 개 엔트리로 수상하며 Hat trick)의 Hat-tricks 구성
  • 주목할 만한 IOCCC29 수상작 일부는 다음과 같은 구성
  • 위 목록은 IOCCC29의 많은 뛰어난 수상작 중 일부에 해당

  • 수상하지 못한 일부 제출작에 대한 비고

    • 최종 선정에 아주 근접했지만 수상하지 못한 훌륭한 제출작이 다수 존재
    • 각 저자가 엔트리에 들인 노력은 높이 평가되지만, 노력만을 기준으로 시상할 수는 없음
    • IOCCC29에 제출했지만 수상하지 못한 코드는 다듬은 뒤 IOCCC30에 다시 제출할 수 있는 대상
    • IOCCC29의 수상작 중 하나 이상은 이전 대회에서 수상하지 못한 코드를 개선한 버전

  • 올해 수상하지 못한 참가자를 위한 격려

    • 올해 IOCCC 제출작에는 많은 노력이 들어갔지만, 모든 제출작에 상을 줄 수는 없음
    • 모든 제출작에 상을 주면 최고라고 판단되고 수상 자격이 있는 제출작의 의미를 빼앗는 결과
    • 최종 라운드 제출작이 수상작이 될 만큼 충분히 좋더라도, 비슷하지만 조금 더 나은 제출작에 밀릴 수 있음
    • 이런 상황이라고 판단되는 제출작은 다음 IOCCC에 개선 버전 제출 권장
    • 여러 차례 수정 제출을 거친 뒤 수상작 수준에 오른 제출작도 존재
    • 다음 IOCCC에는 완전히 다른 유형의 제출작 시도도 가능
    • 다음 IOCCC에 비수상 엔트리를 개선해 재제출할 계획이 없다면 공개 가능

수상작 컴파일 및 실행

2025년 제29회 IOCCC 수상작

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • GameBoy 에뮬레이터 코드가 GameBoy 모양처럼 보이기까지 함. 느린 박수 나올 정도로 미쳤고, 개인적으로 이번 출품작 중 제일 마음에 듦
    https://github.com/ioccc-src/winner/blob/master/2025/ncw1/pr...
    작성자 Nick Craig-Wood는 rclone 만든 사람임

    • 재미있게 봤다니 기쁨 :-) 어떻게 만들어졌는지 보고 싶다면 원본은 여기 있음
      https://github.com/ncw/ioccc-gameboy
      거기에 난독화하지 않은 버전도 대략 있음. 실제로 작업한 건 그쪽이고, 이후 프로그램으로 변수명을 전부 짓누르고 GameBoy 모양에 맞게 압축했음
      출품작의 크기 제한이 가장 힘들었음. IOCCC 출품작은 공백 제외 2503자까지 허용되고, 전체 코드 크기는 4KB인데, Z80 프로세서와 GameBoy 하드웨어 에뮬레이터를 넣기엔 정말 작음
      처음엔 C로 완전한 GameBoy 에뮬레이터를 작성했고 공백 제외 약 6000자에서 시작함. 그 뒤 2503자 제한에 맞추려고 약 100시간을 썼고, 한동안은 들어갈지 확신이 없었음
      목표를 Tetris 실행으로 정했음. Tetris는 비교적 단순한 게임이라 Z80 에뮬레이터의 half carry 플래그나 GameBoy 에뮬레이션의 윈도잉 시스템처럼 필요 없는 기능을 제거함. 또한 C 코드를 끔찍하게 혹사했고, implicit int로 다시는 잊을 수 없는 짓도 했음. IOCCC 규칙 검사기가 C 프로그램으로 구현돼 있어서, 그걸 역공학해 허점을 찾는 데도 시간을 썼음. 특정 연산자들이 토큰 하나로만 계산된다는 걸 발견한 게 특히 유용했음
      충분히 작아진 뒤에는 실행할 게임도 넣어야 했음. Z80 어셈블리로 작성한 테스트 프로그램, 어셈블리로 만든 원주율 계산기, gbdk-2020으로 C로 만든 3D 틱택토, C로 만든 체스 프로그램까지 4개를 만들었음. 꽤 많은 오픈소스 게임도 이 에뮬레이터에서 돌아간다는 걸 알게 돼 가능할 때는 다운로더도 추가함. 의외로 BCD 산술을 쓰는 게임은 많지 않았음
      재미있는 프로젝트였음
    • https://github.com/ncw/ccforth
      https://github.com/ncw/ccforth/tree/master/examples/gameboy
    • 멋지다! 이걸 보면서 나는 CSS와 PHP나 치고 있다니
    • 코드를 그림처럼 보이게 만드는 건 난독화 프로그래밍 대회에서 꽤 많이 쓰인 클리셰임

  • 내가 가장 좋아한 건 Linux와 Doom을 실행할 수 있는 366바이트 C 프로그램 에뮬레이터임 [0]
    이 가상 머신은 OISC, 즉 단일 명령어 컴퓨터를 구현함 [1]
    [0] https://github.com/ioccc-src/winner/blob/master/2025/cable/p...
    [1] https://github.com/ioccc-src/winner/blob/master/2025/cable/R...

    • 지난 몇 주 동안 Linux/amd64 어셈블리로 컴파일되는 내 간단한 프로그래밍 언어를 만들고 있었음
      파일 열기, 셸 명령 실행, strstr, strcpy 같은 표준 라이브러리 루틴을 잔뜩 작성할 수도 있었고, 솔직히 학습 과정에서 필요 없는 것도 구현하긴 했음. 예를 들어 print(getenv("HOME"))는 동작함. 하지만 곧 테스트와 과시용 예제 프로그램이 필요하다는 걸 깨달음
      그래서 당연히 처음 구현한 진짜 프로그램은 brainfuck 인터프리터였음. 덕분에 내 언어는 이제 간접적으로 튜링 완전함
      초기 버전은 유명한 mandelbrot 프로그램 출력을 내는 데 9분이 걸려서 여러 최적화를 했고, 이후 switch/case 문 지원도 넣어 속도를 높였음. 이제 같은 출력을 2분에 만들 수 있으니 개선 여지는 있지만 꽤 진전도 있음
      내 언어 안에 또 다른 언어를 구현하는 반칙 같은 방식이 아주 만족스러웠음. 물론 전부 재미와 학습용이고, 나 자신을 포함해 누구도 진지하게 쓰라고 만든 건 아님
      https://github.com/skx/s-lang
    • 와! 그리고 튜링 완전한 SUBLEQ 변형을 아주 흥미롭게 구현했음

      이 VM은 OISC, 즉 One Instruction Set Computer를 구현한다. 이 명령은 세 개의 부호 있는 32비트 피연산자 a, b, c를 받고, 메모리 m[]에서 다음처럼 프로그램을 실행한다:
      1 PC(program counter)는 0에서 시작
      2 다음 명령을 가져옴, 즉 부호 있는 32비트 피연산자 a, b, c
      3 어떤 피연산자든 하위 비트가 설정돼 있으면 그 비트를 제거하고, 해당 피연산자를 m[operand], 즉 그 주소의 역참조 값으로 바꿈
      4 m[b] = m[b] - m[a]로 설정
      5 m[b]가 0 이하이면 PC를 c로 설정하고, 아니면 PC를 3워드 증가
      6 2단계로 돌아감

    • 이 아이디어는 마음에 드는 것 같지만, 링크된 Eternal Software Initiative [1]는 좀 혼란스러움. 이를 디코딩하는 명령 설명이 여러 버전 있고 서로 충돌함
      여기에는 Set m[b] = m[b] - m[a]라고 되어 있음
      그다음 GitHub의 참조 구현 [2]으로 연결되고, 거기서는 냅킨 메모 [3]만 있으면 된다고 함. 읽은 값을 전부 4로 나누는 방식이고, 참조 구현 [4]도 이를 뒷받침함. 하지만 왜 2가 아니라 4를 고른 건지 명확하지 않음. 비트 하나를 낭비하는 것처럼 보임. 이 비트가 필요했는지, 아니면 향후 확장을 위해 예약된 건지 궁금함
      원래 구현은 4로 나누지 않았고 나중에 추가된 것 같지만, LLVM 코드 생성을 조금 쉽게 하는 것 말고 왜 필요했는지 모르겠음. 4로 나누지 않으면 설명된 시스템이 불가능한지 확인하려면 예제를 많이 따라가 봐야 할 듯함. 아마 짝수 주소에만 접근할 수 있고 PC는 매번 3씩 증가하니 코드 위치를 참조하기는 확실히 성가셨을 것임
      참조 구현은 위치 64에 접근하면 마법처럼 동작해서 64~67 위치를 현재 시각으로 덮어씀. 냅킨 설명에는 나오지만 메인 페이지 설명에는 없음
      두 설명 모두 마법의 -1 주소를 언급하므로, 구현 의존적인 UTC 시계도 자유롭게 쓸 수 있는 메모리를 망가뜨리는 대신 음수 주소로 구현하지 않은 점이 이상함
      두 설명 모두 정기 타이머 인터럽트 과정도 언급하는데, 이것도 아쉬움. 주소 0을 인터럽트 핸들러 위치로, 1을 저장된 PC로 재사용하므로 프로그램 시작 직후 초기 진입점인 위치 0을 덮어써야 함
      [1] https://eternal-software.org/
      [2] https://github.com/adriancable/eternal
      [3] https://github.com/adriancable/eternal/blob/main/docs/napkin...
      [4] https://github.com/adriancable/eternal/blob/main/vm/vm.c
    • 내려받아 빌드해 봤고, 지금까지 본 것 중 가장 인상적인 것이라고 자신 있게 말할 수 있음
    • 영상은 여기 있음
      https://www.youtube.com/live/MoWCwZx1Swc?si=eIOlRsKWNKRVRZeB...

  • 궁금한 사람이 있을까 봐: IOCCC는 가이드라인에서 LLM 사용을 명시적으로 허용함
    "IOCCC has a rich history of remarkable winning entries created by authors who skillfully employed various techniques (often their own tools) to develop their code."

    • 나는 비AI 쪽이지만, 이 경우는 흥미로움. 특히 온라인에 난독화 C 코드가 많지 않고, LLM이 실제 코드에서 의도를 추론하기도 어렵기 때문임. LLM 도움을 받은 출품작을 본 적 있는지 궁금함
      반대로도 흥미로움. LLM이 난독화된 코드의 기능을 얼마나 잘 맞힐 수 있을까?
    • 이건 주로 심사위원들에게 영향을 줌. 조악한 코드가 쏟아질 가능성을 스스로 열어두는 셈이지만, 대회 성격상 심사위원들은 흥미로운 코드와 낮은 품질의 코드를 매우 잘 구분할 것 같음
      IOCCC가 기계의 도움으로 만들었을 수도 있는 코드를 받아들이는 건 좋다고 봄. 덕분에 순수 수작업 우승작의 가치가 더 커져 보임
    • 그러면 LLM 체조 대회가 된 건가?
    • "도구"에 AI가 포함된다면 규칙 7은 자기모순이 됨
      https://www.ioccc.org/2025/rules.html
      여기서 말하는 건 맞춤 코드 생성기를 가리키는 것 같음. "풍부한 역사"를 명시적으로 말하는데, AI가 없던 시절까지 포함하는 표현이라면 왜 AI를 뜻한다고 봐야 하는지 모르겠음

  • 웹사이트 자체도 난독화돼 있어서 C 소스 찾기가 전혀 쉽지 않음

    • 바로 https://www.ioccc.org/2025/#inventory로 가면 됨
    • 탐색하기가 정말 어려움. 대회가 뭔지 파악이 안 되고, 이미 알고 있다는 전제로 만든 것처럼 보임
    • 첫 문장이 우승작 목록 섹션으로 연결되고, 각 우승작 오른쪽 위에 C code 링크가 있음

  • Underhanded C Contest가 돌아왔으면 좋겠음. Obfuscated C 참가자들을 깎아내리려는 건 아니지만, 그쪽이 내겐 훨씬 더 흥미로웠음

  • 여기 Frieren [1] 참조가 있음!
    https://www.ioccc.org/2025/yang2/index.html
    주인공 중 한 명이 Fern이고, 거의 전적으로 흔한 공격 마법인 Zoltraak을 사용함
    [1] https://en.wikipedia.org/wiki/Frieren

  • 세상에, 내가 만든 Game Boy 생명 게임 구현이 우승작 하나에 들어가 있음!

    • 에뮬레이터를 만든 뒤 32KB 제한 안에서 실행할 수 있는 게임을 찾으려고 GitHub를 뒤졌음. 당신 걸 찾았고, 고마움 :-) ./try.sh 스크립트에 사용자가 GitHub에서 내려받아 테스트할 수 있는 옵션을 넣어뒀음

  • 2000년에 첫 인턴십 면접을 봤는데, C 프로그래머 팀에 합류하는 자리였음. 면접관들이 예전 우승작 하나를 보여주고 코드를 리뷰해 보라며 방을 나갔음. 5분쯤 뒤 돌아와서 물었음
    – 그래서요?
    – 죄송합니다, 시간을 낭비하게 했네요. 전혀 이해를 못 하겠습니다
    그러자 다들 웃음을 터뜨리고 입사 절차를 시작하자고 했음
    요즘도 인턴을 이렇게 놀리는지 궁금함. 그때 당황했던 나를 떠올리면 아직도 웃김

  • 오오오! IOCCC가 돌아왔구나!
    주최자들에게 사랑을 보냄 <3 <3 <3 IOCCC를 계속 이어줘서 고맙고, 다시는 사라지지 말아줬으면 함

  • 잠깐, 좀 이해가 안 됨
    Obfuscated C Code Contest는 되는데 Capture the Flag는 안 된다는 건가? AI 때문에?
    https://twit.tv/posts/tech/ai-disrupts-capture-flag-what-mea...

    • Capture the Flag에는 명확한 목표가 있지만, Obfuscated C Contest에는 그런 게 없음. 목표 지향 대회에서 AI가 발전하는 건 이해되지만, 예술적 감각이 들어가는 개방형 대회에서 무엇을 발전으로 봐야 할지는 잘 모르겠음
      "영리한 아이디어를 떠올린 뒤 AI에게 IOCCC 제약에 맞춰 구현해 달라고 할 수 있지 않나?"를 묻는 거라면, 현재 AI 도구는 아직 인간 심사위원이 가치 있다고 볼 수준으로 그걸 해내지 못한다고 봄
답변달기