경험은 나의 것

더이상 MSA를 공부할 필요가 없는 이유

sangkins — Thu, 22 Jan 2026 23:20:33 +0900

1. 들어가며

MSA를 공부할 필요가 없다는 게 아니라.. 모놀리식의 이점을 말해드리고 싶었습니다.

AI Driven Development가 대세잖아요. 이제는 단순한 AI 어시스턴트 수준을 넘어서, PRD와 기획서를 잘 만들어서 넘겨주면 스스로 계획을 세우고 실행까지 마치는 AI 에이전트의 시대입니다. 심지어 PRD도 같이 만드는데요..

단순히 시키는 코드만 짜주는 게 아니라, 복잡한 목표를 스스로 하위 작업으로 쪼개고 필요한 도구를 골라가며 결과를 만들어내는 얘네들이 개발을 진짜 기가 막히게 하거든요.

물론 MSA는 여전히 중요하다고도 얘기할 수 있을 것 같습니다. 특히 대규모 조직에서는 더욱더요. 백엔드 개발자라면 분산 시스템의 원리를 알아야 합니다.
왜 이렇게 되었는지를 따라오다 보면 분산 시스템의 원리를 찾을 수 있습니다. 등장한 배경을 알게 된다면 '왜 이렇게 할까'라는 의문에 답할 수 있겠습니다.

2. MSA는 왜 등장했는가

MSA는 기술적인 문제점보다 조직, 인간의 한계 때문이었습니다.

서비스가 너무 커지면 개발자 한 명이 이해할 수 있는 코드의 양은 한계가 있어 전체 코드를 이해할 수 없었습니다. 그래서 이해 가능한 단위로 쪼갭니다.

또한 콘웨이의 법칙으로 하나의 코드베이스를 건드리면 커뮤니케이션 비용이 폭증합니다. 그래서 팀 단위로 서비스를 나눕니다.
또한 수많은 개발자가 다양한 기능을 개발하는데, 배포 일정?, QA? 산 넘어 산입니다.

그래서 얻은 게 코드의 복잡성을 대폭 줄일 수 있었다는 겁니다.
하지만 은탄환은 없다는 말처럼 복잡성을 줄이는 대신, 운영과 네트워크의 복잡성을 가지고 왔습니다.
복잡한 트랜잭션 관리, 분산 추적, 보상 트랜잭션, 네트워크 레이턴시 등.. 다양한 사이드 이펙트를 불러왔습니다.

3. 주체가 바뀌었습니다 (사람 -> AI)

그런데 이제 코드를 짜고 읽는 주체가 인간에서 AI로 넘어가고 있기 때문입니다.

AI는 하나의 Repo에서 분석을 하는 걸 잘하지, 쪼개진 10개의 Repo의 dependency를 고려하며 개발을 맡겨도 하나의 Repo에서 개발을 하는 것보다 나은 성과를 내지 못합니다. (이건 제가 못하는 것일 수도 있습니다만..)

인간이 읽을 수 없고 이해할 수 없는 엄청난 Context를 AI는 읽습니다. 이게 가장 다른 점입니다.

예를 들어 MSA 환경에서 주문 로직을 고친다고 합시다.
Order Service, Payment Service, Delivery Service, WMS 등등 다양한 Repository를 뒤져야 합니다. API 명세가 달라지면 오류를 뱉겠죠?

이게 Monolithic으로 되어있다고 칩시다. 프로젝트 /init 때립니다. 다 읽어요. 끝. 그냥 끝입니다.

MSA에서는 서비스 간 통신을 위해 REST API, gRPC와 서킷 브레이커, 증분 재시도 등 다양한 방법을 씁니다. 분산 트랜잭션을 일치시키려고 다양한 패턴을 도입합니다. 이러한 모든 건 네트워크를 지나가기 때문에 발생하는 일입니다.

물론 외부 API 요청 및 연계에는 방도가 없겠지만. 내부에서는 통일시키자 이겁니다.

4. 미래의 아키텍처

미래의 아키텍처는 사람이 관리하기 편한 구조가 아니라 AI가 읽기 쉽게, 즉 학습하기 쉽고 생성하기 편한 구조로 돌아간다? 진화할 수 있을지도 모릅니다.

그래서 다시 관리하기 어렵게 돌려라?? 이건 또 아닙니다.
AI가 관리하는 모놀리식은 다릅니다.

실시간 리팩토링, 테스트 커버리지 자동화, 린트 에러. 이 정도는 이제 이렇게만 쓰면 이제 뒤처지는 것 같습니다.
하나의 큰 덩어리에 내부 구조는 완벽하게 모듈화된 형태 (Modular Monolith)로 프로젝트를 배포하는 게 쉬워질 것 같습니다.

5. 결론: MSA 공부보다는...

MSA의 이점이 많기 때문에 사라지지는 않을 거라 생각합니다. 결국 서비스는 사람이 사용하는 것이기 때문이죠. (이것도 언제 바뀔지 모릅니다.)

AI가 잘 이해할 수 있는 구조를 설계하고, 전체 Context를 입력하는 능력, 즉 설계와 기획, 프롬프트 엔지니어라고 하나요? 이게 중요해질 것이라고 생각합니다.

당장 yml 설정 파일을 가지고 고민하는 것보다.. 어떻게 AI를 잘 써먹을까 생각하는 게 뒤처지지 않는 방법이라고 생각합니다.

쪼만한 개발자의 지극히 개인적인 생각입니다. 읽어주셔서 감사합니다.

What is Conway's Law?

What an organization ships externally is a reflection of how it communicates internally. See how this museum puts Conway's Law to the test.

www.atlassian.com

AI Agents vs. AI Assistants | IBM

Explore the differences, similarities, benefits and risks of AI assistants and AI agents.

www.ibm.com

AI 주도 개발 라이프사이클: 소프트웨어 엔지니어링의 재구상 | Amazon Web Services

본 게시글은 AWS DevOps & Developer Productivity Blog에 게시된 AI-Driven Development Life Cycle: Reimagining Software Engineering by Raja SP을 한국어 번역 및 편집하였습니다. 비즈니스 및 기술 리더들은 생산성 향상, 속

aws.amazon.com

Git Push HTTP 400 에러 해결: "unexpected disconnect while reading sideband packet"

sangkins — Sat, 3 Jan 2026 18:40:33 +0900

문제 상황

Local 에서 작업중인 Spring Boot Project를 git에 최초로 푸시하던 중 다음과 같은 에러가 발생했습니다.

$ git push -u origin master
Enumerating objects: 127, done.
Counting objects: 100% (127/127), done.
Delta compression using up to 10 threads
Compressing objects: 100% (102/102), done.
error: RPC failed; HTTP 400 curl 22 The requested URL returned error: 400
send-pack: unexpected disconnect while reading sideband packet
Writing objects: 100% (127/127), 1.09 MiB | 1.64 MiB/s, done. 
Total 127 (delta 26), reused 0 (delta 0), pack-reused 0
fatal: the remote end hung up unexpectedly
Everything up-to-date

| Everything up-to-date. 실제로는 push 되지 않음, 인증 문제인지, 저장소 문제인지 원인 파악이 어려움

문제 원인 분석

대용량 파일?

Github는 100MB 이상 파일을 제한하므로 먼저 Project를 확인 : X 대용량 파일이 원인이 아님 (Git)

Git HTTP Buffer 크기 제한

Writing objects: 100% 127개 파일 압축 후 1.09MB
send-pack : unexpected disconnect while reading sideband packet

실제 원인

Git의 기본 HTTP POST Buffer 의 크기는 1MB
127개 파일 압축 결과가 1.09MB로 버퍼 크기 초과
파일 개별 크기가 작아도 전체 압축 크기가 문제가 된 것

Git 소스 코드로 확인하는 에러 원인

Git의 공식 소스 코드를 통해 왜 http.postBuffer 설정이 이 에러를 해결하는지 정확히 확인할 수 있습니다.

1. 기본값 정의: 약 1MB

Git 소스코드 http.c 파일에서 기본값이 정의되어 있습니다.

ssize_t http_post_buffer = 16 * LARGE_PACKET_MAX;

여기서 LARGE_PACKET_MAX는 pkt-line.h에 정의되어 있습니다.

#define LARGE_PACKET_MAX 65520

계산: 16 × 65,520 = 1,048,320 bytes ≈ 1 MiB

2. 설정값 처리 로직

사용자가 git config http.postBuffer로 값을 설정하면 다음 코드가 처리합니다.

if (! strcmp("http.postbuffer", var)) {
    http_post_buffer = git_config_ssize_t(var, value, ctx->kvi);
    if (http_post_buffer < 0)
        warning(_("negative value for http.postBuffer; defaulting to %d"), LARGE_PACKET_MAX);
    if (http_post_buffer < LARGE_PACKET_MAX)
        http_post_buffer = LARGE_PACKET_MAX;
    return 0;
}

핵심 포인트:

LARGE_PACKET_MAX(65,520 bytes)보다 작은 값을 설정해도 자동으로 최소값으로 조정됨
음수 값 설정 시 경고 메시지 출력

3. 버퍼 크기 초과 시 동작

remote-curl.c의 post_rpc 함수에서 push 데이터가 버퍼를 초과하면 large_request 플래그가 설정됩니다.

static int post_rpc(struct rpc_state *rpc, int stateless_connect, int flush_received)
{
    // ... 
    int err, large_request = 0;

    /* Try to load the entire request, if we can fit it into the
     * allocated buffer space we can use HTTP/1.0 and avoid the
     * chunked encoding mess.
     */
    if (! flush_received) {
        while (1) {
            size_t n;
            enum packet_read_status status;

            if (! rpc_read_from_out(rpc, 0, &n, &status)) {
                large_request = 1;  // Buffer Overflow  
                use_gzip = 0;
                break;
            }
            if (status == PACKET_READ_FLUSH)
                break;
        }
    }

4. 버퍼 공간 부족 감지

rpc_read_from_out 함수에서 남은 버퍼 공간이 LARGE_PACKET_MAX보다 작으면 0을 반환합니다.

static int rpc_read_from_out(struct rpc_state *rpc, int options,
                             size_t *appended,
                             enum packet_read_status *status) {
    size_t left;
    // ... 

    if (rpc->write_line_lengths) {
        left = rpc->alloc - rpc->len - 4;
        buf = rpc->buf + rpc->len + 4;
    } else {
        left = rpc->alloc - rpc->len;
        buf = rpc->buf + rpc->len;
    }

    if (left < LARGE_PACKET_MAX)
        return 0;  // ⚠️ 공간 부족 → large_request = 1 설정됨

5. 버퍼 할당

실제 버퍼는 rpc_service 함수에서 http_post_buffer 값만큼 할당됩니다.

rpc->alloc = http_post_buffer;
rpc->buf = xmalloc(rpc->alloc);
rpc->in = client. in;

6. 공식 문서 설명

Git 공식 문서에서도 이 설정에 대해 명확히 설명하고 있습니다.

http. postBuffer:: 
    Maximum size in bytes of the buffer used by smart HTTP
    transports when POSTing data to the remote system. 
    For requests larger than this buffer size, HTTP/1.1 and
    Transfer-Encoding: chunked is used to avoid creating a
    massive pack file locally.  Default is 1 MiB, which is
    sufficient for most requests. 
+
Note that raising this limit is only effective for disabling chunked
transfer encoding and therefore should be used only where the remote
server or a proxy only supports HTTP/1.0 or is noncompliant with the
HTTP standard.  Raising this is not, in general, an effective solution
for most push problems, but can increase memory consumption
significantly since the entire buffer is allocated even for small
pushes.

동작 흐름 다이어그램

┌─────────────────────────────────────────────────────────────────┐
│                    Git Push HTTP 전송 흐름                        │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  1. 커밋 데이터 압축 (예: 1. 09 MB)                                 │
│           ↓                                                     │
│  2. http_post_buffer 크기 확인 (기본값: ~1 MB)                      │
│           ↓                                                     │
│  3. 데이터 크기 > 버퍼 크기?                                         │
│           ↓                                                     │
│     ┌─────┴─────┐                                               │
│     │ YES       │ NO                                            │
│     ↓           ↓                                               │
│  large_request=1   단일 HTTP POST 요청                            │
│     ↓                    ↓                                      │
│  Chunked Transfer     정상 전송 완료 ✓                             │
│  Encoding 사용                                                   │
│     ↓                                                           │
│  서버/프록시가 HTTP/1.1 Chunked 미지원?                              │
│     ↓                                                           │
│  HTTP 400 에러 발생!  ✗                                           │
│                                                                 │
│  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━  │
│  해결:  http.postBuffer 값 증가                                    │
│        → 버퍼 크기 > 데이터 크기                                     │
│        → 단일 HTTP POST 요청으로 전송                               │
│        → Chunked Encoding 우회                                   │
└─────────────────────────────────────────────────────────────────┘

주의사항

공식 문서에서 말하듯이 http.postBuffer를 무조건 늘리는 것이 해결책은 아니다.

"Raising this is not, in general, an effective solution for most push problems, but can increase memory consumption significantly since the entire buffer is allocated even for small pushes."

의미:

버퍼 값을 늘리면 모든 push 작업에서 해당 크기만큼 메모리가 할당됨 (작은 push도 마찬가지)
효과는 오직 Chunked Transfer Encoding을 비활성화하는 것
서버나 프록시가 HTTP/1.1을 제대로 지원하지 않을 때만 효과적

해결 방법

해결책 : HTTP Buffer 크기 증가

# 10MB
git config http.postBuffer 10485760

# Push
git push -u origin master

# 정말 간단하게 이번 push에서만 변경할 수 있다.
git -c http.postBuffer=10485760 push -u origin master

결과

Branch 'master' set up to track remote branch 'master' from 'origin'.
To https://github.com/shchae04/biz-*...

설정 확인 및 관리

해결 후 설정 원복 - 권장
문제가 해결되었다면 버퍼 크기를 기본값으로 되돌리는 것이 좋다.

# 설정 삭제 (기본값 1MB)
git config --global --unset http.postBuffer

# 현재 설정 확인 
git config http.postBuffer

왜 원복해야 하는지?

- 대부분의 push는 1MB 미만
- 버퍼 크기만큼 매 push마다 메모리 할당
- 10MB 설정 유지 시, 작은 커밋 하나에도 10MB 메모리 사용

대용량 push가 필요하다면, 임시 설정으로 처리하는 게 더 효율적.,

git -c http.postBuffer=10485760 push -u origin master

추가 해결 방법

HTTP -> SSH 사용

SSH는 HTTP Buffer 크기 제한이 없음

# SSH URL 변경
git remote set-url origin git@github.com:shchae04/biz-*... 

# SSH Push
git push -u origin master

그렇다고 SSH 사용이 항상 HTTP 보다 장점이 있을까?

장점

HTTP Buffer 크기 제한 없음
안정적인 전송
git 인증 토큰 만료 문제 X

단점

SSH 키 설정 필요
SSH(22) port 막힌 경우 사용 불가
Github Enterprise에서 SSH 비활성화된 경우 존재함

다른 방법

Git LFS

# Git LFS 설치
$ git lfs install

# 대용량 파일 타입 추적
$ git lfs track "*.psd"
$ git lfs track "*.zip"

요약

문제	원인	해결책
HTTP 400 에러	Git HTTP 버퍼(1MB) 초과	git config http.postBuffer 10485760
대용량 전송	HTTP 프로토콜 제한	HTTPS → SSH로 변경

참고 자료

환경 정보:

OS: macOS (Sequoia 15.3.1)
Git 버전: 2.x
프로젝트: Spring Boot 3.5.3 + Gradle

[Spring] Spring PSA의 편리함과 세션 동시성 문제

sangkins — Fri, 2 Jan 2026 00:42:13 +0900

Spring PSA가 주는 편리함에 간과한 본질을 마주했다.
‘설정 한 줄’로 끝났던 세션이, 동시성이라는 점 때문에 어떻게 변하는지 기록하려고 한다.

1. 편한 PSA & 착각

서비스를 확장하며 WAS 간 세션 정합성 문제를 해결해야 했다.
Spring은 spring.session.store-type=redis라는 설정 한 줄로 복잡한 과정을 추상화 해주었다.

이러한 설정이 스프링이 말하는 PSA의 기능이겠지만, 솔직히 그때는 '참 편하다' 하고 대수롭지 않게 넘겼다.

하지만 운영 환경에서는 예상치 못한 동작을 확인할 수 있었다.
비즈니스 로직을 전혀 수정하지 않아도 모든 것이 해결되었다고 생각했고, 차후에 설계 결과로 인해 데이터가 유실되는 현상을 볼 수 있었다.

2. 분석: Redis Hash와 Spring의 ‘Delta Updates’ 전략

핵심은 다음 한 문장으로 요약된다.

> 인프라의 원자성과 애플리케이션의 원자성은 다르다.

Spring Session은 성능과 정합성 사이의 절충안으로 Redis의 Hash 데이터 구조를 활용한다.

스프링 세션의 최상위 인터페이스인 SessionRepository는 설계 단계에서부터 ‘부분 업데이트’의 가능성을 열어두고 있다.

[Interface Specification: SessionRepository]

/**
 * ...
 * Creates a new Session that is capable of being persisted by this SessionRepository.
 * This allows for optimizations and customizations of how the Session is persisted.
 * For example, the returned implementation might keep track of changes to ensure
 * that only the delta is kept on save.
 */
S createSession();

Delta Update 전략

전략의 핵심: 세션 전체를 매번 다시 저장하지 않는다. 내부적으로 변경된 속성만 추적(keep track of changes)하고, 저장 시점에 **변경분(delta)**만 반영한다.
인프라의 역할: Redis의 HSET 명령을 사용해 변경된 필드만 업데이트한다. 필드 단위 업데이트이므로 서로 다른 필드를 수정할 때는 문제가 없다.
결정적 한계: HSET 자체는 원자적이지만, 세션 속성을 구성하는 Read–Modify–Write 사이클은 애플리케이션 레벨에서 분리되어 수행된다. 이로 인해 동일 속성을 동시에 수정할 경우 **갱신 손실(Lost Update)**이 발생한다.

3. 검증: Lost Update 재현

서비스의 최근 본 상품 목록 시나리오를 예제로 문제를 재현했다.

@RestController
public class SessionConcurrencyController {
    private static final String VIEWED_PRODUCTS = "viewedProducts";

    @GetMapping("/view-product-race")
    public String viewProductRace(HttpSession session) throws InterruptedException {
        int threadCount = 2;
        ExecutorService executorService = Executors.newFixedThreadPool(threadCount);
        CountDownLatch latch = new CountDownLatch(threadCount);

        // 두 개의 스레드가 동시에 세션의 동일 리스트에 상품을 추가
        executorService.submit(() -> { updateSessionList(session, "상품B"); latch.countDown(); });
        executorService.submit(() -> { updateSessionList(session, "상품C"); latch.countDown(); });

        latch.await(5, TimeUnit.SECONDS);
        executorService.shutdown();

        List<String> result = (List<String>) session.getAttribute(VIEWED_PRODUCTS);
        return "최종 결과: " + result + (result.size() < 3 ? " -> [유실 발생!]" : " -> [정상]");
    }

    private void updateSessionList(HttpSession session, String newProduct) {
        List<String> original = (List<String>) session.getAttribute(VIEWED_PRODUCTS);
        List<String> products = new ArrayList<>(original != null ? original : new ArrayList<>());

        try { Thread.sleep(500); } catch (InterruptedException ignored) {}

        products.add(newProduct);
        session.setAttribute(VIEWED_PRODUCTS, products);
    }
}

실행 결과 및 타임라인 분석

실행 결과 및 타임라인 분석 로그에는 두 상품 모두 추가되었다고 찍히지만, 최종 결과는 하나가 누락된 [상품A, 상품C]다.

Read	[상품A] 조회	[상품A] 조회	[상품A]
Modify	[상품A, 상품B] 생성	[상품A, 상품C] 생성	[상품A]
Write (A)	set [상품A, 상품B]	-	[상품A, 상품B]
Write (B)	-	set [상품A, 상품C]	[상품A, 상품C] (유실)

4. 회고 및 대안

단순히 세션 데이터를 저장할때 주의해서 사용하자 라는 말로는 부족하다, 실제로 이 문제를 마주쳤을 때 다음과 같은 점을 고려해야 할 것 같다.

대안	장점	단점	추천 상황
저장소 분리	정합성이 완벽	인프라 비용 및 복잡도 증가	동시 수정이 빈번한 핵심 데이터
분산 락 (Redlock)	데이터 유실 방지	성능 저하 (Lock 오버헤드)	세션 정합성이 반드시 필요한 경우
비즈니스 로직 변경	세션 의존도 낮춤	구현 난이도 상승	최근 본 상품 등 부가 서비스

선택과 교훈

이번 케이스에서는 최근 본 상품이 세션에 머물 필요가 없다고 판단하여 별도 DB 저장소로 분리하고 비동기로 처리하는 방식을 택했다.

세션은 최대한 가볍고 불변에 가까운 데이터만 담는 것이 안전하다.

추상화의 비용
PSA는 생산성을 높여주지만, 데이터 정합성까지 책임지지는 않는다.
현실적인 대응 전략
1. 세션에 변경 가능한 컬렉션을 직접 저장하지 않는다
2. 동시 수정 데이터는 외부 저장소로 분리한다
3. 필요 시 분산 락을 도입하되 비용을 인지한다

혹시 내용 중 틀린 점이나 보완할 부분이 있다면 가감 없이 지적 부탁드립니다.

참고 자료

2025년 회고: 정면으로 마주하기

sangkins — Tue, 30 Dec 2025 15:28:11 +0900

2025년은 무언가를 크게 성취한 해라기보다, 오랫동안 미뤘던 것들을 직접 해보기 시작한 해였다. 생각을 행동으로 옮기며, 실행하는 관성을 만들려고 노력했다.

1. 조직과 문화: CVS에서 Git으로

우리 팀(사실상 회사 전체)은 정보처리기사 필기 서적에나 존재할 법한 구시대의 유산인 CVS를 사용하고 있었다. 신규 프로젝트를 시작하며 더 이상은 미룰 수 없다고 판단했고, 팀에 Git 도입을 제안했다. 단순히 최신 트렌드여서가 아니라, 기존 방식이 가진 구조적 결함이 팀의 생산성에 저하되었기 때문이다.

논리와 근거를 통한 설득: 거창한 지표는 아니더라도, 파일 단위로 관리되는 CVS에서 커밋이 깨질 때마다 발생하는 비효율과 이력 추적의 불확실성을 가감 없이 짚었다. "왜 지금 바꿔야 하는가"에 대해 내가 느낀 불편함을 논리적으로 정리해 팀원들과 공유했다. 또한 CVS 서버 장애시 모든 소스 코드가 유실된다...
구조적 한계 돌파: 프로젝트 전체 스냅샷 기반인 Git으로 전환하면서 이력 추적의 신뢰도를 높였다. 잦은 코드 충돌을 유발하던 환경에서 벗어나 현대적인 브랜치 전략을 수립했고, 이를 통해 기능 단위의 독립 개발과 유연한 통합이 가능한 환경을 구축했다.

단순히 도구를 설치하는 데 그치지 않고 사용법과 워크플로우를 공유하며 팀원들을 설득하는 과정을 거쳤다. 내가 고민해서 내놓은 근거들이 팀을 움직이고, 실제로 도입 후 바라던 방향대로 협업 효율이 개선되는 것을 목격했을 때의 만족감은 매우 컸다. 결과적으로 팀이 새로운 방식으로 대화할 수 있는 기술적 기반을 만들었다는 점이 올해 가장 뿌듯한 지점 중 하나다.

2. 기술적 도전: 운영의 관점에서 보는 과금 시스템

실제로 운영되고 있는 서비스의 핵심인 과금 시스템이 비즈니스의 성장 속도를 따라가지 못하는 상황을 마주했다. 단순히 사용량과 금액을 계산하는 로직에 그치지 않고, 실제 운영에서 마주할 수 있는 수많은 예외 사항을 설계에 녹여내는 데 집중하고 있다.

비즈니스 요구사항의 반영: 볼륨 할인 정책이나 특정 사용자 과금 제외 로직 등 복잡한 비즈니스 요구사항을 설계 단계부터 녹여내기 위해 고민 중이다.
시스템 방어 설계: 내부 시스템 에러로 인해 결함 데이터가 생성될 경우, 이를 과금 대상에서 자동으로 제외하는 검증 로직을 강화하고 있다. 대량 데이터 계산 시 발생할 수 있는 소수점 단위 오차를 방지하기 위해 정밀도 처리 정책을 수립하는 것도 중요한 과제다.

이 과정을 거치며 "코드는 구현보다 운영의 시간이 훨씬 길다"는 점을 느끼고 있다. 설계 단계에서의 깊은 고민이 운영 비용을 얼마나 획기적으로 줄여줄 수 있는지 체감하며 개발을 이어가는 중이다.

3. 개인의 성장: 포기하지 않는 태도

일과 학업의 병행: 회사 업무와 학업을 병행하는 것은 생각보다 쉽지 않았다. 컨디션이 늘 좋을 수는 없었지만, 힘들다는 이유로 포기하지 않는 태도를 배우는 과정이었다고 생각한다. 정보처리기사 자격증 취득은 그 태도에 따라온 당연한 결과물이라 믿는다.
학습의 관성 유지: 영어 학습(Speak)을 하루도 빠짐없이 이어갔다. 때로는 내용이 부실했을지언정 학습의 불꽃을 꺼뜨리지 않기 위해 '매일 하는 관성' 자체를 지키는 데 집중했다.

4. 마무리: 운영은 설계의 거울이다

올해의 가장 큰 배움은 결국 운영 단계에서 왔다. 빠르게 서비스하기 위해 고민을 미뤘던 부분들이 결국 운영에서 그대로 드러나는 것을 보았다. 당시에는 "지금은 넘어가도 된다"고 했던 선택들이 시간이 지나 손대기 어려운 부채가 되어 돌아왔다.

설계 단계에서의 깊은 고민이 운영의 비용을 얼마나 줄이는지 알 수 있었다. 26년의 나는 빠른 개발보다는 '지속 가능한 개발'에 좀 더 무게를 두는 개발자가 되고자 한다.

2026년: 나의 가치를 증명하는 해

2025년이 '실행하는 시늉'을 낸 해였다면, 2026년은 그 실행의 결과로 나의 가치를 증명하는 해가 되어야 한다. 성취하고 인정받고 싶은 욕구는 나를 움직이는 가장 솔직한 동력이다. 이제는 그 에너지를 확실한 결과물로 보여주어야 할 때인 것 같다.

Tech: 인프라의 확장과 지능화
- CloudFlare 인프라 최적화 영역까지!!
- SAP 자격증 취득과 RAG 스터디를 통해 도메인 지식을 공부하고, AI 기술을 실무의 중심으로 가져와야겠다.
Product: 지표로 증명하는 실력
- 사이드 프로젝트인 옥션 프로젝트의 방문자를 일 500명까지 끌어올릴 것이다. 반응을 지표로 확인하며, 내 생각과 방향이 통하는지 검증하겠다.
Habit: 계획의 시스템화와 엄격한 통제
- '계획 세우기'를 미루는 나태함을 치우고자 한다. 매주 일요일 저녁, 다음 주의 Action 3가지를 확정하고 스스로에게 보상과 패널티를 부여하는 시스템을 이용하려 한다.

올해 가장 뼈아픈 수확은 "운영은 설계의 거울"이라는 문장을 마주한 것이다. 과거의 내가 미뤘던 고민들이 부채가 되어 돌아오는 것을 보며, 그 부작용을 체감했다.

2026년의 나는 당장의 속도에 취하지 않고, '지속 가능한 개발'을 위해 스스로를 더 다그치려 한다. 실행의 관성을 만들었다는 안도감에 그치지 않겠다.

[Spring] Filter의 요청 가로채기

sangkins — Sun, 28 Dec 2025 00:50:51 +0900

1. 배경: 세션 탈취 글을 쓰고 나서

spring:
  session:
    store-type: redis

지난 글에서 Spring Session이 Filter와 Decorator 패턴으로 세션 저장소를 Redis로 바꿔치기하는 과정을 알아봤다.

"Filter가 요청을 가로챈다고 했는데, 그럼 요청은 정확히 어디서부터 시작해서 Controller까지 갈까"

그래서 이번엔 Spring 코드를 직접 까보면서 HTTP 요청의 전체 흐름을 파악해보자.

2. 디버깅으로 흐름 추적하기

일단 간단한 Controller를 하나 만들고, Get 요청 후 Call Stack을 확인해봤다.

@RestController
public class TraceController {

    @GetMapping("/trace")
    public String traceEndpoint() {
        return "Trace endpoint Response";  // breakpoint
    }
}

/trace로 요청을 보내고 breakpoint에서 멈췄을 때 Call Stack을 보면:

at com.auction.controller.TraceController.traceEndpoint(TraceController. java:11)
    ...   (Reflection)
at org.springframework.web.servlet. mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(...)
at org.springframework.web.servlet. DispatcherServlet.doDispatch(DispatcherServlet.java:1089)     ← Spring MVC
at org.springframework.web.servlet.DispatcherServlet. doService(DispatcherServlet.java:979)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:1014)
at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:903)
at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:564)
at org.springframework.web.servlet. FrameworkServlet.service(FrameworkServlet.java:885)
at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:658)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(...)                         ← Tomcat Filter Chain
at org.apache.catalina.core.ApplicationFilterChain. doFilter(ApplicationFilterChain. java:140)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)
at org.apache.catalina.core.ApplicationFilterChain. internalDoFilter(...)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(...)
    ...  (Spring Security Filter Chain)
at org.springframework.security.web.FilterChainProxy. doFilterInternal(FilterChainProxy.java:233) ← Spring Security
at org. springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:191)
    ... 
at org.springframework.web.filter. DelegatingFilterProxy. doFilter(DelegatingFilterProxy. java:278)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(...)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(...)
at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(...)                  ← 인코딩 필터
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(...)
at org.apache.catalina.core. ApplicationFilterChain.doFilter(ApplicationFilterChain.java:140)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:167)           ← Tomcat 시작점
    ...

Call Stack을 아래에서 위로 읽으면 요청의 흐름이 보인다:

ApplicationFilterChain.doFilter() - Tomcat의 Filter Chain
FrameworkServlet.service() - Spring 진입점
DispatcherServlet.doDispatch() - Spring MVC 핵심
RequestMappingHandlerAdapter.handle() - Controller 실행
TestController.test() - 내 코드

이걸 바탕으로 전체 흐름을 정리하면:

HTTP Request
    ↓
[Servlet Container - Tomcat]
    ↓
Filter Chain (Filter1 → Filter2 → ... → DispatcherServlet)
    ↓
[Spring MVC]
    ↓
FrameworkServlet.service()
    ↓
DispatcherServlet.doDispatch()
    ↓
Interceptor.preHandle() → Controller → Interceptor.postHandle()
    ↓
HTTP Response

핵심은 이거다:

Filter는 Tomcat이 관리한다. Spring 바깥이다.
Interceptor는 DispatcherServlet 안에서 돌아간다. Spring 내부다.

이제 코드로 하나씩 까보자.

3. Filter: Servlet 스펙이다 (Spring 아님)

Filter는 Jakarta Servlet API에 정의되어 있다. Spring이 만든 게 아니라 Tomcat이 관리한다.

// jakarta.servlet.Filter
public interface Filter {

    void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
            throws IOException, ServletException;
}

// jakarta.servlet.FilterChain
public interface FilterChain {

    // 다음 필터 호출, 마지막이면 Servlet 호출
    void doFilter(ServletRequest request, ServletResponse response) 
        throws IOException, ServletException;
}

Filter 구현하면 이런 식이다:

public class MyFilter implements Filter {

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, 
                        FilterChain chain) throws IOException, ServletException {

        System.out.println("전처리");

        chain.doFilter(request, response);  // 다음으로 넘김

        System.out. println("후처리");
    }
}

지난 글의 SessionRepositoryFilter도 이 구조였다. chain.doFilter() 호출 전에 Request를 Wrapper로 감싸서 넘긴 것이다.

4. FilterChain의 실체: Tomcat의 ApplicationFilterChain

근데 chain.doFilter()를 호출하면 다음 Filter가 어떻게 실행되는 걸까? FilterChain은 인터페이스일 뿐이다. 실제 구현체는 Tomcat의 ApplicationFilterChain이다.

4-1. 필드 구조

// org.apache.catalina.core. ApplicationFilterChain
public final class ApplicationFilterChain implements FilterChain {

    // 필터 배열
    private ApplicationFilterConfig[] filters = new ApplicationFilterConfig[0];

    // 현재 실행 중인 필터의 위치
    private int pos = 0;

    // 등록된 필터의 총 개수
    private int n = 0;

    // 필터 체인 끝에서 실행할 Servlet
    private Servlet servlet = null;
}

핵심은 pos와 n이다. pos는 현재 몇 번째 필터를 실행 중인지, n은 총 필터 개수다.

4-2. doFilter() 구현

@Override
public void doFilter(ServletRequest request, ServletResponse response) 
        throws IOException, ServletException {

    // 아직 실행할 필터가 남아있으면
    if (pos < n) {
        // pos 증가시키면서 다음 필터 가져옴
        ApplicationFilterConfig filterConfig = filters[pos++];
        Filter filter = filterConfig.getFilter();

        // 필터 실행 (this를 넘겨서 재귀 호출 가능하게)
        filter.doFilter(request, response, this);
        return;
    }

    // 모든 필터를 통과했으면 Servlet 실행
    servlet.service(request, response);
}

동작 원리를 정리하면:

pos < n 이면 아직 실행할 필터가 남아있다는 뜻이다
filters[pos++]로 현재 필터를 가져오고 pos를 1 증가시킨다
filter.doFilter(request, response, this)를 호출한다. 여기서 this가 핵심이다
필터 내부에서 chain.doFilter()를 호출하면 다시 이 메서드가 실행된다
이번엔 pos가 증가했으니 다음 필터가 실행된다
모든 필터를 통과하면(pos >= n) 드디어 servlet.service()가 호출된다

4-3. 그림으로 보면

[ApplicationFilterChain]
filters = [Filter1, Filter2, Filter3]
n = 3, pos = 0, servlet = DispatcherServlet

1) doFilter() 호출 (pos=0)
   → pos++ → Filter1.doFilter(req, res, this) 호출

2) Filter1 내부에서 chain.doFilter() 호출 (pos=1)
   → pos++ → Filter2.doFilter(req, res, this) 호출

3) Filter2 내부에서 chain.doFilter() 호출 (pos=2)
   → pos++ → Filter3.doFilter(req, res, this) 호출

4) Filter3 내부에서 chain.doFilter() 호출 (pos=3)
   → pos(3) >= n(3) 이므로
   → servlet.service(req, res) 호출!

결국 재귀 호출 구조다. 각 필터가 chain.doFilter()를 호출하면 다음 필터로 넘어가고, 마지막에 Servlet이 실행된다.

지난 글의 SessionRepositoryFilter가 chain.doFilter(wrappedRequest, response)를 호출했을 때, 이 wrappedRequest가 다음 필터들과 최종적으로 DispatcherServlet까지 전달된 것이다.

5. HttpServlet: Servlet의 진입점

Filter Chain 끝에서 servlet.service()가 호출된다. Spring의 DispatcherServlet은 HttpServlet을 상속받는다.

HttpServlet (Jakarta Servlet) - HTTP 메서드별 분기
    ↑
HttpServletBean (Spring) - Spring Bean 속성 바인딩
    ↑
FrameworkServlet (Spring) - WebApplicationContext 관리
    ↑
DispatcherServlet (Spring) - 요청 디스패칭

HttpServlet의 service() 메서드를 보면:

// jakarta.servlet.http.HttpServlet
protected void service(HttpServletRequest req, HttpServletResponse resp)
        throws ServletException, IOException {

    String method = req. getMethod();

    if (method.equals("GET")) {
        doGet(req, resp);
    } else if (method.equals("POST")) {
        doPost(req, resp);
    } else if (method.equals("PUT")) {
        doPut(req, resp);
    }
    // ... 
}

HTTP 메서드에 따라 doGet, doPost 등으로 분기한다.

6. FrameworkServlet: Spring 진입

FrameworkServlet에서 doGet, doPost 등을 오버라이드한다.

// org.springframework.web.servlet. FrameworkServlet
@Override
protected final void doGet(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {
    processRequest(request, response);
}

@Override
protected final void doPost(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {
    processRequest(request, response);
}

결국 다 processRequest()로 모인다.

protected final void processRequest(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {

    // 컨텍스트 설정 (LocaleContext, RequestAttributes)
    initContextHolders(request, localeContext, requestAttributes);

    try {
        doService(request, response);  // DispatcherServlet. doService() 호출
    }
    finally {
        resetContextHolders(request, previousLocaleContext, previousAttributes);
    }
}

Tip: RequestContextHolder. getRequestAttributes()로 어디서든 현재 요청 정보를 가져올 수 있는 이유가 여기서 설정하기 때문이다.

7. DispatcherServlet. doDispatch(): 여기가 핵심이다

Interceptor가 실행되는 곳이다. 코드를 보자.

// org.springframework.web.servlet.DispatcherServlet
protected void doDispatch(HttpServletRequest request, HttpServletResponse response) 
        throws Exception {

    HandlerExecutionChain mappedHandler = null;

    try {
        ModelAndView mv = null;

        try {
            // 1. Handler(Controller) 찾기
            mappedHandler = getHandler(processedRequest);
            if (mappedHandler == null) {
                noHandlerFound(processedRequest, response);
                return;
            }

            // 2. Interceptor - preHandle()
            if (!mappedHandler.applyPreHandle(processedRequest, response)) {
                return;  // false면 여기서 끝
            }

            // 3. Controller 실행
            HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());
            mv = ha.handle(processedRequest, response, mappedHandler.getHandler());

            // 4. Interceptor - postHandle()
            mappedHandler.applyPostHandle(processedRequest, response, mv);
        }
        catch (Exception ex) {
            dispatchException = ex;
        }

        // 5. View 렌더링
        processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException);
    }
    catch (Exception ex) {
        // 6. Interceptor - afterCompletion() (예외 발생해도 실행)
        triggerAfterCompletion(processedRequest, response, mappedHandler, ex);
    }
}

순서를 정리하면:

getHandler() - 요청 URL에 맞는 Controller 찾음
applyPreHandle() - Interceptor의 preHandle() 실행
ha.handle() - Controller 메서드 실행
applyPostHandle() - Interceptor의 postHandle() 실행
processDispatchResult() - View 렌더링
triggerAfterCompletion() - Interceptor의 afterCompletion() 실행

8. HandlerExecutionChain: Interceptor 실행 로직

applyPreHandle()과 applyPostHandle()이 실제로 뭘 하는지 보자.

// org.springframework.web.servlet.HandlerExecutionChain

// preHandle - 순서대로 실행 (0 → n)
boolean applyPreHandle(HttpServletRequest request, HttpServletResponse response) 
        throws Exception {

    for (int i = 0; i < this.interceptorList.size(); i++) {
        HandlerInterceptor interceptor = this.interceptorList.get(i);

        if (!interceptor.preHandle(request, response, this.handler)) {
            triggerAfterCompletion(request, response, null);
            return false;  // 하나라도 false면 중단
        }
        this.interceptorIndex = i;
    }
    return true;
}

// postHandle - 역순으로 실행 (n → 0)
void applyPostHandle(HttpServletRequest request, HttpServletResponse response, 
                    ModelAndView mv) throws Exception {

    for (int i = this.interceptorList.size() - 1; i >= 0; i--) {
        HandlerInterceptor interceptor = this.interceptorList.get(i);
        interceptor.postHandle(request, response, this.handler, mv);
    }
}

preHandle은 순서대로, postHandle은 역순으로 실행된다.

9. Filter vs Interceptor

구분	Filter	Interceptor
소속	Servlet 스펙	Spring MVC
관리	Tomcat	Spring
실행 위치	DispatcherServlet 이전	DispatcherServlet 내부
Spring Bean 접근	`@Component` 또는 `FilterRegistrationBean` 필요	바로 접근 가능
예외 처리	`@ControllerAdvice` 적용 안됨	`@ControllerAdvice` 적용됨
용도	인코딩, 보안, XSS 필터링	인증/인가, 로깅, 공통 로직

10. 정리

HTTP Request
    ↓
[Tomcat - ApplicationFilterChain]
    │
    ├── pos=0: Filter1.doFilter() → chain.doFilter()
    ├── pos=1: Filter2.doFilter() → chain.doFilter()
    ├── pos=2: SessionRepositoryFilter.doFilter() → chain.doFilter(wrappedRequest)
    └── pos >= n: servlet.service() 호출
    ↓
[DispatcherServlet. doDispatch()]
    ├── getHandler()
    ├── Interceptor.preHandle()
    ├── Controller 실행
    ├── Interceptor.postHandle()
    └── Interceptor.afterCompletion()
    ↓
HTTP Response

지난 글의 SessionRepositoryFilter가 정확히 어느 시점에 동작하는지 이제 알겠다. Tomcat의 ApplicationFilterChain이 pos를 증가시키면서 필터를 순차 실행하고, 모든 필터를 통과한 후에야 servlet.service()로 DispatcherServlet이 실행된 것이다.

그리고 SessionRepositoryFilter가 chain.doFilter(wrappedRequest, response)를 호출했을 때, 이 wrappedRequest가 다음 필터들을 거쳐 최종적으로 DispatcherServlet까지 전달되어, Controller에서 request.getSession()을 호출하면 Redis 세션을 반환하게 된 것이다.

Filter는 Spring 바깥, Interceptor는 Spring 내부. 이 차이를 알면 어디에 뭘 넣어야 하는지 판단하기 쉬워진다.

참고

[Spring] Redis의 세션 Store 휩쓸기

sangkins — Fri, 26 Dec 2025 16:41:24 +0900

1. yml 파일의 설정 한 줄로 바뀌는 세션 위치

spring:
  session:
    store-type: redis # 이 한 줄이 핵심!
    redis: 
      namespace: spring:session
  data:
    redis:
      host: localhost
      port: 6379

현재 진행 중인 프로젝트에서 무중단 배포(Blue/Green) 환경 구축과 세션 정합성 문제를 해결하기 위해 Redis를 도입하게 되었다.

build.gradle에 Spring Session Data Redis 의존성을 추가하고, application.yml에 간단한 설정 몇 줄을 추가했다. 기존 비즈니스 로직 코드를 단 한 줄도 수정하지 않았는데, 세션 저장소가 Tomcat 메모리에서 Redis로 변경된 것이다.

Controller에 있는 httpServletRequest.getSession() 코드는 그대로인데, 어떻게 저장소만 바뀐 걸까?

2. 의문: 도대체 언제 가로챈 걸까?

"스프링은 도대체 언제, 어떻게 내 요청을 가로채서 Redis를 연결한 걸까??"

기존에는 Tomcat(WAS)이 자체적으로 메모리에서 세션을 관리했다. (ConcurrentHashMap) 그렇다면 스프링이 Filter나 Interceptor 단계에서 createSession 같은 동작을 중간에 낚아채는 것일까?

3. 분석: 범인은 Filter와 Decorator 패턴

결론부터 말하자면, 이 마법은 서블릿 컨테이너의 문지기인 Filter, 객체를 포장하는 Decorator(Wrapper) 패턴, 그리고 Spring의 추상화(PSA)가 합작해 낸 결과물이었다.

전체 흐름도

HTTP Request
    ↓
[SessionRepositoryFilter] ← 요청 가로채기
    ↓
wrappedRequest = new SessionRepositoryRequestWrapper(request)
    ↓
filterChain.doFilter(wrappedRequest, ...)  
    ↓
[Controller에서 request.getSession() 호출]
    ↓
SessionRepositoryRequestWrapper. getSession() ← 메서드 오버라이딩
    ↓
sessionRepository.findById(sessionId) ← SessionRepository 호출
    ↓
[RedisIndexedSessionRepository. findById()] ← Redis에서 조회
    ↓
HttpSessionWrapper로 감싸서 반환 ← HttpSession 인터페이스 구현
    ↓
[응답 완료 시]
    ↓
commitSession() → sessionRepository.save() → Redis 저장 ← 저장

3-1. 문지기: SessionRepositoryFilter

모든 비밀의 시작은 SessionRepositoryFilter다. 이 필터는 Order가 매우 낮게 설정되어 있어 필터 체인의 가장 앞단에서 동작한다.

@Order(SessionRepositoryFilter.DEFAULT_ORDER)  // Integer.MIN_VALUE + 50
public class SessionRepositoryFilter<S extends Session> extends OncePerRequestFilter {

    public static final int DEFAULT_ORDER = Integer.MIN_VALUE + 50;

    private final SessionRepository<S> sessionRepository;

    public SessionRepositoryFilter(SessionRepository<S> sessionRepository) {
        if (sessionRepository == null) {
            throw new IllegalArgumentException("sessionRepository cannot be null");
        }
        this.sessionRepository = sessionRepository;
    }
}

다른 Filter나 Interceptor가 request.getSession()을 호출하기 전에 request를 Wrapping 해야 한다. 그렇지 않다면 모든 코드가 Redis 기반 세션을 사용하지 않을 수 있다.

3-1-2. Request를 Wrapper로 감싼다

이 필터의 핵심 역할은 '포장(Wrapping)'이다. doFilterInternal 메서드를 보면 Decorator 패턴이 보인다.

Decorator 패턴이란? 객체에 대한 기능 확장이나 변경이 필요할 때, 상속 대신 객체를 감싸서 기능을 추가하는 유연한 구조 패턴이다. 선물 포장지를 생각하면 된다.

@Override
protected void doFilterInternal(HttpServletRequest request, 
                                HttpServletResponse response, 
                                FilterChain filterChain)
        throws ServletException, IOException {

    request.setAttribute(SESSION_REPOSITORY_ATTR, this.sessionRepository);

    // 1. 원본 request를 Wrapper로 감싼다 (포장)
    SessionRepositoryRequestWrapper wrappedRequest = 
            new SessionRepositoryRequestWrapper(request, response);

    // 2. 원본 response도 Wrapper로 감싼다
    SessionRepositoryResponseWrapper wrappedResponse = 
            new SessionRepositoryResponseWrapper(wrappedRequest, response);

    try {
        // 3. 원본이 아닌 '포장된 객체'를 다음 체인으로 전달! 
        filterChain.doFilter(wrappedRequest, wrappedResponse);
    }
    finally {
        // 4. 요청 처리 완료 후 세션을 Redis에 저장 (Commit)
        wrappedRequest.commitSession();
    }
}

핵심은 3번이다. 이후 실행되는 모든 로직(Controller 등)은 톰캣의 원본 HttpServletRequest가 아니라, 스프링이 바꿔치기한 wrappedRequest를 사용하게 된다.

AS-IS vs TO-BE

구분	AS-IS (기존)	TO-BE (Spring Session 적용 후)
Controller가 받는 객체	`HttpServletRequest`	`SessionRepositoryRequestWrapper`
`getSession()` 호출 시	Tomcat 메모리 세션 반환	Redis 세션 반환

3-2. 바꿔치기: SessionRepositoryRequestWrapper

그렇다면 포장된 wrappedRequest는 무슨 일을 할까? 이 클래스는 HttpServletRequestWrapper를 상속받아 구현되어 있으며, 가장 중요한 getSession() 메서드를 오버라이딩(Override) 하고 있다.

private final class SessionRepositoryRequestWrapper extends HttpServletRequestWrapper {

    @Override
    public HttpSessionWrapper getSession(boolean create) {
        // 1. 이미 현재 요청에서 세션을 가져온 적 있으면 캐시된 것 반환
        HttpSessionWrapper currentSession = getCurrentSession();
        if (currentSession != null) {
            return currentSession;
        }

        // 2. SessionRepository에서 세션 조회 (Redis에서 찾는다!)
        S requestedSession = getRequestedSession();

        if (requestedSession != null) {
            if (getAttribute(INVALID_SESSION_ID_ATTR) == null) {
                requestedSession. setLastAccessedTime(Instant.now());
                this.requestedSessionIdValid = true;
                currentSession = new HttpSessionWrapper(requestedSession, getServletContext());
                currentSession.markNotNew();
                setCurrentSession(currentSession);
                return currentSession;
            }
        }

        // 3. 세션이 없고, create=false면 null 반환
        if (!create) {
            return null;
        }

        // 4. 새로운 세션 생성도 SessionRepository를 통해 (Redis에 생성!)
        S session = SessionRepositoryFilter.this.sessionRepository. createSession();
        session.setLastAccessedTime(Instant.now());
        currentSession = new HttpSessionWrapper(session, getServletContext());
        setCurrentSession(currentSession);
        return currentSession;
    }

    @Override
    public HttpSessionWrapper getSession() {
        return getSession(true);
    }
}

즉, 우리가 컨트롤러에서 무심코 호출했던 request.getSession()은 사실 Redis와 통신하는 래퍼 객체의 메서드였던 것이다.

3-3. 저장소: RedisIndexedSessionRepository

실제로 Redis와 대화하는 구현체는 RedisIndexedSessionRepository다. 세션 데이터를 MapSession 객체로 변환하고, 이를 Redis Hash 자료구조로 저장한다.

@Override
public RedisSession findById(String id) {
    return getSession(id, false);
}

private RedisSession getSession(String id, boolean allowExpired) {
    // 1. Redis Hash에서 세션 데이터 조회
    Map<String, Object> entries = getSessionBoundHashOperations(id).entries();

    if ((entries == null) || entries.isEmpty()) {
        return null;
    }

    // 2. Map → MapSession 객체로 변환
    MapSession loaded = this.redisSessionMapper.apply(id, entries);

    if (loaded == null || (! allowExpired && loaded.isExpired())) {
        return null;
    }

    // 3. RedisSession으로 감싸서 반환
    RedisSession result = new RedisSession(loaded, false);
    result.originalLastAccessTime = loaded.getLastAccessedTime();
    return result;
}

Redis에 저장되는 데이터 구조

HGETALL spring:session:sessions:33fdd1b6-b496-4b33-9f7d-df96679d32fe

┌────────────────────────────┬─────────────────────────────┐
│ Field                      │ Value                       │
├────────────────────────────┼─────────────────────────────┤
│ creationTime               │ 1404360000000               │
│ maxInactiveInterval        │ 1800                        │
│ lastAccessedTime           │ 1404360000000               │
│ sessionAttr: username      │ "Sang Hyeok"                │
│ sessionAttr:loginTime      │ "2025-12-26T10:30:00"       │
└────────────────────────────┴─────────────────────────────┘

3-4. 응답 완료 시 세션 저장 (Commit Session)

요청 처리가 끝나면 finally 블록에서 commitSession()이 호출되어 세션을 Redis에 저장한다.

private void commitSession() {
    HttpSessionWrapper wrappedSession = getCurrentSession();

    if (wrappedSession == null) {
        if (isInvalidateClientSession()) {
            SessionRepositoryFilter.this.httpSessionIdResolver
                    .expireSession(this, this.response);
        }
    }
    else {
        S session = wrappedSession.getSession();

        // SessionRepository. save() 호출 → Redis에 저장! 
        SessionRepositoryFilter.this.sessionRepository.save(session);

        String sessionId = session.getId();
        if (! isRequestedSessionIdValid() || !sessionId.equals(requestedSessionId)) {
            SessionRepositoryFilter.this.httpSessionIdResolver
                    .setSessionId(this, this.response, sessionId);
        }
    }
}

3-5. 최적화: Delta 저장 방식

RedisSession은 변경된 속성만 추적하여 저장한다. 매번 모든 세션 데이터를 덮어쓰면 네트워크 낭비가 심하기 때문이다.

public final class RedisSession implements Session {

    private Map<String, Object> delta = new HashMap<>(); 

    @Override
    public void setAttribute(String attributeName, Object attributeValue) {
        this.cached.setAttribute(attributeName, attributeValue);
        // 변경사항을 delta에 기록
        this.delta.put(getSessionAttrNameKey(attributeName), attributeValue);
    }

    private void saveDelta() {
        if (this.delta.isEmpty()) {
            return;  // 변경된 게 없으면 저장 안 함 (효율성)
        }

	    // HashOperations.putAll → Redis HSET (partial hash update)
        getSessionBoundHashOperations(sessionId).putAll(this.delta);

        // delta 초기화
        this. delta = new HashMap<>(this.delta. size());
    }
}

Tip: 왜 만료 시간이 복잡하게 설정될까?

Redis를 조회해보면 세션 키 외에도 expires, shadow key 등 복잡한 키들이 보인다. 이는 Redis의 Key Expiration 이벤트가 정확한 시점에 발생하지 않을 수 있다는 한계를 극복하고, 세션 만료 시점에 SessionDestroyedEvent를 확실하게 발행하기 위한 Spring Session만의 트릭이다. (실제 데이터는 만료 시간보다 5분 더 오래 살아있다.)

핵심 정리

단계	역할
1단계	`SessionRepositoryFilter`가 요청을 가로채고 Request Wrapping
2단계	`SessionRepositoryRequestWrapper`가 `getSession()` 오버라이딩
3단계	`SessionRepository`에서 세션 저장소 추상화
4단계	`RedisIndexedSessionRepository`에서 Redis 구현체 동작
5단계	`HttpSessionAdapter`에서 Session을 HttpSession으로 변환
6단계	`RedisSession`에서 Delta 추적 후 Redis 저장

4. 결론: PSA (Portable Service Abstraction)

우리가 흔히 쓰는 HttpSession은 사실 클래스가 아니라 인터페이스다.

Spring은 이 점을 이용해 완벽한 PSA를 구현했다:

Filter로 요청을 가로채고,
Wrapper로 구현체를 몰래 바꿔치기하여,
개발자가 모르는 사이에 Session Store를 교체했다.

HttpSession 인터페이스는 그대로, 구현체만 Tomcat에서 Redis로 교체.
아무것도 수정하지 않아도 된다.

덕분에 비즈니스 로직을 단 한 줄도 수정하지 않고, 인프라를 로컬 메모리에서 Redis, JDBC, MongoDB 등으로 자유롭게 변경할 수 있다.

"설정은 별거 없어보이지만, 까보면 생각보다 복잡하게 돌아가고 있었다."

참고 자료

토스 러너스 하이 2기

sangkins — Mon, 15 Dec 2025 22:20:33 +0900

토스 Learner's High 서버 2기 | Notion

토스 Learner’s High 서버 2기의 주인공이 되어보세요!

tosspublic.notion.site

개발자라면 하나씩은 있는 개발자 취업/정보교류 채팅방에서 토스에서 서버 개발자 멘토링 과정을 진행한다는 이야기를 처음 들었을 때, 해보고 싶다는 생각이 먼저 들었다.

그러다 중국 여행을 다녀온 당일인 11월 30일, 그 기억이 다시 떠올라 이력서를 다시 정리해 지원했고,

토스 Learner's High 서버 2기 과정에 참여하게 되었다.

이번 한 달은

기술 스택을 더 늘리는 시간이라기보다는,

토스에서는 어떻게 일하는지,

그리고 내가 앞으로 어떤 방향으로 나아가야 할지를 고민하는 개발자로 성장하는 시간으로 만들고 싶다.

단순한 멘토링이 아니라 스스로 목표를 정하고 실천해야 한다는 점에서

부담도 있고 쉽지 않을 것 같지만, 그래서 더 의미 있는 과정이 될 거라 생각한다.

한 달 뒤에는
지금보다 더 명확한 근거를 가지고
내 선택을 설명할 수 있는 개발자가 되어 있기를 기대한다.

뒤엉킨 레거시 청산기: 빠른 개발과 유지보수, 그 사이

sangkins — Tue, 25 Nov 2025 23:59:39 +0900

배경

프로젝트 초반에는 늘 그렇듯, '일정 준수'가 가장 중요했습니다. 백엔드와 화면을 동시에 개발해야 했기에, 가장 빠르고 직관적인 방법을 선택했죠. 바로 하나의 Controller에서 View와 Data를 모두 처리하는 구조였습니다.

당시에는 가장 효율적인 선택이라고 생각했지만, 프로젝트 규모가 커지고 새로운 모듈을 도입하려다 보니 이 구조가 발목을 잡기 시작했습니다.

당시의 코드

@RequestMapping("/api")
class TotalController(
    private final TotalService service;
) {
    @GetMapping("/form")
    public String form(){ return "form"; }
  
    // DataTables 라이브러리 스펙
    @GetMapping("/detail")
    public ResponseEntity<ResponseDto> getDetail(@RequestParam("id") String id){
        return Result.ok(service.find(id));
    }
    
    // ...여기에 저장, 수정, 조회 로직...
}

이 코드를 보며 막막함을 느꼈습니다.

역할의 모호함: 화면 로직과 데이터 로직이 한 클래스에 섞여 있어, 4000 line에 달하는 소스의 길이와 하나를 수정하면 다른 쪽에 영향을 줄까 겁이 났습니다.
확장성 부재: 프론트엔드 라이브러리에 종속된 응답 구조 때문에, 다른 서비스와의 연동이 불가능했습니다.
복사-붙여넣기의 유혹: 새 기능을 만들 때, 이 구조를 그대로 복사해서 이름만 바꾸면 금방 개발할 수 있다는 점이 컷습니다.

복붙이냐, 개선이냐

새로운 모듈 개발 일정이 다가왔을 때, 저에게는 두 가지 선택지가 있었습니다.

선택 A (복사-붙여넣기): 기존 방식을 그대로 차용한다. (개발 기간 단축, 하지만 기술 부채 누적)
선택 B (리팩토링 병행): 구조를 개선하며 개발한다. (초기 개발 속도 저하, 하지만 유지보수성 확보)

현실적으로는 A가 달콤했습니다. 하지만 이번만 이렇게 하고 나중에 고치자라는 말이 얼마나 지키기 어려운 약속인지 우리 모두 잘 알고 있고 경험이 있습니다. 지금 고치지 않으면, 나중엔 더 큰 비용을 치러야 한다는 확신이 들었습니다.

그래서 조금 돌아가더라도, 수정과 개발을 동시에 진행하는 길을 선택했습니다.

리팩토링 포인트 3가지

개발과 리팩토링을 병행하며 중점적으로 개선한 부분은 다음 세 가지입니다.

View와 API의 확실한 역할 분리

가장 먼저 TotalController를 두 개의 전문화된 컨트롤러로 분리했습니다.

PageController (@Controller): 오직 화면 네비게이션과 권한 체크만 담당합니다.
ApiController (@RestController): 순수한 데이터(JSON) 응답만 담당합니다.

이렇게 분리하고 나니, 프론트엔드 로직이 바뀌어도 API 코드를 건드릴 필요가 없어졌습니다.

특정 라이브러리 종속성 제거 (DataTables)

기존에는 프론트엔드 그리드 라이브러리인 DataTables가 요구하는 포맷(draw, recordsTotal 등)을 서버에서 직접 만들어 반환했습니다. 백엔드가 프론트엔드 구현 상세에 의존하는 구조였습니다.

이를 RESTful한 표준 응답 구조로 변경했습니다. 서버는 표준화된 데이터(content, totalElements 등)만 내려주고, 포맷팅은 프론트엔드(JS)나 어댑터 패턴을 통해 처리하도록 위임했습니다. 덕분에 이제 어떤 프론트엔드 프레임워크가 와도 대응할 수 있는 API가 되었습니다.

리소스(Resource) 중심의 URI 설계

getDetail, saveForm 같은 행위 중심의 URI를 리소스 중심으로 재정의했습니다.

Before: GET /api/getDetail?id=1
After: GET /api/orders/1

사소해 보일 수 있지만, URI만 보고도 어떤 자원을 다루는지 명확히 알 수 있게 되어 협업 효율이 크게 올라갔습니다.

- 리팩토링

처음 리팩토링을 병행하며 개발할 때는 솔직히 힘들었습니다. "그냥 하던 대로 하면 벌써 끝났을 텐데"라는 생각이 들 때도 있었고요.

하지만 그 효과는 두 번째, 세 번째 모듈을 개발할 때 증명되었습니다. 잘 만들어진 공통 API 구조 덕분에, 이후 개발은 '복사-붙여넣기'보다 훨씬 빠른 속도로, 그리고 훨씬 안정적으로 진행할 수 있었습니다.

기술 부채는 피할 수 없지만, 관리할 수 있다는 점을 알았습니다.

"결국은 기반이 튼튼해야 한다는 것."

[혼공학습단 12기] 혼자 공부하는 네트워크 - 6주차 & 회고

sangkins — Sun, 18 Aug 2024 21:55:46 +0900

Wireshark · Display Filter Reference: Index

Wireshark: The world's most popular network protocol analyzer

www.wireshark.org

- 패킷 1

송신지 포트 : 49859

수신지 포트 : 80

Sequence Number : 3588415412

SYN : 1

ACK : 0

- 패킷 2

송신지 포트 : 49859

수신지 포트 : 80

Sequence Number : 35884154123

확인 응답 번호: 697411256

SYN : 1

ACK : 1

- 패킷 3

송신지 포트 : 49859

수신지 포트 : 80

Sequence Number : 3588415413

확인 응답 번호: 697411257

SYN : 0

ACK : 1

TCP 3-way handshake

1. 호스트 A -> B (SYN)

2. 호스트 B -> A (ACK 의 ACK Number)

3. 호스트 A의 SYN 패킷의 Sequence Number 3588415412

즉 3588415412 + 1 = 3588415413

TLS 1.3 핸드셰이크
ServerHello

혼공단 혼공네트워크 회고

사람은 망각의 동물이라 한번 더 공부하길 잘했다는 생각이 든다. 6주가 굉장히 길어 보였지만 어느새 끝이 나있다.

겨울에 진행했었던 혼공컴운에서 굉장히 좋은 기억이 있어서 또 신청을 했는데 마침 네트워크에 대해서 더 알고 싶지만 마땅한 동기 부여가 없어서 아쉬운 그 시점에 메일이 한통 왔다.

12기 혼공학습단 모집!

잘할 수 있을까 라는 생각도 있었지만 그냥 해보기로 했다. 시작이 반이라는 말을 믿고 해 봤다.

전반적인 네트워크의 흐름, 이유 등을 알 수 있었던 시간으로 많은 도움이 되었다. 아쉬운 점으로는 조금 더 깊이 있게 공부했으면 좋았겠지만 시간을 많이 투자하지 못했다. 항상 공부하고 나중에 보면서 정리하자라는 말로 넘어갔는데 이번에도 비슷하게 한 것 같아 아쉽다.

다음에는 좀 더 나은 모습의 내가 되었으면 좋겠다.

오늘의 나는 어제의 나보다 더 나았는지 생각해 보면서 회고를 마치겠습니다.

감사합니다 혼공족장님!

(정리좀 하자)

[혼공학습단 12기] 혼자 공부하는 네트워크 - 5주차

sangkins — Sun, 4 Aug 2024 22:51:11 +0900

시작한 지 얼마 되지도 않은 것 같은 혼공학습단 12기도 얼추 75%를 넘겼다 혼자 공부하는 네트워크는 이미 한번 읽었던 책이라 좀 더 수월하게 할 수 있었던 것 같다.

이번주에는 OSI 7계층 중 7계층에 해당하는 응용 계층에 대해서 알아봤습니다.

응용 계층의 첫번째 챕터는 DNS와 자원이다.

통신을 하기 위해서는 IP주소 이외에 도메인 네임을 사용할 수 있다.

URL : 위치 기반의 식별자

URN : 이름 기반의 식별자

도메인 네임과 네임서버

도메인 네임과 IP는 네임서버에서 관리 (DNS 서버)

도메인 네임은 계층적으로 분류된다.

1. root 도메인

2. TLD 도메인

3. SLD 도메인

전체 주소 도메인 : FQDN

이렇게 계층적이고 분산된 도메인 네임에 대한 관리 체계를 도메인 네임 시스템이라고 한다.

계층적 네임 서버

도메인 네임 리졸빙

로컬 네임 서버 : 클라이언트와 맞닿아 있는 네임 서버

공개 DNS 서버 : 구글 8.8.8.8 , 클라우드 플레어 1.1.1.1 (ISP에서 할당하는 게 아님)

루트 네임 서버 : 질의에 대해 TLD 네임 서버 IP 반환

TLD 네임 서버 : 그 하위 반환

책임 네임 서버 : 특정 도메인 영역을 관리하는 서버 (naver, google, github...)

네임 서버는 DNS 레코드 타입이라고 하는 정보를 저장하고 관리한다.

레코드 유형	설명
A	특정 호스트에 대한 도메인 네임과 IPv4 주소와의 대응 관계
AAAA	특정 호스트에 대한 도메인 네임과 IPv6 주소와의 대응 관계
CNAME	호스트 네임에 대한 별칭 지정
NS	특정 호스트의 IP 주소를 찾을 수 있는 네임 서버
MX	해당 도메인과 연동되어 있는 메일 서버

도메인 네임 리졸빙 과정

- 재귀적 질의

- 반복적 질의

응답받은 결과를 임시로 저장 : DNS 캐시 (TTL 적용)

자원을 식별하는 URI

자원 : 네트워크상의 메시지를 통해 주고받는 대상.

URI : 자원을 식별할 수 있는 정보
URI, URN: 위치, 이름으로 식별

URL

scheme : 자원에 접근하는 방법
authority : 호스트를 특정할 수 있는 정보
path : 자원이 위치한 경로
query : 쿼리 parameter
frament : 자원의 특정 조각을 지칭

URN

위치와 무관하게 자원을 식별할 수 있다. 널리 채택된 방식이 아님.

HTTP

응용 계층에서 정보를 주고받는 데 사용되는 프로토콜

요청-응답 기반 프로토콜
미디어 독립적 프로토콜
스테이트리스 프로토콜
지속 연결 프로토콜

HTTP 메시지 구조

시작 라인(start-line)
method(POST, GET...)
request-target
HTTP-version

응답인 경우

status-line
HTTP-version
status code
reason phrase

필드 라인

HTTP 헤더 (header-line)

헤더 이름
헤더 값
메시지 본문

HTTP 메서드: 다양한 종류가 있다 (POST, GET)

HTTP 상태코드 : 100 ~ 500까지 다양하다.

HTTP 헤더와 HTTP 기반 기술

HTTP 헤더

Host
User-Agent
Referer
Authorization

응답 시 활용되는 HTTP 헤더

Server
Allow
Retry-after
Location
WWW-authenticate

요청과 응답 모두에서 활용되는 HTTP 헤더

Date
Connection
Content-length
Content-Type, Content-Language, Content-Encoding

캐시

불필요한 대역폭 낭비와 응답 지연을 방지하기 위해 사본을 임시로 저장하는 기술

저장위치

웹 브라우저 : 개인 전용 캐시

서버 : 공용 캐시

쿠키

서버에서 생성되어 클라이언트 측에 저장되는 데이터로 상태를 유지하지 않는 HTTP의 특성을 보완하기 위한 수단

콘텐츠 협상과 표현

가장 적합한 형태의 자원을 제공하는 메커니즘 즉 같은 URI에 대해 가장 적합한 자원의 표현을 제공하는 메커니즘

http://www.example.com에서 루트 도메인은. TLD가 com

HTTP 상태코드 300은 리다이렉션 관련 상태 코드입니다.

[혼공학습단 12기] 혼자 공부하는 네트워크 - 4주차

sangkins — Wed, 24 Jul 2024 21:40:18 +0900

전송계층

- 목차
1. 전송 계층 개요: IP의 한계와 포트

2. TCP와 UDP

3. TCP의 오류, 흐름, 혼잡 제어

정리를 위한 정리를 하지 말자....

신뢰할 수 없는 통신과 비연결형 통신

- 패킷이 제대로 도착했는지 확인 하는지 유무에 따라서 나뉜다.

연결형 통신 : 신뢰 O

비연결형 통신 : 신뢰 X

전송 계층은 연결형 통신을 가능하게 한다, 신뢰성 있는 통신을 가능하게 한다 : TCP

신뢰할 수 없는 통신, 비연결형 통신 : UDP

패킷에 특정 어플리케이션 식별할 수 있는 정보 : PORT

Port 정보는 잘 알려진 포트 80, 8080, 443, 22 와 같은 포트들은 0 ~ 1023 내의 범위에 주로 분포되어 있다.

특정 어플리케이션을 지칭하기 위해서 포통 IP:PORT 15.143.22.11:18801 같은 방식으로 나타낼 수 있다.

NAT : 사설 IP 주소와 공인 IP 주소를 변환

- NAT 변환 테이블 : 변환의 대상이 되는 IP 주소가 쌍으로 명시되어 있다.

- 포트기반의 NAT [NAPT (APT)] : 하나의 공인 IP주소를 여러 사설 IP주소가 공유할 수 있도록 하는 NAT의 일종. (N : 1)의 관계가 가능하다.

굉장히 많이 사용하는 포트 포워딩

- 특정 호스트에 IP주소와 포트 번호를 미리 할당하고 해당 IP 주소:포트 번호로써 해당 호스트에게 패킷을 전달하는 기능

네트워크 내부의 서버를 외부에서 접속하는 경우에 사용된다.

- EX: 와이파이로 연결된 컴퓨터 중 하나를 특정해서 접속하는 경우에 사용

ICMP : ping

- ICMP 메시지를 얻기 위해 사용 (Ping)

TCP의 통신 단계와 세그먼트 구조

- 연결 수립

- 데이터 송수신

- 연결 종료

제어 비트

- ACK : 세그먼트의 승인을 나타내는 비트

- SYN : 연결 수립하기 위한 비트

- FIN : 연결 종료하기 위한 비트

송신지 포트			수신지 포트
순서 번호
확인 응답 번호
데이터 오프셋	예약	제어 비트	윈도우
체크섬			긴급 포인터
	옵션

제어비트

CWR

ECE

URG

ACK

PAH

RST

SYN

FIN

TCP 연결 수립과 종료

연결 수립 : 3-Way-Handshake

연결 종료 : FIN -> ACK -> FIN -> ACK

TCP는 상태를 유지한다는 점에서 Stateful 프로토콜이라고도 함.

UDP 데이터그램 구조

UDP는 상태를 유지하지 않는다는 점에서 Stateless 프로토콜이라고도 함

패킷이 손실되거나 순서가 바뀔 수 있다.

송신지 포트	수신지 포트
길이	체크섬

오류, 흐름, 혼잡 제어

- TCP의 신뢰성을 보장하기 위한 기능

오류 제어

- 오류 검출과 재전송: 중복된 ACK 세그먼트를 수신, 타임 아웃이 발생했을 때.

재전송 기법

- ARQ

Stop-and-Wait ARQ
Go-Back-N ARQ
Selective Repeat ARQ

흐름 제어

- 버퍼 overflow를 방지

슬라이딩 윈도우

- 윈도우 : 송신 호스트가 파이프라이닝할 수 있는 최대량

혼잡 제어

- 혼잡 윈도우의 크기를 정하는 혼잡 제어 알고리즘

AIMD(Additive Increase/Multiplicative Decrease) 합으로 증가, 곱으로 감소
Slow Start : 지수적인 증가 (Slow Start threshold) 임계치를 통해 조절
Congetsion avoidance : RTT마다 혼잡 윈도우를 1MSS 증가 시키는 알고리즘 (선형적으로 증가)
Fast recovery : 세번의 중복 ACK 세그먼트를 수신했을 때 느린 시작은 건너 띄고 혼잡 회피를 수행.

IP와 연관된 통신 특성으로 알맞은 단어는?
> 비신뢰성, 비연결형

> TCP 3-way handshake
> SYN -> SYN+ACK -> ACK

작업 관리자에서 프로세스별 PID 확인해 보기

[혼공학습단 12기] 혼자 공부하는 네트워크 - 3주차

sangkins — Tue, 16 Jul 2024 14:20:45 +0900

3주차 (7/15 ~ 7/21)	Chapter 03	Ch.03(03-1) 확인 문제 1번(p.147), (03-3) 확인 문제 2번(p.187) 풀고 설명하기	본인 컴퓨터의 IP 주소와 MAC 주소 파악해 보기

- 목차
1. LAN을 넘어서는 네트워크 계층

2. IP 주소

3. 라우팅

네트워크 계층

개요
- OSI 7계층 모델의 3계층에 해당.
- 데이터 링크 계층의 한계 : 물리 + 데이터 링크 계층만으로는 다른 네트워크까지의 도달 경로를 파악하기 어렵다.
  1. 최적의 경로로 패킷이 이동 : 라우팅 (라우팅을 수행하는 장치 : 라우터)
  2. MAC 주소만으로 모든 네트워크에 속한 호스트의 위치를 특정하기 어렵다.
- LAN을 넘어서는 서로 다른 네트워크 간의 통신을 가능하게 한다.
- 주요 프로토콜로 IP(Internet Protocol)가 있다.
IP 주소
- 네트워크 계층의 핵심 요소로, 호스트를 식별하는 논리적 주소.
- DHCP 프로토콜을 통해 자동으로 할당받거나 직접 할당할 수 있다.
- IPv4(32비트)와 IPv6(128비트) 두 가지 버전이 사용된다.
- 네트워크 부분과 호스트 부분으로 구성된다.
- MTU : 한 번에 전송 가능한 IP 패킷의 최대 크기 (1500 바이트)
- IP 주소 지정, IP 단편화 기능
  IP 주소 지정 : IP 주소를 바탕으로 송수신 대상을 지정하는 것
  IP 단편화 : 전송하고자 하는 패킷의 크기가 MTU 보다 클 경우 MTU 크기 이하의 복수의 패킷으로 나누는 것.
IP(Internet Protocol) 패킷 구조
- 헤더: 버전, 헤더 길이, 서비스 유형, 전체 길이, 식별자, 플래그, 프래그먼트 오프셋, TTL, 프로토콜, 헤더 체크섬, 출발지 IP 주소, 목적지 IP 주소, 옵션
- 페이로드: 상위 계층에서 전달받은 데이터

프레임 헤더				프레임 페이로드	트레일러
프리앰블	수신지 MAC 주소	송신지 MAC 주소	타입 / 길이	데이터	FCS

** 데이터 **

IPv4 패킷 헤더

IPv4 패킷 페이로드

버전

헤더길이

패킷길이

식별자

단편화 오프셋

TTL

프로토콜

헤더 체크섬

송신지
IP 주소

수신지
IP 주소

옵션

패딩

데이터

- 식별자 : 패킷에 할당된 번호

- 플래그 : 3개의 비트로 구성된 필드.

DF (Don't Fragment) -> 단편화 X

0 -> 단편화 수행

MF (More Fragment) 단편화된 패킷이 더있는지 확인 0이면 존재하지 않음, 1이면 존재

- 단편화 오프셋 : 패킷이 단편화되기 전 초기 데이터에서 몇 번째로 떨어진 패킷인지 나타냄

- TTL : 패킷의 수명을 의미 (패킷이 호스트, 라우터에 전달되는 거을 홉(hop)이라고 한다.

- 프로토콜 : 상위 계층의 프로토콜이 무엇인지 나타내는 필드

- 송신지, 수신지 IP 주소 : IPv4 주소

IPv6

IPv4 주소에 비해 IPv6의 주소는 무한히 많다.

구성

- 다음헤더

- 홉 제한

- 송신지 IP 주소

- 수신지 IP 주소

ARP (Address Resolution Protocol)

IP 주소를 MAC 주소로 변환하는 프로토콜.
같은 네트워크 내에서 통신할 때 사용.
요청 -> 응답 -> 테이블 갱신

IP주소

네트워크 주소와 호스트 주소
클래스풀 주소 체계
클래스리스 주소 체계
서브넷 마스크
서브네팅
서브넷 마스크 표기 CIDR

공인 IP 주소와 사설 IP 주소

공인 IP 주소
사설 IP 주소, NAT

정적 IP 주소와 동적 IP 주소

정적 할당
동적할당과 DHCP

라우팅

출발지에서 목적지까지 패킷을 전달하는 과정.
라우팅 테이블을 참조하여 최적의 경로를 선택.
정적 라우팅과 동적 라우팅 방식이 있다.
라우팅 프로토콜
- IGP와 EGP로 나뉨.
- RIP: 대표적인 거리 벡터 라우팅 프로토콜.
- OSPF: 대표적인 링크 상태 라우팅 프로토콜.

라우터

서로 다른 네트워크를 연결하는 3계층 장비.
라우팅 테이블을 기반으로 패킷을 전달.

서브넷팅

큰 네트워크를 작은 네트워크로 분할하는 기술.
네트워크 관리와 보안을 향상.
서브넷 마스크를 사용하여 구현.

NAT (Network Address Translation)

사설 IP 주소를 공인 IP 주소로 변환하는 기술.
IP 주소 부족 문제를 해결하고 내부 네트워크를 보호

ICMP (Internet Control Message Protocol)

IP 통신의 오류 보고 및 진단을 위한 프로토콜입니다.
ping등 네트워크 진단 도구에 사용.

DHCP (Dynamic Host Configuration Protocol)

호스트에게 IP 주소를 자동으로 할당하는 프로토콜.
IP 주소, 서브넷 마스크, 게이트웨이 주소 등을 제공

IPv4의 대표적인 기능 2가지
IP 주소 지정
IP 단편화

라우팅 프로토콜은 AS 내부에서 수행되는 IGP와 AS 외부에서 수행되는 EGP로 나뉩니다. RIP는 대표적인 거리 벡터 라우팅 프로토콜이고 OSPF는 대표적인 링크 상태 라우팅 프로토콜입니다.

본인 컴퓨터의 IP 주소와 MAC 주소 파악하기

윈도우: cmd에서 ipconfig /all 명령어 사용.
맥OS: 터미널에서 ifconfig 명령어 사용.

112.214.1xx.xx
52:0a:10:a1:xx:xx

윈도우와 리눅스에서 중복 폴더 일괄 제거 방법

sangkins — Mon, 15 Jul 2024 00:11:18 +0900

문제

루트 폴더부터 시작해 모든 하위 폴더에 있는 특정 이름의 폴더를 삭제해야 하는 상황이 생겨서 방법을 찾았다.

윈도우

삭제할 폴더 확인 
for /d /r . %d in (폴더명) do @if exist "%d" echo %d

자세히 확인
for /d /r . %d in (폴더명) do @if exist "%d" (
    echo Directory: %d
    dir "%d"
    echo.
)

삭제
for /d /r . %d in (폴더명) do @if exist "%d" rd /s /q "%d"

폴더명이 temp 라면.

for /d /r . %d in (temp) do @if exist "%d" echo %d

리눅스

첫번째 방법
find . -name "CVS" -type d -exec rm -rf {} +

두번째 방법
find . -name "CVS" -type d | xargs rm -rf

삭제할 폴더 확인
find . -name "CVS" -type d

이렇게 재귀적으로 반복되는 폴더를 쉽게 지울 수 있었다.

Chart.js 사용법 + DB 연동

sangkins — Sun, 14 Jul 2024 23:32:06 +0900

DB에서 값을 가져와서 시각적으로 보여주어야 하는 일이 생겼다.

다양한 차트를 지원하면서 MIT 라이센스 오픈 소스 라이브러리를 찾다보니 chart.js를 찾았다.

Chart.js는 다양한 차트를 지원하는 MIT 라이센스 오픈 소스 라이브러리로 다양한 차트를 지원한다.

바 차트 (Bar chart)
라인 차트 (Line chart)
도넛/파이 차트 (Doughnut/Pie chart)
레이더 차트 (Radar chart)
극좌표 차트 (Polar area chart)
버블 차트 (Bubble chart)
스캐터 차트 (Scatter chart)

사용할 차트는 도넛/파이 차트, 라인 차트, 바 차트를 사용하려고 한다.

Spring, MyBatis, JSP를 사용하는 MVC 프로젝트에서 DB에서 가져온 값을 Chart.js로 구현하는 방법

IntelliJ IDEA 2024.1, Oracle DB ,Amazon corretto 8, MyBatis, Spring4, jsp

Chart.js 초기 세팅

npm
CDN
jsDeliver
Github

다양한 방식이 있는데 Github에서 다운 받을 경우 빌드해야 하기 때문에 jsDeliver 에서 다운받았다.

이 중 jsDelivr를 통해 다운로드 받는 방법을 선택했습니다. jsDelivr 웹사이트에서 다운로드 버튼을 클릭하여 압축 파일을 받은 후, 압축을 해제하고 dist 폴더 안의 chart.umd.js 파일을 프로젝트의 resources/js 폴더에 추가했습니다.

chart.umd.js 를 js 폴더 아래에 두었다.

Spring, MyBatis, jsp를 사용하는 MVC 프로젝트에서 DB에서 가져온 값을 Chart.js 로 구현하는 것이 간단해 보였지만 공식메뉴얼에도 연동하는 방법에 대해서는 정확히 나와 있지 않아서 구현해 보았다.

<canvas id="doughnut-chart2"></canvas>

주의할 점 : 스크립트가 canvas 선언 밑으로 와야 한다.

chart.js Failed to create chart: can't acquire context from the given item

I never got into node so I am pretty sure I am doing something massively wrong here since I cannot find any info at all by googling. I have a django site and I wanted a JS charting library, I chose

stackoverflow.com

Make sure to declare the canvas tag in html before the script that creates the Chart.js object. Otherwise, the script executes and tries to find a reference to a canvas that doesn't exist. In the script, any of the following formats may be used to get a reference to the canvas, which is then passed to the Chart.js constructor.

DB 연동 전 차트가 제대로 그려지는지 확인하기 위해 샘플 데이터를 넣은 도넛 차트를 생성한다.

new Chart(document.getElementById("doughnut-chart"), {
    type: 'doughnut',
    data: {
      labels: ["SEND SUCCESS", "SEND FAIL", "TOTAL"],
      datasets: [
        {
          label: "CNT",
          backgroundColor: ["#3e95cd", "#8e5ea2","#3cba9f"],
          data: [5000,2340,7340]
        }
      ]
    },
    options: {
      title: {
        display: true,
        text: 'COUNT'
      }
    }
});

차트가 화면에 정상적으로 출력되는 것을 확인한다.

1. DB Table 생성 (Oracle)

create table status (TYPE VARCHAR2(50), CNT INT);

2. MyBatis Mapper 작성

<select id="selectSendCount" parameterType="java.util.HashMap" resultType="com.test.vo.GraphVO">
	select type, CNT  
    	from STATUS
</select>

3. 인터페이스 작성, 서비스 클래스 작성

public interface StatusDao {
    List<StatusDto> getStatusData();
}

public interface StatusDao {
    List<StatusDto> getStatusData();
}

@Service
public class StatusService {
    @Autowired
    private StatusDao statusDao;

    public List<StatusDto> getStatusData() {
        return statusDao.getStatusData();
    }
}

4. Controller 작성

@Controller
@RequestMapping("")
public class ChartController {
    @Autowired
    private StatusService statusService;

    @GetMapping("/chart")
    public String showChart(Model model) {
        List<StatusDto> statusData = statusService.getStatusData();
        model.addAttribute("statusData", statusData);
        return "chart";
    }
}

5. Jsp 페이지에서 Chart.js 사용

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<canvas id="doughnut-chart"></canvas>

<script>
    var statusData = [
        <c:forEach items="${statusData}" var="status" varStatus="loop">
            {
                type: "${status.type}",
                cnt: ${status.cnt}
            }<c:if test="${!loop.last}">,</c:if>
        </c:forEach>
    ];

    new Chart(document.getElementById("doughnut-chart"), {
        type: 'doughnut',
        data: {
            labels: statusData.map(item => item.type),
            datasets: [{
                label: "CNT",
                backgroundColor: ["#3e95cd", "#8e5ea2","#3cba9f"],
                data: statusData.map(item => item.cnt)
            }]
        },
        options: {
            title: {
                display: true,
                text: 'COUNT'
            }
        }
    });
</script>

이렇게 까지 하면 DB 에서 데이터를 가져와 차트에 표현하는 것을 볼 수 있었다.

DB에 데이터가 변경될 경우에만 가지고 오는 WebSocket 방식도 있지만 간단하게 ajax 요청으로 3초마다 요청하는 방법을 선택했다.

- WebSocket: 양방향 실시간 통신이 가능하며, 서버에서 데이터가 변경될 때만 클라이언트에 알릴 수 있다.

- Server-Sent Events (SSE): 서버에서 클라이언트로의 단방향 실시간 통신이 가능하다.

이 방법은 서버의 부하를 줄 수 있지만 다른 방법이 생각나지 않아 이렇게 사용했다.

차트를 업데이트하는 함수, 초기 차트 이렇게 구분지어서 5. Jsp 페이지에서 Chart.js 사용 을 Refactoring했다.

6. 변경된 Chart.js 사용

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<canvas id="doughnut-chart"></canvas>

<script>
    var chart;
    var chartDataUrl = '<c:url value="/chart-data"/>';

    function createChart(data) {
        chart = new Chart(document.getElementById("doughnut-chart"), {
            type: 'doughnut',
            data: {
                labels: data.map(item => item.type),
                datasets: [{
                    label: "CNT",
                    backgroundColor: ["#3e95cd", "#8e5ea2","#3cba9f"],
                    data: data.map(item => item.cnt)
                }]
            },
            options: {
                responsive: true,
                title: {
                    display: true,
                    text: 'COUNT'
                },
                legend: {
                    position: 'bottom'
                },
                animation: {
                    animateScale: true,
                    animateRotate: true
                }
            }
        });
    }

    function updateChart() {
        $.ajax({
            url: chartDataUrl,
            method: 'GET',
            success: function(data) {
                chart.data.labels = data.map(item => item.type);
                chart.data.datasets[0].data = data.map(item => item.cnt);
                chart.update();
            },
            error: function(error) {
                console.error('Error fetching chart data:', error);
                alert('차트 데이터를 불러오는 데 문제가 발생했습니다. 잠시 후 다시 시도해주세요.');
            }
        });
    }

    // 초기 차트 생성
    $.ajax({
        url: chartDataUrl,
        method: 'GET',
        success: function(data) {
            createChart(data);
            // 3초마다 차트 업데이트
            setInterval(updateChart, 3000);
        },
        error: function(error) {
            console.error('Error :', error);
        }
    });
</script>

setInterval은 서버의 부하를 고려해 적절히 설정해주어도 된다.

Controller 에서 Json 형식으로 데이터를 주고 받아도 된다. 그럴때는 VO 객체를 생성해서 JsonArray에 매핑해주면 된다.

커스텀해서 생성했지만 간단한 방법도 있다 (주석 참고).

 private static String convertGraphVOListToJson(ArrayList<GraphVO> list) {
        JSONArray jsonArray = new JSONArray();
        if (list != null) {
            Iterator<GraphVO> it = list.iterator();
            while (it.hasNext()) {
                GraphVO gVo = it.next();
                JSONObject obj = new JSONObject();
                obj.put("TYPE", gVo.getType());
                obj.put("COUNT", gVo.getCnt());
                jsonArray.add(obj);
            }
        }
        return jsonArray.toJSONString();
    }
    
    
    ************************** Spring **************************
    
    //Spring이 객체를 Json으로 변환
    @RestController
    public class ChartController {
        @GetMapping("/chart-data")
        public List<GraphVO> getChartData() {
            return statusService.getStatusData();
        }
    }
    
    ************************** Spring **************************

json으로 받는 경우 datasets -> data : cntList로 넣어주면 됩니다.

$.ajax({
	url: "../chart-data",
    type: "GET",
    dataType: "json",
    success: function(data) {
    let dataArray = data.statusData;
    for (let i = 1; i < dataArray.length; i++) {
    	cntList.push(dataArray[i].CNT);
    }
    ...............

window.onload 이후에 사용

//차트 Init 함수 (예시)
window.onload = initializeChart;

차트가 정상적으로 출력되는 것을 확인할 수 있다.

ORA-28040 No matching authentication protocol

sangkins — Sat, 13 Jul 2024 01:27:56 +0900

- Oracle Server와 Client 간의 버전 차이로 발생

SQLNET 파라미터 값을 수정하는 방법도 있다는데 간단하게 ojdbc 버전 변경으로 해결.

ojdbc6.jar -> ojdbc7.jar 수정

원인

Oracle 서버와 클라이언트 간의 버전 차이로 인해 발생.

서버와 클라이언트가 사용하는 인증 프로토콜이 일치하지 않을 때 나타난다.

보통 클라이언트 측의 JDBC 드라이버(ojdbc)가 서버 버전과 호환되지 않을 때 발생.

해결 방법

JDBC 드라이버 버전 업데이트:
- 가장 간단하고 효과적인 해결책은 클라이언트 측의 JDBC 드라이버를 서버 버전과 호환되는 최신 버전으로 업데이트.
- ojdbc6.jar에서 ojdbc7.jar로 변경하여 문제를 해결했다..
SQLNET 파라미터 수정 (대안적 방법):
- Oracle 서버의 SQLNET.ORA 파일에서 SQLNET.ALLOWED_LOGON_VERSION 파라미터를 수정하여 이전 버전의 인증 프로토콜을 허용.
- 보안상의 이유로 권장되지 않음.

JDBC 드라이버를 업데이트하면, 클라이언트와 서버 간의 인증 프로토콜 불일치 문제가 해결되어 ORA-28040 오류가 더 이상 발생하지 않음. 이를 통해 데이터베이스 연결이 정상적으로 이루어지고, 애플리케이션이 원활하게 작동.

주의사항

JDBC 드라이버 업데이트 시, 애플리케이션의 다른 부분과의 호환성을 확인하는 것이 중요.

[혼공학습단 12기] 혼자 공부하는 네트워크 - 2주차

sangkins — Wed, 10 Jul 2024 22:18:11 +0900

- 목차
1. 이더넷
2. NIC와 케이블

3. 허브

4. 스위치

1. 이더넷
   - 현대 유선 LAN 환경에서 가장 대중적으로 사용되는 네트워크 기술.
   - 송수신되는 프레임의 형태와 프레임을 주고받는 방법이 정의되어 있다.
   - 국제적으로 표준화된 단일 프로토콜입니다.

2. 통신 매체 표기
   - 전송속도: 숫자만 있으면 Mbps, 숫자 뒤에 G가 붙으면 Gbps를 의미한다.
   - BASE: 베이스밴드의 약자로, 변조 타입을 나타낸다. 다른 변조 타입으로는 BROADBand, PASSband가 있다.
   - 추가 특성: 전송 가능한 최대 거리, 물리 계층 인코딩 방식, 레인 수 등을 명시한다.
   - 매체 종류: C(동축 케이블), T(트위스티드 페어 케이블), S(단파장 광섬유 케이블), L(장파장 광섬유 케이블)

3. 이더넷 프레임 구조
   - 헤더:
     - 프리앰블: 프레임의 시작을 알리는 8바이트 크기의 정보, 송수신지 간 동기화에 사용된다.
     - 수신/송신 MAC 주소: 각 6바이트 길이로, LAN 내 수신지와 송신지를 특정한다.
     - 타입/길이: 1500 이하면 프레임 크기, 1536 이상이면 타입(이더 타입)을 나타낸다.
   - 페이로드: 상위 계층에서 전달받은 데이터, 최대 1500바이트.
   - 트레일러: FCS(Frame Check Sequence), CRC를 이용한 오류 검출에 사용된다.

헤더				페이로드	트레일러
프리앰블	수신지 MAC 주소	송신지 MAC 주소	타입/길이	데이터	FCS
8 byte	6 byte	6 byte	2 byte	46 ~ 1500 byte	4 byte

4. MAC 주소
   - 네트워크 인터페이스마다 부여되는 6바이트 길이의 물리적 주소.
   - 일반적으로 고유하며 변경되지 않음.

5. NIC와 케이블
   - NIC(Network Interface Card): 호스트와 통신 매체를 연결하고 MAC 주소가 부여되는 장비.
   - 주요 케이블: 트위스티드 페어 케이블(전기 신호 사용), 광섬유 케이블(빛 신호 사용)

6. 트위스티드 페어 케이블
   - 실드에 따른 분류:
     STP(브레이드 실드),
     FTP(포일 실드),
     UTP(실드 없음)
   - 카테고리(Cat)에 따라 성능이 다르다.

7. 광섬유 케이블

- 구성 : 코어(빛이 흐르는 부분), 클래딩(빛이 코어 안에서만 흐르도록 코어를 둘러싼 부분)
   - 싱글 모드: 장거리 전송에 적합하지만 비용이 높다. 단파장
   - 멀티 모드: 비교적 근거리 연결에 적합. 장파장

8. 허브
   - 여러 대의 호스트를 연결하는 장치로, 리피터 허브라고도 한다.
   - 반이중 모드로 통신하며, 받은 신호를 모든 포트로 그대로 재전송.
   - 충돌을 피하기 위해 CSMA/CD 프로토콜을 사용한다.

- 캐리어 감지 (CS)

- 다중 접근 (MA)

- 충돌 검출 (CD)

9. 스위치

- 데이터 링크 계층의 네트워크 장비
   - 허브와 달리 전이중 방식으로 통신.
   - MAC 주소를 학습할 수 있어 L2 스위치라고도 한다.
   - 주요 기능:
     - 플러딩: 모든 포트로 프레임 전송
     - 포워딩/필터링: 프레임 전송 여부 결정
     - 에이징: 일정 시간 미사용 MAC 주소 삭제

VLAN(Virtual LAN)
    - 스위치의 기능으로 하나의 스위치로 여러 개의 가상 LAN을 구성하는 기술
    - 포트 기반 VLAN: 스위치의 포트가 VLAN을 결정
    - MAC 기반 VLAN: MAC 주소에 따라 VLAN이 결정
    - VLAN 트렁킹: 여러 VLAN 스위치를 효율적으로 연결하는 방법

Ch.02(02-1) 확인 문제 2번(p.87), (02-3)확인 문제 4번(p.111) 풀고 설명하기

헤더				페이로드	트레일러
ㄱ	수신지 MAC 주소	ㄴ	타입/길이	데이터	ㄷ
8 byte	6 byte	6 byte	2 byte	46 ~ 1500 byte	4 byte

ㄱ : 프리앰블 - 이더넷 프레임의 시작을 알리는 정보

ㄴ : 송신지 MAC 주소 - 수신지 MAC 주소 다음에는 송신지의 MAC 주소를 표시

ㄷ : 수신한 프레임에 오류가 있는지 확인하기 위한 필드

CSMA/CD 와 관련해 서로 맞는 용어

CS - 캐리어 감지

MA - 다중 접근

CD - 충돌 검출

집에 있는 케이블에 표기된 명칭 표기를 바탕으로 케이블 구조 및 전송속도 가늠해 보기

CAT.6 Twist-pair : 10Gbps 속도 예상

[혼공학습단 12기] 혼자 공부하는 네트워크 - 1주차

sangkins — Tue, 2 Jul 2024 23:58:08 +0900

컴퓨터 네트워크 시작하기

- 목차
1. 컴퓨터 네트워크를 알아야 하는 이유
2. 네트워크 거시적으로 살펴보기
3. 네트워크 미시적으로 살펴보기

네트워크의 기초: 개요와 중요성

컴퓨터 네트워크의 중요성
- 개발 과정에서 마주치는 다양한 네트워크 관련 문제
- 네트워크 지식: 개발의 필수적인 배경
네트워크의 거시적 관점
- 정의: 정보를 주고받는 장치들의 통신망
- 구성 요소: 호스트, 서버, 클라이언트, 네트워크 장비
- 인터넷: 네트워크들의 네트워크
- 범위에 따른 분류: LAN, MAN, WAN
- 메시지 교환 방식에 따른 분류 : 회선 교환 방식, 패킷 교환 방식
네트워크의 미시적 관점
- 주요 개념: 프로토콜, 네트워크 참조 모델(계층 모델), OSI 모델, 캡슐화
- OSI 7계층 모델: 이론적 설계를 위한 가이드라인
- TCP/IP 모델: 실용적 구현을 위한 참조 모델

OSI 7	TCP/IP
응용 계층	응용 계층
표현 계층
세션 계층
전송 계층	전송 계층
네트워크 계층	인터넷 계층
데이터 링크 계층	네트워크 엑세스 계층
물리 계층	네트워크 엑세스 계층

캡슐화, 역캡슐화

- 송신과정에서 캡슐화가 이루어지고 수신과정에서 역캡슐화가 이루어진다.

송신 과정에서 택배를 포장하고 수신 과정에서 택배를 뜯는다.

PDU : Protocol Data Unit

- 계층에서 사용하는 메시지 단위

- 상위 계층에서 전달받은 데이터에 현재 계층의 프로토콜 헤더 및 트레일러를 추가 == 현재 계층의 PDU

OSI 계층	PDU
응용 계층	데이터(data)
표현 계층
세션 계층
전송 계층	세그먼트 (segment) 데이터그램 (datagram)
네트워크 계층	패킷 (packet)
데이터 링크 계층	프레임 (frame)
물리 계층	비트(bit)

개발을 하다보면 401, 404, 500, 502 와 같은 에러들을 끝도 없이 만나게 되는데 이러한 에러들이 무엇인지. Get 요청? Post 요청이 무엇인지 명확히 알 수 없다. 개발을 하기 위한 Background가 네트워크라고 생각한다.

네트워크는 여러 장치가 연결되어 정보를 교환하는 통신 체계로 다양한 에러 코드와 HTTP 요청 방식을 이해하는 데 도움이 됩니다. 네트워크는 거시적으로 물리적 구성요소들로 이루어져 있고, 미시적으로는 통신 규칙과 모델들로 구성되고. OSI 모델과 TCP/IP 모델은 엄격한 규칙이 아닌 참조 가이드라인으로, 네트워크 통신의 이해와 구현에 도움을 줍니다.

기본 미션

OSI 모델과 TCP/IP 모델은 가이드라인과 같아서 네트워크의 주체가 아니다 즉. 정해진 법규나 규칙이 아니다.
즉 OSI 7계층 모델은 이론적 설계를 위한 목적, TCP/IP 모델은 실용적 구현을 위한 참조에 가깝다.

선택 미션

네트워크에 대한 설명으로 옳지 않은 것은?

- 네트워크에 대한 이해는 프로그램을 만드는 과정에 도움을 준다.

네트워크 참조 모델에 대한 설명으로 옳지 않은 것은?

- TCP/IP 모델은 4개의 계층으로 통신 과정을 구분한다.

[리뷰] 하루 3분 세상에서 가장 쉬운 IT 수업

sangkins — Sat, 2 Mar 2024 22:41:33 +0900

일반인의 입장에서 간결하고 명확하게 표현한 책이라고 하는 게 정확하다.

알면 알수록 딥하게 들어가는 IT 기술을, 명확한 예시와 설명을 통해서 짧고 간결하게 설명을 해준다.

개발자로 종사하고 있지만 모든 분야를 알 수 없듯이 책 한 권을 통해서 최소한의 IT 상식을 가지게 해 줄 수 있다는 점에서

비전공자, 개발자가 있지만 그 중에서 주니어 개발자들에게 필요한 책이다

예시를 통해서 설명하고 궁금증까지 자연스럽게 연결하는 책의 흐름 속에서 끝까지 읽지 않고 책을 덮을 수 없었다.

하루 3분. 누군가에게는 가장 필요한 3분이 될 수도 있을 듯 하다.

하루 3분, 세상에서 가장 쉬운 IT 수업 | 장종원 - 교보문고

하루 3분, 세상에서 가장 쉬운 IT 수업 | 우리 삶에 꼭 필요한 IT 생존 지식!개발자나 IT 기업 종사자가 아니더라도, 일상생활에서 자주 접하는 IT 기초 지식은 알고 있어야 합니다. 특히 AI 시대가

product.kyobobook.co.kr

한빛미디어 [혼공학습단 11기]

sangkins — Wed, 21 Feb 2024 23:40:57 +0900

나는 리뷰어다를 통해 한빛미디어를 알게 된 이후 혼공학습단에 참여하게 되었습니다. 개발자로서 부족하다고 느꼈던 CS와 OS를 다시 되짚어보고자 해서 혼자 공부하는 컴퓨터 구조 운영체제를 선택했습니다.

6주라는 길다면 길고 짧다면 짧은 시간이 흘렀습니다

강민철 저자님의 인프런 무료 강의를 통해 혼공컴운을 학습하는 경험은 도움이 되었고. 이를 통해 더 나은 개발자로 성장할 수 있다는 자신감을 갖게 되었습니다. 명절 연휴가 끝나고 나 자신을 돌아보면서 더 이상 게으르게 지내고 싶지 않다는 다짐을 했습니다.

혼공학습단에 참여하지 않았다면 더 많은 후회를 했을 것 같습니다. 마지막 주차를 제출하면서, 전 주차에 언급한 내용을 나만의 언어로 다시 정리하지 않은 것이 아쉽습니다. 그러나 혼공학습단을 통해 우수혼공족으로 선정되거나 족장님의 댓글들도 좋았습니다

혼공학습단이 끝나도 아쉬움과 함께 끝없는 자격증 시험과 업무들이 기다리고 있습니다.

그러나 이러한 경험들이 개발자로서 더 나은 기회를 얻을 수 있을 것이라고 믿습니다.

동기부여만으로도 혼공학습단 11기는 성공적이었다고 자부할 수 있습니다.

혼자 공부하는 컴퓨터 구조+운영체제

어려운 컴퓨터 구조와 운영체제의 원리를 누구나 쉽게 이해할 수 있도록 용어와 개념은 한 번 더 풀어쓰고, 적절한 예시와 이해하기 쉬운 그림으로 재미있게 구성했다. 또한 일상 소재를 활용한

m.hanbit.co.kr

[지금 무료] 개발자를 위한 컴퓨터공학 1: 혼자 공부하는 컴퓨터구조 + 운영체제 강의 - 인프런

베스트셀러 『혼자 공부하는 컴퓨터 구조 + 운영체제』 저자 무료 직강. 개발자들이 꼭 알아야 할 컴퓨터 구조, 운영체제 전공서 요약집., 개발자 필수지식 컴퓨터 구조와 운영체제강의 하나로

www.inflearn.com

[혼공컴운] 6주차 Chapter 14 ~ 15 가상메모리,파일 시스템 혼공학습단 갈무리

sangkins — Mon, 12 Feb 2024 17:23:42 +0900

500 페이지에 달하는 혼공컴운 책을 6주에 걸쳐서 마무리하게 되었습니다.

짧으면 짧고 길면 긴 시간인 6주동안 공부하게 된 건 혼공학습단의 도움이 컸던 것 같습니다

2024 나는리뷰어다 에서 아쉽게 선정되지 못했지만 25년에도 다시 한번 도전해 보려고 합니다.

한빛미디어에서 좋은 책과, 스터디로 좋은 영향을 받은 것 같습니다.

✅혼자 공부하는 컴퓨터 구조+운영체제

#혼공학습단 #혼공 #혼공컴운

#	진도	기본 미션	선택 미션
1주차 (1/2 ~ 1/7)	Chapter 01 ~ 03	p. 51의 확인 문제 3번, p. 65의 확인 문제 3번 풀고 인증하기	p. 100의 스택과 큐의 개념을 정리하기
2주차 (1/8 ~ 1/14)	Chapter 04 ~ 05	p. 125의 확인 문제 2번, p. 155의 확인 문제 4번 풀고 인증하기	Ch.05(05-1) 코어와 스레드, 멀티 코어와 멀티 스레드의 개념을 정리하기
3주차 (1/15 ~ 1/21)	Chapter 06 ~ 08	p. 185의 확인 문제 3번, p. 205의 확인 문제 1번 풀고 인증하기	Ch.07(07-1) RAID의 정의와 종류를 간단히 정리해 보기
4주차 (1/22 ~ 1/28)	Chapter 09 ~ 11	p. 304의 확인 문제 1번 풀고 인증하기	Ch.11(11-2) 준비 큐에 A,B,C,D 순으로 삽입되었다고 가정했을 때, 선입 선처리 스케줄링 알고리즘을 적용하면 어떤 프로세스 순서대로 CPU를 할당받는지 풀어보기
5주차 (1/29 ~ 2/4)	Chapter 12 ~ 13	p. 363의 확인 문제 1번 풀고 인증하기	Ch.12(12-1) 임계 구역, 상호 배제 개념을 정리하기
6주차 (2/5 ~ 2/12)	Chapter 14 ~ 15	p. 400의 확인 문제 1번 풀고 인증하기	Ch.14(14-3) 프로세스가 사용할 수 있는 프레임이 3개 있고, 페이지 참조열이 '2313523423' 일 때 LRU 페이지 교체 알고리즘으로 이 페이지를 참조한다면 몇 번의 페이지 폴트가 발생하는지 풀어보기

Chapter 14 가상 메모리
14-1 연속 메모리 할당
14-2 페이징을 통한 가상 메모리 관리
14-3 페이지 교체와 프레임 할당
Chapter 15 파일 시스템
15-1 파일과 디렉터리
15-2 파일 시스템

14. 가상 메모리

14 - 1 연속 메모리 할당

앞에서는 메모리를 연속적으로 배치하는 상황에 대해서 배웠습니다.

프로세스를 연속적인 메모리 공간을 할당하는 방법 (연속 메모리 할당), 고려해야 할 점, 잠재적인 문제를 알아보겠습니다.

스와핑

메모리에 적재된 프로세스들 중 현재 실행되지 않는 프로세스가 있을 수 있다. 이러한 프로세스들을 보조기억장치의 스왑영역으로 이동하고, 메모리의 빈 공간에 다른 프로세스를 적재하여 실행하는 방식. 메모리 최적화라고 생각할 수도 있을 것 같다

메모리 밖으로 나가는 것을 스왑 아웃, 메모리로 들어오는 것을 스왑 인 이라고 한다.

메모리 할당

프로세스는 메모리 내의 빈공간에 적절히 적재되어야 합니다. 프로세스를 연속적으로 할당하는 방식은

최초 적합, 최적 적합, 최악 적합의 세 가지 방식이 있습니다.

최초 적합 : 프로세스의 진입 순서대로 메모리에 적재

최적 적합 : 프로세스가 적재될 수 있는 공간중 가장 작은 공간에 적재

최악 적합 : 프로세스가 적재될 수 있는 공간중 가장 큰 공간에 적재

연속 메모리 할당은 적합한 방법이라고 생각할 수 있지만 모든 프로세스의 크기가 동일하지 않고 시간이 다르다는 것을 생각해 보면

문제점을 발견할 수 있습니다.

이러한 상황 속에서 프로세스를 할당하기 어려울 만큼 작은 메모리 공간들로 인해 메모리가 낭비되는 현상을 외부 단편화라고 합니다.

14 - 2 페이징을 통한 가상 메모리 관리

앞서 프로세스를 메모리에 연속적으로 할당하는 방법은 외부 단편화를 일으킬 수 있고, 실제 메모리보다 더 큰 프로세스를 실행할 수 없다는 점이 있습니다.

예를 들어 LOL이라는 게임이 최소 8GB 메모리를 필요로 한다면 4GB 컴퓨터에서는 실행할 수 없는 것입니다.

이렇게 난 실제 메모리가 적은데 더 큰 프로세스를 실행할 수 있게 해주는 기술이 가상 메모리입니다.

가상 메모리 관리 기법에는 페이징, 세그멘테이션이 있습니다.

페이징이란

외부 단편화의 발생원인은 서로 다른 크기의 프로세스가 메모리에 연속적으로 할당되었기 때문에 발생했습니다.

메모리와 프로세스를 일정한 단위로 자르고, 불연속적으로 배치할 수 있다면 외부 단편화는 발생하지 않습니다.

일정한 단위로 나누고, 페이지를 프레임에 할당하는 가상 메모리 관리 기법이 바로 페이징입니다.

스와핑과 마찬가지로 보조기억장치와 메모리의 스왑을 페이징에서는 페이징 아웃, 페이징 인이라고 합니다.

페이지 테이블

페이징은 불연속적으로 배치한다고 했는데 CPU가 어떻게 위치를 찾을 수 있을까요?

프로세스의 주소를 저장하는 테이블을 페이지 테이블이라고 합니다.

논리주소와 물리주소의 위치를 저장하는 테이블이라고 생각하면 됩니다.

일정한 크기로 메모리와 프로세스를 나눈다고 했는데 남을 수 도 있습니다. 페이지의 크기를 조절하는 것도 하나의 방법이 될 수 있습니다.

프로세스마다 각자의 프로세스 테이블을 가지고 있고 프로세스의 페이지 테이블들은 메모리에 적재되어 있습니다.

CPU 내의 PTBR 이 각 프로세스의 페이지 테이블이 적재된 주소를 가리키고 있습니다.

이렇게 PTBR을 통해 메모리에 접근하면 메모리에 있는 페이지 테이블 보기 위해 반번, 프레임에 접근하기 위해 한번 이렇게 접근하기 때문에 2번의 메모리 접근이 일어납니다.

그래서 사용하는 게 TLB(Translation Lookaside Buffer)라는 페이지 테이블 캐시 메모리를 사용합니다. TLB는 참조 지역성의 원리에 근거해 최근에 사용된 페이지 위주로 가져와 저장합니다.

-- 참조지역성의 원리 --

사용하던 것을 더 사용하게 되는 원리라고 알고 계시면 됩니다.. 입던 옷만 입는 그런 느낌?

CPU에서 논리 주소에 대한 페이지 번호가 TLB 위에 있으면 TLB 히트, 없으면 TLB 미스 라고 합니다.

페이징에서의 주소 변환

하나의 페이지 혹은 프레임은 여러 주소를 가지고 있습니다. 특정 주소에 접근하려면 페이지 주소, 얼마나 떨어져 있는지에 대한 정보가 필요합니다.

페이징에서 논리 주소는 페이지 번호 + 변위

페이지 테이블 엔트리 : 페이지 테이블의 각각의 행들을 지칭합니다.

유효비트

페이지폴트

보호비트

참조비트

수정비트 (더티비트)

14 - 3 페이지 교체와 프레임 할당

요구 페이징의 개념과 페이징 교체 알고리즘, 프레임 할당

요구페이징

처음부터 모든 페이지를 적재하지 않고 필요한 페이지만을 메모리에 적재하는 기법

순수 요구 페이징 기법 : 아무런 페이지도 적재하지 않고 무작정 실행함 (페이징 폴트가 점점 낮아짐)

페이지 교체, 프레임 할당

쫓아낼 페이지를 결정하는 알고리즘 : 페이지 교체 알고리즘

페이지 폴트 횟수는 페이지 참조열을 통해 알 수 있음

FIFO 페이지 교체 알고리즘

2차 기회 페이지 교체 알고리즘

최적 페이지 교체 알고리즘

LRU

스래싱과 프레임 할당

스래싱 : 프로세스가 실제 실행되는 시간보다 페이징에 더 많은 시간을 소요하여 성능이 저하되는 문제

이러한 프레임 할당 방식에는 균등할당과 비례 할당이 있습니다.

균등 할당 : 모든 프로세스에 균등하게 프레임을 제공하는 방식입니다. 얼핏 보면 공정한 방법이라고 생각할 수 있지만 프로세스마다 크기가 다르기 때문에 비합리적이라고 생각할 수 있습니다.

비례 할당 : 프로세스의 크기에 비례해서 프레임을 할당하는 방식입니다. 하지만 실행 전에 얼마나 많은 프레임을 할당할지는 알 수 없기 때문에 결국 실행해 보아야 합니다.

프로세스의 실행을 보고 할당할 프레임 수를 결정하는 방법도 2가지 있습니다.

작업집합 모델 : 프로세스가 일정시간 동안 참조한 페이지의 크기만큼 프레임을 분배하는 방식

페이지 폴트 빈도 : 페이지 폴트율에 상한선과 하한선을 부여, 범위 내에서 프레임을 배분하는 방식

15. 파일 시스템

15 - 1 파일과 디렉터리

파일과 디렉터리는 운영체제 내부 파일 시스템이 관리하는 것입니다.

파일이란 HDD나 SSD 같은 보조기억장치에 저장된 관련 정보의 집합입니다.

파일 속성과 유형 : 크기, 생성일자, 최종 접근일자, 수정일자, 소유자, 생성자, 위치, 유형은 운영체제가 인식하는 파일 종류를 나타냅니다. (JPG, exe, c, java 등)

파일들을 관리하기 위해 디렉터리를 이용할 수 있습니다. 디렉터리 자체도 파일이라고 할 수 있습니다.

15 - 2 파일 시스템

파일 시스템은 파일과 디렉터리를 보조기억장치에 저장하고 접근할 수 있게 해주는 운영체제 내부 프로그램.

파일 시스템에는 다양한 종류가 있고 하나의 컴퓨터에서 다양한 여러 파일 시스템을 사용할 수 있습니다.

보조기억장치를 사용하려면 파티셔닝과 포맷팅을 거쳐야 합니다.

파티셔닝과 포매팅

파티셔닝(partitioning): 하드디스크 등 큰 저장장치를 여러 개의 논리적인 단위로 구획하는 작업

포매팅(formatting): 새로운 데이터를 쓸 수 있도록 파일의 저장 및 관리 방식을 설정하는 작업

파일 할당 방법

연속할당: 보조기억장치의 연속적인 블록에 순서대로 파일을 할당하는 방식

연결할당: 각 블록에 다음 블록의 주소를 저장하여 각 블록이 다음 블록을 가리키게 한 방식

색인할당: 모든 블록 주소를 하나의 색인블록에 모아 관리하는 방식

다양한 파일시스템 중 FAT, 유닉스 파일시스템에 대해서 알아보았습니다.

FAT 파일시스템(file allocation table file system): 연결할당 기반의 파일시스템으로 각 블록에 포함된
다음 블록주소들을 한데 모으는 파일할당테이블(FAT)을 이용하는 방식

유닉스 파일시스템(UNIX file system): 색인할당 기반의 파일시스템으로 모든 블록 주소를 한데 모으는
색인블록을 이용하는 방식

- 메모리 할당방식

최초적합: 최초 발견한 빈 공간에 프로세스를 배치하는 방식

최악적합: 프로세스가 적재될 수 있는 가장 큰 공간에 배치하는 방식

최적적합: 프로세스가 적재될 수 있는 가장 작은 공간에 배치하는 방식

프로세스가 사용할 수 있는 프레임이 3개 있고, 페이지 참조열이 2414523423일 때 페이지 폴트 발생 횟수

1. FIFO : 4번(5, 2, 3, 4)

2. 최적 : 2번(5, 2, 3), 3)

3. LRU : 4번(5, 2, 3, 4)

혼자 공부하는 컴퓨터 구조+운영체제

www.hanbit.co.kr

[혼공컴운] 5주차 Chapter 12 ~ 13 (동기화, 교착상태)

sangkins — Tue, 30 Jan 2024 22:42:49 +0900

✅혼자 공부하는 컴퓨터 구조+운영체제

#혼공학습단 #혼공 #혼공컴운

#	진도	기본 미션	선택 미션
1주차 (1/2 ~ 1/7)	Chapter 01 ~ 03	p. 51의 확인 문제 3번, p. 65의 확인 문제 3번 풀고 인증하기	p. 100의 스택과 큐의 개념을 정리하기
2주차 (1/8 ~ 1/14)	Chapter 04 ~ 05	p. 125의 확인 문제 2번, p. 155의 확인 문제 4번 풀고 인증하기	Ch.05(05-1) 코어와 스레드, 멀티 코어와 멀티 스레드의 개념을 정리하기
3주차 (1/15 ~ 1/21)	Chapter 06 ~ 08	p. 185의 확인 문제 3번, p. 205의 확인 문제 1번 풀고 인증하기	Ch.07(07-1) RAID의 정의와 종류를 간단히 정리해 보기
4주차 (1/22 ~ 1/28)	Chapter 09 ~ 11	p. 304의 확인 문제 1번 풀고 인증하기	Ch.11(11-2) 준비 큐에 A,B,C,D 순으로 삽입되었다고 가정했을 때, 선입 선처리 스케줄링 알고리즘을 적용하면 어떤 프로세스 순서대로 CPU를 할당받는지 풀어보기
5주차 (1/29 ~ 2/4)	Chapter 12 ~ 13	p. 363의 확인 문제 1번 풀고 인증하기	Ch.12(12-1) 임계 구역, 상호 배제 개념을 정리하기
6주차 (2/5 ~ 2/12)	Chapter 14 ~ 15	p. 400의 확인 문제 1번 풀고 인증하기	Ch.14(14-3) 프로세스가 사용할 수 있는 프레임이 3개 있고, 페이지 참조열이 '2313523423' 일 때 LRU 페이지 교체 알고리즘으로 이 페이지를 참조한다면 몇 번의 페이지 폴트가 발생하는지 풀어보기

짧은 시간에 이렇게 공부하는 건 혼공단의 도움이 컸던 것 같습니다!

나만의 언어로 정리하는 게 효과가 좋은 것 같습니다!

개발 공부를 어떻게 하면 좋을까요? 최선의 방법과 최악의 방법

혼공학습단을 10회 정도 운영하면서 여러분께 알려드리면 좋을 것 같은 내용이 있어 공유드립니다. 백엔드 개발자가 되기위해 열심히 공부 중인 개발자 지망생의 글인데요, 기록과 꾸준함의 중

hongong.hanbit.co.kr

마지막 6주차까지!

✅혼자 공부하는 컴퓨터 구조+운영체제
- 진도: Chapter 12 ~ 13
- 기본 미션: p. 363의 확인 문제 1번 풀고 인증하기
- 선택 미션: Ch.12(12-1) 임계 구역, 상호 배제 개념을 정리하기

12 - 1 프로세스 동기화

협력하여 실행되는 프로세스들은 실행 순서와 자원의 일관성을 보장해야 하기 때문에 반드시 동기화(Sync) 되어야 한다.

예를 들어서 구글의 클라우드나 애플의 i-cloud 같은 경우가 있습니다.

분명히 핸드폰으로 사진을 클라우드에 업로드했는데 컴퓨터에서 보았을 때는 업로드가 되어있지 않는 경우도 어떻게 보면 동기화 문제라고 할 수 있지 않을까요?

업로드가 전부 완료되지 않았는데 파일을 읽음으로써 동기화가 이루어지지 않은 것이라고 할 수 있습니다.

이게 바로 실행 순서 제어를 위한 동기화입니다.

동기화란 프로세스 (스레드) 사이의 수행시기를 맞추는 것을 의미합니다.

실행 순서 제어 : 프로세스를 올바른 순서대로 실행하는 것
상호 배제 : 동시에 접근해서는 안 되는 자원에 하나의 프로세스만 접근하는 것

실행 순서 제어를 위한 동기화

특정 조건을 만족해야만 실행을 이어나갈 수 있는 (Read, Write)처럼 동시에 실행되는 프로세스를 올바른 순서대로 실행하는 것.

상호 배제를 위한 동기화

공유가 불가능한 자원의 동시 사용을 피하기 위해 사용되는 알고리즘

은행의 입금과 출금같이 동기화가 제대로 이루어지지 않는 경우를 예시로 들 수 있습니다.

- 생산자와 소비자 문제

이와 같은 경우는 동시에 접근해서는 안 되는 자원에 동시에 접근했기 때문에 문제가 발생했습니다.

여기서 동시에 접근해서는 안 되는 자원이란?

공유 자원과 임계 구역

은행의 입금과 출금, 총합이라는 공동의 자원을 두고 작업을 했습니다. 이러한 자원을 공유 자원이라고 합니다.

동시에 실행하면 문제가 발생하는 자원에 접근하는 코드 영역을 임계 구역이라고 합니다.

잘못된 실행으로 동시에 임계 구역의 코드를 실행하여 문제가 발생하는 것을 레이스 컨디션이라고 합니다.

이러한 사례는 은행의 입출금, 생산자와 소비자 문제를 레이스 컨디션의 사례라고 할 수 있습니다.

레이스 컨디션이 발생하는 원인

- 고급 언어는 실행 과정에서 저급 언어로 변환되어 실행된다. 한 줄의 고급 언어는 여러 줄의 저급언어로 바뀝니다.

이러한 과정에서 문맥 교환이 발생합니다.

이러한 경우에 상호 배제를 위한 동기화는 두 개 이상의 프로세스가 임계 구역에 동시에 접근하지 못하도록 관리하는 것을 의미합니다.

임계 구역 문제의 세 가지 원칙

1. 상호 배제 : 한 프로세스가 임계 구역에 진입했다면 다른 프로세스는 임계 구역에 들어갈 수 없다.

2. 진행 : 임계 구역에 프로세스가 없다면 진입하고자 하는 프로세스는 접근 가능하다.

3. 유한 대기 : 한 프로세스가 임계 구역에 진입하고 싶다면 그 프로세스는 언젠가 임계 구역에 들어올 수 있어야 한다. ( 무한대기 X )

12-2 동기화 기법

이렇게 동시에 접근하면 안 되는 영역에 진입하게 하는 도구가 있습니다.

임계 구역에 오직 하나의 프로세스만 진입하게 하고, 올바른 실행 순서를 보장하는 대표적인 도구 세 가지가 있습니다.

1. 뮤텍스 락 (상호 배제를 위한 동기화 도구)

2. 세마포 (상호 배제 + 실행 순서 제어 동기화 도구)

3. 모니터

뮤텍스 락 (탈의실)

자물쇠 역할: 프로세스들이 공유하는 전역 변수 lock
임계 구역을 잠그는 역할 : acquire 함수
임계 구역의 잠금을 해제하는 역할 : release 함수
Busy Wait : 자원을 많이 먹는다.

세마포 (여러 개의 탈의실, 기차 신호)

임계 구역에 진입할 수 있는 프로세스의 개수 전역 변수 : S(다를 수 있음)
임계 구역에 들어가도 좋은지, 기다려야 할지를 알려주는 wait 함수
임계 구역 앞에서 기다리는 프로세스에 진입해도 된다고 알려주는 signal 함수

모니터

최근에 등장한 동기화 도구
공유 자원과 공유 자원에 접근하기 위한 인터페이스를 묶어서 관리
인터페이스를 통해서만 공유 자원에 접근
접근하고자 하는 프로세스를 큐에 넣어서 순서대로 공유 자원 제공, 상호 배제
실행 순서 제어를 위한 동기화에는 조건 변수를 사용
- 특정 프로세스가 아직 실행될 조건이 안 됐을 경우에는 wait를 통해 실행을 중단
- 특정 프로세스가 실행될 조건이 충족되었을 경우에는 signal을 통해 실행을 재개

13-1 교착 상태란?

프로세스를 실행하기 위해서는 자원이 필요합니다. 두 개 이상의 프로세스가 각자 가지고 있는 자원을 기다린다면 그 어떤 프로세스도 자원을 사용하지 못하는 교착 상태가 됩니다.

교착상태란 간단히 말해서 친구와 내가 있다면 친구가 먹고 있는 걸 나도 먹고 싶고 내가 먹고 있는걸 친구가 먹고 싶어 하는 상태입니다.

누구도 양보하지 않는다면 친구와 나는 서로의 것을 먹지 못합니다.

이러한 상태를 해결하는 방법과 그림으로 설명하는 기법에 대해서 알아보겠습니다.

이러한 교착상태를 설명하는 고전적인 문제 상황은 식사하는 철학자가 있습니다.

자원 할당 그래프

교착상태를 단순하게 표현할 수 있는 간단한 그래프

프로세스는 원, 자원의 종류는 사각형
사용할 수 있는 자원의 개수는 사각형 내에 점으로 표현
프로세스가 어떤 자원을 할당받아 사용 중이라면 자원에서 프로세스를 향해 화살표 표시
프로세스가 어떤 자원을 기다리고 있다면 프로세스에서 자원으로 화살표를 표시

교착 상태 발생 조건

상호 배제 : 한 프로세스에서 사용하는 자원을 다른 프로세스가 사용할 수 없는 상태
점유와 대기 : 자원을 할당받은 상태에서 다른 자원을 할당받기를 기다리는 상태
비선점 : 자원을 강제로 빼앗을 수 없음
원형 대기(환형 대기) : 요청 및 할당받은 자원이 원의 형태를 이룬다

13-2 교착 상태 해결 방법

교착 상태의 발생 조건을 전부 충족시키지 않는다면 교착상태는 발생하지 않습니다.

상호배제 : 모든 자원의 상호 배제를 없애기에는 어렵다 (프린터)

점유와 대기 : 특정 프로세스에 자원을 모두 할당, 아예 할당하지 않는 방법으로 자원의 할당률이 낮아진다

비선점 조건 : 모든 자원이 선점 가능한 것은 아니다. 비선점 조건을 없애 모든 자원을 뺴앗을 수 있도록 하는 건 범용성이 낮아짐

원형 대기 조건 : 자원에 번호를 붙이고, 오름차순으로 자원을 할당하면 원형 대기는 발생하지 않음

수많은 자원에 번호를 붙이고, 어떻게 활용하는가에 따라 특정 자원의 활용률이 떨어질 수 있음

교착 상태 회피

자원의 양을 고려하여 교착 상태가 발생하지 않을 정도의 자원을 배분하는 방식

안전상태 : 모든 프로세스가 정상적으로 자원을 할당받고 종료될 수 있는 상태 (안전 순서열 O)
불안정상태 : 교착 상태가 발생할 수 있는 상태 (안전 순서열 X)
안전순서열 : 교착 상태 없이 안전하게 프로세스들에게 자원을 할당할 수 있는 순서

교착 상태 검출 후 회복

교착 상태 발생 후 사후에 조치하는 방식

검출 후 회복 방식은 프로세스들이 자원을 요구할 때마다 할당하며, 교착 상태 발생 여부를 검사함.

교착 상태가 확인되면 다음과 같은 방식으로 회복함

선점을 통한 회복

해결될 때까지 자원을 몰아주는 방식

프로세스 강제 종료를 통한 회복

교착 상태가 없어질 때까지 한 프로세스씩 강제 종료, OR 모두 강제종료
전자는 오버헤드를 야기, 후자는 작업 내역을 잃게 될 가능성이 존재

교착상태를 아예 무시하는 타조 알고리즘도 있다. 최대 효율을 추구하는 엔지니어 입장에서는 이 방식이 적합할 때도 많다.

뮤텍스 락과 세마포에 대한 설명으로 옳지 않은 것을 고르세요.

뮤텍스 락은 임계 구역을 잠근 뒤 임계 구역에 진입함으로써 상호 배제를 위한 동기화를 이룹니다.
세마포는 공유 자원이 여러 개 있는 상황에서도 이용할 수 있습니다.
세마포를 이용해 프로세스 실행 순서 제어를 위한 동기화도 이룰 수 있습니다.
세마포를 이용하면 반드시 바쁜 대기를 해야 합니다.

반드시 Busy wait이 아니라 wait을 할 수 있습니다.

임계구역과 상호 배제

임계구역 : Race condition이 발생할 수 있는 코드 부분, 영역

임계구역의 문제를 해결하기 위한 3가지 조건

상호배제 : 특정 프로세스가 임계영역 내에서 실행중일 때, 다른 프로세스는 임계영역에 들어갈 수 없다.
진행 : 임계영역을 진행 중인 프로세스가 없을 경우에, 임계영역에 진입을 요구할 경우 유한한 시간 내에 진입해야 한다. 정당한 진입 프로세스를 막으면 안 된다.
한정된 대기 : 임계영역에 대한 진입의 요청을 했을 경우, 무한히 기다리지 않고 유한한 시간 내에 진입해야 한다.

상호배제

특정 프로세스가 공유자원을 사용하고 있을 경우, 다른 프로세스가 해당 공유 자원을 사용하지 못하게 제어하는 기법

혼자 공부하는 컴퓨터 구조+운영체제

www.hanbit.co.kr

[혼공컴운] 4주차 운영체제, 프로세스, 스레드, 스케쥴링에 대해서

sangkins — Fri, 26 Jan 2024 00:21:39 +0900

혼공학습단도 어느덧 4주차가 되었습니다. 해이해지지 않고 열심히 공부하도록 하겠습니다.

✅혼자 공부하는 컴퓨터 구조+운영체제

#혼공학습단 #혼공 #혼공컴운

#	진도	기본 미션	선택 미션
1주차 (1/2 ~ 1/7)	Chapter 01 ~ 03	p. 51의 확인 문제 3번, p. 65의 확인 문제 3번 풀고 인증하기	p. 100의 스택과 큐의 개념을 정리하기
2주차 (1/8 ~ 1/14)	Chapter 04 ~ 05	p. 125의 확인 문제 2번, p. 155의 확인 문제 4번 풀고 인증하기	Ch.05(05-1) 코어와 스레드, 멀티 코어와 멀티 스레드의 개념을 정리하기
3주차 (1/15 ~ 1/21)	Chapter 06 ~ 08	p. 185의 확인 문제 3번, p. 205의 확인 문제 1번 풀고 인증하기	Ch.07(07-1) RAID의 정의와 종류를 간단히 정리해 보기
4주차 (1/22 ~ 1/28)	Chapter 09 ~ 11	p. 304의 확인 문제 1번 풀고 인증하기	Ch.11(11-2) 준비 큐에 A,B,C,D 순으로 삽입되었다고 가정했을 때, 선입 선처리 스케줄링 알고리즘을 적용하면 어떤 프로세스 순서대로 CPU를 할당받는지 풀어보기
5주차 (1/29 ~ 2/4)	Chapter 12 ~ 13	p. 363의 확인 문제 1번 풀고 인증하기	Ch.12(12-1) 임계 구역, 상호 배제 개념을 정리하기
6주차 (2/5 ~ 2/12)	Chapter 14 ~ 15	p. 400의 확인 문제 1번 풀고 인증하기	Ch.14(14-3) 프로세스가 사용할 수 있는 프레임이 3개 있고, 페이지 참조열이 '2313523423' 일 때 LRU 페이지 교체 알고리즘으로 이 페이지를 참조한다면 몇 번의 페이지 폴트가 발생하는지 풀어보기

Chapter 09 운영체제 시작하기
09-1 운영체제를 알아야 하는 이유
09-2 운영체제의 큰 그림
Chapter 10 프로세스와 스레드
10-1 프로세스 개요
10-2 프로세스 상태와 계층 구조
10-3 스레드
Chapter 11 CPU 스케줄링
11-1 CPU 스케줄링 개요
11-2 CPU 스케줄링 알고리즘

운영체제란

Pixabay

프로그램 실행에 필요한 요소들을 자원이라고 하는데.

이러한 자원을 할당하고, 프로그램이 올바르게 실행되도록 돕는 프로그램을 OS(운영체제)라고 한다.

운영체제는 메모리 내 커널 영역에 저장되며, 커널 영역을 제외한 공간은 사용자 영역으로, 일반적인 프로그램들이 적재된다.

커널 영역에 있는 운영체제가 사용자 영역에 적재된 프로그램들에 자원을 할당하고 실행을 돕는 것이다.

위에서 이야기한 커널 영역에 대해서 알아보자. 앞으로 운영체제라 함은 대체로 커널을 지칭한다.

커널에 포함되지 않는 운영체제의 서비스에는 사용자 인터페이스가 있다.

사용자 인터페이스는 GUI, CLI 등이 있다.

운영체제는 응용 프로그램이 자원에 접근하려 할 때 오직 자신을 통해서만 접근하도록 하여 자원을 보호한다.

이때 이중 모드와 시스템 호출이 사용된다.

이중모드

CPU가 명령어를 실행하는 모드를 사용자 모드와 커널 모드로 구분하는 방식

사용자 모드 : 운영체제 서비스를 제공받을 수 없는 모드, 커널 영역 코드 실행 불가, 자원 접근 명령어 실행 불가

커널 모드: 운영체제 서비스를 제공받을 수 있는 모드, 커널 영역 코드 실행 가능, 자원 접근 가능

시스템 호출

사용자 모드에서 운영체제 서비스를 제공받기 위해 운영체제에 보내는 요청으로

일종의 소프트웨어 인터럽트

시스템 호츨 명령어 실행 시 CPU는 기존 작업을 백업, 커널에서 실행 후 다시 기존 작업으로 복귀

운영체제의 핵심 서비스

프로세스 관리
실행 중인 프로그램
자원 접근 및 할당
CPU, 메모리, 입출력장치
파일 시스템 관리
보조기억장치 데이터를 파일과 디렉토리로 관리하는 파일 시스템

프로세스와 스레드

프로세스 개요
실행 중인 프로그램을 프로세스 process라고 한다. 컴퓨터는 수많은 프로세스들이 실행되는데,
유닉스 체계의 운영체제에서는 ps 명령어를 통해 실행 중인 프로세스를 확인할 수 있다.

ps -ef

윈도우 운영체제에서는 tasklist와 작업 관리자를 통해 확인할 수 있습니다.

tasklist

포그라운드 프로세스
- 사용자가 볼 수 있는 공간에서 실행되는 프로세스

백그라운드 프로세스

- 보이지 않는 공간에서 실행되는 프로세스

사용자와 상호작용하지 않고 정해진 작업을 수행하는 것을 데몬 daemon 이라 한다.

윈도우 운영체제에서는 서비스 service 라고 함.

프로세스 제어 블록

nanoslavic

프로세스와 관련된 정보를 저장하는 자료구조.
프로세스가 차례대로 돌아가며 한정된 시간만큼 CPU를 이용하기 위해 타이머 인터럽트가 사용되는데,
클럭 신호를 발생시키는 장치에 의해 주기적으로 타이머 인터럽트가 발생하면
프로세스가 자신의 차례를 양보하고 다음 차례가 올 때까지 기다린다.
그리고 이러한 작업을 하기 위해 운영체제는 프로세스와 관련된 정보를 저장하는 자료구조,
프로세스 제어 블록(PCB) process control block 을 이용한다.

PCB에는 해당 프로세스를 식별하기 위해 꼭 필요한 정보들이 포함되어 있으며, 커널 영역에 존재한다.
PCB에 담기는 정보는 운영체제마다 차이가 있지만 대표적으로 다음과 같은 것들이 있다.

프로세스 ID (PID)
- 프로세스를 식별하기 위해 부여하는 고유한 번호.
- 같은 프로그램도 두 번 실행하면 PID가 다른 두 개의 프로세스 생성.
레지스터 값
- 자신의 실행 차례가 돌아오면 복원할 레지스터 값들을 백업한 것.
프로세스 상태
- 프로세스가 CPU를 이용하고 있는지, 기다리고 있는지, 입출력장치를 사용하려 하는지 등의 정보.
CPU 스케줄링 정보
- 프로세스가 언제, 어떤 순서로 CPU를 할당받을지에 대한 정보.
메모리 관리 정보
- 프로세스가 어느 주소에 저장되어 있는지에 대한 정보.
베이스 레지스터, 한계 레지스터 값과 페이지 테이블 정보.

사용한 파일과 입출력장치 목록
- 어떤 입출력장치가 이 프로세스에 할당되었는지, 어떤 파일을 열었는지 등의 정보.

문맥 교환

어떤 프로세스가 실행되다가 다른 프로세스에게 CPU 자원을 양보하는 상황에서
이전 프로세스가 사용하던 레지스터 값, 메모리 정보 등 중간 정보를 백업해야 하는데
이처럼 프로세스 수행을 재개하기 위해 기억해야 할 중간 정보를 문맥 context 이라고 한다.
문맥은 CPU 사용 시간이 다 되거나 인터럽트가 발생하면 해당 프로세스의 PCB에 백업되며,
프로세스 수행이 재개될 때 PCB에 기록되어 있는 문맥을 복구한다.

이전 프로세스의 문맥을 해당 프로세스의 PCB에 백업하고
다음 프로세스의 문맥을 해당 프로세스의 PCB로부터 복구하여
새로운 프로세스를 실행하는 과정을 문맥 교환 context switch 이라고 한다.

문맥 교환이 자주 일어나는 만큼 빠르게 번갈아가며 수행되어 마치 동시에 실행되는 것처럼 보인다.

(CISC,RISC)

프로세스의 메모리 영역

하나의 프로세스는 사용자 영역에 크게 코드 영역, 데이터 영역, 힙 영역, 스택 영역으로 나뉘어 저장.
정적 할당 영역
- 프로그램이 실행되는 동안 크기가 변하지 않는 영역
코드 영역
- 텍스트 영역 text segment 이라고도 불린다.
- 기계어로 이루어진 명령어가 저장되는 읽기 전용 공간.
데이터 영역
- 전역 변수와 같이 프로그램이 실행되는 동안 유지할 데이터가 저장되는 공간.
동적 할당 영역
- 프로그램이 실행되는 동안 크기가 변할 수 있는 영역
힙 영역
- 프로그래머가 직접 할당할 수 있는 공간.
- 프로그래밍 과정에서 힙 영역에 메모리 공간을 할당했다면 언젠가는 반환해야 한다.
- 반환하지 않는다면 메모리 낭비를 초래하게 되는데 이를 메모리 누수 memory leak 이라고 한다.
- 일반적으로 메모리의 낮은 주소에서 높은 주소로 할당.
스택 영역
- 잠깐 쓰다가 말 데이터를 일시적으로 저장하는 공간.
- 함수의 실행이 끝나면 사라지는 매개 변수, 지역 변수 등.
- 일시적으로 저장할 데이터를 PUSH, 더 이상 필요하지 않은 데이터를 POP.
- 일반적으로 메모리의 높은 주소에서 낮은 주소로 할당.

프로세스 상태와 계층 구조

여러 프로세스들이 빠르게 번갈아가며 실행되는 과정에서
각각의 프로세스는 여러 상태를 거치며 실행되며
그 상태는 PCB를 통해 인식되고 관리된다.

프로세스 상태 표현 방식은 운영체제마다 차이가 있지만 대표적인 상태는 다음과 같다.

- 생성 상태 new
이제 막 메모리에 적재되어 PCB를 할당받은 상태.
실행할 준비가 되면 준비 상태가 되어 CPU의 할당을 기다린다.

- 준비 상태 ready
당장이라도 CPU를 할당받아 실행할 수 있지만 자신의 차례가 아니기에 기다리고 있는 상태.
차례가 되면 CPU를 할당받아 실행 상태가 되는데, 이를 디스패치 dispatch 라고 한다.

- 실행 상태 running
CPU를 할당받아 실행 중인 상태.
타이머 인터럽트가 발생할 때까지 할당된 일정 시간 동안 CPU 사용 가능.
할당된 시간이 끝나면 다시 준비 상태가 되며, 입출력 작업 등을 기다려야 한다면 대기 상태가 된다.

- 대기 상태 blocked
실행 도중 입출력장치를 사용하여 해당 작업이 끝날 때까지 기다리는 상태.
입출력 작업이 완료되면 입출력 인터럽트를 받고 다시 준비 상태가 되어 CPU 할당을 기다린다.

- 종료 상태 terminated
프로세스가 종료된 상태.
PCB와 프로세스가 사용한 메모리 정리.
프로세스 상태를 도표로 정리한 프로세스 상태 다이어그램 process state diagram 이라고 한다.

프로세스는 실행 도중 시스템 호출을 통해 다른 프로세스를 생성할 수 있습니다.
이 때 생성의 주체가 되는 프로세스를 부모 프로세스 parent process 라고 하고
생성의 객체가 되는 프로세스를 자식 프로세스 child process 라고 합니다.

운영체제에 따라 자식 프로세스의 PCB에 부모 프로세스의 PID인 PPID parent PID 가 포함되기도 합니다.

많은 운영체제들은 컴퓨터가 부팅될 때 실행되는 최초의 프로세스가 자식 프로세스를 생성하고
생성된 자식 프로세스가 또 다시 자식 프로세스를 생성하여 트리 구조를 이루는
계층적인 프로세스 구조로 프로세스들을 관리합니다.ㅎ

부모 프로세스는 시스템 호출 fork를 통해 자신의 복사본을 자식 프로세스로 생성
자식 프로세스는 시스템 호출 exec을 통해 자신의 메모리 공간을 다른 프로그램으로 교체

fork를 통해 프로세스를 복제하면 시스템 자원을 그대로 복사한 후 PID와 메모리 주소만 다르고 동일한 내용이 할당됨.

exec은 자신의 메모리 공간에 새로운 프로램을 덮어쓰는 시스템 호출 코드 영역과 데이터 영역의 내용이 실행할 프로그램의 내용으로 바뀌고 나머지 영역은 초기화됨.

fork 후 자식 프로세스가 exec 을 하지 않으면 부모 프로세스와 동일한 코드를 병행하여 실행하게 됨 .

스레드

전통적인 관점에서 보면 하나의 프로세스는 한 번에 하나의 일을 처리.
스레드라는 개념이 도입되며 한 번에 여러 일을 처리할 수 있게 됨.

프로세스를 구성하는 실행 단위
프로세스 내에서 각기 다른 스레드 ID, 프로그램 카운터 값을 비롯한 레지스터 값, 스택으로 구성
힙, 데이터, 코드 영역 등 다른 프로세스 자원은 공유하고 기존의 한 번에 하나의 일만 처리하는 프로세스는 단일 스레드 프로세스라고 말한다.

멀티 프로세스 multi-process

여러 프로세스를 동시에 실행하는 것
프로세스끼리 자원을 공유하지 않음
프로세스끼리 영향력이 적다
IPC, 공유 메모리 등으로 통신은 가능하지만 까다로움

멀티 스레드

프로세스 내에 여러 스레드를 동시에 실행하는 것
스레드끼리 프로세스 자원을 공유한다
멀티 프로세스보다 메모리를 더 효율적으로 사용 가능
통신에 유리

CPU 스케줄링

공정하고 합리적으로 CPU 자우너을 할당하기 위해 운영체제는 어떤 프로세스에 CPU를 할당할지, 어떤 프로세스를 기다리게 할지를 결정합니다.

프로세스마다 우선순위가 다르기 때문에 각각의 상황에 맞게 CPU를 배분하는 방법이라고 생각하면 됩니다.

입출력 집중 프로세스
입출력 작업이 많은 프로세스.
대표적으로 비디오 재생이나 디스크 백업 작업 등을 담당하는 프로세스

CPU 집중 프로세스

CPU 작업이 많은 프로세스.
대표적으로 복잡한 수학 연산, 컴파일, 그래픽 처리 작업 등을 담당하는 프로세스
입출력 집중 프로세스와 CPU 집중 프로세스가 동시에 CPU 자원을 요구할 경우 입출력 집중 프로세스를 먼저 실행하여 입출력장치를 끊임없이 작동시키고 해당 프로세스가 입출력 작업을 하며 대기 상태로 존재하는 동안 CPU 집중 프로세스에 CPU를 집중적으로 할당하는 것이 효율적입니다.

운영체제는 프로세스마다 PCB에 우선순위를 부여하고 이를 기반으로 먼저 처리할 프로세스를 결정하는데
매번 PCB를 확인하는 것은 비효율적입니다.
따라서 프로세스의 상태별로 우선순위에 따라 줄을 세워두고 순서를 결정하는데 이 줄을 스케줄링 큐라고 합니다.
자료구조의 관점에서 FIFO 구조 이지만 반드시 선입선출일 필요는 없습니다.

준비 큐
CPU를 이용하고 싶은 프로세스들이 줄을 서는 스케줄링 큐

대기 큐
입출력장치를 이용하기 위해 대기 상태에 접어든 프로세스들이 줄을 서는 스케줄링 큐
특정 입출력장치별로 대기 큐가 존재(CPU, 하드 디스크, 프린터)
입출력이 완료되어 완료 인터럽트 발생 시 대기 큐에서 제거되고 준비 큐로 이동

프로세스가 실행되고 있을때 우선순위가 높은 프로세스가 오면 중단 하고 실행하느냐, 끝나고 실행하느냐에 따라 2가지 방법이 있습니다.

선점형 스케줄링 preemptive scheduling
프로세스가 시스템 자원을 사용하고 있더라도 운영체제가 강제로 빼앗아 다른 프로세스에게 할당 가능
어느 하나의 프로세스가 자원 사용을 독점할 수 없는 방식
대부분의 운영체제에서 사용하고 있는 방식
프로세스들에 골고루 자원을 배분할 수 있습니다. 문맥 교환 과정에서의 오버헤드가 발생합니다.

비선점형 스케줄링 non-preemptive scheduling
프로세스가 종료되거나 스스로 대기 상태에 접어들기 전까진 다른 프로세스가 끼어들 수 없는 방식
하나의 프로세스가 자원 사용을 독점할 수 있는 방식
문맥 교환 시 오버헤드는 적지만 모든 프로세스가 자원을 골고루 사용 불가합니다.

CPU 스케줄링 알고리즘

운영체제마다 서로 다른 스케쥴링 알고리즘을 사용한다. 여기서는 일곱 가지 방식을 예로 들었습니다.

선입 선처리 스케줄링 (FCFS)
FCFS 스케줄링(FIFO)
준비 큐에 삽입된 순서대로 처리하는 비선점형 스케줄링 방식.
CPU를 오래 사용하는 프로세스가 먼저 도착하면 프로세스들이 기다리는 시간이 매우 길어질 수 있는데

이렇게 CPU를 짧게 사용하는 프로세스가 CPU를 오래 사용하는 프로세스를 기다리며 잠깐의 실행을 위해 오래 기다리게 되는 현상을 호위 효과라고 합니다.

최단 작업 우선 스케줄링 Shortest Job First Scheduling (SJF)
SJF 스케줄링
호위 효과를 방지하기 위해 CPU 사용 시간이 짧은 프로세스를 먼저 실행하는 비선점형 스케줄링 방식입니다..

라운드 로빈 스케줄링 Round Robin scheduling (RR)
선입 선처리 스케줄링에 프로세스가 CPU를 사용할 수 있도록 정해진 시간 타임 슬라이스개념이 더해진 것입니다.
정해진 시간만큼 CPU를 이용하고 아직 프로세스가 완료되지 않았다면

준비 큐 맨 뒤에 삽입.타임 슬라이스가 너무 크면 호위 효과의 발생이 가능합니다.

너무 작으면 문맥 교환 오버헤드가 커집니다.

최소 잔여 시간 우선 스케줄링 Shortest Remaining Time (SRT)

SRT 스케줄링
최단 작업 우선 스케줄링에 라운드 로빈 스케줄링을 합쳐 선점형 스케줄링 방식으로 구현한 것입니다.
작업 시간 대신 잔여 시간을 기준으로 짧은 것을 앞에 둡니다.
정해진 타임 슬라이스만큼 CPU를 사용하면서 남아있는 작업 시간이 가장 짧은 것을 우선시합니다.

우선순위 스케줄링 Priority (FCFS)
프로세스들에 우선순위를 부여하고, 우선순위가 높은 프로세스부터 실행하는 방식입니다.
우선순위가 같은 프로세스끼리는 선입 선처리 (FCFS)
최단 작업 우선 스케줄링과 최소 잔여 시간 우선 스케줄링도 넓게 보면 여기에 포함.
우선순위가 낮은 프로세스의 실행이 계속 연기되는 기아 현상이 발생 가능합니다. 이러한 해결책으로
오래 대기한 프로세스의 우선순위를 높이는 에이징 기법으로 기아 현상을 방지합니다.

다단계 큐 스케줄링 Multi-Level Queue scheduling
우선순위별로 준비 큐를 여러 개 사용하는 방식입니다.
우선순위가 가장 높은 큐에 있는 프로세스를 먼저 처리하고, 비어 있을 경우 다음 우선순위의 큐를 처리합니다.
프로세스 유형별로 우선순위를 구분하여 실행하기 편리하고, 큐별로 타임 슬라이스, 스케줄링 알고리즘 등을 개별적으로 설정 가능합니다

ex: 선입 선처리, 라운드 로빈

다단계 피드백 큐 스케줄링 Multi-Level Feedback Queue scheduling
다단계 큐 스케줄링에서 발생할 수 있는 기아 현상을 방지하기 위해 발전된 형태로 우선순위에 따라 타임 슬라이스만큼 실행한 후, 완료되지 않았다면 다음 우선순위의 큐에 삽입합니다.
오랫동안 실행되지 못했다면 에이징 기법을 적용하여 높은 우선순위의 큐로 이동합니다.
CPU를 오래 사용할수록 점점 우선순위가 낮아지고 오래 기다리면 에이징 기법으로 우선순위가 높아진다.

304P - 1번

생성 상태

준비 상태

실행 상태

종료 상태

대기 상태

선택미션

스케줄링 기법CPU 할당

선입 선처리	A가 모두 실행된 후 B가 실행되고, B가 모두 실행된 후 C가 실행되고, C가 모두 실행된 후 D가 실행된다.
최단 작업 우선	A, B, C, D 중 실행 시간이 짧은 것부터 작업 시간 순으로 실행된다.
라운드 로빈	A, B, C, D가 타임 슬라이스만큼의 시간동안 실행되며, 아직 실행할 게 남은 동안 이 순서로 반복된다.
우선순위	A, B, C, D의 우선순위를 판별하여 우선순위가 높은 프로세스부터 실행된다.

혼자 공부하는 컴퓨터 구조+운영체제

www.hanbit.co.kr

[혼공컴운] 3주차 Chapter 06 ~ 08 메모리, 보조기억장치, 입출력장치

sangkins — Tue, 16 Jan 2024 23:58:24 +0900

벌써 혼공학습단의 절반으로 향해가고 있습니다

3주 차에 공부하는 내용은 메모리, 보조기억장치, 입출력장치를 알아보겠습니다

Chapter 06 | 메모리와 캐시 메모리
- 06-1 | RAM의 특징과 종류
- 06-2 | 메모리의 주소 공간
- 06-3 | 캐시 메모리
Chapter 07 | 보조기억장치
- 07-1 | 다양한 보조기억장치
- 07-2 | RAID의 정의와 종류
Chapter 08 | 입출력장치
- 08-1 | 장치 컨트롤러와 장치 드라이버
- 08-2 | 다양한 입출력 방법

✅혼자 공부하는 컴퓨터 구조+운영체제

#혼공학습단 #혼공 #혼공컴운

#	진도	기본 미션	선택 미션
1주차 (1/2 ~ 1/7)	Chapter 01 ~ 03	p. 51의 확인 문제 3번, p. 65의 확인 문제 3번 풀고 인증하기	p. 100의 스택과 큐의 개념을 정리하기
2주차 (1/8 ~ 1/14)	Chapter 04 ~ 05	p. 125의 확인 문제 2번, p. 155의 확인 문제 4번 풀고 인증하기	Ch.05(05-1) 코어와 스레드, 멀티 코어와 멀티 스레드의 개념을 정리하기
3주차 (1/15 ~ 1/21)	Chapter 06 ~ 08	p. 185의 확인 문제 3번, p. 205의 확인 문제 1번 풀고 인증하기	Ch.07(07-1) RAID의 정의와 종류를 간단히 정리해 보기
4주차 (1/22 ~ 1/28)	Chapter 09 ~ 11	p. 304의 확인 문제 1번 풀고 인증하기	Ch.11(11-2) 준비 큐에 A,B,C,D 순으로 삽입되었다고 가정했을 때, 선입 선처리 스케줄링 알고리즘을 적용하면 어떤 프로세스 순서대로 CPU를 할당받는지 풀어보기
5주차 (1/29 ~ 2/4)	Chapter 12 ~ 13	p. 363의 확인 문제 1번 풀고 인증하기	Ch.12(12-1) 임계 구역, 상호 배제 개념을 정리하기
6주차 (2/5 ~ 2/12)	Chapter 14 ~ 15	p. 400의 확인 문제 1번 풀고 인증하기	Ch.14(14-3) 프로세스가 사용할 수 있는 프레임이 3개 있고, 페이지 참조열이 '2313523423' 일 때 LRU 페이지 교체 알고리즘으로 이 페이지를 참조한다면 몇 번의 페이지 폴트가 발생하는지 풀어보기

학습목표

RAM의 특징과 종류에 대해 학습
논리 주소와 물리 주소의 차이를 이해
논리 주소를 물리 주소로 변환하는 방법을 이해
캐시 메모리와 저장 장치 계층 구조의 개념을 이해

06. 메모리와 캐시 메모리

RAM(Random Access Memory)

실행할 프로그램의 명령어와 데이터가 저장되는 컴퓨터 메모리
저장된 데이터를 순차적이 아닌 임의의 순서로(Random) 접근할 수 있는 데이터 저장소
전원을 끄면 RAM에 저장된 데이터가 사라진다 = 휘발성 메모리(volatile memory)
RAM 용량이 충분히 크다면 보조기억장치에서 많은 데이터를 미리 불러올 수 있다.

06 - 1 RAM의 종류

DRAM(Dynamic RM)
- 저장 데이터가 동적으로 변하는 RAM.
- 데이터의 소멸을 막기 위해 일정 주기로 재저장이 필요한 단점
- 소비 전력, 가격이 낮고 집적도가 높다는 장점
SRAM(STATIC RAM)
- 저장된 데이터가 변하지 않는 정적인 RAM
- DRAM 보다 속도가 빠르다는 장점
- 소비 전력,가격이 높고 집적도가 낮다는 단점
- 대용량이 필요하지 않은 캐시 메모리에 사용
DDR SDRAM( DOUBLE DATA RATE SDRAM)
- 대역폭를 넓혀 속도를 높인 SDRAM
- 대역폭(Data Rate): 데이터 통로의 넓이
SDRAM(Synchronous Dynamic RAM)
- 클럭 신호와 동기화된 DRAM

06-2 메모리 주소의 공간

물리 주소: 메모리 하드웨어가 사용하는 주소
논리 주소: CPU와 실행 중인 프로그램이 사용하는 주소

메모리 관리 장치(Memory Management Unit)

논리주소를 물리주소로 변환(= 논리주소 + 베이스 레지스터 값)하는 장치

메모리 보호 기법
자신의 프로그램 논리 주소 영역을 넘어서는 명령어를 막기 위한 방법
한계 레지스터(Limit Register)가 논리 주소의 최대 크기를 저장하여 제한

값을 계산하는 방법은 192P

06-3 캐시 메모리(Cache Memory)

CPU와 메모리 사이에 위치한, SRAM 기반의 저장 장치
CPU의 연산 속도와 메모리 접근 속도차를 줄이기 위해 만들어짐, 코어와 가까운 순서대로 L1, L2, L3 계층
참조 지역성 원리
CPU가 메모리에 접근할 때 주된 경향을 바탕으로 만들어진 원리
캐시 히트(Cache Hit): CPU가 사용할 것으로 예상되는 내용을 예측하여 캐시 메모리에 저장하고, 실제로 CPU가 그 내용을 사용하는 경우. 반대의 경우인 캐시 미스(Cache miss)
캐시 적중률(Cache Hit Rate) = 캐시 히트 횟수 / 총 수
시간 지역성(Temporal Locality): CPU는 최근에 접근한 메모리 공간에 다시 접근하려는 경향
공간 지역성(Spatial Locality): CPU는 접근한 메모리 공간 근처를 접근하려는 경향

07. 보조기억장치

07-1 다양한 보조기억장치

하드디스크 : 자기적인 방식으로 데이터를 저장하는 보조기억장치

하드디스크의 구조

플래터: 자기 물질로 덮힌 동그란 원판. N/S극이 각각 0과 1의 역할
스핀들: 플래터 회전기
헤드: 플래터 위에서 미세하게 떠서 데이터를 읽고 쓰는 요소
디스크 암: 헤드를 원하는 위치로 이동시키는 요소

하드디스크의 저장 방식

트랙: 플래터 동심원 중 하나의 원
섹터: 트랙의 일부
실린더: 다중 플래터에서 같은 트랙이 위한 곳을 모아 연결한 논리적 단위 공간
쓰기, 읽기

하드디스크 접근 시간

탐색 시간: 접근 데이터가 저장된 트랙까지 헤드를 이동시키는 시간
회전 지연: 헤드가 있는 곳으로 플래터를 회전시키는 시간
전송 시간: 하드디스크와 컴퓨터 간에 데이터를 전송하는 시간

플래시 메모리 : 전기적으로 데이터를 읽고 쓸 수 있는 반도체 기반의 저장장치

플래시 메모리 저장 단위

셀: 플래시 메모리에서 데이터를 저장하는 가장 작은 단위
셀 < 페이지 < 블록< 플레인 < 다이
읽기와 쓰기는 페이지 단위, 삭제는 블록 단위로 이루어짐
SLC, MLC, TLC 가 있다. 순서대로 셀당 bit = 1,2,3
수명 = 길다, 보통, 짧다
읽기/쓰기 속도 = 빠름, 보통, 느림
용량 대비 가격 = 높음, 보통, 낮음

07-2 RAID의 정의와 종류
RAID(Redundant Array of Independent Disks; 복수 배열 독립 디스크)
데이터의 안전성/높은 성능을 위해 여러 개의 물리적인 보조기억장치를 하나의 논리적 보조기억장치처럼 사용하는 기술

RAID Level
RAID 0
여러개의 보조기억장치에 단순하게 나누어 저장하는 방식 (스트라이핑)

장점: 데이터를 동시에 읽고 쓸 수 있기 때문에, 처리 속도가 빠름
단점: 디스크 하나에 문제가 발생하면 읽기에 문제가 발생

RAID 1
완전한 복사본 = 미러링(mirroring)

장점: 데이터 복구가 매우 간단한다.
단점: 완전 복사된 형태이기 때문에 RAID 0보다 속도가 느리고, 사용 가능한 용량이 적기 때문에, 많은 디스크 비용

RAID 4
전용 패리티 디스크가 제공되는 스트라이핑 된 방식

장점: RAID 1보다 적은 하드디스크로도 데이터를 안전하게 보관
단점: 새로운 데이터 저장 시 패리티 디스크에도 접근해야 하므로 패리티 디스크의 병목 현상이 발생

RAID 5
패리티 정보가 분산된 스프라이핑 방식 즉 병목 현상을 해소

RAID 6
서로 다른 패리티 2개를 사용하는 RAID 5 방식

데이터 저장 속도를 조금 희생하더라도 데이터를 더욱 안전하게 보관

장점: 패리티의 증가로 좀 더 안전한 복구가 가능하다.
단점: 패리티 2개 내용을 저장해야 하므로 RAID 5보다 느리다.

08. 입출력장치

08-1 장치 컨트롤러와 장치 드라이버

입출력장치가 다루기 어려운 이유

다양한 종류로 인한 문제점 : 규격화가 어려움
CPU, 메모리에 비해 전송률이 낮음 : 입출력장치와의 소통 문제

장치 컨트롤러
입출력장치가 컴퓨터와 직접 연결되지 않고, 컴퓨터 내부와 통신하는 장치
장치 컨트롤러의 기능CPU와 입출력장치 간의 통신 중개와 오류 검출
장치 컨트롤러를 통해 정보 규격화, 그 과정에서 오류를 검출

데이터 버퍼링
CPU와 입출력장치의 전숭률 차이를 버퍼라는 임시 저장 공간을 통해 전송률을 매칭.

장치 컨트롤러의 구조

데이터 레지스터(dara register): CPU-입출력장치 간 데이터 저장 - 버퍼
상태 레지스터(status register): 입출력장치의 상태 정보 저장
제어 레지스터(control register): 입출력장치가 수행할 명령, 제어정보 저장
장치 드라이버(Device Driver) :장치 컨트롤러를 제어하여 컴퓨터 내부와 통신할 수 있도록 하는 프로그램

08-2 다양한 입출력 방법

CPU와 장치 컨트롤러간의 통신 방법

프로그램 입출력

프로그램 속 명령어로 입출력장치 제어

CPU가 장치 컨트롤러의 레지스터에 접근하는 방법

메모리 맵 입출력

메모리 접근 주소 공간과 입출력장치 접근 주소 공간을 하나의 공간으로 간주하는 방법
메모리 주소공간이 축소
메모리 명령어 = 입출력장치 명령어

고립형 입출력

메모리 주소 공간과 입출력장치 주소 공간을 분리
메모리 주소 공간 축소되지 않음

입출력 전용 명령어

인터럽트 기반 명령어
장치 컨트롤러가 작업을 끝나면 CPU에게 인터럽트 요청 신호를 보내 인터럽트 서비스 루틴을 실행하는 방법

여러 입출력장치에서 동시에 인터럽트가 발생한 경우 순서대로 처리
NMI가 발생한 경우, 우선순위에 따라 처리
PCI를 통해 우선순위를 판별

DMA 입출력
입출력장치, 메모리가 CPU를 거치지 않고 바로 상호작용하는 방식

Mission

SRAM : 주로 캐시 메모리로 사용, 집적도가 상대적으로 낮음

DRAM : 주로 주기억장치로 활용, 대용량화하기 유리

RAID의 정의와 종류

RAID 0 : 여러개의 보조기억장치에 나누어서 저장, 속도가 빠름, 안정성 下

RAID 1 : 완전한 복사본을 저장, 높은 비용, 안전성 上

RAID 4 : 전용 페리티 디스크 제공 스트라이핑 방식, 페리티 디스크 접근으로 인한 병목 현상 발생, RAID 1 보다 더 효율적

RAID 5 : 페리티 정보를 분산 -> 병목현상 해소

RAID 6 : 서로 다른 페리티 2개를 사용하는 RAID 5 방식, 저장 속도는 RAID 5 보다 느리지만 안정성 上, 복구가 쉬움

혼자 공부하는 컴퓨터 구조+운영체제

www.hanbit.co.kr

[혼공컴운] 2주차 - CPU의 작동원리, 성능 향상 기법

sangkins — Tue, 9 Jan 2024 15:00:56 +0900

연초에 시작된 혼공학습단 11기도 벌써 2주 차가 되었습니다. 시간이 참 빨라요

2주 차의 진도는 CPU의 작동원리, 성능 향상 기법을 공부합니다.

혼공컴운 책만으로는 깊이 있는 내용을 알기 어렵기 때문에 헷갈리는 부분은 따로 공부해야 할 듯합니다.

혼자 공부하는 컴퓨터 구조+운영체제

www.hanbit.co.kr

✅혼자 공부하는 컴퓨터 구조+운영체제

#혼공학습단 #혼공 #혼공컴운

#	진도	기본 미션	선택 미션
1주차 (1/2 ~ 1/7)	Chapter 01 ~ 03	p. 51의 확인 문제 3번, p. 65의 확인 문제 3번 풀고 인증하기	p. 100의 스택과 큐의 개념을 정리하기
2주차 (1/8 ~ 1/14)	Chapter 04 ~ 05	p. 125의 확인 문제 2번, p. 155의 확인 문제 4번 풀고 인증하기	Ch.05(05-1) 코어와 스레드, 멀티 코어와 멀티 스레드의 개념을 정리하기
3주차 (1/15 ~ 1/21)	Chapter 06 ~ 08	p. 185의 확인 문제 3번, p. 205의 확인 문제 1번 풀고 인증하기	Ch.07(07-1) RAID의 정의와 종류를 간단히 정리해 보기
4주차 (1/22 ~ 1/28)	Chapter 09 ~ 11	p. 304의 확인 문제 1번 풀고 인증하기	Ch.11(11-2) 준비 큐에 A,B,C,D 순으로 삽입되었다고 가정했을 때, 선입 선처리 스케줄링 알고리즘을 적용하면 어떤 프로세스 순서대로 CPU를 할당받는지 풀어보기
5주차 (1/29 ~ 2/4)	Chapter 12 ~ 13	p. 363의 확인 문제 1번 풀고 인증하기	Ch.12(12-1) 임계 구역, 상호 배제 개념을 정리하기
6주차 (2/5 ~ 2/12)	Chapter 14 ~ 15	p. 400의 확인 문제 1번 풀고 인증하기	Ch.14(14-3) 프로세스가 사용할 수 있는 프레임이 3개 있고, 페이지 참조열이 '2313523423' 일 때 LRU 페이지 교체 알고리즘으로 이 페이지를 참조한다면 몇 번의 페이지 폴트가 발생하는지 풀어보기

Chapter 4. CPU의 작동원리

ALU와 제어장치

ALU는 계산하는 부품으로써 레지스터로부터 피연산자를 받아들이고, 제어장치로부터 수행할 연산을 알려주는 제어신호를 받아들임.

계산한 결과와 더불어 플래그를 내보낸다.

플래그의 종류 : 부호플래그, 제로플래그, 캐리플래그, 오버플로우플래그, 인터럽트플래그, 슈퍼바이저플래그 등.

제어장치는 제어신호를 내보내고 명령어를 해석하는 부품으로써 클럭신호, 해석해야 할 명령어, 플래그값, 제어신호를 받아들인다.

CPU 내부(ALU, 레지스터)와 CPU 외부(메모리, 입출력장치)에 제어신호를 내보낸다

레지스터

레지스터는 CPU내부의 작은 저장장치의 주요 종류 및 역할

-프로그램카운터 : 메모리에서 가져올 명령어의 주소를 저장. (=명령어포인터)

-명령어레지스터 : 메모리에서 가져온 명령어를 저장.

-메모리주소레지스터 : 메모리 주소를 저장.

-메모리버퍼레지스터 : 메모리와 주고받은 데이터 및 명령어를 저장 (메모리 데이터 레지스터)

-범용레지스터 : 다양하고 일반적인 상황에서 데이터와 주소를 모두 저장 가능함.

-플래그레지스터 : 연산결과 및 CPU 상태에 대한 부가적인 정보를 저장.

-특정 레지스터를 이용한 주소지정방식
1. 스택 주소 지정 방식 : 스택과 스택포인터를 이용한 주소지정 방식.

2. 변위 주소 지정 방식 : 오퍼랜드필드 값과 특정 레지스터 값을 더하여 유효주소 결정.

- 상대 주소 지정 방식 : 오퍼랜드와 프로그램카운터의 값을 더하여 유효주소 결정.

- 베이스 레지스터 주소 지정 방식 : 오퍼랜드와 베이스레지스터의 값을 더해 유효주소 결정.

명령어 사이클과 인터럽트

명령어 사이클 : 명령어를 처리하는 일정한 주기의 정형화된 흐름으로 인출, 실행, 간접, 인터럽트 사이클로 구성되어 있습니다. 메모리에서 CPU로 가져오는 인출사이클과 가져온 명령어를 실행하는 실행사이클을 반복.

인터럽트 : CPU의 정상적인 작업을 방해하는 신호로서 CPU자체 또는 입출력장치에 의해 발생.
인터럽트의 종류 : 동기 인터럽트, 비동기 인터럽트
동기 인터럽트 : CPU에 의해 발생하는 것으로 프로그래밍상의 오류 등 예상치 못한 상황에 마주할 때 발생합니다.
비동기 인터럽트 : 주로 입출력장치에 의해 발생하는 것으로 알림과 같은 역할을 수행합니다.

하드웨어 인터럽트 처리순서
1. 입출력장치는 CPU에 인터럽트 요청신호 보냄.
2. CPU는 인터럽트 요청을 확인하고 인터럽트 플래그를 통해 인터럽트 수용여부 확인.
3. 인터럽트 수용의 경우 지금까지의 작업을 백업처리.
4. CPU는 인터럽트 벡터를 참조하여 인터럽트 서비스 루틴(인터럽트 핸들러)을 실행.
5. CPU는 3에서 백업해 둔 작업을 복구하여 실행을 재개.

인터럽트 벡터 : 수많은 인터럽트 서비스 루틴을 구분 식별하기 위한 정보.
인터럽트 서비스 루틴 : 인터럽트를 처리하기 위한 프로그램(인터럽트 핸들러)
막을 수 없는 인터럽트 : 정전이나 하드웨어 고장 (동기 인터럽트)

1. 폴트(fault) : CPU가 인터럽트를 처리한 직후 인터럽트가 발생한 그 명령어부터 실행을 재개
2. 트랩(trap) : CPU가 인터럽트를 처리한 직후 인터럽트가 발생한 명령어의 다음부터 실행 재개
3. 중단(abort) : CPU가 실행 중인 프로그램을 강제로 중단할 수밖에 없는 심각한 오류가 발견된 경우
4. 소프트웨어 인터럽트(software) : 시스템 호출이 발생했을 때 수행

Chapter 5. 성능 향상 기법

빠른 CPU를 위한 설계기법

클럭(clock)의 속도를 높여 CPU를 비롯한 컴퓨터 부품들을 빠르게 작동시킴.

컴퓨터부품은 클럭신호에 맞춰 일사불란하게 움직이고, CPU는 명령어 사이클의 정해진 흐름에 맞춰 명령 실행.

멀티코어(multi-core) CPU(멀티코어프로세서)를 장착하여 명령어 처리속도를 높임.
멀티코어란 CPU 내에서 명령어를 실행하는 부품인 코어(core)를 여러 개인 CPU를 말함.

멀티스레드(multi-thread) CPU(멀티스레드프로세서)를 통해 하나의 코어로 여러 명령어를 동시에 처리.

하드웨어적 스레드 : CPU에서 하나의 코어가 동시에 여러 명령어를 처리하는 방식
소프트웨어적 스레드 : 하나의 프로그램에서 여러 기능을 독립적으로 실행하는 방식

명령어 병렬처리 기법

CPU의 속도를 높이는 것과 함께 CPU가 쉬지 않고 명령어를 동시에 처리하는 기법으로, 시간을 알뜰하게

명령어 파이프라이닝, 수퍼스칼라, 비순차적 명령어 처리 등

명령어 파이프라이닝 : 명령어를 순차적으로 처리하지 않고 같은 단계가 겹치지 않게 각 단계를 동시 실행 기법
명령어 인출-> 명령어 해석-> 명령어 실행-> 결괏값 저장의 과정으로 나뉘어 실행
처리 성능을 높이는 측면이 있지만 특정상황에서는 성능향상에 실패하는 파이프라인 위험 발생 가능
- 테이터 위험(data hazard) : 명령어 간의 데이터 의존성에 의해 발생하는 위험
- 제어 위험(control hazard) : 분기(branch) 등으로 인한 프로그램카운터의 갑작스러운 변화에 의해 발생
- 구조적 위험(structural hazard) : 서로 다른 명령어가 동시에 CPU 부품을 사용하려고 할 때 발생

수퍼스칼라(superscalar) : CPU 내부에 여러 개의 명령어 파이프라인을 포함하는 구조
수퍼스칼라 프로세서(=수퍼스칼라 CPU) : CPU 내에 수퍼스칼라 구조로 명령어 처리가 가능한 CPU

비순차적 명령어 처리(OoOE) : 명령어를 순차적으로 처리하지 않고 순서를 바꿔서 실행해도 무방한 명령어를 먼저 실행하여 파이프라인이 멈추는 것을 방지하는 기법

CISC와 RISC

CPU의 언어인 ISA란?
CPU가 이해할 수 있는 명령어들을 모아놓은 것으로 명령어집합(instruction set) 또는 명령어집합구조
(Instruction Set Architecture)라고 말함.

즉. ISA가 다르면 서로의 명령어를 이해하지 못합니다.

ISA는 각기 다른 성격으로 설계된 양대산맥 CISC와 RISC

CISC(complex instruction set architecture)

복잡하고 다양하고 강력한 기능을 가진 명령어집합으로 가변길이 명령어를 활용.
적은 수의 명령어로 프로그램을 실행할 수 있고 메모리 공간을 절약할 수 있는 장점이 있는 반면 명령어의 크기와 실행시간이 일정하지 않은 취약점이 있음.

RISC(reduced instruction set architecture)

CISC와 달리 단순하고 적은 종류 명령어를 활용함. 명령어가 짧고 규격화되어 있어 고정길이 명령어를 활용하며 명령어 파이프라이님에 최적화됨.

CISC와 RISC의 차이
CISC : 명령어 복잡하고 다양, 가변 길이 명령어, 주소 지정 방식 다양, 명령어 수 적음, 여러 클럭, 파이프라이닝 어려움.
RISC : 명령어 단순하고 적음, 고정 길이 명령어, 주소 지정 방식 적음, 명령어 수 많음, 1 클럭 내외, 파이프라이닝 쉬움.

미션

1. 플래그 레지스터 : 연산 결과 혹은 CPU 상태에 대한 부가 정보를 저장하는 레지스터

2. 프로그램 카운터 : 메모리에서 가져올 명령어의 주소를 저장하는 레지스터

3. 범용 레지스터 : 데이터와 주소를 모두 저장할 수 있는 레지스터

4. 명령어 레지스터 : 해석할 명령어를 저장하는 레지스터

멀티코어 CPU

: 코어

코어와 스레드, 멀티코어와 멀티쓰레드의 개념

1. 코어와 쓰레드:
   - 코어(Core): CPU 내에서 명령어를 실행하는 부품으로, 일반적으로 하나만 존재함.
   - 쓰레드(Thread): 하나의 코어가 명령어를 실행하는 흐름 단위를 나타냄.

2. 멀티코어와 멀티쓰레드:
   - 멀티코어(Multi-core): CPU 내에 여러 개의 코어를 포함하고 있는 구조로, 멀티코어 CPU 또는 멀티코어 프로세서라고 불림.
   - 멀티쓰레드(Multi-thread): 하나의 코어가 여러 개의 명령어를 동시에 실행하는 구조를 나타냄.

복습하는 개념으로 한번 정리해 봤습니다. 머릿속에서 정리되는 것 같아 좋은 것 같습니다!

[혼공컴운] 혼공학습단 11기 1주차 미션을 시작하면서

sangkins — Thu, 4 Jan 2024 22:27:31 +0900

혼공컴운 11기에 선정되어서 그간 부족하다고 느껴졌던 CS와 OS의 개념을 정리해보고 싶어
혼자 공부하는 컴퓨터 구조 + 운영체제 책을 선택하게 되었습니다.

진작 공부할걸,라고 할 때 진짜 할걸
후회를 남기지 않으려 신청했다

혼자 공부하는 컴퓨터 구조+운영체제

www.hanbit.co.kr

혼공학습단 11기의 커리큘럼은 다음과 같습니다.

✅혼자 공부하는 컴퓨터 구조+운영체제

#혼공학습단 #혼공 #혼공컴운

#	진도	기본 미션	선택 미션
1주차 (1/2 ~ 1/7)	Chapter 01 ~ 03	p. 51의 확인 문제 3번, p. 65의 확인 문제 3번 풀고 인증하기	p. 100의 스택과 큐의 개념을 정리하기
2주차 (1/8 ~ 1/14)	Chapter 04 ~ 05	p. 125의 확인 문제 2번, p. 155의 확인 문제 4번 풀고 인증하기	Ch.05(05-1) 코어와 스레드, 멀티 코어와 멀티 스레드의 개념을 정리하기
3주차 (1/15 ~ 1/21)	Chapter 06 ~ 08	p. 185의 확인 문제 3번, p. 205의 확인 문제 1번 풀고 인증하기	Ch.07(07-1) RAID의 정의와 종류를 간단히 정리해 보기
4주차 (1/22 ~ 1/28)	Chapter 09 ~ 11	p. 304의 확인 문제 1번 풀고 인증하기	Ch.11(11-2) 준비 큐에 A,B,C,D 순으로 삽입되었다고 가정했을 때, 선입 선처리 스케줄링 알고리즘을 적용하면 어떤 프로세스 순서대로 CPU를 할당받는지 풀어보기
5주차 (1/29 ~ 2/4)	Chapter 12 ~ 13	p. 363의 확인 문제 1번 풀고 인증하기	Ch.12(12-1) 임계 구역, 상호 배제 개념을 정리하기
6주차 (2/5 ~ 2/12)	Chapter 14 ~ 15	p. 400의 확인 문제 1번 풀고 인증하기	Ch.14(14-3) 프로세스가 사용할 수 있는 프레임이 3개 있고, 페이지 참조열이 '2313523423' 일 때 LRU 페이지 교체 알고리즘으로 이 페이지를 참조한다면 몇 번의 페이지 폴트가 발생하는지 풀어보기

Chapter 1. 컴퓨터 구조 시작하기

목표 : 문제 해결 능력, 성능, 용량, 비용문제를 고려하여 개발할 수 있도록

컴퓨터의 언어 0과 1 이 단위를 bit(비트)라고 한다.

0과 1로 표현하는 정보 : 데이터, 명령어

- 컴퓨터의 네 가지 핵심 부품

픽사베이

컴퓨터는 주기억장치, CPU, 보조기억장치, 입출력장치, 메인보드, 시스템 버스 등으로 구성되어 있다.

1. 주기억 장치

현재 실행되는 프로그램의 데이터와 명령어를 저장하는 부품

RAM(Random Access Memory)와 ROM(Read Only Memory)가 존재.

통상 RAM을 지칭한다.

2. 중앙처리장치

컴퓨터의 두뇌. 메모리에 저장된 명령어를 읽어 들이고, 해석, 실행하는 부품

- CPU 내부 구성 요소 중 3가지

- 1. ALU: 산술논리연산장치

- 2. 레지스터 : 프로그램을 실행하는데 필요한 값들을 임시로 저장하는 장치, 각기 다른 이름과 역할의 레지스터 존재

- 3. 제어장치(Control Unit) : 제어 신호를 내보내고 명령어를 해석하는 장치

3. 보조기억장치

메인메모리의 단점을 보완하는 용량이 크고, 전원이 OFF 돼도 내용을 잃지 않는 보조 메모리

메모리는 현재 실행중인 프로그램을 저장, 보조기억장치는 보관할 프로그램을 저장한다는 점에서 차이점을 가집니다.

4. 입출력장치

마우스, 스피커, 헤드셋같이 컴퓨터 외부와 연결되어서 컴퓨터 내부와 정보를 교환하는 장치를 말합니다.

5. 메인보드, 시스템 버스

컴퓨터의 핵심 부품들은 Main Board라고 부르는 판에 연결되는데. 메인보드에 있는 Bus라는 통로를 통해서 서로 정보를 주고받습니다.

핵심 부품이 정보를 주고받는 통로를 System Bus라고 합니다.

시스템 버스는 3가지 Bus로 이루어져 있는데 다음과 같습니다.

- 시스템 버스

- 1. 주소 버스(Address Bus) : 주소를 주고 받는 통로

- 2. 제어 버스(Control Bus) : 제어 신호를 주고받는 통로

- 3. 데이터 버스(Data Bus) : 명령어와 데이터를 주고 받는 통로

Chapter 2. 데이터

정보의 크기에 따라 표현 가능한 정보의 종류가 달라집니다.

- 1개의 비트는 {0,1} 2가지의 정보를 표현이 가능

- 2개의 비트는 0,0 - 0,1 - 1,1 - 1,0 4가지의 정보를 표현이 가능

- 3개의 비트는... 8가지의 정보가 표현 가능합니다.

2^1= 2개, 2^2 = 4개..... N비트 정보는 2N 개의 정보를 표현할 수 있다.

1바이트(byte)	8비트(8bit)
1킬로바이트(kB)	1,000바이트(1,000byte)
1메가바이트(MB)	1,000킬로바이트(1,000kB)
1기가바이트(GB)	1,000메가바이트(1,000MB)
1테라바이트(TB)	1,000기가바이트(1,000GB)

1 KiB = 1,024Byte.. MiB, GiB, TiB 단위가 다르다.

0과 1만으로 숫자를 표현하는 방법을 이진법이라고 합니다.

일상적으로 십진법을 사용하지만 컴퓨터에게는 이진법으로 알려주어야 합니다.

2진법으로 표현된 수가 음수인지 양수인지 어떻게 알 수 있을까요.

이진법으로 표현된 수의 음수 표현은 2의 보수를 구해 값을 음수로 간주하는 방법입니다.

이진수의 음수 표현 ( 2의 보수 (two's complement) )
1. n비트의 이진수를 각 비트마다 not 연산하기
2. 그 이진수에 1 더하기

2의 보수로 표현한 수의 음수와 양수는 플래그(flag)로 구분합니다.

2의 보수 표현의 한계
- 일반적인 방법이지만 완벽한 방식은 아니다.
- 0, 2^n 형태의 이진수에 2의 보수를 취하면 원하는 음수값을 얻을 수 없음.

이진법으로 숫자를 표현하다 보니 숫자의 길이가 너무 길어진다는 단점이 생겨 십육 진법을 사용하게 되었습니다.

십육 진법(hexadecimal): 15를 넘어가는 시점에 자리 올림. 0~9, A~F까지 사용.
이진수에 비해 더 많은 정보를 표현할 수 있게 되었습니다.

10진수보다 불편한 16진수를 사용하는 이유는 무엇일까요?

- 컴퓨터가 이해하는 이진법으로 변환하기 쉽기 때문입니다.

이렇게 0과 1로 이루어진 문자를 어떻게 이해하고 출력할까요?

우선 문자집합, 인코딩, 디코딩에 대해서 알아보겠습니다.

- 문자집합 : 컴퓨터가 인식할 수 있는 문자들의 모음

- 인코딩 : 컴퓨터가 이해할 수 있게 0과 1로 변환하는 과정

- 디코딩 : 0과 1로 표현된 문자 코드를 사람이 읽을 수 있게 변환하는 과정

아스키코드 :7비트로 표현됨 2^7, 총 128개의 문자를 표현할 수 있다.

EUC-KR : 한글 인코딩의 두 가지 방식 ( 완성형, 조합형) 중 완성형 인코딩 방식.

CP949 : EUC-KR의 확장버전

유니코드: EUC-KR 보다 다양한 한글을 포함, 표준 문자 집합.

UFT-8(Unicode Transformation Format - 8bit): 가변 길이 유니코드 인코딩 방식
즉, 부여된 값의 범위에 따라서 1~4바이트로 표현 가능

Chapter 3. 명령어

- 소스 코드와 명령어

모든 소스 코드는 컴퓨터 내부에서 명령어로 변환됩니다.

즉 고급 언어에서 저급 언어로 변환된다는 것입니다.

고급 언어와 저급 언어
- 고급 언어: 사람이 이해하기 위해 만들어진 컴퓨터 언어
ex > 파이썬, 자바 등
- 저급 언어: 컴퓨터가 직접 이해하고 실행할 수 있는 언어
ex > 어셈블리어, 기계어

- 어셈블리어: 읽기 편한 형태의 저급 언어 (기계어를 읽기 편한 형태로 번역한 언어)

컴파일 언어와 인터프리터 언어

컴파일 언어: 컴파일 방식으로 작동하는 프로그래밍 언어
ex> c, c++...
- 컴파일 : 소스 코드 전체가 저급 언어로 변환 후 프로그램이 실행
- 컴파일러: 컴파일을 수행하는 도구

- 컴파일 과정
소스 파일 → 컴파일 → 오브젝트 파일

인터프리터 언어: 인터프리터에 의해 소스 코드가 한 줄씩 실행되는 포로그래밍 언어
ex> 파이썬, Ruby...
- 인터프리터: 소스 코드를 한 줄 씩 저급 언어로 변환하여 실행하는 툴

이렇게 고급 언어가 저급 언어로 변환되는 대표적인 방법에는 두 가지가 있습니다.

- 명령어의 구조

연산코드와 오퍼랜드

오퍼랜드: 연산에 사용할 데이터 혹은 데이터가 저장된 위치. 피연산자라고도 함.
- 오퍼랜드 필드: 명령어에서 오퍼랜드가 저장되는 영역. 주소필드라고도 함.

오퍼랜드 필드의 개수에 따른 명령어 형식

- 0-주소 명령어: 오퍼랜드가 하나도 없는 명령어
- 1-주소 명령어: 오퍼랜드가 하나인 명령어
- 2-주소 명령어: 오퍼랜드가 두 개인 명령어
- 3-주소 명령어: 오퍼랜드가 세 개인 명령어

연산코드: 명령어가 수행할 연산. 연산자라고도 함.

연산자의 유형

1. 데이터 전송
2. 산술/논리 연산
3. 제어 흐름 변경
4. 입출력 제어

주소 지정 방식

유효 주소: 연산의 대상이 되는 데이터가 저장된 위치로 즉시 주소 지정 방식으로 연산에 사용할 데이터를 오퍼랜드 필드에 직접 명시하는 방식입니다

1. 데이터 표현 범위가 작아집니다.
2. 속도 빠름

직접 주소 지정 방식: 오퍼랜드 필드에 유효 주소를 직접적으로 명시하는 방식입니다.

1. 데이터 표현 범위 즉시 주소 지정 방식보다, 간접 주소 지정 방식보다
2. 속도 즉시 주소 지정 방식보다 느림

간접 주소 지정 방식: 오퍼랜드 필드에 유효 주소의 주소를 명시하는 방식입니다

1. 데이터 표현 범위가 큽니다(상대적으로)
2. 속도가 느립니다.

레지스터 주소 지정 방식: 오퍼랜드 필드에 연산에 사용할 데이터를 저장한 레지스터를 명시하는 방법입니다.

1. 데이터 표현 범위가 작습니다.(상대적)
2. CPU 내부 레지스터에 접근하는 방식으로 직접 주소 지정 방식 보다 빠릅니다.

레지스터 간접 주소 지정 방식: 연산에 사용할 데이터를 메모리에 저장하고 유효 주소를 저장한 레지스터를 오퍼랜드 필드에 명시하는 방법입니다
1. 데이터 표현 범위가 큽니다.
2. CPU 내부 레지스터에 접근하는 방식으로 간접 주소 지정 방식 보다 빠릅니다.

주소 지정 방식에 따른 속도와 범위 차이
1. 속도

- 즉시 > 직접 > 간접
2. 데이터 표현 범위

- 간접 > 즉시 > 직접

주소 지정 방식 속도 : 레지스터 > 메모리 (CPU에 가까운 레지스터)

프로그램이 실행되려면 반드시 메모리에 저장되어 있어야 합니다.

1101(2)의 음수를 2의 보수 표현법으로 나타내면

0010 -> 0011

즉 0011(2)로 나타낼 수 있습니다.

Stack, Queue

- Stack

1. 한쪽 끝이 막혀있는 통과 같은 저장 공간

2. 가장 밑에 있는 책을 빼내려면 가장 나중에 놓은 커피잔부터 치워야 책을 꺼낼 수 있다.

이러한 데이터 관리 방식을 LIFO(후입선출)이라고 한다.

정해진 방향으로만 자료를 쌓을 수 있다는 점, top은 가장 최근에 들어온 자료를 가리키고 있다.
새로 들어오는 자료는 top의 자료 위에 쌓이게 된다.
top위에 삽입하는 연산을 push, 삭제하는 연산을 pop이라고 한다.

- 개발자들의 사이트 Stack overflow의 이름은 Stack이 넘치는 경우 발생하는 오류로 사이트의 이름이 유래된 것이다.

사용사례 및 예시 (LIFO)

- 실행 취소

- 브라우저 방문기록

- 후위 표기법 계산

https://pixabay.com/

- Queue

1. 선입선출, 마치 편의점에서 진열하는 것과 같이 먼저 들어온 제품은 먼저 나가는 것 (FIFO)

2. 대기열과 같다고 생각하면 된다

3. 양쪽이 뚫려있는 저장공간

삽입 연산이 이루어지는 곳을 rear, 삭제연산이 진행되는 곳을 front
삽입연산을 enQueue, 삭제연산을 dnQueue라고 한다.

사용사례 및 예시 (LIFO)

- 프린터의 대기열

- 캐시 구현

- 고객 대기시간 관리

https://pixabay.com/

밤리단길 포케~~ 맛집 크랙킨 (Crackin)

sangkins — Fri, 15 Dec 2023 22:59:30 +0900

여자친구가 그렇게 맛있다는 포케맛집이 있다고 해서 찾아온 밤리단길 크랙킨

영업시간 : 화요일 정기휴무, 나머지 11:00 ~ 19:30

위치는 여기.

합정에서 여기까지 왔다. M7731... 999번을 타고 험난한 여정을 거쳐서 도착한 크랙킨

갔는데 웨이팅이 있었음. 평소 웨이팅을 좋아하는 편이 아니라 그냥 다른 곳 갔을 텐데 여기까지 이건 먹어봐야지. 해서 기다림

30분 정도 밖에서 기다리고 있으니 전화로 들어오시라고 알려주신다.

근데 지금 말하는건데 매장에서 2분이 일하고 계신다.

메뉴는 좀 늦게 나오는 편. 한분이 주방, 한분이 서빙 이렇게 하시는데 그릇 치우면서 주문받고 전화해서 알려주시는 게.. 사람을 더 뽑아도 되지 않을까?라는 생각함.

그냥 조금 늦게 나온다~ 생각하면 맘 편함

메인메뉴인 연어포케의 가격은 12,500원 + 연어 좋아하는~ 연어 추가 (3000원인가) 하고 베이컨 크림 까르보나라 16,000원

+ 제로콜라 2,500원 얼음컵에 줘서 좋았따.

얼음컵 안주면 섭섭한 느낌?

음식 사진 부터. 꼬꼬.

처음 봤을때 생각보다 양이 적어 보였는데 먹다 보니.. 맛있게 배부른 양이였슴.

포케.. 내 입맛에 맞을 수도?.. 크림 까르보나라로 버섯, 베이컨이 많이 들어가 있어서 좋았스

다 먹고 하는 말.

설거지 안 하셔도 되용~~~~

최근에 처음 먹어본 음식이 포케인디 자주 먹게 될 것 같다. 처음 먹어본 내 소감은 초고추장 없는 회덮밥.

이제는 맛있어졌달까?

포케도 파스타도 모두 맛있었던 크랙킨! 이었슴다.

한번 먹어보면 또 오는 양꼬치 맛집 한성대양꼬치

sangkins — Fri, 15 Dec 2023 22:56:15 +0900

한성대 양꼬치
서울 성북구 동소문로6길 14-31
전화예약 필수.
02-911-9000

강서에서 강북까지 약 한시간 가량 지하철을 타고 도착한 한성대 양꼬치.
전화로만 예약이 가능하다고 하니 미리 전화로 예약을 해두고 가자.

골목길 사이에 위치하고 있어서 찾기가 힘들 수도 있다.
하지만 찐 맛집이라 하니. 알아서 잘 가보자.

친구가 미리 예약을 해놓아서 편하게 들어갈 수 있었다.

네이버에 한성대 양꼬치를 검색했을때 양꼬치의 가격이 13,000원이라고 나오는데
업데이트하신 지 좀 되신 것 같다. 3월 기준 15,000원이었다.

양꼬치 2인분, 꿔바로우로 스타트.

처음에는 양고기를 여기까지 와서 먹어야 하나 했다. 집 근처에 맛있는 집이 많았기 때문.

이걸 보면

일단 양고기 합격.

가장 괜찮았던 건 꿔바로우였다.
최근에 가장 많이 먹었던 꿔바로우는 합정의 타오라는 마라탕집인데
거기서 나오는 꿔바로우가 진짜 맛있음.

그래서 설마 거기보다 맛있겠어~ 하고 먹었는데
처음에는 읭?..... 이게 무슨맛이지?.... 하는 맛이었다.

일단 양이 많고 소스 맛이.. 진짜 이건 먹어봐야 표현할 수 있는 맛이었다.

물리지 않는 맛. 다시 기억나는 맛. 새콤달콤한데 자극적이지 않은 맛. 다시 먹고 싶은 맛. 이렇게 표현할 수 있다.

다시 그 근처를 간다면 또 가고 싶은 집이었다..

남자 둘이서 꿔바로우에 양꼬치 2인분 + 맥주. 끗. 맛집 인줭.

내돈내산. 여기까지. - 예약은 필수!

영등포 타임스퀘어 매드포갈릭 프리미엄패키지 2인식사권, 위치, 후기

sangkins — Sun, 10 Dec 2023 17:25:58 +0900

매드포갈릭 영등포타임스퀘어점

저녁을 뭘 먹을지 고민하다가 타임스퀘어 안에 있는 매드포갈릭을 방문했습니다.

매드포갈릭 프리미엄패키지를 올해 초에 구매해놓아서 부담 없이 갔습니다

크리스마스가 코앞이라 타임스퀘어 앞에 트리가 생겼습니다!

하루는 굉장히 느린 것 같은데 일년은 굉장히 빨리 지나가는 느낌?

아무튼 그렇게 타임스퀘어 4층 다이닝스퀘어 CGV옆에

매드포갈릭이 있습니다.

프리미엄패키지를 사놓으면 뭐 먹을지 고민 안 해도 돼서 좋은 것 같아요

매장은 타임스퀘어 안 매장이라서 쾌적합니다!

프리미엄 패키지는 매드포갈릭에서 1년에 한번 진행하는 이벤트인데요 날짜를 잘 맞춰서 사놓으면

좋은 것 같네요

프리미엄패키지 2인 식사권에는 음료선택 2잔, 메인메뉴 2개 이렇게 고를 수 있습니다.

저희는 까르보나라, 루꼴라피자?, 오렌지에이드, 맥주를 시켰습니다

식기가 바구니에 담겨 있었는데 포크가 설거지가 조금 덜 되어있어서 교체받았습니다

두콩이가 좋아하는 까르보나라

맛있다고 하네요?

루꼴라 피자? 피자를 시켰습니다. 천 원 추가를 하면 도우가 두껍게 해서 나오는 걸로 추가했습니다

토마토가 상큼한 게 엄청 잘 어울리더라고요

싱싱한 채소가 올라와 있는 게 또 좋았습니다.

다 먹고 나니 상당히 배가 불러서 타임스퀘어를 구경했습니다.

마무리는 배고파서 짜증 날 뻔한 두콩이로.. 마무릐이

[Kubernetes] 쿠버네티스란?

sangkins — Thu, 30 Nov 2023 23:01:03 +0900

쿠버네티스란 무엇인가?

컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성(Portability)이 있고, 확장가능한 오픈소스 플랫폼.
컨테이너 오케스트레이션 도구의 표준이라고 할 수 있다.
k8s (first : k , end : e , length : 8)을 의미한다.

도커 스웜에서 부터 쿠버네티스가 도커의 공식 오케스트레이션 도구로 채택된 여정을 알아보도록 하자

https://kubernetes.io/

전통적인 배포 : 어플리케이션을 물리적 서버에서 실행. 하나의 서버에서 여러 어플리케이션의 리소스 한계를 정의할 방법이 없었기 때문에, 리소스 할당의 문제가 발생함. 리소스 관리의 어려움.

가상화된 배포 : 물리 서버의 해결책으로 가상화가 도입됨. 단일 물리 서버의 CPU에서 여러 가상 머신을 실행할 수 있게 했다. 가상화를 사용하면 VM간에 어플리케이션을 격리하고, 어플리케이션의 정보를 다른 어플리케이션에서 자유롭게 액세스할 수 없으므로 보안성을 제공할 수 있고, 서버에서 리소스를 보다 효율적으로 활용할 수 있으며 더 나은 확장성을 제공한다.

각 VM은 가상화된 하드웨어 상에서 자체 운영체제를 포함한 모든 구성 요소를 실행하는 하나의 완전한 머신.

컨테이너 개발 : 컨테이너는 VM과 유사하지만 격리 속성을 완화하여 어플리케이션 간에 OS를 공유한다. 컨테이너는 가볍다고 여겨진다. VM과 마찬가지로 컨테이너에는 자체 파일 시스템, CPU 점유율, 메모리, 프로세스 공간 등이 있다. 기본 인프라와의 종속성을 끊었기 때문에 이식성이 매우 높다.

컨테이너의 이점

기민한 어플리케이션 생성과 배포
CI/CD
개발과 운영의 관심사 분리
가시성
개발, 테스팅 및 운영 환경에 걸친 일관성
클라우드 및 OS 배포판 간 이식성
어플리케이션 중심 관리
디커플링, 분산, 유연, 자연스러운 MSA

쿠버네티스가 왜 필요한가? 어떤걸 할 수 있는지?

Production 환경에서는 컨테이너를 관리하고 가동 중지 시간이 없는지 확인해야 한다. 이 문제를 시스템으로 처리하는 것이 쿠버네티스이다. 분산 시스템을 탄력적으로 실행하기 위한 프레임워크를 제공하고 확장과 장애 조치 처리, 배포 패턴등을 제공한다.

서비스 디스커버리와 로드밸런싱
스토리지 오케스트레이션
자동화된 롤아웃과 롤백
자동화된 빈 패킹
자동화된 복구
시크릿과 구성 관리

마무리

여러 컨테이너에 걸쳐 어플리케이션 서비스를 구축하고 컨테이너의 일정을 계획, 컨테이너의 상태를 지속 관리, 개발환경 구축 기간 단축, MSA 아키텍처, 낮은 개발 오버헤드, OS가상화로 격리된 테스트 환경 구축이 내가 생각하는 쿠버네티스를 사용하는 이유이다.

docker swarm을 배운 입장에서 kubernetes 의 이해는 큰 어려움은 없을 것 같다.

kubernetes를 사용하면서 생기는 문제들을 트러블 슈팅. 하는 과정들을 블로그에 올릴 예정입니다

Production-Grade Container Orchestration

kubernetes.io

베트남 호치민 벤탄시장, 롯데마트, 용과, 잭프룻 체크아웃!

sangkins — Mon, 27 Nov 2023 00:10:57 +0900

호치민 니코호텔에서 밥을 배부르게 먹고 아까 사 왔던 용과를 깠다!

용과를 처음에 중국에서 먹었었는데 은은한 단맛이 너무 좋다.

나는 맛있게 먹었는데 두콩씨는 이게 무슨 맛이냐면서.. 달지도 않고 맛 없다구 했다... 맛있는뎅.

개인적으로 하얀색보다 빨간색이 더 맛있다!

벌써 출국하는 날이다. 출국을 저녁에 하고 돌아가는 비행기도 저녁이라 그런지 굉장히 짧은 느낌이 들었다

얼마 있지도 않았는데 벌써 돌아가야 한다고? 하는..

그래도 여행을 왔으니 가족, 친구들을 챙겨줄 먹을거리, 기념품을 사러 호치민 롯데마트로 향헀다.

이른 아침에 눈을 뜨자마자 씻지도 않고 갔는데 너무 더웠다

몬스터의 가격은 어딜 가도 그렇게 싸지 않은 것 같아서 찍어놨다. 그래도 우리나라에 비하면 구뜨~

내가 제일 좋아하는 과일들..

벤탄시장에서 위생이 걱정되면 마트에서 과일을 사 먹어도 될 것 같다

두리안도 먹고 싶었는데 두콩씨가 냄새 맡으면 싫어할 것 같아서 사 먹지는 않았다.

가격도 비쌌

그냥 과일 가격이 말이 안 된다. 솔직히 말해서 베트남에서 살라고 하면 살 수 있을 것 같다.

여자들은 꽃을 좋아한다고 한다. 두콩이가 꽃이 예뻤는지 꽃 사진을 잠깐 프로필 사진으로 바꿔놨다.

아직 꽃을 사 준 적은 없다. 조만간 사봐야겠다

맛있는 거밖에 없다. 두리안. 잭프룻. 레드 잭프룻

잭프룻은 자작나무과라 알레르기가 있는 사람은 조심해야 한다.

알러지가 있어서 알러지 약을 먹고 먹었다 ㅎㅎ

킹크랩? 크레이피쉬도 팔고 있었는데 전날 엄청 많이 먹어서 눈에도 안 들어왔다

베트남 와서 제일 많이 사간 커피 종류!

한국인들이 하도 많이 와서인지 직원분이 반드시! 사야 하는 물건 리스트를 보여주셨다

그렇게 담다 보니 좀 많다는 생각이 들었다. 하지만 여행은 그런 거 생각 안 하고 오는 게 진짜 여행이다

이렇게 기념품, 선물을 사고 호텔로 돌아와 체크아웃을 하고 나왔는데...

( - ing )

베트남 호치민 벱꾸온, 통일궁, 하이랜드 커피, 우체국, 벤탄시장까지

sangkins — Sat, 25 Nov 2023 23:18:31 +0900

다음날 조식을 챙겨 먹고 나온 벱꾸온!

Bếp Cuốn 호치민 맛집 (벱 꾸온)

호텔을 나서서 밥을 먹으러 간 곳은 벱 꾸온 리뷰도 좋고 맛있다고 해서 찾아갔습니다 찾게 된 이유는 반쎄오, 스프링롤, 돼지고기 꼬치 구이등 다양한 요리가 한 번에 나와서 같이 간 소식좌(두

holdbird.tistory.com

배부르게 밥을 먹고 통일궁으로 향했습니다.

가는 길에 있는 편의점에서 일본여행에서 물보다 많이 먹었던 아쿠아리우스를 만났습니다.

일본에서 먹었던 그 맛을 기대하고 샀는데... 탄산이 들어간 아쿠아리웃.... 맛이 다르더라고요

탄산이 없는 게 훨씬 맛있습니다.

그렇게 입장한 통일궁!

눈앞에 빨간 버스가 통일궁 입구인 줄 알았는데 출구였습니다.

사진에서 우측으로 가셔야 매표소가 있습니다.

그렇게 매표소에서 표를 끊고 들어온 통일궁!

날씨가 정말 좋았는데 너무 더웠습니다. 택시에서 내리자마자 땀이 줄줄 흐르는 정도

여행 왔으니 사진은 찍어줘야 하는데 사진은 제가 전부 찍고..

여자친구는 사진이라고는.. 찍으라구해야...찍는 것 같네요!! 불만은 아니에요!!

건축물이 상당히 예뻤습니다.

청와대랑 살짝 비슷한 느낌이 났습니다.

안에서 보니 좀 더 멋지더라고요

이 양식에 대해서 설명을 해주시는걸 엳들었는데 벌써 기억에서 사라졌습니다.

영화관도 자리하고 있었습니다!

베트남은 오토바이가 진짜 많은데 한국보다 미세먼지등 공기가 훨씬 좋은 것 같아요

이게 다 왼쪽에 있는 그.. 나라..

표정도 한번 지어주시네요

이 쪽 길은 옥상에서 벙커 가는 길입니다!

실제로 사용하는지는 모르겠지만 헬리콥터 한대가 옥상에 주기해 있었습니다.

벙커로 내려가는데 너무 더워서 힘들었습니다. 손풍기 하나 있으면 좋을 것 같아요

벙커 내부로 들어왔습니다

집무실, 연락망, 회의실, 침실 등등 있었네요.

그렇게 통일궁 구경을 마치고 나가는 길에 하늘이 너무 이쁘더라고요

입구가 아니라 출구입니다!

통일궁 앞쪽에는 큰 공원이 있습니다. 다음으로 갈 장소가 택시 타고 이동하기에는 가까운 것 같아서 걸어서 갔습니다!

너무 더워서 찾은 하이랜드 커피!

쓰어다 커피... PASS

아이스크림과 연꽃씨?가 들어간 음료를 시켰습니다.

저 씨가 진짜 고소하고 맛있더라고요.

편식쟁이 두콩씨는 먹기 싫다고 했지만 한번 먹어보더니 괜찮다 하더라고요!

(괜찮다 하면 진짜 괜찮은 겁니다!! 편식 퇴치 프로젝트 진행 중입니다.)

성당을 구경하려고 했는데 공사 중이어서 그냥 옆으로 쓰윽 지나갔습니다

그리고 눈앞에 있는 백화점을 들어갔는데 사람이 너무 없어서

장사가 되는지 궁금하더라고요.

그래도 백화점답게 있을만한 곳은 다 있었습니다!

베트남의 인플루언서?로 추정되는 여자분이 화보? 촬영을 하시더라고요!

그래서 두콩이도 화보촬영 한번 했습니다

옥상은 이쁘게 꾸며져 있어서 사진 찍는 커플들을 볼 수 있었습니다.

그렇게 성당 옆을 지나가는데 북 스트리트가 있더라고요. 거리가 굉장히 예뻐서 쭉 둘러봤습니다

거리가 굉장히 예뻤습니다. 안쪽에서 책을 읽는 분들이 많더라고요

그렇게 북 스트리트를 걷고 나니 트래블월렛 무료 출금이 가능한 VP Bank가 눈앞에 있더라고요!

VND 동을 거의 다 썼기 때문에 ATM으로 출금을 하고 향한 곳은 바로 옆에 있는 호찌민 우체국입니다

우체국이 진짜 우체국 업무를 하는 우체국이었습니다.

반은 기념품 샵. 반은 우체국 업무를 하더라고요. 편지를 써서 보내시는 분들이 많았습니다.

간단한 기념품을 호치민 우체국에서 사는 것도 좋을 것 같았습니다.

가격도 그렇게 부담되는 가격이 아니었습니다.

이번엔 벤탄시장인 줄 모르고 간 벤탄시장이 아닌 알고 간 벤탄시장을 왔습니다.

벤탄시장에서 과일을 샀는데 사진이 어딨눈지..

호텔에 들려 짐만 내려놓고 니코호텔로 향했습니다

니코호텔 뷔페 후기!

호치민 랍스터 무제한 뷔페 니코호텔 뷔페

호치민에 여행 가면 다들 한번 가본다는 롯데 호텔 뷔페, 니코호텔 뷔페 중에서 니코호텔 뷔페를 grab으로 잡아서 타고 왔다 호치민 랍스터 뷔페라고 치면 가장 먼저 나오는 호텔 니코 사이공 라

holdbird.tistory.com

베트남 호치민 전쟁박물관, 꽌웃웃, 느억미아 포퀸까지

sangkins — Thu, 23 Nov 2023 23:43:55 +0900

하이랜드 커피를 마시고 전쟁박물관으로 이동했습니다. 베트남은 날씨가 너무 더워서 가까운 거리여도 그랩을 타게 되더라고요

입장료 : 40,000 VND 정도니 가깝다면 한번 가볼 만할 것 같아요

호치민 전쟁박물관 · Phường 6, District 3, Ho Chi Minh City 700000 베트남

★★★★★ · 전쟁 박물관

www.google.com

인당 4만 동에 티켓두장을 끊었습니다.

커피를 마시고 전쟁박물관으로 왔는데 갑자기 비가 쏟아지더라고요

앞에 단체 관광객들이 전쟁박물관 안에 비치되어 있는 우산을 마지막으로 들고 가서 비를 맞으며.. 뛰어가다

두콩씨가 발을 다치는 일이 있었습니다.

그래도 베트남은 열대성 기후로 비가 엄청 쏟아졌다가 금방 그치는 편입니다.

그래서 층별로 구경하고 나올 때쯤 비는 전부 그쳤습니다!!

많이 아프겠다~ 그치~?

전쟁박물관은 1층 ~ 3층까지 관람가능, 1층에는 기념품샵도 있었는데 사고 싶은 건 없었네요

명색이 박물관인데.. 에어컨이 없어서 쪼큼 힘들었습니다.

그래도 선풍기가 하나씩은 설치가 되어 있더라고요!

익숙한 방독면이 보입니다...

베트남전쟁.. 고엽제.. 아직도 고엽제로 피해를 받고 있다고 합니다.

전쟁은 일어나서는 안될 일인 것 같습니다.

러시아 우크라이나 전쟁.. 아직 휴전 중인 우리나라도 마찬가지인 듯합니다.

전쟁의 참혹함을 볼 수 있었습니다.

웬만한 정신으로는 사진들을 전부 제대로 보지 못할 것 같았습니다

구경을 하고 나오면 박물관 부지 안에 전쟁 때 쓰였던 전투기, 전차 등등이 전시되어 있습니다.

비가 그친 지 얼마 되지 않아서 인가 날씨가 무척 좋았습니다

그렇게 전쟁박물관을 둘러보고 호치민에 왔으면 먹는다는 1군에 있는 꽌웃웃에 도착했습니다.

꽌웃웃 · 168 Đ. Võ Văn Kiệt, Phường Cầu Ông Lãnh, Quận 1, Thành phố Hồ Chí Minh 70000 베트남

★★★★☆ · 아메리칸 레스토랑

www.google.com

배가 많이 고픈 상태로 도착했는데 직원 분들이 입구에 앉아 계시더라고요

저희는 웨이팅인 줄 알고 옆에 앉아서 웨이팅~? 이렇게 물어봤는데 웨이팅이 맞다고 해서 앉아서 기다리니..

직원분들이 장난친 거라고 하시고 바로 올라가라고 하더라고요

주문은 이렇게 헀습니다.

폭립 한 덩이는 양이 너무 많은 것 같더라고요

소스는 세 종류가 있었는데 BBQ가 제일 무난한 맛이었습니다!

폭립도 부들부들하고, 소시지가 정말 맛있더라구요.

솔직히 폭립보다 소세지가 더 맛있습니다.

맥주는 무조건! PLATINUM KELLER 시키셔야 합니다!!!!!!! 무조건!

아쉬운지 메뉴판을 보고있네욤

화장실에 있던 귀여운 돼지... 돼콩이..

밥을 배부르게 먹고 소화시킬 겸 호치민의 거리를 걸어가는 도중

발견한!!! 유튜브에서만 봤던 느억미아를 영접했습니다.

가격은 단돈 만동!!!! 우리 돈 500원에 양이 엄청 많습니다. 한국에서도 생각나는 맛이었습니다.

비정제 사탕수수 설탕 맛! 딱 그 맛인데. 맛있어요.. 한번 드셔보세요

마트구경 좋아하는 저는 호치민 마트도 한번 들려보고~

과일이 싸서 부럽더라고요.

뭔가 아쉬운 마음이 들어 호치민 대세 쌀국수 집 포퀸을 갔습니다.

두콩이는 배가 불러 저 혼자 시켜 먹었는데요

쌀국수 하나만 시키기에는 조금 그래서 코코넛 음료도 하나 시켰습니다!

음! 다시 안 시켜도 될 맛이었네요!

쌀국수는 진짜 맛있더라고요.

저는 면보다는 밥 파라서. 그렇게 좋아하지 않는데도 또 먹고 싶다는 생각이 들게 하는 쌀국수집이었어요

두콩씨도 여기가 맛있어서 한번 더 오자고 했는데 결국 한번 더 가지는 못했었네요.

라임옆에 같이 보이는 고추가 쌀국수의 기름진 맛을 깔끔하게 잡아줘서 저는 맛있게 먹었는데

두콩씨는 한입 먹어보더니... 물!!! 물!!!! ㅜㅁㄹ!!!! 매워!!!

회전이 빨라서인지 야채들도 신선하고 맛있었습니다.

단점은 현금 결제밖에 되지 않는다는 점 빼고는 없는 것 같습니다.

호치민에서 웬만한 곳은 다 카드가 가능했습니다!

이렇게 또 먹는 걸로 시작해서 먹는걸로 끝나는 호치민의 2일 차가 지나갔습니다.

저는 먹는 게 제일 좋다고요!

* 저는 정말 먹는걸 가리지 않습니다 * <-> 두콩

베트남 호치민 떤딘성당(핑크성당) 하이랜드커피까지

sangkins — Wed, 22 Nov 2023 23:31:52 +0900

배부르게 밥을 먹고

호텔에 도착해서 짐을 풀고, 씻고

호치민에 오면 꼭 보고 간다는

떤딘성당(핑크성당), 벤탄시장, 하이랜드커피를 다녀왔습니다

핑크성당!!

떤딘성당(핑크성당) · 289 Hai Bà Trưng, Phường 8, Quận 3, Thành phố Hồ Chí Minh, 베트남

★★★★☆ · 천주교 성당

www.google.co.kr

날씨가 더워서 호텔 앞에서 그랩을 잡아서 성당까지 갔습니다. 멀리서도 저게 핑크성당이라고 알 수 있을 만큼 눈에 띄어서

쉽게 찾을 수 있었습니다

영화의 한 장면 같았는데 영화 바비가 촬영한곳이 아닐까 했습니다

정말 성당 말고는 볼게 없었습니다.

바로 앞에는 콩카페가 있었는데 이태원 콩카페에서 먹어본 적이 있어서 따로 가지는 않았습니다

성당 내부는 들어갈 수 없었습니다

시장이 가까워서 벤탄시장으로 이동했던것 같네요

처음 왔을때는 여기가 벤탄시장인 줄 모르고 안을 돌아다녔습니다.

시장 내부가 굉장히 덥고 사람도 많아서 금방 나왔네요

벤탄 시장 내부의 특유의 냄새와 더위 때문에 도망치듯이 나와서

베트남의 제2의 스타벅스 하이랜드커피로 향했습니다.

카페는 굉장히 쾌적했습니다. 자리도 넓고 다양한 메뉴들이 있었습니다

길쭉한 반미?, 쓰어다 커피도 여기서 처음 먹어보았는데 음...

베트남 카페에서도 한국 카페와 다를바 없이 공부하고 있는 사람들이 많더라고요

어디를 가나 자기 계발은 필수인 것 같습니다.

하이랜드 커피 원두, 티 기념품을 사갈 수도 있었습니다. 따로 기념품을 사러 갈 필요 없이 카페에서 바로 사가도 괜찮겠더라고요

쓰어다 커피와 커피젤리가 들어간 커피?.. 였는데

쓰어다 커피는 상상이상으로 달아서 두 모금 먹고 전부 남겼습니다.

베트남 여행 가기 전에 쓰어다 커피 리뷰를 많이 보고 갔었는데 달다, 이 정도로만 알고 있었는데

진짜 너무 달아서. (평소 공차 30%) 당도 기준으로... 못 먹었습니다.

저 커피젤리가 들어간 커피는 맛있더라고요! 이름은 잘 모르겠습니다.. 알려주시면 감사!!..

이렇게 또 핑크성당, 벤탄시장인 줄 모르고 간 벤탄시장, 하이랜드커피까지 갔었는데요

이렇게 먹고 또다시 이동했습니다 어디로?

베트남의 스타벅스 Phúc Long 호치민 푹롱티

sangkins — Tue, 21 Nov 2023 23:16:45 +0900

베트남의 스타벅스라고 불리는 Phúc Long에 다녀왔습니다.

바로 앞에 보이는 QUAN 94는 여기에 써놓았습니다~

Quán Thuý 94 호치민 맛집 (콴 뚜이94)

무이네 투어 이후 베트남에서 처음으로 먹은 음식점 맞은편엔 콴 94가 있는데 찾아보니 Quán Thuý 94가 평이 더 좋길래 찾아서 간 곳 위치는 요기.. Quán Thuý 94 - Miến Cua · 84 Đ. Đinh Tiên Hoàng, Đa Ka

holdbird.tistory.com

구글지도를 보니 조금만 걸어가면 베트남 스타벅스인 Phúc Long이 있어서 간단하게 마실 것을 사러 갔습니다.

안녕하세요! 버스

베트남은 신호등이 신호등이 아닙니다.

나는 길이요 진리요 생각하면 오토바이가 알아서 피해갑니다

시원한 에어컨을 맞고 싶을 때쯤 카페 안으로 들어왔습니다

매장 안은 쾌적하고 넓고 공부하는 사람들도 많았습니다

우리나라와 그렇게 크게 다르지 않은 것 같았네요

주문을 하려는데 영어 메뉴판은 따로 없었습니다.

파파고 없었으면 베트남 여행이 조금 힘들었을 수도... 있을 것 같네요

그렇게 해서 주문한 우롱밀크티와 피치 밀크티!

디저트와 음료 같은 것도 팔고 있었는데 한국과 물가차이가 많이 나는 것 같네요

디저트가 2,000원 정도 생수는 800원 정도 했습니다

카페 한편에서는 푹 롱에서 파는 차와 커피들이 있었습니다

기념품으로 사가면 괜찮을 것 같네요

- 자스민 티 향이 엄청 좋더라고요

우롱밀크티와 피치밀크티!

- 우롱 밀크티는 쌉싸름한 맛이 도는 제 취향이었습니다. (공차 우롱밀크티 당도 30%) 정도?

- 피치 밀크티는 안에 과육이 들어있었는데 제 입맛에는 너무 달아서 (공차 당도 70%) 정도 같았습니다.

당도가 조금 줄었으면 맛있었을 것 같네요!

푹 롱티는 베트남 여행 중에 두콩씨와 같이 여러 번 갔습니다. (우롱밀크티 진짜 맛있어요!..) 꼭 드셔보시길

포장해서 그랩을 잡아 호텔로 복귀했습니다

24시간 만에.... 씻을 수 있다니..

강추 : 우롱밀크티

베트남 호치민 무이네 사막투어 요정의샘 후기

sangkins — Tue, 21 Nov 2023 15:51:27 +0900

무이네 사막투어 후기

호치민하면 무이네 투어를 꼭 간다고 해서 예약한 무이네 사막투어를 다녀왔는데요

호치민에서 무이네까지는 편도 3시간 정도가 소요된다고 하네요

일정

01:30 공항에서 픽업
04:40 무이네 도착 - 지프차로 환승
05:30 화이트 샌듄 일출 구경
06:40 U코너 사진 촬영
07:00 용과밭 방문
07:30 피싱빌리지
07:45 레드 샌듄
08:15 요정의 샘
09:20 무이네 -> 호치민 출발

호치민 ~ 무이네 지프투어 픽업

지프차 기사님이 첫 번째로 데려다주신 곳은 바로 화이트 샌듄이라는 사막인데요. 공항에서 픽업시간이 조금 늦었는데

기사님이 빨리 달려주셔서 해가 뜨기전에 도착할 수 있었네요

풀 한포기 없는 사막을 생각했다면 환상이 깨질 수도 있습니다

화이트 샌듄에 도착하면 ATV를 인당 30만동에 끊었습니다. ATV 탈 때마다 보여줘야 하는데 한 번밖에 안 보여준 것 같네요

화이트 샌듄에서 일출을 볼때는 5시간이 넘는 비행과 차량이동으로 생긴 피곤함이 한 번에 날아가는 듯..

여행은 여유로움 같다. 이 시간만큼은 시간에 쫓기고 살지 않아도 된다는?

왜 무이네 사막 투어를 오는지 알 수 있었네요

화이트 샌듄으로 올라오려면 ATV를 타거나, 걸어 올라와야 하는데 솔직히 ATV 없으면 이동이 힘들었습니다.

인당 30만 동으로 약 1만 6천 원 정도 했었습니다.

사막 투어 가시면 꼭 사막 썰매 요금을 알아보고 타세요... 저흰 호구당해서

타고나니깐 10만 동 요구하더라고요.. 알아본 게 없어서 10만 동을 줬는데 비싸도 2만 동... 당해주지 마세요..

아직도 기분이 나쁘지만 여행지라 그냥 당했구나 생각하고 넘겼습니다

씻지를 못해서 말이 아니다..

피싱 빌리지를 지나서 도착한 레드 샌듄

기사님이 30분 후에 오라고 했는데 너무 덥고 힘들어서 15분도 못 돌아보고 차로 돌아왔다

화이트 샌듄이 엥 이게 사막이라고?라고 하면

레드 샌듄은 이게 사막이지~ 하는 그런 느낌?

마지막 코스는 요정의 샘!

입장료는 현금으로 냈어야 했던 것 같다.

신발을 벗고 맨발로 들어갔는데 모기를 여기서 물렸다.

이렇게 걸어서 올라가는데 바닥이 울퉁불퉁한 곳이 많아서 발바닥이 조금 아프기도 했다

조금 깊은 곳도 있어서 조심해서 올라가면 좋을 것 같다

중간중간에 기념품 샵들도 있었는데 구경하면서 가는 것도 나쁘지 않다

일단 발이 시원해서 습하고 더운 날씨에도 조금 선선하게 느껴졌다

이렇게 베트남의 그랜드 캐니언?이라고 생각하고 열심히 돌아다녔다

반대쪽으로도 가봤는데 냄새가 심해서 도중에 돌아왔다. 이렇게 무이네 사막 투어 일정이 끝났다.

지프차 기사님은 요정의 샘 까지만 데려다주고 돌아가셨다. 팁은 10만 동 드렸다.

운전해 주시는 분도 10만 동 드렸는데 사막썰매 한 번에 10만 동?.. ㅎㅎ

무이네에서 호찌민 까지 이동해주시는 기사님께는 20만 동 드렸다

그렇게 숙소에 짐을 풀고 Quan Thuy94로 갔다.. 한 끼도 못 먹어서 매우 배가 고픈 상태

처음으로 가본 베트남에서 좋은 추억이 될 무이네 사막투어

한 번쯤은 가보면 좋을 것 같다.

이렇게 행복한 베트남에서 하루가 시작됐다

AWS App2Container Application Containerize

sangkins — Sun, 19 Nov 2023 23:32:32 +0900

온프레미스 어플리케이션을 AWS로 마이그레이션 하게 되었다.
Docker + Kubernetes로 배포와 운영을 표준화하였으면 한다.

기존의 Java 어플리케이션을 Containerize 해야 하는데
AWS의 A2C라는 CLI command Tool이 있다.

간단하게 Jar 어플리케이션을 컨테이너화, 분석, CI/CD 파이프라인 사용

간단한 자바 어플리케이션을 A2C로 Containerize 해보려고 한다

A2C (App2Container) 란?

AWS App2Container (A2C)는 온프레미스 데이터 센터 또는 가상 머신에서 실행되는 애플리케이션을 리프트 앤 시프트 하여 Amazon Elastic Container Service (Amazon ECS) 또는 Amazon Elastic Kubernetes Service (Amazon EKS)에서 관리하는 컨테이너에서 실행되도록 지원하는 CLI Tools.

애플리케이션 컨테이너화 - AWS App2Container - Amazon Web Services

AWS App2Container(A2C)는 Java 및 .NET 웹 애플리케이션을 컨테이너 형식으로 마이그레이션하고 현대화하는 명령줄 도구입니다. AWS A2C는 베어 메탈, 가상 머신, Amazon Compute Cloud(EC2) 인스턴스 또는

aws.amazon.com

사전지식

1. Dokcer 컨테이너 이해
2. 컨테이너화가 실행될 위치 결정
3. EC2 인스턴스의 보안그룹
4. AWS 기본 베이스 (IAM, ECS, EKS 등등)
5. IAM Role
6. Key Pair

1. Amazon Linux2 (AMI)
2. Storage >= 20Gb (최소 용량 20GB. 30GB로 잡음)
3. 적절한 IAM Role이 부여된 계정
4. Key 페어 생성

EC2 인스턴스 생성

키 페어 생성

보안그룹은 HTTPS, HTTP 트래픽 허용 TCP 80 Port를 열어주는 보안그룹을 설정하면 된다.

EC2 인스턴스 볼륨의 크기는 20 GiB 이상으로 잡아주면 된다.

A2C에서 20 GiB이상이 요구된다.

AWS에서 제공하는 Connect to instance로 연결

1. Key ID 입력
2. Secret Access Key 입력
3. EC2 인스턴스 시작 리전 입력 - ap-northeast-3
4. Output format : json 상관없음

A2C Flow

1. 실행 중인 어플리케이션을 검색하고 어플리케이션을 분석

2. 어플리케이션을 Containerize

3. Dokcer의 Image Size (조정)

4. 대용량 파일을 식별

5. analysis.json 파일의 appExcludedFiles , appSpecificFiles 업데이트.

1. Linux java 설치

#wget https://download.oracle.com/java/17/latest/jdk-17_linux-x64_bin.rpm

#sudo rpm -ivh jdk-17_linux-x64_bin.rpm

#sudo alternatives --config java

#java -version

2. Linux Docker 설치

서울 리전에서 실행 시 sudo yum update 에러로 오사카 리전에서 실행함.

# 패키지 업데이트
sudo yum update -y

# docker 설치
sudo yum install docker -y

# docker 서비스 실행
sudo service docker start

# ec2-user를 docker 그룹에 추가
sudo usermod -a -G docker ec2-user

3. Server로 jar 파일 전송 (Test)

- SCP -i로 전송

EC2 인스턴스에서 전송된 파일 확인

4. A2C 다운로드 (AWS 인스턴스)

#Amazon S3에서 App2Container 설치 패키지 다운로드
curl -o AWSApp2Container-installer-linux.tar.gz https://app2container-release-us-east-1.s3.us-east-1.amazonaws.com/latest/linux/AWSApp2Container-installer-linux.tar.gz

#서버의 로컬 폴더에 패키지 추출
sudo tar xvf AWSApp2Container-installer-linux.tar.gz

#패키지에서 추출한 설치 스크립트 실행
sudo ./install.sh

#검증을 위해 해시 생성
sha256sum AWSApp2Container-installer-linux.tar.gz

#다운로드의 진위 여부 확인

#1. App2Container 인증서 다운로드
curl -o app2container.cert https://app2container-keys.s3.us-east-1.amazonaws.com/latest/app2container.cert

#2. App2Container 서명 파일 다운로드
curl -o app2container.sig https://app2container-release-us-east-1.s3.us-east-1.amazonaws.com/latest/linux/app2container.sig

#3. 서명 확인
openssl dgst -sha256 -verify app2container.cert -signature app2container.sig /usr/bin/app2container

5. Jar 파일 실행 및 확인

#& -> 백그라운드에서 실행 java 앞에 nohup을 붙이면 무중단 배포.
java -jar xxxx.jar & 

#pid 확인
ps -ef

#종료
kill -9 pid

어플리케이션 동작 확인.

6. App2Container 초기화

App2Container의 전역 설정을 초기화 및 환경 설정.

sudo app2container init

#작업 공간 디렉토리 경로 : /root/app2container

#AWS 프로필 : default

#Amazon S3 버킷 : 기본값 no bucket

#명령 생성 아티팩트 : App2Container 지원에 자동업로드 y

#사용량 지표 수집 권한 : y

#서명된 이미지 적용 여부 : n

7. 어플리케이션 분석

sudo app2container inventory

java-app-id

java-app-id : java-generic-88209a86

sudo app2container analyze --application-id java-generic-88209a86

어플리케이션의 분석결과가 json 형태로 저장된다.

analysis.json

이미지의 크기 최적화 문서 참조

AWS App2Container 생성 도커 이미지 최적화 - AWS Prescriptive Guidance

이 페이지에 작업이 필요하다는 점을 알려 주셔서 감사합니다. 실망시켜 드려 죄송합니다. 잠깐 시간을 내어 설명서를 향상시킬 수 있는 방법에 대해 말씀해 주십시오.

docs.aws.amazon.com

8. 어플리케이션 변환

#어플리케이션 서버에서 어플리케이션을 컨테이너화
sudo app2container containerize --application-id java-app-id

용량에 따라 시간이 어느정도 걸릴 수 있음

9. 어플리케이션 배포

AWS EKS, ECS, App Runner에 배포.

# ECR Repository 생성
- generate app-deployment

#배포 파일 사용자 정의 X
- generate app-deployment--deploy

#AWS에 어플리케이션 배포
- sudo app2container generate app-deployment --application-id java-app-id

10. Clean

1. App2Container /usr/local/app2container 설치된 폴더 삭제

2. AWS profile 정리 - awsconfigure set

이렇게 간단하게 A2C를 이용하여 Linux 서버에서 Java 어플리케이션을 Analysis, Containerize, Deployment까지 하는 법에 대해서 알아봤다. 간단한 Jar 어플리케이션을 분석해서 올리는건 쉬운일이지만 MSA로 구성된 어플리케이션을 A2C로 분석해서 배포하는 건 상당한 어려움이 있을 것 같다.

문서 참조

What is AWS App2Container? - AWS App2Container

What is AWS App2Container? AWS App2Container (A2C) is a command line tool to help you lift and shift applications that run in your on-premises data centers or on virtual machines, so that they run in containers that are managed by Amazon ECS, Amazon EKS, o

docs.aws.amazon.com

틀린 부분은 댓글로 남겨주시면 감사합니다.

호치민 여행 1일차 딴선넛 국제공항

sangkins — Sat, 18 Nov 2023 20:16:33 +0900

호치민 가는 날!
베트남이 은근히 가까울 줄 알았는데 비행시간이 5시간을 넘어서 조금 당황했다.
퇴근을 하자마자 집에 들러 캐리어를 챙겨서 공항철도를 타고 공항에 도착

저녁 9시 비행기로 호찌민 딴선넛 국제공항에 새벽 1시에 도착하고 바로 무이네 사막투어... 일정이 좀 빡빡하다 그쵸?

무이네 사막투어 링크는 아래에!

공항에 도착해서 KB 국민카드 혜택인 100원으로 밥을 먹으려 했는데.. 내 카드는 만료돼서 못쓰고 두콩이 만 백 원으로 밥 먹었다.

스마트 패스를 미리 해놓아서 매우 매우 빠르게 출국심사를 받았다
해외 나갈 거면 미리 해놓는 게 편할 듯? 줄 서있는 사람들이 저게 뭐냐고 보는 시선이 있다 ㅋㅋㅋ

제주항공을 이용했는데 무슨 일인지 탑승동으로 가는 트레인을 안 타고 출국장 바로 옆에서 탑승을 했다

그래도 출국길이니 젠틀몬스터 들려서 두콩이 한컷.. 다음에 사주께..

평일 오후에 출국하는데도 인천공항에는 사람이 많았다
이렇게 매일 놀러 다니고 싶지만..... 언젠가는 할 수 있지 않을까?

출발하기 전에 모종의 일이 있어서.. 사진이 없다.. 헿~ (미안)

두콩이는 잠을 잘 잤다고 하는데 나는 한숨도 못 잤다.. 비행기에서 자는 게 좀 힘들다. 이건 돌아오는 비행기에서는 기절함 ㅋㅋㅋ

비행기 탑승~

길고 긴 비행....

짐 찾고 걸어가다 보면~

처음으로 마주하는 호찌민 떤선넛 국제공항~

마지막으로 나가기 전에 캐리어를 X-Ray 검사하는데 사람들은 많고 하나밖에 없어서 시간이 좀 걸림

한국에서 구매한 esim이 작동을 안 해서.. 공항에서 급하게 50만동(2인) 주고 데이터 무제한 유심을 구매함..
짱 비싸다..

그냥 뭔가 느낌 있게 한컷

호치민 픽업 기사님들

표정이 너무 힘들어 보여서 초상권 보호.. ㅋㅋㅋ

무이네까지 데려다 주실 기사님이 픽업 장소를 알려주셔서 캐리어를 끌고 갔다
호치민의 날씨는 굉장히 습하고 더웠다

중간에 이렇게  한 번씩   쉬고  갔다

이렇게 차를 타고 3시간을 간다. 우리나라에서 택시 3시간 타면 얼마지?..라는 생각

예약한 무이네 사막 투어는 마이리얼트립에서 예매했다. 2명 해서 24만 원?
혹시 몰라 링크도 남겨둠

(단독투어) 호치민출발 무이네지프투어-고속도로이용 편도2.5시간!

무이네의 거대한 사구, 요정의 샘을 방문하고 인생샷을 남겨보세요.

www.myrealtrip.com

해가 뜰 때쯤 지프기사님을 만났는데 급하셨는지 덜컹덜컹 엄청 빠르게 갔었다

다음편에 계속

호치민 랍스터 무제한 뷔페 니코호텔 뷔페

sangkins — Wed, 15 Nov 2023 20:47:39 +0900

호치민에 여행 가면 다들 한번 가본다는 롯데 호텔 뷔페, 니코호텔 뷔페 중에서 니코호텔 뷔페를 grab으로 잡아서 타고 왔다

호치민 랍스터 뷔페라고 치면 가장 먼저 나오는 호텔 니코 사이공 라 브래서리를 갔다 왔다.

5성급 호텔답게 입구부터 깔끔하고 로비를 들어서서 바로 앞에 보이는 2층으로 올라가는 계단으로 올라가면 된다. 옆에는 엘리베이터도 있으니 타고 올라가면 된다.

처음 도착해서 뷔페 위치를 못 찾아서 직원분께 물어봤다

2층으로 올라와서 직원분에게 예약자명을 말하면 테이블로 안내해 준다. 이때 멤버십을 가입하면 할인이 들어가니 방문전에 멤버쉽 가입은 필수

멤버쉽 가입

One Harmony | Okura Nikko Hotels Membership Program

One Harmony is a unique membership program that rewards you when you stay at Okura Hotels & Resorts, Nikko Hotels International or Hotel JAL City hotels. No matter where you go in Japan or overseas, you can earn points and enjoy special services, privilege

oneharmony.com

멤버십 가입하는데 물어보는게 많아서 생각보다 귀찮긴 한데 10%할인은 은근히 크다. 멤버쉽 번호를 받아서 적어갔다

호텔뷔페 예약

La Brasserie

Cuisine: International Location: Level 2 – Capacity: 250 seats*** Breakfast: Daily 6:00 AM – 10:30 AMDinner: Daily 6:00 PM – 10:00...

hotelnikkosaigon.com.vn

혹시 모르니 예약을 하고 갔다 근데 그냥 가도 딱히 상관없어 보였다 주말저녁이나 금요일 저녁만 피하면 예약 없이 가도 무난할듯하다.

영업시간인 18:00 분 전에 가서 로비에 앉아서 기다리다가 바로 입장했다. 테이블에 앉으면 직원분이 어떤 Drink를 마실건지 물어본다.

레드와인, 화이트와인, 맥주, 구아바쥬스 그렇게 있었다.

랍스터도 주문을 앉아서 직원분에게 요청하는 방식이었는데 버터 앤 갈릭, 치즈, 타마린, 싱가폴, 블랙페퍼 맛이 있었다.

처음에 주문을 여러 개 했는데 주문이 꼬인 건지 주문한 건 안 나오고 순서도 이상하게 나왔지만 맛있어서 그냥 먹었습니다.

직원분이 안내해 주신 자리. 다 좋았지만 바로 옆이 직원분이 일? 하시는 곳이라 살짝 정신없었다.

직원분이 아이스박스 안에서 굴을 까서 바로 신선하게 먹을 수 있었습니다. 한국에서도 이런 크기의 굴은 본 적이 없는데 호치민와서 먹었습니다.

옆에 있는 라임을 짜서 굴 위에 뿌려먹으니 비린맛도 없이 맛있었는데...

같이 간... 두콩씨가... 음... 음.... 음.....

SAMPLE이라고 적혀있는 크랩, 랍스터(크레이피쉬)였는데 중국인들이 와서 다 담아갔다가 직원분들이 제지해서 다시 돌려놓는 구경을 했습니다.. ㅎㅎ

고등어회, 참치, 문어 등등이 있었는데 진짜 고등어회가 제일 맛있습니다.

와사비 맛은 여타 뷔페와 다를게 없이 크레파스 와사비?.. 매운맛도 없고 단맛도 없고.. 그냥 간장이랑 같이 먹는 게 제일 무난했습니다.

그렇게 가져온 접시! 랍스터는 굉장히 부드럽고 맛있었습니다. 큰 새우 맛? 좋았습니다. 화이트와인.. 해산물에는 화이트 와인이죠 6~7잔 먹었습니다.

전반적으로 육류의 상태는 썩 좋지 못했습니다. 육류의 상태보다는 소스가 더 맛이 없기도 했고요.

버터앤갈릭 랍스터. 두콩씨 말로는 버터갈릭향이 거의 없어서 일반 랍스터인 줄 알았다고 합니다.

다양하고 이쁜 디저트들이 많았지만 거의 먹지 못했습니다

제가 좋아하는 수박과 용과는 많이 먹었습니다.

굴은 맛있고 고기는... 나머지 음식 상태가 그렇게 썩 좋지는 못했습니다. 신선하지 않다는 게 아니라 제 입맛에 맞지 않았다는 겁니다.

먹기가 정말 힘들었던...... 맛있습니다! 먹기가 굉장히 힘들어서 한번 먹고 안 먹었던 것 같네요

다양한 메뉴들이 있었습니다.

주문하면 구워진 고기를 올려주시는데 차갑게 식은 고기라서.. 생각보다 별로였습니다.

생선을 그 자리에서 튀겨주신다네요 먹어보지는 못했습니다. 따뜻하니 맛있을 수도?

이 고기 앞에 있는 소스들이 전부 제 입맛, 두콩이 입맛에도 맞지 않아서 잘 안 먹었습니다.

딤섬은 두 종류가 있었는데 한번 먹고 음... 이였습니다. 아시죠?

빵 종류도 많아서 먹어보고 싶었네요

피자! 은근히 맛있었습니다. 스프링 롤도 그렇게 맛있다고는 못 느꼈네요

씁쓸한 레드와인도 한잔 먹어봤습니다. 저는 화이트 와인이 더 취향인 것 같았습니다.

니코호텔 뷔페에 가시면 고등어회는 진짜 꼭 드셔야 합니다.. 진짜로요..

제가 좋아하는 과일들이 신선하고 맛이 있어서 정말 좋았습니다.

배가 불러서 정신이 혼미할 때쯤... 걸어 나왔습니다.

제대로 뽕뽑고 온 뷔페. 베트남 호치민 해산물 뷔페 호텔 니코 사이공 라 브래서리였습니다.

2인 기준 멤버십 할인가 3,371,217동 나왔습니다. (약 18만 원)

니코호텔 뷔페 위치

호텔 니코 사이공 · 235 Đ. Nguyễn Văn Cừ, Phường Nguyễn Cư Trinh, Quận 1, Thành phố Hồ Chí Minh 70000

★★★★★ · 호텔

www.google.com

호치민 여행에서 충분히 가볼 만한 곳으로 추천합니다.

Bếp Cuốn 호치민 맛집 (벱 꾸온)

sangkins — Tue, 7 Nov 2023 14:09:32 +0900

호텔을 나서서 밥을 먹으러 간 곳은 벱 꾸온

리뷰도 좋고 맛있다고 해서 찾아갔습니다

찾게 된 이유는 반쎄오, 스프링롤, 돼지고기 꼬치 구이등

다양한 요리가 한 번에 나와서 같이 간 소식좌(두콩)이를 위해서...

벱 꾸온 바로 앞에는 HCMC 대학교가 있었다

HCMC는 호치민 시티 ㅋㅋㅋㅋ

그렇게 들어간 벱 꾸온!

Bếp Cuốn Sài Gòn · 76 Võ Văn Tần, Phường 6, Quận 3, Thành phố Hồ Chí Minh 700000 베트남

★★★★★ · 베트남 음식점

www.google.com

메뉴판에 메뉴가 많았지만 돌고 돌아서 고른

가장 많이 팔린 콤보?

약 60만동

맨 밑에 부가세 VAT 별도라고 나와있는데

결제할 때는 60만 동 그대로 낸 것 같다.

실내는 굉장히 쾌적했고 2층도 있는 것 같았다.

우리는 딱 문 바로 앞에 자리를 안내받았다.

자리에 앉고 나서 직원분이 와서 반쎄오를 먹는 법을 아냐고 물어보신다

당연히 모른다고 했더니 친절히 장갑을 끼시고 알려주신다

특제소스 제조법까지 (칠리소스 + 땅콩소스)

베트남 김치까지?

굉장히 친절하셨던 게 인상 깊다.

유명한 맛집답게 가격은 베트남 물가로는 쉽지 않다.

약 60만 동 세트메뉴를 시켰다.

딤섬을 튀긴듯한 만두? 에는 게살 + 새우살이 들어가 있어 맛있었음

월남쌈도 소스 찍어먹으니 맛있었다

전반적으로 깨끗하고 맛있는 음식들이었다

양이 너무 많아..

많아서 남긴 반쎄오. 해산물은 영 내 취향이 아니였음 ㅋㅋㅋ

전반적인 음식들이 굉장히 다 맛있었고

기억나는 맛이었다

하나만 빼자면.. 돼지고기 꼬치구이? 그건.. 음 굳이 안 먹어도 될듯한 맛

맥주도 시켜 먹고 싶었는데 세트메뉴에 음료가 포함되어 있어서 못 시킨 아쉬움이 남는다

(반쎄오 먹고 입천장 다 까진 건 비밀.)

맛있게 식사를 하고 떤딘성당(핑크 성당) 구경하러 갔다

Quán Thuý 94 호치민 맛집 (콴 뚜이94)

sangkins — Sun, 5 Nov 2023 15:53:10 +0900

무이네 투어 이후 베트남에서 처음으로 먹은 음식점

맞은편엔 콴 94가 있는데 찾아보니 Quán Thuý 94가 평이 더 좋길래 찾아서 간 곳

위치는 요기..

Quán Thuý 94 - Miến Cua · 84 Đ. Đinh Tiên Hoàng, Đa Kao, Quận 1, Thành phố Hồ Chí Minh, 베트남

★★★★☆ · 해산물 요리 전문식당

www.google.com

방문한 시간대가 점심시간이 살짝 지나있어서 여유로운 편이었다

2층에는 에어컨도 나온다고 했는데 1층에 앉았다.

앉자마자 주문한 짜다, 사이공 맥주

물갈이를 한다면 얼음은 먹지 말 것... 위생이 어쩔지 모르니

식탁은 스테인리스 식탁에 바닥은 쓰레기가 많은 편..

베트남은 휴지나 물티슈를 사용하고 바닥에 막 버리는 듯?.. 싶었다

메뉴판을 보고 주문한 게 튀김 30만 동?..

소프트 쉘 크랩 튀김

주인아주머니가 소스에 찍어먹으면 된다고 알려주신다.

칠리소스를 같이 주시는데 같이 먹으면 깔끔하니 맛있다.

튀김이 4조각 나오는데 더 나왔으면 느끼해서 못 먹었을 듯.

굉장히 맛있었다.

약 20만 동?..

게 내장과 살을 같이 볶아준 게살볶음밥 한 번쯤 먹어본 맛이었다.

게 껍질도 종종 들어있으니 조심하자.

게살 볶음밥을 그냥 먹고 있으니 주인아주머니가 오셔서 간장을 따라주셨다.

게살 볶음밥을 간장에 적셔 먹으니 완전히 다른 음식이 됨..

꼭 간장 찍어먹도록 하자.

8만 동 모닝 글로리 (4만 동인지 기억이 안 남)

모닝글로리가 굉장히 맛있었다

밥이랑 같이 먹으면 딱 좋은 나물 반찬 같은 느낌이라 거부감 없이 먹기 좋았다.

이 가격에 생각할 수 없는 양이 나와서 당황했다...

이렇게 게튀김, 게살 볶음밥, 모닝글로리, 맥주, 짜다 를 시키고 총 60만 동 아래로 나왔었다.

베트남 물가로 보면 굉장히 비싼 편이지만

호찌민에서 처음 먹은 음식치고 굉장히 맛있었다.

베트남에 또 한 번 온다면 한번 더 갈만한 그런?

위생을 생각한다면 그리 좋지는 않지만 여행지에서 이 정도는 괜찮다고 생각한다.

배부르게 밥을 먹고 나오자마자 있는 꽃집.

다음에는 꼭.. 꽃 사줄게.. (두콩)

배부르게 먹고 심야 비행 + 무이네 투어로 지친 몸을 이끌고

숙소로 향했다.

두콩이 표정이 말이 아니었다. (몸도 안 좋고)

숙소로 잡은 더해먹호텔 파인 아츠 뮤지엄에 도착하니

일요일이 할로윈이라 숙소도 할로윈 컨셉에 한참이였다!!

무이네 투어는 다음에 계속

설악 쏘라노 바베큐장 후기

sangkins — Thu, 15 Jun 2023 15:14:29 +0900

오랜만에 속초 한화리조트 아니 설악 쏘라노에 다녀왔습니다.
예전에는 가족여행을 속초로만 다녀서 익숙한 곳인데 오랜만에 와서 설레었습니다.

전날 천둥번개가 엄청 쳤었는데 여행당일에는 날씨가 이렇게 좋을 수가..

네고왕에서 구입한 숙박권으로 설악 쏘라노를 예매했습니다
금요일과 주말에는 추가요금이 붙더라고요 저는 10,000원 더 결제했습니다.

놀러 가면? 저녁에 고기를 구워 먹어야죠 설악 쏘라노 리조트는 굉장히 넓은 편에 속해서 1동 ~ 6동까지 이루어져 있는데 1동부터 바베큐장에 가깝습니다. 생각보다 거리가 꽤 되니 알아두셔야 할듯해용

설악 쏘라노 바베큐장 예약은 전날 예약하라고 했지만 전화해서 물어보는 시간 맞춰서 그냥 오면 된다고 했습니다!

운영시간은 18 ~ 22:00까지는 넉넉합니다.

바베큐장 입구

설악 쏘라노 바베큐장 위치입니다.

설악 쏘라노 바베큐장 033-630-5756

하루 전에 전화하라고 하셨는데 비성수기라 그런지 예약 없이도 충분히 입장했습니다!!

매점은 앞쪽에 있는 컨테이너로 음료, 얼음컵등 사소하게 살만한 것들이 있었습니다.
고깃값은 많이 비쌌다는 점...

바베큐장에 기본으로 세팅된 기구들입니다!
2인세트, 4인세트, 숯불, 장갑, 조리기구 대여가 있는데 저희는 숯불 + 조리기구 대여해서 50,000원 결제했습니다.
필요하신 건 쏘라노 지하에 있는 GS25에서 구매하시면 됩니다..!!

5만 원에 대여해서 젓가락, 일회용기 같은 건 제공하는 줄 알았는데 아니었습니다.. 정말 그냥, 숯불, 불판, 장갑, 가위, 집게 정도만 대여해 주니 나머지는 챙겨가시면 됩니다.

접시, 젓가락 등은 다 따로 사셔야 한다는 점

설악 쏘라노 본관 지하에 위치한 GS25에서 사 온 음료, 맥주들
바비큐장안에서 물, 음료, 얼음컵, 고기도 추가 주문할 수 있습니다. 얼음컵 파는 건 정말 좋은 것 같네요!

개수대는 깔끔하게 관리되고 있었고 바로 옆 쓰레기장에 분리수거해서 버려주시면 됩니다.

이렇게 설악 쏘라노에 위치한 바베큐장에 다녀왔습니다.
가족 또는 친구들과 행복한 시간을 보내기에는 정말 좋은 것 같네요!

단점은 벌레가 많고, 화장실이 멀다......... 진짜 멀다.. 다시 GS25까지 가서 화장실 가거나. 돌아서 내려오면 보이는 건물에 화장실이 있다고 하는데 여긴 안 가봐서 잘 모르겠네요

GS25까지 가려면 진짜 멀어요..

바베큐장의 느낌, 음악, 음식들을 정말 잘 즐기고 왔던 행복한 하루였습니다.

고기는 부족해서 추가 구매했는데 사서 가시는 걸 추천합니다! 100g에 5,000원 정도 하니 (삼겹살, 목살 기준) 넉넉하게 사 가세요!!

행복했던 하루였습니다

일산 마라탕 맛집 웨스턴돔 래격마라탕

sangkins — Wed, 31 May 2023 16:36:00 +0900

예전에 맛있게 먹었던 기억이 있는 일산 웨스턴돔에 위치한 래격마라탕에 다녀왔다
비가 많이 오는 날이어서 실내에 위치한 음식점을 찾아봤는데 웨스턴돔 입구에서 가까운 래격마라탕!

매일같이 마라탕 먹자구 보채는 사람이 있어서 한번 더 방문했다

전화 : 0507-1378-3006
영업시간 : 11:00 ~ 22:00

먹느라 정신없어서 홈페이지에서 가져온 메뉴판...

입이 짧은편이라 마라탕은 4000원 정도 담고 소고기 추가해서 7000원어치
꿔바로우는 15,000원 + 빙홍차 4,000원 해서 한 2만 6천 원 정도 나왔던 것 같다.
공깃밥도 한번 시키면 계속 먹을 수 있으니 좋은 듯

마라탕

맛있는 마라탕이라고 생각함
합정에 위치한 타오 마라탕이 범접불가일 뿐

타오마라탕

https://holdbird.tistory.com/12

꿔바로우

꿔바로우는 타오마라탕에 비하면 소스가 싱거운 편이다. 물리지 않고 많이 먹을 수 있다는 점? 타오는 자극적인 맛을 위주로 했다면 슴슴한맛의 꿔바로우를 내보이는 래격마라탕
양이 굉장히 많은 편이다. 튀김옷은 조금 두꺼운 편. 고기가 조금 얇다. 이 정도.
평소에 슴슴하게 먹는다면 맛있게 먹을 래격마라탕 꿔바로우.

슴슴한맛의 맛있는 꿔바로우는 한성대양꼬치에서도 찾을 수 있다.

중국여행에서 맛있게 먹은 빙홍차
이제 한국에서도 쉽게 찾아볼 수 있는 음료지만 마라탕집에서 먹는 중국음료는 맛있다.

맛있게 먹고 나왔다! 우리의 마음속 1등은 타오마라탕이지만
래격마라탕이 맛이 없다는 건 아니다!!
근처에 있으면 자주 올 맛! 래격 마롸탕~

함박 오마카세 맛집 합정 함박 후기

sangkins — Thu, 18 May 2023 21:29:07 +0900

합정에 위치한 함박스테이크 오마카세? 함반에 다녀왔습니다.
위치. 영업시간은 잘 아실 테니 생략하겠습니다

합정역 8번 출구에서 5분 정도 걸으면 나오는 함반 입니다.

함반의 마스코트 입간판. 직화 함박스테끼.

메뉴판과 소스

방울양배추 치즈구이가 추가되는 함반 2인으로 주문했습니다!
월요일 이른 저녁에 방문해서 웨이팅은 없었습니다
한 5시 반쯤. 6시 이후에 도착한다면 웨이팅이 상당할 것 같아요.

매장 안에 테이블의 개수가 많지 않고 코스 요리식으로 나오기 때문에 식사시간이 좀 걸리는 편인 것 같네요
함반 2인은 모아 함반 2인 + 방울 양배추 치즈구이가 천 원 할인돼서 같이 있는 세트였는데
방울양배추치즈구이가 아주 요물... 위에 치즈에 간이 되어있는 방울양배추, 브로콜리 뭔지 알 수 없는 소스가 굉장히 맛있어서 좋았습니다.
모아 함반은 닭 + 돼지 + 소고기 함박이 순서대로 나오는 코스입니다.
함반에 처음 간다면 추천드려요

처음으로 나오는 닭 함박

오돌뼈가 씹히는 식감이 있는 함박인데 개인적으로 저는 이런 식감을 별로 안 좋아하는데도 맛은 있었습니다.
추천 소스가 아마 레몬 소금, 바질 소스였던 것 같네요.
저는 표고 와사비가 제일 맛있었습니다.

두 번째로 나온 돼지 함박!

항정살로 만든 돼지 함박이라고 했는데 굉장히 맛있었습니다.
진짜 맛있음.
이것도 표고와사비랑 같이 먹으니깐... 밥이 술술 들어가서 나올 때 3 공기 먹고 나왔습니다.
이때쯤인가 방울양배추치즈구이가 나왔습니다.

보이는 만큼 맛있었습니다. 안 시켰다고 생각하면 후회했을듯.
참고로 밥과 밑반찬은 처음에는 세팅해 주시고 테이블 뒤쪽에 물, 밥솥이 있어서 직접 퍼 드시면 됩니다.

그리고 마지막에 나온 소고기 함박 - 최고

포포리 계란 + 타래 간장 + 밥
맛있는 간장계란밥에 맛있는 소고기를 같이 먹는데 맛없없.

먹다 보니 밥 3 공기.. 배빵빵..

망원한강공원

망원 한강 공원을 소화시키러 가고~

참고로 계산은 자리에서 도와주십니다!!!

합리적인 가격으로 기념일, 맛있는 한 끼를 즐기고 싶다면, 웨이팅을 감수할 수 있다면
합정역 함반. 가볼만하쥬?

슥 지나친 맛집 뚝섬(성수) 밸런스포케

sangkins — Sun, 14 May 2023 23:18:58 +0900

5월이 어느 정도 지난 지금

사람 많고 카페 많기로 유명한 성수에 다녀왔습니당

날씨는 진짜 덥더라고요 낯에는 덮고 저녁에는 추운 이 모호한 날씨

그래도 한 여름보다는 좋더라구용

점심시간을 살짝 넘겨서 돌아다니다 보니 대부분의 식당이 브레이크타임을 가지고 있더라고요

밸런스포케도 브레이크타임이 있었지만 매장에 들어가서 여쭤보니 웨이팅 리스트에 써 주시면 빈자리 치우고 불러주신다고 하셔서

브레이크타임에도 들어갔습니다!!!

위치 : 서울 성동구 서울숲4길 28 1층

전화 : 070-7585-2299

뚝섬역에서 도보 5분

주말이라 그런 건지는 몰라도?..

배가 고파서 메뉴판을 못 찍어서..

현재 메뉴판 가격이랑 차이가 조금 있더라고요?? 참조하세요

시킨 메뉴는 베스트 메뉴인 하와이안 칠리 쉬림프와 연어포케!!! 연어추가는 4,500원이었는데 연어가 떨어졌는지 연어 추가가 안되고 다음 손님부터는 연어포케 품절...

전체 메뉴~

기본적으로 토마토 마리네이드? 같은 상큼한 입가심도 할 수 있고 할라피뇨 + 양파절임이 있어서 입을 깔끔하게 먹을 수 있었다

쬐큼 심심하게 먹는 편이라 간은 적당했는데 일반적이라면 조금 싱거울 수도 있는 연어 포케!!

아마 소스 더 달라고 하면 더 주시지 않을까?

하와이안 칠리 쉬림프는 다시 방문하면 무조건 시킬 정도로 소스가 맛있었음. 그릇까지 싹싹 비우고 나왔는데 올리진 않~

진짜 의외로 기대를 1도 안 하고 갔는데 만족감이 컸던 밸런스 포케. 포케중독자라면 한번 가고 두 번갈 집.

+ 하와이안 칠리 쉬림프에 반할 수도

성수역에서 걸어서 뚝섬 근처에 있는 포케 맛집 밸런스포케. 무튼 내돈내산.

나의 페이보릿 텐동 웨스턴돔 고쿠텐 (일산)

sangkins — Wed, 10 May 2023 09:40:05 +0900

맛집 리뷰? 그냥 블로그를 쓰는데 말을 어떻게 해야 할지가 고민이다.
그냥 남에게 이야기 해주는 것처럼 쓰거나 반말? 경어? 생각하지 않고 쓰고 있지만 하나로 통합을 해야 할 듯해서..

아무튼 텐동을 별로 좋아하지 않았었는데 착각을 깨준 첫 번째 텐동집이 일산 웨스턴돔에 위치한 고쿠텐

위치 : 일산 웨스턴돔

전화 : 0507-1328-3247

브레이크 타임 : 15:00 ~ 17:30 주말에는 없다!!

평일 : 20 : 30 라스트 오더, 21 : 00 영업 종료

주말 : 20 : 00 라스트 오더, 20 : 30 영업 종료

고양페이 O

혼밥 O

처음에 위치가 굉장히 헷갈렸는데 메인 스트리트 기준으로 에스컬레이터 타고 올라가서

바로 오른쪽으로 가면 됨(래격마라탕) 처음에 헤매어서 엄청 걸었음....

매장은 그렇게 크지 않은 편이고 주말에는 웨이팅도 있었음

세트메뉴는 천 원 정도 할인이 들어가서 세트 메뉴로 먹음

기본인 고쿠텐동 + 장어텐동에다가 음료 2개 혹은 맥주 2잔으로 시킬 수 있는데 양이 상당히 많으니 조심하자.

기본적으로 텐동은 주문하고 튀겨준다 그쵸?

근데 맥주는 앉아서 주문하자마자 바로 나옴.

텐동과 같이 먹어야 맛있을 것 같은데. 일찍 주셔서 이따 달라고 하기에도 좀 그래서 말을 안 했다..

다음 방문 때는 말을 하거나 음식과 같이 달라고 말을 해야겠다고 생각함.

이건 별개로 텐동은 진짜 맛있음. 튀김옷이 얇은 편에 대식가도 울고 갈 양. 밥, 와사비, 장국 제공

밥을 더 달라고 요청하니 온천 계란은 서비스라고 주시는 친절함.

정말 맥주 먼저 나온 것 뺴고는 완벽한 서비스.

SET 1

장어도 짱커서 나눠 먹으면 딱 좋음

진짜 맛있는 간장 계란밥

내가 제일 좋아하는 계란

이건.. 그냥 양이 많아서 보여주고 싶었음

텐동 하면 양이 적어서 밥대신 먹기 좀 그렇다~라고 생각한 편견을 깨준 맛있는 텐동집

+ 밥을 추가로 요청했는데 온센 타마고까지 서비스로 주셨다.

오늘부터 내가 좋아하는 텐동집.

일산 고쿠텐이었다~

몇 없는 서울 애슐리 퀸즈 여의도 한강공원점 후기

sangkins — Thu, 4 May 2023 00:01:26 +0900

마지막으로 다녀온지 약 5년정도 지난 것 같은 애슐리에 다녀왔다.
신촌에 애슐리퀸즈가 있을때 마지막으로 다녀왔으니 얼추 비슷하다.

여의도 한강공원에 위치해 있는 애슐리 퀸즈

전화 : 0507-1414-1063
주차 : 한강공원 제1 주차장, 이랜드 크루즈 주차장 3시간 무료. 퇴점전 직원에게 말하면 된다.

평일 런치 가격 : 19,900원
평일 디너 가격 : 25,900원
주말/공휴일 디너 가격 : 29,900원

초등학생, 미취학 아동은 싼 편임.

오를대로 오른 물가에 아직 잘 버티고 있다고 생각.
빕스와 가격차이가 얼마 나지 않았다고 생각했는데 빕스는 주말 저녁 기준.... 45,900원.....................

평일 저녁에 방문해서 인당 25,900원에 뷔페를 즐기고 왔다.
네이버 예약을 하는 경우에는 한강뷰 창문 쪽 자리에 안내해주시는듯

애슐리 20주년 행사를 하고 있었다.
내 기준 메뉴... 음 딸기 행사할 때 올걸이라는 생각이 들었음. 지극히 내 기준

여의도 애슐리는 여의나루역에서 꽤 떨어져 있어서 상당히 걸어가야 했음.
봤을 때 굉장히 작아보인다. 들어가면 좀 다름

밑에 있는 키오스크에서 결제하고 2층으로 올라가면 직원분이 자리를 안내 해 주신다.

식기반납은 예전에는 직원분들이 직접하셨는데 인건비 절약은 로봇이 짱이지..
이제 테이블 위에 있는 버튼만 누르면 푸드봇이 테이블로 와서 그릇을 넣고 확인 누르면 끄으으읏~~

메뉴는 생각보다 실망스러웠다.
그냥 예전 애슐리 그대로. 그냥 런치로 가면 기분좋게 먹고 나올듯 싶었음.
펩시제로만 많이 먹고 나왔다 With 훈제 연어 짱.

의외로 배추구이 맛있다. 한번 먹어보길 바람.

아 최악은 한치 초밥... 진짜 뱉고 싶었다. 진짜 진짜로..

훈제 연어. 맛있는 양념 치킨들로만 먹고 나오면 후회하지는 않을듯
런치로 가면 추천. 디너는 음음~~ 라이브 스테이크가 아닌 폭립 나오는 곳으로 가는게 좋을 것 같다.
한강뷰를 즐기면서 저녁을 먹을 수 있다는 점에서 좋다. 저녁을 먹고 나서 산책해도 좋은 위치에 있어서 좋음

단점 : 역에서 멀다

자꾸 생각나는 합정역 타오마라탕

sangkins — Tue, 25 Apr 2023 23:54:14 +0900

위치 : 서울 마포구 양화로6길 19 광명빌딩 2층

: 0507-1318-5344

: 포장, 무선 인터넷, 반려동물 동반, 남/녀 화장실 구분

합정에서 가장 많이갔던 집.. 타오 마라탕에 다녀왔습니다. 아마 이번년도에만 6번 정도??

그만큼 맛은 보장되어있다는 거니깐~ 가봅시당

여타 다른 마라탕집과 같이 마라탕, 마라샹궈, 꿔바로우 그리고 쉽게 볼 수 없는 위미라?

마약 옥수수 맛이당. 한번 도전해봤는데 실패는 없었음

언제나 사람은 많지만 6시10분 정도에 가면 웨이팅도 별로 없고 회전률이 빨라서 기다리는데 큰 무리는 없다

입이 굉장히 짧은 분이랑 같이가서 마라탕이 적어 보일수도?
소고기, 양고기, 삼겹살을 추가할 수 있는데 이번에는 새로운 시도로

삼겹살을 추가해봄

결론 : 소고기, 양고기 추가해서 맛있게 먹자.

위미라

갈때마다 옆테이블에서 시켜서 먹고있어서 궁금해서 시켜본 위미라. 대만 마약옥수수 뭐시기라구 한다.

존맛.

합정근처에서 마라탕이 생각날때.. 라고 하고 여자친구가 마라탕 먹자고 하면 여기를 오니깐 열번은 더 가지 않을까?

둘이가서 2만원 초반대에 배부르게 먹고 나왔으니 마라탕은 가성비 맛집 아닐까? 이정도면 국밥을 대체할 수 있을 것 같다.

그돈이면.. 씨... 마라탕 한그릇에 위미라시켜먹구말지..

마라샹궈 후기도 있는데 내 입맛에는 마라탕이 조금 더 맞았던 걸루.

합정 느낌있는 바베큐 맛집. 슬로우야드

sangkins — Fri, 14 Apr 2023 00:07:30 +0900

슬로우야드 바베큐

전화 02-332-0999

매일 11:30 - 23:00

브레이크타임 15:00 - 17:30

카페 운영 15:00 - 17:00

슬로우야드 바베큐

생일을 맞이해서 개장한 지 얼마 안 된? 3~4달 된듯한 따끈따끈한 슬로우야드 바베큐에 다녀왔다.

캐치테이블로 예약할 수 있어서 예약하고 방문했다.

슬로우야드를 가는 길에 밖에서 바라봤을 때는 뷰가 엄청 좋아 보였는데....

미국 정통의 맛 슬로우야드

들어가면 이런 느낌이었다

굉장히 인테리어를 감각적으로 해놓아서 사진찍기에도 좋았

예약을 하고 간거라 들어가자마자 2층으로 올라갔다. 1층은 아마 런치메뉴, 카페 운영할 때 사용하는듯

가격대가 있는 식당은 마찬가지겠지만 세팅해놓은 식기가 느낌이 좋다

- 메뉴판 -

4명이서 파티플래터, 사이드는 감자튀김, 발사믹 머쉬룸으로 선택했는데 진짜 맛있음.

좋은건 더 가까이

처음 받아보고 이게 양이 되겠어~? 했는데 오산이었음.

진짜 배부름. 심지어 고기만 저 정도 양이라 다 먹기도 힘들다. 코울슬로 짱맛, 발사믹 샐러드? 완전 맛있다.

모닝빵 사이에 폴드포크 넣고 코울슬로, 감자튀김 넣어서 먹으면 극락.

데이트하는 분들도 많고, 회식하기에도 좋고, 분위기 좋고 맛도 좋은 바베큐집이 근처에 있어서 좋은 것 같다.

그... 분이 하시는 거기까지 안가도 좋은 것 같다~

진짜 고기고기가 먹고 싶을 때 찾으면 좋은. 합정 슬로우야드였다.

합정(전국) 최고의돈까스 카와카츠 오토코

sangkins — Fri, 31 Mar 2023 13:21:46 +0900

내 기준 최고의 돈까스 맛집

합정 카와카츠 오토코

돈까스를 좋아하는 사람이라면 들어봤을 카와카츠 합정에만 두 곳이 있다.

개인적으로는 최근에 생긴 카와카츠 오토코가 더 입맛에 맞았다.

- 위치 -

대로변에서 한번 꺾기만 하면 카와카츠 오토코가 보인다.

- 메뉴판 -

등심을 더 좋아하는 편이라 돈까스집을 가면 등심만 시키는 편이다.

맛있는 돈까스를 근처에서 먹을 수 있어서 좋다 생각하지만

제로콜라 4천원...............................

쉽지 않았다.

- 첫 번째 방문 -

1번째 방문

퇴근 후 방문을 해서 약간의 웨이팅? 10분 정도 기다린 후 자리에 착석했다.

카와카츠 본점과는 달리 카와카츠 오토코는 전좌석이 바 형식으로 되어있었다.

맛은... 항상 그렇듯 이것보다 더 돈까스가 맛있을 수 있나 싶다.

밥과 장국은 요청하면 바로 리필해 주신다.

와사비도 요청하면 주신다.

여기서 돈까스를 먹는다면 돈까스 소스에 찍어먹지 않는 걸 추천.

소금, 와사비 그 두 개면 돈까스 본연의 맛을 느낄 수 있음.

- 두 번째 방문 -

다음에 방문했을 때는 웨이팅 없이 바로 들어갔다.

그런데... 주문을 하고 한 30분 정도가 되었는데도 음식이 안 나오고 늦게 들어온 다른 테이블음식이 먼저 나왔다.

그래서 직원분이 늦어져서 죄송하다 하고 제로콜라를 서비스로 주셨다.

늦었지만 제로콜라 하나에 풀리는 이 간사한 마음....

직원분들은 전부 친절하시다.

로스와 히레 두 가지를 전부 먹어보고 싶은 분은 모듬카츠를 시키면 되는데

생각보다 양이 굉장히 많아서 남기는 경우도 있으니 알아두쇼.

그리고 계산은 음식을 다 먹은 후 자리에서 카드를 넘겨드리면 된다!

이런 사소한 서비스가 만족을 준다

맛 : 전국 돈까스 최고 (내기준)

서비스 : GOOD

가격 : GOOD (제로콜라....)

위치 : GOOD

재방문의사 : O