[AI] AI 시대, 개발자에 대한 생각

더 늦기 전에 이런 주제로 한 번쯤 정리해보고 싶었다. 시간이 지날수록 AI가 빠르게 발전하면서, 지금 이 생각마저도 틀린 말이 되거나 도태된 생각이 될 수 있으니까. (그래서 오래 지난 뒤 이 글을 본다면 틀린 말도 많을 것이다. 그렇지만 현재 상황에서 보고 생각한 바를 써보려 한다.)

 

AI가 하루가 다르게 바뀌고 있다. 나도 계속해서 Claude Code를 만지작거리고 있다. 서브에이전트 구성, CLAUDE.md 세팅, 토큰 최적화. 주변 개발자들한테 "AI 어떻게 써?" 물어보고 다니면서, 나름 꿀팁도 모으고 있었다. 자극적인 뉴스들 속에서 "뭘 해야 하지", "대체되는 거 아냐" 생각하면서, 도태되지 않으려고 어찌저찌 따라가고 있다.

 

근데 어느 순간, 이런 생각이 들었다. 내가 지금 모으고 있는 이 스킬들, 결국 뭘 위한 거지?

 

AI를 잘 쓰는 게 목적인가? 아니다. AI를 잘 써서 뭔가를 더 빠르게, 더 정확하게 만들어내는 게 목적이다.

 

그렇다면 AI의 끝은 뭘까?

완벽한 자동화다.

 

나보다 똑똑한 두뇌가 생겼다.

모든 일은 점점 자동화되어가고 있다. 인간은 어찌 보면 계속 더 편하게 할 수 있는 도구를 만들어왔다. 개발자도 비슷하다. 예전엔 수동으로 서버 배포하던 걸 CI/CD로 자동화했다. 수동 테스트를 자동화 테스트로 바꿨다. 반복되는 코드를 프레임워크가 대신한다. 모니터링도, 알림도, 스케일링도 자동화한다.

 

물론 개발자가 하는 일을 모두 자동화할 수 있던 건 아니었다. 새로운 사용자 경험을 만들어내는 것, 복잡한 시스템을 설계하는 것, 도메인 전문가와 문제 자체를 재정의하는 것. 단순히 도와주는 도구만으로 이런 걸 대체할 순 없었다.

 

하지만 지금은 다르다. 두뇌가 붙은 애가 일을 대신 처리해준다. AI가 언어를 이해하고, 맥락을 파악하고, 코드를 설계한다. 시킨 대로만 하던 기계에 생각할 수 있는 머리가 달린 거다. 그리고 그 머리가 하루가 다르게 좋아지고 있다.

 

이미 판단의 영역까지 넘어오고 있다. AI가 코드 리뷰를 하고, 아키텍처를 제안하고, 버그의 원인을 분석한다. "이건 A안보다 B안이 낫습니다, 이유는 이렇습니다"까지 말해준다. 예전에는 시니어 개발자한테 물어봐야 했던 판단을, 이제 AI가 꽤 그럴듯하게 해내고 있다. 자율주행은 이미 매 순간 운전 "결정"을 하고, 알고리즘 트레이딩은 투자 "결정"을 한다. 결정 자체는 점점 AI가 해내고 있다.

 

그러면 개발자에게 남는 건 뭘까?

 

지금은, AI의 판단을 판단하는 사람, 그리고 그 결과를 책임지는 사람이다. AI가 "B안이 낫습니다"라고 해도, 진짜 B안으로 갈지 결정하는 건 사람이다. 그 선택이 장애를 내면, "AI가 그러라고 했는데요"라는 변명은 통하지 않는다. 이게 영원할까? 모른다. 다만 그 자리에 서 있는 동안 최대한 잘하는 게 지금 내가 할 수 있는 일이지 않을까 싶다.

 

그러면 앞으로 뭐가 남게 될까?

물론 언제까지 남을진 모르지만 지금 상황에서 생각해 보면, 크게 두 가지로 나뉘지 않을까 싶다.

1. 뭘 만들지 정하고, 방향을 잡는 능력

뭘 만들 건지. 어떤 구조로 갈 건지. 이 기능이 진짜 필요한 건지. 세 가지 선택지 중 뭘 고를 건지.

AI가 코드를 다 짜줘도, "뭘 짜라고 할 건지"는 사람이 정해야 한다. 그리고 이걸 얼마나 명확하게 정의하느냐가 결과물의 질을 좌우한다.

 

이 판단에는 두 가지 종류가 있다. 하나는 기획적인 판단이다. 예를 들어 주문 시스템을 만든다고 하면, "반품 정책을 어디까지 허용할 건지", "이 기능이 매출에 기여하는지", "MVP에 뭘 넣고 뭘 뺄지". 다른 하나는 기술적인 판단이다. "이 구조로 가면 확장성은 좋지만 복잡도가 올라간다", "여기서 캐시를 쓰면 빠르지만 데이터 일관성 문제가 생긴다", "동시 접속 100명을 어떤 방식으로 처리할 건지". 기획과 기술, 양쪽 다 알아야 제대로 된 결정을 내릴 수 있다. AI한테 말해주지 않으면 알아서 적당히 처리하거나, 아예 고려하지 못하는 경우도 많다. (물론 이 마저도 대체되고 있다!)

 

아직은 같은 AI를 쓰더라도, 어떤 사람은 이런 핵심을 짚어서 한 번에 원하는 걸 뽑아내고, 어떤 사람은 이리저리 헤매다가 시간만 쓴다. 이 차이가 순수하게 "판단력" 때문인지, 도구 숙련도나 도메인 경험 때문인지는 솔직히 딱 잘라 말하기 어렵다. 다 섞여 있다. 다만 내 경험상, 뭘 만들어야 하는지를 모르면 도구를 아무리 잘 다뤄도 삽질이 길어졌다. 그래서 근본은 판단력이라고 생각한다.

 

근데 "요구사항을 명확히 정의한다"는 게 말처럼 쉽지 않다. 처음부터 깔끔하게 정리된 요구사항 같은 건 거의 없다. 비즈니스 맥락을 이해하고, 사용자가 진짜 뭘 원하는지 파악하고, 기술적 제약 안에서 타협점을 찾아야 한다. 이건 코드를 잘 짜는 것과는 완전히 다른 스킬이다. 그리고 이걸 제대로 해본 사람과 안 해본 사람의 차이는, AI가 아무리 좋아져도 쉽게 메워지지 않는다.

 

2. 얼마나 효율적으로 실현하느냐

방향이 잡히면, 나머지는 실행이다.

물론 현실에서 "기획 끝 -> 실행 시작"으로 깔끔하게 나뉘는 경우는 거의 없다. 코드를 짜다가 "이건 이렇게 하면 안 되겠다"라고 깨닫기도 하고, 프로토타입을 만들어보고 방향이 바뀌기도 한다. 기획과 실행은 계속 왔다 갔다 한다. 그런데 AI가 이 왔다 갔다를 엄청나게 빠르게 만들어준다. 프로토타입을 하루 만에 뽑아볼 수 있으니까, "일단 만들어보고 판단하자"가 현실적인 전략이 될 수도 있다.

 

게다가 이제 실행의 모습 자체가 예전과 다르다. 코드 짜는 것도, 테스트 돌리는 것도, 배포하는 것도, 리팩터링 하는 것도 AI한테 시킬 수 있다. 그러면 개발자가 하는 건 뭐냐? 워크플로우를 설계하는 거다. AI한테 뭘 어떤 순서로 시킬지, 어떤 맥락을 줘야 더 좋은 결과가 나오는지, 결과물을 어떻게 검증할지. 이런 전체 흐름을 짜는 게 실행의 핵심이 됐다.

그리고 아직은 AI가 종종 틀린다. 자신 있게 내놓은 답이 엉뚱한 경우도 있고, 그럴듯하게 포장된 실수를 알아채려면 결국 사람이 봐야 한다.

 

그리고 AI는 이 둘 다에 걸쳐 있다

여기서 한 가지 짚고 싶은 게 있다. AI를 그냥 "자동화 도구"라고 부르기엔 뭔가 부족하다.

Jenkins는 내 판단력을 키워주지 않는다. 쉘 스크립트도 마찬가지다. 그냥 시킨 대로 할 뿐이다. 반면 AI는 내가 더 좋은 판단을 할 수 있게 도와준다. "이 구조가 맞을까?" 물어보면 트레이드오프를 분석해 주고, 내가 모르는 분야를 빠르게 리서치해주고, 선택지를 비교 정리해 준다. 자동화 도구이면서 동시에 판단의 보조 도구다.

 

다른 것에 비유하자면, AI는 전동 드릴 정도가 아니다. 코드를 짜고, 테스트를 돌리고, 아키텍처까지 제안한다. 거의 집을 알아서 짓는 로봇에 가깝다. 물론 이 로봇이 더 똑똑해지면 "어떤 집을 지을지"까지 알아서 정하는 날이 올 수도 있다. 하지만 지금은 아직 "이 동네에, 이 예산으로, 이 가족 구성에 맞는 집"을 판단하려면 사람이 맥락을 줘야 한다. 그리고 로봇이 짓고 있는 집이 제대로 되고 있는지 확인하는 것도 사람의 몫이다.

 

그래서 AI를 잘 쓴다는 건, 실행을 빠르게 하는 것만이 아니라 더 나은 결정을 내리는 데도 활용하는 것까지 포함한다. 앞서 말한 두 가지, 방향 잡기와 효율적 실현. AI는 그 둘 다를 증폭시켜 준다. 그래도 "뭘 시킬지, AI가 내놓은 결과를 어떻게 볼지"는 내 몫이다.

 

그렇다면 지금 현실은?

앞에서 판단력이 핵심이라고 했다. 하지만 "도구는 별로 안 중요하다"로 결론 내리면 그건 거짓말이다.

 

같은 기능을 만드는데, 한 사람은 AI를 잘 활용해서 하루 만에 끝내고, 다른 한 사람은 일주일이 걸린다. 결과물 품질도 비슷하거나 오히려 전자가 낫다. 기업 입장에서 누구를 선택할까? 답은 뻔하다. AI를 빠르게 습득해서, 남들보다 효율적으로, 더 좋은 결과물을 내는 것. 이게 완전히 자동화가 되기 전까지엔 현실적으로 중요할 것 같다.

 

물론 AI가 발전할수록 사람 간의 차이는 점점 줄어들 거다. 언젠가는 누가 써도 비슷한 결과가 나오는 시대가 올 수 있다. 근데 채용이라는 관점에서 생각해 보면, 기업이 마지막까지 개발자를 뽑는다면 누구를 뽑겠나? AI 성능이 좋아질수록 인간의 몸값 자체가 낮아지는 시대다. 그러면 기왕이면 조금 더 주고, 지식이 깊은 사람, AI를 잘 다루는 사람, 문제를 덜 일으킬 사람을 뽑지 않을까. 신뢰가 중요한 회사일수록 그렇다. 물론 이제 막 창업하는 팀이라면 얘기가 다르다. 거기선 지금도 누구든 만들 수 있다.

 

그리고 이건 개발자만의 이야기가 아닐 것이다. AI가 실행의 장벽을 낮춰주면서, 모든 직군의 경계가 흐려지고 있다. 백엔드 개발자가 프론트도 치고 기획서도 쓰고, 디자이너가 코드로 프로토타입을 만들고, 기획자가 데이터 분석을 직접 한다. "나는 이것만 해요"가 점점 통하지 않는다. 한 사람이 해낼 수 있는 범위가 확 넓어지는 거다.

 

길게 보면 "영역이 넓어진다"가 아니라 "사라진다"가 맞는 표현일 수도 있다. 개발자가 없어지는 세상이 온다면 변호사도 회계사도 세무사도 같이 없어질 거다. 이건 특정 직군의 위기가 아니라 시대 자체의 전환이다. 그리고 그게 개인이 열심히 한다고 해결되는 차원의 문제가 아닐 수도 있다.

 

그래도 "없어진다 vs 안 없어진다"를 놓고 싸우는 건 답이 없다. 그걸 누가 아냐. 개인이 창업해서 내가 새로 판을 짜겠다면 모를까, 지금 기업에서 일하고 있거나 취업을 준비하는 입장이라면 할 수 있는 건 지금에 맞춰가면서 내 영역을 찾아가는 것뿐이다. 그리고 그렇게 따라가다 보면, 어쩌면 진짜 내가 뭔가를 만들어내 창업도 할 수 있는 기회가 보일 수도 있다.

다만, 순서가 있다.

• 먼저, 결정할 수 있는 사람이 되는 것. 뭘 만들지 판단하고, 방향을 잡고, 트레이드오프를 따지는 것. 이게 없으면 AI를 아무리 잘 써도 엉뚱한 걸 빠르게 만들 뿐이다.
• 그다음, AI를 빠르게 익혀서 실현 속도를 높이는 것. 새로운 도구를 빠르게 습득하고, 자기 워크플로우에 녹여내고, 판단의 보조 도구로도 활용하는 것. 좋은 결정을 내려도 실현이 느리면 의미가 반감된다.

순서가 바뀌어도 뭔가를 만들어낼 수는 있다. 근데 그건 AI를 효율적으로 쓰는 거라고 보기 어렵다. 결정 먼저, 자동화는 그다음인 것 같다.

 

그래서 나는 뭘 하고 있나?

거창하게 썼지만, "그래서 어떻게?"가 더 중요하다. 내가 요즘 의식적으로 하려는 건 이 정도다.

 

결정할 수 있는 영역을 넓히기 위해

• 내 역할을 기획 쪽으로 넓혀가고 있다. 요구사항을 분석하고, 뭘 만들어야 하는지 정의하는 것. 이게 명확할수록 AI한테 시키기도 쉬워진다. 다만 처음부터 완벽한 기획은 없다. 실제로는 기획 -> 구현 -> 피드백 -> 기획 수정, 이 루프를 빠르게 도는 게 핵심이다. AI가 이 루프의 속도를 높여준다.
• 그래서 요즘 더 신경 쓰는 건, "개발할 때 뭐가 정해져 있어야 하는가?"를 먼저 따지는 것이다. 어떤 정보가 확정되어야 개발에 들어갈 수 있는지, 어떤 결정이 빠져 있는지. 실제로 요즘은 기획 문서를 작성하거나 요구사항 정의서를 쓰는 데 가장 오래 걸린다. 잘만 입력하면 개발은 AI가 빠르게 처리해 주니까, 어떻게 AI가 잘 이해할 문서를 작성할지가 오히려 중요해졌다.
• 그렇다고 개발 공부를 안 해도 된다는 건 아니다. 앞서 말했듯이 판단에는 기획적인 것과 기술적인 것이 있다. "이 구조가 나중에 문제가 될지", "이 방식이 성능에 영향을 줄지" 같은 기술적 트레이드오프는 개발 지식이 없으면 판단 자체가 불가능하다.  물론 기술적 트레이드오프도 AI가 제안해 준다. "이 구조는 확장성이 좋지만 복잡도가 올라갑니다" 같은 분석을 꽤 잘한다. 근데 그게 우리 상황에 정말 맞는지, AI의 판단이 틀리진 않은지를 판별하려면 결국 개발을 알아야 한다. 기획만 잘한다고 좋은 결정이 나오는 건 아니다.

자동화 능력을 키우기 위해

• 새로운 도구가 나오면 일단 써본다. 완벽히 익히는 게 아니라, 뭘 할 수 있는지 감을 잡는 게 목적이다. 감이 있어야 "이건 이 도구로 하면 되겠다"는 판단이 나온다.
• 직접 써보고, 개선하고, 안 맞으면 버리고 다른 걸 시도한다. 이 사이클을 빠르게 돌리는 게 핵심이다. 새로운 걸 잘 받아들이는 유연함 자체가 경쟁력이 되는 시대다.
• 반복하는 작업이 보이면 바로 자동화한다. 작은 것부터. 스크립트 하나, 단축키 하나라도. 이게 쌓이면 같은 시간에 낼 수 있는 결과물이 완전히 달라진다.
• 사실 뭐든 일단 써본다. 새 도구가 성능이 더 좋을 수도 있고, 내가 원하는 방향으로 더 잘 이끌어줄 수도 있고, AI가 더 잘 이해하는 형태가 나올 수도 있다. 안 맞으면 버리면 그만이다. 써보지 않으면 그 판단조차 할 수 없다.

대단한 건 없다. 솔직히 새로운 도구라고 해봐야 결국 프롬프트를 어떻게 짜느냐, 맥락을 어떻게 잘 넣어주느냐의 차이다. 근데 지금 상황에선 이걸 하느냐 안 하느냐가 차이를 만든다고 본다. 물론 이것마저 필요 없어지는 AI가 오면 무용지물이지만, 그건 그때 가서 생각하면 된다.

 

정리하며

이 글을 쓰기 시작한 계기는 "Claude Code 잘 쓰는 법"이 궁금해서였다. 그런데 파고 들어가다 보니, 진짜 질문은 달랐다.

AI 시대에 개발자에게 필요한 건 두 가지다.

1. 얼마나 기획하고 판단하고 결정을 잘하느냐
2. 나머지를 얼마나 효율적으로 잘 자동화하느냐

"코딩만 하지 말고 비즈니스를 이해하라"는 조언은 오래전에도 있었다. 다른 건 속도일 것이다. 더불어 예전에는 기획력이 부족해도 코딩 실력으로 버틸 수 있었다. 이제는 코딩 자체가 대체되면서, 그 버팀목이 사라지고 있다. 같은 방향의 변화지만, 속도가 완전히 다르다.

지금은 개발 지식과 도메인 지식을 바탕으로 결정하는 능력과 효율적으로 실현하는 능력. 이 두 가지를 연습하는 것이 내가 할 수 있는 최선인 것 같다.

 

아마 앞으로는 Claude Code에 새로운 거 이것저것을 해보고 정리하는 글을 써보려 한다. (다른 AI일 수도 있지만 지금 당장은 클로드코드가 젤 좋은 것 같아서..)  물론 개발 공부도 쓸 예정이다.. 원래는 CS나 개발지식 같은 걸 정리하려 했지만 너무 도태되는 것 같아 병행해서 올리려 한다..! 커밍순..