라이브러리? 프레임워크?

언어는 선택했어.
그런데... 라이브러리? 프레임워크?
이건 또 뭐야?

 

개발자로 전향을 시작하면서 처음 배울 언어를 선택하셨나요? 그럼 이제 언어 공부를 시작했을 겁니다. 기본 언어를 익히면서뭔가 만들어 봐야 한다고 했었죠? 그런데 사실 지금 막 배우기 시작했거나 또는 어떤 기능을 구현하려고 할 때에 모든 기능을 혼자서 다 구현하려고 하면 막막합니다.

그래서 어떤 개발 아이템을 선정해 두고 학습이든 습작이든 뭔가 만들어보려면 먼저 기능 리스트를 작성하고, 해당 기능에서 내가 작성할 부분과 외부에서 이미 개발되어 있는 구현물을 가져다가 쓸 부분을 정리해야 합니다.

이 때 많이 들어보긴 했지만 정확히는 모르는 2가지 용어가 등장하게 됩니다. 바로 라이브러리와 프레임워크라는 용어죠.

 

1. 둘다 남이 만들어 둔 코드 아니야?

맞습니다. 둘다 누군가가 이미 고민하고 만들어서 정상적으로 작동하는지까지 다 테스트해 둔 코드들의 모음입니다. 하지만 이 두 가지는 서로 다른 사용법과 철학을 가지고 있습니다.

1-1. 라이브러리

라이브러리는 재료나 도구와 같은 역할을 해 주는 이미 개발되어 져 있는 개발 결과물입니다. 쉬운 예로 요리를 할 때에 필요한 재료나 도구와 같습니다. 용어에서 느낄 수 있듯이 어떤 흐름이나 방법을 제공하지 않습니다. 그냥 필요할 때에 쓸 재료나 특정 상황에서 좀더 쉽게 어떤 일을 할 수 있도록 하는 도구의 형식으로 사용하는 겁니다.

중요한 사실은 라이브러리를 쓴다는 것은 개발자가 전체적인 흐름을 스스로 결정하고 제어하는 곳에 이 라이브러리를 쓰는 것이 아니라 개발자가 스스로 결정하고 제어하고 있는 흐름 안에서 기능 만 가져다가 쓰는 경우에 이 기능을 제공해 주는 것을 라이브러리라고 부릅니다. 어떤 곳에 어떤 기능이 필요하다는 판단을 개발자가 해서 그 기능에 해당하는 것만 가져다 쓰는 거죠. 그래서 높은 유연성을 제공해 주지만, 구조나 흐름은 개발자가 직접 설계해야 합니다.

그래서 보통 소스코드 안에서 '가져온다'라는 의미의 import 라는 키워드로 많이 나타납니다. import 해서 사용하는 거죠. 아마 개발을 하다보면 기본적으로 대부분 많은 수의 라이브러리를 사용하게 됩니다.

1-2. 프레임워크

이 녀석은 좀 다릅니다. 프레임워크란 이미 어떤 흐름을 미리 디자인 해 둔 런타임과 유사한 환경을 제공합니다. 코드를 작성할 때에도 프레임워크에서 정해둔 방식으로 작성해야 합니다. 프레임워크가 정해둔 방식으로 내가 코드를 작성해서 실행시키면 프레임워크가 내가 만든 코드를 호출해서 실행하게 됩니다. 이런 경우를 IoC 라는 용어를 사용하죠. 제어의 역전이라는 의미입니다. 용어에서 느낄 수 있는것 처럼, 내가 제어하는 것이 아니라 어떤 존재가 내가 만든 코드를 제어 합니다. 대표적으로 Spring Framework가 이런 방식으로 작동하죠. 물론 이 외에서 수 많은 프레임워크가 있습니다.

프레임워크는 현대 소프트웨어 개발에서 중요한 위치를 차지합니다. 아주 중요한 요소를 제공해 주거든요. 바로 개발 방식 및 프로젝트 구조의 표준화와 이를 통한 생산성의 극대화 입니다. 다른 포스트에서도 이야기 했듯이 생산성은 비용과 직결되는 용어입니다. 현업에서 프레임워크는 개발비용과 직결되어 있다고 보면 됩니다.

그래서 대부분의 기업에서 프로젝트를 설계하거나 기획할 때에 프레임워크를 정합니다. Java나 Kotlin의 경우 Spring이나 Android 개발과 관련된 프레임워크를 쓰고, 프런트로 Javascript나 Typescript를 쓰면 Next.js 같은 프레임워크를 쓰죠. 

 

2. 그럼 차이가 뭐지? 난 뭘 써야 해?

라이브러리는 내가 가져와서(import) 해서 사용하고, 프레임워크는 내가 '그 안에서 개발한다'는 개념으로 생각하면 쉽습니다. 그런데 가끔 이런 질문을 받습니다. React.js는 프레임워크가 아니었나요?네. 맞습니다. React.js는 라이브러리입니다. 프레림워크가 아니죠.

React.js는 Javascript나 Typescript로 프런트를 구축할 때에 UI나 모듈을 컴포넌트로 만들기 위해서 필요한 기능을 제공해 주는 라이브러리 입니다. 라이브러리이기 때문에 위에서 이야기 한 것처럼 프로그램의 제어나 흐름을 개발자가 스스로 디자인해서 통제해야 합니다. 물론 어느정도 표준화 되거나 업계에서 많이 사용하는 패턴이 있습니다.

하지만 중요한 것은 개발자가 스스로 결정해야하고, 프로젝트의 아키텍처도 스스로 결정해야 합니다. 그 만큼 자유도가 높아지고 표준화의 수준도 프로젝트 팀 단위로 내부적인 컨벤션 같은 규약으로 정해둬야 하죠.그럼 언제, 어떤 것을 써야 할까요?

2-1. 라이브러리를 선택해야 하는 경우

• 프로그램의 흐름을 직접 제어해야 하는 경우
• 완전한 제어권을 원할 때
• 특정 기능만 필요할 때
• 기존 프로젝트에 외부에서 개발되어 있는 특정 기능 만 추가할 때에

2-2. 프레임워크를 선택해야 하는 경우

• 대규모 프로젝트나 표준화 된 개발 방식이 필요한 경우
• 개발 시간을 단축하고 싶을 때
• 팀 단위로 일관된 코드베이스를 유지하고 싶은 경우 등

 

3. 결론

실제 현업에서 개발 환경을 구축할 때에는 사실 프레임워크를 대부분 사용합니다. 하지만 프런트의 경우에는 React.js를 사용해서 직접 전체 애플리케이션을 설계하고 디자인 하는 경우도 꽤 많습니다. 개발 팀이나 기업별로 고유의 아키텍처를 가지고 프런트 개발 소스를 유지하는 경우가 그런 경우죠.

이런 경우 입사 후 수습기간동안 해당 기업이나 팀 내에서 만들어 진 고유의 아키텍처를 학습하기 위해서 약 2~3개월 정도 아키텍처를 바닥부터 올리는 교육과적을 밟습니다. 물론 이 교육은 경력직 채용 시에도 이루어 집니다. 왜냐하면 각 설계의 구조는 나름대로의 체계와 철학을 가지고 있어서 처음 보는 사람은 신입이든 경력이든 바로 사용할 수 없습니다.

사실 위에서 쉽게 쉽게 설명해서 이야기 하지 않은 부분이 있습니다. 개발을 하다보면 프레임워크는 상다히 중요합니다. Spring의 아버지인 로드 존슨은 '모든 경우 프레임워크 차원에서 생각하고 솔루션을 도출하는 것이 바람직하다'라는 이야기를 할 정도로 이 프레임워크는 현대 소프트웨어 개발에서 매우 중요한 요소입니다. 단순히 라이브러리를 어떤 체계로 빌드업 해 두었다고 모두 프레임워크는 아니라는 뜻도 됩니다. 프레임워크에는 기본적으로 제어의 역전(IoC)라는 개념이 포함되어 있어야 합니다. 내가 코드를 실행하는 것이 아니라 프레임워크가 내 코드를 실행해야 한다는 뜻이죠. 기술적인 철학과 디자인 패턴이 깊이 스며들어 있는 녀석입니다.

물론 일상 개발에서는 이런 철학이나 또는 원칙적인 작동 원리를 생각하지 않고 그냥 편하게 쓰면 됩니다. 그러라고 만들어 둔 녀석이니까요. 하지만 조금 편하고 안정적으로 쓰려면 프레임워크라는 녀석의 철학과 설계의 원칙을 조금 알아두는 것이 좋습니다.

개발자 전향을 바로 한 시점에서는  라이브러리와 프레임워크의 경계가 모호할 수 있습니다. 위에서 예를 든 것처럼 React.js와 Next.js 처럼 말이죠.중요한 것은 용도입니다. 내가 그냥 가져다가 쓸 것인가? 아니면 내가 이미 만들어져 있는 운용환경에 들어가서 정해진 방식대로 코드를 만들것인가... 

어렵지 않죠?