도입
지난 몇 주간 블로그·자동화 파이프라인을 만들면서 AI를 꽤 집중적으로 써봤습니다. 그 과정에서 "AI가 개발자 직무를 얼마나 대체할까"라는 질문에 대해 추상적인 전망이 아니라 구체적인 감각이 생겨서, 그걸 정리해봅니다.

"대체"보다 "역할 분담"에 가깝다는 체감
본문에 들어가기 전에 결론부터 말하면, 지금까지의 경험으로는 "대체"보다는 "역할 분담"에 가까웠습니다. AI가 통째로 대체하는 일이 아니라, 특정 종류의 작업을 훨씬 빠르게 처리해주는 파트너에 가까웠습니다.
AI가 잘하는 영역
1) 범위가 명확히 주어졌을 때의 초안 생성
블로그 초안, 코드 스켈레톤, 설정 파일 작성 같은 작업은 구체적인 지시만 있으면 빠르고 정확합니다.
2) 마지막이 아닌 "1차" 검토
CI에서 코드 디프를 먼저 훑어보거나, 명백한 실수를 거르는 데는 사람보다 일관성 있게 빠릅니다.
3) 반복적이고 구조가 명확한 작업
같은 패턴의 코드를 여러 곳에 복사해서 적용하는 작업은 AI가 사람보다 지치지 않고 일관성도 높습니다.
4) 보일러플레이트와 테스트 코드 초안
제가 만들고 있는 이미지 편집 앱 프로젝트에서도, 반복되는 화면 구조나 테스트 코드 초안은 대부분 AI에게 맡기고 결과물을 훑어보는 정도로 처리했습니다. 판단 기준은 단순한데, "결과물이 잘못됐을 때 제가 바로 알아챌 수 있는가"입니다. 익숙한 패턴이라 이상하면 바로 티가 나는 작업은 맡기는 편이고, 버그 수정이나 소규모 리팩터링은 AI가 초안을 만들면 제가 diff를 한 줄씩 읽으며 의도와 다른 부분만 고치는 식으로 절충했습니다.
AI가 약한 영역
1) 범위가 모호할 때
지난번에 주제를 구체적으로 지정하지 않았더니 AI가 임의로 범위를 좁혀버리는 경험을 했습니다. 사람은 "이 요청이 말이 안 되네"를 알아채지만, AI는 그대로 무언가를 만들어냅니다.
2) 시간이 지나면 바뀌는 사실관계
가격, 버전, 정책 같은 값을 웹검색 없이 물으면 AI가 학습 데이터 시점의 구형값을 그대로 내놓습니다. 이번 프로젝트에서 실제로 구형 모델명을 그대로 쓴 사례를 두 번이나 직접 몸으로 겪었습니다. 같은 프롬프트를 AI 두 개에 나란히 돌려본 적도 있는데, 하나는 웹검색 없이 가격이나 이름을 그럴듯하게 지어냈고 다른 하나는 직접 검색해서 확인한 값을 반영했습니다. 결국 AI 자체의 우열보다, 그 작업에 필요한 도구(웹검색 등)에 접근할 수 있느냐가 결과물의 신뢰도를 갈랐습니다.
3) "맞는지"가 아니라 "좋은지" 판단
여러 옵션 중 어느 것이 이 프로젝트의 방향성과 맞는지는, 결국 맥락을 아는 사람이 결정해야 합니다. 예를 들어 이미지 편집 앱에 AI 이미지 생성 API를 붙일 때, 모더레이션 threshold를 얼마로 둘지가 그랬습니다. 너무 엄격하면 정상적인 요청까지 걸러지고, 너무 느슨하면 원치 않는 콘텐츠가 통과할 위험이 있어서, 카테고리별로 값을 나눠 조정하며 균형점을 찾아야 했습니다. AI는 초기값을 제안해줄 수는 있어도, "이 정도가 이 서비스에 맞는 균형인가"는 실제로 써보면서 사람이 판단할 수밖에 없었습니다.
어디까지 맡길지 정하는 기준
프로젝트를 진행하면서 자연스럽게 정리된 기준이 있습니다.
- 보일러플레이트, 테스트 코드 초안, 익숙한 패턴의 반복 작업: AI에게 대부분 맡깁니다. 결과물을 훑어보는 정도로 충분합니다.
- 버그 수정, 소규모 리팩터링: AI가 초안을 만들고, diff를 한 줄씩 읽으며 의도와 다른 부분만 고칩니다.
- 아키텍처 설계, 기술 선택, 사용자 경험에 직결되는 판단(예: 모더레이션 기준, 데이터 구조 변경): 직접 합니다. AI 제안은 참고 자료 정도로만 씁니다.
이 구분의 기준은 결국 하나였습니다. "잘못됐을 때 제가 알아챌 수 있는가." 익숙한 영역이라 결과물이 이상하면 바로 티가 나는 작업은 맡기고, 제가 판단 근거를 세우지 못하는 영역은 직접 했습니다.
주의사항 / 흔한 실수
- 결과물을 검증 없이 그대로 쓰면 위험합니다. 특히 사실관계가 개입되는 부분은 반드시 직접 확인해야 합니다.
- 범위를 명확히 주지 않으면 AI가 임의로 채웁니다. 이건 AI의 문제라기보다 지시자의 문제에 가깝습니다.
- "대체된다/안 된다"의 이분법으로 보기보다, 어떤 작업이 어느 범주에 속하는지 분류하는 게 더 유용합니다.
마무리
정리하면, 직접 겪은 범위 안에서는 AI가 "개발자를 대체한다"보다는 "반복적이고 명확한 작업을 맡는다"가 더 정확한 표현이었습니다. 보일러플레이트나 반복 패턴은 맡기고, 잘못됐을 때 알아채기 어려운 판단(아키텍처, 사용자 경험에 직결되는 기준)은 직접 하는 식으로 역할을 나누다 보니 자연스럽게 이 결론에 도달했습니다. 맡길 작업과 직접 판단해야 하는 작업을 구분하는 감각은 앞으로도 계속 쓸 것 같습니다.
[핵심요약] AI가 개발자를 대체하는가, 직접 겪은 소감
'개발자 인사이트' 카테고리의 다른 글
| 티스토리 개인 도메인, 서브디렉토리로는 안 되는 이유 (0) | 2026.07.14 |
|---|---|
| AI 코딩 툴, 어디까지 맡기고 어디부터 직접 할까 (0) | 2026.07.13 |
| 지출 없이 시작하는 AI 자동화 부업, 실제로 해보았읍니다 (0) | 2026.07.13 |
| AI 콘텐츠 자동화, 모델보다 중요한 건 이거였습니다 (0) | 2026.07.13 |