개발 도구의 진화가 개발자를 편하게 만들었을까?

개발도구의 진화와 생산성 향상

“ChatGPT로 개발하면 다 만들어 준다던데, 그럼 개발업무는 많이 편해지셨겠네요?”

요즘 개발자들이 가장 많이 듣는 말 중 하나다. AI혁명이 세상을 뒤덮었고 사회 모든면에서 영향을 미치고 있는데, 특히나 개발영역은 이미 점령을 당한 것 마냥 AI가 모든 개발을 대신하는 것처럼 이야기하는 사람들을 만나면 씁쓸한 웃음이 난다. 마치 손글씨로 문서를 작성하던 세상의 사무직 근로자보다 사무자동화가 당연해진 요즘 근로자들의 업무시간이 줄기는커녕 일부는 더 늘어난 것과 비교할 수 있다. 일부 개발자들의 퇴근 시간은 오히려 더 늦어졌다. ChatGPT 같은 도구들이 단순 반복적인 코딩을 도와주는 건 사실이지만, 주변에서 그만큼 더 높은 수준의 결과물을 기대받게 되었기 때문이다.

이는 비단 AI 시대에만 있는 일은 아니다. 개발 도구들은 끊임없이 진화해왔고, 그때마다 “이제 개발이 쉬워지겠네”라는 이야기가 있었다. 하지만 현실은 달랐다. 도구가 발전할수록 개발자에게 요구되는 판단과 책임의 수준은 더욱 높아졌다.

도구의 발전.

개발자들끼리 처음 만나면 보통 주고받는 뻔한 대화들이 있다. 무슨개발하세요? 다음엔 언어 뭐 쓰세요? 다음엔 IDE는 뭐 쓰세요? 정도로 이어진다. 이때 IDE는 Integrated Development Environment의 약자로 통합 개발 환경 정도로 번역할 수 있다. 인테리어 기술자들끼리의 대화에서 “전동드라이버 어느브랜드 쓰세요?” 정도의 느낌이라고 이해하면 좋다. 프로그래머들은 이 IDE로 밥벌이를 하는 사람이다.

도구는 계속 발전해왔다.  1960년대 아폴로 11호에 들어가는 프로그래밍을 했던 ‘마가렛 헤밀턴‘은 자신의 키보다도 높이 쌓여있는 천공카드 코드 사진으로 유명하다. 0과 1로 컴퓨터와 직접 대화하던 시절에는 사람이 직접 모든것을 계산했고 도구의 도움은 기대하기 어려웠다. PC의 보급을 기폭제로 IDE는 상상할수 없을만큼 많이 발전했고, 구현하려는 것에 대한 스케치만 있다면 디테일한 것들은 전부 기억하고 있지 않아도 IDE의 도움을 받아 만들어 낼 수 있게 되었다.

만들어낸 코드를 배포하는 과정도 크게 달라졌다. 과거에는 개발자가 직접 서버에 접속해서 파일을 하나하나 옮기고, 서비스를 재시작하는 등의 수작업이 필요했다. 실수로 잘못된 파일을 옮기거나 순서를 잘못 지키면 서비스가 중단되는 일도 빈번했다. 하지만 지금은 ‘CI/CD’라 불리는 자동화된 배포 도구들이 이 과정을 안전하게 처리해준다. 개발자가 코드를 작성하고 확인 버튼 하나만 누르면, 테스트부터 배포까지 모든 과정이 자동으로 진행된다.

코드를 저장하는 버전 관리 도구도 획기적으로 발전했다. 예전에는 USB나 이메일로 코드를 주고받으며, 누가 어떤 부분을 수정했는지 일일이 확인해야 했다. 지금은 Git이라는 도구 덕분에 수백 명의 개발자가 동시에 작업해도 충돌 없이 코드를 관리할 수 있게 되었다. 실수로 잘못 수정한 부분도 언제든 이전 버전으로 되돌릴 수 있다.

이처럼 개발 도구들은 놀라운 속도로 발전했고, 개발자들의 실수를 줄이고 생산성을 높이는 데 크게 기여했다. 하지만 이런 도구의 발전이 과연 개발자의 업무를 진정으로 줄여주었을까?

변하지 않는 것들

일하는 환경이 많이 바뀌었으나 여전히 개발자의 역할이며, 앞으로도 개발자가 할 것으로 보이는 분야들이 있다. 비즈니스 로직 설계가 그 중 하나다. 이 영역은 업무의 본질적인 판단에 대한 것이다. 간단하게 쇼핑몰 개발에서 첫 구매 고객에게 10% 할인쿠폰을 만들어달라는 요청을 받았다고 생각해보자. 첫 구매 고객의 정의를 내릴 때 결제이력이 있으나 취소한 경우, 반품한 경우 등 어디까지 첫 구매고객으로 처리할지에 대한 판단 영역이 있다. 10%할인부분 역시나 전체 상품금액의 10%인지, 배송비도 포함해서 할인인지, 최대 할인금액 상한을 정할것인지 등등 결정해야 할 것들이 많다. 서비스 기획단계에서 모두 정해올 수도 있지만 항상 그보다 정할것들이 더 많다. IDE나 AI도구들을 활용한다고 해도 이 부분까지 해결하는건 어렵다.

개발자의 일을 코드 작성과 그 코드의 에러를 찾는 일(‘디버깅‘)로 구분했을때 사람마다 다르겠지만 3:7 정도로 문제점을 찾아내는데 시간을 많이 사용하곤 한다. 이 역시나 일부 도구의 도움을 받을 수 있지만 온전히 개발자가 감내할 영역이다. 단순 오타를 잡아주는일은 도움받기 좋지만 인간의 의도까지 바로잡아 주지는 못한다. 위 쇼핑몰의 예시에서 VIP회원은 할인율로 20%로 강제로 세팅하는 부분이 어딘가에 있다고 했을때 도구는 어떤것이 의도된 바인지 알 수 없으니 도움받기도 어렵다.

동료들과 ChatGPT로 시작된 AI홍수를 바라보며 어떤 일들이 살아남을지에 대해 이야기나눈적이 있는데, 필자는 결국은 특정 사업에 대해 책임질수 있는 규모의 업체와 업무분야들이 살아남을것이라고 생각했고 많은 친구들이 동의했던 기억이 있다. 개발 영역에서 어떤 편리한 툴의 도움을 받더라도 최종 책임을 지는건 현업 개발자의 영역이다. 회사 서비스에 장애가 났는데 AI틀때문에 문제가 생겼다고 할 수는 없지 않은가. 코드의 전체 품질과 안정성을 판단하는 일은 앞으로도 개발자의 영역으로 남을것이라고 생각한다.

이 뿐만 아니라 많은 보수적인 업계에서는 이런 도구의 도움을 받는것을 보안 정책으로 막아두기도 한다. 코드가 회사 밖으로 노출되니 보안측면에서 문제가 발생할 여지가 있기 때문이다. 이런 환경에선 AI 혁명은 남의나라 이야기일 뿐이다.

오히려 늘어난 것들

사람들이 뉴스를 보고 개발업무의 변화를 알게 되면서 늘어난 기대들이 있다. 기술이 발전하면서 도구들이 편리해졌지만, 그에 따라 개발자에게 요구되는 품질과 성능 기준은 더욱 높아졌다. 예전에는 단순히 기능이 작동하는 것만으로도 충분했다. 하지만 이제는 사용자 경험(UX)이 어떤지, 성능은 최적화가 잘 되었는지, 보안상 문제는 없는지 등 고려해야 할 요소들이 훨씬 많아졌다.

고객의 요구사항도 더욱 다양해지고 복잡해졌다. 개발자는 이제 단순한 코딩을 넘어 비즈니스 로직을 깊이 이해하고, 고객의 니즈를 정확히 파악해 적절한 솔루션을 제시해야 한다. 이는 개발자가 단순한 기술자가 아닌, 비즈니스 파트너로서의 역할까지 수행해야 함을 의미한다.

결국, 도구의 발전이 개발자의 업무를 줄여주기는커녕, 오히려 더 많은 책임과 판단을 요구하게 되었다. 이러한 변화는 개발자들이 지속적으로 학습하고 성장해야 하는 이유이기도 하다. 도구는 개발자의 업무를 보조하는 역할을 할 뿐, 최종적인 판단과 책임은 여전히 개발자의 몫으로 남아있다. 이는 앞으로도 변하지 않을 개발자의 본질적인 역할일 것이다.