“처음에는 잘 동작했던 코드에 기능을 하나 더 붙이고, 다시 수정하고, 또 다른 요구사항을 추가하다 보면 어느 순간 이런 생각이 들기 시작합니다. ‘이 코드, 정말 괜찮은 걸까?’”

손 코딩하는 시간보다 AI랑 대화하는 시간이 더 많아진 시대. 프로젝트가 조금만 복잡해져도 등골이 괜히 서늘해진 것 같은 느낌적인 느낌이 드는 이유는 뭘까? AI한테 한 번에 너무 많은 걸 “알아서 다 해줘”라고 맡겼다가, 겉보기엔 잘 돌아가는데 막상 속을 들여다보면 이 코드, 정말 괜찮은 건지 식은땀을 흘려본 경험담을 듣는 횟수가 점점 늘고 있어. AI가 아무리 똑똑하고 타자가 빨라도 우리의 마음속까지 완벽하게 읽어내는 건 아니잖아. 구조나 인증 방식을 명확한 지시 없이 뭉뚱그려 시키면, AI는 그 빈칸을 자기 마음대로 추측해서 채워버리곤 해. 그렇게 만들어진 코드를 덮어놓고 수용하다 보면, 나중에는 손도 댈 수 없을 만큼 거대한 기술 부채가 되어 눈덩이처럼 굴러올지도 모른다는 걱정, 요즘 개발에 있어서 기본적인 고민이 된 거 같아. 그래서 AI랑 일할 때 작업을 적절한 크기로 나누고, 명확한 명세서를 주는 게 중요하다고 하나 봐.

무엇보다 AI가 아무리 화려하고 기가 막힌 아키텍처를 제안한다고 해도, 결국 ‘왜 이 기능이 중요한가?’, ‘우리 서비스에 진짜 필요한가?’를 결정하는 건 오롯이 인간 개발자의 몫이라는 점을 명심할 필요가 있어. 이것을 개발자의 ‘기술적 판단력’이라고 할 수 있는데, 코드를 찍어내는 기계가 아니라, 상황과 비즈니스 맥락에 맞는 최선의 선택지를 골라내는 안목이 앞으로 AI 세상에 가장 강력한 무기가 될 수도 있다는 뜻으로 느껴지는 건 나만 그런 거 아니지?

하루가 다르게 쏟아내는 AI 코드의 홍수 속에, 단순히 코딩을 맡기는 걸 넘어 어떻게 하면 AI와 주도적으로 훌륭하게 협업할 수 있을지 고민하는 이들에게 도움이 될 글을 가져왔어. 이 글에는 무작정 AI를 찬양하거나 두려워하는 대신, 현실적인 개발 환경에서 어떻게 기준을 잡고 일해야 하는지 조언들이 담겨 있어서 요즘 같은 시기에 도움이 될 거야.20년 차 개발자가 말하는 “AI에게 ‘알아서 만들어줘’라고 하면 안 되는 이유”

■ IT 스냅샷: 이달의 화두는?‍

• 아스트라 수요 폭주에…오픈AI, 월200달러 요금제 신규가입 중단
  “최근 오픈AI는 ‘범용인공지능(AGI)에 도달했다’는 선언과 함께 ‘GPT-6 아스트라’ 모델을 선보였다. 실제 아스트라는 로봇을 구별하는 데 사용했던 48단계 ‘캡차’ 테스트를 모두 통과하는가 하면…” 아스트라 사용기와 다른 도구와 비교한 글들이 조금씩 나오고 있는데, 과연 말처럼 레알 AGI인가, 마케팅인가는 당신의 판단에 맡길게.
• 내가 안 썼는데 한도 초과…AI 토큰도 도둑질 대상?
  “통제한 구간에서 사용량이 45%에서 55%로 증가했다…일반적인 인포스틸러 악성코드로 컴퓨터의 클로드 로그인 세션을 훔친 뒤 계정에 접근해 사용량을 소비하는 악성 행위…” 아무것도 안 했는데 버그가 났어! vs 아무것도 안 했는데 과금이 됐어? 환경에 따라 탈취의 패러다임도 바뀌는 거라고 생각해.
• 테스트가 늘수록 느려지던 CI, 16분에서 3분이 되기까지
  “커버리지를 올리면서 탄탄한 코드베이스를 만들수록, TDD를 잘할수록 피드백 루프가 길어지는 역설이었어요…테스트 실행에 243초, 테스트 파일과 의존성을 불러와 테스트를 수집하는 단계에는 1,354초가 쓰였어요.” 보통 테스트 로직 자체가 무겁다고 생각하기 쉽지만, 실은 JS/TS 환경에서 수천 개의 모듈(의존성)을 반복해서 읽고 평가하는 데 전체 시간의 80% 이상이 낭비되고 있었다아?!
• 장애 Alert의 원인을 스스로 찾다: SRE Observer 개발기
  “근거가 없는데도 LLM이 code_bug나 external_dependency 같은 구체적 원인을 말하면, 앱은 그 결론을 그대로 믿지 않고 category를 other로 낮춥니다. 여기서 other는 ‘정확한 원인을 아직 특정하지 못했다’는 정직한 상태입니다.” AI야, 모르면 모른다고 말해라. 그게 어려…웠구나…?
• 구독만 하던 Codex와 Claude, LLM 서버로 바꿔 쓰기
  “채팅창을 열어 사용할 때만 활용되고, 그 외 시간에는 비용을 지불한 구독 자원이 충분히 활용되지 못한 채 그냥 놀고 있습니다…클라이언트가 연결을 끊었는데 어댑터가 신호를 무시하면, 그 요청이 동시성 슬롯을 영구 점유해 결국 해당 프로바이더 전체가 멈춰버릴 수 있습니다.” 월급 루팡 중인 유료 구독 AI들, 구글링 대용으로만 사용하고 있는 건 아닌지 돌아볼 것. 더불어 한 번쯤 겪어봤을 좀비 프로세스의 나비효과에 대해 생각할 것.
• 한 명의 개발자가 여러 전문가와 일하는 방법: 역할형 AI 에이전트로 AWS 인프라 포털 만들기
  “AI 코딩 에이전트에게 바로 ‘포털을 만들어 달라’고 요청하면 화면은 빠르게 만들 수 있습니다. 그러나 어떤 데이터를 신뢰할 것인지, 어디까지 자동화할 것인지, 무엇을 완료로 볼 것인지가 정해져 있지 않다면 결과는 쉽게 흔들립니다.” 기획이나 요구사항 명세 없이 AI에게 프롬프트 한 줄로 모든 것을 해결할 수 있을까? 명확한 제약과 조건 설정이 먼저라고 생각하는 사람 손!
• 외부 API 장애가 우리 서비스 장애로 이어졌다
  “장애 탐지를 돕기 위해 만든 Health Status가 오히려 장애 탐지와 원인 파악을 방해한 거예요…자동 Fallback만으로는 어떤 기능과 벤더에 문제가 있는지 알기 어려웠어요.” 단순히 트래픽을 돌리는 기술적 구현보다, ‘이 벤더가 진짜 정상인가?’를 판단하는 조건과 기준을 세우는 것은 얼마나 어려운 것인가!

■ 독자탐구생활‍

• 
  <AI가 두려운 당신에게> by byungsker 님
  이 책을 읽기 전에는 AI 시대를 모두가 같은 기술 경쟁에 참여해야 하는 시대로 생각했던 것 같습니다. 하지만 책을 읽고 나니 각자의 위치에 따라 준비해야 할 것이 다르다는 생각이 들었습니다. 아이에게 필요한 것은 코딩 기술만이 아니라 질문하고 검증하는 능력입니다. 직장인에게 필요한 것은 모든 AI 기술을 공부하는 일이 아니라, 자신의 업무에서 어떤 일을 AI에게 맡기고 어떤 판단을 직접 해야 하는지 구분하는 능력입니다. 창업가에게 필요한 것은 거대 기업과 같은 범용 모델이 아니라, 자신이 잘 아는 분야의 문제를 구체적으로 발견하는 일일 수 있습니다. 결국 AI를 잘 활용한다는 말은 일을 나누고, 결과를 검토하고, 책임의 경계를 정하고, 필요한 기반을 요구하는 일까지 포함합니다. AI가 자주 틀릴 수 있다는 사실도 다시 확인했습니다. 유창한 답변과 올바른 답변은 다릅니다.
  ​
• 
  <AI가 알아서 굴려주는 월급쟁이 재테크> by 뚜루룽 님
  인상 깊었던 문구가 있는데, “업무에는 그토록 열심히 AI를 쓰면서, 정작 ‘내 돈’을 관리하고 불리는 데는 AI를 활용할 생각을 하지 못한다”는 글귀가 바로 그것이다. 생각해보면 자동화, 효율화를 위해 그렇게나 AI를 공부하고 활용하려고 노력하고 있는데, 막상 나는 왜 나의 자산 관리에는 AI를 잘 활용하지 않고 있는가에 대해 반성하게 되었다. 도서에서도 언급했듯이, AI가 재테크에 유용한 이유는, 역시나 정보 검색 시간을 획기적으로 줄여주는 것뿐만 아니라, 어려운 전문 지식을 이해하기 쉽게 풀어서 설명을 해주며, 무엇보다 나의 상황에 맞는 맞춤형 조언을 받을 수 있다는 점이다.
  ​

■ 데브주요뉴스‍

• • OpenAI가 공개한 GPT-6 Astra 공식 활용 가이드: 자주 되묻는 모델을 끝까지 일하게 하는 프롬프팅과 마이그레이션
• • 바이브 코딩 시대의 문서 관리: 무엇을 남기고, 어떻게 읽게 할 것인가
• • “당신이 AI 블루를 느낀다면 남들보다 앞서 있어서 그런 것… 판단하는 자리를 스스로 지키세요”
• • 美대학생들, AI 의존해 사고 포기…MIT “인지적 항복” 경고
• • 부모의 AI 리터러시: “기술보다 중요한 것은 질문하는 힘”
• • 아모데이 “AI 위험 막아야” vs 젠슨 황 “잘못된 양자택일”
• • 환각·타입 오류 없다…오픈AI 출신, 의사결정 특화 AI ‘제브’ 선보여
• • 잘 읽히는 화면에는 리듬이 있다 사용자의 시선을 자연스럽게 이끄는 UI 텍스트 설계 원칙 6가지

에디터 OTL_ 어느덧 9월의 끝자락, 모두 풍성한 한가위 되길!