호랑이 담배피던 시절의 전자정부 프레임워크을 통해 배운 교훈은 프레임웍을 만들려면 잘 유지되야 한다는 것이다. 그래서 프레임워크라는 물건을 만드는 건 매우 어렵다. 전자정부 프레임워크는 당시의 Spring Framework 초기 버전에 공공 프로젝트 진행을 위해 필요한 몇가지 요소를 더한 것이다. 스프링이 시장의 주류로 자리잡는 시기였기에 일관된 형태로 사용하도록 가이드가 어려웠다. 더해서 스프링 프레임워크는 쭉쭉 발전하는데, 전자정부 프레임워크는 스프링의 발전 속도를 따라잡지를 못했다. 결국 한참 벌어진 차이를 극복하지 못했고, 오히려 이걸 쓰는게 보안적인 취약점을 만들기도 했다. 결국 현실의 스프링 대비 한참 낮은 버전이 전자정부 프레임워크의 기반이 되버렸고 개발자들은 왜면했다. 공공 SI를 해야하는 어쩔 수 없는 회사의 개발자들이나 써야하는.

다른 개발 프레임워크은 어떨까? 따지고 보면 예전의 전자정부 프레임워크 접근과 크게 틀리지 않다. 예전에는 그냥 스프링 기반이었다면 이제는 대부분이 스프링부트의 이런 저런 것들이 기반이라는 점 아닐까? 여기에 사내에서 정의된 표준 시스템들인 PaaS 혹은 SaaS를 프레임워크의 요소가 될 것이다. 구성만 보면 전자정부 프레임워크의 구성 요소와 별반 다르지 않은데?

프레이워크를 만든다면 프레임워크 구성 요소들이 동작하도록 엮어야 한다. 상호 동작을 위해 묶으면 일단 강결합이(Tight Coupling) 발생한다. 이런 강결합 상황에서 개별 요소 하나를 바꾸는 건 의존성 문제로 쉽지 않은 일이 되곤한다. 유용함이 커질수록 결합도는 높아지고 변경에 따른 고려 사항들이 많아진다. 결국 바꿀 것들이 많아지거나 아니면 현상을 그대로 유지하는 선택을 강요받는다. 프레임워크의 유지보수 비용이 많이 들어가는 이유이고, 대부분의 프레임워크가 망하는 이유이기도 하다. 그만큼 유연한 구조, Loosely coupled 형태의 프레임워크를 만들기 어렵다.

요즘 만드는 프레임워크는 묶음을 코드가 아닌 AI와 스킬(Skill)을 통해 해결한다. 물론 관련성있는 모듈을 엮기 위한 충분한 메뉴얼이 있어야 한다. 모듈들이 어떤 방식으로 조합되면 좋을지 예시(Example)이 있다면 이를 바탕으로 스킬을 만들 수 있다. 코드가 필요하지만 실제 결합을 위한 코드가 굳이 필요없다. 결합 코드가 물론 좋지만, 코드를 통한 결합은 강결합을 만든다. 이에 반해 AI와 스킬의 조합은 약결합을 통해 기존 강결합된 프레임워크가 보여줄 수 있는 기능을 제공할 수 있다. 프레임워크의 구성 요소의 변경이 필요하더라도 변화 대응에 대한 유연성을 충분히 확보할 수 있다. 다만 언제나 그렇듯 프레임워크 자체에 대한 릴리즈 관리는 변함없이 필요하다.

AI 기반 프레임워크의 주의점은 역시나 할루시네이션이다. 너무 물렁한 요소들이 결합된다면 의도와 다른 방식의 결합물을 쓰는 사람에게 제시할 수 있다. 기능에 대해서는 단단함을 제공해야 하고, 이들이 이어지는 맥락을 약결합되지만 혼선없이 엮일 수 있는 가드레일을 함께 제공해야 한다. 그래야 프레임웍이 제공하는 전체적인 완결성이 지속적으로 제공될 수 있다.

AI 기반 프레임워크가 주는 매력은 굳이 Gradle이나 Maven 같은 툴에 엮을 필요가 없다는 점이다. 프레임워크를 AI Agent화 시키면 언제든 필요할 때 꺼내 쓸 수 있기 때문이다. 그리고 상황에 따라서는 AI가 스스로 이 상황에 가장 맞는 도구로 프레임워크를 꺼내주는게 된다면 “거버닝”을 굳이 강제하지 않아도 자연스러운 조직의 개발 활동으로 이어질 수 있지 않을까 싶다.

꿈꾸는 이야기같지만 실제 이런 것들이 가능한 것이 요즘 아닐까 싶다. 개인이 개발한다면 굳이…라고 이야기할 수도 있겠지만, 조직이 개발을 한다면 이런 프레임워크라는 환경이 조직내에 있어야 한다고 생각한다. 언젠가는 되겠지…