Claude Code, 코드를 작성하게만 하고 계신가요? 그것은 솔직히 정말 아까운 일입니다.

Claude Code의 대단한 점은 손을 움직여 주는 파트너인 동시에, 옆에 앉아 있는 선생님이기도 하다는 것입니다. 구현을 통째로 맡기는 것이 아니라, "가르침을 받는다", "시니어의 머릿속을 훔친다"는 도구로 사용하면 성장 속도가 정말로 달라집니다.

예전의 저는 이랬습니다. 무언가 새로운 것을 시작한다 → 조사한다 → 잘 모르겠다 → 좌절 → 포기. 이 무한 루프. 문서를 열어도 용어를 모르겠고, 그 용어를 조사하면 또 모르는 용어가 나와서, 정신을 차려보면 마음이 꺾여 있습니다. 그 시절 제가 원했던 것은 코드 그 자체보다, "모르는 부분을 이해할 때까지 몇 번이고 쉽게 풀어서 설명해 주는 사람"이었거든요.

그 역할, 지금은 Claude Code가 해줍니다. 계속 질문하기만 하면 24시간 내내 곁에 있어 주는 전속 선생님이 있는 것과 같습니다. 사용하지 않을 이유가 없습니다.

그래서 Claude Code를 "선생님"으로 바꾸는 엄선된 5가지 프롬프트를 소개합니다.

"같은 질문이라면 웹 채팅에 던지면 되지 않아?"라고 생각하실 겁니다. 여기가 첫 번째 핵심입니다.

Claude Code는 터미널(또는 에디터) 안에서 동작하기 때문에, 눈앞에 있는 자신의 코드나 파일, 에러를 그대로 읽고 대화할 수 있습니다. "이 에러 고쳐줘"라고 말하면, 일반론이 아니라 "당신의 그 파일의 그 줄"을 전제로 답변해 줍니다.

즉, 교재가 "어딘가에 있는 입문서"가 아니라 "자신의 프로젝트 그 자체"가 되는 것입니다. 이것이 학습 도구로서 Claude Code를 선택하는 이유입니다. 아래의 프롬프트들도 이 "문맥을 읽을 수 있는 선생님"이라는 강점을 활용하는 것을 전제로 만들었습니다.

참고로 프롬프트는 일본어로 적혀 있지만, 영어로도 문제없이 작동합니다. 편한 쪽을 사용하세요.

1. 기초 다지기

전혀 모르는 분야에 뛰어들 때의 첫 번째 수단. 전문 용어의 벽 때문에 마음이 꺾이지 않도록, 철저하게 풀어서 설명하도록 합니다.

당신은 세계에서 가장 알기 쉽게 가르치는 강사입니다.
이 전문적인 내용을 초등학생이라도 이해할 수 있도록 설명해 주세요.
전문 용어를 사용할 경우에는 반드시 그 의미도 함께 설명해 주세요.

언제 사용하나?: 새로운 라이브러리나 개념, 의미를 알 수 없는 에러를 처음 마주했을 때. 여기서 "아는 척"하며 넘어가면 나중에 반드시 막히기 때문에, 미리 토대를 다지는 모드입니다. 돌아온 설명에 "그 비유를 좀 더 구체적으로", "다른 방식으로"라며 계속해서 추격 질문을 던질 수 있는 것이 채팅의 장점입니다.

2. 에러의 근본 원인 파악하기

에러는 사실 최고의 교재입니다. 단순히 고치기만 하면 아무것도 남지 않으므로, "왜 발생했는지"까지 이해해 버립시다.

이 에러의 원인을 특정해 주세요.
"원인이 무엇인지", "왜 발생하는지", "어떻게 고치는지" 순서대로 설명하고,
수정된 코드도 함께 제시해 주세요.

언제 사용하나?: 에러 때문에 작업이 멈췄을 때. 스택 트레이스(Stack Trace)를 붙여넣기만 해도 되지만, Claude Code라면 해당 파일을 직접 읽게 할 수 있습니다. 요점은 "왜 발생하는지"를 반드시 설명하게 하는 것입니다. 이 부분을 건너뛰면 다음에 비슷한 에러가 나왔을 때 또 똑같은 질문을 하게 됩니다. 원인이 쌓이다 보면 애초에 에러를 밟지 않게 됩니다.

3. 시니어의 사고방식 훔치기

솔직히 정답 코드보다 가치 있는 것이 "그곳에 도달하기까지의 사고방식"입니다. 시니어 엔지니어의 머릿속을 들여다봅시다.

이 기능을 구현할 때, 시니어 엔지니어라면 어떻게 생각할지를
단계별(Step-by-step)로 설명해 주세요.
설계 사상(Design Philosophy), 유지보수성(Maintainability), 확장성(Scalability)의 관점도 포함하여 해설해 주세요.

언제 사용하나?: 구현 전의 설계 단계. "어떻게 쓸 것인가"보다 "왜 그 설계로 하는가"를 언어화하게 만들면, 판단의 척도까지 훔칠 수 있습니다. 설계 사상, 유지보수성, 확장성을 일부러 지정하는 것이 포인트인데, 이것이 없으면 "일단 돌아가는 코드"만 돌아오기 쉽습니다. 나온 설계에 대해 "이 선택의 트레이드오프(Trade-off)는?"라고 덧붙여 물으면 해상도가 더욱 높아집니다.

4. 엄격한 코드 리뷰

직접 작성한 (또는 AI가 작성한) 코드를 엄격한 선배에게 리뷰받는 느낌의 모드입니다.

이 코드를 엄격하게 리뷰해 주세요.
가독성(Readability), 유지보수성(Maintainability), 퍼포먼스(Performance), 보안성(Security)의 관점에서 개선점을 지적하고,
개선된 버전도 제시해 주세요.

언제 사용하나요?: 일단 돌아가는 결과물이 만들어진 후의 마무리 단계입니다. "엄격하게"라는 말을 넣어두면, 눈치 보지 않고 거침없이 문제점을 지적해 줍니다. 관점을 4가지(가독성, 유지보수성, 퍼포먼스, 보안성)로 고정해 두었기 때문에, 리뷰의 누락을 줄이는 것도 은근히 효과적입니다. 개선된 버전을 그대로 복사해서 붙여넣는 것이 아니라, "왜 이쪽이 더 나은 거야?"를 매번 확인하면 리뷰 기준이 자신 안에 쌓여가게 됩니다.

마지막은 학습 그 자체를 설계하도록 하는 모드입니다. 목표로부터 역산하여 최단 경로를 그려줍니다.

저의 현재 레벨은 〇〇입니다.
〇〇를 만들 수 있게 되는 것이 목표입니다.
최단 기간 내에 달성하기 위한 학습 로드맵을 작성해 주세요.
...

언제 사용하나요?: "뭐부터 손을 대야 하지..."라며 막막할 때입니다. 〇〇를 구체적으로 채울수록 정밀도가 올라갑니다 (예: "현재 레벨은 HTML/CSS를 겨우 쓸 수 있는 정도", "목표는 자신만의 가계부 앱을 Next.js로 만들 수 있게 되는 것"). 실전 과제까지 내놓게 하는 것이 중요한데, 이는 읽기만 하고 만족하며 끝나버리는 좌절 패턴을 방지할 수 있습니다.

단발적으로도 효과적이지만, 순서대로 연결하면 하나의 학습 사이클이 됩니다.

⑤ 로드맵으로 목표와 전체상을 결정한다 - 각 단계에서
① 튜터 모드를 사용하여 모르는 개념을 없앤다 -
③ 엔지니어 사고 모드로 설계를 배우며 구현한다 - 막히면
② 에러 해결 모드로 원인까지 이해한다 - 완성된 코드를
④ 리뷰 & 개선 모드로 다듬는다 - 다음 단계로 돌아가 다시 ①~⑤를 반복한다

이 과정을 반복하는 것만으로도, "검색 → 좌절 → 포기"가 "질문 → 이해 → 제작"으로 바뀌어 갑니다.

선생님으로서는 매우 우수하지만, 만능은 아닙니다. 이 점만 주의하세요.

맹신하지 말 것: 그럴싸하게 틀릴 때가 있습니다. 특히 라이브러리 버전 차이나 보안 관련 사항은 공식 문서(Official Documentation)로 확인하는 습관을 들이세요. "엄격하게 리뷰해 줘"라고 말하는 것과 같은 시선을 AI의 답변 자체에도 유지하는 것이 건전합니다. -
필사하고 끝내지 말 것: 개선된 버전을 그대로 붙여넣고 만족하면 ③, ④의 의미가 반감됩니다. "왜?"라는 질문에 대해 한 번은 자신의 언어로 설명할 수 있는지 확인하세요. -
기밀 정보는 조금 신중하게: 업무 코드나 개인 정보가 포함된 파일을 읽게 할 때는, 사용 중인 플랜이나 환경의 데이터 취급 방식을 미리 확인해 두는 것이 안심됩니다.

구현을 AI에게 맡길 수 있는 시대이기에, 차이를 만드는 것은 "자신이 얼마나 알고 있는가"입니다. 그러니 코드를 작성하게 하고 끝내는 것이 아니라, 모르는 것을 알 때까지 몇 번이고 물어볼 수 있는 선생님으로서 마음껏 활용하시길 바랍니다.

24시간 내 옆에 전속 선생님이 있습니다. 이것을 활용하지 않는 것은 너무나 아까운 일입니다. 우선 지금 딱 막혀 있는 에러에 ②의 프롬프트를 던져보세요.