테크커런트

🎯 개발자라면 꼭 알아야 할 디자인 패턴! MVC란?

**MVC(Model-View-Controller)**는 소프트웨어 개발에서 **관심사의 분리(Separation of Concerns)**를 구현하는 대표적인 디자인 패턴입니다.

• 비즈니스 로직과 화면, 입력 제어를 독립적으로 구성할 수 있어 유지보수성이 매우 뛰어납니다.

📌 MVC 구성 요소

🔹 Model (모델)

• 앱이 다뤄야 할 데이터와 비즈니스 로직을 담당합니다.
• 데이터가 변경되면 일반적으로 뷰(View)와 컨트롤러(Controller)에 알려줍니다.
• ✅ 예: 품목 이름, 가격, 수량 등 쇼핑 리스트의 항목 데이터

🔹 View (뷰)

• 사용자에게 보여지는 UI를 담당합니다.
• 데이터를 직접 처리하지 않고, 모델에서 전달받은 데이터만 표시합니다.
• ✅ 예: 쇼핑 항목 리스트를 표 형태로 보여주는 HTML 화면

🔹 Controller (컨트롤러)

• 사용자의 **입력(클릭, 요청 등)**을 받아,
  적절한 모델을 호출하고 뷰를 갱신하는 역할을 합니다.
• ✅ 예: "장바구니에 담기" 버튼 클릭 → 컨트롤러가 해당 품목을 모델에 추가하고, 뷰를 새로고침

🛒 MVC 예제 - 쇼핑 리스트 앱

쇼핑리스트 앱을 예로 들면 다음과 같이 MVC로 나눌 수 있어요.

✅ MVC 패턴의 장점

• 🔧 유지보수가 쉬움: 각 구성 요소가 독립적이라 변경이 용이
• 🧩 협업에 유리: 역할 분리가 명확해 프론트/백엔드 개발자 협업에 이상적
• 🚀 재사용성과 확장성 증가

MVC패턴, 디자인패턴, 모델뷰컨트롤러, Model View Controller, 백엔드기초, 소프트웨어아키텍처, 쇼핑리스트예제, Java MVC, Spring MVC, 웹개발패턴

인터넷 주소에 대해 공부하다 보면 꼭 마주치는 개념이 있죠. 바로 URI와 URL입니다. 두 개념은 비슷하면서도 엄연히 다릅니다. 이번 글에서는 이 둘의 차이를 명확하게 정리해드립니다.

🔍 URI란?

• URI (Uniform Resource Identifier) 는 말 그대로 ‘통합 자원 식별자’입니다.
• 인터넷상의 특정 리소스(자원)를 식별할 수 있는 문자열을 뜻합니다.
• 예) https://www.example.com/news/123 → 이 전체가 URI

🌐 URL이란?

• URL (Uniform Resource Locator) 은 우리가 흔히 말하는 웹 주소입니다.
• URL은 리소스의 ‘위치’를 알려주는 방식입니다.
• 즉, URI의 서브셋(하위 개념)입니다.

✅ URL과 URI의 차이 정리

✨ 쉽게 말하면?

• 모든 URL은 URI입니다.
• 하지만 모든 URI가 URL은 아닙니다.
• URI = 식별, URL = 위치 라고 기억하세요!

📌 마무리

웹 개발, 백엔드, API 작업 시 이 개념을 잘 알고 있으면 요청 경로 설계 시 큰 도움이 됩니다.
이제 URI와 URL 구분, 더 이상 헷갈리지 않겠죠?

✔️ 싱글톤이란?

싱글톤(Singleton) 패턴은 클래스의 인스턴스를 단 하나만 생성하도록 보장하는 디자인 패턴입니다.
객체가 계속해서 생성되는 것처럼 보여도, 실제로는 최초에 생성된 하나의 인스턴스만을 반환합니다.

💡 싱글톤 구현 예제 (Lazy Initialization 방식)

public class Singletone {

    private static Singletone singletone;

    // 생성자를 private으로 막아 외부에서 new로 생성 불가
    private Singletone() {}

    public static Singletone getInstance() {
        if (singletone == null) {
            singletone = new Singletone();
        }
        return singletone;
    }
}

📌 핵심 포인트:

• private static 으로 클래스 내부에 단 하나의 인스턴스를 보관
• 외부에서 new Singletone() 호출 불가능 (생성자 private)
• getInstance() 메서드를 통해서만 인스턴스에 접근 가능
• 필요할 때만 초기화하는 지연 초기화(Lazy Initialization) 방식 사용

⚠️ 싱글톤 패턴 사용 시 주의사항

1. 객체를 2개 이상 생성하지 않도록 철저히 차단해야 함
   • 생성자를 private으로 감춰야 함
2. 상태를 유지하지 않는 Stateless 설계가 중요
   • 필드를 통해 상태를 가지면 여러 사용자 간 충돌 위험
   • 예: 웹 애플리케이션에서 사용자별 데이터를 필드로 저장하면 큰일 남 😱
3. Spring을 사용한다면 걱정할 필요 없음
   • 기본적으로 모든 Bean은 싱글톤 범위로 관리됨
   • @Component, @Service, @Repository 등 사용 시 자동 적용
4. 공유되지 않는 데이터는 지역 변수 또는 ThreadLocal 사용
   • 예: 사용자 요청에 따른 데이터를 처리할 때는 필드 대신 메서드 파라미터 사용

🧠 결론

• 싱글톤은 자원을 절약하고, 전역적으로 동일한 인스턴스를 공유할 수 있어 유용합니다.
• 그러나 잘못 사용할 경우 상태 공유로 인한 오류 발생 가능성이 있으므로, Stateless 설계를 철저히 해야 합니다.
• Spring에서는 기본이 싱글톤이지만, 상태 관리만 잘 하면 안전하게 사용 가능!

📌 목차

1. 프로그램이란?
2. 프로세스란?
3. 스레드란?
4. 자바 스레드의 개념
5. 스레드 사용 시 주의사항

1. 프로그램 (Program)

• 사전적 의미: 어떤 작업을 위해 실행 가능한 파일
• .exe, .jar, .py 등 사용자가 실행시킬 수 있는 상태
• 아직 메모리에 올라가지 않은 정적인 상태

2. 프로세스 (Process)

메모리에 적재되어 실행되고 있는 프로그램의 인스턴스

✅ 정의

• 운영체제로부터 CPU 시간, 메모리 등 시스템 자원을 할당받은 실행 단위
• 하나의 독립된 개체로서 **자신만의 주소 공간과 메모리 구조(Code/Data/Stack/Heap)**를 가짐

✅ 주요 특징

• 프로세스는 독립된 주소 공간을 사용
• 기본적으로 프로세스마다 1개 이상의 스레드 포함
• 다른 프로세스와 자원 공유 ❌ (단, IPC(Inter-Process Communication) 이용 가능)

🧱 프로세스 메모리 구조
┌────────┐
│  Code  │ ← 실행 코드
│  Data  │ ← 정적 변수
│  Heap  │ ← 동적 할당 객체
│  Stack │ ← 함수 호출/지역변수 (스레드별)
└────────┘

3. 스레드 (Thread)

프로세스 내부에서 실행되는 흐름의 최소 단위

✅ 정의

• 하나의 프로세스 내에서 여러 작업을 동시에 처리할 수 있는 실행 흐름
• 프로세스의 **자원(Code/Data/Heap)**을 공유하지만,
  스택(Stack)과 레지스터는 스레드별로 독립적

✅ 주요 특징

• 스레드는 **경량 프로세스(Lightweight Process)**라고 불림
• 같은 프로세스 내 스레드 간에는 메모리 공유 → 속도 빠름, 통신 쉬움
• 메모리 공유로 인한 경합 조건(race condition) 발생 가능성 있음

📌 스레드는 같은 Heap 공유
⟶ 스택은 독립, 힙은 공유

4. 자바 스레드 (Java Thread)

✅ 자바 스레드 개요

• JVM이 운영체제처럼 스레드를 관리
• 자바는 프로세스 개념 없음, 오직 스레드만 있음
• JVM 내부에서 스레드는 다음을 관리:
  • 총 스레드 수
  • 각 스레드의 메모리 주소
  • 스레드 상태 (NEW, RUNNABLE, BLOCKED 등)
  • 우선순위

✅ 자바 스레드의 실행 흐름 예시

public class MyThread extends Thread {
    public void run() {
        System.out.println("스레드 실행 중!");
    }
}

public class Main {
    public static void main(String[] args) {
        MyThread t = new MyThread();
        t.start(); // JVM에 실행 요청
    }
}

5. 스레드 사용 시 주의사항

⚠️ 동기화 문제(Synchronization)

• 멀티 스레드 환경에서는 같은 자원에 동시 접근하면 충돌 가능
• 이를 방지하기 위해 동기화(synchronized) 키워드 사용
• 예시:

synchronized void increaseCounter() {
    counter++;
}

✍️ 서론 개요 (도입부)

웹 시스템을 처음 배우는 사람부터 실무자까지 혼동하기 쉬운 개념이 바로 웹 서버(Web Server) 와 **WAS(Web Application Server)**입니다.
두 용어는 유사하게 들리지만, 역할과 목적은 분명히 다릅니다.

이 글에서는:

• 웹 서버의 정의와 역할
• WAS의 구조 및 동작 과정
• 웹 서비스 아키텍처 흐름
• 왜 Web Server와 WAS를 분리해서 써야 하는지

를 실제 흐름도와 함께 명확하게 정리합니다.

📌 핵심 내용 정리

✅ 웹 서버(Web Server)

• HTTP 요청을 받아 HTML, CSS, JS, 이미지 등의 정적 콘텐츠를 즉시 제공
• 동적 요청은 WAS로 전달하고 결과를 중계
• 대표 소프트웨어: Apache, Nginx

✅ WAS (Web Application Server)

• Servlet, JSP 등의 동적 콘텐츠를 처리하는 미들웨어
• DB 연동, 비즈니스 로직 처리 등 핵심 로직 담당
• 대표 소프트웨어: Tomcat, WebLogic, JBoss

✅ 웹 서비스 아키텍처 구조

✅ 클라이언트 요청의 실제 처리 흐름

1. 클라이언트가 HTTP 요청을 보냄
2. Web Server가 정적 콘텐츠는 즉시 응답,
   동적 요청은 WAS로 전달
3. WAS는 Servlet 생성 → Thread 실행
4. 요청에 따라 doGet() 또는 doPost() 실행
5. 결과 페이지를 Web Server → 클라이언트로 반환

✅ 왜 Web Server와 WAS를 분리해야 할까?

• WAS가 정적 요청까지 처리하면 자원 낭비
• 비즈니스 로직이 느려지고 전체 서비스 지연 발생
• 정적 콘텐츠는 Web Server가 처리 → 부하 분산 & 속도 개선

● 클린코드로 유명한 로버트 마틴의 좋은 객체 지항 설계의 5가지 원칙

 - SRP : 단일 책임 원칙(Single Reponsibility Principle)

 - OCP : 개방-폐쇄 원칙(Open/Closed Priciple)

 - LSP : 리스코프 치환 원칙(Liskvo subsititution Principle)

 - ISP : 인터페이스 분리 원칙(Interface Segregation Principle)

 - DIP : 의존관계 역전 원칙(Dependency Inversion Principle)

 ● SRP 단일 책임 원칙

 - 한 클래스는 하나의 책임만 져야 한다.

 -  하나의 책임이라는 것은 모호하다.(문맥과 상황에 따라 다르다.)

 -  중요한 기준은 변경이다. 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 따라야한다.

●  OCP 개방-폐쇄 원칙

 - 확장에는 열려 있어야 하나 변경에는 닫혀 있어야 한다.

 - 다형성을 활용하여 가능하다.

 - 인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능을 구현해야 한다.

●  LSP 리스코프 치환 원칙

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

 - 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야한다는 것, 다형성을 지원하기 위한 원칙, 인터페이스를 구현한 구현체를 믿고 사용하려면, 이 원칙이 필요하다.

(ex. 자동차의 엑셀은 앞으로 가는 기능이지만 뒤로가게 구현하면 LSP 위반이다.)

● ISP 인터페이스 분리 원칙

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

(ex. 자동차인터페이스 -> 운전 인터페이스, 정비 인터페이스)

(ex. 사용자 클라이언트 -> 운전자 인터페이스, 정비사 인터페이스)

- 인터페이스가 명확해 지고, 대체 가능성이 높아진다.

●  DIP 의존관계 역전 원칙

 - 프로그래머는 "추상화에 의존 해야한다. 구체화에 의존하면 안된다." 의존성 주입은 이 원칙을 따르는 방법 중 하나이다.

 - 즉, 인터페이스에 의존 하라는 것이다.

 - 구현체에 의존하게 되면 변경이 힘들어진다.

정리

 - 객체 지향의 핵심은 다형성

 - 다형성 만으로는 쉽게 부품을 갈아 끼울듯 개발할 수가 없다.

 - 다형성 만으로 구현 객체를 변경 할 때 클라이언트 코드도 함께 변경된다.

- 다형성 만으로 OCP, DIP를 지킬 수 없다.

🧭 목차

1. 자바(Java)란?
2. 자바의 주요 특징
3. 자바의 객체지향 4대 특성

1. 자바(Java)란?

자바(Java)는 1995년, **썬 마이크로시스템즈(Sun Microsystems)**의 **제임스 고슬링(James Gosling)**을 비롯한 연구진들이 개발한 객체 지향 프로그래밍 언어입니다.

원래는 가전제품의 내장 소프트웨어를 위해 개발되었지만,
지금은 웹 애플리케이션, 모바일 앱(Android), 데스크톱 앱 등
다양한 분야에서 가장 널리 사용되는 언어 중 하나입니다.

2. 자바의 특징

● 객체 지향 언어 (Object-Oriented)

• 절차 지향과 달리 기능 단위를 **객체(Object)**로 구성
• 객체 간 협력으로 프로그램 동작
• 유지보수 및 재사용에 유리

● 인터프리터 + 컴파일 언어

• .java → 컴파일 → .class(바이트 코드) → JVM에서 실행
• 실행 시 인터프리트 방식으로 동작

● 플랫폼 독립성

• 한번 작성하면 어떤 OS에서도 실행 가능
• 이유: **JVM(Java Virtual Machine)**이 각 OS에 맞게 동작

● 자동 메모리 관리 (Garbage Collection)

• 개발자가 직접 메모리 해제할 필요 없음
• 불필요한 객체는 GC가 자동 정리

● 멀티 쓰레딩 지원

• 여러 작업을 동시에 처리 가능
• 운영체제마다 쓰레드 API가 달라도, 자바는 자바 API로 일관성 유지

● 동적 바인딩

• 필요한 객체만 생성
• 런타임에 동적으로 클래스 및 메소드 결정

3. 자바의 객체지향 4대 특성

🔒 캡슐화 (Encapsulation)

• 관련 데이터와 메소드를 클래스로 묶음
• 외부 접근 제한 (정보 은닉)

👪 상속 (Inheritance)

• 기존 클래스(부모)의 기능을 재사용
• 자식 클래스는 extends 키워드로 상속
• 모든 클래스는 Object 클래스 상속
• 자바는 단일 상속만 허용
• Is a: 상속 관계 (예: Student is a Person)
• Has a: 포함 관계 (예: Car has a Tire)

📦 추상화 (Abstraction)

• 공통된 속성과 기능만 추출
• 복잡한 구현은 감추고, 필요한 인터페이스만 공개
• 추상 클래스 또는 인터페이스로 구현

🔄 다형성 (Polymorphism)

• 하나의 인터페이스로 다양한 구현
• 대표적인 두 가지 형태:

▪ 오버라이딩 (Overriding)

• 부모 메소드를 재정의
• @Override 어노테이션 사용
• 조건: 이름, 매개변수, 리턴타입 동일

▪ 오버로딩 (Overloading)

• 같은 이름의 메소드를 여러 버전으로 정의
• 조건: 매개변수의 수나 타입이 달라야 함

✅ 마무리

자바는 배우기 쉬우면서도, 실무에서 가장 강력한 도구 중 하나입니다.
웹 백엔드, 안드로이드 앱, 클라우드 서비스 등 어디서나 만나볼 수 있죠.
객체지향의 강력한 특성과 다양한 기능들 덕분에 오늘날도 여전히 인기 있는 언어입니다.

💡 다음 포스팅 예고

✅ JVM, JDK, JRE 차이 완전 정리

프론트엔드 개발을 하다 보면 반드시 마주치는 두 가지 렌더링 방식, 바로 CSR(Client Side Rendering) 과 **SSR(Server Side Rendering)**입니다.
각 방식은 성능, 사용자 경험, SEO 대응에 있어서 확연한 차이를 보입니다. 이 글에서는 CSR과 SSR의 특징과 차이점을 명확하게 정리해 드립니다.

✅ CSR (Client Side Rendering) 이란?

• 클라이언트에서 렌더링을 수행
• 서버는 HTML 틀과 JavaScript만 내려주고,
  브라우저가 JS를 실행하여 실제 콘텐츠를 렌더링
• 사용자 입장에서는 JS가 모두 실행되기 전까지 아무것도 보이지 않음

📌 특징 요약

• 서버는 HTML+JS 전달만 하고, 렌더링은 브라우저가 수행
• 첫 화면 진입 시 빈 화면이 잠깐 보일 수 있음
• **SPA(Single Page Application)**에 적합

✅ SSR (Server Side Rendering) 이란?

• 서버에서 HTML을 렌더링 완료된 상태로 전달
• 사용자는 JS가 실행되기 전에도 일부 내용을 볼 수 있음
• 검색 엔진이나 초기 로딩 속도에서 유리

📌 특징 요약

• 서버가 완성된 HTML을 내려주기 때문에 초기 콘텐츠 노출이 빠름
• JS 로딩은 이후에 수행되므로 사용자는 빠르게 피드백을 받음
• SEO에 더 친화적

🔍 CSR vs SSR 비교

🧠 요약 포인트

• 🔹 빠른 첫 화면이 중요하면 SSR
• 🔹 페이지 전환 속도가 중요하면 CSR
• 🔹 SEO에 민감한 페이지는 SSR 우위
• 🔹 서버 부하를 줄이고 싶다면 CSR 적합