한 달 동안 Devin으로 20개 이상의 작업을 실행한 후 Devin 사용에 대한 소감

2024년 3월, 파운더스 펀드가 주도하고 콜리슨 형제, 엘라드 길 등 업계 리더와 기타 기술 분야의 저명인사들이 후원하는 2,100만 달러 규모의 시리즈 A 투자를 유치한 새로운 AI 회사가 주목받기 시작했습니다. 개발팀은 누구일까요? 국제 정보학 올림피아드 금메달리스트인 이들은 우리 대부분이 이해하기조차 어려운 프로그래밍 문제를 해결할 수 있는 사람들입니다. 이들의 제품인 Devin은 인간 동료처럼 대화할 수 있는 완전 자율 소프트웨어 엔지니어로, 신기술 학습과 성숙한 코드 베이스 디버깅부터 전체 애플리케이션 배포와 AI 모델 학습까지 모든 작업을 수행할 수 있습니다.

초기 데모는 매우 인상적이었습니다. Devin이 사람의 개입 없이 PyTorch 프로젝트를 설치 및 실행하여 Upwork의 바운티 작업을 독립적으로 완료한 방법을 보여줍니다. 이 회사는 Devin이 SWE 벤치마크에서 13.86%의 실제 GitHub 문제를 엔드투엔드 방식으로 해결할 수 있었으며, 이는 이전 시스템보다 약 3배 더 나은 성능이라고 주장합니다. 처음에는 소수의 사용자만 액세스할 수 있었기 때문에 소프트웨어 개발에 혁명을 일으킬 것이라는 흥미로운 트윗이 이어졌습니다.

역할 Answer.AI AI 개발 도구를 자주 사용해보는 팀의 일원인 저희는 Devin에 뭔가 다른 점이 있다고 느꼈습니다. 약속한 기능의 절반만 제공한다면 우리의 업무 방식을 바꿀 수 있을 것 같았습니다. 하지만 트위터의 열광적인 반응에 비해 실제로 이 도구를 사용하는 사람들의 자세한 사용 후기를 찾아볼 수 없었습니다. 그래서 저희는 다양한 실제 업무에 대해 철저히 테스트하기로 결정했습니다. 2024년 가장 기대되는 AI 제품 중 하나를 실제 업무에 사용해 본 철저한 테스트 스토리를 소개합니다.

데빈이란 무엇인가요?

Devin을 독특하게 만드는 것은 인프라입니다. 일반적인 AI 어시스턴트와 달리 Devin은 Slack을 통해 자체 컴퓨팅 환경을 실행하고 실행합니다. Devin과 대화할 때는 웹 브라우저, 코드 편집기, 셸을 갖춘 전체 컴퓨팅 환경에 액세스하여 종속성을 설치하고, 문서를 읽고, 심지어 자신이 만든 웹 애플리케이션을 미리 볼 수 있는 AI와 대화하는 것입니다. 다음은 Devin을 실행하여 작업을 수행하는 한 가지 방법의 스크린샷입니다:

Slack을 통해 Devin을 작업으로 시작하는 한 가지 방법

이 경험은 동료와 채팅하는 것처럼 느낄 수 있도록 설계되었습니다. 원하는 것을 설명하면 Devin이 작업을 시작합니다. Slack을 통해 문제를 해결하는 과정을 지켜보고, 필요할 때 자격 증명을 요청하고, 완료된 작업에 대한 링크를 공유할 수 있습니다. 백그라운드에서는 Docker 컨테이너에서 실행되므로 시스템을 보호하면서 안전하게 실험하는 데 필요한 격리 기능을 제공하며, Devin은 웹 인터페이스도 제공하므로 IDE, 웹 브라우저 등을 사용하여 환경에 액세스하고 실시간으로 작동하는 것을 볼 수 있습니다. 아래는 웹 인터페이스의 스크린샷입니다:

초기 성공

우리의 첫 번째 작업은 간단하지만 사실입니다. Notion 데이터베이스를 Google 스프레드시트로 추출했는데 Devin은 놀라운 능력으로 이 문제를 해결해 주었습니다. Notion API 문서로 이동하여 무엇이 필요한지 파악한 다음, Google Cloud Console에서 필요한 자격 증명을 설정하는 과정을 안내해 주었습니다. API 명령어를 나열하는 대신 각 메뉴와 버튼 클릭을 안내해 주었기 때문에 일반적으로 지루한 문서 검색이 필요한 시간을 절약할 수 있었습니다. 전체 과정은 약 한 시간 정도 걸렸지만 사람과의 상호작용은 몇 분밖에 걸리지 않았습니다. 마지막에 Devin은 데이터가 포함된 완벽한 형식의 Google 스프레드시트 링크를 공유해 주었습니다.

생성된 코드는 약간 길지만 작동합니다. 개발자의 많은 시간이 소요되는 '코드 붙이기' 작업을 처리할 수 있는 AI의 미래를 엿볼 수 있는 것 같은 느낌입니다. 조노는 목성과 토성의 역사적 위치에 대한 주장을 반박하기 위해 행성 추적기를 만드는 데 Devin과 비슷한 성공을 거둔 바 있습니다. 특히 인상적인 점은 그가 전적으로 휴대폰으로 이 작업을 수행했고 Devin은 환경 설정 및 코드 작성과 같은 무거운 작업을 모두 처리했다는 점입니다.

테스트 확장

초기 성공을 바탕으로 Devin의 비동기 기능을 활용했습니다. 우리는 회의 중에 Devin이 문서를 작성하거나 디자인 작업에 집중하는 동안 문제를 디버깅하는 것을 상상했습니다. 하지만 테스트 규모를 확장하면서 문제가 발생했습니다. 단순해 보이는 작업도 몇 시간이 아닌 며칠이 걸리는 경우가 많았고, Devin은 기술적 막다른 골목에 부딪히거나 사용하기에 너무 복잡한 솔루션을 만들곤 했습니다.

더욱 걱정스러운 것은 사실상 불가능한 작업을 밀어붙이는 Devin의 경향입니다. 하나의 Railway 배포에 여러 애플리케이션을 배포하라는 요청(Railway에서 지원하지 않는 기능)을 받았을 때 Devin은 이러한 한계를 인식하지 못한 채 다양한 접근 방식을 시도하고 존재하지 않는 기능을 만들어내는 데 하루 이상을 보냈습니다.

가장 실망스러운 것은 모든 도구에는 한계가 있기 때문에 실패 자체가 아니라 이러한 시도를 복구하는 데 많은 시간을 소비한다는 점입니다.

무엇이 잘못되었는지에 대한 인사이트 확보

여정에서 저희는 혼란스러웠습니다. Devin은 API를 능숙하게 통합하고 기능적인 애플리케이션을 구축할 수 있었지만, 겉보기에 단순해 보이는 작업에는 어려움을 겪는 것을 보았습니다. 운이 나빴던 걸까요? 우리가 잘못 사용하고 있었던 걸까요?

한 달에 걸쳐 다음과 같은 범주의 시도를 체계적으로 문서화했습니다:

1. 처음부터 새 프로젝트 만들기
2. 연구 의무 이행
3. 기존 프로젝트 분석 및 수정

결과는 실망스러웠습니다. 20개의 작업 중 14개는 실패, 3개는 성공(초기 2개 포함), 3개는 결정적이지 않은 결과가 나왔습니다. 더 큰 문제는 어떤 작업이 성공할지 예측할 수 있는 패턴을 발견할 수 없었다는 점입니다. 초기의 성공과 유사한 작업이 예상치 못한 방식으로 실패하기도 했습니다.아래 부록에서 이러한 작업에 대한 자세한 정보를 확인할 수 있습니다. 아래는 이 과정에서 각 카테고리별로 겪은 경험을 요약한 것입니다:

1. 처음부터 새 프로젝트 만들기

이 카테고리는 Devin의 강점이 될 것입니다. 데모 동영상을 보면 업워크에서 바운티 작업을 자율적으로 완료하는 방법을 알 수 있고, 초기 성공 사례를 보면 새로운 개발도 처리할 수 있음을 알 수 있습니다. 하지만 현실은 더 복잡했습니다.

예를 들어, Braintrust라는 대규모 언어 모델(LLM) 통합 가시성 플랫폼과 통합하려는 시도를 생각해 보겠습니다. 합성 데이터를 생성하여 업로드하는 간단한 작업이었지만, Devin은 집중적이고 명확한 솔루션을 제공하는 대신 단순한 작업을 불필요하게 복잡하게 만드는 여러 계층의 추상화라는 코드 수프를 생성했습니다. 결국 우리는 Devin의 시도를 포기하고 커서 단계별로 통합을 구축하는 것이 더 효율적이라는 것이 입증되었습니다. 마찬가지로, AI 메모 작성기와 Spiral.computer 간의 통합을 요청받았을 때 Devin은 한 팀원이 "처음부터 작성한 코드보다 더 읽기 어려운 스파게티 코드"라고 표현한 것을 만들었습니다. 두 시스템에 대한 문서에 액세스할 수 있었음에도 불구하고 Devin은 통합의 모든 측면을 지나치게 복잡하게 생각한 것 같았습니다.

아마도 웹 크롤링을 시도한 것이 가장 잘 드러나는 사례일 것입니다. Devin에게 Google Scholar 링크를 추적하고 저자의 가장 최근 논문 25개를 크롤링해 달라고 요청했는데, 이는 Playwright와 같은 도구로서는 간단한 작업이었습니다. 웹을 탐색하고 코드를 작성하는 Devin의 능력을 고려할 때 이 작업은 특히 쉽게 수행할 수 있을 것으로 예상했습니다. 하지만 HTML 구문 분석을 시도하는 끝없는 반복에 갇혀서 끝내 빠져나오지 못했습니다.

2. 연구 임무

Devin이 특정 코딩 작업에 어려움을 겪는다면 연구 중심의 작업에서 더 잘할 수 있을까요? 결과는 기껏해야 엇갈립니다. 기본적인 문서 조회는 처리할 수 있지만(초기 Notion/Google 스프레드시트 통합에서 보았듯이), 더 복잡한 연구 작업은 어려운 것으로 나타났습니다.

Devin에게 정확한 타임스탬프가 포함된 트랜스크립션 요약(우리가 직면한 특정 기술적 문제)을 요청했을 때, 핵심 문제를 다루기보다는 피상적으로 관련된 기술 정보만 반복할 뿐이었습니다. 잠재적인 해결책을 탐색하거나 주요 기술적 과제를 파악하는 대신 근본적인 문제를 해결하지 못하는 일반적인 코드 예제를 제공했습니다. Devin이 진전을 이룬 것 같더라도 결과는 대개 보기와는 달랐습니다. 예를 들어, 최소한의 데이지UI 테마를 만들라는 요청을 받았을 때는 작동하는 것처럼 보이는 솔루션을 생성했습니다. 하지만 자세히 살펴보니 테마가 실제로 아무 기능도 수행하지 않았고, 사용자 지정한 색상이 아니라 기본 테마에서 가져온 색상이었습니다.

3. 기존 코드 분석 및 수정하기

Devin이 가장 걱정하는 실패는 아마도 기존 코드베이스로 작업할 때 발생할 것입니다. 이러한 작업에는 컨텍스트를 이해하고 기존 패턴과의 일관성을 유지해야 하며, 이는 AI 소프트웨어 엔지니어의 핵심 역량에 속하는 기술입니다.

Devin에게 nbdev 프로젝트를 처리하게 하려는 시도는 특히 빛을 발했습니다. Python 프로젝트를 nbdev로 마이그레이션해 달라는 요청을 받았을 때, 종합적인 설명서를 제공했음에도 불구하고 Devin은 기본적인 nbdev 설정을 이해하지 못했습니다. 더욱 당황스러운 것은 노트북을 직접 편집하는 대신 Python 스크립트를 만들어 수정함으로써 간단한 작업에 불필요한 복잡성을 더하는 노트북 처리 방식이었습니다. 가끔 유용한 주석이나 아이디어를 제공하기도 하지만, 실제 생성되는 코드는 지속적으로 문제가 있었습니다.

보안 검토에서도 비슷한 문제가 발견되었습니다. Devin에게 700줄 미만의 코드가 포함된 GitHub 리포지토리에 대한 보안 취약성을 평가해 달라고 요청했을 때, Devin은 지나치게 많은 오탐과 존재하지도 않는 문제를 허위로 표시했습니다. 이러한 종류의 분석은 Devin의 보다 정교한 접근 방식보다는 타겟팅된 LLM(대규모 언어 모델) 호출로 처리하는 것이 가장 효과적일 수 있습니다.

이 패턴은 디버깅 작업 중에도 계속되었습니다. 설정 스크립트에서 SSH 키 전달이 작동하지 않는 이유를 조사할 때 Devin은 스크립트 자체에 집중했고 문제가 다른 곳에 있을 수 있다는 사실은 전혀 고려하지 않았습니다. 이 땜질식 처방은 실제 근본 원인을 발견하는 데 도움이 되지 않았습니다. 마찬가지로 사용자 입력과 데이터베이스 값 간의 충돌 검사를 추가하라는 요청을 받은 한 팀원은 몇 시간 동안 Devin의 시도를 연구하다가 포기하고 약 90분 만에 직접 기능을 작성했습니다.

팀으로서의 성찰

한 달간의 집중적인 테스트 끝에 저희 팀은 경험을 정리하기 위해 모였습니다. 이 인용문이 저희의 감정을 가장 잘 표현하고 있습니다:

수행할 수 있는 작업은 너무 작고 잘 정의되어 있어서 제 방식으로 더 빨리 수행하는 것이 더 낫습니다. 시간을 절약할 수 있는 대규모 작업에서는 실패할 가능성이 높다고 생각합니다. 결과적으로 제가 실제로 사용하고 싶은 사용 사례는 없습니다.- 조노 휘태커

처음에는 너무 가까워서 무언가를 조정할 수 있을 것 같아서 매우 흥분했습니다. 하지만 점점 더 많은 것을 바꿔야 했기 때문에 서서히 좌절했고, 결국 처음부터 점진적으로 하는 것이 더 낫다는 결론에 도달했습니다.- 아이작 플래스

Devin은 AnswerAI의 내부 도구를 사용하는 데 어려움을 겪었는데, 무엇보다도 여러 가지 문제로 인해 사용하기가 어려웠습니다. 광범위한 문서와 예제를 Devin에게 제공했음에도 불구하고 여전히 문제가 되고 있습니다. 하지만 커서 같은 도구는 점진적인 방식으로 올바른 방향으로 유도할 수 있는 기회가 더 많기 때문에 이런 문제가 발생하지 않는다는 것을 알게 되었습니다.- 하멜 후세인

Devin과 비교했을 때, 개발자 주도의 더 많은 프로세스(예: 커서)가 Devin에서 발생한 대부분의 문제를 피할 수 있다는 사실을 발견했습니다.

평결에 도달하기

Devin과의 협업은 자율 AI 개발의 비전을 보여줍니다. Slack을 통해 채팅하고, 비동기식으로 작동하는 것을 보고, 환경을 설정하고 종속성을 처리하는 등 사용자 경험은 훌륭합니다. 작동하는 모습은 인상적이었습니다.

하지만 여기에는 문제가 있습니다. 저희가 시도한 20개의 작업 중 14개의 실패, 3개의 불확실한 결과, 단 3개의 성공만을 보았습니다. 더욱 걱정스러운 것은 어떤 과제가 성공할지 예측할 수 없다는 것이었습니다. 초기의 성공과 유사한 과제조차도 복잡하고 시간이 많이 소요되는 방식으로 실패했습니다. Devin은 근본적인 장애물을 파악하기보다는 불가능한 해결책을 찾는 데 며칠을 허비하는 등 유망해 보였던 자율성이 부담으로 다가왔습니다.

이는 AI 도구에서 반복적으로 관찰된 패턴을 반영합니다. 소셜 미디어의 흥미와 기업 가치는 실제 활용도와는 거의 관련이 없습니다. 우리가 발견한 가장 신뢰할 수 있는 신호는 제품과 서비스를 제공하는 사용자들의 상세한 스토리에서 비롯됩니다. 현재로서는 AI 지원을 제공하면서 개발 프로세스를 주도할 수 있는 도구를 고수하고 있습니다.

부록: 데빈의 임무 시도

다음 표에는 (1) 새 프로젝트 만들기, (2) 연구, (3) 기존 코드베이스 분석, (4) 코드베이스 수정 등 주제별로 분류하여 Devin에게 제공한 프로젝트가 나와 있습니다.

1. 새 프로젝트 생성

2. 구현 연구

3. 기존 코드 분석

4. 기존 프로젝트의 수정