AI 시대, 개발자에게 필요한 것
AI 시대에 개발자는 무엇을 해야 할까.
AI 시대, 개발자에게 필요한 것
AI는 생각보다 빠르게 발전하고 있다
AI를 쓰다 보면 가끔 이런 생각이 든다.
“이걸 내가 하는 게 맞나?”
코드 작성, 디버깅, 테스트 생성, 리팩토링까지 이제는 상당 부분을 AI가 처리한다.
예전에는 나를 포함한 대부분의 사람들이 이렇게 말하곤 했다.
“AI는 창의적이지 못하다.”
하지만 지금은 상황이 꽤 달라졌다.
Midjourney는 세상에 없던 그림을 만들어내고, GPT-4는 내가 요청한 것보다 더 나은 코드를 제안한다. Claude는 내가 놓친 엣지 케이스까지 찾아낸다.
모방은 창조의 어머니라는 말이 있다.
AI는 인류가 만들어 온 방대한 데이터를 학습하고, 그 안에서 패턴을 찾아 새로운 방식으로 조합한다.
어쩌면 특정 영역에서는 인간보다 더 창의적으로 보일 때도 있다.
게다가 몇 년 전까지만 해도 AI의 가장 큰 문제로 지적되던 할루시네이션도 점점 줄어들고 있다.
2023년에는 존재하지 않는 함수를 아무렇지 않게 제안하던 모델들이, 2024년에는 확신이 없으면 검색을 권장하기 시작했고, 2025년의 모델들은 스스로 추론 과정을 거치며 답을 검증한다.
AI는 이제 단순한 자동완성 도구가 아니다.
꽤 유능한 협업 파트너에 가깝다.
그렇다면,
AI 시대에 개발자는 무엇을 해야 할까?
AI가 정말 놀라웠던 순간들
AI를 쓰면서 가장 놀랐던 순간은 보통 이런 순간이었다.
“이걸 내가 묻지도 않았는데?”
AI는 종종 내가 질문한 것보다 한 단계 위의 문제를 짚어낸다.
한 번은 Three.js 렌더링이 너무 느려서 AI에게 물어봤다.
렌더링이 느린데 뭐가 문제일까?
AI의 답변은 이랬다.
Instanced Mesh를 사용하는 게 좋습니다.
그런데 매 프레임마다 geometry를 업데이트하고 있네요.
static mesh는 미리 생성하고 dynamic한 것만 업데이트하면 훨씬 빠릅니다.
내 질문은 단순히 “왜 느릴까?”였다.
하지만 AI는 코드 전체를 보고
내가 생각하지 못한 구조적인 문제를 짚어냈다. (아마 많은 개발자들이 비슷한 경험을 수도 없이 겪었을 것이다.)
이런 경험이 매우 많이 반복되면서 느꼈다.
AI는 단순한 코드 생성기가 아니다.
코드를 작성해주는 도구라기보다
꽤 괜찮은 조수이자 리뷰어에 가깝다.
결국 중요한 건 “활용 능력”
AI를 꽤 오래 사용하면서 한 가지는 확실하게 느끼게 됐다.
AI는 혼자 두면 방향 없이 떠다닌다.
목표가 없으면 그저 그럴듯한 답을 만들어낼 뿐이다.
하지만 인간이 방향을 잡아주면 그때부터 엄청난 속도로 달린다.
결국 중요한 건 AI 자체가 아니라 AI를 활용하는 능력이다.
1. 문제 정의
예를 들어 이런 질문이 있다고 해보자.
나쁜 질문:
사이트가 느린데 왜 그런지 알려줘
좋은 질문:
Next.js 앱에서 페이지 로딩이 3초 정도 걸린다.
환경:
- 서버: Node.js
- 데이터베이스: PostgreSQL
- 페이지에서 API 5개 호출
가능한 병목 지점을 추정하고 성능 개선 방법을 제안해줘.
AI는 질문의 수준만큼 똑똑해진다.
2. 반복과 개선
AI의 첫 번째 답변은 보통 완성본이 아니라 초안이다.
그래서 중요한 건 한 번의 질문이 아니라 반복적인 개선이다.
예를 들어 React 컴포넌트를 만들 때도 이런 식이다.
1차 요청
React로 모달 컴포넌트 만들어줘
→ 기본적인 모달만 생성됨
2차 요청
React로 모달 컴포넌트 만들어줘
- ESC 키로 닫기
- 배경 클릭 시 닫기
→ 기본적인 UX가 추가됨
3차 요청
React 모달 컴포넌트
요구사항
- ESC 키로 닫기
- 배경 클릭 시 닫기
- fade-in / fade-out 애니메이션
- body scroll lock
→ 실사용 가능한 수준
4차 요청
React + TypeScript로 모달 컴포넌트 작성
요구사항
- 접근성 고려 (aria attributes)
- ESC 키로 닫기
- 배경 클릭 시 닫기
- body scroll lock
- fade animation
→ 실제 프로젝트에 넣어도 되는 코드
이렇게 몇 번만 반복해도 결과의 퀄리티는 크게 달라진다.
AI는 마법이 아니다.
초안을 빠르게 만들고, 반복 개선을 쉽게 해주는 도구에 가깝다.
그래서 AI를 잘 쓰는 사람들의 공통점이 있다.
한 번에 완벽한 질문을 하는 사람이 아니라
질문을 계속 개선하는 사람이다.
결국 AI 시대에는 질문하는 능력 자체가 하나의 기술이 된다.
- 문제를 명확하게 설명하는 것
- 필요한 조건을 정리하는 것
- 원하는 결과를 구체적으로 표현하는 것
이런 것들은 모두 연습으로 좋아진다.
그래서 요즘은 가끔 이렇게 생각한다.
코딩 연습만큼이나
질문하는 연습도 필요하다.
3. 도메인 지식
AI를 쓰면서 가장 중요하다고 느낀 건 도메인 지식이다.
예전에 음성 관련 연구를 하면서 이런 코드를 AI가 제안한 적이 있었다.
1
formants = librosa.piptrack(y, sr)
하지만 이건 틀린 코드였다.
piptrack은 pitch tracking이고 formant 추출은 다른 방식으로 해야 한다.
AI는 그럴듯한 코드를 만들어낸다. 하지만 틀린 코드도 꽤 자연스럽게 만든다.
그래서 결국 판단은 사람이 해야 한다.
AI 의존의 위험
하지만 AI를 너무 편하게 쓰다 보니 조금 이상한 경험을 한 적이 있다.
논문 마감이 얼마 남지 않았던 어느 날 갑자기 인터넷이 끊겼다.
그리고 나는 혼자서 실험 코드를 구현해야 하는 상황이 됐다.
평소 같으면 AI에게 한 줄 질문하면 금방 해결될 문제였다.
그런데 인터넷이 없다는 이유만으로 같은 작업에 30분이나 걸렸다.
그때 문득 깨달았다.
나는 알고리즘을 이해하고 있었던 게 아니라
AI에게 질문하는 방법만 익숙해져 있었던 것이었다.
AI는 강력하지만 동시에 위험한 도구이기도 하다.
특히 개발자에게는 세 가지 문제가 생길 수 있다.
기초가 쌓이지 않는다
1
2
3
Junior: 배열 정렬 어떻게 해요?
AI: [코드]
Junior: 복붙 → 작동
이게 반복되면 1년이 지나도 정렬 알고리즘을 이해하지 못한다.
블랙박스 코드
예전에 이런 코드도 본 적이 있다.
1
2
3
4
const optimized = useMemo(
() => data.map(x => transform(x)),
[data, transform]
);
작성자에게 물어봤다.
“useMemo 왜 썼어요?”
대답은 간단했다.
“모르겠는데 AI가 넣어줬어요.”
게다가 이 코드는 실제로 최적화가 아니라 오히려 느려질 수 있는 코드였다.
창의성 위축
아이러니하게도 AI가 너무 똑똑하면 오히려 내 아이디어를 버리게 될 때도 있다.
예전에 체인 애니메이션을 고민하면서 나는 단순하게 카드 확대 효과를 생각했다.
그런데 AI는 이런 아이디어를 제시했다.
파티클 + 확대 + 회전
너무 화려해서 순간 내 아이디어가 별로처럼 느껴졌다.
하지만 실제로 적용해보니 단순한 카드 확대가 훨씬 좋았다.
AI 의존을 피하기 위한 더 중요한 능력
AI를 계속 사용하다 보니 한 가지 생각이 점점 확실해졌다.
AI 시대에는 “세밀한 구현 능력”보다 “큰 그림을 보는 능력”이 더 중요해질 가능성이 크다.
코드 작성 자체는 이미 AI가 꽤 잘한다.
보일러플레이트 작성, 간단한 로직 구현, 테스트 코드 생성 같은 작업은 AI가 훨씬 빠르게 처리하기도 한다.
하지만 다음과 같은 질문들은 여전히 사람의 영역에 가깝다.
- 전체 아키텍처는 어떻게 설계해야 할까?
- 사용자 경험 흐름은 어떤 게 자연스러울까?
- 이 기능이 정말 필요한 걸까?
- 지금 구조가 3개월 뒤에도 유지될 수 있을까?
AI는 문제를 잘 해결한다.
하지만 어떤 문제를 풀어야 하는지 결정하는 것은 아직 인간의 몫이다.
예시 1 — 시스템 설계
예를 들어 어떤 서비스를 만든다고 가정해 보자.
AI에게는 이런 질문을 할 수 있다.
“Node.js에서 Redis 캐싱을 적용하는 방법을 알려줘.”
AI는 코드와 설정을 꽤 잘 만들어준다.
하지만 그 전에 이런 질문들이 먼저 필요하다.
- 캐싱이 정말 필요한가?
- 캐싱해야 할 데이터는 무엇인가?
- TTL은 어떻게 설정할 것인가?
- 캐시가 깨졌을 때 전략은 무엇인가?
이 질문들은 단순한 코드 문제가 아니라 설계 문제다.
예시 2 — 기능 개발
예를 들어 새로운 기능을 만든다고 할 때도 마찬가지다.
AI에게는 이렇게 요청할 수 있다.
“React로 검색 기능 구현해줘.”
AI는 검색 UI와 API 호출 코드를 금방 만들어낸다.
하지만 실제로 중요한 질문은 이런 것들이다.
- 검색 결과는 실시간이어야 할까?
- debounce를 적용해야 할까?
- 서버 검색이 맞을까, 클라이언트 필터링이 맞을까?
- 검색 결과가 없을 때 UX는 어떻게 처리할까?
AI는 구현을 빠르게 해주지만,
제품의 방향과 경험을 결정하는 건 여전히 사람이다.
내가 느낀 역할 분담
이걸 가장 크게 느낀 건 개인 프로젝트를 만들 때였다.
예를 들어 내가 만든 게임 Rise of the Half Moon에서도 자연스럽게 역할이 나뉘었다.
AI가 잘하는 것
- UI 세부 스타일
- 애니메이션 타이밍 조정
- 반복적인 코드 작성
- 간단한 버그 수정
내가 해야 하는 것
- 게임 메커니즘 설계
- 보드 구조 설계
- 난이도 곡선 설계
- 전체 플레이 경험
결국 나는 구현보다 설계에 더 많은 시간을 쓰게 됐다.
AI가 개발 속도를 높여주면서
오히려 생각하는 시간이 더 많아진 셈이다.
내가 정한 균형
그래서 나름대로 몇 가지 원칙을 정해두고 사용하고 있다.
- 이해한 코드만 사용한다
- 새로운 알고리즘은 직접 구현해본다
- 가끔은 AI 없이 코딩해본다
- 핵심 로직은 직접 만든다
AI가 너무 편하기 때문에
의식적으로 균형을 잡지 않으면 의존도가 쉽게 높아지기 때문이다.
지금 기준으로 체감 비율은 대략 이 정도다.
AI가 하는 일 (약 60%)
- 보일러플레이트 코드 (특별한 비즈니스 로직은 없고 기본 구조만 만드는 코드)
- 리팩토링
- 테스트 코드
- 디버깅 힌트
- 문서 초안
내가 하는 일 (약 40%)
- 핵심 알고리즘
- 시스템 아키텍처
- UX 흐름 설계
- 최종 검증
이 방식이 지금까지는 가장 균형이 좋았다.
개발 속도는 확실히 빨라졌고
동시에 코드에 대한 이해도도 유지할 수 있었다.
앞으로의 개발자
많은 사람들이 이미 느끼고 있을 것이다.
개발자의 역할은 조금씩 바뀌고 있다.
지금
- 주니어: 기능 구현
- 시니어: 설계, 코드 리뷰, 의사결정
몇 년 뒤
- AI: 구현, 테스트, 기본 최적화
- 인간: 설계, 방향 설정, 검증
즉 앞으로는 단순 구현 능력만으로는 차별화가 어려워질 가능성이 있다.
그래서 더 중요해지는 능력이 있다.
- 큰 그림을 보는 사람
- AI를 제대로 활용하는 사람
- 계속 배우는 사람
결국 개발자는 점점 코드를 많이 쓰는 사람이 아니라
문제를 정의하고 해결 방향을 설계하는 사람에 가까워질지도 모른다.
결론
AI는 분명 양날의 검이다.
잘 활용하면 생산성과 학습 속도가 눈에 띄게 빨라진다.
아이디어를 실험하는 속도도 훨씬 빨라진다.
하지만 반대로 잘못 사용하면 기초가 약해지고, 사고 과정 자체를 건너뛰게 될 수도 있다.
그래서 앞으로의 경쟁은 아마 이렇게 바뀔 가능성이 크다.
AI vs 인간이 아니라
AI를 잘 쓰는 인간 vs AI를 못 쓰는 인간
중요한 건 AI를 쓰느냐 마느냐가 아니라 어떻게 사용하느냐다.
AI를 활용하되 의존하지 않고, 빠르게 개발하되 이해하면서 앞으로 나아가는 것.
세밀한 구현은 AI에게 맡기고 우리는 문제를 정의하고 큰 그림을 설계하는 역할을 해야 한다.
AI 시대는 분명 쉽지 않다. 개발자에게도 많은 변화가 생길 것이다.
하지만 준비된 사람에게는 오히려 꽤 큰 기회가 될 수도 있다.
그러니 너무 위축될 필요는 없다.
대신 계속 배우고, 계속 생각하고, 계속 만들어보자.
우리 모두 잘 살아남아 보자.
이상. AI 시대의 무기력해진 개발자들에게.
Tags: #AI #Developer #Career #Future #Balance