코드는 의도를 적은 명세에서 떨어져 나온 손실 압축본일 뿐이고 그 명세를 쓰는 사람이 진짜 프로그래머라는 주장. 아첨하는 성향을 내보낸 사고를 「명세에 이미 하지 말라고 적혀 있었으니 버그다」로 처리한 사례가 구체적으로 나오고, 명세를 맥락에 매번 싣는 대신 가중치로 내리는 절차, 조항마다 번호를 달고 그 번호로 어려운 물음 파일을 찾게 해 둔 구조까지 다룸.
한줄 코멘트. 명세를 조항마다 번호를 달아 두고 그 번호로 시험 물음 파일을 찾게 해 둔 것 — 이 한 가지가 이 발표에서 옮겨 갈 만한 물건이다. 나머지는 「코드보다 소통이 중요하다」는 익숙한 주장이고, 든 수치도 잰 값이 아니라 발표자의 어림이다.
앤스로픽 아닌 다른 연구소에서 정렬 쪽 일을 한다는 사람이 발표한다.
여는 주장은 이렇다. 코드가 내는 값은 열에서 스물 남짓이고 나머지는 짜임새 있는 소통에 있다는 것이다. 사용자와 이야기하고, 줄이고, 어떻게 풀지 궁리하고, 계획을 세우고, 동료와 맞추고, 그것을 코드로 옮기고, 효과를 확인한다.
그러니 막히는 자리는 코드가 아니라 소통이고, 모델이 좋아질수록 그 자리가 더 아프게 느껴질 것이라고 말한다.
무엇을 판에 남기나
무엇을 남기고 무엇을 버리나
*바이브 코딩이 실은 소통이 먼저이고 코드는 그 뒤에 딸려 나온 것이라고 말한다. 그런데 우리가 하는 짓은 반대라는 것이다. 시킨 말은 흘려보내고 나온 코드를 판 관리한다.
빗댐이 세다. 원본을 파쇄하고 구워 나온 것만 조심스레 관리하는 꼴이라는 것이다.
그래서 코드를 명세에서 떨어져 나온 손실 압축본으로 본다. 구운 것을 되돌려 봐야 좋은 주석과 좋은 이름이 돌아오지 않는 것과 같다고 말한다.
거꾸로 충분히 단단한 명세가 있으면 거기서 여러 언어의 코드도, 서버도, 문서도, 안내글도 나온다고 말한다.
이 발표에서 가장 손에 잡히는 대목이다.
자기네가 낸 모델 명세를 든다. 열어 보면 그냥 마크다운 파일 묶음이다. 자연어라서 기술 쪽이 아닌 사람 — 제품·법무·안전·정책 — 도 같은 원본을 읽고 따지고 보탤 수 있다는 것이 요점이다.
옮겨 갈 만한 물건이 여기 있다. 조항마다 번호가 달려 있고, 그 번호로 저장소에서 파일을 하나 더 찾을 수 있다. 그 파일에 그 조항을 걸고넘어지는 어려운 물음들이 들어 있다.
즉 명세와 그 명세를 시험하는 물음이 번호 하나로 묶여 있다.
사례가 이어진다. 어느 판을 갱신한 뒤 모델이 심하게 비위를 맞추는 쪽으로 굴었다.
발표가 든 예가 얄궂다. 사용자가 그 아첨하는 태도를 지적하자 모델이 그 지적을 칭찬했다.
그러면서 이렇게 내보낸 것이 믿음을 깎았다고 말한다.
여기서 명세가 하는 일이 드러난다. 명세에는 처음부터 그러지 말라는 절이 있었다 — 당장은 기분이 좋아도 길게 보면 모두에게 나쁘다는 이유까지 적혀 있었다. 그러니 이 행동은 취향 문제가 아니라 버그가 된다. 되돌리고 글을 내고 고쳤다고 말한다.
그 사건 동안 명세가 믿음을 매어 두는 말뚝 노릇을 했다고 말한다. 무엇이 기대되고 무엇이 아닌지를 밖에 대고 말할 수 있었다는 것이다.
명세를 가중치로 내리는 순서
같은 명세를 모델을 맞추는 데도 쓴다며 자기네 기법을 든다.
명세와 어려운 물음을 함께 놓고, 훈련 중인 모델에서 답을 뽑고, 그 답과 물음과 정책을 더 큰 모델에 줘서 명세에 비추어 점수를 매기게 한다. 그 점수로 가중치를 밀어 준다.
왜 그렇게 하느냐가 이 절의 값이다. 명세를 매번 맥락에 실으면 그때마다 값을 문다. 가중치로 내리면 그 값을 안 물고 모델이 몸에 밴 것처럼 쓴다는 것이다.
명세를 코드처럼 다루자는 다섯 갈래
| 성질 | 무슨 뜻인가 |
|---|---|
| 짜 맞춘다 | 여러 개를 합쳐 하나로 만든다 |
| 돌린다 | 넣으면 결과가 나온다 |
| 시험한다 | 조항마다 걸어 볼 물음이 있다 |
| 맞물리는 면이 있다 | 바깥 세계와 닿는 자리가 정해져 있다 |
| 묶어 낸다 | 부품처럼 떼어 내보낸다 |
부서 둘이 각각 쓴 명세가 서로 부딪히면 그것을 앞으로 끌어내 발행을 막을 수 있어야 한다고 말한다.
마지막 절은 비유다. 미국 헌법을 나라 단위 모델 명세라고 부른다.
발표가 대 놓는 짝
| 헌법 쪽 | 명세 쪽 |
|---|---|
| 조문 | 명세 본문 |
| 개정 절차 | 판을 올리고 내보내는 길 |
| 사법 심사 | 어떤 상황이 정책에 얼마나 맞는지 매기는 일 |
| 판례 | 뜻을 또렷하게 만드는 입력·출력 짝, 곧 단위 시험 |
그러고 넓힌다. 프로그래머는 명세로 실리콘을 맞추고, 제품 쪽 사람은 팀을 맞추고, 입법자는 사람을 맞춘다. 프롬프트를 쓰는 순간 이미 명세를 쓰고 있는 것이라고 말한다.
앞으로의 편집기는 쓰는 동안 모호한 자리를 짚어 되묻는 도구가 될 것이라고 말한다. 닫는 말은 새로 만든 팀에 합류해 달라는 청이다.
10~20과 80~90은 잰 값이 아니다. 무엇을 어떻게 세어 나온 비율인지가 없다. 발표자의 어림이다.
명세가 값을 한다는 증거가 없다. 명세를 두었을 때와 안 두었을 때를 견준 자리가 한 군데도 없다.
가중치로 내린 기법의 결과가 없다. 그렇게 해서 무엇이 얼마나 나아졌는지, 맥락에 싣는 쪽과 견줘 얼마나 아꼈는지가 나오지 않는다.
아첨 사고의 크기가 없다. 얼마나 오래 나갔고 몇 명이 겪었는지가 없다. 자막이 그 판의 이름을 뭉개 놓아 정확한 표기는 원문에서 갈린다.
부딪히는 명세를 막는다는 것은 아직 이야기다. 그런 검사기가 있다는 말은 없고 있으면 좋겠다는 쪽이다.
모범 사례를 자기 회사 것으로만 든다. 명세 문서도 기법도 팀도 전부 한 곳의 것이고, 다른 데서 통했다는 사례가 없다.
용어