나의 "AI" 활용 방법

• 최근 1년 동안 매주 몇 시간씩 대규모 언어 모델과 상호작용하면서 점점 더 어려운 작업을 해결하는 능력에 지속적으로 감명을 받음
  • 그 결과 연구 프로젝트와 개인 프로젝트에서 코드 작성 속도가 최소 50% 빨라짐
• 온라인에서 LLM 유용성에 대해 이야기하는 사람들은 대부분 지나치게 낙관적이거나 지나치게 비관적임
• 미래에 대한 논쟁 보다 지난 1년 동안 LLM을 활용하여 연구 능력을 개선하고 코딩 프로젝트를 돕는 데 사용한 50가지 대화 사례를 제시하고자 함
• 나의 LLM 활용 사례
  • 이전에 사용해보지 않은 기술로 전체 웹 앱을 구축
  • 다양한 프레임워크 사용법을 처음 사용해보지 않고도 배움
  • 수십 개의 프로그램을 C 또는 Rust로 변환하여 성능을 10~100배 개선
  • 대규모 코드베이스를 줄여 프로젝트를 크게 단순화
  • 지난 1년간 거의 모든 연구 논문의 초기 실험 코드 작성
  • 거의 모든 단조로운 작업이나 일회성 스크립트 자동화
  • 새로운 패키지나 프로젝트 설정 및 구성을 위한 웹 검색을 거의 완전히 대체
  • 오류 메시지 디버깅을 위한 웹 검색의 약 50% 대체
• 이를 카테고리화 해보면 2가지임
  1. 학습 도움: 이전에는 어려웠을 일을 할 수 있게 됨
  2. 지루한 작업 자동화: 가장 잘하는 일에 집중하고 어려운 문제를 해결할 수 있게 함
• 가장 중요한 것은 이 사례들이 실제로 LLM을 활용하여 도움을 받은 방법이라는 점
  • 인상적인 기능을 보여주기 위한 것이 아니라 실제 업무를 처리해야 하는 나의 필요에서 비롯된 것

Nuance

• 인터넷이 잘하지 못하는 한 가지는 뉘앙스임. 나는 오늘날의 LLM이 세상을 지배할 것이라고 주장하거나, 미래 모델이 무엇을 할 수 있을지에 대해 이야기하지 않을 것임
  • 단지 오늘날의 모델이 자신에게 도움이 되는지 여부에 대해서만 논의할 것임
• 언어 모델이 유용하다는 것을 정당화하기 위해 글을 쓰는 이유가 궁금할 수 있음. 하지만 학계, 소프트웨어 엔지니어링 분야, 미디어 영역에는 LLM이 아무 기여도 하지 않고, 단지 또 다른 과대 광고 사이클일 뿐이며, 몇 년 후에는 세상에 아무런 영향을 미치지 않고 사라질 것이라고 널리 선언하는 사람들이 있는 것 같음
  • 나는 현재의 LLM이 이미 유용하기 때문에 이들이 잘못되었다고 주장할 것임
• 반대로 오늘날의 모델이 모든 프로그래머를 대체할 수 있고, 사람들은 프로그래밍을 배우지 말아야 한다고 주장하는 사람들도 있음
  • 나는 이들의 주장을 명시적으로 반박하려는 것은 아님
• 나는 LLM이 많은 해로운 영향을 미칠 수 있다는 것을 완전히 이해하고 있음. 허위 정보, 학대, 감시, 일자리 대체 등 모든 것을 의미함. 곧 LLM의 해로운 영향에 대한 생각을 다룬 글을 쓸 예정임. 그러나 이는 언어 모델이 유용할 수 있는지 여부와는 별개의 문제임
• 나는 LLM이 환각을 일으키고, 사실을 되풀이하며, 견고성이 부족하여 실패할 가능성이 있기 때문에 사용하고 싶지 않을 수 있는 이유를 잘 이해하고 있음. 그러나 이 글은 그것에 관한 것이 아님
  • 나는 이러한 실패에도 불구하고 모델이 유용할 수 있다고 생각함
• 이 모델을 훈련시키는 것의 윤리성은 의심의 여지가 있음. 사람들의 허락 없이 그들의 데이터로 훈련되었거나, 모델을 명시적으로 훈련시키기 위해 저임금을 받는 사람들에 대해 생각할 수 있음. 나는 이것이 문제라는 데 동의함
  • 나는 이 글은 그것에 관한 것이 아님
• 내가 여러 번 말했듯이, 이 글은 현재 존재하는 모델이 유용한지 여부에 대해서만 이야기할 것임

나의 배경 이야기

• 나는 일반적으로 무언가를 믿는 사람이 아님. 10년 전 보안 커뮤니티에서 크립토 과대 광고를 겪었지만, 블록체인에 관한 논문을 쓰는 것을 완전히 피했음. 비트코인을 소유한 적이 없음. 모든 주장에 대해 회의적임
• 누군가 이 AI 기술이 매우 유용할 것이고 일상 업무 방식을 크게 바꿀 것이라고 처음 말했을 때, 나의 반응은 "직접 보기 전에는 믿지 않겠다"였음
• 나는 보안 연구원임. 지난 10년 동안 AI 모델이 훈련되지 않은 환경에 직면했을 때 엄청나게 실패하는 모든 방법을 보여주는 것이 일상적인 업무였음. 기계 학습 모델에 대한 입력을 약간 교란시켜 출력을 크게 잘못 생성하게 하거나, 대부분의 기계 학습 모델이 훈련 데이터셋의 특정 예제를 기억하고 사용할 때 반복한다는 것을 보여주었음. 이러한 시스템의 한계를 완전히 이해하고 있음
• 그럼에도 불구하고 나는 현재의 대규모 언어 모델이 인터넷이 만들어진 이후 생산성을 가장 크게 향상시켰다고 말하고 있음. 오늘날 무작위로 선택한 프로그래밍 작업을 인터넷에 접근하거나 최신 언어 모델에 접근하는 것 중 하나를 선택해야 한다면, 절반 이상은 언어 모델을 선택할 것임

[ 내가 LLM을 사용하는 방법 ]

나를 위해 완전한 애플리케이션 구축하기

• 작년에 나는 GPT-4가 소수의 작업을 해결하는 능력을 얼마나 잘 예측할 수 있는지 테스트하는 퀴즈를 만들었음. 그 퀴즈는 꽤 인기가 있었고 천만 회 이상의 페이지 뷰를 기록했음.
• GPT-4에게 이 애플리케이션의 초기 버전 대부분을 작성하도록 했음. 애플리케이션의 기본 구조를 요청하는 것으로 시작하여 다양한 기능을 천천히 구축하는 일련의 질문을 통해 이를 수행했음
• 이 대화는 총 3만 단어에 달하며 당시 최신 GPT-4 모델의 기능을 풀로 사용함
  • [실제 프롬프트와 답변들은 생략합니다]
• 나는 GPT-4와의 대화에서 다양한 방식으로 요청을 했음
  • 단어로 원하는 바를 설명하고 모델에게 전체 구현을 요구하는 메시지부터, 특정 변경 사항을 요청하는 메시지("평균 점수와 비교하는 대신 KDE를 사용하여 백분위수를 말할 수 있나요?")까지
  • 오류 메시지를 복사하여 붙여넣는 완전히 불완전한 질문을 하는 메시지(예: "Plotting: numpy.linalg.LinAlgError: singular matrix")나 간단한 일회성 답변을 요청하는 경우("문자열에서 로드된 내용을 가진 JavaScript로 페이지에 iframe을 추가하는 방법은 무엇입니까?")도 포함
• 언어 모델이 효과적인 이유
  • 언어 모델은 사람들이 이전에 해결한 것들을 잘 해결하기 때문에 이런 방식이 효과가 있음
  • 이 퀴즈의 99%는 다른 사람이 작성할 수 있는 Python 웹서버 백엔드가 있는 기본적인 HTML에 불과했음
• 이 퀴즈가 흥미롭고 사람들이 좋아한 이유는 그 이면의 기술 때문이 아니라 퀴즈의 내용 때문임. 그리고 지루한 부분을 모두 자동화하면 퀴즈를 만들기가 매우 쉬워짐
• 언어 모델의 도움이 없었다면 아마도 이 퀴즈를 만들지 않았을 것이라고 확신함
  • 처음부터 전체 웹 애플리케이션을 작성하는 데 시간을 할애하는 것에 관심이 없었기 때문임
  • 그리고 이는 프로그래밍 방법을 아는 사람의 이야기임!
• 나는 현재의 모델조차도 대다수의 사람들이 솔루션을 요청하는 것만으로 이전에는 결코 해결할 수 없었던 의미 있는 작업을 수행할 수 있게 하기에 충분하다고 믿음
• 앞으로 모델이 나를 위해 전체 애플리케이션을 작성한 몇 가지 사례를 더 소개할 예정이며, 출시할 때 언어 모델의 도움으로 만들어졌음을 분명히 할 것임

새로운 기술을 위한 튜터로서의 역할

• 예전에는 새로운 프레임워크를 따라잡으려고 노력했지만, 한 사람이 할 수 있는 시간은 제한적임
• 직업상 대부분의 시간을 최신 연구 발전을 따라잡는 데 쓰고, 최신 JavaScript 프레임워크의 발전을 따라잡지는 않음.
• 특정 연구 영역 외의 새로운 프로젝트를 시작할 때는 일반적으로 두 가지 선택지가 있음
  • 첫째는 아는 것을 사용하는 것이고,
  • 둘째는 새로운(보통은 더 나은) 방법을 배우는 것임
• 여기서 언어 모델이 도움이 됨. Docker, Flexbox, React 같은 대부분의 새로운 프레임워크나 도구는 다른 사람들에게 새로운 것이 아님. 세계적으로 이러한 것들을 철저히 이해하는 사람들이 수만에서 수십만 명에 이를 것임. 현재의 언어 모델도 그러함.
• 특정 독자를 가정하고 특정 목표를 달성하려는 정적 튜토리얼을 읽는 대신, 언어 모델과 상호작용하여 작업을 해결하는 데 필요한 것을 배울 수 있음.
• 올해 초 LLM 평가 프레임워크를 구축하면서 LLM 생성 코드를 제한된 환경에서 실행하고 싶었음
  • Docker가 이 작업에 완벽한 도구였지만 이전에 사용해 본 적이 없었음.
• Docker를 사용하는 것이 프로젝트의 목표는 아니었고, 단지 목표를 달성하는 데 필요한 도구였음
  • 가능한 한 가장 기본적인 방식으로 안전하게 사용하고 있다는 확신을 갖기 위해 Docker의 10%만 이해하고 싶었음
• 90년대에는 기본 원리부터 Docker 사용법에 대한 책을 구입하고 처음 몇 장을 읽은 다음 건너뛰며 원하는 작업을 하는 방법을 알아내야 했을 것임
  • 지난 10년 동안은 Docker 사용 방법을 설명하는 온라인 튜토리얼을 검색하고 따라하다가 오류 메시지를 검색하여 다른 사람도 같은 문제를 겪었는지 확인하는 식으로 개선되었음
• 하지만 오늘날에는 언어 모델에게 Docker를 가르쳐 달라고 요청하면 됨
  • Docker를 설정하고 실행한 후 Linux에서 실행할 때 권한 문제가 있다는 것을 깨달았음. 이 문제를 해결하고 싶어서 모델에게 도움을 요청했음
  • 이를 통해 Podman에 대해 알게 되었고, 모델에게 Docker 전용 코드를 동등한 Podman 버전으로 다시 작성해 달라고 요청했음
  • 그리고 Docker 컨테이너에서 호스트의 GPU를 전달하는 방법을 알아내고 싶을 때도 요청했음

새로운 프로젝트 시작하기

• 어렸을 때 첫 번째 프로그래밍 언어는 Java였음. 프로그래밍을 정말 좋아했지만 새 프로젝트의 빈 화면을 보는 것이 정말 싫었음. 특히 Java로!
  • Hello World 프로그램을 컴파일하는 것조차도 "public static void main string args"가 무엇을 하는지, 괄호는 어디에 가는지, 어떤 글자가 다시 대문자인지, 중괄호와 대괄호가 왜 여기저기 있는지 알아내는 게 어려웠음
• 그래서 아이라면 누구나 할 법한 일을 했음. 아버지에게 그냥 해달라고 부탁했음
• 20년이 지난 지금도 익숙하지 않은 프레임워크를 사용하여 새 프로젝트를 시작하는 것이 여전히 싫음
  • 상용구를 제거하는 데 너무 많은 시간이 걸리고 내가 뭘 하고 있는지 이해하지 못함
• 예를 들어, 최근 누군가의 효율적이고 최적화된 CPU 구현과 비교하여 GPU에서 일부 순진한 Greedy 검색의 성능을 벤치마킹하기 위해 CUDA 코드를 작성해 보고 싶었음
• 그러나 CUDA 프로그램을 작성하는 방법을 모름
  • C 작성 방법은 알고 GPU 작동 방식, 커널 작동 방식, 메모리 레이아웃 등은 이해함
  • 그러나 실제로 GPU에 작업을 보내는 코드를 작성하는 방법은 모름
  • 그래서 모델에게 CUDA 프로그램의 첫 번째 패스를 작성해 달라고 요청했음
  • 완벽한가? 절대 아님! 그러나 그것은 시작임. 그리고 그것이 바로 내가 원하는 것임
• 여기서 코드가 많이 잘못되었음을 알 수 있음
  • 사실 이것은 전혀 문제가 되지 않음
  • 완벽한 솔루션을 찾는 것이 아니라 시작점을 찾고 있기 때문임
  • 향후 모델이 더 좋아진다면 그것은 놀라운 일이 될 것임
  • 그러나 지금 가지고 있는 것만으로도 이미 큰 도움이 됨.
• 위와는 완전히 별개로, 집에서 작업 중인 다른 개인 프로젝트를 위해 Raspberry Pi Pico W를 사용하고 있음
  • 이것이 처음 사용해보는 것이었음
  • 특히 네트워킹 작업을 수행하길 원했음
  • 물론 온라인에서 원하는 작업을 수행하는 방법을 설명하는 좋은 튜토리얼을 찾을 수 있을 것임
  • 그러나 최근 인터넷 검색을 해보면 상위 5개 결과는 대개 2008년의 버그가 있는 코드를 가진 쓰레기 콘텐츠 팜일 뿐이며, SEO를 위해서만 업데이트되었고 여전히 작동하지 않음
• 그래서 대신 언어 모델에게 내가 원하는 것을 하는 방법을 가르쳐 달라고 요청했음
  • 이전에 마이크로 컨트롤러로 작업한 적이 있어서 그것들이 어떻게 작동하는지 대략 이해하고 있음
  • 그러나 Pico W로 작업해 본 적은 없음
  • 모든 종속성으로 시작하는 데 도움이 되는 것만 있으면 나머지는 알아낼 수 있었음
• 새로운 마이크로 컨트롤러에 대해 항상 작성하는 첫 번째 "hello world" 프로그램은 LED를 깜박이는 것임
  • 이를 통해 장치에 코드를 컴파일하고 업로드할 수 있는지, 모든 핀이 올바르게 설정되어 있는지, 기본적으로 무엇을 하고 있는지 테스트할 수 있음
  • 그래서 그냥 깜박이는 프로그램을 요청하면 됨. (다시 말하지만, 이것이 인터넷에 존재하는가? 거의 확실히 그럴 것임. 그러나 그러면 내가 직접 찾아야 함.)
• 이 코드를 실행하고 나면 여기서부터 무엇을 해야 할지 알게 됨
  • 파이썬이 어떻게 작동하는지 암(믿거나 말거나!)
  • 그래서 특별한 마이크로 파이썬 작업을 끝내고 거기에서 바로 계속 편집할 수 있음
• 그리고 특별한 처리가 필요한 다른 문제에 부딪혔을 때 모델에게 도움을 요청하면 됨
  • 예를 들어 여기서는 모델에게 WiFi에 연결하는 스크립트를 작성해 달라고 요청하는 것으로 계속됨
• 그리고 MQTT 서버에 연결해야 하는 등 다시 막힐 때마다 모델에게 도움을 요청하면 됨
• 이제 이것을 지속적으로 하고 있음. 이 섹션의 맨 위에 있는 예시조차도 가설이 아님
  • HTML 레이아웃을 배우는 새로운 방법이 테이블 대신 div를 사용하는 것이었기 때문에 Flexbox를 사용하는 방법을 묻고 있음

코드 단순화하기

• 보안 연구원으로서 나는 종종 다른 사람의 수천 줄에 달하는 연구 프로젝트가 담긴 새로운 저장소를 받게 되고, 그것이 어떻게 작동하는지 파악하여 공격해야 하는 상황에 처함
  • 모두가 깨끗한 코드를 작성한다면 그리 어려운 일은 아니겠지만, 우리가 살고 있는 세상은 그렇지 않음
  • 연구자들은 깨끗한 코드를 퍼블리시 해야할 동기(incentivized)가 없음
  • 그래서 종종 사람들은 작동하는 쓰레기 코드를 제출 하곤함. (나도 그렇게 함)
• 여기서 공유할 수 있는 연구 관련 예시는 없지만, 내가 작업 중인 개인 프로젝트의 예를 공유할 수 있음
  • 나는 콘웨이의 생명 게임에 대해 건강하지 않은 집착을 가지고 있음
  • 최근 파이썬에서 일부 생명 패턴을 평가하는 빠른 방법을 찾고 있었음
  • 이를 수행하는 훌륭한 C++ 도구인 golly가 있지만, 파이썬 코드를 C++로 다시 작성하고 싶지는 않았음
• golly에는 원하는 작업을 수행하는 CLI 도구가 있음
  • 필요한 것은 그것을 올바르게 호출하는 방법뿐이었음
  • 이를 위한 첫 번째 단계는 약 50개의 다양한 명령행 옵션을 지원하는 C++ 코드를 가져와서 원하는 한 가지 작업만 정확히 수행하도록 하는 것이었음
  • 그래서 500줄의 C++ 코드를 모두 LLM에 덤프하고 동일한 작업을 수행하는 더 짧은 파일을 요청했음
• 그리고 어떻게 되었을까? 완벽하게 작동했음
  • 그런 다음 C++ 코드 주위에 파이썬 래퍼를 요청했음. 그것도 역시 잘 작동했음
• 이것은 너무 귀찮아서 저자 스스로 절대 하지 않았을 일 중 하나임
  • 그러나 이제 그냥 요청하면 되기 때문에, 원래 파이썬 코드보다 100배 빠른 무언가를 가지게 되었음
• 나는 이런 일을 꽤 자주 하고 있음. 파이썬에서 정확히 같은 작업을 수행하는 또 다른 예도 있음
• 이 작업들은 어느 것도 어렵지 않음
  • 그러나 이렇게 할 때마다 상당한 시간을 절약할 수 있음
  • 그리고 이것이 바로 오늘날 LLM이 놀라운 이유 중 하나라고 생각함
  • 화려하지는 않고, "여기 내 삶을 더 쉽게 만들기 위해 LLM을 사용한 지루한 방법"이라고 말해서 인터넷 포인트를 많이 얻을 수는 없겠지만, 이는 실제로 일어나고 있는 일임

단조로운 작업 자동화하기

• 생각이 필요하지 않고 지루하지만 해야 하는 일이 많음
• 작업을 미루는 주된 이유 중 하나는 그것을 해내는 것이 짜증나고 고통스러울 것이라는 것을 알기 때문임
  • LLM은 이런 고통을 엄청나게 줄여주고, 흥미로운 문제만 해결하면 된다는 것을 알기에 무언가를 시작하기가 훨씬 쉬워짐
  • 여기서는 LLM에게 요청하여 해결한 완전히 일상적인 문제들을 살펴보겠음
• 예를 들어 최근 Python 3.9로 작성된 파이썬 프로그램을 디스어셈블해야 했음
  • 대부분의 파이썬 디스어셈블러는 Python 3.7 이전 버전에서만 작동하고 3.9 바이너리에서는 실행되지 않았음
• 디스어셈블은 정말 어려운 작업은 아님. 주로 goto를 따라 제어 흐름을 재구성하면서 실수하지 않는 것이 대부분임
  • 수백 줄의 코드에 대해 수천 개의 op-code를 수동으로 변환하는 데 시간을 보내는 대신, LLM에게 대신 해달라고 요청했음
  • 그리고 정말 잘해냈음! 가능하다고 생각했던 것보다 훨씬 훨씬 더 잘했음
• 또 다른 예는 비정형 데이터를 가져와 정형화된 형식으로 포맷해야 할 때임
  • 예를 들어, 어떤 프로젝트를 하다가 저자 이름과 함께 책 제목 목록이 필요했음
  • 그래서 온라인에서 비정형 형식으로 데이터를 찾아 LLM에게 포맷해달라고 요청했음
• 또는 최근에 어떤 방어를 뚫은 방법에 대한 블로그 게시물을 쓰면서 변경해야 했던 코드의 완전한 diff를 보여주고 싶었음
  • 그래서 (1) diff와 (2) diff를 HTMLify하는 방법에 대한 이전 예제를 붙여넣고 LLM에게 이 diff를 이전 형식으로 제공해 달라고 요청했음
• 또 다른 예로, 업무의 일부로 종종 사용하는 리소스에 대한 인용문을 생성해야 함
  • Google Scholar는 논문에 대해 이를 쉽게 만들어주고 인용문을 복사하여 붙여넣기만 하면 됨
  • 그러나 웹페이지를 인용하는 것은 약간 귀찮음
  • 최근에는 LLM에게 인용문을 생성해 달라고 요청하곤 함. (분명히 하자면, 나는 이것이 정확한지 확인함!)
• 이런 예를 적어도 100개는 더 들 수 있을 것임. 그러나 요점은 이해했으리라 생각함
• 누군가 보고 "그게 다야??"라고 말할 수 있는 유형의 작업이라는 것을 충분히 이해함
  • 그러나 5년 전만 해도 그들은 겨우 일관된 문단을 엮을 수 있을 뿐, 전체 문제를 해결해주지는 못했다는 점을 기억할 것

모든 사용자를 "파워 유저"로 만들기

• 자신보다 훨씬 능숙하지 않은 사람이 어떤 도구를 사용하는 모습을 본 적이 있다면, 그것은 다소 고통스러울 수 있음
  • 어떤 종류의 매크로나 병렬 애플리케이션을 영리하게 사용하면 자동화할 수 있는 작업에 몇 분, 때로는 몇 시간씩 소비하는 것을 볼 수 있음
• 그러나 이를 수행하는 데 필요한 주문을 배우는 데는 시간이 걸리고 어려움
• 예를 들어 최근 Apple Lisa 키보드에서 키보드 입력을 처리하는 파이썬 프로그램을 작성하려고 했음
  • 온라인에서 C로 이 작업을 수행하는 무언가를 작성한 사람을 찾았고, #define KEYNAME key_code와 같은 문장이 많이 있었음
  • 이를 정수 코드를 해당 문자열에 매핑하는 파이썬 딕셔너리로 변환하고 싶었음
• 나는 이맥스 사용자임. 이맥스에서 이 문제를 어떻게 해결하는지 알고 있음. 그리 어렵지는 않을 것임. 다음은 이 효과를 낼 수 있었던 방금 녹화한 주요 캡처임:
  C-h C-s #def [enter] M-f [delete] C-d M-f C-[space] M-f C-w C-a C-y : " M-f ", C-g C-] } C-[ {
• 이는 나에게 거의 자연스러운 것이지만, 이것이 자연스러워지기까지 나는 인생의 절반 이상을 이맥스에 충분히 익숙해지는 데 보냈음. 그러나 이제 LLM이 편집기에 연결되어 있다면 어떤 걸 입력할까?
  C-h C-h rewrite these #defines to a dictionary of {keycode: string, ...}
• 그러면 갑자기 텍스트가 내 눈앞에서 다시 작성됨!
• 이런 경우 LLM의 잠재적 유용성은 전문가보다 비전문가에게 더 높다고 생각함
  • 모델은 모든 사람의 기준을 높여주고, 이전에는 전혀 할 수 없었다면 갑자기 훨씬 더 많은 것을 할 수 있게 됨

API 참조로 활용하기

• 진정한 프로그래머는 도구의 작동 방식을 알고 싶을 때 참조 매뉴얼을 읽음
  • 그러나 나는 게으른 프로그래머라서 그냥 답을 떠먹여 주기를 바람
  • 그래서 이제는 언어 모델에게 물어봄
• 이런 예를 보여주면 어떤 사람들은 방어적으로 반응하며 "LLM이 당신이 이미 가지고 있는 도구로 할 수 없는 일을 한 것은 없다!"라고 말함
  • 그리고 그들이 맞음
  • 그러나 물리적인 책으로 할 수 없는 검색 엔진으로 할 수 있는 것은 없고, 소스 코드를 읽어서 할 수 없는 물리적인 책으로 할 수 있는 것은 없음
• 그러나 이들 각각은 차례로 이전보다 쉬워짐
  • 그리고 무언가가 쉬워지면 더 자주, 질적으로 다른 방식으로 그것을 하게 됨.
• 프롬프트를 포함한 사례들
  • "Bash에서 어떤 $가 모든 남은 인수를 제공하는가"라고 묻고 답을 얻음. (바로 다음에 "이것을 어떻게 사용하는가"라는 또 다른 질문이 이어짐!)
  • 또는 LaTeX에서 텍스트를 빨간색으로 만드는 방법을 알고 싶을 때 더 이상 검색하거나 문서를 읽지 않고 모델에게 물어봄
  • 그리고 다양한 GDB 명령에 해당하는 LLDB 명령이 무엇인지 알고 싶을 때도 같은 방식으로 함
  • 또는 일부 find 명령이 어떻게 작동하는지 알고 싶을 때도
  • lpr 사용 방법도
  • LaTeX 명령을 재바인딩하는 방법도
• 실제로 이것이 내가 LLM을 가장 자주 사용하는 방법 중 하나임
  • 이런 예를 수천 개 더 연결할 수 없는 유일한 이유는 이맥스와 셸 모두에 LLM을 쿼리하는 도구가 내장되어 있기 때문임
  • 그래서 90%의 경우 이런 것들 중 하나를 하고 싶을 때 편집기를 떠날 필요조차 없음

찾기 어려운 것들을 검색하기

• 인터넷에서 콘텐츠를 검색하는 것은 예전에는 어렵게 배운 기술이었음
  • 쿼리에 포함하고 싶은 특정 단어는 무엇인가? 복수여야 하나? 단수? 과거형?
  • 페이지에 나타나지 않기를 원하는 단어는 무엇인가? X AND Y를 원하나, 아니면 X OR Y를 원하나?
• 더 이상 그렇지 않음
  • Google에서 OR을 사용한 쿼리를 마지막으로 작성한 때가 언제인지 기억나지 않음
  • 결과의 하위 집합을 제거하기 위해 마이너스(-)를 사용한 마지막 시기도 기억나지 않음
    = 오늘날 대부분의 경우 찾고 싶은 것을 그냥 적으면 검색 엔진이 찾아줌.
• 그러나 검색 엔진은 여전히 100% 자연어 쿼리는 아님
  • 여전히 Reverse-Jeopardy 게임을 하는 것 같고, 질문이 아닌 답변에 사용할 키워드를 사용하려고 함
  • 이것은 우리 거의 모두가 배웠다는 것을 잊어버린 기술임
• 언어 모델은 오늘날 일부 간단한 작업(시간이 지날수록 점점 더 많아짐)에 대해 그냥 더 좋음
  • 그냥 "그래서 +는 add에 해당한다는 것은 알겠는데 ~는 뭐지"라고 입력하면 inv라는 답을 알려줌
• 이것은 표준 검색 엔진으로 검색하기가 매우 어려운 것임
  • 답을 찾을 수 있는 방법이 있다는 것은 알고 있음
  • 아마도 "python documentation metaclass add"라고 입력한 다음 페이지에서 ~를 검색하면 답을 얻을 수 있을 것임
  • 그러나 LLM에 가진 질문을 그냥 묻는 것도 효과가 있음
• 이렇게 하는 것은 한 번에 불과 몇 초밖에 절약되지 않지만, 어떤 코딩 작업을 해결하는 중이고 이미 한 번에 수백만 가지 일을 처리하려고 할 때는 해결하려는 것을 브레인 덤프하고 일관된 답변을 얻는 것만으로도 놀라움
• 그렇다고 해서 오늘날 그들이 이 일에 완벽하다는 것은 아님
  • 언어 모델은 온라인에 있는 것들이 충분히 자주 반복되었을 때만 알고 있음
  • "충분히 자주"가 의미하는 바는 모델에 따라 다르므로, 모델에게 물어봐야 할지 인터넷에 물어봐야 할지 생각하는 데 몇 번의 정신적 주기를 보내야 함
  • 그러나 모델은 계속 발전할 것임
• 아니면 무작위 충돌이 발생할 때마다 모델에 내가 보는 것을 덤프하고 설명을 요청할 것임
  • 여기서 "Remote wildcard transfer issue"라고 입력하면 그렇게 함
• 완전히 별개의 예로, 작년에 블로그 게시물을 쓰면서 첫 단어의 첫 글자를 크게 하고 나머지 텍스트를 그 주위에 감싸고 싶었음
  • 이것을 드롭 캡이라고 함. 그러나 그 사실을 몰랐음
  • 그냥 원하는 효과를 알고 있었을 뿐이라 언어 모델에게 "텍스트가 O 주위를 감싸는 멋진 책처럼 보이길 원한다"고 물었더니 정확히 원하는 것을 주었음
  • 이 작업 또한 "LLM 덕분에만 했다"는 범주에 속함
  • 이것을 하는 방법을 알아내는 데 많은 시간을 쓰는 것이 가치 있다고 생각하지 않았을 것임
  • 그러나 모델에게 물어볼 수 있었기에 그렇게 했고, 그것이 제 게시물을 조금 더 멋지게 만들어줬음

일회성 작업 해결하기

• 프로그램에는 두 가지 종류가 있음
  • 첫째, 제대로 하고 싶은 프로그램이 있음. 이들은 한동안 존재할 것이고 몇 년 동안 유지 관리해야 하므로 깔끔함이 중요함
  • 둘째, 25초 동안 존재할 프로그램이 있음. 이들은 어떤 작업을 완료하는 데 도움을 주고 즉시 폐기됨
• 코드의 품질에 전혀 신경 쓰지 않고 프로그램이 완전히 독립적인 이런 경우에는 이제 거의 전적으로 LLM을 사용하여 작성함
• 경고: 이 대부분의 경우도 역시 "그게 다야?"라고 말할 만한 것들임
  • 그러나 앞서 말했듯이 주어진 프로젝트에 투자할 수 있는 하루의 시간은 제한되어 있음
  • 그리고 다시는 사용하지 않을 프로그램을 작성하는 시간과 정신적 에너지를 절약할 수 있다면 그렇게 할 것임
• 가장 흔한 예는 아마도 어떤 연구 실험의 결과로 생성한 데이터를 시각화하는 플롯을 생성하는 데 도움을 주는 것일 것임
  • 이런 예가 수십 개 있음. 아마 0보다 100에 가까울 것임. 이들은 모두 기본적으로 동일해 보이므로 여기 하나만 적어봄
• 또 다른 비슷한 예는 한 형식의 데이터를 가지고 있고 이를 다른 형식의 데이터로 변환하고 싶을 때임
  • 보통 이것은 한 번만 해야 하는 것이고, 일단 완료되면 결과 스크립트를 버림
• 원하는 스크립트가 충분히 간단하면 LLM에 전체를 작성해 달라고 요청하는 경우가 많음
  • 예를 들어, 여기서는 LLM에 논문을 큰 소리로 읽어주는 스크립트를 작성해 달라고 요청하여 바보 같은 문법 문제가 없는지 확인할 수 있음
• 대부분의 경우 내가 원하는 것을 잘 모를 때는 모델에 초기 코드를 요청하는 것으로 시작한 다음 거기에서 반복함
  • 예를 들어, 여기 데이터를 빠르게 처리해야 하는 일회성 작업이 있음
  • 2022년에는 이것을 파이썬으로 작성하는 데 2분을 소비하고 한 번만 실행되기 때문에 몇 시간 동안 실행되기를 기다렸을 것임
  • 최적화하는 데 파이썬 프로그램이 실행되는 것보다 오래 걸릴 것임
  • 그러나 지금은? 내 데이터 처리를 해주는 Rust 코드를 요청하는 데 같은 2분을 소비할 것이라고 확신함
• 또는 모델에 데이터 세트를 다운로드하고 초기 처리를 수행해 달라고 요청하는 또 다른 예시가 있음
  • 내가 하기에 쉬운가? 아마도 그럴 것임
  • 그러나 이것은 내가 생각하고 싶은 작업이 아님
  • 데이터 세트로 수행할 연구에 대해 생각하고 싶음
  • 주의를 산만하게 하는 요소를 제거하는 것은 절약되는 몇 분 이상으로 매우 가치 있음
• 또 다른 때는 작은 큐브로 픽셀화된 이미지를 3D 프린팅할 수 있도록 프로그램을 작성하고 있었음
  • 이를 위해 PNG를 STL 파일로 변환하고 싶었지만, 이것은 프로젝트의 요점이 아니었음
  • 그냥 중간에 일어나야 하는 일이었음. 그래서 LLM에게 이것을 해결해 달라고 요청함
• 또 다른 예로, 최근 Docker Compose를 사용하여 새 프로젝트를 설정하고 싶었음
  • 문제가 발생하고 있었고 무슨 일이 있어도 그냥 실행하고 싶었고, 나중에 무엇이 잘못되었는지 알아낼 것임
  • 그래서 결국 오류 메시지를 하나씩 복사하는 것만으로 여러 번의 왕복을 하다가 결국 작동하는 솔루션을 얻었음.
• 또한 많은 경우 완전한 솔루션을 요청하는 것으로 시작한 다음 이를 수정하는 방법에 대한 힌트를 요청하는 나 자신을 발견할 것임
  • 여기 이 대화에서는 HTML을 구문 분석하는 프로그램을 요청하는 것으로 시작하고, 거기에서 API 참조나 개선 방법에 대한 힌트를 요청함
• 또 다른 때는 컴퓨터가 시간이 지남에 따라 메모리와 CPU를 얼마나 사용하는지 추적하고 싶었음
  • 적절한 명령을 찾아내서 내가 원하는 작업을 수행하는 스크립트로 묶는 데 몇 분을 소비할 수도 있었겠지만, 그냥 언어 모델에 대신 해달라고 요청
• 최근 약간의 전자 제품을 만들려고 하고 있었는데, Arduino에서 실행되는 C 프로그램이 있었지만 MicroPython의 Raspberry Pi Pico에서 실행하고 싶었음
  • 이 변환 과정에는 흥미로운 것이 없음. 그냥 완료되어야 함
  • 그래서 직접 작업하는 대신 언어 모델에 대신 해달라고 요청함
• 다른 프로젝트를 위해서는 일부 이미지를 일부 대화형 루프의 멋진 ML 모델로 분류해야 했음
  • 직접 작성할 수도 있었겠지만, 그냥 모델에게 대신 해달라고 요청할 수도 있었음

내게 뭔가를 설명해주기

• 나는 최근 전자 제품에 관심을 갖기 시작함
  • 어렸을 때 전자 제품을 다뤘고 대학에서 몇 가지 수업을 들었음
  • 그러나 이제 실제 프로젝트를 하려고 보니 모르는 수천 가지 사소한 것들 때문에 무언가를 하기가 어려움
• 실용 전자공학 책을 읽을 수도 있겠지만, 그렇게 해서 그 주제에 대해 제대로 이해할 수 있겠지만, 공부하는 것처럼 시간을 보내고 싶지는 않음
  • 전자 제품을 하는 이유의 절반은 하루 종일 논문을 읽고 쓰는 것에서 휴식을 취하기 위해서임
• 여기서 LLM이 좋은 점은 세상에서 가장 지식이 많은 사람만큼 박식하지는 않지만, 내가 가질 수 있는 전자 제품 관련 질문에 대한 답을 아는 사람이 수천, 수백만 명이나 된다는 것임
  • 그래서 언어 모델도 아마 그 답을 알고 있을 것임
  • 그리고 모든 질문에 대한 답을 기꺼이 알려줘서 세부 사항과 씨름하지 않고도 내가 원하는 재미를 느낄 수 있음
  • 그리고 인터넷을 검색하면 조금만 더 노력하면 답을 얻을 수 있겠지만, 복잡한 연구 코드로 하루 종일 일한 후 모델에 요청하기만 하면 되는 편리함이 매우 편안함
• 그래서 여기 언어 모델에 전자 제품의 작동 원리에 대한 기본적인 질문을 한 예시 모음이 있음
  • 이 답변이 완벽한가? 누가 알겠음
  • 하지만 이게 아무것도 모르는 것보다는 나음?
• (이 글은 꽤 길어지고 있고, 이쯤 되면 읽는 것만큼이나 쓰는 것도 지쳤을 것임. 그래서 그냥 아무 설명 없이 이 예시들을 남겨두겠음.)
  • PCB 설계에 대한 기본적인 질문
  • 납땜에 대한 기본적인 질문
  • 커패시터에 대한 기본적인 질문
  • LED에 대한 기본적인 질문
  • 플로피 디스크에 대한 기본적인 질문
• 계속할 수 있지만, 요점은 이해했으리라 생각함

알려진 솔루션으로 작업 해결하기

• 누군가가 이미 한 일이 거의 모든 것임
  • 하고 싶은 일이 정말 새로운 것은 거의 없음
  • 그리고 언어 모델은 이전에 본 것에 대한 솔루션을 제공하는 데 매우 뛰어남
• 최근 프로젝트에서 일부 Python 코드의 성능을 개선해야 했음
  • (1) LLM에게 그것을 C로 다시 작성해 달라고 요청한 다음
  • (2) Python에서 C 코드를 호출할 수 있는 인터페이스를 구축해 달라고 요청했음
• 이 작업들은 "어렵지" 않음
  • Python에서 C로 변환하는 것은 1~2시간이면 할 수 있을 것임
  • 그리고 Python->C API가 어떻게 작동하는지 정확히 모르지만, 문서를 읽으면 알아낼 수 있을 것임
  • 그러나 직접 해야 한다면 절대 하지 않았을 것임
  • 그냥 중요한 경로를 따라가는 것이 아니기 때문에, 자주 실행할 필요가 없는 것들을 더 빠르게 만드는 데 시간을 보내기보다는 기다렸다가 컴퓨터가 작업을 해결하도록 하는 것이 나음
• 그러나 간단한 프로그램의 경우 Python에서 C로 변환하는 것은 (대부분) 기술적인 과정이고, 정확히 하나의 표준 Python->C 호출 규칙이 있음
  • 그래서 그냥 LLM에게 대신 해달라고 요청할 것임.
• 그 이후로 이것이 내가 할 수 있는 일이라고 기대하게 되었고, 기본적으로 빠른 코드 조각이 필요할 때마다 그냥 Python으로 원하는 것을 설명하고 최적화된 C를 요청할 것임
• 다른 때는 같은 일을 하지만, C 출력과 비교했을 때 Rust 출력의 정확성을 더 쉽게 판단할 수 있을 것 같으면 C 대신 Rust 출력을 요청할 것임
• 또 다른 예로, 멀티프로세싱 라이브러리를 사용하여 Python 함수를 병렬화하는 것은 어렵지 않음
  • 약간의 상용구 코드를 작성해야 하고 기본적으로 그냥 일어남
  • 그러나 코드를 작성하는 것은 약간 고통스럽고, 실제로 하고 싶은 작업을 방해함
  • 이제 이것이 필요할 때마다 그냥 LLM에게 대신 해달라고 요청함
• 또는 종종 일부 API를 테스트할 때 처음에는 그냥 curl 요청을 작성하여 처음에는 작업이 돌아가게 만듦
  • 그리고 일단 그것이 작동하고 프로그래밍 방식으로 작업을 반복하고 싶으면 Python으로 변환함
  • 이전에는 보통 정말 못생긴 짓을 하고 그냥 os.popen()을 호출하고 curl 명령을 실행했는데, 이건 좋지 않음
  • Python requests 라이브러리로 변환하는 것이 더 나을 것임. 그러나 그것은 시간이 걸리므로 하지 않을 것임
  • 그러나 이제 그냥 LLM에게 대신 해달라고 요청하면 더 깨끗한 프로그램을 더 빨리 얻을 수 있음
• 여기서 아마도 이야기할 예정인 앞으로의 프로젝트를 위해서는 사람들이 간단한 무선 송신기로 어떤 종류의 것들을 사용하는지 알 필요가 있었음
  • 내가 정말로 원하는 것이 중간값 인간의 대답이기 때문에 LLM이 완벽한 선택임!

일반적인 오류 수정하기

• 2022년 이전에는 일부 유명한 도구나 라이브러리에서 오류 메시지가 발생하면 다음과 같은 프로토콜을 따랐음:
  1. 오류 메시지 복사
  2. Google에 붙여넣기
  3. 상위 Stack Overflow 링크 클릭
  4. 질문이 내가 묻고 싶은 것인지 확인; 그렇지 않으면 2로 이동
  5. 상위 솔루션을 작업에 적용
  6. 작동하지 않으면 2로 가서 검색어를 변경하고, 기도하는 등
• 솔직히 말해서, 보통 고장 나는 도구는 궁극적으로 해결하려는 작업에서 5단계 정도 떨어져 있고, 정말 어떻게 작동하는지는 신경 쓰지 않고 그냥 작동해야 함
• 2024년 지금은 어떨가?
  1. 오류 메시지 복사
  2. LLM에게 "이 오류를 어떻게 고치나요? [오류]"라고 묻기
  3. LLM이 제안한 단계별 솔루션 적용
  4. 작동하지 않으면 "작동하지 않았어요"라고 말하기
• 이에 대한 예시로 보여줄 사본은 없음. (또는 1시간 동안 찾아봐도 찾을 수 없었음) 그러나 이에는 실제로 좋은 이유가 있음: 이를 워크플로에 바로 내장했기 때문임
  • 나는 이맥스 사용자임
  • 프로그램을 실행하고 0이 아닌 상태 코드로 종료될 때마다(즉, 문제가 발생했음을 의미) 자동으로 최신 최고 속도의 LLM을 호출하여 답변을 설명해 달라고 요청하고, 동시에 코드의 버그를 수정하기 위해 직접 적용할 수 있는 패치를 요청하도록 환경을 설정해 두었음
  • 오늘날의 모델은 아직 대부분의 경우 이 작업에서 저자를 이길 만큼 충분히 좋지는 않지만, 점점 가까워지고 있음
  • 그리고 가끔씩 어딘가에 오타가 있어서 추적하기 악몽이 될 것으로 알고 있는 버그를 LLM이 고쳐주면 기분 좋은 놀라움을 얻게 될 것임

정리

• 위에 링크한 모든 대화는 작년에 내가 LLM과 나눈 전체 대화 중 2% 미만을 차지
• 다른 대화들을 링크하지 않은 이유는 해당 모델이 실패한 사례이기 때문이 아니라(물론 그런 사례는 많지만)
  • (1) 이미 링크한 대화와 같은 패턴을 반복하거나
  • (2) 무슨 일이 일어나고 있는지 설명하기 쉽지 않고 왜 유용한지 직접 확인하기 어렵기 때문
• 앞으로도 이러한 모델의 사용은 계속 늘어날 것으로 예상
• 참고로 2023년에 비해 2024년에 웹 인터페이스를 통해 LLM 쿼리를 30% 더 많이 수행했으며, API 쿼리의 증가는 집계할 수 없지만 적어도 2, 3배 정도는 증가했을 것으로 생각

LLM이 할 수 없는 일이 아닌 "할 수 있는 일"을 평가할 것

• 인터뷰 시 지원자를 평가할 때는 그들이 할 수 없는 것보다는 할 수 있는 것에 주목해야 함
• LLM에게 사소한 질문을 던지면 무능해 보일 수 있음. 예를 들어 10억 명이 쓰는 중국어로 질문한다면 제대로 대답하기 어려울 것
• 컴퓨터 공학 내에서도 SQL의 SELECT문 정도만 알고 있는 등 모르는 분야가 많음
• 온라인에서 LLM이 특정 task를 수행하지 못한다는 이유로 과대포장이라 주장하는 것을 이해하기 어려움
  • 문장의 단어 수를 세지 못함
  • 모든 단어가 'a'로 시작하는 시를 쓰지 못함
  • 두 자릿수를 곱하지 못함
  • 리스트에서 무작위 요소를 선택하지 못함
• 그러나 이런 일을 실제로 할 때 LLM이 적합한 도구라고 생각한 적이 있는지 의문
• 64비트 정수의 나눗셈을 머릿속으로 하지 못한다고 해서 인간이 쓸모없다고 말하지 않는 것처럼, LLM이 해결하지 못하는 문제를 구성했다고 해서 LLM을 무시하는 것은 타당하지 않음
• 중요한 것은 LLM이 가치를 제공할 수 있는 task가 있는지 여부
• 프로그래머들은 목적에 따라 다른 언어가 유용함을 이미 잘 알고 있음
  • 운영체제 작성에는 C가 Python보다 적합
  • Python이 변수를 32바이트 경계에 정렬할 수 없다고 말하지 않음. 단지 추상화 수준이 다를 뿐
• LLM도 마찬가지로 매우 높은 수준의 추상화에서 작동함
  • 단순한 프로그램으로도 해결할 수 있는 작업을 LLM에 기대하기는 어려움
  • 그러나 다른 종류의 작업은 해결할 수 있을 것으로 기대할 수 있음

결론

• 이 글을 작성한 두 가지 동기
  • LLM이 개인적으로 이미 많은 가치를 제공하고 있다는 점을 주장하기 위함
  • LLM의 아이디어는 좋지만 자신에게 어떻게 도움이 될지 모르는 사람들에게 활용 예시를 보여주기 위함
• LLM의 가치
  • LLM은 모든 것을 할 수는 없지만 현재 모델만으로도 상당한 가치를 제공함
  • 예를 들어 CUDA 오류를 진단하고 패키지를 재설치하는 방법을 알려주거나, C로 프로그램을 재작성하거나, 특정 주제에 대해 가르쳐 줄 수 있음
  • 이는 대학생도 몇 시간 노력하면 할 수 있는 일이지만, 언제든 질문에 답해줄 수 있는 대학생은 없음. 반면 LLM은 가능함
• LLM의 발전과 현재 상황
  • 5년 전만 해도 LLM은 그럴듯한 영어 문단을 작성하는 것이 최선이었고 실용성은 전무했음
  • 그러나 오늘날 LLM은 프로그래밍 작업의 생산성을 최소 50% 향상시키고 지루한 작업을 제거해 줌
  • LLMs 덕분에 시도하지 않았을 프로젝트도 여러 개 완성했음.
• LLMs의 유용성에 대한 반박
  • "LLM이 과대포장이고 실질적 가치가 없다"는 주장에 반대함
  • 개인적으로 LLM이 큰 가치를 제공하고 있음
  • 20년간 프로그래밍 경험이 있는 나조차도 LLM을 통해 생산성이 크게 향상됨
  • 나 외에도 LLMs의 혜택을 받을 수 있는 사람들이 많을 것이라고 생각함
• 앞으로의 전망
  • 현재 모델만으로도 많은 가치를 제공하고 있음
  • 향후 5년간 LLM들이 어떻게 발전할지 기대와 두려움이 혼재됨
  • 다음 글에서 이에 대한 예측을 다룰 예정임