[10분 테코톡] 🙆‍♀️티버의 API vs Library vs Framework

출처: https://www.youtube.com/watch?v=We8JKbNQeLo

📌 API, 라이브러리, 프레임워크는 각각 무엇이며, 그 차이점은 무엇인가요?

API는 프로그램 간 연결 다리, 라이브러리는 필요한 기능 모음, 프레임워크는 개발 환경 틀이며, 구현 로직 유무 및 프로그램의 흐름 주도권에 따라 차이가 있습니다.

💡 API, 라이브러리, 프레임워크의 핵심적인 차이점을 한 문장으로 요약하면?

라이브러리와 API의 차이는 구현 로직의 유무이고, 라이브러리와 프레임워크의 차이는 응용 프로그램의 흐름 주도권을 누가 가지는지에 달려 있습니다.

배경지식: API, 라이브러리, 프레임워크의 세계

이 자료는 소프트웨어 개발에서 가장 기본이 되는 세 가지 도구, 즉 API, 라이브러리, 프레임워크의 개념과 차이점을 명쾌하게 설명합니다. 특히, 프레임워크의 핵심을 이해하는 데 결정적인 역할을 하는 제어의 역전(IoC) 원칙을 깊이 있게 다루고 있습니다.

이해를 돕기 위해, 자료에 등장하는 용어와 맥락을 세 가지 핵심 배경지식으로 나누어 쉽게 풀어 설명합니다.

1. 핵심 원칙: 제어의 역전 (Inversion of Control, IoC)

자료에서 라이브러리와 프레임워크를 가르는 가장 중요한 차이점으로 언급된 것이 바로 흐름의 주도권입니다. 이 주도권의 차이를 설명하는 소프트웨어 디자인의 핵심 원칙이 제어의 역전(IoC)입니다.

• 제어의 역전(IoC)의 정의:
  • 일반적인 프로그래밍에서는 개발자가 작성한 코드가 다른 함수나 라이브러리를 직접 호출하며 실행 흐름을 통제합니다.
  • 하지만 IoC는 실행 흐름에 대한 주도권을 개발자의 코드에서 프레임워크로 넘기는 설계 방식입니다.
  • 이 원칙을 가장 쉽게 설명하는 별명은 바로 "할리우드 원칙 (Hollywood Principle)" 입니다.
• 할리우드 원칙의 비유:
  • "저희에게 전화하지 마세요, 저희가 연락드리겠습니다 (Don't call us, we'll call you)."
  • 마치 영화 산업에서 오디션을 본 배우가 제작자에게 계속 전화할 수 없고, 제작자가 필요할 때만 배우에게 연락하는 것과 같습니다.
  • 프레임워크는 전체 프로그램의 큰 틀(뼈대)을 가지고 있으며, 개발자가 작성한 코드를 필요할 때, 정해진 규칙에 따라 호출합니다.
• 라이브러리 vs. 프레임워크 (흐름의 차이):

• 제어 흐름 시각화 (IoC):

2. 기술적 메커니즘: Spring Framework와 어노테이션

발표자가 프레임워크의 예시로 든 Spring Framework는 IoC 원칙을 가장 잘 구현한 대표적인 예시입니다. 특히, 개발자가 작성한 '비즈니스 로직'을 프레임워크에 쉽게 연결하는 데 어노테이션(@Annotation)이 핵심적인 역할을 합니다.

• Spring Framework란?

  • Java 언어 기반의 엔터프라이즈급 애플리케이션 개발을 위한 가장 인기 있는 프레임워크 중 하나입니다.
  • 개발자가 복잡한 설정이나 기반 코드를 작성할 필요 없이, 핵심 기능(비즈니스 로직)에 집중할 수 있도록 다양한 기반 환경과 도구를 제공합니다.

• 어노테이션 (@Annotation)의 역할:

  • 어노테이션은 Java 코드에 추가하는 메타데이터(metadata)입니다. 즉, 코드 자체의 동작은 아니지만, 프레임워크에게 이 코드를 어떻게 처리해야 하는지에 대한 '지침'을 제공합니다.
  • 예시:
    • @Controller: 이 클래스는 사용자의 요청을 처리하는 컨트롤러 역할을 한다고 Spring에게 알려줍니다.
    • @Service: 이 클래스는 핵심 비즈니스 로직을 수행하는 서비스 계층의 역할을 한다고 알려줍니다.

• IoC와 어노테이션의 연결:

  • 자료에서 언급했듯이, 개발자는 컨트롤러 클래스를 만들고 그 위에 어노테이션을 붙입니다 .
  • 흐름: 클라이언트의 요청이 들어오면 →\rightarrow→$\rightarrow$ Spring Framework(주도권 보유자)가 요청을 받아서 →\rightarrow→$\rightarrow$ 어노테이션(지침)을 확인하고 →\rightarrow→$\rightarrow$개발자가 작성한 비즈니스 로직을 가진 컨트롤러를 호출(매핑)합니다.
  • 즉, 개발자는 @Controller와 같은 어노테이션을 통해 자신이 작성한 코드를 "여기에 끼워 넣어주세요" 라고 요청하며, Spring이 "알겠습니다. 이 시점에 제가 호출해드리죠" 라고 응답하는 방식으로 IoC가 실현됩니다.

• 스프링 프레임워크의 이점:

  • 스프링 프레임워크는 복잡한 웹 요청 처리, 데이터베이스 연결 등 반복적이고 기반이 되는 작업을 대신 처리하여, 개발자가 비즈니스 로직 (예: 맛집 공유, 예약 처리)에만 집중할 수 있도록 돕는 역할을 합니다.

  ---

  1. API, 라이브러리, 프레임워크 설명 개요

1. 발표 목표: 소프트웨어 개발의 핵심 개념인 API, 라이브러리, 프레임워크 세 가지에 대해 설명한다.
2. 발표 주안점: 발표자가 학습하며 어렵고 애매했던 개념들을 최대한 쉽게 풀어서 설명하는 것에 중점을 둔다.

2. API (Application Programming Interface) 정의 및 특징

2.1. API의 정의와 역할

1. API 약어: API는 Application Programming Interface의 약어이다.
2. API의 역할: API는 프로그램과 프로그램 사이의 연결을 시켜주는 다리 역할을 한다.
3. API 특징:
   1. 구현 내용과는 독립적으로 사용 방법만 정의되어 있다.
   2. API에 따라 권한이 필요할 수 있다.
4. API의 예시: 자바 API와 여러 기업들의 오픈 API가 있다.

2.2. API 예시: 지도 서비스 공유 프로그램 개발

1. 문제 상황 설정:
   1. 사용자끼리 맛집 위치를 지도로 공유하는 서비스를 만들고자 한다.
   2. 개발자가 직접 지도를 만들기에는 시간 소모가 크고 정확도가 낮을 수 있으므로, 기존의 지도 서비스를 이용하고자 한다.
2. API 활용 과정:
   1. 개발자가 만드는 맛집 공유 프로그램에서 외부 지도 서비스(지사)를 이용하려고 한다.
   2. 지도 서비스 제공 기업(지사)은 "우리 프로그램을 사용하려면 이런 식으로 요청을 보내면 너가 원하는 지도 관련 정보를 줄게"라고 사용법을 정의한다.
3. API의 역할 확인:
   1. 개발자는 지사가 정한 URL 경로를 통해 요청을 보내고 원하는 지도 정보를 받을 수 있다.
   2. 이때, 개발자의 프로그램과 지사의 지도 서비스 프로그램 사이에서 다리 역할을 하는 것이 바로 API이다.
   3. 개발자는 API를 통해 외부 프로그램의 기능을 이용하게 된다.

2.3. 구글 클라우드 API 예시

1. 구글 API 현황: 구글 클라우드 플레이스 페이지에 가면 분야별로 매우 다양한 API가 제공된다.
2. 지도 관련 API: 구체적으로 지도 분야의 API를 확인해 보면, 다양한 기능별로 세분화된 API들을 볼 수 있다.
3. 개발 활용 방안: 프로젝트를 진행할 때 필요한 기능이 없다면, 원하는 API를 찾아서 활용하는 것이 개발을 수월하게 진행하는 방법이 될 수 있다.

3. 라이브러리 (Library) 정의 및 특징

1. 라이브러리의 의미: 단어 자체가 도서관을 의미하며, 도서관을 이용하듯 필요한 기능을 빌려 쓰는 개념이다.
2. 라이브러리의 정의: 응용 프로그램 개발을 위해 필요한 기능이나 함수를 모아 놓은 소프트웨어를 의미한다.
   1. 자주 사용하는 함수나 기능들을 모아 재사용하는 것이 목적이다.
3. 라이브러리의 특징:
   1. 독립성: 해당 라이브러리가 다른 라이브러리에 의존하지 않는다는 것을 의미한다.
   2. 응용 프로그램의 능동적 사용: 응용 프로그램(개발자가 만든 코드)이 능동적으로 라이브러리를 호출하여 사용하는 것이 가장 큰 특징이다.
4. 라이브러리 능동적 사용 예시:
   1. 프로그램 목표: 학생들의 성적 평균을 계산하는 프로그램을 만든다.
   2. 처리 과정: 학생 성적이 담긴 문자열을 입력받아 값을 파싱하고, 원하는 평균값을 반환하는 라이브러리를 사용한다.
   3. 코드의 흐름: 개발자가 작성한 응용 프로그램 코드 내에서 필요할 때 라이브러리를 호출하여 평균 계산 결과를 가져온다.
5. 라이브러리 종류 예시: 아파치 코몬스 푸, 자바스크립트 라이브러리인 jQuery 등이 있다.
   

4. 프레임워크 (Framework) 정의 및 특징

4.1. 프레임워크의 정의와 목적

1. 단어 의미: 프레임(Frame)은 '틀' 또는 '뼈대'를 의미하고, 워크(Work)는 '일하다'를 의미한다.
2. 유추된 의미: 프레임워크는 어떤 틀 안에서 일하는 것으로 유추될 수 있다.
3. 공식 정의: 소프트웨어나 소프트웨어 솔루션 개발을 수월하게 하기 위해 제공되는 소프트웨어 환경 틀이다.
4. 개발자 역할: 개발자는 이 환경 틀(프레임워크) 내에서 자신이 원하는 코드를 작성할 수 있게 된다.

4.2. 프레임워크 예시: 웹 애플리케이션 개발 경험 비교

1. 프레임워크 사용 경험 (레벨 2):
   1. 스프링 프레임워크를 사용하여 웹 애플리케이션을 개발했다.
   2. 이 경험에서는 컨트롤러만 작성하면 스프링이 요청을 처리해 주었다.
   3. 처리 과정: 개발자가 비즈니스 로직을 작성하기 위해 요청을 전향하고, 컨트롤러를 생성하고, 어노테이션을 붙인 후 로직을 작성했다.
   4. 프레임워크의 역할: 스프링 프레임워크가 외부 요청을 받아서, 개발자가 작성한 처리 로직을 가진 컨트롤러를 매핑시켜 주고, 비즈니스 로직을 실행시켜 주었다.
2. 프레임워크 미사용 경험 (현재 미션):
   1. 현재 미션에서는 서버를 직접 만들고 있으며, 서브 시스템, 브랜치 스트림을 처리할 수 있는 Request 객체를 직접 생성하여 사용하고 있다.
   2. 또한, 컨트롤러도 직접 매핑시켜 줘야 하며, 컨트롤러를 만들어서 비즈니스 로직을 작성해야 한다.
3. 비교 결과: 스프링 프레임워크가 없을 때는 개발자가 직접 해야 할 일이 훨씬 많다.
4. 결론: 스프링 프레임워크는 개발자들이 비즈니스 로직에 집중할 수 있도록 기반을 다져놓은 것이다.

4.3. 프레임워크의 핵심 특징: 수동적 사용

1. 프레임워크의 구성: 상호 협력하는 클래스와 인터페이스의 집합이다.
2. 응용 프로그램의 사용 주도권: 응용 프로그램이 프레임워크를 수동적으로 사용한다.
   1. 이는 앞서 라이브러리가 응용 프로그램에 의해 능동적으로 호출되는 것과 대비된다.
3. 수동적 사용 예시:
   1. 개발자는 특정 URL을 거쳐 수행될 비즈니스 로직(개발자가 작성한 코드)을 작성한다.
   2. 흐름 주도권: 스프링 프레임워크가 클라이언트의 요청(리퀘스트)을 처리하고, 컨트롤러를 매핑한 후, 프레임워크가 개발자가 작성한 비즈니스 로직을 호출한다.
   3. 관점 차이: 라이브러리는 개발자 코드가 라이브러리를 호출하지만, 프레임워크는 프레임워크가 할 일을 다 한 후에 개발자 코드를 호출한다.
   4. 결론: 이러한 맥락에서 응용 프로그램이 프레임워크에 의해 수동적으로 사용되는 특징이 나타난다.
4. 프레임워크 종류 예시: 스프링 프레임워크, 코드이그나이터, 루비온 레일즈, 장고 등이 있다.

5. 핵심 개념 비교 및 결론

1. 라이브러리와 API 차이점: 구현 로직의 유무이다.
2. 라이브러리와 프레임워크 차이점: 응용 프로그램의 흐름 주도권을 프레임워크가 가지고 있느냐, 아니면 응용 프로그램이 가지고 있느냐의 차이이다.