2025.12.12 2025년의 클린코드

'LLM이 생성한 코드의 퀄리티가 좋지 않다, 고로 바이브코딩은 안된다'라는 주장은 약간 어폐가 있다고 생각하는데, 코드 퀄리티라는 것 역시 맥락과 일하는 방식에 따라 기준이 달라지기 때문이다. 예를 들어 기계어 단위까지 들락날락하며 빡세게 최적화를 해야 하는 맥락, 저 옛날 공룡이 살던 시절에 Win32 API를 다루는 맥락, 현대의 웹을 다루는 맥락 모두 클린코드/클린아키텍쳐의 기준이 조금씩 다르지 않은가.

중생대시절 Win32를 이야기한 이유가 뭐냐 하면, 과거에는 정적분석이 지금처럼 발전하지 않았고 실시간으로 하려고 해도 몹시 느렸기 때문에 Hungarian Notation같은걸 써서 바로 타입을 알아챌 수 있게 하는게 코드의 덕목이었던 것이다.

당연히 지금 그걸 하는건 바보같은 짓인데, 그렇다는건 좋은 코드의 기준 역시 그 시대의 툴링과 환경에 의존적일 수밖에 없다는 것. 그렇기 때문에 인간이 전부 짜고 린터 등이 도와주는 시대의 클린코드/아키텍쳐와 바이브코딩에 맞는 클린코드/아키텍쳐도 당연히 다를수밖에 없다.

그래서 나는 '지속가능한(=엔터프라이즈 레벨의 아주 거대하고 복잡한 구조, 그러면서도 변화무쌍한 요구사항에 개발속도 저하 없이 대응) 바이브코딩을 위한 클린코드/클린아키텍쳐의 기준은 무엇인가' 와 '그 기준에 맞는 클린코드/클린아키텍쳐로 향할 수 있는 바이브코딩의 방법론은 무엇인가'를 고민하는 게 더 건설적이라고 생각한다.