소프트웨어 개발의 미래를 생각하다

Less than 1 minute

소프트웨어 개발의 미래를 생각하다 관련

소프트웨어 개발의 미래를 생각하다 | 요즘IT

대규모 언어 모델(LLMs)은 이미지, 텍스트 및 코드를 생성할 수 있는 능력으로 창의적인 분야에서 큰 반향을 일으켰습니다. 처음에는 결과물이 꽤 우스꽝스러웠습니다. 그림이 뒤틀려 있거나, 틀린 내용으로 코드를 생성할 때도 있어 어색했습니다. 그러나 상황은 점차 안정되어 나아지고 있습니다. 이러한 모델이 등장하기 전에는 그런 작업을 자동화하는 것에 대한 주요 반대 이유로, 기계는 창의적으로 생각할 수 없다는 점을 내세웠습니다. 그러나 이제 그 주장은 날이 갈수록 약해지고 있습니다. 이제 우리는 어디로 가야 할까요?

본문은 세쉬바부 치나콘다(Sheshbabu Chinnakonda)의 글 <Thoughts on the Future of Software Development>을 번역한 글입니다. 필자 세쉬바부 치나콘다는 싱가포르의 투자 회사 테마섹(Temasek)의 엔지니어로 일하고 있습니다. 15년이 넘는 소프트웨어 개발 경력을 바탕으로 작성된 이 글은 필자에게 허락을 받고 번역과 게재를 진행했습니다.

대규모 언어 모델(LLMs, Large Language Models)은 이미지, 텍스트 및 코드를 생성할 수 있는 능력으로 창의적인 분야에서 큰 반향을 일으켰습니다. 처음에는 결과물이 꽤 우스꽝스러웠습니다. 그림이 뒤틀려 있거나, 틀린 내용으로 코드를 생성할 때도 있어 어색했습니다. 그러나 상황은 점차 안정되어 나아지고 있습니다. 이러한 모델이 등장하기 전에는 그런 작업을 자동화하는 것에 대한 주요 반대 이유로, 기계는 창의적으로 생각할 수 없다는 점을 내세웠습니다. 그러나 이제 그 주장은 날이 갈수록 약해지고 있습니다. 이제 우리는 어디로 가야 할까요?

미래를 예측하는 것과 같은 모호한 주제를 다룰 때 문제는, 생각이 혼란스러워 명확히 만들기가 어렵다는 점입니다. 그래서 우리는 프레임워크와 비유를 고안하고 이를 이용해야 합니다.

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

소프트웨어 개발은 단순히 코드를 작성하는 것만이 전부는 아닙니다. 프로그래머에 대해 사람들이 느끼는 이미지는 어두운 방에서 컴퓨터를 보며 열심히 코드를 입력하는 사람입니다. 하루 종일 코딩만 하는 것이라면 매력적으로 들릴 수 있지만, 실제로 소프트웨어 개발 시간의 대부분은 코드를 작성하는 것이 아니라, 다른 사람과 의사소통하거나 아래와 같은 기타 관리 작업에 소요됩니다:

비즈니스 사용자로부터 요구 사항 수집하기
이러한 요구 사항을 코드로 모델링할 수 있도록 정제하기
디자이너 및 제품 관리자와 같은 다른 팀원과 솔루션을 시각화하고 작전 계획을 수립하는 대화
다른 개발자들과 기술적 설계를 수립하고 정제하기
인프라, 구성, 기본 구성 코드 설정하기
실제로 일부 코드를 작성하기
버그 수정, 다른 사람의 코드 이해 시도, 문서 등 작성하기
프로덕션 배포하기
프로덕션 문제점 대응하기
추가로 다른 많은 작업

따라서 “AI가 개발자를 대체할 것이다”와 같이 말하려면 AI가 코드 작성뿐만 아니라 위의 모든 작업에도 능숙해야 합니다.

이러한 작업 중 일부는 미래에 자동화될 수도 있지만 아직은 아닙니다. 이를 어떤 프레임으로 구성해야 할까요?

자율 주행 자동차 세계에서는 자동화 수준을 분류하는 방법을 제시했습니다. 이것은 수준을 세분하여 자동화가 전혀 없음부터, 부분 자동화, 완전 자동화까지 이어집니다. 이런 사고방식은 아래 이유로 매우 유용하죠.

현재 기술로 무엇을 할 수 있는지 명확하게 설명합니다.
우리가 흑백 논리로 생각하지 않게 합니다: 인간이 운전하는 일을 AI가 운전하는 일로 모두 대치하는 대신에 회색 영역에서 인간을 지원하여, AI가 비상 브레이크, 차선 중앙 정렬 등의 일부를 맡습니다.

이러한 분류를 AI 기반 소프트웨어 개발에 적용하면 어떻게 보일까요?

가장 낮은 단계는 이전에 우리가 하던 일과 같습니다

작업에 AI가 포함되지 않습니다. 물론 컴파일러, 빌드 프로세스 등 다른 유형의 자동화가 있었지만, 그러한 것들은 AI가 아니라 사람이 작성한 결정론적 자동화였습니다.

다음 단계는 현재 우리가 하고 있는 일입니다

개발자들이 ChatGPT나 깃허브 코파일럿(GitHub Copilot)을 사용하여 도움을 받습니다. 이를 테스트 작성, 기본 구성 코드 작성, 리팩토링, 코드/오류 이해 따위에 사용합니다. 이것은 채팅으로 다른 개발자와 대화하는 것과 비슷합니다. 질문하고 도움을 받을 수 있지만, 그들은 당신의 컴퓨터에 액세스할 수 없으므로 파일을 생성하거나 빌드 명령을 실행하거나 프로덕션에 배포할 수 없습니다.

가장 높은 수준은 프로젝트의 일부 또는 전체를 개발자에게 위임하는 것과 같습니다.

이러한 “AI 코더”들은 요구 사항을 수용하여 코드를 작성하고 오류를 수정하며 최종 제품을 프로덕션에 배포할 것입니다. 이런 일이 실현되려면 여러 달이 지나야만 가능할 것으로 예상했지만, 데빈(Devin)^[1] 데모를 보고 예상이 틀렸음이 드러났습니다: 지금은 간단한 개발 작업만 수행할 수 있지만 미래에는 개선될 것입니다.

AI 모델의 능력 외에, 솔루션의 정확도에 대해서도 생각해 봐야 합니다. 초기에는 이러한 모델이 환각(Hallucinations)에 빠져 잘못된 답을 낸다거나 특정 방식으로 프롬프트를 표시해야만 원하는 결과를 얻을 수 있었습니다. 이는 채택을 저해하는 요소이며, 대부분은 이 단계에서 AI의 도움을 포기합니다. 그러나 이것도 개선 중이며, 최신 모델은 그런 정도까지 프롬프트 엔지니어링이 필요하지 않습니다. 또한, 모델은 자신의 훈련 데이터에 의존하는 대신 웹을 탐색하여 “학습”할 수 있어야 합니다. 이는 특히 새로운 버전의 라이브러리와 프로그래밍 언어가 도입될 때 중요합니다.

프레임워크: 아웃소싱 소프트웨어 개발

이제 우리가 능력을 확보했으니, 이것이 팀 또는 조직 구조에 어떤 영향을 미치는지 살펴볼까요? 회사들은 여러 가지 방식으로 소프트웨어 개발을 합니다.

모두 사내 개발
대부분 사내 개발, 약간만 외주
대부분 외주, 약간만 사내 개발
모두 외주

어느 면에서 AI 코더는 외부 소프트웨어 벤더나 컨설턴트로 생각할 수 있습니다. 일부 회사는 그들을 많이 사용하고 일부 회사는 그렇지 않습니다. 구성에 상관없이, 내부 팀이 그들의 작업을 감독하는 것이 항상 중요합니다. 이는 벤더의 결과물이 회사의 장기적인 목표와 일치하는지 확인하기 위함입니다. 물론 계약으로 이를 해결할 수 있지만, 이는 일반적으로 특정 벤더나 프로젝트에만 적용되며 이 방법으로 장기적인 목표까지 강요할 수는 없습니다. 벤더를 이끌어 줄 수 있는 소수의 내부 팀을 보유하는 것이 항상 좋습니다. 마찬가지로, AI 개발자를 EC2 인스턴스 식으로 임대할 때도 그들의 작업을 감독할 내부 소프트웨어 개발팀을 유지하면 좋습니다.

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

비즈니스 문제를 해결한다고 말할 때, 얘기해야 할 가장 큰 주제중 하나인 엑셀(Excel)에 대해 이야기해 보겠습니다. 기업 세계가 엑셀을 기반으로 돌아간다는 것은 잘 알려진 비밀이며, 10억 명 이상의 사람들이 이 도구를 사용하고 있습니다. 엑셀은 데이터 정리, 데이터 분석 수행 또는 일부 프로세스를 자동화하는 비즈니스 사용자들에게 진입 장벽이 매우 낮습니다. 그러나 우리는 엑셀을 복잡한 비즈니스 워크플로우에 사용할 수 없습니다. 왜냐하면 그 도구는 세밀한 액세스 제어, 지원되지 않는 시스템과의 통합 능력, 테스트 용이성, 재사용성이 떨어지며, 무엇보다 벤더에 종속됩니다. 마찬가지로, 파워 오토메이트(Power Automate) 등 “로우 코드(Low Code)” 솔루션도 마찬가지입니다.

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

생각해 보면 엑셀과 로우 코드 도구가 수십 년 동안 존재했지만, 소프트웨어 개발이란 직업이 여전히 존재하는 이유는 무엇일까요? 그것은 소프트웨어 개발을 코드 작성으로만 생각할 수 없기 때문입니다. 복잡한 문제를 해결하려면 사람이 나서서 현실 세계 영역의 비즈니스 문제를 디지털 모델로 효과적으로 변환해야 합니다.

다시 말해, 유튜브(YouTube) 튜토리얼을 보고 목공 작업을 수행할 수 있다고 해서 시공 엔지니어의 도움 없이 10층 건물을 지을 수 있는 것은 아닙니다. 물론 일을 올바르게 배우면 천천히 시공 엔지니어가 될 수는 있습니다. 그 일을 올바르게 배우기 위해 시간을 투자할 것인지, 아니면 경험이 풍부한 엔지니어를 고용할 것인지의 문제일 뿐입니다.

그래서 이러한 사람들이 엑셀(Excel)을 사용하든 최신 AI 코더를 사용하든, 그들이 복잡한 논리를 모델링하고 있다면, 그들은 여전히 소프트웨어 개발자라고 저는 생각합니다. 그들은 비즈니스 요구 사항을 표현하려고 다른 도구 - 스프레드시트의 수식, 코드 또는 프롬프트 - 를 사용하고 있을 뿐입니다.

프레임워크: 파이의 크기

“파이의 크기" 주제에 대한 대부분의 불안은 소프트웨어 개발 시장 규모가 그대로 고정되어 있을 것이라는 가정에 기반합니다 - 고정된 시장 규모 안에서 AI 개발자가 인간으로부터 “시장 점유율”을 점차 빼앗아 갈 것이라는 가정이죠.

그러나 우리는 “비즈니스 문제 해결”의 시장 규모가 소프트웨어 개발보다 훨씬 더 크다는 것을 알고 있습니다. 그러므로 소프트웨어 개발이 곧 사라질 것이라고 믿을 이유가 없습니다.

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

비즈니스 논리는 항상 명확한 형식으로 정의되어야 합니다. 프로그래밍 언어에서 “if”, “switch”와 같은 영어 단어를 사용하더라도 이러한 단어가 무엇을 의미하는지 매우 정확히 다루고, 잘못된 단어를 사용하면 작동하지 않는 것과 같은 이유입니다. 생각해 보면, 엑셀 수식이나 로우 코드 플로우에도 동일한 원리가 적용됩니다.

미래에 대화형 영어로 작성한 지시 사항에 따라 소프트웨어 제품을 생성할 수 있는 AI 코더가 있더라도, 비즈니스 논리의 기반이 되는 공식적인 정의는 여전히 백엔드에서 생성할 것이라 생각합니다. 오늘날 우리가 사용하는 언어나 프레임워크와는 매우 다르게 비칠지 모르지만, 비즈니스 논리의 공식 정의는 오늘날의 “코드”와 매우 유사할 것입니다.

AI 코더가 대화형 영어에서 이러한 비즈니스 논리를 결정론적인 방식으로 생성하기까지는, 백엔드에서 생성된 코드를 이해하고 필요에 따라 변경할 수 있는 사람들이 필요할 것입니다. 이러한 사람들이 소프트웨어 개발자가 될 것입니다.

마치며

요약하면, 예측 가능한 미래에도 소프트웨어 개발자에 대한 시장은 여전히 존재할 것으로 믿습니다. 다만 작업의 성격은 변화하고 그들이 사용하는 도구는 현재와 매우 다를 것입니다.

데빈 AI: 미국 코그니션 랩(Cognition Labs)에서 만든 ‘AI 소프트웨어 개발자’로 쉘, 코드 에디터, 브라우저 등 개발자 도구를 사용해 엔지니어링을 수행하는 AI ↩︎