코딩 에이전트 코드 청결도 2026, 클라우드 비용·토큰 낭비 줄이는 기준
코딩 에이전트 코드 청결도는 리팩터링 취향 문제가 아니라 토큰 비용과 클라우드 실행 비용을 움직이는 운영 변수다.
Claude Code나 Copilot 계열 도구를 팀에 붙이면 모델이 코드를 읽고, 파일을 다시 열고, 테스트를 돌리고, 실패한 패치를 고치는 과정이 청구서와 리뷰 시간으로 바뀐다.
arXiv에 공개된 통제 연구는 깨끗한 코드와 지저분한 코드의 외부 동작을 맞춘 뒤 Claude Code 실행 footprint를 비교했다.
그 연구에서 성공률 자체는 크게 달라지지 않았지만 깨끗한 코드에서는 토큰 등가 지표가 7~8% 줄고 파일 재방문은 34% 줄었다.
이 수치를 모든 조직에 그대로 곱하면 안 되지만, 클라우드 비용 최적화 관점에서는 충분히 점검할 만한 신호다.
- 코딩 에이전트 코드 청결도는 입력 토큰, 파일 재방문, CI 재실행, 리뷰 재작업 비용을 같이 줄일 수 있는 후보 지표다.
- 연구 결과는 성공률 개선보다 탐색 비용 감소를 보여주므로 ROI 계산도 “기능 완료율”이 아니라 “작업당 footprint”로 잡아야 한다.
- SonarQube의 new code 품질 게이트와 복잡도 지표는 에이전트 도입 전 품질 기준을 자동화하기 좋은 출발점이다.
- 클라우드 비용 최적화는 모델 비용만 보지 말고 샌드박스 compute, 로그, 테스트, 보안 승인, 실패한 PR 처리 시간을 포함해야 한다.
이 글이 필요한 사람
- Claude Code, OpenAI Codex, GitHub Copilot coding agent를 사내 저장소에 붙이기 전에 비용 기준을 정하려는 개발 리더.
- AI 코딩 도구 사용량은 늘었지만 PR 품질과 CI 재실행 비용이 줄지 않아 원인을 나누고 싶은 플랫폼 엔지니어.
- 레거시 코드 리팩터링 예산을 “개발자 만족”이 아니라 토큰, 리뷰, 테스트 비용 절감 근거로 설명해야 하는 팀장.
- SonarQube, 정적 분석, 품질 게이트를 이미 쓰지만 AI 에이전트 운영 지표와 연결하지 못한 DevOps 담당자.
- 코딩 에이전트 코드 청결도 투자가 클라우드 비용 최적화 항목으로 잡힐 수 있는지 검토하는 FinOps 담당자.
검색 의도 정리: 깨끗한 코드가 왜 비용 항목이 되는가
코딩 에이전트 코드 청결도를 찾는 사람은 보통 “AI가 알아서 고치는데 리팩터링이 아직 필요한가”라는 질문을 갖고 있다.
답은 단순히 필요하다는 쪽이 아니라, 어떤 비용을 줄이려는지 먼저 정해야 한다는 쪽에 가깝다.
에이전트가 코드를 이해하는 과정은 사람이 IDE에서 훑는 과정과 달리 매번 컨텍스트, 도구 호출, 테스트, 로그를 만든다.
함수 이름이 모호하고 의존성이 꼬여 있으면 에이전트는 같은 파일을 되짚어 읽거나 주변 모듈을 더 넓게 탐색한다.
그 탐색은 입력 토큰, 세션 시간, sandbox compute, CI 실행 시간, 리뷰 재작업으로 흩어져 보인다.
따라서 클라우드 비용 최적화 코드 청결도 전략은 “리팩터링을 많이 하자”가 아니라 “에이전트가 낭비하는 탐색을 줄이자”로 잡아야 한다.
비용이 새는 다섯 경로
코딩 에이전트 도입비는 라이선스 가격표 한 줄로 끝나지 않는다.
특히 레거시 저장소에서는 토큰, 테스트, 로그, 리뷰, 보안 승인 비용이 서로 다른 예산 항목으로 흩어진다.
| 비용 경로 | 지저분한 코드에서 보이는 신호 | 측정 지표 | 먼저 줄일 것 |
|---|---|---|---|
| 입력 토큰 | 함수와 파일 경계가 모호해 넓은 범위를 읽는다. | 작업당 입력 토큰, 읽은 파일 수 | 핫스팟 파일 설명과 모듈 경계 정리. |
| 파일 재방문 | 수정한 파일을 다시 열어 의도를 확인한다. | read-after-edit 횟수, 재방문 파일 TOP10 | 이름, 책임, 테스트 위치 정리. |
| CI 재실행 | 작은 변경도 많은 테스트와 긴 빌드를 건드린다. | retry count, job minutes, 실패 원인 | 테스트 분리와 실패 재현 명령 고정. |
| 리뷰 재작업 | AI 패치 의도와 실제 변경 범위가 어긋난다. | 반려 PR 비율, 수동 수정 시간 | diff summary, rollback note, owner 지정. |
| 보안 승인 | 에이전트가 민감 파일과 운영 데이터를 필요 이상으로 탐색한다. | 권한 요청, 차단된 파일 접근 | secret scan, allowlist, MCP 권한 분리. |
이 표에서 중요한 점은 한 항목만 줄이면 다른 항목이 늘 수 있다는 것이다.
예를 들어 컨텍스트를 무작정 줄이면 토큰은 줄지만 테스트 실패와 리뷰 재작업이 늘 수 있다.
연구 근거: 성공률보다 footprint가 움직였다
arXiv 논문은 코드 청결도만 다른 최소쌍 저장소를 만들고, 같은 작업을 양쪽 코드베이스에서 반복 실행했다.
저장소 쌍은 아키텍처, 의존성, 외부 동작을 맞추고 SonarQube 규칙 위반과 인지 복잡도 차이를 중심으로 나뉘었다.
총 33개 작업과 660회 Claude Code 실행이 사용됐고, 에이전트는 자신이 깨끗한 쪽을 보고 있는지 알지 못했다.
결과는 개발팀이 기대하는 “성공률이 크게 오른다”는 그림과 조금 다르다.
통과율은 유의미하게 바뀌지 않았지만 깨끗한 코드에서 토큰 등가 지표와 파일 재방문이 줄었다.
운영 관점에서는 이 차이가 더 현실적인 근거다.
이미 통과율이 충분한 팀이라면 다음 병목은 작업당 비용, 세션 시간, 리뷰 회전율이기 때문이다.
실무 시나리오 1: 레거시 API 버그를 에이전트에게 맡기는 경우
첫 번째 시나리오는 결제 또는 인증 API 버그를 코딩 에이전트에게 맡겼는데 수정 범위가 계속 커지는 경우다.
이 조건이면 검토한다: 에이전트가 같은 파일을 여러 번 읽고, 첫 편집 전 탐색 시간이 길며, PR 설명이 실제 변경 이유를 충분히 설명하지 못한다.
이 경우는 보류한다: 운영 장애 중인 저장소에 품질 기준 없이 에이전트를 바로 쓰고, 실패하면 사람이 뒤에서 급하게 패치를 덮어쓰는 방식이다.
- 최근 30일 장애와 버그 수정 PR에서 에이전트가 읽은 파일 수와 수정한 파일 수를 분리한다.
- 반복 재방문 파일이 특정 서비스, util, mapper, policy 모듈에 몰리는지 확인한다.
- 해당 파일의 책임 설명, 테스트 위치, 입력과 출력 예시를 README 또는 코드 주석이 아닌 팀 문서로 고정한다.
- 큰 함수를 바로 쪼개기보다 새 작업에서 바뀌는 new code에 품질 게이트를 먼저 적용한다.
- 에이전트가 만든 패치는 diff summary, 테스트 증거, 롤백 기준이 없으면 병합하지 않는다.
이 접근은 리팩터링 대장정을 시작하자는 말이 아니다.
에이전트가 매번 헤매는 핫스팟부터 비용 신호로 잡자는 말이다.
실무 시나리오 2: AI PR 자동화가 CI 비용을 키우는 경우
두 번째 시나리오는 Dependabot, 테스트 생성, 소규모 리팩터링을 에이전트가 PR로 올리지만 CI 재실행이 늘어나는 경우다.
이 조건이면 검토한다: 에이전트 PR의 평균 job minutes가 사람 PR보다 높고, 실패 원인이 테스트 환경보다 변경 범위 오해에 가깝다.
이 경우는 보류한다: 에이전트에게 전체 저장소 테스트만 허용하고, 빠른 단위 테스트나 변경 파일 기반 검증 명령을 제공하지 않는 상태다.
- 작업 유형별로 허용할 테스트 레벨을 나눈다: lint, unit, integration, e2e, smoke.
- 에이전트 프롬프트에는 “먼저 관련 테스트만 실행하고, 실패 근거가 있으면 전체 테스트로 확장” 같은 순서를 넣는다.
- CI runner, artifact 보관, 로그 수집량에 cost_owner 태그를 붙인다.
- 동일 실패로 2회 이상 재시도한 세션은 자동 재시도 대신 사람 리뷰로 전환한다.
- 새 코드 품질 게이트 실패는 “AI가 고친다”가 아니라 “작업 범위를 다시 줄인다”로 처리한다.
AI PR 자동화의 비용은 PR 수가 아니라 실패한 검증 회전에서 커진다.
테스트 전략이 없는 코딩 에이전트는 개발자 시간을 줄이기보다 CI 청구서와 리뷰 큐를 늘릴 수 있다.
도입 판단표: 코드 청결도 투자가 비용 절감으로 이어지는 조건
코딩 에이전트 코드 청결도 투자는 모든 저장소에서 같은 우선순위가 아니다.
아래 표는 리팩터링 예산을 잡기 전에 어떤 조건이면 먼저 할지 나누는 기준이다.
| 상황 | 먼저 할 일 | 비용 기대효과 | 보류 기준 |
|---|---|---|---|
| 에이전트가 같은 파일을 반복 탐색한다. | 핫스팟 책임과 테스트 위치 정리. | 입력 토큰과 파일 재방문 감소. | 업무 도메인이 아직 자주 바뀌면 보류. |
| CI 재실행이 많다. | 변경 파일 기반 테스트 명령과 실패 분류. | runner minutes와 로그 비용 감소. | 테스트 자체가 불안정하면 먼저 flaky test 정리. |
| PR 리뷰 반려가 많다. | diff summary와 rollback note 필수화. | 리뷰 회전 시간 감소. | 리뷰 기준이 팀마다 다르면 기준 통일부터 진행. |
| 보안팀 승인 지연이 크다. | 민감 파일 allowlist와 secret scan 연결. | 승인 대기와 사고 대응 비용 감소. | 데이터 분류가 없으면 접근정책부터 정리. |
| 모델 비용이 빠르게 는다. | 작업당 token, tool turn, revisit 예산 설정. | 세션 폭주와 컨텍스트 낭비 감소. | 업무 가치가 불명확한 실험이면 pilot 축소. |
표의 결론은 리팩터링을 전사 캠페인으로 시작하지 말라는 것이다.
에이전트 사용 로그가 보여주는 반복 탐색 지점부터 좁게 손대야 비용 최적화 근거가 남는다.
SonarQube 품질 게이트를 에이전트 비용 게이트로 바꾸는 법
SonarQube 문서는 new code에 초점을 맞춰 품질 표준과 quality gate를 정의하는 흐름을 설명한다.
또한 metrics 문서는 보안, 유지보수성, 신뢰성, 테스트 커버리지, 복잡도, 중복 코드 같은 측정 항목을 제공한다고 정리한다.
이 흐름을 코딩 에이전트에 맞게 바꾸면 “전체 레거시를 당장 깨끗하게 만들자”가 아니라 “에이전트가 새로 건드린 코드부터 악화시키지 말자”가 된다.
- 기준선은 전체 저장소 평균보다 new code 기준으로 둔다.
- 인지 복잡도와 중복 블록 증가는 에이전트 PR에서 별도 경고로 본다.
- 보안 이슈는 모델이 만든 코드라도 예외 없이 사람 승인으로 보낸다.
- 품질 게이트 실패 PR은 토큰을 더 쓰게 하지 말고 작업 범위와 테스트 근거를 다시 작성한다.
- 정적 분석 결과는 에이전트에게 “고쳐라”만 주지 말고 파일, 규칙, 영향 범위, 테스트 명령까지 같이 준다.
품질 게이트가 비용 게이트가 되려면 분석 결과와 에이전트 세션 로그가 같은 PR에 붙어야 한다.
그래야 복잡도 증가, 토큰 증가, CI 재실행이 같은 원인인지 확인할 수 있다.
Claude Code 운영 문서에서 가져올 기준
Anthropic 문서는 Claude Code를 코드베이스를 읽고 파일을 수정하며 명령을 실행하는 agentic coding tool로 설명한다.
공통 workflow 문서는 코드베이스 파악, 버그 수정, 리팩터링, 테스트, PR 작업을 단계별 패턴으로 제시한다.
monitoring usage 문서는 팀이 사용량을 추적해야 한다는 운영 전제를 제공한다.
이 세 가지를 합치면 코딩 에이전트 비용 관리는 프롬프트 문구보다 작업 표면 관리에 가깝다.
- 낯선 코드 탐색 작업과 실제 수정 작업을 분리한다.
- 첫 작업 전에 관련 파일, 도메인 용어, 테스트 명령을 제공해 불필요한 탐색을 줄인다.
- 병렬 세션이나 worktree를 쓸 때는 같은 파일을 동시에 고치지 않도록 owner를 지정한다.
- 사용량 모니터링은 사용자별 합계보다 저장소, 작업 유형, 실패 원인별로 나눠야 한다.
- 자동 명령 실행 권한은 비용과 보안 경계가 동시에 있으므로 allowlist와 승인 로그를 남긴다.
코딩 에이전트 코드 청결도는 그래서 코드 스타일 문제가 아니라 작업 표면을 줄이는 문제다.
작업 표면이 좁을수록 모델이 읽어야 할 코드와 실행해야 할 검증이 줄어든다.
정책 스켈레톤: 품질 게이트와 비용 게이트를 한 파일로 묶기
아래 YAML은 바로 적용할 제품 설정이 아니라 파일럿 운영 기준을 맞추기 위한 검토 스켈레톤이다.
핵심은 정적 분석 품질, 에이전트 사용량, CI 재시도, 클라우드 태그를 서로 다른 팀의 문서에 흩어두지 않는 것이다.
# agent-code-cleanliness-cost-gate.yaml
# 목적: 코딩 에이전트를 팀에 붙이기 전에 코드 청결도와 비용 경계를 같이 확인한다.
# 실제 임계값, 저장소 이름, 예산 한도, 승인자는 조직 정책에 맞게 바꾼다.
owner:
engineering: platform-engineering
finance: finops
security: application-security
repository_scope:
include:
- service-api
- admin-console
- batch-worker
exclude:
- archived-experiments
- unmanaged-prototypes
quality_baseline:
max_new_critical_issues: 0
max_new_high_issues: 0
max_changed_file_cognitive_complexity: 20
max_duplicate_block_growth_percent: 3
require_tests_for_agent_changes: true
agent_budget:
max_input_tokens_per_task: 2500000
max_tool_turns_per_task: 80
max_file_revisits_per_task: 25
max_ci_retry_count: 2
max_sandbox_runtime_minutes: 45
release_gate:
block_when:
- quality_gate_failed_on_new_code
- agent_session_without_task_owner
- repeated_file_revisit_over_budget
- ci_retry_without_root_cause
- secrets_or_prod_data_requested_by_agent
cost_tags:
service: coding-agent
cost_owner: developer-productivity
environment: pilot|production
repository: required
review_policy:
human_review_required: true
require_diff_summary: true
require_test_evidence: true
require_rollback_note: true
AWS Well-Architected Cost Optimization 원칙처럼 비용은 한 번 줄이고 끝나는 항목이 아니라 지속적으로 측정하고 조정해야 한다.
코딩 에이전트도 동일하게 저장소, 작업 유형, 환경 태그를 붙여야 실제 비용 대화가 가능하다.
점검 스크립트: 에이전트 세션 로그에서 낭비 신호 찾기
팀마다 Claude Code, Copilot, 자체 하네스의 로그 형식은 다르다.
그래도 입력 토큰, 도구 호출, CI 재시도, 수정 후 파일 재방문은 공통 비용 신호로 잡을 수 있다.
#!/usr/bin/env python3
# agent_session_budget_check.py
# 목적: 코딩 에이전트 세션 로그를 배포 전 비용 신호로 요약한다.
# 실제 로그 스키마는 Claude Code, Copilot, 사내 하네스 형식에 맞게 매핑한다.
import json
import sys
from collections import Counter
MAX_INPUT_TOKENS = 2_500_000
MAX_TOOL_TURNS = 80
MAX_FILE_REVISITS = 25
MAX_CI_RETRIES = 2
path = sys.argv[1]
with open(path, encoding='utf-8') as f:
events = [json.loads(line) for line in f if line.strip()]
input_tokens = sum(int(e.get('input_tokens', 0)) for e in events)
tool_turns = sum(1 for e in events if e.get('type') == 'tool_call')
ci_retries = sum(1 for e in events if e.get('type') == 'ci_retry')
reads_after_edit = Counter()
edited = set()
for event in events:
file_path = event.get('file')
if not file_path:
continue
if event.get('type') == 'edit':
edited.add(file_path)
if event.get('type') == 'read' and file_path in edited:
reads_after_edit[file_path] += 1
file_revisits = sum(reads_after_edit.values())
failed = []
if input_tokens > MAX_INPUT_TOKENS:
failed.append(f'input_tokens={input_tokens}')
if tool_turns > MAX_TOOL_TURNS:
failed.append(f'tool_turns={tool_turns}')
if file_revisits > MAX_FILE_REVISITS:
failed.append(f'file_revisits={file_revisits}')
if ci_retries > MAX_CI_RETRIES:
failed.append(f'ci_retries={ci_retries}')
summary = {
'input_tokens': input_tokens,
'tool_turns': tool_turns,
'file_revisits': file_revisits,
'ci_retries': ci_retries,
'top_revisited_files': reads_after_edit.most_common(10),
'gate_passed': not failed,
'failed_signals': failed,
}
print(json.dumps(summary, ensure_ascii=False, indent=2))
sys.exit(0 if not failed else 2)
이 스크립트는 예시이며 실제 로그 필드명은 조직 도구에 맞춰 바꿔야 한다.
중요한 것은 세션이 실패했는지보다 어디서 비용 예산을 넘었는지 PR 단위로 남기는 것이다.
보안과 운영 리스크: 비용 절감만 보고 자동화를 넓히면 안 된다
코딩 에이전트가 읽는 파일에는 설정, 테스트 fixture, 배포 스크립트, 내부 API 이름, 때로는 민감한 운영 힌트가 들어 있다.
코드 청결도를 높여 탐색 범위를 줄이면 비용뿐 아니라 과도한 파일 접근도 줄일 수 있다.
| 리스크 | 비용과 연결되는 지점 | 운영 기준 | 보안 기준 |
|---|---|---|---|
| 과도한 컨텍스트 읽기 | 입력 토큰과 세션 시간이 늘어난다. | 관련 파일 후보를 먼저 제공한다. | 민감 경로는 allowlist 밖으로 둔다. |
| 무분별한 명령 실행 | CI와 sandbox 비용이 증가한다. | 명령 단계와 timeout을 고정한다. | production write 명령은 차단한다. |
| 비밀값 노출 | 사고 대응과 회수 비용이 생긴다. | secret scan 실패 시 세션 중단. | 토큰과 키는 로그에 남기지 않는다. |
| 큰 범위 리팩터링 | 리뷰와 테스트 회전이 길어진다. | 작업당 변경 파일 수를 제한한다. | 권한 상승 파일은 사람 승인. |
| 품질 게이트 무시 | 나중에 더 비싼 리팩터링이 된다. | new code 기준으로 차단한다. | 보안 이슈는 예외 승인 기록. |
비용 절감이라는 이름으로 에이전트 권한을 넓히면 나중에 보안팀과 운영팀이 더 큰 비용을 치른다.
가장 좋은 비용 최적화는 에이전트가 필요한 범위만 읽고 필요한 검증만 실행하게 만드는 것이다.
실전 체크리스트: 파일럿 2주 동안 볼 숫자
파일럿 단계에서는 성공한 PR 개수보다 작업당 footprint를 먼저 봐야 한다.
아래 항목을 2주만 모아도 코드 청결도 투자 범위를 훨씬 좁힐 수 있다.
- 작업당 입력 토큰과 출력 토큰을 저장소, 작업 유형, 담당 팀으로 나눈다.
- 첫 편집 전 도구 호출 수와 첫 편집 전 읽은 파일 수를 따로 본다.
- 수정 후 다시 읽은 파일 TOP10을 뽑아 책임 경계가 흐린 모듈을 찾는다.
- 에이전트 PR의 CI retry count와 사람 PR의 retry count를 비교한다.
- 품질 게이트 실패 항목이 new code인지 전체 legacy인지 분리한다.
- 반려된 PR은 “요구사항 오해”, “테스트 실패”, “보안 우려”, “범위 과다”로 태깅한다.
- 비용 절감 배포 뒤에는 결함 재발률과 리뷰 소요 시간이 같이 나빠지지 않았는지 본다.
이 체크리스트 없이 모델만 바꾸면 비용 원인을 모델 가격으로 착각하기 쉽다.
모델 선택도 중요하지만 코드베이스의 탐색 난이도는 모델 교체 뒤에도 남는다.
함께 보면 좋은 글
코딩 에이전트 코드 청결도 전략은 Claude Code 사용법, Codex 도입, Copilot 모델 선택, AI 테스트 자동화와 같이 봐야 판단이 빠르다.
Claude Code 사용법 2026, 설치·로그인·첫 작업과 보안 승인 기준
OpenAI Codex 사용법 2026, 설치·CLI·IDE 첫 작업 가이드
GitHub Copilot 모델 선택 2026, 사내 개발팀 비용·보안·품질 기준
AI 코딩 테스트 자동화 2026, CI에서 테스트 생성·검증·보안 승인 기준
AI 에이전트 루프 설계 2026, 검증·트리거·사람 승인 기준자주 묻는 질문
코딩 에이전트 코드 청결도는 정말 비용을 줄이나요?
공개 연구는 성공률보다 토큰 등가 지표와 파일 재방문 감소를 보여줬으므로, 비용 절감 가능성은 작업당 footprint 기준으로 검증해야 한다.
클라우드 비용 최적화와 코드 청결도는 어떤 관계인가요?
에이전트가 코드를 더 많이 읽고 테스트를 더 자주 돌리면 모델 사용량, sandbox compute, CI runner, 로그 비용이 함께 늘어난다.
레거시 전체를 리팩터링해야 하나요?
아니다.
에이전트 세션 로그에서 파일 재방문, CI 재시도, 품질 게이트 실패가 반복되는 new code와 핫스팟부터 좁게 정리하는 편이 낫다.
SonarQube 점수만 좋아지면 충분한가요?
충분하지 않다.
정적 분석 점수와 함께 작업당 입력 토큰, 도구 호출, CI 재실행, 리뷰 반려 사유를 같은 PR에서 봐야 한다.
코딩 에이전트 비용은 모델 가격표만 보면 되나요?
모델 가격표는 일부일 뿐이며 테스트 실행, 로그 보관, runner minutes, 보안 승인, 실패한 PR 재작업 시간을 같이 봐야 한다.
팀에 바로 적용할 첫 단계는 무엇인가요?
2주 파일럿 동안 작업당 토큰, 읽은 파일 수, 수정 후 파일 재방문, CI retry, 품질 게이트 실패를 모으고 상위 핫스팟 5개만 정리한다.
출처와 확인일
- arXiv — Does Code Cleanliness Affect Coding Agents? A Controlled Minimal-Pair Study (확인일: 2026-07-07)
- GeekNews — 코드 청결도는 코딩 에이전트에 영향을 미치는가? 통제된 최소쌍 연구 (확인일: 2026-07-07)
- Anthropic Docs — Claude Code overview (확인일: 2026-07-07)
- Anthropic Docs — Claude Code common workflows (확인일: 2026-07-07)
- Anthropic Docs — Claude Code monitoring usage (확인일: 2026-07-07)
- SonarQube Docs — Quality standards and new code (확인일: 2026-07-07)
- SonarQube Docs — Understanding measures and metrics (확인일: 2026-07-07)
- AWS Well-Architected — Cost Optimization Pillar (확인일: 2026-07-07)
이 글은 공개 논문, 공식 문서, 기술 문서를 바탕으로 작성한 일반적인 IT 운영 가이드다.
모델 비용, 사용량 지표, Claude Code 기능, SonarQube 측정 항목, 클라우드 과금 방식은 플랜과 시점에 따라 바뀔 수 있다.
실제 도입에는 조직의 보안 정책, 소스코드 반출 기준, 개인정보 처리 기준, 예산 승인 절차를 별도로 적용해야 한다.
댓글
댓글 쓰기