첫 인프라 담당자로 살아남기: 시작, 계획, 계정 관리

들어가며

안녕하세요, 노머스에서 인프라 엔지니어로 합류한 박지영입니다.

우리 회사는 개발자 중심으로 빠르게 성장해왔습니다.
서비스를 만들고, 출시하고, 사용자 피드백을 받는 것이 최우선이었고,
그 과정에서 인프라는 각자가 필요한 만큼 만들고, 필요할 때 직접 고쳤습니다.

누구도 잘못한 사람은 없었습니다.
모두가 최선을 다했기에
적은 리소스로도 빠르게 시장에 도달할 수 있었습니다.

그러나 회사가 커지고, 서비스가 늘고, 사람이 많아지면서
이전까지는 문제되지 않던 것들이 점점 표면 위로 드러나기 시작했을 겁니다.

• “우리 클라우드 계정들, 지금 누가 무슨 권한으로 쓰고 있지?”
• “이 서비스, 어느 네트워크에서 어떻게 돌아가는지 다들 아는 거 맞나?”
• “이번 달 클라우드 비용, 왜 이렇게 많이 나왔지?”

이런 질문들이 하나둘 쌓이면서,
결국 인프라를 전담할 사람이 필요해졌고,
그렇게 저는 회사의 첫 인프라 담당자가 되었습니다.

그 이후 제가 어떤 일들을 겪었고, 또 어떻게 하나씩 해결해 나갔는지 이야기해보려 합니다.

그 중에서도 이번 글에서는 제가 가장 먼저 마주한 문제이자,
인프라 운영의 출발점이었던 계정 관리 현황 을 어떻게 파악하고 정리해 나갔는지에 집중하려고 합니다.

내가 생각하는 인프라 엔지니어의 역할

저는 대고객 서비스를 하는 회사에서의 인프라 엔지니어 역할을
단순히 서버나 클라우드를 관리하는 일로만 보지 않습니다.

왜냐하면 서버나 클라우드 관리만으로도 개발자들이 충분히 할 수 있기 때문입니다.

제가 합류하기 전까지도 개발팀은 인터넷에서 필요한 정보를 찾아보거나,
AI 등을 활용하여 문제를 충분히 잘 해결해왔었다고 생각합니다.

또한, PaaS나 서버리스 같은 서비스를 이용하면
많은 부분은 애초에 관리할 필요조차 없게 만들 수 있고,
정말 어렵다면 MSP 같은 외부 도움을 받는 선택지도 있기 때문입니다.

그런데도 회사는 저를 인프라 엔지니어로 채용했습니다.
그렇다면 회사가 기대하는 바는 단순한 서버나 클라우드 관리가 아닐 것입니다.

그래서 저는 인프라 엔지니어의 역할을 이렇게 정의하게 되었습니다.

• 계정, 네트워크, 비용 같은 핵심 자원들을 하나하나 보살피는 사람
• 그 안에서 운영의 기준과 체계를 만들어가는 사람
• 서비스와 조직이 성장할 수 있는 기반을 다져나가는 사람.

저는 이 일을 그런 마음가짐으로 맡고 있습니다.

처음 만든 인프라 계획

저는 인프라 운영의 방향성과 실행 계획을 세우게 되었습니다.

처음 세운 계획의 핵심은 세 가지였습니다.

첫째, 계정 관리입니다.

누가 어떤 권한을 가지고 무엇을 할 수 있는지 명확히 하고,
불필요한 접근 권한은 줄이며, 관리와 감사를 위한 기준을 마련하는 것이 목표였습니다.

둘째, 네트워크 설계입니다.

서비스별로 운영 환경과 개발 환경을 분리하고,
보안 그룹, 라우팅, VPN 같은 요소들을 통해
안전하고 효율적인 네트워크 구성을 만드는 방향으로 잡았습니다.

셋째, 비용 분석과 최적화입니다.

태그 체계를 정리해 서비스 별 비용을 가시화하고,
불필요한 리소스를 찾아내거나, 아키텍처 차원에서 비용을 줄일 수 있는 방안을 고민했습니다.

이러한 계획들은 단순히 관리 매뉴얼을 만드는 것을 넘어서,
우리 회사 인프라의 기반을 마련하고 앞으로 성장할 수 있는 틀을 만드는 데 초점을 맞췄습니다.

사실 이런 부분들 중 상당수는 이미 어느 정도 진행되어 있었습니다.

그래서 저는 제가 보기에 아직 다듬을 여지가 있는 부분들을 하나하나 채워나가고,
제 경험을 살려 더 체계적이고 구체적인 방식으로 발전시켜야겠다고 생각했습니다.

아무것도 정해진 것이 없는 환경에서 그 역할을 처음 맡는다는 건
무거운 책임감이 먼저 밀려옵니다.

하지만 이런 기회는 누구에게나 주어지는 건 아니라고 생각했고,
그만큼 어떻게 시작하느냐가 중요하다는 마음으로 임했습니다.

그 시작이 단순히 지금만을 위한 관리가 아니라,
앞으로 올 사람들을 위한 기준과 방향을 세우는 일이라고 생각했기 때문입니다.

계정 관리, 현황을 가시화하는 것부터

제가 합류한 시점은 이미 많은 것들이 진행된 뒤였습니다.

그래서 저는 처음부터 완벽히 정리하려 하기보다는,
현재 상태를 하나하나 이해하고 부족한 부분을 살펴보는 데 집중해야 한다고 생각했습니다.

그 중에서 가장 먼저 떠올린 건 인사 관리 시스템이었습니다.
어떤 업무든, 그 전에 먼저 회사의 일원이 되어야 시작할 수 있기 때문입니다.

우리 회사의 인사 관리 시스템은 Flex였습니다.

Flex – HR Service as a Software

Flex에 로그인할 때부터 Google 계정을 기반으로 인증이 이루어진다는 점이 눈에 띄었습니다.
이 말은 결국, 모든 계정 관리의 출발점이 Google Workspace 라는 뜻이었습니다.

다만 이 영역은 인사팀에서 직접 관리하고 있었기에,
제가 바로 개입할 수는 없었고,
일단은 현재 어떤 계정들이 존재하는지 파악하는 것부터 시작하기로 했습니다.

Terraform으로 시작한 인프라 자동화

권한을 받아 Google Admin 콘솔에 접속해 계정과 권한 현황 파악을 시작했습니다.

회사의 구글 계정과 그룹 계정들에 대한 정보들을 Google Sheets에 수작업으로 정리하고 있었습니다.

하지만 혼자서 일하는 상황에서 하나하나 수동으로 정리하는 건 너무 비효율적이라고 느꼈습니다.
무엇보다 저도 사람이기에, 실수하거나 놓치는 부분이 생길 수 있다는 점도 계속 우려되었습니다.

그래서 인프라를 코드로 관리해야겠다고 생각했습니다.

Terraform

Terraform은 HashiCorp에서 만든 인프라를 코드로 관리하는 도구 (IaC: Infrastructure as Code)입니다.

클라우드, 온프레미스, SaaS 등 다양한 환경의 인프라 리소스를 코드로 선언하고,
그 선언 상태를 기준으로 자동으로 생성, 변경, 삭제할 수 있게 해줍니다.

현황 파악을 자동화할 수 있는 도구는 여러 가지가 있지만,
저는 Terraform을 선택했습니다.

이유는 명확했습니다.

• 현재 인프라 구성이 코드로 명시되어 누구나 파악할 수 있음
• Git 같은 버전 관리 시스템으로 변경 이력을 추적할 수 있음
• 현황 파악뿐만 아니라 본래 목적인 리소스 관리까지도 확장 가능함
• 다양한 플랫폼을 하나의 도구로 관리할 수 있음

그렇게 저는 Terraform으로 코드를 작성하기 시작했습니다.

Google Workspace 계정 현황 파악 시작

본격적으로 Terraform 코드를 통해 Google Workspace 계정 현황 파악을 시작했습니다.

Terraform - Google Workspace Provider

Terraform에서 Google Workspace Provider를 사용하려면,
Google Cloud와 Google Workspace의 사전 설정이 필요했습니다.

서비스 계정을 만들고, 필요한 OAuth 권한을 부여하고,
관리자 계정으로의 위임 설정까지 마쳐야
Terraform 코드로 Google Workspace의 읽기 작업이 가능했습니다.
(참조: Manage your Google Workspace organization)

아래 코드는 해당 작업을 Terraform으로 구현한 예시입니다.

# Google Workspace Provider 설정
provider "googleworkspace" {
  customer_id             = "***"  # Google Workspace customer ID (조직 식별자)
  impersonated_user_email = "jiyoung.park@wonderwall.kr"  # API 호출 시 사용할 관리자 계정 이메일

  credentials = pathexpand(
    "/Users/jiyoung.park/.google/credentials/wonderwall-infra-00.json"
  )  # 서비스 계정 JSON 키 파일 경로

  oauth_scopes = [
    "https://www.googleapis.com/auth/admin.directory.domain.readonly",         # 도메인 읽기 전용
    "https://www.googleapis.com/auth/admin.directory.rolemanagement.readonly", # 역할 관리 읽기 전용
    "https://www.googleapis.com/auth/admin.directory.orgunit",                 # 조직 단위 읽기/쓰기
    "https://www.googleapis.com/auth/admin.directory.group",                   # 그룹 읽기/쓰기
    "https://www.googleapis.com/auth/admin.directory.user"                     # 사용자 읽기/쓰기
  ]  # Google API 호출에 필요한 OAuth 스코프 목록
}

# Google Workspace 사용자 전체 목록 가져오기
data "googleworkspace_users" "this" {
  provider = googleworkspace
}

# 가져온 사용자 목록에서 primary_email(이메일)별로 개별 user 데이터 소스 생성
data "googleworkspace_user" "email" {
  provider = googleworkspace

  for_each = toset([
    for user in data.googleworkspace_users.this.users
    : user.primary_email  # 각 사용자의 이메일 주소 추출
  ])

  primary_email = each.value  # 개별 user 데이터 소스의 primary_email 설정
}
...

이렇게 해서 Google Workspace 계정 목록을 확인할 수 있었고,
Terraform을 통해 가시성을 확보할 수 있었습니다.

공식 Provider로는 부족한 부분들

Terraform을 사용하다 보면, 공식 프로바이더에서 지원하지 않는 경우가 있습니다.

예를 들어, Google Workspace 사용자별 MFA(다단계 인증) 상태를 조회해야 했는데,
공식 Google Workspace 프로바이더에는 이를 제공하는 리소스나 데이터 소스가 없었습니다.

저는 이 문제를 해결하기 위해 external을 활용했습니다.

Terraform - external

external 데이터 소스는 Terraform 외부에서 실행된 스크립트의 출력을 Terraform에 값으로 넘겨줄 수 있도록 도와줍니다.

아래 코드는 해당 작업을 구현한 Bash 스크립트 예시입니다.

#!/bin/bash

set -euo pipefail  # 에러 발생 시 즉시 종료, unset 변수 사용 금지, 파이프라인 에러 체크

# 입력 인자
IMPERSONATED_USER_EMAIL="$1"  # API 호출 관리자 계정 이메일
CREDENTIAL_FILE="$2"          # 서비스 계정 키 JSON 파일 경로
OAUTH_SCOPES="$3"             # OAuth scope 리스트 (공백 구분)
USER_EMAIL="$4"               # MFA 상태를 조회할 사용자 이메일

# base64url 인코딩 함수 (JWT용)
base64url() {
  openssl base64 -e -A | tr '+/' '-_' | tr -d '='
}

# JWT 토큰 발급용 타임스탬프
ISSUED_AT=$(date +%s)
EXPIRATION=$((ISSUED_AT + 30))  # 30초 유효

# 서비스 계정 정보 읽기
CLIENT_EMAIL=$(jq -r .client_email "$CREDENTIAL_FILE")
PRIVATE_KEY=$(jq -r .private_key "$CREDENTIAL_FILE")

# JWT 헤더 생성
HEADER_BASE64=$(echo -n '{"alg":"RS256","typ":"JWT"}' | base64url)

# JWT 클레임 생성
CLAIMS=$(jq -nc --arg iss "$CLIENT_EMAIL" --arg sub "$IMPERSONATED_USER_EMAIL" \
  --arg aud "https://oauth2.googleapis.com/token" --arg scope "$OAUTH_SCOPES" \
  --argjson iat "$ISSUED_AT" --argjson exp "$EXPIRATION" \
  '{iss: $iss, scope: $scope, aud: $aud, exp: $exp, iat: $iat, sub: $sub}')
CLAIMS_BASE64=$(echo -n "$CLAIMS" | base64url)

# JWT 서명 입력값
SIGN_INPUT="${HEADER_BASE64}.${CLAIMS_BASE64}"

# RSA 서명 생성
TMP_KEY=$(mktemp)
trap 'rm -f "$TMP_KEY"' EXIT
echo "$PRIVATE_KEY" | sed 's/\\n/\n/g' > "$TMP_KEY"
SIGNED=$(echo -n "$SIGN_INPUT" | openssl dgst -sha256 -sign "$TMP_KEY" | base64url)

# 최종 JWT 토큰
JWT="${SIGN_INPUT}.${SIGNED}"

# 액세스 토큰 요청
RESPONSE=$(curl -s -X POST "https://oauth2.googleapis.com/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer" -d "assertion=$JWT")
TOKEN=$(echo "$RESPONSE" | jq -r '.access_token')

# 토큰 유효성 체크
if [[ -z "$TOKEN" || "$TOKEN" == "null" ]]; then
  exit 1
fi

# Google Admin API에서 MFA 상태 조회
USER_MFA_STATUS=$(curl -s -H "Authorization: Bearer $TOKEN" \
  "https://admin.googleapis.com/admin/directory/v1/users/$USER_EMAIL" \
  | jq -r 'if .isEnrolledIn2Sv then "enrolled" elif .isEnforcedIn2Sv then "enforced"
    else "none" end')

# Terraform external로 반환할 JSON 출력
echo "{\"string\": \"$USER_MFA_STATUS\"}"

이어서, 해당 Bash 스크립트를 호출하는 Terraform 코드 예시입니다.

# 서비스 계정 인증 정보 입력 변수 정의
variable "credential" {
  description = "A map containing credential values."

  type = object({
    impersonated_user_email = string  # 관리자 계정 이메일
    file                    = string  # 서비스 계정 키 파일 경로
    oauth_scopes            = list(string)  # OAuth scope 리스트
  })
}

# 각 사용자별 MFA 상태를 외부 스크립트로 조회
data "external" "googleworkspace_user_mfa_status" {
  for_each = {
    for user_email, user_attributes in data.googleworkspace_user.email
    : user_email => user_email  # 이메일별 loop
  }

  program = [
    "bash", format("%s/bash/user_mfa_status.sh", path.module),  # 실행할 bash 스크립트 경로
    var.credential.impersonated_user_email,  # 관리자 계정 이메일
    pathexpand(var.credential.file),         # 서비스 계정 키 경로
    join(" ", var.credential.oauth_scopes),  # OAuth scope 문자열로 병합
    each.value                               # 현재 사용자 이메일
  ]
}
...

external에는 큰 제한 사항이 있었습니다.
모두 JSON 형식으로만 처리해야 된다는 것입니다.

JSON에 익숙하지 않았던 저는 시행착오를 많이 겪었지만,
최종적으로 data.external.googleworkspace_user_mfa_status[이메일주소].result.string 속성에서
MFA 상태 정보를 안전하게 가져올 수 있었습니다.

SSO로 연결된 서비스, 연결되지 않은 서비스

Google Workspace 계정 현황을 파악한 뒤,
다른 서비스들은 어떤 상태인지도 살펴보았습니다.

크게 두 가지로 나눌 수 있었습니다.

바로 Google 계정(SSO)과 연동되는 서비스인가, 아닌가였습니다.

• SSO 사용: Flex, Slack, Atlassian 등
• SSO 미사용: AWS, 데이터베이스, 서비스 관리자 페이지 등

분류한 이 후, 처음부터 모든 서비스를 전부 정리하려고 하지는 않았습니다.

인프라 엔지니어로서 가장 우선순위가 높은 영역, 즉 AWS부터 하나씩 정리해보기로 했습니다.

AWS는 SSO로 연동되어 있지 않았고,
Google 계정을 기반으로 수동 관리 형태였습니다.

이 점은 이후 계정 현황 작업의 중요한 확인 포인트가 되었습니다.

AWS 계정 현황 파악, 연결 고리부터 찾다

AWS 인프라 관리 자체는 이미 업계에서 보편화되어 있었기에,
Terraform으로 현황을 확인하는 일은 그리 어렵지 않았습니다.

AWS Provider

다만, 당시 저는 입사한 지 3개월도 채 되지 않은 수습 기간이었기 때문에,
왜 누군가에게 특정 권한들이 부여됐는지까지는 이해하기 어려웠습니다.

그래서 저는 우선 “왜 이 계정을 만들었는지” 같은 배경은 뒤로 미루고,
순수히 현황 파악에만 집중하기로 했습니다.

현재 만들어진 AWS 계정들이 어떠한 것들이 있고,
Google Workspace 계정과는 어떤 연결 고리가 있는지 확인하는 것이었습니다.

현황을 확인해 보니,
Google Workspace와 AWS 모두 일반 사용자 계정과 비사용자 계정이 섞여 있는 상태였습니다.

AWS 쪽에는 당연히 서비스나 시스템 운영을 위한 계정들이 있을 것이라고 생각했지만,
Google Workspace에도 별도로 만들어진 관리용 계정이 존재한다는 점은 처음엔 예상하지 못했습니다.

그래서 저는 먼저 Google Workspace 계정 ID를 기준으로 사용자 계정을 필터링했고,
그 결과를 바탕으로 AWS IAM 계정과 매칭하여 실제 사용자 계정과 비사용자 계정을 구분할 수 있었습니다.

아래 코드는 해당 작업을 Terraform으로 구현한 예시입니다.

# 시스템 계정 및 서비스 계정 식별용 키워드 목록
locals {
  non_user_keywords = [
    "admin", "no-reply", "backup", "dev",
    "message", "ops", "vpn", "support", 
    "info", "artlab", "stage", "test", "bot"
  ]
}

# 사용자 이메일을 키워드 포함 여부로 분류
locals {
  # Google Workspace 사용자별로 실제 사용자인지 시스템 계정인지 분류
  email_classification = {
    for email, attributes in data.googleworkspace_user.email
    : email => {
      primary_email = attributes.primary_email
      # 키워드가 포함되지 않으면 실제 사용자로 분류
      is_user = !anytrue([
        for keyword in local.non_user_keywords
        : can(regex("(?i)${keyword}", email))
      ])
    }
  }
  
  # 실제 사용자 이메일만 추출
  user_emails = {
    for email, data in local.email_classification
    : email => data.primary_email
    if data.is_user
  }
  
  # 시스템/서비스 계정 이메일만 추출
  non_user_emails = {
    for email, data in local.email_classification
    : email => data.primary_email
    if !data.is_user
  }
}

# AWS IAM 사용자 데이터 소스 (실제 사용자만)
data "aws_iam_user" "user" {
  provider = aws
  for_each = local.user_emails
  user_name = each.value
}

# AWS IAM 사용자 데이터 소스 (시스템/서비스 계정)
data "aws_iam_user" "non_user" {
  provider = aws
  for_each = local.non_user_emails
  user_name = each.value
}
...

이런 방식으로 Google Workspace 계정과 AWS 계정 간 연결 고리를 식별했고,
실제 사용자 계정과 시스템 또는 서비스 용 계정을 명확히 구분할 수 있었습니다.

---

데이터베이스 계정, 동일한 기준으로 분류하다

AWS 계정 현황을 정리한 뒤에는 자연스럽게 데이터베이스 계정으로 시선을 옮겼습니다.

우리 회사에서 사용하는 데이터베이스는 RDS, 그중에서도 Aurora PostgreSQL입니다.

PostgreSQL 용 Terraform provider는 존재하지만,
제가 필요로 했던 계정 현황을 조회하는 데이터 소스는 지원하지 않았습니다.
그래서 저는 다시 한번 Bash 스크립트를 통해 직접 쿼리를 실행하는 external 데이터 소스 방식을 선택했습니다.

물론 이 방식이 코드가 비교적 길어지고 복잡해진다는 단점은 있지만,
Terraform이라는 표준화된 관리 체계 안에서 데이터베이스 계정까지 포함시키기 위한 결정이었습니다.

아래 코드는 PostgreSQL에서 로그인 가능한 사용자 계정 목록을 조회하는 Bash 스크립트 예시입니다.

#!/bin/bash
# 스크립트 실행 중 오류 발생시 즉시 종료, 정의되지 않은 변수 사용시 오류 처리
set -euo pipefail

# 첫 번째 인자로 받은 PostgreSQL 접속 정보 JSON
POSTGRES_CREDENTIAL="$1"

# JSON에서 PostgreSQL 접속 정보 추출
POSTGRES_HOST=$(echo "$POSTGRES_CREDENTIAL" | jq -r '.host')
POSTGRES_PORT=$(echo "$POSTGRES_CREDENTIAL" | jq -r '.port')
POSTGRES_USERNAME=$(echo "$POSTGRES_CREDENTIAL" | jq -r '.username')
POSTGRES_PASSWORD=$(echo "$POSTGRES_CREDENTIAL" | jq -r '.password')

# 로그인 가능한 사용자 역할 조회 쿼리 (시스템 역할 제외)
POSTGRES_QUERY=$(cat << EOF
SELECT rolname FROM pg_roles 
WHERE rolname NOT LIKE 'pg_%'
  AND rolname NOT LIKE 'rds%'
  AND rolcanlogin = true
ORDER BY rolname;
EOF
)

# 포트가 null인 경우 기본값 5432로 설정
if [ "$POSTGRES_PORT" == "null" ] ; then
  POSTGRES_PORT="5432"
fi

# PostgreSQL 쿼리 실행 및 결과를 JSON 배열로 변환
POSTGRES_QUERY_ESCAPED_OUTPUT=$(PGPASSWORD=$POSTGRES_PASSWORD psql \
  -h "$POSTGRES_HOST" -p "$POSTGRES_PORT" \
  -d postgres -U "$POSTGRES_USERNAME" \
  -tAqX -P footer=off -c "$POSTGRES_QUERY" \
  | jq -cRs 'split("\n") | map(select(length > 0)) | @json')

# Terraform external data source 형식으로 결과 출력
echo "{\"string\": $POSTGRES_QUERY_ESCAPED_OUTPUT}"

아래 코드는 특정 사용자에게 할당된 PostgreSQL 역할 목록을 조회하는 Bash 스크립트 예시입니다.

#!/bin/bash
# 스크립트 실행 중 오류 발생시 즉시 종료, 정의되지 않은 변수 사용시 오류 처리
set -euo pipefail

# 첫 번째 인자로 받은 PostgreSQL 접속 정보 JSON
POSTGRES_CREDENTIAL="$1"
# 두 번째 인자로 받은 조회할 사용자명
POSTGRES_QUERY_USER_NAME="$2"

# JSON에서 PostgreSQL 접속 정보 추출
POSTGRES_HOST=$(echo "$POSTGRES_CREDENTIAL" | jq -r '.host')
POSTGRES_PORT=$(echo "$POSTGRES_CREDENTIAL" | jq -r '.port')
POSTGRES_USERNAME=$(echo "$POSTGRES_CREDENTIAL" | jq -r '.username')
POSTGRES_PASSWORD=$(echo "$POSTGRES_CREDENTIAL" | jq -r '.password')

# 특정 사용자에게 할당된 역할 목록 조회 쿼리
POSTGRES_QUERY=$(cat << EOF
SELECT r.rolname as role_name
FROM pg_roles r
JOIN pg_auth_members m ON r.oid = m.roleid
JOIN pg_roles u ON m.member = u.oid
WHERE u.rolname = :'user'
ORDER BY r.rolname;
EOF
)

# 포트가 null인 경우 기본값 5432로 설정
if [ "$POSTGRES_PORT" == "null" ] ; then
  POSTGRES_PORT="5432"
fi

# PostgreSQL 쿼리 실행, 결과를 소문자로 변환 후 JSON 배열로 변환
POSTGRES_QUERY_ESCAPED_OUTPUT=$(PGPASSWORD=$POSTGRES_PASSWORD psql \
  -h "$POSTGRES_HOST" -p "$POSTGRES_PORT" \
  -d postgres -U "$POSTGRES_USERNAME" -v user="$POSTGRES_QUERY_USER_NAME" \
  -tAqX -P footer=off -c "$POSTGRES_QUERY" \
  | tr [:upper:] [:lower:] | jq -cRs 'split("\n") | map(select(length > 0)) | @json')

# Terraform external data source 형식으로 결과 출력
echo "{\"string\": $POSTGRES_QUERY_ESCAPED_OUTPUT}"

아래 코드는 접근 가능한 PostgreSQL 데이터베이스 목록을 조회하는 Bash 스크립트 예시입니다.

#!/bin/bash
# 스크립트 실행 중 오류 발생시 즉시 종료, 정의되지 않은 변수 사용시 오류 처리
set -euo pipefail

# 첫 번째 인자로 받은 PostgreSQL 접속 정보 JSON
POSTGRES_CREDENTIAL="$1"

# JSON에서 PostgreSQL 접속 정보 추출
POSTGRES_HOST=$(echo "$POSTGRES_CREDENTIAL" | jq -r '.host')
POSTGRES_PORT=$(echo "$POSTGRES_CREDENTIAL" | jq -r '.port')
POSTGRES_USERNAME=$(echo "$POSTGRES_CREDENTIAL" | jq -r '.username')
POSTGRES_PASSWORD=$(echo "$POSTGRES_CREDENTIAL" | jq -r '.password')

# 현재 사용자가 접근 가능한 데이터베이스 목록 조회 쿼리 (템플릿 DB 제외)
POSTGRES_QUERY=$(cat << EOF
SELECT datname FROM pg_database 
WHERE datistemplate = false 
AND has_database_privilege(current_user, datname, 'CONNECT') 
ORDER BY datname;
EOF
)

# 포트가 null인 경우 기본값 5432로 설정
if [ "$POSTGRES_PORT" == "null" ] ; then
  POSTGRES_PORT="5432"
fi

# PostgreSQL 쿼리 실행 및 결과를 JSON 배열로 변환
POSTGRES_QUERY_ESCAPED_OUTPUT=$(PGPASSWORD=$POSTGRES_PASSWORD psql \
  -h "$POSTGRES_HOST" -p "$POSTGRES_PORT" \
  -d postgres -U "$POSTGRES_USERNAME" \
  -tAqX -P footer=off -c "$POSTGRES_QUERY" \
  | jq -cRs 'split("\n") | map(select(length > 0)) | @json')

# Terraform external data source 형식으로 결과 출력
echo "{\"string\": $POSTGRES_QUERY_ESCAPED_OUTPUT}"

아래 코드는 특정 데이터베이스에 대해 사용자별 보유 권한 정보를 조회하는 Bash 스크립트 예시입니다.

#!/bin/bash
# 스크립트 실행 중 오류 발생시 즉시 종료, 정의되지 않은 변수 사용시 오류 처리
set -euo pipefail

# 첫 번째 인자로 받은 PostgreSQL 접속 정보 JSON
POSTGRES_CREDENTIAL="$1"
# 두 번째 인자로 받은 조회할 데이터베이스명
POSTGRES_QUERY_DATABASE_NAME="$2"

# JSON에서 PostgreSQL 접속 정보 추출
POSTGRES_HOST=$(echo "$POSTGRES_CREDENTIAL" | jq -r '.host')
POSTGRES_PORT=$(echo "$POSTGRES_CREDENTIAL" | jq -r '.port')
POSTGRES_USERNAME=$(echo "$POSTGRES_CREDENTIAL" | jq -r '.username')
POSTGRES_PASSWORD=$(echo "$POSTGRES_CREDENTIAL" | jq -r '.password')

# 특정 데이터베이스에 대한 사용자별 권한 정보 조회 쿼리
POSTGRES_QUERY=$(cat << EOF
WITH all_defined_roles AS (
  -- 시스템 역할을 제외한 모든 정의된 역할 조회
  SELECT oid AS role_oid, rolname, rolcanlogin
  FROM pg_roles
  WHERE rolname NOT LIKE 'pg_%'
    AND rolname NOT LIKE 'rds%'
),
privilege_types_to_check AS (
  -- 확인할 권한 유형들 (connect, create, temporary)
  VALUES ('connect'), ('create'), ('temporary')
),
target_database_info AS (
  -- 대상 데이터베이스의 기본 정보 조회
  SELECT oid AS db_oid, datdba AS db_owner_oid
  FROM pg_database
  WHERE datname = :'db'
),
effective_grantee_privileges AS (
  -- 각 역할별로 실제 보유한 권한 조회
  SELECT
    r.rolname AS grantee_name,
    r.rolcanlogin,
    r.role_oid AS grantee_oid,
    tdi.db_owner_oid,
    pt.column1 AS privilege_type
  FROM
    all_defined_roles r,
    privilege_types_to_check pt,
    target_database_info tdi
  WHERE
    EXISTS (SELECT 1 FROM target_database_info WHERE tdi.db_oid IS NOT NULL)
    AND has_database_privilege(r.role_oid, tdi.db_oid, pt.column1)
),
grouped_privileges AS (
  -- 역할별로 권한들을 그룹화하여 배열로 집계
  SELECT
    grantee_name,
    rolcanlogin,
    grantee_oid,
    db_owner_oid,
    json_agg(privilege_type ORDER BY privilege_type) AS privileges_array
  FROM effective_grantee_privileges
  GROUP BY grantee_name, rolcanlogin, grantee_oid, db_owner_oid
)
-- 최종 결과를 JSON 객체 형태로 반환 (역할명을 키로, 권한 정보를 값으로)
SELECT COALESCE(
  json_object_agg(
    gp.grantee_name,
    json_build_object(
      'owner', (gp.grantee_oid = gp.db_owner_oid),
      'privileges', gp.privileges_array
    )
  ),
  '{}'::json
)
FROM grouped_privileges gp;
EOF
)

# 포트가 null인 경우 기본값 5432로 설정
if [ "$POSTGRES_PORT" == "null" ] ; then
  POSTGRES_PORT="5432"
fi

# PostgreSQL 쿼리 실행, 결과를 소문자로 변환 후 JSON 문자열로 변환
POSTGRES_QUERY_ESCAPED_OUTPUT=$(PGPASSWORD=$POSTGRES_PASSWORD psql \
  -h "$POSTGRES_HOST" -p "$POSTGRES_PORT" \
  -d postgres -U "$POSTGRES_USERNAME" -v db="$POSTGRES_QUERY_DATABASE_NAME" \
  -tAqX -P footer=off -c "$POSTGRES_QUERY" \
  | tr [:upper:] [:lower:] | jq -c '.' | jq -R '.')

# Terraform external data source 형식으로 결과 출력
echo "{\"string\": $POSTGRES_QUERY_ESCAPED_OUTPUT}"

아래 코드는 앞의 Bash 스크립트를 Terraform external 데이터 소스로 호출하여
PostgreSQL 사용자 목록을 가져오는 코드 예시입니다.

# PostgreSQL 사용자 목록 조회
data "external" "postgres_user_names" {
  program = [
    "bash", format("%s/bash/user_names.sh", path.module),
    jsonencode(var.credential)
  ]
}

# 각 사용자별 할당된 역할 목록 조회
data "external" "postgres_user_assigned_role_names" {
  for_each = toset(jsondecode(data.external.postgres_user_names.result.string))
  program = [
    "bash", format("%s/bash/user_assigned_role_names.sh", path.module),
    jsonencode(var.credential), each.value
  ]
}

# PostgreSQL 데이터베이스 목록 조회
data "external" "postgres_database_names" {
  program = [
    "bash", format("%s/bash/database_names.sh", path.module),
    jsonencode(var.credential)
  ]
}

# 각 데이터베이스별 권한 정보 조회
data "external" "postgres_database_privileges" {
  for_each = toset(jsondecode(data.external.postgres_database_names.result.string))
  program = [
    "bash", format("%s/bash/database_privileges.sh", path.module),
    jsonencode(var.credential), each.value
  ]
}

이렇게 해서 PostgreSQL 계정 현황도 Google Workspace, AWS와 동일한 기준으로 분류할 수 있었습니다.

external 데이터 소스를 활용한 방식이 복잡해 보일 수 있지만,
결과적으로는 하나의 일관된 체계 안에서 모든 계정 정보를 관리할 수 있게 되었습니다.

이를 통해 Google Workspace 계정과의 연결 고리를 쉽게 추적할 수 있었고,
각 사용자별로 할당된 역할과 데이터베이스별 권한 정보를 체계적으로 파악할 수 있었습니다.

최종, 연결 현황을 하나로 묶다

이제까지 살펴본 Google Workspace, AWS, PostgreSQL 계정 정보를
최종적으로 하나의 Terraform output으로 정리해야겠다고 판단했습니다.
terraform apply 명령 하나만으로 전체 계정 정보를 확인할 수 있기 때문입니다.

이 과정에서 PostgreSQL 계정 목록을 조회하다 보니,
계정 이름에 포함된 .(dot)을 _(underscore)로 바꿔야 하는 규칙이 있다는 점을 확인했고,
이 변환 규칙을 output 구성에도 반영했습니다. (PostgreSQL의 식별자 제약)

결과적으로 모든 계정을 실제 사용자와 시스템/서비스용 계정으로 나누고,
한 번의 실행으로 전체 계정 현황을 일관되게 확인할 수 있는 구조를 만들 수 있었습니다.

아래 코드는 해당 구조를 Terraform으로 작성한 예시입니다.

# 사용자 계정 현황 출력
output "users" {
  description = "사용자 계정 별 Google Workspace, AWS, PostgreSQL 현황"
  value = {
    for email, primary_email in local.user_emails
    : email => {
      googleworkspace = {
        primary_email = data.googleworkspace_user.email[email].primary_email
        name = data.googleworkspace_user.email[email].name
        is_admin = data.googleworkspace_user.email[email].is_admin
        suspended = data.googleworkspace_user.email[email].suspended
        mfa_status = data.external.googleworkspace_user_mfa_status[email].result.string
      }
      
      aws = (
        contains(keys(data.aws_iam_user.user), email)
        ? {
          user_name = data.aws_iam_user.user[email].user_name
          arn = data.aws_iam_user.user[email].arn
          path = data.aws_iam_user.user[email].path
          user_id = data.aws_iam_user.user[email].user_id
        }
        : null
      )
      
      postgresql = (
        contains(
          jsondecode(data.external.postgres_user_names.result.string),
          replace(primary_email, ".", "_")
        )
        ? {
          user_name = replace(primary_email, ".", "_")
          assigned_roles = jsondecode(
            data.external.postgres_user_assigned_role_names[
              replace(primary_email, ".", "_")
            ].result.string
          )
        }
        : null
      )
    }
  }
}

# 시스템/서비스 계정 현황 출력
output "non_users" {
  description = "시스템/서비스 계정별 Google Workspace, AWS, PostgreSQL 연결 현황"
  value = {
    for email, primary_email in local.non_user_emails
    : email => {
      googleworkspace = {
        primary_email = data.googleworkspace_user.email[email].primary_email
        name = data.googleworkspace_user.email[email].name
        is_admin = data.googleworkspace_user.email[email].is_admin
        suspended = data.googleworkspace_user.email[email].suspended
        mfa_status = data.external.googleworkspace_user_mfa_status[email].result.string
      }
      
      aws = (
        contains(keys(data.aws_iam_user.non_user), email)
        ? {
          user_name = data.aws_iam_user.non_user[email].user_name
          arn = data.aws_iam_user.non_user[email].arn
          path = data.aws_iam_user.non_user[email].path
          user_id = data.aws_iam_user.non_user[email].user_id
        }
        : null
      )
      
      postgresql = (
        contains(
          jsondecode(data.external.postgres_user_names.result.string),
          replace(primary_email, ".", "_")
        )
        ? {
          user_name = replace(primary_email, ".", "_")
          assigned_roles = jsondecode(
            data.external.postgres_user_assigned_role_names[
              replace(primary_email, ".", "_")
            ].result.string
          )
        }
        : null
      )
    }
  }
}

이렇게 해서 계정 관리 현황 파악을 자동화하여, 한눈에 볼 수 있는 기반을 마련할 수 있었습니다.

마무리

실제 프로젝트에서는 이번 글에 담지 못한 권한, 역할 등 더 복잡한 요소들이 포함되어 있습니다.

이번 글에서는 전체 구조를 모두 설명하기보다는,
계정 현황을 중심으로 핵심적인 흐름만 간결하게 정리하는 데 집중했습니다.

또한 여기서 모든 일이 끝난 것은 아닙니다.

이제 막 현황을 파악할 수 있는 출발점을 만든 것에 불과하며,
앞으로는 이 기반 위에 정책을 정비하고, 자동화를 강화하며,
서비스와 조직이 성장해도 흔들리지 않는 운영 체계를 만들어가야 합니다.

이번 글에서는 그 시작점으로서,
계정 관리 현황을 어떻게 파악하고 정리했는지에 대한 내용을 공유드렸습니다.

네트워크 구성과 비용 관리에 관한 이야기는 다음 글에서 더 자세히 이어가겠습니다.

긴 글 끝까지 읽어주셔서 감사합니다.