[기고] 코딩하는 AI는 개발자를 대체할 수 있을까?

[글=노규남 | 위블 CEO]
bardroh@weable.ai

알파고로 유명한 구글의 자회사 딥마인드가 또 다시 새로운 모델을 내놓았다. 알파고, 알파제로, 알파폴드에 이은 새로운 알파 시리즈인데, 이번의 모델은 ‘알파코드(AlphaCode)’라는 이름으로 깃허브(github)의 수많은 소스를 학습하여 실제 코딩 문제를 해결할 수 있는 수준이라고 한다. 이미 딥마인드의 블로그에 간단한 소개와 paper, 그리고 테스트 결과를 공개하고 있다. 딥마인드에 의하면 여러 온라인 개발 대회에서 개발자 상위 54.3% 즉 중간 수준의 개발력을 보여주었다고 한다.

최근 깃허브의 코파일럿 등 개발의 일부 작업을 대체해 주는 AI에 대해 관심이 높아진 가운데 실제 코딩할 수 있는 AI가 가능하다면 여러 분야에서 효율성을 높일 수 있는 부분이 생길 것이라는 예측이 있다. 반면 대표적인 고부가가치 산업이며 고도의 정신노동을 요하는 개발 업무까지 AI가 대신할 수 있다면 이는 인간이 할 수 있는 일은 모두 AI가 할 수 있다는 뜻이므로, 말 그대로 진정한 의미에서 직업의 종말을 의미할 것이라는 의견도 있다.

코파일럿(copilot)

코파일럿은 MS가 인수한 깃허브에서 제공하는 서비스로, 사용하려면 깃허브 계정이 필요하다. 현재는 tech preview 상태라서 beta wishlist에 이름을 올려놓고 대기해야 하며, 승인을 받은 후에야 사용할 수 있다. 코파일럿에서 사용하는 것은 OpenAI의 Codex Model인데 이런 초대형 NLP 모델은 상당한 컴퓨팅 파워를 소모하므로 공개적인 베타 서비스하기는 어려워서 제한된 규모의 그룹에게만 서비스하는 것으로 추정된다.

웹상에서 사용할 수 있는 것은 아니고, Visual Studio Code에서 깃허브에 로그인한 후 코드를 입력하거나 주석을 달 때마다 그 상황에 맞는 코드를 제안하는 방식으로 서비스를 제공받을 수 있다. 코파일럿이 작동하는 기본 원리는 기존의 NLP 모델과 크게 다르지 않다. 깃허브의 수많은 공개된 코드들을 가져다가 학습하여 현재 context에서 다음에 나올 가장 잘 맞는 코드를 제안하는 것이다.

이 공개코드들을 어떤 식으로 가공하여 학습 데이터세트를 만들고 학습시켰는지에 대해서는 명확하게 알려져 있지 않지만 통상의 NLP 문제와 마찬가지로, 적절한 입력(현재 코드 context)과 답안(제안할 코드)을 구성할 수 있다면 그에 최대한 비슷하게 코드를 작성할 수 있을 것으로 예상할 수 있다.

다만 FAQ에서 확인할 수 있듯이 코파일럿이 제안한 코드가 오류 없이 빌드된다는 것을 보장하지 않으며 사용자가 원하는 코드라는 것도 보장하지 않는다. 또한 많이 사용되는 기능은 공개 코드들도 풍부하므로 어느 정도 의미 있는 코드를 얻을 수 있지만, 많이 사용되지 않는 기능들은 학습 데이터가 적어서 전자보다 원하는 결과를 얻기 어렵다. 이런 점을 보았을 때 코파일럿은 코딩하는 AI라기보다는 code completion이나 visual assist의 연장선상에서 기존의 코드 제안 기능을 좀 더 지능화한 도구라 할 수 있다.

그리고 코파일럿의 결과는 수많은 공개 코드들에서 구현된 개발자들의 합의에 가까운 내용이다. 즉 ‘공개 코드를 개발하는 사람들은 이런 주제에 대해 대략 이런 식으로 코딩한다’에 가깝다. 새로운 기술이나 개념이 등장하면 처음에는 다양한 유형의 접근법이 시도되지만 시간이 지나면서 어느 정도 정형화된 코드가 만들어지기 때문에 코파일럿은 사람들이 많이 코딩하는 주제에 대한 모범 답안에 가까운 코드를 제안할 수 있을 것이다.

현재도 깃허브나 스택 오버플로(Stack Overflow), 쿼라(Quora) 등을 검색하면서 필요한 코드를 찾는 일은 매우 흔하다. 코파일럿은 이런 검색을 통해 얻어진 결과를 코드화하는 부분까지를 AI로 자동화하여 개발자의 일을 덜어주는 역할을 한다고 볼 수 있다. 하지만 이 코드가 유효하며 원하는 목적에 맞는지에 대한 여부는 최종적으로 사람이 확인해야 한다. 

알파코드(AlphaCode)

알파코드는 코파일럿에서 한 걸음 더 나아가서, 문제를 자연어로 정의하면 그에 해당하는 답 코드 전체를 생성해 주는 솔루션이다. 필자도 관심이 생겨서 그 내용을 좀 들여다보았는데, paper 자체는 70p 정도로 상당한 분량이지만 후반부 절반은 레퍼런스와 상세한 결과물을 포함한 부록이므로 실제 중요한 부분은 전반부의 절반이다.

알파코드가 대상으로 하는 것은 Competitive Programming이라는 분야의 대회 문제들로, 정의된 문제를 주고, 주어진 Input에 대해 정해진 Output이 나오도록 코딩하는 것이다. 즉 문제의 Input을 주었을 때 지정된 Output이 나온다면 pass 되었다고 보고 그렇지 않으면 fail 되었다고 본다.

이런 종류 대회들의 역사는 매우 오래되었으며 CodeForces나 TopCoder, Google Jam, Kaggle 같은 플랫폼들이 대중적으로 알려져 있다. 최근에는 개발자를 채용하기 위해 Competitive Programming 대회를 여는 일도 드물지 않은데, 이를 통해 주로 응시자의 알고리즘 구현 능력을 보게 된다.

이런 대회는 일반적으로 문제를 정의하고 Input과 그에 따르는 Output을 준 후, 코드의 평가에 사람이 개입하지 않고 온라인에서 정해진 규칙에 의해 자동으로 점수가 매겨진다. 따라서 알파코드가 이런 문제를 스스로 풀어서 답안을 제출할 수 있다면 온라인 시스템은 사람이거나 기계이거나 관계없이 코드의 결과만을 평가할 것이고, 이 대회에 참가하는 사람들 중 어느 정도 수준인지를 판단하는 일이 가능할 것이다.

기본적으로는 코파일럿과 동일하게 깃허브의 공개 코드들을 가져다가 학습한다. 처음부터 타깃이 되는 코드를 학습하는 건 아니고 c++, python 등 코드를 Massive Language Model 학습시키는 방식으로 pre-train한다. 이후 fine-tuning을 거쳐 실제 모델을 만들어내는데, 학습시키는 데이터에서 input은 자연어로 정의된 문제, output은 그에 해당하는 각종 언어별 코드다.

즉 알파코드는 이 문제를 자연어 처리의 sequence-to-sequence로 보고 푸는 것이다. 본질적으로는 기계번역과 크게 다르지 않으며, 자연어 token의 sequence를 코드의 sequence로 번역하는 작업과 유사하다.

실제 문제를 풀 때는 하나의 답을 바로 도출하는 것은 아니고, 조건을 바꾸어 가면서 수천~수백만에 이르는 크기의 잠재 답안(샘플)을 얻은 후 이중에서 문제의 테스트를 pass할 수 있는 것만을 필터링한다. 이 단계에서 99%의 샘플이 걸러지지만 이렇게 해도 수천 개의 샘플이 남는다. 이 중에 다시 최대 10개까지의 샘플을 골라낸 후 실행하고 평가하여 최종 답안을 제출하게 된다.

모델 자체도 대단히 크지만 학습시킬 데이터의 양도 방대하고, 모델이 바로 답을 내는 것이 아니며 큰 잠재 답안 군을 생성한 후 필터링하는 식이라 실제 사용 시 아주 많은 자원을 소모하는 일이 불가피할 것이다. 하지만 그렇다고 하더라도 자연어로 정의된 알고리즘 문제를 상위 53.4%, 즉 해당 대회에 참가하는 평균적인 개발자 수준으로 풀어낼 수 있다는 건 놀라운 일이 아닐 수 없다. 

알파코드의 한계

알파코드가 대단한 성과를 낸 것은 사실이나, 아직까지 그 한계도 분명하다. 대표적으로 알파코드는 긴 코드 작성에 어려움이 있을 것으로 추정하는데, 최종 코드가 길어지면 그만큼 예측해야 하는 token의 수가 늘어나고, 정확도를 맞추기 위해서는 필요한 샘플군의 크기가 증가할 수밖에 없기 때문이다.

뉴욕대학교의 어니스트 데이비스(Ernest Davis) 교수에 따르면 알파코드는 20줄짜리 코드를 얻기 위해 백만 개의 샘플 솔루션을 만들어야 하며 코드의 길이를 200줄로 늘리면 10의 60승 개까지의 샘플이 필요할 수 있다. 일반적인 개발자가 그 정도의 코드를 작성하는데 필요한 시간을 생각하면 실무에 적용하기에는 너무 비효율적인 것이다.

또 알파코드가 문제를 풀 수 있는 영역은 순수한 알고리즘으로 결과를 도출하는 분야에 국한된다. 개발 실무에서는 순수한 알고리즘만으로는 서비스를 만들 수 없고 여러 가지 다양한 라이브러리와 솔루션들을 사용하는데, AI는 어떤 솔루션을 사용할지 스스로 결정할 수 없기 때문에 사람이 이들을 모두 판단해 주어야 한다.

간단한 문제 같지만 DB를 MySQL로 할지 PostgreSQL로 할지 결정하는 것만 해도 우리는 매우 여러 가지 조건을 검토한다. 각 솔루션에 대한 개발팀의 숙련도, 사용할 라이브러리의 지원 여부, 성능, 운영과 유지 보수에 들어가는 비용 등 한 가지 DB를 선택하는 문제만 해도 이렇게 고려할 내용이 많다. 더 복잡한 시스템이라면 판단할 내용은 더욱 늘어난다.

프라이빗 블록체인 프로젝트라면 합의 알고리즘으로 PBFT를 쓸 것인지 Raft를 쓸 것인지, 인증 프로세스를 별도로 구동할 것인지 아니면 인증서만으로 운영할 것인지 등 시작 전에 여러 가지 내용을 결정해야 한다. 영상 인식을 한다면 모델의 프레임워크로 pytorch를 쓸 것인지 tensorflow나 keras를 쓸 것인지, CNN을 쓸 것인지, 아니면 Vision-Transformer를 쓸 것인지 모든 것들이 의사 결정의 대상이다.

그렇기 때문에 프로그래밍과 IT 시스템 설계는 고도의 정신노동이고 그 사람이 지금까지 학습하고 경험한 모든 내용들을 다 총합하여 판단하게 된다. 지금까지는 AI가 이런 종류의 의사 결정을 하는 건 불가능해 보이므로 이 부분은 여전히 사람의 몫으로 남아 있다.

이외에도 AI가 개발을 하기 위해서는 문제를 명확하게 정의하는 것이 필요한데, 실제 필드에서의 개발 업무는 대단히 많은 모호함과 아직 결정되지 않은 요소들로 가득 차 있다. 어떤 부분은 실무자가 설명하지도 않고 문서도 존재하지 않는 묵시적 도메인 지식을 사용하여 채워야 한다. 개발 업무는 단순히 알고리즘의 구현만으로 끝나지 않는 것이다.

코딩하는 AI는 개발자의 적이 아니다

결론적으로 코딩하는 AI는 가능하겠으나, 오류가 없이 완벽하지도 않고, 다양한 필드에서의 상황을 이해하지도 못하며, 순수 알고리즘 문제만 풀 수 있다. 더불어 아직까지는 지나치게 비효율적이다. 그렇기 때문에 AI가 개발자의 일을 뺏을 것이라는 우려는 억측이다.

다만 AI가 NLP를 통해 주어진 알고리즘 문제에 대응하는 답을 낼 수 있다면 이는 개발자들의 일을 줄여 주는 보조 도구로서 가치가 있을 수 있다. 전체 산업군에서 디지털 트랜스포메이션이 이루어지고 있는 지금 숙련된 개발자의 수는 턱없이 부족하고, 로우코드나 노코드 플랫폼이 진지하게 거론되고 있는 상황에서 개발자의 효율을 높여줄 수 있는 도구가 나온다는 건 환영할 만한 일이다.

이를 통해 단순 코더의 일은 지금보다 확실히 줄어들 수 있으며 개발자의 일은 점점 더 높은 수준의 의사 결정이 필요한 시스템 설계나, 추상화, 아키텍처링으로 전환될 가능성이 있다. 말하자면 증가하는 IT 시스템의 규모와 복잡도에 대응하여 개발방법론이나 시스템도 발전할 필요가 있으며 이러한 자동화는 옳은 방향이다.

코파일럿이나 알파코드 같은 시스템이 좀더 발전하면 다른 조건을 고려할 필요가 없는 알고리즘 문제는 기계에게 맡기는 것이 일반화될지도 모르겠다. 하지만 그런 경우에도 실제 서비스를 받는 것은 사람이며 운영하는 것도 사람이므로 여전히 개발자의 의사 결정은 중요하다.

점점 개발자의 역할이 고도화될 수는 있으나 강인공지능 또는 일반 인공지능이 나오기 전까지 AI가 개발자를 대체하는 일은 없을 것이다. 따라서 보조자로서 또는 동반자로서의 AI를 어떻게 잘 활용할 수 있을지를 고민하는 것이 지금 시점에서 개발자가 취할 수 있는 의미 있는 태도일 것이다.