15 posts
LLM 대화에는 의도, 거부된 대안, 그리고 작동하는 코드가 담겨 있습니다. 이것이 바로 문서가 되어야 할 것입니다. 다음은 일회성 채팅을 내러티브를 잃지 않고 지속 가능하고 검색 가능한 문서로 전환하는 방법입니다.
당신은 Claude와 45분을 들여 재시도 회로를 설계했다. 실패 모드를 설명하고, 계단식 압력을 숨기기 때문에 지수 백오프를 거부한 뒤, jitter가 포함된 token-bucket rate limiting으로 결정하고 작동하는 구현을 생성했다. 설명은 명확했고, 추론은 타당했으며,…
파견 검사는 250줄을 검토하는 데 4~6명과 2시간이 필요하다. 대형 언어 모델은 준비 작업과 체크리스트 준수를 담당하여 비용을 줄일 수 있지만, 가장 비싼 결함을 찾아내는 인간의 역할을 대체할 수는 없다.
완전한 파견 검사에는 진행자, 낭독자, 2~4명의 검토자, 그리고 작성자가 필요하다. 팀은 한 시간에 125줄의 속도로 대략 250줄의 코드를 2시간 동안 검토한다. 작은 변경에도 8~12인시가 드는 셈이다. 대형 언어 모델은 250줄을 1초도 채 걸리지 않아 읽을 수 있다.…
N-version programming은 간단해 보인다: 여러 구현체를 실행하고 가장 좋은 답을 고른다. 하지만 실제로 '최선'은 '가장 흔한'보다 정의하기 훨씬 어렵다.
같은 함수의 다섯 가지 구현체가 있다. 세 개는 같은 결과를 반환한다. 하나는 조금 다르다. 하나는 예외를 던진다. 어느 것이 맞는가? 대부분의 팀은 다수결을 기본으로 삼는다. 출력이 동일하고 오류가 명백할 때는 잘 작동한다. 하지만 구현체들이 미묘하게 의견이 갈리거나, 모든…
LLM을 활용한 N-version programming은 여러 모델이 필요하지 않다. 프롬프트, 페르소나, 추론 제약을 달리하면 단일 모델에서도 다양하고 정확한 구현을 추출할 수 있다.
N-version programming은 다양성이 서로 다른 작성자에게서 나온다고 가정한다. LLM을 쓸 때는 다른 모델, 다른 제공자, 아마도 다른 학습 실행본을 의미한다. 하지만 그 가정은 틀렸다. 똑같은 모델에게서도 질문하는 방식을 바꾸면—질문 내용이 아니라—의미 있는 다양성을…
AI 코딩은 검증 그레이디언트를 따른다. 백엔드는 밀리초 단위로 검증된다. 웹은 분 단위, 모바일은 시간 단위가 걸린다. 피드백 루프가 AI 코딩의 효과를 결정한다.
AI 모델이 스스로 코딩하는 것 자체는 흥미로운 부분이 아니다. 흥미로운 것은 코드를 생성한 다음에 일어나는 일이다. 모델이 코드가 올바른지 얼마나 빨리 알 수 있는가? 생성과 검증 사이의 피드백 루프가 얼마나 타이트한가? 그 루프가 모든 것을 결정한다. 모델이 자신의 출력을 스스로…
AI 코딩은 어떤 난장판에서도 복구할 수 있는 엘리트 팀에게는 잘 통한다. 그 외 모든 사람은 두려움, 실패한 CI, 중단된 실험만 남는다. 격차는 모델이 아니다.
두 팀이 동일한 AI 모델을 사용하는 모습을 지켜보면, 완전히 다른 두 가지 결과를 목격하게 된다. 첫 번째 팀은 모델에게 화면을 만들라고 지시한다. 출력 결과는 비슷하지만 어딘가 어긋난다. 스타일링은 Figma 파일에서 벗어나 있다. 상태 관리는 건드려서는 안 될 파일까지 건드린다.…
대부분의 팀은 AI 코딩을 시도했다가 QA를 통과하지 못하는 코드를 배포하고 포기합니다. 문제는 모델이 아닙니다—AI 출력을 신뢰할 수 있게 만드는 가드레일의 부재입니다.
AI 코딩을 시도하는 대부분의 팀은 같은 궤적을 따릅니다. 처음에는 들떠서 시작합니다. 모델이 몇 분 만에 기능을 생성하고, 팀은 이를 배포합니다. QA가 버그를 발견하고, 팀은 수정본을 배포합니다. QA가 또 다른 버그를 발견하는데, 이번에는 관련이 없어야 할 다른 모듈에서…
타입 검사, 린트, 아키텍처 규칙은 갖췄다. 하지만 결정론적 체계는 복잡도, 중복, 명명 재앙을 전혀 보지 못한다. 비용 0원인 해결책은 이것이다.
솔직히 말해 보자. 지금 대부분의 AI 코드 생성 과정은 어떻게 생겼는가. Cursor나 Claude Code로 코드를 생성한다. TypeScript 엄격 모드가 타입 불일치를 잡아주니 을 돌린다. 세미콜론 논쟁을 병합 과정에서 하고 싶지 않으니 ESLint를 돌린다. 순환 임포트가…
AI coding 도구는 버전 1을 생성하는 데 탁월합니다. 진짜 엔지니어링 과제는 버전 4에서 시작됩니다. 팀이 나머지를 깨뜨리지 않고 무언가를 바꿔야 할 때입니다.
모든 AI coding 데모는 같은 흐름을 따릅니다. 누군가 모델에 프롬프트합니다. 동작하는 앱이 나타납니다. 청중은 감탄합니다. 감탄할 만합니다. 속도는 실제입니다. 능력도 실제입니다. 버전 1은 AI가 루프에 있을 때 진짜로 더 빠르게 배포됩니다. 문제는 버전 1이 결코 어려운…
AI 생성 코드의 진짜 품질 기준은 첫날에 동작하느냐가 아닙니다. 30일째에 나머지를 전부 rewrite하지 않고도 그 코드를 교체할 수 있느냐입니다.
AI 생성 코드 품질에 대한 대부분의 논의는 생성 시점의 정확성에 초점을 맞춥니다. 출력이 컴파일되는가? 테스트를 통과하는가? 명세에 맞는가? 이것들은 기본 조건일 뿐입니다. 진짜 비용에 대해서는 아무것도 알려주지 않습니다. 진짜 지표는 대체 가능성입니다. 요구사항이 변할 때 이…
사람의 리뷰는 일관적이지 않습니다. AI 리뷰는 더 나쁩니다. AI 생성 codebase에 대해 확장 가능한 유일한 방어는 결정론적 enforcement입니다. 무시되는 제안이 아니라 빌드를 실패시키는 규칙입니다.
AI 생성 코드에 대한 표준 조언은 "주의 깊게 리뷰하라"입니다. 이 조언은 정확하지만 규모에서는 쓸모없습니다. AI 출력을 리뷰하는 개발자는 주의력이 높고, 해당 도메인에 익숙하고, 시간 압박이 없을 때 문제를 잡아냅니다. 그 외의 모든 조건에서 — 그리고 대부분의 조건이 그렇습니다…
AI가 명세에서 구현, 테스트, contract까지 만들어낼 수 있게 되면, 인간이 가장 크게 기여할 수 있는 일은 더 앞단으로 이동합니다. 가장 엄격하게 검토해야 할 대상은 구현이 아니라 명세 그 자체입니다.
AI를 붙여 몇 주만 개발해 봤어도, 아마 이 감각을 이미 알고 있을 겁니다. PR을 엽니다. 코드는 충분히 깔끔합니다. 이름도 무난합니다. 테스트도 있습니다. 겉으로 보기엔 분명히 망가진 곳이 없습니다. 그런데도 어딘가가 걸립니다. 경계가 조금 흐릿한 걸지도 모릅니다.…
AI-generated code를 production에서 버티게 하려면 code review만으로는 부족합니다. type constraints부터 mutation testing, runtime containment까지 layered safety stack이 필요합니다.
AI-generated code의 가장 위험한 점은 항상 틀리다는 데 있지 않습니다. 가장 위험한 점은 너무 자주, merge해도 될 만큼 그럴듯해 보인다는 데 있습니다. 바로 그 점이 리스크입니다. 명백히 깨진 code는 잡힙니다. 하지만 그럴듯해 보이고, 몇 개의…
Stanford CS146S를 AI 아키텍처 관점에서 리뷰하고 비판적으로 검토하며, AI coding의 방향은 맞지만 대체 가능성을 지탱할 설계 규율이 빠져 있음을 짚습니다.
Stanford CS146S는 정식으로는 CS146S: The Modern Software Developer라는 수업입니다. 담당 교수는 Mihail Eric이고, 2025년 가을에 처음 개설된 강의입니다. 수업의 공식 개요와 syllabus details는…
Design by contract, property-based testing, mutation testing, model checking은 나쁜 아이디어가 아니었습니다. 지속적으로 운영하기에 필요한 전문성이 너무 무거웠을 뿐입니다. AI가 그 방정식을 바꿉니다.
소프트웨어 엔지니어링에는 읽는 순간 바로 맞는 말처럼 느껴지는 아이디어가 많습니다. 당연히 contracts는 function이 무엇을 받아들이고 무엇을 반환해야 하는지 정의해야 합니다. 당연히 tests는 몇 개의 예제만 보는 대신 properties를 검증해야 합니다. 당연히 팀은…