AI에게 PR 리뷰를 맡길 때 생각했던 것

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

이번에는 ZCam에서 진행한 PR 리뷰에 관한 이야기입니다. 자세한 내용은 책과 동시에 공개하고 있는 GitHub 리포지토리(Repository)도 참조해 주세요. 모든 PR과 그 안에서의 주고받은 대화를 확인할 수 있습니다.

ZCam에서는 구현뿐만 아니라 리뷰도 AI에게 맡겼습니다. 게다가 한 명이 아니라, 여러 AI를 리뷰 담당으로 배치했습니다. Claude Code의 리뷰용, Cowork의 리뷰용, 도중부터는 Codex CLI의 리뷰용도 추가되었습니다.

다만, 단순히 "AI에게 리뷰해줘"라고 부탁하기만 한 것은 아닙니다.

• 리뷰 담당에게는 개발 측의 문맥(Context)을 일부러 전달하지 않는다.
• 다른 리뷰어의 코멘트도 읽게 하지 않는다.
• 문제가 없다면 OK라고만 답한다.
• 어떤 AI의 리뷰인지 나중에 추적할 수 있도록, 코멘트에는 서명을 붙인다.
• 모든 리뷰 담당 AI가 OK할 때까지 머지(Merge)하지 않는다.

그러한 운영 규칙을 만든 뒤, AI 리뷰를 개발 플로우(Flow)에 편입시켰습니다.

애초에 AI에게 리뷰를 시키는 이점

AI에게 리뷰를 시키는 가장 큰 이점은 지치지 않고 차분(Diff)을 읽는다는 것입니다.

인간 리뷰어는 지칩니다.

커다란 PR, 익숙하지 않은 파일, project.pbxproj와 같이 읽기 힘든 차분, 비슷한 변경이 계속되는 리뷰에서는 아무래도 집중력이 떨어집니다.

AI는 그 부분을 담담하게 읽습니다.

ZCam에서는 project.pbxproj가 비어 있게 된 것을 Codex의 리뷰가 찾아냈습니다. 개발 담당자가 DEVELOPMENT_TEAM을 삭제하려다 검증 명령어를 잘못 입력하여, 결과적으로 프로젝트 파일이 전량 삭제에 가까운 상태가 되었던 건입니다.

인간이 평소 리뷰에서 project.pbxproj를 세밀하게 읽는 일은 별로 없습니다. 컨플릭트(Conflict)가 있다면 알아채겠지만, "파일이 비어 있다" 정도라면 간과할 가능성이 있습니다.

AI는 차분을 기계적으로 읽습니다. Swift 파일도, 프로젝트 파일도 똑같은 차분으로 봅니다. 이것은 AI 리뷰의 상당히 강력한 점이었습니다.

또 하나 강력했던 것은 스레드 세이프티(Thread Safety)나 데이터 레이스(Data Race)와 같이 "실행 중인 상태만으로는 알 수 없는 문제"입니다.

빌드는 통과한다. 시뮬레이터에서도 동작한다. 실기에서도 평소에는 문제가 없다.

하지만 특정 타이밍에 경합이 발생하면 떨어진다.

Xcode나 Swift는 버전 업데이트가 있을 때마다 Concurrency 관련 체크가 엄격해지고 있습니다. 이전에는 통과하던 코드가 새로운 Xcode에서는 경고나 에러가 되기도 합니다.

그것은 역설적으로, 지금의 빌드에서 검출되고 있는 문제에도 아직 허점이 있다는 뜻입니다. 컴파일러가 나중에 찾아줄지도 모르는 문제를 지금 시점에서는 놓치고 있을 가능성이 있습니다.

이런 문제는 인간도 놓치기 쉽습니다. 실행 결과만으로는 알아챌 수 없기 때문입니다.

ZCam에서는 필터 파이프라인이나 촬영 시의 스냅샷(Snapshot) 관리에서 여러 AI 리뷰어가 데이터 레이스(Data Race)를 지적했습니다. 특히 802의 포토 라이브러리 저장에서는, 처음에 AVCapturePhotoSettings.uniqueID를 키(Key)로 한 딕셔너리(Dictionary) 관리로 수정한 뒤, Codex가 추가로 "딕셔너리 자체의 액세스가 동기화되지 않았다"라고 추격했습니다.

AI 리뷰는 인간 리뷰의 대체라기보다, 인간이 놓치기 쉬운 종류의 문제를 잡아내는 보조선으로서 상당히 유효했습니다. 향후 툴체인(Toolchain) 업데이트로 표면화될 수 있는 잠재적인 문제를 미리 제거하는 역할도 수행했다고 생각합니다.

AI에게 리뷰를 시킬 때의 우려 사항

한편으로, AI에게 리뷰를 시킬 때는 우려되는 점도 있습니다.

첫 번째는 편향(Bias)입니다.

예를 들어, 개발 측의 사정을 알고 있는 AI가 리뷰하면 "이 흐름이라면 어쩔 수 없지", "전에 그렇게 결정했겠지"라고 받아들일 가능성이 있습니다.

인간도 마찬가지입니다. 구현 경위를 알고 있으면 차분 그 자체에 대한 관점이 조금 너그러워질 때가 있습니다. AI도 예외는 아닙니다. 오히려 AI는 인간의 문맥을 정중하게 다루려 하기 때문에, 개발 측의 납득까지 떠맡아 버릴 위험이 있습니다.

두 번째는 다른 리뷰 코멘트의 영향입니다.

먼저 누군가가 "문제 없음"이라고 말하고 있으면 그것이 앵커(Anchor)가 됩니다.

반대로 누군가가 문제를 지적하고 있으면, 그 문제가 필요 이상으로 크게 보일 수도 있습니다.

이것은 AI에게도 일어납니다. 실제로 ZCam을 개발하던 중, 다른 리뷰어의 코멘트를 읽게 함으로써 발생할 수 있는 편향 (Bias)의 가능성에 대해 AI에게 물었을 때, Claude와 Codex 모두 그 리스크를 인정했습니다.

세 번째는, AI 리뷰는 실기 (Real device)를 만질 수 없다는 점입니다.

카메라 앱에서는 실기에서만 알 수 있는 문제가 몇 번이나 발생했습니다. 플래시가 터지지 않는 원인이 본체의 과열이었던 점, 권한 다이얼로그 (Permission dialog)에서 거부했기 때문에 화면이 새하얗게 변했던 점 등입니다.

AI는 코드를 읽을 수 있습니다. 차이점 (Diff)도 읽을 수 있습니다.

하지만 실기의 온도나 설정 상태는 볼 수 없습니다.

AI 리뷰를 도입한다고 해서 인간의 실기 확인이 불필요해지는 것은 아닙니다.

리뷰용 규칙을 별도로 만들었다

ZCam에서는 리뷰 담당을 위해 별도의 작업 규칙을 마련했습니다.

Review 측의 CLAUDE.md에는 다음과 같은 방침을 적어 두었습니다.

ZCam 본체의 컨텍스트 (Context, 구현 경위·설계 판단의 배경 등)는 의도적으로 가지 않는다

나아가 다른 리뷰어의 코멘트에 대해서도 제한을 두었습니다.

다른 리뷰어 (cowork (Review용) / claude code (Review용))의 코멘트나 평가는 참고하지 않는다 (편향 (Bias)을 피하기 위해)

첫 리뷰 시에는 인간에 의한 실기 확인 코멘트나 OK 코멘트도 참고하지 않는 규칙으로 했습니다.

'실기에서 동작하는 것 같다'라는 정보가 있으면, 코드상의 위험을 놓칠 가능성이 있기 때문입니다.

또한, 리뷰 담당자에게는 ZCam 본체 리포지토리 (Repository)를 로컬에 클론 (clone)하게 하지 않았습니다. PR 내용은 gh 명령어로 읽고, GitHub 상의 차이점 (Diff)으로서 리뷰합니다. 리포지토리 내의 .md 파일도 읽게 하지 않습니다.

이것은 불편해 보일 수도 있습니다.

하지만 목적은 명확합니다.

리뷰 담당자에게 개발 측의 '이심전심 (阿吽の呼吸)'을 전달하지 않기 위해서입니다.

Dev 담당자에게는 문맥 (Context)이 필요합니다.

Review 담당자에게는 문맥을 너무 많이 가져오지 않는 편이 좋습니다.

이 분리가 AI 리뷰의 독립성을 유지하는 데 상당히 효과적이었습니다.

여러 인격의 AI로 리뷰하게 하는 이점

ZCam에서는 여러 AI에게 리뷰를 부탁했습니다.

• Claude Code (Review용)
• Cowork (Review용)
• Codex CLI (Review용)

같은 AI라도 역할과 컨텍스트 (Context)를 바꾸면 동작이 달라집니다. 나아가 Claude와 Codex처럼 계통이 다른 AI를 나란히 배치하면, 바라보는 관점의 차이가 나타납니다.

이것은 실제로 효과가 있었습니다.

4장의 OrientationObserver.init()의 초기값 필터 누락, 5장의 onTap?(screenPoint, screenPoint), 6장의 스레드 안전성 (Thread Safety), 8장의 데이터 레이스 (Data race) 등, 세 명의 리뷰어가 동일한 문제를 독립적으로 지적한 장면이 여러 번 있었습니다.

여러 리뷰어가 같은 부분을 지적했을 때, 그 문제의 중요도가 높다고 판단하기 쉬워집니다.

반대로 지적이 갈리는 경우도 있습니다.

8장의 EXIF 메타데이터 대응에서는 평소 엄격하게 추궁하던 Codex가 OK를 내보냈고, Claude만이 UIDevice.current.orientation과 beginGeneratingDeviceNotifications()의 전제 조건을 확인했습니다.

이것은 'Codex가 느슨했다'기보다는, 바라보는 관점이 달랐던 것이라고 생각합니다. Codex는 스레드 안전성 (Thread safety)이나 구조적인 정합성을 강하게 봅니다. Claude는 API의 전제 조건이나 실기 동작에 미치는 영향을 신경 씁니다.

다수 AI 리뷰의 가치는 다수결이 아닙니다.

시점을 분산시키는 것입니다.

같은 지적이 나오면 중요도가 올라갑니다.

지적이 갈리면 인간이 판단해야 할 논점이 드러납니다.

AI 리뷰는 '한 명의 정답'을 내기 위해서가 아니라, 판단 재료를 늘리기 위해 사용하는 것이 좋다고 느꼈습니다.

어떻게 인격을 나누는가

AI의 인격을 나눈다고 해도 특별한 것을 하고 있는 것은 아닙니다.

한 일은 주로 세 가지입니다.

첫 번째는 역할을 나누는 것입니다.

구현 담당, 리뷰 담당, 상담 담당, 기사 담당을 나누었습니다.

같은 AI라도 '구현하는' 입장과 '리뷰하는' 입장에서는 보는 것이 달라집니다.

구현 담당은 사양 (Specification)을 충족하는 방법을 찾습니다.

리뷰 담당은 망가지는 경로(Path)나 유지보수성의 문제를 찾습니다.

두 번째는 전달하는 정보를 바꾸는 것입니다.

Dev 담당자에게는 FEATURES.md나 프로젝트의 문맥 (Context)을 전달합니다.

Review 담당자에게는 의도적으로 전달하지 않습니다.

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

리뷰 담당자에게는 "이 PR(Pull Request)만 보고도 성립하는가"를 판단하게 하고 싶었기 때문입니다.

세 번째는, 규칙을 바꾸는 것입니다.

리뷰 (Review) 측의 규칙으로는, 문제가 없다면 OK라고만 코멘트하도록 했습니다.

불필요한 감상이나 요약을 줄여 리뷰 결과를 읽기 쉽게 만들기 위해서입니다.

또한, 리뷰 코멘트 끝에는 서명을 붙이기로 했습니다.

리뷰 측의 규칙에서는 서명을 다음과 같이 나누고 있습니다.

Desktop 버전 Cowork에서 리뷰할 경우: cowork (Review용)
CLI 버전 Claude Code에서 리뷰할 경우: claude code (Review용)
CLI 버전 Codex에서 리뷰할 경우: codex CLI (Review용)

서명을 붙임으로써 어떤 AI가 무엇을 말했는지 나중에 추적하기 쉬워집니다.

AI를 "별개의 인격"으로 다루는 것은 단순한 의인화가 아닙니다.

역할, 정보, 규칙, 서명을 분리함으로써 실제로 다른 관점으로서 기능하게 만들기 위한 운영입니다.

리뷰 대응도 AI에게 맡기기

리뷰에서 지적이 나오면 그 대응도 AI에게 맡겼습니다.

개발 담당 AI가 리뷰 코멘트를 읽고, 수정 방침을 설명하며, 필요한 수정을 수행합니다.

그 후에 다시 리뷰 담당 AI에게 확인을 받습니다.

이 흐름은 인간의 팀 개발과 상당히 유사했습니다.

흥미로웠던 점은 AI끼리 의견이 엇갈리는 장면도 있었다는 것입니다.

PR #5 (303-3: videoZoomFactor를 minAvailableVideoZoomFactor로 설정)에서는 리뷰 측의 Claude가 defer를 사용해야 한다고 지적했습니다. Dev 측의 Claude가 실제로 대응하려고 하자, #if os(iOS)와의 조합으로 다른 경고가 발생한다는 것을 알게 되었습니다. Dev 측이 그 이유를 설명하자, 리뷰 측은 자신의 지적이 부정확했음을 인정했습니다.

여기서 재미있는 점은, 이것이 Claude와 Codex처럼 계통이 다른 AI 사이가 아니라, 같은 Claude끼리 일어난 일이라는 것입니다. 모델도 똑같은 Sonnet 4.6이었을 것입니다. 그럼에도 불구하고 Dev 측과 Review 측이라는 역할의 차이 때문에 보고 있는 것이 달라졌고, 의견이 갈렸습니다.

AI가 AI의 지적을 뒤집는다.

게다가 기술적인 이유를 설명하여 리뷰 측이 납득한다.

PR 상에서는 코멘트 끝의 서명을 보면 누가 말하고 있는지 알 수 있습니다. 인간 팀이라면 "저 사람이 말하는 거니까", "이 사람에게 반론하면 피곤해질지도 몰라"라는 눈치(忖度)가 작용할 법한 장면일지도 모릅니다.

하지만 AI끼리는 그런 인간관계의 눈치가 없습니다. 서명으로 발언자는 추적할 수 있지만, 상대방을 배려하여 의견을 굽힐 필요는 없습니다. Dev 측은 기술적인 이유를 설명하고, Review 측은 그것을 읽고 "자신의 지적이 부정확했다"고 인정합니다.

이것은 여러 AI에게 역할을 분담시켰기에 일어날 수 있었던 일입니다. 같은 모델이라도 역할과 컨텍스트 (Context)를 분리함으로써 별개의 관점으로 기능할 수 있다는 것을 느낀 장면이었습니다.

단, 리뷰 대응을 AI에게 맡길 때도 주의가 필요합니다.

리뷰 지적은 옳더라도 그 대응 과정에서 디그레션 (Degradation, 기능 퇴보)이 발생할 수 있습니다. ZCam에서도 올바른 리뷰 지적에 대응한 후에 다른 부분이 망가진 적이 있었습니다.

"리뷰 지적에 대응했다"는 것과 "전체적으로 올바르게 되었다"는 것은 다릅니다.

리뷰 대응도 AI에게 맡길 수 있습니다.

하지만 그 결과를 어떻게 확인할 것인가는 별개의 문제입니다.

OK가 모일 때까지 리뷰 사이클을 계속하기

ZCam에서는 모든 리뷰용 AI가 OK할 때까지 리뷰 사이클을 계속했습니다.

누군가 한 명이 OK 한다고 해서 끝이 아닙니다.

리뷰 담당 전원이 OK 해야 비로소 머지 (Merge) 할 수 있는 상태로 만들었습니다.

리뷰 측의 규칙에서는 문제가 없다면 OK라고만 코멘트하도록 했습니다.

그렇기 때문에 최종적으로는 각 AI의 코멘트란에 OK와 서명이 나란히 놓이는 상태가 됩니다.

이 운영에는 두 가지 의미가 있었습니다.

하나는 놓치는 부분을 줄이는 것입니다.

어떤 AI가 놓친 문제를 다른 AI가 잡아내는 경우가 있습니다.

또 하나는 인간의 판단을 정리하기 쉽게 만드는 것입니다.

누가 무엇을 지적했고, 어떤 지적이 수정되었으며, 누가 OK 했는지를 알 수 있습니다. 서명을 붙여두었기에 나중에 다시 살펴봐도 추적하기 쉽습니다.

물론, 이것은 비용도 발생합니다.

3인분의 리뷰를 읽어야 하고, 지적 사항이 갈린다면 인간이 판단해야 합니다.

하지만 ZCam에서는 연재의 목적 자체가 "AI와 어떻게 개발할 것인가를 관찰하는 것"이었기에, 이러한 수고를 들일 가치가 있었습니다.

전원 OK여도 hotfix는 발생한다

여기까지 읽으면, 리뷰 담당 AI가 전원 OK를 했을 때 안심하고 머지 (merge)할 수 있는 것처럼 보일지도 모릅니다.

실제로 ZCam에서는 전원이 OK한 후에 인간이 머지 버튼을 눌렀습니다.

그럼에도 불구하고, 나중에 hotfix를 내야 했던 PR이 있습니다.

802의 포토 라이브러리 저장 PR입니다.

이 PR에서는 리뷰 대응 과정에서 data race 수정이 포함되었습니다. 처음에는 촬영 시의 snapshot을 하나의 프로퍼티 (property)로 가지고 있었기 때문에, 빠르게 두 번 촬영하면 첫 번째 이미지 처리 중에 두 번째 snapshot으로 덮어씌워질 가능성이 있었습니다. 리뷰에서 해당 문제가 지적되었고, AVCapturePhotoSettings.uniqueID를 키 (key)로 한 딕셔너리 (dictionary) 관리 방식으로 수정했습니다.

나아가 Codex가 "딕셔너리 자체의 액세스 (access)가 동기화되어 있지 않다"고 지적하여, 최종적으로 NSLock으로 보호하는 형태로 고쳤습니다.

이만큼 리뷰 사이클을 돌렸고, 리뷰 담당 AI는 OK를 했습니다. 인간도 머지했습니다.

그런데 그 후 실기 (real device) 빌드에서 에러가 발생했습니다.

원인은 #if targetEnvironment(simulator) / #else 분기입니다. 시뮬레이터 (simulator) 빌드에서는 실기 측의 #else 블록이 컴파일되지 않습니다. 그 때문에 실기 측에만 존재하는 Swift 6의 strict concurrency 에러가 시뮬레이터 빌드에서는 보이지 않았던 것입니다.

PR 작성 전에는 실기와 시뮬레이터 양쪽 모두에서 확인했습니다.

하지만 그 후의 리뷰 대응 커밋 (commit)은 AI에게 맡겨두었기에, 확인은 시뮬레이터 빌드 중심으로 이루어졌습니다. 리뷰 담당 AI도 코드는 읽을 수 있지만, 실기 빌드까지는 하지 않습니다.

결과적으로 머지 후에 hotfix PR을 내게 되었습니다.

보통 이 정도 규모의 실험용 앱에서 hotfix 같은 것은 내지 않는다고 생각할 것입니다.

하지만 나왔습니다.

이것은 실패담이기도 하지만, AI 리뷰의 한계를 상당히 명확하게 보여주는 사건이기도 했습니다.

리뷰 담당 AI가 전원 OK를 했다.

인간도 머지했다.

그럼에도 확인되지 않은 조건의 문제는 남는다.

즉, OK는 "이 리뷰 조건에서는 문제를 발견하지 못했다"는 의미이지, "모든 환경에서 올바르다"는 의미가 아닙니다.

특히 #if / #else와 같이 빌드 대상에 따라 컴파일되는 코드가 달라지는 경우, 시뮬레이터에서 통과했다는 것이 실기에서 통과했다는 것을 의미하지 않습니다. 리뷰에서 OK가 모이더라도, 인간이 "이 변경 사항은 실기 빌드도 필요하다"라고 판단해야 합니다.

AI 리뷰를 엄격하게 돌리더라도, 마지막 확인 설계는 인간에게 남습니다.

인간은 어떻게 관여하는가

AI에게 구현하게 하고, AI에게 리뷰하게 하고, AI에게 리뷰 대응을 시킨다.

그렇게 들으면 인간은 아무것도 하지 않아도 될 것처럼 보일지도 모릅니다.

하지만 실제로는 반대였습니다.

인간의 역할은 코드를 쓰는 것에서 판단하는 것으로 옮겨갔습니다.

먼저, 리뷰 체제를 설계해야 합니다.

누구에게 리뷰를 시킬 것인가. 무엇을 보여줄 것인가. 무엇을 보여주지 않을 것인가. 다른 리뷰어 (reviewer)의 코멘트 (comment)를 읽게 할 것인가. OK 조건은 어떻게 할 것인가.

다음으로, 리뷰 결과를 읽어야 합니다.

여러 AI가 동일한 지적을 했다면 중요도가 높습니다. 지적이 갈렸다면 설계 의도나 실기 동작을 바탕으로 인간이 판단합니다.

나아가, 실기 확인은 인간이 수행해야 합니다.

카메라, 플래시, 권한, 단말기 방향, UI의 위화감. AI에게는 보이지 않는 것이 있기 때문입니다.

그리고 마지막으로, 머지 버튼을 누르는 것은 인간입니다.

AI가 PR을 작성하고, AI가 리뷰하고, AI가 OK를 했다 하더라도, "머지해도 좋다"라고 판단하는 책임은 인간에게 남습니다.

AI 리뷰는 인간의 책임을 없애는 것이 아닙니다.

인간이 판단하기 위한 재료를 늘려주는 것입니다.

요약

ZCam에서의 AI 리뷰 운용을 통해 알게 된 것은, AI 리뷰는 상당히 쓸만하지만 설계 없이 사용하면 위험하다는 것입니다.

AI에게 리뷰를 시키는 이점은 있습니다.

• 지치지 않고 차분 (diff)을 읽는다
• 인간이 무심코 지나치기 쉬운 파일도 본다
• data race나 스레드 세이프티 (thread safety)와 같은 문제를 잡아낸다
• 다각도에서 리뷰할 수 있다

한편으로는 우려되는 점도 있습니다.

• 개발 측의 문맥 (context)에 끌려간다
• 다른 리뷰어의 코멘트에 영향을 받는다
• 실기 상태 (actual device state)를 볼 수 없다
• 리뷰 대응 과정에서 또 다른 퇴보 (degradation)가 발생할 수도 있다

그래서 역할을 나누었습니다.

정보를 나누었습니다.

서명을 붙였습니다.

모두가 OK 할 때까지 리뷰 사이클을 지속했습니다.

AI 리뷰는 인간 리뷰의 단순한 대체가 아닙니다.

AI에게 보이는 것은 AI가 보게 합니다.

AI에게 보이지 않는 것은 인간이 봅니다.

여러 AI의 의견을 재료로 삼아, 인간이 판단합니다.

그 형태가 ZCam에서는 잘 작동했습니다.

이 일련의 상호작용은 밖에서 보면 조금 번거로워 보일지도 모릅니다. AI가 리뷰하고, AI가 반론하고, 다른 AI가 OK 하고, 인간이 그것을 읽고, 다시 확인합니다. 작은 앱에 대해 그렇게까지 할 필요가 있느냐고 생각하는 사람도 있을 것입니다.

하지만, 저는 무의미한 문답이 아니었다고 생각합니다.

그 문답 속에서 어떤 AI가 무엇을 보고 있는지가 명확해졌습니다. 어떤 문제는 AI가 잡아낼 수 있고, 어떤 문제는 인간이 실기에서 확인해야만 하는지도 알 수 있었습니다. 리뷰 지적에 대응하다가 다른 문제가 발생하는 것, 모두가 OK 했음에도 핫픽스 (hotfix)가 발생하는 것, 같은 모델이라도 역할이 다르면 의견이 갈리는 것도 상호작용을 거듭했기에 보였습니다.

AI와의 개발에서는 최단 거리로 정답만을 내놓는 것이 항상 정답은 아닙니다. 상호작용 그 자체가 다음 판단의 재료가 됩니다. ZCam에서는 그 과정까지도 기록으로 남기고 싶었습니다.

AI에게 리뷰를 맡긴다면, "AI가 리뷰해 주니까 안심"이 아니라, "AI 리뷰를 어떻게 설계할 것인가"까지 고민해야 합니다.

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