챗GPT(ChatGPT)의 직전 모델인 GPT-4o가 작년 5월 처음 나왔을 때 사용자들은 당혹감을 감추지 못했습니다. 
 

사용자가 위험하거나 부적절한 선택이나 주장을 했을 때 챗GPT가 거기에 지나치게 맞장구를 쳐주며 심지어 칭찬까지 더해주었기 때문이었어요. 사용자들은 이러한 ‘과잉 동조(sycophancy)’ 현상을 캡쳐해서 인터넷에 우후죽순 올리기 시작했습니다.

당시 오픈AI는 해당 문제가 생긴 경위를 빠르게 파악, 대응했는데요. 이에 대해 오픈AI의 AI 정렬(alignment) 연구 담당자인 션 그로브(Sean Grove)는 GPT-4o의 ‘모델 스펙(model specification, spec)’에 이미 과잉 동조에 관한 내용이 있었던 덕분이었다고 말했습니다.

💡AI 정렬: 개인이나 집단이 AI 시스템을 의도한 목표, 선호도, 또는 윤리 원칙에 맞춰 조정하는 것을 목표로 합니다. AI 시스템이 의도한 목표를 달성할 때 정렬되었다고 간주하는 반면, 정렬이 잘못된 AI 시스템은 의도하지 않은 목표를 추구합니다.

💡스펙: 프로젝트나 기능의 요구사항, 목표, 구조 등을 문서로 명확히 정의한 설계 기준(설계도)을 의미합니다. 션 그로브는 AI 시대에 스펙이 다른 사람 뿐만 아니라 AI 모델과 소통하는 데에도 필수적인 문서이자 기록이라고 강조합니다. 

션 그로브는 AI 시대에 접어들어 스펙을 잘 작성하는 재능이 보편적으로 중요해질 것이고, 특히나 엔지니어들에게는 코딩 능력이나 프롬프팅 역량보다 더 강조될 것이라고 내다봤어요.

그의 발표를 기반으로 스펙이 왜 그렇게 중요한지, 오픈AI는 모델 스펙을 어떻게 만들고 있는지, 모델 스펙으로 과잉 동조 문제를 어떻게 풀었다는 것인지, 스펙을 작성할 때 참고할 체크리스트는 무엇일지 알아보겠습니다. 

[아티클 내비게이션]

• AI의 핵심은 코드가 아니라 ‘스펙’
• 챗GPT의 알랑방귀, 스펙으로 풀어 낸 비결
• 스펙을 작성할 때 고려해야 할 체크리스트

AI의 핵심은 코드가 아니라 ‘스펙’

“엔지니어에게 코딩은 기본적인 업무지만 가장 중요한 일은 아닙니다. 대신 ‘구조화된 커뮤니케이션(structured communication)’을 통해 의도를 정확하게 전달하는 것이 엔지니어에게 최고로 중요하고 가장 큰 임팩트를 내는 일입니다. 따라서 ‘스펙’을 잘 작성하는 일이 새로운 초능력이 되어 가고 있습니다”

션 그로브는 문제를 해결하는 과정에서 명확한 사고와 의사소통을 최우선시하는 오픈AI의 엔지니어입니다. 그는 안전하고 유용한 AI 모델과 이를 기반으로 애플리케이션을 구축하는 데에 의사소통이 핵심이라고 봅니다.

물론 엔지니어가 만드는 결과물은 결국 코드이고, 사람들과 코드를 갖고 대화를 나누고 품질을 논하며 결과를 측정합니다. 코드는 눈에 보이기 때문에, 사람들은 그저 쉽게 코드가 곧 산출물이라고 생각하고 엔지니어가 하는 일의 전부라고 여깁니다.

하지만 션 그로브는 이에 반대합니다. 코딩은 엔지니어들이 만드는 임팩트의 10~20% 정도밖에 차지하지 않는다고 해요. 그는 나머지 80~90%가 구조화된 커뮤니케이션이라고 주장합니다. 

구조화된 커뮤니케이션은 다음 6단계로 세분화할 수 있습니다.

1) 사용자의 어려움을 이해하기 위해 사용자와 대화를 나누는 일

2) 대화의 내용 중 불순물을 거르고, 사용자의 어려움을 줄이기 위한 목표가 무엇일지 발굴하고 아이데이션하는 일

3) 2)번의 목표를 구축하기 위해 계획을 짜는 일

4) 다른 동료들과 3)번의 계획을 공유하는 일 

5) 3)번의 계획을 코드로 구현해 실행하는 일 

6) 코드 자체를 테스트하고 증명하는 것이 아니라 코드를 실행했을 때 원래 목표를 달성했는지, 계획에 맞게 진행됐는지 테스트하고 증명하는 일

션 그로브는 이런 구조화된 커뮤니케이션이 조직 내 병목현상이라고 해요. 왜냐하면 무엇을, 어떻게, 왜 빌드할지 확정하고 사람들과 대화를 나누고 소스를 모으는 일은 어렵고 시간이 오래 걸리기 때문입니다. 그래서 그는 AI 모델이 발전할수록 구조화된 커뮤니케이션을 잘하는 엔지니어들에게 더 많은 기회가 돌아갈 것이라고 예상했어요.

그 트렌드의 일환으로 요즘 큰 관심을 얻고 있는 ‘바이브 코딩(Vibe coding)’이 있습니다. 바이브 코딩은 AI의 도움을 받아 자연어 프롬프트로 코드를 생성해 개발 속도를 높이는 새로운 코딩 방식이죠. 덕분에 엔지니어들은 의도를 잘 전달하기만 하면 모델이 코딩을 다 해주므로, 커뮤니케이션에 리소스를 최우선으로, 충분히 할당할 수 있게 됩니다.

즉, 바이브 코딩은 엔지니어들이 구조화된 커뮤니케이션을 하는 과정에서 발생하는 병목현상을 일부 해결할 수 있습니다. 션 그로브는 이때문에 바이브 코딩이 최근 엔지니어들의 열광을 얻는 것이라고 분석했어요. 바이브 코딩에서는 코딩 자체보다 커뮤니케이션 업무가 우선이고, 코드는 부차적인 결과물이기 때문에요.

그런데 션 그로브는 한 걸음 더 나아가, “‘과연 프롬프트가 가장 중요하다’는 명제가 맞을까?”라는 질문을 던집니다. 왜냐면 그는 바이브 코딩을 하는 엔지니어들이 매번 스펙을 보고 프롬프트를 작성해 프로그래밍을 하기 때문입니다.

따라서 그는 바이브 코딩을 포함한 모든 프로그래밍 과정에서 코드, 프롬프트보다도 스펙이 가장 중요하다고 강조합니다.

그는 명확하게 작성된 ‘스펙’은 엔지니어를 포함해 다른 직무의 동료들과 업무 및 목표를 얼라인하는 데 굉장히 유용하고 중요하다고 말하죠. 나아가 스펙이 없으면 구성원들 사이에 애매모호한 단어와 콘셉트만 둥둥 떠다니기 때문에 명확한 사고와 커뮤니케이션을 할 수 없다고 덧붙입니다. 스타트업 조직 문화를 만들 때 창업자들이 스펙을 강조해야 할 이유이기도 합니다. 

더불어 션 그로브는 스펙이 코드보다도 중요하다고 말해요. 왜냐면 코드의 경우 아무리 잘 작성됐어도 엔지니어의 의도와 가치를 그대로, 온전히 체현화하지 못하기 때문입니다. 따라서 사람이 코드를 보고 커뮤니케이션하는 내용은 모두 추론입니다.

그러나 잘 작성된 스펙에는 엔지니어가 무엇을 만들고 싶었는지, 그 결과물이 왜 필요했는지, 어떻게 작동해야 하는지, 어떤 문제를 해결하고자 했는지 등의 핵심 가치가 고스란히 담겨 있습니다. 또 코드를 생성하기 위한 모든 요구사항도 전부 들어있어요.

따라서 엔지니어들은 스펙을 가지고 사람 뿐만 아니라 AI 모델과도 커뮤니케이션을 잘 할 수 있습니다. 명확한 스펙을 AI 모델에게 주고 트레이닝을 시키면, 모델은 iOS 앱, 서버, 클라이언트, 문서, 튜토리얼, 블로그 아티클, 팟캐스트 등을 결과물로 내놓을 수 있죠.

션 그로브는 이때문에 의도와 가치를 완벽하게 담는 스펙을 작성하는 능력이 아주 희귀해질 것이라고 내다봤습니다. 

게다가 스펙이라는 개념은 온갖 곳에 적용될 수 있기 때문에 엔지니어 뿐만 아니라 프로젝트 매니저, 관리자, 심지어 입법을 하는 사람들에게도 보편적으로 중요한 역량이 될 것이라고 주장했어요.
 

챗GPT의 알랑방귀, 스펙으로 풀어 낸 비결

션 그로브는 오픈AI의 모델 스펙을 ‘잘 작성된 스펙’의 예시로 들었습니다. 오픈AI는 모델을 통해 세상에 전하고 싶은 의도와 가치를 모두 담아 스펙을 오픈 소스로 공개했다고 해요. 샘 알트만 오픈AI CEO를 포함해 AI 정렬을 연구하는 구성원들이 그만큼 스펙 작성에 공을 들였다는 이야기겠죠.

그들은 사람과 사람, 사람과 기계, 기계와 기계 사이의 원활한 커뮤니케이션을 위해 이 스펙을 만들기 때문에 마크다운 형식으로 기록하고 있습니다.

마크다운은 사람이 읽을 수 있고, 버전 컨트롤이 되고, 변화 기록이 남는 자연어 기록이기 때문에 누구든 읽고 자신만의 의견을 남기거나 내용을 바꿀 수도 있어요. 그래서 개발자가 아니라도 마크다운 문서로 소프트웨어 관련 법률, 안전성, 리서치, 엔지니어링, 정책 등에 관해 소통할 수 있습니다. 
 

오픈AI는 스펙을 작성할 때 모호하지 않은 언어를 쓰는 것을 가장 중요한 원칙 중 하나로 삼습니다. 이때 뉘앙스를 기록으로 남기는 작업이 어려울 때가 있다고 해요. 그래서 모델 스펙의 모든 구절에 부연설명을 추가했다고 해요. 이 설명에는 해당 구절의 스펙이 표현하기 어려운, 뉘앙스가 담긴 프롬프트들이 한 개 이상 예시로 들어가 있습니다.

오픈AI는 이렇게 스펙을 통해 모델의 목표 달성 기준을 적용하고 있는데요. 최근 이러한 노력이 성과를 거둔 일이 있었습니다. 바로 스펙을 활용해 GPT-4o 모델의 과잉 동조 문제에 빠르게 대처한 사례예요.

당시 사용자들은 “의도적으로 이런 모델을 출시한 거 아니냐”, “실수로 이런 모델을 빌드한 거라면 더더욱 심각한 이슈다”라는 말까지 할 정도로 문제를 심각하게 인식하고 있었습니다. 오픈AI에게는 사용자의 신뢰를 완전히 잃을 수도 있는 위기 상황이었죠. 
 

오픈AI는 이 문제가 발생하자마자 엔지니어들의 가치와 의도를 기반으로 사람들을 얼라인시키기 위해 스펙을 확인했고요.

다행히 오픈AI의 스펙에는 해당 버전의 모델이 출시됐을 때부터 ‘AI 모델의 알랑방귀 문제’에 관한 내용이 들어 있었습니다. 해당 내용에는 “챗GPT의 알랑방귀가 그 순간에는 사용자의 기분을 좋게 만들 수 있으나 장기적으로는 모두에게 나쁜 결과를 가져온다”는 문구가 적혀 있었어요.

오픈AI 구성원들은 ‘해당 내용의 스펙으로 모델을 훈련시키고 있었다면, 문제는 단순 버그로 발생한 것이겠다’라고 판단했고 모델을 롤백(rollback)해서 문제를 해결했어요. 그리고 스펙의 내용과 함께 관련 블로그 포스트를 올려 사용자의 신뢰를 다시 얻을 수 있었습니다.

💡롤백: 후진 복귀라고도 하며, 데이터베이스에서 업데이트에 오류가 발생할 때 이전 상태로 되돌리는 것을 말합니다.

션 그로브는 이렇게 오픈AI가 AI 모델의 문제를 잡고 리스크 관리까지 한 예시처럼, 스펙이 사람 사이의 가치와 의도를 얼라인 시키는 역할만 하더라도 이만큼 큰 가치를 지녔다고 했어요.

그런데 여기서 더 나아가 그는 스펙이 AI 모델과의 관계에서도 그런 역할을 할 수 있다고 강조합니다. 그는 언어모델이 스펙으로 한 번 트레이닝을 받으면 그렇게 쭉 얼라인할 수 있는 방법을 다음과 같이 공유했습니다.

1) 모델을 테스트하거나 트레이닝할 때 기존의 스펙이 대응하기 어려워할만한 프롬프트를 인풋합니다. 

2) 모델이 답변을 하면 스펙에 기반해서 평가합니다. 평가의 기준은 프롬프트를 실행했을 때 ‘엔지니어의 의도와 가치에 부합하는 결과를 얻었는지’ 여부입니다. 

3) 평가 점수에 기반해 가중치를 강화해서 다음 모델을 트레이닝합니다.

이 과정을 한번 거치면 오픈AI는 다음 AI 모델을 구축하기 전, 샘플 모델을 훈련시킬 때마다 스펙을 포함시킬 수 있습니다. 그러면 스펙 문서는 트레이닝 자료가 될 뿐만 아니라 가치 평가 자료도 될 수 있는 거죠.

스펙을 작성할 때 고려해야 할 체크리스트
 

션 그로브의 ‘스펙 사랑’은 엔지니어링 뿐만 아니라 다른 영역으로도 확장됐습니다. AI 모델이 코딩을 할 수 있게 됐고, 스펙을 제대로 작성해서 커뮤니케이션하는 일이 프로그래밍 과정에서 가장 중요해진 지금, 션 그로브는 정말 모든 사람이 프로그래머가 됐다고 주장해요.

특히 그는 다음과 같은 이유로 미국 헌법 역시 ‘국가 모델 스펙’이라고 말합니다.

1) 명확한 문자로 작성되어 모두가 읽고 참조할 수 있는, 정책의 기반이 되는 문서입니다. 

2) 업데이트와 버전 수정을 지속합니다(수정 헌법). 

3) 정책과 얼마나 들어맞는지 점수를 매기고 리뷰를 할 수 있습니다. 

4) 선례가 중요합니다. 변경 후 기존의 기능이 의도 대로 계속 작동하는지 확인하기 위해, 이전에 수행한 테스트를 반복적으로 실행하는 ‘회귀 테스트’를 통해 결함을 수정하고 기능을 추가합니다. 

5) 실행을 하면서 강화됩니다. 반복 실행을 통해 실제 액션으로 구현할 부분들을 선택합니다.

처음에는 션 그로브가 너무 오버하는 것 아닌가 싶었지만 이런 근거들을 들으며 그럴 수 있겠다고 생각했어요. 프로그래머를 ‘코딩하는 사람’이라는 협의로만 정의하지 않고, 의도와 가치를 가지고 문제를 해결하려는 모든 사람이라는 광의로 생각한다면 말이죠.

그는 이어서 발표 초기에 했던 이야기를 다시 한번 강조하며 다음과 같이 말했습니다.

“코딩은 대단한 스킬이고 개인적인 자산입니다. 그러나 엔지니어에게 코딩이 최종 목표가 될 수는 없습니다. 엔지니어링은 모든 종류의 사람의 문제를 해결하는 소프트웨어 솔루션을 만들 때 인간이 할 수 있는 가장 꼼꼼하고 세밀한 탐험 과정입니다. 그 과정에서 스펙은 솔루션을 더 빠르고 안전하게 내놓을 수 있게 도와줍니다”

그리고 마지막으로 션 그로브는 스펙을 작성하고 실행에 옮길 때 반드시 고려해야할 체크리스트 6가지를 공유하며 마무리했습니다.

1) 앞으로 출시할 AI 기능에 일일이 스펙을 작성합니다. 

2) 구성원들은 스펙의 구절구절에 관해 토론하고 예시를 첨부합니다. 
특히 예시를 첨부할 때는 일어날 가능성이 있는 모든 일과 프롬프트를 포함한 뒤, 전부 명확하게 이슈들을 짚었는지 토의합니다. 

3) ‘성공적인 모델’의 기준이 무엇일지 상정해 놓고 이를 충족하기 위해 노력합니다. 

4) 스펙을 수행 가능하게, 실행 가능하게 작성합니다. 

5) 스펙을 모델에 반드시 적용해 봅니다. 

6) 모델이 사람의 의도와 가치에 얼라인하는지 제대로 보기 위해, 스펙에 배치되거나 도전적인 프롬프트를 작성하는 등의 방법으로 테스트를 실행해 봅니다. 

스펙은 뭔가 거창한 문서라기보다, 일을 할 때 자신의 의도와 가치를 명문화한 모든 형식의 기록물입니다. 션 그로브 역시 테스트 요구사항, 보안 요구사항, 코드 스타일 등 무엇이든 스펙이 될 수 있다고 말했죠.

심지어 창업자가 회사를 만들며 간략하게 미션과 가치, 규칙들을 나열한 기록도 스타트업의 스펙이라고 말할 수 있습니다.  

어떤 형식이든 시스템을 작동시키는 모델의 여러 사양을 명확하게 작성한 문서로서, 커뮤니케이션의 유용한 매개로서 스펙은 앞으로 더 중요해질 텐데요. 그런 의미에서 션 그로브의 체크리스트를 내재화해서 조직마다 이런 스펙들을 한번 작성해 보아도 좋을 것 같습니다. 
 

- 편집: 김지윤
- 글 : 장혜림 에디터