대형 언어 모델(LLMs, Large Language Models)은 이미지, 텍스트 및 코드를 생성할 수 있게 되면서 창의적인 분야에서 큰 반향을 일으켰습니다. 처음에는 결과물이 꽤 유쾌했는데, 사람들 그림이 뒤틀려 있거나, 틀린 내용으로 코드를 생성할 때도 있어 어색했습니다. 그러나 상황은 점차 안정되어 나아지고 있습니다. 이러한 모델이 등장하기 전에는 그런 작업을 자동화하는 것에 대한 주요 반대 이유로, 기계는 창의적으로 생각할 수 없다는 것이었습니다. 그러나 이제 그 주장은 날이 갈수록 약해지고 있습니다. 이제 우리는 어디로 가야 할까요?
미래를 예측하는 것과 같은 모호한 주제를 생각할 때 문제는, 생각이 혼란스러워지고 명확히 생각하기 어려운 점입니다. 그래서 우리는 프레임워크와 비유를 고안해서 이용해야 합니다.
프레임워크: 소프트웨어 개발 역량 수준
소프트웨어 개발은 단순히 코드를 작성하는 것만은 아닙니다. 프로그래머에 대해 사람들이 느끼는 이미지는 어두운 방에서 컴퓨터를 보며 열심히 코드를 입력하는 사람입니다. 하루 종일 코딩한다면 매력적으로 들릴 수 있지만, 실제로 소프트웨어 개발 시간의 대부분은 코드를 작성하는 것이 아니라, 다른 사람들과 의사 소통이나 기타 관리 작업에 소요됩니다:
• 비즈니스 사용자로부터 요구 사항 수집하기
• 이러한 요구 사항을 코드로 모델링할 수 있도록 정제하기
• 디자이너 및 제품 관리자와 같은 다른 팀원과 솔루션을 시각화하고 작전 계획을 수립하는 대화
• 다른 개발자들과 기술적 설계를 수립하고 정제하기
• 인프라, 구성, 기본구성 코드 설정하기
• 실제로 일부 코드를 작성하기
• 버그 수정, 다른 사람의 코드 이해 시도, 문서 등 작성하기
• 프로덕션 배포하기
• 프로덕션 문제점 대응하기
• 추가로 다른 많은 작업들
따라서 "AI가 개발자를 대체할 것이다"와 같이 말하려면 "AI"가 코드 작성 뿐만 아니라 위의 모든 작업에도 능숙해야 합니다.
따라서 "AI가 개발자를 대체할 것이다"와 같이 말하려면 "AI"가 코드 작성 뿐만 아니라 위의 모든 작업에도 능숙해야 합니다.
하지만 위의 목록을 보면, 이러한 작업 중 일부는 미래에 자동화될 수도 있지만 아직은 아닙니다. 이러한 생각을 어떻게 구성해야 할까요?
자율 주행 자동차 세계에서는 자동화 수준을 분류하는 방법을 제시했습니다. 이것은 이산적인 수준으로 분리하여, 자동화가 전혀 없음부터, 부분 자동화, 완전 자동화까지 이어집니다. 이것은 여러 이유로 매우 유용한데요:
• 현재 기술로 무엇을 할 수 있는지 명확하게 설명합니다.
• 우리가 흑백으로 생각하지 않게 합니다 - 인간이 운전하는 일을 AI가 운전하는 일로 모두 대치하는 대신에 회색 영역에서 인간을 지원하여, AI가 비상 브레이크, 차선 중앙 정렬 등의 일부를 맡습니다.
이러한 분류가 AI 기반 소프트웨어 개발에서는 어떻게 보이나요?
• 가장 낮은 단계는 이전에 우리가 하던 일과 같습니다 - 작업에 AI가 포함되지 않습니다. 물론 컴파일러, 빌드 프로세스 등 다른 유형의 자동화가 있었지만, 그러한 것들은 AI가 아니라 사람이 작성한 결정론적 자동화였습니다.
• 다음 단계는 현재 우리가 하고 있는 일입니다 - 개발자들이 ChatGPT나 GitHub Copilot을 사용하여 도움을 받습니다. 이를 이용하여 테스트 작성, 기본구성 코드 작성, 리팩토링, 코드/오류 이해 등에 사용합니다. 이것은 채팅으로 다른 개발자와 대화하는 것과 비슷합니다. 질문을 하고 도움을 받을 수 있지만, 그들은 당신의 컴퓨터에 액세스할 수 없으므로 파일을 생성하거나 빌드 명령을 실행하거나 프로덕션에 배포할 수 없습니다.
• 가장 높은 수준은 프로젝트의 일부 또는 전체를 개발자에게 위임하는 것과 같습니다. 이러한 "AI 코더"들은 요구 사항을 수용하여 코드를 작성하고 오류를 수정하며 최종 제품을 프로덕션에 배포할 것입니다. 이런 일이 실현되려면 여러 달이 지나야만 가능할 것으로 예상했지만, Devin 데모를 보고 예상이 틀렸음이 드러났습니다 - 지금은 간단한 개발 작업만 수행할 수 있지만 미래에는 개선될 것입니다.
AI 모델의 능력 외에, 솔루션의 정확도에 대해서도 생각해봐야 합니다. 초기에는 이러한 모델이 환각에 빠진다거나 특정 방식으로 프롬프트를 표시해야만 원하는 결과를 얻을 수 있었습니다. 이는 채택을 저해하는 요소이며, 대부분은 이 단계에서 AI 도움을 포기합니다. 그러나 이것도 개선 중이며, 최신 모델은 그런 정도까지 프롬프트 엔지니어링이 필요하지 않습니다. 또한, 모델은 자신의 훈련 데이터에 의존하는 대신 웹을 탐색하여 "학습"할 수 있어야 합니다. 이는 새로운 버전의 라이브러리와 프로그래밍 언어가 도입될 때 중요합니다.
프레임워크: 아웃소싱 소프트웨어 개발
지금 우리가 능력을 확보했으니, 이것이 팀 또는 조직 구조에 어떤 영향을 미치는지 살펴볼까요? 회사들은 여러 가지 방식으로 소프트웨어 개발을 합니다:
• 모두 사내 개발
• 대부분 사내 개발, 약간만 외주
• 대부분 외주, 약간만 사내 개발
• 모두 외주
어느 면에서 AI 코더는 외부 소프트웨어 벤더나 컨설턴트로 생각할 수 있습니다. 일부 회사는 그들을 많이 사용하고 일부 회사는 그렇지 않습니다. 구성에 상관없이, 내부 팀이 그들의 작업을 감독하는 것이 항상 중요합니다. 이는 벤더의 결과물이 회사의 장기적인 목표와 일치하는지 확인하기 위함 입니다. 물론 계약으로 이를 해결할 수 있지만, 이는 일반적으로 특정 벤더나 프로젝트에만 적용되며 이 방법으로 장기적인 목표까지 강요할 수는 없습니다. 벤더를 이끌어 줄 수 있는 소수의 내부 팀을 보유하는 것이 항상 좋습니다. 마찬가지로, AI 개발자를 EC2 인스턴스 식으로 임대할 때에도 그들의 작업을 감독할 내부 소프트웨어 개발팀을 유지하면 좋습니다.
프레임워크: 소프트웨어 개발은 복잡성을 모델링 하는 일
비즈니스 문제를 해결한다고 말할 때, 얘기해야 할 가장 큰 이슈 중 하나인 Excel에 대해 이야기해보겠습니다. 세계가 Excel을 기반으로 돌아간다는 것은 잘 알려진 비밀이며, 10억 명 이상의 사람들이 사용하고 있습니다. Excel은 데이터 정리, 데이터 분석 수행 또는 일부 프로세스를 자동화 하는 비즈니스 사용자들에게 진입 장벽이 매우 낮습니다. 그러나 우리는 Excel을 복잡한 비즈니스 워크플로우에 사용할 수 없습니다. 왜냐하면 그것은 세밀한 액세스 제어, 지원되지 않는 시스템과의 통합 능력, 테스트 용이성, 재사용성이 없고, 벤더 종속되기 때문입니다. 마찬가지로, Power Automate 등 "Low Code" 솔루션도 마찬가지입니다.
원래 질문으로 돌아와서, 비즈니스 사용자들이 소프트웨어 개발자의 도움 없이도 AI 코더를 사용하여 이러한 복잡한 워크플로우를 만들 수 있을까요?
비즈니스 사용자들이 소프트웨어 개발자의 도움 없이도 AI 코딩 도구를 사용하여 이러한 복잡한 워크플로우를 만들 수 있을까요?
생각해 보면, Excel과 Low Code 도구는 수십 년 동안 존재했지만, 소프트웨어 개발 직업이 여전히 존재하는 이유는 무엇일까요? 그것은 소프트웨어 개발을 코드 작성으로만 생각하기 때문입니다. 복잡한 문제를 해결하려면 사람이 나서서 현실 세계 영역의 비즈니스 문제를 디지털 모델로 효과적으로 변환할 수 있습니다.
다시 말해, YouTube 튜토리얼을 보고 목공 작업을 수행할 수 있다고 해서 시공 엔지니어의 도움 없이 10층 건물을 지을 수 있는 것은 아닙니다. 일을 올바르게 배우면 천천히 시공 엔지니어가 될 수는 있습니다! 그 일을 올바르게 배우기 위해 시간을 투자할 것인지, 아니면 경험이 풍부한 엔지니어를 고용할 것인지의 문제일 뿐입니다.
그래서 이러한 사람들이 Excel을 사용하든 최신 AI 코더를 사용하든, 그들이 복잡한 논리를 모델링하고 있다면, 그들은 여전히 소프트웨어 개발자라고 저는 생각합니다! 그들은 비즈니스 요구 사항을 표현하려고 다른 도구를 사용하고 있을 뿐입니다 - 스프레드시트 수식, 코드 또는 프롬프트.
프레임워크: 파이의 크기
이 주제에 대한 대부분의 불안은 소프트웨어 개발 시장 규모가 그대로 고정되어 있을 것이라는 가정에 기반합니다 - AI 개발자가 인간으로부터 "시장 점유율"을 점차 빼앗아 갈 것이라는 가정이지요.
이전 절에서 우리는 "비즈니스 문제 해결"의 시장 규모가 소프트웨어 개발보다 훨씬 더 크다는 것을 알고 있습니다. 그러므로 소프트웨어 개발이 곧 사라질 것이라고 믿을 이유가 없습니다.
프레임워크: 공식 비즈니스 논리 정의
비즈니스 논리는 항상 명확한 형식으로 정의되어야 합니다. 이것이 프로그래밍 언어에서 "if", "switch"와 같은 영어 단어를 사용하더라도 이러한 단어가 무엇을 의미하는지 매우 정확히 다루고, 잘못된 단어를 사용하면 작동하지 않는 이유입니다. 생각해 보면, 엑셀 수식이나 Low Code 플로우에도 동일한 원리가 적용됩니다.
미래에, 대화형 영어로 작성한 지시사항에 소프트웨어 제품을 생성할 수 있는 AI 코더가 있더라도, 비즈니스 논리의 기반이 되는 공식적인 정의는 여전히 백엔드에서 생성할 것으로 생각합니다. 오늘날 우리가 사용하는 언어나 프레임워크와는 매우 다르게 비칠 지 모르지만, 비즈니스 논리의 공식 정의는 "코드"와 매우 유사할 것입니다.
AI 코더가 대화형 영어에서 이러한 비즈니스 논리를 결정론적인 방식으로 생성하기까지는, 백엔드에서 생성된 코드를 이해하고 필요에 따라 변경할 수 있는 사람들이 필요할 것입니다. 이러한 사람들이 소프트웨어 개발자가 될 것입니다.
결론
요약하면, 예측 가능한 미래에도 소프트웨어 개발자에 대한 시장이 여전히 존재할 것으로 믿습니다. 다만 작업의 성격은 변화하고 사용하는 도구는 현재와 매우 다를 수 있습니다.
