소프트웨어 개발의 미래에 대한 고찰
(sheshbabu.com)- 대규모 언어 모델(LLMs)은 이미지, 텍스트, 코드를 생성할 수 있게 되면서 창작 분야에서 큰 파장을 일으킴
- 처음에는 사람의 손이 잘못 그려진 그림, 잘못된 사실을 말하는 등 웃긴 결과물이 많았지만, 점차 개선되고 있음
- 이러한 모델들이 등장하기 전에는 기계가 창의적으로 생각할 수 없다는 것이 자동화에 대한 주된 반대 논리였으나, 이제 그 주장은 점점 약해지고 있음
- 이제 어디로 가야할까?
Framework: 소프트웨어 개발 능력 수준
- 소프트웨어 개발은 단순히 코드를 작성하는 것 이상임
- 프로그래머의 이미지는 어두운 방에서 컴퓨터를 바라보며 열심히 코드를 타이핑하는 사람이지만, 실제로는 코드 작성보다 다른 작업에 더 많은 시간을 할애함
- 비즈니스 사용자로부터 요구사항 수집
- 요구사항을 코드로 모델링할 수 있도록 정제
- 디자이너, 제품 관리자와 같은 팀원과 솔루션 시각화 및 계획 수립
- 다른 개발자와 기술 설계 및 정제
- 인프라 설정, 구성, 보일러플레이트 등
- 실제 코드 작성
- 디버깅, 타인의 코드 이해, 문서 작성 등
- 프로덕션 배포
- 프로덕션 이슈 대응
- 그 외 많은 작업들
- "AI가 개발자를 대체할 것이다"라는 말은 AI가 위의 모든 작업에 능숙해야 한다는 것을 의미함
- 하지만 위 목록을 보면 이러한 작업 중 일부는 향후 자동화될 수도 있지만 아직은 자동화될 수 없는 것처럼 보임
자율주행 자동차의 자동화 수준 분류
- 자율주행 자동차 분야는 자동화 수준을 분류하는 방법을 개발함
- 이 분류는 현재 기술이 무엇을 할 수 있는지 명확하게 설명하고, 흑백논리를 피함
- 이런 분류를 AI 기반 소프트웨어 개발에 대해 적용해 보면
- 가장 낮은 단계는 이전에 우리가 가지고 있던 것, 즉 업무에 AI가 관여하지 않는 단계. 물론 컴파일러, 빌드 프로세스 등과 같은 다른 유형의 자동화가 있었지만 이는 AI가 아니라 사람이 작성한 결정론적 자동화에 해당
- 그 다음 단계는 현재 우리가 가진 것
- 개발자들이 ChatGPT 또는 GitHub Copilot을 사용하여 지원받는 것
- 개발자들은 테스트 작성, 상용구 코드, 리팩토링, 코드/오류를 이해하기 위해 이를 사용
- 채팅을 통해 동료 개발자와 대화하면서 질문하고 도움을 받을 수는 있지만 컴퓨터에 대한 액세스 권한이 없으므로 파일을 만들거나 빌드 명령을 실행하거나 프로덕션에 배포할 수는 없음
- 가장 높은 단계는 프로젝트의 일부 또는 전체를 "AI 코더"에게 위임하는 것
- AI 코더가 요구 사항을 받아 코드를 작성하고 오류를 수정한 후 최종 제품을 프로덕션에 배포
- 아직 이런 일이 일어나기까지는 몇 달이 더 걸릴 것이라고 생각했지만, 지금은 간단한 개발 작업만 수행할 수 있지만 앞으로 개선될 가능성이 있다는 것이 Devin 데모를 통해 증명됨 Devin, 첫 번째 AI 소프트웨어 엔지니어
- AI 모델의 능력 외에도 솔루션이 얼마나 정확한지 생각해봐야함
- 이러한 모델은 환각에 취약하거나 원하는 것을 얻기 위해 특정 방식으로 프롬프트해야 하는 경향이 있음
- 이로 인해 도입에 마찰이 발생하고 대부분의 사람들이 이 시점에서 AI 비서를 포기하게 됨
- 하지만 이 역시 개선되고 있으며, 최신 모델에서는 이러한 수준의 프롬프트 엔지니어링이 필요하지 않음
- 또한 모델은 학습 데이터에 의존하는 대신 웹을 탐색하여 '학습'할 수 있어야 함
- 이는 새로운 버전의 라이브러리와 프로그래밍 언어가 도입됨에 따라 중요한 사항
Framework: 아웃소싱된 소프트웨어 개발
- 이제 역량을 구축했으니 팀이나 조직 구조에 어떤 영향을 미칠까? 회사는 다양한 방식으로 소프트웨어 개발을 수행함:
- 완전 인하우스
- 소수의 벤더와 함께 대부분 인하우스
- 다수의 벤더와 함께 조금만 인하우스
- 완전 벤더
- AI 코더를 아웃소싱된 소프트웨어 벤더/컨설턴트로 생각할 수 있음
- 회사 내부 팀이 벤더의 작업을 감독하는 것이 중요함
- 계약을 통해 이 문제를 해결할 수도 있지만, 계약은 일반적으로 특정 공급업체나 프로젝트에만 적용되며 이 방법으로는 장기적인 목표를 강제할 수 없음
- 벤더를 안내할 수 있는 소규모의 사내 팀이라도 두는 것이 좋음
- 마찬가지로, EC2 인스턴스처럼 AI 코더를 임대할 수 있는 경우에도 소프트웨어 개발자로 구성된 사내 팀이 작업을 감독하는 것이 유리
Framework: 소프트웨어 개발은 복잡성 모델링
- 비즈니스 문제를 해결하는 것에 대해 이야기할 때, Excel을 예로 들 수 있음.
- Excel은 진입장벽이 매우 낮아서 이걸로 데이터를 정리하고, 데이터 분석을 수행하거나, 일부 프로세스를 자동화 가능
- 하지만, 세분화된 액세스 제어, 지원되지 않는 시스템과의 통합 기능, 테스트 가능성, 재사용성, 공급업체 종속성 등의 기능이 없기 때문에 복잡한 비즈니스 워크플로우에는 적합하지 않음
- Power Automate 등과 같은 "로우 코드" 솔루션도 마찬가지
- "비즈니스 사용자가 소프트웨어 개발자의 도움 없이 AI 코더를 사용하여 이러한 복잡한 워크플로우를 만들 수 있을까?"
- 생각해 보면 Excel과 로우 코드 도구는 수십 년 동안 존재해 왔는데 소프트웨어 개발이라는 직업은 왜 여전히 존재할까?
- 그것은 소프트웨어 개발을 단순히 코드를 작성하는 것으로 생각하기 때문
- 복잡한 문제에는 이러한 복잡성을 효과적으로 관리하고 비즈니스 문제를 실제 도메인에서 디지털 모델로 변환할 수 있는 사람이 필요
- 다시 말해, 토목 기술자의 도움 없이 유튜브 튜토리얼을 통해 나무 창고를 지을 수 있다고 해서 10층짜리 건물도 똑같이 지을 수 있고, 지어야 한다는 뜻은 아님
- 이 일을 제대로 하는 방법을 배우다 보면 서서히 토목 기술자가 될 수 있음
- 다만 제대로 배우기 위해 시간을 투자할 것인지, 아니면 숙련된 엔지니어를 고용할 것인지의 문제일 뿐
- 따라서 Excel을 사용하든 최신 AI 코더를 사용하든, 복잡한 로직을 모델링하고 있다면 여전히 소프트웨어 개발자라고 생각
- 다만 스프레드시트 수식, 코드, 프롬프트 등 비즈니스 요구 사항을 표현하는 도구가 다를 뿐
Framework: 파이의 크기
- 이 주제를 둘러싼 대부분의 불안은 소프트웨어 개발 시장의 규모가 그대로 유지된다는 가정, 즉 AI 코더가 서서히 인간으로부터 '시장 점유율'을 빼앗아갈 것이라는 가정을 전제로 함
- "비즈니스 문제 해결" 시장의 크기가 소프트웨어 개발보다 훨씬 크기 때문에 소프트웨어 개발이 곧 사라지지는 않을 것임
Framework: 형식적 비즈니스 논리 정의
- 비즈니스 로직은 항상 명확한 형식으로 정의되어야 함
- 그렇기 때문에 프로그래밍 언어는 'if', 'switch' 등과 같은 영어 단어를 사용하더라도 그 단어의 의미를 매우 엄격하게 정의하고 잘못된 단어를 사용하면 작동하지 않음. 생각해 보면 Excel 수식이나 로우 코드 흐름도 마찬가지
- 미래에는 AI 코더가 대화형 영어로 주어진 명령어를 통해 소프트웨어 제품을 생성할 수 있다고 해도 백엔드에서 생성되는 비즈니스 로직에 대한 기본적인 공식 정의는 여전히 존재할 것이라고 생각
- 오늘날 우리가 사용하는 언어나 프레임워크와는 매우 다르게 보일 수 있지만, 비즈니스 로직의 공식적인 정의는 '코드'와 매우 유사하게 들림
- AI 코더가 이러한 비즈니스 로직을 결정론적인 방식으로 대화형 영어로 생성할 수 있을 때까지는 백엔드에서 생성된 코드를 이해하고 필요한 경우 변경할 수 있는 사람이 여전히 필요. 바로 소프트웨어 개발자
결론
- 업무의 성격이 바뀌고 우리가 사용하는 도구가 지금과는 매우 달라지겠지만, 가까운 미래에도 소프트웨어 개발자를 위한 시장은 여전히 존재할 것이라고 생각
OpenAI가 유명세를 타기 전까지만 해도 AI 도입이 가장 늦게 혹은 불가능하다고 여겼던 예술분유 부터 AI가 영역을 확장하는 것을 보면, 지금 '사람'만이 가능하다고 생각하는 것들이 '안전'하지 않을 수 있다는 생각이 문득 들었습니다.
AI 프롬프트 중요성이 날로 부각되면서, 점점 더 명확한 스펙 정의와 요건 정리가 필수임을 각성하는 유저가 많아질것이고, 이것은 결국 향후 개발자가 작업하는데 유리한 방향으로 작용될 수 있을거 같네요.
코드는 사람을 위한 것이고, 기계가 코드를 작성한다는 건 사람이 여전히 필요하다는 것이니 먼 미래의 발전방향은 아니라고 생각합니다. 초기에 실험했던 backend-GPT (https://github.com/RootbeerComputer/backend-GPT) 처럼 일종의 블랙박스에 우리가 원하는 질문을 던져넣으면 DB 에 접근해서 데이터를 처리하고 그 앞뒤의 경험에는 사람이 일부 개입하는 형태로 발전할 거라고 봅니다.
chat GPT, Copilot 에 대해서 많이들 이야기 하는 부분중에 프롬프트 엔지니어링에 대해서 언급이 되는 것 같습니다. 우리가 주로 프로그래밍을 위해 회의를 하며, 말로써 빠르게 의사 전달을 하고 정리해서 확인하고 하는 과정들을 어떻게 AI 코더에게 효율적으로 전달하고 의사소통할 수 있는가도 중요한 요소라고 생각되네요 ^^.