코딩 에이전트를 위한 컨텍스트 엔지니어링

컨텍스트 엔지니어링은 코딩 에이전트가 작업을 수행하기 전에 무엇을 참조할지 결정하는 작업입니다. 성능이 뛰어난 모델이라도 사용자가 입력하는 데이터만큼의 결과를 제공하기 때문에 컨텍스트 엔지니어링은 출력 품질에 가장 큰 영향을 미치는 요소입니다.

Jira에서는 에이전트에게 필요한 컨텍스트가 이미 업무에 포함되어 있습니다. 업무 항목은 목표 및 수용 기준을 포함하고 있으며 Teamwork Graph는 업무 항목을 코드, 결정 사항 및 관련 문서와 연결하므로, 에이전트는 빈 프롬프트 대신 실제 의도를 기반으로 작업을 수행합니다. 이 컨텍스트는 한 컴퓨터 내 로컬 파일에만 갇혀 있지 않고 팀 전체에서 공유합니다.

이 가이드에서는 컨텍스트 엔지니어링의 개념, 컨텍스트 창이 코딩 에이전트의 실질적인 제약 조건인 이유 및 프롬프트마다 일일이 입력하지 않아도 에이전트가 필요한 정보를 얻을 수 있도록 Jira에서 컨텍스트를 엔지니어링하는 방법을 알아봅니다. 실제로는 이미 진행 중인 작업에 몇 가지 조치를 하면 됩니다.

• 에이전트에게 단순한 프롬프트가 아닌 목표를 제공합니다. Jira 업무 항목을 사양으로 작성하고 에이전트를 평가하는 기준이 되는 수용 기준을 포함합니다.

• 그래프를 통해 주변 컨텍스트를 제공합니다. 업무 항목을 프롬프트의 시작점으로 사용하면 Teamwork Graph가 작업과 관련된 문서, 결정 사항 및 관련 컨텍스트로 확장합니다.

• 표준을 공유하고 최신 상태로 유지합니다. 규칙은 Confluence에 상주하므로 모든 에이전트 및 팀 동료가 동일한 소스에서 정보를 가져옵니다.

• 모든 에이전트에게 동일한 컨텍스트 계층을 제공합니다. 동일한 조직 컨텍스트가 Claude Code, Cursor, Codex, GitHub Copilot, Jira Coding Agent와 같은 모든 코딩 에이전트에게 적용됩니다.

컨텍스트 엔지니어링이란 무엇입니까?

컨텍스트 엔지니어링은 코딩 에이전트가 올바르게 작업하는 데 필요한 정보를 갖출 수 있도록 각 단계에서 모델이 어떤 정보를 참조할지 의도적으로 결정하는 작업입니다. 이 정보는 프롬프트 이상을 의미하며, 여기에는 코드베이스, 표준, 종속성, Git 기록, 도구 정의, 목표 및 수용 기준이 포함됩니다. 각 작업에 맞춰 이러한 정보 집합을 선별하는 것이 새로운 업무입니다.

프롬프트 엔지니어링은 사용자가 직접 정보를 선별하여 단일 지시 사항에 입력하는 것을 의미합니다. 컨텍스트 엔지니어링은 여러 단계로 된 작업에서 에이전트에게 필요한 정보(예: 입력, 검색, 요약 및 제외되는 내용)를 시스템에서 제공하여 에이전트가 필요에 따라 나머지 정보를 찾을 수 있도록 하는 것을 의미합니다.

컨텍스트가 많다고 해서 반드시 더 좋은 컨텍스트는 아니라는 점에 유의해야 합니다.

• 고신호 컨텍스트는 현재 진행 중인 작업에 실제로 도움이 되는 정보입니다

• 저신호 컨텍스트는 오래되거나 주제와 관련이 없거나 중복되지만 여전히 모델이 읽어야 하는 콘텐츠입니다

컨텍스트 창이 저신호 토큰으로 채워지면 모델이 변경되지 않았는데도 답변이 느려지고 정확도가 떨어집니다. 이 품질 저하를 컨텍스트 부패라고 합니다. 즉, 컨텍스트 창이 오래되거나 모순되거나 저신호 토큰으로 채워져 출력 품질이 점차 저하되는 것입니다. 효과적인 컨텍스트 엔지니어링에서는 적절한 컨텍스트를 추가하는 것만큼이나 오래된 컨텍스트를 제거하는 것도 중요합니다.

왜 컨텍스트 창이 코딩 에이전트의 제약 조건입니까?

코딩 모델은 컨텍스트 창에 포함되는 내용만 추론할 수 있는데, 컨텍스트 창은 코드베이스, 문서 및 팀의 기록에 비해 작습니다. 규칙, 아키텍처 또는 작업의 배경이 되는 결정 사항을 컨텍스트 창에 포함하지 않으면 성능이 뛰어난 에이전트라도 잘못되거나 안전하지 않은 코드를 제공하게 됩니다.

에이전트에게 컨텍스트 수집을 맡기면 다음과 같은 몇 가지 실패 모드가 반복해서 나타납니다.

• 새로운 저신호 토큰이 유입되면 초기에 내린 결정이 컨텍스트 창 밖으로 밀려나기 때문에 긴 작업에서 에이전트가 방향을 잃습니다.

• 에이전트가 정보를 과도하게 검색하여 실제로 사용하는 것보다 훨씬 많은 정보를 컨텍스트 창으로 가져와 토큰 예산을 노이즈에 낭비합니다.

• 에이전트는 사용자가 입력하지 않은 표준을 전혀 알지 못하므로 나머지 팀원들이 따르는 패턴을 어기는 코드를 제공합니다.

• 에이전트가 단독으로는 잘 작동하지만 나머지 팀원 또는 다른 에이전트가 같은 영역에서 무엇을 하고 있는지는 알지 못합니다.

대신 적절한 컨텍스트에 쉽게 액세스할 수 있도록 하면 에이전트가 작업을 진행하면서 필요한 정보를 스스로 발견할 수 있으므로, 모든 규칙과 결정을 일일이 수동으로 명시할 필요 없이 프롬프트를 높은 수준으로 유지할 수 있습니다.

Jira에서 코딩 에이전트를 위한 컨텍스트를 어떻게 엔지니어링합니까?

Jira에서는 업무 자체가 컨텍스트가 됩니다. 의도는 업무 항목에 상주하고 주변 참조 자료는 Teamwork Graph를 통해 연결되며 지속 가능한 표준 및 결정 사항은 Confluence 및 Loom에서 가져오므로, 모든 에이전트 및 팀 동료가 동일한 소스에서 정보를 얻습니다. Jira는 단일 컴퓨터 내 로컬 파일을 넘어 목표, 진행 중인 결정 및 논의 사항, 업무 전반의 기록까지 확장됩니다. 모든 정보가 지속적으로 공유되어, 에이전트가 작업에 활용하는 컨텍스트는 팀 전체에서 구조화되고 최신 상태를 유지하며 일관되게 적용됩니다.

컨텍스트 엔지니어링은 다음 세 가지 원칙을 기반으로 합니다.

1. 적합한 정보 선택

2. 체계적으로 유지

3. 지속적으로 유지

1. 선택 및 검색: 업무 항목을 사양으로 작성

'선택'은 작업에 필요한 최소한의 고신호 컨텍스트 집합을 고르는 것이며, '검색'은 모든 정보를 미리 컨텍스트 창에 채우는 대신 필요할 때 적절한 팩트 정보를 가져오는 것입니다. Jira에서는 두 경우 모두 업무 항목에서 시작합니다.

• Jira에서 작동하는 방식: 목표를 설명에 입력하고 수용 기준을 체크리스트에 추가합니다. 그러면 에이전트가 읽을 수 있는 구조로 의도 및 평가 기준이 제공됩니다. 그런 다음, 업무 항목을 연결된 에이전트에게 할당합니다. 에이전트는 전체 코드베이스가 아니라 업무 항목 및 연결된 컨텍스트에서 시작합니다. 에이전트와 스파링하며 사양을 구체화하는 것도 업무의 일부입니다. 에이전트는 방대한 데이터를 빠르게 읽고 사용자가 작업을 시작하기 전에 공백을 찾도록 도와줍니다.

• 제공 예정: Jira 플래너는 아이디어를 이미 컨텍스트가 포함되어 있고 에이전트가 바로 사용할 수 있는 계획 및 업무 항목으로 전환합니다. 대기 목록에 등록하세요.

2. 공유 컨텍스트: 업무를 붙여넣지 않고 연결

구조와 형식이 중요합니다. 에이전트가 쉽게 탐색할 수 있도록 컨텍스트를 구성하고 복사하기보다는 연결된 상태로 유지하세요. Teamwork Graph는 매번 수동으로 조합할 필요 없이 주변 컨텍스트를 사용할 수 있도록 도와줍니다.

• Jira에서 작동하는 방식: 업무 항목을 관련 업무 항목, 코드 및 사양, RFC 또는 결정 기록이 포함된 Confluence 페이지에 연결합니다. 에이전트는 단순히 티켓 텍스트뿐만 아니라 작업과 관련된 컨텍스트도 상속받습니다. Loom 안내 동영상도 마찬가지입니다. 버그 재현 또는 디자인 근거 관련 동영상의 대화 기록 및 요약이 그래프에 연결되므로, 팀 동료에게 설명했을 내용이 에이전트가 읽을 수 있는 컨텍스트가 됩니다. 따라서 별도의 벡터 저장소를 구축하고 유지 관리하지 않아도 실제 업무에서 '정확히 검색된 팩트' 정보를 제공합니다.

3. 지속성: 표준 및 결정 사항을 축적되는 곳에 유지

지속성(또는 메모리)은 에이전트가 매번 처음부터 시작하지 않도록 세션 간에 지속 가능한 팩트 정보를 계속 사용할 수 있는 상태로 유지하는 것입니다. 고려해야 할 세 가지 요소는 에이전트가 작업 중에 보유하는 정보, 작업 간에 유지해야 하는 정보 및 필요할 때 조회할 수 있는 정보입니다.

• Jira에서 작동하는 방식: 규칙, 아키텍처 결정 및 선호하는 패턴은 공유 Confluence 스페이스에 상주하므로, 전체 팀 및 모든 에이전트가 아무도 볼 수 없는 개인의 컴퓨터에 저장된 복사본이 아니라 그래프를 통해 동일한 소스에서 정보를 가져옵니다. 시스템을 통해 작업이 진행될수록 그래프가 더욱 풍부해지므로 다음 에이전트가 활용할 수 있는 정보도 더 늘어납니다. 개발자가 추가로 수동 단계를 처리할 필요 없이 업무가 진행되면서 컨텍스트가 축적됩니다.

팀 전반에서 업무가 원활하게 진행되도록 돕는 두 가지 요소는 모든 에이전트가 사용할 수 있는 하나의 컨텍스트 계층과 그 컨텍스트의 안정성 및 권한을 유지하는 거버넌스입니다.

모든 에이전트를 위한 하나의 컨텍스트 계층

엔지니어링한 컨텍스트는 모든 도구에서 사용할 수 있어야만 가치가 있습니다. 각 에이전트에게 표준을 다시 가르치는 것은 컨텍스트 부패가 다시 발생하는 가장 빠른 방법입니다.

• Jira에서 작동하는 방식: 두 가지 경로를 통해 모든 코딩 에이전트에 동일한 조직 컨텍스트를 제공합니다. Teamwork Graph CLI는 코딩 에이전트가 터미널에서 해당 컨텍스트 및 도구에 직접 액세스할 수 있도록 합니다. 한 번만 설정하면 에이전트가 작업하면서 그래프를 쿼리할 수 있습니다. Atlassian Rovo MCP 서버는 Claude, Cursor, Codex 및 GitHub Copilot과 같은 MCP 클라이언트에 동일한 기능을 제공합니다. Teamwork Graph는 어떤 방식으로든 컨텍스트를 제공하며, 업무 항목, 결정, 문서 및 코드를 하나의 쿼리 가능한 계층으로 연결합니다. 컨텍스트를 한 번 엔지니어링한 후 작업을 수행하는 모든 모델에서 사용합니다.

거버넌스: 컨텍스트의 안정성 및 권한을 유지

컨텍스트는 최신 상태이고 에이전트에게 볼 권한이 허용된 경우에만 유용합니다. 거버넌스는 더 많은 에이전트가 공유된 계층을 활용해도 신뢰성을 유지하도록 돕습니다.

• Jira에서 작동하는 방식: 에이전트는 기본적으로 팀이 이미 사용하고 있는 동일한 권한을 상속받으므로 자신의 소유자가 볼 수 있는 데이터만 볼 수 있으며 에이전트 전용 규칙을 통해 범위를 추가로 세분화할 수 있습니다. 액세스, 승인 및 감사가 함께 작동하는 방식을 알아보려면 Jira의 에이전트 기반 엔지니어링 가드레일 및 안전을 참조하세요.

Jira는 나머지 컨텍스트 스택과 어떻게 통합됩니까?

현재 코딩 에이전트가 참조하는 컨텍스트의 대부분은 단일 컴퓨터에 집중되어 있습니다. 즉, 열려 있는 리포지토리, 몇 개의 로컬 파일 및 개발자가 프롬프트에 입력한 내용 정도입니다. 이 방식은 단독으로 사용되는 경우 유용하지만 정보가 개인별로 분산되어 있는 경우 잊히기 쉽습니다. Jira 및 Teamwork Graph는 중요한 컨텍스트를 최신 상태를 유지하며 관리 가능한 하나의 공유 계층으로 가져와 전체 팀 및 에이전트가 활용할 수 있도록 합니다.

이 중 어느 것도 코딩 에이전트, IDE 또는 로컬 구성을 대체하지 않습니다. 이 도구는 여전히 리포지토리별 상세 코드와 실제 코드를 처리합니다. Jira는 최상단에 있는 공유 계층이므로, 모든 도구가 활용하는 컨텍스트는 구조화되고 최신 상태로 유지되며 팀 전체에 걸쳐 일관됩니다.

Jira에서 첫 에이전트에게 실제 컨텍스트를 제공하는 방법

컨텍스트 엔지니어링의 궁극적인 목적은 에이전트가 필요한 정보를 스스로 찾을 수 있도록 도구 및 정보를 제공하는 것입니다. Jira 및 Teamwork Graph는 에이전트가 MCP 또는 CLI를 통해 접근하는 공유 컨텍스트 계층이므로, 이 계층을 정확하고 연결된 상태로 유지하는 것이 중요합니다.

잘 구성된 업무 항목 하나로 시작하여 추측하는 에이전트와 의도를 기반으로 작업하는 에이전트의 차이를 확인해 보세요.

1. 에이전트에게 평가할 기준을 제시합니다. 자체 포함 리팩터링이나 소규모 버그 수정처럼 실행 취소가 쉬운 범위가 명확하고 위험도가 낮은 하나의 작업을 선택하여 설명에 목표를 작성하고 체크리스트에 수용 기준을 추가합니다.

2. 컨텍스트를 붙여넣는 대신 에이전트가 상속하도록 합니다. 브랜치, 커밋 또는 풀리퀘스트에서 업무 항목 키를 참조하여 업무 항목을 코드에 연결하고 그 배경이 되는 문서 또는 결정 사항을 연결합니다. 에이전트는 단순히 티켓 텍스트뿐만 아니라 작업과 연결된 컨텍스트도 활용합니다.

3. 공유 표준을 지정합니다. 따라야 할 규칙을 Confluence 페이지에 연결하여 다음 에이전트 및 팀 동료가 동일한 소스를 사용할 수 있도록 합니다.

4. 에이전트에게 할당합니다. 에이전트는 전체 코드베이스 또는 빈 프롬프트보다 집중도가 높은 시작점인 업무 항목 및 연결된 컨텍스트에서 시작합니다.

5. 처음 제공한 기준에 따라 검토합니다. 업무 항목에 작성한 수용 기준을 기반으로 풀리퀘스트를 검사하여 에이전트에게 제시한 원래 기준에 따라 산출물을 평가합니다.

6. 에이전트가 작업을 마무리하게 합니다. 마지막에 세션 요약, 주요 결정 및 절충안, 연결된 풀리퀘스트를 포함하여 업무 항목을 업데이트하도록 프롬프트를 입력하여 다음 팀 동료 또는 에이전트가 Teamwork Graph를 통해 중단된 부분부터 이어서 작업할 수 있도록 합니다.

이 방식으로 몇 개의 업무 항목을 실행하면 업무가 진행됨에 따라 그래프가 채워집니다. 각 에이전트는 업무 항목에 요약, 주요 결정 사항 및 연결된 풀리퀘스트를 남기므로 다음 에이전트는 이전보다 더 풍부한 정보를 기반으로 작업을 시작합니다. 이것이 바로 실행마다 초기화되지 않고 누적되는 컨텍스트 엔지니어링입니다.

컨텍스트 엔지니어링에 대해 자주 묻는 질문

컨텍스트 엔지니어링과 프롬프트 엔지니어링의 차이점은 무엇입니까?

프롬프트 엔지니어링은 단일 프롬프트를 위해 관련 정보를 수동으로 선별하는 분야입니다. 컨텍스트 엔지니어링은 검색, 구조, 메모리 및 목표 자체를 포함하여 여러 단계로 구성된 작업 전반에서 에이전트에게 정보를 제공하는 시스템을 구현하는 분야로, 에이전트가 필요에 따라 온디맨드로 세부 정보를 표시하게 합니다.

AI 코딩 에이전트는 Jira에서 어떻게 컨텍스트를 가져옵니까?

에이전트는 업무 항목, 설명, 수용 기준 및 관련 업무, 문서 및 코드를 연결하는 Teamwork Graph에서 컨텍스트를 가져와서 빈 프롬프트가 아니라 실제 의도를 기반으로 작업합니다.

코딩 에이전트는 왜 훌륭한 프롬프트를 사용해도 잘못된 코드를 생성합니까?

하나의 프롬프트로는 규칙, 아키텍처 또는 작업의 배경이 되는 결정 사항을 포함하지 못합니다. 대부분의 에이전트 오류는 모델 오류가 아닌 컨텍스트 오류이며, 표현을 다듬는 것보다 더 정확한 컨텍스트를 제공하는 것이 문제를 더 효과적으로 해결합니다.

에이전트가 이미 내 리포지토리를 읽고 있는 경우에도 여전히 컨텍스트 엔지니어링이 필요합니까?

예. 에이전트는 리포지토리를 통해 코드가 무엇인지 알 수 있지만 왜 그렇게 만들었는지, 어떤 표준을 따라야 하는지 또는 팀 전체에서 어떤 일이 진행되고 있는지는 알 수 없습니다. 나머지 정보는 컨텍스트 엔지니어링이 제공합니다.

컨텍스트 부패란 무엇입니까?

컨텍스트 부패란 컨텍스트 창이 오래되거나 모순되거나 저신호 토큰으로 채워져 에이전트의 출력 품질이 점차 저하되는 것입니다. 모델이 변경되지 않았는데 답변이 느려지고 정확도가 떨어집니다.