이서영의 개발 블로그

[Vue.js/PrimeVue] Password 컴포넌트에 구글 계정 정보가 자동 입력되는 문제

스응 — Wed, 9 Jul 2025 10:28:57 +0900

PrimeVue의 Password 컴포넌트를 사용했는데

해당 사이트에 저장해둔 계정 정보가 계속 자동으로 입력되는 문제가 있었다.

# 해결방법

<Password
  id="password"
  v-model="vm.user.password"
  name="password"
  :input-props="{ autocomplete: 'new-password' }"
/>

- 위와 같은 방식으로 넣어 주어야 Password 컴포넌트 내부의 <input> 태그에 autocomplete: 'new-password'가 적용된다.

[Swagger] Please indicate a valid Swagger or OpenAPI version field.

스응 — Wed, 11 Jun 2025 13:58:33 +0900

Unable to render this definition The provided definition does not specify a valid version field.
Please indicate a valid Swagger or OpenAPI version field.
Supported version fields are swagger: "2.0" and those that match openapi: 3.x.y (for example, openapi: 3.1.0).

딱히 건든 거 없이, git push만 했는데 갑자기 저런 에러가 나면서 스웨거가 제대로 실행이 안됐다.

Swashbuckle 캐시 문제 때문에 이런 현상이 발생하는 경우가 있다고 한다.

강력 새로고침 ([Ctrl] + [Shift] + [R])로 해결했다.

[Vue.js/konva] 파스칼 케이스로 작성했을 때 konva 컴포넌트가 불러와지지 않는 문제

스응 — Thu, 10 Apr 2025 14:00:13 +0900

[ 문제 상황 ]

vue-konva는 기본적으로 컴포넌트명에 'v-' 접두사를 붙여서 케밥 케이스로 사용한다.

ex) v-stage, v-text, ...

이전에 다른 프로젝트에서는 괜찮았는데, 이번 프로젝트는 저장 시 컴포넌트명이 자동으로 파스칼 케이스로 변환되도록 규칙이 설정되어 있어서 컴포넌트 인식이 안되는 문제가 발생했다.

<VStage :config="containerConfig">
    <VLayer>
        <VText :config="{ text: 'temp', fontSize: 15 }" />
    </VLayer>
</VStage>

[Vue warn]: Failed to resolve component: VStage If this is a native custom element, make sure to exclude it from component resolution via compilerOptions.isCustomElement. at <PaybackChallenge onVnodeUnmounted=fn<onVnodeUnmounted> ref=Ref< null > > at <RouterView > at <AppLayout onVnodeUnmounted=fn<onVnodeUnmounted> ref=Ref< Proxy(Object) {__v_skip: true} > > at <RouterView > at <App>

[ 해결 ]

main.ts에 VueKonva를 등록할 때 prefix를 변경해주면 된다.

import VueKonva from 'vue-konva'

// 생략

app.use(VueKonva, { prefix: 'V' })
app.mount('#app')

[CS] CI/CD

스응 — Wed, 27 Nov 2024 23:30:11 +0900

CI/CD

- 코드를 지속적으로 통합, 테스트, 배포하는 프로세스를 자동화하는 프로세스

- CI (Continuous Integration)

· 코드 변경 사항을 주기적으로 중앙 저장소에 통합

→ 병합 충돌 최소화

· 자동 빌드 및 단위 테스트 수행

· 문제를 빠르게 식별하고 수정할 수 있음

- CD (Continuous Delivery)

· 코드를 항상 배포 가능한 상태로 유지

· 빌드 후에 모든 코드 변경 사항을 운영 환경에 자동으로 배포

CI/CD 파이프라인

1. 코드 푸시 (Push)

: 개발자가 변경 사항을 버전 관리 시스템(Git 등)에 Push함

2. 빌드 (Build)

: 코드를 컴파일하고 의존성을 설치한 후, 실행 가능한 애플리케이션 생성

3. 테스트 (Test)

: 자동화된 테스트 수행

4. 배포 (Deploy)

: 테스트를 통과한 코드를 스테이징(테스트 환경) or 운영 환경에 배포

※ 파이프라인

: 소프트웨어 개발/배포 과정에서 자동화된 작업이 순차적으로 진행되는 일련의 흐름

CI/CD 구성 요소

1) 버전 관리 시스템 (VCS)

· GitBub, GitLab, Bitbucket 등

2) CI/CD 도구

· Jenkins, GitHub Actions, CircleCI, Travis CI, Azure DevOps 등

3) 테스트 프레임워크

· Jest, Mocha, PHPUnit, xUnit 등

4) 배포 도구

· Docker, Kubernetes, AWS CodeDeploy, Terraform 등

[CS] 해시 알고리즘 (Hash Algorithm)

스응 — Tue, 26 Nov 2024 18:56:37 +0900

해시 알고리즘

- 임의의 길이를 가진 입력 값을 고정된 길이의 해시 값 또는 해시 코드로 변환하는 함수
- 결과 값의 길이가 고정되어 있음
- 해시 값은 입력 값에 대해 고유 식별자 역할을 함
※ 단, 충돌 가능성이 존재하기 때문에 완벽한 고유성을 보장하지 않으나, 이러한 충돌이 발생한 확률은 매우 낮도록 설계됨
- 일방향성 (One-way Property)
: 해시 값을 통해 원 입력 값을 역으로 추론하는 것이 거의 불가능함
- 계산 속도 빠름

MD5 (Message Digest 5)

- 길이 : 128비트
- SHA에 비해 충돌 공격에 취약함
→ 현재는 보안에 민감한 애플리케이션에 사용하지 않음
※ 충돌 공격
: 두 개의 서로 다른 입력 값이 같은 해시 값을 만들어 내는 공격
- 길이 : 128비트

SHA (Secure Hash Algorithm)

i. SHA-1
· 길이 : 160비트
· 보안성이 약화되어 더 이상 권장되지 않음
ii. SHA-2
· 현재 가장 널리 사용됨
· SHA-256 : 256비트 / 블록체인 및 보안 인증서에서 많이 사용됨
· SHA-512 : 512비트 / 데이터 저장 시 높은 보안성이 요구될 때 사용됨
iii. SHA-3
· 가장 최신 버전
· 강력한 충돌 저항성과 보안성 제공

bcrypt

- 비밀번호 저장에 특화된 해싱 함수
- 기존 시스템과의 호환성이 뛰어남
- CPU 공격 방어
- 고유한 랜덤 데이터(Salt)를 추가하여, 동일한 비밀번호라도 다른 해시 값을 생성함

→ 레인보우 테이블 공격 방어

: 해시 값을 역추적하여 원래의 입력 값을 알아내는 것

- 슬로우 해싱 (Slow Hashing)

: 의도적으로 연산을 느리게 만듦

→ 공격자가 대량의 해시를 빠르게 계산하지 못하도록 함

- 비용 인자 설정 가능

: 하드웨어 성능이 개선되더라도, 해싱 과정을 의도적으로 느리게 만들 수 있음

→ 브루트 포스 공격 방어

: 가능한 모든 입력 값을 하나씩 대입하여 비밀번호를 찾아내는 것

scrypt

- 비밀번호 저장에 특화된 해싱 함수
- 병렬 공격 방어
- bcrypt에 비해 보안성이 높음
- GPU/ASIC 공격 방어

[CS] 웹 보안(Web Security)과 주요 취약점

스응 — Mon, 25 Nov 2024 00:04:42 +0900

핵심 보안 원칙

1) 기밀성 (Confidentiality)

- 민감한 데이터가 인가되지 않은 사용자에게 노출되지 않도록 보호

ex) 암호화된 통신(SSL/TLS)을 사용해 데이터 전송 보호

2) 무결성 (Integrity)

- 데이터가 전송 중 손상/변경되지 않도록 보장

ex) 데이터 해시 및 디지털 서명 활용

3) 가용성 (Availability)

- 서비스가 항상 정상적으로 사용 가능하도록 보장

ex) DDoS 방어와 서버 장애 대비

HTTPS의 중요성

1) 웹사이트의 무결성 보호

- 침입자가 웹사이트와 사용자 간의 통신을 암호화함

→ 침입자가 조작하지 못하도록 방지함

- 악의적인 공격자 또는 불법적인 광고 삽입을 차단함

2) 사용자의 개인 정보 보호

- 웹사이트와 사용자 간의 통신을 암호화하여, 사용자의 개인 정보나 활동이 노출되지 않도록 보호함

(HTTP 요청인 경우 사용자의 활동 정보를 쉽게 추적할 수 있음)

3) SEO 점수 향상

- 검색 엔진은 HTTPS를 사용하는 웹사이트를 우선시함

→ HTTPS를 사용하면 검색 결과에서 더 높은 순위를 얻을 수 있음

주요 보안 취약점

1) Zero-day

- 취약점이 공개되기 전에, 공격자가 이를 발견하여 악용하는 공격

- 보안 패치가 발표되기 전까지 방어하기 어려움

- 악성코드나 해킹 도구를 사용해 시스템에 침입하거나 데이터를 탈취함

2) Vulnerable packages (취약한 패키지)

- 외부 패키지/라이브러리가 보안 취약점을 내포하고 있을 때 발생하는 위험

- 패치가 늦어지면 시스템 전체에 영향을 미칠 수 있음

3) XSS (Cross Site Scripting)

- 웹사이트에 악성 스크립트를 삽입하여, 사용자의 브라우저에서 실행시키는 공격

→ 사용자의 브라우저에서 공격자가 원하는 작업을 수행할 수 있게 됨

- 사용자 세션 탈취

- 클릭을 유도하여 악성 사이트로 유도

4) SQL Injection (SQL 삽입)

- 사용자의 입력값을 필터링하지 않고 SQL 쿼리에 직접 포함시킬 경우 발생하는 공격

- 공격자가 쿼리를 변조해 DB의 민감한 데이터를 유출/삭제할 수 있음

- 이를 방지하기 위해, 반드시 파라미터화된 쿼리나 바인딩된 변수를 사용해야 함

-- 예시
SELECT * 
FROM MEMBER 
WHERE ID = @ID

-- 여기서 @ID를 필터링하지 않고 문자열로 그대로 받을 경우
-- "123; DELETE FROM MEMBER" 와 같은 형태의 문자열이 들어가게 되면

SELECT *
FROM MEMBER
WHERE ID = 123; DELETE FROM MEMBER

-- 와 같은 쿼리가 실행되며 MEMBER 테이블의 전체 데이터가 삭제됨

5) Credential Leaks (자격 증명 유출)

- 사용자 인증 정보가 노출/유출되어 계정 탈취 등의 사고가 발생하는 문제

- 비밀번호 또는 API 키가 암호화되지 않거나 잘못된 보안 설정으로 인해 유출되는 경우

6) PoLP (최소 권한 원칙, Principle of Least Privilege)

- 사용자가 시스템에서 수행할 수 있는 작업의 범위를 최소화하여 권한을 설정하는 보안 원칙

- 공격자가 침입하더라도 피해를 최소화할 수 있음

7) DDoS (분산 서비스 거부 공격, Distributed Denial of Service)

- 여러 대의 시스템을 이용해 특정 서버/네트워크를 과부하 상태로 만들어 서비스를 방해하는 공격

- 대량의 트래픽을 발생시킴

→ 서버의 리소스를 고갈시켜 서비스가 중단되도록 함

※ DoS (서비스 거부 공격, Denial of Service)

- 네트워크/시스템의 가용성을 방해하는 공격 유형

- 서비스의 정상적인 동작을 방해하여 시스템을 과부하/차단시키려는 시도

- 단일 시스템의 공격 → DDoS에 비해 출처를 탐지하고 방어하기가 훨씬 쉬움

[CS] 캐싱 유형

스응 — Sun, 24 Nov 2024 18:56:31 +0900

캐싱 유형

1) 클라이언트 측 캐싱 (Client-side Caching)

- 저장 위치 : 사용자의 기기 (브라우저, 앱, ...)

- 이미 로드한 정적 리소스를 저장하여, 재요청 시 로딩 속도를 개선함

- 주로 브라우저 캐시를 통해 이뤄짐

: HTTP 헤더로 캐싱 정책 설정 ex) Cache-Control, Expires, ...

- 네트워크 요청 없이 오프라인 액세스를 지원할 수 있음

[장점]

· 서버에 대한 요청량 감소 → 서버의 부하 감소

· 데이터가 로컬에 있어 즉시 제공 가능 → 응답 속도 빠름

[단점]

· 저장 용량이 제한적임

· 최신 데이터를 가져오려면 캐시를 삭제해야 함

2) 서버 측 캐싱 (Server-side Caching)

- 저장 위치 : 서버 내 메모리/디스크 또는 별도의 캐시 서버(Redis, Memcached 등)

- 서버에서 데이터를 준비하는 과정에서 캐싱을 사용함

: 반복된 요청에 대해 동일한 응답을 일일이 생성하지 않고, 미리 계산된 데이터를 제공함

- 주로 동적 데이터를 캐싱함 (API 응답, 렌더링 결과 등)

[장점]

· DB/서버의 부하 감소

· 복잡한 계산이나 데이터 처리 시간을 줄임

[단점]

· 캐싱 무효화 정책을 잘못 설정하면 최신 데이터와 다른 데이터를 제공할 수 있음

· 캐시 저장소를 위한 추가적인 비용이 발생할 수 있음

3) CDN Caching

- 저장 위치 : 전 세계에 분산된 CDN 서버

- 정적 리소스를 사용자와 가까운 위치에 저장하여 제공함

- HTTP 헤더로 캐싱 정책 설정

[장점]

· 글로벌 성능 향상

: 사용자가 자신과 가까운 CDN 서버로부터 콘텐츠를 받음 → 응답 속도 빠름

· 정적 리소스 요청이 CDN에서 처리됨 → 서버 부하 감소

· 자동 확장 지원 → 트래픽이 급증하더라도 안정적임

[단점]

· 비용 증가

· 동적 데이터를 캐싱하는 데에는 적합하지 않음

※ CDN (Content Delivery Network)

- 콘텐츠를 사용자에게 더 빠르고 효율적으로 제공하기 위해 전 세계에 분산된 서버 네트워크

- 콘텐츠 캐싱

- 트래픽 분산

: 특정 서버로의 트래픽 집중을 방지하고, 여러 서버로 요청을 분배함

- 콘텐츠를 원본 서버가 아닌, 사용자와 가까운 엣지 서버(Edge Server)에서 제공함

- DDoS 방어 및 웹 애플리케이션 방화벽(WAF) 기능을 제공함

캐싱 정책을 설정하는 HTTP 헤더

# Cache-Control

- 현대 HTTP 캐싱의 핵심 헤더

[주요 지시자]

i. max-age

: 콘텐츠를 캐싱할 최대 시간 (초 단위)

Cache-Control: max-age=3600 // 3600초 (1시간) 동안 캐싱

ii. no-cache

: 캐싱된 데이터가 있어도 서버에서 유효성을 확인한 후 사용함

Cache-Control: no-cache

iii. no-store
: 데이터를 절대 캐싱하지 않음

Cache-Control: no-store

iv. must-revalidate

: 캐시된 콘텐츠가 만료된 경우, 클라이언트가 반드시 서버에 유효성 검사를 요청하도록 강제함

Cache-Control: public, max-age=3600, must-revalidate

v. public

: 모든 클라이언트와 프록시에서 캐싱 허용

Cache-Control: public, max-age=86400

vi. private

: 특정 사용자만 캐싱 가능

Cache-Control: private, max-age=3600

# Expires

- 특정 시점 이후 캐싱된 콘텐츠가 만료되었음을 알림

- HTTP/1.0에서 사용되었으며, 현재는 Cache-Control의 max-age로 대체됨

// 2024년 11월 21일 12시 이후에는 콘텐츠를 새로 가져와야 함
Expires: Wed, 21 Nov 2024 12:00:00 GMT

# Vary

- 서버 응답이 요청 헤더의 값에 따라 다를 수 있음을 알림

// 클라이언트의 언어에 따라 다른 데이터를 캐싱함
Vary: Accept-Language

# Pragma

- HTTP/1.0에서 사용되었으며, 현재는 Cache-Control로 대체됨

Pragma: no-cache

[CS] 백엔드 개발자 로드맵 따라가기 (진행중)

스응 — Sat, 23 Nov 2024 18:19:03 +0900

백엔드 개발자 로드맵 링크

- https://roadmap.sh/backend

Backend Developer Roadmap: What is Backend Development?

Learn what backend development is, what backend developers do and how to become one using our community-driven roadmap.

roadmap.sh

1. 인터넷 (Internet)

- 정의 & 인터넷 주소 체계 & DNS 작동 방식 : https://young0105.tistory.com/383
- HTTP/HTTPS : https://young0105.tistory.com/146
- 웹 : https://young0105.tistory.com/147
- 호스팅 : https://young0105.tistory.com/384
- 브라우저 : https://young0105.tistory.com/385

2. 버전 관리 시스템 (Version Control Systems, Git)

- https://young0105.tistory.com/50

3. API

- https://young0105.tistory.com/386

4. 인증 (Authentication)

- 정의 & 인증 전략 : https://young0105.tistory.com/387
- 쿠키 & 세션 : https://young0105.tistory.com/160

5. 캐싱 (Caching)

- 정의 & 캐싱 전략 : https://young0105.tistory.com/388
- 캐싱 유형 : https://young0105.tistory.com/391

6. 웹 보안 (Web Security)

- 보안 원칙 & 주요 취약점 : https://young0105.tistory.com/392
- 해시 알고리즘 : https://young0105.tistory.com/393

7. 테스팅 (Testing)

8. CI/CD

- https://young0105.tistory.com/394

[C#/dotnet] 권한 부여 (Authorize)

스응 — Fri, 22 Nov 2024 17:18:40 +0900

참조

- https://learn.microsoft.com/ko-kr/aspnet/core/security/authorization/simple?view=aspnetcore-8.0

[Authorize] 어트리뷰트

- 대상에 대한 액세스를 인증된 사용자만 가능하도록 제한하는 어트리뷰트

- 인증되지 않은 사용자가 접근하는 경우 → 401 Unauthorized 반환

- 인증되었지만, 권한이 없는 사용자가 접근하는 경우 → 403 Forbidden 반환

# 컨트롤러에 대한 액세스를 인증된 사용자로 제한하기

// AccountController 내부의 Login(), Logout() 둘 다 인증된 사용자만 액세스 가능
[Authorize]
public class AccountController : Controller
{
    public ActionResult Login()
    {
    }

    public ActionResult Logout()
    {
    }
}

# 개별 메서드에 대한 액세스를 인증된 사용자로 제한하기

public class AccountController : Controller
{
    // Login()은 모든 사용자가 액세스 가능
   public ActionResult Login()
   {
   }

    // Logout()은 인증된 사용자만 액세스 가능
   [Authorize]
   public ActionResult Logout()
   {
   }
}

# 대상에 대한 액세스를 특정 역할을 가진 인증된 사용자로 제한하기

// "Admin" 역할을 가진 인증된 사용자만 액세스 가능
[Authorize(Roles = "Admin")]

// "Admin" 또는 "Manager" 역할을 가진 인증된 사용자만 액세스 가능
[Authorize(Roles = "Admin,Manager")]

# 특정 정책에 따라 제한하기

// 정책 정의 (Program.cs)
services.AddAuthorization(options =>
{
    options.AddPolicy("MinimumAge", policy =>
        policy.RequireClaim("Age", "18"));
});

---------

// 해당 정책 내 조건을 만족하는 인증된 사용자만 액세스 가능
[Authorize(Policy = "MinimumAge")]

[AllowAnonymous] 어트리뷰트

- 인증되지 않은 사용자의 액세스를 허용하는 어트리뷰트

- [Authorize]를 무시함

: 컨트롤러에 [Authorize], 특정 메서드에 [AllowAnonymous]가 적용되어 있는 경우, 해당 메서드는 모든 사용자가 액세스 가능

[Authorize]
public class AccountController : Controller
{
    // Login()은 모든 사용자가 액세스 가능
    [AllowAnonymous] 
    public ActionResult Login()
    {
    }

    // Logout()은 인증된 사용자만 액세스 가능
    public ActionResult Logout()
    {
    }
}

[CS] 캐싱 전략

스응 — Thu, 21 Nov 2024 23:33:48 +0900

캐싱 (Caching)

- 자주 사용하는 데이터를 미리 저장해 두고, 필요할 때 빠르게 가져와서 사용하는 기술

[장점]

i. (적절하게 사용할 경우) 성능 향상

ii. 리소스 절약

: 네트워크 트래픽 감소 & 데이터베이스 부하 감소

iii. 지연 시간 응답 → 사용자 경험 개선

[고려사항]

i. 캐시된 데이터와 원본 데이터 간 불일치가 발생할 수 있음

ii. 유효성 관리 방법

· TTL로 데이터 갱신 or 수동으로 캐시 무효화

iii. 불필요한 캐싱은 메모리 낭비로 이어질 수 있음

iv. 캐싱 처리를 하는 게 적합한 상황인지 판단해야 함

· 읽기 작업이 많은 경우 캐싱이 유용함

· 쓰기 작업이 많은 경우 일관성 문제가 생길 가능성이 높음

캐싱 전략

# Write-Through 캐싱

- 데이터를 캐시에 쓰는 동시에, 원본 저장소(DB)에도 즉시 기록함

- 추천 대상 : 실시간 데이터 일관성이 중요한 경우

[장점]

· 캐시에 항상 최신 데이터가 유지됨 → 데이터 일관성 보장

[단점]

· 쓰기 작업 시 속도가 느릴 수 있음

# Write-Back 캐싱

- 데이터를 캐시에 쓰고, 원본 저장소에는 특정 조건일 때에만 기록함

ex) 캐시 만료, 시스템 종료 등

- 추천 대상 : 데이터 변경 빈도가 높고, 일관성이 덜 중요한 경우

[장점]

· 쓰기 작업이 빠름

· 원본 저장소 접근 횟수 감소 → 부하 감소

[단점]

· 캐시 손상 시 데이터가 유실될 수 있음

# Read-Through 캐싱

- 데이터 요청 시 캐시를 먼저 확인하고, 캐시에 없으면 원본 저장소에서 데이터를 먼저 가져와 캐시에 저장함

- 추천 대상 : 읽기 작업이 빈번한 경우

[장점]

· 자주 조회되는 데이터인 경우 빠른 응답 가능

· 캐시에 없는 데이터만 원본에서 가져오기 때문에 효율적임

[단점]

· 캐시에 없을 경우 초기 요청이 느릴 수 있음

# Lazy-Loading 캐싱

- 데이터를 요청할 때에만 캐시에 저장함

- 추천 대상 : 요청이 간헐적으로 발생하는 경우

[장점]

· 초기 캐시 로드 시간이 필요 없음

· 필요한 데이터만 캐싱 처리 → 메모리 효율 UP

[단점]

· 해당 데이터를 처음으로 요청하는 경우 응답이 느릴 수 있음

· 자주 사용되지 않는 데이터는 캐싱되지 않음

# Time-to-Live (TTL)

- 캐시된 데이터의 유효 기간을 설정하여, 일정 시간이 지나면 무효화시킴

- 실시간 데이터가 필요 없는 경우

[장점]

· 오래된 데이터를 자동으로 갱신할 수 있음

· 메모리 관리 용이

[단점]

· 유효 기간을 적절하게 설정하지 않는 경우 문제가 생길 수 있음

- TTL이 너무 짧을 때 : 갱신 빈도 증가 → 원본 저장소 부담

- TTL이 너무 길 때 : 캐시된 데이터와 원본 데이터 간 불일치 가능성

# LRU (Least Recently Used)

- 가장 오래 사용되지 않은 캐시 데이터를 삭제함

# LFU (Least Frequently Used)

- 가장 적게 사용된 캐시 데이터를 삭제함