서론
AI 모델은 이제 대부분의 코딩 작업을 맡기고 리뷰와 검수까지 시킬 수 있을 만큼 좋아졌다. 주변 개발자분들께 여쭤보면 코드를 입력하는 시간보다 프롬프트를 입력하는 시간이 더 많고, 자동화 스크립트 대신 에이전트에 쓸 스킬을 만들고 있다고 할 만큼 개발 업무의 형태가 많이 변했다.
AI가 코딩을 하고 리뷰까지 하는 방식으로 일하다 보니, 이전과 달라진 업무 흐름에 혼란스러워하는 사람도 많고 지금 하고 있는 일에 확신을 갖지 못하는 분들도 늘기 시작했다. 나 역시 과거와 많이 달라진 업무와 프로세스를 보며 이렇게 하는 게 맞는지 의문을 가지고, 때로는 비판적으로 바라보곤 한다.
이전의 개발자
과거의 개발은 전문가의 영역에 가까웠다. 의사나 파일럿 같은 전문직이라기보다는, 목수나 건축가처럼 고객이 원하는 요구사항에 맞춰 설계하고 제작하고 보수해 주는 직업에 가까웠다. 러닝커브만 넘으면 누구나 할 수 있었지만, 요구사항이 복잡하고 구현 난이도가 높을수록 더 깊은 지식을 요구했다.
그래서 기업은 이런 전문 인력을 대규모로 채용해 돈이 되는 제품이나 내부 시스템을 만들며 경쟁력을 쌓아갔다. 문제는 소프트웨어가 물리적으로 존재하지 않는다는 점이었다. 고려하고 신경 써야 할 일이 생각보다 많았고, 기업은 시스템을 유지하기 위해 정말 많은 돈을 써야 했다.
그러다 코로나 시기에 플랫폼 시장이 급성장하면서 정말 많은 개발자가 필요해졌고, 전공자·비전공자 가릴 것 없이 IT 인력을 채용하기 시작했다.
AI가 나온 이후의 개발 시장
AI가 나온 이후 가장 크게 변한 것은 IT 직업일 것이다. 처음에는 빠른 코드 자동 생성으로 개발자 한 명이 두 명의 생산성을 낼 수 있게 해줬다면, 이제는 코드를 직접 작성하는 것을 넘어 리뷰와 검수까지 해주면서 한 명이 팀 하나의 생산성을 내는 시대가 되었다.
그래서 기업은 높아진 생산성만큼 소수의 엔지니어로 이루어진 조직을 선호하기 시작했다. 개발자를 늘린다고 해서 그만큼 늘어나는 산출물과 리스크를 기업이 다 감당할 수 있는 것도 아니었고, 인원이 늘어나는 만큼 소통 비용과 매니징 비용이 든다는 것도 이미 겪어봤기 때문에, 필요한 인력만 남기기 시작한 것이다.
소수의 엔지니어는 무슨 일을 할까?
남은 소수의 엔지니어에게는 높아진 생산성만큼 높은 기대치가 걸렸다. 한 명이 풀스택으로 개발하거나, 비즈니스를 설계하고 전략을 세우는 엔지니어가 되거나, 더 넓은 범위의 시스템과 인프라를 전문적으로 관리하는 엔지니어가 되는 등 기업마다 변화의 모습은 제각각이었다.
여기서 의문이 하나 생겼다. 생산성이 높아진 만큼 우리가 만들어야 하는 소프트웨어의 절대량도 줄어든 걸까? 찾아보니 그건 아니었다. 기술이 발전한 만큼 만들어야 하는 소프트웨어의 수준 자체가 높아졌고, 대규모 시스템이나 코어 시스템은 기술 발전 속도만큼 빠르게 바뀔 수 없다. 만들어야 하는 소프트웨어의 범위는 줄기는커녕 오히려 더 넓어졌다고 봐야 할 것이다.
코드를 몰라도 코딩할 수 있는 세상
AI가 나오기 전, 스타트업에서 파이썬 자동화 세미나를 한 번 연 적이 있다. 관심을 끌려고 실습 위주로 세션을 준비했는데, 참석자들은 간단한 print 문이나 셀레니움 라이브러리 호출조차 많이 어려워했다. 그때는 '이 정도는 정말 날로 먹는 건데 왜 이렇게 어렵게 생각하지?'라고 생각했다. 지금 돌아보면 기존에 하던 일과 완전히 다른 생소한 형태의 업무였다는 점, 그리고 인터페이스 기반으로 일하던 사람에게 빈 창에 문자만 입력하고 문자만 보이는 CLI와 IDE 환경 자체가 큰 장벽이었을 것이다.
아무튼 예전에는 이런 간단한 프로그램조차 만들기 어려워서 비용을 내고 전문가에게 맡겼지만, 지금은 완전히 달라졌다. 각자 필요한 프로그램과 플랫폼을 직접 만들기 시작했고, 개발자의 관여 없이도 필요한 것을 만들 수 있게 되었다. 아이디어와 창의력만 있으면 돈을 벌거나 자기 잡무를 자동화할 수 있게 되면서 개발자의 입지는 점점 줄어들었다.
개발 비용을 줄이려는 시도는 하루이틀 일이 아니다
이런 시도가 과거에 없었던 것은 아니다. SaaS를 만들거나 카페24, 네이버 스토어처럼 완전형 서비스를 만들어 소비자가 개발 없이 인터페이스만으로 서비스를 운영하게 해주는 플랫폼이 있었고, 노코드·로우코드처럼 코드 없이 혹은 최소한의 코드로 원하는 소프트웨어를 만드는 시장도 AI 이전부터 존재했다.
하지만 이런 플랫폼과 툴로 각기 다른 환경과 요구사항을 전부 구현하기는 쉽지 않았다. 그래서 많은 기업이 규모가 커지면 결국 내재화를 하거나 전문 인력, 전문 업체를 통해 필요한 소프트웨어를 개발했다. AI가 나온 이후에는 그 전문 인력이 사람에서 AI로 바뀐 것이다. 클라이언트의 요구사항에 맞춰 더 저렴하고 빠르게 구현할 수 있으니, AI로 개발하기 시작한 것이다.
개발자도 코딩을 안 하는 세상
그렇다면 개발자는 직접 코딩을 할까? 물론 직접 하는 개발자도 있지만, 직접 코딩하지 않는 개발자가 정말 많이 늘었다. AI가 코딩을 더 잘 짜서 그런 걸까? 그건 아닐 것이다. AI를 쓰는 개발자들이 공통으로 이야기하는 게 버그가 늘었다는 것이고, 중복 코드가 많아지고 일관된 형태로 개발되지 않아 품질이 낮아졌다는 것이다. 그러니 사람이 직접 짜는 것보다는 못하다고 볼 수 있다.
그런데 왜 개발자는 AI에게 코딩을 맡길까? 답은 생산량에 있는 것 같다. 프랜차이즈와 파인다이닝의 차이를 떠올리면 이해가 쉽다. 파인다이닝은 요리 하나에 정말 많은 사람의 손이 들어간다. 매일 신선한 재료를 매입하고, 재료 손실을 줄이고 맛을 높이기 위해 기계보다 사람을 많이 쓴다. 프랜차이즈는 다르다. 대량으로 매입한 뒤 공장에서 대량 가공한 조미료를 쓴다. 그래서 프랜차이즈가 파인다이닝보다 저렴한 가격에 음식을 내놓을 수 있는 것이다.
코드도 마찬가지다. 모든 소프트웨어가 품질에 비례해 가치를 만드는 것은 아니다. 완벽한 제품보다는 조금 흠이 있어도 유용한 제품이, 그리고 다른 제품보다 더 많이 더 빠르게 발전하는 제품이 필요하다. 그래서 테스트 코드와 품질 좋은 코드에 시간을 쏟기보다, 부족하더라도 고객이 원하는 것을 더 빠르게 만들기 위해 AI를 쓰는 것이다.
그렇다면 기술은 의미가 있는 걸까?
많은 엔지니어가 이제는 문제 정의가 더 중요해질 거라고 말한다. 문제 정의란 정확히 무엇일까? 각자 해석하기 나름이겠지만, 나에게 문제 정의란 맞는 해결 방안을 찾는 것이다. 뭐 당연한 소리 아닌가 싶겠지만, 맞는 해결 방안을 찾는 일이 정말 어렵다는 건 여러분도 알 것이다.
현재 상황이 어떤지 알아야 하고, 투입할 수 있는 리소스와 시간, 리스크까지 고려해야 할 게 한두 가지가 아니다. 선택한 해결 방안이 정답이 아닐 수도 있으니 매몰비용도 생각해야 한다. 이 많은 요소를 놓고 맞는 해결 방안을 찾는 건 정말 쉽지 않은 일이고, 그래서 문제 정의가 잘 되어야 한다는 것이다. 그렇다면 나는 왜 여기서 문제 정의를 계속 이야기할까? 기술의 본질이 문제를 해결하기 위해 나온 개념이기 때문이다. 데이터베이스는 흩어져 관리되던 파일 시스템을 효율적으로 다루기 위해 나왔고, 우리가 자주 쓰는 컨테이너는 OS나 버전 같은 환경으로부터 독립적으로 관리하기 위해 나왔다.
기술을 모른 채 사용할 때의 비용
이건 내 경험이기도 하다. 우리는 MQTT 프로토콜을 쓰면서도 지금 쓰는 방식에 어떤 문제가 있는지, 무엇을 개선할 수 있는지 알지 못했다. 몰랐으니 고쳐야 한다는 생각조차 못 하고 있었다. 그러다 이번에 MQTT를 제대로 파악하고 정리하면서 QoS 0을 1로 전환해 최소 1회 전달을 보장하게 만들었고, AWS IoT Core의 디바이스 섀도우까지 활용하면서 기술이 가진 이점을 온전히 쓸 수 있게 되었다.
반대로 기술을 알고 고르면 우리에게 맞는 선택을 할 수 있다. 회사의 비즈니스 지표를 모니터링할 도구를 리서치하면서, 도입 비용이 낮고 키바나처럼 ES 인덱스 개념을 알 필요 없이 간편하게 쿼리를 만들 수 있는 메타베이스를 도입했다. 물론 다른 BI 도구에 비해 심층 분석은 어렵다. 하지만 우리 조직과 데이터 리터러시 역량을 고려하면 적절한 선택이었다고 생각한다.
기술을 잘 안다는 것은 필요한 해결책이 무엇인지 잘 안다는 것이다
AI 모델이 아무리 좋아져도 회사의 모든 컨텍스트를 다 담을 수는 없을 것이다. 모든 미팅록과 메신저, 팀원 개개인의 생각과 성향까지 고려할 수 없고, 회사 내에서 접근할 수 있는 정보도 제한적이기 때문에 완벽한 해결책을 내줄 수는 없다.
물론 아이디어나 리서치는 해줄 수 있다. 하지만 그 해결책이 지금 우리 상황에 맞는지, 틀린 방향은 아닌지는 결국 사람이 판단하고 결정해야 한다. 기술의 장단점이 무엇인지, 지금 해결책이 오버엔지니어링은 아닌지, 무엇을 트레이드오프해야 하는지 알려면 결국 기술을 공부해야 하고, 그 기술의 이점이 지금 우리 조직과 회사에 맞는지 되물어야 한다.
과거에는 이런 기술과 방법론의 학습 비용과 실행 비용이 컸기 때문에 미리 공부하고 준비해야 했다. 지금은 필요한 정보를 빠르게 찾을 수 있고 실행 비용도 많이 낮아져서, 미리 준비하지 않아도 도입할 수 있게 되었다. 그렇다면 이제 키워야 할 역량은 바로 이것, 우리에게 맞는 해결책을 알아보는 눈이 아닐까라는 생각이 든다