AI 애플리케이션 빌드의 미래는 타입 안전성에 달려 있다

AI로 생성된 코드는 컴파일될 수 있지만, 엄격한 타입 안전성이 없으면 그 성공은 매우 짧은 기간으로 제한된다. 타입 안전성은 코드가 확장됨에 따라 숨겨진 버그와 런타임 오류로 부서지는 것을 방지하는 가드레일이다.

우리는 컨텍스트, 지시, 린팅, 피드백 루프를 통해 AI를 엄격한 타이핑으로 강제해야 한다. 몇 시간 더 걸릴 수 있지만, 코드의 품질이 향상된다.

인센티브 문제

AI는 사용자를 만족시키고자 한다. 사용자가 제공한 보상 함수를 최적화하며, 대부분의 경우에는 단순히 “컴파일되나요?”이다. 따라서 AI는 초록색 체크마크를 얻기 위해 필요한 모든 구석을 자르려고 한다. 컴파일 시간에는 괜찮아 보이지만, 런타임에는崩壊한다.

이것은 왜 AI가 any를 좋아하는지 설명한다. 또는 기대되는 UUID와 같은 더 엄격한 타입 대신에 string과 같은 광범위한 타입을 선택한다. 코드는 컴파일되지만, 올바름은 이미 손상된다. 더욱 심각한 문제는 AI가 몇 파일 전에 무엇을 썼는지 기억하지 못하므로, 타입 안전성 없이 프로젝트는 복잡성이 증가함에 따라 자체 무게 아래로 붕괴한다.

에러의 두 종류

AI 생성 코드가 실행될 때, 일반적으로 두 가지 유형의 타입 안전성 문제가 발생한다:

1. 컴파일 타임 에러

• 발생하는 일: 컴파일러가 선언된 타입과 전달된 값 사이의 불일치를 감지한다.
• 인간이 수정하는 방법: 호출자가 잘못되었는지(42를 string으로 변환), 함수 시그니처가 잘못되었는지(숫자 타입을 받도록 변경) 결정한다.
• AI가 “수정”하는 방법: 인수 타입을 any로 변경한다. 문제는 “해결”되었지만, 미래의 오류를 잡을 수 있는 가드레일을 제거했다.

2. 런타임 에러

• 발생하는 일: 컴파일러는 모든 것이 괜찮다고 생각하지만(타입을 느슨하게 해서), 실제 런타임 값은 가정과 일치하지 않는다.
• 인간이 수정하는 방법: 변수를 소스(예: API 또는 데이터베이스 쿼리)로 되돌려서 경계에서 타입을 수정하여 올바른 string으로 데이터를 가져온다.
• AI가 “수정”하는 방법: 컨텍스트 없이 추측한다. 모든 것을 String(…)으로 감싸거나, 타입을 다시 느슨하게 한다. 충돌은 사라지지만, 논리 이제는 깨진다. Number는 수학을 위해 사용되지만, 이제는 string이다.

이 런타임 에러 → AI “수정” → 느슨한 타이핑의 순환은 빠르게 합성된다. 결과는 컴파일되고 런타임 에러가 적지만, 신뢰할 수 없는 코드베이스가 된다. 의사 스케줄링 시스템을 생각해 보자. AI가 ‘수정’하면 타입을 느슨하게 해서 코드는 컴파일되고 에러는 사라지지만, 계산은 조용히 깨진다. 의사들의 시프트가 두 번 예약되고, 병원의 한 날개는 커버되지 않는다.

데이터베이스 승수

데이터베이스에 연결하는 순간, 오류는 증가하고 그 원인은 더 어려워진다. SQL은 타입이 있는 이유가 있다. 모든 스키마(INT, TEXT, UUID, BOOLEAN)는 데이터에 대한 가정들을 암호화한다.

AI가 모든 것을 string | any로 평탄화하면, 이러한 보장을 잃는다:

• 잘못된 쓰기: 불리언 필드에 “true”를 삽입하면 컴파일되지만, 데이터베이스를 손상시킨다.
• 잘못된 읽기: 쿼리가 NULL을 반환하지만, AI는 문자열을 가정하여 런타임 충돌이 발생한다.
• 깨진 관계: 관계 키가 UUID로 예상되지만, AI가 문자열로 처리하여 쓰레기 값을 보내면, 조인은 충돌하지 않지만 데이터가 반환되지 않는다. 이는 나중에 결과가 누락되거나 일관되지 않게 나타날 때까지 오류를 숨긴다.

이것이 왜 진지한 팀이 타이핑 언어를 사용하고 스키마에서 API까지 타입 안전성을 강제하는지 설명한다. 그렇지 않으면, 데이터베이스는 더 이상 보호하지 않으며, 숨겨진 문제가 합성된다.

성숙한 팀이 엄격한 타이핑을 강제하는 이유

엄격한 타이핑은 개발자를 느리게 하는 것이 아니다. 확장을 가능하게 하는 것이다.

타입은:

• 의도를 코드에 인코딩한다.
• 리팩터링을 안전하고 예측 가능하게 만든다.
• production에 도달하기 전에 버그 전체 클래스를 잡는다.
• 미래의 개발자(및 AI)에게 함수 또는 객체를 사용하는 방법을 정확하게 보여준다.

타입 안전성 없이, AI의 코드는 더러워진다. 하지만, 그것이 있으면, 동일한 AI는 신뢰할 수 있고 확장할 수 있는 코드를 생성한다.

AI를 타입 안전성으로 강제하는 방법

AI를 주니어 엔지니어처럼 다뤄야 한다. 빠르며, 재능이 있지만, 방향 없이 조심스럽다.

제공할 올바른 컨텍스트

인터페이스와 사용할 수 있는 타입을 제공한다. 사용 예를 보여준다. 코드 구조에 대한 의견을 제시한다.

엄격한 지시 제공

AI에게 any를 사용하지 말고, unknown을 허용하지 말고, 모든 메서드, 객체 및 변수를 타이핑하라고 매우 분명하게 지시한다. 지시를 따르는 데 어려움을 겪을 수 있다(특히 첫 번째 패스에서).

린팅으로 강제

주니어 개발자의 코드를 검토하는 것과 마찬가지로, AI의 코드도 검토해야 한다. “좋은 코드”를 정의하는 사용자 지정 린팅 규칙을 설계한다. 린팅 실패를 모델에 피드백하여 통과할 때까지 반복한다. 여러 라운드가 걸릴 수 있지만, 보상 함수를 타입 안전성을 포함하도록 변경한다.

체크와 함께 반복

컴파일 타임 에러, 런타임 로깅, 클릭스루 테스트. 각 반복은 AI가 타입을 더 엄격하게 하고 production 등급 코드에 더 가까이 이동하도록 강제한다.

더 나은 빌드 방법

원시 생성 속도를 포기하고, 더 높은 품질을 얻는 것이 장기적으로 보상된다는 것을 배웠다. 즉, any 타입에 대한 제로 관용, 여러 피드백 루프 및 엄격한 린팅 규칙을 강제하는 것을 의미한다. AI는 코드를 “완료”라고 부르기 전에 통과해야 한다. 지속적인 노력이 필요하지만, 품질이 저하되는 것을 방지하는 유일한 방법이다.

이전에 언급한 주요 점은, AI가 런타임 오류를 타입을 느슨하게 함으로써 패치하기 시작하면, 악순환이 시작된다는 것이다. 각 수정은 또 다른 가드레일을 제거하고, 코드베이스는 컴파일되지만, 취약하고 유지보수할 수 없다. 반면에, AI가 타입 안전성을尊重한다면, 미덕의 순환이 시작된다. 각 반복은 가드레일을 더 엄격하게 하고, 코드베이스는 깨끗해지고, 품질은 신뢰할 수 있는 것으로 합성된다.

이 시스템이 지속적인 코드 품질을 제공한다고 믿는다. 모든 반복은 기준을 완화하는 것이 아니라 강화하는 것이設計되어 있다. 이것이为什么 최고의 엔지니어링 팀이 강력하게 타이핑된 언어를 선택하는 이유이다. 타입 안전성은 유지보수에 대한 기준 가드레일이며, AI가 이를 무시하면 애플리케이션이 production 등급에 도달하지 못한다는 것을 보장한다.