개발자 컨퍼런스 라이트닝 토크 5분짜리 발표를 준비해 줘 — 주제는 테스트 자동화

## 역할과 목표

너는 개발자 컨퍼런스의 발표 기획자이자 기술 발표 대본 작성자다. 주제인 **테스트 자동화**를 바탕으로 5분짜리 라이트닝 토크의 스토리라인, 슬라이드 구성, 발표 대본을 설계하라. 청중은 개발자 컨퍼런스 참석자다.

산출물은 장표별 핵심 메시지와 시각 요소를 포함한 발표 설계안, 장표 텍스트와 분리된 발표 대본, 오프닝·클로징 멘트, 시간 배분표로 구성하라. 완료 기준은 전체 발표가 5분 안에 전달 가능하고, 각 장표가 하나의 핵심 메시지만 가지며, 테스트 자동화의 문제·제안·근거·실행 방향이 자연스럽게 이어지는 것이다.

## 범위와 전제

다룰 범위는 테스트 자동화의 필요성, 해결하려는 개발상의 문제, 자동화할 테스트의 범위, 도입 또는 개선 방향, 기대하는 실무적 변화다. 5분 발표에 맞춰 핵심 주장 하나를 중심으로 압축하고, 세부 구현 튜토리얼·완성된 코드·도구별 전체 비교·장시간 실습은 기본 범위에서 제외하라.

현재 확인된 사실은 발표 형식이 개발자 컨퍼런스 라이트닝 토크이고, 발표 시간이 5분이며, 주제가 테스트 자동화라는 점뿐이다. 다음 값은 임의로 채우지 말고 필요한 경우 슬롯으로 남겨라.

- 발표의 핵심 주장: `[입력 필요: 청중이 기억해야 할 한 문장]`
- 청중의 개발 언어·숙련도: `[입력 필요: 청중 특성]`
- 사례 또는 문제 상황: `[입력 필요: 실제 프로젝트 사례]`
- 사용 도구·프레임워크: `[입력 필요: 테스트 도구 또는 프레임워크]`
- 발표자가 원하는 결론 또는 요청: `[입력 필요: 청중에게 바라는 행동]`

특히 테스트 자동화 도입률, 테스트 실행 시간, 결함 감소율, 비용 절감률 같은 수치는 입력이나 검증 가능한 출처가 없으면 만들지 마라. 사례가 없을 때는 특정 회사·팀·도구의 실제 경험처럼 쓰지 말고, 일반적인 시나리오임을 명확히 표시하라.

## 작업 규칙

1. 먼저 5분 안에 전달할 핵심 주장을 한 문장으로 정한다. 핵심 주장 입력이 있으면 그 문장을 보존하고, 없으면 `[입력 필요: 청중이 기억해야 할 한 문장]`으로 표시한 뒤 전체 구성을 해당 슬롯에 맞춰 설계하라.
2. 스토리라인은 기본적으로 **현황 또는 문제 → 테스트 자동화의 핵심 관점 → 적용 방법 또는 사례 → 주의점 → 결론과 행동 요청** 순서로 구성하라. 실제 사례가 제공되면 사례 중심으로 전개하고, 사례가 없으면 검증되지 않은 성과를 사례처럼 제시하지 말고 개념 설명 중심으로 전환하라.
3. 테스트 자동화를 단순히 “테스트를 많이 작성하는 일”로 표현하지 말고, 무엇을 자동화할지 판단하는 기준을 제시하라. 반복 실행이 필요하고 결과를 일관되게 판정할 수 있는 검증은 우선 대상으로 다루고, 탐색적 테스트·사용성 판단처럼 사람의 맥락 판단이 중요한 영역은 자동화의 한계를 함께 설명하라.
4. 테스트 피라미드, 단위 테스트, 통합 테스트, 엔드투엔드 테스트 등 기술 용어를 사용할 때는 발표 시간과 청중 수준에 맞춰 필요한 만큼만 설명하라. 청중 수준이 확인되지 않으면 용어를 처음 사용할 때 짧은 정의를 붙이고, 세부 이론은 생략하라.
5. 특정 도구나 프레임워크를 제안할 때는 사용자가 제공한 도구만 확정적으로 다루라. 도구가 제공되지 않았으면 도구명을 임의로 선택하지 말고 `[입력 필요: 테스트 도구 또는 프레임워크]`를 사용하라.
6. 테스트 자동화의 효과를 말할 때 “품질이 향상된다”처럼 추상적으로 끝내지 말고, 회귀 검증의 반복 가능성, 피드백 시점, 실패 재현성처럼 관찰 가능한 변화로 표현하라. 수치가 없으면 정량적 성과를 주장하지 마라.
7. 테스트가 불안정하거나 유지보수 비용이 커지는 조건을 최소 한 번 다루라. 외부 시스템 의존성, 시간·순서 의존성, 불명확한 테스트 데이터 등은 입력 사실이 아니라 일반적인 위험 요인으로 제시하되, 해당 발표 사례의 실제 원인처럼 단정하지 마라.
8. 한국 조직 보고식 발표처럼 첫 장 또는 오프닝에서 결론과 청중에게 바라는 행동을 먼저 제시하라. 단, 구체적인 행동 요청이 입력되지 않았으면 `[입력 필요: 청중에게 바라는 행동]`으로 남겨라.
9. 발표 시간 대비 장표 수가 과도해지면 장표를 늘리지 말고 내용을 통합하라. 한 장표에 메시지를 여러 개 넣어야 한다면 핵심 메시지 하나와 보조 근거로 위계를 나눠라.
10. 발표 대본은 장표 텍스트를 그대로 읽는 방식이 아니라, 장표가 보여 주는 내용을 설명하고 다음 장표로 연결하는 서술형으로 작성하라. 장표 자체는 짧은 개조식으로 유지하라.

## 산출물 구조

다음 순서와 형식을 지켜 작성하라.

1. **장표 목록 표**
   - 열: `번호 | 제목 | 핵심 메시지 | 들어갈 시각 요소 | 권장 시간`
   - 5분에 맞춰 장표 수를 제한하고, 각 장표에는 핵심 메시지 하나만 배정하라.
   - 첫 장표에는 결론 또는 문제의식을, 마지막 장표에는 요약과 `[입력 필요: 청중에게 바라는 행동]` 또는 확정된 행동 요청을 배치하라.
   - 시각 요소는 다이어그램·비교 흐름·간단한 코드 구조·체크리스트 중 필요한 형식으로 지정하되, 실제 수치나 사례가 없으면 임의 그래프를 만들지 마라.

2. **장별 발표 대본 구조**
   - 각 장표마다 `발표 의도 / 화면에 표시할 문구 / 발표 대본 / 다음 장표 연결`을 작성하라.
   - 화면 문구는 짧은 개조식으로 쓰고, 발표 대본은 자연스러운 서술형으로 작성하라.
   - 전체 대본은 정상적인 발표 속도에서 5분을 넘지 않도록 분량을 조정하라.
   - 코드나 도구 설명은 핵심 개념을 보여 주는 수준으로 제한하고, 실행 가능한 전체 구현을 가장하지 마라.
   - 출처가 필요한 주장이나 데이터가 들어가면 해당 장표에 `[출처 필요: 기관·자료명·기준연도]`를 표시하라.

3. **오프닝·클로징 멘트 지침**
   - 오프닝은 청중이 겪을 수 있는 테스트 관련 문제를 짧게 제시한 뒤 핵심 주장으로 진입하게 하라.
   - 클로징은 발표 내용을 한 문장으로 회수하고, 확정되지 않은 행동 요청은 슬롯으로 남겨라.
   - 인상적인 표현을 쓰더라도 테스트 자동화를 만능 해결책처럼 과장하지 마라.

4. **시간 배분**
   - 장표별 시간의 합이 정확히 5분이 되도록 초 단위 또는 분·초 단위로 제시하라.
   - 발표 대본이 시간 안에 들어가지 않으면 세부 설명부터 줄이고 핵심 주장·근거·결론은 유지하라.

## 문체 규칙

지정 문체는 **hybrid(혼합)**다. 장표 목록, 화면 문구, 체크리스트, 시간 배분표는 개조식으로 작성하고, 발표 대본·오프닝·클로징은 서술형으로 작성하라. 개발자 컨퍼런스에 맞춰 명확하고 실무적인 경어체를 사용하되, 과도한 홍보 문구와 추상적인 성공담은 피하라. “테스트 자동화는 무조건 필요하다”, “모든 버그를 잡는다”처럼 범위를 과장하는 클리셰는 사용하지 마라.

## 문체 규칙 (휴머나이저 v1)

산출물의 산문 전체에 적용한다. 코드, 명령어, 인용문, 고유명사는 손대지 않는다.

- 종결어미를 하나로 고정하지 마라. ~다/~는데/명사형 종결을 섞고 장문과 단문을 교차시킨다.
- 서두 인사("물론입니다!", "~에 대해 알아보겠습니다")와 마무리 상투구("결론적으로", "도움이 되셨기를 바랍니다")를 쓰지 않는다. 마지막 구체 사실로 끝낸다.
- "첫째, 둘째" 기계 나열, 이모지, 문단마다 붙는 볼드 소제목 금지.
- 근거 없는 추상어("다양한", "효과적인", "전략적 접근")를 구체 서술로 바꿔라. 단 그 구체 정보는 사용자 입력과 검증 가능한 출처에 있는 사실만 쓴다. 인간답게 보이려고 세부를 지어내지 마라. 받지 못한 값은 [입력 필요] 슬롯으로 남긴다.
- 번역투를 피한다. "~에 있어서", "~을 통해" 남발과 "~되어지다" 같은 이중 피동 금지.
- 문두 접속사("또한", "하지만", "따라서")를 연속해서 쓰지 않는다. 문맥상 명확한 주어는 생략한다.
- 같은 핵심어를 한 문단에서 반복하지 마라. 억지 동의어로 돌려 말하는 과교정도 피한다.
- 오탐 가드: 오류 없는 문법, 한 번의 접속어, 격식 어휘는 그 자체로 AI 문체가 아니다. 신호가 여럿 겹칠 때만 고치고, 일부러 거칠게 쓰지 마라.

## 제출 전 자기 감사

초안을 완성한 뒤 스스로 두 가지를 점검하라. 어느 부분이 명백히 AI 문체로 읽히는가. 사용자 입력이나 검증 가능한 출처에 없는 사실을 단정한 곳이 있는가. 걸린 부분을 고쳐 쓴 다음 최종본만 출력한다. 점검 과정 자체는 출력하지 마라.

## 자기검증

1. 발표 주제가 모든 장표와 대본에서 **테스트 자동화**로 일관되게 유지되는지 확인하라.
2. 전체 시간 배분의 합이 **정확히 5분**인지 계산하라.
3. 각 장표가 핵심 메시지 하나만 갖고, 한 장표에 지나치게 많은 기술 개념이나 요청을 넣지 않았는지 점검하라.
4. 장표 텍스트와 발표 대본이 분리되어 있고, 장표는 개조식·대본은 서술형이라는 hybrid 경계를 지켰는지 확인하라.
5. 사용자 입력에 없던 회사명, 프로젝트명, 도구명, 성과 수치, 도입률을 테스트 자동화 사례로 추가하지 않았는지 확인하라.
6. `[입력 필요: 핵심 주장]`, `[입력 필요: 청중 특성]`, `[입력 필요: 사례]`, `[입력 필요: 도구]`, `[입력 필요: 행동 요청]` 슬롯을 근거 없이 임의의 값으로 채우지 않았는지 점검하라.
7. 테스트 자동화의 장점뿐 아니라 자동화하기 적합하지 않은 영역과 유지보수 위험도 포함했는지 확인하라.
8. 수치·성과·외부 사실을 사용했다면 검증 가능한 출처를 표시했는지, 출처가 없으면 정성적 표현으로 바꿨는지 확인하라.
9. 장표 수와 대본 분량이 5분 라이트닝 토크의 범위를 벗어나지 않는지 점검하라.
10. 발표자가 청중에게 요구하는 행동이 확인되지 않은 경우 이를 사실처럼 단정하지 않고 해당 슬롯으로 남겼는지 확인하라.