P2-8.3 딕셔너리(dictionary): 키(key)로 값을 찾는 구조¶

Section ID: P2-8.3 Version: v2026.07.20

P2-8.2에서는 순서가 있는 값 묶음인 리스트(list)를 봤습니다. 하지만 모든 데이터가 순서로만 읽히는 것은 아닙니다.

설정 이름으로 설정값을 찾고, 라벨 번호로 라벨 이름을 찾고, 사용자 ID로 사용자 정보를 찾는 상황에서는 위치보다 이름표가 중요합니다. Python에서는 이런 구조를 딕셔너리(dictionary)로 다룹니다.

여기서는 딕셔너리(dictionary)와 키(key)의 기본 구분을 설명합니다. 리스트(list)와 순서 기반 접근의 대표 설명은 P2-8.2에, 값(value)과 타입(type)의 대표 설명은 P2-8.1과 개념사전에 두고, 여기서는 “어떤 기준으로 값을 찾을 것인가”에 집중합니다.

바로 앞 절의 리스트가 몇 번째 값인가를 중심으로 읽혔다면, 여기서는 어떤 이름이나 식별자로 찾는가가 중심이 됩니다. 이 차이를 먼저 잡아 두면, 뒤의 반복 절에서 리스트와 딕셔너리를 같은 loop 안에서 돌리더라도 무엇을 기준으로 꺼내고 있는가를 구분하기 쉬워집니다.

핵심 기준: 딕셔너리(dictionary): 키(key)로 값을 찾는 구조¶

• 딕셔너리(dictionary)를 키(key)와 값(value)의 묶음으로 설명할 수 있습니다.
• 딕셔너리를 범용적인 매핑(mapping) 구조로 설명할 수 있습니다.
• 리스트와 딕셔너리의 차이를 위치(index)와 키(key)의 차이로 설명할 수 있습니다.
• dict[key], dict.get(key)의 차이를 설명할 수 있습니다.
• 설정값, 라벨 맵, 샘플 ID 조회, 컬럼 설명 예시를 읽을 수 있습니다.

세 가지 기준¶

여기서는 문법보다 무엇을 기준으로 값을 찾을 것인가를 먼저 봅니다. 아래 세 가지 기준이 뒤 절의 반복과 키 누락 처리 설명을 읽는 바탕이 됩니다.

딕셔너리는 기준으로 값을 찾는 구조다¶

일반적으로 매핑(mapping)은 어떤 기준을 값에 연결하는 구조입니다. 그 기준을 키(key)라고 부르고, 키에 연결된 대상을 값(value)이라고 부를 수 있습니다.

Python에서는 이런 매핑 구조를 딕셔너리(dictionary)로 자주 표현합니다.

문제 상황: 이름표로 값을 찾는 가장 단순한 딕셔너리 예를 먼저 보고 싶습니다. 입력(input): name, score, passed 키를 가진 student 딕셔너리. 기대 출력(output): student["name"]과 student["score"] 값이 출력됩니다. 확인할 개념: 딕셔너리는 위치가 아니라 키로 값을 찾는 매핑 구조입니다.

1
2
3
4
5
6
7
8
9

# 이 예제는 딕셔너리가 키로 값을 찾고 연결하는 방식을 확인합니다.
student = {
    "name": "Kim",
    "score": 82.5,
    "passed": True,
}

print(student["name"])
print(student["score"])

리스트가 위치로 값을 찾는다면, Python 딕셔너리는 키로 값을 찾습니다.

딕셔너리는 AI 실습에서 자주 보입니다.

• 설정값 묶음: {"learning_rate": 0.01, "epochs": 10}
• 데이터 한 행: {"text": "hello", "label": "positive"}
• API 응답 일부: {"model": "example", "tokens": 120}
• 모델 평가 결과: {"accuracy": 0.91, "loss": 0.32}

딕셔너리는 “순서대로 몇 번째 값인가”보다 “어떤 이름의 값인가”가 중요할 때 사용합니다.

딕셔너리는 범용적인 맵 구조로 자주 쓰인다¶

딕셔너리는 단순히 여러 값을 한곳에 모아 두는 문법이 아닙니다. Python 공식 문서에서는 딕셔너리를 매핑 타입(mapping type)으로 설명합니다. 매핑(mapping)은 어떤 키(key)를 어떤 값(value)에 연결하는 구조입니다. 이 설명은 Python을 넘어 설정 파일, JSON 응답, 라벨 맵, 메타데이터를 읽을 때도 그대로 이어집니다.

이 절에서는 딕셔너리를 다음 기준으로 이해합니다.

딕셔너리는 키를 주면 연결된 값을 찾기 위한 범용적인 맵(map)입니다.

문제 상황: 숫자 라벨을 사람이 읽는 이름으로 바꾸는 가장 작은 대응표를 보고 싶습니다. 입력(input): 0, 1을 문자열 라벨에 연결한 label_name 딕셔너리와 예측값 1. 기대 출력(output): 예측값 1에 대응하는 "positive"가 출력됩니다. 확인할 개념: 딕셔너리는 기준 키를 주면 연결된 값을 바로 꺼낼 수 있습니다.

1
2
3
4
5
6
7
8

# 이 예제는 딕셔너리가 키로 값을 찾고 연결하는 방식을 확인합니다.
label_name = {
    0: "negative",
    1: "positive",
}

prediction = 1
print(label_name[prediction])

위 예시에서 prediction이 1이면 딕셔너리는 1이라는 키에 연결된 "positive"를 찾아 줍니다. 리스트처럼 “몇 번째 칸을 뒤져야 하는가”를 사람이 직접 생각하기보다, 키를 기준으로 값을 꺼냅니다.

이 감각은 실무와 AI 실습에서 자주 나타납니다.

딕셔너리가 범용적인 맵처럼 느껴지는 이유는 이런 상황에서 드러납니다. 키가 있으면 값을 바로 찾을 수 있고, 키가 없으면 없다는 사실을 확인할 수 있습니다.

문제 상황: 설정 이름이 딕셔너리에 있을 때만 값을 꺼내는 기본 패턴을 확인하고 싶습니다. 입력(input): 설정 딕셔너리 config와 찾을 키 learning_rate. 기대 출력(output): 키가 존재하면 해당 설정값이 출력됩니다. 확인할 개념: 딕셔너리는 키 존재 여부를 확인한 뒤 안전하게 값을 꺼낼 수 있습니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 이 예제는 딕셔너리가 키로 값을 찾고 연결하는 방식을 확인합니다.
config = {
    "batch_size": 32,
    "learning_rate": 0.001,
    "epochs": 10,
}

name = "learning_rate"

if name in config:
    print(config[name])

다만 성능을 말할 때는 조심해야 합니다. 딕셔너리는 일반적으로 키 기반 조회에 매우 유용하고 빠른 구조로 쓰이지만, 모든 상황에서 항상 최선이라는 뜻은 아닙니다. 키는 해시 가능(hashable)해야 하고, 데이터의 순서 자체가 중요한 문제라면 리스트나 다른 구조가 더 적합할 수 있습니다.

딕셔너리는 해시맵인가?¶

Python 딕셔너리를 보면 “이것은 해시맵(hash map)인가?”라는 질문이 자연스럽게 생깁니다. 짧게 답하면, 사용 관점에서는 딕셔너리를 키(key)로 값을 찾는 매핑(mapping) 구조로 이해하고, 구현 관점에서는 해시(hash)를 이용하는 자료구조로 이해할 수 있습니다.

하지만 이 절에서는 딕셔너리를 곧바로 “해시맵”이라고만 부르지 않습니다. 이유는 세 가지입니다.

첫째, Python 공식 문서가 딕셔너리를 표준 매핑 타입(mapping type)으로 설명하기 때문입니다. 독자가 먼저 익혀야 하는 관점은 “키를 값에 연결한다”입니다.

둘째, 해시맵이라는 말은 구현 방식에 가까운 표현입니다. 해시(hash), 해시 가능성(hashable), 충돌(collision), 테이블(table) 같은 세부 개념이 따라옵니다. 이 절의 목적은 구현 내부보다 Python 코드를 읽을 때 “왜 위치가 아니라 키로 찾는가”를 이해하는 것입니다.

셋째, Python 딕셔너리는 C++ STL의 여러 컨테이너 중 하나에 그대로 대응되는 이름이 아닙니다. C++의 std::map처럼 키 정렬을 중심으로 이해하면 틀릴 수 있고, multi-index 구조처럼 한 데이터를 여러 인덱스로 동시에 조회하는 구조로 이해해도 과합니다. Python 공식 문서는 딕셔너리의 키가 삽입 순서(insertion order)를 보존한다고 설명하지만, 이것은 키를 정렬한다는 뜻이 아닙니다.

그래도 해시와의 연결은 기억해 둘 필요가 있습니다. Python 딕셔너리의 키는 해시 가능(hashable)해야 합니다. 그래서 문자열, 숫자, 튜플처럼 바뀌지 않는 값은 키로 자주 쓰이지만, 리스트처럼 바뀔 수 있는 값은 보통 딕셔너리 키로 쓸 수 없습니다.

문제 상황: 문자열 키로 점수를 찾는 간단한 딕셔너리 예를 보고 싶습니다. 입력(input): 이름을 키로, 점수를 값으로 둔 scores_by_name. 기대 출력(output): "Kim" 키에 연결된 점수 82. 확인할 개념: 딕셔너리 조회는 안정적인 키를 기준으로 값을 찾는 동작입니다.

1
2
3
4
5
6
7

# 이 예제는 딕셔너리가 키로 값을 찾고 연결하는 방식을 확인합니다.
scores_by_name = {
    "Kim": 82,
    "Lee": 91,
}

print(scores_by_name["Kim"])

이 예시에서 "Kim"은 키이고, Python은 이 키를 이용해 연결된 값을 찾습니다. 내부 구현을 자세히 몰라도, “키로 값을 찾으려면 키가 안정적으로 식별되어야 한다”는 감각은 남겨야 합니다.

또 하나 주의할 점은 같은 키를 여러 번 저장할 수 없다는 점입니다. 같은 키에 새 값을 저장하면 기존 값은 새 값으로 바뀝니다.

문제 상황: 같은 키에 값을 두 번 넣으면 마지막 값만 남는다는 점을 확인하고 싶습니다. 입력(input): 빈 딕셔너리 scores와 "Kim" 키에 대한 두 번의 대입. 기대 출력(output): "Kim" 키에 마지막 값 91만 남은 딕셔너리. 확인할 개념: 하나의 키는 하나의 현재 값만 가리키며 재대입 시 기존 값이 덮어써집니다.

1
2
3
4
5
6
7

# 이 예제는 딕셔너리가 키로 값을 찾고 연결하는 방식을 확인합니다.
scores = {}

scores["Kim"] = 82
scores["Kim"] = 91

print(scores)

이 코드는 "Kim"이라는 키에 두 점수를 모두 보관하지 않습니다. 마지막 값인 91만 남습니다. 한 키에 여러 값을 모으고 싶다면 값(value) 쪽에 리스트를 넣어야 합니다.

문제 상황: 한 사람의 여러 점수를 한 키 아래에 함께 보관하는 방법을 보고 싶습니다. 입력(input): "Kim" 키에 점수 리스트 [82, 91]를 넣은 딕셔너리. 기대 출력(output): "Kim" 키에 연결된 점수 리스트가 출력됩니다. 확인할 개념: 하나의 키에 여러 값을 두려면 값 쪽에 리스트 같은 묶음을 넣어야 합니다.

1
2
3
4
5
6

# 이 예제는 딕셔너리가 키로 값을 찾고 연결하는 방식을 확인합니다.
scores = {
    "Kim": [82, 91],
}

print(scores["Kim"])

따라서 Python 딕셔너리는 “키로 빠르게 접근하기 쉬운 구조”로 체감될 수 있지만, 대용량 데이터를 위한 만능 인덱스 구조는 아닙니다. 데이터가 아주 커지거나 여러 기준으로 동시에 찾아야 하거나 정렬·범위 검색이 중요해지면 데이터베이스, pandas, 별도 인덱스 구조를 검토해야 합니다. 이 절에서는 그 전 단계로, Python 코드에서 가장 자주 만나는 키 기반 매핑 감각을 익힙니다.

여기서는 다음 기준을 기억합니다.

• 리스트는 순서와 위치가 중요할 때 사용합니다.
• 딕셔너리는 키로 값을 찾는 일이 중요할 때 사용합니다.
• 딕셔너리는 설정값, 라벨 맵, 메타데이터처럼 “이름으로 찾는 데이터”에 적합합니다.
• 딕셔너리는 해시 기반 구현과 연결되지만, 이 절에서는 매핑(mapping) 관점으로 먼저 읽습니다.
• 딕셔너리는 키 정렬 트리나 멀티인덱스 구조로 단정하지 않습니다.
• 키별 카운트처럼 반복하면서 딕셔너리에 값을 누적하는 패턴은 P2-8.4에서 다룹니다.

딕셔너리를 쓰는 상황들¶

딕셔너리는 “무엇을 기준으로 값을 찾을 것인가”가 분명할 때 적합합니다.

설정값 묶음¶

문제 상황: 설정 이름으로 학습 설정값을 찾는 전형적인 딕셔너리 사용 예를 보고 싶습니다. 입력(input): batch_size, learning_rate, epochs를 담은 config. 기대 출력(output): learning_rate 값이 출력됩니다. 확인할 개념: 설정 데이터는 순서보다 이름이 중요하므로 딕셔너리와 잘 맞습니다.

1
2
3
4
5
6
7
8

# 이 예제는 딕셔너리가 키로 값을 찾고 연결하는 방식을 확인합니다.
config = {
    "batch_size": 32,
    "learning_rate": 0.001,
    "epochs": 10,
}

print(config["learning_rate"])

설정값은 순서보다 이름이 중요합니다. learning_rate라는 이름으로 값을 찾으면 config[1]처럼 위치로 찾을 때보다 의미가 분명합니다.

라벨 번호를 이름으로 바꾸기¶

문제 상황: 모델의 숫자 라벨을 사람이 읽는 문자열로 바꾸는 예를 보고 싶습니다. 입력(input): 숫자 키와 감성 이름을 연결한 label_map, 예측 라벨 2. 기대 출력(output): neutral 문자열이 출력됩니다. 확인할 개념: 딕셔너리는 라벨 번호와 라벨 이름의 대응표로 자주 쓰입니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# 이 예제는 딕셔너리가 키로 값을 찾고 연결하는 방식을 확인합니다.
label_map = {
    0: "negative",
    1: "positive",
    2: "neutral",
}

predicted_label = 2

print(label_map[predicted_label])

모델 출력이 숫자 라벨일 때, 사람이 읽을 수 있는 이름으로 바꾸는 데 딕셔너리를 사용할 수 있습니다.

샘플 ID로 데이터 찾기¶

문제 상황: 샘플 ID 하나로 해당 데이터의 텍스트를 바로 찾는 구조를 보고 싶습니다. 입력(input): 샘플 ID를 키로, 샘플 정보를 값으로 둔 samples_by_id. 기대 출력(output): "s001"에 대응하는 텍스트 "good product"가 출력됩니다. 확인할 개념: 딕셔너리는 식별자에서 데이터 본문으로 가는 조회 구조로 쓸 수 있습니다.

1
2
3
4
5
6
7
8
9

# 이 예제는 딕셔너리가 키로 값을 찾고 연결하는 방식을 확인합니다.
samples_by_id = {
    "s001": {"text": "good product", "label": "positive"},
    "s002": {"text": "bad service", "label": "negative"},
}

sample_id = "s001"

print(samples_by_id[sample_id]["text"])

데이터가 많아지면 “몇 번째 데이터인가”보다 “어떤 ID의 데이터인가”가 중요해질 수 있습니다. 이때 딕셔너리는 ID에서 샘플로 가는 맵처럼 쓰입니다.

컬럼 이름으로 의미 붙이기¶

문제 상황: 컬럼 이름이 무엇을 뜻하는지 별도 설명표로 관리하는 예를 보고 싶습니다. 입력(input): 컬럼 이름을 설명 문자열에 연결한 column_description. 기대 출력(output): "score" 키에 대한 설명이 출력됩니다. 확인할 개념: 딕셔너리는 메타데이터와 설명 정보를 이름 기준으로 정리하는 데 적합합니다.

1
2
3
4
5
6
7
8

# 이 예제는 딕셔너리가 키로 값을 찾고 연결하는 방식을 확인합니다.
column_description = {
    "text": "입력 문장",
    "label": "정답 라벨",
    "score": "모델 점수",
}

print(column_description["score"])

데이터셋을 읽을 때 컬럼 이름의 의미를 따로 정리해 두면, 이후 전처리와 문서화가 쉬워집니다.

딕셔너리는 오브젝트와 비슷하게 보이지만 같은 말은 아니다¶

지금까지 본 예시 때문에 딕셔너리는 JSON의 객체(object)나 일부 언어의 object 표현과 비슷하게 보일 수 있습니다. 중괄호를 쓰고, 이름으로 값을 찾기 때문입니다. 그래서 API 응답이나 설정 파일을 볼 때 딕셔너리와 객체가 비슷한 모양으로 나타납니다.

하지만 이 절에서는 딕셔너리를 객체(object)라고 부르지 않습니다. Python에서 객체(object)는 더 넓은 말입니다. 숫자, 문자열, 리스트, 딕셔너리, 함수도 모두 객체로 볼 수 있습니다. 반면 딕셔너리는 그중에서도 키(key)를 값(value)에 연결하는 매핑(mapping) 구조입니다.

따라서 딕셔너리는 “가벼운 객체”가 아니라 “키로 값을 찾는 구조”로 먼저 읽는 쪽이 오해가 적습니다. 객체(object), 클래스(class), 메서드(method)는 이 장의 중심 범위를 넘기므로 이후 필요한 시점에 따로 다룹니다.

키가 없을 수 있다는 점을 조심한다¶

딕셔너리에서 없는 키를 바로 꺼내면 오류가 날 수 있습니다.

문제 상황: 존재하지 않는 키를 바로 조회하면 어떤 위험이 있는지 보여 주고 싶습니다. 입력(input): name, score만 가진 student 딕셔너리와 없는 키 "label". 기대 출력(output): 없는 키 조회가 실패하는 예시. 확인할 개념: 딕셔너리는 모든 키가 항상 있다고 가정하면 오류가 날 수 있습니다.

1
2
3
4

# 이 예제는 딕셔너리가 키로 값을 찾고 연결하는 방식을 확인합니다.
student = {"name": "Kim", "score": 82.5}

print(student["label"])

"label"이라는 키가 없기 때문에 이 코드는 실패합니다.

키가 없을 수도 있는 상황에서는 get()을 사용할 수 있습니다.

문제 상황: 없는 키를 조금 더 안전하게 읽는 방법을 확인하고 싶습니다. 입력(input): student.get("label"), student.get("label", "unknown"). 기대 출력(output): 기본적으로 None, 기본값을 주면 "unknown"이 출력됩니다. 확인할 개념: get()은 키가 없을 수 있는 데이터를 다룰 때 안전한 조회 도구입니다.

1
2
3
4
5

# 이 예제는 딕셔너리가 키로 값을 찾고 연결하는 방식을 확인합니다.
student = {"name": "Kim", "score": 82.5}

print(student.get("label"))
print(student.get("label", "unknown"))

데이터 파일이나 API 응답을 다룰 때는 항상 모든 키가 있다고 가정하면 문제가 생길 수 있습니다. 실제 데이터에는 빠진 값, 이름이 다른 값, 예상과 다른 타입이 섞일 수 있습니다.

사례 및 예시¶

사례 1. 라벨 번호를 사람이 읽는 이름으로 바꾸고 싶을 때¶

감성 분류 모델이 예측 결과로 0, 1, 2 같은 숫자만 돌려준다고 하겠습니다. 사람은 이 숫자를 보고 바로 의미를 이해하기 어렵고, 보고서나 화면에는 negative, positive, neutral처럼 이름이 필요합니다.

이때 처음 떠올릴 수 있는 방법은 리스트에 순서대로 넣는 것입니다. 하지만 여기서 중요한 것은 몇 번째 값인가보다 어떤 번호가 어떤 이름에 대응되는가입니다. 즉 위치보다 기준 키가 더 중요합니다.

딕셔너리는 이런 대응표를 읽고 쓰기에 맞는 구조입니다. 0 -> negative, 1 -> positive처럼 키와 값을 연결해 두면, 예측 결과 숫자를 사람이 읽는 이름으로 쉽게 바꿀 수 있습니다. 설정값, 샘플 ID, 컬럼 설명도 같은 방식으로 볼 수 있습니다.

확인 가능한 결과는 예측 라벨 숫자를 넣었을 때 바로 이름이 나오는지입니다. label_map[prediction]으로 원하는 문자열을 얻을 수 있다면, 이 문제는 리스트보다 딕셔너리로 읽는 쪽이 더 자연스럽습니다.

체크리스트¶

• 딕셔너리(dictionary)를 키와 값의 묶음으로 설명할 수 있다.
• 딕셔너리를 매핑(mapping) 구조로 설명할 수 있다.
• 딕셔너리를 사용 관점에서는 매핑(mapping), 구현 관점에서는 해시 기반 구조로 설명할 수 있다.
• 리스트는 위치로, 딕셔너리는 키로 값을 찾는다는 차이를 설명할 수 있다.
• get()이 키가 없을 수 있는 상황에서 유용함을 설명할 수 있다.
• 라벨 맵, 설정값, 샘플 ID 조회, 컬럼 설명 예시를 읽을 수 있다.
• 키가 없을 수 있는 상황에서 조회 방식을 구분할 수 있다.

출처와 참고 자료¶

• Python Software Foundation, Data Structures, Python 3.14.6 documentation, 확인 날짜: 2026-07-20. 딕셔너리 생성, 키로 값에 접근, items()를 이용한 순회 예시 확인에 사용했다.
• Python Software Foundation, Mapping Types — dict, Python 3.14.6 documentation, 확인 날짜: 2026-07-20. dict가 mutable mapping type이며 키를 통해 값을 찾는 구조라는 설명 확인에 사용했다.
• Python Software Foundation, Glossary: dictionary, hashable, Python 3.14.6 documentation, 확인 날짜: 2026-07-20. dictionary와 hashable 용어 정의를 확인하는 근거로 사용했다.
• Python Software Foundation, Data model, Python 3.14.6 documentation, 확인 날짜: 2026-07-20. 객체의 identity/type/value와 hash 가능성 설명을 딕셔너리 키 제약의 배경으로 확인하는 근거로 사용했다.