겉보기엔 완벽한 코드가 사실은 악성코드? — 언더핸디드 C 콘테스트 이야기

완벽해 보이는 코드가 사실은 악성코드라면?

코드 리뷰를 아무리 꼼꼼히 해도 도저히 못 잡아내는, 겉보기엔 너무나 멀쩡하고 깔끔한데 사실은 몰래 나쁜 짓을 하는 코드. 이런 걸 일부러 만들어보는 대회가 바로 언더핸디드 C 콘테스트(Underhanded C Contest)예요. 이름부터가 '뒤통수치는 C'라는 뜻이죠.

대회 규칙이 재밌어요

이 대회의 목표는 특이해요. 주어진 과제(예: 이미지를 처리해라, 데이터를 암호화해라)를 정상적으로 수행하는 C 코드를 짜되, 그 안에 은밀한 악성 동작을 숨기는 거예요. 핵심은 '얼마나 나쁜 짓을 하느냐'가 아니라 '얼마나 결백해 보이느냐'예요. 숙련된 개발자가 코드를 아무리 들여다봐도 “어? 이거 이상한데?” 소리가 안 나올수록 높은 점수를 받아요. 즉, 악의를 가장 자연스러운 코드 속에 녹여내는 기술을 겨루는 대회인 거죠.

어떻게 속이는 걸까요

트릭들은 대부분 C 언어의 미묘하고 함정 많은 구석을 파고들어요. 예를 들면 정수 오버플로(값이 표현 범위를 넘어가면 슬쩍 음수로 뒤집히는 현상), 부호 있는 정수와 없는 정수를 헷갈리게 섞기, 배열 경계를 한 칸 벗어나는 오프바이원(off-by-one), memcpy에 넘기는 크기를 은근슬쩍 틀리게 하기, 매크로로 눈속임하기 같은 것들이죠. 대표적인 예로, 겉으로는 데이터를 암호화하는 것처럼 보이는데 실제로는 키를 미묘하게 약화시켜서 나중에 쉽게 깰 수 있게 만들어두는 식이에요. 또는 이미지의 각 픽셀 최하위 비트에 비밀 데이터를 슬쩍 흘려보내듯이, 정상 기능과 악성 기능이 같은 코드 안에 자연스럽게 겹쳐 있어서 구분이 안 되게 하는 거죠.

이게 왜 중요하냐면요

이 대회는 단순한 장난이 아니라 아주 뼈아픈 교훈을 줘요. '사람 눈으로 하는 코드 리뷰가 생각보다 훨씬 허술하다'는 거예요. 실제로 이건 공급망 공격(supply chain attack)의 핵심 원리와 똑같아요. 2024년에 있었던 xz 유틸리티 백도어 사건 기억하시나요? 오픈소스 압축 라이브러리에 누군가 몇 년에 걸쳐 신뢰를 쌓은 뒤, 사람 눈엔 잘 안 띄는 방식으로 백도어를 심어 전 세계 리눅스 서버를 위협했던 사건이에요. 언더핸디드 C가 대회로 보여주는 걸 현실에서 그대로 재현한 셈이죠.

업계 맥락에서 보면

이 주제는 컴퓨터 과학의 고전인 켄 톰슨의 '신뢰를 신뢰하는 것에 대하여(Reflections on Trusting Trust)'와도 이어져요. 컴파일러 자체에 백도어가 숨어 있으면 소스 코드가 아무리 깨끗해도 소용없다는 유명한 이야기죠. 최근으로 오면 SolarWinds 사태, npm·PyPI에 올라오는 악성 패키지들이 전부 같은 문제의 연장선이에요. 그래서 업계는 정적 분석 도구, 재현 가능한 빌드(reproducible build), SBOM(소프트웨어 자재 명세서), 그리고 애초에 이런 함정이 적은 메모리 안전 언어(Rust 등)로 눈을 돌리고 있어요.

한국 개발자에게

우리에게 주는 메시지는 명확해요. 'LGTM(대충 좋아 보임)' 하고 넘기는 코드 리뷰 문화, 검증 없이 끌어다 쓰는 오픈소스 의존성이 얼마나 위험한지 다시 돌아보게 하거든요. 의존성 하나 추가할 때 정말 믿을 만한지 확인하고, 정적 분석·의존성 스캐닝 도구를 파이프라인에 넣고, 리뷰할 때 '이 코드가 악의적이라면 어떻게 숨겼을까?'라는 시선으로 한 번 더 보는 습관이 필요해요. 보안이나 CTF에 관심 있는 분이라면 이런 트릭들을 방어자 입장에서 공부해두는 것 자체가 좋은 훈련이 되고요.

한 줄 정리: 가장 위험한 코드는 가장 평범해 보이는 코드예요. 여러분은 방금 승인한 그 PR, 정말 안전하다고 자신할 수 있나요?