1.한글 Path Parameter가 WAF/프록시에서 400을 일으키는 이유

1) 경로 파라미터 방식은 왜 위험 요소로 취급될까?

경로(path segment)에 한글이나 특수 문자가 포함된 URL은 보안 로드밸런서/WAF등 입장에서 “위험 요청”으로 간주되기 쉽습니다. 예를 들어 다음 요청을 보겠습니다.

GET /community/search/오

사람이 보기엔 아무 문제 없어 보이지만, 네트워크 장비나 WAF는 ‘비 ASCII 문자’ 가 들어간 경로 자체를 의심하는 경우가 많습니다. 마치 택배 주소에 외계어가 끼어 있으면 시스템이 자동으로 스캔하는 것처럼요.

보안 장비들은 보통 아래와 같은 패턴에 민감하게 반응합니다.

1. URL 경로에 비정상적인 문자 포함

2. 퍼센트 인코딩이 제대로 되지 않은 상태로 전달된 요청

3. 세그먼트가 비정상적으로 짧거나 길 때

4. 한글·일본어·중국어가 포함된 경우 (일부 구형 장비에서 오탐 발생)

즉, 개발 서버는 멀쩡한데, 서버 앞단의 WAF/LB가 먼저 400을 던져 버리는 구조입니다.

2) 퍼센트 인코딩이 안 되어 있으면 더욱 문제가 커진다

브라우저와 HTTP 표준에서는 한글 path segment를 반드시 퍼센트 인코딩 해야 합니다.

예: 오 → %EC%98%A4

따라서 아래 요청이 맞는 형식입니다.

GET https://서버/community/search/%EC%98%A4

하지만 많은 프록시나 WAF는 퍼센트 인코딩 되어 있어도 경로에 인코딩 문자열이 들어간 것을 위험하다고 판단해 요청 자체를 차단하기도 합니다. 특히 AWS WAF, Cloudflare 일부 룰, F5 ASM 등에서 이런 일이 자주 발생합니다.

3) 쿼리 방식은 왜 안전한가?

같은 요청이라도 다음처럼 쿼리 파라미터로 보내면 대부분의 보안 장비가 허용합니다.

GET https://서버주소/community?search=오

또는 퍼센트 인코딩 버전:

GET https://서버주소/community?search=%EC%98%A4

쿼리는 검색 조건·필터링에서 흔히 쓰이기 때문에, 보안 장비들도 기본적으로 “정상 요청”으로 간주합니다.

2. JS 기반 서버 기준 쿼리 방식이 가장 올바른 해결책인 이유

1) 이미 컨트롤러에서 쿼리 방식이 준비되어 있다

작성된 NestJS 컨트롤러에는 이미 다음 메서드가 존재합니다.

@Get()
async listBoard(@Query() dto: SearchBoardRequestDto): Promise<SearchBoardResponseDto> {
  return this.communityService.searchBoard(dto);
}

즉, 서버에서 쿼리 방식 호출을 기본으로 지원하고 있습니다.

이를 클라이언트에서 이렇게 호출할 수 있습니다:

GET https://api.ieg-lab.com/community?search=오

페이지네이션도 가능:

GET https://api.ieg-lab.com/community?search=오&skip=0&take=10

이 방식은 path segment에 민감한 WAF에서 훨씬 안전하게 통과합니다.

2) Postman으로 아래 두 가지를 비교 테스트해보세요

GET https://api.ieg-lab.com/community?search=오

GET https://api.ieg-lab.com/community?search=%EC%98%A4

➜ 1번이 정상 동작하면?

프론트에서도 반드시 쿼리 방식으로 전환해야 합니다.

➜ 둘 다 막힌다면?

그건 WAF 정책 문제이므로 로드밸런서·보안팀 로그를 확인해야 합니다.

3. (선택) 그래도 /community/search/오 같은 Path 방식을 유지하고 싶다면

1) 퍼센트 인코딩된 URL을 사용하시면 됩니다.

https://api.ieg-lab.com/community/search/%EC%98%A4

4. 프론트엔드에서는 어떻게 수정해야 할까?

❌ 기존(문제 발생 가능) fetch(/community/search/${searchKeyword});

✅ 수정(완전 안전) fetch(/community?search=${encodeURIComponent(searchKeyword)});

이 방식은:

보안 장비에서 막히지 않고

한글·특수문자·이모지 모두 정상 처리가 되며

JS DTO 기반의 Query Validation과도 자연스럽게 연동이 됩니다.

마무리

이번 글에서는 400 Bad Request가 서버 로직 문제가 아닌, WAF·프록시·로드밸런서 등 네트워크 보안 계층에서 발생하는 경우에 대해 자세히 설명했습니다. 특히 한글이 포함된 path parameter가 보안 장비에서 차단되는 사례가 매우 흔하다는 점, 그리고 이를 해결하는 가장 안전한 방식은 쿼리 방식(?search=...)으로 전환하는 것임을 확인했습니다.

NestJS에서도 이미 쿼리 방식을 지원하고 있으므로, 프론트에서도 encodeURIComponent를 사용해 쿼리 파라미터로 보내면 문제 없이 검색 기능을 안정적으로 운영할 수 있습니다.! 감사합니다!

그래서 직접 만들었습니다. (아래 링크) https://main.d3kod2wksckcvr.amplifyapp.com/

프로젝트 핵심 목적

“모든 주요 개발/디자인 툴의 단축키를 Windows / macOS 완전 분리 + 통합 데이터 구조로 제공하는 프로젝트”

이 프로젝트는 단순 정리 문서가 아니라, 웹 / 앱 / 서비스에 바로 연동 가능한 실사용 데이터셋입니다.

지원 툴

• VS Code
• IntelliJ
• Figma
• Photoshop
• Illustrator
• Premiere Pro

모든 툴이 아래와 같은 통일된 구조를 가집니다.

즉,

✅ Windows / macOS 완전 분리

✅ 실무에서 실제로 쓰는 단축키만 정리

앞으로 추가 예정

After Effects

Affinity Photo & Designer

Final Cut Pro

이 프로젝트를 통해 얻고 싶은 것

개발자/디자이너의 툴 학습 비용 감소

작업 속도 향상

단축키 기반 UX 실험

실제 프로덕트로의 확장

🚀 이 프로젝트는 계속 확장 중입니다. 피드백, 개선 제안, 협업 모두 환영합니다.!

회사에 들어와서 mac을 처음 사용해보니 여태것 window만 쓰다가 mac을 쓰려니 사소한 단축키 부터, 설치나 환경변수 설정 까지 처음하다보니 낯설게 느껴지기도 하지만 특유의 mac ui가 맘에 들어 만족 중입니다!

암튼

DBeaver를 사용해서 maria db를 연결 하려고 하니 위에 사진과 같은 오류가 계속해서 발생하고 있었습니다..

gpt : 권환문제(대에충 해결 할 수 있어보이는 명령어 제공), 구글링 : 권환문제(오류 원인과 나와같은 오류들을 대응 했던 사람들의 블로그 제공)

이런문제들은 gpt보다 구글링을 통해 블로그를 보면서 해결하는게 좋다고 생각하는 저의 자칭 빅데이터를 기반으로 다른 블로그를 참고하여 이 오류를 해결해 보겠습니다.

https://stackoverflow.com/questions/62231627/access-denied-for-user-rootlocalhost-in-dbeaver 역시 스택오버플로우를 보니 저와 같은 오류를 발견한 사람이 있었습니다.. . . . 아 다른 경우네요.. 더 찾아보니 https://wakestand.tistory.com/495 제가 발생한 오류와 완전히 비슷한 오류를 발견 하였습니다!

아 역시 mariadb 자체 권환 문제인가 싶어서, mariadb는 workbanch가 따로 없으니 cli를 통해 쿼리문을 작성하여 권환을 주려고 하였습니다!

하지만 제가 어떠한 명령어를 사용해도 먹히지 않았습니다..

https://dbeaver.com/docs/dbeaver/Database-driver-MariaDB/#mariadb-connection-settings 공식 페이지 인데 이글도 참고!!

삽질 끝에...

결국에는 기존에 maria db 를 밀고 다시 다운로드 하였습니다.. 많은 블로그를 보니 다들 그렇게 하시더라구요...

암튼 정상적으로 maria db 와 연결되어

이렇게 사용할 수 있게 되었습니다!!

GitHub 인증 flow 연결하기

처음엔 GitHub 클라이언트 ID를 발급받고, 아래와 같은 URL로 리디렉션되도록 구성했다.

밑에 url 코드는 내가 개발하고 있는 gitmago 서비스의 github 연동 url 이다.

https://github.com/login/oauth/authorize?client_id=Ov23liG2nzd77CtuJ9cZ&redirect_uri=https://www.gitmago.com/auth/github/callback&scope=read:user

연동을 시도하면 자동으로 auth/github/callback 엔드포인트로 이동되는데, 서버 코드에는 아직 access token을 처리하는 로직이 빠져있었다. 따라서 다음과 같이 코드를 받아 처리하는 로직을 추가했다.

.

@GetMapping("/auth/github/callback")
public ResponseEntity<?> githubCallback(@RequestParam("code") String code) {
    // code를 받아 access token 발급 로직 처리
}

#### 위에 로직처럼 get 매서드를 통해 code를 파라미터로 받아 함수 안에서 처리 할 수 있게 구성 되어있음

처음에는 여기까지 아무 문제 없이 잘 작동하는 것처럼 보였다.

문제 발생... 서버에서만 인증 실패?

하지만 실제 배포 환경에서 테스트해보니 인증이 제대로 되지 않았다. 클라이언트 ID도 정확하고, redirect URI도 맞게 설정되어 있었는데 말이다.

로컬에서는 모든 게 정상 작동하는데, 서버만 문제라니... 의심 가는 부분이 생기기 시작했다.

원인은 이미지였다... Docker에서 깨졌던 build

결국 문제의 원인은 이미지 빌드 과정에서 어노테이션이 누락되었기 때문이었다. 로컬에서는 개발 서버에서 직접 빌드하고 바로 띄우니까 문제가 없었지만, Docker 이미지로 빌드해서 ECR → ECS에 배포하는 과정에서 어노테이션을 포함한 클래스가 누락되었던 것이다.

다시 말해, 다음과 같이 어노테이션이 제대로 붙은 클래스를 포함시키지 못하고 있었다.

@RequestParam("code") // ← 이 어노테이션!

. 이를 수정한 후 이미지를 다시 빌드하고 ECR에 푸시한 뒤 ECS에 재배포하자, 문제는 깔끔하게 해결되었다.

회고

OAuth 연동은 비교적 간단한 작업이라고 생각했는데, 배포 환경에서는 예상치 못한 오류가 나올 수 있다는 걸 다시 한 번 느꼈다. 특히 어노테이션 누락이나 빌드 환경의 차이로 인해 발생하는 이슈는 디버깅이 꽤 까다로울 수 있다.

앞으로는 Docker 빌드 시 누락되는 클래스나 어노테이션이 없는지 꼼꼼하게 체크해야겠다.!

Git 사용, 아직도 어렵게 느껴지시나요?
Git을 사용하면서 충돌과 관련된 고민을 단숨에 해결해 줄 GitKraken 입니다. 깔끔한 UI와 편리한 기능으로 Git 관리와 프로젝트 작업이 정말 쉬워질 겁니다.

GitKraken이란?

GitKraken은 Git GUI 클라이언트로, 말 그대로 Git 작업을 훨씬 간단하고 직관적으로 만들어줍니다.
복잡한 명령어 대신 화면을 실시간으로 보면서 작업할 수 있는게 큰 메리트라고 할수 있습니다.
맨 오른쪽에 default Profile 이라고 뜨는데 계정과 연결이 되지 않아서 맨 오른쪽 처럼 뜹니다. 하단의 Interation 에 github를 클릭한후 계정과 연결하면 뜹니다.

GitKraken 설치와 기본 설정

설치 방법

1. GitKraken 공식 웹사이트에 접속해 주세요.
2. 사용하는 운영체제에 맞는 설치 파일을 다운로드하고 실행합니다.
3. 간단한 설정 과정을 거치면 됩니다.

초기 설정

초반에 깃헙 계정을 연동 할때 SSL로 연동을 하였는데 오류가 굉장히 많이 났었다.

GitKraken을 사용하고 좋은 점

마무리하며

소스트리? 형식의 프로그램을 처음 사용하였는데 사용하고 나니 한눈에 코드 수정 사항을 보게 되어 좋았던것 같습니다. 또한 gitkraken은 커밋이나 PR시 바로 변경 사항이 반영되어 편리 했던것 같습니다

SLF4J(W): No SLF4J providers were found.
SLF4J(W): Defaulting to no-operation (NOP) logger implementation
SLF4J(W): See https://www.slf4j.org/codes.html#noProviders for further details.

라는 에러줄이 발생됩니다.

해당오류는 바인딩 버전이 맞지 않아 생기는 오류입니다. 의존성 파일이 존재하는 pom.xml이나 buildgradle파일에 들어가서 버전만 변경해주면 되는 오류 입니다.

저는 buildgradle파일에 의존성을 추가 하기때문에 buildgradle에서 변경해 주면 됩니다.

dependencies {
    // Spring Boot Core Dependencies
    implementation 'org.springframework.boot:spring-boot-starter-web'
    implementation 'org.springframework.boot:spring-boot-starter-thymeleaf'
    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
    implementation 'org.springframework.boot:spring-boot-starter-data-mongodb'
    implementation 'org.springframework.boot:spring-boot-starter-security'

    implementation 'jakarta.validation:jakarta.validation-api:3.0.2'
    implementation 'org.hibernate.validator:hibernate-validator:8.0.1.Final'

    implementation 'io.github.cdimascio:java-dotenv:5.3.1'
    implementation 'com.fasterxml.jackson.core:jackson-databind:2.15.2'

    implementation 'org.thymeleaf.extras:thymeleaf-extras-springsecurity6'

    compileOnly 'org.projectlombok:lombok:1.18.30'
    annotationProcessor 'org.projectlombok:lombok:1.18.30'

    developmentOnly 'org.springframework.boot:spring-boot-devtools'

    testImplementation 'org.springframework.boot:spring-boot-starter-test'
    testImplementation 'org.springframework.security:spring-security-test'

    // SLF4J API 추가
    implementation 'org.slf4j:slf4j-api:1.7.9'

    implementation 'ch.qos.logback:logback-classic:1.4.11'
}

주석처리가 되어있는부분에 api:~ 부분이 원래는 api:2.0.0이런식으로 정의되어있었다면 바인딩버전을 맞추기위해 api:1.7.9로 변경하였더니 해당오류가 사라졌습니다.

버전 수정 : 2.0.0 -> 1.7.9 로 변경

재점검 해보기 , 안드로이드스튜디오 기준으로 왼쪽 상단에 줄3개를 클릭하고 1.캐시 초기화 하고 restart 하기

2. Gradle 리프레쉬하기

3.재빌드 하기

이 3가지 방법을 실행 한다면 R클래스를 import 관련 문제를 해결할수있다.

그럼 권환을 주면 해결될 일이다. Add permission check 를 클릭하고 권한을 주고 , 권한을 주게 되면 this 라는 매개변수로 받게되어 또 다른 오류가 생기게 되는데 ,자신이 설정한 매개변수로 값을 바꾸면 된다. 나는 context로 매개변수를 설정하였는데 this를 아래 사진과 같이 context로 바꾸니 오류가 해결됬다.

question , answer 패키지를 아래와 같이 생성해주고

Question.java Answer.java 이름에 자바클래스 파일을 생성 해줍니다.

Answer.java 파일코드

package com.AdA.backend.answer;

import java.time.LocalDateTime;

import org.springframework.data.annotation.CreatedDate;

import com.AdA.backend.question.Question;

import jakarta.persistence.Column;
import jakarta.persistence.Entity;
import jakarta.persistence.GeneratedValue;
import jakarta.persistence.GenerationType;
import jakarta.persistence.Id;
import jakarta.persistence.ManyToOne;

import lombok.Getter;
import lombok.Setter;


@Getter
@Setter
@Entity

public class Answer {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Integer id;

    @Column(columnDefinition = "TEXT")
    private String content;

    @CreatedDate
    private LocalDateTime createDate;

    @ManyToOne
    private Question question;

}

Question.java 파일코드

package com.AdA.backend.question;

import java.time.LocalDateTime;
import java.util.List;

import com.AdA.backend.answer.Answer;

import jakarta.persistence.CascadeType;
import jakarta.persistence.Column;
import jakarta.persistence.Entity;
import jakarta.persistence.GeneratedValue;
import jakarta.persistence.GenerationType;
import jakarta.persistence.Id;
import jakarta.persistence.OneToMany;

import lombok.Getter;
import lombok.Setter;

@Getter
@Setter
@Entity
public class Question {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Integer id;

    @Column(length = 200)
    private String subject;

    @Column(columnDefinition = "TEXT")
    private String content;

    // 필드 이름을 createdDate로 수정
    private LocalDateTime createdDate;

    @OneToMany(mappedBy = "question", cascade = CascadeType.REMOVE)
    private List<Answer> answerList;
}

파일에 그대로 파일에 위와같은 코드를 수정해줍니다. 그러면 실제로 JPA 형식으로 복잡한 SQL 쿼리문 작성없이 DB테이블이 생성된겁니다.

👉왜 JPA를 사용해야될까?

JPA는 반복적인 CRUD SQL을 처리해준다. JPA는 매핑된 관계를 이용해서 SQL을 생성하고 실행하는데, 개발자는 어떤 SQL이 실행될지 생각만하면 되고, 예측도 쉽게 할 수 있고 , 코드의 가독성 및 유지보수의 향상 , 데이터베이스 독립성 , 객체와 데이터베이스간의 매핑 , 자동화 된 데이터베이스 처리 다양한 측면에서 CRUD 작업을 처리하기에 편리 하기 때문에 사용 합니다.

코드를 순차적으로 살펴볼건데

Answer.java, Question.java 클래스 파일에

사용되었던 , JPA 속성을 살펴볼거다. @Getter , @Setter , @Entity 3개의 이노테이션 속성이 클래스 위에 있다.

각각의 어노테이션은 코드의 가독성을 높이고 , 개발자의 반복적인 작업을 줄여주는 데 도움을 준다.

Lombok : @Getter 와 @Setter

간단하게 생각하면 불필요한 코드 작성을 막아준다. 클래스 필드에 대해 자동으로 getter와 setter 매서드를 생성 해준다. Entity_ 어노테이션은 테이블 처럼 취급 할 수 있다.

또한

@Id

primary key(기본키)로 취급

@GeneratedValue

기본키의 값을 어떻게 생성할지를 지정

@ManyToOne

한 엔터티가 여러개의 엔터티와 연결할수있는 일대 다 관계를 말함. 간단하게 외래키단하게 외래키(Foreign Key)를 말한다.

@CreatedDate

생성된 날짜와 시간을 자동으로 생성해주는 속성 (게시판,채팅)에 사용

column(length(=200)

컬럼 200자 내외로 길이 제한을 한다.

@속성의 이름을 지정해주고 private를 작성하고 , 그다음 컬럼에 자료형을 적어주고 컬럼의 명을 작성하면 컬럼이 자동으로 만들어진 것 이다.

@column (추가적인 속성)
private String name; 이런식으로 작성하면 컬럼이 생성된것이다.

👉각각의 클래스를 확인하여 어떠한 컬럼이 만들어졌는지 확인하기

각각의 클래스 jpa 파일을 살펴보면

👉Answer.java

import로 필요한 라이브러리들을 불러와주고, id , content , createtime , question 컬럼 4개를 만들어 주었다.

👉Question.java

마찬가지로 import로 필요한 라이브러리를 불러와준다. id, subject , content , createdDate , answerList 컬럼 5개를 만들어주었다.

이렇게 까지 하면 jpa를 통한 CRUD 구성의 DB 구축이 완료 되었다.

추가적으로 질문 사항이 있으시면 discord : youjininny_ 로 연락주시면 됩니다.

Dependencies 의존성은 아래의 리스트 대로 추가해주시면 됩니다.

코드를 application.properties 파일을 아래와 같이 그대로 복붙해줍니다. spring.application.name=demo 은 폴더명으로 바꿔주고 spring.datasource.url=jdbc:h2:~/adabase 뒤에 adabase은 DB이름을 뜻합니다. adabase하고 싶은 DB이름으로 지정해줍니다.

의존성에 대한 설명을 하면

⭐️ Spring Boot DevTools

자동 재시작이 가능 하다 , spring 안에서 코드에 변경사항이 있을때 , 기존에는 서버를 껐다 켜야되지만 자동으로 변경사항을 반영을 해준다는 이점이 있다.

⭐️ Lombok

lombok 라이브러리를 불러오면 @Getter, @Setter , @Data 같은 어노테이션만 붙이면 , 불필요한 코드들을 줄일수 있다. 그러므로 코드가 짧아지고 깔끔해지며 읽기 편해짐

⭐️ validation

사용자가 입력한 데이터가 올바른지 검사하는 확인함.

⭐️ Spring Data JPA

복잡한 SQL을 손으로 쓰지 않고 , 매서드만 호출하면 SQL을 만들어 준다. 예를 들어 , findByName(String name) 이라는 이름만으로도 이름으로 데이터를 찾을 수 있는 SQL이 형성되서 굳이 SQL Quary문을 작성하지 않아도 됨.

⭐️ H2 Database

연결할 데이터 베이스를 의존성에 추가를 하는 것인데 , 메모리를 통해서 DB를 사용하는것이기 때문에 속도가 매우 빠르고 테스트 하기에 적합하다.(임시데이터를 다룰때 편리함)

⭐️ Thymeleaf

서버 사이드 템플릿 엔진이다(대체로 테스트 할... html 화면 같은거?)

*application.properties 파일 *

spring.application.name=demo

#DATABASE
spring.h2.console.enabled=true
spring.h2.console.path=/h2-console
spring.datasource.url=jdbc:h2:~/adabase
spring.datasource.driverClassName:org.h2.Driver
spring.datasource.username=sa
spring.datasource.password=

#JPA
spring.jpa.properties.hibernate.dialect=org.hibernate.dialect.H2Dialect
spring.jpa.hibernate.ddl-auto=update  
# SQL Debug
spring.jpa.show-sql=true
spring.jpa.properties.hibernate.format_sql=true    입력하세요

C:\Users\user 이름 파일경로로 이동 한 다음 "adabase.mv.db" 라는 이름을 텍스트 파일을 만들어주고 명을 변경해줍니다.

아래와 같이 변경을 해주면 h2데이터베이스가 내 내장 하드드라이브에서 사용되는 DB가 만들어진거고, application.properties 파일을 위와 같이 수정해 줌으로써 연결이 된겁니다.

다음 DemoApplication파일을 우클릭해주고

RUN'DemoApplication.main()'을 실행해주고

이런식으로 consloe에서 아래와 같이 뜨게 되는데 정상적으로 실행된것입니다.

localhost:8080/h2-console을 브라우저 위에 검색해서 들어가시면

이런식으로 접속 콘솔이 뜨게 되면 JDBC URL '/'뒤에 부분을 'adabase' 로 하게 되면 DB에 들어가게 됩니다.

SecurityConfig 클래스에서 UserService빈을 참조하고 있고, UserService 클래스에서 PasswordEncoder빈을 참조하고 있고, PasswordEncoder 빈은 SecurityConfig에서 정의되어있습니다.

결과적으로 SecurityConfig->UserService->SecurityConfig의 순환참조가 발생하였습니다.

해결방법

원래는 SecurutyConfig 클래스에서 불러와진던 PasswordEncoder를 UserSerivce클래스에서 처리하게 코드를 바꾸었습니다.

결론적으로 PasswordEncoder빈 생성위치를 UserService로 이동하여 순환참조를 제거 하였습니다.

메인메모리에서 frequent itemset을 찾는 알고리즘 입니다.

쉽게 이해 하기 위한

주어진 itemset I가 최소 s번 이상 나타난다고 가정해 봅시다. 그러면 itemset I의 부분집합 J는 최소 s번 이상 나타난다는 것을 의미합니다.

다시 말해, 만약 어떤 아이템 I가 최소 s개의 바스켓에 나타나지 않는다면, 즉 자주 등장하지 않는다면, I를 포함하는 어떤 pair도 s번 이상 나타날 수 없습니다.

예를 들어, {B}가 자주 등장하지 않는다면 {B,D}도 자주 등장하지 않습니다. 이는 {B}가 자주 등장하지 않으면 {B,D}와 같은 아이템셋은 전혀 자주 등장하지 않을 것이기 때문입니다.

따라서, 최소 s개의 바스켓이 자주 등장하지 않으면 {B},{BD}와 같은 아이템셋에 대한 탐색은 하지 않습니다. 이는 바로 가지치기를 의미합니다.

첫번째 pass:

첫 번째 패스에서는 각 바스켓을 순차적으로 읽으면서 메인 메모리에서 각 아이템이 몇 번 등장하는지를 셉니다. 이 과정에서는 singleton 아이템셋이 얼마나 자주 등장하는지를 확인합니다. 이때 필요한 메모리는 아이템의 개수만큼이 됩니다.

두번째 pass:

첫 번째 패스에서는 데이터를 다시 처음부터 쭉 읽게 되는데, 이때는 pass1에서 frequent하다고 판단한 아이템들의 쌍에 대해서만 count를 합니다. 즉, pass1에서 자주 등장하는 것으로 확인된 아이템들에 대해서만 pair를 만들어서 그 쌍을 카운트합니다.

메인 메모리 구조는 다음과 같습니다 , pass1에서는 메모리의 상단 영역에 각 개별 아이템의 카운트를 저장합니다. 이때 각 아이템의 카운트를 누적하고, 최소 s번 이상 등장하는 것으로 판단되는 frequent한 아이템들을 사용하여 가능한 모든 pair를 만듭니다. 그리고 이러한 pair의 카운트를 메모리 영역에서 세는 것이 pass2입니다.

빈발하게 나타나는 singleton item 과 pair의 count를 세는 방법

가장 많이 빈발하는 아이템을 찾은 후에는 이러한 빈발 아이템들을 기반으로 빈발 쌍의 후보를 골라냅니다. 이 후보 쌍들은 실제로 빈발한지를 카운트하여 확인하게 됩니다.

A-Priori 알고리즘은 Ck와 Lk를 반복하여 만드는 과정을 말합니다. 여기서 k가 2일 때 가장 많은 메모리가 필요하게 됩니다.

PCY(park-chen-yu) Algorithm

A-priori 유사하지만 다른 점

PCY(Principle of Counting with a Hash Table)는 A-Priori와 유사한 알고리즘이지만, 각각의 아이템 count를 세는 대신에 pair의 count를 세기 위한 해시 테이블을 유지합니다. 이 해시 테이블의 각 버킷은 해당 pair의 해시값을 가지고 있는 pair의 count를 포함하고 있습니다. A-Priori의 pass1에서 사용되지 않는 많은 메인 메모리 문제를 해결하기 위해, PCY에서는 각 pair를 해시하여 count가 s() 이상인지를 확인하는 것을 합니다.

pcy 알고리즘을 사용하였을 때 좋은점

PCY 알고리즘은 A-Priori와 다르게 개별적으로 빈발하는 아이템의 수가 많을 때에도 (2,3)과 (1,9)와 같은 쌍이 선발되지 않을 수 있습니다. PCY 알고리즘에서는 가장 작은 support 수를 지정하고, 쌍으로 묶은 후 해당 쌍의 Total count가 지정한 support 수를 넘지 못할 경우 탈락시킵니다. 즉, PCY 알고리즘은 A-Priori 알고리즘과 달리 개별 아이템의 쌍을 묶고, 최소 support에 미치지 못할 때 탈락한다는 점에서 다릅니다. 이는 PCY 알고리즘의 주된 아이디어라고 볼수 있습니다.

pass 1 메모리 사용량을 줄일수 있다.

• 각각의 버킷은 해당 쌍이 frequent 한지 여부만을 중요시합니다
• 버킷 값이 1이면 해당 버킷은 frequent한 것을 나타내며, 그 bit 값이 0이면 frequent하지 않음을 나타냅니다.

이러한 이유로 A-Priori 알고리즘에서는 버킷의 카운터를 약 32비트로 사용했지만, PCY 알고리즘에서는 1비트만으로도 frequent 여부를 구별할 수 있기 때문에 메모리 사용량을 크게 줄일 수 있습니다.

pass 2 쌍이 두가지 조건을 만족 해야된다.

• (i ,j ) 각각이 frequent 아이템 이어야 하고 ,
• 해당 쌍이 frequent한 버킷으로 해싱되어야 됩니다.

만약에 (i)와 (j)가 frequent하지만 (i,j) 쌍이 frequent 하지 않으면 셀 필요가 없게 됩니다.

메인메모리 구조

중요한건 PCY 알고리즘을 활용한 변형 알고리즘

멀티 스테이지

변형 메모리

pass1에서는 pair의 수를 한 번 적어주고, pass2에서는 i와 j의 값이 모두 frequent한 조건을 만족할 때 실행됩니다. 그러나 이러한 조건을 만족하는 pair가 매우 적기 때문에, 각 버킷이 기여하는 pair의 수가 적어집니다. 결과적으로, 빈발하지 않지만 빈발한 것처럼 보이는 pair의 수를 줄일 수 있습니다.

PCY 알고리즘의 단점은 메모리가 한 번 더 사용된다는 것이지만, 까다로운 조건으로 인해 최종적으로 후보 pair의 수를 줄일 수 있어 더편리하고 효율적 입니다. pass3에서는 3가지 조건을 모두 만족하면 count하게 됩니다.

멀티 해쉬

PCY에서 pass1 단계에서 여러 개의 해시 테이블을 동시에 사용하는 것은 원래 한 개의 해시 테이블만 사용하는 것과는 달리 메모리 사용량을 줄일 수 있는 잠재적인 장점이 있습니다. 그러나 이러한 접근 방식은 리스크도 동반합니다. 해시 테이블이 두 개인 경우, 각 테이블이 담을 수 있는 메모리 크기가 절반으로 줄어들게 됩니다. 그 count들이 minimum support 넘긴다면 , 의미 가없어 더 이상 효과적인 방법이 아니게 됩니다.

Random sampling

Market-Basket 데이터가 매우 큰 경우, 그 중 일부를 랜덤하게 샘플링하여 사용합니다. 예를 들어, 전체 바스켓의 10% 정보만을 랜덤하게 추출하는 것은 단 한 번의 데이터 읽기 과정만으로 이루어지므로 1-pass 알고리즘으로 간주됩니다.

첫 번째로는 바스켓을 위한 샘플들이 포함되고, 두 번째로는 카운트를 위한 메모리가 할당됩니다. 그러나 바스켓 샘플이 매우 작기 때문에 모든 것이 메모리에 쉽게 저장될 수 있습니다. 여기서 주의해야 할 점은 원래의 minimum support가 있었지만 이제 샘플링을 하였으므로, 샘플 크기에 맞게 minimum support를 조정해야 한다는 것입니다. 예를 들어, 전체 데이터에서는 20번 이상 나타나야 하는데, 1/4의 데이터만 사용한다면 5번 이상 나타나면 충분합니다.

그러나 이러한 Random sampling은 전체 데이터가 아닌 일부 데이터만 샘플링되었기 때문에 오류가 발생할 가능성이 있습니다. 이는 주요한 리스크 요인 중 하나입니다.

Random sampling 의 단점 일부 데이터만 샘플링 했기 때문에 오류가 생기게 됩니다.

False positive

실제로는 빈발하지 않지만 빈발한 것처럼 나타나는 아이템을 발견한 후, 실제로 빈발한지를 확인하기 위해 한 번 더 패스를 실행하여 검증할 수 있습니다. 이를 통해 해당 아이템이 실제로 빈발한지 여부를 확인하고, 필요하다면 제거할 수 있습니다.

False negative

실제로는 빈발한 아이템셋이지만 알고리즘 실행 결과에는 빈발하지 않은 것으로 나타나는 경우가 있습니다. 이는 False positive라고 합니다. False positive의 경우에는 오류를 제거할 수 없는데, 그 이유는 원래 아이템셋이 존재했지만 우연히 랜덤하게 샘플링된 아이템셋이 해당 빈발성을 충분히 포착하지 못할 수 있기 때문입니다.

False negative를 줄이기 위한 한 가지 좋은 방법은 minimum support를 줄이는 것입니다. Minimum support를 줄이면 조금만 나타나도 아이템셋이 빈발한 것처럼 보이기 때문에 오류를 줄일 수 있습니다. 그러나 이렇게 minimum support를 줄이면 frequent한 후보 아이템셋이 많아지므로 메모리 요구량이 늘어날 수 있습니다. 또한, 실제로는 빈발하지 않은데 빈발한 것으로 나타나는 False positive가 증가할 수 있습니다. 이러한 장단점을 고려하여 적절한 선택이 필요합니다.

SON 알고리즘

현재 전체 데이터가 매우 크기 때문에 문제가 발생합니다. 이를 해결하기 위해 전체 데이터를 k개의 chunk로 나누는 방법을 사용할 수 있습니다. 예를 들어, k가 10이라면 전체 데이터를 10개의 조각으로 나눈 후 각각의 조각을 메인 메모리로 읽습니다. 각각의 조각은 메모리에 쉽게 들어갈 정도로 작다고 가정합니다. 그런 다음 메모리에 올려진 각각의 조각에서 알고리즘을 실행하여 모든 frequent itemset을 찾습니다.

원래의 minimum support가 s였다면 이를 k개의 chunk로 나눈 경우에는 minimum support를 k분의 s로 줄여주어야 합니다. 각각의 chunk에서 candidate를 찾은 다음에 한 번 더 pass를 돌려서 전체 바스켓에서 실제로 frequent한 candidate를 확인합니다. 이때, 모든 chunk에서 빈발하지 않았다면 전체적으로 support가 s보다 작아지게 됩니다. 각각의 chunk에서 candidate를 찾은 다음에 한 번 더 pass를 돌려서 전체 바스켓에서 실제로 frequent한 itemset을 찾는 것입니다. 따라서 앞에서 설명한 monotonicity 개념이 여기서 나오게 됩니다. 목표는 전체 n개의 바스켓에서 최소 s번 이상 나온 itemset을 찾는 것인데, 이 n개의 바스켓을 k개의 chunk로 나누었기 때문에 이를 고려하여 minimum support를 조정하고, 각각의 chunk에서 frequent한 candidate를 찾은 다음 전체 바스켓에서 실제로 frequent한 itemset을 찾아내는 것입니다.

이글을 마치며

지금까지 Market Basket Analysis에 대한 알고리즘 및 메모리 구성에 대해 살펴보았습니다.

어떤 고객이 특정 상품을 살 때, 함께 자주 구매되는 다른 상품이 존재하며,
이를 찾아내는 것이 Market‑Basket Model의 핵심입니다.

예시:

“우유를 사는 고객들은 치즈도 함께 사는 경향이 있음”

1. 기본 개념 정리

Support (지지도)

Support는 특정 아이템 집합(Itemset)이 전체 거래 데이터에서 얼마나 자주 나타나는지를 의미합니다.
→ 비율(%) 혹은 횟수로 표현되며, 분석 목적에 따라 기준은 달라질 수 있습니다.

Confidence (신뢰도)

conf(i → j) = support(i ∧ j) / support(i)

• i를 포함하는 거래 중에서, j도 함께 포함된 거래 비율
• 값이 클수록 "i를 구매한 고객이 j도 함께 구매할 확률"이 높다는 뜻입니다.

2. Confidence만으로는 충분하지 않다: Interest의 필요성

문제점

• 어떤 아이템 x를 사면 milk를 산다는 규칙: x → milk
• milk 자체가 자주 구매되기 때문에, 어떤 x든 conf는 높게 나올 수 있음
• 하지만 이는 진짜 연관성이 아닐 수 있음

Interest의 정의

interest(i → j) = conf(i → j) – support(j)

• j의 기본 구매율을 빼면, 진정한 연관성 여부를 파악 가능
• j의 구매율이 낮지만 conf가 높다면 → 높은 interest → 마케팅 인사이트

3. 연관 규칙 예시: j → m 분석

트랜잭션 데이터

• 전체 거래: B1, B2, B3, B4, B5, B6 → 6건
• j가 포함된 거래: B1, B2, B4, B5, B6 → 5건
• j와 m이 모두 포함된 거래: B1, B2, B5 → 3건

계산

conf(j → m) = 3 / 5 = 0.6 support(m) = 3 / 6 = 0.5 interest = 0.6 – 0.5 = 0.1

→ interest = 0.1
→ 단순한 우연이 아니라 상대적으로 유의미한 연관 규칙

4. Frequent Itemset 종류

Maximal Frequent Itemset

• 더 이상 빈발한 superset(상위 집합)이 존재하지 않는 itemset
• 예:
  • {A}, {A,B}는 {A,B,D}라는 superset이 있기 때문에 Maximal 아님
  • {B,C}는 확장 불가 → Maximal

Closed Frequent Itemset

• 같은 support 값을 가진 빈발 superset이 존재하지 않는 itemset
• 예:
  • {A,B,C}가 support 3을 가지고 있고, {A}는 support가 낮다면
    → {A,B,C}는 Closed
  • {B}는 더 큰 Closed frequent itemset에 포함되면 제외

5. 연관 규칙 발견 절차 (Association Rule Mining)

Step 1: Frequent Itemset 탐색

• 최소 support 기준을 만족하는 itemset 먼저 추출

Step 2: 연관 규칙 생성

• i → j 관계에 대해 아래 항목 계산:
  • conf(i → j)
  • interest(i → j)

Step 3: 유의미한 규칙 필터링

• 높은 confidence + 높은 interest 조합이
  → 마케팅적으로 가장 활용 가치 높은 규칙

요약: 연관 규칙 분석의 핵심

• Support: 얼마나 자주 등장하는가?
• Confidence: 함께 등장할 확률은 얼마나 되는가?
• Interest: 진짜 연관성인가, 아니면 단순 인기 아이템인가?

✔️ Confidence와 Interest를 함께 고려하면
→ 실제로 유의미한 상품 연관 규칙을 발굴할 수 있으며,
→ 마케팅, 추천 시스템, 재고 운영 등에 효과적으로 활용 가능합니다.

-이 블로그 내용은 서울대학교 인공지능 학과 청강 데이터마이닝 수업을 기반으로 작성한 블로그 입니다-