몇 년 전부터 챗GPT 열풍이 있었지만, 인공지능이 개발자에게 미칠 영향에 큰 관심을 두지 않고 있었습니다. 적어도 작년 여름까지는 그랬던 듯합니다. 그러다가 지난여름 어느 날 인공지능 분야의 저명한 전문가 안드레이 카파시(Andrej Karpathy)가 AI 툴을 이용한 개발에 대해 쓴 글을 보게 되었습니다. 그는 커서(Cursor)라는, 인공지능을 기본 탑재한 IDE로 개발하는 일을 두고 “자연어(영어)로 프로그래밍을 하고 인공지능이 생성한 결과를 활용한 반코딩(half-coding)을 하는 양상”이라고 묘사했습니다. <출처: 안드레이 카파시 X> 그렇게 커서의 존재를 알고 난 후에 6개월 정도 시간이 흘렀습니다. 그사이에 인공지능과 프로그래밍에 대한 주제를 두고 발전한 제 생각을 몇 개의 에피소드를 중심으로 글로 풀어 봅니다. 안드레이 카파시(Andrej Karpathy)는 누구인가요?안드레이 카파시는 인공지능 분야의 저명한 전문가로, 스탠퍼드 대학에서 페이-페이 리 교수의 지도하에 딥러닝과 컴퓨터 비전으로 박사 학위를 취득했습니다. 이후에 OpenAI 창립 멤버 (2015-2017)였으며, 테슬라 인공지능 부문 책임자(2017-2022)를 역임했으며, 최근에는 2024년 AI 교육 스타트업 유레카 랩스(Eureka Labs)를 설립했습니다. <출처: 퍼플렉시티 답변> 주니어 개발자나 외주 개발을 대체할 수 있어요작년에 SNS로 연락을 취해 온 개발자를 만난 일이 있었습니다. 아마도 그는 제가 개발과 사업 경험을 모두 갖고 있기 때문에 만남을 청한 듯합니다. 개발 커뮤니티에 관심이 있는 저는 동료나 후배 개발자들과 생각을 나누는 일을 즐기기 때문에 흔쾌히 만남에 응했습니다. 그는 자신을 10년 차 개발자로 소개했는데, 이제 스스로 개발을 하는 1인 사업자가 될 수 있다고 확신하고 있었습니다. 어떤 사업인지는 분명하지 않았지만, 그를 독립 개발자로 나서게 한 직접적인 동기는 인공지능이 만들어 주는 코드 생산력이라고 합니다. 인상 깊은 만남이었지만, 일시적인 만남이었기에 금세 잊어버렸습니다. 그런데, 그 즈음에 중국에서 함께 일했던 가까운 후배와의 만날 일이 있었습니다. 그에게 지금 다니는 회사를 나와서 외주 개발을 하는 회사를 설립하겠다는 말을 들었습니다. 마치 데자뷔 같은 장면이었습니다. 그는 자신을 믿고 따르는 두 명의 인턴사원과 손발을 맞춘 일이 있다며, 회사에서 애정이 가지 않는 일을 할 바에야 셋이서 전업으로 일을 하면 지금의 몇 배는 할 수 있다고 확신했습니다. 이번 확신의 중심에도 ‘인공지능의 위력’이 있었습니다. 인공지능의 위력을 설명하는 방식은 다음과 같은 식이었습니다. 인공지능 출현 이전에는 번거롭지만 시간이 걸리는 작업을 주니어에게 맡겨왔는데, 인공지능을 코딩에 활용하면 그럴 필요가 없다고 그는 강조했습니다. 이를테면 ‘몇 명 정도 개발자가 할 일을 혼자서 할 수 있다’며 구체적인 수치를 거론하기도 했습니다. 혼자서 할 엄두가 나지 않던 CSS 작업을 가능하게 해 줘요한편, 지금 회사의 동료 개발자는 어떻게 느끼는지도 궁금했습니다. 그는 소위 백엔드 개발자 출신이기 때문에 평소 웹이나 앱 화면을 구성하는 복잡한 프론트엔드 코드에 자신이 없었다고 합니다. 커서를 사용하기 전에는 말이죠. 그러나, 커서를 쓰고 나서는 굳이 프론트엔드 개발자에게 코드를 작성해 달라 부탁할 필요가 없다고 합니다. 원하는 화면을 그대로 프롬프트에 던지고 인공지능이 만들어 준 코드를 이해한 후에 필요한 부분만 고치면 그만이라고 말합니다. 대화를 거듭하면서 호기심이 생겨서 직접 커서를 써 보기로 했습니다. 일단, 작은 실험을 해 보기로 했죠. 저희 회사에서는 React와 Go를 기반 프로그래밍 언어로 쓰고 있는데, 이들이 화면을 표현하고, 화면에서 벌어진 사용자 행위를 서버에 전달하는 틀을 코드로 보고 싶었습니다. 참고로 저는 이 두 언어 모두에 대한 사용 경험이 없는 상태였습니다. 놀랍게도 별도의 학습 없이 몇 시간 시행착오만으로 원하는 수준의 코드를 얻을 수 있었습니다. 말 그대로 한국말로 제가 원하는 바를 프롬프트로 전달하고 나온 코드를 얻은 것이죠. 물론, 만들어진 프로그램을 실행을 하고, 어떤 의미인지를 알 수 있어야 한다는 점이 전제입니다. 하지만, 이는 개발자라면 누구나 일상으로 하는 행위입니다. 프로그래밍 작동에 대한 아주 기본적인 이해만 있다면, 자신이 만들고자 하는 것이 무엇인가를 정교한 말로 정의하는 일이 코드 작성을 대신해 주었습니다. <출처: 작가> 저는 90%의 시간은 프롬프트 작성에 쓰고, 10%만 코딩을 해요그 후로 연말과 연초를 지나는 가운데 개발자들과 만날 일이 있으면 인공지능에 대한 상대의 경험과 견해를 물었습니다. 두 가지 답변이 인상 깊었습니다. 한 번은 저를 제외한 두 명의 개발자가 정반대의 의견을 개진하는 상황이었습니다. 한 분은 조금 과장하면 예찬론자에 가까웠고, 다른 한 분은 테스트 코드 작성 아니면 처음 코드를 작성할 때나 도움이 된다고 했습니다. 저는 후자의 주장이 흥미롭게 여겨졌습니다. 그래서, 거듭 질문을 하며 그가 그렇게 느끼는 이유를 알고자 노력했습니다. 그의 답을 들으면서 머릿속에서는 두 개의 단어가 떠올랐습니다. 하나는 레거시이고 두 번째는 맥락(Context)입니다. 레거시가 떠오른 이유는 인공지능 효용성에 의문을 제기한 개발자의 가장 강력한 근거 때문입니다. 그는 자신이 속한 특정 업종에서는 “생성형” 인공지능이 큰 도움을 줄 수 없다고 주장했습니다. 생성형 인공지능의 한계를 떠올려 보면 그가 지적하는 문제의 초점을 짐작할 수 있습니다. 그가 만나는 코드에 대한 학습이 생성형 인공지능의 “모델”에는 없기 때문에, 인공지능이 아무리 많은 코드를 생성해 보아야 쓸모없는 엉뚱한 코드밖에 되지 않는다는 것입니다. 흔히 레거시라고 불리우는 시스템이 있는 조직에 가 보면 시스템을 구성하는 코드나 작동 방식이 여러 사람의 머릿속에 흩어져서 존재합니다. 이는 인공지능에서 흔히 쓰는 어휘로 표현하면, 모델이 없는 경우라고 할 수 있습니다. 물론, 인공지능 기술로 구현한 모델과 제가 여기서 언급한 모델의 물리적인 모양은 다릅니다. 하지만, 생성형 인공지능은 모델에 근거해서 무언가를 만들어 낸다는 점에서는 레거시를 모델이 없는 상황에 비유할 수 있다는 생각이 들었습니다. 그리고 그 생각 속에서 “맥락을 반영한 모델”이 있어야 생성형 인공지능이 힘을 갖는다는 점을 떠올렸습니다. 묘하게도 지난주에 만난 개발자는 하루에 10% 정도만 코드를 작성한다고 했습니다. 그리고, 나머지 90%의 시간을 자신의 일에 대한 맥락 그리고 원하는 코드의 형태에 대한 맥락을 학습시키는 일에 쓴다는 이야기를 들었습니다. 그가 쓴 단어가 제가 여기 쓴 단어들과 그대로 일치하지는 않지만, 개발자가 일하는 환경에 대한 맥락을 모델에 충분히 반영하면 코딩의 상당 부분은 인공지능이 생성해 줄 수 있다는 생각은 일치했습니다. 인공지능 도움 없이 코딩하는 일이 드문 일이 될 수 있다앞에서 인용했던 안드레이 카파시의 글을 다시 보겠습니다. 프로그래밍이 정말 빠르게 변하고 있네요. 저는 깃헙(GitHub) 코파일럿(Copilot) 대신 커서와 Sonnet 3.5를 다시 써보고 있는데, 이제는 확실히 더 낫다는 생각이 들어요. 며칠 동안 경험해 본 바로는, 제 "프로그래밍" 작업의 대부분은 이제 영어를 쓰는 것(프롬프트 작성 후 생성된 변경 사항을 검토하고 편집하는 것)이고, 약간의 "반코딩"로 바뀌었어요. 원하는 코드의 첫 부분을 쓰고, LLM이 계획을 알 수 있도록 주석을 조금 달아준 다음, 탭 키를 눌러 자동 완성을 사용하는 거죠. 가끔은 100줄짜리 코드 변경 사항이 딱 들어맞게 나오는데, 이전에는 10분 넘게 걸렸을 일이에요. 아직 모든 기능을 충분히 활용하지는 못하는 것 같아요. 마치 코딩을 처음부터 다시 배우는 것 같지만, 이제는 3년 전만 해도 유일한 방법이었던 "도움 없는" 코딩으로 돌아가는 것은 상상할 수 없어요. 앞선 지인이 일하는 방식과도 크게 괴리감이 없습니다. 그가 코딩은 10%만 한다고 할 때, 함께 자리에 있던 개발자가 자신의 일자리가 사라질 수 있겠다는 두려움을 느낀다고 했습니다. 저는 이러한 변화에 대한 제 느낌을 전하기 위해 비유를 섞어 이렇게 말했습니다. 제가 처음 개발을 할 때는 IDE가 없었습니다. 편집기에서 코드를 작성한 후에 검은색 콘솔 화면에서 컴퓨터에 명령어를 던져서 컴파일을 하고 배포를 했습니다. 하지만, 지금은 거의 대부분의 개발자들이 IDE를 씁니다. 직무와 도구라는 보편적 패턴으로 보면, 사무직이라면 누구나 엑셀이나 워드, 한글을 쓰는 것과 다르지 않습니다. 이러한 변화처럼 조만간 개발자들이 스스로 모든 코드를 짜는 일이 드문 일이 될 수 있다고 생각합니다. 또 다른 예시로 프로그램 배포도 생각해 보세요. 지난 10년 사이에 인프라 가상화는 굉장히 생소한 일에서 꽤나 보편적인 일로 바뀌었습니다. 인공지능을 이용한 코드 생산은 머지않아 보편적인 작업이 될 가능성이 높습니다. 묻고 따지고 풀어내기, 그리고 프롬프트 엔지니어링조금 서베이를 해 보면 이런 변화의 조짐을 다룬 의견을 찾거나 이러한 변화에 맞춰 완전히 새로운 패러다임을 내놓는 시도들을 어렵지 않게 찾을 수 있습니다. 하지만, 여기서는 남들의 새로운 기술 소개 대신에 독자 여러분들이 어떻게 이 상황을 받아들일 것인가에 대한 화두를 던지는 일로 마무리를 하겠습니다. 먼저 프롬프트 엔지니어링이 이제는 필수적인 기술 스택이 되었다는 점을 말하고 싶습니다. 앞서 90%의 노력을 프롬프트 작성에 시간을 쓴다는 지인이 있었습니다. 그때 필요한 지식과 기술은 무엇일까요? 묻고 따지는 풀어내는 능력이라고 할 수 있습니다. 다른 말로 하면 ‘문제 정의’라고 할 수도 있습니다. 그 일을 개발자 입장에서 자신에게 익숙하게 만들어야 합니다. 앞서 제가 커서를 사용해서 React와 Go 언어를 사용하는 웹 프로그램의 작동 방식을 이해하기 위한 코드를 생성한 경험을 말했습니다. 아래 그림은 그 과정에서 만들어진 간단한 화면과 자동 방식을 UML 형식으로 그린 그림입니다. <출처: 저자 브런치 글> 이와 같이 어떤 현상을 간단하게 표현하는 일을 모델링이라고 합니다. 제가 다뤄야 할 일을 문제라고 하면, 문제를 추상화하여 표현한 결과를 모델이라 합니다. 모델은 다양한 형식을 띨 수 있습니다. 시연을 위해 쓰는 화면을 흔히 데모라고 하는데, 이 역시 모델의 일종이라 할 수 있습니다. 제가 앞에 그린 UML 순차도 역시 전형적인 모델 표현법의 하나입니다. 프롬프트 엔지니어링에서 추구해야 할 점은 바로 (인공지능의 모델과 다른 프로그래밍의) 그 모델을 인공지능이 이해할 수 있는 형태로 만들어 가는 일이라 할 수 있습니다. 제가 개발을 배우던 시절에는 C++, CGI, ASP, Java, Oracle, Web과 같은 기술 요소들의 문법과 작동 방식을 이해하는 일이 개발자들의 공통 지식이었습니다. 하지만, 커서를 사용한 짧은 경험에서 프로그래밍 언어의 중요성이 전과 확연히 달라졌음을 느꼈습니다. 이제는 각 산업 영역이나 커뮤니티에 따라 언어를 택하는 일이 더 합리적으로 보입니다. 그리고, 그 언어의 문법이나 사용법을 배우는 방법은 책과 매뉴얼이 아니라 인공지능에 질의하며 모델을 만드는 형태가 되어야 한다는 생각이 듭니다. 나는 어떻게 경쟁력을 높일 것인가?한편, 개발자들과 인공지능에 대한 대화를 할 때, 또 다른 개발자 한 분은 전혀 다른 이야기를 했습니다. 자신이 직장에서 겪는 가장 큰 감정 노동은 너무나 당연하게 보이는 코드 개선 노력조차 하지 않는 개발자들과 함께 일하는 것이라고 했습니다. 그 자리에 있는 모든 개발자가 공감했습니다. 모두 다른 직장에 다니는 사람들이지만 유사한 자기 경험이 있는 것이죠. 제가 특정 기업의 표준 개발 프레임워크를 만들던 때가 있었습니다. 당시 가장 큰 노력이 들어가는 부분은 프레임워크 개발이 아니었습니다. 그 프레임워크를 이용해서 코드를 작성하도록 기존의 개발자들을 교육하고 움직이게 하는 일이었습니다. 당시를 돌아보면 그들 대다수가 스스로 학습을 하지 않는다는 전제가 있었습니다. 그래서 매우 지난한 일이었던 것으로 기억합니다. 커서를 쓸 때 제가 몸으로 느낀 놀라움이 당시를 소환했습니다. 이제 프레임워크를 만들어서 누군가를 교육할 필요가 없겠다는 생각이 들었습니다. 그들에게 교육을 하고, 감시를 하는 노력 대신에 인공지능에 투자할 가능성이 높겠다는 생각이 들었습니다. 마지막으로 최근에 만난 지인의 이야기를 하겠습니다. 그는 코인 거래를 자동으로 하는 프로그램을 만들기 위해 코파일럿을 사용해서 코드를 만들었다고 합니다. 그는 개발자가 아닙니다. 그래서, 처음 프로그램을 만들 당시에는 파이썬 문법을 공부하기 위해 온라인 강의를 결제했다고 합니다. 그러다 너무나 더딘 진도 때문에 인공지능 사용을 시도했는데, 결과적으로 강의를 듣지 않고도 작동하는 프로그램을 만들었습니다. 지금은 거래 중에 자주 멈추는 프로그램의 문제를 해결하고자 저희 회사 개발자에게 도움을 청하는 과정에 있습니다. 이 사건을 일반화하면 이렇게 의미를 해석할 수 있습니다. 이제는 개발자가 아닌 사람도 스스로 묻고 따질 수 있으면 인터넷 공간에 노출된 지식에 기반한 해결책을 얻을 수 있습니다. 문서나 음성 형태로도 얻을 수 있고, 코드 형태로도 얻을 수 있게 되었습니다. 다만, 공개된 정보로 학습한 인공지능이 생성한 결과가 나에게 딱 맞는 해결책은 아닐 수 있죠. 그때는 개발자(전문가)를 찾아 적정한 비용으로 문제를 해결할 수 있습니다. 상상하기에 따라서는 그 여파는 상당한 파장을 일으킬 듯합니다. 이런 변화가 이미 불가역적으로 진행되고 있는 상황에서 지금 할 수 있는 일은 무엇일지 질문하는 행위는 분명 가치가 있을 것입니다. ©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.
