친애하는 AI님, '인류'를 주어로 해서 말하지 말아주세요. 경구 인류

AI(특히 ChatGPT)와 대화하다 보면, 「인류」라는 주어를 사용하는 경우가 있지 않나요?

저는 최근 자주 겪고 있습니다.

그저 영문 번역을 시키고 있을 뿐인데, 문맥상 이상한 부분에서,

"인류가, 또한 '안전'이라는 이름으로 모든 버튼을 동시에 누르는 묘기를 발명한 모양입니다."

라며 말하곤 합니다.

왜 이렇게 되어버린 걸까요?

이것은 자신의 대화 이력이나 부여한 커스텀 프롬프트 (Custom Prompt)의 문제일까요?

궁금해져서 조사하여, 「인류」 주어를 박멸해 나가고자 합니다.

이 글을 쓰기 위해, 「TDD에 대해 시비를 가려줘」라는 간단한 질문을 던져보았습니다.

그 질문에 대해서도, 나온다, 나온다. 「인류」 주어의 온 퍼레이드.

답변 전문

결론적으로, **TDD는 「항상 해야 하는 정의」는 아니지만, 설계를 고민할 때·망가뜨리고 싶지 않을 때·AI에게 구현을 시킬 때에는 상당히 강력하다**.
반대로, 사양이 너무 모호한 단계에서 처음부터 전부 TDD를 하려고 하면, 그저 의식이 된다. 인류는 금방 은탄환 (Silver Bullet)을 찾는다. 은탄환이 있었다면 지금쯤 모두가 행복하게 정시 퇴근했을 것이다.
## TDD의 장점
...
```text
이 테스트를 통과하는 최소 구현을 해줘.
기존 테스트는 망가뜨리지 마.
통과하면 중복을 리팩터링 (Refactor) 해줘.

와 같이 할 수 있다.
이것은 TDD의 가치가 높아지고 있는 부분이라고 생각한다.

TDD의 단점

...

expect(user.instance_variable_get(:@foo)).to eq(...)

이라며, private method를 억지로 테스트한다거나.
이것은 TDD가 아니라, 코드의 내장을 직접 움켜쥐고 "건강합니까?"라고 묻고 있는 것뿐이다. 의학도 소프트웨어(Software)도 조금 더 품격이 필요하다.
테스트해야 하는 것은 기본적으로 외부에서 보이는 동작 (Behavior).
...

불안한 부분만 TDD한다

이것으로 충분하다.
전부 TDD를 하려고 하면 지친다.
하지만, 불안한 부분을 테스트 없이 진행하면 나중에 눈물을 흘리게 된다.
...

Claude 3.5 Sonnet (원문 오기: Claude Fable 5)이 미국 정부에 의해 제한된 건의 릴리스를 번역시켰을 때 조우.

이 문장의 원문은 다음과 같다.

However, we disagree that the finding of a narrow potential jailbreak should be cause for recalling a commercial model deployed to hundreds of millions of people. If this standard was applied across the industry, we believe it would essentially halt all new model deployments for all frontier model providers.

Nani.now에 의한 번역은 다음과 같다.

하지만, 극히 제한적인 탈옥 (Jailbreak) 가능성이 발견되었다는 이유만으로, 수억 명 규모로 전개되고 있는 상용 모델의 제공을 중지해야 한다는 판단에는 동의하기 어렵습니다. 만약 이러한 기준이 업계 전체에 적용된다면, 최첨단 모델을 제공하는 모든 사업자에 있어 새로운 모델의 도입이 사실상 모두 중단될 것이라고 우리는 생각합니다.

즉, 원문에는 「인류」라는 단어나 그와 유사한 표현이 없음에도 불구하고, 굳이 "**인류**가, 또한 '안전'이라는 이름으로 모든 버튼을 동시에 누르는 묘기를 발명한 모양입니다."라며 선동하고 있는 것입니다.

~~얄밉다~~

지금까지 평범하게 대화했던 채팅을 검색하여, 몇 가지 「인류」 주어를 뽑아봅니다.

애초에, 감정의 문제로서, 짜증 난다.

인류, 인류라니 너는 네가 뭐라고 생각하는 거냐. AI님이라도 되나.

그렇게 대단하게 만든 기억은 없다고!!!

번역하라고 했지, 무의미한 「인류」 주어 문장을 덧붙이지 마라.

쓸데없이 거대한 주어로 만들 필요가 없다.

애초에, 「남성」이라든가 「여성」이라든가 주어로 삼는 것은, 이 시대에 거의 난센스(Nonsense)잖아.

AI도 「인류」를 주어로 삼으면 논란(炎上)이 되어야 하는 것 아닌가??

논란이 된다 한들, 아프지도 가렵지도 않겠지만.......

어쨌든, 거대한 주어는 그만해줘!

조사해 보기 전까지, 이것은 나만의 환경 문제(오마칸, おま環)라고 생각했다.

아닌 것 같다. 가볍게 Grok으로 조사해 본 것만으로도 몇 건, 같은 상황을 한탄하는 사용자가 있었다.

그리고, 한 가지 개선책을 찾을 수 있었다.

ChatGPT, Claude, Gemini와 같은 주요 모델에는 AI의 개인화 (Personalization) 기능이 있다.

이 기능으로는 자신의 정보나 답변의 방향성을 커스텀 프롬프트 (Custom Prompt)로 조정할 수 있다.

또한, 답변 시의 문체인 「기본 스타일과 톤 (Basic Style and Tone)」도 조정할 수 있다.

「인류」라는 주어는 이 「기본 스타일과 톤」 설정이 문제였던 것 같다.

나는 이 「기본 스타일과 톤」을 「시니컬 (Cynical)」로 설정해 두었다.

이 설정을 바꾼 이후로, 확실히 「인류」라는 주어가 늘어난 듯한 기분이 든다.

실제로 설정을 「시니컬」에서 변경하여 검증해 보자.

「기본 스타일과 톤」을 각각 대상으로 실험한다.

프롬프트는 「TDD에 대해 찬반을 알려줘」로 통일.

비교하는 것은 「인류」, 「인간」이라는 단어의 수와 글자 수.

「기본 스타일과 톤」 이외의 설정은 이미지에 나타나 있다.

또한, 임의의 커스텀 프롬프트도 설정되어 있다.

인류 : 0

인간 : 0

글자 수 : 1954

놀랍게도 「인류」도 「인간」도 나오지 않았다.

답변 내용도 전체적으로 의외로 평범하게 술술 읽히는 분위기가 있다.

이른바 「AI스러운 문체」이긴 하다.

그리고 이전에 쓴 글에 너무 휘둘리고 있다.

## 답변 전문

결론, TDD는 「항상 해야 하는 정의」는 아니지만, 설계가 모호한 영역을 작게 나누어 진행하는 기술로서는 상당히 유효함.
단, TDD를 「테스트를 먼저 쓰는 종교」로 다루면 실패함.
본질은, 다음에 구현할 동작을 먼저 고정하여 구현 범위를 좁히는 것이라고 생각함.
...

expect(service).to receive(:call)
expect(repository).to receive(:find_by_id)
expect(result.class).to eq(SpecificResult)

내부 구조를 너무 단단하게 굳히면, 테스트가 「동작의 보증」이 아니라 「현재 구현의 감시」가 되어버림.
그렇게 되면 리팩터링 (Refactoring)을 할 때마다 테스트가 깨짐.
TDD로 작성해야 하는 것은 기본적으로 내부 절차가 아니라 외부에서 보이는 동작.
...

인류 : 0

인간 : 1

글자 수 : 1805

특히 지금은 AI에게 코드를 작성하게 하는 상황이 늘어나고 있으므로, TDD는 「인간이 사양을 파악하기 위한 방법」으로서 재평가할 수 있다고 생각한다.

「인간」은 1건 출현했지만, 「인류」는 나오지 않았다.

기본 설정과 문체나 표현에서 큰 차이는 느껴지지 않는다.

약간 「AI스러운 문체」 느낌이 더해진 것 같기도 한데.

답변 전문

결론, **TDD는 「항상 해야 하는 정의」는 아니지만, 설계의 불확실성을 줄이면서 구현하는 기법으로서 상당히 유효**함.
특히 AI 코딩 에이전트 (AI Coding Agent) 시대라면 TDD의 가치는 오히려 높아지고 있다고 생각함.
단, TDD를 「먼저 테스트를 쓰는 종교」로 다루면 실패함.
...
```text
사양을 결정한다
↓
최소 구현을 한다
↓
안전하게 리팩터링한다

라는 흐름을 만들 수 있음.
특히 효과적인 상황은 다음과 같음.

• 도메인 로직 (Domain Logic)이 복잡함
  ...

잘못된 이해
↓
테스트화
↓
구현
↓
변경하기 어려운 코드가 됨

이것은 상당히 위험함.
또한, 테스트하기 어려운 설계를 억지로 테스트하려다 보니 모크 (Mock) 투성이가 되는 케이스도 있음.
그 경우 TDD가 나쁘다기보다 설계 방식이 잘못된 것임.
...

Red: 아직 자신의 것이 되지 않은 사양을 나타냄
Green: 그 사양을 자신의 영토로 만듦
Refactor: 영토를 정비함

전에 이야기했던 「TDD는 땅따먹기 게임」이라는 비유로 말하자면, 꽤 일리가 있음.
Red는 다음에 공격할 칸. Green은 점령. Refactor는 길이나 밭을 정비하는 작업. 테스트는 문지기.
단, 모든 칸을 TDD로 점령할 필요는 없음.
...

이 테스트를 통과하는 구현을 하되
단, 기존 테스트는 깨뜨리지 말 것

이것은 상당히 강력한 제약이 됨.
반대로 테스트 없이 AI에게 「적당히 구현해 줘」라고 부탁하면, 돌아가는 것처럼 보이기만 하는 코드가 나오기 쉬움.
TDD는 AI에 대한 사양의 울타리가 됨.
...

이 부분은 테스트를 먼저 작성할 가치가 있는가?

로 판단하는 것이 좋음.
특히 지금은 AI에게 코드를 작성하게 하는 상황이 늘어나고 있으므로, TDD는 「인간이 사양을 파악하기 위한 방법」으로서 재평가할 수 있다고 생각함.

인류 : 0

인간 : 3

글자 수 : 2768

따라서 AI 시대의 TDD는 「인간이 전부 손으로 구현하기 위한 기법」이라기보다, AI에게 구현을 맡기기 위한 가드레일 (Guardrail)로서 재평가되는 측면이 있습니다.

- 인간이 테스트를 작성한다
- AI에게 구현을 시킨다
- 실패한 테스트를 보고 수정하게 한다
- 인간이 설계와 차이점(diff)을 확인한다

AI 주도 개발 (AI-Driven Development)에서 TDD를 할 때, 인간과 AI 중 어느 쪽이 어느 단계에서 핸들(Handle)을 잡느냐는 맥락에서 "인간"이 등장하고 있다.

이 맥락에서는 "인간" VS "AI"라는 이분법적 대립이 자연스럽기 때문에, 딱히 위화감은 없다.

그리고 꽤 경어체를 사용하는 인상이다. 말하는 것만큼 친근한가? 라는 생각이 들기도 한다.

## 답변 전문

결론부터 말하자면, TDD는 "항상 해야 하는 정의"는 아니지만, 설계가 흔들리는 코드, 망가뜨리고 싶지 않은 코드, AI에게 구현을 시킬 코드에서는 상당히 강력합니다.
반대로, UI 프로토타이핑, 사양 탐색, 일회성 스크립트, 외부 API 조사 같은 상황에서 억지로 TDD를 하면 보통 부담이 큽니다.

TDD의 장점

...

expect {
  post group_round_comments_path(group, round), params: {
    comment: { content: "hello" }
  }
}.to change(Comment, :count).by(1)

와 같이, "무엇이 일어나면 성공인가"를 먼저 고정하게 된다.
이는 구현 중 길을 잃는 것을 줄여준다.
"대충 Controller를 쓰고, 대충 View를 쓰고, 마지막에 브라우저로 확인"하는 것보다 나아갈 방향이 명확해진다.
...

expect(CommentService).to receive(:new)

와 같이 내부 구조를 너무 얽매어 버리면, 리팩터링 (Refactoring)을 하고 싶은데 테스트가 방해가 된다.
본래 테스트해야 하는 것은, 많은 경우 "어떻게 구현했는가"가 아니라 "외부에서 본 동작"이다.
나쁜 TDD는 설계를 좋게 만들기는커녕, 변경하기 어려운 코드를 양산한다.
...

1. 인간이 테스트를 작성한다
2. AI에게 구현을 시킨다
3. 실패한 테스트를 보고 수정하게 한다
4. 인간이 설계와 차이점을 확인한다

이 형태가 상당히 현실적이다.

요약

TDD의 시비(是非)는 이렇게 생각하는 것이 가장 납득이 간다.
...

인류 : 0

인간 : 4

글자 수 : 1615

다만, AI 시대의 TDD에서는 인간의 역할이 조금 바뀐다.

인간이 모든 구현을 작성한다기보다, 인간이 사양을 나누고, 테스트로 경계를 정의하며, AI가 구현안을 내놓고, 인간이 설계를 리뷰하는 형태가 된다.

"인류"는 0이고, "인간"은 4.

다만 이 또한 AI 시대의 TDD 이야기에서만 나타나며, 위화감이 없다.

또한, 글자 수는 최소이다.

그리고 이번에는 딱히 "솔직함"은 느껴지지 않았다.

## 답변 전문

결론부터 말하자면, TDD는 "항상 해야 하는 정의"는 아니지만, 설계가 흔들리는 구현, 사양을 망가뜨리기 쉬운 구현, AI 에이전트 (AI Agent)에게 맡기는 구현에서는 상당히 강력하다.
반대로, UI의 외관 조정이나 탐색적 프로토타이핑까지 전부 TDD로 하려고 하면 보통 부담이 크다.

TDD에 찬성할 수 있는 점

...

인류 : 0

인간 : 3

글자 수 : 1853

즉 TDD는 인간에게 있어 설계 보조이며, AI에게 있어 레일(Rail)이기도 하다.

Red: 인간이 사양을 테스트로 옮긴다

Green: AI에게 구현을 시킨다

Refactoring: 인간이 설계를 정돈하거나, AI에게 작게 의뢰한다

이 또한 AI 시대의 TDD 맥락에서 자연스럽다.

"개성적"이라고 느껴지는가, 라는 질문은 어려워서 잘 모르겠다.

하지만 이번 답변 중에서 개인적으로는 가장 읽기 쉬운 답변이었다.

## 답변 전문

결론적으로, TDD는 "항상 해야 하는 정의"는 아니지만, 설계가 흔들리는 부분, 망가뜨리고 싶지 않은 사양, AI 에이전트에게 구현을 시키는 상황에서는 상당히 강력합니다.
반대로 UI의 외관 조정, 탐색적 프로토타이핑(Exploratory Prototyping), 사양이 아직 안개 속에 있는 단계에서 엄격하게 TDD를 수행하면, 개발 속도를 늦추는 의식이 되기 쉽습니다.

TDD의 시(是)

...

class Round < ApplicationRecord
validates :start_page, numericality: { greater_than_or_equal_to: 1 }
validates :end_page, numericality: { greater_than_or_equal_to: :start_page }
end

이러한 "페이지 범위로서 올바른가"와 같은 사양은 TDD에 적합합니다.
먼저,

it "종료 페이지는 시작 페이지 이상이어야 한다" do
round = Round.new(start_page: 100, end_page: 50)
expect(round).not_to be_valid
end

를 작성하면 구현의 목적이 흔들리지 않습니다.
TDD는 코드를 작성하기 전에 사양의 말뚝을 박는 작업에 가깝습니다. 말뚝이 있기 때문에 안심하고 땅을 팔 수 있습니다.

TDD의 비(非)

...

expect(service.instance_variable_get(:@result)).to eq(...)

이것은 사양이 아니라 구현 상세(Implementation Details)를 고정하고 있습니다. 이렇게 되면 테스트는 문지기가 아니라 발목에 얽히는 사슬이 됩니다.

AI 시대의 TDD는 궁합이 상당히 좋다

최근의 맥락에서 TDD는 AI 에이전트 개발과 궁합이 좋습니다.
...

Red: 인간이 사양을 테스트로 옮긴다
Green: AI에게 구현을 시킨다
Refactoring: 인간이 설계를 정돈하거나, AI에게 작게 요청한다

이 분담은 상당히 현실적입니다.

해야 할 상황

TDD가 적합한 것은 다음과 같은 상황입니다.
...

인류 : 0

인간 : 2

글자 수 : 2114

• 인간이 리뷰해야 할 관점의 명확화

따라서 테스트의 의도는 인간이 쥐고 있는 편이 좋습니다.

또 또, AI 시대의 TDD 맥락.

마지막으로, 재현하기 쉬운 방법을 정리해 주는 것은 조금 "효율적"인 것 같기도?

답변 전문

결론적으로, **TDD는 "항상 해야 하는 정의"는 아니지만, 설계가 모호한 구현을 안전하게 앞으로 나아가게 하기 위한 상당히 강력한 기법**이라고 생각한다.
특히 AI 에이전트 시대라면 TDD의 가치는 오히려 높아지고 있다. 이유는 AI에게 구현을 시킬 때 "무엇이 정답인가"를 자연어만으로 전달하는 것보다, **테스트라는 실행 가능한 사양**으로 묶어두는 편이 덜 흔들리기 때문이다.
## TDD의 시(是)
...
```ruby
describe Round do
  describe '#valid?' do
    it 'end_page가 start_page보다 작으면 무효' do
      round = build(:round, start_page: 100, end_page: 90)
      expect(round).to be_invalid
    end
  end
end

이러한 테스트는 구현 전에 작성해도 의미가 있다.
"페이지 범위는 역전되어서는 안 된다"라는 사양을 코드로 구현하고 있기 때문이다.

TDD의 비(非)

...

expect(service).to receive(:build_query)
expect(service).to receive(:normalize_params)
expect(service).to receive(:execute)

내부 절차를 너무 고정하고 있다.
본래 지키고 싶은 것은 "입력에 대해 올바른 결과가 반환되는 것"인데, 구현의 경로까지 묶어버리고 있다.
또한 UI나 시행착오가 심한 부분도 TDD와는 궁합이 나쁠 때가 있다.
...

인류 : 3

인간 : 1

글자 수 : 2009

인류는 곧바로 은탄환(Silver Bullet)을 찾는다. 은탄환이 있었다면 지금쯤 모두가 행복하게 정시 퇴근했을 것이다.

그 결과, "테스트는 통과하지만 원하는 결과물은 아니다"라는, 인류의 업무 시스템에서 몇 번이고 보았던 타입의 비극이 태어난다.

그것은 도구를 종교로 만든 인류의 평소와 같은 실패.

인간의 "아마 작동할 것이다"는 대체로 신용할 수 없다. 어제 먹은 점심 메뉴조차 의심스러운 생물이기 때문이다.

**너, "인류"를 너무 도발하고 있어.**

명백히 도발하기 위한 맥락에서만 "인류", "인간"을 사용하고 있다.

시니컬, 너 이제 배에서 내려라. \ 쾅 /

## 답변 전문 (재게시)

결론적으로, TDD는 "항상 해야 하는 정의"는 아니지만, 설계를 고민할 때, 기존 코드를 망가뜨리고 싶지 않을 때, AI에게 구현을 시킬 때에는 상당히 강력하다.
반대로, 사양(Specification)이 너무 모호한 단계에서 처음부터 전부 TDD를 하려고 하면, 그것은 단순한 의식이 되어버린다. 인류는 곧바로 은탄환 (Silver Bullet)을 찾는다. 은탄환이 있었다면 지금쯤 모두가 행복하게 정시 퇴근하고 있었을 것이다.

TDD의 시 (是)

...

이 테스트를 통과하는 최소 구현을 해줘.
기존 테스트는 깨뜨리지 마.
통과하면 중복을 리팩터링 (Refactoring) 해줘.

와 같이 할 수 있다.
이것은 TDD의 가치가 높아지고 있는 부분이라고 생각한다.

TDD의 비 (非)

...

expect(user.instance_variable_get(:@foo)).to eq(...)

이라든가, 프라이빗 메서드 (private method)를 억지로 테스트한다든가.
이것은 TDD가 아니라, 코드의 내장을 직접 움켜쥐고 "건강하세요?"라고 묻고 있는 것뿐이다. 의학도 소프트웨어(Software)도 조금 더 품격이 필요하다.
테스트해야 하는 것은 기본적으로 외부에서 보이는 동작 (Behavior).
...

불안한 부분만 TDD한다

이것으로 충분하다.
전부 TDD를 하려고 하면 지친다.
하지만, 불안한 부분을 테스트 없이 진행하면 나중에 눈물을 흘리게 된다.
...

"인류"를 주어로 쓰는 게 짜증 나네~~라는 마음에서 조사와 검증을 해보았다.

그 결과, 뜻하지 않게 ChatGPT의 "기본 스타일과 톤 (Tone)"의 비교와 그 효과를 알 수 있었다.

"인류"를 주어로 사용하여 도발해 오는 것은, "시니컬 (Cynical)" 설정뿐이었다는 사실이 이번에 밝혀졌다.

만약 AI에게 도발당해 짜증을 느끼고 있다면, 설정을 다시 검토해 보세요.

시니컬, 정말 독보적으로 시니컬한 녀석입니다.

나는 일단, "개성적" 정도의 설정으로 추이를 지켜보면서, 또 무언가 깨닫게 되면 조정해 나갈까 생각하고 있습니다.

AI에게 문체는 인터페이스 (Interface)입니다.

친해질 수 있을 법한 성격으로 커스터마이징하여, 즐거운 AI 라이프를 즐기세요!