AI 시대의 개발자 - Problem Solvers to Problem Definers
AI가 코드를 작성하는 시대에 개발자의 역할은 어떻게 바뀌고 있을까. 개발자의 새로운 역할에 대한 개인적인 생각.
AI와 함께 일하는 개발자
AI의 발전
AI를 계속 사용하다 보면 어느 순간 이런 생각이 든다.
“이걸 내가 하는 게 맞나?”
코드 작성, 디버깅, 테스트 생성, 리팩토링, 문서 작성까지
이제는 상당 부분을 AI가 처리한다.
예전에는 많은 사람들이 이렇게 말하곤 했다.
“AI는 창의적이지 못하다.”
하지만 지금은 상황이 꽤 달라졌다.
AI는 더 이상 단순한 자동완성 도구가 아니다.
꽤 유능한 협업 파트너에 가까워지고 있다.
실제로 AI가 인간보다 확실하게 더 잘하는 영역도 있다.
AI가 더 잘하는 것들
AI와 함께 개발을 하다 보면 체감하게 된다.
AI는 다음과 같은 일들을 놀라울 정도로 빠르게 해낸다.
- 코드 작성 속도
- UI 구현
- 문서 정리
- 블로그 글 구조화
- 디버깅 힌트
- 리팩토링
솔직히 말하면,
단순 구현만 놓고 보면 AI가 인간보다 빠를 때도 많다.
그래서 가끔 이런 생각이 들기도 한다.
“앞으로 개발자는 필요 없는 거 아닐까?”
하지만 AI를 조금 더 오래 사용하다 보면
다른 사실도 점점 보이기 시작한다.
AI가 못하는 것도 있다!
AI는 실행을 매우 잘한다.
하지만 다음과 같은 질문에는
여전히 인간의 역할이 크게 남아 있다.
1. 문제 정의
AI에게는 이런 질문을 할 수 있다.
1
"React로 검색 기능 구현해줘"
그러면 AI는 꽤 괜찮은 코드를 만들어준다.
하지만 그 전에 더 중요한 질문이 있다.
- 우리는 왜 검색 기능이 필요한가?
- 어떤 사용자가 사용할까?
- 실시간 검색이 필요한가?
- 서버 검색이 맞을까, 클라이언트 필터링이 맞을까?
AI는 주어진 문제를 해결하는 것에는 강하다.
하지만
어떤 문제를 풀어야 하는지 결정하는 것
이건 여전히 인간의 영역이다.
2. 연구 질문
연구에서도 마찬가지다.
예를 들어 내가 연구하고 있는 주제가 있다면
AI에게 이런 질문은 할 수 있다.
1
"formant extraction python code"
하지만 진짜 중요한 질문은 이런 것들이다.
- 성공률에 큰 영향을 미치는 진짜 중요한 변수는 무엇일까?
- Formant는 피해야 할까, 활용해야 할까?
- 어떤 실험이 의미 있는 결과를 만들까?
AI는 코드와 구현을 도와줄 수 있다.
하지만
어떤 질문을 해야 하는지
그 질문 자체는 보통 연구자의 경험에서 나온다.
3. 경험에서 나오는 인사이트
AI는 데이터를 기반으로 답한다.
하지만 개발을 하다 보면
데이터로 설명하기 어려운 경험적 직감이 생긴다.
예를 들면 이런 것들이다.
- “FEMU 써보니까 Hot / Cold 분리가 생각보다 중요하더라.”
- “nsh 만들면서 느낀 건 이 구조가 디버깅하기 훨씬 편하다.”
- “Pipe보다 Shared Memory가 실제로 훨씬 빠르다.”
이런 판단은 보통
- 실제로 구현해보고
- 실패도 해보고
- 여러 번 실험하면서
몸으로 축적되는 지식이다.
AI는 이런 경험을 직접 축적하지는 못한다.
4. 맥락과 판단
AI는 정답을 잘 만든다.
하지만 정답이 항상 정답은 아니다.
예를 들어 이런 상황을 생각해 보자.
- 이 기술이 우리 상황에 맞는가?
- 이 구조가 3개월 뒤에도 유지 가능한가?
- 성능보다 개발 속도가 더 중요한 상황인가?
이건 단순한 기술 문제가 아니라
맥락을 이해하는 문제
다.
그리고 맥락은
- 팀 상황
- 제품 방향
- 일정
- 경험
같은 것들과 깊게 연결되어 있다.
결국 개발자의 역할은 바뀌고 있다
그래서 요즘 점점 이런 생각이 든다.
AI 시대에 개발자의 가치는
코드를 얼마나 빨리 쓰느냐가 아닐 수도 있다.
오히려 더 중요한 것은 이것에 가까워 보인다.
- 문제를 정의하는 능력
- 좋은 질문을 찾는 능력
- 경험에서 나온 판단
- 맥락을 이해하는 능력
즉 앞으로의 개발자는
단순히 코드를 만드는 사람이 아니라
문제를 정의하고 방향을 설계하는 사람
에 더 가까워질지도 모른다.
AI 시대에 더 중요해지는 능력: 안목
AI를 계속 사용하다 보면서 한 가지 능력이 점점 더 중요하다고 느꼈다.
나는 이걸 “안목”이라고 부르고 싶다.
여기서 말하는 안목은 단순한 취향이 아니다.
어떤 것이 좋은지, 나쁜지, 지금 상태가 어떤지 정확히 판단하는 능력이다.
예를 들어 이런 상황을 생각해보자.
AI에게 이런 요청을 한다.
1
"React로 검색 기능 구현해줘"
AI는 꽤 괜찮은 코드를 만들어낸다.
- debounce 적용
- API 호출
- 로딩 상태 처리
- 기본적인 UI
겉보기에는 잘 동작하는 코드다.
하지만 여기서 중요한 질문이 생긴다.
- 이 구조가 지금 프로젝트에 맞는가?
- 이 코드가 과한 설계는 아닌가?
- 성능을 위해 불필요한 최적화를 하고 있지는 않은가?
- 더 단순한 방법은 없는가?
AI는 코드의 가능한 정답을 만든다.
하지만 그 정답이 지금 상황에서 좋은 선택인지 판단하는 것은 인간의 몫이다.
그래서 점점 이런 구조가 만들어진다.
1
2
AI : 빠르게 많은 선택지를 만든다
사람 : 그 중에서 무엇이 좋은지 판단한다
AI가 강해질수록
오히려 판단 능력의 가치가 더 올라간다.
좋은 안목은 어떻게 만들어질까
문제는 여기서 생긴다.
안목은 책 한 권 읽는다고 생기지 않는다.
대부분의 경우 다음 세 가지에서 만들어진다.
1. 많이 만들어보기
코드를 많이 읽는 것보다
직접 많이 만들어보는 경험이 훨씬 중요하다.
왜냐하면 개발에서는 이런 일이 매우 자주 일어나기 때문이다.
처음 만든 구조
→ 몇 달 뒤 유지보수 지옥
처음에는 멋있어 보이는 구조가
나중에는 가장 큰 기술 부채가 되는 경우도 많다.
이런 경험을 몇 번 겪고 나면
자연스럽게 이런 감각이 생긴다.
“이 구조는 미래의 나를 괴롭히겠다.”
이게 바로 안목의 시작이다.
2. 실패 경험
흥미로운 점은
안목은 보통 성공보다 실패에서 더 많이 생긴다는 것이다.
예를 들어 이런 경험들이다.
- 과한 abstraction
- 불필요한 microservice
- premature optimization
- 지나치게 복잡한 상태 관리
처음에는 좋은 설계처럼 보인다.
하지만 실제 프로젝트에서는 종종 이렇게 끝난다.
1
결론: 그냥 단순하게 만들 걸.
이런 실패들이 쌓이면서
판단 기준이 생기기 시작한다.
3. 많이 비교하기
AI 시대에는 이 방법이 특히 강력하다.
AI에게 여러 가지 방법을 동시에 물어보는 것이다.
예를 들어 이런 식이다.
1
2
3
4
"이 문제를 해결하는 방법을
3가지 아키텍처로 설명해줘.
각 방식의 장단점도 비교해줘."
그러면 AI는 보통 이런 결과를 준다.
- 방법 A
- 방법 B
- 방법 C
이때 중요한 것은 답을 그대로 쓰는 것이 아니라
비교하면서 판단하는 과정이다.
1
2
3
왜 이 방법이 더 단순하지?
왜 이 구조가 더 유지보수하기 좋지?
왜 이 방법이 더 느릴까?
이런 질문과 경험이 쌓이면
자연스럽게 이런 판단이 가능해진다.
“이 방식은 너무 과하다.
더 단순한 방법이 있을 거야.”
이게 바로 안목이다.
AI와 일하면서 생긴 새로운 감각: AI와의 팀플(?)
재밌는 변화도 하나 생겼다.
예전에는 협업을 굉장히 좋아했다.
여러 명이 모여서
- 아이디어를 나누고
- 설계를 고민하고
- 같이 구현하는 과정
이게 개발의 큰 즐거움 중 하나였다.
그런데 요즘은
조금 이상한 경험을 하고 있다.
나는 분명히 혼자 프로젝트를 하고 있는데
혼자라는 느낌이 잘 들지 않는다.
왜냐하면 작업 흐름이 보통 이렇게 흘러가기 때문이다.
1
2
3
4
5
6
7
8
9
10
나: 아이디어 제안
GPT: 코드 초안 생성
Claude: 구조 개선 제안
나: 방향 수정
AI: 구현 반복
이걸 계속 하다 보면
이상하게 팀플을 하는 느낌이 든다.
물론 AI는 사람이 아니다.
하지만 역할이 분명히 나뉘기 시작한다.
- 어떤 AI는 코드를 잘 짜고
- 어떤 AI는 설명을 잘하고
- 어떤 AI는 구조를 잘 정리한다
그래서 요즘은 개발할 때
이런 생각을 자주 하게 된다.
“누가 이걸 제일 잘하지?”
재밌는 건 여기서
나도 팀원 중 하나가 된다는 점이다.
그래서 필요한 능력: 메타인지
AI와 협업하는 시대에는
한 가지 능력이 특히 중요해진다.
메타인지다.
즉
내가 무엇을 잘하고
무엇을 못하는지
그리고 AI가 무엇을 잘하고 못하는지
정확히 아는 능력이다.
예를 들어 이런 판단이 필요하다.
1
2
3
4
5
이건 내가 직접 짜는 게 빠르다
이건 AI에게 맡기는 게 낫다
이건 같이 고민해야 한다
이 판단이 정확할수록
AI와의 협업 효율이 크게 올라간다.
결국 AI 시대의 개발은
이런 형태에 가까워질지도 모른다.
1
AI + 인간 = 새로운 팀
그리고 그 팀에서 가장 중요한 역할은
아마도 이것일 것이다.
누가 무엇을 해야 하는지 판단하는 사람
그래서 결국 다시 처음 질문으로 돌아온다.
AI 시대에 개발자의 진짜 가치는 무엇일까?
내가 내린 결론은 꽤 단순하다.
코드를 잘 쓰는 사람보다
문제를 잘 정의하고, 좋은 판단을 하고, 경험에서 인사이트를 만드는 사람
이런 사람이 더 중요해질 가능성이 크다.
그리고 그 과정에서
AI는 경쟁자가 아니라
가장 강력한 협업 도구
가 될 수도 있다.
AI 의존의 위험
AI와 함께 개발하면 생산성이 정말 많이 올라간다.
예전에는 몇 시간 걸리던 작업이
지금은 몇 분 안에 끝나기도 한다.
- 보일러플레이트 코드
- 기본적인 UI 구현
- 테스트 코드
- 간단한 버그 수정
이런 것들은 이제 AI가 훨씬 빠르다.
문제는 여기서 시작된다.
너무 편하다.
그리고 너무 편한 도구는
항상 의존을 만들기 쉽다.
인터넷이 끊겼던 날
한 번은 논문 마감이 얼마 남지 않았을 때였다.
실험 코드를 조금 수정해야 했는데
갑자기 인터넷이 끊겼다.
평소 같으면 이렇게 했을 문제였다.
1
2
"PyTorch에서 이런 레이어 구조 만들고 싶은데
이 코드가 맞을까?"
그리고 몇 초 뒤에
AI가 코드와 함께 설명을 준다.
그런데 그날은 인터넷이 없었다.
그래서 혼자 코드를 다시 짜기 시작했다.
평소라면 2~3분이면 끝났을 작업이
그날은 30분 정도 걸렸다.
그때 문득 이상한 생각이 들었다.
“나는 이걸 이해하고 있었던 걸까?”
“아니면 그냥 AI에게 묻는 데 익숙해져 있었던 걸까?”
AI가 문제를 해결해 주는 동안
나는 생각하는 과정을 일부 건너뛰고 있었을지도 모른다.
기초가 약해질 수 있다
이건 특히 주니어 개발자에게 더 위험할 수 있다.
예를 들어 이런 상황이 반복된다고 해보자.
1
2
3
4
5
Junior: 배열 정렬 어떻게 해요?
AI: [정렬 코드]
Junior: 복붙 → 작동
문제는 코드가 잘 작동한다는 것이다.
그래서 더 이상 고민하지 않게 된다.
하지만 이런 방식이 반복되면
1년이 지나도 이런 질문에 답하기 어려울 수 있다.
- 정렬 알고리즘의 시간 복잡도는?
- 언제 quicksort가 좋고 언제 mergesort가 좋을까?
- built-in sort는 내부적으로 어떻게 동작할까?
AI는 문제를 빠르게 해결하지만
그 과정에서 학습 기회가 사라질 수도 있다.
블랙박스 코드
또 다른 문제는 이해하지 못한 코드다.
예전에 이런 코드를 본 적이 있다.
1
2
3
4
const optimized = useMemo(
() => data.map(x => transform(x)),
[data, transform]
);
코드를 작성한 사람에게 물어봤다.
“왜 useMemo를 쓴 거예요?”
대답은 간단했다.
“AI가 넣어줘서요.”
문제는 이 코드가 실제로는
최적화가 아니라 오히려 성능을 떨어뜨릴 수 있는 코드였다는 점이다.
AI는 종종 “그럴듯한 코드”를 만든다.
그리고 그럴듯한 코드는
생각보다 쉽게 사람을 속인다.
그래서 점점 더 중요한 원칙이 생긴다.
이해한 코드만 사용한다.
창의성이 줄어드는 순간
AI를 사용하면서 느낀 또 하나의 이상한 경험이 있다.
가끔은 내 아이디어를 스스로 버리게 된다.
예전에 게임 애니메이션을 고민하던 적이 있었다.
내가 생각한 아이디어는 단순했다.
- 카드가 선택되면 살짝 확대되는 효과
그런데 AI에게 물어보니
이런 아이디어를 제안했다.
- 파티클 효과
- 회전 애니메이션
- 확대 + 글로우 효과
훨씬 화려했다.
그래서 순간 이런 생각이 들었다.
“내 아이디어가 너무 단순한가?”
하지만 실제로 구현해보니
결과는 정반대였다.
단순한 카드 확대 효과가 훨씬 좋았다.
AI는 많은 아이디어를 제안할 수 있다.
하지만
좋은 아이디어와 화려한 아이디어는 다르다.
그리고 그 차이를 판단하는 것은
여전히 사람의 몫이다.
그래서 내가 정한 몇 가지 원칙
AI를 계속 사용하다 보니
나름대로 몇 가지 기준이 생겼다.
1. 이해한 코드만 사용한다
AI가 만든 코드라도
내가 설명할 수 없다면 사용하지 않는다.
최소한 이 질문에는 답할 수 있어야 한다.
- 이 코드는 왜 필요한가?
- 이 구조의 장점은 무엇인가?
- 언제 문제가 생길 수 있는가?
2. 새로운 알고리즘은 직접 구현해본다
정렬, 그래프 탐색, 신호 처리 같은 것들은
AI가 코드를 만들어주더라도
한 번은 직접 구현해본다.
직접 구현해보면
문서로 이해하는 것과 완전히 다른 감각이 생긴다.
3. 가끔은 AI 없이 코딩한다
이건 의도적으로 하는 연습이다.
가끔은
- AI를 끄고
- 문서만 보고
- 직접 구현해본다.
속도는 느리지만
사고 과정이 다시 살아난다.
4. 핵심 로직은 직접 만든다
AI에게 맡겨도 되는 부분이 있다.
- 보일러플레이트
- 반복 코드
- 기본적인 UI
- 테스트 코드
하지만 핵심 로직은 가능하면 직접 만든다.
왜냐하면 그 부분이
프로젝트의 진짜 이해와 연결되어 있기 때문이다.
내가 찾은 균형
지금 기준으로 체감 비율은 대략 이 정도다.
AI가 하는 일 (약 60%)
- 보일러플레이트 코드
- 리팩토링
- 테스트 코드
- 디버깅 힌트
- 문서 초안
내가 하는 일 (약 40%)
- 핵심 알고리즘
- 시스템 아키텍처
- UX 흐름 설계
- 최종 검증
이 방식이 지금까지는
가장 균형이 좋았다.
개발 속도는 확실히 빨라졌고
동시에 코드에 대한 이해도도 유지할 수 있었다.
그래서 결국 결론은 단순하다.
AI는 분명 강력한 도구다.
하지만 개발자의 경쟁력은
AI를 쓰느냐 마느냐가 아니라
AI를 어떻게 활용하느냐
에 달려 있을 가능성이 크다.
앞으로의 개발자
많은 사람들이 이미 느끼고 있을 것이다.
개발자의 역할은 조금씩 바뀌고 있다.
예전에는 대략 이런 구조였다.
1
2
Junior: 기능 구현
Senior: 설계 + 코드 리뷰 + 의사결정
하지만 AI가 개발 과정에 깊게 들어오면서
구조가 조금씩 달라지고 있다.
몇 년 뒤에는 이런 형태가 더 자연스러울지도 모른다.
1
2
AI: 구현 + 테스트 + 기본 최적화
인간: 문제 정의 + 설계 + 판단
즉 앞으로는
단순 구현 능력만으로 차별화하기 어려워질 가능성이 있다.
코드를 쓰는 능력 자체는
점점 더 평준화될 가능성이 크기 때문이다.
그래서 더 중요해지는 능력들이 있다.
1. 큰 그림을 보는 능력
AI는 개별 문제를 매우 잘 해결한다.
하지만 시스템 전체를 설계하는 일은
여전히 사람의 영역에 가깝다.
예를 들어 어떤 서비스를 만든다고 해보자.
AI에게는 이런 질문을 할 수 있다.
1
"Node.js에서 Redis 캐싱 적용하는 방법 알려줘"
AI는 꽤 좋은 코드를 만들어준다.
하지만 그 전에 더 중요한 질문들이 있다.
- 캐싱이 정말 필요한가?
- 어떤 데이터를 캐싱해야 하는가?
- TTL은 어떻게 설정해야 하는가?
- 캐시가 깨졌을 때 전략은 무엇인가?
이 질문들은 단순한 코드 문제가 아니라
설계 문제다.
그리고 설계는 보통
- 경험
- 맥락
- 트레이드오프 판단
같은 것들과 연결되어 있다.
2. 좋은 질문을 찾는 능력
AI 시대에는 질문의 수준이 결과의 수준을 결정한다.
예를 들어 이런 질문을 생각해보자.
나쁜 질문
1
사이트가 느린데 왜 그런지 알려줘
좋은 질문
1
2
3
4
5
6
7
8
9
10
11
12
Next.js 앱에서 페이지 로딩이 3초 정도 걸립니다.
환경
Node.js 서버
PostgreSQL
페이지에서 API 5개 호출
가능한 병목 지점을 추정하고
성능 개선 방법을 제안해주세요.
질문이 구체적일수록
AI의 답변도 훨씬 정확해진다.
그래서 AI 시대에는
질문하는 능력 자체가 하나의 기술이 된다.
- 문제를 명확하게 설명하는 능력
- 필요한 조건을 정리하는 능력
- 원하는 결과를 구체적으로 표현하는 능력
이런 것들은
모두 연습으로 좋아진다.
3. 계속 배우는 능력
AI가 강해질수록
아이러니하게도 학습 속도가 더 중요해진다.
왜냐하면 기술의 변화 속도가
훨씬 빨라질 가능성이 크기 때문이다.
예전에는
- 새로운 프레임워크 학습
- 새로운 언어 학습
이런 것들이 몇 년 단위로 일어났다.
하지만 지금은
- 새로운 AI 도구
- 새로운 개발 방식
- 새로운 협업 방식
이 계속 등장하고 있다.
그래서 앞으로 중요한 능력 중 하나는
아마 이것일 것이다.
빠르게 배우고 적응하는 능력
AI vs 인간이 아니다
AI 이야기가 나오면
항상 이런 질문이 나온다.
“AI가 개발자를 대체할까?”
하지만 실제로는
조금 다른 경쟁이 될 가능성이 크다.
1
AI를 잘 쓰는 사람 vs AI를 못 쓰는 사람
AI는 점점 더 강력해지고 있다.
그래서 중요한 것은
AI를 피하는 것이 아니라
AI와 함께 일하는 방법을 배우는 것
일지도 모른다.
그리고 아마
앞으로의 개발자는 점점 이런 모습에 가까워질 것이다.
- 코드를 많이 쓰는 사람보다
문제를 많이 정의하는 사람
- 구현을 많이 하는 사람보다
- 방향을 많이 설계하는 사람
AI는 실행을 담당하고
인간은 방향을 정한다.
이 조합이 앞으로의 개발에서
가장 강력한 형태가 될 수도 있다.
그래서 나는 이렇게 생각한다
AI 시대의 개발자는
단순히 “코드를 잘 쓰는 사람”이 아니라
다음과 같은 능력을 가진 사람에 가까워질 것이다.
- 문제를 정의하는 사람
- 좋은 질문을 만드는 사람
- 경험에서 인사이트를 얻는 사람
- 기술의 트레이드오프를 판단하는 사람
그리고 무엇보다
AI를 협업 도구로 사용할 수 있는 사람
결론 — 개발자는 무엇이 되는가
AI를 오래 사용하다 보면 한 가지 변화가 분명하게 느껴진다.
개발의 중심이
“코드를 어떻게 작성할까”에서
“어떤 문제를 풀어야 할까”로 이동하고 있다는 것이다.
예전에는 구현이 가장 큰 장벽이었다.
아이디어가 있어도
코드를 직접 만들어야 했고
실험하는 데에도 시간이 많이 걸렸다.
하지만 AI가 등장하면서 상황이 조금 바뀌었다.
이제는 구현 자체보다
무엇을 만들지 결정하는 것이 더 중요한 문제가 되고 있다.
AI는 실행을 잘한다.
- 코드를 만든다
- 버그를 찾는다
- 구조를 정리한다
하지만 여전히 어려워하는 것이 있다.
- 어떤 문제를 풀어야 하는지
- 어떤 방향이 맞는지
- 어떤 선택이 더 나은지
결국 개발자의 역할은 점점 이런 쪽으로 이동하고 있다.
1
구현자 → 문제 설계자
코드를 많이 쓰는 사람보다
좋은 문제를 정의하는 사람.
기술을 많이 아는 사람보다
무엇이 중요한지 판단할 수 있는 사람.
그리고 AI를 경쟁자가 아니라
협업 도구로 사용할 수 있는 사람.
AI 시대의 개발자는 아마 이런 모습에 더 가까워질 것이다.
문제를 설계하고 방향을 결정하는 사람.
즉, AI 시대에 중요한 능력은 코딩이 아니라 좋은 문제를 찾는 능력이다.
Tags: #AI #Developer #Career #Future #Balance