[24일차]ABC 부트캠프

 

---

포트(Port)란

포트는 "컴퓨터 네트워크에서 프로그램끼리 서로 통신할 때 쓰는 '출입구 번호'"라고 생각하면 된다.

• 집에 여러 개의 방이 있듯이, 한 컴퓨터(=집)에도 여러 개의 프로그램(=방)이 동시에 네트워크를 사용한다.
• 그런데 집 주소(=IP 주소)만으로는 "어느 방(=프로그램)"으로 가야 할지 알 수 없다.
• 그래서 포트 번호라는 방 번호를 붙여서 "IP 주소 + 포트 번호"로 정확히 찾아가는 것.

비유로 이해하기

• IP 주소 = 아파트 동·호수 (아파트 단지 전체에서 우리 집을 가리킴)
• 포트 번호 = 집 안의 방 번호 (거실, 방1, 방2처럼 구분)
• 데이터 패킷 = 택배 (인터넷을 통해 오가는 실제 데이터)

👉 즉, 택배 기사님(네트워크)이 "IP 주소"를 보고 아파트를 찾아가고, "포트 번호"를 보고 어느 방으로 배달할지 결정

 

포트 번호의 범위

포트 번호는 0번 ~ 65535번까지 있다. (16비트 정수라서)

• 0 ~ 1023번: 잘 알려진 포트 (Well-known Ports) → 특정 서비스가 거의 고정적으로 사용
  • 예: 80번(HTTP), 443번(HTTPS), 22번(SSH), 25번(SMTP)
• 1024 ~ 49151번: 등록된 포트 (Registered Ports) → 특정 앱/서비스들이 사용
• 49152 ~ 65535번: 동적 포트 (Dynamic/Private Ports) → 클라이언트가 임시로 사용

실제 예시

1. 내가 웹 브라우저로 www.naver.com에 접속할 때:
   • 브라우저(클라이언트)는 임의의 동적 포트를 열고 요청을 보냄
   • 네이버 서버는 80번(HTTP) 또는 443번(HTTPS) 포트에서 기다림
   • 데이터는 IP 주소로 네이버 서버까지 가고, 포트 번호를 보고 "웹 서비스 프로그램"에 전달됨
2. 내가 친구랑 메신저로 대화할 때:
   • 메시지 서버는 예를 들어 **5222번(XMPP 같은 메신저 포트)**에서 대기
   • 클라이언트 앱은 해당 포트와 연결해서 메시지를 주고받음

클라이언트는 **임시 포트 번호(Ephemeral Port, 동적 포트)**를 사용.

• 보통 49152 ~ 65535번 사이에서 운영체제가 자동으로 할당.
• 클라이언트가 요청을 보내면, "출발지 포트"는 매번 바뀌고, "목적지 포트"는 서버의 고정 포트.
• 서버가 응답을 줄 때는 클라이언트의 임시 포트로 돌려줌.

---

정적 서버(Static Server)

정적 서버는 그대로 저장된 파일을 클라이언트에게 전달하는 서버

• 서버에 있는 HTML, CSS, JS, 이미지 같은 파일을 있는 그대로 보냄.
• 서버 쪽에서 특별히 계산하거나 가공하지 않음.
• 클라이언트(브라우저)는 받은 파일을 그대로 화면에 표시.

📌 예시:

• HTML 파일 하나 만들어서 index.html로 저장하고, 웹 서버에 올려두면 그대로 보여줌.
• 옛날 홈페이지들(공지사항, 단순 회사 소개 페이지 등) → 정적 서버 방식

👉 장점: 빠르고 안정적임, 서버 자원 소모 적음
👉 단점: 내용이 바뀌면 매번 직접 파일 수정해야 함 (유연성이 떨어짐)

 

동적 서버(Dynamic Server)

동적 서버는 클라이언트 요청에 따라 서버가 “즉석에서” 결과를 만들어 보내는 서버

• 서버가 DB와 상호작용해서 필요한 데이터를 가져옴.
• 요청마다 다른 결과를 만들어 응답.
• 주로 PHP, Node.js, Python(Django/Flask), Java(Spring) 같은 서버 사이드 프로그래밍이 쓰임.

📌 예시:

• 쇼핑몰에서 내가 장바구니를 열면, 내 계정에 맞는 상품 목록을 DB에서 불러와서 페이지를 생성해줌.
• 로그인한 사람마다 다른 화면이 나오는 웹사이트들 → 동적 서버

👉 장점: 사용자 맞춤 서비스 제공 가능, 자동화·확장성 높음
👉 단점: 서버 부하가 크고 속도가 느릴 수 있음, 보안 이슈 발생 가능

 

 

현대 웹에서의 활용

사실 요즘은 정적 + 동적을 섞어서 쓰는 경우가 많다.

• 예:
  • 블로그 본문은 DB에서 불러와서 동적으로 생성
  • 이미지·CSS·JS 파일은 정적으로 제공 (CDN 활용)
• 프레임워크(React, Next.js, Vue 등)도 정적/동적 방식을 조합해서 성능 최적화

 

 

 

 

정적 파일(파일만 서빙)

-python -m http server 8000

 

동적 서버

적 서버는 클라이언트 요청에 따라 서버가 코드를 실행해서 결과를 만들어서 응답

 

 

---

HTTP (HyperText Transfer Protocol)

• 웹에서 정보를 주고받기 위한 기본 통신 규약(프로토콜)
• 브라우저 ↔ 서버 간에 데이터를 주고받을 때 사용
• 하지만 암호화되지 않은 평문(plain text) 통신이라 보안에 취약.
  • 누군가 네트워크를 엿보면 → 아이디/비밀번호, 개인정보가 그대로 보임

📌 비유:
편지를 쓰고 그냥 봉투 없이 우편함에 넣는 것과 같음 → 누구나 편지 내용을 볼 수 있음.

---

 HTTPS (HyperText Transfer Protocol Secure)

• HTTP에 보안(SSL/TLS) 계층을 추가한 버전
• 서버와 클라이언트가 데이터를 주고받을 때 암호화해서 보냄
• 따라서 중간에 누가 가로채도 내용을 알 수 없음

📌 비유:
편지를 보내는데, 자물쇠 달린 봉투에 넣고 열쇠는 받는 사람만 가지고 있음 🔑
→ 중간에서 훔쳐봐도 해독 불가!

---

🔹 3. 동작 방식 차이

1. HTTP
   • 클라이언트가 요청 → 서버가 응답
   • 그냥 평문으로 주고받음
2. HTTPS
   • 먼저 SSL/TLS Handshake 과정을 거쳐 암호화 키를 서로 주고받음
   • 이후부터는 그 키를 이용해 데이터를 암호화해서 주고받음

---

ngrok

• 내 로컬(개인 PC)에서 실행 중인 서버를 외부 인터넷에서 접근할 수 있게 해주는 도구.
• 보통 내 컴퓨터에서 localhost:3000 이런 주소로 서버를 켜면, 다른 사람은 접속할 수 없음
  → ngrok을 쓰면 임시로 공개 가능한 URL을 만들어 줍니다.

📌 즉, 내 컴퓨터를 인터넷에 잠시 노출시키는 터널 역할!

https://dashboard.ngrok.com/get-started/setup/windows

ngrok — Log in

 

 

 

 

 

https://docs.pydantic.dev/latest/

Welcome to Pydantic - Pydantic

 

1. Tailwind CSS

• CSS 프레임워크임
• 부트스트랩처럼 미리 짜여진 컴포넌트 거의 없음
• 대신 mt-4, text-xl, bg-red-500 같은 유틸리티 클래스만 줌
• 개발자가 필요한 스타일을 퍼즐처럼 조립 가능
• CSS 파일 따로 안 건드려도 됨 → HTML 클래스만으로 스타일 다 됨
• 빠르고 일관된 스타일링 가능함

---

2. Vanilla JS

• 프레임워크나 라이브러리 안 쓰고 순수 자바스크립트만 쓰는 거 말함
• jQuery, React, Vue 같은 거 다 배제
• 브라우저 내장 기능만으로 개발
• 장점: 가볍고 의존성 없음
• 단점: 복잡한 프로젝트에서 구조 관리 힘듦

---

3. htmx

• HTML에서 직접 AJAX, WebSocket 같은 걸 제어할 수 있게 해줌
• <button hx-get="/data" hx-target="#result"> 이런 식으로 쓰면 서버에서 데이터 가져옴
• 자바스크립트 안 쓰고도 비동기 통신 가능
• 철학: “HTML을 다시 웹의 중심으로”
• JS 로직 줄이고 서버 중심 개발 가능

---

4. Alpine.js

• 미니멀한 프론트엔드 JS 프레임워크
• React나 Vue처럼 컴포넌트 기반인데 훨씬 가벼움
• <div x-data="{ open: false }" x-show="open"> 이런 식으로 쓰면 됨
• HTML 태그 속성(x-data, x-show, x-on:click)으로 로직 표현
• "Tailwind랑 같이 쓰는 작은 Vue" 느낌

---

 

AI 활용에 대한 “태도”에서 좋은 관점을 제시하는 글이니, 일독을 권합니다.

——

✅ AI착시와 평균의 함정을 피한 슈퍼 개인의 통찰:
     AI 도구로 생산성 38% 향상시킨 개발자의 비밀

모든 개발자가 착시에 빠졌는데, 단 한 명만 성공한 이유
지난달 발표된 한 연구 결과가 개발자 커뮤니티에 충격을 안겼다. 16명의 개발자에게 AI 개발 도구(Cursor와 Claude Sonnet)를 사용하게 했더니, 모든 개발자가 "생산성이 향상되었다"고 답했음에도 불구하고 실제로는 평균 19% 작업 시간이 지연되었다는 것이다.
하지만 이 이야기에는 놀라운 반전이 있었다. 16명 중 단 한 명, 퀜틴 앤서니(Quentin Anthony)라는 개발자만은 무려 38%의 생산성 향상을 달성했던 것이다.
퀜틴은 X(트위터)에서 자신의 경험을 공개하며 왜 자신만 성공했는지, 그리고 다른 사람들은 왜 실패했는지에 대한 깊이 있는 분석을 공유했다.

✅ 슈퍼 개인의 세 가지 핵심 인사이트

1. "AI는 마법이 아니다" - 실패 모드 회피의 중요성
퀜틴이 발견한 첫 번째 함정은 AI에 대한 과도한 기대였다.

"사람들은 AI는 도구일 뿐이라고 말하면서도 마법의 상자처럼 대한다"

대부분의 개발자들이 다음과 같은 패턴에 빠졌다:

AI에게 너무 복잡한 작업을 한 번에 요청
원하는 결과가 나올 때까지 계속 재시도
이 반복 과정 자체가 도파민 분비를 유발해 중독성을 만듦

퀜틴은 이런 함정을 피하기 위해 AI의 한계를 명확히 인식하고, 적절한 수준의 작업만 맡겼다. 개발을 잘한다고 해서 AI 도구를 잘 쓰는 것은 아니라는 그의 지적이 핵심이다.

2. "AI의 능력은 극도로 편중되어 있다" - 스마트한 선택과 집중
두 번째 인사이트는 AI의 능력 분포에 대한 정확한 이해였다.
퀜틴은 AI가 다음과 같은 특성을 갖는다고 분석했다:

학습 데이터가 풍부한 영역: 뛰어난 성능 (웹 개발, 일반적인 알고리즘 등)
학습 데이터가 부족한 영역: 매우 취약한 성능 (저수준 시스템 프로그래밍, 특수한 도메인 등)

그는 "잠깐 써보고 안 되겠다 싶으면 바로 수동으로 전환한다"는 원칙을 세웠다. 다른 개발자들이 AI가 잘 못하는 영역에서도 계속 시도하며 시간을 낭비하는 동안, 그는 빠른 판단으로 효율성을 극대화했다.

3. "집중력 관리가 승부를 결정한다" - 의식적인 워크플로우 설계
세 번째이자 가장 중요한 인사이트는 인간의 주의력 관리였다.

AI가 답변을 생성하는 30초 동안 사람들이 SNS를 확인
결국 30초 대기 시간이 30분의 딴짓으로 확장
"컨텍스트 부패" 현상: 긴 대화로 인해 AI가 혼란스러워짐

그의 해결책은

의식적인 맥락 관리: 후속 작업을 미리 준비
새로운 채팅 자주 시작: 컨텍스트 관리
자기 인식: 자신의 주의력 패턴을 이해하고 관리

✅ 슈퍼 개인이 되기 위한 실천 방법

AI착시와 평균의 함정에서 벗어나기 위해서는

1. 도구의 한계를 인정하라
AI가 만능이 아님을 받아들이기
실패했을 때 빠르게 포기하고 다른 방법 시도

2. 자신만의 사용 패턴을 개발하라
어떤 작업에 AI가 효과적인지 경험으로 학습
충분한 연습 시간 확보

3. 집중력을 의식적으로 관리하라
AI 대기 시간에 할 일을 미리 준비
주의 분산 요소들을 제거

4. 지속적인 자기 성찰
내가 왜 이 도구를 사용하는가?
정말 시간을 절약하고 있는가?

도구가 아닌 사용자가 차이를 만든다.

도구 자체에 매혹되지 말고
도구의 한계와 자신의 한계를 정확히 파악하고
의식적이고 전략적으로 접근해야 한다.

퀜틴의 마지막 조언이 모든 것을 요약한다.

"LLM은 도구일 뿐이다. 우리는 그 함정들을 배우고 자기 성찰을 해야 한다."

---

---

https://aistudio.google.com/prompts/new_chat

로그인 - Google 계정

구글 ai sudio를 활용하여 만든 뽀모도로 타이머 프롬프트