LLM에게 코딩 시키기, 요즘 바이브 코딩이라 불리는 일을 해 봤다. 동기는, 리니어 공간에서의 이미지 리사이즈 작업이 ImageMagick 같은 전문? 툴 없이 파이썬 라이브러리로만으로 가능한가? 라는 호기심.

의외로, 알려진 알고리즘을 적용하라는 지시에는 LLM이 매우 효과적으로 대응했다. 정형화되어 있는 작업은 그게 조금? 전문적이라고 해도 찰떡 같이 알아듣고 탬플릿처럼 코드를 만들어냈다. 거대 LLM은 지식의 범위가 매우 넓다고 절감했다.

오히려 문제는 쉽다고 예측했던 색영역 프로필 처리에서 일어났다. 존재하지 않는 메소드들을 계속 있다고 하며 라이브러리 버전 문제라고 우겼다. 제미나이도, chatgpt도 동일했다. 해당 라이브러리 문서를 직접 찾아보니, LLM들이 가져온 오브젝트는 유저에게 노출되지 않은 내부 C 코드에 있는 것들이었다.; 오브젝트는 내부를, 메소드는 문서화 되어 있는 API의 것을 조합해서 코드를 만들어 낸 것이었다.

인간 개발자는, 자기 전문 영역이 아닌 한 라이브러리의 내부 코드까지는 잘 보지 않는다. 즉 API 문서를 기반으로 작업을 해 나간다. LLM은 정반대였다. 오픈소스 라이브러리라면, 오히려 문서보다도 외부 문서화되지 않은 소스 코드가 더 잘 학습 되는 자료였던 것이다. 그 과정에서 라이브러리의 전체 동작 과정을 잘 파악할 정도는 아니었기에 동작하지 않는 코드들을 계속 만들어 냈고.

매우 흥미로운 경험이었다. LLM은 인간과는 전혀 다른 학습, 구성 과정을 통해 코딩한다. 요구-설계-개념-문서-코드 라는 단계는 LLM에게는 의미가 없다. 프로그래머들은 이제 이세돌 이후 바둑 기사들이 겪었던 충격과 비슷한 변화를 나름? 받게 된 듯 하다.

그러니까 인간에게는 벽이었던 게, LLM에게는 전혀 벽이 아니었던 것이다. 언젠가 인간의 이해와 사고를 돕기 위한 장치들의 오버헤드는 그냥 낭비가 될 듯 하다. 가히 어셈블리 코딩에서 컴파일러가 도입되는 수준의 충격이 오겠다. + LLM을 최대한 활용하려면 결국 오픈 소스여야 한다. 소스 코드 없는 바이브 코딩은 장점이 떨어져서, 독점 소프트웨어/라이브러리들은 크게 쇠퇴할 수 밖에 없겠다.

와, 진짜 쇼크였음. 이게 이런 식으로 동작하는구만, 이게 되네...;;