Classic_Blue_Note

스프링 프레임워크에 대해 공부하면서, 스프링의 가장 큰 두가지 특징으로 DI와 IoC가 존재한다는 것을 배웠었다.

그런데 스프링에서 DI와 IoC를 도입하게 된 이유로 되돌아 올라가 보면, 싱글톤 패턴을 적용하면서 객체지향에서의 SOLID 원칙을 따르기 위해 해당 개념을 사용했다고 한다. 그러나 해당 개념에 대해서 이해하기 어려웠던 점도 있고, 최근 코딩 테스트 이후 CS 시험들을 2차 테스트로 보면서 SOLID 원칙에 대해 어느정도 상세히 이해하고 있는지에 대해서 묻는 문제들이 자주 출제되었다. 그래서 스프링 공부를 하면서 겸사겸사 SOLID 원칙에 대해 간단하게 정리해 보았다.

SOLID란 로버트 마틴의 좋은 객체 지향 설계의 5가지 원칙으로, 해당 원칙들의 맨 앞글자들을 따서 만든 용어이다. 이 원칙을 알아야 하는 이유는 시스템의 기능이 확장되거나 변동사항이 있을 때, 객체지향적인 설계가 추구하는 점인 기존의 시스템들이 영향을 받지 않는 방향을 갖기 위해서이다.

1. SRP(Single Responsibility Principle, 단일 책임 원칙)

소프트웨어의 한 객체는 단 하나의 책임만 가질 수 있다.

변경이 있을 때 파급 효과가 작은 경우 SRP를 잘 따랐다고 할 수 있으며, 책임의 범위를 적절하게 조절할 필요가 있다.

객체 간의 응집도를 최대화하고, 객체 간의 결합도를 최소화하는 것이 좋은 프로그램이라고 볼 수 있다.

2. OCP(Open/Closed Principle, 개방 폐쇄 원칙)

소프트웨어가 기존의 코드를 변경하지 않고(Closed) 확장할 수 있다(Open).

확장에는 열려 있고, 변경에는 닫혀 있어야 한다.

이때 자바의 경우 다형성을 사용하는데, 인터페이스를 구현한 새로운 클래스를 만듬으로써 새로운 기능을 구현한다.

그러나 구현 객체를 변경하려면 결국 클라이언트 코드를 변경해야 하는 문제점이 있고, 이때 OCP가 깨지게 된다. 따라서 스프링에서는 이 원칙을 DI를 이용하여 지원하고 있다.

3. LSP(Liskov Substitution Principle, 리스코프 치환 원칙

객체는 프로그램의 정확성을 깨트리지 않으면서 하위 타입의 인스턴스로 변환할 수 있어야 한다.

클래스를 상속하는 자식 클래스들은 부모 클래스의 규약을 지켜야 한다는 것으로, 기능적으로 보장이 필요하다는 의미이다. 인터페이스에 대한 구현체를 구현할 때, 인터페이스의 규약을 지켜줘야 한다.

컴파일 단계에서 문제가 생기지 않을수는 있지만, 부모 클래스가 규정하고 있는 기능을 무시하거나 오버라이딩을 자제해야 한다는 의미이다.

4. ISP(Interface Segregation Principle, 인터페이스 분리 원칙)

특정 클라이언트를 위한 인터페이스 여러개를 사용하는 것이 범용 인터페이스를 하나 사용하는 것보다 낫다.

여러 개의 인터페이스를 구현함으로써 대체 가능성을 향상시키고, 인터페이스의 기능을 명확하게 표현할 수 있다.

일반적인 인터페이스를 구체적인 여러 인터페이스로 나눠줌으로써 ISP를 만족하도록 설계할 수 있다.

5. DIP(Dependency Inversion Principle, 의존 관계 역전 원칙)

추상화에 의존해야지, 구체화에 의존하면 안된다.

구현체보다는 인터페이스나 추상 클래스에 의존하는 편이 좋다는 의미로, 클라이언트 코드가 구현 클래스를 바라보는 것이 아닌, 인터페이스를 바라보도록 하는 것을 의미한다. 즉, 역할에 의존하게 한다는 의미로써, 클래스에서 역할의 의미를 갖는 인터페이스에 의존해야 한다는 것이다.

그러나 일반적인 경우, 인터페이스가 구현 클래스를 선택하게 되기 때문에 이때, DIP의 위반이 발생할 수 있다. 따라서 이 문제점도 스프링에서는 DI를 이용하여 클라이언트 코드 변경 없이 기능을 확장할 수 있도록 제공하고 있다.

1. RDT란

RDT란 Reliable data transfer의 약자로, TCP에서 신뢰성 있는 데이터 전송을 보장하기 위한 개념이다. RDT는 TCP가 UDP와 구분되는 가장 큰 특징이라고 볼 수 있으며, 사실상 TCP 네트워킹에서 가장 중요한 개념으로 봐도 무방하다.

네트워크는 공식적으로 7개의 계층으로 이루어져 있다(OSI 7 Layer 참고). RDT란 이때, 상위 계층에서 전송한 데이터가 손상되거나 손실되지 않도록 보장하는 개념으로써, 하위 계층에서 신뢰성을 보장할 수 없기 때문에 특정 계층에서 신뢰성을 보장하도록 하면, 그 상위 계층의 신뢰성은 모두 보장된다는 개념으로 볼 수 있다.

패킷을 송신하는 경우, 상위레이어에서 rdt_send()를 이용하여 RDT 프로토콜로 데이터를 전송한다. 이후 RDT 프로토콜에서 신뢰할 수 없는 채널인 하위 레이어로 보낼 때, udt_send()를 이용하여 패킷을 전송한다.

패킷을 수신하는 경우, rdt_rcv()를 통하여 하위 레이어에서 RDT 프로토콜로 데이터를 전송하고, RDT 프로토콜에서 상위 레이어로 데이터를 보낼 때 deliver_data()를 호출하여 데이터를 전송한다.

즉, 하위 Unreliable Channel을 통과하더라도, 신뢰성 있는 전달을 보장하는 것이 RDT 프로토콜의 기본이라고 볼 수 있다.

2. RDT 1.0

RDT 1.0은 네트워크의 모든 채널이 완벽하게 신뢰성 있다고 가정할 때 사용하는 방식으로, 단순히 데이터의 송신 및 수신만 이루어지는 구조이다. 채널이 안정적이기 때문에, 패킷 손실 등의 에러가 전혀 발생하지 않는다고 가정한다.

rdt_sender는 상위 계층에서 데이터를 받고 데이터를 포함한 패킷을 생성한 뒤, 이를 송신한다.

rdt_receiver는 하위 채널에서 패킷을 수신하고, 데이터를 추출한 뒤, 이를 상위 계층으로 전달한다.

이때 만약 하위 채널이 안정적이지 못하다면, 그래서 비트 오류가 발생할 수 있다는 것을 가정하여 RDT 2.0으로 발전하게 된다. 

3. RDT 2.0

RDT 2.0부터는 비트 에러가 발생할 수 있다고 생각하고 이때의 에러 처리에 대해 생각하고 설계를 진행하였다. 따라서 ACK, NAK 라는 신호를 보내는데, 이를 통해 수신된 패킷이 손상되었는지 여부를 수신자가 송신자에게 반환해 준다.

이때 rdt_sender는 두 가지의 상태를 갖는다. sender는 파일을 보낸 후, ACK/NAK 신호를 기다린다. 이후 오류가 없다면 상위 계층에서 데이터를 기다리는 상태로 돌아간다. NAK가 수신된다면 데이터를 재전송하고, 또다시 ACK/NAK 신호를 기다린다.

rdt_receiver는 단일 상태를 갖는다. 패킷이 도착했을 때, 수신된 패킷의 손상 여부에 따라 ACK/NAK로 응답하고, NAK를 응답한 뒤에는 다시 패킷이 도착하는 것을 기다린다.

RDT 2.0은 이론상 잘 동작하는 것처럼 보이지만, 치명적인 결함이 존재한다. ACK와 NAK 패킷 자체의 손상을 가정하지 않는다는 점이다. 예를 들어, 수신자가 ACK를 보내야 하는데, 이것이 손상되어 제대로 전달이 되지 않는다면 송신자는 패킷을 수신 측으로 다시 보내야 할 것이다. 이때 수신 측은 혼란이 있을 것이다. 아까 받은 데이터에 대한 ACK를 보냈는데, 동일한 데이터가 다시 왔으니 해당 데이터가 다음 데이터인지 중복으로 온 이상 있는 데이터인지 확인이 불가능하다. 따라서 이런 문제점들을 해결하기 위해 RDT 2.1이 도입되었다.

4. RDT 2.1

RDT 2.1은 RDT 2.0에 시퀀스 넘버를 추가한 방식이다. RDT 2.0에 비해 이런 순서 번호를 갖고 있는 이유는 각 패킷에 대한 순서를 정함으로써 해당 패킷이 새로운 데이터를 전송하는 것인지 NAK를 받아 재전송한 것인지를 구분하기 위한 것이다. 만약 송신자가 NAK 1이라는 데이터를 받으면, 송신자는 1번 패킷이 문제가 있다는 것을 확인할 수 있다. 그림에서는 편의상 시퀀스 넘버가 0, 1 두가지만 있다고 가정한다.

rdt_sender는 총 4가지 상태가 존재한다. 패킷을 만들고 시퀀스 0을 넣어서 전송하고, 상태를 전환한 뒤 ACK/NAK를 기다린다. 이후 rdt_receiver가 0번 패킷에 대한 ACK/NAK를 전송해 주고, ACK를 받으면 시퀀스 1을 넣은 새로운 패킷을 보내 주며, NAK를 받거나 오류가 있는 패킷이 들어온다면(corrupt 발생), 시퀀스 0을 넣은 기존 패킷을 보낸다. 따라서 0번 패킷을 보내기 전 상태, 0번 패킷을 보내고 ACK/NAK를 기다리는 상태, 1번 패킷을 보내기 전 상태, 1번 패킷을 보내고 ACK/NAK를 기다리는 상태 총 4가지 상태가 존재하게 된다.

rdt_receiver는 2가지 상태가 존재한다. 0번 패킷을 보내기 전 상태, 1번 패킷을 보내기 전 상태이다. 1번 패킷을 보내기 전 상태에서 1번 패킷이 수신되면 ACK를 보내면 되고, 0번 패킷이 도착하면 0번 패킷이 중복도착했으므로 무언가 중간에 문제가 생겼음을 확인하고, 0번 패킷에 대한 ACK를 보낸다. 그 외 NAK를 보내는 상황은 RDT 2.0과 동일하게 이루어진다.

5. RDT 2.2

RDT 2.2는 RDT 2.1에서 NAK 신호를 삭제한 프로토콜이다. NAK 대신 가장 최근에 잘 받은 패킷에 대한 ACK를 보냄으로써 NAK를 보내는 것과 동일한 효과를 얻을 수 있다.

RDT 2.1과 동일하게 이루어지지만, 송신 측이 1번 패킷을 보냈을 때, 수신 측에서 1번 패킷에 대한 ACK가 아니라 0번 패킷에 대한 ACK가 돌아온다면 송신 측은 1번 패킷의 전송에 문제가 있다는 것을 확인하고 재전송하게 된다.

그러나 RDT 2.2까지 적용하더라도 전송 도중 패킷이 유실될 수 있는 상황은 확인이 불가능하다. 모종의 이유로 데이터 패킷 자체가 유실될 수 있는데, 이러한 문제를 해결하기 위해 RDT 3.0이 등장했다.

6. RDT 3.0

RDT 3.0에서는 일정 시간을 기다리는 timer를 이용하여 패킷 손실을 검출하고, 손실이 발생했을 때 어떤 행동을 해야 하는지 판단할 수 있다. 타이머는 100% 패킷 손실이 일어났다고 보장할 수는 없지만, 손실이 일어났다고 판단할 수 있는 시간을 선택할 수 있다. 만일 ACK가 특정 시간 안에 수신되지 않는 경우 패킷이 재전송될 수 있으며, 이 경우는 특정 패킷이 전송 딜레이가 너무 커져서 타이머 시간보다 늦게 도착하는 경우에도 패킷이 재전송될 수 있다는 것을 의미한다. 따라서 중복 데이터 패킷이 존재할 수 있으며, 이는 RDT 2.2에서 시퀀스 넘버를 이용하여 이미 해결한 부분이다.

RDT 3.0의 receiver의 경우, RDT 2.2의 receiver와 동일한 역할을 한다.

RDT 3.0까지 발전하면서 네트워크에서 신뢰성 있는 전송에 대한 성능은 향상되었지만, 기본적으로 RDT는 전송 후 대기하는 방식의 프로토콜이기 때문에, 현대 고속 네트워크에 대한 요구를 모두 만족시키지는 못했다. 따라서 이러한 문제점들을 해결하기 위해, ACK를 기다리지 않고 여러 패킷을 전송하도록 허용함으로써 성능 향상을 가져올 수 있다. 이러한 기술을 파이프라이닝이라고 하며, 파이프라이닝 기술을 위해서 고려해야 할 다양한 사항들이 생겨났다.

- Sequence Number 범위의 증가 : 여러 패킷을 보내야 하므로 0과 1로는 부족함

- 버퍼 필요 : 송/수신측에서 모두 각각 여러 패킷을 담을 수 있는 버퍼가 필요함

- 파이프라이닝에서의 오류 회복 방법 : 파이프라이닝 시스템에서 패킷 손실 및 지연 패킷에 대한 처리 방식이 필요

따라서 해당 방법을 처리하기 위해 Go-Back-N 방식과 Selective Repeat 방식을 이용하여 패킷 손실 및 지연 패킷에 대한 처리를 진행하게 된다.

원본 기사

https://www.boannews.com/media/view.asp?idx=97456 

"기업 10곳 당 1곳에는 오래되어 취약한 프로토콜을 사용하는 장비가 존재한다. 공격자들을 위한 침투 경로가 지천에 널려 있다는 것이다." 기사 中

기사에서는 SMB 프로토콜에 대해 상세히 설명하면서 해당 프로토콜을 사용하는 기업들이 많다고 언급하고 있다. 하지만 실제로 기업에서는 해당 프로토콜 이외에도 다양한 오래된 프로토콜들이 존재한다. 단적인 예로, 필자도 경험한 사례가 있었는데, 내부망이긴 하지만 윈도우XP를 사용하는 PC도 다수 존재했고, 대부분의 PC들이 서비스가 종료된 윈도우 7을 사용했다. 이는 기사에서도 언급하고 잇는데, 많은 조직들이 몇년간 취약한 프로토콜들을 제거하려고 노력해 왔지만, 내부망에서의 프로토콜들에는 상당히 무감각하다고 언급하고 있다.

또한 기사에서는 고급 해커들의 기술들에 대해서도 언급하고 있다. 그들은 누구도 다룰 수 없는 최신식 기술을 사용하는 것이 아니라, 조직 내에서 취약한 부분을 잘 찾아내기 때문이라고 하고 있는데, 워너크라이 랜섬웨어 사태에서만 봐도, 오래된 프로토콜인 SMB에서 발생했는데, 지금도 여전히 SMB는 널리 사용되고 있다.

기업 내부에서는 이보다 더 많은 프로토콜이 사용되고 있을 것이다. 그리고 그중에는 이미 취약점이 충분히 발견되었으나, 기업의 사정에 의해 업그레이드 할 수 없는 프로토콜들도 존재할 것이다. 이러한 프로토콜이 존재할 수 있다. 하지만 이를 아는 것과 모르는 것은 천지차이이다. 기업 내부에서 어떤 프로토콜이 실행되고 있는지 파악하고, 가시성을 확보하여 위험에 대비하는 것이 급선무인 것이다.

실제로 기사에서도 해당 내용을 언급하고 있다. 기업 내부에서 어떤 프로토콜이 실행되고 있는지 모르는 경우가 대다수였고, 이를 은둔의 IT라고 부르기도 했다. 오래된 프로토콜 역시 같은 맥락이라고 볼 수 있다.

기업 내부의 프로그램이 파악된다면, 파악된 정보들을 토대로 회사 내에서 꼭 필요한 프로토콜이 아닌 이상 업그레이드하거나, 프로토콜을 사용하지 않는 등의 조치가 필요하다. 하지만 회사 내에서 꼭 필요한 경우, 다른 프로토콜로 교체를 검토하거나, 보안 대책을 추가로 세우는 등의 방법을 통해 위험을 감소시킬 수도 있고, 온프레미스가 아닌 클라우드 환경을 사용하는 등 위험 전가 대책을 세울 수도 있다. 하지만 모든 위험 대책의 첫번째는 자원의 파악이다. 현재 어떤 식으로 기업의 IT 환경이 돌아가고 있는지 파악하는 것이 우선시 되어야 할 것이다.

원본기사

www.boannews.com/media/view.asp?idx=97149

"우리 사회 전반에서 디지털화가 가속화되고 있다. 종이나 카드 같은 실물로 가능하던 일들이 이제는 스마트폰을 통해 이뤄지고 있다." (본문 中)

기사에서 말한 것과 같이, 디지털 뉴딜 정책의 일환으로 진행되는 '디지털 신분증' 구축사업도 이와 같은 맥락이다. 실물 실분증의 분실, 위/변조 및 도용 문제 등 고질적인 문제점을 해결하고, 온/오프라인을 아우르는 신원증명 수단의 필요성에 따라 이를 추진했다. 실제로 최근 모바일 공무원증을 필두로 각종 모바일 신분증들이 운영을 시작하고 있다.

정부가 지원하고 있는 디지털 신분증 사업은 정부가 발급하여 공신력을 부여하고, 블록체인을 기반으로 하는 DID 기술을 적용하여 디지털 신분증 사용 및 검증을 수행하고 있다. 탈중앙화를 통하여 신원을 증명하고, 해당 신원증명 정보를 블록체인에 공유하여 사용 및 검증에 있어서 타인이나 기관이 개입할 수 없도록 하고 있다.

DID 기술이란 분산 ID 신뢰 저장소를 통하여 운영되는 ID 서비스를 의미하는데, 기존 기관의 자체 데이터베이스, 또는 OAuth를 이용하여 타 인터넷 서비스 기업들의 데이터베이스를 사용하여 ID 서비스를 제공했다면, 이제는 블록체인을 통하여 신뢰 저장소를 구축, ID서비스를 제공하는 기술을 의미한다. 블록체인의 특성을 통하여 개인의 데이터 주권을 실현하고, 위/변조를 검증할 수 있다는 점을 이용하여 ID 서비스로의 활용성을 더욱 높이고 있다.

신기술의 도입은 양날의 검이다. 신기술의 발전에 따라 더 편한 서비스를 제공할 수도 있지만, 어떤 문제점이 발생할지는 아무도 모르는 것이다. 하지만 반대쪽 날을 잘 다스릴 수만 있다면, 검 없이 싸우는 것보다는 나을 것이다. 또다른 문제로, 양날의 검을 다스리기 위해 날을 모두 없애 버린다면 그 검을 사용하는 의미 또한 없어질 것이다.

신기술을 통해 지속적으로 개인정보 서비스도 발전해가고 있는데, 적절한 규제를 통해 안전한 서비스를 제공해야 하겠지만, 너무 과도한 제재로 인해 기술의 의미가 없어지는 것도 좋지 않은 상황일 것이다. 그 적절한 균형을 맞추는 것이 중요하다.

원본 기사

www.boannews.com/media/view.asp?idx=97016&skind=D

어도비에서 "원스톱 어노말리 숍(One-Stop Anomaly Shop)", 줄여서 OSAS라는 오픈소수 도구를 개발하여 공개하였다. 해당 도구는 머신러닝을 기반으로 하고 있고, 데이터 셋에서 이상한 점을 발견하게 해 주는 기능을 갖고 있다. 데이터 유형별 레이블을 생성함으로써, 로그 데이터에 새로운 구조를 추가해 주는 머신러닝 도구라고 볼 수 있다.

OSAS를 사용할 경우, 특정 데이터 셋에서 어떤 변수, 또는 변수의 조합이 가장 좋은 결과를 가져다 줄 지 빠르게 알 수 있다고 기사에서 설명하고 있다. 컴퓨터 연산에서 이상 현상을 잡아내는 것과 데이터 셋의 맥락에서 이상한 이유를 밝혀내고 설명하는 것은 또 다른 의미이기 때문에, 후자의 부분에서 OSAS가 유용하게 사용될 수 있다고 설명하고 있다.

OSAS는 ELK Stack을 기반으로 만들어져 있으며, 도커 이미지를 통해 배포되고 있다. 또한 머신러닝 부분은 파이썬으로 작성되어 있다. 배포 가이드는 공식 깃허브를 통해 확인할 수 있다.(https://github.com/adobe/OSAS)

어도비 외에도 다양한 소프트웨어 개발 업체들이 머신런이 관련 도구들을 무료로 풀어나가고 있다. 이번달 초에도 마이크로소프트에서 MITRE의 ATT&CK 프레임워크를 이용하여 자사의 공격 트래픽 데이터를 결합한 머신 러닝 모델을 공개한 적이 있었는데, 이처럼 거대한 기업에서 오픈 소스 생태계에 기여하는 것은 좋은 영향력을 행사할 수 있을 것으로 보인다.

보안에서 오픈소스란 양날의 검이다. 오픈 소스 생태계를 통해 여러가지 좋은 보안 솔루션 또는 소프트웨어들을 무료로 사용할 수 있어 비용적인 측면에서 긍정적이지만, 소스가 공개되어 있는 만큼, 공격자들의 화이트박스 테스트를 통한 공격이 가능하기 때문이다. 과거에는 이러한 문제 때문에 오픈소스 기여를 잘 안하는 경우가 많았지만, 최근 보안 생태계에서도 ELK, Snort 등을 기반으로 한 오픈소스 도구들이 늘어가는 추세이다.

이러한 오픈소스 도구들이 늘어나면서, 단순히 오픈소스를 그 자체로 사용하는 것이 아니라, 여타 프로그램에 응용해서 사용하는 경우도 많이 있었는데, 최근 보안 시스템 구축 실습 과제를 진행하면서 사용했던 Wazuh도 그 중 하나이다. 해당 프로그램 역시 ELK Stack을 기반으로 운영되고 있으며, Kibana App 형태로 서버를 운영할 수 있도록 구축되어 있다.

보안도 점차 오픈소스 생태계에 적응해 나가는 만큼, 오픈소스에 대한 투자와 지원도 이루어져야 할 것이다. 단순히 사용하는 것만 아니라, 꾸준한 기여를 통해 오픈소스 생태계에서의 한 가닥으로 나아가는 것은 어떨까.

소프트웨어 개발을 위한 여러 디자인 패턴들 중, 웹 서비스에 자주 사용되는 패턴으로 MVC 디자인 패턴이 있다. Spring MVC, Django 등에서 활용되고 있는 패턴이다.

MVC란 Model, View, Controller의 앞글자를 따서 MVC 패턴이라고 부르며, 애플리케이션을 세 가지의 역할로 구분하는 개발 방법론이다. 그림처럼, 사용자는 Controller만 조작하고, Controller는 Model을 통하여 데이터를 가져오게 되며, 그 정보를 바탕으로 시각적인 표현을 담당하는 View를 통해 사용자에게 전달하게 된다.

간단히 말해서, 사용자는 Controller를 통해 입력하고, View를 통해 출력을 받는다고 볼 수 있다. 일종의 추상화 개념이라고 볼 수 있다. 위의 그림의 경우, Controller와 View의 연관 관계는 표현되어 있지 않는데, 실제로는 Controller에서 View에도 영향을 줄 수 있고, Model이 Controller에도 정보를 전달할 수 있다..

각각의 구성 요소들은 각자의 역할을 수행해야 하며, 각각의 구성 요소가 다른 요소들에게 영향을 미치지 않고 각자의 역할에 충실해야 한다는 것이 MVC 패턴의 핵심이다.

Controller는 Model에 명령을 보냄으로써 Model의 상태를 변경할 수 있어야 한다(Manipulate). 또한, Controller는 관련된 View에도 명령을 보냄으로써, Model의 표시 방법을 바꿀 수 있어야 한다. 

Model은 Model의 상태에 변화가 있을 때, Controller와 View에 해당 내용을 전달한다. 이와 같은 행위를 통해, View는 최신의 결과를 보여주고, Controller는 Model의 변화에 따라 명령을 추가하거나, 제거하거나, 수정할 수도 있다. 특정 MVC 구현에서는 Model에서 전달하는 것이 아니라, View나 Controller가 직접 Model의 상태를 읽어 오는 경우도 있다.

View는 사용자가 볼 결과물을 생성하기 위해 Model로부터 정보를 얻어 온다.

Django에서는 Model, View, Controller를 각각 Model, Template, View로 사용하고 있다.

일반적으로 Model의 경우 클래스 형태로 표현되며, 이 클래스는 하나의 데이터베이스 테이블이라고 볼 수 있다. Django의 경우 ORM(Object Relational Mapping)이라는 데이터베이스 기능을 지원하기 때문에, 파이썬 코드를 통해서 DB Handling이 가능하다.

Template의 경우 HTML 형태로 구현되며, View에게 받은 데이터를 동적으로 적용한다. 이때 Django의 경우, 자체적인 Django Template 문법을 지원하며, 이 문법을 통해 동적으로 적용이 가능하다.

View의 경우, MVC 패턴에서의 컨트롤러에 대응된다. 요청에 따라, 적절한 로직을 수행하고, 결과를 Template에게 전달하는 역할을 한다.

참고자료

• 생활코딩 MVC 디자인 패턴(opentutorials.org/course/697/3828)
• 위키백과 모델-뷰-컨트롤러(ko.wikipedia.org/wiki/%EB%AA%A8%EB%8D%B8-%EB%B7%B0-%EC%BB%A8%ED%8A%B8%EB%A1%A4%EB%9F%AC)
• Django 공식 문서(docs.djangoproject.com/ko/3.2/)