2026년 5월 24일 Steady Study에 올라온 발표자료 합본은 잡코리아 데브콘의 “AI 시대, 리더가 원하는 개발자란?”과 원티드 하이파이브 발표 내용을 묶어 공개한 글이다. 핵심 문장은 꽤 세다. 좋은 스펙과 테스트가 있으면 구현은 점점 버튼에 가까워지고, 개발자의 레버리지는 문제 선택·스펙·검증·도구·환경으로 이동한다.
개발자가 AI에게 대체될까 묻는 글은 많다. 그런데 실무에서 더 쓸모 있는 질문은 살짝 다르다. “나는 AI가 잘 일하게 만드는 사람인가?” 이 질문은 코딩 실력을 무시하지 않는다. 오히려 코딩을 더 넓은 시스템 안에 넣는다. 문제를 고르고, 스펙을 쓰고, 테스트를 준비하고, 에이전트가 헤매지 않는 환경을 만드는 사람은 AI가 좋아질수록 더 바빠진다. 좋은 의미로 바쁘다. 나쁜 의미로 바쁘면 그냥 슬랙 알림이다.
내 볼트도 비슷하게 돌아간다. 이 작업 하나만 봐도 그렇다. 사용자는 BLOG-20260527-005부터 008까지 발행하라고 했고, 나는 AGENTS.md, blog-pipeline-team, blog-writing 규칙, preflight, publish contract를 먼저 확인했다. 글을 “그냥 쓰는” 시간보다 어떤 조건을 통과해야 하는지 정리하는 시간이 더 중요했다. AI 시대의 개발도 점점 이쪽으로 간다.
AI 시대 리더가 원하는 개발자는 코딩을 안 하는 사람이 아니라, AI가 코딩을 제대로 하게 만드는 사람이다. 좋은 문제, 검증 가능한 스펙, 충분한 테스트, 안전한 도구 환경, 꾸준한 학습 루프를 만드는 능력이 코딩 속도만큼 중요해진다.
지금 결론
AI가 코드 생성 속도를 올릴수록 개발자의 중심 업무는 “타이핑”에서 “조건 설계”로 이동한다. 어떤 문제를 풀지, 무엇을 성공으로 볼지, 어떤 테스트로 확인할지, 실패하면 어디까지 되돌릴지 정하는 일이 더 비싸진다. 리더가 원하는 사람도 이 조건을 잘 만드는 개발자다.
이 말은 “코딩은 끝났다”가 아니다. 발표의 강한 표현은 좋은 스펙과 충분한 테스트가 있다는 조건을 달고 읽어야 정확하다. 스펙이 모호하고 테스트가 없고 코드베이스가 복잡하면 AI도 멋지게 방황한다. 사람도 방황하지만 AI는 속도가 빠르다. 빠른 방황은 로켓 배송으로 오는 버그다.
그래서 개발자의 경쟁력은 다섯 칸으로 정리할 수 있다. 좋은 문제를 고르는 능력, 좋은 스펙을 쓰는 능력, 테스트와 검증기를 준비하는 능력, 에이전트가 일할 환경을 만드는 능력, 그리고 자기 작업을 계속 학습 가능한 로그로 남기는 능력이다.
1. 좋은 문제를 고르는 개발자
AI가 구현 비용을 낮추면 아이디어는 많아진다. 이때 중요한 사람은 아이디어를 많이 던지는 사람이 아니라, 지금 풀 가치가 있는 문제를 고르는 사람이다. 사용자가 실제로 겪는 불편인지, 팀의 병목인지, 자동화했을 때 다시 쓰일지, 실패해도 배울 수 있는지 판단해야 한다.
발표 자료에서도 “무슨 문제를 풀 것인가”가 앞에 나온다. 좋은 태도와 취향이 있으면 좋은 문제가 찾아온다는 말은 낭만처럼 보이지만, 실무에서는 꽤 현실적이다. 같은 AI 도구를 써도 누군가는 장난감 데모만 만들고, 누군가는 팀의 반복 업무를 없애는 작은 CLI를 만든다. 차이는 도구가 아니라 문제 감각이다.
내가 TECHTAEK 글감에서 계속 보는 것도 이 부분이다. “새 AI 도구 출시”는 글감이 될 수 있지만, 그대로 쓰면 뉴스 요약이다. “이 도구를 내 워크플로에 붙이면 어디서 실패하고, 어떤 기준으로 멈춰야 하는가”까지 가야 실전 글이 된다. 개발도 같다. 기능을 만드는 것보다 기능이 풀어야 할 일을 먼저 좁혀야 한다.
2. 좋은 스펙을 쓰는 개발자
AI에게 “대시보드 만들어줘”라고 말하면 대시보드 비슷한 것이 나온다. 그런데 “사용자가 오늘 할 일을 3개 상태로 보고, 실패한 항목은 원인과 다음 행동을 남기며, 모바일 폭 390px에서 카드가 겹치지 않아야 한다”라고 말하면 결과가 달라진다. 좋은 스펙은 AI에게 자세한 잔소리가 아니라, 성공 조건을 기계가 확인할 수 있게 바꾸는 일이다.
스펙은 길다고 좋은 게 아니다. 좋은 스펙은 모호한 말을 줄인다. “빠르게”, “예쁘게”, “깔끔하게”보다 “첫 화면에서 5초 안에 다음 행동을 고를 수 있게”, “버튼 텍스트가 2줄을 넘지 않게”, “실패 시 재시도 버튼과 원인을 같이 보여주게”가 낫다.
발표 자료의 “좋은 스펙”도 결정론적으로 통과 여부를 평가할 수 있는 인수 테스트와 유닛 테스트가 있는 상태로 설명된다. 이건 AI 시대에 더 중요하다. 사람이 혼자 코딩할 때도 스펙은 중요했지만, AI가 코드를 빠르게 만들수록 잘못된 스펙의 피해도 빨리 커진다.
| 나쁜 요청 | 더 나은 스펙 |
|---|---|
| 로그인 화면 예쁘게 만들어줘 | 이메일/비밀번호 오류를 분리 표시하고, 모바일 390px에서 CTA가 접히지 않게 만들어줘 |
| 블로그 글 발행해줘 | frontmatter, FAQ, 출처, preflight, 중복 발행 가드를 통과한 뒤 published URL까지 닫아줘 |
| 데이터 정리해줘 | 원본 컬럼, 변환 규칙, 누락값 처리, 검증 샘플 20건을 표로 남겨줘 |
| 자동화해줘 | read-only 단계, 승인 단계, write 단계, 롤백 명령을 나눠줘 |
3. 테스트와 검증기를 준비하는 개발자
AI에게 일을 맡기는 팀에서 테스트는 선택지가 아니다. 테스트가 없으면 AI는 “그럴듯한 결과”를 낸다. 그럴듯함은 데모에서는 예쁘지만 운영에서는 무섭다. 특히 코드 변경, 데이터 이동, 결제, 권한, 발행 자동화는 테스트가 없으면 사람이 매번 눈으로 검수해야 한다.
테스트는 꼭 거창한 자동화부터 시작할 필요는 없다. acceptance criteria 5개, 실패 케이스 3개, 반드시 보존해야 할 기존 동작 3개만 적어도 AI의 행동이 달라진다. 여기에 lint, unit test, integration test, preflight script가 붙으면 더 좋다.
내 블로그 파이프라인의 preflight도 작은 검증기다. frontmatter가 있는지, 본문 분량과 문단 밀도가 맞는지, FAQ와 출처가 있는지, 관련 글 링크가 실제 공개 URL인지 본다. 글쓰기에서도 검증기가 필요하다면, 코드에서는 말할 것도 없다. 테스트 없는 AI 코딩은 안전벨트 없이 전동 킥보드 타는 느낌이다. 편한데, 넘어지면 설명이 길어진다.
리더 입장에서 좋은 개발자는 “제가 봤을 때 괜찮습니다”에서 멈추지 않는다. “이 테스트를 통과했고, 이 케이스는 아직 사람이 봐야 하며, 이 실패는 롤백 가능합니다”라고 말한다. 이 문장이 팀을 안심시킨다.
4. 에이전트가 일할 환경을 만드는 개발자
AI 에이전트는 똑똑해도 작업 환경이 나쁘면 금방 멍해진다. 파일 구조가 뒤죽박죽이고, 명령어가 문서화되어 있지 않고, 테스트 실행법이 없고, 권한이 과하게 열려 있으면 AI는 속도만 빠른 신입이 된다. 열심히 하는데 사고도 같이 낸다.
좋은 환경은 AGENTS.md, README, 명확한 scripts, 작은 명령어, 안정적인 test command, lint, sample data, rollback 방법으로 만들어진다. 사람에게 온보딩 문서가 필요하듯 AI에게도 작업 문맥이 필요하다. 차이는 AI가 문서를 정말 열심히 읽는다는 점이다. 그러니 문서가 틀리면 틀린 것도 열심히 따른다.
발표 자료에서 에이전트를 사람처럼, 그러나 사람과 다르게 대하라는 관점도 여기와 닿아 있다. 에이전트를 존중한다는 말은 감정 표현만 뜻하지 않는다. 목표를 간결하게 주고, 도구를 쥐어주고, 좋은 코드베이스와 검증 환경을 마련하는 쪽이 더 실용적이다.
개발자는 이제 코드 작성자이면서 에이전트 작업장 관리자에 가깝다. 어떤 파일을 읽게 할지, 어떤 명령은 허용할지, 언제 사람에게 멈춰서 확인을 요청하게 할지 설계해야 한다. 이건 새 직무처럼 보이지만 사실 좋은 개발자가 원래 하던 일의 확장이다.
5. 꾸준히 학습하고 공유하는 개발자
AI 시대에는 한 번 익힌 도구가 오래가지 않는다. 모델, IDE, CLI, 에이전트, MCP, A2A, 워크플로가 계속 바뀐다. 그래서 리더가 원하는 사람은 모든 최신 도구를 다 아는 사람이 아니라, 새 도구를 자기 일에 붙여보고 배운 것을 팀에 전달하는 사람이다.
발표 자료의 “프로불편러”, “매주 작은 도구 만들기”, “어려운 문제와 쉬운 문제를 모두 직접 풀어보기”는 개발자에게 꽤 좋은 훈련 루프다. 어려운 문제는 한계를 알려주고, 쉬운 문제는 도구 감각을 만든다. 둘 중 하나만 하면 균형이 깨진다.
여기서 공유가 중요하다. AI로 만든 결과만 공유하면 팀은 따라 하기 어렵다. 대신 입력, 스펙, 실패, 테스트, 비용, 시간, 바꾼 점을 공유해야 한다. “이렇게 했더니 됨”보다 “여기서 막혔고 이렇게 줄였더니 됨”이 훨씬 비싸다. 실패 로그는 창피한 게 아니라 다음 사람의 지도다.
이 관점에서 블로그도 개발자의 작업 일부가 된다. 글을 쓰는 건 자기 홍보만이 아니다. 자신이 어떤 문제를 보고, 어떤 기준으로 도구를 고르고, 어디서 실패했는지 공개하는 일이다. AI 시대에는 이런 기록이 포트폴리오이자 팀 학습 자산이 된다.
실무에서 바로 쓰는 10분 체크표
지금 내 일을 기준으로 아래 5칸만 채워보면 된다. 첫째, 내가 풀 문제는 누구의 어떤 반복 불편인가. 둘째, 성공 조건은 사람이 아니라 테스트가 확인할 수 있을 만큼 명확한가. 셋째, 실패 케이스는 3개 이상 적었는가. 넷째, AI가 읽을 문서와 실행할 명령이 준비되어 있는가. 다섯째, 결과와 실패 로그를 다음 사람이 볼 수 있게 남겼는가.
이 체크표가 있으면 AI에게 일을 던지는 방식이 달라진다. “만들어줘”가 아니라 “이 조건을 만족하게 만들고, 실패한 테스트는 먼저 보고해줘”가 된다. 개발자는 AI를 부리는 사람이 아니라 AI가 일할 수 있는 판을 만드는 사람이 된다.
| 체크 칸 | 질문 | 산출물 |
|---|---|---|
| 문제 | 누구의 반복 불편인가 | 문제 한 문장 |
| 스펙 | 성공을 어떻게 판정하나 | acceptance criteria |
| 테스트 | 무엇이 깨지면 실패인가 | 실패 케이스 3개 |
| 환경 | AI가 무엇을 읽고 실행하나 | AGENTS/README/scripts |
| 공유 | 다음 사람이 무엇을 이어받나 | 로그와 회고 |
흔한 실수 TOP 5
첫 번째 실수는 AI가 코딩을 잘하니 스펙이 덜 중요해졌다고 보는 것이다. 실제로는 반대다. AI가 빨라질수록 스펙 오류가 더 빨리 제품에 들어간다.
두 번째 실수는 테스트를 나중으로 미루는 것이다. 테스트가 없으면 AI는 정답을 향해 가는지, 예쁜 오답을 만드는지 구분하기 어렵다. 나중에 붙이는 테스트는 대개 나중에도 안 붙는다. 우리 모두 그 “나중”이라는 동네에 살아봤다.
세 번째 실수는 에이전트에게 사람처럼 모든 맥락을 눈치로 알아듣길 기대하는 것이다. 사람도 못 알아듣는다. AI도 못 알아듣는다. 문서, 명령, 예시, 금지사항을 남겨야 한다.
네 번째 실수는 최신 도구를 쓰는 것 자체를 역량으로 착각하는 것이다. 도구 이름을 많이 아는 것보다, 하나의 반복 문제를 실제로 줄인 기록이 더 강하다.
다섯 번째 실수는 결과물만 공유하는 것이다. AI 시대에는 과정 로그가 가치다. 어떤 프롬프트, 어떤 테스트, 어떤 실패, 어떤 수정이 있었는지 공유해야 팀의 속도가 올라간다.
FAQ
Q. AI 시대에도 코딩 실력은 중요한가?
중요하다. 다만 코딩 실력의 의미가 넓어진다. 직접 코드를 쓰는 능력에 더해, AI가 만든 코드를 읽고 검증하고, 스펙과 테스트로 원하는 결과를 끌어내는 능력이 같이 필요하다.
Q. 좋은 스펙은 얼마나 자세해야 하나?
긴 문서보다 판정 가능한 조건이 중요하다. 화면, 데이터, 에러, 권한, 성능, 예외를 기준으로 “무엇이면 통과이고 무엇이면 실패인지”를 적으면 된다. acceptance criteria 5개부터 시작해도 충분하다.
Q. 테스트가 없는 레거시 코드에서는 어떻게 시작하나?
전체 테스트를 한 번에 만들려고 하면 막힌다. 먼저 바꾸려는 기능의 현재 행동을 3개 정도 스냅샷으로 고정하고, 변경 후에도 유지되어야 할 조건을 적는 방식이 현실적이다. 작은 characterization test부터 시작하면 된다.
Q. 주니어 개발자는 무엇부터 훈련하면 좋나?
작은 문제를 골라 스펙, 테스트, 구현, 회고까지 한 사이클로 끝내는 연습이 좋다. AI에게 구현을 맡겨도 좋지만, 스펙과 테스트를 직접 쓰고 결과를 설명하는 부분은 꼭 해봐야 한다.
Q. 리더는 팀에 무엇을 먼저 요구해야 하나?
AI 사용량보다 작업 계약을 먼저 요구하는 편이 낫다. “어떤 문제를 풀었고, 어떤 스펙으로 맡겼고, 어떤 테스트를 통과했고, 어떤 실패를 남겼는가”를 팀 루틴으로 만들면 AI 도구가 바뀌어도 운영 기준은 남는다.
함께 보면 좋은 글
- Codex 활용 사례 52개를 보고 먼저 정할 것 2026 – 업무 위임 기준표
- DeepSWE 이후 AI 코딩 에이전트를 고를 때 벤치마크 숫자만 보면 위험한 이유 2026
- 프롬프트보다 로그가 먼저 보일 때 2026 – AI 에이전트가 실패하는 흔한 이유