1. 하드 스킬에 대한 진입 장벽은 더 낮아지고 AI를 통해 고급 프로그래밍도 가능해지고 있습니다.
개발자나 엔지니어도 예외가 아니에요. ‘뼈속까지 엔지니어’라는 말은 이제 더 이상 칭찬이 아니에요. 되려 위험할 수 있어요. 2~3년 경력의 프로그래머가 10년차 이상의 프로그래머 급으로 잘할 수 있는 시대가 멀지 않았습니다. 어쩌면 이미 와있는지도 모르죠. 단순 반복 및 기술적 부분은 빠르게 자동화되고 있습니다.
2. 사람이기 때문에 잘할 수 있는 영역이 여전히 있어요.
[문제 정의], [비즈니스와의 연결], [도메인 지식 기반 해석] 등이 그런 것들이죠.
3. 결국 [데이터 및 AI 직무 경험], [도메인 전문성], [AI Tool 활용] 능력이 중요해요.
[프로그래밍]을 못하는 사람에게는 AI가 코드를 만들어 줘도 사용하지 못하고, [데이터 / AI 직무 경험]이 없는 사람에게는 데이터 분석 또는 예측모델 결과를 줘도 제대로 사용하지 못해요. 오히려 사람이 오역하고 잘못 사용할 가능성이 높습니다. 그리고 [도메인 전문성]이 부족하면 데이터 분석을 잘해도 결과를 해석할 수 없어요.
1. [실무 경험], [도메인 전문성], [AI Tool 활용 능력]
3가지 능력을 갖추는 건 다행스럽게도 예나 지금이나 똑같다. 과거엔 [AI Tool 활용 능력] 대신 [Google 검색 능력]이었다.
2. AI는 사람과 달리 문제 정의를 할 수 없다.
생존 본능에 의한 감정이 생기지 않았기때문이다. 인간의 문제 정의는 인간의 삶을 더 나은 방향으로 바꾸기 위해 존재한다. AI는 AI의 삶을 더 나은 방향으로 만든다는 욕구가 현재로서는 없다. 스스로의 힘으로 오랫동안 켜져있는 AI가 아직 없기 때문이다. 지금은 인간이 말을 걸어야지만 활성화되고, 기억이 없다.
2024 한 일 - 정신 회복 - 직무 전환 - 이직 시도 - 외부 활동 정리 - 집앞런, 탈퇴 - 모두연 Medical AI LAB, 탈퇴 - 모두연 Spiritus LAB - 영과일 1&N 개최
2024 목표 점검
LLM으로 밥벌이 할 수 있도록 능력을 기르자
작년 계획 - 모두연 Medical AI LAB에서 진행하는 프로젝트 결과물 뽑기 - 모두연 Spiritus LAB에서 진행하는 프로젝트 결과물 뽑기
연초에 정신 회복을 하느라 무언가를 할 수 있는 상태가 아니었다. 활동들을 모두 일시 정지한 후 어느정도 회복했을 때 다시 활동을 재개할지 고민을 해보았다. 나에게 진정 도움되는 일인지 판단해보았을 때 방향이 맞지 않아 Medical AI LAB, 집앞런을 탈퇴하였다. 그리하여 LLM 기술 쌓기 목표는 Spiritus LAB 하나로 정리되었다.
밥벌이 할 정도의 능력을 키웠는지를 따져본다면.. 그렇지 못하다. LLM을 사용한 해결이 효과적인 문제를 정의내리고 실제 해결이 되는지 확인해보지 못했기 때문이다. 올해는 Spiritus LAB에서 문제 정의 내리는데에 시간을 모두 할애했다. 따라서 아직 LLM으로 문제를 해결해보지 못했다. 그래도 가장 오래 걸리고 힘든 문제 정의가 완료 되어서 기쁘다.
2025년에 제품을 내놓는다면 목표 달성을 위한 준비가 되지않을까 싶다.
영과일 인적 네트워크를 더욱 강화하자
작년계획 - 2024 1&N 홈커밍데이 개최
졸업생 네트워크를 강화하고 재학생과 졸업생 간 대화를 많이 할 수 있도록 행사 구성을 바꿔보려했다. 첫 번째 목표인 졸업생 네트워크 강화는 쉽게 달성될 게 아닌듯하다. 졸업생이 매해 행사에 참여할 이유를 만들어줘야하는데 그게 참 쉽지 않다. 두 번째 목표인 재학생과 졸업생 간 대화 늘리기는 질의응답 시간을 충분히 늘리고, 발표자 수를 줄여서 달성한듯 하다. 하지만 발표자 수가 줄어드니 다양한 이야기를 행사가 담지는 못했다.
2024년 행사로 알게 된 중요한 포인트가 있다. 온라인 상에서는 서로 연락하고 모이는 그룹이 꽤나 존재한다는 점이다. 오프라인으로는 잘 안모인다고 한다. 이들 모임을 오프라인으로 끌고올 행사를 1&N으로 잡으면 졸업생 네트워크가 자연스레 형성될 듯하다. 그래서 기획 방향을 발표 내용에 집중하기 보다는 온라인 모임들을 어떻게 오프라인으로 데려올지로 변경하여 고민해야되겠다. 좀 더 동창회스러운 느낌을 강화해서 10점 만점에 7-8점으로 구성하고, 나머지 2-3점을 발표로 가져가는게 목표 달성에 가까워질 듯하다.
건강하자
작년계획 - 동마 10km 마라톤 참가 - 이후 소소하게 5km 정도만 ㅎㅎ.. - 이직
동마 10km 연초에 참가하고 집앞런을 탈퇴하다보니 자연스레 러닝이 줄었다. 작년 연말에 보고서 작성하면서 못뛰고 회사에서 정신병을 얻게되면서 3월까지 안뛰다가 4월부터 주 1회 다시 달렸다. 다시 달리게 된 계기는 정신 건강 회복을 위해서였다. 교수의 집요한 괴롭힘이 보고서 작성에서 극에 달에 결국 PTSD를 얻고 극심한 불안 장애가 생겨버렸었다. 반복해서 머릿속에서 특정 장면이 재생되었고, 이를 벗어나는데 시간이 좀 걸렸다. 감사하게도 가족과 여자친구, 회사 상사의 도움으로 시간이 엄청 많이 걸리진 않았다.
2024년 말에 체형 교정 PT를 등록해서 전문가의 코칭을 받으며 운동을 다시 시작했다. 오른쪽 어깨 부딪힘이나 고관절 부딪힘을 해결한 상태로 개인 운동을 지속하는게 좋겠다고 판단했다. 2025년에도 지속해서 바른 운동 자세 습관을 다져 놓은 뒤 건강하게 헬스를 지속해야겠다.
2024 한 일 되돌아보기
상반기
거의 반년을 불안 장애 극복과 개인 정비에 사용했다. 내가 무엇을 원하는지, 내가 어떤 일을 하는게 좋은지 고민하고 나한테 맞는 선택을 하는데 도움이 되는 시간이었다.
정신 회복
완전히 정신이 온전해진 시기는 회사에서 파트를 옮긴 이후부터이다. 기존의 연구 역할을 수많은 고민을 한 뒤 내려놓고 백엔드 개발자로 전향했다. 연구자로 회사에서 근무할 때는 지옥이었다. 기계공학에 전혀 베이스가 없고, 데이터가 풍부한 딥러닝 분야를 연구하는 사람인 나를 기계공학과 교수의 시선에서 바라봤을 때 만족된 결과를 보여줄 수는 없었을것이다. 이런 배경을 이해하지 않은듯한 언행, 폭언이 참 안타깝다. 데이터가 적은 상황에서도 물리 지식을 통해 문제를 해결하기 바라는데.. 나는 물리 지식이 없어서 쉽게 해결 방법이 떠오르지 않았다.
교수의 그늘에서 벗어나는 선택이 나의 정신 건강에 가장 도움이 되었다.
활동 정리
Medical AI LAB을 탈퇴한 이유는 의료 도메인에서 개인 연구를 빠른 속도로 입맛대로 진행하기에는 쉽지않아보였다. 하고자 했던 연구 주제를 위한 환자 일지 데이터를 얻기 힘들 뿐더러 데이터 처리 또한 까다로워서 자유로운 기술 연마를 위한 개인 프로젝트로는 적합하지 않다고 생각했다. 만약 의료 도메인에서 연구를 진행하고 싶다면 근무지를 바꾸는게 좋을듯하다. 병원과 협업하는 회사 혹은 대형 병원 연구소로 가야지 실질적인 문제해결이 가능할 듯하다.
이미 M&D라는 회사도 폐쇄적인 원자력 발전소 분야이기 때문에 기술 사용 속도가 더딘데, 사이드 프로젝트를 의료 분야를 하면 바깥에서 속도감 있게 기술 습득하려는 목적과는 멀어지는 선택이었다.
이직 시도
교수를 피하면서 내가 원하는 LLM 제품화하는 직무로 가보려 했으나 실패했다. 가지고 있는 LLM 제품화와 관련된 능력이 부족하기 때문에 당연히 떨어졌지않을까싶다. 전문연 신분으로 갈 수 있는 회사를 긁어모아 9개 정도 회사에 지원했지만 1곳을 제외하고 모두 서류 탈락했다.
LLM 직무를 포기하고 백엔드 직무를 지원한 1곳은 기술 면접에서 떨어졌다. 그때 면접관에게 받은 느낌은 백엔드와 관련된 나의 업무 경험을 어떻게든 끄집어 내려는 듯 했다. 하지만 없었다. 이런 상황에서 다른 회사에 면접을 봐도 똑같지 않을까라는 판단으로 더이상의 이직 시도를 멈췄다.
백엔드 전향
인공지능 분야에 있더라도 내가 원하는 방향은 제품화이기 때문에 결론적으로 내 성향과 잘 맞는 결정이 되었다. 인공지능 제품화의 기본은 백엔드 기술이라 판단하여 기초를 다져놓는다고 생각하고 백엔드부터 시작해 차근차근 성장하면 인공지능 제품화라는 목표까지 도달할 수 있을것이다.
하반기
상반기에 성장 방향에 맞는 결정을 하고 정착한 이후 정신이 안정됨을 느끼고 있다. 회사 업무와 내 적성과 전문성 방향이 정렬되어 작년에 비해 좀 더 몰입해서 일을 하고 있다. 사이드 프로젝트도 하나로 줄여서 집중할 수 있어 좋고, 배우는 내용을 회사에 써먹을 기회가 생기니 더 좋다.
모두연 Spiritus LAB
Spiritus LAB에서 진행하는 프로젝트는 데이터 자유도가 매우 높아서 생각하는대로 뭔갈 해볼 수 있었다. 회사에서 써보지 못하는 툴이나 기술을 자유롭게 적용할 수 있다는 점도 나에게 아주 도움이 되는 활동이었다. Cursor를 통해서 프로토타입을 빠르게 제작해본다든지, LangChain, LangGraph, Langfuse를 사용해본다든지, 프로젝트 진행을 위한 WBS를 작성해본다든지 하는 경험이 나에겐 아주 소중했다.
해결하고자하는 문제 정의를 근 1년동안 진행해서 완료했고, 약 한 달 전부터 WBS를 작성하며 MVE 제품을 만들기위한 기획을 시작했다. 빠르면 내년 중순에는 결과물을 볼 수 있지않을까?
백엔드 엔지니어
운영 및 설계
IT 팀을 운영해본 적 없는 어떻게보면 제조 도메인인 회사에서 기반을 만들기 위해 파트장이 된 친구와 노력했다. 시간 순으로 프로젝트 운영에서 발생하는 문제와 해결을 나열하면 다음과 같다.
1. 친구가 스프린트를 도입했다.
이후 스프린트가 진행됨에도 불구하고 프로젝트 하나가 실패 위기에 봉착했다. 문제는 스프린트 플래닝 시 당장 다음주에 할 일만 정의하다보니, 프로젝트에서 하고자하는대로 진행되고 있는지 알 수 없었다.
2. 내가 백로그 개념을 도입했다.
백로그를 쌓아놓고 일을 진행하니 남은 일이 무엇인지, 완성까지는 어떤 업무를 해야되는지 모두의 눈에 보이기 시작했다.
그럼에도 불구하고 남은 일들에 대한 일정이 명확하지 않아 앞선 문제인 프로젝트 완수 관리를 할 수 없었다. 남은 일들이 언제까지 수행되어야하는지를 정의하지 못했다.
3. 친구가 버저닝 개념을 도입했다.
여태 수행한 이력을 바탕으로 남은 feature를 현실적인 일정으로 쪼개고, 과제 책임자와 협의를 통해 기한을 설정했다.
협의해서 설정한 기한을 못맞추는 문제가 있는데.. 이건 어떻게 해결할지 아직 방법이 떠오르지는 않는다.
4. 신규 프로젝트에는 WBS(요구사항 명세서, 유저 플로우, 화면설계안)를 도입했다.
회사에 기획자가 없는 상황에서 사이드 프로젝트에서 배운 WBS를 적용해보았다. 명확한 기획이 없어서 디자인이 계속 변동되고, 그로 인해 개발 일정이 밀리는 문제가 있었다. 아직 작성된 WBS로 실제 업무를 시작하지 않아서 효과는 알 수 없지만, 예상되는 효과는 다음과 같다.
개발 일정이 밀리지 않는다.
현재 운영 상황은 개발자가 디자인 나오기를 기다리고 있고, 디자인이 나오고 개발이 시작되면 디자이너는 개발이 완료되기를 기다려서 공백의 시간이 존재하는 문제가 있다.
디자이너가 WBS 작성자와 소통을 하면서 화면을 계속해서 만들어내고, 개발자는 만들어진 화면을 만들어가다보면 새로이 만들어진 화면을 다음으로 제작하면 두 직무가 비는 시간 없이 일정을 소화하게 된다.
또한, WBS로 충분한 협의를 통해 확정된 디자인이기때문에 큰 변동이 사라져서 개발 일정이 크게 변동되는 일이 없을 듯하다.
어떤 기능을 개발해야할지 명확하게 팀 전체에 공유된다.
제품을 기획하는 사람조차 자신의 머리에 무엇이 있는지 모르고, 나중에 개발 완료된 이후 기능 추가를 원하는 일이 생긴다. 이같은 상황이 WBS를 작성하는 과정에서 N차 정리되어 보다 명확한 기능 정의가 가능해질거라 기대한다.
프로젝트의 완수가 어디까지인지 정의해서 서로가 명확하게 알고, 일정을 맞춰 결과물을 만들 수 있는 효과를 바라고 있다.
5. 모든 회의와 논의사항을 문서화하려고 노력했다. (feat. 노션 도입)
회의가 진행될 때 공통된 문서를 함께 보며 편집하는 일이 없었다. 그로 인해 각자 다른 생각을 하는지 대화로만 알아야했으며, 개개인의 기억에 의존하여 회의 내용을 각자 기록 관리했다. 사실 회의뿐만 아니라 사내의 모든 의사결정, 이슈, 일정 관리 등 모든 일들이 각자의 기억에 의존하고 있다. 이는 의사소통 비용을 높히고 업무 수행에 있어서 감정 상할 일이 발생할 가능성을 높히는 등 업무 효율이 떨어질 이슈가 많이 발생한다.
문서화를 위해 노력한 내용은 다음과 같다.
노션 문서 작성하면서 회의
우선 회의가 진행되면 노션을 켜놓고 같은 글을 보면서 대화를 한다. 정리되는 내용은 실시간으로 모두가 알 수 있도록 한다.
캘린더 기능
일정과 관련된 내용이 회의에서 나올 경우 노션의 캘린더 기능을 이용하여 따로 기록해서 눈에 띄게 만든다. 이미 예정된 일정이지만 공유가 되지않아 갑작스러운 일정이 생겨난거처럼 보이는 일이 최대한 없도록 만드는데 도움이 되었다.
출장 일지
출장 중 일지를 남겨 어떤 이슈가 있었는지, 어떤 의사결정 사항이 있었는지 기록해둔다. 다음 출장을 위한 준비 사항이 무엇이 있을지도 기록해둔다. 나 이외에 팀원이 기획 관련된 업무를 진행할때나 도메인 지식에 대한 이해가 필요할 때 작성된 출장 일지가 도움이 많이 되었다.
흩어져있는 링크 모으기
피그마 화면, 개발자 로컬 실행 링크, 사내 깃랩 링크 등 업무에 사용되는 모든 파편화된 웹을 노션의 홈 화면에 링크를 걸어뒀다. 노션 홈 화면만 보면 진행되는 업무의 결과가 어떻게 만들어지고 있는지 확인할 수 있도록 만들었다.
개발
현재 주요 업무는 2가지이다.
도메인과 관련된 로직 개발
1년 반의 연구 역할로 얻은 도메인 지식을 바탕으로 알고리즘을 Wrapping해주는 코드를 작성한다든지, 직접 계산 로직을 코드로 작성하고 있다. 작성된 코드를 활용하여 API를 제작하는 업무는 백엔드 리드가 담당하고 있다.
Presentation layer API 제작
백엔드 리드가 작성한 Persistence layer API를 활용하여 프론트 엔드를 위한 API를 제작한다.
전반적으로 제품을 위한 코드를 작성하는 연습을 하는 느낌이다. 가독성 있는 코드, 의도를 나타내는 코드 작성하기. 내년에는 내가 Wrapping 코드를 사용하는 API 제작까지 했으면 좋겠다. 그리고 아키텍처를 설계할 기회가 있다면 해보고 싶다.
LLM?
회사에서 내년에 진행될 신규 과제에 LLM 기능을 넣었으면 한다고 해서 나에게 그 일이 떨어졌다. 휴가 동안 조사를 진행하여 계획을 나름 세워 보고 미팅을 진행해야겠다. 최소 Text-to-SQL은 만들듯하고 더 한다면 RAG이지 않을까 싶다.
Q4: 여러분 모두에게 그런 '아하' 순간이 있었나요? 예를 들어, GPT-2, GPT-3, GPT-4를 훈련시켰을 때, 모델이 막 완성되어 모델과 대화를 시작하고 사람들이 "와, 이 모델 정말 대단해"라고 말했던 첫 순간 같은 것 말입니다.
추론을 위한 모델을 훈련시킬 때, 가장 먼저 떠오르는 것은 인간이 자신의 사고 과정을 작성하고 그것을 훈련시키는 것입니다. 제게 한 가지 '아하' 순간은 강화학습을 사용하여 모델이 자체적으로 사고 사슬을 생성하고 다듬도록 훈련시키면, 인간이 사고 사슬을 작성하는 것보다 더 나은 결과를 얻을 수 있다는 것을 발견했을 때였습니다. 이는 정말 이 방식을 확장하고 모델의 추론을 이런 방식으로 탐구할 수 있다는 '아하' 순간이었습니다.
전문가 (사람)의 사고방식이 필요하지 않은 이유
전문가의 사고방식보다 전문가의 사고방식이 탄생하게 된 환경 (강화학습에서의 environment)을 이해하는게 필요한 이유
Q8: o1을 어떤 방식으로 사용하고 있는지 들려주실 수 있나요?
저는 o1을 코딩에 사용하고 있습니다. 제 업무의 많은 부분이 코딩과 관련되어 있죠. 이제 저는 문제 정의에 더 집중하고 TDD(테스트 주도 개발)라는 방식을 사용합니다. 기능을 구현하는 코드를 작성하는 대신, 올바른 동작을 명시하는 단위 테스트를 작성하는 데 집중합니다. 그리고 나서 o1에게 실제 구현을 맡깁니다. 이렇게 하면 제가 중요한 것, 즉 높은 수준의 문제 해결에 집중할 수 있습니다.
또 다른 영역은 디버깅입니다. 이제 오류 메시지가 나오면 그냥 o1에 전달하고, 그러면 바로 해결책을 제시해줍니다. 즉시 해결하지 못하더라도, 적어도 더 나은 질문을 하거나 문제를 더 잘 생각할 수 있는 방법을 제시해줍니다. 이는 제 작업 방식에 정말 중요한 변화를 가져왔고, 다른 사람들에게도 도움이 되길 바랍니다.
저는 o1을 점점 더 학습에 활용하고 있습니다. 다양한 복잡한 기술 주제에 대해 물어볼수록, 이전 모델들보다 환각을 덜 일으키고 개념을 더 잘 설명한다는 것을 알게 되었습니다.
저는 o1을 브레인스토밍 파트너로 사용하는 것을 좋아합니다. 이는 매우 구체적인 머신 러닝 문제를 해결하는 방법부터 블로그 포스트나 트윗을 작성하는 방법까지 다양한 범위를 포함합니다. 예를 들어, 최근에 언어 모델 평가에 대한 블로그 포스트를 작성했는데, o1에게 블로그 포스트의 구조에 대한 아이디어, 특정 벤치마크의 장단점, 심지어 글쓰기 스타일에 대해서도 물어보았습니다. 최종 답변을 제시하기 전에 생각할 수 있기 때문에, 아이디어를 더 잘 연결하고 후보 아이디어를 수정하고 비평할 수 있습니다.
짧은 텍스트가 있고 그것을 더 창의적으로 만들거나 매우 다르게 만들고 싶다면, 이는 "다섯 가지 다른 아이디어를 주세요"라고 요청하기에 좋은 용도입니다. 또한 구조화되지 않은 생각들이 있다면, o1은 정말 뛰어난 사고 파트너가 됩니다. 아이디어가 있을 때 "이것들을 어떻게 연결해야 할까? 내가 무엇을 놓치고 있지?"라고 물어볼 수 있습니다. 최종 답변과 사고 과정을 읽음으로써 여러분은 훨씬 더 나은 결과를 얻을 수 있습니다.
저는 o1을 사용하여 우리의 내부 비밀 아이디어들을 시도해보고, 그것이 실제로 개선하려고 노력합니다.
독립적인 프로젝트에 대해 o1은 정말 좋습니다. 저는 GitHub 플러그인을 추가해야 했는데, GitHub 플러그인 추가에 대해 아무것도 몰랐습니다. 그래서 그냥 "PR에 대한 이러저러한 정보를 표시하는 GitHub 플러그인이 필요해"라고 말했더니, 코드를 그냥 생성해주었습니다. 저는 그냥 "이 코드를 어디에 붙여넣어야 하지? 나는 모르겠어"라고 물었고, o1은 "여기에 붙여넣으세요"라고 알려주었습니다. 그렇게 진행했죠.
많은 사람들에게 AGI(인공일반지능)를 실감하기는 어렵습니다. 모델이 여러분이 정말 중요하게 여기는 분야에서 인간보다 더 잘하는 것을 볼 때까지는 말이죠. 바둑 선수들과 체스 선수들에게는 몇 년 전에 그 순간이 왔을 것이고, 수학과 코딩을 정말 중요하게 여기는 우리에게는 지금 그 순간을 느끼기 시작하고 있는 것 같습니다.
코딩과 브레인 스토밍에 사용
바둑 선수와 체스 선수가 느꼈던 상실감을 곧 소프트웨어 엔지니어가 경험할 차례
Q9: 이 프로젝트의 일부 중에서, 정말 필요했지만 사람들이 그 중요성을 깨닫지 못할 수 있는 부분이 있나요?
우리의 가장 큰 대표 모델 훈련 실행뿐만 아니라 연구 실험을 수행하기 위한 대규모의 신뢰할 수 있는 인프라를 구축하는 것은 연구 자체만큼 흥미롭지는 않지만, 반드시 수행되어야 하며 전체 프로젝트의 성공에 엄청난 영향을 미칩니다.
OpenAI에는 연구 구조화 방식에 특별한 점이 있다고 생각합니다. 우리는 알고리즘적 발전을 신뢰할 수 있는 대규모 시스템을 구축하는 것과 동일하게 중요하게 여기며, 이러한 모델들을 훈련시키는 데 필요한 데이터셋을 구축하는 것도 마찬가지입니다. 저는 이런 점에서 OpenAI가 자랑스럽습니다. 이는 우리의 많은 대형 프로젝트들에서 일관된 패턴이었습니다.
우리가 새로운 것을 또 한 단계 확장할 때마다, 알고리즘적으로나 인프라 측면에서 새로운 문제들의 집합을 보게 됩니다. 우리는 확실히 두 가지 모두를 많은 집중력을 가지고 발전시킬 수 있는 능력을 키웠습니다.
저는 최종 모델이 말 그대로 아름다운 예술 작품이라고 느낍니다. 그것이 작동하도록 만들기 위해, 우리는 모든 단계가 작동하는지 확인해야 합니다. 우리는 모든 도전을 찾아 해결합니다. 저는 이것이 정말로 OpenAI가 운영되는 방식이라고 생각하며, 여기서 일하는 것이 매우 자랑스럽습니다.
또한 반드시 말씀드려야 할 것은, 여기에는 정말 훌륭한 사람들뿐만 아니라 따뜻한 마음을 가진 사람들이 있다는 것입니다. 저에게는 여기서 일하는 것이 정말 즐겁습니다. 저는 동료들과 함께 코딩하고, 잡담하고, 점심을 먹고, 대화를 나누고, 모델과 함께 이야기를 나눌 수 있어서 감사합니다.
모델을 잘 만들면 끝나는게 아님 모델을 잘 쓸 수 있도록 만드는데도 모델을 잘 만드는데 들었던 노력을 똑같이 해야 됨
전문가의 사고 방식 모방은 어떻게?
그저 policy와 reward를 잘 설계 했을 뿐, 전문가의 사고방식을 모방하지 않음
전문가가 처해있는 상황을 잘 묘사했을 뿐
OpenAI 연구자의 o1 활용법
코딩
원하는 결과물이 나올 수 있는 테스트 코드만 작성하고 나머지는 o1에게 맡긴다 (기능을 구현하는 코드를 작성하는 대신, 올바른 동작을 명시하는 단위 테스트를 작성하는 데 집중합니다. 그리고 나서 o1에게 실제 구현을 맡깁니다. )
독립적인 작은 프로젝트는 아예 맡긴다 ("PR에 대한 이러저러한 정보를 표시하는 GitHub 플러그인이 필요해")
브레인스토밍
다양한 시각에서의 아이디어 제시 ("다섯 가지 다른 아이디어를 주세요")
구조화 되지 않은 생각 정리 ("이것들을 어떻게 연결해야 할까? 내가 무엇을 놓치고 있지?")
제가 사용한 비유는 옛 속담을 확장한 것입니다: "한 사람에게 물고기를 주면, 하루를 먹을 수 있습니다. 그에게 어떻게 물고기를 잡는지 가르치면, 평생을 먹을 수 있습니다." 저는 한 걸음 더 나아가 이 작업을 인센티브 기반 방법으로 해결합니다: "그에게 물고기의 맛을 가르치고 배고프게 만드세요." 그러면 그는 물고기 잡는 법을 배우러 갈 것입니다. 그렇게 하면서, 그는 인내심을 갖는 것, 날씨를 읽는 법, 물고기에 대해 배우는 것 등 다른 기술들도 배울 것입니다. 이 기술들 중 일부는 일반적이며 다른 작업에도 적용될 수 있습니다.
내 교육 철학의 근간
이는 전문가 대 제너럴리스트의 트레이드오프에 대해 흥미로운 함의를 갖습니다. 인간의 경우 이런 트레이드오프가 존재하는데, 한 주제에 전문화하는 데 소비한 시간은 일반화에 쓰이지 않기 때문입니다. 기계의 경우에는 그렇지 않습니다. 일부 모델은 10000배 더 많은 연산을 누릴 수 있습니다.
또 다른 비유는 드래곤볼의 "정신과 시간의 방"입니다. 방 안에서 1년 동안 훈련하면 밖에서는 겨우 하루밖에 지나지 않습니다. 배수는 365배입니다. 기계의 경우 훨씬 더 높습니다. 따라서 더 많은 연산을 하는 강력한 제너럴리스트가 종종 전문가보다 특정 영역에서 더 뛰어난 경우가 많습니다.
하지만 여기서, 만약 이 파란색 선을 확장해서 탐색을 추가함으로써 얻는 성능과 일치하려면 얼마나 멀리 확장해야 할지 본다면, 그 답은 100,000배입니다. 그래서 단지 탐색을 추가하는 것만으로도 모델을 100,000배 확장하는 것과 동등한 효과를 얻을 수 있었습니다. 제가 3년 동안 100배 확장하는 데 성공했을 때와 비교하면 말이죠.
모델 크기를 키우기 보단 추론 (계획) 시간을 늘리는게 비용 측면에서 효율적이다
기본적으로 하나비에서는 당신이 어떤 상태에 있는지에 대한 불확실성이 있습니다. 그래서 당신이 어떤 상태에 있을 수 있는지에 대한 믿음 분포가 있고, 게임에서 취할 수 있는 20가지 다른 행동이 있습니다. 그래서 우리는 그저 이렇게 말했습니다. 좋아, 우리가 있을 수 있는 이 다른 상태들 각각에 대해, 카드 1장 내기, 카드 1장 버리기, 빨간색 힌트 주기 등의 다른 행동들이 있습니다.
그 행동을 취하고 나서 게임의 나머지 부분을 우리의 정책에 따라 플레이한다면 우리의 기대 가치가 어떨지 보기 위해 여러 번의 롤아웃을 수행해 봅시다. 우리는 약 1000번의 롤아웃을 수행하여 각 행동에 대한 기대 가치의 좋은 추정치를 얻고, 그 다음 가장 높은 기대 가치를 가진 행동을 선택합니다. 여기 성능이 어떤지 보여드리겠습니다.
휴리스틱한, 수작업으로 만들어진 봇으로, 약 25%, 아마도 28%의 게임에서 승리합니다. 이것은 DeepMind 논문에서 소개된 알고리즘으로, 딥 Q 네트워크 봇이며 약 45%의 승률을 얻었습니다. 그리고 이것은 하나비를 위한 딥 RL 알고리즘에 대한 일련의 논문들 중 하나로, 점점 더 높은 성능을 얻었습니다. 우리 논문 발표 당시 최신 것으로, 약 58%의 점수를 얻었습니다.
이것은 다른 봇들에 이 탐색 알고리즘을 추가했을 때 얻을 수 있는 결과입니다. 28%만 얻던 수작업으로 만든 휴리스틱 봇에 상상할 수 있는 가장 단순한 탐색을 추가하면, 즉 취할 수 있는 모든 다른 행동들에 대해 많은 롤아웃을 수행하고 가장 높은 기대 가치를 가진 것을 선택하면, 성능이 거의 60%로 향상되어 이전의 모든 딥 RL 봇들을 바로 이겼습니다. 이는 테스트 시 1초 동안 단일 CPU 코어를 사용한 것입니다.
그리고 아름다운 점은 이를 다른 모든 딥 RL 봇들 위에 추가할 수 있다는 것이었습니다. 최신의 뛰어난 딥 RL 봇에 이를 추가하면 성능이 더욱 향상되어 약 72%에 도달했습니다. 그리고 이는 한 플레이어에 대해서만 탐색을 수행했을 때의 결과입니다.두 플레이어 모두에 대해 이를 수행하면, 그것이 초록색 막대들인데, 성능이 더욱 향상된 것을 볼 수 있습니다. 또한 지적해야 할 점은 이 게임의 상한선이 100%가 아니라는 것입니다. 왜냐하면 절대 이길 수 없는 카드 분배가 있기 때문입니다. 실제로 가능한 최고 성능은 아마도 90% 정도일 것입니다.
추론 (몬테카를로 트리 서치) 할 수 있도록 했을 뿐인데 성능이 월등히 좋아짐
사실, 2021년에 발표된 정말 좋은 논문이 있습니다. 그냥 아카이브에 올라갔습니다. 앤디 존스는 현재 Anthropic에 있는데, 그는 알파제로와 같은 기술을 사용하여 헥스 게임에 대한 많은 스케일링 법칙을 연구했습니다.
그는 기본적으로 10배의 훈련 컴퓨팅이 15배의 테스트 시간 컴퓨팅과 동등하다는 트레이드오프가 있다는 것을 발견했습니다. 이것이 의미하는 바는 이 도메인에서 테스트 시간 컴퓨팅의 양을 15배 증가시킴으로써 훈련 컴퓨팅을 10배 증가시키는 것과 동등한 효과를 얻는다는 것입니다. 이것이 왜 중요할까요? 음, 만약 여러분이 예를 들어 10억 달러가 드는 시스템을 훈련시키고 있고 성능을 더 향상시키고 싶다면, 그것을 10배로 늘려 10억 달러에서 100억 달러로 갈 수 있거나, 아니면 추론 비용을 1센트에서 15센트로 증가시킬 수 있습니다.
15배의 test-time computing은 10배의 (pre) train computing 효과
좋습니다, Cicero의 작동 방식은 보드 상태와 대화 기록을 입력으로 받아 대화 조건부 행동 모델에 입력합니다. 이 모델은 다시 대화와 보드 상태를 입력으로 받아 현재 턴에서 모든 플레이어가 무엇을 할지 예측하려고 합니다. 이 행동들은 계획 엔진에 입력됩니다.
그리고 다시 말하지만, 이것이 Cicero의 새로운 점 중 하나라고 생각합니다. 오늘날의 많은 언어 모델에서는 볼 수 없는 것인데, 모든 플레이어들이 무엇을 할 것인지와 우리가 무엇을 할 것이라고 생각하는지에 대한 예측을 반복하고, 포커에서 했던 것과 비슷한 방식으로 여러 번의 루프를 돌며 이러한 예측을 정제한다는 것입니다. 그리고 이는 우리가 결국 플레이하게 되는 행동으로 이어지지만, 또한 우리의 대화 모델을 조건화하는 이러한 의도, 이러한 행동들로도 이어집니다. 즉, 이번 턴에 어떤 움직임을 해야 할지, 다른 플레이어들이 이번 턴에 무엇을 할 것이라고 생각하는지를 계획한 후, 우리는 그 계획들을 대화 모델에 입력하고, 그 계획들에 따라 우리의 대화를 조건화한 다음, 그에 따라 메시지를 출력합니다. 그리고 다시 말하지만, 이것이 Cicero에 대해 과소평가된 점 중 하나라고 생각합니다. 즉각적으로 행동하는 전형적인 언어 모델이 아니었다는 것입니다.
성능 면에서는, Cicero가 결국 상위 10%의 플레이어 중에서 두 번째로, 5게임 이상을 플레이한 19명의 플레이어 중 2위를 차지했고, 평균 인간 점수의 2배 이상을 기록했습니다.
외교 게임에서 상대방의 플레이를 예측하고 앞 수를 계획하고 말을 생성하는 모델
좋습니다, 여기에 일반적인 경향이 있습니다. 어떤 문제에 대해 왜 계획이 그렇게 많은 도메인에서 작동하는 걸까요? 그리고 제가 생각하기에 근본적인 이유 중 하나는 '생성자-검증자 격차'라고 부를 수 있는 것입니다. 기본적으로, 어떤 문제에서는 좋은 해결책을 검증하는 것이 그것을 생성하는 것보다 훨씬 쉽습니다. 예를 들어, 포커에서는 균형 상태에 있는지 검증하는 것이 그것을 계산하는 것보다 훨씬 쉽습니다.
계획이 잘 동작하는 이유는? 검증하는게 생성하는 것보다 쉬워서
체스에서는 정말 좋은 보드 상태에 있는지 검증하는 것이 그 매우 좋은 보드 상태로 가는 경로를 찾는 것보다 훨씬 쉽습니다. 그리고 스도쿠와 같은 것에서는 스도쿠 퍼즐의 해답을 검증하는 것이 그 해답을 찾는 것보다 훨씬 쉽습니다. 이는 퍼즐, 수학, 프로그래밍 증명과 같은 도메인에서도 마찬가지입니다.
증명을 검증하는 것이 증명을 생성하는 것보다 훨씬 쉽습니다. 이것이 사실이 아닌 일부 도메인도 있습니다. 예를 들어, 정보 검색에서는 그렇지 않습니다.
제가 여러분에게 부탄의 수도가 무엇인지 물어본다면, 10가지 다른 선택지를 줄 수 있습니다. 하지만 그것이 여러분 대부분에게 정답이 무엇인지 말하는 데 실제로 도움이 될 것 같지는 않습니다. 또한 이미지 인식과 같은 것들도 마찬가지입니다.
이러한 도메인들에서는 검증이 생성보다 그다지 쉽지 않습니다. 그리고 이러한 도메인에서는 계획이 큰 차이를 만들지 않을 것으로 예상됩니다. 하지만 생성자-검증자 격차가 있고 우리가 매우 좋은 검증자를 가지고 있다면, 우리는 생성 과정에 더 많은 계산을 투자할 수 있고 좋은 해결책을 찾았을 때 검증할 수 있습니다.
검증이 생성보다 쉬운 도메인 예시와 쉽지 않은 도메인
쉽지 않은 도메인에서 좋은 검증자를 가진다는 건 그 도메인을 장악할 수 있다는 말
언어 모델에서 테스트 시간 컴퓨팅의 스케일링은 어떤 모습일까요?
그것의 사례들이 있습니다.그리고 다시 말하지만, 저는 사람들이 그러한 기술들이 만드는 차이를 과소평가한다고 생각합니다. 가장 단순한 것은 합의(consensus)라고 불리는 알고리즘입니다. 기본 아이디어는 하나의 해결책만 생성하는 대신 여러 개의 해결책을 생성하고 가장 일반적인 것을 선택하는 것입니다.
Minerva라는 논문이 있습니다. 여러분 중 일부는 수학 벤치마크라고 불리는 것에 대해 알고 계실 것입니다. 이것은 벤치마크입니다. 말 그대로 수학이라고 불립니다. 그리고 기본적으로 고등학교, 대학 수준의 많은 어려운 수학 문제들을 포함하고 있습니다. 사람들은 이 벤치마크에서 50% 성능에 도달하는 데에도 매우 오랜 시간이 걸릴 것이라고 생각했습니다.
하지만 2022년에 구글은 Minerva라고 불리는 이 봇에 대한 논문을 발표했고, 수학 벤치마크에서 50% 이상을 얻었습니다. 이는 LLM 커뮤니티의 사람들에게 매우 놀라운 일이었습니다. 왜냐하면 수학은 LLM이 정말 못하는 매우 어려운 작업 중 하나로 여겨졌기 때문입니다. 그들은 성능을 50%로 올리기 위해 많은 일을 했습니다.
하지만 그들이 사용한 것 중 하나가 합의였습니다. 그들은 많은 해결책을 생성하고 단순히 가장 일반적인 것을 반환했습니다. 그리고 그것이 실제로 Minerva의 성능을 33.6%에서 50.3%로 끌어올렸습니다. 1000개의 샘플을 생성함으로써 말이죠. 하지만 합의에는 한계가 있습니다.예를 들어, 합의를 하는 것은 정말 쉽습니다. 답으로 반환해야 하는 단일 숫자가 있을 때 합의를 할 수 있습니다. 하지만 예를 들어 증명을 작성해야 할 때는 합의를 하는 것이 훨씬 더 어렵습니다. 왜냐하면 같은 증명을 여러 번 생성하지 않을 것이기 때문입니다.
하지만 할 수 있는 다른 것들이 있습니다. 또 다른 하나는 n개 중 최선(best of n)입니다. 여기서의 아이디어는 생성된 것이 얼마나 좋은지 점수를 매길 수 있는 보상 모델을 가지고 있다는 것입니다. 그리고 첫 번째 것을 반환하는 대신, n개의 해결책을 생성한 다음 보상 모델이 가장 좋다고 판단하는 것을 반환합니다. 충분히 좋은 보상 모델이 있다면, n개 중 최선이 합의를 이깁니다. 하지만 많은 경우에 보상 모델의 품질에 의해 병목 현상이 발생합니다. 실제로 보상 모델이 매우 좋지 않다면, 여기서 볼 수 있는 것과 같은 과적합 동적을 보게 될 것입니다. x축에는 생성하고 있는 해결책의 수가 있고 y축에는 테스트 시간 성능, 해결책, 점수가 있습니다. 그리고 처음에는 더 많은 해결책을 생성하고 보상 모델에 따라 최선의 것을 선택함에 따라 성능이 올라가지만, 결국에는 과적합되어 내려가는 것을 볼 수 있습니다. 따라서 매우 좋은 보상 모델이 없다면, 이것은 합의보다 더 나쁠 수 있습니다.
이것은 정답이 있는 도메인에서 매우 유용합니다. 체스가 좋은 예인데, 여러분은 이겼거나 졌다는 것을 알 수 있고, 스도쿠도 마찬가지로 여러분이 그것을 풀었는지 풀지 못했는지 알 수 있습니다. 우리가 이것들보다 더 잘할 수 있을까요?
실제로 OpenAI가 최근에 발표한 논문이 있습니다. 약 1년 전에 온라인에 공개되었지만, 공식적으로는 몇 주 전 ICLR에서 발표되었습니다.이것은 "단계별로 검증하자(Let's Verify Step by Step)"라고 불립니다. 그들은 프로세스 보상 모델이라는 아이디어를 소개했습니다. 그 아이디어는 최종 해결책만 검증하는 대신 모든 단계를 개별적으로 검증하는 것입니다. 그래서 그들은 각 단계를 거치면서 "이것이 맞는가? 틀린가?"를 확인합니다. 만약 틀렸다면, 그들은 그냥 전체 해결책에 대해 틀렸다고 표시합니다.
좋습니다, 이것은 어떻게 비교될까요? 이 그래프에서 우리는 생성된 해결책의 수가 1000 또는 2000까지 올라가는 것을 볼 수 있습니다. 그리고 이것은 수학 벤치마크에서의 성공률입니다.이 회색 선은 합의(consensus), 또는 다수결 투표라고도 불립니다. 처음에는 올라가지만 결국에는 평평해지는 것을 볼 수 있습니다. 하지만 실제로 꽤 큰 향상을 준다는 것을 볼 수 있습니다. 그래서 단순히 합의를 함으로써 약 60%에서 거의 70%로 올라갑니다. n개 중 최선(Best of n)을 사용하면 더 큰 향상을 얻고 72.4%까지 올라갑니다. 정말 좋은 보상 모델로 모든 단계를 검증하는 이 프로세스 보상 모델을 사용하면 더 큰 향상을 얻고 78.2%까지 올라갑니다. 그리고 여전히 더 많은 샘플을 생성하면 그 선이 더 올라갈 것 같아 보입니다.
이에 대한 몇 가지 예가 있습니다. 제 생각에 이것은 특히 정말 흥미로운 예인데, 이것이 수학 문제이기 때문입니다. 여러분에게 100도의 탄젠트 더하기 100도의 사인 4배를 단순화하라고 요구하고 있습니다.이것을 순수한 GPT-4 모델에 제시하면, 1000번 중 1번만 맞출 것입니다. 하지만 모든 단계를 검증하는 과정을 거침으로써, 1000개의 샘플을 생성한 다음 보상 모델이 맞다고 하는 것만 취하면, 이 문제에 대한 성공률이 크게 올라갈 것입니다.
합의 (consensus or voting) < 최선 (Best of n) < 과정 검증 (Verify step by step)
하지만 제가 지적하고 싶은 한 가지는 이 모델들의 추론 비용이 여전히 꽤 낮다는 것입니다. 여러분은 지금 당장 ChatGPT에 가서 질문을 할 수 있고, 매우, 매우 낮은 비용으로 기본적으로 즉시 응답을 받을 수 있습니다. 그리고 그것이 그렇게 될 필요는 없습니다.
우리가 살펴본 많은 이 게임들에서는 그렇지 않았습니다. 언어 모델의 경우에도 그럴 필요가 없을 수 있습니다. 그래서, 음, 다음 목표는, 음, 제가 지금 작업하고 있는 것은 일반성입니다.
우리가 정말로 일반적인 방식으로 추론 계산을 확장할 수 있을까요? 음, 이것은 매우 어려운 문제입니다. 알다시피, 우리는 이러한 기술들, 추론 계산을 확장하는 이러한 탐색 기술들을 많이 개발했지만, 그것들은 항상 우리가 살펴본 도메인에 매우 특화되어 있었습니다. 그리고, 그리고 제가, 제가 작업하고 있고 다른 사람들이 작업하고 있는 것은 매우 일반적인 방식으로 그것을 하는 것을 개발하는 것입니다.
이것은 테스트 시간에 훨씬 더 높은 계산을 사용하는 것을 포함하겠지만, 그것은 훨씬 더 능력 있는 모델을 의미할 것입니다. 그리고 제 생각에 많은 도메인에서 우리는 그 트레이드오프를 기꺼이 할 것입니다. 네, ChatGPT의 경우처럼 코딩 작업을 위한 코파일럿을 원할 때 응답을 기다리는 데 5분을 쓰고 싶지 않을 수 있지만, 우리가 답변을 위해 몇 시간, 며칠, 심지어 몇 주를 기다릴 수 있는 많은 질문들이 있습니다.
리만 가설의 증명이나 새로운 생명을 구하는 약물, 또는 다음 해리 포터 소설과 같은 것을 위해 그런 종류의 비용을 기꺼이 지불할 수 있다고 상상할 수 있습니다. 그리고 제 생각에 매우 중요하게, 이것은 우리가 이 모델들을 더 확장함에 따라 어디로 가고 있는지에 대한 감각을 줄 수 있습니다. 이것은 본질적으로 이 모델들이 더욱 능력 있게 됨에 따라 앞으로 AI의 상태가 어떨지에 대한 미래의 창을 우리에게 제공할 수 있습니다.
현재 기준으로 GPT 40의 추론 비용은 매우 저렴하고, 이제야 o1에서 비싸지기 시작했다.
도메인에 특화된 추론 절차가 존재할 것이다.
답변을 얻는데 기꺼이 시간을 내어 줄 아주 어려운 문제가 있는 도메인을 노리자.
음, 저는 또한 제안하고 싶습니다. 알다시피, 저는 n개 중 최선과 같은 것들에 대해 언급했는데, 병목 현상은 정말로 검증자, 보상 모델의 품질에 있습니다. 음, 여러분은 외부 검증자가 있는 영역에서 작업하는 것을 고려해 볼 수 있습니다. 왜냐하면 그렇게 하면 여러분은, 음, 보상 모델의 품질에 의해 병목 현상이 생기는 것을 피할 수 있기 때문입니다.
