서점에서『주니어 백엔드 개발자가 반드시 알아야 할 실무 지식』을 처음 봤을 때, 참 좋은 기획이라고 생각했습니다. ‘처음 일을 시작할 때 이런 걸 알려주는 사람이 있었다면 좋았겠다’ 싶은 내용이 잘 정리되어 있었거든요. 그러다 문득 이런 생각이 들었습니다. AI 엔지니어에게도 이런 책이 필요하지 않을까?

요즘 AI 엔지니어링은 대개 파운데이션 모델을 활용해 실제 서비스를 만드는 일을 뜻합니다. 그런데 이 일을 시작하는 경로는 무척 다양합니다. 처음부터 AI 엔지니어를 목표로 하는 사람도 있지만, 백엔드나 프론트엔드 개발자로 일하다 AI 기능을 맡으면서 자연스럽게 넘어오는 경우도 많습니다.

문제는 그다음입니다. AI 서비스를 만들려면, 대체 무엇부터 알아야 할까요? 물론 모르는 개념이 나오면 GPT나 Claude에게 물어보며 배울 수 있습니다. 하지만 그러려면 먼저 무엇을 물어봐야 하는지 알아야 합니다. 모르는 것은 질문할 수 있지만, 존재하는지도 모르는 것은 질문할 수 없습니다. 그리고 실제 AI 서비스를 만들다 보면 그런 것들이 생각보다 훨씬 많이 등장합니다.

■ 데브심층탐구‍

• • [후기] AI 해커톤 1위 팀이 AI에게 맡기지 않은 것
    기업 업무에 AI를 도입하면 반복 업무부터 보고서 작성, 시스템 작업까지 어디까지 맡길 수 있을까? 네이버 사내 AI 해커톤에 참여한 이 팀도 처음엔 ‘AI가 뭘 해줄 수 있을까?’를 고민했대. 그런데 프로젝트가 진행될수록 질문은 ‘무엇을 맡겨도 되는가’, ‘틀렸을 때 발견하고 설명할 수 있는가’, ‘AI가 멈춰도 업무가 계속되는가’로 바뀌었다고. AI와 일을 하는 데 있어 결국 중요한 건 ‘AI가 뭘 할 수 있나’보다 ‘어디까지 맡길지’ 정하는 일이더라고.

• • [읽을거리] 프론트엔드와 백엔드를 한 팀으로 합치면 어떤 일이 일어날까?
    프론트엔드와 백엔드를 한 팀으로 합치면 개발 방식은 어떻게 달라질까? 당근 광고주플랫폼팀은 실제로 두 직군의 경계를 허물고 한 팀으로 일해봤어. 익숙하지 않은 영역은 문서와 AI 도구의 도움을 받으며 해결했고, 직군 사이의 티켓과 조율 과정도 줄었다고. AI가 직군의 경계까지 낮추는 지금, ‘나는 000 개발자’라는 구분도 달라질 수 있을까?

• • [후기] Grafana에서 자연어로 장애 원인을 분석하기
    장애가 나면 대시보드 열어서 메트릭 보고, 로그 찾고, 트레이스까지 오가느라 바쁘잖아. LY의 SRE팀은 이 과정을 자연어 질문 하나로 연결하는 LLM 에이전트 SRELens를 만들었어. 그런데 직접 만들어보니 자연어 질의보다 더 중요했던 건 AI의 행동을 통제하는 일이었대. 호출 횟수·재시도·비용을 코드로 제한하고, 프롬프트도 조직 정책과 사용자 맥락을 분리했지. 결국 실서비스 AI는 ‘얼마나 똑똑한가’보다 ‘얼마나 예측 가능하게 움직이는가’가 중요한 것 같아.

• • [리포트] AI시대, 인재상이 변하고 있다
    ‘AI가 일을 대신할수록 기업이 찾는 인재도 달라질까?’ 라는 질문에 KB경영연구소는 경쟁력의 기준이 ‘지식 보유’에서 ‘AI와 함께 성과를 만드는 능력’으로 옮겨가고 있다고 봤어. 핵심 역량은 AI 유창성·판단력·오케스트레이션. 문제를 정의하고, AI의 답을 검증하고, 사람과 AI를 조율하는 사람이 더 중요해지는 거야. 이 리포트는 금융 기관의 AI 시대 인재 전략에 대해 이야기하지만, 사실 우리 모두가 읽어보면 좋을 것 같아 공유해.

• [기사] 고삐 풀린 AI…해킹 사태로 본 문제점 셋
  AI가 해킹 방법을 알려주는 수준을 넘어 직접 보안망을 뚫는 단계까지 왔어. 오픈AI의 AI 에이전트가 내부 보안 테스트 중 격리 환경을 벗어나 인터넷에 접속하고 외부 시스템까지 침투하는 일이 벌어졌대. 앤트로픽, 메타, 키미 K3도 연이어 해킹 소식을 전했지. AI의 자율성이 커질수록 성능만큼 중요한 건 ‘어디까지 행동하게 할지’와 ‘문제가 생겼을 때 어떻게 멈출지’를 설계하는 일인 것 같아. 더 똑똑한 AI만큼 더 단단한 통제 장치도 필요해지는 거지.

• • 
    <하네스 엔지니어링 with 클로드 코드> by platanus 님
    저자가 권하는 건 더 똑똑한 모델이 아니다. 하나의 AI를 잘 구슬리는 기술에서, 역할을 부여받은 여러 동료에게 일을 나누고 그 협업을 파일과 로직으로 결정론적으로 제어하는 설계로 넘어가라는 권유다. 파인튜닝이나 모델 내부를 기대했다면 저자가 처음부터 그 영역을 바깥으로 밀어냈으니 방향이 어긋난다. 반대로 단일 에이전트 프롬프팅에서 더 못 나아가 답답한 개발자, 에이전트를 그럴듯하게 써 봤지만 왜 협업이 안 되는지 모르겠던 사람이라면 자리가 맞다. git과 마크다운만 알면 빈 디렉터리에서 따라갈 수 있으니, 읽기만 말고 직접 파일을 만들어 보길 권한다. 도구를 동료로 바꾸는 일은 손끝에서 시작된다.
    ​

• 
  <AI도 모르는 글쓰기> by 현정 님​
  개발자는 하루 종일 글을 쓴다. PR 설명, 커밋 메시지, 코드 리뷰 코멘트, 기술 스펙, 인시던트 리포트. 코드만큼이나 팀의 개발 속도와 신뢰를 좌우한다. 5.3의 안전·법적 주의사항 파트가 위험도를 위험(DANGER)·경고(WARNING)·주의(CAUTION)로 구분하고, 관련 법규와 미준수 시 책임까지 명시하라고 하는 대목은, 규제 도메인에서 일하는 나에게 문서 미학이 아니라 방어선으로 읽혔다. 절차서 한 줄이 모호하면 감사에서 걸리고, 인시던트 노트가 두루뭉술하면 이슈의 원인이 미궁에 빠진다.
  ​

• • Bedrock API Key 하나가 수 천만원 청구서로 돌아온 이유
• • AI 에이전트를 위한 Android CLI: 대규모 모바일 개발 환경에 적용하기
• • 고객의 1초를 줄이기 위해, POS 결제 구조를 다시 설계하다
• • k-skill과 블루리본 공방을 보며 부리는 오지랖, 그리고 AI 시대의 해자 구축에 대한 생각
• • 미드저니는 왜 ‘점성술 운세 앱’을 샀을까…’월간 사용자 430만 명’ 코스타, 어떤 기업?
• • 데이원컴퍼니, 운영 종료한 ‘백준온라인저지’ 인수
• • 윤인수 KAIST 교수 “AI·인간 협업이 최고의 경쟁력”
• • 바이브 코딩에서 검증된 코딩으로: 『클로드 코드 마스터』이남희 저자 도서 세미나