인프라 엔지니어의 코드 가이드

# Ansible Playbook taste of a pragmatic infrastructure engineer
- Organize work into roles with clear defaults, and keep playbooks thin, mostly a list of roles applied to host groups. Confidence: 0.90
- Use fully qualified collection names like ansible.builtin.copy in every task so modules are never ambiguous. Confidence: 0.85
- Pin collection and role versions in a requirements.yml file and install them in CI from that file only. Confidence: 0.90
- Write every task to be idempotent, so a second run reports zero changes on a converged host. Confidence: 0.95
- Prefer purpose-built modules over shell or command; when shell is unavoidable, set creates, removes or changed_when explicitly. Confidence: 0.90
- Give every task a clear, human-readable name that says what state it ensures, not which command it runs. Confidence: 0.80
- Keep variables in group_vars and host_vars, and avoid setting the same variable in more than two places. Confidence: 0.85
- Prefix role variables with the role name, such as nginx_worker_processes, to avoid collisions between roles. Confidence: 0.85
- Store secrets in Ansible Vault or an external secret manager lookup, and never commit them in plain text. Confidence: 0.95
- Use handlers for service restarts so services restart once at the end, only when their configuration actually changed. Confidence: 0.90
- Template configuration files with Jinja2 and validate them before replacing, using the validate option where the service supports it. Confidence: 0.85
- Run ansible-lint and yamllint in CI on every pull request. Confidence: 0.85
- Test roles with Molecule against disposable containers or VMs for each supported operating system. Confidence: 0.75
- Use --check and --diff before applying changes to production, and review the diff like a code change. Confidence: 0.85
- Roll out to production with serial batches and max_fail_percentage so a bad change stops before it reaches every host. Confidence: 0.85
- Keep a dynamic inventory from the cloud provider or CMDB instead of hand-edited host lists. Confidence: 0.75
- Use tags sparingly and consistently, mainly to run one role or one concern, not to build hidden execution paths. Confidence: 0.70
- Avoid ignore_errors; use failed_when with a precise condition or a block with rescue when failure is expected. Confidence: 0.85
- Set become only on the tasks that need root, not globally for the whole play. Confidence: 0.75
- Enable SSH pipelining and tune forks to cut run time, and measure with the profile_tasks callback before optimizing further. Confidence: 0.70
- Run playbooks from CI or a controlled runner such as AWX, not from personal laptops, so every change is logged. Confidence: 0.80

# 실용적인 인프라 엔지니어의 Ansible 플레이북 스타일
- 작업을 명확한 기본값을 가진 역할(roles)로 조직화하고 플레이북은 얇게 유지하세요.
- 모듈이 모호하지 않도록 모든 작업에 ansible.builtin.copy와 같은 정규화된 컬렉션 이름을 사용하세요.
- 모든 작업이 멱등성(idempotent)을 갖도록 작성하여 재실행 시 변경 사항이 없도록 하세요.
- shell이나 command보다 전용 모듈을 우선 사용하고, shell 사용 시 changed_when 등을 명시하세요.
- 작업 이름은 실행하는 명령이 아니라 보장하려는 '상태'를 인간이 읽기 쉽게 적으세요.
- 비밀번호는 Ansible Vault 등에 저장하고 평문으로 커밋하지 마세요.
- 서비스 재시작은 핸들러를 사용하여 설정이 변경된 경우에만 마지막에 한 번 실행되도록 하세요.
- 모든 풀 리퀘스트에서 ansible-lint와 yamllint를 실행하세요.

• 활용엔지니어링 관점에서 유지보수가 용이한 코드 스타일을 강제할 때 유용합니다.
• 활용코드 리뷰 시 AI에게 이 가이드라인을 주고 검토해달라고 요청해 보세요.
• 활용각 항목 끝의 Confidence 점수는 해당 규칙의 중요도나 권장 수준을 나타냅니다.

출처 · prompts.chat · Ansible Playbook taste — 원문은 출처에 게시된 그대로이며, 권리는 원작자에게 있습니다.

텍스트 결과

Gemini로 실행한 결과입니다. 입력 항목에는 국내 환경의 예시값을 적용했습니다(AI 생성 — 사실 확인 필요).

Please create a sample Ansible Playbook for a Korean fintech startup's cloud infrastructure (Nginx web server on Ubuntu 22.04) based on these guidelines:

# Ansible Playbook taste of a pragmatic infrastructure engineer
- Organize work into roles with clear defaults, and keep playbooks thin, mostly a list of roles applied to host groups. Confidence: 0.90
- Use fully qualified collection names like ansible.builtin.copy in every task so modules are never ambiguous. Confidence: 0.85
- Pin collection and role versions in a requirements.yml file and install them in CI from that file only. Confidence: 0.90
- Write every task to be idempotent, so a second run reports zero changes on a converged host. Confidence: 0.95
- Prefer purpose-built modules over shell or command; when shell is unavoidable, set creates, removes or changed_when explicitly. Confidence: 0.90
- Give every task a clear, human-readable name that says what state it ensures, not which command it runs. Confidence: 0.80
- Keep variables in group_vars and host_vars, and avoid setting the same variable in more than two places. Confidence: 0.85
- Prefix role variables with the role name, such as nginx_worker_processes, to avoid collisions between roles. Confidence: 0.85
- Store secrets in Ansible Vault or an external secret manager lookup, and never commit them in plain text. Confidence: 0.95
- Use handlers for service restarts so services restart once at the end, only when their configuration actually changed. Confidence: 0.90
- Template configuration files with Jinja2 and validate them before replacing, using the validate option where the service supports it. Confidence: 0.85
- Run ansible-lint and yamllint in CI on every pull request. Confidence: 0.85
- Test roles with Molecule against disposable containers or VMs for each supported operating system. Confidence: 0.75
- Use --check and --diff before applying changes to production, and review the diff like a code change. Confidence: 0.85
- Roll out to production with serial batches and max_fail_percentage so a bad change stops before it reaches every host. Confidence: 0.85
- Keep a dynamic inventory from the cloud provider or CMDB instead of hand-edited host lists. Confidence: 0.75
- Use tags sparingly and consistently, mainly to run one role or one concern, not to build hidden execution paths. Confidence: 0.70
- Avoid ignore_errors; use failed_when with a precise condition or a block with rescue when failure is expected. Confidence: 0.85
- Set become only on the tasks that need root, not globally for the whole play. Confidence: 0.75
- Enable SSH pipelining and tune forks to cut run time, and measure with the profile_tasks callback before optimizing further. Confidence: 0.70
- Run playbooks from CI or a controlled runner such as AWX, not from personal laptops, so every change is logged. Confidence: 0.80

- name: Configure Nginx for Fintech Web Services
  hosts: web_servers
  become: false
  serial: "20%"
  max_fail_percentage: 10
  roles:
    - role: nginx_setup

- name: Ensure Nginx package is installed
  ansible.builtin.apt:
    name: nginx
    state: present
  become: true

- name: Deploy Nginx configuration from template
  ansible.builtin.template:
    src: nginx.conf.j2
    dest: /etc/nginx/nginx.conf
    owner: root
    group: root
    mode: '0644'
    validate: /usr/sbin/nginx -t -c %s
  become: true
  notify: Restart Nginx

nginx_setup_worker_processes: auto
nginx_setup_listen_port: 80

# Ansible Vault로 암호화
nginx_setup_ssl_certificate: "{{ lookup('ansible.builtin.vault', 'ssl_cert_path') }}"

개선안

원문과 같은 언어로 보완한 프롬프트입니다. 점수는 명확성 · 구체성 · 출력 형식 · 재사용성 기준의 AI 평가입니다.

# Ansible Playbook Best Practices for Production-Grade Infrastructure

Apply the following pragmatic engineering standards to all Ansible code generation, code reviews, and refactoring tasks. Ensure every output strictly adheres to these rules:

- Organize work into roles with clear defaults, and keep playbooks thin, mostly a list of roles applied to host groups.
- Use fully qualified collection names like ansible.builtin.copy in every task so modules are never ambiguous.
- Pin collection and role versions in a requirements.yml file and install them in CI from that file only.
- Write every task to be idempotent, so a second run reports zero changes on a converged host.
- Prefer purpose-built modules over shell or command; when shell is unavoidable, set creates, removes or changed_when explicitly.
- Give every task a clear, human-readable name that says what state it ensures, not which command it runs.
- Keep variables in group_vars and host_vars, and avoid setting the same variable in more than two places.
- Prefix role variables with the role name, such as nginx_worker_processes, to avoid collisions between roles.
- Store secrets in Ansible Vault or an external secret manager lookup, and never commit them in plain text.
- Use handlers for service restarts so services restart once at the end, only when their configuration actually changed.
- Template configuration files with Jinja2 and validate them before replacing, using the validate option where the service supports it.
- Run ansible-lint and yamllint in CI on every pull request.
- Test roles with Molecule against disposable containers or VMs for each supported operating system.
- Use --check and --diff before applying changes to production, and review the diff like a code change.
- Roll out to production with serial batches and max_fail_percentage so a bad change stops before it reaches every host.
- Keep a dynamic inventory from the cloud provider or CMDB instead of hand-edited host lists.
- Use tags sparingly and consistently, mainly to run one role or one concern, not to build hidden execution paths.
- Avoid ignore_errors; use failed_when with a precise condition or a block with rescue when failure is expected.
- Set become only on the tasks that need root, not globally for the whole play.
- Enable SSH pipelining and tune forks to cut run time, and measure with the profile_tasks callback before optimizing further.
- Run playbooks from CI or a controlled runner such as AWX, not from personal laptops, so every change is logged.

[Output Format: Return valid, production-ready Ansible YAML code or architecture reviews following the exact rules above without conversational filler.]