개발은 반복적으로 새롭고 유용한 무언가를 창조하는 것입니다.
우리가 '개발'이라고 들었을 때 흔히 떠올리는 것은 신제품 개발입니다. 이는 개별 제품을 제조하는 것과는 다르며, 제품의 청사진이나 주형을 만드는 것을 의미합니다.
따라서 신제품 개발을 통해 만들어진 설계도나 주형은 공장에서 반복적으로 사용되어 동일한 제품이 대량 생산됩니다.
또한 개인의 능력 개발이나 사회 및 국가 개발과 같은 용례도 있습니다. 이는 단순히 소유하고 있는 것이 증가하는 것을 넘어, 개발된 능력을 반복적으로 사용하여 이점을 얻을 수 있다는 의미를 내포합니다.
개인과 사회의 경제력은 경기 상황에 따라 오르내릴 수 있지만, 기본적으로 개발된 능력은 영구적입니다.
설령 줄어든다 해도, 그것은 경제적 번영과 같은 오르내림이 아니라 쇠퇴로 간주됩니다.
나아가 기술 및 지식 개발도 있습니다. 이는 개인이나 특정 사회의 능력과 달리 쉽게 공유될 수 있다는 특징을 가집니다.
그리고 이러한 개발의 결과물인 제품, 능력, 지식, 기술 중 일부는 다음 개발에 유용하게 활용될 수 있습니다.
이러한 유용한 결과물을 개발함으로써 개발의 범위가 확장되고 효율성과 품질 또한 향상됩니다.
AI 주도 소프트웨어 개발
일반적으로 개발은 상당한 시간과 노력을 필요로 했습니다. 특히 사회가 발전하고 다양한 것들이 더욱 정교해짐에 따라 새로운 것을 창조하는 일은 점점 더 어려워졌습니다.
그러나 생성형 AI의 출현으로 이러한 상황이 변화하고 있습니다. 현재 소프트웨어 개발은 생성형 AI의 뛰어난 프로그래밍 능력 덕분에 극적인 변화를 겪고 있습니다.
생성형 AI를 기반으로 한 자율 에이전트가 소프트웨어 엔지니어로서 소프트웨어 개발의 중심이 되는 미래 비전은 이미 현실이 되고 있습니다.
우리는 현재 과도기에 있습니다. 개발을 완전히 생성형 AI에 맡길 수는 없지만, 생성형 AI를 능숙하게 활용하면 소프트웨어 개발을 강력하게 진척시킬 수 있습니다.
이를 AI 주도 소프트웨어 개발이라고 합니다.
개발형 개발
생성형 AI가 소프트웨어 개발을 간소화하면 최종 목표 소프트웨어 개발뿐만 아니라 개발 자체를 돕는 소프트웨어 개발도 효율적으로 만들 수 있습니다.
앞서 언급했듯이, 개발을 돕는 결과물은 개발 범위를 확장하고 효율성과 품질 향상에 기여합니다. 더욱이 효과적으로 생성되면 다른 개발 프로젝트에서도 재사용할 수 있습니다.
따라서 소프트웨어 개발 과정에서 유용한 소프트웨어를 개발함으로써 궁극적으로 전체 효율성을 높이고, 이 자산을 미래 개발에도 활용할 수 있습니다.
전통적으로 이러한 개발 보조 소프트웨어를 개발하는 것은 현장에서 흔한 일이었지만, 그 자체로 개발 시간과 노력이 필요하여 신중한 평가와 목표 설정이 요구되었습니다.
생성형 AI를 활용하면 작고 즉흥적인 작업을 자동화하는 간단한 소프트웨어를 빠르게 만들 수 있습니다. 처리 과정이 명확한 작업의 경우, 생성형 AI는 거의 오류 없이 정확한 프로그램을 생성할 수 있습니다.
이로 인해 소프트웨어 개발 중에 개발을 돕는 소프트웨어를 개발하는 것이 이전보다 훨씬 쉬워졌습니다.
그리고 더 깊이 생각해보면, 개발 과정에서 유용한 도구들이 지속적으로 개발되어 개발 방식 자체를 변화시키는 개발 스타일이 나타납니다.
이를 개발형 개발이라고 부르겠습니다.
개발형 개발을 실천하려면 자신이 진행하는 소프트웨어 개발을 객관적으로 관찰하여 어떤 부분을 소프트웨어에 위임할 수 있고 어떤 부분을 인간만이 할 수 있는지 고민하는 습관, 그리고 그러한 개발 보조 소프트웨어를 개발하는 기술이 필요합니다.
더 나아가, 이러한 소프트웨어 도구에도 생성형 AI를 통합할 수 있습니다. 소프트웨어 내부에 AI를 포함시킴으로써, 독립적인 생성형 AI 에이전트와 달리 처리 범위를 좁히고 명확한 경로를 어느 정도 정의할 수 있습니다.
AI 에이전트도 프롬프트를 통해 유사한 결과를 얻을 수 있지만, 생성형 AI를 통합한 소프트웨어는 프로그램과 프롬프트를 모두 결합하여 정확도를 더 쉽게 높일 수 있습니다.
개발형 개발을 실천할 수 있다면, 첫 번째 프로젝트보다 두 번째 프로젝트에서 품질과 비용 모두 개선될 것입니다. 나아가 세 번째, 네 번째 프로젝트 등 횟수를 거듭할수록 개선은 계속해서 축적될 것입니다.
이는 단순히 생성형 AI를 사용하여 소프트웨어를 개발하는 방식과는 완전히 다릅니다. 생성형 AI 도구를 단순히 숙달하는 팀과 개발형 개발을 실천하는 팀 사이에는 시간이 지남에 따라 상당한 격차가 발생할 것입니다.
리팩토링 주도 테스트
테스트 주도 개발(TDD)이라는 개념이 있습니다. 이는 먼저 사양에 기반하여 테스트를 설계하고, 그 테스트를 통과하도록 소프트웨어를 개발하는 방식입니다.
처음에는 생성형 AI가 자동 테스트를 위한 테스트 프로그램을 쉽게 개발할 수 있게 해주므로, 테스트 주도 개발이 실현 가능할 것이라고 저 또한 생각했습니다.
그러나 개발형 개발을 실천하면서 구현 전에 테스트를 설계하는 접근 방식이 항상 적합하지는 않다는 생각을 하게 되었습니다.
특히 웹 애플리케이션처럼 사용성이나 시각적 디자인과 같은 감성적인 측면이 포함되어 직접 조작하며 경험할 수 있는 소프트웨어의 경우, 상세한 테스트보다는 실제로 소프트웨어를 실행하고 만져보는 것이 더 우선순위가 높다는 것을 깨달았습니다.
이는 UI/UX 수준에서 상당한 불만족이 발생하면 프레임워크, 기본 아키텍처, 데이터 모델 또는 유스케이스와 같은 근본적인 부분을 변경해야 할 가능성이 있기 때문입니다.
현재 진행 중인 개인 소프트웨어 개발 프로젝트에서도 기능 유연성과 성능 문제를 발견하여 두 개의 프레임워크를 다른 것으로 교체한 적이 있습니다.
또한 메모리 사용 효율성이 낮은 부분이 있어 처리 방식을 전면적으로 재검토한 경우도 있습니다.
테스트는 바로 이러한 리팩토링 시점에서 처음으로 의식적인 고려 대상이 됩니다.
만약 개발 초기 단계이거나 기능 및 사양이 어차피 크게 변경될 예정이라면 테스트는 필요하지 않을 수도 있습니다.
하지만 개발이 상당히 진행되어 확인해야 할 항목이 많아진다면, 리팩토링 과정에서 기능적 결함이나 누락이 없는지 확인하기 위해 테스트가 필요할 것입니다.
그러므로 개발이 어느 정도 진행되어 리팩토링이 필요해지는 시점에 테스트 프로그램을 만드는 아이디어도 나쁘지 않습니다.
이때 중요한 것은 모든 코드에 대한 테스트를 만드는 것이 아니라, 앞으로 크게 변경될 가능성이 적은 안정된 부분에 테스트를 집중하고, 여전히 유동적인 부분은 자동 테스트 없이 남겨두는 것입니다.
이를 리팩토링 주도 테스트라고 부를 수 있습니다.
결론
생성형 AI는 소프트웨어 개발을 극적으로 변화시키고 있습니다.
이전 글에서 저는 전통적인 풀스택 엔지니어 역할을 넘어 다양한 도메인, 인프라, 실행 환경을 결합한 전방위 시스템을 개발할 수 있는 전방위 엔지니어가 되는 것이 중요하다고 언급했습니다.
또한, 저는 사양과 구현을 일치시키는 전통적인 소프트웨어 개발 방식이 아닌, 소프트웨어의 동작을 통해 사용자 경험을 향상시키는 경험 및 행동 중심 개발 시대가 도래할 것이라는 글도 작성했습니다.
개발형 개발과 리팩토링 주도 테스트는 바로 이러한 새로운 소프트웨어 개발의 지평으로 우리를 이끌어갈 접근 방식입니다.