LLM은 '더 높은 추상화 계층'이 아닙니다 — 왜 이 구분이 중요한가

요즘 자주 듣는 말, 정말 맞을까요?

요즘 개발자 커뮤니티에서 자주 들리는 말이 있어요. "LLM은 새로운 프로그래밍 추상화 계층이다." 어셈블리에서 C로, C에서 파이썬으로 올라온 것처럼, 이제는 자연어로 코딩하는 시대가 왔다는 거죠. 그럴듯하게 들리는데요, 한 시니어 개발자가 "잠깐, 그건 추상화의 정의 자체와 맞지 않다"고 정면으로 반박하는 글을 썼습니다. 단순한 LLM 회의론이 아니라, 우리가 무심코 쓰는 '추상화'라는 단어의 의미를 다시 짚어보는 글이라 한번 차근차근 살펴볼 만해요.

추상화가 뭐냐면요

프로그래밍에서 추상화 계층이 올라간다는 게 뭐냐면, 같은 입력에 대해 항상 같은 출력이 나오는 결정적(deterministic) 변환을 말해요. 예를 들어 C 컴파일러에 int x = 1 + 1;을 넣으면, 어느 컴퓨터에서 몇 번을 돌려도 똑같은 어셈블리 코드가 나옵니다. 파이썬의 print('hello')도 마찬가지예요. 추상화 계층이 올라간다는 건 '더 적은 코드로 같은 결과를 안정적으로 얻는다'는 뜻이지, '컴퓨터가 알아서 잘 해준다'는 게 아니거든요.

그런데 LLM은 어떤가요? 같은 프롬프트를 두 번 넣으면 거의 항상 다른 코드가 나옵니다. 어떤 날은 잘 동작하는 코드를, 어떤 날은 미묘하게 버그 있는 코드를 뱉어요. 입력이 같아도 출력이 다르다는 건, 정의상 추상화 계층이 아니라 확률적인 코드 생성기에 가깝다는 거죠. 글쓴이는 이걸 "비행기 자동조종 장치"가 아니라 "매번 다른 신입 개발자에게 같은 일을 시키는 것"에 비유합니다.

그럼 LLM은 뭘까요

글쓴이가 LLM을 쓸모없다고 말하는 건 아니에요. 오히려 "LLM은 강력한 도구"라고 분명히 인정합니다. 다만 그 도구의 정체가 무엇인지를 정확히 봐야 한다는 거예요. LLM은 추상화 계층이라기보다는 숙련된 검색·합성 도구에 가깝습니다. 스택오버플로우와 깃허브, 문서를 빠르게 뒤져서 그럴듯한 답을 합쳐주는 일을 굉장히 잘해요. 이건 매우 유용한 일이고, 생산성을 끌어올려 줍니다.

하지만 추상화 계층과 결정적으로 다른 점이 있어요. 추상화 계층 위에서는 그 아래 계층을 몰라도 안전하게 작업할 수 있어요. 파이썬 개발자가 메모리 주소를 몰라도 코드를 짤 수 있는 것처럼요. 반면 LLM이 짜준 코드는 반드시 그 아래 계층(실제 코드)을 읽고 검증해야 합니다. 코드를 못 읽는 사람이 LLM으로 만든 결과물은 동작 여부를 확인할 길이 없거든요. 이건 추상화의 본질적인 약속을 깨뜨리는 거예요.

왜 이 구분이 중요할까

단순히 용어 시비처럼 보일 수 있지만, 사실 매우 실용적인 문제예요. "LLM은 새로운 추상화"라고 믿으면 자연스럽게 따라오는 결론들이 있어요. 예를 들어 "이제 코드를 직접 읽을 필요 없다", "주니어 개발자 교육은 자연어 프롬프트 위주로 바꿔야 한다", "코드 리뷰보다 프롬프트 리뷰가 더 중요하다" 같은 거죠. 만약 진짜 추상화라면 이게 맞는 방향이지만, 확률적 생성기라면 정반대로 "코드를 더 잘 읽어야 하고, 더 깊이 이해해야 한다"가 됩니다.

실제로 글쓴이는 "LLM 시대일수록 컴퓨터 사이언스 기초가 더 중요해진다"고 강조해요. 왜냐면 LLM이 뱉은 코드의 보안 취약점, 성능 함정, 미묘한 버그를 잡아내려면 결국 사람이 읽고 판단해야 하니까요. 추상화는 '몰라도 되게' 만들지만, LLM은 '더 잘 알아야 안전하게' 쓸 수 있습니다.

비슷한 논의들

이 주제는 최근 1~2년간 계속 이어지고 있어요. 안드레이 카파시는 "영어가 새로운 프로그래밍 언어"라고 했고, 사이먼 윌리슨 같은 개발자는 "LLM은 빠른 견습생"에 가깝다고 표현했죠. DHH는 "LLM 코드 베끼기는 신뢰 가능한 추상화가 아니다"라며 비슷한 회의론을 펼쳤고요. 이번 글은 그중에서도 '추상화 계층'이라는 단어 자체에 정면으로 도전한다는 점이 좀 독특해요.

또 흥미로운 비교가 있는데요, 컴파일러는 처음 나왔을 때도 "어셈블리만큼 안 빠르다"는 비판을 받았지만 결정성과 신뢰성 덕분에 결국 표준이 됐어요. LLM이 그 길을 따라갈지, 아니면 영원히 '검토가 필요한 보조 도구'로 남을지가 향후 몇 년간의 핵심 쟁점이 될 것 같습니다.

한국 개발자에게는

실무에서 바로 와닿는 시사점이 두 가지 있어요. 첫째, "바이브 코딩"으로 만든 코드는 반드시 한 번 더 읽어야 한다는 거예요. 특히 보안이나 결제, 인증 같이 잘못되면 큰일나는 영역에서는 LLM 출력을 그대로 커밋하는 습관을 경계해야 합니다. 둘째, 신입·주니어 교육 방향성이에요. "이제 LLM이 다 해주니까 기초는 필요 없다"는 분위기가 일부에 있는데, 오히려 자료구조·OS·네트워크 같은 기초가 LLM 시대의 차별화 무기가 될 가능성이 높아요. LLM이 짜준 코드의 시간복잡도가 이상한지, 메모리 누수가 있는지를 알아채는 사람이 결국 시니어로 성장합니다.