The SDLC You Build Yourself — Andy Wong, Andrei Bocan & Shane Wolf, Atlassian

한 줄 핵심

Atlassian은 AI 에이전트를 코드 작성 전후의 전 과정을 연결해, 계획·리뷰·운영·자동화까지 아우르는 AI 중심 SDLC를 구현하는 방법을 보여준다.

시간별 요약

1. 0:00
   AI 중심 SDLC 소개 에이전트가 소프트웨어 개발 생애주기 전반을 바꾸고 있으며, Atlassian은 이를 오케스트레이션 중심의 새로운 개발 방식으로 보고 있다. 이번 워크숍은 지난 1년 반 동안 만든 도구들과 앞으로의 방향을 빠르게 훑는 데 초점을 둔다.
2. 1:38
   코드의 좌우를 함께 다루기 AI 도구의 생산성 향상은 점점 둔화되고 있고, 그 다음 기회는 코드 작성 자체보다 계획·오케스트레이션·리뷰·운영 같은 주변 업무에 있다. Atlassian은 그 영역을 중심으로 여러 에이전트와 그래프 기반 협업 구조를 만들고 있다.
3. 2:31
   Jira 코딩 에이전트와 조직 맥락 Jira coding agent는 Jira 티켓뿐 아니라 Confluence, 이메일, Slack까지 읽어 조직 맥락을 모으고, PR 작성과 수정까지 클라우드 안에서 처리하도록 설계되어 있다. 필요하면 Claude, Cursor, CodeX 같은 다른 에이전트에도 작업을 배정할 수 있고, 자동화 규칙도 연결된다.
4. 4:08
   AI 리뷰와 저장소 표준 AI reviewer는 PR의 버그를 찾고, 요구사항을 검증하고, 저장소별 표준을 적용해 일관성을 유지하는 역할을 한다. 리뷰는 코드만 보는 것이 아니라 Jira, Confluence, Slack 등에서 맥락을 끌어와 전체 요구를 기준으로 판단한다.
5. 5:42
   코드 리뷰의 잡음 줄이기 리뷰 코멘트 중에는 너무 사소하거나 가치가 낮은 잡음이 많기 때문에, 자체 모델로 이를 걸러내는 방식이 사용된다. 그 결과 인간의 코멘트 해결률이 상당히 개선되었고, 각 도구의 효과는 대시보드로 측정한다.
6. 6:49
   자율 개발과 사용 인사이트 AI autodev는 Jira 보드의 티켓 중 자율 처리가 가능한 작업을 골라 표준을 적용한 뒤 PR을 생성한다. 월별 크레딧, 사용자별 실행 수, 적용 저장소 범위를 제한할 수 있고, Slack 연동과 ROI 대시보드로 운영 상황을 추적한다.
7. 8:42
   AI SRE를 통한 장애 대응 AI SRE는 장애 발생 시 이전 인시던트와 문서, Slack 맥락을 모아 원인을 추정하고 복구 방법을 제안한다. 특히 새벽 시간대의 진단 부담을 줄이고, 영향 범위와 완화 절차를 빠르게 요약해 준다.
8. 9:36
   AI 컨텍스트 엔진 여러 저장소와 문서에 흩어진 정보를 표준화된 맥락으로 모아 에이전트가 더 효율적으로 일하도록 하는 것이 AI context engine의 핵심이다. Semantic code search를 통해 Jira, Confluence, 과거 인시던트, 외부 도구까지 연결하고, 브라우저·IDE·CLI에서 바로 쓰는 형태를 지향한다.
9. 11:13
   워크숍 설정과 네트워크 문제 해결 참가자에게 계정 번호와 로그인 정보를 배포하고 JCA 체험용 워크스페이스에 접속시키는 과정이 안내된다. 다만 현장 Wi-Fi 문제가 발생해 공유 화면, 접속 설정, QR 코드 배포를 오가며 복구를 시도한다.
10. 15:36
    네트워크 복구 중 질문 시간 네트워크를 복구하는 동안 제품 방향, 제공 기능, 워크플로우에 관한 질문을 받는다. 이 구간은 데모보다 Q&A에 가깝고, 참여자들이 실제로 무엇을 궁금해하는지 확인하는 시간이다.
11. 16:16
    연결된 맥락과 코드 검색 Atlassian의 그래프 데이터베이스는 Confluence, Jira, Bitbucket, Slack, Notion 등에서 들어오는 맥락을 연결해 한데 묶는다. 코드 검색은 문서보다 현재의 코드와 그에 이른 과거 결정을 더 신뢰할 수 있게 하여, 모노레포에 의존하지 않고도 필요한 정보를 끌어오게 한다.
12. 20:09
    충돌 처리, 최신 맥락, 인간의 권한 여러 출처에서 얻은 정보가 충돌할 때는 결국 인간이 무엇이 সত্য인지, 어떤 맥락에서만 참인지 판단해야 한다. 캐시를 오래 유지하면 오래된 정보가 될 위험이 커지므로, 최신 정보를 우선하되 검증된 콘텐츠를 인간이 표시하는 방식이 중요하다.
13. 25:01
    요구사항 검증과 샌드박스 Jira coding agent는 작업 항목의 수용 기준 체크리스트를 따라 코드가 요구사항을 만족하는지 검증한다. 전용 샌드박스에서 Docker 등을 사용해 설치·실행·브라우저 검증까지 수행할 수 있으며, 사용자는 자신의 API 키나 Atlassian credits 체계를 통해 모델을 쓸 수 있다.
14. 31:26
    모델 라우팅, 스킬, 하네스 현재는 모델을 자동으로 똑똑하게 라우팅하기보다 사용자가 직접 모델을 선택하는 방식에 가깝다. 하네스가 상위 실행 환경을 제공하고, 스킬과 서브에이전트가 작업별로 어떤 모델을 쓸지 정하는 구조이며, 더 나은 라우팅은 autodev에서 실험 중이다.
15. 35:07
    오래된 문서와 검증된 출처 오래된 문서는 검색 결과를 오염시킬 수 있지만, 실제로는 최근 결과를 우선하고 Confluence의 verified badge 같은 방식으로 신뢰도를 표시해 해결한다. 오래된 자료라도 당시의 결정을 이해하는 데는 가치가 있으므로, 완전한 삭제보다 출처 신뢰도 관리가 중요하다.
16. 36:42
    표준 만들기와 적용 데모 표준은 직접 생성해 이름, 설명, 규칙을 정의하고, 특정 저장소나 패턴에 맞춰 적용할 수 있다. 이후 coding agent가 PR을 검사해 표준 위반 여부를 코멘트로 남기므로, 수작업으로 일일이 강제하지 않아도 된다.
17. 39:08
    AutoDev와 백로그 작업 AutoDev의 목표는 백로그에서 자율 처리 가능한 일을 골라 PR을 만들고, 팀이 기능 개발에 더 많은 역량을 쓰게 만드는 것이다. 기존 코드베이스를 표준 준수 상태로 점진적으로 맞추는 작업도 염두에 두며, 너무 많은 PR이 한꺼번에 쏟아지지 않도록 점진적 진행을 강조한다.
18. 43:22
    비용 한도, 리뷰 용량, 인간 개입 자율 작업이 잘못된 일을 집어 들거나 과도한 비용을 쓰지 않도록, 티켓당·주당 비용과 WIP 한도를 둬야 한다. 설명이 부족한 백로그 항목은 먼저 사람이 맥락을 보강해야 하며, 리뷰 단계가 멈추지 않도록 Slack으로 적절한 시점에 사람을 호출하는 흐름이 중요하다.
19. 46:24
    실행 가능한 구현 계획 세우기 AI Planner는 아이디어가 현재 저장소에서 실현 가능한지 먼저 판단하고, 가능하다면 구현 계획과 필요한 작업 분해를 제시한다. 스파이크, PM, 매니저가 방향성을 미리 검증하고 싶을 때 특히 유용한 도구다.
20. 47:20
    코드와 역사적 결정 코드 검색은 15,000개가 넘는 저장소에서 어디에 변경을 넣어야 하는지, 어떤 서비스가 무엇을 쓰는지 같은 질문의 범위를 좁혀 답을 찾는다. 현재 코드뿐 아니라 과거의 설계 결정과 그 이유를 함께 보아야 같은 실수를 반복하지 않고 더 나은 변경 경로를 설계할 수 있다.
21. 51:31
    결정적 검사와 에픽 오케스트레이션 표준을 Markdown으로 관리하는 현재 방식은 체크박스처럼 결정적인 CI 검사와 바로 연결되지는 않는다. 다만 Jira epic을 더 작은 티켓으로 나누고, 그 결과를 바탕으로 자동화가 여러 단계의 작업을 순차적으로 오케스트레이션하는 방식은 이미 가능하거나 확장 가능하다.
22. 54:34
    세션 변경, 환경, 마무리 질문 JCA 세션은 IDE나 클라우드 환경과 분리되어 있어, 세션 안에서의 변경은 실시간 반영되지만 로컬 IDE 변경은 별도 인스턴스로 취급된다. 실행 환경은 Docker 기반이며, 최근에는 AI reviewer에서도 skills를 지원하기 시작해 워크플로우 확장성이 커지고 있다.

실무 인사이트

• 이 영상의 핵심은 개별 코딩 보조보다, 계획·리뷰·운영·자율 실행을 하나의 SDLC로 묶는 오케스트레이션 전략이다.
• 도입 우선순위는 코드 생성보다 맥락 수집과 검증에 있다. 최신 코드, 문서, Slack, 티켓을 연결해야 에이전트의 품질이 안정된다.
• 실무 적용 시에는 자율화 범위를 넓히기 전에 비용 한도, WIP 제한, 인간 승인 지점, 검증 가능한 표준부터 먼저 설계하는 것이 효과적이다.