Claude Code의 Skills와 Hooks에 나의 판단 기준을 담고, 작은 업무부터 자동화하기
AI에게 코드를 작성해 달라고 하면 꽤 빠르게 결과가 나옵니다.
그런데 개발 과정 전체를 돌아보면, 여전히 사람이 챙겨야 하는 일이 많습니다.
에러 로그를 복사해서 전달하고, 관련 파일을 알려주고, 프로젝트 규칙을 다시 설명합니다. 코드가 나오면 테스트를 실행하라고 요청하고, 실패하면 결과를 붙여 넣습니다. 작업이 끝나면 변경 내용을 정리하고 문서도 수정합니다.
“이것도 확인해줘.”
“테스트도 돌려줘.”
“기존 코드 스타일에 맞춰줘.”
분명 AI를 사용하고 있는데, 어느 순간부터 제가 AI의 다음 행동을 계속 지정하고 있습니다. 이런 상황을 생각해 보면 자연스럽게 질문이 하나 생깁니다.
반복해서 지시하는 과정까지 자동화할 수는 없을까요?
제가 생각하는 자동화의 핵심은 AI 에이전트가 나와 같은 사고 과정을 바탕으로 엔지니어링하도록 만드는 것입니다.
문제를 만나면 무엇부터 확인하는지, 어떤 근거로 수정 방향을 정하는지, 어디까지 검증해야 끝났다고 판단하는지. 제가 개발하면서 사용하는 이런 기준을 에이전트의 작업 과정에도 담고 싶은 것입니다. 그 기준이 실제로 적용되는지는 에이전트가 확인한 근거와 변경 내용, 검증 결과를 통해 살펴볼 수 있습니다.
물론 이 과정을 한 번에 완성하기는 어렵습니다. 그래서 작은 업무 하나부터 자동화하고, 의도한 방식으로 수행했는지 검증한 뒤, 유효했던 방식을 다음 업무로 넓혀 가는 접근이 좋다고 생각합니다.
이전 글에서는 AI 코딩 도구를 활용하기 위한 컨텍스트와 개발 흐름을 이야기했습니다. 이번에는 Claude Code의 Skills와 Hooks를 활용해 이러한 판단 기준을 작업 절차로 옮겨 보겠습니다. 에러 수정부터 시작해서, 검증한 방식을 새 기능 개발에도 적용하는 흐름입니다.
예시는 Java·Spring Boot·Gradle 프로젝트를 가정합니다. 기본적인 Claude Code 사용 경험이 있는 개발자를 대상으로, 자신의 프로젝트에 맞게 바꿔 볼 수 있는 구성을 소개합니다.
예제의 검증 범위: 설정 JSON과 Bash 구문, 임시 Git 저장소에서 검사 스크립트의 성공·실패 동작을 확인했습니다. 실제 Claude Code 세션과 Spring Boot 프로젝트에서 버그 수정까지 통합 실행한 사례는 아닙니다.
처음부터 “개발을 전부 자동화하겠다”라고 접근하면 범위가 너무 넓습니다. 우선 제가 처리 순서와 판단 이유를 설명할 수 있는 작은 업무 하나를 고르는 편이 좋겠습니다. 예를 들어 재현 방법이 분명한 버그 하나, 수정 후 늘 실행하는 검사 하나 정도입니다.
작게 시작하면 결과를 살펴보기도 쉽습니다. 에이전트가 어디에서 제 의도와 다르게 판단했는지, 어떤 정보나 기준을 더 제공해야 하는지 확인할 수 있기 때문입니다. 아래 업무들도 처음부터 전부 연결하기보다 하나씩 적용하고 검증할 대상으로 볼 수 있습니다.
업무 | 필요한 입력 | 확인할 결과 |
|---|---|---|
버그 수정 | 재현 방법, 에러 로그, 기대 동작 | 재현 테스트와 수정 후 검증 결과 |
API 추가 | 요청·응답 명세, 도메인 규칙 | 구현 코드, 테스트, API 문서 |
코드 리뷰 | 변경 diff, 요구사항 | 근거가 있는 문제점과 개선 제안 |
PR 설명 작성 | 최종 변경 사항, 검증 결과 | 변경 목적·내용·검증 방법 |
예를 들어 “버그 좀 고쳐줘”에는 완료 기준이 없습니다. 반면 “잘못된 정렬 값으로 요청하면 500이 발생하는 문제를 재현하고, 400을 반환하도록 수정해줘”에는 확인할 동작이 있습니다.
자동화는 여기서 시작합니다. 에이전트가 해야 할 일, 판단에 사용할 기준, 그 일이 끝났다는 증거를 함께 정의하는 것입니다.
에이전트에게 일을 맡기려면 먼저 작업 환경을 이해할 수 있어야 합니다.
빌드 명령이 무엇인지, 예외 처리는 어디에서 하는지, 테스트를 실행하려면 DB가 필요한지. 사람이 새 프로젝트에 합류했을 때 확인하는 것과 크게 다르지 않습니다.
Claude Code에서는 CLAUDE.md에 이런 프로젝트 지침을 작성할 수 있습니다. 관심사별 규칙은 .claude/rules/로 나누어 관리할 수 있습니다. 다만 문서에 적힌 지침만으로 준수가 보장되지는 않으므로, 검증 가능한 규칙은 검사 도구와 함께 사용하는 편이 좋습니다. [1]
다음은 프로젝트 루트에 두는 CLAUDE.md의 간단한 예시입니다.
# 프로젝트 안내
## 기술 및 구조
- Java 21, Spring Boot, Gradle을 사용한다.
- 기존 Controller → Service → Repository 구조를 따른다.
- 예외 응답은 GlobalExceptionHandler에서 처리한다.
## 실행 및 검증
- 전체 테스트: ./gradlew test
- 단일 테스트: ./gradlew test --tests '패키지명.테스트명'
- 테스트 실행에 필요한 환경은 docs/testing.md를 참고한다.
## 작업 규칙
- 구현 전에 유사한 기존 코드와 테스트를 확인한다.
- 요구사항과 관계없는 리팩터링은 별도 작업으로 제안한다.
- 동작을 바꿨다면 해당 동작을 검증한다.
- 실행하지 못한 검증은 완료 보고에 이유를 남긴다.여기에 모든 설계 문서와 과거 논의를 넣을 필요는 없습니다. 자주 필요한 정보는 짧게 남기고, 자세한 내용은 관련 문서를 참조하게 만들면 됩니다.
특히 테스트 명령만 적고 실행에 필요한 조건을 빠뜨리면 곤란합니다. 테스트용 DB, 환경 변수, 외부 API 모킹 여부까지 알아야 에이전트가 코드 오류와 환경 문제를 구분할 수 있습니다.
규칙을 적을 때도 평소 제가 왜 그렇게 작업하는지 돌아볼 필요가 있습니다. “유사한 기존 코드를 먼저 확인한다”는 규칙에는 프로젝트의 설계 의도를 파악하고 기존 구조에 맞춰 변경하려는 이유가 있습니다. 이런 판단의 배경을 필요한 만큼 함께 남겨야, 에이전트가 새로운 상황에서도 기준을 적용하기 쉬워집니다.
이름만 보면 둘 다 자동화 기능처럼 느껴집니다. 실제 구성에서는 역할을 나누면 이해하기 쉽습니다.
구성 요소 | 맡길 역할 | 예시 |
|---|---|---|
CLAUDE.md·Rules | 프로젝트의 공통 맥락과 규칙 | 예외 응답 규약, 테스트 명령 |
Skills | 반복해서 수행할 작업 절차 | 버그 조사·수정·검증 순서 |
Hooks | 정해진 이벤트에 연결할 동작 | 파일 수정 후 검사 실행 |
CLI·MCP | 작업에 필요한 도구와 데이터 접근 | 테스트 실행, 이슈·로그 조회 |
Skill은 SKILL.md에 지침을 작성해 사용하는 기능입니다. 관련 작업에서 Claude가 불러오도록 구성하거나, 사용자가 /스킬이름으로 직접 호출할 수 있습니다. 필요한 시점에 상세 절차를 제공할 수 있다는 점에서 매번 긴 프롬프트를 붙여 넣는 수고를 줄여줍니다. [2]
Hook은 Claude Code의 특정 이벤트에 연결하는 동작입니다. 이 글에서는 이벤트가 발생하면 셸 스크립트를 실행하는 command Hook을 사용하겠습니다. [3]
예를 들면 다음처럼 역할을 나눌 수 있습니다.
“실패 원인을 조사하고 수정하는 순서”는 Skill에, “파일 수정 후 검사를 실행하는 시점”은 Hook에 넣습니다.
검사 결과를 해석하고 다음 수정을 결정하는 것은 에이전트의 역할입니다. Hook을 설정했다고 해서 버그 수정 자체의 정확성이 보장되는 것은 아닙니다.
에러 수정부터 시작한다면 먼저 “내가 이 문제를 직접 맡았을 때 무엇을 확인할까?”를 적어볼 수 있습니다. 기대 동작을 확인하고, 로그를 읽고, 원인이라고 의심한 부분을 재현해 볼 것입니다. 수정 후에는 같은 문제가 사라졌는지와 주변 동작에 영향이 없는지를 확인하겠죠.
이 판단 순서를 Skill로 옮겨 보겠습니다. 예를 들어 수정 전에 재현하는 이유는, 추측한 원인이 실제 문제와 연결되는지 확인하기 위해서입니다. 절차마다 이런 목적이 있어야 결과를 검토할 때도 무엇을 봐야 하는지 분명해집니다.
이번 예시의 순서는 다음과 같습니다.
기대 동작과 실제 동작을 비교합니다.
로그와 관련 코드를 확인합니다.
가능한 경우 실패하는 테스트로 문제를 재현합니다.
원인에 해당하는 부분을 수정합니다.
재현 테스트와 관련 테스트를 실행합니다.
변경 내용과 남은 불확실성을 보고합니다.
프로젝트의 .claude/skills/fix-bug/SKILL.md에 다음과 같이 작성합니다.
---
name: fix-bug
description: 재현 방법이나 실패 로그가 있는 버그를 조사하고 수정할 때 사용한다.
disable-model-invocation: true
---
# 버그 수정
요청 내용: $ARGUMENTS
## 진행 절차
1. CLAUDE.md와 관련 규칙을 읽는다.
2. 기대 동작과 실제 동작을 정리한다.
3. 관련 코드, 테스트, 제공된 로그를 확인한다.
4. 가능한 경우 수정 전에 실패하는 재현 테스트를 만든다.
5. 확인된 원인을 해결하는 범위로 코드를 수정한다.
6. 재현 테스트와 영향을 받는 관련 테스트를 실행한다.
7. 최종 diff에서 불필요한 변경이 없는지 확인한다.
## 판단 기준
- 로그에서 확인한 사실과 아직 확인하지 못한 원인 가설을 구분한다.
- 수정 방향은 재현 결과나 관련 코드의 근거를 바탕으로 정한다.
- 테스트는 기대 동작을 검증해야 하며, 잘못된 동작에서는 실패해야 한다.
- 예상과 다른 결과가 나오면 원인 가설을 다시 확인한다.
## 중단 및 질문 기준
- 기대 동작이 모호하면 구현 전에 질문한다.
- 동일한 실패를 해결하려는 수정이 3회 연속 실패하면
시도한 내용과 추가로 필요한 정보를 보고한다.
- 외부 서비스나 테스트 환경 문제는 코드 결함과 구분한다.
- 테스트를 삭제하거나 기대값을 임의로 낮춰 통과시키지 않는다.
## 완료 보고
- 원인과 판단 근거
- 변경 사항
- 실행한 검증과 결과
- 실행하지 못한 검증과 이유disable-model-invocation: true는 이 Skill을 사용자가 명시적으로 호출하도록 하는 설정입니다. 예시에서는 버그 수정 절차를 의도적으로 시작하기 위해 넣었습니다. [2]
호출은 이렇게 할 수 있습니다.
/fix-bug 상품 목록 API에 지원하지 않는 sort 값을 전달하면
500이 발생합니다. 프로젝트의 기존 예외 응답 형식에 맞춰
400을 반환하도록 수정하고, 회귀 테스트를 추가해주세요.이 요청에는 기존 응답 형식과 재발 방지를 위한 테스트까지 작업 범위에 포함했습니다. 제가 직접 수정할 때 챙기려는 기준을 에이전트에게도 전달한 것입니다.
첫 실행에서는 최종 코드와 함께 판단의 근거도 검토합니다. 실제로 문제를 재현했는지, 원인에 맞는 부분을 수정했는지, 추가한 테스트가 기존 오류를 잡아낼 수 있는지를 확인합니다.
Skill에 적은 재시도 횟수는 모델이 따라야 하는 지침입니다. 실행 횟수나 비용에 엄격한 상한이 필요하다면, 별도의 실행 제어 코드에서도 제한해야 합니다.
작업 절차를 만들어도 작은 검사는 반복해서 빠뜨릴 수 있습니다. 이런 검사부터 Hook에 연결해 보겠습니다.
여기서는 Claude가 Write 또는 Edit 도구로 파일을 수정한 뒤, Git이 추적하는 변경의 공백 오류 등을 검사하는 예시를 사용합니다. 기능 테스트보다 가볍고, Hook의 동작을 확인하기에도 단순합니다.
프로젝트의 .claude/settings.json에 다음 설정을 추가합니다. 기존 설정이 있다면 hooks 항목을 병합해야 합니다.
{
"hooks": {
"PostToolUse": [
{
"matcher": "Write|Edit",
"hooks": [
{
"type": "command",
"command": "bash \"$CLAUDE_PROJECT_DIR/.claude/hooks/check-diff.sh\"",
"timeout": 10
}
]
}
]
}
}연결할 .claude/hooks/check-diff.sh는 다음과 같습니다. Bash와 Git이 있는 환경을 가정합니다.
#!/usr/bin/env bash
set -u
cd "${CLAUDE_PROJECT_DIR:?}" || exit 1
# 이 예시에서는 이벤트 입력을 사용하지 않습니다.
cat >/dev/null
check_output=$(git diff --check 2>&1)
check_status=$?
if [ "$check_status" -eq 0 ]; then
exit 0
fi
printf '%s\n' "$check_output" >&2
printf '%s\n' \
'변경 사항 검사에 실패했습니다. 출력에서 원인을 확인해주세요.' >&2
exit 2PostToolUse에서 종료 코드 2를 반환하면 stderr의 내용을 Claude에게 전달할 수 있습니다. 이미 끝난 파일 수정을 취소하는 동작은 아닙니다. 에이전트가 피드백을 받아 다음 행동을 판단하도록 연결하는 것입니다. [3]
이 예시에는 범위가 있습니다. git diff --check는 기본적으로 추적 중인 파일의 스테이징되지 않은 변경을 검사합니다. 새 미추적 파일이나 스테이징된 변경까지 모두 확인하는 검사가 아니며, 기능의 정확성도 판단하지 않습니다. 또한 방금 수정한 파일뿐 아니라 다른 추적 파일에 남아 있던 변경도 함께 검사하므로, 작업 전부터 있던 공백 오류가 보고될 수 있습니다. 위 matcher는 Write와 Edit 호출에만 반응하며, Bash 명령 등을 통한 수정은 이 설정의 대상이 아닙니다.
적용 여부는 테스트용 저장소에서 다음 순서로 확인할 수 있습니다.
Git이 추적 중인 테스트 파일을 준비하고, 변경 사항이 없는 상태를 확인합니다.
Claude Code에 해당 파일을 Edit 도구로 수정하면서 줄 끝 공백을 넣도록 요청합니다.
검사 메시지가 전달되는지 확인한 뒤 공백을 제거하게 하고, 후속 검사에 문제가 없는지 확인합니다.
이 과정에서 설정 적용과 피드백 전달까지 확인해야 합니다. 스크립트를 터미널에서 실행한 결과만으로 Claude Code와의 연결까지 확인했다고 볼 수는 없습니다.
프로젝트에 적용할 때는 이 부분을 확장하면 됩니다. Hook 입력의 파일 경로를 읽어 해당 파일만 검사하거나, 프로젝트에서 사용하는 포맷터·린터를 연결하는 방식입니다.
다만 파일을 수정할 때마다 전체 통합 테스트를 실행하면 기다리는 시간이 커집니다. 저는 자동화 구성을 다음처럼 나누는 편이 합리적이라고 생각합니다.
시점 | 검사 예시 |
|---|---|
파일 수정 직후 | 빠른 형식 검사, 파일 단위 린트 |
하나의 기능 구현 후 | 관련 단위 테스트, 컴파일 |
작업 완료 전 | 요구사항 확인, 관련 통합 테스트, diff 검토 |
PR의 CI | 팀에서 정한 필수 검사 |
작업 종료를 검사하는 Stop Hook도 사용할 수 있습니다. 다만 실패할 때마다 계속 작업하게 만들면 불필요한 반복이 생길 수 있으므로, stop_hook_active 같은 상태와 중단 조건을 고려해야 합니다. [3]
검사를 추가한 뒤에는 오류를 발견하는 효과와 검사로 인해 늘어난 대기 시간을 함께 확인하면 됩니다.
버그 수정이 “잘못된 동작을 기대 동작으로 바꾸는 일”이라면, 기능 개발은 “아직 없는 기대 동작을 구현하는 일”입니다. 둘 다 목표와 검증 기준이 필요합니다.
예를 들어 상품 목록에 카테고리 필터를 추가한다고 가정해 보겠습니다.
상품 목록 API에 선택적 categoryId 필터를 추가해주세요.
기대 동작
- categoryId를 생략하면 기존 조회 동작을 유지합니다.
- categoryId를 전달하면 해당 카테고리 상품만 조회합니다.
- 존재하지 않는 카테고리는 빈 목록을 반환합니다.
- 기존 페이지네이션과 정렬을 유지합니다.
진행 방식
- 먼저 기존 조회 코드와 테스트를 읽고 변경 계획을 설명해주세요.
- 기존 API 응답 구조와 프로젝트 규칙을 따라 구현해주세요.
- 각 기대 동작을 검증하고 문서도 갱신해주세요.
- 불명확한 도메인 규칙은 구현 전에 질문해주세요.여기서 “존재하지 않는 카테고리는 빈 목록”은 이 예제에서 선택한 요구사항입니다. 서비스에 따라 404나 400을 반환하는 것이 맞을 수도 있습니다. 이런 결정은 에이전트가 추측하도록 두기보다 먼저 정하는 편이 좋습니다.
버그 수정에서 검증한 방식은 이런 작은 기능 추가에도 적용해 볼 수 있습니다. 기존 코드를 먼저 이해하고, 근거를 가지고 변경하며, 기대 동작을 검증한다는 기준은 이어집니다. 여기에 새 요구사항을 해석하고 설계 방향을 정하는 과정이 추가됩니다.
한두 개의 작은 기능에서 이 흐름이 유효했는지 확인하고, 반복되는 절차가 보이면 기능 개발용 Skill로 정리할 수 있습니다. 절차는 기존 코드 탐색, 변경 계획, 구현, 테스트, 문서 갱신 순서로 구성합니다.
반면 각 작업의 카테고리 규칙이나 응답 예시처럼 달라지는 정보는 요청에 남깁니다. 공통 절차는 Skill에, 이번 작업의 구체적인 요구사항은 입력에 담는 방식입니다.
새 기능에서는 테스트 통과만으로 충분하지 않을 때도 있습니다. API라면 실제 요청과 응답을 확인하고, UI라면 화면을 조작해 확인해야 할 수 있습니다. 무엇을 검증했는지와 무엇을 아직 확인하지 못했는지를 완료 보고에 함께 남겨야 합니다.
개발 업무에는 코드 작성 이후의 일도 많습니다. 리뷰 요청, 문서 갱신, 커밋 메시지, PR 설명 작성까지 이어집니다.
이 작업에도 입력과 결과를 명확하게 정할 수 있습니다.
코드 리뷰라면 “코드 좋아?” 대신 최종 diff와 요구사항을 제공하고, 오류 가능성·경계 조건·기존 동작 변화에 집중하도록 요청합니다. 지적에는 관련 파일과 판단 근거를 포함하게 만듭니다.
PR 설명은 처음 세운 계획보다 실제 변경 사항을 기준으로 작성해야 합니다. 구현 중 방향이 달라졌는데 PR에는 예전 계획이 남는 일이 생길 수 있기 때문입니다. 실행하지 않은 테스트가 검증 항목에 들어가지 않도록 실제 실행 결과도 함께 전달합니다.
외부 데이터가 필요하면 CLI나 MCP를 연결할 수 있습니다. 예를 들어 이슈의 재현 절차나 관측 도구의 오류 로그를 가져와 버그 수정 작업의 입력으로 사용할 수 있습니다. 이때 원본 로그 전체보다 발생 시각, 관련 요청, 오류 메시지, 재현 조건처럼 판단에 필요한 정보를 제공하는 편이 작업 범위를 잡기 쉽습니다.
탐색 범위가 큰 작업은 탐색·구현·검증 역할을 나누는 구성도 고려할 수 있습니다. 다만 여러 에이전트를 사용한다면 어떤 파일을 누가 수정하는지, 결과를 누가 통합하는지까지 정해야 합니다. 역할을 나누는 비용이 줄어드는 작업 시간보다 커지지 않는지 확인할 필요가 있습니다.
제가 확인하고 싶은 것은 “내가 중요하게 생각하는 판단과 검증을 에이전트가 수행했는가”, 그리고 “그 방식이 실제 업무에 도움이 되었는가”입니다. 두 가지를 함께 봐야 다음 단계의 자동화로 넓힐 근거가 생깁니다.
처음에는 비슷한 크기의 작업 몇 개를 골라 다음 항목을 기록해 보면 좋겠습니다.
관찰할 항목 | 확인하려는 것 |
|---|---|
작업 완료까지의 전체 시간 | 대기·검증·재작업까지 포함한 처리 속도 |
사람이 개입한 시간과 이유 | 반복 지시가 줄었는지, 어느 단계가 막히는지 |
원인 판단과 수정의 근거 | 확인한 사실을 바탕으로 변경했는지 |
수정 후 다시 발견된 오류 | 검증이 충분했는지 |
테스트와 실행 확인 결과 | 완료 판단의 근거가 있는지 |
사용 비용 | 줄어든 업무에 비해 비용이 적절한지 |
한 번 잘된 결과만 보고 효과를 판단하기는 어렵습니다. 환경 문제로 중단된 작업, 요구사항을 잘못 해석한 작업도 함께 기록해야 다음에 개선할 부분이 보입니다.
예를 들어 테스트 실행 전에 항상 DB 설정을 다시 설명하고 있다면 실행 문서를 보완할 수 있습니다. 같은 예외 응답 규칙을 반복해서 틀린다면 규칙 문서와 테스트를 보강할 수 있습니다.
이때 제 방식 자체도 검토 대상입니다. 에이전트가 다른 접근을 제안했더라도 근거가 있고 더 적은 변경으로 문제를 해결한다면 받아들일 수 있습니다. 제가 가진 판단 기준을 출발점으로 삼되, 검증하면서 그 기준도 함께 개선하는 것입니다.
반대로 특정 작업에만 필요한 지침을 공통 규칙에 계속 추가하면 다른 작업까지 복잡해집니다. 반복해서 나타나는 문제인지 확인한 뒤 적절한 위치에 반영하는 편이 좋겠습니다.
여기까지 구성하면 개발자가 직접 입력하는 코드의 양은 줄어들 수 있습니다. 대신 해야 할 일이 더 분명해집니다.
어떤 문제를 해결할지 정하고, 필요한 맥락을 제공하고, 결과를 확인할 기준을 만듭니다. 반복되는 실패를 발견하면 작업 절차나 검증 방법을 개선합니다.
제가 생각하는 자동화는 이처럼 제가 문제를 바라보고 해결하는 사고 과정을 에이전트의 작업에 담아가는 일입니다. 문제를 이해하고, 근거를 찾고, 변경하고, 결과를 검증하는 방식까지 함께 옮기는 것입니다.
이를 위해서는 제가 평소 당연하게 여기던 판단을 설명할 수 있어야 합니다. 어떤 로그를 먼저 보는지, 언제 수정 범위를 줄이는지, 무엇을 확인해야 완료라고 말하는지를 구체적으로 적어 보는 것부터 시작할 수 있습니다.
이 글에서 자동화 대상으로 삼은 것은 정의된 범위 안에서의 코드 탐색, 수정, 검사 실행, 결과 정리입니다. 무엇을 올바른 동작으로 볼지, 어떤 설계상의 절충을 받아들일지, 검증 결과가 실제 반영에 충분한지는 개발자가 판단해야 합니다. 자동화할 범위는 이런 판단 기준이 얼마나 명확하고 결과를 얼마나 확인할 수 있는지에 따라 달라집니다.
저는 이렇게 하나씩 자동화하고 검증하는 방식이 괜찮은 출발점이라고 생각합니다. 그 과정에서 에이전트의 작업 방식도 다듬어지고, 제가 해오던 엔지니어링도 더 명확해질 수 있을 것입니다.
많이 부족한 저와 글이지만 읽어주셔서 감사합니다. 좋은 인사이트 공유와 피드백은 언제든 환영합니다 :)