닌텐도 카트리지를 구입한 후 소프트웨어를 업데이트하지 않던 시대는 이미 오래 전에 지나갔습니다. 세상은 변했고 소프트웨어도 변했습니다.
소프트웨어는 그 자체의 작은 (멋진) 회색과 검은색 상자 안에 사는 것이 아니라 서로 연결된 기계에 살고 있습니다. 소프트웨어는 변화에 반응하고 적응해야 하며, 그 이유는 다양합니다. 새로운 공격에 대비한 보안 업데이트든, 변화하는 에코시스템에 발맞추기 위한 기능 업데이트든 간에 말이죠. 소프트웨어는 업데이트되어야 하고 유지 관리되어야 합니다. 코드를 다시 작성하고, 종속성을 업데이트하고, 애플리케이션을 다시 배포해야 합니다.
이것은 무료가 아닙니다. 계속 가치를 제공하기 위해 배포를 유지하려면 지속적인 비용이 발생합니다. 그리고 유지 관리해야 하는 코드가 많을수록 비용도 증가하기 때문에 코드가 삭제되는 경우가 많습니다. 이제 질문은 가치를 제공하던 코드를 왜 삭제할까요? 코드의 가치는 어디에 있을까요?
코드와 개발 생태계의 진화
코드의 가치를 이해하려면 추상화에 대해 이야기해야 합니다. 대부분의 개발자는 0과 1, 심지어 0에서 f까지(일부는 여전히). 대신 프로그래밍 언어는 개발자가 0과 1 대신 실제 단어를 사용할 수 있도록 진화했습니다. 하드웨어는 개발자가 작성해야 했던 것을 실리콘으로 추상화하도록 진화했습니다. 프로그래밍 언어는 시간이 지남에 따라 다음과 같이 계속 발전해 왔습니다. 더 높은 수준의 추상화 개발자의 삶을 더 쉽게 만들기 위해 노력했습니다. 저수준의 기계어(1세대 언어 또는 1GL)에서 어셈블리(2세대 또는 2GL)로, C나 Java와 같은 보다 추상화된 고수준 언어(3GL)에서 R, SQL 또는 PL/SQL과 같은 도메인별 언어(4GL)로, Lisp, OPS5 또는 Mercury 같은 제약 조건/논리 기반 언어(5GL)로 나아갔습니다. 요점은 각 세대가 개발자의 복잡성을 더 많이 추상화한다는 것입니다. 5GL은 AI에 의존하여 명시된 문제와 조건에 따라 솔버를 생성합니다.
개발 에코시스템은 프로그래밍 언어와 함께 발전해 왔습니다. 개발자는 새 프로젝트를 시작할 때 처음부터 시작하지 않습니다. 개발자는 라이브러리, 종속성, 데이터베이스, 데이터 플랫폼, 노코드/로우코드를 사용합니다. 기존 소프트웨어를 사용하고 상호 작용합니다. 코드를 추상화할 수 있는 모든 것, 결국에는 더 적은 코딩으로 동일한 수준의 기능을 계속 제공한다는 의미입니다.
총소유비용(TCO) 절감 및 유지보수 개선
처음부터 다시 시작하면 비용이 엄청나게 많이 듭니다. 저는 항상 이 점을 기억합니다. 토스터 이야기. 토마스 트와이트는 기존의 추상적인 방식 없이 처음부터 토스터를 만들기로 결심했습니다. 그는 광석 채굴부터 제련, 토스터기 제작에 필요한 모든 것을 직접 만들었습니다. 결국 토스터는 작동하지 않았고 터무니없이 많은 시간과 비용이 들었습니다. 토스터기를 만드는 데는 한 문명 전체가 필요합니다. 소프트웨어도 마찬가지입니다(아직은 그 단계에 이르지 못했지만). 가치를 제공하려면 추상화를 사용해야 합니다. 작성된 코드가 적다는 것은 유지 관리할 코드가 적다는 것을 의미하며, 유지 관리에 소요되는 비용이 줄어들어 총소유비용이 낮아집니다.
개발자의 업무는 '레거시' 코드를 작성하는 것입니다. 아직 어딘가에서 실행 중인 레거시 코드가 있다면 축하드리며, 여러분은 가치를 제공하고 있고 앞으로도 계속 제공할 것입니다. 이를 위한 가장 좋은 방법 중 하나는 도구와 종속성 또는 추상화로 구성된 에코시스템을 현명하게 선택하는 것입니다. 여러 종류의 워크로드를 지원하고 새로운 워크로드를 계속 제안하는 최신 클라우드 데이터 플랫폼을 사용하는 것이 좋습니다. 그 과정에서 데이터베이스를 변경하는 것은 비용이 많이 들기 때문입니다. 단순히 데이터를 옮기는 것이 아니라 코드를 다시 작성하고 새로운 것을 유지 관리해야 하기 때문입니다. 그리고 코드를 더 많이 작성할수록 유지 관리 비용이 높아진다는 것은 이제 누구나 알고 있는 사실입니다.
소프트웨어 개발에 대한 AI의 영향
이것이 AI와 어떤 관련이 있을까요? 대규모 언어 모델(LLM)에 대한 많은 관심이 있었고, 새로운 도구가 등장하여 코드를 작성해 주겠다고 약속하는 것을 보았습니다. 이렇게 하면 소프트웨어 개발의 초기 비용을 줄일 수 있겠지만, 개발자/조직/팀이 정말 원하는 것일까요? 팀원 중 누구도 작성하지 않은, 우리가 요구한 것과 정확히 일치하거나 일치하지 않을 수도 있는 코드를 더 많이 작성하는 데 드는 비용은 얼마일까요? 적절한 도구, 적절한 라이브러리로 추상화할 수 있었다면 유지 관리가 얼마나 어려울까요? 비용이 얼마나 많이 들까요?
다음 코드를 고려하십시오. 제너레이티브 AI 는 현재로서는 3GL의 기술 부채 생성기입니다. 향후 더 정확해지고 기존 추상화 및 주변 에코시스템을 더 잘 활용하게 되면 상황이 달라질 수 있습니다. 하지만 지금은 부가가치를 창출하는 것이 아니라 그 반대입니다. 스칼라 코드를 작성하는 방법은 스칼라 개발자 수만큼이나 많습니다(3GL을 사용하면 사용 중인 추상화를 인터페이스하는 데 도움이 되는 코드, 또는 다른 추상화나 종속성을 대체할 수 있는 코드인 '접착제' 또는 상용구 코드를 많이 생성하게 됩니다).
현재로서는 기존 5GL을 살펴보거나 4GL, 특히 SQL과 같은 도메인 제약이 있는 제너레이티브 AI를 사용하는 것이 더 흥미롭습니다. SQL은 구문이 더 간단하기 때문에 제너레이티브 AI에 매우 적합합니다. SQL은 SQL입니다. 3GL을 사용할 때처럼 SQL 코드를 유지 관리할 필요가 없습니다. 그리고 SQL 코드를 생성할 때 그 가치는 바로 도메인 가치, 비즈니스 가치입니다. 이것이 가장 중요한 부분입니다. SQL은 3GL과 5GL의 중간 지점입니다. 여전히 3GL과 같은 프로그래밍 언어입니다. 5GL에서처럼 문제와 제약이 있는 대신 원하는 것을 표현할 수 있습니다. 모든 데이터 저장소가 결국 SQL을 다시 가져오는 데에는 이유가 있습니다. 그리고 Couchbase처럼 SQL이 새로운 기능으로 계속 업데이트되는 이유도 여기에 있습니다.
결론
TCO 절감을 고려하고 있다면 올바른 추상화를 선택하세요. 그리고 코드를 작성하여 TCO를 절감할 수 있는 제너레이티브 AI를 찾고 있다면 다시 한 번 생각해보고 4GL과 함께 사용해야 합니다.
줄이려면 TCO 그리고 데이터 스프롤, 많은 기업이 선택하는 카우치베이스. 지금 바로 무료 체험을 통해 Couchbase를 직접 사용해 보세요. 시험판.
