eval is not evil (with LLM)
아래의 글을 먼저 읽고 오면 글의 제목과 맥락을 이해하기 쉽습니다. eval()? eval() 함수는 다양한 스크립트 언어에서 제공하는 기능으로, 문자열 형태로 작성된 코드를 실행할 수 있는 함수입니다. JavaScript, Python, PHP, Ruby 등에서 공통적으로 존재하며, 문자열을 그대로 가져와서 코드로 실행이 가능한 만큼 강력한 도구이지요. 하지만 그동안 eval은 위의 레퍼런스에서처럼 사악한 사술로 비추어졌습니다. python에서는 단일식만 처리가 가능한 eval()과 여러 문의 코드를 처리하는 exec()이 구분됩니다. 하지만, 이 글에서는 같은 맥락의 함수로 여기겠습니다. eval() is evil? 이렇게 강력한 도구가 왜 위험한 것을 넘어서, 사용하는 것 자체에도 '사악하다'는 오명이 붙었을까요? 가장 큰 문제는 보안 취약점입니다. eval()은 문자열로 전달된 내용을 그대로 실행하는 함수입니다. 그렇기에 입력이 정확하게 통제되어야 안전한 사용임을 전제로 하지요. 이런 함수가 문제가 되는 상황은 어떤 상황일까요? 외부에서 임의로 입력된, 신뢰할 수 없는 데이터를 실행하는 경우입니다. 이런 특성은, '사용자를 절대로 믿지말라'고 가르치는 웹 개발에서 특히 문제가 됩니다. 임의의 유저가 어떤 입력을 가져올 지 모르는 일이고, 이를 그대로 믿어서는 안되니깐요. 예를 들어, 사용자가 입력한 문자열을 그대로 eval()로 처리하면, 공격자는 이를 악용해 시스템 명령어를 실행하거나 데이터를 탈취할 수 있습니다. XSS이나 RCE 같은 심각한 공격에 노출될 위험도 있죠. 문자열로 받은 코드를 실행하기에 생기는 문제도 있습니다. 그대로 실행하기엔 사전에 성능 평가나, 디버깅도 어렵습니다. 문제가 생긴다면, 이를 잘 캐치할 수 없죠. 이를 보면, eval() 자체의 문제이기보다는 eval() 함수가 사용되는 환경을 둘러싼 문제에 가깝지 않으신가요? eval() 자체는 강력한 도구이지만, 런타임에서 항상 불안함을 가지고 있던 eval()이었고, 비교적 개방적인 웹 생태계였기에 이런 분위기가 형성된 것이라고 봅니다. 사실 아래와 같은 "eval is evil but not why you may think"와 같은 글에서도 eval 자체의 문제라기 보다는 시스템의 문제이기에 적확하게 사용하면 된다고 하지만, 그럼에도 불구하고 "This is just horrible advice"와 같은 댓글이 달리기도 하죠. eval() with llm's output?
2