안녕하세요. @rikachiii입니다. POPOPO 주식회사에서 백엔드를 담당했습니다.

이 글은 무엇인가?

지난번에는 POPOPO의 백엔드가 어느 정도 규모로, 몇 명에 의해 다루어졌는지 숫자로 보여드렸습니다. 마지막 표에서 보듯이, 2025년 5월 말 이후 백엔드 병합 PR의 7할은 Devin이 만든 것입니다.

이번에는 그 Devin에 대해 '수많은 코딩 에이전트 중에서 왜 Devin을 선택하여 팀에 추천했는지'를 쓰고자 합니다. 선택한 후에 AI와 어떻게 마주하고, 어떻게 운영해 왔는지는 다음 글에서 나누어 쓰겠습니다. 미리 말씀드리자면, 이것은 2025년 시점의 POPOPO 당시 체제에서의 저의 판단이며, 도구 자체의 일반적인 우열을 논하는 것은 아닙니다.

전제: 1.6명 체제와 사일로화(属人化)에 대한 불안감

지난번 팀 체제를 돌이켜보면 '2025-02~2025-10: 1.6명'이라는 기간이 있었습니다. 정직원은 저 혼자, 업무 위탁은 주말에만 가동하는 2명이었습니다. AI 개발은 이 시기에 시작되었습니다.

지난 글의 정정 및 개발 체제상의 책임

그러고 보니, 지난번 기사에 보충할 점이 한 가지 있습니다. 기사를 읽으신 분들 중 45명 정도에게서 'POPOPO가 정말 적은 인원으로 개발했네요!' 라는 반응을 얻어 오해를 드린 것 같습니다. 백엔드 팀은 정직원 12명 체제였지만, 프론트엔드 팀에는 약 20명의 엔지니어가 있었고, 기획팀이나 디자이너, 프로모션 등을 포함하면 총 50명이 넘는 팀 체제가 있었습니다. 미출시 서비스 개발이라는 점을 고려했을 때, 다른 스타트업과 비교해도 상당히 규모가 큰 개발을 했다고 생각합니다.

그 속에서 이 시기의 저의 우려는 코드를 빠르게 작성하는 것보다 **'내가 내일 쓰러지면 백엔드 개발이 완전히 멈춘다', '내가 퇴사한다면 인계할 곳이 없다'**는 것이었습니다. API 설계나 DB 설계 등 프론트엔드가 의존하는 리소스가 백엔드 팀 측의 담당이었기 때문에, 백엔드 개발이 멈추는 것은 위에서 언급한 프론트엔드 팀의 개발 상당 부분이 멈추는 것과 같았고, 따라서 프론트엔드 팀의 개발 흐름을 끊지 않도록 필요한 API나 DB 인터페이스를 계속 제공하는 것이 당시 백엔드 팀의 책임이었습니다.

판단의 이유가 남지 않는 문제

하지만 그렇게 되자 대부분의 설계는 충분한 논의를 거쳐 만들어진 것이 아니었고, 개발 중에 모든 설계 의도를 기록할 수도 없었습니다. 객관적으로 볼 때 '왜 이런 아키텍처로 했는지', '왜 이런 테이블 구성으로 했는지' 같은 판단은 대다수가 명확하지 않았고, 모두 문서화되어 있지도 않았습니다. 이렇게 하고자 하는 일명 사일로화(属人化) 문제는 제가 매우 중대한 리스크로 인식했습니다.

프로젝트 비용이나 운영 등 조직을 가로지르는 판단은 ADR (Architecture Decision Record)로 남겼지만, 백엔드에 국한된 이야기까지는 당연히 백엔드의 범위 내에서 결정했습니다. 그리고 백엔드의 범위가 매우 넓했다는 것은 제1회에서 언급했듯이 그렇습니다.

시스템을 만든다는 것

'컴퍼니의 법칙(Conway's Law)'이라는 말을 아시는 분들도 많으실 겁니다. '컴퍼니의 법칙'에 대한 설명은 뒤에 보충으로 쓰겠습니다[1]만, 저는 아키텍트를 직업으로 삼고 있어 시스템을 만들면서 다양한 판단과 조직의 사정이 시스템에 계속 남는 것을 체감적으로 알고 있습니다. 또한 '왜 이런 설계가 되었는지?'라는 일명 **'시스템 고고학(システム考古学)'**을 여러 번 해왔던 입장이었고, 과거의 잘못된[2] 판단으로 괴로워했던 경험도 있습니다.

이번에는 이러한 메타적인 시선까지 깊이 다루지는 않겠지만, 프로젝트 조직과 구축하는 시스템은 분리될 수 없다고 생각합니다. 그리고 시스템을 '한 번 작동할 때까지 만들고 끝'내는 것이 아니라, '순환하며 계속되는 사이클'을 만드는 것이라고 생각합니다. 사람의 몸처럼 순환 고리를 가지고 빙글빙글 돌아가고 있는 상태가 시스템이며, 누군가 한 명이 빠지면 멈춰버리는 것은 시스템이라고 부를 수 없습니다. '최대한 건강하게 돌아가는 상태를 유지하고 시스템의 수명을 늘리는 것'이 시스템 엔지니어의 일이며, 그 목표 중 하나는 **'내가 언제 사라져도 시스템이 작동하는 상태' [3]**라고 생각합니다.

이러한 전제에 서서, 저 혼자 설계가 폐쇄되어 있거나 설계 의도가 남아있지 않은 상태를 제가 왜 문제 삼았는지 이해하실 수 있을 것이라고 생각합니다.
'세상의 스타트업은 다 그런 것'이라고 체념할 수 있는 사람도 있겠지만, POPOPO의 개발 규모는 위에서 말씀드린 것처럼 그렇게 작지 않았습니다. 당시부터 이 프로젝트가 세상에 큰 임팩트를 줄 것이라는 목표가 있었기 때문에, 이것이 언젠가 붕괴하는 것은 제 직책 및 사명과 크게 어긋나는 일이었습니다.

전제: Firestore 채택

자, 이야기를 시스템 개발로 되돌려 보겠습니다. 지난번 각주에서 '다른 글에서 쓰겠다'고 했던 Firestore 직접 접근에 대한 이야기입니다.

부하 대책 요구사항

Firestore를 채택한 이유는 몇 가지가 있지만, 가장 큰 이유는 **'돌발적인 접속 및 다수의 동시 연결을 견디는 것'**이었습니다. POPOPO에서는 프로모션으로 대규모 라이브 스트리밍을 진행할 예정이었고, 처음부터 SNS나 푸시 알림을 통한 대규모 유입도 예상했기 때문에, 순간적/동시 접속 모두 10만 명 규모의 동시 접속에 견디는 것이 설계상의 전제이자 명확하게 전달된 요구사항 및 수치 목표였습니다.

돌발 부하만으로 대응할 방법은 여러 가지가 있지만, POPOPO에는 라이브 기능이 있었기 때문에 당연히 하트비트(시청을 계속하고 있는지 확인)도 필요했습니다. 이는 시청자 수를 카운트하는 데 필요했고, 게다가 지난번 글에서 언급한 '추첨' 기능에도 필요했습니다. 누가 시청자로 남아있는지 알 수 없다면, 이미 라이브를 보고 있지 않은 사람에게 당첨 기회를 줄 수 있게 되고, 시청 중인 사람이 당첨될 때까지 계속해서 순차적으로 당첨자를 뽑게 되어 라이브가 흥미를 잃게 됩니다. 이를 위해서는 시청 중인 클라이언트로부터 주기적(POPOPO에서는 1분마다)으로 하트비트를 보내 '누가 지금 어떤 라이브를 보고 있는지' 기록할 필요가 있었습니다.

이것을 서버의 Web API 등에서 받으면 돌발 부하를 그대로 받게 됩니다. 물론 서버 대수를 늘리고, 언제 올지 모르는 돌발 부하에 대비해 돈을 계속 지출하면 견딜 수는 있지만, 그것은 아키텍처의 패배입니다.

이행 결정

지금은 그렇게 뜬금없는 판단은 아니라고 생각하지만, 당시 상황은 조금 복잡했습니다. 검토를 시작한 것이 2023년 11월 30일이었고, 제가 참여한 지 아직 한 달이 채 되지 않은 시점이었습니다. 이 시점에서 POPOPO는 이미 (시제품 단계를 포함하면) 1년 이상의 개발 기간이 지나 백엔드 API도 일단 가동되어 있고, 관리 툴 등도 갖춰져 있으며, 게다가 프론트엔드 개발도 당연히 진행되고 있었습니다. 당시에는 Rust + MySQL 구성으로 만들어져 있었고, Rust용 공식 Firestore SDK가 없다는 점을 포함하여 판단하기 어려운 부분이 많았습니다. 특히 고민되었던 것은, Firestore로 정말 POPOPO를 완성할 수 있을지에 대한 전망이 서지 않았다는 것이었습니다.

결과적으로, Rust + MySQL에서 TypeScript + Firebase로의 이행을 결정한 것이 2024년 5월 23일이며, 여기서부터 Rust 코드베이스를 완전히 버리고 TypeScript 코드베이스를 만드는 작업이 시작되었습니다.

AI 개발의 기반

이 구성 변경에는 이후의 AI 개발 이행에 따라 좋은 부작용도 있었습니다. 그것은 코드베이스 정비가 0부터 할 수 있었고, 제 범위 내에서 모든 것을 정리할 수 있었다는 점, 그리고 기능 구현이 '업데이트형 API 추가 + Firestore 스키마 및 보안 규칙 추가 + 통합 테스트 추가'라는 거의 같은 형태의 반복이 되었다는 점입니다.

채택 당시에는 물론 AI 개발을 전제로 한 것은 아니었기에 전혀 의식하지 못했지만, 이 '발판이 정비된 상태에서 업무가 정형화되고, 검증 수단(통합 테스트/규칙 테스트/lint)이 갖춰진' 상태는 나중에 돌이켜보면 AI에게 일을 맡기기 위한 전제 그 자체였습니다. 반대로 말하면, 이 토대 없이 Devin만 넣었다면 같은 결과가 나오지 않았다고 생각합니다.

Why Devin?

자, 지난번 글에서 Claude Code도 사용했음을 보여드렸지만, 저는 백엔드 팀에게는 Devin을 추천했다고도 썼습니다. 제가 Devin을 추천했던 이유는 거의 모두 앞서 언급된 종속성(属人化)에 대한 우려에 대한 답이 되었기 때문입니다. 그 이유는 다음과 같은 4가지입니다.

1. 개발의 컨텍스트가 자연스레 남는다

첫 번째 이유입니다. 저는 Devin에게 요청하는 것을 거의 모두 Slack 스레드에서 진행했습니다. Devin에는 Web UI도 있지만, Slack이 필수적인 것은 아니었지만, Slack에서 요청하는 것이 가장 편리했습니다. 그 결과, '무엇을 부탁했고 왜 그렇게 수정했는지'라는 개발의 컨텍스트가 의도치 않게 전부 Slack에 남게 되었습니다. 이전에 올렸던 '파이어볼' 스크린샷도 그렇게 남아있었던 것입니다.

앞서 언급한 '시스템 고고학(System Archaeology)' 관점에서 볼 때, 이러한 경위가 의식적으로 기록하지 않아도 Slack에 남아 있다는 것은 나중에 엄청난 메리트가 됩니다. Slack 자체를 Devin에게 검색하게 할 수도 있고, 다른 AI가 Slack을 조사해도 같은 것이 가능합니다.

로컬에서 동작하는 AI 툴을 사용하는 사람들은 제대로 이 설계 경위를 팀에 남기고 있을까요? 남기고 있는 사람도 있겠지만, 논의 과정까지 확실히 설명해내는 것은 강하게 이를 의식하고 있는 저조차 어렵다고 생각합니다.

게다가 시스템은 개발자만의 것이 아닙니다. 기획, 영업, 디자이너, 경영자 등 어느 직책의 사람이라도 Slack을 검색하며 AI에게 질문하는 상황이 되었습니다. 이때, 시스템이 왜 이런 형태가 되었는지, 당시 무엇이 논의되고 고려되었고, 무엇이 논의되거나 고려되지 않았는지에 대한 경위가 자연스럽게 포착된다는 가치는 앞으로 더욱 커질 것이라고 생각합니다.

실제로 POPOPO에서도 출시가 가까워지면서 기획, CS, QA, PM 등 엔지니어가 아닌 멤버들이 Slack에서 Devin에게 사양이나 코드 조사를 요청하기 시작했습니다. Devin 세션 중 약 20%는 엔지니어 외의 사람이 개시했으며, 출시 월에는 전월 대비 거의 3배 가까이 증가했습니다. 회사 내부에서는 'Devin 조사', 'Devin 말로는'이라는 관용구가 생겼고, CS팀에서는 'Devin 조사를 통해 죄송하지만, ~라는 이해로 알고 있습니다. 오류가 있다면 알려주십시오'와 같은 형태로 확인이 오기 시작했습니다. 버그 트래킹 티켓에도 'Devin 조사 메모' 항목이 생겼습니다.

불량 보고가 도착하는 방식도 바뀌었습니다. 이전에는 '~라는 현상이 발생하고 있습니다'라는 보고를 받고, 제가 코드를 읽으며 원인을 찾는 것부터 시작했습니다. 하지만 이제는 대부분의 경우 원인 추정까지 완료된 상태로 도착합니다. 저는 거의 조사할 필요가 없어졌고, 조사 결과에 적힌 안을 읽어 방침을 정하고, Devin에게 처리를 요청하며, 코드를 검토하는 것으로 충분해지는 경우가 늘었습니다. 요청한 쪽에서 PR(Pull Request)까지 만들어주는 경우도 있었습니다 (물론 Devin이 만든 것입니다).

여기서 가장 좋았던 점은 '엔지니어의 수고가 적다는 것'이 아닙니다. '기획이나 PM이 이미 문제의 본질을 이해한 상태에서 엔지니어를 찾아와 상담하고 있다는 것'입니다. 버그 수정 시 엔지니어가 하는 작업의 90%는 코드를 고치는 것이 아니라, 왜 발생했는지, 고치면 어떻게 되는지, 다른 사양과 모순되지 않는지에 대한 조사와 조정이라고 저는 생각합니다. 이 90%가 해결된 상태, 기획이나 PM이 '이것을 수정하면 어떻게 될까'를 이해하고, 어느 안으로 하고 싶은지까지 어느 정도 결정한 상태로 엔지니어에게 전달되는 것입니다. 실무에 종사하는 엔지니어라면 이 만족감을 느낄 수 있을 것이라 생각합니다.

기획이나 PM이 이런 본질까지 도달할 수 있었던 것은 코드와 그 경위를 Devin으로부터 끌어낼 수 있었기 때문입니다. 컨텍스트가 자연스럽게 남는 것은 엔지니어가 아닌 사람들이 시스템을 이해하는 데 도움을 주기도 했습니다.

2. 병렬 개발이 가능하다

Devin은 클라우드에서 동작하며, 대화 세션마다 하나의 머신을 가집니다. 따라서 로컬 환경을 점유하지 않고 동시 병렬로 개발을 진행할 수 있습니다. 제 담당 영역이 넓어서, 많은 날에는 하루에 12세션을 열었고, 68시간 동안 11세션이 작동한 적도 있었습니다[4]. 물론 실시간으로 동시에 대화할 수 있었던 것은 5세션 정도였는데, 이는 개인적으로 인간의 한계에 가깝다고 생각합니다. 5명과 동시에 이야기하는 것과 같아서, 다른 스레드의 이야기를 실수로 다른 Devin에게 전달해 준 적이 12번 있었습니다. 그럼에도 불구하고, 5개의 작업이 각각 다른 머신에서 빌드나 테스트를 돌리는 상황을 로컬 머신의 툴로 재현하려고 했다면, 엄청난 고안 없이는 머신 리소스 측면에서 개발이 정체되었을 것이라고 생각합니다.

특히, 통합 테스트를 실행하면서 수정하거나 관리 도구 UI를 수정할 때 Devin이 유용했습니다. UI 수정의 경우 스크린샷을 찍고 컴포넌트 움직임은 동영상으로 녹화하여 GitHub PR에 첨부하도록 했기 때문에, UI 수정 역시 거의 지시만으로 완료될 수 있었습니다.

사례: OGP 이미지 레이아웃

가장 왕복(반복 작업)이 많았던 사례를 하나 소개합니다. OGP 이미지(SNS에서 링크 공유 시 나타나는 카드 이미지)의 서버 측 합성입니다. 출시 5주 전인 2026년 2월, 새로운 요구사항에 맞춰 6종류의 OGP 이미지를 재작업했을 때의 일입니다.

처음에는 디자이너가 Figma에 넣어둔 완성본 참고 디자인을 SVG 그대로 리포지토리에 두고, '이것을 재현해 달라'고 전달했습니다. 당연히 SVG에는 레이어 구조 정보가 포함되어 있고 파트별 벡터 정보도 있기 때문에, 그것만 보면 재현할 수 있을 것이라고 생각했기 때문입니다.

그리고 생성된 이미지를 PR에 첨부하여 차이점을 확인했을 때, 로고의 투명도나 워터마크 위치가 아무리 고쳐도 맞지 않았습니다. 8일 후에는 PR을 일단 닫고 디자이너의 지시를 받아 다시 진행했습니다. 원인 중 하나는 로고 SVG 자체에 투명도나 색상이 내장되어 있어, 코드 측 지정과 이중으로 적용되고 있었기 때문이었습니다. 그래서 'SVG는 형태만 사용하고, 색상은 그때그때 코드 측에서 지정한다'는 방침으로 변경했고, 결국 디자이너에게 소재 SVG를 다시 받아 전면 교체했습니다. 기록을 보면 대략 3번 정도 작업 방식을 바꿨습니다.

2025년 10월경 이후로는 제가 거의 손으로 코딩하지 않았기 때문에, 여기서 '내가 직접 하는 것이 빠르다'며 가져갈 선택지는 없었습니다. 손으로 고치지 않은 이유는 또 있습니다. 1에서 작성한 시도와 오류의 로그를 Slack에 남기고 싶었기 때문입니다. 이미지 하나에도 의도가 담겨 있습니다. 그것을 디자이너와 이야기하고 Devin에게 전달하는, 그 중간 과정을 거친 논의 기록이 프로젝트로서 큰 가치가 있다고 생각했습니다.

아마 지금 AI라면 처음 제가 시도했던 방식만으로도 상당히 높은 정확도의 결과를 반환할 수 있을 것이므로, 이는 AI의 발전으로 해결되는 부분일 수도 있습니다. 하지만 역시 잘하는 영역과 서툰 영역은 분명히 존재하며, 이 시행착오 과정은 저에게 매우 배움이 많았던 사례였습니다.

3. 작업 상황이 프로젝트에 공개됨

이야기로 돌아가겠습니다. 세 번째 이유는 1과 약간 중복되지만, 다른 사람의 개발 과정을 볼 수 있다는 점도 큰 부분입니다.

POPOPO는 완전 원격으로 개발하고 있으며, 업무 위탁 멤버의 참여와 이탈이 몇 번 있었습니다. 원격으로, 게다가 주말 근무하는 멤버들과 함께 개발할 경우, '지금 무엇을 하고 있는지, 얼마나 진행되었는지, 어디서 막히고 있는지'를 파악하려면 보고와 확인을 위한 커뮤니케이션이 필요합니다. 이는 보고하는 측과 확인하는 측 모두에게 부담이며, 어느 한쪽이라도 바쁘면 끊기기 쉽습니다.

작업이 클라우드상의 세션으로 진행된다면, 이 보고/확인 과정의 상당 부분은 불필요해집니다. 저희 조직 설정에서는 Devin의 세션이 팀 내에서 열람 가능했기 때문에, 진척 상황을 알고 싶다면 세션을 들여다보기만 하면 되고, Devin에게 다른 세션을 읽게 하고 요약하게 할 수도 있었습니다.

즉,

• 멤버 측은 작업 상황을 일일이 보고할 필요가 없고
• 확인하고 싶은 측은 듣지 않아도 상황을 알 수 있다는 관계가 됩니다.

'확인하고 싶은 측'은 직속 매니저에 국한되지 않습니다. 진척도를 신경 쓰는 사람은 리더뿐만 아니라 옆 팀(저에게는 프론트엔드 팀이나 기획 팀), 나아가 프로젝트 매니저, 경영진 등 모두가 '확인하고 싶은 측'입니다. Devin과 Slack으로 이야기한다는 것은, 프로젝트의 모든 멤버에게 작업 진행 상황이 실시간으로 공개된다는 의미입니다.

4. 개발 방식과 지식이 공개됨

마지막 네 번째 이유는 다른 것과 약간 겹치지만, 다른 시점에서 설명하겠습니다.

Claude Code와 같은 로컬 CLI(Command Line Interface) 타입의 도구를 사용하는 사람들은 자신의 머신에 CLAUDE.md를 키우고 있을 것입니다. 그곳에는 개발의 컨텍스트(전제 용어, 팀 멤버, 문서에 없는 역사 등)가 축적됩니다. 물론 skill을 정비하거나 리포지토리 측의 CLAUDE.md를 제대로 업데이트하는 사람도 많을 것이고, 조직으로서는 그것을 권장하고 있을 것입니다.

다만, 리포지토리 반영은 '일부러' 하는 것입니다. PR(Pull Request)과 리뷰를 거칠 필요가 대부분 있고, 일상적인 작업 중에는 미루기 쉽습니다. 게다가, skill은 어디까지나 결과물에 불과하며, 잘 개발하는 사람이 처음에 무엇을 이야기하고 어떻게 던져주었는지, 그 상호작용 자체는 어디에도 남지 않습니다. skill을 어떻게 구축했는지가 사실 개발의 진수(眞髓)일 것입니다. 기계가 고장 나면 해당 세션은 사라지고 복원은 불가능합니다.

Devin에는 knowledge라는 기능이 있어, 세션 중에 학습한 것을 Devin 스스로가 knowledge에 추가할 것으로 제안해 줍니다. 이 제안을 수용할지 여부를 사람이 판단하는 흐름으로 팀의 암묵지가 조직 측에 축적됩니다. POPOPO의 knowledge는 가장 많았던 시기에 112건(그중 백엔드 관련이 약 80건)이었고, 정리(다음 글에서 다룹니다)를 거쳐 66건까지 줄였으며, 이후 추가 및 업데이트를 거쳐 현재는 68건입니다.

게다가 세션이 열려 있기 때문에, 잘 개발하는 팀 멤버들의 상호작용을 보고 AI와의 대화 방식을 그대로 따라 할 수 있습니다. 반대로, 자신이 던진 방식 때문에 AI가 막힐 때 다른 사람에게 보여주고 '컨텍스트가 좁다', '단정적으로 너무 많이 써서 AI의 제안 여지를 없애고 있다'와 같은 피드백을 받을 수도 있습니다.

새로 합류한 멤버가 과거 세션을 따라가며 '이 팀에서는 어떻게 업무를 진행하는지'를 파악할 수 있다는 것도 같은 성질에서 오는 장점입니다. 이직 경험이 있는 분들도 많겠지만, 신입이 처음 팀에 합류했을 때 '다른 사람들은 어떻게 일하고 있을까?'는 가장 먼저 직면하는 과제입니다. 그럴 때, 그 팀에서 최고의 성과를 내고 있는 사람의 업무 방식을 Slack에서 완전히 전부 엿볼 수 있는 상태가 있다면, 이보다 더 좋은 학습 방법은 없습니다.

보충: Claude Code와의 사용법 비교

백엔드 개발자들은 Claude Code도 사용했고, 저 자신도 시도해 보고 있습니다. 위의 네 가지는 'Devin만이 할 수 있는' 것은 아니며, Claude Code 역시 Slack 연동이나 공유 기반을 갖추면 같은 상태에 근접하게 만들 수는 있습니다. 차이점은, 클라우드 상주하며 채팅을 진입점으로 하는 형태에서는 이것들이 아무것도 하지 않아도 성립한다는 점입니다. 위와 같은 문제를 실제로 겪고 있는 기업은 많겠지만, 과연 Claude Code의 세션 전체를 팀이나 회사 전체에 제대로 열어 검색 가능하게 하고 있는 기업이 그리 많은가요?

요약 및 다음 글에서 계속

여기까지 왜 Devin을 선택했는지에 대해 써왔습니다. 네 가지 이유 모두 코드를 빠르게 작성하는 것보다는, 개발의 경위·진척도·방식을 '남기거나', '공개하는' 것에 관한 것입니다.

지금까지 Devin을 강력히 추천하는 것처럼 읽으셨겠지만, 이는 1.6명 체제에서 인력 의존성(属人化)에 고민하던 당시 저의 시점이었고, 체제나 단계가 다르면 다른 판단이 될 것이라고 생각합니다. 다만, POPOPO의 당시 상황에서는 메리트가 컸던 것은 사실입니다.

하지만 도구만 선택한다고 해서 컨텍스트나 knowledge가 '남거나·축적될' 가능성만 있을 뿐입니다. 다음 글에서는 Devin을 선택한 후에 실제로 AI와 어떻게 마주하고, 어떻게 운영했는지에 대한 노하우를 쓰겠습니다.

그럼 다음 글에서 뵙겠습니다.

"콘웨이의 법칙(Conway's Law)"이란 '시스템을 설계하는 조직은 그 조직의 커뮤니케이션 구조와 똑같은 구조의 설계를 만들어낸다'는 것입니다. 예를 들어, 프론트엔드 팀과 백엔드 팀 두 팀으로 시스템을 만들 경우, 시스템은 2층 구조가 되기 쉽고, 프론트·백·인프라 팀 세 팀으로 시스템을 만들면, 시스템은 3층 구조가 되기 쉽다는 것입니다. 즉, '조직의 형태가 시스템의 형태를 결정해 버린다'는 법칙입니다. ↩︎

• 잘못되었는지 여부는 당연히 사람 각자의 해석에 따르겠지만, 제가 직업적으로 다룬 제한된 사례라 할지라도(당시 판단으로도) '굳이 이런 선택을 할 필요는 없었겠다'라는 선택지를 골랐던 경우가 셀 수 없이 많습니다. 물론 그곳에 있던 사람들을 탓하는 것이 아니라, 대부분의 판단 오류 원인은 정보 부족이나 정리 부족, 나아가 시간 부족 등이 가장 큰 이유일 것입니다. ↩︎

이는 컨웨이의 법칙(Conway's Law)으로 볼 때 모순적인 상태입니다. 그 사람이 없으면 개발할 수 없는 것을, 그 사람 자신을 시스템에 통합하지 않고 만들려고 하는 것이니까요. 인간으로 비유하자면, '자신과 분리 가능한 외부 장치에 의해 자신의 몸이 만들어지는 상태'... 즉, 어머니와 태아의 관계 같은 형태로, '태아 시스템이 완성되면 어머니로부터 분리한다'는 출산 과정을 구현하려는 것에 가깝다고 생각합니다. ↩︎

• Devin API에서 가져온 제가 만든 세션 867건의 생성 시점으로부터 계산한 것입니다. 하루 평균 생성 건수는 중앙값이 3, 최대가 12였습니다. ↩︎

논의 (Discussion)