[바미] AI가 일하는 시대, 나는 어떤 개발자가 되어야 할까

들어가기 전에

지난 6월, 하용호 님의 AI시대 나의 전문성을 재설계하는 법 강연을 들었다.

강연을 본 직후부터 내용을 정리해두고 싶었지만, 업무와 여러 일정이 겹치면서 한 달 넘게 미루다가 이제야 글로 남기게 됐다.

 

시간이 조금 지난 뒤 다시 발표 자료를 살펴보니 당시에는 흥미롭게만 들었던 이야기들이 실제 업무를 하면서 더 구체적으로 와닿았다. 특히 AI가 만들어주는 결과물의 양이 점점 늘어나면서 단순히 AI를 잘 사용하는 것보다 그 결과를 이해하고 검증하며 책임지는 능력이 중요하다는 생각을 자주 하게 됐다.

 

그래서 이번 글에서는 강연의 모든 내용을 그대로 요약하기보다 개발자로 일하는 내 입장에서 특히 인상 깊었던 부분과 앞으로 어떤 개발자가 되어야 할지에 대해 고민한 내용을 정리해보려고 한다.

AI를 많이 사용한다고 반드시 일을 잘하는 것은 아니다

강연에서 가장 현실적으로 느껴졌던 부분은 기업의 AI 전환이 처음부터 순조롭게 진행되지는 않는다는 이야기였다.

처음에는 AI 제품을 도입하고, 교육을 진행하고, 구성원들에게 적극적으로 사용하라고 독려한다.

이후 사내 시스템과 AI를 연결하면 사용량과 산출물이 빠르게 증가한다. 하지만 어느 순간부터 생산량은 늘었는데 회사 전체의 성과가 기대만큼 좋아지지 않는 시기가 찾아온다.

 

강연에서는 AI를 도입한 뒤 곧바로 성과가 상승하는 것이 아니라 학습 비용과 검증 비용을 지불하고 기존 업무 흐름을 다시 설계하는 과정을 거쳐야 한다고 설명한다. 이를 AI J-Curve Trap이라고 표현한다.

 

이 부분을 들으면서 개인에게도 똑같이 적용되는 이야기라고 느꼈다. AI가 코드를 빠르게 만들어준다는 이유로 생산량만 늘리다 보면 정작 내가 그 코드를 제대로 이해하지 못하는 상황이 생길 수 있다. 처음에는 일을 빨리 처리했다고 생각하지만 나중에 장애가 발생하거나 요구사항이 변경되면 코드를 다시 파악하는 데 더 많은 시간이 필요해진다.

 

결국 AI를 사용해 당장의 작업 시간을 줄였지만 그만큼의 비용을 나중에 다른 형태로 지불하게 되는 것이다.

가장 인상 깊었던 AI 시대의 세 가지 부채 개념

이번 강연에서 가장 기억에 남은 내용은 기술부채, 인지부채, 의도부채였다.

 

기술부채는 개발자에게 익숙한 개념이다. 당장의 일정과 기능 구현을 우선하면서 좋지 않은 구조가 누적되고, 시간이 지날수록 유지보수 속도가 느려지는 문제다. AI 시대에는 여기에 인지부채와 의도부채가 더해진다.

 

인지부채는 AI가 만든 코드와 문서를 사람이 충분히 이해하지 못한 상태로 사용하고 배포하면서 쌓인다. 과거에는 직접 코드를 작성하는 과정에서 자연스럽게 구조와 맥락을 이해했다. 하지만 AI가 결과물을 한 번에 만들어주면, 코드를 이해하는 일이 자동으로 따라오지 않는다. 이제는 결과물을 파악하기 위한 시간을 의도적으로 확보해야 한다.

 

의도부채는 한 단계 더 위험하다. 코드는 정상적으로 동작하지만 왜 그런 구조와 숫자, 조건을 사용했는지 아무도 알지 못하는 상태다. 특정 제한 시간이 왜 5초인지, 특정 고객사의 데이터만 왜 다르게 처리하는지, 당시 어떤 제약과 논의를 거쳐 결정했는지가 사라지는 것이다.

 

개발 업무를 하면서도 이런 상황은 자주 발생한다.

 

몇 달 전에 작성된 조건문을 보며 '왜 이 경우만 예외 처리했지?'라고 생각하거나 정상적으로 운영되는 기능이라 함부로 수정하지 못했던 경험이 있다. 기존에는 이런 문제가 주로 문서 부족이나 담당자의 퇴사 때문에 발생했다면 AI 시대에는 결과물이 만들어지는 속도가 빨라진 만큼 이러한 부채도 더욱 빠르게 쌓일 수 있다.

 

특히 AI와 대화하며 고민했던 내용은 채팅 세션 안에만 남고, 실제 코드에는 최종 결과만 반영되는 경우가 많다. 왜 이 방법을 선택했는지, 어떤 대안을 검토했고 무엇을 포기했는지는 쉽게 사라진다. 그래서 앞으로는 코드를 남기는 것만큼이나 판단의 이유를 남기는 일이 중요해질 것 같다.

개발자의 역할은 생산에서 검증으로 이동한다

강연의 핵심 메시지 중 하나는 사람의 주요 업무가 생산에서 검증으로 이동한다는 것이었다.

 

과거에는 사람이 직접 결과물을 만들고 검증했다면 앞으로는 생산의 많은 부분을 AI가 담당하고 사람은 결과물이 올바른지를 판단하는 데 더 많은 시간을 사용하게 된다. 발표에서는 기존의 ‘생산+검증’ 구조에서 생산은 AI가 하고 사람은 검증을 담당하는 구조로 역할이 바뀐다고 설명한다.

 

처음에는 이 표현이 조금 과장됐다고 생각했다. 개발자라면 여전히 직접 코드를 작성하는 능력이 중요하지 않을까 싶었다.

하지만 생각해보면 이미 업무 방식이 조금씩 그렇게 바뀌고 있다.

 

예전에는 코드의 대부분을 직접 작성했다면 지금은 AI가 만든 초안을 검토하고 수정하는 시간이 늘었다. 어떤 테이블 구조가 적절한지, 예외 상황이 빠져 있지는 않은지, 기존 시스템과 충돌하지 않는지, 운영 환경에서 문제가 생기지는 않을지를 판단하는 일이 더 중요해지고 있다.

 

AI가 코드를 작성하는 속도는 사람이 따라가기 어렵다. 그렇다면 사람의 경쟁력은 더 빠르게 타이핑하는 능력이 아니라, 어떤 결과가 올바른 결과인지 정의하는 능력에서 나올 수밖에 없다.

모든 코드를 읽는 대신 검증 구조를 만들어야 한다

AI가 만든 모든 결과물을 사람이 처음부터 끝까지 세밀하게 검토하는 것은 현실적으로 불가능하다.

결과물이 많아질수록 리뷰하는 사람은 지치고, 결국 중요한 부분만 대충 확인하거나 AI의 결론을 그대로 받아들이게 된다. 강연에서는 이러한 상태를 인지적 항복이라고 표현한다.

 

이를 해결하기 위한 방법이 검증 레이어다.

모든 구현 과정을 사람이 직접 확인하는 대신 결과물이 반드시 통과해야 하는 기준을 만드는 것이다. 기능이 정상적으로 작동하는지 확인하는 테스트, 처리 속도나 응답 시간을 측정하는 수치, 유지보수성과 사용자 경험을 평가하는 정성적 기준 등이 검증 레이어가 될 수 있다.

 

개발자에게는 테스트 코드와 모니터링, 로그, 정적 분석, 성능 기준 등이 이에 해당할 것이다.

AI가 어떤 방식으로 코드를 만들었는지 모든 줄을 완벽하게 파악하지 못하더라도 핵심 비즈니스 규칙과 예외 상황을 검증하는 테스트를 충분히 통과하고 운영 지표에 이상이 없다면 결과를 신뢰할 수 있다.

 

이 이야기를 들으며 좋은 개발자는 앞으로 코드를 많이 작성하는 사람이 아니라 AI가 잘못된 결과를 내놓지 못하도록 안전장치를 설계하는 사람에 가까워질 수 있겠다는 생각이 들었다.

전문성은 사라지는 것이 아니라 위치가 바뀐다

AI가 많은 업무를 수행할 수 있게 되면서 전문성의 가치가 낮아질 것이라는 이야기도 많다. 하지만 강연의 결론은 오히려 반대였다.

 

AI가 만들어낸 결과가 틀렸는지 판단하려면 해당 분야를 알아야 한다. 자신의 전문 분야에서는 이상한 점을 금방 알아차리지만

잘 모르는 분야에서는 AI의 답변이 그럴듯하다는 이유만으로 쉽게 믿게 된다. 강연에서는 ‘그럴듯한 가짜’를 걸러내고 진짜 결과를 확신하기 위해 전문성이 필요하다고 설명한다.

 

또한 쉬운 결정은 AI가 처리할 수 있지만 가치가 충돌하는 어려운 결정은 결국 사람에게 남는다.

속도와 안정성 중 무엇을 우선할지, 비용을 줄이면서 어디까지 품질을 보장할지, 일정 안에 어떤 기능을 포기할지와 같은 문제에는 하나의 정답이 없다.

 

해당 도메인을 이해하고, 실패했을 때의 영향을 예측하고, 결과에 책임질 수 있는 사람이 결정해야 한다.

결국 전문성은 단순히 특정 기술을 능숙하게 다루는 능력에서 끝나지 않는다.

 

앞으로의 전문가는 자신이 맡은 분야에서 문제를 정의하고, AI가 올바르게 일할 수 있도록 검증 기준을 만들고, 결과를 운영하며, 중요한 결정에 책임지는 사람이 될 것이다. 강연에서는 이를 ‘스킬의 숙련자에서 운영의 책임자로’의 변화라고 정리한다.

무엇을 만들지보다 무엇을 만들지 않을지가 중요하다

AI를 활용하면 기능을 만드는 비용이 크게 낮아진다. 이전에는 일정이나 개발 비용 때문에 포기했던 아이디어도 비교적 쉽게 구현할 수 있다.

 

하지만 만들기 쉬워졌다고 해서 모든 것을 만들어서는 안 된다. 기능이 계속 늘어나면 관리할 대상도 함께 늘어난다. 아무도 사용하지 않는 기능이 쌓이고, 제품의 방향이 흐려지며, 결국 기술부채가 된다. 이 때 필요한 능력이 강연에서 이야기한 취향이다.

 

여기서 말하는 취향은 단순한 미적 감각이 아니다. 무엇을 만들 것인지뿐 아니라 무엇을 만들지 않을 것인지 결정하는 기준이다.

더하는 비용이 낮아질수록 오히려 빼는 결정이 더 중요해진다. 개발자로 일하다 보면 요청받은 기능을 구현하는 데 집중하기 쉽다. 하지만 AI 시대에는 구현 가능 여부보다 '이 기능이 정말 필요한가?', '서비스의 핵심 경험과 연결되는가?', '운영 비용까지 감수할 가치가 있는가?'를 더 먼저 고민해야 할 것 같다.

 

AI가 무엇이든 만들어줄 수 있는 시대에는 잘 만드는 능력보다 만들 가치가 있는 것을 고르는 능력이 더 희소해질 수 있다.

강연을 보고 바꾸고 싶은 업무 방식

이번 강연을 보고 AI를 사용하는 방식도 조금 바꿔야겠다고 생각했다. 먼저 AI가 만들어준 코드가 정상적으로 동작한다는 이유만으로 바로 받아들이지 않으려 한다. 기존 구조와 비즈니스 규칙을 제대로 반영했는지 확인하고 중요한 로직에는 반드시 테스트와 검증 기준을 함께 만들어야 한다.

 

두 번째로 결과뿐 아니라 판단의 이유를 남겨야 한다. PR이나 이슈에 무엇을 변경했는지만 기록하는 것이 아니라, 왜 이 방식을 선택했고 어떤 대안을 검토하고 포기했는지를 함께 남겨야 한다. 그래야 시간이 지나도 의도부채가 쌓이는 것을 줄일 수 있다.

 

세 번째로 AI에게 곧바로 답을 요구하기보다 필요한 경우 AI가 나에게 질문하도록 만들고 싶다. 요구사항에서 빠진 내용과 애매한 조건을 먼저 질문하게 하면 내가 알고 있지만 설명하지 않았던 암묵지를 더 많이 드러낼 수 있다.

 

마지막으로 나만의 판단 기준과 경험을 축적할 공간이 필요하다는 생각이 들었다. AI를 매번 새로운 도구처럼 사용하는 것이 아니라, 과거의 결정과 선호, 업무 방식을 기억하는 파트너로 만들어야 한다.

마치며

이번 강연을 통해 AI 시대의 전문성은 사라지는 것이 아니라 형태가 바뀌고 있다는 점을 가장 크게 느꼈다.

예전의 전문성이 직접 결과물을 얼마나 잘 만들어내는가에 가까웠다면, 앞으로의 전문성은 문제를 정확히 정의하고, AI가 만든 결과를 검증하고, 중요한 선택을 내리고, 그 결과에 책임지는 능력에 가까워질 것이다.

 

AI가 코드를 대신 작성한다고 해서 개발자의 역할이 없어지는 것은 아니다. 오히려 어떤 코드가 필요한지, 무엇이 잘못됐는지, 어떤 구조가 장기적으로 안전한지 판단할 수 있는 개발자의 역할은 더 중요해질 수 있다.

결국 앞으로 내가 고민해야 할 질문은 'AI보다 코드를 잘 작성할 수 있을까?'가 아니다.

AI가 만들어낸 수많은 결과 중에서 무엇이 옳은지 판단하고, 그 결과를 믿을 수 있게 만들며, 끝까지 책임질 수 있는 개발자가 될 수 있을까?

 

이번 강연은 그 질문을 진지하게 생각하게 만든 시간이었다.