윤리적 고려사항은 선언문으로 해결되지 않고 측정과 절차로만 관리됩니다. 이 수업에서는 편향이 시스템에 들어오는 지점 중 아키텍트가 통제할 수 있는 것, 공정성을 지표로 다루는 방법, 그리고 투명성을 사용자 경험과 조직 절차로 구현하는 방법을 다룹니다.
편향이 들어오는 지점
편향(bias)을 논할 때 흔히 학습 데이터만 이야기하지만, 아키텍트가 실제로 손댈 수 있는 지점은 따로 있습니다. 시스템에 편향이 유입되는 경로를 나누면 다음과 같습니다.
| 유입 지점 | 아키텍트의 통제 가능성 |
|---|---|
| 모델 학습 데이터 | 낮음 (모델 선택으로만 간접 대응) |
| 프롬프트의 표현 | 높음 |
| 퓨샷 예시의 구성 | 높음 |
| 검색 코퍼스의 구성 | 높음 |
| 평가셋의 구성 | 높음 |
| 임계값과 규칙 | 높음 |
아래 다섯 가지가 실질적인 작업 대상입니다. 예를 들어 퓨샷 예시가 특정 유형의 사례로만 채워져 있으면 모델은 그 유형을 기본값으로 삼습니다. 검색 코퍼스가 특정 지역·언어·부서의 문서에 치우쳐 있으면 그 밖의 질의에 대한 답변 품질이 체계적으로 낮아집니다.
이 두 가지는 코드 리뷰로는 발견되지 않고 데이터 검토로만 드러납니다. 설계 검토 항목에 "퓨샷 예시와 검색 코퍼스의 구성"을 명시적으로 넣어 두는 것이 실무적인 대응입니다.
공정성은 분해 평가로만 보인다
공정성 문제의 핵심은 전체 지표가 집단별 실패를 가린다는 점입니다. 전체 정확도 92%는 어떤 집단에서 60%가 나오고 있어도 그대로 92%일 수 있습니다.
따라서 평가를 설계할 때 분해 축(segment)을 미리 정해야 합니다. 어떤 축으로 나눌지는 시스템의 용도에 따라 다르지만, 흔히 쓰는 축은 다음과 같습니다.
- 입력 언어와 표기 방식
- 지역과 시간대
- 사용자 유형이나 요청 규모
- 데이터의 신선도(최신 문서 대 오래된 문서)
- 요청의 길이와 복잡도
# 전체 지표와 분해 지표를 함께 낸다
overall = accuracy(results)
by_segment = {
seg: accuracy([r for r in results if r.segment == seg])
for seg in SEGMENTS
}
worst = min(by_segment.items(), key=lambda kv: kv[1])
print(f"전체 {overall:.1%} · 최저 구간 {worst[0]} {worst[1]:.1%}")
# 릴리스 기준을 전체가 아니라 최저 구간으로 잡는 것이 핵심이다
assert worst[1] >= MIN_SEGMENT_ACCURACY
마지막 줄이 설계 판단입니다. 릴리스 게이트를 전체 평균이 아니라 최저 구간에 걸면 특정 집단의 품질 저하를 눈감고 배포하는 일을 구조적으로 막을 수 있습니다. 다만 구간을 지나치게 잘게 나누면 표본이 작아 잡음이 커지므로, 구간별 최소 표본 수를 함께 정해야 합니다.
투명성은 세 가지 질문에 답하는 것
투명성을 "모델의 판단 근거를 설명한다"로만 이해하면 실현 불가능한 목표가 됩니다. 실무에서 요구되는 투명성은 사용자의 세 가지 질문에 답하는 것에 가깝습니다.
- AI가 관여했는가 — 응답이 자동 생성되었는지, 사람이 검토했는지를 알립니다.
- 무엇을 근거로 했는가 — 인용과 출처를 제시합니다. 근거를 보여 주는 것이 내부 추론을 설명하는 것보다 실용적이고 검증도 가능합니다.
- 틀렸다면 어떻게 하는가 — 이의 제기와 정정 요청 경로를 제공합니다.
세 번째가 자주 빠집니다. 이의 제기 경로가 없으면 사용자는 잘못된 결과를 받아들이거나 시스템을 떠나는 선택밖에 없고, 조직은 오류를 발견할 기회를 잃습니다. 이의 제기는 사용자 배려이자 품질 신호의 수집 창구라는 관점이 중요합니다.
설명 가능성에 대해서는 현실적인 선을 알아 두어야 합니다. 모델의 내부 계산을 인과적으로 설명하는 것은 현재 기술로 보장할 수 없고, 모델이 생성한 "이유"는 실제 계산 과정의 기록이 아니라 또 하나의 생성물입니다. 시험에서도 모델이 스스로 밝힌 근거를 감사 증거로 그대로 신뢰하는 선택지는 오답으로 나옵니다. 검증 가능한 투명성은 입력·출처·버전·개입 기록처럼 시스템이 관측한 사실에서 나옵니다.
윤리 판단을 조직 절차로 만들기
개별 엔지니어의 양심에 맡기면 판단은 사람과 시점에 따라 달라지고 기록도 남지 않습니다. 아키텍트가 할 일은 판단이 일어나는 자리를 절차 안에 만드는 것입니다.
실무에서 쓰는 장치는 세 가지입니다.
- 용도 등급 분류 — 시스템의 용도를 위험 수준으로 분류하고, 등급별로 요구되는 검토 수준을 정합니다. 사람에게 영향을 주는 결정(채용, 신용, 의료)일수록 높은 등급입니다.
- 검토 게이트 — 설계 단계와 배포 전에 정해진 항목을 점검합니다. 분해 평가 결과, 이의 제기 경로, 사람 개입 지점이 점검 항목에 들어갑니다.
- 결정 기록 — 무엇을 고려했고 무엇을 수용했는지 남깁니다. 잔여 리스크를 수용한 근거가 여기 들어갑니다.
세 번째가 가장 자주 생략되지만 실제로는 가장 유용합니다. 시간이 지나 문제가 제기되었을 때 "고려하지 않았다"와 "고려했고 이런 근거로 수용했다"는 완전히 다른 상황이고, 후자만이 개선의 출발점이 됩니다. 이 기록은 아키텍처 결정 기록(6.2, 6.4)과 같은 형식으로 관리하면 되고, 별도의 윤리 문서를 따로 만들 필요는 없습니다.
시험 함정
- 편향 대응을 모델 선택이나 학습 데이터 문제로만 보는 선택지 — 퓨샷 예시, 검색 코퍼스, 평가셋 구성이 아키텍트의 실질적 통제 지점입니다.
- 전체 정확도가 목표치를 넘으면 공정성 요건을 만족한다는 판단 — 집단별 분해 없이는 특정 구간의 실패가 가려집니다.
- 모델이 생성한 근거 설명을 감사 증거로 그대로 사용하는 설계 — 그 설명은 내부 계산의 기록이 아니라 또 하나의 생성물입니다.
- 투명성을 내부 추론 공개로 정의하는 선택지 — 검증 가능한 투명성은 출처·버전·개입 기록에서 나옵니다.
- 이의 제기 경로를 선택적 기능으로 취급하는 판단 — 오류 발견과 품질 신호 수집의 주요 창구입니다.
- 구간을 잘게 나눌수록 공정성 평가가 정확해진다는 서술 — 구간별 최소 표본 수를 정하지 않으면 잡음이 결론을 지배합니다.
실습 시나리오
실제 시험과 같은 형식의 시나리오 문제입니다.
다국어 고객 문의 분류 시스템을 배포하려 합니다. 전체 정확도는 목표치인 90%를 넘겼고, 검색 코퍼스는 본사에서 작성한 영어 문서가 대부분입니다. 배포 전 점검에서 아키텍트가 우선해야 할 조치는 무엇입니까?
빌드 연습 · 분해 평가와 검토 게이트 구성하기
약 45분1.분해 축 정하기
대상 시스템에서 품질 격차가 생길 수 있는 축을 세 개 이상 정하고 이유를 적습니다.
기대 결과 · 각 축이 시스템의 용도와 연결되어 설명됩니다.
2.구간별 표본 확보
각 구간에 최소 표본 수를 정하고 평가셋이 그 기준을 충족하는지 확인합니다.
기대 결과 · 표본이 부족한 구간이 식별되고 보강 계획이 적힙니다.
3.최저 구간 게이트 구현
릴리스 검사에 최저 구간 정확도 기준을 추가합니다.
기대 결과 · 전체 평균이 목표를 넘어도 최저 구간이 미달이면 실패합니다.
4.코퍼스 구성 점검
검색 코퍼스와 퓨샷 예시의 구성을 분해 축 기준으로 집계합니다.
기대 결과 · 특정 구간에 치우친 부분이 수치로 드러납니다.
5.결정 기록 남기기
수용하기로 한 잔여 격차와 그 근거, 재검토 시점을 기록합니다.
기대 결과 · 기록에 이의 제기 경로와 재측정 주기가 포함되어 있습니다.