코드 추상화는 결국 코드를 묶는 방식만 다르다

코드를 직접 작성하던 시절, 나는 “정적 클래스는 폴더일 뿐이다”, “마이크로서비스는 함수일 뿐이다”, “충분히 멀리서 보면 모든 것은 모놀리스다” 같은 말을 종종 했다. 지금도 그 생각을 굽히지 않는다. 그런 말에는 일리가 있다.

마이크로서비스와 클래스를 비교해 보자.

• 둘 다 코드를 캡슐화한다.
• 둘 다 공개 API를 가진다.
• 둘 다 상태를 보유한다.
• 둘 다 수명 주기가 있다.

실제로 다른 점은 무엇일까?

• 마이크로서비스는 코드베이스의 나머지 부분과 독립적으로 배포할 수 있다.
• 마이크로서비스는 코드 단위 사이에 더 강한 경계를 둔다.

차이는 대체로 이 정도라고 생각한다. 나머지는 대부분 관점과 규모의 문제다. 예를 들어 클래스 핫 리로드를 지원하는 프로그램이 있다면, 기능적으로 마이크로서비스를 배포하는 것과 비슷하지 않을까?

마이크로서비스는 더 큰 격리와 장애 허용성을 제공한다. 같은 코드베이스에서 많은 사람이 일하는 조직에는 이 점이 더 나을 수 있다. 하지만 AI와 함께라면 코드 구성과 배포에 관한 여러 전제를 다시 생각해야 한다고 본다. 빠르게 움직일 수 있다는 점에서 핫 리로드가 더 나은 경우도 있지 않을까?

요즘 바이브 코딩을 하다가 코드베이스가 나빠지고 같은 오류가 곳곳에서 반복되기 시작하면, 리팩터링이 필요하다는 신호로 받아들인다. 그럴 때는 “이런 일이 벌어지는 것 같으니 문제를 해결하려면 이 코드 조각들을 한곳에 모아야 한다”고 말한 다음, “이 다섯 가지는 사실 같은 것이다”라고 설명한다. 대개 그렇게 하면 문제가 해결된다.

AI가 찾아낸 추상화가 함수인지, 클래스인지, 폴더인지는 별로 중요하지 않다. 결국 다 같은 것이기 때문이다. 중요한 것은 서로 관련된 코드를 한곳에 모으는 일이다.

이 사이트에 처음 올린 글 가운데 하나는 어떤 코드베이스든 구성하는 방법에 관한 글이었다. 이제는 내가 구성하는 코드를 직접 작성하지 않으니, 모든 추상화가 같다는 점이 점점 더 분명해진다.

• 코드가 있다.
• 코드를 단위로 묶는 방법이 있다.
• 코드 단위 사이에 의존성 그래프가 있다.

바이브 코더로서 내가 할 일은 다음과 같다.

• 관련 코드를 한곳에 모은다.
• 비슷한 부작용을 한곳에 모은다.
• 의존성 그래프가 순환하지 않고 가능한 한 트리 형태를 이루도록 한다.
• 코드베이스를 가능한 한 선언적으로 만든다(무엇이든 눈을 가늘게 뜨고 보면 인터프리터다).

이것은 모든 소프트웨어에 해당한다. 나머지, 이제 AI가 맡는 일은 모두 기계적인 작업일 뿐이다. 프로그래밍 언어는 다 같다. 가상 클래스와 믹스인, 폴더와 모듈도 다 같다. while과 for, switch와 if도 모두 같다.