[번역] 소프트웨어 개발의 미래에 대한 생각

원문 : https://www.sheshbabu.com/posts/thoughts-on-the-future-of-software-development/

대규모 언어 모델(LLM)은 이미지, 텍스트, 코드를 생성할 수 있게 되면서 창작 분야에서 큰 반향을 불러일으켰습니다. 처음에는 사람 손을 제대로 그리지 못하기도 했고 잘못된 사실과 코드를 환각하는 그림을 그려 꽤 웃긴 결과도 많았습니다. 하지만 이런 문제는 천천히 그리고 꾸준히 개선되고 있습니다. 대규모 언어 모델이 등장하기 전, 창의적인 작업을 자동화하는 데 반대하는 주요 주장은 기계가 창의적으로 생각할 수 없다는 것이었습니다. 이제 이 주장은 날이 갈수록 약해지고 있습니다. 이제 어떻게 해야 할까요?

미래 예측과 같은 막연한 문제에 대해 생각하려고 할 때 생각이 흐려지고 명확하게 생각하기 어려워지기 쉽습니다. 따라서 우리는 의지할 수 있는 프레임워크와 비유를 만들어야 합니다.

프레임워크: 소프트웨어 개발 역량 수준

소프트웨어 개발은 단순히 코드를 작성하는 것만이 아닙니다. 사람들이 갖고 있는 프로그래머의 이미지는 어두운 방에 앉아 컴퓨터를 보며 격렬하게 코드를 타이핑하는 사람입니다. 하루 종일 코딩하는 것이 매우 매력적으로 들리지만 대부분의 소프트웨어 개발 시간은 코드 작성보다는 다른 사람과의 의사소통이나 기타 관리 업무에 소비됩니다.

• 비즈니스 사용자로부터 요구 사항 수집
• 이러한 요구 사항을 코드로 모델링할 수 있도록 구체화하기
• 디자이너 및 프로덕트 매니저와 같은 다른 팀원들과 함께 솔루션을 시각화하고 공격할 작전을 세우기 위해 대화하기
• 다른 개발자와 협력하여 기술 설계를 도출하고 이를 개선합니다.
• 인프라, 구성, 보일러플레이트 등 설정하기
• 실제로 코드 작성하기
• 디버깅, 다른 사람의 코드 이해, 문서 작성 등
• 프로덕션에 배포
• 실서비스 대응
• ... 그리고 더 많은 작업

따라서 "AI가 개발자를 대체할 것입니다."라는 말을 하려면 "AI"가 코드 작성뿐만 아니라 위의 모든 작업에 능숙해야 한다는 뜻입니다.

하지만 위의 목록을 보면 이러한 작업 중 일부는 향후 자동화할 수 있지만 아직은 자동화할 수 없는 것처럼 보입니다. 이 생각을 어떻게 정리할까요?

자율주행 자동차의 세계에서는 자동화 수준을 분류하는 방법을 생각해 냈습니다. 자동화 없음에서 부분 자동화, 완전 자동화까지 단계별로 설정할 수 있습니다. 저는 여러 가지 이유로 이 기능이 매우 유용하다고 생각합니다.

• 현재 기술이 무엇을 할 수 있는지 명확하게 설명합니다.
• 흑백으로 사고하는 것을 방지합니다. - AI가 인간 운전자를 완전히 대체하는 인간 운전자 vs AI 운전자의 문제가 아니라 긴급 제동, 차선 중앙 유지 등과 같이 인간 운전자가 AI의 도움을 받는 회색 영역이 있을 수 있습니다.

이러한 분류는 AI 기반 소프트웨어 개발에는 어떻게 적용될까요?

• 가장 낮은 단계는 이전에 사용하던 단계입니다. - 업무에 AI가 개입하지 않습니다. 물론 컴파일러, 빌드 프로세스 등과 같은 다른 유형의 자동화도 있었지만 이는 AI가 아니라 사람이 작성한 결정론적 자동화였습니다.
• 다음 단계는 현재 우리가 가진 것입니다. - 개발자를 지원하기 위해 ChatGPT 또는 깃허브 코파일럿을 사용합니다. 테스트 작성, 보일러플레이트 코드, 리팩터링, 코드/에러 이해 등의 작업에 사용합니다. 이는 채팅을 통해 동료 개발자와 대화하면서 질문하고 도움을 받을 수는 있지만 컴퓨터에 액세스할 수 없으므로 파일을 만들거나 빌드 명령을 실행하거나 프로덕션에 배포할 수 없는 것과 같습니다.
• 가장 높은 단계는 프로젝트의 일부 또는 전체 프로젝트를 개발자에게 위임하는 것과 같습니다. 이러한 "AI 코더"는 요구 사항을 받아 코드를 작성하고, 오류를 수정하고, 최종 제품을 프로덕션에 배포합니다. 이런 일이 일어나려면 아직 몇 달이 더 걸릴 것이라고 생각했지만, Devin 데모를 통해 지금은 간단한 개발 작업만 수행할 수 있지만 앞으로 개선될 가능성이 있다는 것이 증명되었습니다.

AI 모델이 할 수 있는 것 외에도 솔루션이 얼마나 정확한지 생각해 보아야 합니다. 초기에는 이러한 모델이 환각에 빠지기 쉽거나 원하는 결과를 얻기 위해 특정 방식으로 프롬프트해야 합니다. 이로 인해 도입에 마찰이 발생하고 대부분의 사람들이 이 시점에서 AI 어시스턴트를 포기합니다. 하지만 이 역시 개선되고 있으며, 최신 모델에서는 이러한 수준의 즉각적인 엔지니어링이 필요하지 않습니다. 또한 모델은 학습 데이터에 의존하지 않고 웹을 탐색하여 "학습"할 수 있어야 합니다. 이는 새로운 버전의 라이브러리와 프로그래밍 언어가 도입될 때 중요합니다.

프레임워크: 외주 소프트웨어 개발

이제 역량을 구축했는데 팀이나 조직 구조에 어떤 영향을 미칠까요? 회사는 다양한 방식으로 소프트웨어 개발을 수행합니다.

• 100% 자체 개발
• 대부분 자체 개발, 일부 외주 개발
• 대부분 외주 개발, 일부 자체 개발
• 100% 외주 개발

어떻게 보면 AI 코더를 외주 소프트웨어 공급업체/컨설턴트라고 생각할 수 있습니다. 외주 개발을 많이 하는 회사가 있고, 그렇지 않은 회사도 있습니다. 비중에 관계없이 항상 자체 개발 팀이 업무를 감독하는 것이 중요하다고 생각합니다. 이는 외주 업체의 결과물이 조직의 장기적인 목표에 부합하는지 확인하기 위한 것입니다. 물론 계약을 통해 이 문제를 해결할 수 있지만 일반적으로 특정 외주 업체나 프로젝트에만 적용되며, 이 방법으로는 장기적인 목표를 강제할 수 없습니다. 외주 업체를 감독 할 수 있는 소규모의 사내 개발 팀이 있는 것이 늘 더 좋습니다. 마찬가지로, EC2 인스턴스처럼 AI 코더를 임대할 수 있는 경우에도 소프트웨어 개발자로 구성된 사내 개발 팀이 작업을 감독하는 것이 유리합니다.

프레임워크: 소프트웨어 개발은 모델링 복잡성

비즈니스 문제 해결에 대해 이야기하고 있다면, 골치 아픈 문제인 엑셀에 대해 이야기하는 시간을 갖도록 하겠습니다. 전 세계 10억 명 이상이 엑셀을 사용한다는 사실은 잘 알려진 비밀입니다. 데이터를 정리하고, 데이터 분석을 수행하거나, 일부 프로세스를 자동화하려는 비즈니스 사용자에게 매우 낮은 진입 장벽을 제공합니다. 하지만 엑셀에는 세분화된 액세스 제어, 지원되지 않는 시스템과의 통합 기능, 테스트 가능성, 재사용성, 공급업체 종속성 등의 기능이 없기 때문에 복잡한 비즈니스 워크플로에는 사용할 수 없습니다. Power Automate 등과 같은 "로우 코드" 솔루션도 마찬가지입니다.

다시 원래 질문으로 돌아가서, 비즈니스 사용자가 소프트웨어 개발자의 도움 없이 AI 코더를 사용하여 이러한 복잡한 워크플로우를 만들 수 있을까요?

비즈니스 사용자가 소프트웨어 개발자의 도움 없이 AI 코딩 도구를 사용하여 이러한 복잡한 워크플로우를 만들 수 있을까요?

생각해 보면 엑셀과 로우 코드 도구는 수십 년 동안 존재해 왔는데, 소프트웨어 개발이라는 직업은 왜 여전히 존재할까요? 소프트웨어 개발을 단순히 코드를 작성하는 것으로 생각하면 됩니다. 복잡한 문제의 경우, 이러한 복잡성을 효과적으로 관리하고 비즈니스 문제를 실제 영역에서 디지털 모델로 전환할 수 있는 사람이 필요합니다.

다시 말해, 토목 기술자의 도움 없이 유튜브 튜토리얼을 통해 나무 창고를 지을 수 있다고 해서 10층짜리 건물도 똑같이 할 수 있거나 해야 한다는 의미는 아닙니다. 이 일을 제대로 배우기 시작하면 천천히 토목 엔지니어가 될 수 있습니다! 제대로 배우기 위해 시간을 투자할 의향이 있는지, 아니면 숙련된 엔지니어를 고용할 의향이 있는지에 대한 문제일 뿐입니다.

따라서 엑셀을 사용하든 최신 AI 코더를 사용하든, 복잡한 로직을 모델링하고 있다면 여전히 소프트웨어 개발자라고 생각합니다! 스프레드시트 수식, 코드, 프롬프트 등 다양한 도구를 사용하여 비즈니스 요구 사항을 표현하고 있을 뿐입니다.

프레임워크: 파이의 크기

이 주제를 둘러싼 대부분의 불안은 소프트웨어 개발 시장의 규모가 그대로 유지된다고 가정하고, AI 코더가 서서히 인간으로부터 "시장 점유율"을 빼앗아 갈 것이라고 가정합니다.

앞선 섹션에서 "비즈니스 문제 해결"의 시장 규모가 소프트웨어 개발보다 훨씬 크다는 것을 알 수 있습니다. 따라서 소프트웨어 개발이 조만간 사라질 것이라고 믿을 이유가 없습니다.

프레임워크: 공식적인 비즈니스 논리 정의

비즈니스 로직은 항상 명확한 형식으로 정의되어야 합니다. 그렇기 때문에 프로그래밍 언어는 "if", "switch" 등과 같은 영어 단어를 사용하더라도 이러한 단어의 의미를 매우 엄격하게 정의하며, 잘못된 단어를 사용하면 작동하지 않습니다. 생각해 보면 엑셀 수식이나 로우 코드 흐름도 마찬가지입니다.

미래에는 AI 코더가 대화형 영어로 주어진 명령어에서 소프트웨어 제품을 생성할 수 있더라도 백엔드에서 생성되는 비즈니스 로직의 기본 공식 정의는 여전히 존재할 것이라고 생각합니다. 오늘날 우리가 사용하는 언어나 프레임워크와는 매우 다르게 보일 수 있지만, 비즈니스 로직의 공식적인 정의는 "코드"와 매우 유사합니다.

AI 코더가 이러한 비즈니스 로직을 결정론적인 방식으로 영어 대화에서 생성할 수 있을 때까지는 백엔드에서 생성된 코드를 이해하고 필요한 경우 변경할 수 있는 사람이 여전히 필요합니다. 바로 소프트웨어 개발자입니다.

결론

요약하자면, 업무의 성격이 바뀌고 우리가 사용하는 도구가 지금과는 매우 달라지겠지만, 가까운 미래에도 소프트웨어 개발자를 위한 시장은 여전히 존재할 것이라고 생각합니다.