본 기사의 위치— 본 기사는 awslabs/aidlc-workflows 리포지토리의 규범 규칙 및 이용 가이드를 소재로, 필자가 AI를 활용하여 읽어내고 정리한 해석입니다. AWS가 공식적으로 발표한 방법론이 아니며, 1차 자료의 번역이나 요약도 아닙니다.

시리즈— 본 기사는 AI로 풀어보는 AI-DLC v2 시리즈의 일부입니다.

참조한 버전— Claude Code 구현을 대상으로, 2026년 6월 시점의 v2.1.3 (커밋 c95070e, core/)을 참조하고 있습니다. Kiro·Codex 구현은 대상에서 제외되어 기술 내용이 다를 수 있습니다. OSS 구현은 업데이트가 계속되고 있으므로, 최신 상태는 공식 리포지토리를 확인해 주시기 바랍니다.

개요

학습 루프 (Learning Loop)는 워크플로우 중에 컨덕터 (Conductor)가 내린 판단을 기록해 두었다가, 그중 사람이 남기기로 결정한 것을 영구적인 규칙이나 센서 (Sensor)로 바꾸어 다음 워크플로우에 적용하는 메커니즘입니다. AI와 함께 개발하다 보면 "이 용어는 이런 의미로 사용해줘", "이 절차는 생략해도 돼"와 같은 수정을 반복해서 전달하게 되는 경우가 많습니다. 그러한 수정 사항은 대화가 끊기면 사라집니다. 학습 루프는 이러한 "수정의 일회성"을 멈추고, 한 번 바로잡은 것을 다음부터는 전제로 삼습니다.

중심에는 스테이지 완료와 승인 사이에 배치된 학습 게이트 (Learning Gate)가 있습니다. 컨덕터가 깨달은 점을 학습 로그 (Learning Log)에 기록하고, 게이트에서 사람이 남길 것을 선택하면, 확정된 학습 내용이 방법을 기록하는 파일에 저장됩니다. 본 기사에서는 무엇이 기록되고, 사람이 어떻게 선택하며, 확정된 학습이 어디에 어떻게 저장되어 다음에 어떻게 적용되는지를 풀어봅니다.

학습 루프란 무엇인가

AI 에이전트 (AI Agent)에게 작업을 맡기면, 사양의 모호함을 메우거나, 절차를 일부 생략하거나, 여러 선택지 중 하나를 고르는 등 그 상황에 맞는 판단이 쌓여가게 됩니다. 판단 그 자체는 피할 수 없습니다. 문제는 사람이 "그 부분은 이렇게 고쳐줘"라고 바로잡더라도, 그 수정 사항이 세션을 넘어가면 남지 않는다는 점입니다.

학습 루프는 이러한 수정을 영구적인 규칙으로 바꾸어 다음에 활용하는 메커니즘 전체를 가리킵니다. 원어는 learning loop이며, 소스 상의 정식 명칭은 Learnings Ritual입니다. 기록·선별·저장의 3단계로 구성되며, 선별 단계가 학습 게이트 (학습 루프 내의 유입구)에 해당합니다. 이하에서는 이 3단계를 순서대로 살펴보겠습니다.

에이전트에 의한 기록

컨덕터는 스테이지 작업 중에 내린 판단을 학습 로그 (memory.md)에 수시로 적어둡니다. 스테이지 시작 시 생성되어 작업 진행에 따라 추가되는 작업 메모입니다. 기록을 사람이 담당하면 비용이 발생하므로, 적어두는 것은 컨덕터에게 맡기고 무엇을 남길지만 사람이 판단합니다.

기록은 다음 4가지 카테고리로 나누어 남깁니다.

학습 로그는 컨덕터가 직접 작성하는 몇 안 되는 파일입니다. 상태나 감사 로그 (Audit Log)가 도구에 의해 자동으로 쌓이는 것과 달리, 이곳만큼은 컨덕터가 내용을 작성합니다. 누가 어떤 파일을 작성하는지에 대한 구분은 별도의 기사 「상태와 감사」에서 다룹니다.

학습 게이트 절차

각 스테이지의 작업이 끝나면, 승인 게이트 직전에 학습 게이트가 실행됩니다. 다음 순서로 진행됩니다.

• 후보 추출— 도구 (aidlc-learnings.ts surface)가 학습 로그를 읽고, Interpretations · Deviations · Tradeoffs의 각 엔트리를 후보로서 원문 그대로 제시합니다. Open questions는 미결된 조사 사항이므로 후보가 되지 않습니다. 많은 워크플로우에서는 남겨야 할 후보가 나오지 않는 것이 일반적입니다.
• 선택— 사람이 후보별로 남길지 버릴지를 선택하고, 필요하다면 문구를 수정합니다. 저장 범위 (후술하는 project / team)도 여기서 선택합니다.
• 모순 검사— 남기기로 결정한 규칙 후보에 대해, 컨덕터가 조직 규칙 (org.md)의 동일한 주제 섹션과 한 줄씩 대조합니다 (conflict-check). 모순이 있으면 해당 조직 규칙을 제시한 후, 사람이 다시 쓰기 · 철회하기 · 사람의 판단으로 밀어붙이기 (escalate) 중 하나를 선택합니다. 센서 후보는 대조 대상이 없으므로 이 검사를 거치지 않고 진행됩니다.
• 저장— 도구 (aidlc-learnings.ts persist)가 모순이 없는 후보를 저장합니다. 쓰기 작업은 모두 락 (Lock) 안에서 도구를 통해 수행되며, RULE_LEARNED

등의 감사 이벤트가 기록됩니다. 동일한 후보의 중복 쓰기는 자동으로 방지됩니다.

학습 게이트(Learning Gate)는 조언일 뿐, 승인 게이트(Approval Gate)를 멈추지는 않습니다. 후보가 나오지 않으면 그대로 승인으로 진행됩니다.

확정 학습의 저장소

확정된 학습은 practice로 취급됩니다. 방법을 기술하는 memory/project.md (또는 memory/team.md)의 주제 헤더(topic heading) 아래에, 한 줄의 practice로서 추가됩니다.

행의 형태는 - 본문 (learned YYYY-MM-DD)입니다. 주제 헤더는 내용에 맞춰 컨덕터(Conductor)가 분류합니다. 일반적인 시정 사항은 기본값인 ## Corrections, 테스트 방침이라면 ## Testing Posture, 금지 사항이라면 ## Forbidden입니다. 사람이 지정하는 것은 원래의 4가지 카테고리 중 하나일 뿐이며, 저장소의 헤더는 분류에 맡깁니다.

중요한 점은, 이 저장소가 규칙을 읽는 쪽과 동일한 파일이라는 점입니다. 학습을 쓰는 쪽과 다음 스테이지에서 규칙을 읽는 쪽이 분리되어 있지 않습니다. 따라서 학습은 그대로 다음 회차의 전제로 쌓여 올라갑니다.

저장 범위는 project와 team으로 나뉩니다.

• project — 이 프로젝트 내의 다음 회차 이후에만 적용됨 (memory/project.md)
• team — 프로젝트를 넘어 팀 전체에 적용됨 (memory/team.md)

후보는 모두 project에서 제안되며, 팀 전체로 확산하고 싶을 때만 team으로의 승격(promotion)을 선택할 수 있습니다. 특정 프로젝트의 배움이 의도치 않게 다른 프로젝트에 영향을 미치는 일은 없습니다. 조직(org)으로의 승격 경로는 없습니다.

규칙(Rule)과 센서(Sensor)로의 분류

확정된 학습은 다음 단계에 적용하는 방식에 따라 규칙과 센서로 나뉩니다.

• 규칙 (Rule) — "다음부터는 이렇게 판단해"라는 사전 지시. 앞서 언급한 practice로서 방법 파일에 쌓이며, 다음 스테이지 시작 시 컨덕터에게 읽혀집니다.
• 센서 (Sensor) — "다음부터는 이것을 충족하는지 확인해"라는 사후 검증. 결과물 저장 시 자동으로 실행되는 조언적인 체크로, 메커니즘 자체는 별도 기사 「센서」에서 다룹니다.

어느 쪽으로 활용할지는 컨덕터가 후보의 성질에 따라 제안하고, 사람이 확인한 후 결정합니다.

센서의 도입

학습을 센서로 만들 때, 스테이지 체크는 two-write install이라는 두 번의 쓰기를 통해 설치됩니다. 하나는 센서 본체로, project 범위의 매니페스트(manifest) aidlc-<id>.md를 새로 만듭니다. 이는 대상 결과물을 matches:의 글로브(glob, 파일명 패턴 지정/와일드카드)로 좁힙니다. 다른 하나는 연결 작업으로, 해당 센서의 id를 원래 기반이 된 스테이지의 sensors: 프론트매터(frontmatter) 목록에 추가합니다.

두 번의 쓰기는 동일한 락(Lock) 안에서 일괄적으로 수행되며, 감사 이벤트 SENSOR_PROPOSED가 기록됩니다. 설치된 센서는 다음 워크플로우의 컴파일(스테이지 정의나 규칙을 사전에 그래프로 고정하는 처리) 시에 묶이며, 그때부터 작동하기 시작합니다.

이때 스테이지 파일의 본문(## Steps 등)은 수정하지 않습니다. 늘어나는 것은 프론트매터의 도입 목록뿐입니다. 스테이지 본체를 불변(immutable)하게 유지하는 이유는 프레임워크의 업데이트와 현장의 추가 사항이 충돌하지 않도록 하기 위해서입니다. 동일한 스테이지가 많은 프로젝트에서 실행되므로, 본체를 건드리면 방법론이 각지에서 제각각으로 분기되어 버립니다.

다음 워크플로우로부터의 반영

학습은 설계상 "다음 워크플로우부터" 적용됩니다. 쓰기 자체는 학습 게이트에서 즉시 수행되지만, 반영은 다음 회차부터입니다. 규칙은 앞서 언급한 바와 같이 다음 스테이지 시작 시에 읽히며, 센서도 다음 컴파일부터 묶입니다.

실행 중인 워크플로우 중간에 규칙을 끼워 넣지 않는 이유는, 이미 승인된 스테이지의 전제가 무너져 버리기 때문입니다. "쓰기는 즉시, 반영은 다음 회차"라는 규율이 실행 중인 워크플로우의 안정성을 지탱합니다. 참고로, 규칙이 언제 읽히는지(사전 동봉된 규칙과 실행 측이 스스로 읽는 지식(knowledge)의 차이)는 별도 기사 「규칙과 지식」에서 다룹니다.

전체상

요약

학습 루프 (Learning Loop)는 기록·선별·저장의 3단계로 "한 번의 시정 (correction)"을 "다음의 전제 (premise)"로 바꿉니다. 컨덕터 (Conductor)가 학습 로그에 통찰 (insight)을 기록해 쌓아두고, 학습 게이트 (Learning Gate)에서 사람이 남길 것을 선택하며, 확정된 학습은 방법 파일의 practice 이거나 스테이지 (Stage)에 묶인 센서 (sensor)로서 저장됩니다. 저장 위치는 규칙을 읽는 측과 동일하므로, 배움은 그대로 쌓여갑니다. 그리고 반영은 항상 다음 워크플로우 (workflow)에서 시작되므로, 실행 중인 안건의 전제는 무너지지 않습니다.

참조원

관련 기사

이전 기사: 규칙과 지식

다음 기사: 상태와 감사

목차: AI로 풀어보는 AI-DLC v2

Discussion