강남거북이개발자

클로드와 함께 뭘 할까 고민하다가 뉴스레터를 만들었다.

이름은 ‘최소한의 AI 상식’.

https://stibee.com/api/v1.0/emails/share/PTtaQc6U34Gi8uPFHbADJKK7FBjpdro

스티비라는 툴을 무료로 사용할 수 있었고, 무료 제약이 있어서 격주에 한번씩 받아보도록 했다.

이번 26-001호 주제는 딱 두 개다

하나는 "AI 가격이 왜 이렇게 빨리 내려가나",

다른 하나는 "그 밑에서 무슨 돈이 움직이고 있나".

만들어보니 참, 괜찮습니다.

클로드가 AI와 관련된 최신 뉴스에 대한 소식을 정리해주고, 이를 상식적인 선에서 풀어주는 부분이 좋았다.

AI로 어떤 제작을 할 때에는 최대한 검토를 하는 편인데, 

뉴스레터 편은 검토라기 보다는 내가 정보를 더 얻어가는 느낌이 들었다.

뉴스레터 구독하기 → https://page.stibee.com/subscriptions/521538

뉴스레터는 격주 월요일마다 발송할 예정이다.

다음 예정일은 19일에 발송하겠다.

안녕하세요. 오늘부터 가끔씩, 요즘 개발자들 사이에서 도는 얘기나 제가 직접 겪은 걸 짧게 정리해서 올려보려고 합니다. 첫 호 주제는 요즘 제일 많이 받는 질문이에요.

"AI 잘 쓰는 사람들이랑 안 쓰는 사람들, 진짜 차이가 나요?"

차이가 납니다. 근데 이상하게, 많은 사람이 "AI를 못 써서" 밀리는 게 아니라 "안 물어봐서" 밀립니다. 1년 정도 지켜보면서 느낀 차이를 다섯 가지로 정리해봤습니다.

1. 검색부터 하지 않고, 일단 물어본다

예전엔 에러 메시지를 복사해서 검색창에 붙여넣었습니다. 이제는 맥락이랑 같이 AI한테 먼저 던집니다. "이 함수에서 이런 에러가 나는데, 우리 코드 스타일 고려하면 뭐가 의심돼?" 이런 식으로요. 검색은 정답을 찾는 일이고, 질문은 가설을 세우는 일인데, 후자가 훨씬 빠릅니다.

2. 코드를 짜기 전에 설계를 같이 한다

많이들 AI를 "코드 생성기"로만 씁니다. 근데 진짜 차이는 코드를 짜기 전에 납니다. 이 기능을 어떤 구조로 갈지, 예외는 뭘 고려할지, 나중에 뭐가 문제될지를 먼저 상의합니다. 대충 만들고 나서 고치는 것보다, 만들기 전에 10분 물어보는 게 훨씬 쌉니다.

3. 리뷰와 디버깅에서 AI를 '페어'로 쓴다

혼자 짜면 내 눈엔 다 맞아 보입니다. 그래서 짠 다음에 "이 코드에서 놓친 엣지 케이스 있어?" 하고 물어봅니다. 내가 만든 코드를 남이 봐주는 것과 비슷한 효과인데 시간은 몇 분입니다. 디버깅도 마찬가지. 로그를 붙여주고 "이 흐름에서 뭐가 이상해?" 하면 사람이랑 얘기하듯이 범위가 좁혀집니다.

4. 모르는 개념은 '설명'으로 먼저 배운다

새 기술이 나오면 문서부터 파는 사람도 있지만, 요즘은 먼저 큰 그림을 잡고 들어갑니다. "초등학생한테 설명하듯이, 근데 틀린 비유는 쓰지 말고" 하고 한 번 듣고 시작하면, 문서 읽는 속도가 달라집니다. 대신 AI 설명을 그대로 믿지 않고 공식 문서로 교차 확인하는 습관은 필수입니다.

5. 무엇을 자동화할지 판단하는 게 실력이 된다

이게 제일 큰 차이입니다. AI는 시키면 다 해주지만, "뭘 시킬지"는 사람이 정합니다. 반복되는데 규칙이 명확한 일을 골라서 자동화하는 감각, 요즘 제일 비싼 능력입니다.

한 가지 경고

AI를 많이 쓰는 사람이 더 조심해야 하는 것도 있습니다. AI는 그럴듯하게 틀린 답을 잘 줍니다. 그래서 요즘은 "코드 잘 짜는 능력"보다 결과를 검증하는 능력이 더 중요해졌습니다. 못 쓰는 사람이 밀리는 게 아니라, 검증 없이 믿는 사람이 밀립니다.

이번 호 한 줄 요약

AI 때문에 밀리는 게 아니라, 안 물어보고 안 검증해서 밀린다.

다음 호 예고

다음엔 "AI한테 일을 맡길 때 자주 실패하는 패턴"을 다뤄볼까 합니다. 다뤘으면 하는 주제가 있으면 알려주세요.

여기까지 읽어주셔서 감사합니다. 공감되면 주변 개발자분께 공유해주세요.

나한테 "강의 좀 해주세요"라는 연락이 처음 왔을 때, 솔직히 반가움보다 무서움이 컸다. 코드는 꽤 오래 짰지만, 누군가를 몇 시간 동안 가르쳐본 적은 없었다. 발표는 좀 해봤어도, 발표와 수업이 완전히 다른 장르라는 건 그때는 몰랐다.

어쨌든 해보기로 했다. 그 뒤로 강의가 몇 번 더 이어졌고, 그 과정에서 "개발을 잘하는 것"과 "가르치는 것"이 생각보다 훨씬 다른 능력이라는 걸 자주 느꼈다. 오늘은 그 얘기를 좀 해보려고 한다.

첫 강의는 거의 사고였다

나는 내가 아는 걸 최대한 많이, 최대한 정확하게 전하려고 했다. 슬라이드는 지식으로 꽉 채웠고, 용어는 하나도 빼먹지 않고 다 넣었다. 근데 끝나고 돌아온 얘기가 "좋은데 어렵다"였다.

그때는 "어려운 내용이니까 그럴 수도 있지" 하고 넘겼다. 근데 그게 착각이었다. 문제는 난이도가 아니라, 내가 설명을 "내 기준"으로 하고 있었다는 거다. 나는 이미 아는 사람이라 어디서 막히는지를 모른다. 그 막히는 지점을 못 짚으면, 아무리 정확한 설명도 소용이 없다.

강의는 내 지식이 아니라 상대의 이해를 목표로 한다

개발할 때를 떠올리면 이해가 쉽다. 좋은 코드는 내가 짜기 편한 코드가 아니라 남이 읽기 편한 코드다. 강의도 똑같다. 내가 설명하기 편한 순서가 아니라, 듣는 사람이 이해하는 순서로 풀어야 한다.

이걸 깨닫고 준비 방식을 좀 바꿨다.

• 슬라이드는 줄이고, 대신 "이걸 왜 배워야 하는가"를 앞에 둔다.
• 용어는 처음 나올 때 한 줄로 풀어준다.
• 예시는 실무에서 바로 겪는 상황으로 바꾼다.

별거 아닌 것 같아도, 반응이 확 달라졌다.

가르치면 내가 더 공부하게 된다

강의 준비에서 제일 무서운 건, 내가 대충 아는 부분이 다 드러난다는 거다. "이건 왜 이렇게 되나요?"라는 질문 하나에 얼버무리는 순간 끝난다. 그래서 강의 하나를 준비할 때마다, 평소엔 그냥 넘겼던 "왜"를 다시 파게 된다.

남을 가르치는 게 나를 가르치는 셈이다. 강의를 시작한 뒤로 개념을 더 또렷하게 이해하게 된 건, 공부를 더 해서라기보다 "설명할 수 있어야 하니까"였다. 설명 못 하는 건 아는 게 아니더라.

강단에서 제일 무서운 건 Q&A다

준비한 대로만 흘러가면 강의는 할 만하다. 문제는 질문이다. 슬라이드에 없는 걸 물어보면 머릿속이 하얘진다. 특히 임원분들 앞에서는 질문의 결이 다르다. "이게 실제로 돈이 되나요?", "우리 조직에 맞나요?" 같은 걸 묻는다. 정답이 없는 질문도 많다.

처음엔 모르는 걸 모른다고 못 해서 얼버무렸다. 근데 그게 더 안 좋다는 걸 몇 번 겪고 알았다. 지금은 이렇게 한다.

• 아는 건 또렷하게, 모르는 건 "확인해서 알려드리겠습니다"라고 짧게.
• 답이 애매하면 "케이스에 따라 다르다"고 전제를 깔고 조건을 나눈다.

강단에서 정직한 게 실력보다 오래 간다. 이건 진짜라고 생각한다.

그래서 개발자가 강의를 하면 남는 것

강의가 주는 게 부수입만은 아니다. 설명을 잘하게 되면 협업이 편해지고, 문서를 잘 쓰게 되고, 회의에서 내 의견이 좀 더 먹힌다. 남을 설득하는 모든 순간이 가르치는 일의 연장이라서, 강의에서 배운 게 일상 업무로 그대로 넘어온다.

그리고 뭣보다, 내가 아는 것들을 다시 정리하게 된다. 머릿속에 뭉쳐 있던 것들이 말이 되는 순간이 있다. 그 쾌감이 은근 크다.

마무리

강의는 결국 사람 머릿속을 디버깅하는 일이다. 어디서 막히는지 추적하고, 잘못된 전제를 고치고, 다시 돌려본다. 코드 디버깅이랑 크게 다르지 않다. 대상이 코드에서 사람으로 바뀔 뿐.

개발자라면 한 번쯤은 사람들 앞에 서볼 만하다. 잘할 필요는 없다. 나처럼 첫 판은 망쳐도 된다. 망치고 나면 다음 판이 훨씬 낫다.

요즘 AI 비서를 붙여놓고 "알아서 해줘"를 외치다가, 한 번 크게 데이고 나서 정리한 내용이다.

결론부터 말하면, AI 자동화는 "무엇을 자동화하느냐"에서 90%가 갈린다. 잘못 고르면 자동화를 만드는 데 든 시간이 원래 일보다 커진다. 이 글은 어떤 걸 맡기고, 어떤 걸 안 맡기는지 + 실제로 어떻게 굴리는지를 정리한 것이다.

1. 자동화의 함정: "만들다 지쳐서" 끝난다

처음엔 뭐든 자동화하고 싶어진다. 근데 써보면 두 부류로 나뉜다.

• 한 번 만들면 끝없이 이득인 것 — 매주/매일 똑같이 반복되고, 규칙이 명확한 일.
• 만들자마자 규칙이 바뀌는 것 — 예외가 많고, 매번 판단이 필요한 일.

두 번째를 자동화하면 100% 이렇게 된다. 자동화 만들기 → 예외 케이스 발견 → 또 고치기 → 또 예외… 무한 루프. 자동화의 대상은 "내가 지루해하는 일"이 아니라, "내일도 똑같이 할 일"이다.

2. 자동화하기 좋은 것 / 나쁜 것

내가 쓰는 판단 기준은 이 세 가지다.

1. 반복성 — 주기가 있는가? (매일/매주/매월)
2. 규칙성 — 결과가 정해져 있는가? (알림, 요약, 초안, 점검)
3. 실패 비용 — 틀려도 되돌릴 수 있는가? (리마인더는 틀려도 괜찮지만, 결제/발송은 아니다)

세 개 다 만족하면 맡긴다. 하나라도 애매하면 사람이 최종 확인하는 구조로 둔다.

맡기기 좋은 예:

• 정기 리마인더 (회의 준비, 마감, 청구서)
• 주기 점검 + 결과 보고 (상태가 바뀔 때만 알림)
• 초안 생성 (최종 발행은 내가)
• 정리/요약 (긴 글, 회의록, 뉴스)

일부러 안 맡기는 예:

• 외부로 나가는 발송/결제
• 예외가 잦은 의사결정
• 한 번 하면 끝나는 일 (자동화가 오히려 손해)

3. 실제 구성: 트리거 → 작업 → 보고, 3단 구조

자동화를 굴릴 때는 이 3단으로 나눠서 설계한다.

① 트리거 (언제)

• 시간 기반: 매일 07:00, 매주 월요일 09:00 같은 스케쥴
• 이벤트 기반: 뭔가가 바뀌었을 때 (파일 생성, 상태 변경)
• 가능하면 정확한 시각이 필요한 건 시간 기반으로, 문맥이 필요한 건 이벤트 기반으로.

② 작업 (무엇을)

• LLM이 필요한 작업(요약/초안/판단)과, 필요 없는 작업(집계/정렬/백업)을 분리한다.
• LLM 호출은 돈이다. 규칙으로 되는 건 규칙으로 처리하고, 정말 언어/판단이 필요한 부분만 모델에 넘긴다.

③ 보고 (누구에게)

• 항상 알림을 보내면 피곤하다 → 변화가 있을 때만 알린다.
• 무시하면 안 되는 건 실패 알림. "조용한 성공, 시끄러운 실패"가 원칙.

이 3단만 지켜도 유지보수가 확 편해진다. 특히 ③에서 "변화 있을 때만"을 지키는 게 체감이 크다.

4. 실무에서 바로 쓰는 원칙 5가지

1. 한 번에 다 자동화하지 않는다. 가장 귀찮은 한 가지부터.
2. 실패를 조용히 넘기지 않는다. 실패는 알림으로 나오게.
3. 두 번 이상 실패하면 멈춘다. 무한 재시도는 로그만 더럽힌다. (이거 진짜 중요하다 — 실패했으면 실패했다고 알려주게)
4. 결과를 남긴다. 언제 무엇을 했는지 로그/PR/노트로 흔적을 남기면 나중에 "왜 이렇게 됐지"를 안 헤맨다.
5. 자동화 자체를 점검한다. 만든 자동화가 아직 도는지, 주기적으로 확인하는 감시를 하나 둔다. (안 그러면 어느 순간 조용히 죽어 있다)

특히 3번, 나는 이걸 규칙으로 못 박아뒀다. 자동화가 2~3번 실패하면 반복하지 말고 멈추고 사람에게 알린다. 처음엔 "괜히 멈추네" 싶었는데, 몇 번 겪고 나면 이게 제일 마음 편하다.

5. 그래서 뭐가 좋아지나

자동화의 진짜 이득은 "일을 대신 해주는 것"이 아니라 "내가 그 일을 기억하고 있지 않아도 되는 것"이다.

• 리마인더를 안 외워도 된다.
• 점검을 안 챙겨도 된다.
• 보고서 골격을 안 짜도 된다.

머릿속에서 지워도 되는 일이 늘어나면, 그만큼 정작 집중해야 할 일에 쓸 에너지가 남는다. 나는 이게 체감상 제일 크다.

정리

• 자동화는 "내일도 똑같이 할 일"에만. 지루한 일엔 쓰지 않는다.
• 트리거 → 작업 → 보고 3단으로 설계하고, 보고는 변화 있을 때만.
• 실패는 시끄럽게, 성공은 조용하게. 2~3번 실패하면 멈추고 알린다.
• 한 번에 다 하지 말고, 제일 귀찮은 하나부터.

다음엔 실제로 돌리고 있는 자동화 하나를 골라서 구성이랑 삽질기를 풀어볼까 한다.

참고

• 개인 사용 경험 정리 (특정 서비스 추천이 아닌 일반 원칙)

지난 글에서 클로드 5.5 시리즈 소식을 정리했는데, 그 글 이후로 제일 많이 받는 질문이 이거다.

"그래서 돈 내고 쓰는 입장에서 뭘 쓰면 되는데?"

모델이 Opus, Sonnet, Haiku, 그리고 Fable까지 있으니 고르기가 쉽지 않다. 2026년 10월 4일 기준으로 정리해봤다.

한눈에 보는 라인업

• Claude Fable 5.1 - 최상위(프런티어) 라인. 입력 $10 / 출력 $50 (100만 토큰 기준). 컨텍스트 100만, 출력 128K. 속도는 느린 편. 캐시 읽기는 입력가의 2.5%.
• Claude Opus 5.5 - 실사용 최고 성능. 입력 $4 / 출력 $20. 컨텍스트 100만, 출력 128K. 속도 보통. 캐시 읽기 5%(= $0.20).
• Claude Sonnet 5.5 - 가성비 담당. 입력 $2 / 출력 $10. 컨텍스트 100만, 출력 128K. 빠름. 캐시 읽기 10%(= $0.20).
• Claude Haiku 4.5 - 최저가/최속. 입력 $1 / 출력 $5. 컨텍스트 20만, 출력 64K. (Haiku 5.5는 아직 안 나옴)

참고로 Fable 5.1, Opus 5.5, Sonnet 5.5는 모두 지식 컷오프가 2026년 6월이고, "adaptive thinking"(스스로 생각량 조절)이 기본으로 켜져 있다. 사고 깊이는 effort 파라미터로 조절한다.

실무 기준: 이렇게 고르면 된다

1) 웬만한 건 다 Sonnet 5.5

코딩, 문서 작성, 요약, 일반 대화는 Sonnet 5.5로 충분하다. Opus 5.5의 절반 가격($2/$10)에 속도는 더 빠르고, 컨텍스트도 똑같이 100만 토큰이다. 기본값처럼 쓰면 된다.

2) 길고 복잡한 에이전트 작업은 Opus 5.5

코드베이스 전체 마이그레이션, 감사, 여러 단계를 거치는 자동화처럼 "오래 걸리고 실수하면 큰일"인 작업은 Opus 5.5가 낫다. 여기엔 숨은 장점이 있는데, Opus 5.5는 캐시 읽기가 입력가의 5%라서, 긴 컨텍스트를 반복해서 쓰는 에이전트/코딩 워크로드에서 체감 비용이 확 준다.

3) 진짜 최고 난도는 Fable 5.1

Fable 5.1은 가장 똑똑하지만 $10/$50으로 비싸고 느리다. "이건 어떻게 해도 안 된다" 싶을 때 카드처럼 꺼내 쓰는 용도다.

4) 단순 대량/저지연은 Haiku 4.5

분류, 추출, 라우팅, 짧은 요약처럼 "많이, 빠르게, 싸게"가 중요한 작업은 Haiku 4.5($1/$5). Haiku 5.5가 나오면 이 자리는 그걸로 교체하면 된다.

돈 아끼는 팁 5가지

1. 프롬프트 캐싱을 켜라. 캐시 읽기는 입력가의 10%(모델별 2.5~5%) 수준이다. 같은 시스템 프롬프트나 문서를 반복해서 넣는 작업이면 비용이 크게 줄어든다.
2. 급하지 않으면 Batch API. 배치 요청은 기본가에서 50% 할인이다.
3. effort를 낮춰라. Sonnet 5.5는 기본 high, Opus 5.5는 기본 medium이다. 단순 작업에서 굳이 최고 effort를 쓸 필요가 없다.
4. Fast 모드는 정말 급할 때만. Opus 5.5의 Fast 모드는 최대 2.5배 빠르지만 입력 $8 / 출력 $40으로 두 배다.
5. 작업별로 모델을 갈라 써라. 어려운 것만 Opus/Fable, 나머지는 Sonnet/Haiku로 라우팅하면 전체 비용이 크게 준다.

옮길 때 주의 (마이그레이션)

• Sonnet 4.5는 2026년 11월 30일에 은퇴한다. 4.5를 쓰던 코드는 5.5로 옮겨야 한다.
• Sonnet 5에서 Sonnet 5.5로 올라갈 때 깨지는 변경점 5가지: (1) 사고를 끄려면 disabled 대신 between_tools 사용, (2) 강제 툴 사용(tool_choice: any/tool)은 400 에러, (3) thinking 블록이 모델·대화에 묶임, (4) 예전 computer_20251124 툴 미지원, (5) advisor 툴 페어링 제한.
• 급하게 안 옮겨도 되면 마이그레이션 가이드를 보고 천천히 옮기는 걸 추천한다.

정리

• 기본은 Sonnet 5.5, 어려우면 Opus 5.5, 가끔 Fable 5.1, 대량 단순 작업은 Haiku 4.5.
• 비용은 "모델 선택"보다 캐싱 + 배치 + effort에서 갈린다. 이 3개만 챙겨도 체감이 크다.
• 파일럿으로 Sonnet 5.5부터 깔고, 병목이 보이면 그 부분만 Opus 5.5로 올리는 게 현실적이다.

다음엔 실제로 Opus 5.5와 Sonnet 5.5에 같은 작업을 시켜서 품질/비용을 비교해보는 글을 써볼까 한다.

참고 출처

• Claude Platform 모델 문서 (Sonnet 5.5 / Opus 5.5 개요 및 비교표)
• Claude Platform 릴리즈 노트 (2026-09-22 Opus 5.5, 2026-09-28 Sonnet 5.5, 2026-09-30 Sonnet 4.5 deprecation)
• Introducing Claude Opus 5.5 (Anthropic)

둘째 출산하고 아가별 산후도우미 서비스를 이용했어요.

아가별은 친구의 추천을 받아 예약한 곳이예요!

처음에는 첫째를 길러봤으니 '둘째니까 좀 괜찮겠지' 하는 마음도 있었는데요.

막상 둘째를 낳아보니 생각보다 쉽지 않더라고요 😂

이번에 아가별에서 산후도우미서비스를 이용하게 되었는데,
결론적으로 너무 좋은 관리사님을 만나게 되어 정말 감사한 시간이었습니다.  

무엇보다, 관리사님이 아기를 정말 예뻐해주신다는 게 느껴졌어요.

아기를 안아주실 때나 달래주실 때 보면 정말 손주 보듯이 예뻐해주시는 느낌이었어요. 🥹

아기가 울 때에도 따뜻하고 차분하게 안아주시고,

아기한테 계속 말을 걸어주시면서 눈 맞춰주시고 웃어주시는 모습이 좋았어요.

관리사님이 아기를 워낙 예뻐해주시니까 저도 마음 놓고 쉴 수 있었어요.ㅎㅎ

그리고 산후에는 육아하며 밥을 잘 차려먹기가 쉽지 않았는데,

관리사님이 제가 먹고 싶은 것도 물어봐주시고 음식 솜씨가 정말 좋으셔서 잘 챙겨먹을 수 있었습니다.

그리고 청소도 정말 꼼꼼하게 잘해주셨어요. 아기 돌보는 것만으로도 바쁘실 텐데 집안 정리나 청소까지 신경 써주셔서 너무 감사했어요.

특히 제가 미처 신경 쓰지 못했던 부분까지 알아서 깔끔하게 정리해주셔서 집이 늘 깨끗하게 유지됐어요.

첫째, 둘째를 함께 돌보는 상황에서 청소 걱정까지 덜 수 있어서 정말 큰 도움이 됐습니다:)

그리고 첫째도 함께 예뻐해주시고, 잘 챙겨주셔서 너무 감사했어요.

관리사님이 계셔서 아기 돌볼 때 모르는 것도 많이 여쭤보고, 수유텀도 4시간으로 잘 잡히고, 

심적으로도 많이 힘이 되고, 회복할 수 있었던 4주의 시간이었습니다. ㅎㅎ

신청할 때부터 상담할 때까지 친절하게 알려주셔서 너무 편안했고,

또 좋은 관리사님을 만나게 되어 아가별산후도우미 너무나 추천드려요!

요즘 클로드를 구독하고 이걸 어떻게 써야할까 여러가지 시도해보고 있다.

클로드가 내가 바라보는 크롬 화면을 같이 볼 수 있는 기능이 있어서 이걸 이용해서

대한민국 축구를 함께 보았다.

Claude in Chrome 이라는 기능인데, 

크롬 확장팩으로 클로드를 설치하게 되면, 크롬의 확장 프로그램으로 클로드를 사용할 수 있는 기능이다.

https://claude.com/claude-in-chrome

대한민국 vs 우루과이 전은 비록 4:1로 졌지만, 

승부의 패착 요인, 보강해야할 부분을 경험이 많은(?) AI가 분석해줌으로서

축구를 바라보는 견문이 조금 넒어질 수 있다는 장점이 있었다.

근데 아무래도 AI랑 같이 보니까 살짝 답답..하긴 하다.

https://youtu.be/C-f-5kbKwJM?si=92tTtlyKAV782vw7