코드를 다 이해할 수 없을 때, 좋은 추상화가 맡아야 할 책임

TL;DR

• 코딩 에이전트가 코드를 빠르게 늘리면 사람이 만든 시스템을 충분히 이해하지 못하는 격차가 커진다. James Cowling은 여기에 구현 세부를 살필 의사까지 줄어드는 관심 격차가 더해진다고 본다. 해법은 모든 코드를 다시 손으로 쓰기보다 신뢰할 수 있는 인터페이스와 책임의 경계를 설계하는 데 있다.
• 좋은 추상화는 사용자가 기억해야 할 세부와 변경의 파급 범위를 줄인다. 단순하고 쓰기 쉬우며 사용법이 드러나고 다른 부분과 조합할 수 있어야 한다. 내부를 몰라도 쓸 수 있다는 것과 어떤 결과를 보장하는지도 모른다는 것은 다르다.
• 플랫폼의 가치는 코드 제공에 그치지 않고 특정 문제와 운영 부담을 맡는 데서 나온다. 직접 대규모 스토리지를 만든 경험이 있는 Cowling도 Convex에서는 S3를 사용한다. 차별화되지 않는 영역의 책임을 전문 공급자에게 맡겨 제품에 집중한다는 설명이다.
• 에이전트도 필요한 문맥이 적고 잘못된 상태를 표현하기 어려운 인터페이스에서 이익을 얻을 수 있다. 트랜잭션은 동시성 문제를 제한된 계약 안에서 다루는 대표 사례다. 다만 모든 트랜잭션이 같은 격리 보장을 제공하거나 모든 오류를 없애는 것은 아니다.
• 엔지니어에게는 시스템의 가능성과 한계를 아는 전문성, 사용자의 문제를 이해하는 설계 감각이 함께 필요하다. 팀의 모든 줄을 관리할 수 없게 된 테크 리드처럼 신뢰를 판단할 구조를 만들어야 한다. 발표는 설계 논증과 경험담이며 에이전트 성능 향상을 계량한 벤치마크는 아니다.

코드 생산보다 이해가 느려지는 상황

Convex 공동창업자이자 CTO인 James Cowling은 Abstract의 첫 컨퍼런스를 에이전트 개발에 반대하는 행사로 규정하지 않는다. 오히려 코드 생성이 흔해질수록 소프트웨어를 설계하는 판단과 결과에 대한 책임이 차이를 만든다는 출발점을 잡는다. 디자이너나 PM의 명세를 받아 에이전트에 전달하는 역할만으로는 엔지니어링의 기여를 설명하기 어렵다는 비판도 이 맥락에 있다. 발표의 대상은 코드를 많이 만드는 방법보다 만들어진 시스템을 관리하는 방법이다.

Cowling은 에이전트가 생산하는 코드가 사람의 이해를 앞지르는 현상을 이해 격차라고 부른다. 코드를 읽더라도 직접 설계하고 작성했을 때만큼의 맥락을 갖기 어려우며 생성량이 늘면 그 차이가 더 커진다는 관찰이다. 그렇다고 내년부터 모두 손으로 코드를 쓰던 방식으로 돌아갈 것이라고 기대하지 않는다. 내부의 모든 구현을 알지 못한 채 시스템을 사용하고 변경해야 하는 조건을 설계의 전제로 받아들인다.

좋은 추상화는 기억할 것과 영향을 줄인다

발표는 과거의 소프트웨어 위기를 인간이 구성 요소와 상호작용을 모두 머릿속에 넣기 어려워진 문제로 설명한다. 추상화는 복잡한 구현에서 사용에 필요한 인터페이스를 분리해 그 부담을 줄였다. 파일 저장을 요청할 때 모든 디스크의 동작을 생각하지 않는 것처럼 사용자는 제한된 계약을 다룬다. 내부를 계속 들여다봐야만 사용할 수 있다면 복잡성이 인터페이스를 넘어 새어 나온다.

좋은 추상화의 조건으로는 단순함과 사용 용이성, 건전성, 사용법을 드러내는 형태, 조합 가능성이 강조된다. 특히 한 부분의 변경이 다른 모든 부분의 수정으로 번지는 결합을 줄이는 일이 중요하다. 요금제 하나를 추가하려는데 사용자 표현과 시스템 곳곳을 바꿔야 하는 청구 시스템은 그 반대 사례다. 추상화의 성과는 계층이 많아지는 데 있지 않고 사용자가 한 번에 알아야 할 맥락과 변경의 파급 범위가 작아지는 데 있다.

이해 부족에 관심 부족까지 더해진다

Cowling이 더 강한 문제로 보는 것은 관심 격차다. 발표에서 그는 ClawHub의 인기로 Convex의 데이터베이스 부하가 갑자기 커졌던 경험을 회고한다. 불필요한 클라이언트 갱신을 줄이도록 쿼리를 바꾸자고 제안했지만 상대 개발자가 자신은 그 코드를 읽거나 쓰지 않았으니 바꾸려면 직접 PR을 올려 달라는 취지로 답했다는 사례다. 이는 발표자의 경험담이며 이 노트에서 별도 사고 기록이나 당사자 설명을 확인한 것은 아니다.

그가 끌어낸 결론은 고객을 더 열심히 가르치는 데만 의존하지 말고 세부를 이해하지 않아도 사용할 수 있게 설계하자는 쪽이다. 전등을 켜는 사람이 발전과 송전의 모든 원리를 알아야 하는 것은 아니듯 이해의 위임 자체는 발전을 가능하게 한다. 달라진 점은 이제 자신이 생산한 코드의 내부도 이해하지 못할 수 있다는 데 있다. 이때는 무엇을 맡겼고 어떤 동작을 믿을 수 있는지 분명한 계약이 필요하다. 무관심을 정당화하는 구호로는 부족하다.

공급자는 기능과 함께 문제를 맡는다

코드를 쉽게 생성할 수 있으니 데이터베이스와 플랫폼도 모두 직접 만들면 된다는 주장에 Cowling은 전문화된 공급망의 가치를 대조한다. 아이스크림 트럭 사업자가 타이어 고무의 배합까지 개발하지 않는 이유는 비용뿐 아니라 그 분야의 지식과 문제 해결을 전문 공급자에게 맡길 수 있기 때문이다. 소프트웨어 플랫폼도 여러 사용자가 반복해서 풀 문제를 한곳에 모아 개선한다. 구현을 생성하는 능력만으로 장기간의 운영 경험과 책임이 같은 수준에 도달하지는 않는다.

Cowling은 데이터베이스와 함께 고객이 특정 문제에 신경을 덜 써도 되는 기회를 판다고 설명한다. Dropbox에서 대규모 스토리지 이전을 이끌었지만 Convex의 저장소로는 S3를 사용한다고 밝힌다. 경험이 없어서 못 만드는 것과 만들 수 있어도 다른 공급자에게 맡기는 것은 다른 판단이다. 제품이 차별화되는 부분에 집중하려면 어느 문제를 직접 소유하고 어느 계약을 구매할지 결정해야 한다.

에이전트가 좁은 범위에서 추론하게 만든다

좋은 추상화는 사람뿐 아니라 에이전트가 한 번에 다뤄야 할 문맥도 줄인다는 것이 발표의 설계 논리다. 유효하지 않은 상태를 인터페이스에서 표현하기 어렵게 만들면 잘못된 경로가 줄고 에이전트는 제품의 차별화된 부분에 집중할 여지가 생긴다. 반대로 불필요한 계층과 서로 멀리 떨어진 코드 사이의 의존은 추론 부담을 키운다. 발표는 현재 에이전트의 API 설계와 단순화, 비지역적 추론의 약점을 지적하지만 그 개선 폭을 수치로 측정하지는 않는다.

트랜잭션은 동시에 일어나는 여러 변경을 다룰 때 활용할 수 있는 예다. 다만 실제 동작은 데이터베이스와 격리 수준에 달려 있다. 영상에서는 MySQL과 PostgreSQL을 언급하며 기본 격리 수준을 Repeatable Read로 설명하지만 공식 문서상 MySQL InnoDB의 기본값은 Repeatable Read이고 PostgreSQL은 Read Committed다. PostgreSQL의 SELECT FOR UPDATE 행 잠금도 일반 조회를 모두 차단하는 장치는 아니며 같은 행을 수정하거나 잠그려는 작업을 제어한다. 발표의 동시성 예시는 이런 차이를 생략한 설명이므로 사용 시 확인할 계약을 대신하지 않는다.

S3의 일관성 변화는 사용자 문제에 가까워지는 인터페이스의 사례로 등장한다. Cowling은 과거의 최종 일관성 때문에 저장 여부를 따로 추적해야 했던 경험과 지금의 더 직접적인 사용 방식을 대비한다. 현재 AWS 문서는 새 객체 쓰기와 덮어쓰기·삭제 이후의 읽기, 객체 목록 조회에 강한 일관성을 제공한다고 설명한다. 이 보장을 데이터베이스의 여러 행을 묶는 트랜잭션과 같은 것으로 볼 수는 없다. 단순한 API라도 무엇을 언제 관찰할 수 있는지 정확히 알아야 한다는 점은 남는다.

구현의 모양보다 사용자의 문제를 따른다

좋은 추상화를 만들려면 무엇이 가능한지 아는 시스템 전문성과 사용자가 무엇을 하려는지 이해하는 설계 감각을 함께 써야 한다. Cowling은 인터페이스의 형태가 내부 구현보다 해결하려는 문제를 따라야 한다고 강조한다. 내부 구조를 그대로 노출하고 사용자가 적응하도록 요구하면 기술적으로 멋진 시스템도 사용하기 어렵다. 컴퓨터 과학의 기초가 여전히 중요한 이유는 구현을 전부 손으로 작성하기 위해서만이 아니라 가능한 보장과 숨길 수 없는 제약을 판단하기 위해서다.

마지막에는 에이전트를 다루는 개발자를 테크 리드에 비유한다. 팀의 모든 코드를 세세하게 관리하다 인지 한계에 부딪혔을 때 손을 떼고 알아서 하도록 내버려 두는 것이 답은 아니다. 어떤 구성 요소를 신뢰할 수 있고 어떻게 사용하면 되는지 판단할 구조를 만드는 일이 필요하다. 더 빠르게 기존 코드를 생산하는 것에서 멈추지 않고 관리 가능한 구성 요소로 새로운 제품을 만들려면 이 책임이 남는다. 이해를 모두 소유할 수 없다는 현실과 결과에 책임져야 한다는 요구를 함께 다루는 것이 발표의 결론이다.

참고 자료

Convex — The End of Understanding: Why Good Abstractions Matter — 23분 영상의 영어 자동자막 전체와 한국어 자동자막을 대조했다. 자동자막의 고유명사·기술 용어 오류 가능성을 고려했으며 데이터베이스와 S3의 보장은 아래 공식 문서로 보완했다.

PostgreSQL — Transaction Isolation

PostgreSQL — Explicit Locking

MySQL 8.4 — InnoDB Transaction Isolation Levels

Amazon S3 — Strong Consistency