AI 시대의 SDLC를 직접 설계하기

URL: https://www.youtube.com/watch?v=ks55L-DkLE8 날짜: 2026-10-13 채널: Tech Bridge 원문 제목: [한영자막] 직접 만드는 SDLC — Andy Wong, Andrei Bocan, Shane Wolf (Atlassian) 발표자: Andy Wong, Andrei Bocan, Shane Wolf (Atlassian) 원출처 행사: AI Engineer's World Fair

📌 핵심 질문 / 핵심 주장

==AI 코딩 도구의 다음 생산성 도약은 코드 생성 모델 자체가 아니라, 코드의 왼쪽과 오른쪽에 있는 계획·조율·검토·운영을 조직의 맥락과 연결하는 데서 나온다.==

• AI 코딩 도구가 늘어날수록 단순한 코드 작성에서 얻는 생산성 향상은 점차 둔화된다.
• Jira, Confluence, Bitbucket, Slack, Notion과 소스 코드의 관계를 AI Context Engine으로 연결하면 에이전트가 현재 코드와 과거 의사결정을 함께 검색할 수 있다.
• AI Reviewer는 낮은 가치의 지적을 걸러내고, AutoDev는 검토 용량·비용·요구사항의 불확실성을 통제하면서 백로그를 PR로 전환한다.
• 사람이 권위를 부여하고 최종 검토하는 구조가 남아 있어야 하며, 에이전트가 많이 만들어내는 것보다 팀이 감당할 수 있는 변화량이 중요하다.

1. 코드 생성 너머로 확장되는 AI 네이티브 SDLC

Atlassian은 AI를 개발자의 편집기 안에만 넣지 않고, 작업의 시작부터 운영과 회고까지 연결하는 방향으로 확장한다.

1.1. 생산성 곡선이 가리키는 다음 기회

1. 코드 생성만으로는 다음 도약을 만들기 어렵다

   1. AI 에이전트는 소프트웨어 개발 생명주기를 크게 바꾸었지만, 코딩 도구가 추가될수록 도구 하나가 더해주는 생산성 증가는 점차 줄어들고 있다.
   2. Andy Wong은 가장 큰 기회가 코드 자체보다 코드의 왼쪽과 오른쪽, 즉 계획(planning), 오케스트레이션(orchestration), 코드 리뷰, 운영(operations)에 있다고 말했다.
   3. 개발팀은 코드를 쓰는 시간뿐 아니라 무엇을 만들지 정하고, 조직의 표준을 적용하고, 변경을 검토하고, 장애를 복구하는 데 많은 시간을 쓴다.

2. Atlassian의 제품 묶음은 SDLC의 주변부를 연결한다

   1. Teamwork Graph는 업무·코드·사람·의사결정의 관계를 연결하는 맥락 계층이다.
   2. Jira Coding Agent(JCA)는 Jira 작업 항목을 읽고 조직 맥락을 바탕으로 계획·구현·검증을 수행하는 Atlassian 네이티브 코딩 에이전트다.
   3. AI Reviewer는 풀 리퀘스트의 버그·표준 위반·요구사항 충족 여부를 코드 바깥의 맥락까지 참고해 검토한다.
   4. 중앙화된 Standards는 조직의 규칙을 저장하고 여러 저장소의 풀 리퀘스트에 반복 적용한다.
   5. AI Planner는 아이디어나 스파이크가 현재 저장소에서 실현 가능한지 판단하고 구현 계획을 만든다.
   6. AutoDev는 백로그에서 에이전트가 처리할 수 있는 일을 골라 풀 리퀘스트를 만들며, AI SRE는 과거 장애·Jira·Confluence의 맥락으로 장애 원인과 완화책을 제안한다.

1.2. Jira Coding Agent와 개발 작업의 위임

1. JCA는 조직 맥락을 읽는 엔터프라이즈 에이전트다

   1. JCA는 Jira 티켓뿐 아니라 연결된 Confluence 문서, 이메일, Slack 메시지와 기타 Atlassian 생태계 정보를 읽어 특정 작업을 계획하고 구현한다.
   2. 작업과 풀 리퀘스트를 Jira 클라우드 안에서 관리할 수 있어 코드 변경의 요청·실행·검토를 하나의 흐름으로 묶는다.
   3. JCA를 쓰고 싶지 않은 팀은 Jira 작업을 Claude, Cursor, Codex 같은 외부 에이전트에 직접 할당할 수 있다.
   4. Jira의 조건 기반 자동화는 조건이 충족될 때 JCA 또는 선택한 에이전트를 호출하는 SDLC 자동화를 구성한다.

2. 워크숍은 실제 작업 흐름을 체험하도록 설계됐다

   1. Shane Wolf가 나눠준 번호가 로그인 계정과 연결되고, student와 번호를 조합한 계정으로 테스트 Jira 워크스페이스에 들어가도록 안내했다.
   2. 참가자는 Confluence 페이지의 링크와 QR 코드로 테스트 공간에 접속하고, Bitbucket의 Atlassian swag 스타터 저장소에서 작업을 시작하도록 했다.
   3. 행사장 Wi-Fi가 작동하지 않아 로그인과 데모가 반복해서 지연됐다. 발표자들은 QR 코드와 로그인 안내를 다시 띄우고, 행사가 끝날 때까지 워크숍 사이트를 열어두겠다고 했다.
   4. 테스트 계정이 안전하지 않으므로 GitHub Gist나 Bitbucket Snippet에 공개해도 괜찮을 정보만 입력하라는 주의가 붙었다.

2. AI Reviewer와 조직 표준의 자동 적용

AI Reviewer의 가치는 리뷰 댓글을 많이 만드는 데 있지 않고, 사람이 실제로 수정할 만한 댓글만 남기는 데 있다.

2.1. 낮은 가치의 리뷰 노이즈 제거

1. 리뷰는 코드 밖의 요구사항까지 확인해야 한다

   1. AI Reviewer는 풀 리퀘스트를 훑어 버그를 찾고 표준을 강제하며 요구사항 충족 여부를 확인한다.
   2. Jira, Confluence, 소스 코드 관리 시스템(SCM), Slack의 정보를 검색해 변경이 해결해야 할 문제와 비교한다.
   3. 단순한 코드 패턴만 검사하면 티켓의 의도나 조직의 약속을 놓칠 수 있으므로, 리뷰의 범위를 코드 바깥으로 넓힌다.

2. 댓글 수보다 해결률이 품질 지표다

   1. 기존 코드 리뷰 도구는 지나치게 꼼꼼해서 낮은 가치의 댓글과 불필요한 지적을 많이 남길 수 있다.
   2. Atlassian은 자체 모델로 이런 노이즈를 필터링하고, 사람이 실제 코드 변경으로 해결할 가능성이 낮은 댓글을 줄이려 한다.
   3. Andy Wong이 제시한 사람의 코드 리뷰 댓글 해결률은 약 45%이고, AI Reviewer는 약 40%의 사람 해결률을 기록했다.
   4. 이 수치는 AI 리뷰가 댓글을 많이 쓰는 능력이 아니라 인간 리뷰에 가까운 실행 가능한 지적을 만드는 능력으로 평가되어야 함을 보여준다.

2.2. Standards로 저장소 전체에 규칙 배포

1. 표준은 중앙에서 만들고 적용 범위를 선택한다

   1. 데모에서 design token enforcement라는 새 표준을 만들고 이름·설명·규칙을 입력했다.
   2. 표준 적용 대상은 저장소를 하나씩 수동 선택하거나 패턴 매칭으로 지정할 수 있다.
   3. 표준이 저장되면 Rovo Dev/Jira 코딩 에이전트가 해당 저장소의 풀 리퀘스트를 검토하고 규칙을 지키지 않은 부분에 댓글을 단다.
   4. GitHub, GitLab, Bitbucket Cloud 등 여러 SCM 플랫폼에서 같은 표준을 사용할 수 있다.

2. 자연어 표준과 결정적 검사의 경계가 남아 있다

   1. Standards의 규칙은 자연어와 Markdown으로 작성된다.
   2. 참석자는 표준을 이진적인 CI 체크로 변환해 예/아니오로 판정할 수 있는지 물었다.
   3. 당시 제품에는 자연어 표준을 결정적 CI 검사로 매핑하는 기능이 기본 제공되지 않았다.
   4. Andy Wong은 Markdown 안에 체크 조건을 넣는 방법을 언급하면서, 이 요구사항을 Standards 팀에 전달하겠다고 답했다.
   5. 자연어 에이전트 리뷰는 기존 코드까지 점진적으로 정리할 수 있지만, 결정적 CI 검사는 반복 가능한 안전망을 제공하므로 두 방식의 결합이 중요하다.

3. AI Context Engine과 코드의 진실

AI 에이전트의 성능은 모델의 생성 능력뿐 아니라 어떤 자료를 어떤 관계로 검색해 주는지에 좌우된다.

3.1. 그래프 데이터와 에이전트 검색

1. 여러 업무 시스템의 관계를 하나의 맥락으로 만든다

   1. Atlassian 내부에는 고객이 제품에 입력한 데이터를 연결하는 여러 그래프 데이터베이스가 있다.
   2. Confluence, Jira, Bitbucket의 데이터는 제품 사용 과정에서 추론된 관계 또는 사용자가 명시한 관계로 연결된다.
   3. Jira 티켓이 Confluence의 사양 문서를 근거로 삼는 관계처럼, 업무 항목과 문서의 연결이 검색 가능한 구조로 저장된다.
   4. Notion과 Slack 같은 서드파티 제품도 연결해 조직 전체의 맥락을 하나의 직물(tapestry)처럼 엮는다.
   5. AI Context Engine은 그 위에서 필요한 순간에 자료를 찾는 에이전트 검색(agentic search)을 제공한다.

2. 현재 작업과 조직의 다른 작업을 연결한다

   1. 한 팀이 플랫폼의 한쪽에서 만든 기능이 다른 팀의 문서·프로젝트·이니셔티브에 영향을 줄 수 있다.
   2. Context Engine은 현재 에이전트 코딩 세션에 관련 팀의 문서와 작업 맥락을 끌어온다.
   3. AI Planner와 AutoDev는 Context Engine을 활용해 계획과 구현 대상을 파악하고, AI Reviewer도 더 많은 맥락을 가져오는 실험을 시작했다.
   4. Rovo Chat은 초기 고객 접근 단계에서 코드 질문에 Confluence 검색과 연결 도구를 활용하며, GitHub와 Bitbucket이 연결된 경우 각 서비스의 검색 API도 사용한다.
   5. Teamwork Graph CLI는 Context Engine의 핵심 기능과 코드 컨텍스트 스킬을 외부 에이전트에 노출하는 경로다.

3.2. 모노레포의 대안으로서 코드 검색

1. 모노레포는 맥락을 보장하지만 도구 부채를 만든다

   1. 여러 저장소에 코드가 흩어져 있으면 에이전트가 항상 필요한 맥락을 얻기 어렵기 때문에 팀은 모노레포를 선택해 왔다.
   2. 모노레포는 모든 코드를 한곳에 두는 대신, 거대한 저장소를 운영하는 도구와 빌드 체계를 별도로 구축해야 한다.
   3. Andrei Bocan은 모노레포를 선택하는 일이 모노레포의 부채를 함께 선택하는 것이며, “그것을 만들기 위한 도구를 만드는 데 많은 시간을 쓴다”고 지적했다.

2. 코드 수준 검색은 저장소를 합치지 않고 맥락을 합친다

   1. Atlassian은 코드 수준 접근이 가능한 새로운 코드 검색 제품을 구축하고 있다.
   2. Context Engine은 필요한 저장소와 파일을 높은 처리량으로 찾아 제품 저장소가 모노레포처럼 작동하게 만든다.
   3. 문서는 특정 시점의 상태를 기록한 스냅샷일 수 있지만, 현재 실행되는 로직의 진실은 코드에 있다.
   4. 에이전트는 코드를 직접 검색해 현재 동작을 파악하고, 관련 문서와 관계 정보를 위에 겹쳐 계획과 구현 경로를 만든다.

3.3. 최신성·충돌·권위의 처리

1. 최신 정보를 우선하되 과거 문서를 버리지 않는다

   1. 오래된 문서는 현재 상태와 다를 수 있어 검색 결과를 오염시키는 것처럼 보인다.
   2. Shane Wolf는 오래된 문서도 특정 시점에 왜 그런 결정을 했는지 알려주는 가치 있는 자료라고 말했다.
   3. 현재 코드가 어떻게 존재하는지와 과거 결정이 왜 내려졌는지를 함께 보면, 에이전트가 과거의 실수를 반복하지 않는 구현 경로를 선택할 수 있다.
   4. 조직에서 오래된 결과가 여전히 유효하면 최신 결과를 우선하는 검색 정책과 함께 Confluence의 verified 배지를 사용해 최신 권위를 표시한다.

2. 충돌하는 정보에는 인간의 권위 부여가 필요하다

   1. 서로 다른 자료가 충돌할 때 에이전트가 어느 정보가 사실인지 자동으로 확정해서는 안 된다.
   2. 사람은 특정 자료를 검증됨(verified)으로 표시하고 다른 자료보다 높은 권위를 부여할 수 있다.
   3. 정보는 미리 하나의 스냅샷으로 고정하기보다 필요할 때 최신 상태로 가져오는 편이 낫다. 캐시가 오래되면 새로운 사실을 가릴 수 있기 때문이다.
   4. Confluence 문서에는 인간이 검증 여부를 표시하기 쉽지만, Jira 작업 항목을 자동으로 authoritative하게 만드는 일은 더 많은 수동 작업을 필요로 한다.
   5. Jira 항목을 자동으로 권위 있는 정보로 만들면 실제 검증 없이 권위를 얻게 되는 이상한 상황이 생길 수 있다.

3.4. 15,000개 저장소를 다루는 Code Chat

1. 검색 공간을 먼저 좁힌다

   1. Atlassian에는 약 15,000개의 저장소가 있어 이 변경을 어디에 구현해야 하는가, X와 Y가 어디에 구현되어 있는가, 어떤 서비스가 다른 서비스를 사용하는가 같은 질문도 어렵다.
   2. Code Chat은 답이 있을 가능성이 높은 코드 영역으로 검색 공간을 먼저 좁힌 뒤, 그 영역을 깊이 파고들어 답을 만든다.
   3. 코드 검색 결과에 Teamwork Graph의 문서·업무·사람 관계를 결합해 현재 코드와 과거 의사결정을 함께 반영한다.

2. 기록되지 않은 의도를 보완한다

   1. 에이전트가 생성한 코드에는 결정을 내린 이유가 빠지기 쉽다.
   2. 과거 문서의 결정 이유는 현재 코드와 다르더라도 미래 변경에서 같은 실수를 반복하지 않게 하는 역사적 맥락이다.
   3. AI Planner는 관련 프로젝트와 문서를 참고해 구현 방법을 찾고, AutoDev는 같은 맥락으로 백로그 작업의 수행 가능성을 판단한다.

4. 검증·실행 환경·비용의 현실

에이전트가 코드를 작성하는 능력만큼, 결과를 실행하고 요구사항을 검증하며 비용을 통제하는 능력이 중요하다.

4.1. 인수 조건과 샌드박스 검증

1. Jira 작업 항목의 체크리스트가 검증 기준이 된다

   1. JCA는 작업 항목에 인수 조건(acceptance criteria) 체크리스트가 있다고 가정한다.
   2. 코드 생성을 끝냈다고 판단하면 체크리스트의 각 조건을 다시 확인한다.
   3. 저장소에 프로젝트를 실행하는 방법이 적혀 있으면 에이전트가 필요한 것을 설치하고 실행한 뒤, 브라우저를 열어 검증 절차까지 수행할 수 있다.

2. Atlassian이 제공하는 샌드박스에는 한계가 있다

   1. JCA는 Docker가 활성화된 Atlassian 전용 컨테이너 샌드박스에서 실행된다.
   2. 샌드박스는 대부분의 설치·실행 작업을 처리할 수 있지만, 사용자가 자신의 샌드박스를 가져와 연결하는 기능은 당시 제공되지 않았다.
   3. 특수한 사내 인프라나 별도 실행 환경이 필요한 기업은 이 제약을 고려해야 한다.

4.2. 모델 선택과 크레딧 보고

1. 현재는 사용자가 모델을 선택한다

   1. JCA는 Anthropic과 OpenAI 계열 모델을 선택해 사용할 수 있으며, 당시 제품이 모든 모델을 자동으로 지능적으로 라우팅하지는 않았다.
   2. 스킬과 서브에이전트는 특정 작업에 사용할 모델을 지정할 수 있다.
   3. AutoDev는 작업 난이도에 맞는 모델을 추천하고, 특정 작업이 저비용 모델로 충분한지 판단할 수 있는 지표를 제공하는 방향으로 개발되고 있다.

2. 비용·사용량의 세부 추적은 계속 개발 중이다

   1. 각 에이전트는 고객의 API 키를 사용할 수 있고, 사용량에 따른 종량제(pay-as-you-go) 구조가 적용된다.
   2. 사용량은 제품과 경험 단위로 어느 사용자가 어떤 기능을 썼는지 확인하는 수준까지 나뉘지만, 작업 경험별 세부 보고는 아직 충분하지 않다.
   3. 한 사용자가 어떤 작업에 10억 토큰을 쓸 수도 있으므로, 에이전트가 만든 결과의 가치가 비용을 정당화하는지 확인해야 한다.
   4. AI 코딩을 사용하는 사람이 늘어날수록 팀 단위 투자수익률(ROI)과 작업별 비용 귀속이 중요해진다.
   5. 워크숍 질의응답에서 JCA는 이미 출시된 기능이며, 크레딧 과금과 API 키 사용 방식이 함께 설명됐다.

4.3. 개발 환경과 세션 격리

1. 클라우드 에이전트 세션과 IDE 변경은 분리된다

   1. JCA 세션 안에서 바꾼 코드는 해당 클라우드 세션에서 실시간으로 반영된다.
   2. 클라우드 안의 VS Code 인스턴스에서 만든 변경도 클라우드 세션에 실시간으로 보인다.
   3. 사용자의 별도 IDE에서 만든 변경은 별도 인스턴스이므로 JCA 세션의 실시간 상태와 자동으로 같아지지 않는다.

2. 온프레미스 실행 요구에는 컨테이너가 기준이 된다

   1. 참석자가 온프레미스 환경에서 에이전트를 여러 개 실행할 때 필요한 개발 환경을 질문했다.
   2. 답변은 Docker 기반이라는 짧은 확인으로 정리됐다.
   3. AI Reviewer에는 스킬 지원이 추가됐으며, 당시 한 달이 채 안 된 기능으로 소개됐다.

5. AutoDev: 백로그를 PR로 바꾸는 SDLC 오케스트레이션

AutoDev는 에이전트가 코드를 많이 만드는 시스템이 아니라, 팀이 감당할 수 있는 범위에서 반복 작업을 대신 수행하는 오케스트레이터를 지향한다.

5.1. 초기 릴리스의 작업 흐름

1. 확신할 수 있는 백로그 작업만 선택한다

   1. Andrei Bocan은 AutoDev를 Atlassian의 AI SDLC 오케스트레이션 진입점으로 소개했다.
   2. 초기 릴리스는 백로그에서 에이전트가 자율적으로 처리할 수 있다고 판단한 작업을 골라 구현하고 팀 검토용 PR을 생성한다.
   3. 팀은 올바른 일을 고르고 있는지, 표준을 지키는지 확인하며, 이 피드백으로 코드베이스의 에이전트 준비도와 하네스(harness)를 개선한다.
   4. 사용자는 AutoDev가 가져갈 작업을 직접 지정할 수도 있다.

2. 기존 코드의 표준 준수도 점진적으로 높인다

   1. AI Reviewer의 표준은 앞으로 코드베이스에 들어오는 변경을 검사한다.
   2. AutoDev는 기존 코드베이스를 스캔하고 여러 개의 작은 PR을 순차적으로 만들어 기존 코드도 표준에 맞춘다.
   3. 코드베이스 절반을 한꺼번에 바꾸거나 높은 churn을 만드는 PR은 사람이 승인하기 어렵기 때문에, 자동화는 변경량을 점진적으로 제한해야 한다.

5.2. 검토 용량·요구사항·비용을 통제한다

1. 작업량은 팀의 검토 용량 안에 있어야 한다

   1. 팀원 한 명에게 일주일에 3~5개의 PR만 할당하는 식으로 작업 진행량(work-in-progress)을 제한할 수 있다.
   2. Andrei Bocan은 “누구도 하루에 50개의 PR을 검토하는 데 시간을 쓰고 싶어 하지 않는다”고 강조했다.
   3. 작은 단위의 진행은 표준 준수도를 높이면서 엔지니어가 기능 개발에 쓸 시간을 보존한다.

2. 모호한 작업에는 사람이 먼저 요구사항을 보완한다

   1. 백로그에는 요약 한 줄이 do the thing인 것처럼 목표와 성공 조건이 빠진 작업 항목이 존재한다.
   2. AutoDev는 이런 항목을 임의로 추측해 구현하지 않고 사람에게 실제 목표와 작업 여부를 묻는다.
   3. 사람이 충분한 수준으로 요구사항을 구체화한 뒤에야 에이전트가 구현을 시작한다.
   4. 검토 단계에서는 사람이 병합할지 폐기할지 판단하고, AutoDev는 적절한 시점에 Slack으로 검토 요청을 보낸다.

3. 비용 상한과 ROI를 운영 규칙으로 둔다

   1. 작업 항목별 지출 상한과 주간 지출 상한을 설정해 에이전트가 무제한으로 실행되지 않게 한다.
   2. 이런 비용 제한은 자율 에이전트 운영의 기본 조건으로 간주된다.
   3. ROI 인사이트는 사용한 비용보다 실제로 원하는 작업이 얼마나 완료됐는지 확인하게 한다.

5.3. 조직 전체의 마이그레이션을 조율한다

1. AutoDev는 조직 조향(organizational steering)을 목표로 한다

   1. 대규모 조직에는 비슷한 서비스가 수천 개 있고, 여러 팀이 같은 버전 업그레이드나 표준 적용을 반복한다.
   2. 예시로 10,000개의 서비스를 한 Rails 버전에서 다른 버전으로 마이그레이션하는 작업이 제시됐다.
   3. 한 팀이 작업 방식을 정하면 에이전트가 유사한 서비스에 PR을 만들고 사람은 우선순위·예외·조율을 담당한다.
   4. 과거 작업에서 얻은 기억과 학습을 연결하면 반복적인 조직 작업을 더 적은 사람의 개입으로 수행할 수 있다.

2. Jira 보드가 자동화의 관제판이 된다

   1. AutoDev가 어떤 작업을 선택했고 누구에게 할당했으며 어디에서 막혔는지 Jira 보드에 나타난다.
   2. 사람들은 다음에 할 일을 정할 때 Jira 보드를 보는 경우가 많으므로, 자동화 활동도 기존 업무판 안에 보여야 한다.
   3. 사람이 잘못된 작업 선택이나 잘못된 담당자 배정을 발견하면 중간에 개입하고, AutoDev는 그 경험을 통해 선택 방식을 개선한다.

6. AI Planner와 에픽 분해

계획 단계의 에이전트는 아이디어를 곧바로 코드로 바꾸지 않고, 저장소의 실제 상태와 실행 가능성을 먼저 확인한다.

6.1. 아이디어의 실현 가능성과 구현 계획

1. AI Planner는 계획 전 단계의 질문에 답한다

   1. 스파이크를 진행하는 사람, 프로젝트 관리자, 엔지니어링 관리자는 특정 저장소에서 아이디어가 가능한지 먼저 알고 싶어 한다.
   2. AI Planner는 아이디어와 구현하려는 기능을 입력받고 Context Engine을 통해 저장소·관련 문서·기존 프로젝트를 조사한다.
   3. 현재 코드베이스에서 계획이 실현 가능한지 판단하고, 가능하다면 필요한 구현 항목을 분해한다.
   4. 같은 목표에 도달하는 여러 실행 경로를 제시해 계획 선택을 돕는다.

2. 계획과 실행은 연속된 자동화가 될 수 있다

   1. AI Planner가 만든 분해 결과는 Jira 작업 항목과 에픽 구조로 이어질 수 있다.
   2. 구체화된 작업은 JCA 또는 AutoDev가 실행하고, 표준과 인수 조건이 검토 단계에 전달된다.
   3. Context Engine은 계획·코딩·리뷰가 각자 별도의 검색 결과를 만들지 않도록 공통 맥락을 제공한다.

6.2. 에픽에서 작업 파동으로 내려가기

1. 에픽을 작은 작업과 에이전트 파동으로 분해한다

   1. JCA에 Jira 에픽을 더 작은 작업으로 나누도록 요청하면 여러 Jira 작업 항목을 만들 수 있다.
   2. Jira 자동화 규칙은 분해가 끝난 뒤 각 작업마다 새 JCA 세션을 시작할 수 있다.
   3. 여러 작업을 동시에 실행하는 첫 번째 에이전트 파동 뒤에, 결과를 바탕으로 두 번째 파동을 실행하는 구성이 가능하다.
   4. 더 큰 에픽도 기초 작업, V0, V1, V2처럼 여러 에픽과 단계로 계속 세분화할 수 있다.
   5. 이 흐름은 Rovo가 직접 수행하는 기능이라기보다 Jira 자동화와 JCA를 조합하는 방식이며, AutoDev도 일부를 담당할 가능성이 언급됐다.

2. 실행 순서가 의존성을 반영해야 한다

   1. 기초 작업은 뒤의 기능 구현을 막지 않도록 먼저 처리되어야 한다.
   2. 첫 번째 파동이 기반을 만들면 다음 파동이 상위 기능을 구현하는 식으로 에이전트 작업을 연결할 수 있다.
   3. 사람은 각 파동의 요구사항, 결과, 다음 파동으로 넘길 조건을 확인해야 한다.

7. 행사 현장의 질문과 운영 맥락

제품의 가능성뿐 아니라 인터넷 장애와 계정 운영까지 워크숍의 실제 사용 조건을 드러냈다.

7.1. Wi-Fi 장애가 바꾼 진행 방식

1. 네트워크 장애가 데모를 질의응답으로 전환했다

   1. 발표자들은 Cloudflare 설정을 끄고 네트워크를 바꾸며 여러 장비에서 접속을 시도했다.
   2. 행사장 IT 담당자에게 해결을 요청하는 동안 화면 공유와 QR 코드가 반복해서 중단됐다.
   3. 참석자들은 Context Engine, 검증 요구사항, 모델 라우팅, 개발 환경을 질문했고, 발표자들은 제품 구조를 설명하며 시간을 채웠다.

2. Wi-Fi 농담은 에이전트 시스템의 운영 조건을 드러냈다

   1. 참석자가 “2026년의 위대한 미해결 문제”가 Wi-Fi라고 농담했고, AGI가 구해주기 전에 Wi-Fi가 먼저 해결될 것이라는 대화가 이어졌다.
   2. 트래픽을 찢고 최적화해야 한다는 농담이 이어지며, 네트워크와 실행 환경이 자율 시스템의 전제라는 점이 드러났다.
   3. 기술 스택이 아무리 자동화되어도 실제 배포·검증 환경의 연결성이 없으면 작업 흐름이 멈춘다.

7.2. 워크숍 계정과 보안 주의

1. 임시 계정으로 JCA를 체험한다

   1. 참석자는 1-ish-devo.atlassian.net 주소와 배포받은 번호를 사용해 접속하도록 안내됐다.
   2. 사용자 이름은 student와 번호를 조합하고, 행사 화면에 표시된 공통 비밀번호를 사용했다.
   3. 행사가 끝나면 계정을 초기화할 예정이므로 민감한 정보를 입력하지 않아도 된다고 안내했다.

2. 테스트 환경에서도 입력 데이터의 공개 범위를 제한한다

   1. 참가자는 공개 저장소에 올려도 괜찮은 수준의 내용만 입력해야 한다.
   2. 데모 계정이 안전해 보이더라도 조직의 비밀·고객 정보·실제 운영 자격 증명을 넣어서는 안 된다.

주요 발언 모음

“가장 큰 기회는 코드의 왼쪽과 오른쪽, 즉 계획·오케스트레이션·코드 리뷰·운영에 있다.” — Andy Wong

“진실은 코드 안에 있다.” — Andrei Bocan

“오래된 문서에는 그 결정이 왜 내려졌는지에 대한 중요한 역사적 맥락이 있다.” — Shane Wolf

“누구도 하루에 50개의 PR을 검토하는 데 시간을 쓰고 싶어 하지 않는다.” — Andrei Bocan

“검토 단계에서 일이 죽는다. 사람들은 다른 일로 바쁘기 때문이다.” — Andrei Bocan

“do the thing”처럼 한 줄만 적힌 작업 항목은 에이전트가 추측하지 않고 사람에게 요구사항을 되묻는다. — Andrei Bocan

“모노레포를 선택하는 일은 모노레포의 부채를 선택하는 것이고, 그것을 만들기 위한 도구를 만드는 데 많은 시간을 쓴다.” — Andrei Bocan

핵심 데이터·수치

• 약 15,000개 저장소: Atlassian 전체에서 코드 검색과 관계 파악이 어려워지는 규모다.
• 약 40% AI 리뷰 댓글 해결률: 사람이 실제 코드 변경으로 해결한 AI Reviewer 댓글의 비율이다.
• 약 45% 인간 기준선: 사람이 작성한 코드 리뷰 댓글의 해결률로 제시된 비교 기준이다.
• 주 3~5개 PR: AutoDev가 한 팀원에게 할당할 수 있는 작업 진행량의 예시다.
• 하루 50개 PR: 사람이 감당하고 싶어 하지 않는 검토량의 예시다.
• 10,000개 서비스: Rails 버전 마이그레이션처럼 조직 전체에 반복되는 대규모 자동화의 예시다.
• 10억 토큰: 한 사용자가 단일 작업에 과도하게 쓸 수 있는 비용·ROI 경고의 과장된 예시다.
• V0·V1·V2: 하나의 큰 에픽을 기초 작업과 단계별 에픽으로 나누는 실행 구조의 예시다.

결론 및 시사점

1. AI 개발의 병목을 코드 생성에서 흐름 조율로 옮겨야 한다: 계획·표준·리뷰·운영을 연결하지 않으면 코드 생성 속도가 빨라져도 전체 리드타임은 크게 줄지 않는다.
2. 조직 맥락이 장기적인 차별화 요소가 된다: 모델은 바뀔 수 있지만, 코드·업무·사람·문서·과거 결정의 관계를 검색하는 Context Engine은 여러 에이전트가 공유하는 기반이 될 수 있다.
3. 현재 코드와 과거 의도를 함께 검색해야 한다: 코드는 현재 동작의 기준이고, 오래된 문서는 왜 그렇게 결정했는지 알려주는 기억이므로 어느 하나를 버리면 잘못된 변경을 만들 가능성이 커진다.
4. 사람의 권위 부여와 검토는 자동화되지 않은 안전장치다: 충돌하는 정보와 모호한 Jira 항목을 에이전트가 임의로 확정하지 않도록 verified 상태와 인간의 요구사항 보완이 필요하다.
5. 검토 용량이 자동화 용량의 상한이다: AutoDev의 PR 수를 제한하고 작은 변경을 순차적으로 배포해야 에이전트가 만든 결과가 팀의 병목으로 되돌아오지 않는다.
6. 자율성에는 비용·환경·검증 정책이 따라야 한다: 작업별 비용 상한, 주간 비용 상한, Docker 샌드박스, 인수 조건 체크리스트, 브라우저 검증이 함께 있어야 한다.
7. Jira 에픽과 자동화 규칙은 에이전트 파이프라인의 골격이 될 수 있다: 에픽을 작은 작업과 파동으로 분해하고 각 작업에 JCA를 연결하면 기초 작업부터 V0·V1·V2까지 의존성을 반영한 실행이 가능하다.
8. AI 네이티브 SDLC는 팀이 직접 설계하는 운영 체계다: 표준, 맥락, 모델, 비용, 검토 방식은 조직마다 다르므로 하나의 범용 에이전트보다 팀의 제약과 목표에 맞춘 오케스트레이션이 중요하다.

핵심 요약 (20줄)

1. AI 코딩 도구가 늘어날수록 코드 생성만으로 얻는 생산성 향상은 둔화된다.
2. 다음 생산성 기회는 계획·오케스트레이션·리뷰·운영처럼 코드의 왼쪽과 오른쪽에 있다.
3. Teamwork Graph는 업무·코드·사람·의사결정의 관계를 공통 맥락으로 연결한다.
4. Jira Coding Agent는 Jira 티켓과 Confluence·Slack·이메일의 조직 지식을 함께 읽는다.
5. JCA는 계획·구현·검증과 풀 리퀘스트 관리를 Jira 클라우드 안에서 수행한다.
6. Jira 작업은 JCA뿐 아니라 Claude·Cursor·Codex 같은 외부 에이전트에도 할당할 수 있다.
7. AI Reviewer는 코드뿐 아니라 Jira·Confluence·SCM·Slack의 요구사항을 참고한다.
8. Atlassian은 낮은 가치의 리뷰 댓글을 걸러내 AI 리뷰의 노이즈를 줄인다.
9. AI Reviewer의 댓글 해결률은 약 40%로 인간 기준선 약 45%에 근접한다.
10. Standards는 자연어와 Markdown 규칙을 저장소별 또는 패턴별로 적용한다.
11. 자연어 표준을 결정적 CI 체크로 바꾸는 기능은 당시 기본 제공되지 않았다.
12. 약 15,000개 저장소를 다루려면 모노레포 대신 빠른 코드 검색과 관계 검색이 필요하다.
13. 현재 코드가 동작의 진실을 제공하고 과거 문서는 결정의 이유를 제공한다.
14. Context Engine은 충돌하는 자료의 권위를 인간이 검증하도록 설계된다.
15. JCA는 인수 조건 체크리스트와 Docker 샌드박스로 구현 결과를 검증한다.
16. 사용자가 자신의 샌드박스를 가져오는 기능과 세부 비용 귀속은 아직 제약으로 남아 있다.
17. AutoDev는 백로그에서 확신할 수 있는 작업을 골라 팀 검토용 PR을 만든다.
18. AutoDev는 주 3~5개 PR 같은 작업량 제한과 티켓·주간 비용 상한을 둔다.
19. do the thing처럼 모호한 백로그 항목은 사람이 요구사항을 보완한 뒤 에이전트가 처리한다.
20. AI 네이티브 SDLC의 핵심은 더 많은 코드를 만드는 일이 아니라 팀이 감당할 수 있는 맥락·변경·검토 흐름을 직접 설계하는 일이다.