10월 20일 화요일
오늘 하나만 본다면
프로덕션급 LLM과 에이전트 현장 가이드
에이전트를 프로덕션에 올리는 열쇠는 더 큰 모델이 아니라 모델을 더 좁은 상자에 가두는 것이고, 그 순서까지 정해져 있습니다.
- 데모가 잘 되는 에이전트와 고객이나 돈 앞에 세울 에이전트 사이에는 협곡이 있고, 건너는 열쇠는 더 큰 모델이 아니라 모델 주변의 지루한 장치입니다. 결정성, 평가, 보정된 신뢰도, 겹겹의 가드레일, 감사 기록, 관측성을 꼽습니다.
- 핵심 주장은 LLM이 확률적이므로 모델을 결정적으로 만들 수는 없지만, 모델의 일을 판단이 필요한 가장 작은 결정으로 줄이고 그 결정을 테스트하고 막고 감사하고 관측할 수 있는 결정적 장치로 감싸면 보장을 얻는다는 것입니다.
- 성숙도 모델은 6단계입니다. 0은 노트북, 1은 결정성(에이전트는 제안만 하고 적용은 별도 컴포넌트가 하며, 기능마다 고정된 그래프와 루프 상한을 둡니다), 2는 평가(CI 게이트, 기준선 대비 드리프트), 3은 신뢰도(자동 처리와 사람 검토의 임계값), 4는 안전과 거버넌스(경계에서 PII 처리, 추가만 가능한 감사 원장), 5는 운영성(비용 통제, 모델 라우팅과 폴백, 배포 없이 켜는 킬 스위치), 6은 빌드 자체의 규율(결정 로그)입니다.
- 사용법은 가장 약한 단계를 찾아 순서대로 고치는 것입니다. 대부분의 팀은 0단계에 강하고 5단계를 바라지만, 결정성은 평가보다, 평가는 신뢰도보다, 안전은 확장보다 먼저라고 말합니다. 열 개 체크리스트 중 절반 미만이면 데모가 암시하는 것보다 이르다고 진단합니다.
AI 코딩 도구의 검증 체계를 고민한다면 "제안과 적용을 분리하라"는 1단계가 바로 맞닿습니다. 에이전트가 쓴 코드를 사람이나 결정적 게이트가 적용하는 구조와 같은 원리입니다. 다만 25편짜리 시리즈의 지도 글이라 각 단계의 근거와 수치는 하위 글에 있고 이 글에는 없습니다.
읽을 만한 것
그래도 프로그래밍을 즐겨도 된다
벽돌깨기를 손으로 짜는 저자는 Claude가 한 번에 만들 수 있다는 사실이 요점이 아니라고 말하고, 즐거움에는 경제적 정당화가 필요 없다고 씁니다.
- 회사에서는 손으로만 짜는 코드의 경제성이 바뀐 게 맞지만, 그것은 일이지 삶이 아니라고 구분합니다. 인터넷에서 가장 목소리 큰 쪽이 가장 우울하고 전염성이 강하다는 진단입니다.
- 저자는 주말마다 직접 코드를 짭니다. 지금은 충돌 판정이 엉성한 벽돌깨기를 만들며 게임 프로그래밍을 배웁니다. Claude가 한 번에 만들어줄 수 있다는 사실은 요점이 아니라고 말합니다.
- 곁가지 공부의 예로 Agda 같은 종속 타입 언어의 아이디어를 Java 타입 안전성에 밀어붙여 본 것, 재귀 도식(recursion scheme)을 몇 시간씩 붙들고도 가치를 아직 모르는 것을 듭니다. 좋은 아이디어는 몇 해 머릿속에서 익은 뒤에야 보이고, 당장 쓸모가 없어도 어려운 것을 이해하는 일 자체가 보상이라고 봅니다.
- "더 이상 즐기면 안 되는 분위기"라는 사회적 압력을 느껴 글을 썼고, 즐거움에는 경제적 정당화가 필요 없다는 것이 결론입니다. 각주에서 vibe coding도 즐겁다고 인정합니다. 코드를 한 줄도 안 본 앱이 여럿이고 보면 경악할 것 같지만, 그 방식은 그 방식대로 독특하게 재미있다고 씁니다.
아래 "프로그래밍의 부고"와 짝으로 읽으면 같은 변화를 두 사람이 어떻게 다르게 받아들이는지 보입니다. 한쪽은 일과 삶을 갈라 즐거움을 지키고, 다른 쪽은 직업으로서의 프로그래밍이 끝났다고 애도합니다.
프로그래밍의 부고
결과물만 원하던 개발자에게 LLM은 계속 주는 선물이지만, 퍼즐을 푸는 과정이 즐거움이던 개발자에게는 상실이 실제로 큽니다.
- Simon Willison의 링크 블로그 글로, Jeremy Scheff의 "프로그래밍의 부고"를 인용해 코딩 에이전트가 경력 프로그래머에게 남긴 상실을 짚습니다. 본문은 인용이 대부분이라 원문 전체는 Scheff의 글에 있습니다.
- Scheff의 회고에 따르면 프로그래밍은 상상할 수 있는 최고의 직업 중 하나였습니다. 까다로운 작은 논리 퍼즐을 풀면 돈을 받았고, 퍼즐이 까다로울수록 더 받았습니다. 평범한 사람은 그걸 못 했기 때문에 사람들이 개발자를 필요로 했고, 개발자가 전략과 일정과 가능한 범위를 정했습니다.
- 갈림길은 무엇을 좋아했느냐입니다. 동작하는 시스템을 만드는 일이 좋고 풀이 과정의 문제 자체에는 깊은 관심이 없던 사람에게 LLM은 계속 주는 선물입니다. 문제를 직접 푸는 일이 즐거움의 큰 부분이었다면 상실은 실제로 큽니다.
짧은 인용 글이라 2분이면 읽습니다. 위의 Chris Kiehl 글과 함께 읽으면, 같은 도구 앞에서 "일이 아니라 취미로 지키면 된다"와 "직업의 핵심이 사라졌다"가 어떻게 갈리는지 보입니다.
모든 나눗셈을 느리게 만든 0.000000000000000000542퍼센트 버그
나눗셈에 분기 하나를 붙인 수정이 CPU에서는 차이가 없는데 GPU(CUDA)에서는 5548μs를 12592μs로 늘렸습니다.
- 2의 보수에서는 가장 작은 음수에 대응하는 양수가 없어서 x를 -1로 나눈 값은 x가 최솟값일 때 표현할 수 없습니다. 32비트에서는 입력 2의 64제곱 가지 중 한 가지가 해당해 제목의 비율이 나옵니다. C에서 부호 있는 정수 오버플로는 미정의 동작이고, x86에서는 CPU 예외로 프로그램이 죽기도 합니다.
- Futhark는 C 코드를 생성하는 언어이고 자체 의미론에서는 오버플로가 감싸기(wrap)로 정의됩니다. 그래서 모든 정수를 부호 없는 C 타입으로 표현해 연산하고, 비교와 나눗셈처럼 부호가 중요한 연산만 부호 있는 타입을 씁니다. 나눗셈이 그 구멍이었고 약 10년간 버그로 남아 있었습니다.
- 수정은
y == -1이면 부호 없는 산술로 음수화하는 분기를 모든 나눗셈에 넣는 것입니다. 비용은 모든 나눗셈에 붙는 분기입니다. - 측정은 갈립니다. 실제 벤치마크 모음과 순차 CPU 백엔드에서는 차이가 없었습니다(3390148μs 대 3389215μs). 나눗셈만 반복하게 만든 인위적 프로그램을 CUDA에서 돌리면 5548μs가 12592μs로 2배 넘게 느려졌습니다. PTX를 보니 기존에는 div.s32 네 개가 한 블록에 이어져 풀렸지만 수정 후에는 나눗셈 사이마다 분기가 끼었고, AMD GPU에서도 비슷하되 영향은 더 작았습니다.
- 결론은 정확성은 양보할 수 없으니 감수하되, 음수가 없다고 아는 코드는 부호 없는 나눗셈을 쓰면 된다는 것입니다. 저자가 기억하는 마지막 미정의 동작이며, 정의가 구현에 맡겨진 비트 시프트 초과 사례가 하나 남아 있습니다.
"거의 일어나지 않는 경우"의 정확성에 얼마를 지불할지, 그리고 그 비용이 플랫폼에 따라 얼마나 다르게 나타나는지를 실측으로 보여 줍니다. 벤치마크 모음에서 안 보이던 비용이 인위적 프로그램에서 2배로 드러나는 대목은 성능 측정을 어떻게 설계해야 하는지에 대한 교훈이기도 합니다.
짧게 알아두기
- Blocking Identity Resolution Infrastructure
WebKit BlogiOS, iPadOS, macOS, visionOS 27의 Safari가 이메일을 몰래 수집해 추적 ID로 바꿔주는 identity resolution 서드파티 도메인의 네트워크 접근을 막습니다. 로그인이나 뉴스레터 폼에서 이런 서드파티 스크립트에 기대는 기능이 있다면 Safari 27에서 동작을 확인해야 합니다.
수집 상태
수집 7587건, 본문 확보 22건, 실은 글 4편. 실패한 소스: 없음