SQL 은 무엇일까요?

SQL, Structured Query Language 는 관계형 데이터베이스를 조작하기 위한 언어입니다. 사용자가 원하는 데이터를 정확하게 조회하거나 삽입하고, 효율적인 쿼리를 통해 시스템의 성능을 관리하는 데 핵심적인 역할을 합니다.

String sql = "INSERT INTO user (username, email) VALUES (?, ?)";
jdbcTemplate.update(sql, "name", "email");

ORM 은 무엇일까요?

ORM, Object Relational Mapping 은 객체지향 프로그래밍 언어의 객체와 관계형 데이터베이스의 테이블을 자동으로 매핑해주는 도구 입니다. 예시로는 Java 의 JPA, Hibernate, Python 의 SQLAlchemy 등이 있습니다.

userRepository.save(new User("name", "email"));

아래의 예제 코드만 보면 ORM 을 사용하는 것이 훨씬 간편하고 직관적으로 보입니다. 이뿐만 아니라 ORM 을 사용하면 여러가지 추가적인 장점이 존재합니다.

• 객체 조작만으로 데이터베이스 연동이 가능 → 반복적으로 SQL 을 작성할 필요가 없음
• 테이블 변경 시 도메인 모델만 변경하면 됨 → 일관성 유지 가능
• SQL Injection 등 보안 이슈 예방 가능 (바인딩 처리)

ORM 은 위와 같이 다양한 장점을 가지고 있으며, 개발 속도와 코드 가독성을 높여주는 강력한 도구 입니다.

이렇게 보면 ORM 은 SQL 을 대신할 수 있는 완벽한 대체 수단으로 보입니다. 하지만 사실은 그렇지 않습니다. 이제 ORM 의 한계와 단점을 알아보겠습니다.

ORM 의 한계와 단점

• 연관 객체 조회 시 반복 쿼리 발생 → 성능 저하
• 다중 조인, 서브쿼리 등은 ORM 으로 표현하기 어려움
• 어떤 SQL 이 실행되었는지 명확하지 않아서 쿼리 추적이 어려움 → 디버깅 난이도 상승

또한 실무에서도 대규모 데이터를 다루는 프로젝트에서는 ORM 의 추상화가 오히려 걸림돌이 됩니다. 실제로 많은 기업들이 대량 조회에는 ORM 을 사용하지 않습니다.

결론적으로

백엔드 개발자는 ORM 뿐만 아니라 SQL 에 관한 충분한 사용 경험과 이해도 필요합니다.

• 데이터 조회 최적화: 특정 조건에 맞는 데이터만 빠르게 추출해야 할 때
• 대량 삽입/ 갱신 처리: 트랜잭션 처리와 배치 작업에 유리 ☞ 트랜잭션: DBMS 에서 데이터를 다루는 논리적인 작업의 단위 ☞ 트랜잭션 처리: 트랜잭션 각 단위가 원자성, 일관성, 고립성, 지속성의 성질을 유지할 수 있도록 처리하는 것 ☞ 배치 작업: 사용자 개입 없이, 정해진 시간이나 조건에 따라 반복적으로 실행되는 일괄 처리 작업
• 다중 조인, 서브쿼리 등을 통해 복잡한 처리 가능

결국 ORM 도 SQL 을 기반으로 만들어진 것이기때문에ORM을 제대로 이해하고 사용하기 위해서는 SQL 에 대한 선행 학습이 우선되어야합니다.

결론적으로 SQL 은 단순한 기술이 아니라 백엔드 시스템을 이해하고 제어하기 위한 중요한 기본 지식입니다.

이제 5가지 원칙에 대해서 그 원칙이 무엇이고, 어떻게 지켜야하고, 위반한, 잘 지킨 예시는 어떤것이 있는지 하나하나 알아보겠습니다.

원칙1 'S'

SRP - Single Responsibility Principle 단일 책임 원칙: 클래스는 하나의 책임 만 가져야 하며, 변경 이유도 하나여야 한다.

이 말은 한 클래스가 여러 이유로 변경되지 않도록 해야한다는 의미입니다.

예를 들어서

@Service
public class UserService {
    public void register(User user) {
        validateUser(user);   // 1. 유효성 검증
        userRepository.save(user); // 2. 사용자 저장
        mailService.sendWelcomeMail(user.getEmail()); // 3. 이메일 발송
    }
}

이 코드에서는 UserService 가 바뀌는 이유가 유효성 검사 검증 기준이 변경되거나, 사용자 저장 방식이 바뀌거나 등등 다양합니다. → 따라서 이 클래스는 SRP, 단일 책임 원칙을 지키고 있지 않습니다.

그러므로 코드를 아래와 같이 개선할 수 있습니다.

@Service
public class UserService {
    private final UserValidator validator;
    private final MailService mailService;

    public void register(User user) {
        validator.validate(user);
        userRepository.save(user);
        mailService.sendWelcomeMail(user.getEmail());
    }
}

• UserValidator : 유효성 검사 책임
• UserRepository : 데이터 저장 책임
• MailService : 이메일 발송 책임

→ 각각은 하나의 이유로만 변경됨 → SRP 준수

원칙2 'O'

OCP - Open Closed Principle 개방 폐쇄 원칙: 소프트웨어 요소는 확장에는 열려 있고, 수정에는 닫혀 있어야 한다.

예시와 함께 OCP 에 대해서 더 알아보겠습니다.

public class DiscountService {
    public int getDiscountPrice(String grade, int price) {
        if ("NORMAL".equals(grade)) {
            return price - 1000;
        } else if ("VIP".equals(grade)) {
            return price - 3000;
        } else {
            return price;
        }
    }
}

이런 코드라면 새로운 할인 정책이 추가될 때마다 if-else문 을 추가하는 번거로움을 겪게 됩니다. 확장에는 열려 있고 수정에는 닫혀 있어야 하는 OCP 를 위반하게 된 것이죠.

따라서 아래와 같이 코드를 개선할 수 있습니다.

interface PaymentMethod {
    void pay();
}

class CardPayment implements PaymentMethod {
    @Override
    public void pay() {
        // 카드 결제 처리
    }
}

class CashPayment implements PaymentMethod {
    @Override
    public void pay() {
        // 현금 결제 처리
    }
}

class PaymentProcessor {
    void pay(PaymentMethod method) {
        method.pay();
    }
}

• PaymentMethod 라는 인터페이스를 통해 결제 방식 추가가 자유롭습니다.
• 새로운 결제 수단이 생겨도 PaymentProcessor 는 수정할 필요가 없습니다. → OCP 를 만족하는 구조

원칙3 'L'

LSP - Likov Substituition Principle 리스코프 치환 원칙: 하위 클래스는 상위 클래스를 완벽하게 대체할 수 있어야 한다.

이 의미는 부모 클래스 객체를 사용하는 곳에 자식 클래스 객체를 넣어도 동일하게 작동해야 한다는 의미입니다. 자식 클래스가 부모의 규칙을 깨거나 예외를 발생시키면 LSP 가 위반됩니다. 아래의 예시와 함께 더 자세히 알아보겠습니다.

class Bird {
    public void fly() {
        // 날 수 있음
    }

    public void layEgg() { 
        // 알 낳기 
    }
}

class Chicken extends Bird {
    @Override
    public void fly() {
        throw new UnsupportedOperationException("닭은 날 수 없습니다.");
    }
}

• Bird 는 fly() 가 가능한 객체로 설계됨 (부모 클래스의 규칙)
• Chicken 는 Bird 를 상속하지만 fly() 불가능 (= 자식 클래스가 부모 클래스의 규칙을 깸) → Bird 를 사용하는 코드에서 Chicken 를 넣으면 에러 발생 → LSP 위반

따라서 아래와 같이 코드를 개선할 수 있습니다.

interface Bird {
    void layEgg();
}

interface Flyable {
    void fly();
}

class Parrot implements Bird, Flyable {
    public void layEgg() { 
        // 알 낳기 
    }

    public void fly() { 
        // 날기 
    }
}

class Chicken implements Bird {
    public void layEgg() { 
        // 알 낳기 
    }
}

• Bird 는 공통 기능인 layEgg() 만 포함합니다.
• Flyable 은 날 수 있는 새에만 필요한 기능인 fly() 를 분리합니다.
• Chicken 는 둘 다 구현 → 날 수 있는 새
• Chicken 는 Bird 만 구현 → 날 수 없는 새 → LSP 를 만족하는 코드

원칙4 'I'

ISP - Interface Segregation Principle 인터페이스 분리 원칙: 클라이언트는 자신이 사용하지 않는 인터페이스에 의존하지 않아야 한다.

이 원칙은 하나의 거대한 인터페이스보다, 작고 명확한 인터페이스 여러 개로 나누는 것이 좋다는 의미를 포함하고 있습니다.

아래의 예시와 함께 더 자세히 알아보겠습니다.

interface Worker {
    void work();
    void eat();
}

class Robot implements Worker {
    public void work() { }
    public void eat() {
        throw new UnsupportedOperationException("로봇은 밥 안 먹음");
    }
}

• Robot 은 eat() 이 필요 없음
• 하지만 Worker 를 구현하므로 eat() 을 구현해야 함 → ISP 위반

따라서 아래와 같이 코드를 개선할 수 있습니다.

interface Workable {
    void work();
}

interface Eatable {
    void eat();
}

class Human implements Workable, Eatable {
    public void work() { }
    public void eat() { }
}

class Robot implements Workable {
    public void work() { }
}

• 각 기능을 인터페이스로 분리
• 각 클래스는 자신이 필요한 인터페이스만 구현 → ISP 를 만족하는 코드

원칙5 'D'

DIP - Dependency Injection Principle 의존 역전 원칙: 고수준 모듈은 저수준 모듈에 의존하면 안된다. 둘 다 추상화에 의존해야 한다.

DIP 를 위반하면, 고수준 모듈(비즈니스 로직)이 저수준 모듈(구현 클래스)에 직접 의존하게 되고 이러면 변경에 취약해집니다. 따라서 인터페이스(추상화) 를 통해 서로 느슨하게 연결해야 합니다.

아래의 예시와 함께 더 자세히 알아보겠습니다.

class MySQLDatabase {
    public void save(String data) {
        // MySQL에 저장
    }
}

class DataService {
    private MySQLDatabase db = new MySQLDatabase();

    public void save(String data) {
        db.save(data);
    }
}

• DataService (비지니스 로직) 는 MySQLDatabase (구현 클래스) 에 직접 의존
• MySQL에서 다른 DB로 교체하려면 DataService 도 수정해야 함 → DIP 위반

따라서 아래와 같이 코드를 개선할 수 있습니다.

interface Database {
    void save(String data);
}

class MySQLDatabase implements Database {
    public void save(String data) {
        // MySQL에 저장
    }
}

class DataService {
    private final Database db;

    public DataService(Database db) {
        this.db = db;
    }

    public void save(String data) {
        db.save(data);
    }
}

• Database 라는 인터페이스에 의존 → 실제 구현은 외부에서 주입
• MySQL, MongoDB 등 다양한 구현체를 쉽게 교체 가능 → DIP 준수

SOLID 원칙은 꼭 지켜야 하는 것일까?

SOLID 원칙은 객체 지향 설계에 있어서 "필수 규칙" 이 아니라, "권장되는 설계 지침" 입니다. 이 말은 SOLID 원칙을 반드시 따라야 하는 것은 아니라는 의미 입니다.

첫번재 이유 프로젝트 규모가 작거나 단기간에 끝나는 프로젝트라면, SOLID 원칙을 엄격히 적용하면, 과설계가 발생할 수 있습니다.

두번재 이유 모든 원칙을 다 지키려고 하면 코드 구조가 복잡해져서 협업이나 유지보수가 어려워질 수 있습니다.

결론 SOLID 원칙을 모두 적용하려면 많은 시간과 노력이 요구됩니다. 따라서 성능, 유지보수성 등의 우선 순위를 고려하여 이에 따라 필요한 정도로 적당히 원칙을 적용하는 것이 중요합니다.

Explicit, Implicit 그게 뭔데요?

두 단어는 각각 한국말로 Explicit 은 명시적인 Implicit 은 묵시적인 이라는 뜻을 가지고 있습니다.

명시적 : 내용이나 뜻을 분명하게 드러내 보이는 것 묵시적: 직접적으로 말이나 행동으로 드러내지 않고 은연중에 뜻을 나타내 보이는 것

한국말로 했을 때 뜻풀이는 다음과 같습니다.

따라서 Explicit 한 코드 는 내용이나 뜻이 분명하게 드러난 코드, Implicit 한 코드 는 직접적으로 내용이나 뜻을 드러내지 않고, 은연중에 보이는 코드 라고도 할 수 있습니다.

이걸 그냥 말로만 하면 당연히 이해가 어렵겠죠! 아래에서 예시와 함께 알아보겠습니다.

--plicit 하게 코드 작성하기

01 --plicit 한 변수명 작성하기

Explicit 한 변수명 예시

user_age = 25

변수가 어떤 데이터를 담고 있는지 명확하게 알 수 있음

Implicit 한 변수명 예시

x = 25

변수명이 추상적이라 코드를 처음 보는 사람이 이해하기 어려움

02 --plicit 한 함수명 작성하기

Explicit 한 함수명 예시

def calculate_total_price(items):

함수가 어떤 역할을 하는지 함수명만 보고도 유추할 수 있음

Implicit 한 함수명 예시

def handle_data(data):

함수가 정확히 어떤 일을 하는지 이름만으로 알기 어려움

--plicit 한 코드의 장단점

Explicit 한 코드의 장점

• 누구나 코드를 읽고 이해하기 쉬움
• 시간이 지나도 의도를 파악하기 쉬움
• 팀원 간 커뮤니케이션 비용 절감

Explicit 한 코드의 단점

• 코드 길이가 늘어남
• 개발 속도 저하

Implicit 한 코드의 장점

• 짧고 깔금한 코드 작성 가능
• 빠르게 아이디어를 구현할 때 유리함

Implicit 한 코드의 단점

• 다른 사람이 코드를 해석할 때 어려움을 겪음
• 맥락에 대해, 각 변수 또는 함수가 하는 역할을 오해해 잘못된 사용의 발생 가능성
• 팀원 간 오해 발생 가능

팀 프로젝트 -> Explicit 한 코드 혼자 코테 문제를 풀 때/ 숏코딩 -> Implicit 한 코드

웹서버 WAS API서버 RestAPI RestfulAPI

웹 개발을 공부하다보면 자주 마주치는 개념들 입니다. 비슷해보이지만 엄연히 다른 이 개념들을 헷갈리지 않게 각각의 개념부터 비슷한 두 개념을 비교해가며 설명해드리겠습니다.

개념 설명

01 웹서버 (Web Server)

정적인 파일 (HTML, CSS 등 -> 즉시 응답 가능한 컨텐츠) 을 클라이언트에게 전달해주는 서버

• 웹서버는 사용자가 웹사이트에 접속했을 때 필요한 정적 자원을 빠르게 제공
• 단순히 요청을 받고 해당 파일을 찾아 응답하는 구조 -> 처리 속도가 빠름
• 대표적인 웹서버 : Apache HTTP Sever, Nginx
• 주로 프론트엔드 정적 리소스 제공에 사용됨

02 WAS (Web Application Server)

동적인 웹 페이지를 생성하기 위해 로직을 처리하는 서버

• 웹서버 단독으로 처리할 수 없는 데이터베이스 조회나 다양한 로직 처리가 필요한 동적 컨텐츠 제공
• 백엔드 로직이 실행되는 공간
• 주로 데이터베이스 서버와 같이 실행됨
• 대표적인 WAS : Tomcat, WildFly, Jetty
• DB 연동, 세션 처리, 로직 수행 등을 담당

03 API 서버

API (Application Programming Interface) : 소프트웨어 애플리케이션 간에 데이터, 기능, 특징을 교환할 수 있도록 하는 규칙이나 프로토콜

프론트엔드나 외부 시스템에 데이터를 전달하는 백엔드 서버

• 예전에는 서버가 HTML 까지 만들어서 보냈지만, 최근엔 프론트엔드 담당자가 UI 를 만들고 백엔드 담당자가 API 서버를 통해 JSON 형태의 데이터만 제공하는 방식이 일반적 (= 데이터 위주의 응답)

04 RestAPI

REST (Representatial State Transfer) : 자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 모든 것을 의미

REST 아키텍쳐 스타일을 적용한 API

• 자원을 URI 로 표현
• HTTP 메서드를 통해 해당 자원에 대한 행위를 명확히 나타내는 방식

05 RestfulAPI

REST 규칙을 더 엄격하게 준수한 API

• REST 아키텍쳐를 얼마나 잘 따랐는가에 따라 RestAPI 를 Restful 하다고 표현
• URI 설계, 메서드 사용, 상태코드 응답 등을 REST 원칙에 맞게 명획하고 일관되게 구현

개념 비교

01 웹서버 VS WAS

02 WAS VS API 서버

03 API 서버 VS REST API

04 RestAPI VS RestfulAPI

따라서 지금부터 도커 네트워크를 이해하기 위해 꼭 알아야 할 핵심 네트워크 개념들에 대해서 알아보겠습니다.

IP 란?

아이피 (IP, Internet Protocol) 주소는 네트워크 상에서 기기 (컴퓨터, 스마트폰 등) 를 식별하기 위한 주소입니다.
사람에게 집 주소가 있듯, 기기에도 IP 주소가 있어야 서로 통신할 수 있습니다.

포트란?

IP 주소가 어느 기기인지를 알려준다면, 포트 (Port) 는 그 기기 안의 어떤 프로그램인지를 식별하는 번호입니다.
같은 IP 주소를 가진 기기 안에서도 여러 포트 번호를 통해 다양한 서비스를 동시에 실행할 수 있습니다.

• 예시:
  • 80번 포트: HTTP 웹 서버
  • 443번 포트: HTTPS 웹 서버

웹 브라우저는 URL에서 포트 번호를 명시하지 않아도, 사용하는 프로토콜에 따라 기본 포트를 자동으로 사용합니다.

• http:// → 80
• https:// → 443

https://www.youtube.com -> 정상적으로 접속 가능 https://www.youtube.com:443 -> 정상적으로 접속 가능 https://www.youtube.com:80 -> 맞지않는 포트번호로는 접속 불가

공인 IP vs 사설 IP

공인 IP (Public IP)

• 인터넷 상에서 전 세계적으로 유일한 주소
• 인터넷 서비스 제공자 (ISP (Internet Service Provider)) 로부터 할당받음
• 외부에서 접근 가능

사설 IP (Private IP)

• 내부 네트워크 (예: 집, 회사, 학교 등) 에서만 사용되는 IP 주소
• 외부 인터넷에서는 접근 불가

사설 IP 주소 대역

사설 IP는 다음 범위 안에서만 사용합니다:

CIDR(사이더) 표기법이란?

CIDR (Classless Inter-Domain Routing) 은 IP 주소를 표현하고 주소 범위를 나누기 위한 표기법입니다.

형식: IP주소/숫자

예: 192.168.0.0/24 <- 슬래쉬 뒤에 이 숫자가 prefix

CIDR에서 가능한 IP 수는 아래 공식으로 계산할 수 있습니다. (가능한 IP 수) = 2 ^ (32 - (prefix 길이))

192.168.0.0/24 에서 알 수 있는 사실

• 네트워크 주소: 192.168.0
• 사용할 수 있는 호스트 수: 256개 (0~255)
  (실제로는 254개만 사용 가능. 0은 네트워크 식별용, 255는 브로드캐스트용)

라우터 (router)

라우터는 내부 네트워크와 외부 인터넷을 연결해주는 장비입니다.

• ISP로부터 받은 공인 IP를 통해 인터넷에 연결
• 내부 장치에는 각각 사설 IP를 자동 할당
• 외부 통신 시 NAT을 사용해 사설 IP ↔ 공인 IP 변환 처리

네트워크 인터페이스와 포트

• 네트워크 인터페이스 : 컴퓨터나 네트워크 장비가 네트워크에 연결되어 데이터를 주고받기 위한 물리적 또는 가상의 연결 지점
• 포트 : 해당 인터페이스를 통해 들어오는 데이터가 어떤 프로그램으로 전달되어야 하는지 구분하는 번호

인바운드와 아웃바운드

• *인바운드 (Inbound) *: 외부 → 내부로 들어오는 요청 (예: 외부에서 내 서버 접속)
• *아웃바운드 (Outbound) *: 내부 → 외부로 나가는 요청 (예: 내가 인터넷에 접속)

NAT

NAT (Network Address Translation) 는 네트워크 주소 변환 기술입니다. 내부 사설 아이피 주소를 공인 아이피 주소로 변환하거나 그 반대로 바꾸는 기능입니다. 여러 대의 내부 장치가 하나의 공인 아이피를 통해 인터넷과 통신하고, IPv4 의 주소 부족 문제 해결에 도움을 줍니다.

포트 포워딩

포트 포워딩 (Port Forwarding) 은 외부에서 내부 네트워크의 특정 장치 (서버) 로 접근할 수 있도록 포트를 연결해주는 설정입니다.

1. 내 컴퓨터에서 내부 서버가 192.168.0.10:8080 에서 실행 중 이다.
2. 외부 사용자가 공인IP:80 으로 접근
3. 포트 포워딩 설정을 통해 외부 사용자가 공인IP:80 를 통해 192.168.0.10:8080 에 접근할 수 있게 한다.

-> 라우터가 요청을 내부 서버로 포워딩 해주는 구조

DNS 서버란?

DNS (Domain Name System) 는 도메인 이름을 IP 주소로 변환해주는 시스템입니다.

• 사용자는 naver.com 처럼 도메인을 기억하지만, 실제 네트워크 통신은 223.130.200.104 같은 IP 주소로 이루어집니다.
• DNS는 이런 매핑 작업을 처리해줍니다.

도커 네트워크에서도 컨테이너 이름이 곧 도메인 역할을 하며, 내부 DNS 기능을 통해 서로 통신합니다.

지금까지 도커를 잘 이해하기 위해서 네트워크에 대해서 알아봤습니다. 지금부터는 도커의 가상 네트워크에 대해서 알아보겠습니다.

도커를 공부하는 개발자가 반드시 알아야 할 도커 상식

네트워크는 크게 공인망과 사설망으로 나뉩니다.

공인망

: 외부 네트워크를 사용한 통신망

• 외부에서 접근가능한 네트워크

  사설망

  : 내부 네트워크를 사용한 통신망

• 내부에서만 통신이 가능한 네트워크

• 라우터는 내부 서버들에게 사설아이피를 할당합니다.

  라우터

  는 아까 말했듯이 공인 아이피 ↔ 사설 아이피 간의 중계 역할을 합니다.

• 외부에서 들어오는 요청은 공인 아이피를 통해 라우터에 도달하고, 라우터는 이를 내부 서버 (사설아이피) 로 전달합니다. (외부 요청 --공인아이피--> 라우터 -> 내부서버)

• 반대로, 내부 서버에서 외부로 나갈 때도 라우터가 NAT 기능을 통해 사설 아 이피로 변환해줍니다. (내부서버 (사설아이피) --NAT--> 공인아이피)

라우터를 통해 내부 서버들은 사설 IP를 할당받고, 이러한 사설망 내의 서버 위에서 도커가 실행됩니다. 도커는 해당 서버 안에서 자체적으로 가상 네트워크 환경을 구축하여 컨테이너 간의 통신을 관리합니다. 지금부터 도커의 가상 네트워크에서 사용되는 여러가지 용어와 개념들에 대해서 정리하고 알아보겠습니다.

도커 가상 네트워크란?

도커의 가상 네트워크에서는 크게 브릿지 네트워크로 나뉘고 그 안에서 각각의 컨테이너들이 동작합니다.

도커 명령어를 통해 가상의 네트워크 브릿지를 생성할 수 있습니다.

도커 네트워크 관련 명령어

네트워크 리스트 조회 (현재 어떤 브릿지들이 생성되어 있는지)

docker network ls

이렇게 뜨는것이 기본적인 상태 입니다.

네트워크 상세 정보 조회

docker network inspect {네트워크명}

해당 명령어를 실행하면 사진과 같이 많은 정보들이 나옵니다. 그중에서 우리가 봐야할 것은 바로 이 부분입니다. Subnet 다음에 오는 주소는 공인아이피로 부터 할당받은 사설아이피고 밑에 Gateway 다음에 오는 주소는 사이더를 이용하여 내부 서버에 할당받은 아이피 주소 입니다. Subnet 옆에 오는 주소는 사이더 표기법이고, prefix 가 16이므로 172.17.255.255 까지 이용가능함을 알 수 있습니다.

네트워크 생성

docker network create {네트워크명}

네트워크 삭제

docker network rm {네트워크명}

위와 같은 두 명령어를 통해 네트워크를 생성하고 삭제할 수 있습니다.

지금부터는 오늘 배운 개념들에 대해서 실습을 통해 알아보겠습니다. 각각 다른 브릿지에 있는 두 컨테이너가 서로 접속 가능한지 알아보겠습니다.

실습과정

1. second-bridge 라는 이름의 브릿지를 한개 더 만들어보겠습니다.

   docker network create second-bridge
   

![](https://velog.velcdn.com/images/developer_gaeun/post/7fbac433-6e66-44f6-9e5f-833e66d6abf7/image.png)
2. `docker network ls` 명령어를 통해 확인해보면 사진과 같이 새로운 브릿지 `second-bridge` 가 생성되었음을 확인할 수 있습니다.
3. 지금부터는 `bridge` 에 `ubuntuA`, `ubuntuB`, `second-bridge` 에 `ubuntuC` 를 생성해보겠습니다.

docker run -d --name ubuntuA devwikirepo/pingbuntu

아무 설정없이 컨테이너를 생성하면 기본 브릿지에서 생성됩니다.

macOS 라면 cmd + tab 을 눌러 화면을 한개 더 띄우고 아래의 명령어를 실행시켜 보겠습니다.

docker run -it --name ubuntuB devwikirepo/pingbuntu bin/bash

ubuntuA 와 달리 -it 로 실행시키면 컨테이너 내부에 접근할 수 있습니다.
한번 더 cmd + tab 을 눌러 화면을 한개 더 띄우고 아래의 명령어를 실행시켜 보겠습니다.

docker run -it --network second-bridge --name ubuntuC devwikirepo/pingbuntu bin/bash

```

명령어를 이용하여 ubuntuA, ubuntuB 는 bridge 에 ubuntuC 는 second-bridge 에 생성했습니다. 정말 그럴까요? docker inspect {컨테이너 명} 을 이용하여 확인해보겠습니다. ubuntuA 를 생성한 쉘에서 확인하겠습니다.

docker inspect ubuntuA, docker inspect ubuntuB 의 실행결과

docker inspect ubuntuC 의 실행결과

각 컨테이너가 저희의 예상과 같이 실행되고 있음을 알 수 있습니다.

이제 컨테이너 끼리 서로 접속해보겠습니다. 이때 ping {IP} 을 사용합니다. 위에 inspect 명령어를 사용했을때 IPAddress 옆에 있는 아이피주소가 그 컨테이너가 할당받은 아이피 입니다.

ubuntuB 가 실행중인 쉘에서 ping {ubuntuA IP} 를 실행하면 요청이 정상적으로 작동합니다.

ping {ubuntuC IP} 를 실행하면 요청이 가지 않습니다. 즉 두개의 다른 브릿지에 있는 컨테이너는 통신할 수 없음을 알 수 있습니다.

ubuntuC 가 실행중인 쉘에서 ping {ubuntuA or B IP} 를 실행해도 통신할 수 없습니다.