쿠키 (웹 브라우저에 저장되는 정보)

• HTTP의 특성으로 인해 요청과 응답을 주고 받으면 연결이 끊어짐 (재 요청시 서버는 이전 요청 기억 못 함)

• 클라이언트 인증을 유지하기 위해 쿠키나 세션 사용 - 서버가 클라이언트를 기억하도록 (예) 매번 로그인 필요 없음

• 쿠키는 클라이언트 쪽에서 관리되는 작은 기록 정보 파일 (서버가 사용자의 웹 브라우저에 전송 – 보안 위험 有)

└ 브라우저는 그 데이터 조각들을 저장해 놓았다가, 동일한 서버에 재 요청 시 저장된 데이터를 함께 전송

└ 예) 쇼핑몰 장바구니 기능, 자동 로그인, 팝업 창 ‘오늘 더이상 보지 않음' 체크

 

세션 (서버 쪽 저장. 서버가 나를 알아보는 방법. 개발 쪽 세션)

• 세션은 쿠키를 기반으로 하지만 사용자 정보 파일을 서버에서 관리 (세션 ID 부여) - 예) 로그인

• 웹 브라우저가 종료될 때까지 인증 상태 유지

• 쿠키보다 보안 측면에서 우수하지만 사용자가 많아질수록 서버 메모리를 많이 차지하여 성능 저하의 위험

 

 

캐시는 서버와 통신 없이 브라우저 내에서 빠르게 동작되도록 기억하는 역할.

 

ga4 데모 계정

https://analytics.google.com/analytics/web/?utm_source=demoaccount&utm_medium=demoaccount&utm_campaign=demoaccount#/p213025502/reports/intelligenthome

✅ 1. 마케터가 데이터를 분석하는 이유

  • 감이 아닌 객관적인 수치로 의사결정하기 위해
  • 가설 → 데이터로 검증 → 실험 → 인사이트 도출 → 액션 실행

✅ 2. 데이터 분석 기본 개념

  • 정의: 고객/시장 데이터를 수집·분석해 의미 있는 통찰을 얻고, 의사결정에 활용
  • 장점: 리스크 최소화, 고객 이해 심화, 성과 기여 증명 가능

✅ 3. 데이터 분석 5단계 프로세스

  1. BQ 설계: 명확한 비즈니스 질문부터 시작
  2. 데이터 수집/정제: GA4, Amplitude 등 툴 활용
  3. 분석: 세그먼트, 퍼널, 코호트 분석 등
  4. 인사이트 도출: 패턴·이유 파악 + 가설 수립
  5. 실험 실행: A/B 테스트, 개선안 실행

✅ 4. 좋은 BQ(Business Question)의 조건

  • 비즈니스 중심
  • 구체적이고 측정 가능
  • 실행 가능한 액션 도출 가능

❌ “SNS 광고 효과 있나?”
✅ “지난달 인스타 광고 유입자의 전환율은 비노출 그룹보다 높은가?”


✅ 5. 데이터 유형별 분류

유형정의예시목적
퍼스트 파티 자사에서 직접 수집 회원정보, 구매 이력 충성고객 관리, 개인화 추천
세컨드 파티 제휴사로부터 공유 카드사 고객 데이터 타겟 확장, 제휴 캠페인
서드 파티 외부 판매 데이터 관심사, 리타겟팅 광범위 타겟팅, 신규시장 개척
 

✅ 6. 쿠키와 식별자 이해

  • 퍼스트파티 쿠키: 로그인, 장바구니 유지
  • 서드파티 쿠키: 광고 추적용 (쿠키리스 시대 종료 중)
  • 식별자: ID, 디바이스, CRM ID 등 → 장기 추적용

✅ 7. 지표 분석 핵심: 비율과 효율성

  • CTR = 클릭률 (%), CVR = 전환률, ROAS = 광고수익률, CPA/CAC 등
  • 단순 수치보다 투입 대비 성과를 보는 것이 중요

✅ 8. 벤치마크 설정

  • 과거 대비, 목표 대비, 업계 평균 비교
  • 벤치마크 없으면 숫자의 ‘좋고 나쁨’을 판단할 수 없음

✅ 9. 데이터 시각화의 기본

차트목적
꺾은선 그래프 시간 흐름 분석
막대 그래프 카테고리 간 비교
파이 차트 구성 비중 시각화
콤보 차트 비교 + 추세 동시 표현
 

✅ 10. 인사이트란?

사실 + 맥락 + 다음 행동
→ 예: “30대 남성은 장바구니 후 3일 내 결제”
→ 인사이트: 리마인드 푸시 타이밍 최적화 필요


✅ 11. 실무 활용 예시

  • GTM 활용: 광고 태그 빠르게 설치
  • 퍼스트 데이터 강화: 쿠키리스 시대 대응
  • 세그먼트 분석: 충성고객 vs 이탈고객 구분
  • 그루핑: 광고 채널/고객군/카테고리별 묶음
  • 리포트 설득력 향상: 벤치마크, 비율지표 활용

✅ 기억할 실전 포인트 요약

  • 감 → BQ → 데이터 분석 → 인사이트 → 실행
  • 퍼널별로 데이터 다르게 활용 (서드→세컨드→퍼스트)
  • CTR이 높다고 좋아 말고, CVR·ROAS로 효율을 봐라
  • 숫자는 쪼개고, 비교하고, 그래프로 보여줘야 설득력 있다

 

 

🍪 쿠키 (유저 식별)

HTTP는 클라의 상태를 서버가 기억하지 않는 Stateless이기 때문에, 일례로 로그인 여부나 유저정보를 서버에게 매 요청마다 전달해 주지 않는 이상, 서버가 클라의 상태를 알 수 없다. 

이를 해결하기 위해 로그인 성공 시 서버가 응답메세지 헤더에 Set-Cookie 필드를 포함하여 클라이언트에 유저의 정보를 담은 쿠키를 전달한다. 해당쿠키는 브라우저의 쿠키저장소에 저장되고, 이후 요청마다 자동으로 요청메세지 헤더의 Cookie필드에 포함돼 서버로 전송된다. 그러면 서버는 해당 요청이 로그인을 완료한 유저의 요청인지와 같은 해당 유저의 정보를 알 수 있다.

 

정리:

Set-Cookie: 서버 > 클라이언트 쿠키 전달. 필드=값을 나열하여 만료시점과 같은 세부 설정들 추가가능.

Cookie: 클라이언트 > 서버 쿠키전달. 즉, 쿠키는 본질적으로 클라에 저장되는 것이다.

 

근데 민감한 유저 정보를 담아 주고 받는건 보안상 위험하기 때문에 주로 로그인 성공시 서버에서 해당 유저 정보와 연결된 세션 키(sessionId)를 생성해 저장하고, 유저 정보 대신 키를 Set-Cookie에 담아 전달하면 추후 클라이언트에서 해당 키를 다시 받았을 때 어떤 유저인지 식별 가능하도록 한다. (서버는 이 세션 키와 실제 유저 정보를 매핑해서 클라이언트를 식별) 

ex)

Set-Cookie: sessionId=abc123; Expires=Wed, 09 Jun 2025 10:18:14 GMT;

Cookie: sessionId=abc123

 

이렇게 세션과 쿠키는 세트 개념이라고 볼 수 있다.

서버측에 각 사용자에 대한 정보를 사물함처럼 각 칸에 session.setAttribute로 저장해뒀다가

쿠키의 세션ID가 사물함 열쇠가 되어 해당 칸을 열어 session.getAttribute해서 사용하면 되는 것이다.

 

 

서버에서 JAVA코드로 session을 다루는 대강의 예시를 살펴보자.

@Controller
public class Controller {
    
    @PostMapping("/login")
    public String login(HttpServletRequest request, 
                       @RequestParam String userId, 
                       @RequestParam String password) {
        
            HttpSession session = request.getSession(); 
            session.setAttribute("userId", user.getId()); 
            session.setAttribute("userName", user.getName());
        
        return ~~;
    }
    
    @GetMapping("/check")
    public String checkAuth(HttpServletRequest request) {
        
        HttpSession session = request.getSession();
        String userId = (String) session.getAttribute("userId");
        String userName = (String) session.getAttribute("userName");
        
        return ~~;
    }

 

 

 

 

세션은 세션 스토리지와 다른 개념. ’세션이 만료되었습니다. 다시 로그인 해주세요.’ 에서의 세션임.)

허나 쿠키 저장소를 항상 들러서 매번 헤더에 전송하는 건 아직 비효율적인 측면이 있다. 따라서 최소화 하는 것이 좋고, 대신 브라우저 상에 데이터를 저장하되 서버에 전송하지 않는 웹 스토리지를 이용하기도 한다. (용량도 업)

🧺 웹스토리지 localStorage: 명시적으로 지우지 않는 한 영구적. 브라우저를 껐다 켜도 해당 도메인에서 로컬스토리지의 데이터가 유지된다. 다른 탭이어도 같은 도메인이면 같은 로컬 스토리지를 공유한다. 하지만 예를 들어 구글에서 저장된 로컬저장소의 데이터를 네이버에서 접근할 수는 없다. ex 자동 로그인 sessionStorage: 브라우저 하나의 탭이 하나의 세션이라고 생각하면 되는데, 각 세션마다 독립적으로 데이터가 저장되어 같은 도메인이라도 다른 탭에서는(=세션이 다르면) 접근할 수 없다. 브라우저가 종료되면 탭도 닫히는 거니까 말할 것도 없이 데이터가 사라진다. ex 일시적 로그인 필요할 때만 클라에서 js로직으로 꺼내 사용. (window. localStorage/ sessionStorage 객체로 .setItem/ .getItem) (단, 쿠키든 웹 스토리지든 브라우저 상에는 중요정보(주민번호, 카드번호..)는 저장하면 안된다.)

'' 카테고리의 다른 글

HTTP 통신  (0) 2025.01.04
osi 7계층, 인터넷 프로토콜 스택의 4계층(TCP/IP 4계층)  (3) 2024.12.29
TCP/IP 프로토콜과 인터넷 통신  (2) 2024.12.28
월드 와이드 웹 (www)  (4) 2024.12.27
URI: Uniform Resource Identifier

URL: Uniform Resource Locator

URN: Uniform Resource Name

URL과 URN은 URI에 포함된 개념이고 URI와 URL이 주로 사용된다.

애써 구분할 필요는 없다. 웹상에서 자원이 어디 있는지를 알려주는 규약이라고 생각하면 된다.

해당 위치에 있는 리소스는 HTML 파일뿐만 아니라 이미지, 영상, JSON, 처리 로직 등 다양한 형태일 수 있다.

웹 브라우저(클라이언트)의 주소창에 URL을 입력하면, 해당 위치(서버)로 요청을 보내 리소스를 받아와 렌더링한다.
이는 HTTP메소드 중 GET방식에 해당한다.

이 URL은 다음과 같은 구성 요소로 이루어져 있다:

  1. 프로토콜: https
  2. 도메인: www.google.com
    DNS를 통해 매핑된 IP 주소로 변환된다. DNS란 도메인 네임 시스템을 의미하고 이 서버를 통해 복잡한 IP주소를 친근한 도메인명으로 접근할 수 있게 한다. 이 자리에 도메인 대신 ip를 직접 넣어도 당연히 작동한다. (터미널에서 nslookup 명령어를 통해 ip주소 쉽게 확인 가능)
    도메인명에서 www는 생략하는 추세이다.
  3. 포트번호: 443
    HTTP(80), HTTPS(443)와 같은 기본 포트는 생략 가능하다.
  4. 리소스 경로(Path): /service/pc/eventView
    웹 서버에서 자원(페이지, 파일)이 위치하는 주소를 나타낸다. 계층적 구조로 되어 있어, 마치 폴더 안의 파일처럼 보인다. 혹은 백엔드 프레임워크에서 물리적 위치와 상관없이 특정 로직(메서드)에 연결하기 위해 컨트롤러나 메소드에 경로 매핑 작업을 수행하기도 한다.
  5. 쿼리(Query): ?name=sung&age=27 
    전달할 데이터가 있을 때 Key-Value 형식으로 사용하며, 파라미터라고도 한다. 값은 문자열로 전달된다.

요청-응답 모델인 HTTP통신에서 서버는 클라이언트의 요청이 있을 때만 응답을 보낸다. 즉, 클라이언트가 요청하지 않으면 서버는 아무 동작도 하지 않는 단방향 통신을 한다. 그리고 클라이언트와 서버는 요청-응답이 끝나면 연결을 끊는 비연결성(connectionless)의 특성도 갖는다. 항시 연결을 유지하지 않으므로 서버 자원을 절약할 수 있지만 요청할 때마다 새로운 연결을 맺기 때문에, TCP의 3-way handshake 같은 추가 작업이 필요하다.(일반적으로는 connectionless지만, 웹소켓 통신 라이브러리를 이용하면 실시간 양방향 데이터 전송이 가능하다. 이는 주식 차트, 채팅, 스트리밍 등에 활용된다.)
연결을 끊은 이후에 서버는 클라이언트의 상태를 기억하지 않는다. 무상태성(stateless) 덕분에 서버가 특정 클라이언트의 정보를 관리하지 않아도 되므로, 서버 컴퓨터 중 하나가 장애가 나더라도 영향을 받지 않으며 필요 시 서버 장비를 무한히 증식시킬 수 있어(확장성) 트래픽 처리에 용이하다. 허나 클라이언트가 로그인했더라도 서버는 그 상태를 유지하지 못해서 다음 요청때 해당 사용자가 로그인 된 사용자인지 기본적으로 알지 못한다는 단점이 있다. 무상태성을 극복하기 위해 (브라우저)쿠키, (서버)세션 같은 추가적인 메커니즘이 필요하다. (단, 상태 유지는 최소한으로 하는 것이 좋다.)

 

 

 

 

 

 

클라(pc, 스마트폰..)는 서버와 HTTP 요청&응답 메시지를 패킷에 담아 주고받는다.요청 메시지는 URL에 담긴 정보들과 거의 유사하다.

 

+ http프로토콜로 주고받는 데이터가 html뿐 아니라 JSON, XML, 이미지 등 다양한 데이터 포맷으로 확대되면서 구체적인 로직과 제공해줘야 할 데이터들은 서버와 db에 존재하고 클라는 ui/ux에 집중하여 독립적으로 발전하게 되었다.

참고로 헷갈리지 말아야 할 것은 클라이언트 영역이라고 우리가 지칭하는 것들도 클라 영역에서 이루어지는 것들에 주목할 뿐 사실은 서버에서 받아온 데이터들이다. 사용자의 관점에서 브라우저에 존재하며 서버에 요청하는 로직들을 포함한 것을 클라라고 부르는 것이다. 예를 들어, 클라이언트 사이드에서 JavaScript를 이용해 사용자와 상호작용하며 서버로 API 요청을 보내고, 그 응답 데이터를 화면에 표시한다고 했을때 이 JS 코드도 최초에는 서버에서 보내줬다는 의미다.

 

나의 답:

SELECT ED.ID, ED.GENOTYPE, EDP.GENOTYPE AS PARENT_GENOTYPE FROM ECOLI_DATA AS ED
LEFT JOIN (SELECT ID, GENOTYPE FROM ECOLI_DATA) AS EDP
ON ED.PARENT_ID = EDP.ID
WHERE ED.GENOTYPE & EDP.GENOTYPE = EDP.GENOTYPE
ORDER BY ID;

 

주어진 테이블의 SIZE_OF_COLONY, DIFFERENTIATION_DATE 는 필요없음.

비트연산자에 대한 개념을 몰라서 이렇게 간단한 쿼리인줄 모르고 끙끙 앓았다.

이진법이 나오면 비트연산자를 의심하자.

부모의 형질을 다 포함하냐는 말은 자식 형질과 부모 형질의 교집합이 부모 형질이냐는 말과 같다 !

즉, & 비트연산자를 사용했을 때 결과가 부모 형질과 같아야 한다.

 

비트연산자

a = 25, b = 10

이를 이진법으로 표현하면

a = 0001 1001, b = 0000 1010

 

두 값의 각 자리를 비교하며 해당 자리의 결과를 출력하는 연산자

AND 연산( & ): 둘 다 1일 때만 1을 출력

a & b = 0000 1000 = 8

OR 연산( | ): 둘 중 하나라도 1이면 1을 출력

a | b = 0001 1011 = 27

XOR 연산( ^ ): 둘 중 하나만 1일 때만 1을 출력

a ^ b = 0001 0011 = 19

 

하나의 값과 사용되는 연산자

보수 연산( ~ ): 모든 비트를 반전시킨다

~a = 1110 0110 = -26

왼쪽 시프트(<<): 지정된 비트 수만큼 왼쪽으로 이동

a << 2 = 0110 0100 = 100

오른쪽 시프트(>>): 지정된 비트 수만큼 오른쪽으로 이동

a >> 2 = 0000 0110 = 6 

 

조건절에서 사용되는 기타 연산자

각 단어의 뜻을 이해하면 암기하지 않아도 쉽다.

  • IN: 목록 내의 값과 일치하는지 확인할 때 사용
  • ANY: 여러 값 중 하나라도 조건을 만족하면 됨
  • ALL: 모든 값이 조건을 만족해야 함
  • EXISTS: 서브쿼리의 결과가 존재하는지 여부만 확인 (IN과 비슷)

SELECT * FROM 상품 WHERE 카테고리 IN ('의류', '신발', '가방');

SELECT * FROM 상품  WHERE 가격 > ANY (5000, 10000, 15000);  -- 5000보다 비싼 상품들 조회됨

SELECT * FROM 상품  WHERE 가격 < ANY (5000, 10000, 15000);  -- 15000보다 저렴한 상품들 조회됨

SELECT * FROM 상품  WHERE 가격 = ANY (5000, 10000, 15000);  -- IN과 동일 기능

SELECT * FROM 상품  WHERE 가격 > ALL (5000, 10000, 15000); -- 15000보다 비싼 상품들 조회됨

SELECT * FROM 상품  WHERE 가격 < ALL (5000, 10000, 15000); -- 5000보다 저렴한 상품들 조회됨

SELECT * FROM 상품  WHERE 가격 = ALL (5000, 10000, 15000); -- X

SELECT * FROM 주문  WHERE EXISTS (SELECT * FROM 배송완료);

한 프로그램에서 전송된 데이터가 어떤 과정을 거쳐 다른 컴퓨터의 프로그램까지 도착하는가를 계층을 나눠 표현한 개념이 있다. 이는 추상화된 통신 과정의 이해를 돕기 위해 나름의 기준으로 구체화한 것이다.

서적마다 다른 분류 방식(참조 모델)이 제시될 수 있겠지만 대표적으로는 다음 두 모델이 있고, 같은 통신 과정을 표현한 모델이기에 사실 본질은 같다.

OSI 7계층을 깊게 공부하여 각 계층과 전반의 흐름을 완전히 이해한다면 네트워크를 마스터했다고 볼 수 있을 만큼 중요해서 자격증을 공부해보면 OSI 7계층이 아주 중요한 개념으로 등장하는 경우가 많다.

단, 말그대로 청사진을 위한 '참조'모델이기에 너무 '계층의 역할'에 국한되어 대응시키려 말고 전체 통신 흐름에 집중해서 천천히 이해해보자.

 

OSI 7계층

  1. 물리계층
  2. 데이터링크계층
  3. 네트워크계층
  4. 전송계층
  5. 세션계층
  6. 표현계층
  7. 응용계층

TCP/IP 4계층(인터넷 프로토콜 스택의 4계층)

  1. 네트워크 엑세스 계층(= 네트워크/ 네트워크 인터페이스 계층) = 물리, 데이터링크 계층
  2. 인터넷 계층(IP) = 네트워크 계층(네트워크 엑세스 계층 아님)
  3. 전송 계층(TCP/UDP) = 전송 계층
  4. 애플리케이션 계층(HTTP/FTP) = 세션, 표현, 응용 계층

 

컴퓨터간에 데이터가 전달되는 과정은 보내려는 택배물품을 여러 겹의 포장으로 감싸 손을 떠나 보내면

받는 사람이 그 역순으로 포장을 뜯어 내용물을 최종으로 확인하는 것과 똑같은 과정을 거친다.

즉, 여러 계층을 거치며 포장되어 전송되고(캡슐화), 도착하면 패키지를 풀러(역캡슐화) 확인하는 것이다.

이 과정을 TCP/IP 4계층 모델로 살펴보자. 

우선 애플리케이션계층에 해당하는 프로그램(웹브라우저/게임/카톡…)에서 전달하고자 하는 http메세지가 생성된다.

이후 OS영역에 해당하는 전송 계층, 인터넷 계층에서 차례로 메세지에 TCP정보 IP정보를 추가하여 감싼다. (ip보다 tcp가 먼저임)

그렇게 최종적으로 생성된 패킷은 출발/도착 ip, 출발/도착 port, http메세지, 기타 정보로 구성된다.

마지막으로 네트워크 엑세스 계층에서는 이더넷 프레임을 추가하고 LAN 카드의 MAC 주소 등 물리적 전송에 필요한 정보까지 포함하게 된다. 그렇게 송신 준비를 마친 후 인터넷을 구성하는 여러 네트워크 장비를 거쳐 도착 노드(컴퓨터)에 도착하게 되고, 

해당 컴퓨터에서는 네트워크 엑세스 > 인터넷 > 전송 > 애플리케이션 계층을 거쳐 최종적으로 프로그램이 메세지를 확인하게 된다.

(네트워크 엑세스 계층: 이더넷 프레임 제거 > 인터넷 계층: IP 관련 정보 확인 및 제거 > 전송 계층: TCP 관련 정보 확인 및 제거 > 애플리케이션 계층: 최종 데이터 수신)

 

1. 애플리케이션 계층 (Application Layer)

OSI 7계층의 상위 3개 계층(응용, 표현, 세션)을 포함

  • 응용 계층: 사용자와 직접 상호작용
    • 웹브라우저, 파일 전송, 이메일 등의 서비스
    • HTTP, FTP, SMTP 등의 프로토콜 사용
  • 표현 계층: 데이터 형식을 변환
    • 암호화/복호화
    • 데이터 압축
    • 문자 인코딩 (ASCII, UTF-8 등)
  • 세션 계층: 통신 세션 관리

2. 전송 계층 (Transport Layer)

OSI 7계층의 전송 계층과 동일

  • TCP: 신뢰성 중시 (데이터 손실 방지)
    • 연결 지향적 통신, 순서 보장, 오류 검사와 재전송
  • UDP

3. 인터넷 계층 (Internet Layer)

OSI 7계층의 네트워크 계층:

  • IP 주소 기반의 라우팅
  • 패킷의 경로 결정
  • 서로 다른 네트워크 간의 통신 관리

4. 네트워크 인터페이스 계층 (Network Access Layer)

OSI 7계층의 물리계층과 데이터링크 계층을 포함:

  • 데이터링크 계층: 직접 연결된 노드 간 통신
    • MAC 주소 사용
    • 이더넷 프레임 생성
  • 물리 계층: 실제 물리적 연결 담당
    • 전기 신호로 변환
    • 케이블, 리피터, 허브 등의 장비 사용

 

'' 카테고리의 다른 글

쿠키, 웹스토리지(로컬 스토리지, 세션 스토리지)  (0) 2025.01.05
HTTP 통신  (0) 2025.01.04
TCP/IP 프로토콜과 인터넷 통신  (2) 2024.12.28
월드 와이드 웹 (www)  (4) 2024.12.27

+ Recent posts