최근 LLM과의 프로그래밍에 '고수준 언어의 등장으로 대부분의 프로그래머는 특별한 경우가 아니면 어셈블리를 알 필요가 없게 되었다'는 예시를 적용해 'LLM 등장 이후 이제 자연어가 기존 프로그래밍 언어의 새 추상화 계층'이라고 말하는 사람들을 종종 봤다. 나는 이 비유가 적절하지 않다고 생각한다. 심지어 이 주장이 '그러니까 이제 코드를 읽지 않아도 된다'는 주장을 뒷받침 하려고 할 때는 더욱 그렇다. 우리가 LLM에게 자연어로 내리는 명령은 비결정적/고맥락 명령이다. 이것을 추상화 계층이라 부르는 것은 어색하다. 프로그래밍의 추상화 계층이란 언제나 결정적으로 동작한다. 고수준 언어와 어셈블리의 관계가 그렇다. 구현을 뒤로 감춘 인터페이스가 그렇다. 파사드, 프록시 같은 디자인 패턴, 우리가 아는 모든 HTTP 프레임워크, UI 프레임워크 역시 마찬가지다. LLM과의 대화는 추상화 레이어가 아니다. 인간과의 대화다. 조직에서 일해본 개발자라면 다른 개발자와의 기술 논의, PM과의 요구사항 분석이 LLM과의 대화와 유사하다는 것을 아마 느꼈을 것이다. 기술팀의 리더 경험이 있다면 팀원과의 대화가 LLM과의 대화와 유사하다는 것을 아마 느꼈을 것이다. 경험상 기술팀의 대화에서 가장 중요한 것은 언제나 복잡한 요구사항, 인간의 마음, 정치적 관계, 미묘한 우선순위였다. 프로그래밍이란 이런 현실을 직관으로 파악하는 것과, 파악된 것을 표현하는 과정으로서의 모델링이었다. 어쨌거나 이것도 결과적으로 추상화 된 것 아니냐고 할 수도 있을 것 같다. 하지만 이 추상화는 LLM 이후가 아니라 프로그래밍이 탄생한 순간부터 존재했던 추상화다. 대표가 기술 프로젝트를 지시하는 것, PM이 업무를 분배하는 것, CTO가 기술 가이드를 주는 것, 옆자리 동료와 기술 대화를 나누는 것 전부 자연어로 된 추상화다. 이걸 '추상화'라고 부르는 것도 어색하지만, 억지로 그렇게 부르더라도 이제와 LLM과 연관 짓는건 역시나 어색하다. (외부로부터 지시를 받고 코드를 작성하는 역할에 집중하던 개발자가, 전적으로 일을 시킬 수 있는 팀원을 처음 가져봤다면 이 차이가 크게 느껴졌을 수 있을지도 모르겠다) '그러니까 코드를 읽지 않아도 된다'는 말에 일부 동의하지 않는 것도 이런 이유다. 방금 말한 기존부터 있었던 모든 '자연어 추상화'들 중 대표와 PM을 제외하면 코드를 전혀 읽지 않아도 되는 경우는 없다. 우리는 언제나 자연어로 대화했지만 서로의 코드를 읽었다. 심지어는 나보다 훨씬 실력이 좋은 개발자의 코드도 열심히 읽었다. 오늘날의 LLM이 나보다 코드를 더 잘 작성한다고 해도 읽어야 하는 상황에서는 읽어야 한다. (모든 코드를 읽어야 한다는 말은 아니다. 그럼 어떤 코드를 읽어야 할까? 담에 정리해보면 좋을 듯) 반대로 말하면 내가 어떤 프로젝트에서 대표 혹은 PM의 역할이라면 코드를 읽지 않아도 된다는 말이기도 하다. 나도 혼자 사이드 프로젝트를 할 때는 LLM이 작성한 코드를 거의 읽지 않는다. 왜냐하면 그 때의 나는 대표 혹은 PM이기 때문이다. 대신 현실의 유저에게 집중한다. 하지만 이런 경우에도 결국 책임을 지는 사람은 필요하다는 것을 생각해야 한다. 나혼자 쓰는 도구를 만드는게 아니라면.