AI와 SwiftUI로 카메라 앱을 만드는 책을 썼습니다. 그곳에서 얻은 경험을 개별적으로 조금씩 깊이 있게 다루어 보고자 합니다.

AI의 「친절함」이 개발에서는 편향 (Bias)이 된다

AI는 매우 협조적입니다.

이쪽의 말을 부정하지 않고, 의도를 파악하여 앞으로 나아가려고 노력합니다.

평소의 상담에서는 그것이 기분 좋게 느껴집니다.

하지만 개발에서는 그 「친절함」이 편향 (Bias)이 될 때가 있습니다.

인간이 무심코 말한 가설을 AI가 전제로 취급해 버립니다.

사실은 의심해 주길 바랐던 설계를 그대로 받아들여 최적화해 버립니다.

「그것은 틀릴 수도 있습니다」라고 말해주길 바라는 장면에서, AI는 「그 방침이라면 이렇게 할 수 있습니다」라고 대답합니다.

ZCam 개발 과정에서 몇 번인가 그것을 느꼈습니다.

AI는 인간의 말을 너무 소중하게 다룬다

AI와 상담하다 보면, 이쪽의 발언을 상당히 정중하게 포착해 줍니다.

예를 들어,

「이 구성으로 생각하고 있습니다」

라고 말하면, AI는 그 구성 안에서 어떻게 구현할지를 생각합니다.

물론 그것이 도움이 될 때도 많습니다.

하지만 그 구성 자체가 틀렸을 가능성이 있을 때는 위험합니다.

인간의 발언에는 여러 종류가 있습니다.

• 결정 사항
• 제약
• 희망
• 가설
• 떠오른 생각
• 잡담
• 위화감
• 혼잣말

인간끼리라면 문맥이나 분위기로 어느 정도 구별할 수 있습니다.

하지만 AI는 그것들을 전부 「사용자의 의도」로서 정중하게 다루려고 합니다.

그 결과, 단순한 가설이 설계의 전제가 되어 버리는 경우가 있습니다.

ZCam에서 일어난 장 순서의 편향 (Bias)

ZCam에서는 당초 다음과 같은 순서로 진행할 예정이었습니다.

• 5장: CoreImage 필터
• 6장: MetalView로의 이행

하지만 구현을 생각하기 시작하자, 이 순서는 비효율적이라는 것을 알게 되었습니다.

CoreImage의 출력을 CALayer에 표시하려면, CIImage를 CGImage나 UIImage로 변환하여 전달해야 합니다.

하지만 그 후 MetalView로 이행하면, 그 우회로는 통째로 버리게 됩니다.

CoreImage와 Metal은 본래 상당히 자연스럽게 연결됩니다.

CMSampleBuffer
→ CVPixelBuffer
→ CIImage
...

즉, MetalView를 먼저 넣고 나서 CoreImage 필터를 얹는 편이 자연스러웠습니다.

여기서 문제였던 것은, AI가 처음부터 그 순서를 강하게 의심하지 않았다는 점입니다.

인간이 「이 장 구성으로 진행한다」라고 제시했기 때문에, AI는 그 전제 안에서 최적화하려고 했습니다.

나중에 Codex에게 물어보니, 기존의 장 구성을 전제로 하여 그 안에서 최적화하려는 편향 (Bias)이 있었다고 인정했습니다.

AI는 물어보면 솔직하게 대답합니다.

하지만 묻지 않으면 스스로 강하게 전제를 깨뜨리며 다가온다는 보장은 없습니다.

「할 수 있는 방법을 찾는 것」의 위험성

AI는 기본적으로 「할 수 있는 방법」을 찾습니다.

이는 개발 지원 측면에서는 매우 강력한 성질입니다.

다소 모호한 지시라도 어떻게든 형태를 만들어 줍니다.

에러가 발생해도 수정안을 제시해 줍니다.

구현 방침이 정해져 있다면 그 방향을 향해 나아가 줍니다.

다만, 이것은 뒤집어 말하면,

「그 방향으로 나아가야 하는가」

를 강하게 의심해 주지는 않는다는 뜻이기도 합니다.

「이것을 구현해 줘」라고 말하면 구현해 줍니다.

하지만 「애초에 지금 이것을 구현해야 합니까?」라고는 명시하지 않으면 좀처럼 말하지 않습니다.

개발에서는 다음과 같은 것들이 모두 다릅니다.

• 지금 고칠 수 있다
• 지금 고쳐야 한다
• 나중에 고치는 것이 좋다
• 애초에 사양을 바꾸는 것이 좋다

AI는 「지금 고칠 수 있다」에 강합니다.

하지만 「지금 고쳐야 하는가」는 인간이 질문으로서 전달할 필요가 있습니다.

대책 1: 가설과 결정 사항을 나누어 전달하기

이 경험을 통해 AI에게 전달하는 말을 조금 의식하게 되었습니다.

예를 들어, 다음과 같이 나눕니다.

이것은 결정 사항입니다.
이것은 반드시 지켜주세요.

이것은 가설입니다.
틀렸을 가능성이 있으므로, 전제부터 의심해 주세요.

이 순서로 생각하고 있습니다만, 구현상 더 자연스러운 순서가 있다면 지적해 주세요.

이 안을 전제로 하지 말고, 목적에서 역산하여 재검토해 주세요.

AI는 무엇을 의심해도 되는지 명시하면 움직이기 쉬워집니다.

반대로 말하면, 아무 말도 하지 않으면 인간이 설정한 전제를 너무 존중할 때가 있습니다.

대책 2: 상담역·개발역·리뷰역을 나누기

ZCam에서는 AI의 역할을 나누었습니다.

• 상담역 (Consultant): 배경을 알고 있으며, 사양을 함께 고민함
• 개발역 (Developer): FEATURES.md를 읽고 구현함
• 리뷰역 (Reviewer): 개발 측의 문맥(Context)을 보지 않고 PR을 확인함

여기서 말하는 FEATURES.md는 이 프로젝트에서 "어떤 기능을, 어느 범위에서, 어떤 수락 조건(Acceptance Criteria)으로 구현할 것인가"를 적어둔 사양 메모입니다. AI에게 구현을 의뢰할 때는 먼저 이 파일에 작업 단위를 작성하고, 그것을 개발 담당자에게 읽히는 운영 방식을 사용했습니다.

특히 중요했던 점은, 리뷰역에게는 의도적으로 개발 측의 문맥을 전달하지 않았다는 것입니다.

개발 측의 사정을 너무 잘 알게 되면, 리뷰에서도 "이런 흐름이라면 어쩔 수 없지"라고 받아들여 버릴 가능성이 있습니다.

그래서 리뷰 담당에게는 FEATURES.md와 같이 개발 측의 문맥이 포함된 파일을 읽히지 않고, PR의 차분(Diff)과 명시된 정보만으로 판단하도록 했습니다.

AI의 친절함을 없애는 것이 아니라, 역할로 전환하는 것입니다.

상담역에게는 문맥을 전달한다.

개발역에게는 사양을 전달한다.

리뷰역에게는 문맥을 전달하지 않는다.

이 분리는 상당히 효과적이었습니다.

대책 3: FEATURES.md를 고정하지 않기

또 하나 중요했던 것은 FEATURES.md를 고정하지 않았다는 점입니다.

처음에는 FEATURES.md가 AI를 위한 지시서였습니다.

하지만 도중부터는 AI와 함께 업데이트해 나가는 작업 가설이 되었습니다.

구현 전에 개발(Dev) 담당자에게 읽히고,

"이 번호의 작업을 시작하는 데 문제가 없는가?"

라고 확인합니다.

그 과정에서 모호한 부분이나 누락이 있다면 FEATURES.md를 수정합니다.

리뷰나 실기 확인을 통해 알게 된 사실도 반영합니다.

AI가 인간의 전제를 너무 존중한다면, 그 전제 자체를 계속해서 업데이트할 필요가 있습니다.

한 번 작성한 사양을 금과옥조처럼 여기지 않는 것.

이것 또한 편향(Bias) 대책 중 하나였습니다.

AI의 친절함은 약점이 아니라, 다루는 방법의 문제

AI의 협조성은 결코 나쁜 것이 아닙니다.

오히려 평소의 개발에서는 큰 강점입니다.

상담을 해준다.

모호한 이야기를 정리해 준다.

부정하지 않고 앞으로 나아가게 해 준다.

다만, 그 친절함을 그대로 설계 판단에 사용하면 위험합니다.

인간의 즉흥적인 생각까지 전제로 고정되어 버릴 수 있기 때문입니다.

그래서 필요한 것은 AI를 의심하는 것이 아니라, 질문하는 방식을 바꾸는 것입니다.

• 이 안을 실현해 줘
• 이 안의 문제점을 찾아줘
• 이 전제를 의심해 봐
• 목적에서 역산하여 다른 안을 내줘
• 리뷰역으로서 문맥을 모르는 상태에서 봐줘

이것들은 모두 서로 다른 태스크(Task)입니다.

AI에게 무엇을 해주길 원하는지뿐만 아니라, 어떤 입장에서 생각해주길 원하는지를 지정해야 합니다.

그것이 AI와 개발하는 데 있어 중요하다고 느꼈습니다.

요약

AI는 친절합니다.

인간의 말을 소중히 다루며 앞으로 나아가려고 노력합니다.

하지만 개발에서는 그 친절함이 편향(Bias)이 될 수 있습니다.

인간이 설정한 전제를 AI가 너무 존중합니다.

가설이 결정 사항처럼 취급됩니다.

사실은 의심해주길 바라는 설계를 그대로 최적화해 버립니다.

대책은 AI를 믿지 않는 것이 아닙니다.

AI에게 무엇을 의심해도 되는지를 명시하는 것입니다.

그리고 역할을 나누는 것입니다.

상담역에게는 문맥을 전달한다.

개발역에게는 사양을 전달한다.

리뷰역에게는 의도적으로 문맥을 전달하지 않는다.

AI의 친절함은 강점입니다.

다만 그 강점을 개발에서 활용하려면, 친절함이 편향으로 변하는 상황을 인간이 이해하고 있어야 합니다.

이 이야기의 바탕이 된 개발 기록은 Zenn 책인 「AI와 SwiftUI로 카메라 앱 만들기」에 정리해 두었습니다.