7부 38장. AI와 함께 디버깅하고 리팩터링하기
7부 38장. AI와 함께 디버깅하고 리팩터링하기
코딩 AI를 처음 써 본 사람은 대개 "새 코드를 빨리 만들어 주는 도구"로 기억한다. 물론 그것도 맞다. 하지만 실제 개발에서 시간을 더 많이 잡아먹는 일은 의외로 새로 짜는 일이 아니다. 이미 있는 코드를 읽고, 왜 깨졌는지 찾고, 여기저기 꼬인 구조를 정리하고, 다시 테스트해서 안심할 수 있는 상태로 만드는 일이다. 많은 팀에서 진짜 시간이 사라지는 곳은 바로 여기다.1
그래서 실전에서 강한 사람은 AI에게 "만들어"만 시키지 않는다. "왜 깨졌는지 설명해 봐", "어디서부터 어긋났는지 좁혀 봐", "겉동작은 그대로 두고 내부만 정리해 봐"라고 시킨다. 이 장의 핵심도 거기에 있다. AI는 코드를 새로 쓰는 데만 유용한 것이 아니라, 고치고 다듬는 일에서도 아주 강력한 협업자가 될 수 있다.
이미지 출처: How to effectively utilise AI to enhance large-scale refactoring
디버깅에서 AI가 진짜 빛나는 순간
버그를 고칠 때 가장 흔한 실수는 너무 빨리 해결책부터 달려드는 것이다. 에러 메시지를 보자마자 "이거 고쳐 줘"라고 던지면, AI는 꽤 그럴듯한 패치를 내놓는다. 문제는 그 패치가 원인을 제대로 짚지 못한 채 증상만 눌러 버리는 경우가 많다는 점이다. 그러면 버그는 잠깐 사라진 듯 보이다가 다른 모습으로 다시 튀어나온다.2
좋은 디버깅은 의사처럼 해야 한다. 약부터 먹이는 것이 아니라 먼저 진단부터 해야 한다. AI에게도 같은 태도가 필요하다. 먼저 물어야 할 것은 "무엇을 고치면 될까?"가 아니라 "무엇이 원인인가?"다.3
예를 들어 로그인 버튼이 눌러도 아무 일도 안 일어난다고 해 보자. 이때 나쁜 요청은 이렇다.
"로그인 안 되는데 고쳐 줘."
이 말에는 너무 많은 빈칸이 있다. 콘솔 에러가 있는지, 버튼 클릭 이벤트가 안 타는지, 검증에서 막히는지, 서버 응답이 실패하는지, 성공은 했지만 화면 전환이 안 되는지 전혀 알 수 없다.
더 좋은 요청은 이렇게 바뀐다.
에러 메시지는 없고, 로그인 버튼을 누르면 로딩만 잠깐 보였다가 아무 변화가 없습니다. 기대 동작은 성공 시 대시보드로 이동하는 것입니다. 실제로는 같은 화면에 머뭅니다. 아래는 관련 컴포넌트와 네트워크 로그입니다. 먼저 원인을 추정하고, 가능성 높은 순서대로 설명해 주세요. 아직 코드는 수정하지 마세요.
이렇게 하면 AI는 곧장 망치를 휘두르는 대신, 손전등을 들고 현장을 보기 시작한다.
AI 디버깅의 기본 원칙은 "설명 먼저, 수정은 나중"이다
AI와 함께 버그를 잡을 때 가장 효과적인 습관은 하나다. 고치기 전에 설명시키는 것이다.2 이 한 가지 습관만 들어도 엉뚱한 수정이 크게 줄어든다.
설명 먼저가 중요한 이유는 단순하다. AI는 코드를 처음 보는 외부 협업자와 비슷하기 때문이다. 처음부터 수정하게 하면 가장 흔한 패턴이나 상식적인 버그 유형에 기대어 답을 낸다. 반면 먼저 설명하게 하면, 적어도 현재 코드의 흐름과 기대 동작의 차이를 한 번은 짚고 지나가게 된다.
특히 다음 정보가 함께 들어가면 진단 품질이 확 좋아진다.
정확한 에러 메시지와 스택 트레이스
관련 코드 조각과 호출 흐름
기대한 동작과 실제 동작
최근에 바뀐 점
이미 해 본 시도와 그 결과
이 다섯 가지는 버그 리포트이면서 동시에 AI를 위한 훌륭한 컨텍스트다.3
에러 메시지가 없을 때도 방법은 있다. 그럴수록 더더욱 "무엇이 잘못됐나?"보다 "이 함수가 지금 어떤 순서로 동작하는지 단계별로 설명해 달라"고 요청하는 편이 낫다.2 사람도 흐름을 따라가다 보면 "아, 여기서 상태가 안 바뀌네" 하고 눈이 열리듯, AI도 실행 경로를 따라가며 어긋난 지점을 더 잘 드러낸다.
버그를 잡는 6단계 루프
AI 디버깅은 재주보다 순서가 중요하다. 실전에서는 다음 루프를 기억하면 된다.
증상을 관찰한다. 추측이 아니라 보이는 사실부터 적는다.
재현한다. 어떤 입력과 어떤 순서에서 문제가 생기는지 고정한다.
격리한다. 관련 범위를 줄여 문제 지점을 좁힌다.
설명시킨다. AI에게 원인 후보와 흐름을 먼저 분석하게 한다.
최소 수정한다. 한 번에 크게 뜯지 말고 가장 좁은 수정부터 적용한다.
검증한다. 재현 시나리오와 테스트로 진짜 해결됐는지 확인한다.
이 루프가 중요한 이유는, 버그를 "한 번에 맞히는 퀴즈"로 보지 않게 해 주기 때문이다. 디버깅은 원래 추리소설이 아니라 현장 조사에 가깝다. 단서를 모으고, 범위를 줄이고, 가설을 시험하는 작업이다.4
여기서 AI는 추리 파트너 역할을 잘한다. 로그를 읽고, 가능성 목록을 만들고, 최근 변경 사항과 현재 코드 흐름을 연결해 본다. 하지만 마지막 판정은 여전히 사람이 내려야 한다. 특히 "이 수정이 우리 서비스의 진짜 의도와 맞는가?"는 AI보다 사람이 훨씬 잘 안다.
로그는 AI에게 아주 좋은 먹잇감이다
사람이 보기 싫어하는 긴 로그와 지저분한 콘솔 출력은 오히려 AI가 잘 다루는 영역이다. 여러 서비스 로그가 섞여 있거나, 에러가 연쇄적으로 터졌거나, 같은 요청의 흔적이 군데군데 흩어져 있을 때 사람은 쉽게 지친다. 반면 AI는 이런 자료에서 패턴을 찾는 데 강하다.5
그래서 로그를 붙일 때는 예쁘게 정리하려고 애쓰기보다, 충분한 맥락과 함께 있는 그대로 제공하는 것이 더 낫다. 다만 시간축과 요청 흐름이 보이도록 최소한의 설명은 붙여 주는 편이 좋다. 예를 들면 "로그인 요청 직후 10초 구간의 백엔드 로그", "테스트 실패 시점의 전체 스택 트레이스"처럼 묶어 주면 된다.
AI에게 로그를 줄 때는 이런 식의 요청이 잘 먹힌다.
이 로그를 시간 순서대로 읽고, 사용자에게 보이는 증상과 직접 연결되는 실패 지점을 먼저 찾아 주세요. 그다음 가능한 원인을 높은 가능성부터 3개만 제시해 주세요.
이 요청이 좋은 이유는 두 가지다. 먼저 "무슨 일이 있었는지"를 서술하게 하고, 그다음에야 "왜 그랬는지"를 추정하게 만들기 때문이다. 서술 없는 추정은 늘 위험하다.
막히면 AI에게 로그를 더 넣게 하라
사람 개발자도 어려운 버그를 만나면 로그를 더 심는다. AI와 일할 때도 똑같다. 오히려 더 적극적으로 해 볼 수 있다. AI는 어디에 임시 로그를 넣어야 할지 제안하고, 필요한 경우 직접 디버깅용 출력문을 추가한 뒤, 그 결과를 다시 읽어 원인을 좁혀 갈 수 있다.6
이 방식이 좋은 이유는 억측을 줄여 주기 때문이다. 예를 들어 폼 제출이 안 될 때 AI에게 이렇게 시킬 수 있다.
아직 수정하지 말고, 입력값, 검증 결과, 네트워크 요청 직전 상태를 확인할 수 있는 임시 로그만 추가해 주세요. 그 로그를 기준으로 어떤 가설을 검증하려는지도 함께 적어 주세요.
이렇게 하면 AI는 그냥 고치려 들지 않고, 증거를 더 잘 수집하는 방향으로 움직인다. 디버깅에서 이 차이는 크다. 감으로 고친 코드는 다시 깨지기 쉽고, 증거를 보고 고친 코드는 오래 버틴다.
가능하면 실패하는 테스트를 먼저 만들자
버그 수정에서 가장 좋은 친구는 실패하는 테스트다. 테스트가 있으면 "지금 정말 문제가 재현되는지", "수정 후에 정말 해결됐는지"를 같은 기준으로 비교할 수 있다. AI에게도 이것은 큰 도움이 된다. 애매한 설명보다 실패하는 테스트 하나가 훨씬 정확한 컨텍스트가 되기 때문이다.3
특히 미묘한 버그일수록 그렇다. 시간대 처리, 비동기 순서, 경계값 입력, 상태 꼬임 같은 문제는 말로 설명하면 길어지고 흔들리지만, 재현 테스트로 만들면 훨씬 또렷해진다.
그래서 버그를 고칠 때는 이런 순서가 좋다. 먼저 AI에게 재현 조건을 바탕으로 최소 실패 테스트를 만들게 한다. 그다음 그 테스트를 통과시키는 가장 작은 수정만 하게 한다. 이 방식은 범위를 좁히고, 고쳤다는 착각도 줄여 준다.
한 번에 파일 전체를 갈아엎게 하지 마라
AI가 제일 신나 하는 순간 중 하나는 "제가 더 깔끔하게 다시 써 드릴게요" 모드에 들어갈 때다. 보기에는 멋지지만, 디버깅에서는 위험한 경우가 많다. 버그 하나 잡으려다가 구조를 통째로 바꾸면, 원래 문제는 가려지고 새 문제가 딸려온다.4
그래서 버그 수정에서는 늘 최소 수정을 먼저 요구하는 편이 좋다. 예를 들면 이런 표현이다.
원인을 설명한 뒤, 문제를 해결하는 가장 작은 패치부터 제안해 주세요. 관련 없는 정리나 리팩터링은 하지 마세요. 수정 범위는 해당 함수와 테스트로 우선 제한해 주세요.
이 요청은 AI의 과한 성실함을 제어한다. 때로는 일을 많이 하는 것이 좋은 것이 아니라, 딱 필요한 만큼만 하는 것이 더 좋은 일이다.
디버깅이 길어질수록 대화보다 상태 관리가 중요하다
버그가 어려울수록 대화는 길어진다. 그런데 대화가 길어진다고 해서 이해가 깊어지는 것은 아니다. 오히려 오래 끌수록 맥락이 흐려지고, 이미 버린 가설이 다시 살아나고, AI가 옛 정보를 끌고 다니는 일이 생긴다.
이럴 때는 중간 정리가 필요하다. 지금까지 확인한 사실, 버린 가설, 아직 열린 가설, 다음 실험 계획을 짧게 다시 써서 AI와 공유하면 좋다. 에이전트형 도구를 쓴다면 아예 작업 메모나 상태 파일처럼 지속되는 컨텍스트를 두는 것도 도움이 된다. 실제 대규모 코드 정리 작업에서도 이런 지속 컨텍스트가 품질과 일관성을 높이는 데 큰 역할을 했다.7
간단히 말해, 디버깅이 길어질수록 "많이 말하기"보다 "현재까지 확정된 사실을 잘 정리하기"가 더 중요하다.
리팩터링은 버그 수정과 닮았지만 목표가 다르다
이제 구조 개선 쪽으로 넘어가 보자. 버그 수정은 깨진 동작을 원래대로 되돌리는 일이고, 리팩터링은 겉으로 보이는 동작은 유지한 채 내부 구조를 더 좋게 만드는 일이다. 둘은 비슷해 보이지만, AI에게 줄 지시는 분명히 달라야 한다.
버그 수정에서 핵심은 원인 진단이다. 반면 리팩터링에서 핵심은 불변 조건이다. 즉, "무엇은 바꿔도 되지만 무엇은 바뀌면 안 되는가"를 먼저 고정해야 한다.
그래서 리팩터링 요청은 이런 느낌이 좋다.
이 함수는 동작은 맞지만 책임이 너무 많아 읽기 어렵습니다. 외부 동작과 공개 인터페이스는 그대로 유지한 채, 역할을 더 작게 나누는 방향으로 정리해 주세요. 먼저 리팩터링 옵션 2개를 장단점과 함께 제안하고, 그다음 가장 보수적인 안으로 진행해 주세요.
이 프롬프트의 좋은 점은 "깔끔하게 해 줘"보다 훨씬 안전하다는 데 있다. AI는 미용사가 아니라 외과 의사처럼 움직여야 한다. 보기 좋게 바꾸는 것이 목적이 아니라, 행동은 유지하면서 구조만 더 건강하게 만드는 것이 목적이기 때문이다.1
AI와 리팩터링할 때는 작은 단위가 정답이다
기술 부채는 대청소 한 번으로 끝나는 일이 아니다. 현실에서는 기능 개발 틈틈이 조금씩 줄여 가는 편이 훨씬 잘 된다. AI도 이 방식에서 힘을 발휘한다. 거대한 "전면 개편"보다, 함수 하나, 모듈 하나, 패턴 하나를 잡아 점진적으로 정리할 때 훨씬 안정적이다.1
실전에서는 다음 질문으로 범위를 정하면 좋다.
지금 가장 읽기 어려운 함수는 무엇인가
중복이 가장 많이 보이는 부분은 어디인가
테스트가 있거나 추가하기 쉬운 경계는 어디인가
수정 영향이 비교적 좁은 모듈은 무엇인가
이 질문으로 대상을 고르면, AI가 낸 제안도 검토하기 쉬워진다. 한 번에 저장소 전체를 고치게 하면 멋있어 보일 수는 있어도, 그 순간부터 사람 검토자는 지옥문을 연 셈이다.
큰 리팩터링일수록 "탐색 → 배치 작업 → 검증"으로 나눠라
대규모 코드 정리에서는 AI를 그냥 스크립트 생성기로만 쓰면 오히려 일이 늘 수 있다. 실제로도 처음에는 "AI가 자동화 스크립트를 다 짜서 한 번에 정리하면 되지 않을까?"라고 생각하기 쉽다. 그런데 저장소가 크고 패턴이 여러 갈래로 퍼져 있으면, 진짜 어려운 부분은 단순 치환이 아니라 죽은 코드 찾기, 간접 영향 읽기, 예외 판단하기 같은 데 있다.7
그래서 큰 리팩터링에서는 보통 세 단계가 더 안전하다.
먼저 AI에게 패턴을 탐색시키고, 어디에 무엇이 퍼져 있는지 목록을 만들게 한다. 그다음 작은 묶음으로 배치 작업을 하게 한다. 예를 들어 패키지 하나, 폴더 하나, 기능 하나씩 처리하는 식이다. 마지막으로 각 묶음마다 테스트와 리뷰로 검증한다. 이 과정을 반복하면서 프롬프트와 규칙을 조금씩 다듬으면 점점 더 안정적으로 속도가 붙는다.7
쉽게 말해, 대형 리팩터링은 삽 한 번으로 산을 깎는 일이 아니라, 구획을 나눠 조금씩 정리하는 토목공사에 가깝다.
AI가 특히 잘하는 리팩터링, 사람이 꼭 봐야 하는 리팩터링
AI는 패턴을 읽는 데 강하다. 그래서 다음과 같은 정리 작업에서는 꽤 믿을 만하다.1
중복 로직을 함수로 추출하기
너무 긴 함수를 작은 책임 단위로 나누기
이름과 스타일의 불일치를 정리하기
빠진 테스트 후보를 찾기
명백한 죽은 코드나 불필요한 분기를 드러내기
반대로 사람이 반드시 깊게 봐야 하는 부분도 있다.
이 코드가 실제 비즈니스 규칙을 그대로 지키는가
겉보기엔 같아도 미묘한 동작 변화가 생기지 않았는가
성능 최적화가 엉뚱한 제약을 깨지 않았는가
여러 파일에 걸친 변경이 장기적인 구조에 맞는가
AI가 제안한 리팩터링은 종종 "보기에는 더 좋아 보이는데 우리 서비스에는 맞지 않는" 함정이 있다. 예를 들어 공통화가 과해서 오히려 읽기 어려워지거나, 일반화가 지나쳐 실제 도메인 의미가 흐려지는 경우다. 이런 판단은 여전히 사람 몫이다.
디버깅과 리팩터링을 같이 할 때의 함정
버그를 고치다 보면 "이참에 구조도 좀 정리할까?"라는 유혹이 생긴다. 반대로 리팩터링하다 보면 숨어 있던 버그도 보인다. 둘이 완전히 분리되는 일은 드물다. 다만 한 작업 안에서 둘을 구분하지 않고 섞는 것은 위험하다.
가장 흔한 실패 패턴은 이렇다. 버그를 잡으려다가 파일 구조를 갈아엎고, 리팩터링을 한다며 동작을 은근히 바꾼다. 그리고 마지막에는 무엇이 버그 수정이고 무엇이 구조 개선인지 아무도 설명하지 못한다.
이 문제를 피하려면 AI에게 작업 성격을 명확히 선언해야 한다. 예를 들어 이렇게 구분한다.
이번 작업의 1차 목표는 재현되는 버그 수정입니다. 구조 개선 아이디어가 있더라도 먼저 최소 수정으로 해결해 주세요. 리팩터링 제안은 별도 섹션으로 분리해서 적어 주세요.
또는 반대로 이렇게 말할 수도 있다.
이번 작업은 리팩터링이 목적입니다. 외부 동작은 유지해야 하며, 동작 변경이 필요해 보이는 부분은 수정하지 말고 위험 요소로만 보고해 주세요.
이렇게 선을 그어 주면 AI도 훨씬 덜 헷갈린다.
상호작용형 디버깅 도구를 쓸수록 AI는 더 강해진다
최근의 코딩 에이전트나 CLI 도구가 강력한 이유는 단순히 답변을 잘해서가 아니다. 파일을 읽고, 테스트를 돌리고, 터미널 명령을 실행하고, 필요하면 디버거까지 써서 추가 정보를 스스로 수집할 수 있기 때문이다. 연구 흐름에서도, 이런 상호작용형 디버깅 도구를 쓸 수 있을 때 에이전트의 문제 해결력이 더 좋아진다는 신호가 계속 나오고 있다.8
이 말은 곧, 좋은 코딩 AI 활용은 "정답을 한 번에 받아내는 기술"이 아니라는 뜻이다. 오히려 "필요한 정보를 더 모으고, 가설을 시험하고, 다시 검증하는 루프를 얼마나 잘 돌리느냐"에 가깝다. 즉, AI를 마술사처럼 대하면 실망하고, 조사관처럼 쓰면 점점 강해진다.
이런 경우에는 고치기보다 다시 짜게 하는 편이 낫다
모든 버그를 끝까지 디버깅할 필요는 없다. 때로는 다시 만드는 편이 더 싸다. AI와 일할 때도 이 판단이 중요하다.
다음과 같은 경우에는 재생성이 더 나을 수 있다.
수정 시도가 여러 번 실패했는데 같은 유형의 문제가 반복될 때
코드의 기본 구조 자체가 잘못 잡혀 있을 때
버그가 특정 함수가 아니라 전체 설계에서 나온 것일 때
AI가 계속 넓은 범위의 임시방편만 제안할 때
반대로 버그 지점이 비교적 좁고, 재현 조건이 선명하고, 실패 테스트가 있고, 기존 구조를 살릴 가치가 있다면 디버깅이 더 낫다. 중요한 것은 고집이 아니라 비용 감각이다. 한 군데 금 간 컵은 붙이면 되지만, 바닥이 없는 컵이라면 새로 만드는 편이 빠르다.
실전에서 바로 쓰기 좋은 요청 패턴
디버깅과 리팩터링에서 자주 잘 먹히는 요청 문장을 몇 개만 소개해 보자.
버그 추적용
아래 증상을 기준으로 원인 후보를 3개만 제시하고, 각각 어떻게 확인할지 진단 절차를 적어 주세요. 아직 코드는 수정하지 마세요.
이 에러 로그와 관련 코드를 보고, 기대 동작과 실제 동작이 어디서 갈라지는지 단계별로 설명해 주세요.
최소 실패 테스트를 먼저 작성하고, 그 테스트를 통과시키는 가장 작은 수정만 제안해 주세요.
구조 개선용
이 함수의 외부 동작은 유지한 채, 가독성과 책임 분리를 개선하는 리팩터링 옵션을 2개 제안해 주세요. 장단점도 함께 적어 주세요.
중복 로직 제거가 목표입니다. 공개 인터페이스는 바꾸지 말고, 변경 범위는 이 모듈과 관련 테스트로 제한해 주세요.
구현 전에 어떤 파일이 영향을 받는지 먼저 조사하고, 실제 수정은 가장 보수적인 범위로 진행해 주세요.
이런 문장은 화려하지 않지만 실전에서 강하다. AI를 멋지게 자극하기보다, 안전하게 일하게 만드는 문장이기 때문이다.
결국 중요한 것은 "증거 있는 수정"이다
AI와 함께 디버깅하고 리팩터링할 때 가장 경계해야 할 것은, 그럴듯함에 속는 것이다. 설명이 매끈하고 패치가 예뻐 보여도, 재현 조건이 사라졌는지, 테스트가 통과하는지, 실제 사용자 흐름이 회복됐는지 확인하지 않으면 믿으면 안 된다.5
이 기준은 생각보다 강력하다. 버그 수정에서는 "문제가 재현되던 입력에서 이제 정말 안 깨지는가"를 본다. 리팩터링에서는 "겉동작이 같다는 증거가 있는가"를 본다. 둘 다 핵심은 같다. 느낌이 아니라 증거로 끝낸다는 것이다.
AI는 이 과정에서 엄청난 속도를 준다. 원인 후보를 빨리 내고, 관련 파일을 넓게 읽고, 테스트 초안을 만들고, 작은 패치를 여러 번 시도할 수 있다. 하지만 그 속도가 가치가 되려면, 사람 쪽에서 기준을 세워야 한다. 무엇이 해결인지, 무엇이 위험인지, 무엇이 아직 확인되지 않았는지를 끝까지 붙들어야 한다.
그렇게만 하면 AI는 단순한 코드 생성기가 아니라, 버그를 추적하고 구조를 개선하는 실전 수리공이 된다. 새 집을 짓는 데만 쓰는 것이 아니라, 삐걱거리는 문을 고치고, 엉킨 배선을 정리하고, 오래된 배관을 갈아 끼우는 데까지 함께 쓸 수 있는 존재가 되는 것이다. 그리고 많은 개발 현장에서, 사실 더 값진 쪽은 바로 그 후자다.
이 장의 정리
AI는 새 코드를 만드는 데만 강한 것이 아니다. 디버깅에서는 원인 후보를 좁히고, 로그를 읽고, 재현 테스트를 만들고, 최소 수정안을 제안하는 데 큰 힘을 발휘한다.
다만 좋은 습관이 필요하다. 설명 먼저, 수정은 나중이다. 증상과 재현 조건, 기대와 실제 결과, 로그와 최근 변경 사항을 함께 주고 먼저 원인을 분석하게 해야 한다.
리팩터링에서는 특히 불변 조건이 중요하다. 외부 동작, 공개 인터페이스, 테스트 통과 같은 기준을 먼저 고정하고, 작은 범위부터 점진적으로 정리해야 한다.
또한 디버깅과 리팩터링 모두에서 핵심은 같다. 크게 고치기 전에 좁게 확인하고, 느낌보다 증거를 믿고, 한 번에 끝내려 하지 말고 조사와 검증의 루프를 돌리는 것이다.
AI와 함께 코드를 잘 고치는 사람은 "수정해 줘"를 잘 말하는 사람이 아니다. 원인을 좁히고, 범위를 지키고, 증거로 검증하는 사람이다. 그 감각이 생기면, AI는 코드를 대신 써 주는 도구를 넘어 코드를 함께 고쳐 가는 믿을 만한 동료가 된다.
참고
1AI for Developers: Code Review, Debugging, Documentation, and Integrated Workflows
2AI Coding Workflow Mastery: Debug, Refactor, Ship
3AI for Debugging: Step-by-Step Workflow
5Lesson 10: Debugging with AI Agents
6Debugging Workflow for Agentic Coding
7How to effectively utilise AI to enhance large-scale refactoring
8Debug-gym: an environment for AI coding tools to learn how to debug code like programmers
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.