“AI를 잘 쓰는 사람과 못 쓰는 사람의 차이는 뭘까?”
동료들에게 자주 받는 질문이다. ChatGPT가 나온 지 3년, Claude Code를 본격적으로 쓴 지 1년이 넘었다. 그 사이에 내 작업 방식은 근본적으로 바뀌었다. 단순히 “AI에게 물어보는 것"이 아니라, AI와 함께 생각하는 방식 자체가 달라졌다.
이 글에서는 내가 Claude를 어떻게 활용하고 있는지—질문하는 방식, 문제를 해결하는 패턴, 그리고 최근 Codex와 병용하면서 발견한 것들을 솔직하게 공유하려 한다.
질문의 진화: “이거 해줘"에서 “같이 생각하자"로
처음 AI 도구를 쓸 때는 검색 엔진의 연장선이었다. “Go에서 map을 순회하면서 삭제하려면?” 같은 단답형 질문. Stack Overflow 대신 Claude에게 물어볼 뿐이었다.
하지만 점점 질문의 형태가 바뀌었다. 초기에는 바로 질문부터 던졌다. “이 에러 어떻게 고쳐?” 지금은 다르다. 먼저 내가 무엇을 하려는지, 어디까지 해봤는지, 왜 막혔는지를 설명한다. Claude가 나의 사고 과정을 이해해야 더 정확한 답을 줄 수 있다는 것을 알기 때문이다. 예를 들어 이런 식이다:
“온보딩 플로우에서 3단계 이후 이탈률이 40%야. 지금은 한 화면에 입력 필드가 6개인데, 사용자 인터뷰에서 ‘뭘 입력해야 할지 모르겠다’는 피드백이 많았어. 필드를 줄이기보다 단계를 나누는 방향으로 개선하고 싶은데, 어떤 구조가 좋을까?”
“온보딩 이탈률 줄이는 법 알려줘” 한 마디보다, 이렇게 맥락을 주면 결과물의 질이 극적으로 달라진다. 좋은 답은 좋은 질문에서 오는 게 아니라, 좋은 맥락에서 온다.
경험이 더 쌓이면서 제약 조건을 적극적으로 명시하게 되었다. “이 프로젝트는 Go 1.22를 쓰고, 외부 의존성을 최소화하는 게 원칙이야”, “이 코드는 초당 10만 요청을 처리해야 해. 가독성보다 성능이 우선이야” 같은 것들. Claude는 제약 조건이 없으면 가장 “안전한” 답을 준다. 범용적이고, 교과서적이고, 하지만 내 상황에는 맞지 않는 답. 제약 조건은 Claude가 무한한 가능성의 공간에서 내가 원하는 영역으로 좁혀가게 만드는 가이드레일이다.
가장 효과적이라고 느끼는 패턴은 Claude에게 역할을 부여하는 것이다. “너는 지금 시니어 SRE야. 이 아키텍처의 장애 시나리오를 분석해줘"라고 하면, 단순한 코드 설명이 아니라 운영 관점의 위험 요소를 짚어준다. 같은 코드를 놓고도 어떤 역할로 보느냐에 따라 완전히 다른 인사이트가 나온다.
문제 해결 패턴: Claude와 일하는 방식
예전에는 고무 오리 인형에게 코드를 설명하면서 스스로 버그를 찾았다(러버덕 디버깅). Claude는 대답하는 러버덕이다. 내가 문제를 설명하면 질문을 던져주고, 내 사고의 빈틈을 찾아준다. “이 함수에서 데드락이 발생하는 것 같은데, mutex 잠금 순서가 문제인지 모르겠어"라고 시작하면, Claude는 코드를 보면서 “이 goroutine에서 A를 잠그고 B를 기다리는데, 저 goroutine에서는 B를 잠그고 A를 기다리고 있다"고 짚어준다. 혼자 30분 걸릴 분석이 3분에 끝난다. 핵심은 Claude에게 답을 구하는 게 아니라, 나의 사고 과정을 검증받는 것이다.
아키텍처 설계에서는 “같이 화이트보드 앞에 선 동료"가 된다. “이벤트 드리븐 아키텍처를 도입하려고 하는데, Kafka vs SQS+SNS 중에 고민이야. 우리 팀 규모는 5명이고, 현재 트래픽은 일 100만 이벤트 정도야. 어떤 트레이드오프가 있을까?” 이런 질문에 Claude는 양쪽의 장단점을 정리해주면서, 내가 놓친 관점—운영 복잡도, 팀 학습 곡선, 향후 확장 시나리오—을 추가해준다. 최종 결정은 내가 하지만, 의사결정의 표면적이 넓어진다.
코드 생성 워크플로우도 바뀌었다. 빈 파일에서 시작하는 것이 아니라, 의도를 설명하면 초안이 나오고, 그 위에서 반복적으로 다듬는다. 중요한 것은 한 번에 완벽한 코드를 기대하지 않는다는 점이다. 첫 번째 결과물은 80% 정도다. 거기서 “에러 핸들링을 이렇게 바꿔줘”, “이 부분을 테이블 드리븐 테스트로 바꿔줘” 같은 반복적 개선을 한다.
글쓰기에서는 구조화 파트너다. 내가 두서없이 생각을 쏟아내면, Claude가 그것을 논리적 흐름으로 재배열해준다. 특히 유용한 것은 반론 생성이다. 내 주장에 대해 “이런 반론이 있을 수 있다"고 미리 짚어주면, 글의 완성도가 올라간다. 이 블로그의 여러 글에 있는 “예상되는 반론들” 섹션은 대부분 Claude와의 대화에서 나왔다.
프롬프팅 패턴: 무엇이 효과적인가
시행착오를 거치면서 정리된 프롬프팅 패턴들이 있다.
단순히 답만 달라고 하면 Claude는 결론만 준다. “왜 그렇게 생각하는지 과정을 보여줘"라고 하면, 추론 과정이 드러나면서 내가 동의하지 않는 가정을 잡아낼 수 있다. 특히 아키텍처 결정처럼 트레이드오프가 있는 문제에서 이 패턴은 필수다.
내가 가장 많이 쓰는 패턴은 “먼저 질문해줘"다. 복잡한 문제를 던질 때, “바로 답하지 말고, 먼저 네가 이해한 것과 추가로 알아야 할 것을 질문해줘"라고 요청한다. Claude가 던지는 질문을 보면, 내가 빠뜨린 맥락이 뭔지 알 수 있다. 그리고 그 질문에 답하는 과정에서 내 생각도 정리된다.
하나의 답을 받으면 그것이 최선인지 판단하기 어렵다. “세 가지 다른 접근법을 각각의 트레이드오프와 함께 제시해줘"라고 하면, 의사결정의 지형도가 그려진다. 보통은 세 번째 선택지에서 내가 생각하지 못한 접근법을 발견한다.
Claude Code에서 프로젝트 루트에 CLAUDE.md 파일을 두면, 매 세션마다 반복할 필요 없이 프로젝트의 컨텍스트를 자동으로 전달할 수 있다. 나는 여기에 프로젝트 컨벤션, 아키텍처 원칙, 자주 사용하는 명령어를 정리해둔다. 매번 같은 맥락을 설명하는 비용을 없애는 것이다. 사실 이 파일 하나가 생산성에 미치는 영향이 생각보다 크다.
Claude + Codex: 두 도구의 병용
최근에는 Claude Code 안에서 Codex를 함께 쓰고 있다. 처음에는 “비슷한 도구를 왜 두 개나 쓰지?“라고 생각했지만, 실제로 써보니 용도와 강점이 다르다.
의학에서 중요한 진단에는 second opinion을 구한다. 코드에서도 마찬가지다. 복잡한 알고리즘이나 시스템 설계에서, Claude의 답을 Codex에 던져서 검증하거나 그 반대를 한다. 두 모델이 같은 결론을 내리면 신뢰도가 올라가고, 다른 결론을 내리면 내가 더 깊이 생각해야 할 지점이 드러난다. 예를 들어, 동시성 코드에서 Claude가 “이 접근이 안전하다"고 하고 Codex가 “레이스 컨디션 가능성이 있다"고 하면, 그 차이를 파고들면서 내가 진짜로 이해하게 된다. 모델끼리의 의견 차이가 나의 학습 기회가 되는 셈이다.
Claude Code CLI 안에서 Codex를 스킬로 호출할 수 있다는 점도 중요하다. 별도의 도구를 오가지 않아도 된다. 코드를 작성하다가 “이 부분은 Codex에게 한번 물어보자” 하면 같은 터미널에서 바로 확인하고 돌아올 수 있다. 도구 간 전환에 걸리는 30초가 사라지면, 사고의 흐름이 끊기지 않는다.
써보면서 느낀 것은, 모든 작업에 하나의 도구만 고집할 필요가 없다는 점이다. Claude는 맥락이 긴 대화, 아키텍처 설계, 글쓰기, 복잡한 리팩토링에 강하고, Codex는 코드 생성의 정확도, 특정 언어/프레임워크의 관용적 패턴, 빠른 구현에 강하다. 마치 드라이버와 아이언을 상황에 맞게 바꿔 쓰는 것과 같다. 도구에 집착하지 않고, 문제에 맞는 도구를 선택하는 것이 핵심이다.
아직 부족하다고 느끼는 것들
AI 도구를 찬양만 할 생각은 없다. 쓰면서 느끼는 한계도 분명히 있다.
Claude Code의 대화는 세션이 길어지면 초기 맥락이 흐려진다. 30분 전에 설명한 제약 조건을 잊고 엉뚱한 방향으로 가는 경우가 있다. CLAUDE.md로 일부 해결되지만, 세션 내 동적인 맥락—“아까 그 접근은 안 된다고 했잖아”—은 아직 완벽하지 않다.
Claude는 틀릴 때도 자신 있게 답한다. 특히 최신 라이브러리 버전이나 잘 알려지지 않은 API에서 이런 일이 잦다. “이 함수가 있어요"라고 자신 있게 말하는데, 실제로는 존재하지 않는 API인 경우. 이것은 경험이 적은 개발자에게 특히 위험하다. AI의 답을 무조건 신뢰하지 않는 습관이 필요하다.
Claude에게 코드를 맡기면, 요청한 것보다 더 많은 것을 만들어주고 싶어 한다. 에러 핸들링 추가, 로깅 추가, 테스트 추가… 원래 의도는 간단한 유틸 함수 하나였는데, 돌아보면 50줄짜리 프로덕션 코드가 되어 있다. “이 정도면 충분해"라고 선을 긋는 것은 여전히 사람의 몫이다. 에러 메시지와 스택 트레이스를 던지면 대부분 잘 분석해주지만, 재현이 어려운 간헐적 버그나 분산 시스템의 타이밍 이슈에서는 한계가 있다. 결국 시스템에 대한 깊은 이해와 직관이 필요한 영역은 여전히 존재한다.
AI 시대에 리더십이 더 중요해지는 이유
AI 도구를 쓰면서 가장 의외의 깨달음은 이것이었다. 리더십 경험이 AI 활용 능력에 직결된다.
팀을 이끌어본 사람이라면 안다. 주니어에게 일을 맡길 때와 시니어에게 일을 맡길 때, 요구사항을 전달하는 방식이 다르다. 작은 일은 구체적으로 지시하고, 큰 일은 목적과 제약 조건만 주고 방법은 맡긴다. 중간에 방향이 틀어지면 작업을 멈추고 되돌리는 판단도 해야 한다. Claude를 쓸 때도 똑같다.
작은 일에는 “이 함수의 에러 핸들링을 추가해줘. 에러는 fmt.Errorf로 wrap하고, 호출자에게 리턴해” 같이 명확하게 지시한다. 작은 작업에 과도한 맥락을 주면 오히려 불필요한 것들을 만들어낸다. 반면 “이 시스템의 인증 모듈을 설계해줘"처럼 큰 작업은 접근이 다르다. 먼저 plan 모드로 설계를 요청하고, 그 설계를 검토한 뒤에 구현으로 넘어간다. “왜 이것을 해야 하는지"와 “어떤 제약이 있는지"만 전달하고, 어떻게는 먼저 제안을 받는다.
리더가 가장 어려워하는 의사결정 중 하나가 “이거 방향이 잘못됐으니 되돌리자"다. AI와 일할 때도 마찬가지다. Claude가 열심히 코드를 작성하고 있는데, 중간 결과물을 보니 근본 접근이 틀렸다. 이때 “아까운데 좀 더 해보자"가 아니라, 과감하게 멈추고 다른 접근으로 전환하겠다고 결정하는 것. 이 판단력은 프롬프팅 스킬이 아니라 리더십 경험에서 온다. 매몰 비용의 오류는 사람에게만 적용되는 것이 아니다. AI가 만든 결과물에도 “여기까지 왔는데…“라는 미련이 생긴다. 하지만 좋은 리더가 프로젝트를 피봇할 줄 알듯, AI와의 작업에서도 과감하게 방향을 전환해야 할 때가 있다.
Claude Code에서 여러 에이전트를 병렬로 실행할 때, 이 감각이 더 뚜렷해진다. 탐색 에이전트에게는 넓게 조사하게 하고, 구현 에이전트에게는 좁고 깊게 작업하게 한다. 각 에이전트의 결과물을 취합해서 다음 방향을 정하는 과정은, 팀의 여러 파트에서 올라온 리서치를 종합해서 의사결정하는 것과 본질적으로 같다. 결국 AI 시대에 엔지니어에게 필요한 것은 “프롬프트를 잘 쓰는 능력"이 아니다. 무엇을 시킬지 판단하고, 어떻게 전달할지 결정하고, 결과를 평가해서 다음 행동을 정하는 능력—이것은 리더십 그 자체다.
그래서 무엇이 달라졌는가
1년간의 경험을 돌아보면, 가장 크게 달라진 것은 일의 속도가 아니라 일의 밀도다.
같은 시간에 더 많이 하는 것이 아니라, 같은 시간에 더 깊이 하게 되었다. 보일러플레이트와 반복 작업에 쓰던 시간이 설계와 의사결정에 쓰인다. 코드를 타이핑하는 시간이 줄고, 코드를 생각하는 시간이 늘었다.
그리고 AI와 일하면서 오히려 사람과 일하는 능력이 날카로워졌다. 맥락을 잘 전달하고, 제약 조건을 명확히 하고, 상대방의 답변을 비판적으로 평가하는 것—이것은 AI에게든 동료에게든 똑같이 필요한 능력이다. AI를 잘 다루는 사람이 팀도 잘 이끈다. 그리고 팀을 잘 이끌어본 사람이 AI도 잘 다룬다. 이 둘은 서로를 강화한다.
정리
- 맥락이 답의 질을 결정한다. “이거 해줘"보다 “이런 상황에서 이런 제약으로 이것을 하려 한다"가 훨씬 나은 결과를 만든다.
- Claude는 대답하는 러버덕이다. 답을 구하기보다, 사고를 검증받는 도구로 쓸 때 가장 효과적이다.
- 프롬프팅은 기술이다. “먼저 질문해줘”, “세 가지 선택지를 줘”, “생각의 과정을 보여줘”—이런 패턴이 결과를 바꾼다.
- 도구를 병용하라. Claude와 Codex는 강점이 다르다. 교차 검증과 용도별 분리로 더 나은 결과를 얻을 수 있다.
- AI의 한계를 알아야 잘 쓸 수 있다. 자신감의 함정, 맥락의 휘발성, 과잉 생성의 유혹을 인지하고 있어야 한다.
- 리더십이 곧 AI 활용 능력이다. 작은 일과 큰 일을 다르게 맡기고, 멈출 때를 아는 판단력은 리더십 경험에서 온다.
AI 도구는 계속 발전할 것이다. 하지만 도구가 아무리 좋아져도, 무엇을 시킬지 판단하는 것, 결과를 평가하는 것, 방향이 틀렸을 때 되돌리는 것—이것은 여전히 사람의 영역이고, 리더의 역할이다.
그리고 한 가지 더 기억해야 할 것이 있다. 지금 내가 쓰고 있는 이 도구, 이 워크플로우가 항상 최선은 아니라는 점이다. Claude가 최선이 아닌 날이 올 수 있고, 지금의 프롬프팅 패턴이 무의미해지는 변화가 올 수도 있다. 실제로 지난 3년간 우리가 목격한 변화의 속도를 생각하면, 다음 변화는 더 빠르게 찾아올 가능성이 높다.
중요한 것은 특정 도구에 정체성을 묶지 않는 것이다. 오늘 배운 것을 정리하고, 내일의 새로운 방법을 익히고, 그 과정 자체를 성장으로 받아들이는 것. 도구는 바뀌어도 배우는 방법을 아는 사람은 매번 적응한다.
나는 Claude를 “더 나은 나"를 만드는 도구로 쓰고 있다. 더 빠르게가 아니라, 더 깊게 생각할 수 있게 해주는 도구로. 그리고 언젠가 더 나은 도구가 나타나면, 이 경험을 발판 삼아 다시 배워보려 한다.
마지막으로 하나만 더. 돈을 아끼지 말자. AI 도구 구독에 쓰는 비용은 어떤 강의보다, 어떤 취미생활에 쓰는 비용보다 저렴하다. 그런데 돌아오는 것은 비교할 수 없이 크다.