AI가 코드를 짜는 시대, 개발자로서 느낀 것들

2026. 2. 17. 21:31·dev.log

개요

AI가 하루가 다르게 발전하고 있습니다. 개발자로서, 지금 느끼는 것들과 제가 나아갈 방향을 정리해보려 합니다.

달라진 개발 환경

AI가 발전하면서 개발자들의 작업 방식이 크게 바뀌었습니다. 구글링과 공식 문서 대신 AI를 통해 질의응답을 하며 개발하는 것이 자연스러워졌고, 회사에서도 AI를 적극적으로 활용하는 모습이 눈에 띕니다.

 

코드 자동완성, 리팩토링 제안, 테스트 코드 생성까지 개발의 거의 모든 단계에 AI가 깊숙이 들어와 있습니다. 불과 3년 전만 해도 "AI가 코드를 짠다"는 말이 반신반의의 대상이었는데, 지금은 AI 없이 개발하는 것이 오히려 비효율적으로 느껴질 정도입니다.

개발자 채용 시장의 변화

AI가 개발자를 대체할 날이 얼마 남지 않았다는 이야기도 심심치 않게 들립니다. 실제로 채용 시장을 보면 신입 공고가 눈에 띄게 줄었고, 주변만 봐도 최소 3년차 이상의 경력직을 원하는 곳이 대부분입니다.

 

이유는 단순합니다. 실무에 바로 투입할 수 있는 경력직을 뽑아 AI를 활용하게 하면, 신입 여러 명 몫의 효율을 낼 수 있기 때문입니다.

 

여기서 한 가지 더 주목할 점이 있습니다. 단순히 "코드를 작성할 수 있는 사람"의 수요가 줄어드는 것이 아니라, "무엇을 만들어야 하는지 판단하고 설계할 수 있는 사람"의 가치가 높아지고 있다는 것입니다. 코드를 짜는 행위 자체는 AI가 빠르게 따라잡고 있지만, 비즈니스 요구사항을 기술적 의사결정으로 전환하는 능력은 여전히 사람의 영역에 가깝습니다.

그래서 지금, 나는 어떻게 해야 할까

결론부터 말하면, 대체될 수 없는 개발자가 되어야 한다고 생각합니다. 아무리 AI가 개발자를 대신한다 해도, 결국 어떤 개발자의 명령에 의해 움직일 것입니다. 그렇다면 그 명령을 내리는 사람이 되면 됩니다.

1. 적극적인 AI 활용

솔직히 처음에는 AI에 대한 거부감이 있었습니다. 어렵게 느껴지기도 했고, 굳이 써야 하나 싶기도 했습니다. 하지만 돌이켜보면 그건 관심이 없었기에 생긴 막연한 두려움이었습니다. 공식 문서나 개발자 블로그를 찾아 읽으며 AI의 기능들을 하나씩 파악하기 시작하니, 단순히 명령을 내리는 것 이상으로 상황에 맞게 활용할 수 있는 폭이 넓다는 걸 알게 되었습니다.

 

최신 동향도 놓치지 않기 위해 지인분께 해외 개발 관련 유튜버들을 추천받아 구독하고, 실제 활용 사례를 살펴보기도 했습니다. 인상적이었던 것은 해외 개발자들이 하나의 AI와 대화하며 개발하는 수준을 넘어, 여러 에이전트를 병렬로 활용하고 있다는 점이었습니다. 몇 주에서 몇 달이 걸릴 기능을 하루 만에 만들어내는 모습도 볼 수 있었습니다.

 

여기서 느낀 점은, AI를 "잘 쓴다"는 것이 단순히 프롬프트를 잘 작성하는 데서 그치지 않는다는 것입니다. 어떤 작업을 AI에게 위임할지, 어떤 단위로 나누어 지시할지, 결과물을 어떻게 검증할지까지 포함하는 워크플로우 설계 능력이 필요합니다. 이 능력은 결국 개발 경험과 도메인 이해도에서 나온다고 생각합니다.

 

그리고 이 도메인 이해도는 단순히 AI 활용에만 국한되지 않을 수 있다는 생각도 들었습니다. 개발자는 요구사항 분석, 설계, 구현, 운영까지 서비스의 전체 생애주기에 관여하면서 도메인과 직접적으로 맞닿아 있습니다. 이렇게 쌓인 도메인 지식에 AI 활용 능력이 더해진다면, 기획자 없이도 하나의 서비스를 직접 만들어 사업화하는 것도 충분히 가능하다고 봅니다.

2. 활용만으로는 부족하다

자연어로 AI에게 명령을 내려 개발하는 것에는 한계가 있습니다. 개발 지식이 있는 상태에서 AI를 활용하는 것과, 아무 지식도 없는 상태에서 AI를 활용하는 것은 완전히 다릅니다.

 

예를 들어, AI에게 "게시판 만들어줘"라고 하면 그럴듯한 코드가 나옵니다. 하지만 그 코드가 N+1 문제를 일으키는지, 트랜잭션 범위는 적절한지, 동시성 이슈는 없는지, 보안 취약점은 없는지를 판단하려면 결국 개발자 본인의 지식이 필요합니다. 코드 레벨뿐만 아니라 인프라 구성이나 아키텍처 선택까지, AI가 제안하는 결과물이 내가 만들고자 하는 서비스에 정말 적합한지는 결국 직접 확인하고 판단할 수 있어야 합니다. AI가 만든 코드를 "그대로 쓰는 사람"과 "검증하고 개선할 수 있는 사람" 사이에는 큰 차이가 있다고 생각합니다.

3. 판단력을 기르기 위한 꾸준한 공부는 필수

결국 이런 판단과 결정을 내리기 위해서는 탄탄한 개발 지식이 필요합니다. 새로운 기술을 꾸준히 공부하면서, 궁극적으로는 트레이드오프 상황에서 공부한 내용들을 되짚어보며 올바른 판단을 내릴 수 있도록 연습해야 합니다. 단순히 "이 기술을 안다"가 아니라, "이 상황에서 왜 이 기술을 선택했는가"를 설명할 수 있는 수준이 되어야 한다고 생각합니다.

마치며

지금까지의 이야기를 정리하면, 결국 제가 되고 싶은 개발자의 모습은 PM에 가까운 개발자입니다.

 

AI가 코드를 대신 작성해주는 시대에, 개발자의 본질적인 가치는 더 이상 좋은 코드를 직접 작성하는 것에 있지 않습니다. 오히려 "무엇을, 왜 만들어야 하는가" 를 정의하고, 기술적으로 올바른 방향을 설계하는 능력이 핵심이라고 생각합니다. 요구사항을 분석하고, 우선순위를 정하며, 기술적 제약 속에서 최적의 판단을 내리는 것은 PM의 역할이기도 합니다. 하지만 도메인과 기술 양쪽을 깊이 이해하는 개발자가 이 과정에 참여할 때, 훨씬 더 정확하고 실질적인 결정이 가능해진다고 봅니다.

결국 제가 지향하는 방향은, AI에게 무엇을 시킬지 판단하고 그 결과를 검증하며 서비스 전체의 방향을 잡을 수 있는 개발자입니다. 코딩 실력만으로 평가받는 시대는 지나가고 있고, 앞으로는 이런 판단력을 갖춘 개발자가 살아남을 것이라고 생각합니다.

 

이를 위해 블로그를 통해 개발 중 생기는 이슈와 고민을 꾸준히 정리해 나가려 합니다. 글을 쓰는 과정 자체가 모호했던 개념을 구체화하고, 판단의 근거를 명확히 하는 데 큰 도움이 되기 때문입니다. 2026년은 부족한 부분들을 하나씩 채워나가는 한 해로 만들겠습니다. 이 글이 그 첫 시작으로, 멈추지 않고 꾸준히 흐르고자 합니다.

'dev.log' 카테고리의 다른 글

계층형 CTE 한 줄이 주석 처리된 코드 세 줄을 살린다  (0) 2026.03.08
PUT vs PATCH, 팩트만 정리합니다  (0) 2026.03.01
도메인 모델이 뚱뚱해지고 있다면, Read Model을 도입할 때입니다  (0) 2026.02.25
'dev.log' 카테고리의 다른 글
  • 계층형 CTE 한 줄이 주석 처리된 코드 세 줄을 살린다
  • PUT vs PATCH, 팩트만 정리합니다
  • 도메인 모델이 뚱뚱해지고 있다면, Read Model을 도입할 때입니다
kyeongwoo.ryu
kyeongwoo.ryu
꾸준함이야말로 가장 가치 있는 능력이라고 생각하며, 하루하루 배우고 흘러가는 과정을 기록합니다.
  • kyeongwoo.ryu
    Rio.dev
    kyeongwoo.ryu
    • 분류 전체보기 (10) N
      • dev.log (4)
      • life.log (6) N
  • 링크

    • GitHub
  • 최근 글

kyeongwoo.ryu
AI가 코드를 짜는 시대, 개발자로서 느낀 것들
상단으로

티스토리툴바