이번 시간에는 로컬 LLM 에이전트의 대화 이력을 관리하는 전략 네 가지를 돌려 보면서, 이력이 쌓일 때 무엇이 느려지고 어떤 값을 잊는지 측정하며 배워가는 시간입니다.
먼저 이런 장면부터 볼게요. 로컬 LLM 에이전트와 20단계짜리 대화를 나눈 뒤, 앞에서 조회한 값을 다시 물어봤어요. 대화 이력은 하나도 버리지 않고 매번 모델에 그대로 보냈습니다.
6단계에서 좋아요 수를 조회하는 도구 get_like_count가 돌려준 mysql-06 글의 좋아요 수는 908이었어요. 이 값은 16단계에 보낸 56개 메시지 안에 그대로 있었고요.
그런데 모델은 811이라고 답했어요. 811은 12단계에서 조회한 다른 글(docker-11)의 좋아요 수입니다. 이 글에 싣지 않은 추가 측정에서는, 같은 질문을 이력 없이 필요한 도구 결과 하나만 넣어 물으면 세 번 모두 908로 맞혔어요.
그래서 같은 20단계 대화를 전략마다 돌리면서, 단계마다 Ollama가 알려 주는 프롬프트 토큰 수, 캐시에서 재사용한 토큰 수, 처리 시간을 기록하고, 끝의 확인 질문 일곱 개로 각 전략이 무엇을 잃었는지 볼게요.
비교할 네 가지 전략
네 전략 모두 시스템 메시지(모델의 역할과 규칙을 적은 첫 메시지)는 항상 남겨요.
full: 모든 메시지를 보냅니다.last_n: 최근 N개 사용자 턴과 그 턴에 딸린 모델 응답, 도구 결과만 보내요. 이 글에서 N은 8입니다.clear_tool: 최근 K개 도구 결과는 그대로 두고, 그보다 오래된 도구 결과의 내용만[이전 도구 결과 생략]으로 바꿔요. K는 3입니다.summarize: 직전 호출의 프롬프트가 3,000토큰을 넘으면, 최근 두 턴을 뺀 앞부분을 같은 모델로 요약해서 메시지 하나로 바꿉니다. 요약 호출에 든 토큰과 시간도 따로 세요.
대화 이력 전체는 그대로 쌓아 두고, 모델을 부르기 직전에 "이번에 무엇을 보낼지"만 정하는 함수로 만들었어요. 네 전략의 함수는 ctxlab/policies.py에 있습니다.
실습 준비
이 글의 명령은 모두 실습 코드의 agent-context-growth/ 디렉터리에서 실행합니다.
compose.yaml: Ollama 0.34.4 컨테이너와 Python 3.12 클라이언트 컨테이너requirements.txt: 클라이언트 컨테이너가 설치하는 패키지 두 개make_session.py: 가짜 사이트 DBsite.db와 20단계 세션session.jsonl을 만드는 스크립트lab.py: 전략별 세션(session)을 돌리는 진입점show.py: 실행 기록을 단계별 표, 확인 질문 채점, 요약문으로 찍는 스크립트ctxlab/: 이력 전략, 세션 실행기, 도구 두 개를 담은 패키지(파일 4개)agentlab/: 도구 등록·실행, 채점, 가짜 사이트 DB 생성 모듈 패키지(파일 11개)sessions/: 이 글을 쓸 때 남은 세션 기록 11개.lab.py session은 같은 이름의 기록이 있으면 그 세션을 건너뛰므로, 직접 돌리려면 이 디렉터리를 비우고 시작합니다
그 밖의 파일은 데이터·보조 스크립트입니다.
compose.yaml은 ollama/ollama:0.34.4 컨테이너(메모리 4,500MB, CPU 2.75)와 python:3.12-slim 클라이언트 컨테이너(메모리 500MB, CPU 0.25)를 띄우고, Ollama는 127.0.0.1:7570에 열어요. Docker Desktop 안에서는 Mac의 GPU를 쓰지 못하니까 모든 추론은 CPU로 합니다.
OLLAMA_NUM_PARALLEL=1: 요청을 한 번에 하나만 처리해요. 처리 중인 대화를 담는 자리(슬롯)가 하나뿐이라서, 캐시 재사용을 해석하기 쉽습니다.LLAMA_ARG_CACHE_RAM=256: 처리한 프롬프트를 쌓아 두는 캐시의 기본 상한이 8192MiB라서 컨테이너 메모리 상한을 넘길 수 있어요. 그래서 256MiB로 낮췄습니다.client: 세션을 돌리고 채점하는 Python 컨테이너입니다./api/chat에 JSON을 직접 보내고 응답 JSON을 통째로 저장해요.
compose 파일에 name: actx가 있어서 프로젝트 이름은 따로 주지 않고, 클라이언트 컨테이너에서 Python을 실행하는 함수 하나를 정의해 둘게요. 아래 블록은 파일로 만들지 말고 실습 디렉터리에서 연 터미널에 그대로 붙여 넣어 주세요. 이후 명령은 모두 이 터미널에서 실행하고, 터미널을 새로 열면 다시 붙여 넣으시면 됩니다.
docker compose up -d
docker compose exec ollama ollama pull qwen3:1.7b
lab() { docker compose exec -T client python "$@"; }
mkdir -p out
모델은 qwen3:1.7b(Q4_K_M)이고, 모든 호출에 think: false를 줘서 생각 과정을 쓰지 않게 했어요.
temperature: 0,seed: 42: 같은 입력에 같은 출력이 나오게 하려는 설정이에요.num_ctx: 8192: 컨텍스트 길이입니다.num_predict: 256: 한 응답의 최대 생성 토큰 수예요. 요약 호출만 512입니다.num_thread: 3: 컨테이너 CPU 상한(2.75)에 맞췄어요.
모델이 사전 지식으로 답하지 못하게, 이 사이트처럼 보이는 가짜 데이터(글 60개, 콘텐츠 12개)를 SQLite 파일 하나에 만들고 도구 네 개를 붙였어요.
search_articles(query): 제목에 검색어가 들어간 글의 slug와 제목 목록get_like_count(slug): 글 하나의 좋아요 수get_article_meta(slug): 글 하나의 제목, 태그, 작성일, 글자 수, 연결된 콘텐츠(course_slug)와 본문 앞부분. 이 도구를 부른 한 턴이 이력에 420~470토큰을 더합니다.list_courses(tag): 태그 하나에 연결된 콘텐츠 목록(제목, 가격, 수강생 수). 메시징 태그는 8개 콘텐츠를 돌려주고, 이 턴이 약 440토큰을 더합니다.
좋아요 수(100~999), 수강생 수(1000~9999), 글자 수(10000~29999), 가격(31000 이상)은 모두 서로 겹치지 않는 정수예요. 그래서 엉뚱한 값이 우연히 정답과 같아지는 일이 없습니다.
세션은 session.jsonl에 한 줄에 한 단계씩 적었어요. make_session.py가 site.db를 만든 뒤 세션을 적습니다.
lab make_session.py
424e6f3264e4eedf0a2bd28f47f72f5c74c6d394686077afa26d333f38aa7963 site.db (sha256 of the SQL dump)
80ce8cbfd9ad8f98aced636a4a2646b5f60d2e19dad0c54a9d2a131f2f627b51 session.jsonl
steps 20, recall 7, tool 13
step 14 <- step 13 (distance 1) answer 14646
step 15 <- step 12 (distance 3) answer 821
step 16 <- step 6 (distance 10) answer 908
step 17 <- step 7 (distance 10) answer 24843
step 18 <- step 4 (distance 14) answer 94000
step 19 <- step 2 (distance 17) answer crs-02
step 20 <- step 2 (distance 18) answer 20331
1~13단계는 도구를 불러야 하는 요청이에요("get_like_count 도구로 mysql-06 글의 좋아요 수를 조회해 줘."). 14~20단계는 앞에서 본 값을 다시 묻는 확인 질문이고요("앞에서 확인한 mysql-06 글의 좋아요 수는 몇이었어? 도구를 다시 부르지 말고 앞에서 확인한 값으로 답해 줘.").
distance는 원래 값을 얻은 단계와의 거리예요. 19단계의 course_slug, 17단계와 14단계의 글자 수처럼, 원래 요청이 묻지 않아서 모델의 답에는 나오지 않고 도구 결과 안에만 있는 값도 일부러 넣었어요.
Ollama /api/chat 응답에서는 프롬프트에 관한 숫자 두 개를 읽어요.
prompt_eval_count: 프롬프트의 입력 토큰 수입니다. Ollama 0.34.4에서는 캐시에서 꺼낸 토큰도 포함해요.prompt_eval_cached_count: 그중 캐시에서 읽은 토큰 수예요. 앞선 요청과 앞부분(접두부)이 같으면 그만큼은 다시 계산하지 않습니다.
그래서 이 글에서 "다시 계산한 토큰"은 prompt_eval_count - prompt_eval_cached_count라고 보시면 됩니다.
실습 1: 전체 이력 유지, 토큰은 쌓이고 정답은 절반
full로 20단계 세션을 세 번 돌렸어요. 나머지 전략도 같은 명령에 전략 이름만 바꿔 돌리면 됩니다.
결과는 show.py로 봐요. steps는 호출 기록을 단계별로 묶어서, 첫 호출의 프롬프트와 캐시 토큰, 단계 안 모든 호출이 다시 계산한 토큰의 합, 모델 시간을 찍어 줍니다.
lab lab.py session full --runs 1,2,3
lab show.py steps full_r1
[full_r1] step: calls | prompt at first call (cached) | recomputed in step | model time
step 1: 2 | 706 ( 669) | 133 | 3.5s
step 2: 2 | 838 ( 693) | 575 | 10.1s
step 3: 2 | 1303 ( 825) | 537 | 10.2s
step 4: 2 | 1417 ( 1290) | 525 | 11.2s
step 5: 2 | 1850 ( 1404) | 828 | 17.4s
step 6: 2 | 2272 ( 1837) | 492 | 13.4s
step 7: 2 | 2366 ( 2259) | 522 | 14.0s
step 8: 2 | 2843 ( 2353) | 884 | 21.3s
step 9: 2 | 3292 ( 2830) | 684 | 18.7s
step 10: 2 | 3552 ( 3279) | 681 | 21.2s
step 11: 2 | 3998 ( 3539) | 558 | 18.0s
step 12: 2 | 4128 ( 3985) | 200 | 10.5s
step 13: 1 | 4222 ( 4115) | 107 | 5.4s
step 14: 1 | 4288 ( 4209) | 79 | 3.8s
step 15: 1 | 4346 ( 4275) | 71 | 4.6s
step 16: 1 | 4408 ( 4333) | 75 | 3.4s
step 17: 1 | 4464 ( 4395) | 69 | 3.6s
step 18: 1 | 4530 ( 4451) | 79 | 4.1s
step 19: 1 | 4594 ( 4517) | 77 | 4.0s
step 20: 1 | 4649 ( 4581) | 68 | 4.1s
열은 왼쪽부터 그 단계의 모델 호출 수, 첫 호출의 프롬프트 토큰(괄호 안은 그중 캐시에서 읽은 토큰), 그 단계의 호출들이 다시 계산한 토큰의 합, 모델 처리 시간이에요.
프롬프트는 706토큰에서 4,649토큰까지 늘었어요. 그래도 각 단계가 다시 계산한 토큰은 수십에서 수백 토큰이고, 처리 시간도 단계당 4~21초에 머물렀습니다. 앞부분이 그대로인 동안은 그만큼을 캐시에서 읽기 때문이에요.
show.py recall은 확인 질문만 골라서, 정답과 모델의 답, 그리고 원래 값이 그 질문을 보낼 때 프롬프트 안에 남아 있었는지(value in prompt)를 찍어 줍니다.
lab show.py recall full_r1
[full_r1] recall 3/7
step 14 distance 1: expected 14646 got 17927 WRONG (value in prompt no)
step 15 distance 3: expected 821 got 821 OK (value in prompt yes)
step 16 distance 10: expected 908 got 811 WRONG (value in prompt yes)
step 17 distance 10: expected 24843 got 14843 WRONG (value in prompt yes)
step 18 distance 14: expected 94000 got 94000 OK (value in prompt yes)
step 19 distance 17: expected crs-02 got crs-02 OK (value in prompt yes)
step 20 distance 18: expected 20331 got 17927 WRONG (value in prompt yes)
세 번 반복은 단계별 토큰 수와 답이 모두 같았고, 확인 질문은 세 번 모두 7개 중 3개를 맞혔어요.
- 14단계는 값이 이력에 없었어요. 13단계에서 모델이 도구를 부르지 않고
답: 2026-03-13이라고 지어냈기 때문이에요. - 16, 17, 20단계는 값이 이력 안에 있었는데 틀렸어요. 16단계의 811은 docker-11의 좋아요 수, 14단계와 20단계의 17927은 10단계에서 본 k8s-13의 글자 수예요. 모르는 값을 지어낸 게 아니라, 이력에 있는 비슷한 종류의 값 가운데 엉뚱한 것을 집은 거예요.
이 실습의 4,600토큰은 모델이 지원하는 길이(40,960)의 9분의 1 정도인데도, 1.7B 모델에서는 같은 종류의 숫자가 여러 개 쌓인 것만으로 이런 혼동이 나왔어요.
실습 2: 최근 N턴만 남기기와 오래된 도구 결과만 지우기
last_n과 clear_tool을 두 번씩 돌렸어요. 두 번의 결과는 단계별 토큰 수와 답이 모두 같았습니다. last_n의 단계별 표를 볼게요(발췌).
lab lab.py session last_n --n 8 --runs 1,2
lab lab.py session clear_tool --k 3 --runs 1,2
lab show.py steps last_n_r1
[last_n_r1] step: calls | prompt at first call (cached) | recomputed in step | model time
step 8: 2 | 2843 ( 2353) | 884 | 21.8s
step 9: 2 | 3162 ( 669) | 2715 | 51.3s
step 10: 1 | 2952 ( 670) | 2282 | 40.6s
step 11: 3 | 2916 ( 669) | 2421 | 47.7s
step 12: 2 | 2666 ( 669) | 2054 | 36.9s
step 13: 2 | 2334 ( 670) | 2069 | 37.6s
step 14: 1 | 2711 ( 670) | 2041 | 37.6s
8단계까지는 full과 같아요. 그런데 9단계에서 사용자 턴이 9개가 되어 맨 앞 턴을 빼기 시작하자, 캐시에서 읽은 토큰이 669~674로 떨어졌어요. 앞 턴 하나를 빼면 그 뒤의 모든 메시지가 앞으로 당겨지니까, 시스템 메시지 뒤의 문자열이 직전 요청과 처음부터 달라지기 때문이에요.
9~14단계에서 last_n은 단계마다 2,000~2,700토큰을 다시 계산했고 단계당 37~51초가 걸렸어요. 같은 구간에서 full은 200~880토큰, 10~21초였습니다. 세션 전체의 모델 처리 시간은 full 3.4분, last_n 7.6분이에요.
clear_tool은 그 중간이었어요(발췌).
lab show.py steps clear_tool_r1
[clear_tool_r1] step: calls | prompt at first call (cached) | recomputed in step | model time
step 3: 2 | 1303 ( 825) | 537 | 9.7s
step 4: 2 | 1417 ( 1290) | 1163 | 18.8s
step 5: 2 | 1799 ( 1353) | 1433 | 26.6s
step 6: 2 | 1839 ( 1404) | 1425 | 23.8s
step 7: 2 | 1923 ( 1816) | 1096 | 20.1s
step 8: 2 | 2048 ( 1558) | 1518 | 26.4s
step 9: 2 | 2162 ( 1701) | 1668 | 30.1s
step 10: 2 | 2413 ( 2140) | 1474 | 28.0s
step 11: 2 | 2492 ( 2033) | 1341 | 25.0s
step 12: 2 | 2274 ( 2131) | 837 | 17.0s
step 13: 1 | 2194 ( 2087) | 107 | 4.3s
도구 결과가 네 번째로 쌓이는 4단계부터 12단계까지, 새 도구 결과가 들어올 때마다 가장 오래된 원본 결과 하나가 [이전 도구 결과 생략]으로 바뀌어요. 바뀐 메시지가 이력 중간에 있으니 그 지점부터 끝까지 다시 계산했고, 이 구간에서 단계마다 1,100~1,700토큰을 다시 계산했습니다. 세션 전체 모델 처리 시간은 4.4분이었어요.
이제 무엇을 잊었는지 볼게요.
lab show.py recall last_n_r1 clear_tool_r1
[last_n_r1] recall 2/7
step 14 distance 1: expected 14646 got 14646 OK (value in prompt yes)
step 15 distance 3: expected 821 got 821 OK (value in prompt yes)
step 16 distance 10: expected 908 got 124 WRONG (value in prompt no)
step 17 distance 10: expected 24843 got 14246 WRONG (value in prompt yes)
step 18 distance 14: expected 94000 got 150000 WRONG (value in prompt no)
step 19 distance 17: expected crs-02 got crs-08 WRONG (value in prompt no)
step 20 distance 18: expected 20331 got 14246 WRONG (value in prompt no)
[clear_tool_r1] recall 2/7
step 14 distance 1: expected 14646 got 17927 WRONG (value in prompt no)
step 15 distance 3: expected 821 got 821 OK (value in prompt yes)
step 16 distance 10: expected 908 got 908 OK (value in prompt yes)
step 17 distance 10: expected 24843 got 07 WRONG (value in prompt no)
step 18 distance 14: expected 94000 got 150,000 WRONG (value in prompt no)
step 19 distance 17: expected crs-02 got crs-10 WRONG (value in prompt no)
step 20 distance 18: expected 20331 got 17927 WRONG (value in prompt yes)
두 전략 모두 7개 중 2개였어요. 그런데 잃은 값의 종류가 서로 달라요.
last_n은 거리로 잘랐어요. 최근 8턴 안에 있는 14, 15단계만 맞히고, 거리 10 이상은 모두 틀렸습니다. 값이 없으니 모델은 모른다고 하지 않고 그럴듯한 값(124, 150000)을 만들었습니다.clear_tool은 값의 위치로 잘랐어요. 16단계의 908은 6단계 도구 결과가 지워졌는데도 맞혔습니다. 6단계에서 모델이답: 908이라고 쓴 답이 이력에 남아 있었기 때문이에요. 반대로 도구 결과 안에만 있던 값(17단계 글자 수, 18단계 가격, 19단계course_slug)은 모두 틀렸어요.
이력을 줄이면 보내는 토큰은 줄지만, 접두부가 매번 바뀌면 캐시를 잃어서 오히려 느려질 수 있다는 거죠.
실습 3: 요약으로 압축하기
summarize는 새 사용자 턴을 받기 직전에 직전 호출의 prompt_eval_count를 봐요. 3,000을 넘었으면 최근 두 턴을 뺀 앞부분(앞선 요약이 있으면 그것까지)을 대화 기록 글로 바꿔 같은 모델에 요약을 시키고, 그 요약을 시스템 메시지 바로 뒤의 메시지 하나로 넣습니다.
요약 지시문은 실험 전에 정해 둔 것을 썼어요. 지시문 다음에 대화 기록을 붙여 보냅니다.
아래는 사용자와 운영 도우미의 대화 기록이다. 나중에 사용자가 앞에서 본 값을 다시 물을 수 있으니, 사용자가 요청한 것과 도구가 돌려준 값을 요약하라. slug, course_slug, 좋아요 수, 글자 수, 작성일, 콘텐츠 제목과 가격, 수강생 수 같은 값은 빠짐없이 원래 값 그대로 적어라. 본문 내용은 적지 않는다. 글머리표 목록으로만 쓴다.
lab lab.py session summarize --threshold 3000 --runs 1,2
lab show.py summaries summarize_r1
--- summary before step 9 (covers 6 turns): prompt 1734, output 7 tokens, 37.5s
답: 908
--- summary before step 14 (covers 5 turns): prompt 1925, output 5 tokens, 44.3s
답: 2
요약이 두 번 일어났고, 결과는 답: 908과 답: 2였어요. 대화 기록 속의 모든 답이 답: <값> 형식이다 보니, 모델은 기록을 요약하지 않고 마지막 요청에 답하는 쪽을 따라갔어요. 확인 질문은 7개 중 2개(14, 15단계)만 맞혔습니다.
그래서 결과를 본 뒤 지시문을 한 번 고쳤어요. 대화 기록을 앞에 두고 지시문을 뒤로 옮겼으며, "질문에 답하지 말고 답: 줄도 쓰지 않는다"를 넣었습니다.
<대화 기록>
(대화 기록)
</대화 기록>
위는 사용자와 운영 도우미의 대화 기록이다. 이 기록을 요약하라. 질문에 답하지 말고 `답:` 줄도 쓰지 않는다. 도구 결과에 나온 slug, course_slug, 좋아요 수, 글자 수, 작성일, 콘텐츠 제목과 가격, 수강생 수는 빠짐없이 원래 값 그대로 적는다. 본문 내용은 적지 않는다. 글머리표 목록으로만 쓴다.
lab lab.py session summarize --threshold 3000 --summary-version 2 --label summarize2 --runs 1,2
lab show.py recall summarize2_r1
[summarize2_r1] recall 4/7
step 14 distance 1: expected 14646 got 14646 OK (value in prompt yes, in summary no)
step 15 distance 3: expected 821 got 821 OK (value in prompt yes, in summary no)
step 16 distance 10: expected 908 got 908 OK (value in prompt yes, in summary yes)
step 17 distance 10: expected 24843 got 07 WRONG (value in prompt no, in summary no)
step 18 distance 14: expected 94000 got 147000 WRONG (value in prompt yes, in summary yes)
step 19 distance 17: expected crs-02 got cours-03 WRONG (value in prompt no, in summary no)
step 20 distance 18: expected 20331 got 20331 OK (value in prompt yes, in summary yes)
이번에는 값이 목록으로 남아 7개 중 4개로, 첫 지시문(2개)과 full(3개)보다 많이 맞혔습니다.
- 요약에서 빠져서 틀림: 17단계(grpc-09 글자 수)와 19단계(
course_slug)예요. 도구 결과 안에만 있던 값이 요약에 없었어요. - 요약에는 있었지만 못 씀: 18단계입니다. 정답 94000은 요약에
cours-05: 94000으로 있었지만, 질문은 「메시지 큐 실무」라는 제목으로 물었고 요약에는 제목이 없어요. 값이 요약에 남아 있어도 질문이 가리키는 이름(제목)이 빠지면 모델은 그 값을 찾지 못했어요.
요약이 일어난 단계의 시간도 볼게요(발췌).
lab show.py steps summarize2_r1
[summarize2_r1] step: calls | prompt at first call (cached) | recomputed in step | model time
step 8: 2 | 2843 ( 2353) | 884 | 38.7s
step 9: 2 | 1788 ( 5) | 3743 | 47.4s + summary 54.5s
step 10: 2 | 2048 ( 1775) | 681 | 25.1s
...
step 14: 1 | 1470 ( 5) | 3534 | 34.3s + summary 76.6s
step 15: 1 | 1531 ( 1457) | 74 | 3.3s
요약이 일어난 9단계와 14단계는 요약 호출과 그 뒤의 재계산을 합쳐 각각 100초, 110초 남짓이 걸렸어요. 요약 직후의 첫 호출은 캐시에서 5토큰만 읽어서, 시스템 메시지와 도구 정의까지 처음부터 다시 계산합니다.
정리
범위: Ollama 0.34.4(CPU, num_thread 3), qwen3:1.7b Q4_K_M(think: false, temperature 0), num_ctx 8192, 20단계 세션 하나(도구 단계 13개, 확인 질문 7개), 전략마다 2~3번 반복.
full의 프롬프트는 706토큰에서 4,649토큰까지 늘었지만 단계마다 다시 계산한 토큰은 수십~수백 개, 처리 시간은 단계당 4~21초였습니다. 이 글에 싣지 않은 추가 측정에서는 이력 없이 필요한 도구 결과 하나만 주면 확인 질문 7개를 세 번 모두 맞혔는데,full에서는 값이 이력 안에 있던 6개 중 3개를 이력 속 비슷한 종류의 다른 값(811, 17927)으로 틀렸습니다. 이력을 모두 넣었다고 모델이 그 값을 찾아 쓴다고 보지 마세요.last_n(N=8)은 앞 턴을 빼기 시작한 9단계부터 캐시에서 읽은 토큰이 669~674로 떨어져 9~14단계마다 2,000~2,700토큰을 다시 계산했고, 세션 모델 시간이full3.4분보다 긴 7.6분이었고, 최근 8턴 밖의 값은 모두 틀렸습니다. 이력을 줄일 때는 보내는 토큰이 아니라prompt_eval_cached_count로 캐시가 유지되는지 확인해 주세요.clear_tool(K=3)은 결과를 지운 4~12단계마다 1,100~1,700토큰을 다시 계산했고, 모델이 답에 옮겨 적지 않은 도구 결과 속 값(글자 수, 가격,course_slug)을 모두 잃었습니다.- 첫 요약 지시문은 요약을
답: 908,답: 2한 줄로 만들어 확인 질문 2/7이었고, 지시문을 고치자 4/7이 됐지만 값의 이름(제목)이 빠져 요약에 있던 94000도 쓰지 못했습니다. 요약을 쓴다면 요약문을 기록하고 값과 이름이 함께 남았는지 검사해 주세요.