<div id="readability-page-1" class="page"><div id="page" role="main">

			
				
<article id="post-1422">
	

	<div>
				<p>예전에 전자정부 프레임워크을 통해 배운 교훈은 프레임웍을 만들려면 잘 만들어야 한다는 사실이다. 그리고 분명한 사실이지만, 프레임워크라는 이름을 붙힌 물건을 만드는 건 매우 어렵다는 것이다. 전자정부 프레임워크는 당시의 Spring Framework 2.x 버전에 몇가지 것들을 더해 둔 것에 지나지 않는다. 공공 프로젝트 진행에 필요한 몇 가지 것들을 추가하고 이들을 쓰기 위한 몇가지 컨벤션들을 더한 느낌 정도? 그럼에도 일관된 형태로 쓰기도 차 어려웠고, Spring Framework 자체는 쭉쭉 발전하는데, 일관된 형태가 스프링의 발전을 따라잡지를 못했다. 결국 한참 벌어진 차이를 극복하지 못했다. 기억상으로는 이런 현실의 Spring 버전 대비 한참 낮은 버전이 전자정부 프레임워크의 기반이었고, 개발자들은 왜면했다. 공공 SI를 해야하는 어쩔 수 없는 회사의 개발자들이나 써야하는.</p>
<p>요즘의 프레임워크은 어떨까? 따지고 보면 예전의 전자정부 프레임워크 접근과 크게 틀리지 않다. 예전에는 그냥 스프링 기반이었다면 이제는 대부분이 스프링부트의 이런 저런 것들이 기반이라는 점 아닐까? 여기에 사내에서 정의된 표준 시스템들인 PaaS 혹은 SaaS를 프레임워크의 요소가 될 것이다. 예전의 전자정부 프레임워크의 구성 요소와 별반 다르지 않은데?</p>
<p>예전에 프레이워크를 만들었다면 이들이 동작하도록 엮어야 했다. 만약 엮임이 느슨하면 그냥 따로 쓰는 것과 차이가 없기 때문에 묶으면 일단 강결합이(Tight Coupling) 발생한다. 이런 강결합 상황에서 뭐 하나 바꾸는 건 쉽지 않다. 모듈 하나의 변경만으로도 많이 바꿔야한다. 프레임워크의 유지보수 비용을 만드는 가장 큰 요인이다. 대부분의 프레임워크가 망하는 이유도 이것 아닐까 싶다.</p>
<p>요즘 만드는 프레임워크는 묶음을 코드가 아닌 AI와 스킬(Skill)을 통해 해결한다. 관련성있는 모듈들이 엮이는 것은 충분한 메뉴얼이 제공된다는 전제하여 AI가 당연히 잘한다. 어떻게 쓰여야 할지에 대한 부분도 스킬을 활용할 수 있다. 코드가 없다. 코드는 다 좋긴 하지만 Tight Coupling을 만든다. 이에 AI와 스킬의 조합은 Loosely Coupling을 나태낼 수 있다. 구성 라이브러리가 변경되더라도 구성 요소에 대한 간단한 Declaration 변경으로도 충분히 변화된 사항을 반영시킬 수 있다. 여기다 표준화된 CI/CD 체계만 갖추고 있다면 적절한 설정으로 보안을 충분히 커버할 수 있는 프레임워크를 제시하는 것도 가능하다.</p>
<p>확실히 AI는 새로운 관점과 도구임에는 분명하다. 예전같았다면 Tightly coupling의 지옥에 있어야 할 다양한 프레임워크들이 자유롭게 개발자와 만날 수 있기도 하고, 프레이워크 자체의 발전을 Loosely coupling을 통해 보다 유연하게 제공할 수 있는 장점을 제공하니까. 다만 토큰을 써야 한다는 것은 숙명이겠지만… 손쉽게 부담없이 쓸 수 있도록 메뉴얼을 잘 준비하면 되지 않을까 싶다.</p>
<p>예전에는 코멘트는 관리안되는 요소다… 라고 강력 반대를 했지만, 최근 작업 결과물에 MD 파일이 누락되거나 수정 내용에 대한 설명이 없다면 PR 머지를 하면 안되는거 아닌가 싶은 생각도 든다.</p>
			</div>

	

</article>


				
					
	

			
			</div></div>

Dreaming for the Future

예전에 전자정부 프레임워크을 통해 배운 교훈은 프레임웍을 만들려면 잘 만들어야 한다는 사실이다. 그리고 분명한 사실이지만, 프레임워크라는 이름을 붙힌 물건을 만드는 건 매우 어렵다는 것이다. 전자정부 프레임워크는 당시의 Spring Framework 2.x 버전에 몇가지 것들을 더해 둔 것에 지나지 않는다. 공공 프로젝트 진행에 필요한 몇 가지 것들을 추가하고 이들을 쓰기 위한 몇가지 컨벤션들을 더한 느낌 정도? 그럼에도 일관된 형태로 쓰기도 차 어려웠고, Spring Framework 자체는 쭉쭉 발전하는데, 일관된 형태가 스프링의 발전을 따라잡지를 못했다. 결국 한참 벌어진 차이를 극복하지 못했다. 기억상으로는 이런 현실의 Spring 버전 대비 한참 낮은 버전이 전자정부 프레임워크의 기반이었고, 개발자들은 왜면했다. 공공 SI를 해야하는 어쩔 수 없는 회사의 개발자들이나 써야하는.
요즘의 프레임워크은 어떨까? 따지고 보면 예전의 전자정부 프레임워크 접근과 크게 틀리지 않다. 예전에는 그냥 스프링 기반이었다면 이제는 대부분이 스프링부트의 이런 저런 것들이 기반이라는 점 아닐까? 여기에 사내에서 정의된 표준 시스템들인 PaaS 혹은 SaaS를 프레임워크의 요소가 될 것이다. 예전의 전자정부 프레임워크의 구성 요소와 별반 다르지 않은데?
예전에 프레이워크를 만들었다면 이들이 동작하도록 엮어야 했다. 만약 엮임이 느슨하면 그냥 따로 쓰는 것과 차이가 없기 때문에 묶으면 일단 강결합이(Tight Coupling) 발생한다. 이런 강결합 상황에서 뭐 하나 바꾸는 건 쉽지 않다. 모듈 하나의 변경만으로도 많이 바꿔야한다. 프레임워크의 유지보수 비용을 만드는 가장 큰 요인이다. 대부분의 프레임워크가 망하는 이유도 이것 아닐까 싶다.
요즘 만드는 프레임워크는 묶음을 코드가 아닌 AI와 스킬(Skill)을 통해 해결한다. 관련성있는 모듈들이 엮이는 것은 충분한 메뉴얼이 제공된다는 전제하여 AI가 당연히 잘한다. 어떻게 쓰여야 할지에 대한 부분도 스킬을 활용할 수 있다. 코드가 없다. 코드는 다 좋긴 하지만 Tight Coupling을 만든다. 이에 AI와 스킬의 조합은 Loosely Coupling을 나태낼 수 있다. 구성 라이브러리가 변경되더라도 구성 요소에 대한 간단한 Declaration 변경으로도 충분히 변화된 사항을 반영시킬 수 있다. 여기다 표준화된 CI/CD 체계만 갖추고 있다면 적절한 설정으로 보안을 충분히 커버할 수 있는 프레임워크를 제시하는 것도 가능하다.
확실히 AI는 새로운 관점과 도구임에는 분명하다. 예전같았다면 Tightly coupling의 지옥에 있어야 할 다양한 프레임워크들이 자유롭게 개발자와 만날 수 있기도 하고, 프레이워크 자체의 발전을 Loosely coupling을 통해 보다 유연하게 제공할 수 있는 장점을 제공하니까. 다만 토큰을 써야 한다는 것은 숙명이겠지만… 손쉽게 부담없이 쓸 수 있도록 메뉴얼을 잘 준비하면 되지 않을까 싶다.
예전에는 코멘트는 관리안되는 요소다… 라고 강력 반대를 했지만, 최근 작업 결과물에 MD 파일이 누락되거나 수정 내용에 대한 설명이 없다면 PR 머지를 하면 안되는거 아닌가 싶은 생각도 든다.
						
Share List

접착제같은 AI라고 해야할까?

댓글