2021.07.21

칼럼 | '미래는 좀처럼 오지 않는다'··· 깃허브 코파일럿을 둘러싼 호들갑

Matt Asay | InfoWorld
미래는 언제나 너무 오래 걸린다는 것이 문제이다. 

이런 예를 들어보자. 2006년 당시 자바의 설립자이자 책임 디자이너였던 제임스 고슬링은 “휴대폰이 미래의 데스크톱이 될 것이다”라고 선언했다. 고슬링이 틀린 것은 아니지만, 아직 완전히 맞다고 할 수는 없다. 휴대폰은 어디에나 있는 디바이스가 되었지만, 데스크톱은 지난 분기에만 7,160만 대가 출시됐기 때문이다.

필자는 데스크톱이 없어졌으면 좋겠다. 지난주에도 이웃의 바이러스 걸린 윈도우 노트북을 고쳐주느라 예기치 않게 휴가를 내야만 했다. 고슬링의 선언이 현실이 되기를 바라마지 않지만, 그런 날은 좀처럼 오지 않고 있다.
 
ⓒ Getty Images Bank

필자도 대담한 예측을 즐기는 편이다. 오픈소스가 독점 소프트웨어를 묻어버릴 것이라거나 클라우드가 온프레미스 데이터센터를 말살할 것이라는 등등. 하지만 요즘은 이런 과도한 열정을 조금은 식히려고 한다. 이유는 앞서 말했듯이 미래는 너무 오래 걸리기 때문이다. 최근에는 클라우드도 시간이 좀 걸릴 것이라고 쓰기도 했다.

모두가 필자의 이런 주장에 동의하는 것은 아니다. 포레스터 애널리스트 3명은 “튜링봇(TuringBots)이 현실화되면서 기업용 애플리케이션을 구축하는 방법에 대한 역할과 툴과 기술이 완전히 바뀔 것이다”라고 선언했다.

이들이 말하는 튜링봇은 “기업용 애플리케이션 구축을 돕는 소프트웨어 봇”을 의미하는데, 말하자면 깃허브의 코파일럿(CoPilot) 같은 것이다. 맞다. 실제로 이런 툴은 개발자가 기업용 앱을 구축하는 방식을 완전히 바꿔놓을 수 있다. 하지만 그런 일이 금방 일어날 것이라고 기대하지는 말자.
 

AI 주도형 개발 시대의 도래

IT 업계는 수십 년째 노코드 또는 로우코드 개발이란 약속을 지키려 노력했다. 포레스터 애널리스트들이 지적했듯이, 우리는 소프트웨어 개발을 단순화하기 위해 모델 중심 아키텍처와 다른 접근법에 많은 시간을 들였다. 이런 접근법이 도움이 되기는 했지만, 소프트웨어 개발은 여전히 고약하고 잔인하다. 

깃허브 코파일럿이 출시되기 전에 쓴 이 보고서에서 포레스터의 애널리스트들은 소프트웨어 개발을 바꿔 놓을 AI의 가능성을 칭찬하느라 여념이 없다. 

“우리가 애플리케이션을 개발하는 방식에 엄청난 혁신이 다가오고 있다. AI 봇이 전체 애플리케이션 개발 라이프사이클에서 비즈니스 분석가와 아키텍트, 개발자, 테스터, 운영 담당자의 좋은 동료가 되면, 전반적인 분석, 설계, 개발, 테스트, 배치 정보 및 역량을 강화할 수 있다. 한 마디로, 소프트웨어 개발과 테스트, 배치, AI 모델 자체의 구축과 배치를 한층 더 자동화하고 더 빠르게 개발하는 시대가 도래한 것이다.”

깃허브 코파일 출시 전이었지만, 뒷부분에는 다음과 같은 내용도 추가했다.

“튜링봇은 모든 애플리케이션의 설계와 품질 요구사항, 레퍼런스 애플리케이션, 인프라 기술 스택을 모두 읽고 학습할 것이다. 애플리케이션 개발 전문가와 튜링봇은 함께 애플리케이션을 구축하고 변경하고 리팩터링할 것이며, 현재 프로세스보다 더 빠르게 이를 대규모 환경으로 확장해 비용을 극적으로 절감할 수 있을 것이다. 이 모든 것이 버튼을 누르는 것처럼 쉽고 빠르게 이루어질 것이다.”

필자는 저자 중 두 명을 알지만, 두 사람 다 한없이 낙천적인 사람은 아니다. 그럼에도 이런 단계에 도달하기 위해서는 아직 가야할 길이 멀다.
 

AI 주도 개발에 시간이 걸리는 이유

깃허브 코파일럿은 멋지지만, 지금 프로덕션에 적용할 준비가 된 것일까? 그렇기도 하고 아니기도 하다. 범용 AI로는 코파일럿이 인간의 코딩 능력을 대체할 준비가 부족하다. 여러 애플리케이션에 맞춰서 코드를 재작성해야 하는 글루 코드나 작은 유틸리티와 관련된 소일거리는 처리할 수 있을 것 같다.

코파일럿을 언제 신뢰해야 하는지 아는 데는 인간의 개입이 상당히 필요하다. 예를 들어, 소프트웨어 컨설턴트 존 바실리는 “AI를 이용해 개발을 한다면, AI가 맞을 수도 있는 아이템 10개를 줄 것이다. 어떤 것은 안성맞춤이고 어떤 것은 엉망진창일 것이다. 다이아몬드 원석을 찾으려면 모래를 한참 걸러내야만 한다”고 지적했다. 인포월드 기고가 사이먼 비슨도 “코파일럿이 생산하는 코드가 옳다고 기대해서는 안된다. 개발자는 여전히 AI가 작성한 작은 코드를 쓸 것인지, 쓴다면 어떻게 쓸 것인지 결정을 내려야만 한다”고 지적했다. 

비교적 경험이 적은 개발자에게 코파일럿은 구세주처럼 보일 수도 있다. 하지만 궁극적으로 학습을 가로막는 존재가 될 것이며, 코파일럿이 제안하는 코드가 엉망인지 완벽한지도 알 수 없게 된다. 경험이 많건 적건 개발자라면, 대부분은 정확한 어떤 것에 의존하지 않는 것이 더 쉽다는 것을 알게 될지 모른다. 비즈니스 사용자가 마이크로소프트 오피스를 고집하는 이유도 마찬가지다. 오픈오피스가 문서 포맷과 “대부분 호환”된다는 것은 온전히 믿을 수 없는 툴이기 때문이다.

이렇게 문제점을 지적한다고 해서 AI 주도 소프트웨어 개발이나 노코드/로우코드 플랫폼이 현실성이 없다는 것은 아니다. 다만 시간이 걸릴 것이다. 여전히 메인프레임을 사용하고 있는 업계에서 미래에 기대를 거는 것은 좋은 일이지만, 기대보다 오래 걸릴 것이라고 생각하는 것 역시 지혜로운 일이 될 것이다. editor@itworld.co.kr



2021.07.21

칼럼 | '미래는 좀처럼 오지 않는다'··· 깃허브 코파일럿을 둘러싼 호들갑

Matt Asay | InfoWorld
미래는 언제나 너무 오래 걸린다는 것이 문제이다. 

이런 예를 들어보자. 2006년 당시 자바의 설립자이자 책임 디자이너였던 제임스 고슬링은 “휴대폰이 미래의 데스크톱이 될 것이다”라고 선언했다. 고슬링이 틀린 것은 아니지만, 아직 완전히 맞다고 할 수는 없다. 휴대폰은 어디에나 있는 디바이스가 되었지만, 데스크톱은 지난 분기에만 7,160만 대가 출시됐기 때문이다.

필자는 데스크톱이 없어졌으면 좋겠다. 지난주에도 이웃의 바이러스 걸린 윈도우 노트북을 고쳐주느라 예기치 않게 휴가를 내야만 했다. 고슬링의 선언이 현실이 되기를 바라마지 않지만, 그런 날은 좀처럼 오지 않고 있다.
 
ⓒ Getty Images Bank

필자도 대담한 예측을 즐기는 편이다. 오픈소스가 독점 소프트웨어를 묻어버릴 것이라거나 클라우드가 온프레미스 데이터센터를 말살할 것이라는 등등. 하지만 요즘은 이런 과도한 열정을 조금은 식히려고 한다. 이유는 앞서 말했듯이 미래는 너무 오래 걸리기 때문이다. 최근에는 클라우드도 시간이 좀 걸릴 것이라고 쓰기도 했다.

모두가 필자의 이런 주장에 동의하는 것은 아니다. 포레스터 애널리스트 3명은 “튜링봇(TuringBots)이 현실화되면서 기업용 애플리케이션을 구축하는 방법에 대한 역할과 툴과 기술이 완전히 바뀔 것이다”라고 선언했다.

이들이 말하는 튜링봇은 “기업용 애플리케이션 구축을 돕는 소프트웨어 봇”을 의미하는데, 말하자면 깃허브의 코파일럿(CoPilot) 같은 것이다. 맞다. 실제로 이런 툴은 개발자가 기업용 앱을 구축하는 방식을 완전히 바꿔놓을 수 있다. 하지만 그런 일이 금방 일어날 것이라고 기대하지는 말자.
 

AI 주도형 개발 시대의 도래

IT 업계는 수십 년째 노코드 또는 로우코드 개발이란 약속을 지키려 노력했다. 포레스터 애널리스트들이 지적했듯이, 우리는 소프트웨어 개발을 단순화하기 위해 모델 중심 아키텍처와 다른 접근법에 많은 시간을 들였다. 이런 접근법이 도움이 되기는 했지만, 소프트웨어 개발은 여전히 고약하고 잔인하다. 

깃허브 코파일럿이 출시되기 전에 쓴 이 보고서에서 포레스터의 애널리스트들은 소프트웨어 개발을 바꿔 놓을 AI의 가능성을 칭찬하느라 여념이 없다. 

“우리가 애플리케이션을 개발하는 방식에 엄청난 혁신이 다가오고 있다. AI 봇이 전체 애플리케이션 개발 라이프사이클에서 비즈니스 분석가와 아키텍트, 개발자, 테스터, 운영 담당자의 좋은 동료가 되면, 전반적인 분석, 설계, 개발, 테스트, 배치 정보 및 역량을 강화할 수 있다. 한 마디로, 소프트웨어 개발과 테스트, 배치, AI 모델 자체의 구축과 배치를 한층 더 자동화하고 더 빠르게 개발하는 시대가 도래한 것이다.”

깃허브 코파일 출시 전이었지만, 뒷부분에는 다음과 같은 내용도 추가했다.

“튜링봇은 모든 애플리케이션의 설계와 품질 요구사항, 레퍼런스 애플리케이션, 인프라 기술 스택을 모두 읽고 학습할 것이다. 애플리케이션 개발 전문가와 튜링봇은 함께 애플리케이션을 구축하고 변경하고 리팩터링할 것이며, 현재 프로세스보다 더 빠르게 이를 대규모 환경으로 확장해 비용을 극적으로 절감할 수 있을 것이다. 이 모든 것이 버튼을 누르는 것처럼 쉽고 빠르게 이루어질 것이다.”

필자는 저자 중 두 명을 알지만, 두 사람 다 한없이 낙천적인 사람은 아니다. 그럼에도 이런 단계에 도달하기 위해서는 아직 가야할 길이 멀다.
 

AI 주도 개발에 시간이 걸리는 이유

깃허브 코파일럿은 멋지지만, 지금 프로덕션에 적용할 준비가 된 것일까? 그렇기도 하고 아니기도 하다. 범용 AI로는 코파일럿이 인간의 코딩 능력을 대체할 준비가 부족하다. 여러 애플리케이션에 맞춰서 코드를 재작성해야 하는 글루 코드나 작은 유틸리티와 관련된 소일거리는 처리할 수 있을 것 같다.

코파일럿을 언제 신뢰해야 하는지 아는 데는 인간의 개입이 상당히 필요하다. 예를 들어, 소프트웨어 컨설턴트 존 바실리는 “AI를 이용해 개발을 한다면, AI가 맞을 수도 있는 아이템 10개를 줄 것이다. 어떤 것은 안성맞춤이고 어떤 것은 엉망진창일 것이다. 다이아몬드 원석을 찾으려면 모래를 한참 걸러내야만 한다”고 지적했다. 인포월드 기고가 사이먼 비슨도 “코파일럿이 생산하는 코드가 옳다고 기대해서는 안된다. 개발자는 여전히 AI가 작성한 작은 코드를 쓸 것인지, 쓴다면 어떻게 쓸 것인지 결정을 내려야만 한다”고 지적했다. 

비교적 경험이 적은 개발자에게 코파일럿은 구세주처럼 보일 수도 있다. 하지만 궁극적으로 학습을 가로막는 존재가 될 것이며, 코파일럿이 제안하는 코드가 엉망인지 완벽한지도 알 수 없게 된다. 경험이 많건 적건 개발자라면, 대부분은 정확한 어떤 것에 의존하지 않는 것이 더 쉽다는 것을 알게 될지 모른다. 비즈니스 사용자가 마이크로소프트 오피스를 고집하는 이유도 마찬가지다. 오픈오피스가 문서 포맷과 “대부분 호환”된다는 것은 온전히 믿을 수 없는 툴이기 때문이다.

이렇게 문제점을 지적한다고 해서 AI 주도 소프트웨어 개발이나 노코드/로우코드 플랫폼이 현실성이 없다는 것은 아니다. 다만 시간이 걸릴 것이다. 여전히 메인프레임을 사용하고 있는 업계에서 미래에 기대를 거는 것은 좋은 일이지만, 기대보다 오래 걸릴 것이라고 생각하는 것 역시 지혜로운 일이 될 것이다. editor@itworld.co.kr

X