문제

오늘 복습해 볼 문제는 2월에 과제로 받았던 다리를 지나는 트럭이다. 링크

문제 요약

다리의 길이와 무게를 기준으로 두고 모든 트럭이 다리를 건너려면 최소 몇 초가 필요한지 구한다.

##  예시 ## 

# bridge_length=2, weight=10, truck_weights=[7,4,5,6]
# 초기큐 : queue=[0,0], truck_weights =[7,4,5,6], total=0
# 1초: queue=[0,7], truck_weights[4,5,6], total=7
# 2초: queue=[7,0], truck_weights=[4,5,6], total=7 (4는 무게초과로 대기)
# 3초: queue=[0,4], truck_weights=[5,6], total=4```

이전 풀이

from collections import deque
def solution(bridge_length, weight, truck_weights):
    # 다리를 나타내는 큐 (다리 길이만큼 0으로 초기화 - 0은 빈 공간)
    queue = deque([0] * bridge_length)

    # 대기 중인 트럭들을 큐로 관리
    orders = deque(truck_weights)

    # 경과 시간
    time = 0

    # 현재 다리 위에 있는 트럭들의 총 무게
    total = 0

    # 1. 대기 중인 트럭이 없어질 때까지 1초씩 시뮬레이션
    while orders:
        time += 1

        # 2. 1초가 지났으므로 다리 위 모든 트럭이 한 칸 앞으로 이동
        #    맨 앞 칸(queue[0])이 다리를 완전히 벗어나므로 총 무게에서 제거
        total -= queue[0]
        queue.popleft()

        # 3. 대기 중인 첫 번째 트럭이 다리에 올라갈 수 있는지 확인
        #    현재 다리 위 총 무게 + 다음 트럭 무게가 제한 무게를 초과하면
        #    트럭을 올리지 않고 빈 공간(0)으로 채워 다리 길이를 유지
        if total + orders[0] > weight:
            queue.append(0)
        else:
            # 4. 무게 제한 이하이면 대기 트럭을 다리에 올림
            #    대기 큐에서 트럭을 꺼내 다리 큐에 추가하고 총 무게 갱신
            w = orders.popleft()
            total += w
            queue.append(w)

    # 마지막 트럭이 다리를 완전히 건너는 시간 추가
    return time + bridge_length

새 풀이

큐에 0을 넣지 않아도 풀 수 있다.

이전 코드는 트럭이 다리에 올라가지 못할 때 deque에 0을 넣고, 올라갈 수 있을 때까지 반복했다.

그러나 트럭이 다리에 올라갈 때마다 무게, 나가는 시간을 저장한다면 불필요한 반복 연산시간을 줄일 수 있을 것이다.

예상되는 효과는 아래와 같다.

(1) 대기 시간을 매 루프마다 소비하지 않고 앞 트럭이 나가는 시간으로 바로 점프해 불필요한 반복을 제거할 수 있다

(2) 나가는 시간이 미리 저장되어 있어 마지막에 time + bridge_length 를 별도로 계산하지 않고 바로 반환할 수 있다.

from collections import deque

def solution(bridge_length, weight, truck_weights):
    # 빈 큐로 시작 - 0으로 채울 필요 없이 (무게, 나가는 시간)으로 관리
    bridge_queue = deque()

    # 대기 중인 트럭들 관리
    waiting_trucks = deque(truck_weights)

    # 현재 시간
    current_time = 0

    # 현재 다리 위 총 무게
    current_weight = 0

    while waiting_trucks:

        # 1. 나가는 시간이 된 트럭만 골라서 제거
        while bridge_queue and bridge_queue[0][1] <= current_time:
            current_weight -= bridge_queue.popleft()[0]

        # 2. 다음 트럭을 올려도 무게 제한을 넘지 않는 경우
        if current_weight + waiting_trucks[0] <= weight:

            # 대기 트럭 꺼내기
            truck_weight = waiting_trucks.popleft()

            # 현재 다리 무게 증가
            current_weight += truck_weight

            # 트럭이 다리에 올라가는 시간
            current_time += 1

            # 3. (무게, 나가는 시간)을 함께 저장
            # 나가는 시간 = 현재 시간 + 다리 길이
            bridge_queue.append(
                (truck_weight, current_time + bridge_length)
            )

        else:
            # 4. 다음 트럭을 못 올리는 경우

            # 앞 트럭이 나가는 시간으로 바로 점프
            if bridge_queue:
                current_time = bridge_queue[0][1]

            # 예외 처리용
            else:
                current_time += 1

    # 마지막으로 저장했던 트럭이 다리를 완전히 건너는 시간 출력
    return bridge_queue[-1][1]

주요 자료구조

deque

# <파이썬 알고리즘 인터뷰> p.266, 책만, 2020

일반적인 큐는 뒤에서만 삽입이 이루어지고 앞에서만 인출이 가능한 반면, 데크(Deque)는 양쪽에서 모두 삽입과 삭제가 가능해 스택과 큐의 특징을 모두 갖고 있다.

물론 이 문제에서 양쪽 삽입과 삭제를 활용하지는 않았지만, 일반적인 리스트의 삭제 연산인 pop(0)보다 popleft()가 빠르기에 성능 최적화에 도움이 되었다.

pop(0) vs popleft()

# list.pop(0) → O(n)
lst = [1, 2, 3, 4, 5]
lst.pop(0)
# [1, 2, 3, 4, 5]
#  ↑ 제거
# [2, 3, 4, 5]
#  ↑ ↑ ↑ ↑ 나머지 요소를 전부 한 칸씩 앞으로 당김 → 요소 수만큼 연산 발생

# deque.popleft() → O(1)
from collections import deque
dq = deque([1, 2, 3, 4, 5])
dq.popleft()
# [1, 2, 3, 4, 5]
#  ↑ 제거
#     ↑ 포인터만 다음 요소로 이동 → 요소 수와 무관하게 연산 1번

진정한 테토 호소인 는 선크림도 바르지 않고, 걱정도 하지 않는다. 그치만 언니가 고민해 보라고 했으니 고민이라는 것을 해보겠다.

트래픽이 증가한다

트래픽은 서버의 데이터 전송량을 의미한다. 외부에서 해당 서버에 접속하는 사용자가 많아질수록 트래픽은 증가한다.

만약 서버가 감당할 수 있는 한계를 초과한 트래픽이 지속적으로 유입되면, 서버는 정상적으로 동작하지 못하고 결국 다운된다.

따라서 평소보다 트래픽이 10배 이상 급증한다면, 별도의 대비가 없는 서버는 분명히 다운된다.

Next.js에서 트래픽 증가

Next.js를 사용한다고 가정해보자.

Next.js는 싱글 스레드 기반의 자바스크립트 런타임인 Node.js 위에서 동작하며, 서버에서 리소스를 미리 렌더링한 뒤 브라우저에 전달하는 SSR(Server Side Rendering) 방식을 지원한다. Node.js는 I/O 작업에는 뛰어난 성능을 보이지만, CPU 중심 작업에서는 단일 스레드만 사용하기 때문에 적절한 구성 없이 많은 작업을 처리할 경우 성능 문제가 발생할 수 있다.

(1) 서버 병목현상 또한 싱글 스레드 환경에서는 병렬 처리가 제한되므로 작업을 순차적으로 처리하게 된다. 따라서 복잡한 페이지를 SSR하는 동안 서버는 다른 요청을 즉시 처리하지 못하고 대기 상태에 놓일 수 있다.

(2) 대규모 트래픽 처리 한계 소수의 요청만 처리할 때는 큰 문제가 없지만, 초당 수백 명 이상의 사용자가 동시에 접속하는 상황에서는 순차 처리로 인해 응답 시간이 증가하고 서버가 다운될 가능성도 존재한다. 결국 단일 스레드 기반 환경에서는 병목 현상과 블로킹 현상이 발생할 수 있으며, 과도한 서버 부하는 렌더링 성능 저하로 이어질 수 있다.

해결책

캐싱 전략을 사용하면, 서버가 동일한 데이터를 반복적으로 렌더링하지 않아도 되어 서버 부하를 줄일 수 있고, 응답 속도가 개선되어 대규모 트래픽 상황에서도 안정적인 서비스 운영이 가능해진다.

캐싱전략 : 자주 사용하는 데이터를 빠르게 접근할 수 있도록 저장해 성능을 최적화하는 전략

강제캐싱(force-cache)

우리가 fetch API로 캐싱을 수행할 때 별도의 옵션을 지정하지 않으면, 브라우저는 사용자가 이전에 동일한 요청을 보낸 적이 있는지 HTTP 캐시를 먼저 확인한다.

• HTTP 캐시에 최신 데이터가 있다면 : 서버 요청 없이 캐시 데이터를 즉시 반환
• HTTP 캐시에 오래된 데이터가 있다면 : 서버에서 데이터 변경 여부를 확인한 뒤 캐시를 사용하거나 갱신할 수 있는 조건부요청 발신
• 일치하는 캐시가 없다면 : 서버에 새 요청을 보내 응답 데이터를 캐시에 저장

하지만 이러한 과정에서는 캐시의 최신 여부를 검사하기 위한 추가 요청이 발생하므로 일정한 시간이 소요된다.

따라서, 강제캐싱 (force-cache) 을 사용한다면,

• 서버로부터 받은 응답 데이터를 캐시에 저장
• 최신화되었는지 여부를 판단하지 않고, 사용자 요청시 일치하는 데이터가 있다면 즉시 반환

하여 위 과정을 축소하고 서버로 보내는 요청 수를 줄여 서버 부하를 줄일 수 있다.

예시

// 강제캐싱을 헤더에 사용하는 경우
fetch('/api', { cache: 'no-store' })

// 강제캐싱을 응답에 사용하는 경우
fetch("some.json", { cache: "force-cache" }).then((response) => {
  /* 상세 생략 */
});

Revalidation

강제 캐싱은 서버 요청 수를 줄여 성능을 향상시킬 수 있지만, 캐시된 데이터의 최신성을 보장하지는 않는다. 따라서 데이터 변동성이 높은 서비스에서는 일정 주기마다 캐시를 재검증하고 갱신하는 Revalidation 전략을 사용하여 이를 보완할 수 있다.

※ 재검증 과정에서 추가적인 서버 요청이 발생하므로 강제 캐싱에 비해 응답 속도가 조금 느려질 수 있다. 감안하여 사용하자.

예시

// 30초간 캐싱하고, 이후에는 새로운 요청보내기
fetch('/a', { next: { revalidate: 30 } })

정리

ISR(Incremental Static Regeneration)을 이용한 페이지 캐싱

웹 페이지를 미리 생성하는 렌더링 기법인 ISR(Incremental Static Regeneration)을 사용하면, 최초 요청 시 생성된 정적 페이지를 캐싱하여 빠르게 제공할 수 있다.

최초 렌더링 이후 변경되는 데이터는 필요한 시점에만 SSR(Server Side Rendering), CSR (Client Side Rendering) 등으로 다시 렌더링함으로써, 성능 최적화와 데이터 최신성을 모두 고려한 효율적인 렌더링이 가능하다.

예시

※ ISR을 대규모 서비스 환경에서 안정적으로 운영하기 위해서는 데이터 요청 처리 외에도 Redis와 같은 별도의 캐싱 서버를 구축하여 캐싱된 페이지 데이터를 중앙에서 관리하는 작업이 필요하다.

여러 개의 Node.js 서버 인스턴스가 각각 독립적으로 캐시를 생성하고 관리하는 구조에서 발생할 수 있는 캐시 불일치 문제를 해결해야하기 때문이다.

// 페이지 라우터

export const getStaticProps = async () => {

  // 데이터 요청
  const data = await fetch('/a')
    .then((res) => res.json())

  return {

    // 컴포넌트에 전달할 props
    props: { data },

    // 30초마다 페이지 재생성(Revalidation)
    revalidate: 30
  }
}

function Page({ data }) {

  // 캐싱된 정적 페이지 반환
  return <div>{data.title}</div>
}

// 앱라우터

// → 해당 페이지를 30초 주기로 재생성

export const revalidate = 30

async function Page() {

  // fetch 결과를 캐싱
  const data = await fetch('/a')
    .then((res) => res.json())

  // 캐싱된 페이지 반환
  return <div>{data.title}</div>
}

export default Page

씨스터디 결론

💚🌼 msms804 🌼💚 : 트래픽이 갑자기 10배 늘어나면 가장 먼저 걱정할 것은 무엇인가요?

Profitah : 평소보다 예측하기 어려운 수준의 트래픽이 발생한 만큼, 가장 먼저 우려되는 것은 과도한 서버 부하와 이로 인한 서버 다운 가능성입니다. 사용자가 서비스 이용 중 불편을 겪으면 이탈로 이어지고, 이는 매출 감소로 직결될 수 있습니다. 따라서 빠른 장애 대응과 안정적인 서비스 복구를 최우선으로 문제 해결에 집중하겠습니다.

우선 이상 트래픽이 감지되는 즉시 웹페이지를 일시적으로 제어하고 서버 점검 안내를 선제적으로 제공하여 사용자 불편을 최소화하겠습니다. 이어서 서버 사양을 높이고 대수를 늘리는 방식으로 급증한 트래픽을 분산 처리할 수 있는 환경을 구축하겠습니다.

서버가 안정화된 뒤에는 서비스 특성에 맞는 렌더링 방식과 캐싱 전략을 적용해 서버 부하를 줄이고 응답 속도를 개선하겠습니다. 최신 데이터 반영이 중요한 게시판은 서버 사이드 렌더링(SSR)을 적용하고, 데이터 변경이 적은 정적 페이지는 재검증 기반 캐싱(ISR) 또는 정적 사이트 생성(SSG)과 브라우저 캐싱을 활용해 서버 부담을 분산하겠습니다.

또한 요청 빈도가 높은 데이터는 Redis와 같은 캐싱 서버에서 중앙 관리하여 서버 간 캐시 불일치를 방지하고, 반복 요청을 줄여 낮은 비용으로 높은 성능 효율을 확보하겠습니다.

참고문서

Request: cache 속성

프론트엔드 개발자의 대규모 트래픽 처리?? 🤔

청약통장 이벤트 진행을 위해 갭체크를 진행했는데, 시뮬레이션 유형에서 가장 많은 어려움을 느꼈다. 특히 제한 시간 내 문제를 해결하지 못해 2문제는 풀이를 마무리하지 못했으며, 이를 통해 시뮬레이션 유형에 대한 개념 이해와 문제 접근 방식이 부족하다는 점을 뼈저리게 실감했다.

시뮬레이션이란

코딩테스트에서 시뮬레이션이란, 제시된 알고리즘이나 규칙을 한 단계씩 차례대로 직접 수행하여(모방하여) 정답을 도출하는 알고리즘 유형을 의미 한다.

예시유형

위와 같이 구하고자 하는 값이 어떻게 구해지는지, 일정한 규칙을 찾으면 시뮬레이션을 정복할 수 있다.

문제풀이

a, b, c, d = map(int, input().split())

# Please write your code here.
start  = a * 60 + b   # 시작 시간(ab)를 분으로 변환
end = c * 60 + d     # 종료 시간 (cd)를 분으로 변환

# 뺄셈하여 구한 시간의 차이를 변수 gap 에 저장
gap = end - start

# 결과 출력
print(gap) 

시(hour)를 뜻하는 a c 에 60을 곱하여 분으로 변환하고 (1시간은 60분임으로) 종료시간에서 시작시간을 빼, end에서 start까지 몇 분이 걸리는지 구하였다.

고민한 것

a, b, c, d = map(int, input().split())

elapsed_time = 0

while True:
    if a == c and b == d:
        break

    elapsed_time += 1
    b += 1

    if b == 60:
        a += 1
        b = 0

print(elapsed_time)

시작시점과 종료시점을 분으로 변환하지 않고 풀이하는 방법도 고민했지만, 보다 직관적인 풀이를 위해 해당 방식은 사용하지 않았다.

이 풀이에서는 시작 시점부터 종료 시점까지 1씩 증가시키며, 목표에 도달하기까지 몇 번 증가했는지를 계산하여 전체 경과 시간을 구하였다.

결론

시뮬레이션 문제는 다양한 방법으로 풀이할 수 있지만, 문제의 출제 의도와 연산 효율성, 그리고 코드의 가독성을 종합적으로 고려하여 핵심 규칙을 찾아 풀이하는 것이 가장 유의미하다고 생각한다.

뿐만 아니라 시뮬레이션적 사고를 키우는 것은 알고리즘 문제 풀이와 코딩 테스트의 핵심적인 가치 중 하나다. 주어진 조건과 상태의 변화를 단계적으로 추적하고, 이를 코드로 정확하게 구현하는 능력을 기르는 데 중요한 역할을 하는 훈련은 단순히 문제를 푸는 행위를 넘어, 복잡한 현실의 요구사항을 논리적으로 분해하고 재구성하는 문제 해결 능력으로 이어질 것이다.

1줄요약 : 시뮬레이션 문제 열심히 풀겠다.

그러다 부트캠프 동기들을 통해 이번 활동을 알게 됐다. 나와 속도를 맞추어 함께 달려주었던 고마운 사람들이다.

이번 대외활동에 합류하게 된다면, 정글에서 그랬듯 단순히 지식을 쌓는 것을 넘어 서로 건강한 자극을 주고받으며 함께 성장할 수 있을 것 같아 기대된다.

아울러, 실무 경험이 풍부한 멘토님의 건강한 지도 아래에서 더 규칙적이고 좋은 루틴을 만들어갈 수 있을 것이라는 점 역시 기대하고 있다.

캐시(Cache)란?

자주 사용하는 데이터를 미리 복사해 두는 임시 저장소.

자주 사용하는 데이터의 사본을 저장해 두고, 데이터나 값에 대한 요청이 들어오면 빠르게 처리할 수 있도록 도와주어 데이터를 가져오는 시간이 오래 걸리거나 재계산하는 시간이 오래 걸리는 작업 효율화에 도움을 준다.

예시

응답 속도 향상 + 서버 부하 감소 + 대규모 트래픽 분산 처리 + 외부 API 호출 비용 절감 효과를 위해 캐시를 활용한 서비스들

• 인스타그램 : 피드에 들어갔을 때 친구 게시물, DM, 릴스, 내 프로필 정보 등의 데이터를 미리 캐싱해 두고, 조회 요청이 들어오면 빠르게 읽을 수 있도록 해준다.

• 셋로그 : 메인 화면에서 시간대별 친구 영상 데이터와 영상에 대한 댓글 데이터를 미리 캐싱해 두고, 조회 요청이 들어오면 빠르게 읽을 수 있도록 해준다.

캐시 불일치 (Cache Inconsistency)

캐시 불일치는 원본 데이터베이스에 저장된 데이터와 캐시에 저장된 데이터가 서로 다른 상황

캐시와 DB의 불일치는 왜 발생하나

서버 간 네트워크 문제, 비동기 처리로 인한 DB 저장과 캐시 갱신 간의 지연, 동시성 문제 등

캐시는 DB의 데이터를 복사하여 저장하는 임시 저장소이기에 원본 데이터인 DB의 값이 변경되었을 때 캐시의 데이터가 함께 즉시 갱신되지 않으면 발생한다.

문제 해결을 위한 캐시 전략

읽기(Read) 전략

Cache Aside (Lazy Loading)

캐시를 사용할 때 클라이언트가 데이터를 요청하면, 서버는 먼저 캐시에서 데이터를 조회한다.

이때 찾고자 하는 데이터가 캐시에 존재하면(Cache Hit) 캐시에서 데이터를 반환하고, 데이터가 존재하지 않으면(Cache Miss) 원본 데이터베이스(DB)에서 데이터를 조회하여 반환한 뒤 해당 데이터를 캐시에도 저장한다.

쓰기(Write) 전략

Write Through

원본 데이터에 대한 변경분이 생긴 경우, 매번 캐시에 해당 데이터를 찾아 함께 변경하는 방식.

2번 쓰기가 발생하지만, 캐시는 항상 최신 데이터를 가지게 된다.

그러나, 무작정 데이터를 갱신하거나 저장하는 방식은 리소스 낭비가 될 수 있다. 사용자가 잘 사용하지 않는 데이터마저 캐시에 저장되기 때문이다.

따라서 해당 방식을 사용할 경우, 캐시가 오랫동안 사용되지 않으면 자동으로 삭제되도록 TTL(Time To Live)과 같은 만료 시간을 함께 사용하는 것이 좋다.

Cache Invalidation

원본 데이터에 대한 변경분이 생긴 경우, 캐시 데이터를 만료시키는 방식

Write Through 방식의 단점을 보완한 방식이며 캐시에 데이터가 삭제되니 캐시 불일치에 대한 걱정은 하지 않아도 된다.

Cache Miss 증가 → DB 접근률 증가 → DB 부하로 이어질 가능성이 있고 캐시 재생성 시간 증가로 인해 사용자가 체감하는 서비스 이용시간이 느릴 것이다.

Write Back (Write Behind)

원본 데이터에 대한 변경분이 생긴 경우, 캐시를 먼저 업데이트한 이후 추후에 원본 데이터를 변경하는 방식

즉, 디스크 쓰기 작업을 비동기 작업으로 수행하여 성능을 개선하는 방식이다.

이 방식은 쓰기 작업이 빈번하며 일시적인 캐시 불일치를 허용하는 서비스에서 유용하게 사용될 가능성이 높다. (데이터를 DB에 저장하는 것보다 캐시 저장이 훨씬 빠르기 때문)

일관성 수준 선택

강력한 일관성(Strong Consistency) vs 결과적 일관성(Eventual Consistency)

결론

Q. 캐시를 도입하면 데이터가 DB와 달라지는 문제가 생기곤 하는데, 이런 불일치는 왜 발생하고 어떻게 해결하면 좋을까요?

A. 캐시는 DB의 데이터를 복사하여 저장하는 임시 저장소이기 때문에 원본 데이터인 DB의 값이 변경되었을 때 캐시의 데이터가 함께 즉각 갱신되지 않으면 캐시불일치가 발생합니다.

이러한 불일치 문제를 해결하기 위해서는 캐시와 DB 간 데이터 일관성을 유지할 수 있는 읽기 및 쓰기전략이 필요합니다.

예를 들어, 강력한 일관성이 필요한 경우에는 Write Through나 Cache Invalidation 전략을 사용하여 캐시와 DB의 데이터를 최대한 동일하게 유지하고

성능과 확장성이 더 중요한 서비스에서는 Cache Aside, Write Back(Write Behind)과 같은 결과적 일관성 기반 전략을 사용해야 합니다.

이러한 전략들을 서비스 특성에 맞게 잘 선택한다면

캐시 불일치 문제를 완화할 수 있으며, 상태 기반 렌더링과 대규모 트래픽 처리 등 사용자 경험에 최적화된 서비스를 효율적으로 구현해 나갈 수 있을 것입니다.

이상!

참고자료

브라우저가 자원을 가져오는 방법

브라우저 → 웹서버 요청 → 웹서버가 응답 → 브라우저가 랜더링

브라우저 → 웹서버 요청

한때는 누군가의 가장 애정하는 프로젝트였지만, 불과 n주만에 그에게서 완전히 잊혀진 프로젝트 유씽크 를 살펴보자.

브라우저에서 버튼을 클릭해 유튜브 영상과 관련된 상호작용을 시도한다.

웹서버 요청 → 웹서버가 응답

브라우저에서 버튼을 클릭했을 때 해당 웹서버에 요청헤더를 사용해 HTTP 요청이 전송되었다. 이때 요청 헤더에는 Content-Type, User-Agent 등 key-value 형태의 부가 정보가 담겨 전달되고,

웹서버는 요청을 처리한 뒤 응답을 돌려주는데, 여기서 받은 200 OK는 요청이 정상적으로 처리되었고 응답 본문에 요청한 리소스가 포함되어 있다는 의미다.

웹서버가 응답 → 브라우저가 랜더링

웹서버의 응답을 받은 브라우저는 응답 헤더를 확인하고, 문제가 없으면 받은 리소스를 화면에 랜더링한다.

앞서 잠시 언급했지만 위의 예시 사진에서도 200 ok 상태코드가 있는 응답헤더를 받았으므로 멋진 리소스가 랜더링 되었을 확률이 높다.

브라우저 보안정책

200번대 상태코드 응답을 받았음에도 브라우저에 멋진 리소스가 랜더링 되었을 것이라고 확신할 수 없는 이유는 브라우저 보안정책 때문이다.

브라우저는 웹서버의 응답을 확인할 때 보안 검사도 함께 수행하는데, 보안정책에 맞지 않는 응답을 받으면 웹서버에서 200~299의 성공 상태 코드가 있는 응답이 반환되더라도 브라우저는 해당 응답을 차단하여 랜더링하지 않는다.

SOP (Same-Origin Policy, 동일 출처 정책)

여러 브라우저 정책 중, 오늘은 SOP를 중점적으로 다뤄보자. 모든 브라우저는 기본적으로 같은 출처에서 온 리소스만 허용하고, 다른 출처의 리소스는 기본적으로 차단한다.

http://yousync.kr/page/1

여기서 Origin은 무엇일까? 그렇다. yousync.kr이다.

스킴(프로토콜) + 도메인 + 포트번호를 합친것이 Origin 인 것이다. SOP는 Origin의 구성요소 중 하나라도 다르면 다른 출처로 판단하여 리소스 접근을 차단한다.

https://yousync.kr  vs  http://yousync.kr   → 스킴 달라 ❌
https://yousync.kr vs  https://yousing.kr    → 도메인 달라 ❌
https://yousync.kr  vs  https://yousync.kr:2025 → 포트 달라 ❌

서버는 어떻게 다른 도메인의 요청을 허락해주나

CORS

브라우저가 다른 출처의 리소스 접근을 제한하는 정책(SOP, Same-Origin Policy)을 완화할 수 있도록, 서버가 특정 출처의 접근을 허가해주는 HTTP 헤더 기반 메커니즘

CORS 헤더 동작 방식

브라우저가 네트워크 요청을 처리하는 방식을 정의한 Fetch Standard 규약에 따르면, 브라우저는 서버 데이터 변형의 우려가 없는 요청은 Simple Request 로, 변형의 우려가 있는 요청은 Preflight Request 로 처리한다.

현대 API 통신은 대부분 application/json 을 사용하기 때문에 Simple Request 조건을 만족하는 경우는 거의 없고, 대부분 Preflight Request가 발생한다.

Simple Request (단순요청)

서버 데이터 변형의 우려가 없는 요청으로, 아래 조건을 모두 만족할 때 Preflight 없이 바로 요청을 보낸다.

메서드   : GET, POST, HEAD 중 하나
Content-Type : 아래 중 하나
               - text/plain
               - multipart/form-data
               - application/x-www-form-urlencoded

Preflight Request (사전요청)

Simple Request 조건을 벗어난 요청으로, 본 요청 전에 OPTIONS 메서드로 서버에 먼저 허락을 구한다.

메서드   : PUT, DELETE, PATCH 등
Content-Type : application/json 등
커스텀 헤더 : Authorization 등

브라우저가 Preflight 요청을 보내면 서버는 아래 세 가지 헤더를 담아 응답해야 한다.

Access-Control-Allow-Origin  : 허락할 출처
Access-Control-Allow-Methods : 허락할 메서드
Access-Control-Allow-Headers : 허락할 헤더

※ OPTIONS :브라우저가 Preflight 상황에서 자동으로 보낼 것으로, 수동으로 요청을 보내는 코드는 작성하지 않아도 괜찮다.

요약

Simple Request
- 브라우저 : 조건 일치 시 바로 요청
- 서버     : Access-Control-Allow-Origin 설정해야 함

Preflight Request
- 브라우저 : 조건 벗어나면 OPTIONS로 먼저 허락 구함
- 서버     : 세 가지 헤더 모두 설정해야 함
             Access-Control-Allow-Origin
             Access-Control-Allow-Methods
             Access-Control-Allow-Headers

시스터디 결론

Q.   CORS(Cross-Origin Resource Sharing)는 무엇이며 왜 필요한가요?

A.

CORS는 다른 Origin의 리소스를 브라우저에서 렌더링할 수 있도록 보안 정책을 완화해주는 HTTP 헤더 기반 메커니즘입니다.

사랑과 전쟁으로 CORS를 설명하자면, 브라우저는 남편, 다른 출처의 리소스는 여자친구, 보안 정책(SOP)은 시어머니, 서버는 시아버지입니다.

시어머니인 SOP로 인해 남편인 브라우저가 여자친구인 리소스를 만날 수 없을 때, 전세계 모든 브라우저가 네트워크 요청을 처리하는 방식에 대해 정의 되어 있는 Fetch Standard 규약에 따라 서버 데이터 변형 여부를 고려하여 단순요청 또는 사전요청을 보내면, 시아버지인 서버가 특정 출처의 접근을 허가하는 응답 헤더를 함께 보내 브라우저가 다른 Origin의 리소스를 로드할 수 있도록 해줍니다.

CORS가 없었다면 YouTube 영상 리소스를 받아와야 했던 유씽크는 시작조차 하지 못했을 것입니다.

우리 모두가 좋아했던 유씽크를 위해 CORS는 반드시 필요합니다.

반박시 님 유씽크 싫어함 이상.

++ 비유가 난해했다는 피드백을 받음.

>>>>> 뉴스 링크

뉴스 요약

최근 서드파티 AI 도구인 Context.ai의 Google Workspace OAuth 앱이 외부 공격자에 의해 침해되었는데, Vercel 직원이 해당 도구를 Google 계정과 연동해 두었다가, 공격자가 이 OAuth 앱을 통해 직원의 Google 계정 권한을 탈취했고, 그 결과 Vercel 내부 시스템까지 침입하게 되었다. 이로 인해 직원 명단과 암호화되지 않은 일반 환경 변수들이 모두 유출되었다.

이 뉴스가 웹도메인에 끼친 영향

이 뉴스는 웹 개발에 있어

복잡한 기능을 직접 구현하지 않아도 되고 DB 서버 구축·관리 부담도 줄여주는 서드파티도구는 편리하지만,

서드파티도구의 내부 코드나 보안 수준에 관해서 통제할 수 없기에 그에 따르는 위험도 고려해볼 필요가 있다는 것을 깊게 생각하게 해줌

※ 서드파티도구 : 하드웨어 생산자(1st)나 서비스 제공자(2nd)가 아닌,
외부의 제3자 개발자/기업이 만든 소프트웨어나 솔루션

생각

서드파티도구와의 연동 권한은 최소한으로 설정해 서드파티 보안 이슈를 예방할 수 있고 해당 도구가 해킹당했을 상황을 가정해 피해 범위를 사전에 제한하는 조치가 필요하다. (ex. API 키 등 민감 정보는 암호화해서 저장, OAuth 스코프 최소화, 토큰 만료 기간 및 자동 갱신 설정, 허용된 IP에서만 접근 가능하도록 제한 등)

🔗 문제 링크

dp - 탑다운

(1,1)에서 오른쪽 혹은 아래쪽으로 1번씩 이동할 수 있을 때, 입력값(m,n)까지 이동하는 경우의 수를 모두 구하자.

문제풀이

풀이흐름

최종 목적지에 도달하기 위해서는, 최종 목적지 이전 중간 목적지들까지 오는 경우의 수를 먼저 알아야 한다.

재귀함수를 이용하면 점화식에 의해 각 위치의 경우의 수가 하향식으로 결정되며, 계산된 결과는 메모이제이션으로 저장한다.

메모제이션에 저장된 결과를 조합하면 최종 목적지까지 오는 전체 경우의 수를 구할 수 있다.

예시

최종 목적지: (2,2)

시작점 : (1, 1)

중간 목적지 : (1,2 / 2,1)

1,2 까지 경우의 수 : 1

2,1 까지 경우의 수 : 1

최종목적지까지 경우의수: 1 + 1 = 2

ex) 최종 목적지: (2,2) 시작점 : (1, 1) 중간 목적지 : (1,2 / 2,1) 1,2 까지 경우의 수 : 1 2,1 까지 경우의 수 : 1

최종목적지까지 경우의수: 1 + 1 = 2

점화식 : dp[i][j] = dp[i-1][j] + dp[i][j-1]

정답 코드

def solution(m, n, puddles):
    answer = 0  # (1,1)에서 (m,n)까지 이동하는 경우의 수

    # 시작점 (1,1)에서 한 번 이동한 두 칸의 경우의 수를 미리 초기값으로 설정.(점화식 적용을 위해)
    info = dict([((2, 1), 1), ((1, 2), 1)]) # 1,1로 시작하면  dp 점화식이 참조하는 값이 생기지 않아, 문제풀이를 할 수 없음.

    # # 웅덩이 좌표를 튜플로 변환하여 info 딕셔너리에 0으로 저장 (해당 위치로 갈 수 없음)
    for puddle in puddles: 
        info[tuple(puddle)] = 0 

    def func(m, n): # 탑다운(재귀+ 메모제이션) 방식으로 경우의 수 계산

        # 격자 밖이면 0 반환
        if m < 1 or n < 1:
            return 0

        # 이미 계산된 좌표면 바로 반환 (메모이제이션)
        if (m, n) in info:
            return info[(m, n)]

        # 현재 좌표 = 위에서 등교하는 경우 + 왼쪽에서 등교하는 경우
        return info.setdefault(
            (m, n),
            func(m - 1, n) + func(m, n - 1)
        )

    # 최종 결과는 MOD 적용
    return func(m, n) % 1000000007

다른 풀이

dp - 바텀업

def solution(m, n, puddles):
    answer = 0
    route_map = [[0]*m for i in range(n)]
    memo = [[0]*m for i in range(n)]
    for p in puddles:
        route_map[p[1]-1][p[0]-1] = 1
    memo[0][0] = 1
    for i in range(n):
        for j in range(m):
            if i == 0 and j == 0:
                continue
            if route_map[i][j] == 1:
                memo[i][j] = 0
            elif i == 0:
                memo[i][j] = memo[i][j-1]
            elif j == 0:
                memo[i][j] = memo[i-1][j]
            else:
                memo[i][j] = memo[i-1][j] + memo[i][j-1]
    print(memo)
    answer = memo[n-1][m-1]
    return answer % 1000000007```

생각해 본 것

다소 뻔한 말이지만,

DP 문제는 탑다운과 바텀업 두 방식 모두로 풀이가 가능하며, 상황에 따라 어떤 방식이 더 적합한지 고민해볼 필요가 있다.

찾아보니 일반적으로는 아래 기준으로 선택하면 좋다고 한다.

요즘 나는 2026년을 누구보다 세게 강타하기 위해, 매일 IT 기술 관련 아티클을 읽고 스터디가 끝난 후에는 스터디 친구들과 AI 기술 및 발전에 대해 토의하는 시간을 갖고 있다.

아티클을 나누는 씨스터디의 디스코드 방

여러 주제의 결론은 결국 하나, 급변하는 세상에 대처하기 위해서도, 좋은 프로젝트를 하기 위해서도, 언제나 흔들리지 않을 탄탄한 기본기를 갖춰야 한다는 것.

친구들의 말을 깊이 새기며 기술을 익히되 흔들리지 않는 기본기를 쌓아가려 노력했고, 🐺 이를 기반으로 가장 개선하고 싶었던 부분들에서 약 6% 와 33% 그리고 그 이상의 개선을 이루어내고 있다.

앞으로는 기본기에 충실하며 다른 수치들도 더 개선해 나가고 싶다.

어느 웹사이트의 게시판에 '스터디장, 미리 합격을 축하드려요'라는 제목의 게시글을 작성하고, 동일한 내용의 ㅈㄱㄴ 게시글을 작성한뒤, 게시판으로 돌아가 해당 게시글을 조회한다고 가정해 보자.

쓰기 흐름

웹 브라우저(클라이언트)에서 글을 쓰고 저장 버튼을 클릭하면 POST 요청이 웹 서버로 전달되고, 웹 서버가 해당 데이터를 DB에 저장한다.

읽기 흐름

제목을 클릭하면 서버로 GET 요청이 발송되고, 서버가 요청을 처리한다. 데이터베이스에서 해당 게시글의 ID를 기준으로 조회하여 게시물의 제목과 내용을 반환한다.

성능 개선 방법

쓰기

프론트엔드에서 저장 버튼이 한 번 눌리고 요청이 한번 간 뒤에도 버튼 클릭을 막지 않으면 사용자가 저장 버튼을 여러번 클릭해 post 요청을 여러번 보낼 수 있다.

이는 서버 부하 혹은 게시물 중복 저장을 야기한다.

1. 프론트엔드 단에서 버튼이 한번 클릭 되면 클릭 되지 않도록 막거나,
2. 백엔드 단에서 한 유저가 게시글을 업로드 할 때 일정한 시간을 두고 같은 제목과 같은 내용의 게시물을 올릴 수 있도록 설정해두어야 문제를 방지할 수 있을 것이다.

읽기

모든 문자열이 일치하는 게시물을 읽는 것은 시간적으로 비효율적이므로 게시물에 고유 ID를 부여하고, 데이터베이스의 인덱스(Index)를 이용하면 인덱스를 기준으로 게시물을 조회할 수 있다.

게시판을 만들 때는 댓글, 좋아요, 대댓글 등의 데이터를 저장하기 위해 주로 관계형 데이터베이스(RDBMS)를 사용하는데, MySQL, PostgreSQL 등 대표적인 관계형 데이터베이스의 인덱스는 내부적으로 B+Tree 자료구조로 구현되어 있어 정렬된 상태를 유지하면서 빠른 탐색이 가능하다.

시?씨?스터디 결론

Q. 다음 주 면접 질문은

성능을 쓰기와 읽기 관점으로 구분해서 설명해주세요.

입니다.

여러분의 지망 도메인에 맞게 준비하시면 됩니다.

A .웹 도메인에서 쓰기와 읽기 관점의 성능은 클라이언트에서 전달된 데이터를 효율적으로 적재하고 빠른 시간내에 탐색할 수 있는가 입니다.

성능이란, 기능성의 정도이며, 즉, 구현한 기능이 얼마나 잘 작동하는가를 의미합니다.

웹도메인의 핵심역할은 언제나 유저의 사용을 위하여 있으므로 웹도메인에서 쓰기와 읽기관점의 성능을 측정하기 위해서는 유저의 편의를 위한 쓰기와 읽기가 잘 되고 있는 지를 측정해야합니다.

따라서 쓰기와 읽기 성능을 높인다는 것은 곧 사용자가 데이터를 저장하고 조회하는 과정에서 불편함을 느끼지 않도록 하는 것이며,

이것이 웹 도메인에서 성능 최적화의 궁극적인 목표라고 할 수 있을것입니다.

Applibot [애플리봇]

일본의 CyberAgent에 소속된 게임 제작사.

서비스 게임

출처 : 나무위키

선택한 서비스

먼작귀 포켓

서비스 소개

방치형 게임

시간의 흐름에 따라 게임머니가 증가하고 게임을 실행시키지 않은 백그라운드에서도 게임머니가 증가한다.

이 게임머니로 캐릭터, 장비, 스킬 등을 강화해 레벨별 스테이지를 클리어 하는 게임인데,,,

귀여운 먼작귀들이 등장함에도 너무도 큰 단점이 있어 2일만에 게임을 접었다.

개선하거나 추가하고 싶은 기능

레벨업시 +1씩 만 증가하는기능

레벨업이 1씩만 가능하기 때문에 레벨업을 하는데 들어가는 시간이 크고, 유저 피로도가 높아진다.

기술적 개선방법

딕셔너리에 일괄적으로 상승시킬 능력치를 담아 일괄 레벨업 가능한 기능

출처 : 구글

위와 같이 일괄 레벨업이 가능하도록 하는 기능이 필요하다고 생각한다. 굳이 딕셔너리를 사용하려는 이유는 상태 : 레벨 형태의 정보를 서버로 전송하는 구조를 고려하고 있기 때문이다. like 메이플 스탯분배. ok?

또, 딕셔너리는 키 기반 구조이기에 이름(키) 기준으로 명확하게 관리할 수 있으며, 새로운 상태가 추가되거나 수정될 때 순서에 영향을 받지 않아 확장성과 유지보수 측면에서 유리하다고 판단된다.

# list (index 기반)
list_stats = [10, 8, 12]

# dict (key 기반)
dict_stats = {
    "strength": 10,
    "dexterity": 8,
    "intelligence": 12
}

# index 기반 접근
list_stats[0] += 2

# key 기반 접근
dict_stats["strength"] += 2

++ 아 생각해보니 메이플 스탯도 일괄 레벨업이 아니구나...! ㅎㅎ 그치만 수정하기 귀찮네요... 일단 제가 하고 싶은 말은 잘 전달 되었으리라 믿어요.

서울 시내 이곳저곳을 탐험하다가 혼자서 쉬기 좋아보이는 장소를 하나 찾았습니다.
인터넷도 되고 전화도 터지며,
제가 아는 사람 중 이곳에 출입하는 사람은 저를 포함해 단 두 명뿐인 곳입니다. 아리따운 여성들의 공간ㅎㅎ

여러분이 서울에서 조용히 머물 일이 있으시다면 위치를 공유해 드리도록 하겠습니다.

이상.

스패니쉬 스쿼트

사실 이 운동은 아직 시작하지 않았습니다. 몇 분 전에 추천받았기 때문입니다.

언젠가는 이 운동을 물리치료와 병행하며, 5/16이 된 4/25 회동 전까지 100만 번 하고 더 강해져서 참석하겠습니다.

다들 정말 보고 싶어요~ 씨유 인 메이~~

🔗 문제 링크

완전탐색

양이 잠에 들때 마지막으로 구한 숫자를 출력하라

예시) N=1692
      1N=1692  -> {1,6,9,2}
      2N=3384  -> {1,6,9,2,3,8,4}
      3N=5076  -> {1,6,9,2,3,8,4,5,0,7} -> 0~9 모두 수집 -> 5076 출력

문제풀이

set을 사용해 중복값을 제거한뒤, 자릿수에서 1~9까지의 숫자가 나올때까지 완탐을 돈다

# 마지막 숫자를 구하는 함수
def find_last_number(n): #n을 인자로 받는데

    # 마지막 숫자를 구할 수 없는 경우를 우선 생각하자.
    if n == 0: # 만약 n이 0이면 무엇을 곱해도 0이 나오므로
        return "INSOMNIA" # "INSOMNIA (= 불면증)"를 반환하는 것으로 시작.

    # 이후에는
    number_0_9 = set() # 0~9까지의 숫자를 저장할 set을 만들고
    multiplier = 1 # 곱할 수를 1로 초기화한 후 (Nx1 부터 시작해야하니까)

    # 0~9까지의 숫자가 모두 나올 때까지 반복하는 while 루프를 시작한다.
    while len(number_0_9) <=9: # number_0_9의 길이가 9 이하일때
        current = n * multiplier # n * multiplier를 current에 저장하며
        multiplier += 1 # multiplier를 1씩 증가시키고
        collect_digits(current, number_0_9) # 어떠한 함수를 써서 current값을 반환받는다. 
    return current # 이게 뭔지는 아래에 가서 자세히보자 

# current의 각 자릿수를 number_0_9에 추가해서 0~9까지의 숫자를 수집하는 함수
def collect_digits(current, number_0_9):
    for digit in str(current):  # current를 문자열로 변환해 한 글자씩 순회
        number_0_9.add(digit)   # 각 자릿수를 set에 추가 (이미 있으면 자동 무시)

# 입력 처리
def solve():
    t = int(input()) # 첫 번째 줄에서 테스트 케이스의 수 t를 입력받는다.

    for case_idx in range(1, t + 1): # 테스트 케이스에 맞는 출력을 위해 각 테스트 케이스에 대해 1부터 t까지 반복하면서 case_idx를 1씩 증가시킨다.
        n = int(input()) # 각 테스트 케이스마다 n을 입력받는다.
        result = find_last_number(n) # find_last_number 함수를 호출하여 n에 대한 결과를 result에 저장한다.
        print(f"Case #{case_idx}: {result}") # 결과 출력


solve() # solve 함수를 호출하여 프로그램을 실행

다른 풀이

for문으로 범위를 고정하되, break로 조기 종료해 불필요한 탐색을 방지함 ㅁ

import sys ; read = sys.stdin.readline
for n in range(int(read())):
    x = int(read())
    if x == 0 : print(f"Case #{n+1}: INSOMNIA") ; continue
    r = [False]*10
    for i in range(1,4096):
        for j in range(10):
            if str(j) in str(i*x) : r[j] = True
        if all(r) : print(f"Case #{n+1}: {i*x}") ; break

생각해 본 것

탐색 범위가 주어지지 않은 코드를 작성할 때는 정확한 연산보다 실행시간과 메모리 관리를 우선적으로 고려할 필요가 있지 않을까?

break 없이 for문으로 과도하게 넓은 범위를 전부 탐색한다면, 매 반복마다 str(i * x) 문자열이 생성되어 메모리 낭비가 심해진다. 이런 상황에서는 break나 while로 조건 만족 즉시 종료하는 것이 훨씬 효율적일 수 있을 것이다.

이진 탐색 트리는 이진탐색의 개념을 트리 형태의 구조에 접목한 자료구조로, 선형시간이 소요되는 연결 리스트 자료구조의 수행시간을 향상하기 위한 자료구조이다.

※ 이진탐색 : 정렬된 데이터의 중간에 위치한 항목을 기준으로 데이터를 두 부분으로 나누어가며 특정항목을 찾는다.

구조

단순 연결 리스트에서는 각 노드가 다음 노드만을 가리키므로 이진 탐색을 적용하기 어렵다.

반면, 이진 탐색 트리는 각 노드가 왼쪽 자식 노드와 오른쪽 자식 노드를 가지며, 데이터의 크기에 따라 노드가 배치된다.

이러한 구조를 통해 탐색 시 매 단계마다 탐색 범위를 절반으로 줄일 수 있어 효율적인 탐색이 가능하다.

이진탐색 트리 조건

각 노드 n에 저장된 키가 n의 왼쪽 서브 트리에 있는 노드에 저장된 키보다 크고, n의 오른쪽 서브트리에 있는 노드의 키보다 작아야 한다.

즉,

왼쪽 서브트리 < 현재 노드 < 오른쪽 서브트리

보완방법

이진 트리 형태의 자료구조는 대용량의 데이터 처리에 효율적이지 못하다.

이진트리가 가질 수 있는 최대 자식수는 2인데, 대용량 데이터를 처리하려면 트리의 높이가 높아지고 탐색시간이 길어지기 때문이다.

노드에 수백에서 수천개의 키를 저장하여 트리의 높이를 낮추고, 다방향 검색을 하면 이와같은 문제점을 해결할 수 있다.

B-Tree

한 노드에 여러 키와 데이터를 저장하는 균형 트리

1) 모든 노드는 동일한 깊이를 갖는다. 2) 루트가 아닌 각 노드의 자식 수는 ⌈M/2⌉ 이상 M 이하이다. 3) 루트의 자식 수는 2 이상이다.

B+Tree

모든 실제 데이터는 리프 노드에 저장되고, 내부 노드는 탐색을 위한 키만 가지는 균형 트리

1) 모든 리프 노드는 동일한 깊이를 갖는다. 2) 내부 노드는 키와 자식 포인터만을 가지며, 탐색을 위한 인덱스 역할을 수행한다. 3) 모든 데이터는 리프 노드에만 저장된다. 4) 리프 노드들은 연결 리스트 형태로 서로 연결되어 있어 순차 탐색이 용이하다. 5) 각 노드의 자식 수는 B-Tree와 동일하게 최소 ⌈M/2⌉ 이상, 최대 M 이하를 만족한다.

B-Tree vs B+Tree

내부 노드에서 데이터를 제거해 구조를 가볍게 만들면 더 많은 키를 담을 수 있어 리프노드에 담을 수 있는 자식수가 증가하고, 그 결과 트리의 높이가 낮아져 디스크 접근 횟수(I/O)가 줄어든다.

따라서 디스크 기반 대용량 데이터 환경에서는 B+Tree가 더 적합하다.

시스터디 결론

질문

수천만 건의 회원 정보가 메모리에 다 올라가지 않고 디스크에 저장돼 있습니다. 회원번호 하나 찾기도 자주 하고, 100000번~200000번 회원을 순서대로 읽기 같은 작업도 자주 합니다. 어떤 자료구조가 좋을까요?

답변

리프 노드에 데이터가 집중되고, 리프 노드 간 연결을 통해 순차 접근이 가능하므로 단건 조회와 범위 조회가 모두 중요한 디스크 기반 대용량 데이터 환경에서는 B+Tree가 가장 적합합니다.

🔗 문제 링크

완전탐색

k개의 숫자로 이루어진 집합 S가 주어졌을 때, 집합 S에서 숫자 6개를 선택하는 모든 조합을 구할 것.

문제풀이

combinations 내장함수+완전탐색을 사용해 수월하게 조합을 구하였다.

from itertools import combinations 

while True: 
    data = list(map(int, input().split())) # data라는 리스트 요소값을 공백을 기준으로 구분, 정수로 입력받아 넣음. 

    if data[0] == 0:  # 첫 번째 값(k)이 0이면
        break # while루프 종료

    k = data[0] # 리스트 data의 첫번째 값을 k라 칭하고
    nums = data[1:] #나머지 data 요소는 nums라 칭한 뒤 

    for comb in combinations(nums, 6):  # nums에서 6개를 뽑는 모든 조합 순서대로(오름차순) 탐색
        print(*comb)  # 조합을 공백으로 구분해서 한 줄 출력
    print()  # 각 테스트케이스 사이 빈 줄 출력

다른 풀이

combinations 대신 permutations 내장함수를 사용한 코드이다.

from itertools import permutations 

while True: 
    data = list(map(int, input().split())) # data라는 리스트 요소값을 공백을 기준으로 구분, 정수로 입력받아 넣음. 

    if data[0] == 0:  # 첫 번째 값(k)이 0이면
        break # while루프 종료

    k = data[0] # 리스트 data의 첫번째 값을 k라 칭하고
    nums = data[1:] 나머지 data 요소는 nums라 칭한 뒤 

    for per in permutations(nums, 6):  # nums에서 6개를 뽑는 모든 조합 순서대로(오름차순) 탐색
        print(*per)  # 조합을 공백으로 구분해서 한 줄 출력
    print()  # 각 테스트케이스 사이 빈 줄 출력

생각해 본 것

combinations 대신 permutations를 쓰면 왜 출력 초과가 뜰까?

두 함수는 모두 itertools에서 가져올 수 있지만, combinations는 순열을 고려하지 않고, permutations는 순열을 모두 고려하여 결과를 반환한다.

permutations는 문제에서 요구하는 것 보다 지나치게 많은 결과를 출력해 출력 초과가 발생한 것이다.

순열을 고려하지 않아도 되는 문제라면 combinations를 사용하자.

데이터의 통신, 처리, 추출, 응용을 연구하는 정보이론에서 확률변수의 불확실성(uncertainty)을 정량화하는 척도.

즉, 정보 엔트로피는 데이터가 얼마나 다양하고 복잡하며 예측하기 어려운지를 의미한다.

정보 엔트로피가 높다는 것

픽셀값이 다양하고 복잡한 이미지이다!

예시
1) 노이즈 이미지
2) 랜덤한 픽셀 값
= 색이 들쭉날쭉하고 규칙이 없음

정보 엔트로피가 낮다는 것

픽셀값이 단순하고 반복적인 이미지이다!

예시
1) 단색 이미지 (완전 흰색, 검은색)
2) 반복 문자열 AAAAAA
= 단순한 구조

엔트로피 높다! → 엔트로피 낮다!

데이터 압축과 정보엔트로피

데이터 압축은 원래 표현보다 더 적은 비트를 사용하여 정보를 부호화하는 과정이다. 이때 압축의 목표는 데이터 내의 중복성(Redundancy)을 제거하여, 데이터 크기를 이론적 최소 정보량인 정보 엔트로피(Information Entropy)에 최대한 수렴시키는 것.

즉, 불필요한 데이터를 압축해 저장 공간의 효율적 활용, 전송 속도 향상 및 비용 절감, 그리고 데이터 관리 및 배포의 편의성을 극대화하는 것이다.

이때 모든 압축 방식은 데이터 복원 여부에 따라 무손실(Lossless) 또는 손실(Lossy) 압축으로 나뉜다.

무손실 압축

무손실 압축은 데이터 내 반복 패턴, 출현 빈도, 문구 중복과 같은 통계적 중복성을 제거하거나 짧은 기호 및 위치 정보(인덱스)로 치환하여, 데이터 크기를 이론적 최소 정보량인 엔트로피에 수렴시키는 과정

즉, 데이터의 내용을 단 1비트도 손실하지 않고 크기만 줄이는 방식이며(그러나 엔트로피 이하로는 압축이 불가능하다) 압축을 복원하면 원래의 원본 데이터와 100% 일치한다.

예시
1. PNG
2. ZIP
3. GIF

무손실 압축에서의 치환

원본 값을 유지하면서 데이터를 더 짧은 코드로 표현하는 방식이다.

예시
A → 1
B → 01
C → 001

• 하프만 코딩 같은 방식을 사용하여 자주 등장하는 데이터일수록 더 짧게 표현해 복원 시 원본과 완전히 동일

무손실 압축에서의 반복 제거 (패턴 압축)

반복되는 데이터를 값과 횟수로 표현하여 압축한다.

예시
AAAAAA → A6
00000000 → (0, 8)

• 원본 데이터는 그대로 유지되며 표현만 변경됨

무손실 압축에서의 참조 방식 (사전 기반)

이미 등장한 데이터를 다시 저장하지 않고 위치를 참조한다. 당연히 원본 데이터는 그대로 유지 되며 이후 반복 문자열을 재사용하여 압축한다 (=zip)

예시
ABABABAB
→ [AB][AB][AB][AB]
→ [1][1][1][1]

손실압축

인위적으로 일부 정보를 제거하여 데이터의 복잡도(엔트로피)를 낮추는 과정.

데이터의 일부를 영구적으로 삭제하여 파일 크기를 획기적으로 줄인다. 압축을 풀었을 때 원본과 유사해 보이지만, 실제 데이터는 이미 변형된 상태이다.

예시
1. JPEG 
2. MP3 
3. MP4 

손실 압축에서의 제거

사람이 인지하기 어려운 정보(덜 중요한 데이터)를 제거한다.

예시
1) 이미지 색상 단순화
   256색 → 64색으로 감소

2) JPEG에서 고주파(디테일) 제거
   → 머리카락, 잔디 등의 세밀한 부분 일부 삭제

손실 압축에서의 치환

원본 데이터를 유사한 값(근사값)으로 변환한다.

예시
1) 픽셀 값 평균화
   [101, 102, 103] → [102, 102, 102]

2) 색상 근사화
   RGB(123, 201, 98)
   → RGB(120, 200, 100)

3) 오디오 압축 (MP3)
   → 사람이 잘 듣지 못하는 주파수 제거 후 재구성

씨스터디 결론

Q. 1000x1000 해상도의 JPEG 파일이 두 장 있습니다. 하나는 '파란 하늘'이고, 다른 하나는 '나뭇잎' 사진입니다. 이 두 파일의 용량을 논리적으로 추론하고, 같은 해상도임에도 용량 차이가 발생하는 이유를 설명하세요.

A. Jpeg 파일은 압축될 때 원본값이 제거되거나 삭제되는 손실압축방식을 채택합니다.

손실압축 방식은 중요하지 않은 데이터는 삭제하거나 근사값으로 치환하여 데이터의 복잡도를 낮추는데,

파란 하늘 사진은 픽셀값의 변화가 적고 중복값이 많은 데이터이지만 나뭇잎 사진은 픽셀값의 변화가 크고 중복값이 적은 데이터이기에

파란하늘의 압축 효율이 높아 나뭇잎 이미지보다 파일 용량이 더 작아질 가능성이 큽니다!!

찡긋 😉

,,,,!

유저모드에서 직접 수행할 수 없는 보호된 자원에 접근하기 위해 운영체제의 커널 루틴을 호출하여 서비스를 이용하는 것.

프로그램이 커널의 기능을 요청하기 위해 운영체제를 호출하는 방식.

시스템 콜은 정글 보안팀과 같은 역할을 한다. 왜인지 왜곡된 그곳의 이미지는 잊자

프로그램은 유저모드에서 실행되므로 파일, 메모리, 프로세스, 네트워크와 같은 보호된 자원과 하드웨어에 직접 접근할 수 없다.

따라서 파일 처리, 프로세스 생성, 메모리 관리등으로 보호된 자원에 접근이 필수적인 작업이 필요할 경우 커널모드로 전환하여 운영체제의 기능을 요청해야 한다.

이때 운영체제의 커널 루틴을 호출하여 서비스를 제공받는 방식을 시스템 콜이라고 한다.

기능

1. 유저 모드에 있는 응용 프로그램이 커널의 기능을 사용할 수 있도록 한다.
2. 시스템 호출을 하면 유저 모드에서 커널 모드로 바뀐다.
3. 커널에서 시스템 호출을 처리하면 커널 모드에서 유저 모드로 돌아가 작업을 계속한다.

시스템 호출의 유형

1.프로세스 제어(process control) 2. 파일 조작(file manipulation) 3. 장치 관리(device management) 4. 정보 유지(information maintenance) 5. 통신(communication)

시스템콜의 발생

유저 모드에서 실행 중인 어플리케이션에서 커널에게 어떤 서비스를 요청할 때 발생함.

더 알아보기

유저모드 vs 커널모드

운영체제는 시스템의 안정성과 보안을 위해 CPU(중앙처리장치) 실행 권한을 두 가지 모드로 나누어 관리한다.

유저모드

일반 응용 프로그램이 실행되는 모드로 제한된 권한만을 가진다.

커널모드

운영체제가 실행되는 모드. 모든 하드웨어 자원에 접근 가능

특징

눈을 감아 멈춰있던 나를 깨워

즐거운 Java 스터디가 종강을 맞이했다. 정글 졸업 이후 한동안 공부를 손에서 놓고 있었는데, 그간 멋진 Java 스터디 덕분에 오랜만에 공부에 집중하며 새로운 지식을 쌓을 수 있어 좋았다.

낯선 세계를 들여다보다

Java, 객체지향…… 내게는 너무나 멀게만 느껴지던 세계였는데, 스터디를 통해 비로소 들여다볼 용기가 생긴 것 같다. 여럿이 함께 공부한 덕분에 큰 원동력이 생기고, 서로를 보며 좋은 자극을 주고받을 수 있었기에 가능한 일이었다.

고마운 스터디 멤버들에게

늘 내게 좋은 영향을 주는 고마운 정글 여친, 스터디의 진행을 도맡아 가장 고생 많았던 스터디장 🩷🤍🩷 jaykxo 🩷🤍🩷 언니,

스터디 대리 진행을 시도하던 중 음향 장비 이슈가 터져 난감했는데, 능숙하게 대신 진행해 주신 혜림님, 좋은 문제를 꼼꼼히 준비해 주신 윤지님, 백엔드 현직자의 경험으로 알짜배기 지식을 전파해 주신 강현님, 부트캠프를 떠나기 전에도, 떠난 후에도 든든한 버팀목이 되어 준 지희님,

저마다의 색깔로 함께했던 모든 순간을 빛내준 이 스터디를, 영원토록 뜨겁게 지지 않을 이 계절을 오래도록 기억할 것 같다.