개발을 위한 기초 개념들

MVC 패턴이란?

(Model View Controller Pattern)
조율, 데이터, 화면으로 프로그램을 구성하는 방식
Model(데이터) - models.py
Candidate 클래스의 형식대로 데이터를 DB에 저장, 불러옴
View(화면) - templates
화면에 어떤 장면을 보여줄지를 결정

Controller(조율) - views.py
Candidate 모델에서 데이터를 읽어, index.html에 전달

그 외 다른 소프트웨어 디자인 패턴들

아키텍쳐 패턴(Architectural Patterns)은 대략 다음의 10가지 종류가 있습니다.

1. Layered pattern

2. Client-server pattern

3. Master-slave pattern

4. Pipe-filter pattern

5. Broker pattern

6. Peer-to-peer pattern

7. Event-bus pattern

8. Model-view-controller pattern

9. Blackboard pattern

10. Interpreter pattern

프레임워크란?

"프레임워크란, 소프트웨어의 구체적인 부분에 해당하는 설계와 구현을 재사용이 가능하게끔 일련의 협업화된 형태로 클래스들을 제공하는 것"

라이브러리란?

라이브러리란 자주 사용되는 로직을 재사용하기 편리하도록 잘 정리한 일련의 코드들의 집합을 의미합니다.

프레임워크 vs 라이브러리

프레임워크는 자동차의 프레임, 즉 기본적으로 구성하고 있는 뼈대를 말합니다.라이브러리는 자동차의 기능을 하는 부품을 의미합니다.
예를 들어, 자동차를 굴러갈 수 있게 하는 바퀴, 어두운 밤을 환하게 비출 수 있는 헤드라이트, 비 올 때 창문을 닦아주는 와이퍼 등이 라이브러리라고 할 수 있습니다.

컴파일러와 인터프리터의 차이?

컴파일러

컴파일러는 프로그램 전체를 스캔하여 이를 모두 기계어로 번역한다. 전체를 스캔하기 때문에 대개 컴파일러는 초기 스캔 시간이 오래 걸린다. 하지만 전체 실행 시간만 따지고 보면 인터프리터 보다 빠르다. 왜냐하면 컴파일러는 초기 스캔을 마치면 실행파일을 만들어 놓고 다음에 실행할때 이전에 만들어 놓았던 실행파일을 실행하기 때문이다. 하지만 단점도 있다. 컴파일러는 고급언어로 작성된 소스를 기계어로 번역하고 이 과정에서 오브젝트 코드(Object Code)라는 파일을 만드는데 이 오브젝트 코드를 묶어서 하나의 실행 파일로 다시 만드는 링킹(Linking) 이라는 작업을 해야한다. 설명만 딱 봐도 뚝딱하고 번역을 하는것 같아 보이진 않는다. 이때문에 컴파일러는 통상적으로 인터프리터 보다 많은 메모리를 사용해야 한다. 또한 컴파일러는 오류 메시지를 생성할때 전체 코드를 검사한 후에 오류 메시지를 생성한다. 그래서 실행 전에 오류를 발견 할 수 있다. 대표적인 언어로 C,C++,JAVA 등이 있다.

인터프리터

컴파일러와는 반대로 인터프리터는 프로그램 실행시 한 번에 한 문장씩 번역한다. 그렇기 때문에 한번에 전체를 스캔하고 실행파일을 만들어서 실행하는 컴파일러보다 실행시간이 더 걸린다. 그럴 수 밖에 없다고 본다. 한 문장 읽고 번역하여 실행시키는 과정을 반복하는게 만들어 놓은 실행파일을 한번 실행시키는 것보다 빠르긴 힘들어 보인다. 하지만 인터프리터는 메모리 효율이 좋다. 왜냐하면 컴파일러처럼 목적코드를 만들지도 않고, 링킹 과정도 거치지 않기 때문이다. 이 때문에 인터프리터는 메모리 사용에 컴파일러 보다 더 효율적인 모습을 보인다. 인터프리터는 오류 메시지 생성과정이 컴파일러와 다르다. 인터프리터는 한번에 한문장씩 번역하기 때문에 프로그램을 실행시키고 한 문장씩 번역될때 오류를 만나게 되면 바로 프로그램을 중지한다. 그래서 프로그램을 실행해봐야지만 오류 발견이 가능하다. 대표적인 언어로 Python, Ruby, Javascript 등이 있다.

컴파일러(compiler)
전체 파일을 스캔하여 한꺼번에 번역한다.
초기 스캔시간이 오래 걸리지만, 한번 실행 파일이 만들어지고 나면 빠르다.
기계어 번역과정에서 더 많은 메모리를 사용한다.
전체 코드를 스캔하는 과정에서 모든 오류를 한꺼번에 출력해주기 때문에 실행 전에 오류를 알 수 있다.
대표적인 언어로 C, C++, JAVA 등이 있다.

인터프리터(interpreter)
프로그램 실행시 한 번에 한 문장씩 번역한다.
한번에 한문장씩 번역후 실행 시키기 때문에 실행 시간이 느리다.
컴파일러와 같은 오브젝트 코드 생성과정이 없기 때문에 메모리 효율이 좋다.
프로그램을 실행시키고 나서 오류를 발견하면 바로 실행을 중지 시킨다. 실행 후에 오류를 알 수 있다.
대표적인 언어로 Python, Ruby, Javascript 등이 있다.

API란?

'Application Programming Interface'의 약자로서 운영체제와 응용프로그램 사이의 통신에 사용되는 언어나 메시지 형식

먼저 API란, 쉽게 말하면 가게의 점원입니다. 점원은 손님의 주문을 받아 요리사에게 전달하죠? 반대로 요리사에게 받은 음식을 손님에게 전합니다. 점원의 역할처럼 API는 중간 전달자입니다.
요리사와 손님을 각 서버라고 한다면 API는 중간에서 양쪽의 서버를 연결을 해 주는 거죠.

FastAPI란?

파이썬 3.6 버전부터 제공되는 트랜디하고 높은 성능을 가진 파이썬 프레임워크. FastAPI라는 이름처럼 빠르게 개발을 진행할 수 있다. 별도의 구성이나 설치의 필요없이 바로 사용할 수 있는 비동기적인 특성을 가진 프레임워크이기 때문이다.

패키지매니저란?

패키지 매니저(Package manager)는 패키지를 다루는 작업을 편리하고 안전하게 수행하기 위해 사용되는 툴이다.
여기서 패키지를 다루는 작업이란 패키지를 설치, 업데이트, 수정, 삭제하는 작업을 의미한다.

라이브러리가 코드의 작성을 위해 사용되는 코드의 묶음이라면, 패키지는 코드의 배포를 위해 사용되는 코드의 묶음이다.

MSA란?

MircroService Architecture의 줄임말

마이크로서비스(microservice)는 애플리케이션을 느슨하게 결합된 서비스의 모임으로 구조화하는 *서비스 지향 아키텍처(SOA) 스타일의 일종인 소프트웨어 개발 기법이다.

MSA 장점
1. 배포

• 서비스별 개별 배포가 가능합니다.(배포시 전체 서비스의 중단이 없습니다.)
• 특정 서비스의 요구사항만을 반영하여, 빠르게 배포 가능합니다.

2. 확장

• 특정 서비스에 대한 확장성(scale-out)이 유리합니다.
• 클라우드 기반 서비스 사용에 적합합니다.

3. 장애

• 일부 장애가 전체 서비스로 확장될 가능성이 적습니다.
• 부분적으로 발생하는 장애에 대한 격리가 수월합니다.

4. 그 외

• 새로운 기술을 적용하기 유연합니다.(전체 서비스가 아닌 특정 서비스만 별도의 기술 또는 언어로 구현 가능)
• 각각의 서비스에 대한 구조 파악 및 분석이 모놀리식 구조에 비해 쉽습니다.

MSA 단점

1. 설계의 어려움

• MSA는 모놀리식에 비해 상대적으로 많이 복잡합니다. 서비스가 모두 분산되어 있기 때문에 개발자는 내부 시스템의 통신을 어떻게 가져가야 할지 정해야합니다. 또한, 통신의 장애와 서버의 부하 등이 있을 경우 어떻게 transaction을 유지할지 결정하고 구현해야합니다.

2. 성능

• 서비스 간 호출 시 API를 사용하므로, 통신 비용이나 Latency에 대해 이슈가 존재합니다.

3. 테스트/데이터 트랜잭션

• 모놀리식에서는 단일 트랜잭션을 유지하면 됐지만 MSA에서는 비즈니스에 대한 DB를 가지고 있는 서비스도 각기 다르고, 서비스의 연결을 위해서는 통신이 포함되기 때문에 트랜잭션을 유지하는게 어렵습니다.
• 통합 테스트가 어렵습니다. 개발 환경과 실제 운영환경을 동일하게 가져가는 것이 쉽지 않습니다.

4. 데이터 관리

• 데이터가 여러 서비스에 분산되어 있어 조회하기 어렵습니다.
• 데이터를 관리하기 어렵습니다.