![]()
DNS와 hosts 파일 동작 원리1. 일반적인 DNS 조회 과정브라우저 → hosts 파일 확인 → DNS 서버 조회 → IP 주소 반환 → 웹사이트 접속2. hosts 파일 수정 후 과정브라우저 → hosts 파일에서 직접 IP 발견 → DNS 서버 건너뛰고 바로 해당 IP로 접속hosts 수정하여 사용하기 단계별 정리단계 1: 현재 상황 파악원래 도메인(예: example.com)이 CloudFront → S3를 가리킴하지만 Cafe24 서버(000.000.000.000)의 내용을 확인해야 함단계 2: hosts 파일 수정로컬 hosts 파일에 다음과 같은 내용 추가:000.000.000.000 example.com단계 3: 결과브라우저에서 example.com 입력 시 DNS를 거치지 않고 바로 ..
![]()
SSO vs OAuthSSO(Single Sign-On)와 OAuth는 인증(Authentication)과 인가(Authorization) 관점에서 서로 다릅니다. 간단히 비교하면 다음과 같습니다:✅ 목적의 차이항목SSO (Single Sign-On)OAuth (Open Authorization)핵심 목적하나의 로그인으로 여러 서비스 사용제3자 앱이 사용자의 자원에 접근 허용주요 개념인증(Authentication) 중심인가(Authorization) 중심✅ 예시SSO:회사 포털에 한 번 로그인하면 이메일, 회계, 인트라넷 등 다양한 시스템에 추가 로그인 없이 접근 가능OAuth:어떤 앱이 “구글 계정으로 로그인”할 때, 구글에서 인증하고 → 해당 앱이 사용자 이메일, 프로필 등 제한된 정보에 접근하도록..
![]()
JSON-LD: 웹 표준에서 AI 검색 기반으로JSON-LD는 단순한 웹 표준에서 AI 기반 검색 최적화의 핵심으로 변모했습니다. 2011년 JSON과 시맨틱 웹 기술을 연결하기 위해 설계된 JSON-LD는 이제 지식 그래프, AI 크롤러, 생성형 검색 엔진의 중요한 인프라 역할을 하고 있습니다. 이러한 진화는 기계가 웹 콘텐츠를 이해하고 처리하는 방식에서 가장 중요한 변화 중 하나를 나타냅니다.기원과 표준화: 링크드 데이터를 접근 가능하게 만들기JSON-LD는 2011년 시맨틱 웹 기술을 단순화해야 한다는 절실한 필요에서 출현했습니다. Digital Bazaar의 Manu Sporny가 프로젝트를 시작했고, 공동 편집자인 Gregg Kellogg, Markus Lanthaler, Dave Longley..
![]()
작년에 FSD를 나름대로(?) 적용하여 진행했던 프로젝트가 있었습니다.그러나 FSD에 대한 깊은 이해를 바탕으로 적용했다기 보다는그냥 '기능 중심으로 묶는다' 정도로 생각했었기 때문에 부족함을 많이 느꼈었습니다. 그래서 이번에 FSD를 다시한번 공부하며 도입해 보았는데 이 과정에서여러 의견을 종합하고 제 나름대로 커스텀(...)해보았던 기록을 남깁니다. FSD의 개념에 대한 내용은 검색하면 많이 나옵니다.# (번역) 기능 분할 설계 - 최고의 프런트엔드 아키텍처# 프론트엔드 개발자 관점으로 바라보는 관심사의 분리와 좋은 폴더 구조 (feat. FSD)# Feature-Sliced Design을 직접 사용하면서 느낀 장점과 단점# FSD 아키텍처 알아보기위 블로그 등을 참고할 수 있겠습니다(감사합니다) ..
![]()
문제 상황회사 밖에서 회사 서버에 접속해야 했습니다.하지만 회사 서버는 방화벽 설정으로 인해 외부에서는 직접 접근이 불가능했습니다.해결 시도회사에서 제공한 OpenVPN 설정 파일(.ovpn)과 함께, crt, key, pem 등 필요한 인증서 파일들도 모두 갖추고 있었습니다.macOS에서 OpenVPN Connect 앱으로 시도했지만, 접속은 계속 실패했고 로그에는 서버 타임아웃 메시지가 반복되었습니다..ovpn 파일을 수정해 UDP → TCP, 포트 변경, 불필요한 옵션 제거 등 여러 가지 방법을 시도했지만 효과가 없었습니다.결국 회사 선임에게 도움을 요청했고, 제 집 공인 IP를 화이트리스트에 등록하는 방식으로 문제를 해결했습니다.배운 것이 과정을 통해 VPN의 기본 원리에 대해 다시 이해하게 되었..
![]()
🔬 마이크로프론트엔드 개념 정리 및 심화 분석1️⃣ 마이크로프론트엔드 개념 정리📌 정의와 목적:마이크로프론트엔드(Micro Frontend)는 여러 개의 작고 독립적인 프론트엔드 애플리케이션을 모아 하나의 거대한 앱처럼 구성하는 아키텍처 스타일을 말합니다 (마이크로프론트엔드 아키텍쳐). 다시 말해, 마이크로서비스 개념을 프론트엔드에 적용하여 프론트엔드 전체를 분리된 작은 단위로 개발/테스트/배포하는 패턴입니다.각각의 단위 애플리케이션(마이크로 앱)이 독립적으로 제공되고, 이러한 마이크로 앱 “조각(fragment)” 들을 조합하여 최종 사용자에게는 하나의 일관된 웹 앱으로 보이게 만드는 것이 목표입니다 (마이크로프론트엔드 아키텍쳐) (마이크로 프론트엔드로 페이지 및 뷰 작성 - AWS 규범적 지침)...
![]()
XSS와 SQL Injection: 왜 실행될까?💡 핵심 질문:"유저 입력에 JavaScript 코드나 SQL 문을 넣는다고 해서, 이게 클라이언트나 서버에서 실행될 수 있는가?"✅ 답변: 실행될 수 있음.XSS는 클라이언트(브라우저)에서 실행되는 문제SQL Injection은 서버(DB)에서 실행되는 문제둘 다 입력값을 제대로 처리하지 않으면 악성 코드가 실행될 수 있음.1️⃣ XSS (Cross-Site Scripting) → 클라이언트에서 실행됨XSS가 발생하는 이유:브라우저는 HTML을 렌더링할 때, 스크립트(이 값이 그대로 데이터베이스에 저장됨이후, 다른 사용자가 이 페이지를 방문할 때 저장된 악성 스크립트가 브라우저에서 실행됨📌 왜 실행될까?서버가 입력값을 필터링 없이 그대로 HTML로 반..
![]()
1. XSS(Cross-Site Scripting) 방어💡 문제:사용자가 입력한 HTML 태그를 그대로 렌더링하는 취약점 발견 (Stored XSS)URL 파라미터에서 자바스크립트 실행이 가능한 이슈 발견 (Reflected XSS)✅ 해결 방법:React에서 기본적으로 dangerouslySetInnerHTML을 사용하지 않도록 하고, DOMPurify를 적용해 안전한 HTML만 허용서버에서 Content-Security-Policy (CSP) 헤더를 추가하여 악성 스크립트 실행 방지escape()를 적용해 HTML 인코딩 처리📌 예제 코드 (DOMPurify 적용)import DOMPurify from "dompurify";const sanitizedHTML = DOMPurify.sanitize(..
![]()
HTTP란 무엇인가?HTTP(HyperText Transfer Protocol)는 클라이언트-서버 간의 요청/응답을 처리하는 프로토콜입니다.HTTP는 클라이언트와 서버 간의 요청-응답을 처리하는 애플리케이션 계층 프로토콜입니다. 기본적으로 stateless하며, 요청 방식(메서드)과 응답 코드, 헤더, 바디 등의 개념을 포함합니다. GET, POST, PUT, DELETE 같은 메서드를 사용해 리소스를 요청하고 조작합니다. 또한, HTTP/1.1, HTTP/2, HTTP/3 등의 버전이 있으며 성능과 보안 측면에서 차이를 보입니다.주요 개념HTTP의 특징Stateless (기본적으로 상태를 유지하지 않음)Request-Response 구조메서드(GET, POST, PUT, DELETE 등)와 역할HTTP..
![]()
추상화(Abstraction)란?추상화는 코드의 복잡성을 줄이기 위해 핵심적인 기능만 노출하고, 불필요한 세부 사항을 숨기는 개념입니다. 예를 들어, 자동차를 운전할 때 내부 엔진 동작을 몰라도 '엑셀을 밟으면 가속된다'는 것만 알면 됩니다. 프로그래밍에서도, 함수나 클래스가 내부 로직을 감추고 인터페이스만 제공하면, 더 쉽게 이해하고 유지보수할 수 있습니다. 복잡성을 줄이고, 사용자가 필요한 정보만 보이도록 설계내부 구현을 숨기고, 인터페이스만 제공하여 유지보수성을 향상**객체지향 프로그래밍(OOP)에서 핵심 원칙 중 하나 ✅ 추상화의 핵심 역할 → "불필요한 세부 사항을 숨기고, 핵심 기능만 제공"✅ 쉽게 이해할 수 있는 비유 → "자동차의 가속 원리를 몰라도 운전 가능"✅ 실제 코드 적용 가능성 →..
![]()
📌 Trunk-Based Development vs GitHub Flow 차이점둘 다 가벼운 브랜치 전략으로, 빠른 배포를 목표로 합니다. 하지만 몇 가지 중요한 차이가 있습니다.🚀 1. Trunk-Based Development (TBD)✅ 핵심 개념:main 브랜치(=Trunk)에서 직접 개발하고,짧은-lived feature 브랜치만 사용하며,하루에도 여러 번 main에 머지하는 방식.✅ 특징:브랜치는 짧게 유지 → 몇 시간 또는 하루 이내 병합Long-lived feature 브랜치 없음 → develop 브랜치 XCI/CD 필수 → main에 병합 시 항상 배포 가능 상태 유지✅ 워크플로우:main에서 직접 개발하거나 짧은-lived 브랜치 생성빠르게 개발 후 main에 머지CI/CD가 ma..
![]()
애자일 방법론(Agile Methodology)이란?애자일(Agile) 방법론은 빠른 개발과 지속적인 개선을 목표로 하는 소프트웨어 개발 방식입니다.고객의 요구 사항 변화에 유연하게 대응하고, 반복적인 개발과 피드백을 통해 품질을 개선하는 것이 핵심입니다.🛠 애자일 방법론의 핵심 개념반복적(Iterative) 개발 → 짧은 주기로 기능을 추가 및 개선고객 중심(Customer Collaboration) → 고객 피드백을 지속적으로 반영자율적인 팀(Self-organizing Team) → 개발팀이 주도적으로 의사결정변화 수용(Embrace Change) → 계획보다 적응을 중요하게 생각작동하는 소프트웨어(Working Software) → 문서보다 실제 동작하는 제품을 우선📜 애자일 선언(Agile ..
![]()
제어 역전(Inversion of Control, IoC)과 의존성 주입(Dependency Injection, DI)의 개념 및 차이점1. 제어 역전(Inversion of Control, IoC)제어 역전(IoC)은 객체의 흐름(제어)을 개발자가 직접 관리하는 것이 아니라 외부에서 제어권을 가져가고, 필요한 시점에 객체를 실행하는 디자인 패턴을 의미합니다.쉽게 말해, 객체의 생성과 실행 흐름을 프레임워크나 컨테이너에 맡기는 방식입니다.예제 1: 제어 역전이 없는 코드 (개발자가 직접 객체를 제어)class Service { run() { console.log("Service is running!"); }}class Application { constructor() { this.serv..
![]()
문제 정의불필요한 조건문과 중복된 로직이 가독성과 유지보수성을 해쳤습니다.if(pageQery !== null) { const page = Number(pageQuery); const start = page === 1 || page === 0 ? 0 : (page - 1) * MOIMS_ITEMS_PER_PAGE; // ...}급하게 구현하느라 생각이 가는 대로(?) 작성했던 코드.하지만 지나고 보니 너무나도 이상해 보였습니다.단순한 조건문 개선 상황이지만, 이런 실수를 계속 반복하면 안 된다고 생각했습니다.나는 앞으로도 이런 짓을 할 것인가? 하는 성찰의 순간이 찾아왔습니다.해결 과정🔍 왜 이해가 안되고 무슨 문제가 있었을까?page === 1 || page === 0 → 불필요한 조건문NaN,..
![]()
Qvercel 등 serverless 서비스에 대해 질문이 있어요. nextjs 는 간단한 서버 기능도 있어서 풀스택 프레임워크에 가깝잖아요. 그리고 이를 vercel에 배포시 자동적으로 이러한 서버 기능이 작동하고요. 그런데 fs 같은 파일 동작은 처리하지 못하는 걸로 알고 있는데, 이게 serverless 이기 때문인 건가요? severless 이므로 저장할 server 가 없어서 파일을 다루지 못하는 걸까요?A맞습니다. Serverless 환경에서는 서버 기능을 제공하지만, 파일 시스템과 같은 지속적인 상태 관리는 제한적입니다. 이 제약은 Serverless의 특성과 동작 방식 때문입니다. 아래에서 이에 대한 자세한 이유를 설명드리겠습니다.1. Serverless란?Serverless는 실제로 서버..
![]()
sudo lsof -i :5432sudo kill -9
![]()
CORS? SOP?1. SOP(동일 출처 정책, Same-Origin Policy)웹 보안 모델의 핵심으로, 다른 출처의 리소스에 대한 접근을 제한브라우저에서 실행되는 JavaScript가 다른 출처의 API나 리소스에 접근하지 못하도록 함동일 출처의 정의: 프로토콜, 호스트, 포트가 모두 같은 경우 참고링크SOP의 목적: 악의적인 스크립트가 민감한 정보에 접근하는 것을 방지하기 위함2. CORS(교차 출처 리소스 공유, Cross-Origin Resource Sharing)SOP의 제한을 일부 해제하기 위한 보안 정책서버측에서 특정 출처에 대한 접근을 허용할 수 있게 해줌동작방식:클라이언트 측 요청: 요청이 발생할 때 브라우저는 요청이 안전한지 확인하기 위해 CORS 확인서버 측 응답: 특정 클라이언트..
![]()
1.Q1: OOP는 Stateful 프로그램에는 적합하지만, Stateless 프로그램에는 적합도가 떨어지는 편인가?A1: ① Stateful과 Stateless의 개념 Stateful 프로그램은 내부에 상태(state)를 유지하며, 그 상태에 따라 프로그램의 동작이 달라집니다. 예를 들어, 은행 계좌의 잔액 정보를 저장하고 그에 따라 입출금 작업을 수행하는 시스템은 상태를 유지해야 합니다. 반면에 Stateless 프로그램은 내부에 상태를 유지하지 않습니다. 즉, 각 요청이나 함수 호출은 이전의 상태에 영향을 받지 않고 독립적으로 처리됩니다. 예를 들어, 단순한 계산기 프로그램은 입력값에 따라 결과를 반환하지만, 내부에 상태를 저장하지 않습니다.A1: ② 객체지향 프로그래밍(OOP)과 Stateful ..
![]()
1. 싱글톤 패턴이란? Zustand 는 싱글톤 패턴?싱글톤 패턴(Singleton Pattern)은 소프트웨어 디자인 패턴 중 하나로, 하나의 클래스에서 단 하나의 인스턴스만 생성되도록 보장하는 패턴입니다. 즉, 애플리케이션 전체에서 특정 클래스의 객체가 오직 하나만 존재하고, 어디서든 이 객체에 접근할 수 있는 전역적인 접근점을 제공합니다. 정의:싱글톤 패턴은 클래스의 인스턴스를 하나로 제한하고, 해당 인스턴스가 전역적으로 사용될 수 있도록 하는 디자인 패턴입니다. 동작 방식:• 클래스 내에 하나의 인스턴스만을 생성하며, 외부에서 해당 인스턴스를 직접 생성할 수 없도록 생성자를 private으로 설정합니다.• 클래스가 처음 호출되면 내부적으로 인스턴스를 생성하고, 이후부터는 동일한 인스턴스를 반환하여..
![]()
오늘은 전 팀원님과 지난 팀프로젝트 코드 리뷰를 진행했습니다! 꽤나 시간이 걸렸지만 한 줄 한 줄 이야기 나누면서 이해도도 높아지고 함께 코딩한다는 것이 어떤 느낌인지도 확실히 알 수 있었습니다. 그 과정에서 내 코드를 돌아보며, ' 좋은 함수' 란 무엇인지에 대해 되새겨 보았습니다. 특히, 함수 보다 상위 스코프에서 정의된 변수를 사용할 경우, 함수 실행시 해당 상위 변수를 파라미터에 넣어서 쓰는게 좋은지, 아니면 그냥 상위 변수를 참조해도 되는지가 명확하지 않았습니다. 그래서 '좋은 함수'에 대해 다시한번 되짚어 보았습니다. 1. 순수 함수 (Pure Functions): 가능하면 순수 함수를 사용하는 것이 좋습니다. 순수 함수는 동일한 입력에 대해 항상 동일한 결과를 반환하며, 외부 상태를 변경하지..
