미식가의 개발 일기

AWS 핵심 서비스 & IAM Identity Center로 유저 권한 관리

대체불가 핫걸 — Thu, 26 Mar 2026 09:46:18 +0900

AWS란?

Amazon Web Services는 서버, 저장소, 데이터베이스와 같은 IT 인프라를 빌려서 사용할 수 있는 클라우드 플랫폼이다.

핵심 서비스

1. EC2(Elastic Compute Cloud) → 서버

애플리케이션이 돌아가는 가상의 리눅스 서버

2. S3(Simple Storage Service) → 파일 저장소

서버와 분리해서 관리하는 이미지, 영상, 데이터 저장소

3. RDS(Relational Database Service) → 데이터베이스

DB에 데이터 저장 및 관리

4. IAM(Identity and Access Management) → 권한 관리

사용자, 서버 권한 설정

5. VPC(Virtual Private Cloud) → 네트워크

AWS 내에서 생성하는 가상 네트워크 공간

IAM Identity Center로 유저 권한 관리

보안 관점에서 일상적인 작업에 루트 계정을 사용하는 것은 권장되지 않는다. IAM Identity Center를 활용하여 하나의 계정으로 여러 사용자의 권한을 관리할 수 있다. 사용자 또는 그룹으로 묶어 관리할 수 있고, 필요에 따라 커스텀 권한 설정도 가능하다.

IAM Identity Center 접속

활성화

groups → create group

user → add user

권한 관리: 생성한 그룹의 권한을 설정한다.

Dashboard → Manage permissions

aws-accounts → 내 계정 선택 → Assign users or groups

permission 설정할 그룹 선택

permission 타입 설정: aws permission template 중에서도 adminstrator 권한을 가지는 옵션으로 선택했다. 원하는 permission이 있다면 custom도 가능하다

다시 권한 설정 화면으로 돌아가서 group과 permission을 차례로 선택해준다

성공

→ 메일로 온 링크로 접속해서 로그인 정보를 등록해주면 관리자 권한을 가진 계정으로 로그인이 가능하다.

→ IAM Identity Center에서 생성한 계정은 AWS 기본 로그인 페이지에서 접근이 불가하고 Identity Center 포털로 접근해야한다. (AWS IAM Identity Center → AWS access portal URLs)

docker 경로 변경 (현재 docker 경로에 용량이 부족할 때)

대체불가 핫걸 — Wed, 25 Mar 2026 13:04:11 +0900

docker로 개발을 할 때 용량이 부족하여 실행이 불가하거나 프로세스가 중단되는 경우가 있다.
이때 용량이 충분한 경로로 변경해줘야 한다.

멈춰있는 컨테이너, 네트워크, 이미지 등 정리

경로를 변경하기 전, 쓰지 않는 자원 때문에 용량이 부족한 것일수도 있으니 먼저 멈춰있는 자원들을 정리해준다.

	docker system prune

용량 확인

현재 root 디렉토리의 용량은 89%정도 차 있는 상태이고, 쓰지 않는 자원을 정리했음에도 불구하고 여전히 용량이 부족하다. docker 경로 변경이 필요하다.

df -h

현재 경로 확인

	docker info -f '{{ .DockerRootDir }}'

도커 서비스 중단

이동 중 도커가 계속 실행 중이면 데이터의 유실이나 손상이 일어날 수 있으므로 반드시 먼저 모든 도커 서비스를 중단해줘야 한다.

sudo systemctl stop docker
sudo systemctl stop docker.socket

기존 데이터 이동(현재 경로 → 새로운 경로)

앞에서 확인한 현재 경로의 데이터를 새로운 경로로 이동해준다.

sudo mv /var/lib/docker /data

→ ls 명령으로 잘 이동된 것을 확인할 수 있다.

경로 설정

파일을 옮겼으면 도커에게 새로운 경로를 알려줘야 한다. daemon.json 파일에 root 경로를 새로운 경로로 명시해준다.

sudo vi /etc/docker/daemon.json

{
  "data-root": "/data"
}

재실행

sudo systemctl start docker

새로운 경로 확인

docker info -f '{{ .DockerRootDir}}'

→ /data 폴더로 잘 옮겨진 것을 확인할 수 있다.

Docker 개념 정리 및 실무에서 자주 사용하는 명령어

대체불가 핫걸 — Mon, 23 Mar 2026 08:24:54 +0900

도커란?

‘애플리케이션 + 인프라’를 하나로 묶어 어디서든 동일하게 실행되도록 만드는 기술이다.

애플리케이션: 로직이 담긴 코드
인프라: 애플리케이션이 실행되기 위한 환경

애플리케이션은 항상 인프라에 의존한다.

서버가 다르거나 런타임 버전이 다를 시 같은 코드를 실행하더라도 에러가 발생하고, 이러한 인프라 환경을 맞추는 데 엄청난 리소스가 낭비된다. 이를 해결하기 위한 것이 바로 도커이다.

도커는 이 둘을 하나의 컨테이너로 묶어 개발 환경과 실행 환경의 차이를 없애준다.

도커 특징

불변 인프라: 특정 시점의 서버 상태를 저장하여 복제할 수 있다.
이식성: 어떤 환경에서 실행되도 일관된 결과가 나온다.
멱등성: 같은 작업을 여러 번 수행해도 결과가 변하지 않는다.
관리 용이
빠른 배포 속도

도커 컨테이너 배포 과정

“Dockerfile 생성 → 이미지 빌드 → 컨테이너 실행”

도커는 애플리케이션과 인프라를 하나의 컨테이너에 담아 관리한다.

컨테이너를 만들기 위한 템플릿을 이미지라고 하며 이미지 구성 순서는 Dockerfile에 정의한다.

Dockerfile

이미지를 구성하는 순서

FROM python:3.10 # 베이스 이미지(from docker hub)

COPY . /app # 도커 컨테이너 안으로 복사할 경로  

RUN pip install -r requirements.txt # 이미지를 빌드할 때 실행할 명령

CMD ["python", "app.py"] # 컨테이너를 시작할 때 실행할 명령

Image

도커 컨테이너를 만들기 위한 템플릿

이미지를 생성하는 방법은 크게 2가지이다.

Dockerfile을 통한 직접 build

docker image build -t [image-name]:[tag-name] [Dockerfile-path] 

# custom docker file
docker image build -f [Dockerfile-name] -t [image-name]:[tag-name] [Dockerfile-path]

Docker Hub에서 공식 이미지 pull

docker image pull [repository-name]:[tag-name]

check images

docker images

Container

애플리케이션과 인프라가 함께 담긴 가상 박스

이미지 빌드가 끝났다면 container를 실행시켜 실제로 동작하도록 해야한다.

이때 포트 포워딩을 해주는 것이 중요한데, 도커 컨테이너는 격리된 환경이기 때문에 내부에서 사용하는 컨테이너 포트가 따로 존재한다. 따라서 외부에서 접근하려면 호스트 머신 포트와의 연결이 필요하다.

또한, 이미지명과 태그를 함께 명시하여 버전 관리를 용이하게 하는 것도 중요하다.

실행

docker container run -d -p 9000:8000 [image-name:tag-name]

# p 9000:8000 <- 포트 포워딩(host-port : container-port)

정지

docker container stop [container-name]

파기

docker container rm [container-name]

실행 중이 아닌 모든 컨테이너 파기

docker contanier prune

로그 확인

docker container logs [container-name]

컨테이너 내부에서 명령 실행

docker container exec -it [container-name] sh

복사

# 컨테이너 ->  호스트
docker contanier cp [container-name]:[origin-path] [target-path]

or

#호스트 -> 컨테이너
docker container cp [origin-path] [container-name]:[target-path]

check containers

docker ps

# 종료된 컨테이너 포함
docker ps -a

docker-compose

여러 컨테이너의 실행을 한번에 관리

앞서 다뤘던 이미지 생성과 컨테이너 실행을 한번에 묶어 관리할 수 있는 것이 바로 docker-compose이다. 하나의 파일에 여러 설정을 정의한 후 한 번의 명령으로 환경을 세팅할 수 있으며 여러 개의 이미지나 컨테이너도 하나의 파일로 관리할 수 있다.

실제 프로젝트를 진행할 때는 docker run 명령어를 일일치 치는 경우는 드물고, 거의 docker-compose를 활용하여 환경을 세팅한다.

services:

  embedding-server: # 서비스 정의
    build: . # Dockerfile을 사용하여 이미지 빌드(Dockerfile path 지정) 
    image: embedding-server:latest # image-name:tag-name
    container_name: embedding-server # container-name
    ports:
      - "8000:8000" # port forwarding -> host-port:container-port
    restart: unless-stopped # 직접 멈추기 전까지는 자동 재시작
    volumes: # 볼륨 마운트 -> host 경로:container 경로 연결
      - /data/embedding:/app/data
    depends_on: # 종속성 설정
	    - postgresql # postgresql 실행 후 실행 
      
  postgresql:
    image: postgres # 공식 postgres 이미지 사용 
    restart: always # 어떤 상황에서도 재시작
    container_name: postgres
    ports:
      - "5432:5432"
    environment: 
      POSTGRES_DB: postgres
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres 
      PGDATA: /var/lib/postgresql/data/pgdata # 실제 데이터가 저장될 내부 경로 
    volumes:
      - /data/postgres_260226:/var/lib/postgresql/data

실행: docker-compose up -d (강제 빌드 옵션: --build )
정지: docker-compose down

[Elasticsearch] Elasticsearch 검색 API

대체불가 핫걸 — Sun, 13 Jul 2025 14:23:07 +0900

Search API 기본 구조

_search 엔드포인트를 통해 인덱스 내 문서를 검색할 수 있다. 가장 기본적인 형태는 아래와 같다.

GET /my_index/_search
{
  "query": {
    "match": {
      "title": "elasticsearch"
    }
  }
}

자주 사용하는 쿼리 종류

Elasticsearch에서 쿼리는 Query DSL(Domain Specific Language)로 작성하며,

대표적으로 match, term, bool 쿼리가 많이 사용된다.

match 쿼리 – 자연어 검색

match 쿼리는 전체 텍스트 검색(full-text search)에 사용된다. 내부적으로 분석기(analyzer)가 적용되어 입력된 문자열을 나누고, 토큰을 기준으로 검색한다.

예를 들어 "machine learning"을 입력하면 "machine", "learning" 두 단어 중 하나라도 포함된 문서를 검색한다.
한국어의 경우 형태소 분석을 통해 "머신 러닝" 등도 잘 검색된다.

"query": {
  "match": {
    "title": "machine learning"
  }
}

term 쿼리 – 정확한 값 일치

term 쿼리는 정확히 일치하는 값만 검색할 때 사용된다. 분석기가 적용되지 않기 때문에, 일반적인 텍스트에는 잘 맞지 않고 정확한 키워드 검색에 적합하다.

"query": {
  "term": {
    "status": "approved"
  }
}

정확히 status 필드가 "approved"인 문서만 검색한다.
만약 텍스트 필드에 term 쿼리를 쓰고 싶다면 .keyword 형태로 사용해야 한다.

"term": { "title.keyword": "머신 러닝" }

bool 쿼리 – 조건 조합(AND / OR / NOT)

bool 쿼리는 여러 쿼리를 조합해서 사용할 수 있다. 대표적으로 must, should, must_not, filter 키워드를 포함한다.

must	모두 일치해야 함 (AND)
should	하나 이상 일치 (OR)
must_not	일치하면 제외 (NOT)
filter	점수 계산 없이 필터링 (성능 ↑)

"query": {
  "bool": {
    "must": [
      { "match": { "title": "AI" } },
      { "term": { "author.keyword": "강민지" } }
    ],
    "must_not": [
      { "term": { "category.keyword": "스포츠" } }
    ],
    "filter": [
      { "range": { "publish_year": { "gte": 2020 } } }
    ]
  }
}

⚙️ 주요 검색 옵션

query	검색 조건 설정
size	가져올 문서 개수 설정 (기본: 10)
from	페이지네이션 시작점 설정
_source	검색 응답에 포함시킬 필드 지정
sort	검색 결과 정렬
highlight	검색어 하이라이팅 표시
aggs	통계 및 집계 분석
post_filter	집계 유지한 채 결과 필터링
track_total_hits	총 문서 수 계산 방식 조절
explain / profile	쿼리 설명 및 성능 분석 도구

예를 들어, 다음과 같이 검색 결과를 정렬하고 일부 필드만 응답받을 수 있다.

{
  "query": { "match": { "title": "AI" } },
  "_source": ["title", "author"],
  "size": 5,
  "sort": [{ "publish_date": "desc" }]
}

[Elasticsearch] Bulk API: Elasticsearch 대량 색인 작업

대체불가 핫걸 — Sun, 13 Jul 2025 12:59:50 +0900

✅ Bulk API란?

Bulk API는 여러 개의 문서 작업(색인, 생성, 수정, 삭제)을 한 번의 HTTP 요청으로 처리할 수 있는 기능이다.
이 방식을 사용하면 다음과 같은 이점이 있다:

다수의 HTTP 호출 → 1회 요청으로 병합 → 네트워크 비용 절감
대량 색인 시 속도 향상
비동기 일괄 작업에 적합

공식 홈페이지

Bulk index or delete documents | Elasticsearch API documentation

All methods and paths for this operation: POST /_bulk PUT /_bulk POST ...

www.elastic.co

요청 형식 (NDJSON)

Bulk API는 newline-delimited JSON 포맷을 사용한다.

POST /_bulk
Content-Type: application/x-ndjson

{ "index": { "_index": "my_index", "_id": "1" } }
{ "title": "문서 1", "content": "내용입니다" }
{ "create": { "_index": "my_index", "_id": "2" } }
{ "title": "문서 2", "content": "새 문서입니다" }
{ "update": { "_index": "my_index", "_id": "1" } }
{ "doc": { "title": "수정된 문서 1" } }
{ "delete": { "_index": "my_index", "_id": "2" } }

작업 타입별 설명 및 예제

1️⃣ index – 문서 추가 또는 덮어쓰기

존재하는 문서일 경우 덮어씀 (upsert)

{ "index": { "_index": "my_index", "_id": "1" } }
{ "title": "Elasticsearch 배우기", "content": "Bulk API 정리" }

2️⃣ create – 문서 없을 때만 생성

문서가 존재하면 에러 발생

{ "create": { "_index": "my_index", "_id": "2" } }
{ "title": "새 문서", "category": "tech" }

3️⃣ update – 문서 일부 필드 수정

기존 문서에서 특정 필드만 수정

{ "update": { "_index": "my_index", "_id": "1" } }
{ "doc": { "title": "업데이트된 제목" } }

4️⃣ delete – 문서 삭제

{ "delete": { "_index": "my_index", "_id": "2" } }

⚠️ 주의할 점

요청 형식은 반드시 newline 단위의 JSON(NDJSON) 이어야 한다.
너무 많은 문서를 한 번에 처리하면 성능 저하 또는 실패 발생 → 보통 1000개 단위로 나누어 처리 추천
응답에서 errors: true가 나오면 개별 작업의 실패 여부를 꼭 확인해야 한다.

[Elasticsearch] 엘라스틱서치 인덱싱

대체불가 핫걸 — Sun, 6 Jul 2025 22:47:11 +0900

엘라스틱서치에서 인덱스란?
데이터를 저장하는 공간으로 매핑을 통해 데이터 구조를 정의할 수 있다.

인덱스 생성 구조

해당 API로 PUT 요청을 보내면 새로운 인덱스가 생성된다.

PUT : https://ip:9200/index_name

인덱스 생성을 위해서는 JSON body에 2가지를 정의해야 한다.
- `settings`: 클러스터, 인덱스 운영 설정(샤드 개수, 복제본 수, 텍스트 분석기 정의(커스텀 필터 등록) 등)
- `mappings`: 필드 이름과 데이터 타입 지정

해당 예제는 커스텀 analyzer인 `my_analyzer`에 `standard` tokenizer로 모든 단어를 분리하고, `lowercase` filter를 적용해 모든 단어를 소문자로 변환하도록 지정한다.
`title`과 `content` 필드에 해당 커스텀 analyzer를 적용하고, id는 검색에 사용하지 않도록 `index: false`로 정의되었다.

{
    "settings": {
        "analysis": {
            "analyzer": {
                "my_analyzer": {
                    "type": "custom",
                    "char_filter": [],
                    "tokenizer": "standard",
                    "filter": ["lowercase"]
                }
            },
            "char_filter": {

            },
            "tokenizer": {
                "standard": {
                    "type": "standard"
                }
            },
            "filter": {
                "lowercase": {
                    "type": "lowercase"
                }
            }
        }
    },

    "mappings": {
        "properties": {
            "id": {
                "type": "long",
                "index": false
            },
            "title": {
                "type": "text",
                "analyzer": "my_analyzer"
            },
            "content": {
                "type": "text",
                "analyzer": "my_analyzer"
            }
        }
    }
}

※ elastic 공식 인덱스 생성 가이드

analyzer | Reference

The analyzer parameter specifies the analyzer used for text analysis when indexing or searching a text field. Unless overridden with the search_analyzer...

www.elastic.co

분석기 테스트

GET : https://ip:9200/index_name/_analyze

{
  "analyzer": "my_analyzer",
  "text": "안녕하세요. 테스트 문장입니다."
}

nori tokenizer

앞서 사용한 standard tokenizer는 단순 띄어쓰기 및 문장 부호 기준 토큰화를 진행하므로 한글의 조사나 어미를 잘 처리하지 못한다.

따라서 한글을 처리할 때는 nori tokenizer를 주로 사용한다.

1. 엘라스틱서치 컨테이너 접속

sudo docker exec -it es /bin/bash

2. nori 분석기 설치

bin/elasticsearch-plugin install analysis-nori

3. 엘라스틱서치 컨테이너 재시작

sudo docker restart es

4. setting에 nori tokenizer 추가

`decompound_mode`: 복합어 분해 방법
- `none`: 분해 X
- `discard`: 분해해서 버림
- `mixed`: 분해해서 포함 (복합어 + 원어)
`discard_punctuation`: 문장 부호를 제거할지 여부 (`true`, `false`)
`lenient`: 오류에 관대하게 동작할지 여부 (`true`, `false`)

"settings": {
    "analysis": {
        "analyzer": {
            "my_analyzer": {
                "type": "custom",
                "char_filter": [],
                "tokenizer": "nori",
                "filter": ["lowercase"]
            }
        },
        "char_filter": {

        },
        "tokenizer": {
            "nori": {
                "type": "nori_tokenizer",
                "decompound_mode": "mixed",
                "discard_punctuation": true,
                "ienient": true

            }
        },
        "filter": {
            "lowercase": {
                "type": "lowercase"
            }
        }
    }
}

사용자 사전 기반 tokenizer

특정 단어들만 커스텀하여 분해하고 싶다면 사용자 사전을 사용하면 된다.

1. 컨테이너 외부에 userdict.txt 생성

컨테이너 내부에 두면 임사 파일로 처리되며 유지, 접근이 어렵다.

mkdir elastic_dict
cd elastic_dict

touch userdict.txt

2. 기존 컨테이너 제거 후 새로 생성

제거

sudo docker stop es
sudo docker rm es

재생성

sudo docker run -d --restart unless-stopped \
  --name es \
  -v /home/mingd/elastic_dict/:/usr/share/elasticsearch/config/dict/ \ # 여기에 경로 추가 
  -p 9200:9200 -p 9300:9300 \
  --network myes \
  -e "discovery.type=single-node" \
  -e "ES_JAVA_OPTS=-Xms2g -Xmx2g" \
  docker.elastic.co/elasticsearch/elasticsearch:8.17.2

비밀번호 재설정

sudo docker exec -it es /bin/bash

bin/elasticsearch-setup-passwords interactive

nori 분석기 재설치

bin/elasticsearch-plugin install analysis-nori

sudo docker restart es

3. settings 수정

"settings": {
    "analysis": {
        "analyzer": {
            "my_analyzer": {
                "type": "custom",
                "char_filter": [],
                "tokenizer": "nori",
                "filter": ["lowercase"]
            }
        },
        "char_filter": {

        },
        "tokenizer": {
            "nori": {
                "type": "nori_tokenizer",
                "decompound_mode": "mixed",
                "discard_punctuation": true,
                "ienient": true,
                "user_dictionary": "dict/userdict.txt" # 여기에 경로 추가 

            }
        },
        "filter": {
            "lowercase": {
                "type": "lowercase"
            }
        }
    }
}

4. userdict.txt 작성

txt 파일 수정 후에는 컨테이너 재시작 필수

동의어 사전 기반 filter

문장 분해가 끝나면 filtering 작업을 해주는데 동의어 사전을 만들어 특정 단어를 치환, 확장한다.

⚠️ 주의사항 (tokenizer와 synonym filter 충돌)

동의어 필터는 tokenizer 이후에 적용된다.
따라서, 동의어 사전에 정의된 단어들이 tokenizer에서 정확히 분리되는 단위와 일치해야 한다.
예를 들어:
- tokenizer가 "운동화"를 "운동", "화"로 나눈다면,
  동의어 사전에서 "운동화 => 스니커즈"로 지정해도 작동하지 않음.
- 이 경우 "운동화"가 하나의 token으로 유지되도록 사용자 사전에 등록해야 동의어 필터가 적용 가능.

✅ 따라서 동의어로 처리할 단어는 tokenizer에서 분리되지 않도록 사용자 사전에 미리 정의해두어야 한다.

1. 컨테이너 외부에 userdict.txt 생성

※ 위에서 폴더 만들고 마운트 했으므로 엘라스틱 컨테이너 재성성하지 않아도 됨

cd elastic_dict

touch synonym.txt

2. settings 수정

"settings": {
    "analysis": {
        "analyzer": {
            "my_analyzer": {
                "type": "custom",
                "char_filter": [],
                "tokenizer": "nori",
                "filter": ["lowercase", "synonym"] # 여기에 추가 
            }
        },
        "char_filter": {},
        "tokenizer": {
            "nori": {
                "type": "nori_tokenizer",
                "decompound_mode": "mixed",
                "discard_punctuation": true,
                "ienient": true,
                "user_dictionary": "dict/userdict.txt"
            }
        },
        "filter": {
            "lowercase": {
                "type": "lowercase"
            },
            # 여기에 추가 
            "synonym": {
                "type": "synonym",
                "synonyms_path": "dict/synonym.txt",
                "lenient": true
            }
        }
    }
}

3. synonym.txt 작성

txt 파일 수정 후에는 컨테이너 재시작 필수

확장

ai, 인공지능, artificial intelligence
택배, 배송, 배달
휴대폰, 스마트폰, 모바일

치환

이메일 => 메일
핸드폰 => 휴대폰
노트북컴퓨터 => 노트북

택배를 검색하면 type이 synonym인 배송, 배달이 함께 검색되고, 이메일 > 메일로 검색되는 것을 확인할 수 있다.

[Elasticsearch] 엘라스틱서치, 키바나 설치하기: Ubuntu(WSL), Docker 환경

대체불가 핫걸 — Sun, 6 Jul 2025 16:15:29 +0900

Elasticsearch는 다양한 방법과 경로를 통해 설치할 수 있는데요.
저는 Ubuntu(WSL) 기반으로 Docker를 이용해 설치했습니다.

0️⃣ Ubuntu(WSL) + VSCode 환경 설정

※ 환경 설정이 필요한 분들은 아래 포스팅을 참고해주세요.

Ubuntu(WSL) + VSCode 환경 설정

Windows 10/11 환경에서 Ubuntu WSL을 설치하고, VSCode와 연동하여 개발 환경을 최적화하는 과정을 단계별로 자세히 소개하겠습니다. Powershell 관리자 권한 실행 후 wsl 설치wsl --install Ubuntu 설치wsl --install

irreplaceablehotgirl.tistory.com

1️⃣ Docker 설정

※ Docker 설치가 안 되어 있으시면 아래 링크에서 Docker Desktop을 설치해주세요.

Docker Desktop: The #1 Containerization Tool for Developers | Docker

Docker Desktop is collaborative containerization software for developers. Get started and download Docker Desktop today on Mac, Windows, or Linux.

www.docker.com

Docker Desktop > Settings > Resources > WSL Integration에서 Ubuntu 체크 후 Apply & restart

2️⃣ Elasticsearch 설치

터미널에서 명령어를 차례대로 입력한다.

사용자 정의 네트워크 생성

sudo docker network create --driver bridge myes # 네트워크 이름

Elasticsearch 실행

sudo docker run -d --restart unless-stopped \
  --name es \
  -p 9200:9200 -p 9300:9300 \
  --network myes \
  -e "discovery.type=single-node" \
  -e "ES_JAVA_OPTS=-Xms2g -Xmx2g" \
  docker.elastic.co/elasticsearch/elasticsearch:8.17.2

sudo docker run -d --restart unless-stopped \  # 백그라운드 실행, 자동 재시작 
  --name es \  # 도커 컨테이너 이름 
  -p 9200:9200 -p 9300:9300 \  # 호스트 9200, 9300 포트를 컨테이너 9200, 9300 포트에 각각 매핑 (REST API, 클러스터 통신용)
  --network myes \  # 연결할 네트워크 
  -e "discovery.type=single-node" \  # 단일 노드 클러스터 모드
  -e "ES_JAVA_OPTS=-Xms2g -Xmx2g" \  # JVM 힙 메모리 최소/최대 크기를 2GB로 설정
  docker.elastic.co/elasticsearch/elasticsearch:8.17.2  # Elasticsearch 공식 8.17.2 버전 도커 이미지 지정

컨테이너 확인

sudo docker ps

→ 해당 명령어를 수행했을 때 생성한 컨테이너 이름이 보인다면 성공

3️⃣ ES 암호 재설정 및 접속

REST API 요청 시 필요한 암호 재설정이 필요하다.

ES 컨테이너 접속

sudo docker exec -it es /bin/bash

비밀번호 재설정 명령

bin/elasticsearch-setup-passwords interactive

→ 해당 화면이 나오면 순차적으로 6자리 비밀번호를 입력해준다.

ES 접속

로컬로 접속을 했고, 사용자 이름: elastic(기본 관리자), 비밀번호를 입력하면 접속되는 것을 확인할 수 있다.
Elasticsearch 8.x 버전부터는 보안이 기본적으로 활성화되어 있기 때문에 https로 접속해야 한다.

https://[IP주소]:9200

postman으로 접속

Auth Type > Basic Auth로 변경 후 Username, Password를 입력하고 Send를 보내면 잘 접속이 되는 것을 확인할 수 있다.

4️⃣ kibana 설치

※ kibana(키바나): Elasticsearch에서 수집·저장한 데이터를 시각적으로 탐색하고 분석할 수 있는 웹 기반 도구

sudo docker run -d --restart unless-stopped --name kb \
  --network myes \
  -p 5601:5601 \
  docker.elastic.co/kibana/kibana:8.17.2

sudo docker run -d --restart unless-stopped --name kb \ # 컨테이너 이름 
  --network myes \ # 연결할 네트워크 이름  
  -p 5601:5601 \ # 호스트 5601포트를 컨테이너 5601포트와 매핑 (Kibana UI 포트)
  docker.elastic.co/kibana/kibana:8.17.2

5️⃣ kibana 컨테이너 접속

sudo docker exec -it kb /bin/bash

kibana 접속

로컬로 접속을 했고, Elasticsearch 컨테이너 토큰값이 필요하다.

http://[IP주소]:5601

Elasticsearch 컨테이너 토큰값 가져와서 입력

sudo docker exec -it es /usr/share/elasticsearch/bin/elasticsearch-create-enrollment-token -s kibana

kibana verification 토큰값이 필요하다.

kibana verification 토큰값 가져와서 입력

sudo docker exec -it kb /usr/share/kibana/bin/kibana-verification-code

토큰값까지 입력하면 해당 화면이 뜨고, es때와 마찬가지로 Username:elastic, Password를 입력하면 접속할 수 있다.

컨테이너 명령어

실행중인 컨테이너 확인

sudo docker ps

재시작

sudo docker restart container-name

정지

sudo docker stop container-name

제거

sudo docker rm container-name

Ubuntu(WSL) + VSCode 환경 설정

대체불가 핫걸 — Sat, 5 Jul 2025 22:18:45 +0900

Windows 10/11 환경에서 Ubuntu WSL을 설치하고,
VSCode와 연동하여 개발 환경을 최적화하는 과정을 단계별로 자세히 소개하겠습니다.

Powershell 관리자 권한 실행 후 wsl 설치

wsl --install

Ubuntu 설치

wsl --install -d Ubuntu

- 위의 코드를 실행하면 자동으로 WSL2로 설치 되지만 최신 커널(WSL2)을 설치 하라는 오류가 나오면 아래 코드 실행

wsl --set-version Ubuntu

※ "Installing, this may take a few minutes..."가 뜬다면 잘 설치되고 있는 것이고 5분~10분 정도 소요됩니다!

VSCode > Remote - WSL 확장 설치

WSL 우분투 환경으로 VSCode 열기

WSL 터미널에 `code .` 입력

VSCode 새창이 열리며, 좌측 하단에 WSL:Ubuntu로 연결된 것을 확인할 수 있다.

Ubuntu 접속

ubuntu

Ubuntu 접속 해제

exit

[Elasticsearch] 엘라스틱서치란?

대체불가 핫걸 — Sat, 5 Jul 2025 14:01:07 +0900

1️⃣ 엘라스틱서치란?

대용량의 데이터를 실시간으로 검색하고 분석할 수 있도록 설계된 분산형 오픈소스 검색엔진이다.

구조화된 데이터뿐만 아니라 비정형 텍스트, 로그, 메트릭, 문서 등 다양한 형태의 데이터를 빠르게 처리할 수 있다.

검색엔진

사용자가 입력한 검색어(쿼리)를 바탕으로, 방대한 데이터 중에서 관련된 정보를 빠르게 찾아주는 소프트웨어 시스템이다.

웹사이트, 문서, 상품, 로그 등 다양한 데이터 유형에 적용되며, 오늘날 거의 모든 온라인 서비스의 핵심 기술로 자리 잡고 있다.

엘라스틱서치 인덱싱 과정

JSON 형태의 문서 → 역색인(Inverted Index) 생성 → 토큰화 및 분석 → 문서를 인덱스에 저장

단순한 key-value 저장소가 아닌 역색인 구조를 사용하기에 수백만 개 문서도 빠르게 검색할 수 있다.

일반 인덱스: 문서 → 단어
역색인: 단어 → 문서 목록

엘라스틱서치 문장 분석 과정

char_filter > tokenizer > token_filter 과정을 거친다.

[문장]

   ↓ 1. char_filter (문자 치환: html 태그 제거, 특수문자 치환)
   
[전처리된 문장]

   ↓ 2. tokenizer (단어 분리) * 한국어는 거의 NORI tokenizer 사용 * 
   
[토큰 목록]

   ↓ 3. token_filter (불필요한 토큰 제거 및 변환: 소문자 변환, 어간 추출 등)
   
[최종 토큰 목록] → 인덱싱

엘라스틱서치 구성 요소

구성 요소	설명
Cluster	노드의 집합
Node	Elasticsearch 실행 단위
Index	문서 저장 논리 단위
Shard	인덱스를 나눈 조각 (물리적 단위)
Document	실제 저장되는 데이터 (JSON)

2️⃣ 엘라스틱서치 특징

FTS: Full-Text Search

문서 전체 내용을 대상으로 단어(키워드)를 검색하는 방식이다.

단순한 `WHERE title = '엘라스틱서치' `같은 값 일치 검색이 아니라, 자연어 문장을 쪼개고 분석해서 "의미 있는 단어가 포함되어 있는지"를 검색하는 방식이다.

RDB에에서도 FTS는 가능하지만 실무에서 사용하기에는 여러 한계가 존재하며 엘라스틱서치의 강력한 커스터마이징 기능을 따라가기 어렵다.

RESTful API 기반

엘라스틱서치는 HTTP를 통해 JSON 형식의 RESTful API를 이용하며, 손쉽게 데이터를 CRUD(Create, Read, Update, Delete) 할 수 있다. 덕분에 다양한 언어와 플랫폼에서 접근이 용이하다.

거의 실시간 검색

데이터를 저장한 직후 거의 실시간(NRT, Near Real-Time)으로 검색할 수 있다.

1초 미만 ~ 수 초 수준의 지연이 있다.

분산 아키텍처

클러스터 기반으로 작동하며, 데이터를 샤드 단위로 분산 저장한다.

각 샤드는 레플리카(샤드의 복사본)를 가질 수 있어 데이터의 안정성과 수평 확장성을 동시에 확보할 수 있다.

스키마리스 구조

처음에는 명시적인 스키마가 없으며 필드 유형을 자동으로 추론해준다. 필요한 경우 명시적인 매핑 설정도 가능하다.

다양한 통계 및 집계 가능

단순 검색을 넘어 데이터를 집계하여 통계, 차트, 대시보드로 활용할 수 있다.

※ 시간대별 요청 수, 평균 최대 최소 값 계산, 조건별 그룹

3️⃣ 엘라스틱서치 vs 관계형 데이터베이스

Elasticsearch	관계형 데이터베이스
인덱스	데이터베이스
샤드	파티션
타입	테이블
문서	행
필드	열
매핑	스키마
Query DSL	SQL

추가, 검색, 삭제, 수정 기능 비교

엘라스틱서치에서의 HTTP 메서드	기능	데이터베이스 질의 문법
GET	데이터 조회	SELECT
PUT	데이터 생성	INSERT
POST	인덱스 업데이트, 데이터 조회	UPDATE, SELECT
DELETE	데이터 삭제	DELETE
HEAD	인덱스의 정보 확인	-

4️⃣ 엘라스틱서치 사용 사례

로그 분석: ELK 스택 (Elasticsearch + Logstash + Kibana)
검색 서비스: 쇼핑몰, 뉴스 사이트의 텍스트 검색
추천 시스템: 유사 콘텐츠 검색
모니터링: APM(Application Performance Monitoring), 실시간 지표 수집 및 시각화
RAG 시스템의 백엔드 검색엔진 (최근엔 dense_vector도 지원)

5️⃣ 엘라스틱서치 장점

강력한 커스텀 기능: 토크나이징을 통해 검색 커스텀을 다양하게 할 수 있다. (인덱싱을 잘 한다면 검색어 자동 소문자 처리, 조사 처리, 합성어 처리 등 다양한 검색어를 처리할 수 있음)

6️⃣ 엘라스틱서치 한계점

실시간 검색 X, 벡터 검색 한계, 리소스 소비 큼, 설정이 복잡.

[논문 리뷰] YOLO(You Only Look Once): Unified, Real-Time Object Detection

대체불가 핫걸 — Sun, 11 May 2025 17:49:19 +0900

YOLO는 현재 시각 지능 딥러닝 분야에서 가장 중요한 객체 탐지 알고리즘 중 하나이다.
본 리뷰에서는 YOLO의 핵심 아이디어와 기존 방식과의 차별점에 초점을 맞춰 원본 논문을 살펴보고자 한다.

0️⃣ Abstract (요약)

기존의 객체 탐지는 분류 문제로 정의했다면, YOLO는 객체 탐지를 회귀 문제로 정의한다.

YOLO는 전체 이미지를 한번에 처리하여 Bounding Box(좌표)와 Class Probabilities(클래스 확률)을 동시에 예측하는 단일 신경망(neural network) 기반의 모델이다.

또한, YOLO는 매우 빠르다. 실시간으로 초당 45프레임을 처리할 수 있고, 더 작은 버전인 Fast YOLO는 초당 155프레임을 처리할 수 있으며 다른 실시간 탐지기보다 2배 더 높은 mAP를 달성한다.

YOLO는 다른 객체 탐지 시스템에 비해 "위치 오차"는 더 많이 발생하지만 "잘못된 탐지"는 덜하다는 장점이 있고, 다양한 도메인에 잘 일반화 되어있다. ("정확히 어디 있는지"는 상대적으로 부정확하나, "무엇인지"는 잘 맞춘다.)

※ mAP(mean Average Precision): 모델이 얼마나 정확하게 다양한 Class를 탐지했는지 보여주는 성능 지표

1️⃣ Introduction (소개)

기존의 객체 탐지 시스템들은 분류기(classifier)를 탐지용으로 재활용하는 방식을 채택해 왔다.

예를 들어, DPM은 슬라이딩 윈도우 방식을 사용하여 하나하나 분류기를 적용한다.

또, R-CNN은 제안 영역(region proposal)을 먼저 생성한 후, 제안된 박스마다 분류기를 생성한다. 이후 박스를 정제, 중복 탐지 제거, 객체 간 맥락 반영 등 복잡한 후처리 과정이 필요하다.

이러한 파이프라인은 느리고, 각 요소가 따로 학습되기 때문에 최적화도 어렵다.

YOLO는 객체 탐지를 하나의 회귀(regression) 문제로 다시 정의한다.

이미지 픽셀에서 곧바로 Bounding Box(좌표)와 Class Probabilities(클래스 확률)를 동시에 예측하는 방식으로, 이미지를 한 번만 보면(You Only Look Once) 그 안에 객체의 위치를 예측할 수 있다.

<YOLO 처리 과정은 간단하고 직관적이다.>

입력 이미지를 448 x 448 크기로 리사이즈한다.
그 이미지를 CNN(단일 합성곱 신경망)에 통과시킨다.
예측한 결과 중 신뢰도가 일정 기준 이상인 것만 선택한다.

<장점>

빠른 속도: 복잡한 탐지 파이프라인 없이 이미지 신경망을 한 번만 적용하면 된다. 기본 YOLO는 Titan X GPU에서 배치 없이도 초당 45프레임을 처리하며, 빠른 버전은 초당 150프레임 이상을 달성한다. 이는 실시간 영상 스트리밍도 지연 없이(25ms 이하) 처리할 수 있음을 의미한다. 또한 기존 실시간 시스템보다 2배 높은 mAP를 달성한다.
전체 이미지 기반 추론: 슬라이딩 윈도우는 영역 제안 기법과 달리 전체 이미지를 보기 때문에 형태뿐 아니라 맥락(context information)도 학습할 수 있다. Fast R-CNN과 같은 상위 탐지 모델은 배경을 객체로 오탐지하는 일이 많은데, YOLO는 이러한 배경 오류가 절반 이하이다.
뛰어난 일반화 능력: 학습 도메인과 다른 새로운 도메인에서 테스트해도 DPM이나 R-CNN보다 훨씬 나은 성능을 보인다. 새로운 환경이나 예기치 못한 입력에도 견고하게 작동한다.

2️⃣ Unified Detection (통합된 탐지)

YOLO는 객체 탐지의 여러 단계를 하나의 신경망으로 통합하여 전체 이미지와 그 안의 모든 객체를 전역적 관점으로 파악할 수 있다.

이러한 구조는 end-to-end 학습(입력부터 출력까지 한 번에 학습)이 가능하며, 실시간 속도를 유지하면서도 높은 mAP를 달성한다.

<YOLO의 작동 방식>

S x S 그리드로 이미지 분할
각 그리드 셀이 예측
- B개의 Bounding Boxes
  - (x, y): Box의 중심 좌표
  - (w, h): Box의 가로, 세로 길이
  - Confidence Scores → `Pr(Object) × IOU(pred, truth)`: 객체가 Bounding Box 내에 존재할 확률 x 예측 박스와 실제 박스가 얼마나 일지하는지
- C개의 Class Probabilities
  - `Pr(Classi | Object)`: 그리드 셀에 객체가 있을 때, 해당 객체가 i번째 Class에 속학 확률
  - 객체가 없으면 Class 확률은 0
최종 출력 텐서 → S × S × (B ∗ 5 + C)
- PASCAL VOC 데이터셋에서 평가할 때, S = 7, B = 2, C = 20 사용
- 이미지를 7 x 7 그리드로 나누고, 각 그리드 셀이 2개의 Bounding Box를 예측한다. PASCAL VOC는 20개의 Class를 가진다. 따라서 한 셀당 30개의 값을 가지는 7 x 7 x 30 텐서가 출력된다.

2.1 Network Design

YOLO 모델은 CNN(합성곱 신경망)으로 구현하였고, PASCAL VOC 객체 탐지 데이터셋으로 평가했다.

GoogLeNet 구조에서 영감을 받았지만 해당 모델에서 사용한 Inception 모듈 대신, Lin et al.의 방식처럼 `1×1 축소 계층` → `3×3 합성곱 계층`을 교대로 사용하여 연산 효율을 높였다.

<YOLO 모델 아키텍처>

24개의 합성곱 계층(Convolutional Layers)과 2개의 완전 연결 계층(Fully Connected Layers)으로 이루어짐
ImageNet 분류 사전 학습 → 이미지의 특성 추출시 224x224 해상도를 사용하며, 객체 탐지 수행시 448x448로 2배 높은 해상도를 사용
최종 출력은 7x7x30 텐서이며, 이는 각 그리드 당 2개의 Bounding Box와 20개의 Class를 포함한다.

추가로, 경량화된 Fast YOLO 버전도 있으며, 이는 24개가 아닌 9개의 합성곱 레이어만 사용해 속도를 더욱 끌어올렸다. 단, 학습 방식이나 파라미터는 동일하다.

2.2 Training

1. 사전 학습

20개의 합성곱 계층(Convolutional Layers)을 사용하여 ImageNet 1000-class competition 데이터셋으로 사전 학습을 진행했으며 Darknet 프레임워크를 사용했다.

학습은 약 1주일 동안 진행되며, ImageNet 2012 검증셋에서 88%의 정확도로 단일 크롭 top-5 달성했다.

2. 객체 탐지 모델로의 전환

Ren et al.의 아이디어에 따라 4개의 합성곱 계층(Convolutional Layers)과 2개의 완전 연결 계층(Fully Connected Layers)을 추가한다.

이때 이 계층들의 가중치는 무작위 초기화(randomly initialized)하며 입력 해상도를 224x224에서 448x448로 변경한다.

3. 최종 Layer → Bounding Boxes와 Class Probabilities 예측

최종 계층에서 Bounding Boxes와 Class Probabilities를 예측한다,

이미지의 너비와 높이 기준으로 Bounding Box의 w(너비)와 h(높이)를 정규화하여 0~1 사이에 두도록 하고, x와 y는 소속된 그리드 위치를 기준으로 0~1 사이의 상대 좌표로 표현된다.

4. 활성화 함수

최종 계층에 선형 활성화 함수를 사용하며, 다른 모든 계층에서는 Leaky ReLU 활성화 함수를 사용한다.

Leaky ReLU는 x > 0 일 때는 x, x <= 0일 때는 0.1x로 설정하여 음수 값을 허용해 기울기 소실 문제를 완화한다.

5. 손실 함수

손실 함수는 합성곱 계층(Convolutional Layers)의 출력에 대해 SSE(Sum of Squared Error)를 사용하여 최적화한다.하지만 이로 인해 Bounding Box의 좌표 예측의 오차와 Class 확률 예측 오차가 동일하게 취급되어 비효율성을 가질 수 있다.객체가 없는 그리드 셀의 신뢰도(confidence) 값은 0에 가까운데, 전체 이미지에서 객체가 없는 그리드 셀이 많기 때문에 객체가 없는 상황에 대한 손실이 지나치게 커질 수 있으며 이는 모델의 불안정성으로 이어질 수 있다.따라서 이를 해결하기 위해 Bounding Box 좌표 예측 오류에 대한 손실을 증가시키고, 객체가 없을 때 발생하는 오류의 손실을 감소시킨다.이때 λcoord (바운딩 박스 좌표 예측의 가중치)를 5로, λnoobj (객체가 없는 그리드 셀에서의 가중치)를 0.5로 설정하여 이 문제를 해결한다.또한, Bounding Box의 w, h 대신 sqrt(w), sqrt(h)로 제곱근을 예측하여 작은 박스에서 발생할 수 있는 오류에 더 높은 가중치를 부여한다.

6. 가장 적합한 Bounding Box 예측기 선택

YOLO는 각 그리드 셀에서 여러 개의 Bounding Box를 예측하지만 훈련 중에는 하나의 Bounding Box 예측기만이 해당 객체를 예측하도록 한다.이를 위해 가장 높은 IOU 값을 가진 예측기를 책임자로 지정하여, 각 예측기가 특정 객체에 특화되도록 한다.

7. 훈련 과정에서의 손실 함수 최적화

훈련 중 최적화되는 다중 부분 손실 함수는 다음과 같으며 객체가 존재하는 셀에 대해서만 Class 예측과 Bounding Box 예측에 대해 패널티를 부과한다.

좌표 예측 손실(bounding box prediction loss)
클래스 예측 손실(classification prediction loss)
객체가 없는 그리드 셀에 대한 손실(no object loss)
객체가 있는 그리드 셀에 대한 손실(object loss)

8. 훈련

훈련 데이터: PASCAL VOC 2007 및 2012 데이터셋을 사용하며, 2012 데이터셋을 사용할 때는 2007 테스트 데이터를 포함하여 학습
Batch size는 64, Momentum은 0.9, Weight decay는 0.0005로 설정
Learning Rate: 10^-3에서 시작하여 점차적으로 10^-2로 증가한 뒤, 10^-2로 75 epochs, 10^-3으로 30 epochs, 10^-4로 30 epochs 동안 훈련 진행
Dropout: 0.5 → co-adaptation 방지
Data Augmentation: 원본 이미지 크기의 최대 20%까지 임의로 조정하거나 이동, HSV 색공간에서 이미지의 노출도(exposure)와 채도(saturation)를 최대 1.5배까지 무작위 조정

※ co-adaptation: 한 뉴런이 다른 뉴런에 과도하게 의존해 독립적인 학습을 못 하는 현상

※ HSV(Hus: 색상, Saturation: 채도, Value: 명도)

2.3 Inference

훈련과 마찬가지로 네트워크 평가는 한 번이면 되므로 테스트가 매우 빠르다.

PASCAL VOC 데이터셋에서 네트워크는 이미지당 98개의 Bounding Box를 예측하고, 각 박스에 대해 Class 확률을 예측한다.

일반적으로 객체가 어느 그리드 셀에 속하는지 명확하게 알 수 있으며, 네트워크는 각 객체에 대해 하나의 박스만 예측한다.

그러나 일부 큰 객체나 경계에 있는 객체는 여러 셀에서 예측될 수 있다.

이러한 중복 예측을 해결하기 위해 NMS(Non-maximal suppression)를 사용하며 이는 mAP(평균 정밀도)를 2-3% 향상시킬 수 있다.

※ NMS(Non-Maximum Suppression): 객체 탐지에서 중복된 바운딩 박스를 제거하는 후처리 기법

2.4 Limitations of YOLO

공간적 제약: 각 그리드 셀에서 2개의 Bounding Box만 예측하고, 1개의 Class만 가질 수 있으므로 서로 가까운 객체나 작은 객체에 약하다.
비정상적인 비율이나 배치에 약함: 데이터로부터 Bounding Box를 학습하기 때문에 새로운 비율이나 배치를 가진 객체를 일반화하는 데 어려움이 있다.
다운샘플링 문제: 여러 번 다운샘플링을 진행하므로 Bounding Box를 예측할 때 사용하는 Feature가 다소 거칠고 부정확할 수 있다.
손실함수의 한계: 작은 박스와 큰 박스의 오류를 똑같이 처리한다. (작은 박스에서의 위치 예측이 5픽셀만 틀려도 전체 박스 위치에서 큰 차이로 간주되어 IOU가 급감한다. 반면, 큰 박스에서는 같은 5픽셀이라도 상대적으로 무시할 정도로 작은 비율이라 IOU 변화가 적은데 YOLO는 이 둘은 동일한 오차로 처리하기 때문에 문제가 된다.)

※ 다운 샘플링(Downsampling): 입력 이미지가 448x448에서 7x7로 작게 줄어드는 과정

3️⃣ Comparison to Other Detection Systems (다른 탐지 시스템들과의 차이점)

YOLO는 기존 객체 탐지 시스템들과 달리, 복잡한 파이프라인을 하나의 CNN 모델로 통합한 단순하고 빠른 구조를 가진다.
기존 시스템들은 보통 여러 단계를 거치거나 느린 반면, YOLO는 실시간 속도로 다양한 객체를 탐지할 수 있다.

기존 객체 탐지 시스템들

robust한 feature 뽑기 → 분류기(classifier) 또는 위치 추정기(localizer) 사용 → 슬라이딩 윈도우 방식 or 제한된 영역(subset region)을 대상으로 실행

	DPM(Deformable Parts Model)	YOLO
특징	슬라이딩 윈도우 기반 탐지 특징 추출 → 분류 → 박스 예측 → NMS를 따로 처리 30Hz DPM만 실시간 탐지 가능	모든 과정을 하나의 CNN으로 통합 고정된(static) 특징 대신, 탐지 작업에 맞춰 학습된 특징 사용 → 빠르고 정확 처음부터 속도를 고려해 설계

	R-CNN	Fast/Faster R-CNN	YOLO
특징	Selective Search로 후보 영역 → CNN으로 특징 추출 → SVM으로 분류 → 박스 조정 → NMS → 매우 느림(1장당 40초) 한 장당 약 2000개 박스 예측	Selective Search 대신 신경망 기반 Region Proposal 사용 → 이전보다 빠르지만 실시간은 아님	공간 제약(grid 구조)이 중복 탐지를 줄임 전체를 하나의 모델로 통합해 학습 → 빠름 한 장당 약 98개 박스 예측

	Deep MultiBox	YOLO
특징	단일 객체 탐지용 (예: 얼굴만 탐지) → 분류기 필요	완전한 탐지 시스템

	OverFeat	YOLO
특징	CNN으로 Localization 후 탐지 → 전역 맥락 판단 불가	전체 이미지를 보고 탐지

	MultiGrasp	YOLO
특징	이미지 1개에 물체 1개만 탐지 가능	여러 클래스, 여러 객체를 동시에 예측 그리드 구조는 MultiGrasp에서 영감을 받음

4️⃣ Experiments (실험)

PASCAL VOC 2007에서 YOLO와 Fast R-CNN을 비교하며 오류 유형을 분석한 결과, YOLO는 배경에 대한 오탐(배경을 객체로 착각)을 줄이는 데 효과적이었으며, 이를 Fast R-CNN의 결과 보정(rescoring)에 활용하여 mAP 성능을 향상시켰다.
또한 VOC 2012와 예술 작품 데이터셋에서도 높은 mAP을 기록하며 YOLO의 뛰어난 일반화 성능을 입증하였다.

4.1 Comparison to Other Real-Time Systems

많은 객체 탐지 연구들이 기존 탐지 파이프라인은 빠르게 만드려는 시도를 해왔지만, 이 중 실제로 실시간(30FPS 이상) 성능을 달성한 건 Sadeghi et al. 뿐이다.

※ Sadeghi et al.: DPM 기반 객체 탐지 시스템을 GPU로 실시간 구현한 논문의 저자들이다.

YOLO와 다른 탐지기의 mAP(성능), FPS(속도) 비교

<실시간 탐지기 비교>

Fast YOLO는 현재까지 가장 빠른 객체 탐지기로, 52.7%의 mAP와 155 FPS를 기록하며 실시간 탐지기 중 정확도가 2배 이상 향상되었다.
일반 YOLO는 mAP를 63.4%까지 끌어올리면서 45 FPS로 실시간 속도를 유지한다.

<실시간이 아닌 탐지기 비교>

VGG-16 백본을 사용한 버전도 훈련했으며, 더 정확하지만 느림
Fast R-CNN은 분류는 빠르지만 Selective Search 사용으로 전체 속도는 매우 느림, 나머지 R-CNN 기법은 Selective Search를 제거해 속도를 개선했으나 여전히 실시간은 아님

4.2 VOC 2007 Error Analysis

YOLO와 Fast R-CNN의 성능 차이를 더 자세히 보기 위해 VOC 2007 데이터셋에서 오류 유형별 분석을 수행했다.

Hoiem et al.의 방법론을 따랐으며, 각 클래스별로 상위 n개의 예측값을 검사하고, 아래와 같은 오류 유형으로 분류했다.

`Correct`: 정답 클래스, IOU > 0.5 → 정확한 탐지
`Localization`: 정답 클래스, 0.1 < IOU < 0.5
`Similar`: 유사한 클래스, IOU > 0.1
`Other`: 다른 클래스, IOU > 0.1
`Background`: 물체가 존재하지 않음, IOU < 0.1

YOLO는 객체의 위치를 정확히 잡는 데 약해 Localization 오류가 많고, Fast R-CNN은 실제 객체가 없는 곳을 탐지하는 Background 오류가 많다.

즉, YOLO는 Fast R-CNN보다 위치 정확도는 떨어지지만 배경 탐지 안정성은 높다.

4.3 Combining Fast R-CNN and YOLO

YOLO와 Fast R-CNN을 결합하여 성능을 개선한 실험

YOLO는 배경에 대한 오탐률이 낮다.

그래서 YOLO를 활용해 Fast R-CNN이 예측한 박스 중 배경일 가능성이 높은 것을 제거함으로써 성능을 높인다.

YOLO의 예측 확률과 Bounding Box간 IOU를 기준으로, Fast R-CNN의 예측 점수에 가중치를 주는 방법으로 보정한다.

Combined: 결합 후 mAP, Gain: 결합 후 mAP 향상 폭

2007 data, VGG-M, CaffeNet과 같이 기존 Fast R-CNN 모델을 결합한 것보다, YOLO와 결합했을 때 mAP 향상이 훨씬 큰 것을 확인할 수 있다.

YOLO는 2015년 11월 6일 기준, 외부 데이터를 허용한 PASCAL VOC 2012 com4 리더보드에서 유일한 실시간 객체 탐지기이다.

Fast R-CNN과 결합했을 때 Fast R-CNN 단독 모델 대비 mAP가 2.3% 향상되어 전체 4위 성능을 기록했다.

YOLO와의 결합이 성능을 크게 향상시킨 이유는 단순한 모델 앙상블 효과가 아니라 YOLO가 Fast R-CNN과는 서로 다른 오류 패턴을 가지기 때문이다. 이러한 보완적인 특성이 Fast R-CNN의 성능을 크게 끌어올릴 수 있었다.

하지만 각 모델을 따로 실행한 뒤 결과를 결합하기 때문에 속도 면에서는 YOLO의 장점을 살리지 못하지만 YOLO는 매우 빠르기 때문에 전체적인 처리 시간에 큰 영향을 주지는 않는다.

4.4 VOC 2012 Results

YOLO는 VOC 2012에서 mAP 57.9%로, 최신 모델보다는 낮은 성능을 보인다.

작은 객체 탐지에는 약하지만, 고양이(cat), 기차(train)처럼 일부 큰 객체 카테고리에서는 높은 성능을 보인다.

YOLO와 Fast R-CNN 결합하면 리더보드 순위가 5단계 상승하며,

이는 YOLO 단독 성능은 제한적이지만 Fast R-CNN과의 결합을 통해 성능 향상이 가능함을 보여준다.

4.5 Generalizability: Person Detection in Artwork

현실에서는 테스트 데이터와 학습 데이터가 다를 수 있으므로 다양한 도메인에서 잘 작동하는 것이 중요하다.

이를 평가하기 위해 YOLO를 포함한 여러 모델을 예술 작품 속 사람 탐지에 특화된 두 데이터셋으로 비교했다.

비교 기준으로는 VOC 2007 데이터에서 훈련된 모델의 사람 클래스에 대한 AP(Average Precision)를 사용했다.

Picasso: VOC 2012로 훈련
People-Art: VOC 2010으로 훈련

R-CNN은 VOC 2007에서는 높은 성능을 보이지만, 예술 이미지로 넘어가면 성능이 급격히 하락한다.

이는 R-CNN이 사용하는 Selective Search가 자연 이미지에 최적화되어 있고, 작은 영역만 분류기로 처리해 일반화가 잘 되지 않기 때문이다.

DPM은 AP가 낮지만 예술 이미지로 넘어가도 성능 감소가 작다. 객체의 형태, 배치 등 공간 모델링이 강력하기 때문이다.

YOLO는 VOC 2007에서 좋은 성능을 보이고, 예술 이미지로 전이될 때 성능 감소폭이 가장 작다.

YOLO는 DPM처럼 객체의 크기, 형태, 위치, 관계까지 학습하며 이는 픽셀 수준에서는 다르지만 구조적 유사성이 있는 예술 이미지에도 잘 대응할 수 있게 한다.

5️⃣ Real-Time Detection In The Wild (현실 세계에서의 실시간 객체 탐지)

YOLO는 웹캠과 연결해도 실시간 객체 탐지 성능을 유지한다.

YOLO는 개별 이미지를 처리하지만, 웹캠에 연결하면 물체가 움직이거나 외형이 변하더라도 추적 시스템처럼 작동한다.

이 데모와 소스 코드는 https://pjreddie.com/yolo에서 확인할 수 있다.

6️⃣ Conclusion (결론)

객체 탐지를 위한 통합 모델인 YOLO는 단순한 구조로 설계되어 있으며, 전체 이미지를 기반으로 학습한다.

기존 분류기 기반 접근 방식과 달리 탐지 성능과 직접적으로 연결된 손실 함수를 사용하여 학습된다.

Fast YOLO는 가장 빠른 범용 객체 탐지기이며, YOLO는 실시간 객체 탐지 분야에서 새로운 성능 기준을 제시했다.

또한 새로운 도메인에도 일반화 성능이 뛰어나 빠르고 견고한 객체 탐지가 필요한 분야에 적합하다.

출처

You Only Look Once: Uniﬁed, Real-Time Object Detection, Redmon et al., 2016–05–09

You Only Look Once: Unified, Real-Time Object Detection

We present YOLO, a new approach to object detection. Prior work on object detection repurposes classifiers to perform detection. Instead, we frame object detection as a regression problem to spatially separated bounding boxes and associated class probabili

arxiv.org