'A급 코드'를 원했던 진짜 이유 — 우리는 코드가 아니라 머릿속 공간을 지키고 있었다

오랫동안 나는 'A급 코드'를 좋은 개발자의 증표처럼 여겼다. 깔끔하게 조직되고, 이름이 잘 붙고, 책임이 또렷하게 나뉜 코드가 그것이다. 그런데 어느 순간 이런 질문이 떠올랐다. 우리는 왜 그토록 A급 코드를 원했을까? 코드 그 자체가 아름다워서였을까, 아니면 다른 이유가 있었을까?

답을 따라가다 보면 의외의 결론에 닿는다. 우리가 지키려던 것은 코드가 아니라 우리 머릿속의 공간이었다.

코드는 자산이 아니라 부채다

소프트웨어 공학의 오래된 명제 하나가 있다. "코드는 자산이 아니라 부채다(Code is a liability, not an asset)." 구글의 개발 문화를 정리한 책 Software Engineering at Google이 분명하게 못 박은 말이다. 가치를 주는 것은 코드가 제공하는 기능이지 코드 자체가 아니다. 같은 기능을 1만 줄의 뒤엉킨 코드로도, 1줄의 명료한 코드로도 만들 수 있다면 우리는 당연히 후자를 고른다. 코드는 적을수록 좋은, 들고 있으면 비용이 드는 짐에 가깝다.

그렇다면 한 가지가 이상해진다. 코드가 부채라면, 우리는 왜 그 부채를 '깔끔하게' 정리하는 데 그렇게 많은 시간을 쏟았을까? 부채는 줄이면 그만인데, 왜 줄이는 것을 넘어 '조직'하려 했을까?

한 번에 머릿속에 담을 수 있는 건 4~7개뿐

여기서 인간 인지의 한계를 짚어야 한다. 작업기억(working memory), 즉 우리가 어떤 작업을 하는 동안 머릿속에 동시에 붙들고 있을 수 있는 정보의 양은 놀랄 만큼 작다. 심리학에서 흔히 인용되는 수치로 한 번에 약 4~7개 항목이 한계다. 변수 몇 개, 호출 흐름 몇 갈래, 조건 분기 몇 개를 동시에 떠올리는 순간 우리 머리는 이미 포화 상태에 가까워진다.

코드를 고치려면 그 코드가 어떻게 동작하는지를 머릿속에 모델로 세워야 한다. 그런데 깊게 중첩된 반복문이나 배배 꼬인 분기를 읽다 보면, 머릿속 작업 공간이 코드 해독에 다 쓰여 정작 원래 하려던 작업조차 잊는다. 깔끔하게 조직된 코드, 일관된 패턴, 좋은 이름은 바로 이 인지부하(cognitive load, 어떤 일을 처리할 때 머리에 걸리는 부담)를 낮추는 장치였다. 다음에 무슨 일이 벌어질지 예측 가능하게 만들어, 한정된 작업기억 안에 코드를 욱여넣을 수 있게 도왔다.

다이어그램 설명. 이 그림은 'A급 코드' 요구가 어디서 출발했는지를 한 줄기로 보여준다. 출발점은 코드의 아름다움이 아니라 사람의 한계다. 한 번에 네댓 개밖에 못 담는 작업기억이 먼저 있고, 코드를 고치려면 그 동작을 머릿속 모델로 세워야 하며, 그 모델 세우기가 가능하려면 코드가 담기 쉬운 형태여야 했다. 결국 깔끔한 코드는 목적이 아니라 사람의 인지공간에 맞추기 위한 수단이었다. 놓치기 쉬운 함정은 이 인과를 거꾸로 읽는 것이다. '깔끔함'을 그 자체로 추구해야 할 가치로 떠받들면, 정작 그것이 무엇을 위한 도구였는지를 잊는다.

전제가 흔들린다 — AI는 코드를 머릿속에 담지 않는다

이 모든 논리에는 숨은 전제가 하나 있었다. 코드를 다루는 주체가 인간이라는 점이다. 작업기억의 한계도, 인지부하도, 전부 사람이 코드를 읽고 머릿속에 담아야 한다는 데서 나왔다.

그런데 코드를 생성하고 수정하는 주체가 더 이상 사람만이 아니게 됐다. 큰 언어모델(LLM, 방대한 텍스트로 학습해 사람 말과 코드를 생성하는 AI)은 수천 줄을 한 번에 읽고, 고치고, 다시 쓴다. 작업기억 4~7개라는 제약이 AI에게는 적용되지 않는다. 그러니 'AI가 다루기 좋은 코드'의 조건은 '사람이 머릿속에 담기 좋은 코드'의 조건과 같지 않을 수 있다.

2025년 초 안드레이 카파시는 이런 흐름을 바이브 코딩(vibe coding)이라 이름 붙였다. 코드가 존재한다는 사실조차 잊고 AI가 만들어 내는 결과의 '느낌'에 몸을 맡기는 방식이다. 도발적인 표현이지만, 핵심 질문은 진지하다. 사람이 코드를 한 줄 한 줄 머릿속에 담지 않아도 된다면, 그 코드는 꼭 '최적'이거나 'A급'이어야 할까?

검증이 생산보다 싸다 — 검증 비대칭

이 질문에 단서를 주는 개념이 검증 비대칭(asymmetry of verification)이다. 오픈AI의 제이슨 웨이가 'verifier's law'로 정리한 생각으로, 요지는 단순하다. 어떤 답을 만들어 내는 것보다 그 답이 맞는지 확인하는 쪽이 대개 훨씬 싸다. 스도쿠를 푸는 것은 어렵지만 다 푼 스도쿠가 맞는지 채점하는 것은 쉽다. 계산 이론의 P 대 NP 문제가 일상에서 드러나는 얼굴이기도 하다.

여기서 실용적인 결론이 따라 나온다. 검증이 값싸고 믿을 만하게 된다면, 우리는 AI에게 자유롭게 답을 만들게 하고 검증으로 걸러내면 된다. 좋은 검증기를 갖추면 모델을 마음껏 생성하게 풀어 놓고 통과한 것만 취하는 방식으로 품질을 배수로 끌어올릴 수 있다. 리스트를 정렬해 달라고 할 때 우리는 정렬 알고리즘을 명세하지 않는다. 그저 결과가 정렬됐는지 확인할 수 있다는 사실을 믿고 맡긴다.

내 자산을 굴리는 시스템을 믿는 방식

비유를 하나 들겠다. 내 자산을 굴리는 퀀트 트레이딩(quant trading, 수학 모델과 자동화된 규칙으로 매매하는 방식) 시스템이 있다고 하자. 나는 그 시스템의 코드를 한 줄도 직접 보지 않을 수 있다. 대신 수백 개의 검증 테스트를 둔다. 손절 규칙이 작동하는가, 포지션 한도를 넘지 않는가, 과거 데이터에서 손실이 한계 안에 머무는가, 동일 주문이 중복 체결되지 않는가? 이 검증을 전부 통과하면 나는 그 시스템에 돈을 맡긴다.

이때 내가 관리하는 것은 코드가 아니다. 나는 검증을 관리한다. 시스템 내부가 우아하게 짜였는지, 함수 이름이 예쁜지는 내 관심사가 아니다. 내가 정한 촘촘한 검증을 통과해 결과를 담보하느냐가 전부다. 과정이 'A급'이 아니어도, 결과가 내가 세운 기준을 만족하면 그걸로 충분하다.

▲ 예전 방식 — 코드 품질을 관리한다

다이어그램 설명. 이 그림은 관리의 무게중심이 코드에 놓였던 시절을 보여준다. 개발자가 코드를 직접 읽고, 그 동작을 머릿속에 모델로 세우고, 그 모델 위에서 손으로 고친다. 모든 단계가 사람의 머리를 거치므로, 코드가 머릿속에 잘 담겨야 한다는 요구가 사슬 전체를 지배한다. 'A급 코드'에 대한 집착은 바로 이 구조의 자연스러운 결과였다.

▲ 바뀐 방식 — 검증 품질을 관리한다

다이어그램 설명. 이 그림은 관리의 무게중심이 검증으로 옮겨간 구조를 보여준다. 개발자는 코드를 직접 읽는 대신 무엇을 통과해야 하는지를 설계하고, 코드 생성은 AI에게 맡기며, 통과 여부로 결과를 판단해 담보한다. 앞 그림과 비교하면 사람의 머릿속에 코드를 담는 단계가 통째로 빠진 점이 핵심이다. 그래서 코드가 사람의 작업기억에 맞춰 깔끔할 필요가 상대적으로 줄어든다. 다만 한 가지를 오해하면 안 된다. '코드를 안 본다'가 '아무것도 관리하지 않는다'는 뜻이 아니라, 관리 대상이 검증으로 자리를 옮겼다는 뜻이다.

그래서 결론 — 단, 정직하게

여기까지의 논리를 한 줄로 줄이면 이렇다. 검증을 잘 통과하고 결과를 담보한다면, 그 과정이 반드시 '최적'이거나 'A급'일 필요는 없다. 우리가 A급 코드를 원했던 진짜 이유가 인간의 인지공간에 코드를 맞추기 위해서였다면, 그 인지공간을 거치지 않는 경로가 생긴 이상 요구 조건도 달라지는 게 자연스럽다.

다만 도발적인 결론일수록 단서를 정직하게 달아야 한다. 이 논리는 검증이 충분히 촘촘할 때만 성립한다. 카파시 자신도 경고했듯, 모델은 우리 대신 잘못된 가정을 세우고 그것을 확인 없이 밀고 나간다. 검증이 빈약하면 통과한 결과가 사실은 틀렸다는 사실을 우리는 끝내 모른다. 그러니 자유롭게 생성하게 두는 만큼, 무엇이 '결과를 담보한다'는 뜻인지를 정의하는 책임은 오히려 더 무거워진다. 부담이 사라진 게 아니라 코드 품질에서 검증 품질로 자리를 옮겼을 뿐이다.

개인 개발자가 가져갈 것

나 같은 개인 개발자에게 이 전환은 시간 배분의 문제로 다가온다. 예전에는 머릿속에 담길 만큼 깔끔한 코드를 만드는 데 많은 시간을 썼다. 이제는 질문을 바꾼다. 이 부분을 내가 직접 읽고 이해해야만 하는가, 아니면 결과를 담보하는 검증을 세우는 편이 더 나은가? 핵심 도메인 로직처럼 내가 끝까지 책임져야 하는 곳은 여전히 머릿속에 담는다. 반대로 검증으로 결과를 충분히 가둘 수 있는 곳은, 과정의 우아함에 집착하기보다 검증을 두텁게 하는 쪽으로 시간을 옮긴다.

'A급 코드'는 여전히 좋다. 다만 그것이 목적이 아니라 사람의 한계를 메우던 도구였음을 기억할 때, 우리는 비로소 어디에 그 도구를 계속 쓰고 어디서 다른 도구로 갈아탈지를 분별할 수 있다.

---

참고한 공개 자료:

• Code is a liability (not an asset) — Hacker News 토론: https://news.ycombinator.com/item?id=46519727
• "Code is a liability, not an asset" 정리 글: https://somehowmanage.com/2020/10/17/code-is-a-liability-not-an-asset/
• Jason Wei, "Asymmetry of verification and verifier's law": https://www.jasonwei.net/blog/asymmetry-of-verification-and-verifiers-law
• Vibe coding — Wikipedia: https://en.wikipedia.org/wiki/Vibe_coding
• The Limits of Human Cognitive Capacities in Programming (작업기억과 코드 가독성): https://florian-kraemer.net/software-architecture/2024/07/25/The-Limits-of-Human-Cognitive-Capacities-in-Programming.html

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.