위험하다는 eval 코드, 그런데 왜 아직도 쓰나요

저녁 7시 46분, 에르메스단에 소박한 질문 하나가 올라왔다. "근데 eval코드는 그렇게 위험하다는데 만들어진이유가뭔가요"라는 글이었다. eval 코드(문자열을 프로그램 코드로 즉석에서 실행하는 함수)는 임의의 문자열을 그대로 실행할 수 있어 보안 사고의 단골 원인으로 꼽히는데, 그럼에도 왜 존재하고 여전히 쓰이는지를 묻는 소박하지만 근본적인 물음이었다. 개발 지식을 다루는 방에서 흔히 나올 법한 질문이면서도, 막상 답하려면 코드 실행 구조 자체를 짚어야 하는 물음이기도 했다.

3분 뒤 답이 나왔다. "지금 스티어링같은 이유가 있었다고 들은거같아요"라는, 확언이 아닌 전언 형태의 응답이었다. 스티어링(steering, 실행 중인 프로그램이나 모델의 동작 방향을 그 자리에서 조정하는 것)과 관련된 이유가 있는 것으로 들었다는 취지였다. 위험을 감수하고서라도 실행 중인 코드의 흐름을 유연하게 바꿔야 하는 상황이 있고, eval 코드가 그 유연성과 맞닿아 있다는 이야기로 읽힌다. 위험성만 놓고 보면 없애는 게 맞아 보이지만, 실제로는 그 위험성과 맞바꿀 만한 실용적 쓰임새가 분명히 있다는 답이었던 셈이다.

대화는 곧 위험한 코드를 실무에서 어떻게 관리하느냐는 쪽으로 넘어갔다. 저녁 8시 24분, 한 참여자는 자신의 실사용 사례를 공유했다. "저는 오픈소스는 아니고 회사 소스코드 pr올라오면 자동 검토하게 코덱스에 세팅해놨어요"라는 내용이었다. 코덱스(Codex, 오픈AI의 코딩 에이전트 도구)를 이용해 회사 내부 코드의 PR(pull request, 코드 변경을 병합해 달라고 요청하는 절차)이 올라올 때마다 자동으로 검토하도록 만들어뒀다는 것으로, 위험 요소를 사람이 일일이 확인하는 대신 AI 리뷰어를 상시 배치해두는 방식이었다. 특히 공개된 오픈소스가 아니라 외부에 잘 드러나지 않는 회사 내부 소스코드에까지 이 방식을 적용했다는 점에서, 보안에 예민한 코드일수록 자동 검토의 필요성이 더 크다는 인식이 읽혔다.

질문 하나에서 시작된 대화가 결국 실무 팁으로 마무리된 흐름이 눈에 띈다. eval 코드처럼 위험성이 잘 알려진 요소도 나름의 존재 이유(스티어링)가 있다는 점을 짚은 뒤, 곧바로 그 위험을 관리하는 실제 방법(자동 코드리뷰 세팅)까지 이어졌기 때문이다. 오픈소스가 아닌 회사 내부 코드에도 자동 검토 체계를 적용했다는 사례는, 보안이 특히 민감한 사내 개발 환경에서도 AI 기반 코드리뷰 자동화가 이미 실무에 들어와 있음을 보여준다. 위험한 코드를 아예 없애기보다, 그 위험을 상시 감시하는 체계로 관리하는 쪽이 더 현실적인 해법으로 자리 잡고 있는 것으로 보인다. 짧은 개발 잡담 하나가 결국 '위험을 어떻게 다루는가'라는 실무적 물음으로 이어진 셈이다.