AI에게 삭제를 맡기기 전에 — 스킬 중복을 안전하게 검증한 방법

📝 한줄 요약

여러 AI 에이전트에 흩어진 36개 강의 관련 스킬을 정리하면서, 비슷해 보인다는 이유로 바로 지우지 않았다. 실제 호출 관계를 증거지도로 만들고, 격리된 시험환경에서 역할 경계를 검증한 뒤 30개로 정리했다. 삭제한 패키지는 0개였다.

바쁘시면 이것만 읽어도 됩니다:

• 비슷한 스킬이 여러 프로필에 쌓여 무엇이 실제로 필요한지 한눈에 알기 어려웠다.

• AI가 조사부터 삭제까지 자동으로 처리할 수 있을 것 같았지만, 어디까지 맡겨도 안전한지 확신이 없었다.

• 36개 스킬을 이름이 아니라 caller·wrapper·publisher의 연결관계로 펼쳐 보았다.

• 가장 중요한 발견은 중복의 본질이 스킬 개수가 아니라 요청의 즉시 종착점과 역할 경계라는 점이었다.

• 첫 개선안은 성능이 좋아졌지만 안전 기준을 넘지 못해 실제 적용을 중단했다.

• 최종적으로 활성 인스턴스는 36개에서 30개가 됐지만 실제 삭제는 0건이었다.

• 독자가 재사용할 수 있도록 증거지도 점검표와 프롬프트를 함께 정리했다.

🎯 이런 분들께 도움이 됩니다

• 여러 AI 에이전트와 스킬을 함께 운영하는 비개발자

• 회사나 개인 환경에서 AI 자동화를 늘리다가 중복과 충돌을 겪는 사람

• AI에게 파일이나 설정 정리를 맡기고 싶지만 삭제 사고가 걱정되는 사람

• 프롬프트와 자동화가 늘어나면서 “무엇이 진짜 필요한가?”를 다시 점검하고 싶은 사람

😫 문제 상황 — 비슷해 보이는데, 무엇을 지워도 될지 몰랐다

강의 영상을 처리하는 AI 작업환경에는 여러 전문 에이전트가 있었다. 전체 흐름을 조율하는 에이전트, 음성과 영상을 전사하는 에이전트, 강의를 지식으로 정리하는 에이전트, 법률강의를 구조화하는 에이전트가 각자 역할을 맡고 있었다.

시스템이 커질수록 강의와 관련된 스킬도 여러 프로필에 쌓였다. 이름이 같거나 본문이 매우 비슷한 스킬도 있었고, 서로 다른 이름인데 실제 책임이 겹쳐 보이는 스킬도 있었다.

가장 불편했던 점은 두 가지였다.

첫째, 무엇이 실제로 필요한 스킬인지 한눈에 알 수 없었다. 둘째, 중복처럼 보인다고 함부로 지웠다가 에이전트의 호출 경로나 역할 분담이 깨질까 불안했다.

처음 요청은 단순한 삭제 지시가 아니었다.

이거 말고 우리 에이전트들이 보유하고 있는 강의 recap, 정리 관련 스킬들을 x-ray로 검사하는 것은 어때?

이 질문에서 작업이 시작됐다.

처음 확인한 범위는 다음과 같았다.

겉으로는 파일 비교 작업처럼 보였다. 하지만 실제로는 “비슷한 파일을 찾는 일”보다 “각 파일이 시스템에서 어떤 관계를 맺고 있는지 확인하는 일”에 가까웠다.

🌱 처음에는 무엇을 몰랐나

처음에는 AI가 조사부터 삭제까지 자동으로 정리할 수 있을 것 같았다. 파일명과 본문을 비교하고, 많이 겹치는 스킬을 찾아내고, 불필요한 것만 지우면 될 것처럼 보였다.

문제는 어디까지 AI에게 맡겨도 안전한지 확신이 없었다는 점이다.

같은 파일이 여러 곳에 있다는 사실만으로는 불필요한 중복이라고 할 수 없었다. 프로필이 서로 격리되어 있다면 각 프로필이 같은 공용 도구를 따로 가지고 있어야 할 수도 있었다. 반대로 이름이 완전히 달라도 같은 요청에서 동시에 선택되며 역할 충돌을 만들 수도 있었다.

또 하나의 오해도 있었다. 설치된 스킬이 많으면 모든 스킬 본문이 매번 AI의 Context에 들어갈 것이라고 생각하기 쉽다. 실제 측정 결과는 달랐다. 전체 파일 수보다 어떤 요청에서 어떤 스킬이 선택되는가가 더 중요했다.

그래서 질문을 바꿨다.

어떤 스킬이 서로 비슷한가?

가 아니라,

어떤 요청에서 어느 스킬이 선택되어야 하며, 그 스킬은 누구에게 무엇을 넘겨야 하는가?

를 묻기 시작했다.

🛠️ 사용한 도구와 방법

• Hermes Agent: 여러 전문 프로필과 스킬을 조사하고 실제 선택 결과를 관찰

• 타디스: 전체 작업의 좌표를 연결하고 안전 게이트와 역할 경계를 조율

• Context X-Ray: 스킬 본문·크기·연결 파일·호출 책임을 펼쳐 보는 진단 방식

• Selection Harness: 실제 사용자 요청과 비슷한 시험 문항을 새 세션에서 실행해 선택 결과를 측정

• 증거 원장: 각 스킬의 고유 기능과 호출 관계를 기록

• SHA-256과 rollback 기록: 이동 전후 파일 동일성과 복구 가능성 검증

핵심은 AI의 판단을 그대로 믿는 대신, 관찰 가능한 증거와 독립 검증을 함께 사용한 것이다.

🔍 36개 스킬을 이름이 아니라 관계로 펼쳐 보았다

이번 작업에서 가장 강조하고 싶은 장면은 36개 스킬의 caller·wrapper·publisher 관계를 증거지도로 만든 과정이다.

파일 이름과 설명만 보면 두 스킬이 비슷해 보일 수 있다. 하지만 다음 질문에 답하지 못하면 삭제 여부를 판단할 수 없다.

• 누가 이 스킬을 호출하는가?

• 다른 스킬이나 자동화가 이 스킬을 전제로 하는가?

• 별도 실행 도구나 wrapper가 연결되어 있는가?

• 최종 결과물을 발행하는 publisher와 어떤 관계인가?

• 같은 기능이 다른 프로필에도 필요한 이유가 있는가?

• 기존 스킬을 대체한 것인가, 아직 병행 운영 중인가?

증거지도는 각 스킬을 고립된 파일이 아니라 시스템의 한 노드로 보게 했다.

증거지도 점검표

조사 결과, 완전히 같은 패키지 그룹과 높은 유사도 후보가 발견됐다. 그러나 이들은 곧바로 삭제 목록이 되지 않았다. 모두 추가 증거가 필요한 후보로 남겼다.

가장 어려웠던 점도 여기였다.

정적 유사도만으로는 필요한 복제와 불필요한 중복을 구별할 수 없었다.

이 한계를 인정한 뒤에야 안전한 정리가 가능해졌다.

🧪 실제 요청 100개로 스킬 선택을 시험했다

정적 분석 다음에는 실제 요청에 가까운 시험이 필요했다. 그래서 100개의 routing 문항을 만들었다.

• 특정 스킬이 반드시 필요한 요청

• 인접 스킬과 경계가 헷갈리는 요청

• 강의 스킬을 불러서는 안 되는 요청

• 정보가 모호해 과잉 선택이 일어날 수 있는 요청

각 문항은 새로운 Hermes 세션에서 실행했다. AI가 어떤 스킬을 실제로 선택하는지 관찰했다.

첫 결과는 79/100 통과였다.

여기서 중요한 사실이 드러났다.

필요한 스킬을 놓치는 문제보다, 필요하지 않은 스킬까지 함께 부르는 문제가 더 컸다.

예를 들면 이런 식이었다.

• 전체 파이프라인을 조율해 달라는 요청에서 총괄·전사·발행 스킬이 한꺼번에 선택됐다.

• 전사 자료만 다음 에이전트에 넘기라는 요청에서 최종 강의정리 스킬까지 선택됐다.

• 영상 용량만 줄이고 전사는 하지 말라는 요청에서 STT 스킬이 선택됐다.

• 완성된 파일을 보관소에 등록만 해 달라는 요청에서 제작 스킬까지 선택됐다.

스킬의 수가 많다는 사실보다 역할 경계가 흐리다는 사실이 문제였다.

⚠️ 첫 번째 시련 — 검사 도구 자체도 안전하지 않았다

첫 시험은 아무 파일도 변경하지 않았고 실행 실패도 없었다. 그렇다고 그 검사 방식을 바로 믿을 수는 없었다.

독립 검토에서 검사 도구가 읽기 전용 조회 기능뿐 아니라 변경 가능한 관리 기능까지 노출하고 있다는 사실을 발견했다.

실제로 변경 기능이 호출된 적은 없었다. 하지만 “이번에는 사고가 없었다”와 “다음에도 구조적으로 안전하다”는 같은 말이 아니다.

그래서 첫 결과를 삭제 근거로 사용하는 것을 중단했다.

100문항의 관측값은 보존한다.
하지만 이 결과만으로 삭제·보관·비활성화를 결정하지 않는다.

검사 도구부터 다시 만들었다.

• 실제 운영환경과 분리된 임시 시험환경 사용

• 비밀정보와 운영 데이터베이스 제외

• 성공한 읽기 결과만 실제 선택으로 인정

• 문항·검사기·Context의 지문을 고정

• 이전 실행과 조건이 다르면 이어서 실행하지 못하게 차단

• 점수와 전체 결과를 별도 검사기가 다시 계산

• 운영환경에서 시험용 설명문을 바꾸려 하면 실행 전 중단

이 과정에서 배운 첫 번째 원칙은 단순했다.

AI 시스템을 정리하는 도구도 정리 대상보다 먼저 안전해야 한다.

🚦 성능이 좋아져도 안전 기준을 넘지 못하면 멈췄다

다음 단계에서는 첫 시험에서 실패한 21문항과 정상 대조군 9문항을 묶어 같은 30문항을 반복했다.

스킬 설명에 “언제 쓰는가”뿐 아니라 “가장 가까운 어떤 요청에는 쓰지 않는가”를 명확히 적었다.

결과는 크게 좋아졌다. 선택되는 Context도 약 15.8% 줄었다.

하지만 미리 정한 조건은 불필요한 활성화가 20% 미만이어야 한다는 것이었다. 최종 수치는 23.3%였다.

그래서 전체 100문항 재시험과 실제 운영환경 변경을 중단했다.

• production 설명 변경: 0건

• archive: 0건

• 삭제: 0건

• 비활성화: 0건

숫자가 좋아졌다는 이유로 기준을 바꾸지 않았다.

이 장면은 성공담에서 쉽게 빠지는 부분이다. AI가 개선안을 만들었다고 바로 적용하는 대신, 사전에 합의한 실패 기준을 지켰다.

좋은 결과를 얻는 것보다, 안전하게 “아직 아니다”라고 말하는 것이 더 중요한 순간이 있다.

💡 전환점 — 문제는 스킬 개수가 아니라 ‘즉시 종착점’이었다

가장 인상적인 순간은 문제의 본질을 다시 정의했을 때였다.

처음에는 36개라는 숫자가 커 보였다. 하지만 실제 라우팅 실패를 살펴보니 문제는 스킬의 절대 개수가 아니었다.

한 요청에 전체 작업 흐름이 언급되면 AI는 관련된 여러 단계의 스킬을 모두 불러오려 했다. 그러나 사용자가 지금 원하는 것은 전체 단계의 동시 실행이 아니라, 이번 요청이 당장 도착해야 할 한 지점인 경우가 많았다.

예를 들면 다음과 같다.

• 전체 과정을 조율해 달라 → 총괄 lane

• 한 영상의 전사본을 새로 만들어 달라 → 전사 lane

• 전사 증거를 다음 에이전트에 넘겨 달라 → evidence handoff lane

• 최종 강의정리 글을 작성해 달라 → narrative lane

• 이미 완성된 파일을 등록해 달라 → publication lane

이때 생긴 원칙이 endpoint-first였다.

여러 스킬이 보여도 이름이나 전체 파이프라인에 끌려가지 않는다. 지금 요청의 즉시 종착점을 먼저 정하고, 그 종착점을 책임지는 역할을 선택한다.

이 원칙은 스킬 설명을 짧게 다듬는 것보다 훨씬 강력했다. 각 에이전트가 어디까지 처리하고 누구에게 넘길지가 선명해졌다.

🧭 삭제 대신 가역적으로 정리했다

증거지도와 추가 검증을 마친 뒤 실제 정리에 들어갔다.

투자 분석을 담당하는 프로필에는 강의·여행·법률 recap 스킬 사본이 남아 있었다. 실제 caller·wrapper·자동화 연결을 조사했지만 그 프로필에서 사용해야 할 근거를 찾지 못했다.

그래도 삭제하지 않았다.

• 활성 스킬 위치 밖의 archive로 이동

• 이동 전후 패키지 전체의 hash 비교

• 원래 위치와 되돌리는 방법 기록

• 투자 전용 스킬이 정상 유지되는지 확인

7개 패키지를 가역 archive로 옮겼다. 삭제는 0건이었다.

다른 프로필에는 최종 발행 스킬로 들어가는 진입점이 빠져 있었다. 여기서도 구현 전체를 다시 복제하지 않았다. 공용 publisher를 호출하는 얇은 bridge만 추가했다.

그 결과 활성 인스턴스는 36개에서 30개가 됐다.

이 과정의 핵심은 “얼마나 많이 없앴는가”가 아니었다.

필요한 연결은 남기고, 근거 없는 활성 사본만 되돌릴 수 있게 치웠다.

🧩 역할 경계를 실제 운영에 반영했다

물리적인 중복을 줄인 뒤에는 역할 경계를 단계별로 검증했다.

먼저 강의 지식화를 담당하는 프로필에서 다음 경계를 분리했다.

• 자막과 타임스탬프 추출

• 위키에서 기존 문서 검색

• 최종 강의정리 작성

• 완성된 결과물 발행

해당 프로필에서 효과가 확인됐지만 전체 시스템에는 바로 확대하지 않았다. 다른 프로필의 실패가 남아 있었기 때문이다.

다음에는 총괄 에이전트와 전사 전담 에이전트의 경계를 함께 좁혔다.

• 전체 파이프라인 조율

• 직접 전사

• STT-only

• 전사+evidence package

• 완성본 발행

각 요청은 하나의 즉시 종착점에 따라 선택되도록 했다.

최종 production-clone 회귀시험 결과는 다음과 같았다.

• 통합 시험: 31/31 PASS

• 전사 전담 전체 시험: 24/24 PASS

• Precision/Recall: 100% / 100%

• 불필요한 활성화: 0%

• 실행 실패: 0

• 독립 validator: PASS

• 변경 후 예상하지 않은 drift: 0

주의: 최초 baseline은 100문항 전체였고 최종 회귀는 변경과 인접 경계를 집중 점검한 31문항이다. 두 수치를 같은 모집단의 단순 전후 점수처럼 비교하지 않았다.

✅ 결과 — 세 가지가 함께 달라졌다

이번 작업 뒤 실제 운영에서 세 가지 변화가 생겼다.

1. 역할과 소유자가 명확해졌다

각 스킬을 어디에 맡기고, 어디까지 처리한 뒤 누구에게 넘길지 판단하기 쉬워졌다.

2. 중요한 연결을 끊을 위험이 줄었다

호출 근거가 없는 항목만 가역적으로 정리했다. 삭제 대신 archive와 rollback 검증을 사용했다.

3. 불필요한 동시 선택이 사라졌다

전체 파이프라인·전사·발행 요청이 각각 맞는 lane으로 분리됐다.

Before vs After

정확한 시간 절감 효과는 측정하지 않았다. 대신 라우팅 시험과 파일 hash, 독립 validator처럼 다시 확인할 수 있는 증거를 남겼다.

🌱 내가 달라진 점

이 작업 전에는 AI의 자동화 능력에 먼저 기대를 걸었다. 조사하고, 판단하고, 정리하는 전 과정을 AI가 처리할 수 있을 것처럼 보였다.

작업 후에는 순서가 달라졌다.

1. 먼저 어떤 증거가 필요한지 정한다.

2. 성공 조건과 함께 중단 조건을 세운다.

3. 실제 운영환경과 분리된 곳에서 시험한다.

4. 되돌릴 수 있는 방식으로 최소 변경한다.

5. AI의 결과를 별도 도구로 다시 검증한다.

6. 파일이 아니라 역할·연결·즉시 종착점 단위로 문제를 본다.

AI의 자동화 능력보다 되돌릴 수 있는 구조와 독립 검증이 더 중요하다는 것을 배웠다.

💬 이 과정에서 배운 AI 활용 팁

가장 중요한 팁

여러 스킬이 보이면 이름이 아니라 요청의 즉시 종착점을 기준으로 역할을 나눈다.

효과적이었던 것

1. 유사도를 후보 생성에만 사용하기
   같은 파일이나 비슷한 본문은 조사 시작점일 뿐 삭제 근거가 아니다.

2. 실제 호출 관계 확인하기
   caller·wrapper·script·publisher·handoff를 함께 봐야 한다.

3. 동일한 요청으로 전후 비교하기
   개선 전후에 다른 문항을 사용하면 효과를 정확히 비교하기 어렵다.

4. 중단 기준을 먼저 정하기
   결과가 좋아 보여도 사전 기준을 넘지 못하면 멈춘다.

5. 삭제보다 가역 archive 사용하기
   역할과 호출이 충분히 관찰될 때까지 되돌릴 수 있는 상태를 유지한다.

이렇게 하면 안 됩니다

1. 이름이 같다는 이유만으로 중복이라고 단정하기

2. 본문 유사도가 높다는 이유만으로 삭제하기

3. 검사 도구가 production을 변경할 수 있는 상태에서 시험하기

4. 일부 프로필의 성공을 전체 시스템에 바로 확대하기

5. 개선 수치가 나왔다는 이유로 사전 안전 기준을 낮추기

6. archive를 삭제라고 표현하거나 rollback 검증을 생략하기

📋 안전한 AI 스킬 정리 체크리스트

조사

• 어떤 프로필과 스킬을 조사할지 범위를 고정했는가?

• 파일명·본문뿐 아니라 caller를 확인했는가?

• wrapper·script·publisher·handoff 관계를 확인했는가?

• profile-local 복제가 필요한 이유를 확인했는가?

• 대체·병행·중단 상태를 구분했는가?

시험

• 실제 요청과 비슷한 positive·boundary·negative 문항이 있는가?

• production과 격리된 환경에서 실행하는가?

• 변경 전후에 동일한 문항을 사용하는가?

• 점수를 별도 검사기가 다시 계산하는가?

• 중단 기준을 실행 전에 정했는가?

실행

• 삭제보다 archive를 먼저 검토했는가?

• 이동 전후 hash가 같은가?

• rollback 위치와 조건을 기록했는가?

• 의도한 변경 외 drift가 없는가?

• 최종 결과를 사람이 읽을 수 있는 지도와 문서로 남겼는가?

🌍 다른 업무에 적용한다면?

이 방법은 강의 스킬에만 한정되지 않는다.

여러 AI 에이전트 운영

리서치·법률·재무·디자인 에이전트가 비슷한 검색과 문서 작성 도구를 가지고 있을 때, 실제 요청의 종착점과 handoff를 기준으로 정리할 수 있다.

회사 자동화와 SaaS

비슷한 Zap·워크플로·봇이 쌓였을 때 이름이 아니라 trigger·input·output·downstream 의존성을 증거지도로 만들 수 있다.

프롬프트와 템플릿 관리

비슷한 프롬프트를 바로 합치지 않고 실제 사용처·출력 형식·후속 작업을 확인해 정본과 특수 변형을 구분할 수 있다.

문서와 파일 정리

같은 이름의 문서가 여러 폴더에 있을 때 hash뿐 아니라 누가 참조하는지, 어느 문서가 정본인지, 어떤 자동화가 읽는지를 확인한 뒤 가역적으로 정리할 수 있다.

향후에는 다른 전문 스킬군에도 같은 증거지도와 Selection Harness를 적용할 계획이다.

🤝 배워서 남 주기

이번 결과를 성공담으로만 남기지 않기 위해 세 가지를 함께 공유한다.

1. caller·wrapper·publisher를 확인하는 증거지도 점검표

2. 바로 복사해 사용할 수 있는 진단·검증 프롬프트

3. 실제 X-Ray 화면과 안전 기준 미달로 멈춘 NO-GO 사례

특히 NO-GO 장면을 숨기지 않는 것이 중요하다. AI 활용 사례는 항상 “한 번에 잘됐다”는 이야기일 필요가 없다. 안전 기준을 지켜 멈춘 과정도 다른 사람에게는 중요한 실행 지식이다.

🕊️ 널리 사람을 이롭게 한다면

이 사례는 세 가지 어려움을 줄일 수 있다.

• 비개발자가 AI에게 정리를 맡길 때 중요한 파일과 설정을 잃을 불안

• 여러 AI 에이전트를 운영하며 중복과 충돌의 원인을 찾지 못하는 답답함

• 자동화가 가능하다는 이유만으로 삭제와 변경을 서두르는 위험

핵심은 AI를 덜 사용하는 것이 아니다. 더 많은 일을 맡기되, 증거를 요구하고 안전하게 멈추며 되돌릴 수 있게 만드는 것이다.

이 원칙이 널리 쓰이면 AI 자동화의 진입장벽뿐 아니라 자동화에 대한 불안도 함께 낮출 수 있다.

🚀 앞으로의 계획

이번에 만든 증거지도와 Selection Harness를 다른 전문 스킬군에도 적용하려 한다.

• 법률 검토 스킬군의 역할 경계

• 문서 변환·OCR 스킬군의 중복과 handoff

• 이미지 생성·편집 스킬군의 즉시 종착점

• 리서치·모니터링 스킬군의 검색과 분석 책임

• 공용 utility의 profile-local 필요성

각 영역에서도 같은 순서를 유지한다.

증거지도
→ 격리 시험
→ 중단 기준
→ 최소 변경
→ 독립 검증
→ 가역 보존

📋 재사용 가능한 프롬프트

프롬프트 1 — 여러 AI 스킬의 중복을 안전하게 진단하기

[프로필 또는 에이전트 목록]이 보유한 스킬을 안전하게 점검해 주세요. 파일명과 본문 유사도만 비교하지 말고, 각 스킬의 실제 caller·wrapper·script·publisher·handoff·profile-local 필요성을 조사해 uniqueness ledger와 typed relation map을 만드세요. exact-copy와 near-copy는 처분 대상이 아니라 evidence-pending 후보로 표시하고, production 파일은 수정하지 마세요. 조사 결과에는 각 스킬의 owner, 즉시 종착점, 입출력, 대체 관계, rollback 가능성을 포함해 주세요.

프롬프트 2 — 역할 경계를 shadow 환경에서 검증하기

[스킬군]의 역할 경계를 개선하되 production을 직접 수정하지 마세요. positive·boundary·negative·ambiguous 요청 fixture를 만들고, 격리된 sandbox에서 동일 문항의 변경 전후 선택 결과를 비교하세요. recall, precision, false activation, 선택 Context, process failure, drift를 측정하고, 실행 전에 중단 기준을 정하세요. 기준을 통과한 변경만 최소 범위로 승격하고, 모든 이동과 수정에는 rollback manifest와 hash 검증을 남겨 주세요. 여러 스킬이 후보라면 요청의 즉시 종착점을 기준으로 하나의 primary lane을 선택하세요.

🖼️ 추천 이미지

1. 문제 상황: 6개 프로필과 36개 스킬이 겹쳐 보이는 정리 전 지도

2. 증거지도: caller·wrapper·publisher가 연결된 관계 그래프

3. 첫 번째 시련: 운영환경과 격리 시험환경을 분리한 구조도

4. NO-GO 장면: 불필요한 활성화 23.3%에서 멈춘 안전 게이트

5. 결과: 36개→30개, 삭제 0건, 최종 회귀 31/31 요약 카드

6. 전환점: 파일 유사도 중심에서 즉시 종착점 중심으로 바뀐 Before/After

🔚 마무리

이번 작업에서 스킬을 줄인 숫자보다 더 중요한 결과는 판단 방식의 변화였다.

처음에는 AI에게 중복을 찾아 정리해 달라고 하면 될 것 같았다. 실제로는 AI에게 삭제 권한을 주기 전에, 무엇을 증거로 볼지와 언제 멈출지를 먼저 설계해야 했다.

비슷한 파일은 쉽게 찾을 수 있다. 그러나 그 파일이 왜 존재하는지, 누가 호출하는지, 어디로 결과를 넘기는지까지 확인해야 안전하게 정리할 수 있다.

그래서 이 사례의 결론은 “AI가 6개 스킬을 줄였다”가 아니다.

AI에게 삭제를 맡기기 전에, 관계를 증명하고 종착점을 정하고 되돌아올 길부터 만들었다.