01 · 프롬프트 밖의 정보도 결과를 바꾼다
모델은 요청 문장 외에도 읽은 파일, 도구 설명, 검색 결과, 직전 오류와 대화 기록을 바탕으로 다음 행동을 고릅니다. 이를 모두 포함한 작업 정보가 컨텍스트입니다. 필요한 파일이 빠지면 추측이 생기고, 오래된 결정이 섞이면 이미 바뀐 요구사항으로 작업할 수 있습니다.
Anthropic의 컨텍스트 엔지니어링 글은 컨텍스트를 유한한 자원으로 보고 필요한 정보를 선별하는 접근을 설명합니다. 긴 작업에는 요약, 외부 기록, 별도 작업자의 역할도 다룹니다. 아래의 기록 양식은 그 개념을 학생 프로젝트와 운영 자동화 학습에 적용한 제안입니다.
02 · 정보에는 출처와 상태를 붙인다
“서버가 느리다”라는 문장은 관찰인지 추측인지 알기 어렵습니다. “테스트 환경에서 /records 응답이 세 번 모두 2초를 넘었다”는 관찰이고, “목록 쿼리가 원인일 수 있다”는 가설입니다. 둘을 나누어 적고 확인 명령이나 파일 위치를 함께 둡니다.
작업 노트는 목표, 확인 사실, 미확인 가설, 결정, 다음 행동 다섯 부분이면 시작할 수 있습니다. 요구가 바뀌면 이전 결정에 폐기 표시를 하고 새 결정의 이유를 남깁니다. 마지막 문장만 짧게 요약하면 변경 경위가 사라져 같은 결정을 다시 논의하게 될 수 있습니다.
03 · 전체 저장소 대신 질문에 맞춰 읽기
로그인 오류를 수정한다면 진입 경로, 인증 설정, 관련 핸들러와 재현 결과부터 살펴봅니다. 무관한 이미지 폴더와 전체 로그를 한꺼번에 넣을 필요는 없습니다. 탐색 단계에서 파일 이름과 책임을 파악한 뒤 필요한 범위로 좁혀 읽어 보세요.
검색 결과는 최신성이 보장된 사실이 아닙니다. 현재 브랜치의 파일과 실제 실행을 확인하고, 버전별 동작은 해당 버전의 공식 문서와 비교합니다. 출처가 서로 다르면 하나를 조용히 지우기보다 차이를 기록해 해결할 질문으로 남깁니다.
04 · 인계 노트는 다음 행동을 실행하게 만든다
다음 세션의 사람이 이어받는다고 생각해 봅니다. “거의 완료”보다 “입력 검증 수정, 공백 입력은 통과, 새로고침 후 유지 여부는 미검증”이 유용합니다. 변경 파일 목록, 실행 명령, 실패 입력, 임시 설정의 위치를 남기면 긴 대화를 다시 읽는 시간을 줄일 수 있습니다.
요약 직후에는 현재 코드와 차이가 없는지 확인합니다. 코드가 바뀌었는데 인계 노트는 이전 함수명을 가리킬 수 있습니다. 완료 체크는 남아 있는 코드를 직접 확인한 근거와 연결하세요. 비밀키나 사용자 원본 데이터 대신 마스킹된 최소 재현 자료를 기록합니다.
05 · 시스템·임베디드 과제로 확장하기
시스템 엔지니어 지망생은 샘플 장애 로그에서 시간대, 에러율, 마지막 설정 변경을 나눠 기록할 수 있습니다. 임베디드 입문자는 보드 모델, 펌웨어 버전, 연결 핀과 측정 조건을 남겨 같은 증상을 재현할 수 있습니다. 맥락이 정확하면 AI의 제안도 사람이 평가하기 쉬워집니다.
포트폴리오에서는 기록 전후에 재현까지 걸린 시간을 비교해 보세요. 무조건 짧은 컨텍스트가 좋은 것이 아니라 필요한 사실을 빠짐없이 찾을 수 있는지가 기준입니다. 자신이 만든 요약만 읽은 동료가 다음 검사를 실행할 수 있다면 좋은 출발입니다.