한 줄짜리 제목이 던지는 질문
“Code is clay now(이제 코드는 점토다)”. Alberto Denia라는 개발자가 쓴 글의 제목인데요, 이 짧은 문장이 요즘 많은 개발자가 어렴풋이 느끼던 변화를 꽤 정확하게 짚고 있어요. 이 글에서는 이 비유를 출발점 삼아, AI 코딩 도구가 일상이 된 지금 코드를 대하는 태도가 어떻게 바뀌고 있는지 같이 풀어볼게요.
대리석에서 점토로
예전 코드는 대리석에 가까웠어요. 한 번 깎으면 되돌리기 어렵고, 한 줄 한 줄에 시간이 많이 들었죠. 그래서 우리는 코드를 아끼고, 오래 쓸 수 있게 설계하고, 함부로 버리지 않는 걸 미덕으로 배웠어요. 몇 주 걸려 만든 모듈을 갈아엎자는 말이 나오면 회의실이 조용해지던 기억, 다들 있으시죠?
그런데 AI 코딩 도구가 들어오면서 코드를 만드는 비용이 확 내려갔어요. 설명 몇 줄이면 화면 하나, API 하나가 몇 분 만에 나오거든요. 점토 비유의 핵심이 이거예요. 점토는 마음에 안 들면 뭉개서 다시 빚으면 돼요. 아까울 게 없죠. 코드도 비슷해졌어요. 구현 방식 세 가지를 다 만들어보고 제일 나은 걸 고르거나, 꼬여버린 모듈을 고치는 대신 처음부터 새로 만드는 게 오히려 빠른 경우가 늘었어요.
그럼 무엇이 단단하게 남아야 할까
점토는 모양을 마음대로 바꿀 수 있지만, 모양을 잡아주는 틀이 없으면 금방 흐물흐물해져요. 그래서 코드가 점토가 될수록 오히려 더 단단해져야 하는 것들이 있어요.
첫째는 테스트예요. 테스트는 코드가 아무리 바뀌어도 “이 입력엔 이 결과가 나와야 한다”는 약속을 지켜주는 틀이에요. 점토를 부어 넣는 거푸집 같은 거죠. 코드를 통째로 갈아엎어도 테스트가 통과하면 안심할 수 있어요.
둘째는 명세와 인터페이스예요. 모듈 내부는 얼마든지 다시 빚어도 되지만, 다른 모듈과 맞닿는 경계, 즉 API 형태나 데이터 스키마는 함부로 바뀌면 안 돼요. 내부는 점토, 경계는 돌이라고 생각하면 편해요.
셋째는 판단력이에요. 켄트 벡은 AI 도구를 써본 뒤, 자기 기술의 90%는 가치가 0이 됐지만 나머지 10%의 영향력은 천 배가 됐다는 취지의 말을 한 적이 있어요. 타이핑 속도나 문법 암기는 점토처럼 흔해졌고, 무엇을 만들지 정하고 좋은 결과물을 알아보는 눈이 귀해진 거예요.
점토의 함정: 굽지 않은 그릇
물론 좋은 점만 있는 건 아니에요. 점토는 가마에 굽기 전까지 약하거든요. AI가 빠르게 만든 코드도 마찬가지예요. 잘 돌아가는 것처럼 보여도 아무도 내부를 제대로 이해하지 못한 채 배포되면, 장애가 났을 때 고칠 사람이 없어요. 요즘 이해 부채라는 말이 나오는 이유죠. 기술 부채가 나중에 갚아야 할 설계의 빚이라면, 이해 부채는 팀이 자기 코드를 이해하지 못해서 쌓이는 빚이에요.
리뷰 부담도 있어요. 코드 생성은 빨라졌는데 사람이 읽는 속도는 그대로라서 병목이 작성에서 검토로 옮겨갔어요. 점토 덩어리를 마음껏 만들 수 있게 됐다고 전부 가마에 넣을 수는 없으니, 무엇을 버리고 무엇을 구울지 고르는 일이 훨씬 중요해졌어요.
업계 흐름 속에서
이 생각이 완전히 새로운 건 아니에요. 프레드 브룩스는 『맨먼스 미신』에서 하나는 버릴 각오로 만들라고 했죠. 처음 만든 시스템은 어차피 배우는 과정이라 버리게 된다는 이야기였는데, 예전엔 버리는 비용이 너무 커서 실천하기 어려웠어요. 지금은 그 비용이 크게 낮아진 거고요. 2025년에 안드레이 카파시가 말한 바이브 코딩도 비슷한 흐름이에요. 다만 바이브 코딩이 코드를 굳이 들여다보지 않는 쪽에 가깝다면, 점토 비유는 계속 손으로 만지고 다시 빚는 쪽에 가까워요. 개발자의 역할이 사라진다기보다 바뀐다는 데 무게가 실린 거죠.
한국 개발자에게 주는 시사점
국내 현장에서는 이 변화가 특히 프로토타입 단계에서 크게 느껴질 거예요. 기획 회의에서 말로 설명하던 걸 그날 오후에 실제로 돌아가는 화면으로 보여줄 수 있으니까요. 그런데 가장 위험한 순간은 그 프로토타입이 그대로 운영 코드가 될 때예요. 점토로 빚은 시안과 구워낸 제품을 구분하는 팀 규칙이 필요해요. 예를 들어 운영 브랜치에 들어가려면 반드시 테스트와 리뷰를 거치게 하는 식이죠.
주니어 개발자라면 “AI가 다 짜주는데 뭘 배워야 하지?” 하는 불안이 있을 수 있어요. 점토 비유로 보면 답이 보여요. 빚는 손은 AI가 빌려줄 수 있지만, 잘 빚어졌는지 알아보는 눈은 직접 길러야 해요. 코드를 읽는 능력, 테스트를 설계하는 능력, 경계를 나누는 설계 감각이 앞으로 더 귀해질 거예요.
마무리
코드가 싸지면 코드 자체보다 코드를 고르고 다듬는 판단이 비싸져요.
여러분도 요즘 코드를 고치는 대신 통째로 다시 만드는 일이 늘었나요? 갈아엎어도 괜찮은 코드와 절대 그러면 안 되는 코드를 어떻게 구분하고 계신지 궁금해요.
🔗 출처: Hacker News