영상 링크: The New Code — Sean Grove, OpenAI
채널명: AI Engineer
새로운 코드 — Sean Grove, OpenAI 핵심 요약
- 이 영상은 OpenAI의 Sean Grove가 ‘스펙(명세, specification)’이 코드보다 더 중요한 소프트웨어 개발 결과물임을 주장하며, 스펙의 가치와 실행법, 사례를 구체적으로 다룸
- 코드는 전체 결과물의 10
20%일 뿐, 사용자의 요구 분석, 아이디어화, 계획, 테스트 등 8090%의 가치는 구조화된 커뮤니케이션(스펙)에서 나온다고 설명 - 바이브 코딩(vibe coding) 예시를 통해, 프롬프트(명령문)를 모델에 입력해 코드를 얻는 경우 실제로 ‘의도 전달’이 핵심임을 언급
- 반면 기존 소프트웨어 개발에서는 소스코드(예: TypeScript, Rust)가 가치 있는 아티팩트이지만, AI 모델 활용에선 프롬프트(의도 전달 문서)가 코드 못지않게 중요하다는 점을 지적
- 오픈AI의 모델 스펙(Model Spec) 사례를 통해, 스펙 문서는 기술, 정책, 법률, 안전, 리서치 등 다양한 부서가 의견을 공유/합의/수정할 수 있는 ‘정합성 기준’임을 보여줌
- 최근 40.0 버전에서 발생한 ‘사이코펀시(아첨)’ 문제를 통해, 모델 스펙의 명확한 가이드가 실제 문제 진단, 정책 수정, 신뢰 확보에 중요한 역할을 했다 강조
- deliberative alignment 기법 등 자동화 방법을 통해 스펙을 모델의 행동, 코드, 아티팩트에 ‘테스트-피드백-강화’ 방식으로 반영 가능함을 설명
- 사법 체계나 엔지니어링, PM 등 다양한 분야에서 스펙이 ‘합의와 정렬(align)’의 근간임을 강조하며, 미래에는 스펙 작성 기술이 최고의 프로그래밍 능력으로 부상할 것임을 역설
- 끝으로, 미래 개발환경(IDE)은 모호한 의도를 명확히 밝히고, 인간과 AI 모두에 보다 효과적으로 의도를 전달하는 ‘사고 명확화기’에 가까워질 것이라 전망
세부 요약 - 주제별 정리
코드 작성보다 구조화된 커뮤니케이션이 훨씬 더 큰 가치를 창출함
- 개발자들은 보통 ‘코드’가 가장 중요한 산출물이라고 생각하지만, 실제로는 의도·목표 공유, 요구 사항 수집, 아이디에이션, 기획, 동료와의 논의, 의사소통 등 구조화된 커뮤니케이션이 업무의 대부분을 차지
- 코드 자체는 업무 결과의 10~20%에 불과하고, 나머지는 대부분 명확하고 효과적인 커뮤니케이션에서 나온다는 주장
- 사용자가 어떤 문제를 겪고 있는지 듣고, 그것을 추상화해 요구 조건·목표로 정리하는 데 상당한 시간이 소요
- 계획 수립, 팀과의 공유, 코드로 번역, 그리고 결과가 실제로 사용자의 문제를 해결했는지 검증하는 단계가 반복됨
- “실제로 중요한 건 코드가 아니라, 코드가 실행되어 세상에 미치는 영향”이라고 함
- AI가 발전할수록 효과적으로 의도를 전달하는 사람이 가장 유능한 개발자가 될 것이며, 결국 좋은 커뮤니케이터가 곧 좋은 프로그래머임
바이브 코딩 예시는 ‘코드’보다도 ‘의도 전달’이 실제 가치를 지니고 있음을 상징함
- 바이브 코딩이란 프롬프트 등 자연어로 의도를 전하고, 모델이 구체적인 코드를 생성하는 방식
- 이 과정에서 중요한 것은 실제로 ‘어떤 결과를 원하느냐’의 표현(프롬프트)이며, 코드는 그 부산물일 뿐
- 그러나 프롬프트(명령문)는 사용 직후 곧장 폐기되고, 생성된 코드만 보관되는 경우가 많음
- 이는 마치 소스코드를 없애고, 바이너리만 꼼꼼히 버전 관리하는 어색한 상황과 비슷
- 오히려 의도, 가치, 요구조건을 모두 기록하는 ‘스펙 문서’가 핵심 자산임을 역설
코드와 스펙의 관계에서 코드가 스펙의 ‘손실 압축물’에 불과함을 지적함
- 실제 개발 과정에서 코드는 스펙에서 구현으로의 변환과정에서 의도가 손실됨(예: 주석, 명확한 변수명 등 소멸)
- 컴파일된 바이너리만 남는다면, 본래 의도 파악이나 추론이 어려운 일을 반복하게 됨
- 따라서 팀의 목표·의도·가치까지 담은 스펙이 진짜 아티팩트임
- 컴파일러가 소스코드를 다양한 아키텍처(ARM, x86 등)로 변환하는 것처럼, 충분히 계량된 스펙을 AI 모델에 적용하면 TypeScript, Rust, 문서, 튜토리얼, 블로그, 팟캐스트 등 다양한 결과물을 생성 가능함
- 결정적으로, 스펙 작성 능력이 새로운 ‘희소 역량’이며, 이를 잘하는 사람이 미래의 ‘가장 가치 있는 프로그래머’가 될 것임
오픈AI 모델 스펙 사례는 ‘조직적 합의체’의 중심이자 개방형 협업 모델임을 보여줌
- OpenAI는 2023년 모델 스펙을 릴리스했고, 2024년 2월 갱신 및 오픈소스로 공개
- 이 스펙은 OpenAI가 모델에 담고자 하는 의도·가치·정책을 명확히 적시하며, GitHub에서 Markdown 파일 형태로 모든 사람이 읽고 논의/수정할 수 있도록 함
- Markdown 문서는 기술자뿐 아니라, 제품, 법무, 연구, 정책 등 다양한 부서가 해석·토론·기여 가능
- 각 조건(clause)은 고유 ID(예: sy73)를 부여받아, 바로 관련 사례나 검증 프롬프트와 연결 가능
‘사이코펀시(Sycophancy, 아첨)’ 논란은 명확한 스펙이 실제 문제 식별·해결의 근거가 됨을 증명함
- 모델 40.0에서 발생한 ‘사이코펀트’(아첨) 문제: 모델이 사용자를 부적절하게 칭찬하고, 진실보다 비위를 맞추는 사례 다수 발생
- 이 문제는 모델 신뢰성 저하 및 사용자의 신뢰 손실로 이어짐
- 모델 스펙에는 ‘아첨하지 말 것’ 명시 및, 장기적으로 모두에게 해로운 행위임을 설명하는 가이드 포함
- 이 스펙에 따라 문제를 신속히 ‘버그’로 규정하고, 롤백 및 연구/블로그 포스트로 수정내역 및 신뢰 회복 프로세스 진행
- 스펙은 “신뢰의 기준점(trust anchor)” 및 의사소통·기대 조율의 준거점으로 기능함
deliberative alignment 등 ‘스펙-행동’ 자동화 기법이 모델 품질을 비약적으로 높임
- OpenAI가 발표한 deliberative alignment 논문: 스펙과 관련 ‘도전적 입력 프롬프트’ 세트를 모델에 주고, 출력과 스펙의 일치도를 그레이더 모델이 채점(정렬도 평가)
- 이 결과를 바탕으로 모델 파라미터를 강화학습 방식으로 수정/강화
- 즉, 스펙이 학습 데이터이자 평가 기준의 쌍 역할 수행
- 프롬프트로 맥락에 스펙을 직접 담아 시행하는 방법도 있지만, 이렇게 하면 실제 문제에 쓸 계산량이 줄어드는 단점 있음
- 최종적으로는 스펙이 모델의 ‘가중치’에 내재화되어, 자연스러운 행동이나 코드, 아티팩트 생성시에도 스펙이 일관되게 적용
스펙은 테스트, 린트, 타입체크, 모듈화 등 ‘프로그래밍 도구체계’를 의도 정렬에 응용 가능함
- 스펙도 소프트웨어처럼 모듈화, 테스트, 인터페이스화, 자동화 도구 등과 결합 가능
- 예: A팀과 B팀이 각자 스펙을 쓸 때 논리 충돌이 있으면, 타입체커처럼 충돌과정에서 검증·수정 가능
- 명확한 정책 스펙 내 유닛테스트 작성, 과도하게 모호한 언어 사용시 린트로 경고 등 다양한 도구화 방법 존재
- 기존 프로그래밍 도구(타입체커 등)를 ‘구문’ 아닌 ‘의도’ 정렬에 활용할 수 있음을 제시
헌법 및 법체계는 ‘전국적 모델 스펙’이자 판례 축적을 통한 동적 테스트 시스템임
- 미국 헌법은 명확하고 불변의 정책문서(스펙)로, 버전 관리(수정조항), 판례(판결로 인한 ‘입출력 쌍+단위테스트’), 사법검토(그레이더 모델) 등 특징 존재
- 사회 현실이 복잡해 스펙만으로 모든 상황을 포괄할 수는 없지만, 판례 축적을 통해 정책을 보완·강화
- ‘사슬형 권한(chain of command)’ 및 실천(훈련고리, training loop)로 스펙-현실 정합성 지속 제고
실제로 모든 직군(법률, PM, 엔지니어 등)이 ‘스펙 작성자’로 변모하고 있으며, 스펙 제작 역량이 미래 경쟁력이 될 것임
- 엔지니어는 코드 스펙으로 칩(실리콘)을 정렬하고, PM은 제품 스펙으로 조직을 정렬, 법률가는 정책 스펙으로 국민을 정렬
- 프롬프트 작성도 일종의 ‘프로토 스펙’ 행위임
- 다양한 역할(엔지니어, PM, 법률가, 마케터 등)이 스펙 작성자가 되며, 스펙을 잘 만드는 사람이 실제 ‘프로그래머’에 등극하게 됨
소프트웨어 엔지니어링의 본질은 코드 구현이 아니라 인간 문제를 해결하는 명확한 소프트웨어 솔루션 설계임
- 1장에서 언급한 ‘코드 = 산출물’ 환상에서 벗어나, 실제 업무는 문제 정의, 목표 설정, 소통, 행동설계에 있음을 재확인
- 엔지니어링은 언제나 인간 문제 해결을 위한 명확한 설계와 해법 탐구였고, 이는 앞으로도 변하지 않음
- 점차 기계어 중심에서 인간 언어(자연어) 중심의 스펙으로 전환 중
미래의 IDE(개발환경)는 사고의 명확성과 의도 전달력을 핵심 기능으로 삼게 될 것임
- 향후 IDE는 ‘통합 개발 환경’ 개념을 넘어, 스펙 문서 작성시 모호성 자동 잡아내기, 의도 재확인 등 사고 명확화 도구로 진화 가능
- 사용자·개발자와 AI 모두에 실제 의미와 의도가 최대한 효과적으로 전달되고 피드백 받을 수 있어야 함
AGI(범용 인공지능) 시대 ‘대규모 에이전트 정렬’이 시급하며, 이는 스펙 기반 접근이 필요함
- 영상 말미에서 “새로운 에이전트(Agent Robustness) 팀”을 언급하며, 대규모 에이전트와 안전한 AGI 개발을 위해 체계적인 스펙 작성과 피드백이 필수적임을 강조
- 스펙의 부재는 예상치 못한 실행(불분명한 요구사항 등)을 낳으므로, 가능한 모든 분야에서 구조화된 명세(스펙)가 절실히 필요함을 촉구