IT/모바일
이 글은 마틴 파울러(Martin Fowler)가 포스팅한 ‘프로그래밍을 위한 LLM 프롬프트의 예(An Example of LLM Prompting for Programming)’에 대한 O'Reilly Media 콘텐츠 전략 담당 부사장 Mike Loukides의 해설입니다.
*국내에 마틴 파울러의 포스팅을 번역해 소개한 블로그도 있으니 관련 내용은 링크에서 참고하실 수 있습니다.
GPT 모델과 그 후속 모델이 ‘프로그래밍’을 어떻게 변화시킬지, 많은 이들이 기대에 부풀어 있습니다. 하지만 분명한 것은 프로그래밍 프로세스가 "챗GPT, 신발을 판매하는 엔터프라이즈용 애플리케이션을 만들어 주세요"가 되어서는 안 된다는 것입니다.
(저를 비롯해) 많은 이들이 어떤 프로그램을 작성하기 위해 챗GPT를 사용해 봤을 겁니다. 때로는 적절하게, 때로는 그렇지 않은 경우도 있었지만, 아직까지 챗GPT로 전문적인 수준의 개발 사례와 결과물을 보여주는 사람은 보지 못했습니다.
앞서 마틴 파울러의 포스팅에서 파울러는 씽크웍스(Thoughtworks)의 중국 기술 책임자인 쉬 하오(Xu Hao)가 챗GPT로 엔터프라이즈 애플리케이션의 일부를 구축하는 데 사용한 프로세스에 관해 설명합니다.
척 보기에도 쉬 하오가 작업 코드를 생성하는 데 사용한 프롬프트가 매우 길고 복잡하다는 것을 알 수 있습니다.
이러한 프롬프트를 작성하려면 챗GPT 사용과 소프트웨어 개발 모두에서 상당한 전문 지식이 필요합니다. 줄 수를 세어보지는 않았지만, 프롬프트의 총길이는 챗GPT가 생성한 코드의 줄 수보다 더 많을 것으로 추측됩니다.
먼저 이 코드를 작성할 때 쉬 하오가 사용하는 전반적인 전략에 주목해 봅시다. 그는 '지식 생성(Knowledge Generation)'이라는 전략을 사용하고 있습니다.
그의 첫 프롬프트는 매우 깁니다. 여기에는 아키텍처, 목표, 설계 지침이 있으며, 챗GPT에 코드를 생성하지 말라고 명시적으로 지시합니다.
대신 목표를 달성하기 위한 일련의 단계인 행동 계획을 요청합니다. 챗GPT가 작업 목록을 구체화하도록 한 후, 한 번에 한 단계씩 코드를 요청하고 해당 단계가 올바르게 완료되었는지 확인한 후 계속해서 다음을 진행합니다.
대부분의 프롬프트는 테스트에 관한 것입니다. 챗GPT는 생성하는 각 함수에 대해 테스트를 생성하라는 지시를 받습니다.
적어도 ‘이론적’으로는 전문 프로그래머들 사이에서 테스트 주도 개발(TDD)이 널리 실행되고 있습니다. 하지만 제가 만난 대부분의 사람들은 실상은 그렇지 않다는 의견에 동의하는 편입니다.
대부분의 테스트는 단순한 경향이 있습니다. 코너 케이스(corner cases), 오류 조건(error conditions) 등 '어려운 것'에 대해서는 거의 다루지 않습니다.
그런 모습들을 이해할 수는 있지만, 한 가지 분명히 해야 할 것은 AI 시스템으로 코드를 작성하려면 해당 코드를 철저하게 테스트해야 한다는 것입니다. (AI 시스템이 테스트를 작성한다면, 그 테스트 자체도 테스트해야 할까요? 그 질문에는 노코멘트 하겠습니다.)
코파일럿(Copilot), 챗GPT 또는 기타 도구를 사용해 코드를 생성해 본 사람들은(저의 지인 중 다수) 테스트에 주의를 기울여야 한다는 데 동의합니다.
일부 오류는 쉽게 발견할 수 있습니다. (챗GPT는 종종 존재하지 않는 ‘라이브러리 함수’를 호출합니다.) 그러나 훨씬 더 미묘한 오류도 발생하여 주의 깊게 검사하고 테스트하지 않으면 ‘올바른 것처럼 보이는’ 잘못된 코드를 생성할 수 있습니다.
파울러의 포스팅을 읽고 챗GPT로 산업용 소프트웨어를 작성하는 것이 간단하다고 결론을 내리는 것은 금물입니다. 같은 상황을 놓고 봤을 때, 상당한 전문 지식에 더불어 쉬 하오가 달성하고자 하는 목표, 그리고 달성 방법에 대한 탁월한 이해가 필요합니다.
이러한 이해 중 일부는 아키텍처에 관한 것이고, 일부는 큰 그림(소프트웨어가 사용될 컨텍스트)에 관한 것이며, 일부는 프로그램을 작성할 때 항상 발견하는 사소한 것, 즉 사양에서 말했어야 하지만 말하지 않은 것을 예상하는 것입니다.
프롬프트는 기술 스택에 대해 자세히 설명해야 합니다. 또한 구성 요소를 구현하는 방법, 사용할 아키텍처 패턴, 필요한 다양한 유형의 모델, 챗GPT가 작성해야 하는 테스트에 관해서도 설명해야 합니다.
쉬 하오는 분명 프로그래밍을 하고 있지만, 이는 다른 종류의 프로그래밍입니다.
1950년대부터 우리가 '프로그래밍'으로 이해해 온 것과 분명히 관련이 있지만, C++나 자바스크립트와 같은 공식적인 프로그래밍 언어를 사용하지 않은 것입니다.
대신 아키텍처, 시스템 전체에 대한 이해, 테스트에 훨씬 더 중점을 둡니다. 이런 기술이 새로운 것은 아니지만, 기술(을 사용하는 방식에) 변화가 왔다는 점이 중요해 보입니다.
또한, (적어도 현재로서는) 중요한 핸디캡(?!)이 있는 챗GPT의 제한 내에서 작업해야 한다는 것도 염두에 둘 필요가 있습니다.
챗GPT에 제공된 정보가 다른 사용자에게 유출되지 않을 것이라고 가정할 수 없습니다. 챗GPT로 프로그래밍하는 사람은 프롬프트에 독점 정보를 포함하지 않도록 주의해야 합니다.
직접 자바스크립트를 작성하는 것보다 챗GPT로 개발하는 것이 더 빠를까요? 아마도 그럴 수 있습니다. (파울러의 포스팅에는 시간이 얼마나 걸렸는지는 나와 있지 않습니다.)
쉬 하오가 라이브러리 함수 등의 세부 정보를 찾는 데 시간을 들이지 않고도 이 코드를 개발할 수 있었을까요? 거의 그랬을 겁니다.
하지만 제 생각에는 코드를 생성하는 데 걸리는 시간이 90%가 아니라 25~50% 정도 단축된 것 같습니다(다시 한번 추측입니다).
(포스팅에는 쉬 하오가 작동하는 코드를 생성하는 프롬프트를 얻기 위해 몇 번이나 시도해야 했는지는 나와 있지 않습니다.)
그래서… 챗GPT는 유용한 도구이며, 시간이 지남에 따라 더 좋아질 도구임은 의심할 여지가 없습니다. 사용법을 잘 익힌 개발자는 더 효과적으로 사용할 수 있겠죠. 25~50%가 그리 놀랄만한 수준은 아닙니다만, 챗GPT를 효과적으로 사용하는 것도 분명한 학습이나 배움에 의한 기술일 수 있습니다.
그것이 누군가의 일자리를 빼앗는 것으로 이어지지는 않을 것입니다. 하나의 작업을 반복적으로 수행하는 직업을 가진 이들에게는 위협일 수 있지만, 프로그래밍이란 것은 그런 방식으로 이뤄지지 않습니다. 그런 적도 없고요.
프로그래밍은 문제 해결에 기술을 적용하는 것입니다. 반복적으로 작업을 수행해야 하는 경우, 자신의 기술을 사용하여 스크립트를 작성하고 솔루션을 자동화합니다.
챗GPT는 이러한 방향으로 나아가는 또 다른 단계로, 스택오버플로에서 문서를 찾고 질문하는 작업을 자동화한 것이라고 생각할 수도 있겠습니다. 주니어 프로그래머가 배우고 이해해야 하는 또 하나의 필수 도구가 생긴 것일 수도 있겠습니다. (이미 '부트 캠프'에서 이런 것들을 가르치고 있다고 해도 놀랍지 않습니다.)
그렇다면 챗GPT가 우리가 생각하는 프로그래밍에 위협이 되는 부분이 있다면 무엇일까요?
챗GPT로 중요한 애플리케이션을 개발하고 나면 무엇이 남을까요? 사람이 작성하지 않았고, 아무도 깊이 이해하지 못하는 소스 코드가 남게 됩니다.
작성에 몇 분 걸리지 않았더라도 그것은 '레거시 코드'에 해당합니다. 이는 10년, 20년, 30년 전에, 그러니까 더 이상 회사에서 일하지 않는 팀 혹은 누군가가 작성했지만 유지관리, 확장 및 디버깅이 필요한 소프트웨어와 유사한 셈입니다.
(대부분의 사람들은 소프트웨어 ‘유지관리’보다 ‘그린필드 프로젝트’를 선호합니다.)
프로그래머의 작업이 유지관리 쪽으로 훨씬 더 강력하게 이동한다면 어떻게 될까요? 챗GPT와 그 후속 버전은 출처와 상관없이 레거시 코드 작업을 위한 더 나은 도구를 제공하는 방향으로 발전하게 될 겁니다.
이미 놀라울 정도로 코드 설명에 능숙한데다, 대규모 코드 기반을 탐색하고, 이 정보를 사용해 디버깅에 도움이 되는(!) 확장 기능도 쉽게 상상해볼 수 있겠습니다.
이러한 도구가 만들어질 것이라고 확신하지만 아직은 존재하지 않습니다. 이러한 도구가 개발되면 프로그래머가 소프트웨어를 개발하는 데 사용하는 기술이 크게 변화할 것입니다.
챗GPT, 코파일럿 및 기타 도구는 소프트웨어 개발 방식을 바꾸고 있습니다. 하지만 소프트웨어 개발이 사라질 것이라고 생각하지는 마세요.
챗GPT를 보조 도구로 사용하여 프로그래밍하는 것은 더 쉬울 수 있지만 목표, 컨텍스트, 시스템 아키텍처, 그리고 무엇보다도 테스트에 대한 철저한 이해가 필요하기 때문에 결코 간단하지 않습니다.
사이먼 윌리슨(Simon Willison)의 말처럼 "이것은 사고(thinking)를 위한 도구이지, 사고(thinking)를 대체하는 도구가 아닙니다."
- 원문 : 오라일리, Real World Programming with ChatGPT
- 번역 : DeepL
- 편집 : 한빛미디어 마케팅팀
>> 주목할 키워드 : 테스트, 아키텍처
>> 키워드 연관 도서 : <풀스택 테스트>, <소프트웨어 아키텍처 101>
10가지 테스트 기술의 기본 원칙과 전략
소프트웨어 개발 주기 동안 수행되는 10가지 테스트 기술의 기본 원칙. 상황별로 각 기술을 활용하는 방법과 전략. 도구와 실무 접근법에 더한 저자의 노하우까지, 테스트의 모든 것...
엔지니어링 접근 방식으로 배우는 소프트웨어 아키텍처 기초
모든 기술 스택에 고루 적용되는 아키텍처의 원칙. 지난 10년간 이룩한 모든 혁신과 현대적 관점에서 바라본 소프트웨어 아키텍처를 만나다. 막막했던 아키텍처가 쉬워지는 실무 지침서...
TAG :
최신 콘텐츠