vibe coding이 바꾼 것, 그리고 바꾸지 못한 것
자연어로 지시한다는 방식
최근 몇 년 사이 프로그래밍 방식에 변화가 있었다. 코드를 직접 쓰는 대신 하고 싶은 것을 말로 설명하면 코드가 만들어지는 방식이다. 흔히 vibe coding이라 불린다.
이 방식은 실제로 작동한다. 그리고 우리가 하려는 것과 구조가 같다. 말로 지시하고, 아래에서 복잡한 것이 만들어지고, 결과를 확인한다.
그런데 코드에서 잘 통하는 것이 수치해석에서 그대로 통하지는 않았다. 이 차이를 짚어두는 것이 이 연재의 논지에서 중요하다. 왜 우리는 DSL이라는 중간층을 따로 만들어야 했는가에 대한 답이기 때문이다.
코드가 유리한 세 가지
1. 결과를 즉시 확인할 수 있다
“버튼을 누르면 목록이 정렬되게 해줘”라고 했다고 하자. 코드가 만들어지고 실행하면 눈으로 보인다. 정렬되면 성공이고 안 되면 실패다.
이 즉각적인 확인이 vibe coding을 가능하게 하는 핵심 조건이다. AI가 틀린 코드를 만들어도 곧바로 드러난다. 그러면 다시 말하면 된다.
수치해석은 다르다. 결과가 맞는지 눈으로 알 수 없다.
손잡이 온도가 48도로 나왔다. 이게 맞는 값인가? 알 방법이 없다. 실제로 만들어 재보지 않으면. 그리고 실제로 재볼 수 있다면 애초에 계산할 필요가 없었다.
틀린 결과와 맞는 결과가 똑같이 생겼다. 이게 결정적인 차이다.
2. 테스트를 자동으로 돌릴 수 있다
코드에는 검증 장치가 있다. 테스트를 작성해 돌리면 기계가 판단해 준다.
수치해석에도 검증 방법이 있지만 성격이 다르다. 해석적 해가 알려진 단순한 문제로 대조하거나, 격자를 더 잘게 나눠 답이 수렴하는지 보거나, 물리 법칙 위반이 없는지 확인한다. 이 방법들은 20편에서 다룬다.
문제는 이것들이 “맞다”를 증명하지 못한다는 점이다. 명백히 틀린 경우를 걸러낼 뿐이다. 검증을 다 통과한 답도 여전히 틀릴 수 있다.
3. 틀려도 대개 안전하다
코드가 잘못 만들어지면 실행이 안 되거나 화면이 이상하거나 에러가 난다. 대체로 눈에 보이고, 고치면 된다.
수치해석의 실패는 다르다. 결과를 근거로 물리적인 결정이 내려진다. 이 두께로 만들자, 이 재료를 쓰자. 그 결정이 제품이 되고, 잘못되면 실제 손실이 생긴다.
같은 종류의 오류인데 비용이 다르다.
그렇다면 무엇이 통하는가
이렇게 보면 부정적으로 들리지만, 실제로는 vibe coding의 핵심 통찰이 우리에게 그대로 적용된다. 다만 적용되는 위치가 다르다.
핵심 통찰: 사람이 다루는 표면을 얇게 하고, 복잡함을 아래로 내린다.
이건 유효하다. 사용자는 문장 한 줄을 쓰고, 아래에서는 스무 개의 결정과 격자 생성과 반복 계산이 일어난다. 이 구조 자체는 옳다.
우리가 추가해야 했던 것은 그 사이에 검사 가능한 층을 끼우는 일이었다.
코드에서는 그 층이 없어도 된다. 코드 자체가 읽을 수 있고, 실행하면 확인되기 때문이다. 코드가 곧 검사 가능한 중간 표현이다.
수치해석에서는 결과로 확인할 수 없으므로, 조건 단계에서 확인해야 한다. 그게 DSL이다.
| 코드 생성 | 수치해석 | |
|---|---|---|
| 중간 표현 | 코드 자체 | DSL |
| 검사 시점 | 실행 후 (결과로) | 실행 전 (조건으로) |
| 틀림의 발견 | 즉시, 자동 | 어렵다. 조용히 지나갈 수 있다 |
| 그래서 필요한 것 | 빠른 반복 | 결정의 가시화 |
마지막 줄이 이 편의 결론이다. 수치해석에서는 반복 속도보다 결정의 투명성이 먼저다.
왜 AI에게 전부 맡기지 않았나
여기서 자연스러운 반문이 있다. AI가 계산까지 하면 안 되나. 물리 문제를 주면 답을 말해주는 방식으로.
실제로 큰 언어 모델은 간단한 물리 문제의 답을 그럴듯하게 말한다. 문제는 그 답이 계산에서 나온 것이 아니라는 점이다. 비슷한 문제의 패턴에서 나온 것이다.
그래서 대개 자릿수는 맞지만 정확하지 않고, 조건을 조금 바꿨을 때 답이 일관되게 변하지 않는다. 설계 판단의 근거로 쓸 수 없다.
우리 구조에서 AI는 계산하지 않는다. 번역만 한다. 실제 계산은 검증된 수치 기법이 한다. 이 분리가 신뢰의 기반이다.
- AI가 잘하는 일 — 애매한 말에서 의도를 읽고 형식으로 옮기기
- AI에게 맡기지 않는 일 — 방정식 풀기
2부를 정리하며
여덧 편에 걸쳐 하나를 다뤘다. 사람의 말과 계산기 사이에 무엇을 놓을 것인가.
답은 DSL이었다. 그리고 그 DSL의 설계 원칙은 세 줄로 정리된다.
- 좁게 만든다. 기본값이 정해지는 범위만 다룬다. 좁음이 검사와 보충을 가능하게 한다.
- 많이 결정한다. 사용자에게 묻지 않는다. 물으면 마찰이고, 마찰이면 아무도 쓰지 않는다.
- 전부 보여준다. 결정한 것을 숨기지 않는다. 숨기면 조용히 틀리고, 조용히 틀리면 도구가 아니라 함정이 된다.
이 세 줄이 이 프로젝트의 기술적 핵심이다. 앱의 화면이나 솔버의 성능보다 이 설계가 먼저다.
3부에서는 그 아래로 내려간다. 지금까지 “복잡함을 아래로 내린다”고 말해온 그 아래에서 실제로 무슨 일이 일어나는지. 격자를 자르고 방정식을 풀고 답이 맞는지 확인하는 과정이다.
다음 편 예고 — 격자를 자른다는 것 (FDM). 3부의 시작. 컴퓨터가 미분방정식을 푸는 가장 기본적인 방법을 그림으로 이해한다.