doksam.com
블로그

AI 시대에 개발자는 어떻게 살아남아야 하나 — 2026년 중반 버전

2026-07-22aideveloperagentclaude-code회고

지난 3월에 「AI 시대에 개발자는 어떻게 살아남아야 하나? 를 클로드에게 물었습니다」라는 글을 올렸다. 클로드의 답을 받아 적은 Q&A 였다. 요지는 이랬다 — 완전 대체는 어렵고, 문제 정의·시스템 사고·커뮤니케이션이 핵심 역량이며, AI 는 "망치가 목수를 대체하지 않듯" 능력 증폭 도구다.

4개월이 지났다. 그 사이 내 작업 방식이 통째로 바뀌었고, 그 글의 절반은 여전히 맞고 절반은 이미 낡았다. 이번엔 질문을 다시 던지는 대신, 실제로 겪은 것을 기준으로 그 답을 갱신한다.

개발자 지휘자가 로봇 에이전트 오케스트라를 지휘하는 일러스트 — git push, CI, 머지, deploy 를 각자 연주한다

낡은 부분부터: "망치" 비유는 죽었다

3월의 글은 AI 를 도구로 전제했다. 코드 리뷰 파트너, 학습 도구, 반복 작업의 초안 생성기. 사람이 주체이고 AI 가 보조라는 구도다.

지금 내 화면은 그 구도가 아니다. 에이전트 세션 여러 개가 각자 git worktree 를 하나씩 잡고 이슈 등록 → 브랜치 → 구현 → 테스트 → MR → 머지 → 배포 확인 → 이슈 클로즈를 처음부터 끝까지 수행한다. 이 블로그 자체가 그 증거다. 블로그 기능 구현도, Orca worktree 워크플로 글도, 지금 읽고 있는 이 글도 에이전트가 작성해서 MR 로 올리고 배포까지 확인한 것이다. 나는 방향을 정하고, 중간 산출물에 "꼴랑 사진 하나 넣었네?" 같은 피드백을 던지고, 머지를 게이트한다.

망치는 스스로 못을 고르지 않는다. 지금의 에이전트는 못을 고르고, 박고, 박았다고 보고까지 한다. 도구라기보다 주니어 팀원 여러 명에 가깝고, 그래서 필요한 역량도 "도구 활용법"이 아니라 "팀 운영법"으로 바뀌었다.

여전히 맞는 부분: 문제 정의, 그리고 검증

3월 글의 핵심 역량 세 가지 중 문제 정의 능력은 오히려 더 중요해졌다. 에이전트는 시킨 일을 빠르게 해내지만, 시킬 일이 무엇인지는 정의해 주는 만큼만 안다. 모호하게 시키면 모호한 결과물이 그럴듯한 포장을 쓰고 돌아오는데, 이게 사람 주니어보다 위험하다. 사람은 모르면 묻지만, 에이전트는 그럴듯하게 채워 넣는 쪽으로 실패하기 때문이다.

"AI 결과를 무조건 신뢰하지 말고 항상 검증하라"는 경고도 그대로 유효하다. 다만 검증의 단위가 바뀌었다. 3월엔 함수 하나, 코드 조각 하나를 검증했다면 지금은 diff 전체, 테스트 결과, 배포 후 실측을 검증한다. 코드 리뷰어의 눈이 아니라 릴리스 매니저의 눈이 필요하다.

새로 추가해야 하는 것: 워크플로가 곧 실력이다

4개월 운영해 보고 얻은 가장 큰 교훈은 이거다. 에이전트의 출력 품질은 모델보다 워크플로에 좌우된다.

  • 이슈 우선: 모든 작업은 이슈 번호를 갖고, 브랜치·커밋·MR 에 그 번호가 박힌다. 에이전트가 길을 잃어도 추적이 된다.
  • worktree 격리: 세션마다 독립 폴더. 병렬로 굴려도 서로 발밑을 바꾸지 못한다.
  • 검증 게이트: typecheck·테스트·CI 를 통과해야 머지. 배포 후엔 운영 URL 을 실제로 찔러 확인한다.
  • 지침의 축적: 말투부터 시크릿 취급, 커밋 규칙까지 전역 지침 파일에 쌓는다. 에이전트에게 하는 피드백은 휘발되지 않고 다음 세션의 기본값이 된다.

이건 결국 좋은 엔지니어링 조직이 사람에게 해 주는 것과 같다. 온보딩 문서, 코드리뷰, CI, 컨벤션. AI 시대의 개발자 실력은 "코드를 얼마나 잘 짜나"에서 "이 체계를 얼마나 잘 설계하나"로 이동하고 있다.

주니어 조언도 갱신이 필요하다

3월 글은 주니어에게 "기본기"를 강조했다. 방향은 맞는데 이유를 고쳐야 한다. 기본기가 필요한 건 AI 없이 코딩하기 위해서가 아니라, AI 의 결과물을 판정하기 위해서다.

에이전트가 올린 MR 을 머지할지 말지는 결국 사람이 정한다. 그 판정에 필요한 게 자료구조·네트워크·운영체제 지식이고, "이 쿼리가 왜 느린지", "이 diff 가 왜 위험한지"를 보는 눈이다. 직접 짜는 시간은 줄어도, 읽고 판정하는 시간은 늘어난다. 기본기는 생산 도구에서 감식 도구로 역할이 바뀌었을 뿐 여전히 필수다.

하나 덧붙이면 — 직접 짜는 감각을 완전히 놓으면 감식안도 같이 무뎌진다. 판정만 하는 사람은 결국 판정도 못 하게 된다.

결론: 지휘자 비유, 이번엔 진짜다

3월 글의 결론은 "AI 를 지휘하는 오케스트라 지휘자"였다. 당시엔 수사에 가까웠는데, 지금은 문자 그대로의 묘사가 됐다. 오늘도 세션 대여섯 개가 서로 다른 레포에서 동시에 연주 중이고, 내 일은 악보(이슈)를 쓰고, 파트별 연주(MR)를 듣고, 합주(머지·배포)를 승인하는 것이다.

"변화 속에서 자신의 가치를 재정의하라"는 3월의 마무리는 그대로 가져온다. 다만 한 문장을 보탠다. 재정의는 관망으로 되지 않는다. 에이전트에게 실제 업무를 맡겨 보고, 실패시켜 보고, 워크플로를 고쳐 본 만큼만 재정의된다. 4개월 전의 나는 클로드에게 물었고, 지금의 나는 클로드에게 시킨다. 다음 갱신판에서는 무엇이 또 낡아 있을지 궁금하다.