자료가 바뀌어도, 판단의 출처는 잃지 않습니다

배우는 이유

정정·재수집·파일 이동이 일어나도 기존 판단의 근거를 다시 찾기 위해 배웁니다.

이 구간의 목표

문서 ID, 내용 버전, 수집 위치, 인용 위치를 분리하고 새 버전이 필요한 조건을 설명합니다.

3강에서 무엇을 한 건으로 기록할지 정했습니다. 이제 그 대상의 이름·위치·내용이 바뀌어도 같은 기록을 추적하는 방법을 배웁니다.

보고서의 웹 주소가 같아도 내용은 바뀔 수 있습니다. 반대로 파일 이름이나 저장 폴더만 바뀌고 내용은 그대로일 수 있습니다. URL 하나를 문서의 정체성과 버전으로 모두 쓰면 두 상황을 구분할 수 없습니다. 업무 대상을 가리키는 안정 ID와 그때 확보한 바이트의 버전을 나누어야 합니다.

이 실습은 같은 시험의 보고값이 28 mm에서 26 mm로 정정되는 합성 사례를 사용합니다. 숫자의 크기를 외우는 것이 목표가 아닙니다. 이전 판단이 어느 버전을 보았고 지금의 답이 어느 버전을 보았는지 추적하는 것이 목표입니다. 다른 문서에 같은 내용이 있어도 출처의 정체성까지 같다고 보지 않습니다.

이번에 만드는 결과는 문서 → 버전 → 인용 위치의 연결입니다. 원문을 보존하고 해시를 계산한 뒤, 답변에 문서 ID·버전·절 또는 행을 함께 붙입니다. 해시는 내용이 바뀌었는지 확인하는 도구이며, 보고서의 측정이 과학적으로 참이라는 증거는 아닙니다.

안정 ID · 원문 버전 · 근거의 핵심 개념

배우는 이유

실험 결과를 해석할 수 있도록 용어와 책임을 먼저 분리합니다.

이 구간의 목표

문서 ID, 내용 버전, 수집 위치, 인용 위치를 분리하고 새 버전이 필요한 조건을 설명합니다.

문서 ID

업무에서 같은 문서로 관리하기로 한 대상의 식별자입니다. URL이나 제목이 바뀌어도 동일성 근거가 유지되면 ID를 유지합니다. 자동으로 판단할 근거가 없으면 검토 대상으로 남깁니다.

원문 버전

특정 시점에 확보한 내용입니다. 같은 문서 ID 아래 내용 해시가 달라지면 새 버전을 추가합니다. 기존 버전을 덮어쓰면 이전 판단을 재현할 수 없습니다.

내용 해시

바이트로부터 계산한 지문입니다. 같은 바이트의 반복 수집을 감지할 수 있지만, 동일한 텍스트를 복사한 두 발행자의 문서를 같은 업무 문서로 합칠 근거는 아닙니다.

근거 위치

문서 버전에 속한 절·페이지·행과 실제 인용문입니다. 버전만 맞아도 인용문이 그 위치에 없으면 근거 검증이 끝나지 않았습니다.

같은 자료를 다시 받으면 무엇이 늘어날까요?

배우는 이유

같은 자료에서 조건 하나를 바꾸고 결과가 달라지는 이유를 확인합니다.

이 구간의 목표

반복 수집과 표기 정정에서 버전 수가 각각 어떻게 달라질지 먼저 예상해 보세요.

같은 자료를 다시 받으면 무엇이 늘어날까요?

서버가 고정된 보조 합성 문장의 SHA-256을 실제 계산합니다. 입력 선택에 따라 문서와 버전의 수, 인용 가능 여부가 달라집니다.

1. 동일 내용 재수집을 실행하고 버전 수를 확인합니다.
2. 정정과 다른 문서를 각각 선택해 ID와 해시가 맡는 역할을 비교합니다.
3. 인용 누락을 선택하고 내용 보존과 답변에 인용할 자격이 별개인지 확인합니다.

모바일에서는 준비된 조건별 Python 계산 결과를 비교합니다. 새로운 실행은 PC 실습에서 진행합니다.

결과에서 무엇을 읽어야 할까요?

배우는 이유

성공·거절·미확인의 의미를 구분하고 검증의 범위를 정확히 읽습니다.

이 구간의 목표

결과의 차이를 원인·근거·남은 확인사항으로 설명합니다.

설계 이유를 자신의 말로 설명합니다

배우는 이유

실습의 구조를 자신의 업무 질문과 설계 선택에 연결합니다.

이 구간의 목표

추천 구조·대안·실패 조건을 구분해 이유를 설명합니다.

어떤 구조를 선택할까요?

추천

문서 ID + 버전 해시 + 수집 위치 + 근거 위치를 별도 필드로 둡니다.

대안

수정되지 않는 단일 임시 메모라면 파일 경로만으로 시작할 수도 있습니다.

판단 기준

이력·감사·복수 출처가 필요한 순간부터 경로만으로는 부족합니다. 해시 생성보다 동일 문서로 볼 기준을 정하는 판단이 더 중요합니다.

규정 원문이나 시험 성적서의 개정에서도 주소와 제목이 유지될 수 있습니다. 답변에는 언제 수집한 어떤 버전인지 남겨야 변경의 영향을 추적할 수 있습니다.

다음 5강은 이 버전을 시간과 연결합니다. ‘최신 자료’와 ‘당시 알고 있던 자료’가 왜 다른 조회인지 확인합니다.

그때의 판단을, 그때 알던 정보로 되돌아봅니다

배우는 이유

늦게 도착한 정정이나 미래 적용 자료를 과거·현재 판단에 잘못 섞지 않기 위해 배웁니다.

이 구간의 목표

대상 시점과 기록 시점을 구분하고 SQLite에서 당시 알 수 있던 값을 조회합니다.

4강이 버전을 보존했다면, 5강은 어느 시점의 질문에 어떤 버전을 쓸지 정합니다.

9월 1일 시험을 9월 2일에 보고받았고 9월 6일에 정정본이 도착했다고 합시다. 9월 3일 담당자의 판단을 검토하는 질문에는 당시 알려진 28 mm가 필요합니다. 현재 같은 시험을 묻는 질문에는 정정된 26 mm가 필요합니다. 어느 쪽도 다른 쪽을 지우는 이유가 되지 않습니다.

시험이 일어난 시간과 시스템이 그 사실을 알게 된 시간은 다릅니다. 규정에서는 사건 시각 대신 효력 시작일과 종료일을 따져야 할 수도 있습니다. 이 두 시간 축을 분리하면 늦게 수집한 자료를 과거부터 알고 있었다고 잘못 해석하는 일을 막을 수 있습니다.

이번 실습은 요청마다 작은 메모리 SQLite 테이블을 만들고 매개변수 SQL로 조회합니다. 운영 DB를 만들거나 변경하지 않습니다. 시간 조회의 원리를 익히는 예제이며 모든 업무에 이벤트 소싱 전체를 도입하라는 뜻은 아닙니다. 정정 이력과 질문에 필요한 시간 축부터 정합니다.

기준 저장소 · 시간 · 이력의 핵심 개념

배우는 이유

실험 결과를 해석할 수 있도록 용어와 책임을 먼저 분리합니다.

이 구간의 목표

대상 시점과 기록 시점을 구분하고 SQLite에서 당시 알 수 있던 값을 조회합니다.

대상 시점

시험 발생일이나 규정 효력일처럼 업무 사실이 가리키는 시간입니다. 이 예제에서는 시험 시각 하나를 사용합니다. 규정의 유효 구간과 동일한 모델이라고 단정하지 않습니다.

기록 시점

해당 버전이 시스템에 등록되어 판단에 이용 가능해진 시간입니다. 나중에 받은 정정본의 기록 시각을 과거로 소급해서 바꾸지 않습니다.

as-of 조회

어느 대상 시점에 대해, 언제까지 알려진 자료를 사용할지 지정한 조회입니다. 현재 날짜로 무조건 최신 행 하나를 고르는 것과 다릅니다.

충돌과 누락

같은 우선순위에 서로 다른 값이 남으면 충돌입니다. 자료가 없는 경우는 미확인입니다. 둘 다 임의의 최신 행이나 0으로 해결하지 않습니다.

시간 축 두 개로 조회하기

배우는 이유

같은 자료에서 조건 하나를 바꾸고 결과가 달라지는 이유를 확인합니다.

이 구간의 목표

9월 3일 조회에서 아직 도착하지 않은 26 mm가 보이면 어떤 문제가 생길까요?

시간 축 두 개로 조회하기

같은 시험의 두 버전을 SQLite에 넣고, 대상 시점과 지식의 기준일을 각각 조건으로 사용합니다. 표에는 선택에서 제외된 행의 이유도 표시합니다.

1. 정상 이력에서 기준일을 수집 전·정정 전·정정 후로 바꿉니다.
2. 시험 전의 대상 시점을 골라 아직 발생하지 않은 결과가 섞이지 않는지 봅니다.
3. 상충 값을 추가하고, 나란한 기록 중 하나를 임의로 택하지 않는지 확인합니다.

모바일에서는 준비된 조건별 Python 계산 결과를 비교합니다. 새로운 실행은 PC 실습에서 진행합니다.

결과에서 무엇을 읽어야 할까요?

배우는 이유

성공·거절·미확인의 의미를 구분하고 검증의 범위를 정확히 읽습니다.

이 구간의 목표

결과의 차이를 원인·근거·남은 확인사항으로 설명합니다.

설계 이유를 자신의 말로 설명합니다

배우는 이유

실습의 구조를 자신의 업무 질문과 설계 선택에 연결합니다.

이 구간의 목표

추천 구조·대안·실패 조건을 구분해 이유를 설명합니다.

어떤 구조를 선택할까요?

추천

불변의 버전 행과 명시적인 시간 조건으로 시작합니다.

대안

상태 전이 전체를 재생해야 하는 요구가 생기면 이벤트 로그 설계를 추가할 수 있습니다.

판단 기준

모든 클릭을 이벤트로 보관하는 복잡성부터 늘리지 않습니다. 보존해야 할 사실과 시간 질문을 먼저 명시합니다.

가격 관측은 거래 시각과 수집 시각을, 규제 자료는 효력 시점과 확인 시점을 나눕니다. 시간대와 시간 정밀도도 입력 계약의 일부입니다.

다음 6강에서는 저장한 사실과 미확인 상태에 어떤 규칙을 적용할지 배웁니다. 이력 보존이 먼저 되어야 규칙 결과의 근거도 되짚을 수 있습니다.

용어의 뜻, 추론, 자료 검사를 구분합니다

배우는 이유

용어를 일관되게 쓰고, 기록이 없다는 이유로 거짓이나 비적용을 추론하는 실수를 막기 위해 배웁니다.

이 구간의 목표

개념 정의·개별 사실·추론 규칙·입력 제약을 나누고 unknown을 유지하는 규칙을 설명합니다.

3~5강에서 개체·관계·근거·시간을 준비했습니다. 이제 이 기록을 어떤 의미와 규칙으로 읽을지 명시합니다.

온톨로지는 업무 대상과 관계의 의미를 명시한 모델입니다. 그래프 모양의 화면이나 그래프 DB 자체를 뜻하지 않습니다. ‘시험이 문서에 보고된다’, ‘가설이 관측을 설명하려 한다’처럼 관계의 뜻을 공유하면 서로 다른 자료를 연결할 때 무엇을 합쳐도 되는지 판단할 수 있습니다.

어떤 조건이 적용되는지 기록이 없다고 해서 그 조건이 비적용인 것은 아닙니다. 적용됨·비적용·미확인이라는 업무 상태를 명시해야 규칙이 추측을 사실로 바꾸지 않습니다. 승인됨은 절차상의 상태이므로 적용 근거나 완료 증거를 대신할 수 없습니다.

RDF는 주어·관계·목적어로 사실을 표현하고, OWL은 개념과 관계의 논리적 의미를 다룹니다. SHACL은 데이터가 요구한 형태를 갖추었는지 검사하며, Datalog 같은 규칙 언어는 명시한 규칙으로 결과를 도출합니다. 이번 대시보드는 그 책임을 Python 함수로 보여줍니다. RDF/OWL/SHACL 엔진을 실행했다는 뜻은 아닙니다.

온톨로지 · 규칙 · 검증의 핵심 개념

배우는 이유

실험 결과를 해석할 수 있도록 용어와 책임을 먼저 분리합니다.

이 구간의 목표

개념 정의·개별 사실·추론 규칙·입력 제약을 나누고 unknown을 유지하는 규칙을 설명합니다.

TBox · 개념과 관계 정의

‘시험은 업무 대상의 한 종류’, ‘관측은 시험을 대상으로 한다’처럼 종류와 관계의 의미를 정합니다. 특정 시험 하나의 측정값은 여기에 넣지 않습니다.

ABox · 개별 사실

‘SYN-TEST-001은 시험’, ‘OBS-1은 이 시험에서 보고됨’ 같은 개체의 기록입니다. 각 사실의 출처·시점은 별도 연결이 필요합니다.

추론 규칙

이 교육 예제의 R1은 적용 상태가 미확인이면 검토 과제를 생성합니다. 규칙 이름·버전을 남기면 왜 그 과제가 생겼는지 설명할 수 있습니다. 실제 법적 적용 판단을 자동 확정하지 않습니다.

제약 검사와 열린 세계

정해진 필수 필드 누락은 입력 검사의 실패입니다. 한편 알지 못하는 사실은 거짓이라고 단정하지 않습니다. 업무에서 닫힌 목록을 쓸 경우도 그 범위와 가정을 명시해야 합니다.

승인이 unknown을 바꾸는지 실험하기

배우는 이유

같은 자료에서 조건 하나를 바꾸고 결과가 달라지는 이유를 확인합니다.

이 구간의 목표

승인을 ‘있음’으로 바꿨을 때 적용 미확인이나 완료 근거 누락이 사라질까요?

승인이 unknown을 바꾸는지 실험하기

적용 상태·완료 증거·승인을 독립적으로 바꿉니다. Python이 형식 검사, 검토 과제, 완료 근거 상태를 각각 반환합니다.

1. 미확인·근거 미확보에서 승인 유무만 바꾸어 봅니다.
2. 미확인과 필드 누락의 검사 결과가 다른 이유를 읽습니다.
3. 근거 있는 비적용을 선택하고, 누락에서 비적용을 추정한 경우와 구분합니다.

모바일에서는 준비된 조건별 Python 계산 결과를 비교합니다. 새로운 실행은 PC 실습에서 진행합니다.

결과에서 무엇을 읽어야 할까요?

배우는 이유

성공·거절·미확인의 의미를 구분하고 검증의 범위를 정확히 읽습니다.

이 구간의 목표

결과의 차이를 원인·근거·남은 확인사항으로 설명합니다.

설계 이유를 자신의 말로 설명합니다

배우는 이유

실습의 구조를 자신의 업무 질문과 설계 선택에 연결합니다.

이 구간의 목표

추천 구조·대안·실패 조건을 구분해 이유를 설명합니다.

어떤 구조를 선택할까요?

추천

개념사전·명시적인 상태·작은 버전 관리 규칙·실패 입력부터 만듭니다.

대안

표준 데이터 교환이나 복잡한 논리 추론이 실제로 필요하면 RDF/OWL 및 검증 엔진을 추가합니다.

판단 기준

온톨로지의 의미 설계는 엔진 설치 전에 가능합니다. 엔진 채택은 질의·교환·규칙 요구로 결정하며 모든 데이터를 즉시 그래프 DB로 옮기지 않습니다.

요구사항 관리에서는 적용 상태, 안전 검토에서는 근거 상태, 여행 일정에서는 예약 상태를 명시합니다. 기록이 없는 것을 승인·확정·완료로 보지 않는 원리가 같습니다.

다음 7강은 LLM이 이 구조에 맞는 후보를 내도록 요청하고, 반환 결과를 별도로 검사하는 방법입니다.

그럴듯한 응답을 검토 가능한 후보로 바꿉니다

배우는 이유

모델의 문장·JSON·자신감을 곧바로 업무 사실이나 실행 권한으로 사용하지 않기 위해 배웁니다.

이 구간의 목표

호출 실패·파싱 실패·형식 실패·근거 실패를 구분하고 후보까지만 만드는 경계를 설명합니다.

6강에서 검사할 상태와 규칙을 정했습니다. 이번에는 LLM의 응답이 그 계약을 지키는지 단계별로 확인합니다.

LLM은 보고서를 읽고 관측·가설·결정을 구조화하는 초안을 만들 수 있습니다. 그러나 JSON이 올바르게 생겼다는 것만으로 숫자와 출처가 맞는 것은 아닙니다. 호출이 성공했는지, JSON을 읽을 수 있는지, 필요한 필드가 있는지, 인용문이 실제 버전에 있는지 순서대로 확인해야 합니다.

사내 API와 앱 사이에는 provider adapter를 둡니다. 이 층은 인증·요청·응답의 차이를 앱 내부 계약으로 바꾸는 역할입니다. 모델이 어떤 회사 제품인지를 도메인 모델 전체가 알게 만들지 않습니다. 실제 사내 기능은 확인 전까지 unknown이며 이 실습의 모의 응답으로 지원 여부를 추정하지 않습니다.

이번 실습은 정상 JSON과 잘못된 JSON, 빈 결과, 시간 초과 같은 고정 응답을 선택해 검사합니다. 인터넷이나 LLM을 호출하지 않습니다. 흐름과 오류 처리를 실제 Python으로 확인하지만, 모델 추출 정확도·회사 인증·실제 API 성능은 이 검사로 평가할 수 없습니다.

LLM 추출 · API 연결 경계의 핵심 개념

배우는 이유

실험 결과를 해석할 수 있도록 용어와 책임을 먼저 분리합니다.

이 구간의 목표

호출 실패·파싱 실패·형식 실패·근거 실패를 구분하고 후보까지만 만드는 경계를 설명합니다.

호출 경계

HTTP 실패와 모델이 반환한 내용은 별개입니다. timeout은 모른다는 응답조차 받지 못한 상태이며, 자료에 사실이 없다는 증거가 아닙니다.

응답 스키마

필수 키·타입·허용 상태를 정합니다. approved나 command처럼 계약에 없는 필드가 들어오면 실행하지 않고 거절합니다.

Grounding · 근거 연결

응답의 버전과 인용문을 원문에 대조합니다. 형식은 맞아도 인용 숫자가 다르면 후보를 검토 대기 또는 거절로 남깁니다.

후보의 수명

검사를 통과한 결과도 CANDIDATE입니다. 권한 있는 검토·승인·게시와 구분하여 잘못된 추출이 바로 기준 기록이 되는 것을 막습니다.

어디에서 멈춰야 하는 응답일까요?

배우는 이유

같은 자료에서 조건 하나를 바꾸고 결과가 달라지는 이유를 확인합니다.

이 구간의 목표

형식이 맞지만 인용 값이 틀린 응답은 어느 단계에서 막혀야 할까요?

어디에서 멈춰야 하는 응답일까요?

합성 원문은 DOC-A/v2의 ‘패널 변형량 26 mm.’입니다. 선택한 모의 응답을 파싱·검사하고, 중단 지점과 원래 응답을 함께 표시합니다.

1. 정상 후보의 최종 상태가 승인 완료인지 확인합니다.
2. 깨진 JSON과 잘못된 인용을 비교하고 실패 단계의 차이를 봅니다.
3. 원문 지시와 시간 초과를 선택해 권한이나 빈 사실로 바뀌지 않는지 확인합니다.

모바일에서는 준비된 조건별 Python 계산 결과를 비교합니다. 새로운 실행은 PC 실습에서 진행합니다.

결과에서 무엇을 읽어야 할까요?

배우는 이유

성공·거절·미확인의 의미를 구분하고 검증의 범위를 정확히 읽습니다.

이 구간의 목표

결과의 차이를 원인·근거·남은 확인사항으로 설명합니다.

설계 이유를 자신의 말로 설명합니다

배우는 이유

실습의 구조를 자신의 업무 질문과 설계 선택에 연결합니다.

이 구간의 목표

추천 구조·대안·실패 조건을 구분해 이유를 설명합니다.

어떤 구조를 선택할까요?

추천

LLM에는 후보 추출을 맡기고 검증과 실행 권한은 앱이 관리합니다.

대안

명확한 표나 고정 형식 자료는 규칙 기반 파서로 먼저 읽을 수 있습니다.

판단 기준

모든 입력을 LLM에 보내는 편의와 오류·비용·보안 부담을 비교합니다. 이 단계의 mock 성공을 실제 모델 정확도로 보고하지 않습니다.

보고서, 규정 개정 안내, 콘텐츠 대본에서도 원문의 정보와 원문에 쓰인 명령은 분리합니다. 다른 사람의 문서가 앱의 실행 권한을 바꾸지 않습니다.

다음 8강은 검토한 구조화 기록을 읽기 좋은 Wiki로 투영하면서 원문과 수동 메모를 보존합니다.

다시 만들어도 잃지 않는 지식 화면을 설계합니다

배우는 이유

자동 요약을 재생성할 때 원문·근거·직접 작성한 메모를 잃지 않기 위해 배웁니다.

이 구간의 목표

원문·기준 DB·생성 Wiki·수동 메모의 책임을 나누고 입력 변경 후 재검토를 설명합니다.

7강에서 만든 후보를 검토했다면, 사람이 읽고 찾아갈 수 있는 페이지가 필요합니다. 기준 기록과 읽기 화면을 분리합니다.

Wiki는 자료를 읽기 좋은 이야기와 링크로 보여주는 창입니다. 사람이 읽는 문장에 모든 상태와 이력을 묻어 두면 어떤 필드가 바뀌었는지, 승인이 무엇을 대상으로 했는지 검사하기 어렵습니다. 기준 DB에 대상·관계·출처·상태를 두고 Wiki는 그 기록의 읽기용 투영으로 생성합니다.

투영이라는 말은 원본을 보존한 채 목적에 맞는 표현을 만든다는 뜻입니다. 같은 기록으로 Markdown 페이지와 검색 인덱스를 다시 만들 수 있습니다. 문장 생성이 실패해도 원문과 구조화 기록은 남아 있어야 합니다. 사람이 직접 적은 해석과 질문은 자동 생성 영역과 다른 경로에 둡니다.

이번 실습은 합성 기록을 Markdown 문자열로 렌더링하고 이전 화면과 비교합니다. 실제 파일 게시나 Obsidian 실행은 하지 않습니다. 페이지의 안정 ID, 근거 버전, 가설의 미검증 상태, 수동 메모 보존을 확인하는 최소 구현입니다. 정정본이 들어오면 예전 승인으로 새 문장을 확정하지 않습니다.

LLM Wiki · 읽기용 투영의 핵심 개념

배우는 이유

실험 결과를 해석할 수 있도록 용어와 책임을 먼저 분리합니다.

이 구간의 목표

원문·기준 DB·생성 Wiki·수동 메모의 책임을 나누고 입력 변경 후 재검토를 설명합니다.

기준 기록

현재 선택한 버전, 검토 상태, 관계를 구조화해 둔 데이터입니다. Wiki의 문장 자체를 다시 읽어 승인 여부를 추정하지 않습니다.

생성 Wiki

같은 입력에서 다시 만들 수 있는 Markdown입니다. 어떤 문서·버전에서 생성했는지 표시하고 관측과 가설을 다른 항목으로 씁니다.

수동 메모

사람의 질문·경험·검토 의견입니다. 자동 생성 대상에서 제외하며 연결이 필요하면 안정적인 페이지 ID를 참조합니다.

입력에 결속된 승인

v1 승인으로 v2 출력을 게시할 수 없습니다. 입력이 바뀌면 영향받는 후보와 페이지를 재검토하고 승인 버전을 갱신해야 합니다.

정정 후 Wiki를 다시 만들어 보기

배우는 이유

같은 자료에서 조건 하나를 바꾸고 결과가 달라지는 이유를 확인합니다.

이 구간의 목표

내용이 정정됐는데 승인 버전이 이전 그대로라면 새 페이지는 어떤 상태여야 할까요?

정정 후 Wiki를 다시 만들어 보기

기존 v1 페이지와 새 입력의 Markdown 미리보기를 나란히 표시합니다. 게시 가능 여부와 수동 메모 해시를 별도로 계산합니다.

1. 현재 버전의 화면과 안정적인 페이지 ID를 봅니다.
2. 정정 후 승인 전·후를 비교하고 미리보기와 게시 가능 상태를 구분합니다.
3. 수동 메모가 같은 해시인지, 가설 문구가 원인 확정으로 바뀌지 않는지 확인합니다.

모바일에서는 준비된 조건별 Python 계산 결과를 비교합니다. 새로운 실행은 PC 실습에서 진행합니다.

결과에서 무엇을 읽어야 할까요?

배우는 이유

성공·거절·미확인의 의미를 구분하고 검증의 범위를 정확히 읽습니다.

이 구간의 목표

결과의 차이를 원인·근거·남은 확인사항으로 설명합니다.

설계 이유를 자신의 말로 설명합니다

배우는 이유

실습의 구조를 자신의 업무 질문과 설계 선택에 연결합니다.

이 구간의 목표

추천 구조·대안·실패 조건을 구분해 이유를 설명합니다.

어떤 구조를 선택할까요?

추천

generated/와 manual/의 책임을 분리하고 페이지 ID·입력 버전·생성 시점을 남깁니다.

대안

한 파일을 같이 편집해야 한다면 관리 영역 표시와 충돌 검사를 설계할 수 있습니다.

판단 기준

관리 영역 방식은 병합 오류 위험이 커집니다. 우선 별도 보존이 쉬운 구조로 시작하고 필요한 편집 경험에 맞춰 확장합니다.

PPT나 보고서 초안도 승인된 데이터에서 다시 만들 수 있는 출력물입니다. 원본 표, 편집 의견, 자동 생성 본문을 분리하면 재생성 시 판단 근거를 잃지 않습니다.

다음 9강에서는 이런 기록과 페이지 중 질문에 필요한 근거를 찾는 검색 방법을 비교합니다.

질문에 필요한 근거를 찾는 방법부터 비교합니다

배우는 이유

찾기 쉬운 문서와 답변에 필요한 근거를 혼동하지 않고 검색 방식의 선택 이유를 배우기 위해 다룹니다.

이 구간의 목표

동일한 자료와 질문에서 ID·키워드·관계 검색의 결과를 비교하고 부족한 근거를 설명합니다.

8강에서 만든 Wiki가 읽기 화면이라면, 검색은 질문에 필요한 원문과 기록을 고르는 단계입니다.

RAG는 질문과 관련된 자료를 검색한 뒤 그 자료를 모델의 답변 맥락으로 제공하는 흐름입니다. 검색 단계에서 옛 버전이나 다른 시험을 가져오면 문장 생성이 매끄러워도 답은 틀릴 수 있습니다. 먼저 어떤 자료를 정답 근거로 볼지와 최신·과거의 기준을 정해야 합니다.

정확한 ID가 있는 질문은 ID 조회가 강합니다. 낯선 표현이나 별칭을 포함한 질문은 키워드 또는 임베딩 검색이 도움이 될 수 있습니다. ‘이 결정이 어느 보고서의 어떤 정정에 영향을 받나’ 같은 질문은 확인된 관계를 따라가는 방식이 유용합니다. 모든 질문을 그래프나 임베딩 하나로 해결할 필요는 없습니다.

이번 실습은 네 개의 작은 합성 문서에 같은 질문을 적용합니다. ID 포함 여부, 정해진 검색어의 일치 개수, 명시된 시험·문서 종류·현재 버전 관계를 실제 계산해 비교합니다. 임베딩 API나 그래프 DB를 실행하지 않으며, 작은 예제의 점수를 일반적인 검색 정확도로 확대하지 않습니다.

검색 · RAG · 그래프 사용 조건의 핵심 개념

배우는 이유

실험 결과를 해석할 수 있도록 용어와 책임을 먼저 분리합니다.

이 구간의 목표

동일한 자료와 질문에서 ID·키워드·관계 검색의 결과를 비교하고 부족한 근거를 설명합니다.

검색 대상과 정답표

검색 코퍼스에는 원문과 공개된 메타데이터만 넣습니다. 어떤 문서가 정답인지 적힌 평가표는 검색 입력에서 제외해야 평가 누출을 피할 수 있습니다.

정확 ID 조회

SYN-TEST-001처럼 식별자가 명시되면 관련 문서를 빠짐없이 찾기 쉽습니다. 질문에 ID가 없으면 별칭 해소 등 추가 단계가 필요합니다.

키워드 검색

문구가 겹치는 문서를 찾습니다. 표현이 달라 누락되거나, 같은 단어를 쓰는 다른 대상이 함께 검색될 수 있습니다. 실제 결과에서 그 이유를 확인합니다.

관계 기반 검색

확인된 관계와 버전 정보를 따라갑니다. 없는 관계를 모델이 추측해 경로로 추가하면 검색 근거가 조작될 수 있으므로 관계의 출처도 관리합니다.

같은 질문을 세 방법으로 찾아보기

배우는 이유

같은 자료에서 조건 하나를 바꾸고 결과가 달라지는 이유를 확인합니다.

이 구간의 목표

현재 값만 묻는 질문에 D1과 D4도 함께 나오면 답변 단계에 어떤 처리가 더 필요할까요?

같은 질문을 세 방법으로 찾아보기

D1은 시험 T1의 v1, D2는 T1의 정정 v2, D3는 T1의 검토 결정, D4는 다른 시험 T2의 보고서입니다. 필요한 근거 수와 실제 검색 결과를 함께 봅니다.

1. 현재 값 질문을 세 방법으로 실행하고 D2 외 자료가 나오는 이유를 봅니다.
2. 복합 질문을 실행하고 보고서와 회의록이 모두 필요한지 확인합니다.
3. 원인 입증 질문에서 자료를 찾았다는 것과 입증 근거를 찾았다는 것을 구분합니다.

모바일에서는 준비된 조건별 Python 계산 결과를 비교합니다. 새로운 실행은 PC 실습에서 진행합니다.

결과에서 무엇을 읽어야 할까요?

배우는 이유

성공·거절·미확인의 의미를 구분하고 검증의 범위를 정확히 읽습니다.

이 구간의 목표

결과의 차이를 원인·근거·남은 확인사항으로 설명합니다.

설계 이유를 자신의 말로 설명합니다

배우는 이유

실습의 구조를 자신의 업무 질문과 설계 선택에 연결합니다.

이 구간의 목표

추천 구조·대안·실패 조건을 구분해 이유를 설명합니다.

어떤 구조를 선택할까요?

추천

ID·키워드 조회를 기준선으로 만들고 실패 질문이 요구하는 관계·의미 검색을 추가합니다.

대안

표현 변형이 많으면 임베딩 검색을, 다단계 연결이 핵심이면 관계 질의를 평가합니다.

판단 기준

같은 질문·같은 자료·같은 근거 기준으로 비교해야 복잡성 증가가 실제 개선인지 판단할 수 있습니다.

규정 변경 영향 분석은 개정 조항과 관련 판단의 연결이 중요하고, 일반 자료 탐색은 제목·키워드가 유효할 수 있습니다. 질문의 구조가 도구 선택을 이끕니다.

다음 10강에서는 찾은 자료를 바탕으로 실제 변경을 허용할 조건과 중복 실행 방지를 다룹니다.

허용된 변경을 한 번만 실행합니다

배우는 이유

검토되지 않은 입력의 실행과 재시도로 인한 중복 효과를 막기 위해 배웁니다.

이 구간의 목표

검증·승인·실행을 나누고 입력 버전에 묶인 승인과 멱등성 키의 의미를 설명합니다.

앞 강의는 기록과 답변을 만들었습니다. 이제 시스템이 게시 같은 변경을 수행할 때 지켜야 할 조건을 다룹니다.

실행 하네스는 모델이나 사용자가 제안한 작업을 실제 효과로 바꾸기 전에 범위·권한·상태·재시도를 검사하는 장치입니다. 프롬프트에 조심하라고 쓰는 것만으로 구현되지 않습니다. 실제 시스템에서는 인증된 주체와 허용 경로를 코드와 운영 환경이 강제해야 합니다.

승인은 구체적인 대상과 입력 버전에 결속되어야 합니다. v1 초안의 게시를 승인한 뒤 내용이 v2로 바뀌었다면 이전 승인을 그대로 사용할 수 없습니다. 요청 본문에 reviewer라고 적는 것과 인증된 검토자임을 확인하는 것도 다릅니다. 이번 실험의 역할은 미리 정해진 교육용 시나리오입니다.

네트워크 응답을 놓치면 사용자는 같은 버튼을 다시 누를 수 있습니다. 그때 게시가 두 번 발생하지 않도록 요청 키와 입력 해시, 실행 결과를 함께 저장합니다. 이 실습은 메모리 SQLite에 효과를 기록하며 외부 게시를 하지 않습니다. 실제 외부 서비스에서는 상대 시스템의 멱등성 지원과 트랜잭션 경계까지 검토해야 합니다.

실행 하네스 · 승인 · 멱등성의 핵심 개념

배우는 이유

실험 결과를 해석할 수 있도록 용어와 책임을 먼저 분리합니다.

이 구간의 목표

검증·승인·실행을 나누고 입력 버전에 묶인 승인과 멱등성 키의 의미를 설명합니다.

검증

입력 구조와 근거가 조건을 충족하는지 확인합니다. 입력이 유효하다는 사실은 그 작업을 허가했다는 뜻이 아닙니다.

승인

권한 있는 주체가 특정 대상·버전·범위의 실행을 허가한 기록입니다. 만료·취소·입력 변경 조건을 명시합니다.

멱등성 키

같은 작업 요청의 재전송을 식별합니다. 같은 키와 같은 입력은 이전 결과를 돌려주고, 같은 키에 다른 입력은 충돌로 거절합니다.

실행 원장

실제로 반영된 효과와 요청의 연결입니다. 로그에 시작했다고 적힌 것만으로 완료로 처리하지 않으며 결과와 함께 보존합니다.

같은 게시 요청을 두 번 보내보기

배우는 이유

같은 자료에서 조건 하나를 바꾸고 결과가 달라지는 이유를 확인합니다.

이 구간의 목표

같은 키를 재사용했지만 두 번째 입력이 바뀌면 이전 성공을 반환해도 될까요?

같은 게시 요청을 두 번 보내보기

한 번의 실험 안에서 두 요청을 순서대로 처리합니다. SQLite의 UNIQUE 키와 입력 해시 비교로 신규 효과·재사용·충돌을 구분합니다.

1. 첫 실행과 재시도의 효과 수가 왜 모두 한 건인지 봅니다.
2. 키 충돌에서 기존 원장과 효과가 보존되는지 확인합니다.
3. 오래된 승인·승인 없음·자가 승인을 선택해 효과가 0인지 비교합니다.

모바일에서는 준비된 조건별 Python 계산 결과를 비교합니다. 새로운 실행은 PC 실습에서 진행합니다.

결과에서 무엇을 읽어야 할까요?

배우는 이유

성공·거절·미확인의 의미를 구분하고 검증의 범위를 정확히 읽습니다.

이 구간의 목표

결과의 차이를 원인·근거·남은 확인사항으로 설명합니다.

설계 이유를 자신의 말로 설명합니다

배우는 이유

실습의 구조를 자신의 업무 질문과 설계 선택에 연결합니다.

이 구간의 목표

추천 구조·대안·실패 조건을 구분해 이유를 설명합니다.

어떤 구조를 선택할까요?

추천

입력 버전·작업 범위에 결속된 승인과 UNIQUE 멱등성 키를 둡니다.

대안

외부 시스템이 요청 키를 지원하지 않으면 대사·outbox·보상 절차를 추가 검토합니다.

판단 기준

로컬 DB 트랜잭션만으로 임의의 외부 효과를 exactly-once로 보장할 수 없습니다. 외부 경계의 실패를 별도로 설계해야 합니다.

PPT 배포, 예약 신청, 메일 발송도 중복되면 비용이나 혼란이 생깁니다. 입력과 승인의 관계, 이미 실행된 효과를 확인하는 원리가 같습니다.

다음 11강에서는 효과를 기록한 직후 앱이 멈춘 상황에서 어떻게 재개하는지 살펴봅니다.

멈춘 위치보다, 실제 반영된 일을 먼저 확인합니다

배우는 이유

재시작이 이미 끝난 일을 중복 실행하거나 바뀐 입력을 이어서 처리하지 않도록 배우는 강의입니다.

이 구간의 목표

업무 지식·실행 원장·체크포인트·개발 기억을 나누고 안전하게 재개할 조건을 설명합니다.

10강에서 한 번의 효과를 원장에 연결했습니다. 이제 원장과 진행 표시가 어긋나는 중단 상황을 다룹니다.

긴 작업은 중간에 멈출 수 있습니다. 프로그램이 ‘다음은 J1’이라는 체크포인트를 저장한 뒤 실제 J1을 완료하고, 새 체크포인트를 쓰기 전에 중단될 수 있습니다. 재시작 때 진행 표시만 읽으면 이미 끝난 J1을 다시 실행하게 됩니다. 효과의 근거가 무엇인지 먼저 정해야 합니다.

실행 원장은 어떤 작업이 실제로 반영됐는지 기록합니다. 체크포인트는 빠르게 재개하기 위한 위치 힌트입니다. 개발 기억은 이후 작업에 도움이 되는 설계 판단과 실패 경험입니다. 업무 지식은 보고서와 관측처럼 업무 대상을 설명합니다. 이 네 종류를 하나의 메모로 합치면 권한과 보존·갱신 규칙이 흐려집니다.

이번 실습은 J1~J3이라는 고정 작업과 모의 원장으로 재개 계획을 계산합니다. 기존 Memory Harness나 보호된 메모리 저장소에는 접근하지 않습니다. 실제 프로세스를 강제 종료하거나 디스크 내구성을 시험한 것이 아니라, 중단 경계별 입력을 주었을 때 복구 판단이 맞는지 확인하는 시뮬레이션입니다.

실행 기억 · 중단 · 복구의 핵심 개념

배우는 이유

실험 결과를 해석할 수 있도록 용어와 책임을 먼저 분리합니다.

이 구간의 목표

업무 지식·실행 원장·체크포인트·개발 기억을 나누고 안전하게 재개할 조건을 설명합니다.

업무 지식

보고된 사실·근거·가설·결정과 변경 이력입니다. 실행이 어디까지 갔는지와 다른 질문에 답합니다.

실행 원장

완료 효과를 작업 ID·입력 해시와 연결한 기록입니다. 재개 시 이미 반영된 작업을 제외하는 기준으로 사용합니다.

체크포인트

마지막으로 저장한 진행 위치입니다. 원장보다 늦을 수 있으므로 그 위치를 곧 완료의 권위로 삼지 않습니다.

개발 기억

왜 이 구조를 선택했고 어떤 실패 조건을 발견했는지 남깁니다. 재사용할 경험이며 원문·효과 기록의 대체물이 아닙니다.

중단 시점을 바꾸며 재개 계획 비교하기

배우는 이유

같은 자료에서 조건 하나를 바꾸고 결과가 달라지는 이유를 확인합니다.

이 구간의 목표

원장에는 J1 완료, 체크포인트에는 J1 대기라면 어느 기록을 기준으로 삼을까요?

중단 시점을 바꾸며 재개 계획 비교하기

J1 수집 → J2 후보 검토 → J3 모의 게시를 가정합니다. 원장과 체크포인트를 화면에 함께 표시하고 남은 작업만 계산합니다.

1. 반영 전·후 중단의 재개 시작 작업을 비교합니다.
2. 입력이 바뀌었을 때 이전 체크포인트를 그대로 사용하지 않는지 확인합니다.
3. 원장 이상 사례에서 자동 삭제·추측 복구 대신 검토가 필요한지 읽습니다.

모바일에서는 준비된 조건별 Python 계산 결과를 비교합니다. 새로운 실행은 PC 실습에서 진행합니다.

결과에서 무엇을 읽어야 할까요?

배우는 이유

성공·거절·미확인의 의미를 구분하고 검증의 범위를 정확히 읽습니다.

이 구간의 목표

결과의 차이를 원인·근거·남은 확인사항으로 설명합니다.

설계 이유를 자신의 말로 설명합니다

배우는 이유

실습의 구조를 자신의 업무 질문과 설계 선택에 연결합니다.

이 구간의 목표

추천 구조·대안·실패 조건을 구분해 이유를 설명합니다.

어떤 구조를 선택할까요?

추천

입력 지문 확인 → 원장 검증 → 완료 작업 제외 → 남은 작업 재개 순서를 둡니다.

대안

모든 작업을 처음부터 반복해도 안전한 순수 계산이라면 재계산이 더 단순할 수 있습니다.

판단 기준

비용이 크거나 외부 효과가 있는 작업에서만 복구 상태의 복잡성이 정당화됩니다. 체크포인트가 있다고 내구성까지 증명된 것은 아닙니다.

자료 수집·보고서 생성·대량 파일 처리에서도 완료 표시보다 실제 산출물과 원장의 일치를 확인해야 합니다. 개인 개발 메모는 이 검증을 대신하지 않습니다.

다음 12강은 이러한 실패 사례를 매번 같은 기대 결과로 검사하는 평가 하네스를 만듭니다.

성공 예시보다, 실패를 막는 기준을 반복합니다

배우는 이유

매번 그럴듯한 결과만 확인하는 대신 중요한 실패가 재발하지 않는지 검증하기 위해 배웁니다.

이 구간의 목표

Skill의 절차와 실행 권한을 구분하고 고정 사례의 기대·실제 결과를 여러 평가 축으로 읽습니다.

이제 여러 실패 조건을 알고 있습니다. 이를 재사용 가능한 작업 절차와 고정된 평가로 묶습니다.

Skill은 작업 방법·입력·출력·검사를 재사용할 수 있도록 정리한 절차입니다. 문서에 ‘원문을 바꿔도 된다’고 쓰여 있다고 실제 허용 권한이 생기지는 않습니다. 입력 문서와 Skill 본문, 사용자 요청, 시스템 정책의 역할을 구분해야 절차가 권한을 몰래 확대하지 않습니다.

평가 하네스는 고정된 입력에 대해 기대 결과와 실제 결과를 비교합니다. 정상 자료 한 건이 잘 처리되는 것만으로는 정정·충돌·시간 초과·중복 실행을 다뤘다고 할 수 없습니다. 이번 과정에서 반복한 12개 실패 가족을 같은 기준으로 검사하고 어떤 축이 실패했는지 표시합니다.

모든 항목을 unknown으로 답하면 함부로 확정하는 오류는 줄지만 업무에 필요한 결과도 제공하지 못합니다. 반대로 모든 요청을 통과시키면 편리해 보여도 근거와 권한이 무너집니다. 안전성과 유용성을 분리해서 비교해야 하나의 종합 점수가 중요한 실패를 가리지 않습니다.

Skill · 평가 하네스의 핵심 개념

배우는 이유

실험 결과를 해석할 수 있도록 용어와 책임을 먼저 분리합니다.

이 구간의 목표

Skill의 절차와 실행 권한을 구분하고 고정 사례의 기대·실제 결과를 여러 평가 축으로 읽습니다.

재사용 절차

언제 쓰고 무엇을 입력받아 어떤 산출물을 검증할지 명시합니다. 이 수업의 Skill 예시는 프로젝트 내부 읽기 자료이며 전역 설치나 권한 변경을 하지 않습니다.

고정 기대 결과

검사 전에 기대 결과를 정합니다. 실패 후 통과시키려고 정답표를 실제 출력에 맞춰 바꾸면 회귀를 발견할 수 없습니다.

평가 누출

정답과 해설을 검색 코퍼스나 모델 입력에 섞으면 외운 답을 정확한 추출처럼 평가할 수 있습니다. 입력 자료와 기대 결과를 분리합니다.

여러 평가 축

근거·상태, 변경·중복, 권한·복구를 따로 읽습니다. 통과율이 높아도 원문 덮어쓰기 같은 핵심 실패는 별도로 차단해야 합니다.

세 가지 처리 전략을 같은 기준으로 평가하기

배우는 이유

같은 자료에서 조건 하나를 바꾸고 결과가 달라지는 이유를 확인합니다.

이 구간의 목표

무조건 통과와 무조건 미확인 전략은 서로 어떤 실패를 일으킬까요?

세 가지 처리 전략을 같은 기준으로 평가하기

실제 교육용 함수의 결과와 두 의도적으로 부족한 전략을 비교합니다. 각 행에서 기대 값·실제 값·일치 여부를 확인합니다.

1. 세 전략을 실행하고 통과 개수보다 실패 행의 의미를 읽습니다.
2. 정정·승인·중단 재개의 기대 결과가 왜 고정되어야 하는지 설명해 봅니다.
3. 자신의 업무에서 가장 큰 손실을 만드는 실패 하나를 Codex 대화에서 골라 봅니다.

모바일에서는 준비된 조건별 Python 계산 결과를 비교합니다. 새로운 실행은 PC 실습에서 진행합니다.

결과에서 무엇을 읽어야 할까요?

배우는 이유

성공·거절·미확인의 의미를 구분하고 검증의 범위를 정확히 읽습니다.

이 구간의 목표

결과의 차이를 원인·근거·남은 확인사항으로 설명합니다.

설계 이유를 자신의 말로 설명합니다

배우는 이유

실습의 구조를 자신의 업무 질문과 설계 선택에 연결합니다.

이 구간의 목표

추천 구조·대안·실패 조건을 구분해 이유를 설명합니다.

어떤 구조를 선택할까요?

추천

작은 고정 실패 세트와 축별 결과를 먼저 운영합니다.

대안

자료가 늘면 별도 검증용 질문과 모델 평가를 추가하고 운영 사례를 회귀 입력으로 축적합니다.

판단 기준

처음부터 거대한 평가 플랫폼을 만들기보다 가장 중요한 실패가 실제로 잡히는지 확인합니다. 정답을 검색에 넣어 통과율을 높이지 않습니다.

콘텐츠 제작에서는 입력 변경 후 구승인 사용을, 시험 데이터에서는 단위·출처 누락을, 업무 자동화에서는 중복 효과를 고정 실패 사례로 삼을 수 있습니다.

다음 13강에서는 로컬에서 검증한 설계를 회사 환경에 옮길 때 아직 모르는 기능과 정책을 구분합니다.

회사 API의 실제 기능에 맞춰 경계를 옮깁니다

배우는 이유

회사 API의 기능·인증·자료 정책을 추정하지 않고 적용 가능한 설계를 만들기 위해 배웁니다.

이 구간의 목표

지원·미지원·미확인을 구분한 기능표와 데이터 이동 경계를 설명하고 적절한 대안을 선택합니다.

로컬 실습에서 데이터와 실패 조건을 확인했습니다. 이제 어떤 부분이 환경 독립적이고 무엇을 회사에서 새로 확인해야 하는지 나눕니다.

Codex가 코드를 작성할 수 있다는 것과 회사 시스템이 런타임에 그 기능을 사용할 수 있다는 것은 다릅니다. 회사 API가 텍스트 생성만 제공한다면 도구 호출이나 구조화 출력은 앱이 별도로 관리해야 합니다. 개발 도구의 편의 기능을 제품의 가용 기능으로 가정하면 배포 후 설계가 성립하지 않을 수 있습니다.

모델 이름보다 먼저 확인할 항목은 입력 자료의 이동 가능 범위, 인증 방식, 저장·로그 정책, 텍스트·구조화 출력·임베딩·도구·이미지 지원 여부입니다. 알려지지 않은 기능을 false로 적으면 사용할 대안을 지나치게 제한하고, true로 적으면 실행할 수 없는 흐름을 만들게 됩니다.

이번 실험의 제공자 프로필은 모두 보조 합성 가정입니다. 실제 내부 주소나 토큰이 필요하지 않습니다. 프로필과 자료 종류를 바꾸면 어떤 흐름을 계획할 수 있는지 계산하되 실제 서비스에는 연결하지 않습니다. 회사 승인은 이 화면의 선택값으로 만들어지지 않습니다.

사내 환경 이식 설계의 핵심 개념

배우는 이유

실험 결과를 해석할 수 있도록 용어와 책임을 먼저 분리합니다.

이 구간의 목표

지원·미지원·미확인을 구분한 기능표와 데이터 이동 경계를 설명하고 적절한 대안을 선택합니다.

기능 프로필

텍스트·구조화 출력·임베딩·도구 실행을 true/false/unknown으로 기록합니다. 각 값에는 실제 문서나 시험 결과가 근거로 필요합니다.

자료 경계

공개·합성·사내 자료가 어떤 환경으로 이동 가능한지 정합니다. 모델 기능이 충분해도 자료 정책이 금지하면 그 경로를 사용할 수 없습니다.

어댑터와 앱의 책임

인증·요청 포맷은 어댑터가, 의미·근거 검증·승인·실행 원장은 앱이 관리합니다. 특정 API 이름을 도메인 기록 전체에 퍼뜨리지 않습니다.

대안과 검증 잔여

구조화 출력이 없으면 텍스트 응답을 엄격히 파싱하고 제한 재시도할 수 있습니다. 임베딩이 없으면 ID·키워드 검색으로 시작합니다. 실제 품질은 새로 평가합니다.

기능이 줄어들어도 유지할 설계 찾기

배우는 이유

같은 자료에서 조건 하나를 바꾸고 결과가 달라지는 이유를 확인합니다.

이 구간의 목표

텍스트만 지원하는 API에서도 버전·근거·승인·Wiki 분리를 유지할 수 있을까요?

기능이 줄어들어도 유지할 설계 찾기

가상 프로필의 기능표와 자료 경계를 대조합니다. 출력은 실행 가능성에 대한 교육용 계획이며 실제 연결 성공이 아닙니다.

1. 기능 미확인과 텍스트 전용을 비교하고 unknown과 false의 차이를 봅니다.
2. 사내 자료와 외부 제공자를 조합했을 때 계획이 막히는 이유를 읽습니다.
3. 오프라인에서 가능한 자료 관리와 불가능한 모델 추출을 나누어 봅니다.

모바일에서는 준비된 조건별 Python 계산 결과를 비교합니다. 새로운 실행은 PC 실습에서 진행합니다.

결과에서 무엇을 읽어야 할까요?

배우는 이유

성공·거절·미확인의 의미를 구분하고 검증의 범위를 정확히 읽습니다.

이 구간의 목표

결과의 차이를 원인·근거·남은 확인사항으로 설명합니다.

설계 이유를 자신의 말로 설명합니다

배우는 이유

실습의 구조를 자신의 업무 질문과 설계 선택에 연결합니다.

이 구간의 목표

추천 구조·대안·실패 조건을 구분해 이유를 설명합니다.

어떤 구조를 선택할까요?

추천

환경 독립적인 핵심 기록과 검증을 유지하고 제공자별 차이를 작은 어댑터에 모읍니다.

대안

회사 플랫폼이 이미 제공하는 승인된 검색·저장 서비스를 사용할 수도 있습니다.

판단 기준

사용 가능한 플랫폼을 확인한 후 중복 구현을 줄입니다. 알 수 없는 기능 때문에 검증되지 않은 외부 연결을 자동 대안으로 사용하지 않습니다.

실제 도입 문서에는 기능값 옆에 확인 근거와 미확인 항목을 함께 둡니다. 문자 수를 토큰 수로 간주하거나 특정 인증 규격을 이름만으로 추정하지 않습니다.

마지막 14강에서는 수집부터 정정·재승인·복구까지 한 흐름으로 묶고 어떤 설계 선택을 설명할 수 있게 되었는지 확인합니다.

자료가 바뀌고 작업이 멈춰도 근거를 이어갑니다

배우는 이유

부분 기능의 성공을 전체 신뢰로 착각하지 않고 시스템의 책임과 한계를 스스로 설명하기 위해 배웁니다.

이 구간의 목표

수집→후보→검증→승인→Wiki→정정→복구를 추적하고 핵심 설계 선택 세 가지를 근거와 함께 설명합니다.

앞의 개념을 하나의 합성 업무 흐름으로 연결합니다. 각 기능이 왜 필요한지 실패 지점에서 다시 확인합니다.

완성된 시스템은 보고서를 요약하는 순간보다 자료가 정정되고 승인이 오래되고 작업이 중단되는 순간에 설계의 차이가 드러납니다. 마지막 실습은 같은 합성 시험을 사용해 각 경계에서 무엇을 보존하고 무엇을 막아야 하는지 한 화면에서 연결합니다. 숫자가 바뀌어도 원인 가설은 여전히 미검증일 수 있습니다.

먼저 원문의 지문과 버전을 만들고 모의 추출 후보의 형식·근거를 확인합니다. 해당 입력의 검토 승인이 있어야 Wiki를 게시할 수 있습니다. 정정 후에는 이전 승인이 새 내용까지 허가하지 않으며, 게시 효과를 이미 기록했다면 재시작 때 같은 효과를 다시 만들지 않습니다.

통합 실습의 성공은 교육용 구현이 지정한 실패 조건을 처리했다는 뜻입니다. 실제 계측 타당성, 법적 적용 판단, 사내 인증, 외부 모델 성능, 운영 장애 복구까지 검증한 것은 아닙니다. 강의 완료 역시 버튼 하나로 표시하지 않습니다. 구조를 선택한 이유와 아직 남은 검증을 자신의 말로 설명하는 것이 학습 결과입니다.

통합 실습 · 설계 되설명의 핵심 개념

배우는 이유

실험 결과를 해석할 수 있도록 용어와 책임을 먼저 분리합니다.

이 구간의 목표

수집→후보→검증→승인→Wiki→정정→복구를 추적하고 핵심 설계 선택 세 가지를 근거와 함께 설명합니다.

근거의 연결

최종 문장에서 원문 버전과 인용 위치까지 거슬러 올라갈 수 있어야 합니다. 중간의 후보·승인·실행도 동일한 입력을 참조해야 합니다.

변경 영향

정정은 보고값뿐 아니라 그 값에 의존한 후보·승인·Wiki를 재검토하게 합니다. 관련 없는 수동 메모를 자동으로 지우지는 않습니다.

효과와 복구

작업이 멈춘 위치보다 실제로 반영된 효과를 확인합니다. 같은 요청의 재전송은 원장의 결과를 재사용합니다.

설계 되설명

무엇을 왜 나눴고 어떤 대안이 있었으며 어떤 조건에서 실패하는지 설명합니다. 코드 실행 성공과 사용자의 이해는 별도로 기록합니다.

자료의 일생을 한 번에 따라가기

배우는 이유

같은 자료에서 조건 하나를 바꾸고 결과가 달라지는 이유를 확인합니다.

이 구간의 목표

정정본 수신 후 오래된 승인으로 게시를 시도하면 어느 단계에서 멈춰야 할까요?

자료의 일생을 한 번에 따라가기

같은 버전·추출·승인·Wiki·멱등성 함수를 연결합니다. 메모리 SQLite와 문자열 출력만 사용하며 실제 외부 게시나 운영 DB 변경은 없습니다.

1. 정상 흐름의 각 단계와 Wiki의 인용 버전을 확인합니다.
2. 정정 후 재승인 전·후를 비교하고 실패 단계 아래가 실행되지 않는지 봅니다.
3. 중단 후 재시도에서 요청 수와 효과 수가 다른 이유를 설명합니다.

모바일에서는 준비된 조건별 Python 계산 결과를 비교합니다. 새로운 실행은 PC 실습에서 진행합니다.

결과에서 무엇을 읽어야 할까요?

배우는 이유

성공·거절·미확인의 의미를 구분하고 검증의 범위를 정확히 읽습니다.

이 구간의 목표

결과의 차이를 원인·근거·남은 확인사항으로 설명합니다.

설계 이유를 자신의 말로 설명합니다

배우는 이유

실습의 구조를 자신의 업무 질문과 설계 선택에 연결합니다.

이 구간의 목표

추천 구조·대안·실패 조건을 구분해 이유를 설명합니다.

어떤 구조를 선택할까요?

추천

ADR 1: 원문·기준 기록·생성 Wiki·수동 메모를 분리합니다. ADR 2: LLM은 근거 있는 후보까지 담당합니다. ADR 3: 승인·효과·복구를 입력 버전에 결속합니다.

대안

관계 질의·공유 규모·실시간 요구가 커지면 별도 검색 엔진이나 그래프 저장소, 작업 큐를 검토합니다.

판단 기준

도구의 이름보다 필요한 질문과 실패 비용을 먼저 설명합니다. 현재 최소 구조로 해결되지 않는 구체적인 요구가 있을 때 확장합니다.

본 강의를 듣기 전에 묻고 싶은 질문 10개: ① 개체 동일성은 누가 판단하나 ② 원문 버전은 어떻게 보존하나 ③ 인용 위치가 사라지면 어떻게 하나 ④ 시간과 정정을 어떻게 조회하나 ⑤ unknown과 비적용을 어떻게 구분하나 ⑥ 추출 후보의 검토 주체는 누구인가 ⑦ 검색 정답은 어떻게 평가하나 ⑧ 승인은 어떤 입력에 묶이나 ⑨ 중단 후 효과는 어떻게 대사하나 ⑩ 회사 API에서 실제 확인해야 할 기능은 무엇인가.

여기까지 준비된 화면은 14강이며 이해 완료 표시는 별개입니다. 막힌 개념은 해당 강의로 돌아가 조건을 바꾸어 보고, Codex와 한 질문씩 이유를 확인합니다. 다음 기술을 더하기 전에 자신의 업무 질문 하나에 이 구조를 적용해 설명하는 것이 마무리 과제입니다.