쿠버네티스 보안 강화 전략: 컨테이너 런타임부터 RBAC 최적화까지 심층 분석

쿠버네티스 환경의 보안 취약점을 분석하고, 컨테이너 런타임 보호, 네트워크 정책, RBAC 최적화 등 실질적인 보안 강화 전략을 비교 분석하여 안전한 클라우드 인프라 구축 방안을 제시합니다.

클라우드 네이티브 환경의 핵심 기술인 쿠버네티스(Kubernetes)는 수많은 기업과 개발팀에게 혁신적인 유연성과 확장성을 제공하고 있습니다. 하지만 이러한 복잡한 분산 시스템은 그만큼 다양한 보안 위협에 노출될 수밖에 없습니다. 컨테이너 이미지 취약점부터 네트워크 침투, API 서버 오용에 이르기까지, 쿠버네티스 보안은 단순한 설정 문제를 넘어선 다층적인 접근을 요구합니다.

그렇다면 우리는 복잡한 쿠버네티스 환경에서 어떻게 하면 보안 취약점을 효과적으로 방어하고, 안정적인 서비스를 유지할 수 있을까요? 이 글에서는 컨테이너 런타임 보호부터 네트워크 정책, RBAC 최적화에 이르는 핵심 보안 전략들을 심층적으로 분석하고, 각 전략의 장단점과 실질적인 적용 방안을 제시하여 안전한 쿠버네티스 인프라 구축을 위한 가이드라인을 제공하고자 합니다.

📑 목차

• 컨테이너 런타임 보안 강화: 실행 환경 보호의 첫걸음
• 런타임 보안 도구 비교 및 활용
• 컨테이너 이미지 보안: 신뢰할 수 있는 소스부터 배포까지
• 쿠버네티스 네트워크 정책 최적화: 마이크로 세그멘테이션 구현
• 기본 네트워크 정책 이해 및 적용
• 고급 네트워크 정책 적용 사례 및 CNI 비교
• RBAC(Role-Based Access Control) 심화와 최적화: 권한 관리의 핵심
• RBAC 권한 모델 설계 및 일반적인 실수 방지
• RBAC 권한 감사 및 모니터링
• API 서버 보안 및 기타 핵심 요소: 클러스터의 중추 보호
• API 서버 인증 및 권한 부여 강화
• 시크릿(Secret) 관리와 감사
• 지속적인 보안 운영 및 모니터링: 보안은 과정이다
• 보안 취약점 스캔 및 패치 관리
• 보안 이벤트 로깅 및 분석, 경고 시스템 구축

Image by analogicus on Pixabay

컨테이너 런타임 보안 강화: 실행 환경 보호의 첫걸음

쿠버네티스 클러스터에서 컨테이너 런타임은 애플리케이션이 실제로 실행되는 핵심 영역입니다. 이 영역의 보안은 전체 시스템의 안정성에 직결됩니다. 컨테이너 런타임 환경을 효과적으로 보호하기 위해서는 여러 계층의 접근이 필요합니다.

런타임 보안 도구 비교 및 활용

컨테이너 런타임 보안을 강화하는 데는 다양한 도구와 기술이 활용됩니다. 대표적으로는 시스템 호출(syscall)을 모니터링하고 비정상적인 행위를 탐지하는 도구, 그리고 컨테이너의 권한을 최소화하는 기술들이 있습니다.

구분	Falco	AppArmor/SELinux	gVisor/Kata Containers
주요 기능	시스템 호출 기반 런타임 보안 모니터링 및 위협 탐지	강제적 접근 제어(MAC)를 통한 프로세스 및 파일 접근 제한	독립적인 커널 또는 경량 VM을 통해 컨테이너 격리 강화
장점	실시간 위협 탐지 및 경고 유연한 규칙 정의 가능 쿠버네티스 이벤트와 연동 용이	운영체제 레벨의 강력한 보안 세밀한 권한 제어 가능 낮은 성능 오버헤드	컨테이너 탈출(Container Escape) 방지 강력한 격리 보장 멀티테넌트 환경에 적합
단점	초기 규칙 설정 및 튜닝 필요 오탐(False Positive) 발생 가능성	프로파일 작성 및 관리 복잡성 운영체제 종속적 기존 애플리케이션과의 호환성 문제	상대적으로 높은 성능 오버헤드 일부 애플리케이션 호환성 문제 리소스 사용량 증가
적용 시점	런타임 중 비정상 행위 감지 및 대응	컨테이너 배포 전 권한 제어 적용	고도의 격리가 필요한 워크로드 배포 시

Falco는 컨테이너 내부에서 발생하는 시스템 호출 이벤트를 실시간으로 분석하여 잠재적인 위협을 탐지합니다. 예를 들어, 컨테이너 내부에서 예상치 못한 파일 쓰기 작업이나 네트워크 연결 시도 등을 감지하여 경고를 발생시킬 수 있습니다. 다음은 특정 디렉토리에 실행 파일이 생성되는 것을 감지하는 Falco 규칙의 예시입니다.

- rule: Detect new executable in sensitive directory
  desc: An executable was created in a sensitive directory
  condition: >
    (evt.type=creat or evt.type=open or evt.type=openat) and evt.dir=< and fd.name startswith "/etc/" and fd.name contains "/" and fd.name endswith ".conf" and fd.type=file and fd.is_exe=true
  output: >
    Executable file created in sensitive directory (user=%user.name command=%proc.cmdline file=%fd.name)
  priority: WARNING
  tags: [filesystem, sensitive]
    

AppArmor나 SELinux는 컨테이너가 호스트 시스템 자원에 접근하는 방식을 엄격하게 제한하는 강제적 접근 제어(MAC) 프레임워크입니다. 이를 통해 컨테이너 탈출 공격의 위험을 줄이고, 컨테이너가 불필요한 권한을 가지지 않도록 할 수 있습니다. 예를 들어, 웹 서버 컨테이너가 특정 포트와 웹 루트 디렉토리 외의 다른 자원에 접근하지 못하도록 프로파일을 정의할 수 있습니다.

gVisor나 Kata Containers와 같은 기술은 컨테이너를 경량 가상 머신(VM)이나 독립적인 커널 환경에서 실행하여 호스트 커널로부터의 격리 수준을 한층 더 높입니다. 이는 멀티테넌트 환경이나 고도의 보안이 요구되는 워크로드에 적합하며, 컨테이너 탈출 공격의 가능성을 최소화합니다.

컨테이너 이미지 보안: 신뢰할 수 있는 소스부터 배포까지

컨테이너 런타임 보안의 출발점은 바로 안전한 컨테이너 이미지입니다. 취약점이 포함된 이미지는 배포되는 순간부터 잠재적인 위협이 됩니다.

• 이미지 스캐닝: Trivy, Clair, Anchore와 같은 도구를 사용하여 이미지를 빌드하는 과정에서 취약점을 자동으로 스캔하고, 알려진 취약점(CVE)이 있는 경우 배포를 차단해야 합니다.
• 신뢰할 수 있는 레지스트리 사용: 검증된 컨테이너 레지스트리(예: Harbor, AWS ECR, Google Container Registry)를 사용하고, 이미지 서명 및 무결성 검증을 통해 변조된 이미지가 배포되는 것을 방지해야 합니다.
• 최소한의 베이스 이미지 사용: 가능한 한 가볍고 필요한 구성 요소만 포함된 베이스 이미지(예: Alpine Linux 기반 이미지)를 사용하여 공격 표면을 줄여야 합니다.
• 정기적인 이미지 업데이트: 사용 중인 이미지의 베이스 운영체제 및 라이브러리 취약점에 대한 패치를 주기적으로 적용하여 최신 보안 상태를 유지해야 합니다.

쿠버네티스 네트워크 정책 최적화: 마이크로 세그멘테이션 구현

쿠버네티스 클러스터의 기본 네트워크 모델은 모든 파드(Pod)가 서로 통신할 수 있는 평탄한 네트워크(Flat Network) 구조를 가집니다. 이는 개발 편의성을 높이지만, 한 파드가 침해당했을 때 네트워크 전체로 위협이 확산될 수 있는 단점을 가집니다. 이를 방지하기 위해 쿠버네티스 네트워크 정책(NetworkPolicy)을 활용한 마이크로 세그멘테이션이 필수적입니다.

기본 네트워크 정책 이해 및 적용

NetworkPolicy는 파드 간의 네트워크 트래픽을 제어하는 쿠버네티스 리소스입니다. 인그레스(Ingress) 및 이그레스(Egress) 규칙을 정의하여 어떤 파드가 어떤 파드와 통신할 수 있는지 명확하게 지정할 수 있습니다. 기본적으로 네트워크 정책이 없는 파드는 모든 인그레스 및 이그레스 트래픽을 허용합니다.

네트워크 정책을 적용할 때는 최소 권한 원칙(Principle of Least Privilege)을 따르는 것이 중요합니다. 즉, 필요한 통신만 허용하고 나머지는 모두 차단하는 기본 차단(Default Deny) 정책을 시작점으로 삼는 것이 좋습니다. 이는 네임스페이스(Namespace) 또는 클러스터 전체에 적용될 수 있습니다.

다음은 특정 네임스페이스 내에서 app=backend 레이블을 가진 파드에 대해 app=frontend 레이블을 가진 파드로부터의 인그레스 트래픽만 허용하는 네트워크 정책 예시입니다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-access
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080
    

고급 네트워크 정책 적용 사례 및 CNI 비교

네트워크 정책은 단순히 파드 간 통신을 제어하는 것을 넘어, 서비스 메시(Service Mesh)와 연동하여 더욱 세밀한 제어가 가능합니다. Calico, Cilium, Kube-router 등 다양한 CNI(Container Network Interface) 플러그인들은 쿠버네티스 NetworkPolicy를 구현하며, 각각 고유한 고급 기능을 제공합니다.

구분	Calico	Cilium
기반 기술	IP 기반 라우팅 및 BGP	eBPF(extended Berkeley Packet Filter)
네트워크 정책	쿠버네티스 NetworkPolicy 지원 Calico Global NetworkPolicy (클러스터 전체 정책)	쿠버네티스 NetworkPolicy 지원 CiliumNetworkPolicy (L7 정책, ID 기반 정책)
주요 장점	광범위한 배포 및 성숙도 네트워크 가상화 기능 (IP-in-IP, VXLAN) 간편한 설정 및 관리	고성능 및 저지연 L7 정책(HTTP, Kafka 등) 지원 ID 기반 보안(Sidecarless Service Mesh) 런타임 보안 기능 통합
고려 사항	L7 정책은 별도의 서비스 메시 통합 필요 복잡한 환경에서 라우팅 설정 필요	eBPF에 대한 이해 필요 상대적으로 높은 시스템 요구 사항

Calico는 강력한 네트워크 정책 기능을 제공하며, 쿠버네티스 NetworkPolicy 외에 GlobalNetworkPolicy를 통해 클러스터 전체에 걸친 보안 규칙을 정의할 수 있습니다. 이는 특정 IP 범위로부터의 접근을 차단하거나, 특정 포트에 대한 트래픽을 제한하는 등 클러스터의 외부 통신을 제어하는 데 유용합니다.

Cilium은 eBPF 기술을 활용하여 높은 성능과 함께 L7(애플리케이션 계층) 네트워크 정책을 지원합니다. 이는 HTTP 요청 경로, 헤더, Kafka 토픽 등 애플리케이션 수준의 세부적인 통신 제어를 가능하게 합니다. 예를 들어, 특정 서비스로의 HTTP GET 요청만 허용하고 POST 요청은 차단하는 등의 정책을 구현할 수 있습니다.

네트워크 정책을 효과적으로 사용하기 위해서는 다음과 같은 전략을 고려해야 합니다.

• 네임스페이스 격리: 각 애플리케이션 또는 환경(개발, 스테이징, 운영)별로 별도의 네임스페이스를 사용하고, 네임스페이스 간의 통신을 엄격하게 제어합니다.
• 정책 시뮬레이션: Kube-OVN의 ovn-trace와 같은 도구를 사용하여 네트워크 정책이 실제로 어떻게 작동할지 시뮬레이션하여 의도치 않은 서비스 중단을 방지합니다.
• 정기적인 감사: 배포된 네트워크 정책이 여전히 유효하고, 불필요한 예외를 허용하고 있지 않은지 주기적으로 검토합니다.

Image by haalkab on Pixabay

RBAC(Role-Based Access Control) 심화와 최적화: 권한 관리의 핵심

RBAC(Role-Based Access Control)는 쿠버네티스에서 사용자 및 서비스 어카운트(Service Account)가 클러스터 리소스에 접근할 수 있는 권한을 제어하는 핵심 메커니즘입니다. 최소 권한 원칙에 따라 RBAC를 올바르게 설정하는 것은 보안 침해를 막는 데 매우 중요합니다.

RBAC 권한 모델 설계 및 일반적인 실수 방지

쿠버네티스 RBAC는 Role (네임스페이스 범위), ClusterRole (클러스터 범위), RoleBinding, ClusterRoleBinding의 네 가지 기본 리소스로 구성됩니다. Role은 특정 네임스페이스 내에서 리소스에 대한 권한을 정의하고, ClusterRole은 클러스터 전체 리소스에 대한 권한을 정의합니다. RoleBinding과 ClusterRoleBinding은 이러한 Role을 사용자 또는 서비스 어카운트에 연결합니다.

RBAC 모델을 설계할 때 가장 중요한 것은 최소 권한 원칙을 철저히 지키는 것입니다. 즉, 사용자나 애플리케이션이 자신의 작업을 수행하는 데 필요한 최소한의 권한만 부여해야 합니다. 과도한 권한은 보안 사고 발생 시 피해 범위를 크게 확대시킬 수 있습니다.

일반적으로 저지르는 실수로는 다음과 같은 것들이 있습니다.

• 와일드카드(*) 권한 남용: 특히 ClusterRoleBinding에서 * (모든 리소스, 모든 동사) 권한을 부여하는 것은 매우 위험합니다. 이는 사실상 클러스터 관리자 권한을 부여하는 것과 같습니다.
• 기본 서비스 어카운트 사용: 파드에 기본 서비스 어카운트(default ServiceAccount)를 사용하는 것은 권장되지 않습니다. 각 파드에 필요한 최소 권한을 가진 별도의 서비스 어카운트를 생성해야 합니다.
• 권한 감사 부재: RBAC 설정을 변경한 후에도 정기적인 감사 없이 방치하는 경우, 불필요하거나 과도한 권한이 누적될 수 있습니다.

다음은 특정 네임스페이스 내에서 파드를 읽을 수 있는 최소한의 권한을 부여하는 Role 및 RoleBinding 예시입니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: my-namespace
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods-in-my-namespace
  namespace: my-namespace
subjects:
- kind: User
  name: developer-user # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
    

RBAC 권한 감사 및 모니터링

RBAC 설정은 시간이 지남에 따라 복잡해지고 잘못될 수 있으므로, 정기적인 감사와 모니터링이 필수적입니다.

• kubectl auth can-i 사용: 특정 사용자 또는 서비스 어카운트가 특정 작업을 수행할 수 있는지 확인하는 데 유용합니다.

  
  kubectl auth can-i create pods --as=developer-user -n my-namespace
              

• Kube-bench, Polaris: CIS 벤치마크 기반의 보안 감사 도구들은 RBAC 설정의 취약점을 탐지하고 권장 사항을 제공합니다.
• 감사 로그 분석: 쿠버네티스 API 서버의 감사 로그(Audit Logs)를 통해 어떤 사용자가 어떤 리소스에 접근했는지 기록하고 분석하여 비정상적인 접근 패턴을 탐지할 수 있습니다.
• 권한 검토 프로세스: 새로운 Role 또는 ClusterRole을 생성하거나 기존 권한을 수정할 때, 반드시 보안 및 운영팀의 검토를 거치는 프로세스를 수립해야 합니다.

Image by stevepb on Pixabay

API 서버 보안 및 기타 핵심 요소: 클러스터의 중추 보호

쿠버네티스 API 서버는 클러스터의 모든 통신과 제어가 이루어지는 중앙 지점입니다. API 서버의 보안은 클러스터 전체의 보안을 좌우하므로, 철저한 보호가 필요합니다.

API 서버 인증 및 권한 부여 강화

API 서버는 다양한 인증(Authentication) 및 권한 부여(Authorization) 메커니즘을 지원합니다.

• TLS(Transport Layer Security) 사용: API 서버와 모든 클라이언트 간의 통신은 반드시 TLS를 통해 암호화되어야 합니다.
• 강력한 인증 방식:
  • X.509 클라이언트 인증서: 관리자 및 자동화 도구에 강력한 인증을 제공합니다.
  • 서비스 어카운트 토큰: 파드 내에서 API 서버에 접근할 때 사용되며, RBAC와 연동하여 세밀한 권한 제어가 가능합니다.
  • OIDC(OpenID Connect): 기존 기업의 ID 공급자(IdP)와 연동하여 통합된 사용자 인증을 구현할 수 있습니다.
• 어드미션 컨트롤러(Admission Controllers): API 서버로 들어오는 요청을 가로채서 유효성을 검사하거나 특정 정책을 강제할 수 있습니다. Pod Security Admission은 파드의 보안 컨텍스트를 강제하여 권한 상승 공격을 방지하는 데 필수적입니다. OPA(Open Policy Agent)나 Kyverno와 같은 정책 엔진을 활용하여 더욱 복잡하고 세밀한 사용자 정의 정책을 적용할 수 있습니다.

예를 들어, Pod Security Admission을 사용하여 특정 네임스페이스에 restricted 프로파일을 적용하여 보안 수준을 높일 수 있습니다.

apiVersion: v1
kind: Namespace
metadata:
  name: sensitive-app
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/audit: restricted
    

시크릿(Secret) 관리와 감사

데이터베이스 비밀번호, API 키, 인증서 등 민감한 정보는 쿠버네티스 시크릿(Secret)으로 관리됩니다. 시크릿은 기본적으로 Base64로 인코딩되어 저장되지만, 이는 암호화가 아니므로 추가적인 보안 조치가 필요합니다.

• etcd 암호화: 쿠버네티스 클러스터의 백엔드 데이터 저장소인 etcd에 저장되는 시크릿은 반드시 미사용 암호화(Encryption at Rest)를 통해 보호되어야 합니다. 이는 EncryptionConfiguration을 통해 구성할 수 있습니다.
• 외부 시크릿 관리 도구 연동: HashiCorp Vault, AWS Secrets Manager, Google Secret Manager와 같은 외부 시크릿 관리 도구와 연동하여 시크릿을 중앙에서 안전하게 관리하고, 쿠버네티스 파드에 필요할 때만 주입하는 방식을 고려할 수 있습니다. Sealed Secrets와 같은 도구는 GitOps 환경에서 암호화된 시크릿을 안전하게 저장하고 배포하는 데 유용합니다.
• 시크릿 접근 감사: 누가 어떤 시크릿에 접근했는지 감사 로그를 통해 추적하고, 비정상적인 접근 시도를 탐지해야 합니다.

지속적인 보안 운영 및 모니터링: 보안은 과정이다

쿠버네티스 보안은 일회성 프로젝트가 아니라 지속적인 운영과 모니터링이 필요한 과정입니다. 새로운 취약점은 끊임없이 발견되며, 클러스터 구성도 변화하기 때문입니다.

보안 취약점 스캔 및 패치 관리

클러스터 구성 요소, 노드 운영체제, 컨테이너 이미지 등 모든 계층에서 지속적인 취약점 스캔을 수행하고 적절한 패치를 적용하는 것이 중요합니다.

• 컨테이너 이미지 스캐닝 자동화: CI/CD 파이프라인에 Trivy, Clair와 같은 이미지 스캐너를 통합하여 새로운 이미지가 빌드될 때마다 자동으로 취약점을 검사하고, 심각한 취약점이 발견되면 배포를 차단해야 합니다.
• 노드 운영체제 보안: 쿠버네티스 노드로 사용되는 서버의 운영체제(예: Ubuntu, CentOS)도 정기적으로 보안 패치를 적용하고, 불필요한 서비스는 비활성화하며, CIS 벤치마크와 같은 보안 가이드라인에 따라 강화해야 합니다.
• 쿠버네티스 버전 업데이트: 쿠버네티스 자체도 지속적으로 보안 패치와 개선 사항이 릴리스됩니다. 안정적인 최신 버전으로 주기적으로 업데이트하여 알려진 취약점을 해결해야 합니다.
• 런타임 취약점 관리: Falco와 같은 도구를 활용하여 런타임 중 발생하는 비정상적인 행위를 탐지하고, 이를 통해 제로데이 공격이나 알려지지 않은 취약점 악용 시도를 조기에 발견할 수 있습니다.

보안 이벤트 로깅 및 분석, 경고 시스템 구축

클러스터에서 발생하는 모든 보안 관련 이벤트를 중앙 집중식으로 로깅하고 분석하여 잠재적인 위협을 식별하고 대응해야 합니다.

• 통합 로깅: 쿠버네티스 감사 로그, 컨테이너 로그, 노드 시스템 로그를 모두 수집하여 ELK 스택(Elasticsearch, Logstash, Kibana) 또는 Fluentd, Prometheus, Grafana와 같은 도구를 통해 중앙에서 관리하고 시각화합니다.
• 감사 로그(Audit Logs) 활용: 쿠버네티스 API 서버의 감사 로그는 모든 API 요청에 대한 상세 정보를 제공합니다. 이를 통해 누가, 언제, 무엇을, 어떻게 했는지 추적하여 보안 침해 사고 발생 시 원인 분석에 결정적인 역할을 합니다. 감사 로그를 SIEM(Security Information and Event Management) 시스템과 연동하여 고급 분석을 수행할 수 있습니다.
• 보안 이벤트 모니터링 및 경고: 정의된 보안 규칙이나 임계값을 위반하는 이벤트가 발생하면 Slack, PagerDuty, 이메일 등 적절한 채널을 통해 즉시 담당자에게 경고를 보내는 시스템을 구축해야 합니다. 예를 들어, 실패한 로그인 시도가 일정 횟수 이상 발생하거나, 민감한 리소스에 대한 비정상적인 접근 시도가 있을 경우 경고를 발생시킬 수 있습니다.
• 침해 사고 대응 계획: 보안 사고 발생 시 신속하고 체계적으로 대응할 수 있는 침해 사고 대응(Incident Response) 계획을 수립하고, 정기적으로 모의 훈련을 통해 대응 능력을 강화해야 합니다.

결론적으로, 쿠버네티스 보안은 단일 솔루션으로 해결될 수 있는 문제가 아닙니다. 컨테이너 런타임 보호, 네트워크 정책, RBAC 최적화, API 서버 보안, 그리고 지속적인 모니터링과 감사에 이르는 다층적인 방어 전략을 통합적으로 구축해야 합니다. 각 보안 계층의 장단점을 명확히 이해하고, 우리 조직의 특정 요구사항과 위험 프로파일에 맞춰 최적의 솔루션과 정책을 적용하는 것이 중요합니다. 견고한 쿠버네티스 보안은 단순히 위협을 방어하는 것을 넘어, 클라우드 네이티브 환경의 잠재력을 최대한 발휘할 수 있는 안정적인 기반을 제공할 것입니다.

이 글에 대한 여러분의 생각이나 추가적인 보안 팁이 있다면 댓글로 공유해 주세요! 여러분의 경험과 지식이 더욱 풍부한 논의를 이끌어낼 수 있습니다.

📌 함께 읽으면 좋은 글

• [클라우드 인프라] 서버리스 아키텍처 비용 최적화: 효율적인 애플리케이션 설계 및 운영 노하우
• [클라우드 인프라] 서버리스 아키텍처 심층 분석: AWS Lambda와 API Gateway로 고성능 백엔드 구축 전략
• [클라우드 인프라] 클라우드 비용 최적화 실전 가이드: AWS/GCP/Azure 리소스 효율화와 FinOps 전략

이 글이 도움이 되셨다면 공감(♥)과 댓글로 응원해 주세요!
궁금한 점이나 다루었으면 하는 주제가 있다면 댓글로 남겨주세요.