Vision: Zero Bugs - Johann Schleier-Smith, Temporal

영상 링크: Vision: Zero Bugs — Johann Schleier-Smith, Temporal
채널명: AI Engineer

제로 버그 비전: 소프트웨어에서 버그 없는 세상을 꿈꾸다 핵심 요약

• 소프트웨어 개발자가 아닌 대부분의 사용자는 소프트웨어 버그를 거의 인식하지 못하지만, 개발자들에게 버그는 일상적인 스트레스이자 중요한 문제이다.
• “제로 버그(Zero Bugs)“라는 비전을 반박하는 여러 현실적 이유(불완전한 현실, 코드 규모와 복잡성, 명세의 모호성, 경제적 비효율성 등)가 존재한다.
• 항공우주(에어버스 A320, 우주왕복선 등)와 같이 치명적 결과를 용납하지 않는 산업에서는 0에 가까운 버그율로 운영되는 고신뢰 소프트웨어가 실제로 존재한다.
• 이들 시스템의 성공 요인에는 N중 프로그래밍, 명세 기반 설계, 독립적 검증팀, 방어적 프로그래밍, 정적 분석 및 공식 검증 등이 포함된다.
• 소프트웨어 공학의 발전사(고급 언어와 추상화, 구조적 프로그래밍, 모듈화 등)는 버그 감소와 신뢰성 확보에 중추적 역할을 해왔다.
• 공식 기법(formal methods) 및 자동 증명 도구(예: Daphne, Spark) 등이 실제 상용 환경에서 점점 더 폭넓게 적용되고 있다.
• LLM(대형 언어모델)을 활용한 “에이전틱 코딩”에서는 전통적 검증법이 그대로 적용되지 않기에, 새로운 품질보증 및 위험분석 방법이 요구된다.
• 에이전트가 생성한 코드의 생산비용은 전통적 개발 방식에 비해 수천~수만 배 저렴하며, 고신뢰 코드를 100배 저렴하게 만들 가능성을 시사한다.
• 고신뢰 코드를 구현하기 위한 도구와 절차(정형 명세, 모듈화, 분리된 검증 등)는 이미 확립되어 있으며, 에이전트 활용으로 더 널리 확산될 전망이다.
• 버그 없는 소프트웨어 실현은 기술적으로 가능할 뿐 아니라, AI·에이전트의 발전과 결합돼 근본적 소프트웨어 품질 혁신을 이끌 수 있다.

세부 요약 - 주제별 정리

일상적 경험과 개발자 현실은 버그 인식에서 크게 다르다

• 비개발자 대다수에게 버그는 별다른 영향 없이, 일상적으로 사용하는 앱(카메라, SNS, 뱅킹 등)은 대부분 정상 동작하는 것으로 느껴진다.
• 그러나 소프트웨어를 만든 개발자에게는 버그와 장애 가능성, 긴급 대처, 클라우드 장애 등으로 인한 지속적인 스트레스가 존재한다.
• 실제 예시로 발표자 본인이 미니골프 예약 과정에서 앱 오류로 혼란을 겪은 경험을 소개하며, 버그가 남에게도 일상적 영향을 미칠 수 있음을 강조한다.

”제로 버그” 비전을 반박하는 주요 현실적 이유가 존재한다

• 세상은 애초에 완벽하지 않으므로, 약간의 버그나 장애는 감수할 수 있다는 주장.
• 현대 소프트웨어는 이미 상당히 높은 신뢰성으로 운영되고, 치명적 영역에서는 별도의 대책이 구비되어 있다는 견해.
• 코드 규모가 수백만 줄이며, 특히 에이전트가 생성하는 코드가 늘수록 복잡성/버그 가능성이 기하급수적으로 커짐.
• 명세의 모호성(사용자 기대치는 불명확하며, 구현·기획의 경계가 애매함)으로부터 비롯되는 근본적 한계.
• 예측 불가한 현실세계(예: 자율주행차)의 변수는 완전한 소프트웨어 신뢰성을 불가능하게 만듦.
• 소프트웨어 검증 기법들의 이론적·계산적 한계(일부 문제는 계산적으로 불가능).
• 경제적 저해 요인: 경쟁업체가 품질보다 속도를 중시하면 고품질 소프트웨어는 채택되지 않음, 모든 버그 수정의 ROI(투자대비효과)가 낮음, 심지어 일부 기업은 지원 수익을 위해 버그를 방치한다는 시니컬한 시각.

항공우주 산업 사례는 실제로 제로 버그에 근접한 신뢰성을 입증함

• 1980년대 개발된 Airbus A320의 조종 소프트웨어는 지금까지 소프트웨어 결함 때문인 심각한 사고를 기록하지 않음.
• 주요 신뢰성 비법은 아래와 같음:
  • N중 프로그래밍: 핵심 요소는 서로 다른 프로세서(x86, 모토로라 등)·운영체제·독립적 팀이 따로 개발하여 상호 검증 및 이중화 구현.
  • 명세 기반 설계: 방대한 문서화와 시나리오별 동작 증명이 가능한 설계 문서 활용.
  • 독립 검증팀: 개발팀과 분리된 팀이 소프트웨어의 요구 동작을 검증.
  • 방어적 프로그래밍: 실행 중 메모리 할당 금지(정적 할당만 사용), 예외 처리 최소화, 오류 조건을 코드에 명시적으로 표시.
  • 정적 분석 및 공식 검증: 코드 수준에서 자동 도구와 검증 기법을 적극 활용.
• 에어버스 프로젝트에서는 “제로 결함”을 표준으로 삼고, 터빈 팬 블레이드처럼 소프트웨어를 인증·검증 가능한 컴포넌트로 간주.

체계적 품질 프로세스와 상호 피드백이 신뢰성의 초석이 됨

• 계획·요구사항 명세·개발뿐만 아니라, 외부(기관, 정부 등) 인증, 시스템 통합 테스트 등 다단계 프로세스를 통한 지속적 품질 제고.
• 피드백 루프를 통해 각 단계별로 상호 보완 및 미세조정이 이루어짐.
• 하드웨어와 필연적으로 연동되는 영역(항공, 자동차, 의료 등)에서는 통합 테스트 및 외부 규제기관의 검증이 특히 강조됨.

우주왕복선·탐사로버 등도 극단적 고신뢰 소프트웨어가 가능함을 입증함

• 우주왕복선: 420,000줄 소스코드의 세 버전에서 오류는 각 한 번, 11개 버전 전체적으로 17건(동등 기능 상용 소프트웨어 대비 버그 밀도 1/1000).
• 역대 우주왕복선 손실 사고는 모두 하드웨어 문제로 야기되었으며, 소프트웨어 결함은 그 원인이 된 적이 없음.
• Curiosity 로버: 수백만 달러에 달하는 임무비용, 현장 개입 불가 상황에서 극한의 신뢰성 필요, 중복 시스템 및 상용 RTOS(실시간 운영체제) 활용 등 신뢰성 기술 진화 예시.

다양한 산업에서 고신뢰 소프트웨어 개발 경험이 축적됨

• 항공우주 외에도 화학, 자동차, 의료기기, 원자력, 보안 등에서도 유사한 고신뢰 소프트웨어 사례가 존재함.
• 각 산업별로 요구·환경에 맞춰 기술과 프로세스가 맞춤화되고 적용됨.

소프트웨어 공학의 발전(언어, 추상화, 구조, 모듈화 등)이 신뢰성 향상에 결정적이었다

• 고급 언어(High-level language) 도입(195080년대): 추상화·구조화로 생산성 510배 향상, 의미있는 데이터 구조/문맥 기반 설계가 가능해짐.
• 구조적 프로그래밍(Edgar Dijkstra 등): goto문 논쟁을 종식시키고 if-else, 반복 등 기본 제어구조로 익숙한 패턴을 확립. 계층적 분할로 복잡도 관리 가능.
• 모듈화(1970년대 David Parnas): 소프트웨어를 모듈 단위로 분리·조합하여 지역적으로 검증·사고(사람/LLM 모두 가능), 전체 시스템 복잡도 선형/아차피 비선형적으로 관리 가능.
• 라이브러리 활용을 통한 검증된 모듈 결합은 과거 인간뿐 아니라 LLM·에이전트에게도 동일하게 유효함.

LLM·에이전트 코딩 환경에서는 기존 검증 기법의 도전과 새로운 방법론의 필요성이 대두된다

• LLM(대형 언어모델)은 긴 context window(맥락 유지력)를 보유하지만, 여전히 사람과 같이 ‘작업 기억’의 제약이 있음.
• 기존 라이브러리의 신뢰성, 모듈화 원칙 등은 LLM 기반 코드 생성에도 필수적임(모든 코드·라이브러리를 맞춤 생성하는 것이 실용적이지 않음).
• Temporal과 같은 시스템을 통해 신뢰성 관련 문제를 별도 구성요소(내부 미들웨어 등)로 위임하여 소프트웨어 전체의 내구성을 높일 수 있음.

공식 기법(Formal Methods) 발전과 실전 활용도가 크게 증가하고 있다

• Daphne 등의 언어/도구를 활용하면 코드 내에 명세 및 증명을 포함시킬 수 있고, 예시로 배열 내 요소 탐색 프로그램을 작성/검증 시, 잘못된 코드에 대해 도구가 바로 오류를 검출함.
• 공식 검증은 명세 품질에 따라 한계도 있으나, 최근 수십 년 간 실사용 예시가 꾸준히 증가함.
• 상용 활용 예:
  • SCL 마이크로커널: 완전 검증된 운영체제(내장/보안용).
  • Comfort C 컴파일러: 항공 등에서 사용하는 완전 검증 컴파일러(입력 C코드와 산출 결과 일치 증명).
  • Project Everest: 인터넷 트래픽 보호용 대중적 암호화 라이브러리 공식 검증 적용.
  • 마이크로프로세서(수십 년 전부터 공식 검증 사용).
• 성능 측면에서도 업계 벤치마크의 등장으로 성공률 30%대 → 100% 근접까지 향상, 런타임은 50분의 1 이하로 단축.
• 정적 검증(타입 시스템, 추가 체크 등)부터 코드-명세 결합(Daphne, Spark), 별도의 증명 시스템(Lean)에 이르기까지 다양한 도구와 접근법이 실무에서 적용됨.
• 모델체킹(모든 가능한 상태 검증), 자동화 추론이 발전함에 따라 범용적 적용 가능성이 커짐.

에이전틱(Agentic) 코딩 실전 적용 방법론이 새롭게 제안된다

• 상세 명세, 타입언어, 모듈화 등 익숙한 방법 외에도 에이전트에게 “위험분석”/“안전성 근거” 작성 요청, separate prompt(테스트와 구현을 다른 프롬프트-모델에서 요청), 여러 LLM 조합 등 활용.
• 코드의 신뢰성 구축을 위해 중요한 부분만 공식 기법·증명법 적용, 나머지는 검증된 라이브러리 위임 등 실용적 방법이 가능.
• 코드 크기를 줄이고, 테스트/검증 쉽게 하며, 외부 모듈 적극 활용 권장.

”소프트웨어 3.0” 시대, 전통 검증법이 LLM 기반 개발 환경에 곧바로 통하지 않는다

• Andrej Karpathy가 제창한 “소프트웨어 3.0”은 프롬프트가 코드가 되는, AI를 통한 완전히 새로운 개발 패러다임.
• LLM의 비결정적 행동·거대한 상태공간 때문에, 기존 공식 기법이나 전통적 검증 방법이 사실상 적용되지 않음.
• 그러나 LLM은 미지의 입력에 대응 가능, 모호성 처리 능력이 있어, 오히려 새로운 복원력(Resilience) 형태·에러 대응 아키텍처가 등장할 수 있음을 시사.
• 예시: 에러발생 시에만 LLM 호출, 에이전트 기반 장애 대응 설계 등.

에이전틱 코드(LLM 기반)의 생산비용은 전통적 개발 대비 압도적으로 낮다

• 직접 코드 예시: 2분간 요구 입력, GPT-5 기반 60만 토큰 입력, 3.5M 캐시, 48,000 reasoning, 28,000 출력 토큰 사용. 전체 비용 약 $2.
• 출력 토큰 비용이 전체의 15%에 불과, 나머지는 반복 테스트 및 추론에 소요됨(즉, 코드 작성 자체는 비용의 극히 일부분).
• 인간 개발자 기반 고신뢰 코드: 1990년대 NASA 우주왕복선 기준 $1,000/줄, 2020년대 환산 $2,500/줄, 경우에 따라 $3,000/줄까지 도달.
• 일반 소프트웨어: 보통 $10~$100/줄(아웃소싱 비중 높을 경우 $1~$10/줄).
• 에이전틱 코딩(LLM 등): 수천~수만 배 저렴, 심지어 고신뢰 코드 생산도 일반 소프트웨어 생산비용보다 100배 저렴할 가능성.

고신뢰 소프트웨어 개발 절차는 이미 입증됐으며, 에이전트 활용으로 대중적 확장이 가능하다

• 고신뢰 코드를 위한 절차(정형 명세, 모듈화, 분리 검증, 공식 기법 등)는 항공우주 등에서 이미 실증되어 있음.
• 에이전트 기술(특히 고품질 검증, 적대적 테스트 등)을 적용하면, 인간 개발자보다 더 적은 결함의 소프트웨어를 대량·저가로 생성 가능.
• 에이전트가 신뢰성이나 품질에서 인간 개발자보다 앞서면, 소프트웨어 개발 패러다임이 급격히 바뀔 것이 예고됨.

유머와 메타포: 타디그레이드(Ziggy)는 절대 “버그”가 아니다

• Temporal의 마스코트인 Ziggy(타디그레이드)는 벌레가 아니라, 극한 환경(우주 포함)에서도 살아남는 동물로 설명됨.
• Ziggy를 우주로 보내 실험한 경험을 예시로 전달, 타디그레이드 특성에 빗대어 “내구성 있는 소프트웨어”와의 연관성을 유머러스하게 강조함.