11 posts
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를 검증해야 합니다. 당연히 팀은…