[ Essay - Technology ] 바이브 코딩의 허와 실

이미지
지금 우리는 가히 AI 시대라는 패러다임의 전환에 시대에 살고 있다고 해도 과언이 아니다. 특히, IT 업계에서 대다수의 작업량을 차지하는 프로그래밍의 영역에서 생성 AI를 이용한 생산성 향상의 가능성이 보이면서 어느 분야보다 가장 빠르게 괄목적인 성과를 이루고 있는듯 하다. 고작 몇 년전에는 커서에 의해 프로그래밍을 AI에게 프로그래밍을 위임하는 것이 더 나을 수 있다는 것이 어느정도 증명되면서, 작년에는 Claude Code의 영향으로 인해 이러한 이슈가 좀 더 가속화되지 않았나 싶다. 이러한 굉장히 빠르게 이루어지고 있는 생성형 AI 솔루션의 발달은 개발자의 종말론을 더더욱 부각시키면서 업계 전반이 큰 변화를 겪고 있는 것으로 보인다. 특히 이러한 변화 속에서 “프로그래밍을 몰라도 생성형 AI만 있으면 제품을 만들 수 있다”는  주장도 자연스럽게 힘을 얻고 있다. 최근에는 Saas 솔루션은 종말할 것이라는 다소 파격적인 이야기도 들리는 것으로 보면 소프트웨어 업계가 큰 격변의 시기가 온것임에는 틀림 없어 보인다. 허(虛): 빠르게 만들 수 있다는 환상 이런 상황에서 가장 주목받는 주장들은 서론에서 언급했다시피 ‘프로그래밍을 알지 못한다고 하더라도  생성형AI를 이용하면 빠르게 제품을 개발이 가능하다’라는 주장이고, 실제로 이는 어느 정도 타당성이 있어 보인다. 정말로 움직이는 결과물을 단 몇초 만에 보여주기 때문이다. 하지만, 이러한 ‘빠르게 제품 개발 가능하다’는 주장의 가장 큰 맹점이 있는데 개발자의 존재 이유가 단순한 제품이나 기능개발에 있지 않다는 점이다. 만약, AI를 통해 그럴듯 한 솔루션을 만들었다고 치자. 이것에 얼마만큼의 비지니스성과 지속가능성이 있을까? 더 나아가 당신이 이 솔루션을 이용하려고 하는 유저라면, 이 솔루션에 어떠한 가치를 내리고 얼마 만큼의 돈을 지불할 수 있을까? 당신이 금세 만들 수 있는 제품을 상대방이라고 못 만들 이유가 없지 않을까? 그러니깐, 앞서서 이런 것들을 생각하지 못 한 솔루션들은 상대적으로...

[ Web ] 서버 사이드(Sever Side) ? 클라이언트 사이드(Client Side)? 2 [서버 사이드(Sever Side), 결론]


이전 글에서 클라이언트 사이드에 대해서 
어느 정도 직감을 잡았으리라 생각 된다.

그 다음 부터는 크게 설명할것이 없을 듯하다.

왜냐하면
클라이언트 사이드와 크게 다를바가 없기 때문이다.

따라서 이번에는 서버 사이드에 대한 이야기보다
서버 사이드와 클라이언트 사이드 이 두개를 놓고 이야기하는 것에
중점을 둘 것이다.

그럼 이제 서버 사이드에 대한 이야기부터 시작해보자.

서버 사이드(Server Side)


클라이언트 사이드와 동일하게 
나의 직감을 이야기 하면
서버(제공자) 측에서 수행되는 것들 혹은 애플리케이션(언어 등)
으로 정의 내리고 싶다.

물론 클라이언트 사이드에서 이야기한대로
정의는 사람마다 다를 수 있다.

서버 사이드의 목표는 클라이언트에 전달할 
정/동적 웹페이지를 만들어서 보내는 것이다.

이에 사용되는 언어 혹은 도구로서 언급될 수 있는 것들은


Java, PHP, Ruby, Python, Node.js 등을 언급할 수 있다.

서버 사이드는 클라이언트로 보낼 
웹 페이지(HTML, JavaScript 등이 담긴)를 만들어 보내며,
정말 중요한 작업들(사용자 유효성, DB 관련 등)을 수행한다.

즉 웹에서 서버와 클라이언트는 
정해진 웹 페이지로 서로 커뮤니케이션을 한다고 볼 수 있다.

서버 사이드와 클라이언트 사이드의
상관 관계


그렇다면 1부에서 마지막에서 잠깐 언급했던 
메모리의 이야기로 다시 돌아와보자.

나는 1부 마지막 쯤에 
그럴 수 밖에 없는 서버 측의 이유가 있다고 이야기를 했다.

그에 대한 이야기를 하고자 한다.

많은 이유가 언급될 수 있는데
그 중 가장 큰 이유는 

서버의 수보다 클라이언트 수가 
절대적으로 많을 수 밖에 없기 때문이다.



제한적인 서버 수에 비해 사용자가 압도적으로 많기 때문에
혹은 많을 수 있기 때문에

가급적 서버의 부담을 줄일 수 밖에 없다.

하지만 서버가 수용할 수 있는 한계는 있고,
사용자는 많거나 많을 수 있는 상황에서

사용자 유효성 검사,
DB관련 처리 등의 정말 필요한 처리를 제외하고는
클라이언트에서 처리하는 것이 효율적이다.

서버의 점점 부담이 가면 갈수록 
서버의 상태는 위험해지며,
결국 서버가 다운되는 상태까지 이르게 된다.

이러한 이유 때문에
서버 사이드는 이런 중요한 처리에 
관련된 쪽으로 발달하였고,

클라이언트 사이드는 비교적 중요하지 않은 처리
혹은 무거운 처리에 
관련된 쪽으로 발달되었다고 나는 보고 있다.

따라서 어느 쪽에 무게를 더 두느냐에 따라 
프로젝트의 진행 방향이 조금 다를 수도 있다.

서버 사이드에 너무 무게를 둔다면
비교적 사용자가 이용하는데 쾌적함을 느낄 수 있을 것이지만,

그 만큼 서버에 부담이 가해지는 것을 염두해둬야한다.

반대로
클라이언트 사이드에 너무 무게를 둔다면
서버에 가해지는 부담은 그 만큼 줄어들 겠지만

사용자가 이용하는데 불편함을 느낄 것이다.

이는 매출으로도 이어질 수 있기 때문에
반드시 고려해 봐야한다.

따라서 이 균형을 적절히 
유지하는 것이 가장 베스트라 할 수 있다. 

물론 1부에서 이야기 했듯이 

현재에 들어서는 하드웨어의 비약적인 발달로 
대개 비교적 클라이언트 사이드에 무게가 갈 것 이다.

마치며


이로서 대략적으로 서버 사이드와 
클라이언트 사이드에 대한 이야기를 해보았다.

결론적으로

클라이언트 사이드는
클라이언트(사용자) 측에서 수행되는 것들 혹은 애플리케이션(언어 등)

서버 사이드는
서버(제공자) 측에서 수행되는 것들 혹은 애플리케이션(언어 등)
와 비슷한 직감을 가질 수 있으면 된다.

조금 덧 붙여서 이야기하자면


웹 업계에서 말하는 직종 중에
프론트 엔드와 백엔드가 있는데

이런 클라이언트 사이드 언어를 다루고
그에 관련된 개발자를 프론트 엔드

그리고 서버 사이드 언어를 다루고
그에 관련된 개발자를 백엔드라 부른다.

여기 까지 해서 
내가 하고 싶은 이야기는 모두 한 듯 하다.

나의 글을 통해 서버 사이드와 클라이언트 사이드의
직감을 잡는데 도움이 되었길 바란다.






이 블로그의 인기 게시물

[ Web ] 서버 사이드(Sever Side) ? 클라이언트 사이드(Client Side)? 1 [서론, 클라이언트 사이드(Client Side)]

[ Web ] 웹 애플리케이션 아키텍처 (Web Application Architecture)

[ Web ] 웹 애플리케이션 서버 아키텍처의 정의 및 유형 ( Define and Types of Web Application Server Architecture )