우선 제목이 반말(!)이라 죄송합니다. 블로그 포스트 톤으로 쓰다보니 굳이 높임말로 바꾸기 보다는 그대로 두는게 나은 선택인 듯하여 그대로 두었습니다. 요즘 먹고사니즘으로 바쁘다 보니 잡생각 할 시간도 잘 없어서 뜸했는데 오랜만에 긱뉴스에서 좋은 글을 봐서 생각을 조금 정리해 보았습니다. 😁

오늘 GeekNews에서 「이해 가능한 소프트웨어를 향하여」라는 글을 봤습니다. 원문은 Anna Liberty의 Towards Understandable Software입니다.

사실 GeekNews에서의 요약본도 충분하다고 생각하지만 그래도 원문을 보고 왔습니다. 원문의 출발점은 단순합니다. 프로그래밍은 괴롭고, 코드는 읽기 어렵고, 유지보수하기 어렵고, 어떤 프로젝트든 그것을 제대로 이해하는 사람은 소수라는 것. 그리고 사람들이 LLM에 몰리는 이유도 LLM이 훌륭해서가 아니라 프로그래밍이 그만큼 괴롭기 때문이라는 진단입니다. 라이브러리를 풀로 붙이고, 끝없는 보일러플레이트를 쓰고, 충돌하는 스택을 맞추는 일. 그 고통이 사람들을 LLM으로 밀어냈다는 겁니다.

여기서 원문이 내리는 결론과, 제가 인디개발자로써 이른바 에이전틱 코딩을 꽤 오랫동안 해보면서 생각한 것이 조금 달라서 정리해 봅니다.

LLM은 추상화가 아니라 자동화에 가깝다

원문에서 가장 또렷한 통찰은 LLM을 추상화 계층으로 보지 않는다는 점입니다.

LLM은 사람이 하던 코드 작성을 대신해줍니다. 자연어로 말하면 코드가 나오고, 에러를 붙여 넣으면 수정안이 나오고, 요구사항을 적으면 테스트까지 만들어줍니다. 그래서 높은 수준의 추상화처럼 보입니다. 하지만 엄밀히 말하면 이건 추상화라기보다 자동화에 가깝습니다.

추상화는 낮은 수준의 복잡성을 감추고, 예측 가능한 방식으로 더 높은 수준의 조작을 가능하게 해야 합니다. SQL을 쓰면 파일 오프셋을 직접 계산하지 않아도 되고, React를 쓰면 DOM 조작을 매번 직접 하지 않아도 됩니다. 추상화도 새 복잡성을 만들지만, 적어도 같은 입력과 같은 규칙에 대해 예측 가능한 층위를 제공합니다.

LLM은 다릅니다. LLM은 확률적으로 의도를 해석하고 그럴듯한 결과를 생성합니다. 같은 지시를 해도 세부 구현은 흔들리고, 문맥에 따라 결과가 달라지고, 때로는 없는 사실을 만들어냅니다. 원문의 표현을 빌리면, LLM이 추상화 계층이라면 손실이 매우 심한 계층입니다.

그래서 LLM은 결정론적 추상화 계층이라기보다, 코드 작성이라는 노동을 자동화하는 계층에 가깝습니다. 이 구분은 정확하고, 저도 동의합니다. 자동화는 같은 일을 더 빨리 하게 만들고, 추상화는 그 일을 덜 하게 만듭니다.

여기서 원문과 제 생각이 갈립니다.

Anna Liberty는 LLM을 더 잘 쓰자고 말하지 않습니다. 오히려 LLM을 걷어내자고 말합니다. 원문은 LLM이 환경적으로 파괴적이고, 학습 데이터의 출처가 떳떳하지 않으며, 결과가 일관되지 않고, 사용자에게 의존성을 심는다고 봅니다. 그래서 자동화의 이득을 포기하지 않으면서도 LLM은 버릴 수 있다고 주장합니다. 자동화를 포기하려고 LLM을 버리는 게 아니라, LLM 없이도 자동화와 높은 추상화를 가질 수 있다는 쪽입니다.(많은 오래된 개발자들이나 코더들이 비관적으로 혹은 비판적으로 내어 놓는 목소리와 비슷합니다)

원문이 내놓는 대안은 코드 자체를 걷어내는 방향입니다. 문서를 먼저 쓰고 코드를 거기에 매다는 문해적 프로그래밍(literate programming), 코드 대신 시각적으로 조작하는 GUI 프로그래밍, 그리고 트랜스포머의 생성 능력 없이 문법에서 의미만 파싱하는 결정론적 자연어 처리. 요지는 LLM을 잘 길들이자는 게 아니라, LLM을 대체할 진짜 추상화 계층을 새로 만들자는 것입니다. 원문 제목의 "이해 가능한"은 산출물이 다른 사람에게 읽히기 쉬워야 한다는 뜻에 가깝습니다만

저는 거기까지는 가지 않겠습니다.

LLM을 루프에서 빼는 대신, 루프 안에 두되 길들이는 쪽을 택했습니다. 이유는 단순합니다. 문해적 프로그래밍도, 결정론적 자연어 컴파일러도 아직 대부분의 실무 환경에 없습니다. 원문이 그리는 세계는 매력적이지만 아직 도착하지 않았고, 그 사이에도 코드는 짜여야 합니다. 그래서 저는 지금 손에 있는 도구(!)로 무엇을 할지를 더 본격적으로 묻습니다.

이 차이를 굳이 적어두는 이유는, 원문을 제 결론의 근거처럼 쓰고 싶지 않아서 입니다. 제가 원문에서 빌려온 건 "LLM은 추상화가 아니라 자동화"라는 진단 한 줄이고, 처방은 서로 다릅니다. 원문은 LLM을 대체하자고 하고, 저는 LLM을 좋은 도구로서의 구조를 만들자고 합니다. 그리고 이 글에서 말하는 "이해"는 원문과 달리, 산출물의 성질이 아니라 개발자가 갖춰야 할 능력 쪽을 제 정의 해보는 것입니다.

코드를 모르는 개발자의 시대는 아니다

AI 코딩 도구가 좋아지면서 자주 나오는 말이 있습니다. 이제 개발자는 코드를 몰라도 되는 것 아니냐는 말입니다. 반은 맞고 반은 틀립니다.

코드를 전혀 몰라도 된다는 뜻은 아닙니다. 그런 시대가 오려면 아직 멀었고, 어쩌면 오지 않을 수도 있습니다. 결국 실행되는 건 코드이고, 장애가 나면 코드를 봐야 하고, 보안 문제가 생기면 코드를 봐야 합니다. LLM이 만든 코드도 책임까지 대신 져주지는 않습니다.

다만 모든 개발자가 모든 코드를 직접 읽고, 모든 구현을 손으로 따라가며, 모든 세부를 머릿속에 넣어야 하는 시대는 조금씩 저물고 있습니다. 중심이 바뀌고 있습니다.

예전에는 코드 라인 단위의 이해를 더 많이 요구 받았습니다. 이 함수가 어떤 인자를 받고, 어느 객체를 수정하고, 어떤 라이브러리를 호출하는지 직접 따라가야 했습니다. 지금도 그 능력은 필요합니다. 하지만 앞으로 더 중요한 건 코드 자체보다 코드가 놓인 구조입니다.

이 모듈의 책임은 무엇인가. 이 데이터는 어디에서 생기고 어디까지 흘러가는가. 이 기능은 도메인에서 어떤 의미를 갖는가. 실패하면 어떤 상태가 남는가. 테스트는 무엇을 보장하고 무엇을 보장하지 않는가. LLM이 만든 결과를 어떤 기준으로 채택하거나 폐기할 것인가.

이런 걸 이해하지 못하면 코드를 읽을 수 있어도 소프트웨어를 이해한 건 아닙니다. 반대로 이 구조를 이해하고 있으면, 모든 코드를 직접 읽지 않아도 작업을 이끌 수 있습니다. LLM에게 작업을 나눠주고, 결과를 검증하고, 잘못된 방향을 되돌릴 수 있습니다. 개발자는 코드를 덜 읽게 될 수 있습니다. 하지만 그만큼 더 큰 것을 이해해야 합니다.

지시가 명확하면 방향은 수렴한다

그렇다고 LLM을 못 믿을 도구로만 볼 필요는 없습니다. LLM은 결정론적이지 않지만, 완전히 무작위 도구도 아닙니다. 지시가 명확하면 결과는 꽤 좁은 방향으로 수렴합니다.

예를 들어 이렇게 말하면 결과는 매번 다릅니다. 제대로 안 나올 수도 있구요.

인증 기능 만들어줘.

이 요청은 너무 광범위합니다. 마치 홈페이지 만들어줘 처럼요. 세션을 쓸 수도, JWT를 쓸 수도, OAuth를 붙일 수도, DB 스키마를 바꿀 수도, 임의의 라이브러리를 추가할 수도 있습니다.

하지만 이렇게 말하면 결과가 달라집니다.

FastAPI에서 JWT access token 검증 미들웨어를 만들어줘. 입력은 Authorization: Bearer 헤더이고, 실패 시 401 JSON을 반환해. 기존 UserRepository.find_by_id()를 사용하고, DB 스키마는 건드리지 마. 테스트는 만료 토큰, 잘못된 서명, 정상 토큰 3개를 추가해.

이 경우에도 LLM은 컴파일러처럼 동작하지 않습니다. 하지만 결과는 크게 좁아집니다. 중요한 건 자연어를 완전히 결정론적인 프로그래밍 언어로 만드는 게 아니라, LLM이 흔들려도 결과가 한 방향으로 수렴하도록 제약을 주는 것입니다. 입력 조건을 명확히 하고, 수정 범위를 제한하고, 실패 조건을 정의하고, 테스트를 붙이고, 결과를 검증하는 루프를 밖에 두는 것. 이게 LLM 시대 개발자가 해야 할 일에 가깝습니다.

보일러플레이트를 쓰게 하지 말고, 만드는 도구를 만들게 하라

LLM으로 개발하는 사람은 자주 반복 작업을 LLM에게 시킵니다. API 라우트 만들어줘, DTO 만들어줘, 테스트 만들어줘, 문서 업데이트해줘, 비슷한 컴포넌트 하나 더 만들어줘.

처음에는 편합니다. 하지만 쉽게 한계에 부딪힙니다. 매번 LLM에게 같은 보일러플레이트를 쓰게 하면 출력이 조금씩 달라집니다. 코드 스타일이 흔들리고, 예외 처리가 달라지고, 파일 구조가 어긋나고, 리뷰 비용이 반복되고, 컨텍스트도 계속 낭비됩니다. 제 생각에 이건 낮은 단계의 자동화입니다.

더 나은 방향은 LLM에게 보일러플레이트를 계속 쓰게 하는 게 아니라, 보일러플레이트를 만들어내는 스크립트를 짜게 하는 것입니다. CRUD가 반복된다면 매번 CRUD 코드를 쓰게 할 게 아니라 프로젝트 규칙에 맞는 생성기를 만들게 하고, DTO 변환이 반복된다면 스키마 기반 mapper 생성기를 만들게 하고, 테스트 fixture가 반복된다면 scaffold 명령어를 만들고, 문서 업데이트가 반복된다면 코드나 스키마에서 문서를 추출·동기화하는 스크립트를 만드는 식입니다.

LLM을 코드 작성 노동자로 쓰는 게 아니라, 반복을 제거하는 도구 제작 보조자로 쓰는 겁니다. 흥미로운 건 이 방향이 원문의 "한 층을 자동화하고 싶을 때는 그 층을 추상화로 걷어내라"와 닮았다는 점입니다. 다만 저는 그 추상화를 LLM의 도움으로 만들고, 원문은 LLM 없이 만들자고 합니다. 꽤 중요한 사실인데 도착지가 비슷해도 경로가 다릅니다. 비결정론적인 LLM 사용에선 결과도 과정도 모두 중요합니다.

반복 작업은 LLM 밖으로 빼야 한다

LLM은 강력하지만 비쌉니다. 여기서 비용은 돈만이 아닙니다. 컨텍스트 비용, 검증 비용, 재현성 비용, 리뷰 비용이 모두 포함됩니다.

같은 일을 매번 LLM에게 시키면 매번 설명해야 하고, 매번 조금씩 다른 결과가 나오고, 매번 확인해야 하고, 실수도 반복됩니다. 반대로 한 번 생성기를 만들고 검증하면 그 다음부터는 해당 생성기 자체는 결정론적인 도구가 됩니다. 같은 입력을 넣으면 같은 구조의 코드가 나오고, 팀 컨벤션도 템플릿 안에 고정되고, 긴 설명을 반복하지 않아도 됩니다.

이게 하네스가 필요한 이유이기도 합니다. 하네스는 LLM을 더 화려하게 포장하는 장치가 아닙니다. LLM이 매번 흔들리지 않도록 바깥에서 구조를 잡는 장치입니다. 무엇을 읽을지, 무엇을 수정할지, 어떤 테스트를 돌릴지, 어떤 결과를 채택할지, 실패하면 어디로 되돌아갈지 정하는 외부 구조입니다.

그래서 하네스가 많다고 좋은 게 아닙니다. 스킬이 많고, 에이전트가 많고, 훅이 많고, 문서가 많다고 좋은 것도 아닙니다. 좋은 하네스는 반복되는 판단과 작업을 줄이고, 나쁜 하네스는 새로운 절차와 설명을 늘립니다.

카파시의 Software 2.0과 vibe coding

Andrej Karpathy는 2017년 Software 2.0에서 신경망이 소프트웨어를 만드는 방식 자체를 바꾸고 있다고 설명했습니다. 사람이 직접 작성하는 코드가 Software 1.0이라면, 학습된 신경망의 가중치가 Software 2.0이라는 관점입니다.

이후 LLM 코딩 도구가 등장하면서 그는 2025년에 "vibe coding"이라는 표현을 썼습니다. 다만 원래 정의를 정확히 보는 게 좋습니다. 카파시의 vibe coding은 코드가 존재한다는 사실조차 잊고 흐름에 완전히 몸을 맡기는 방식입니다. diff를 더 이상 읽지 않고, 에러 메시지는 그냥 복붙해 넣고, 버려도 되는 주말 프로젝트에 쓰는 가벼운 방식이라고 본인이 못 박았습니다. 즉 원래 vibe coding은 이해를 끌어올리는 쪽이 아니라, 이해를 내려놓는 쪽입니다. 지금은 밈처럼 쓰이지만, 무책임하게 코드를 안 봐도 된다는 뜻으로 읽으면 오히려 원 정의에 더 가깝습니다.

제가 얘기하고 싶은 건 카파시의 정의 그 자체가 아니라, 그 표현을 뒤집어 읽었을 때 남는 것입니다. AI가 코드를 더 많이 쓰게 될수록, 사람에게 남는 역할은 타이핑이 아니라 취향, 판단, 감독에 가까워진다는 것. 이건 카파시가 vibe coding이라는 말로 한 주장이 아니라, 그 말을 실무를 통해 저만의 해석을 한 것입니다. LLM에게 초안을 쓰게 하고, 코드를 만들게 하고, 테스트를 제안하게 하고, 반례를 찾게 할 수는 있습니다. 하지만 그 결과가 맞는지 판단하는 사람은 여전히 필요합니다.

개발자는 어디에 있어야 하나

LLM 시대의 개발자는 코드를 덜 치게 될 수 있습니다. 하지만 일이 줄어드는 건 아니고, 일의 위치가 바뀝니다.

개발자는 도메인을 이해해야 합니다. 사용자가 실제로 무엇을 하려는 지, 어떤 제약이 있는지, 어떤 상태가 위험한지, 어떤 예외가 중요한지 알아야 합니다.

개발자는 구조를 이해해야 합니다. 경계가 어디인지, 모듈이 왜 나뉘는지, 데이터가 어떻게 흐르는지, 어느 부분이 바뀌기 쉬운지 알아야 합니다.

개발자는 검증을 이해해야 합니다. 테스트가 무엇을 보장하는지, 로그가 무엇을 말하는지, 실패가 어떤 상태를 남기는지 알아야 합니다.

그리고 개발자는 자동화와 추상화를 구분해야 합니다. 반복 작업을 LLM에게 계속 맡기는 게 나은지, 아니면 그 반복을 없애는 도구를 만들어야 하는지 판단해야 합니다.

이 역할은 코더보다 조금 위에 있습니다. 아키텍트라는 말은 조금 과할 것 같고, 오히려 운영자에 가깝습니다. LLM과 코드와 도구와 문서와 테스트가 함께 돌아가는 작업장을 운전하는 사람입니다.

이해는 외주 줄 수 없다

카파시가 했던 말입니다. "생각의 일부는 외주를 줄 수 있어도, 이해는 외주를 줄 수 없습니다."

LLM에게 초안을 쓰게 하고, 코드를 만들게 하고, 테스트를 제안하게 하고, 반례를 찾게 하고, 모르는 라이브러리를 조사하게 하고, 지루한 변환 작업을 시킬 수 있습니다. 여기까지는 외주가 됩니다. 하지만 LLM이 낸 답이 맞는지 판단하는 일은 외주가 안 됩니다. 그 판단은 코드 라인 하나를 읽는 능력 만으로 되지 않고, 도메인과 구조와 제약을 알아야 가능합니다.

앞으로 개발자의 가치는 이 지점에서 갈릴 것 같습니다.(아닐 수도 있습니다. 반박 시 반박하신 분의 말씀이 무조건 옳습니다)

코드를 많이 쓰는 사람보다, 무엇을 코드로 만들지 아는 사람. LLM에게 일을 많이 시키는 사람보다, LLM이 반복하지 않아도 되게 구조를 만드는 사람. 코드를 빠르게 읽어내는 사람보다, 코드보다 큰 것을 이해하는 사람.

LLM 시대의 개발자는 코드를 덜 이해해도 되는 사람이 아닙니다. 코드보다 큰 것을 이해해야 하는 사람입니다.

참고

• Anna Liberty, Towards Understandable Software (2026-03-07) - LLM을 자동화 계층으로 보고, 문해적·시각적·결정론적 NLP 프로그래밍으로 LLM을 대체하자는 주장

• GeekNews, 이해 가능한 소프트웨어를 향하여

• Andrej Karpathy, Software 2.0 (2017)

• Simon Willison, A quote from Andrej Karpathy on "vibe coding" (2025-02-06, vibe coding 원 정의)

• Donald Knuth, Literate Programming

• Entangled, Bidirectional Literate Programming

• ReTangled, Codeberg repository