Discernment for code
Discernment for code · 5 min
AI가 몇 분 안에 작동하는 제품을 만들어낼 수 있게 되면, "작동한다"는 더 이상 기준이 되지 못합니다. AI로 구축된 제품이 일반적으로 실패하는 지점, 개발 단계에서는 드러나지 않지만 프로덕션에서 드러나는 기술적 사각지대, 그리고 AI가 갖지 못한 안목을 기르는 방법을 배우게 됩니다.
한국어 대본
- 00:00이제 AI로 무언가를 만들었습니다. 실행됩니다. 테스트도 통과합니다. 하지만 그게 대수입니까? 생각해 보세요,
- 00:12우리가 만들고 있는 프로젝트를. 그것이 환자의 예상 대기 시간이
- 00:17갑자기 10분에서 90분으로 뛰는 시나리오를 처리했습니까? 그것이 다양한 환자 요구를 고려하고 해결했습니까?
- 00:22그것이 기존 데이터의 역사적 편향을 반영했습니까? 작동하는 제품과 좋은
- 00:27제품은 항상 같은 것이 아닙니다. 그리고 AI가 몇 분 안에 작동하는 제품을 만들 수 있을 때,
- 00:33그 차이를 구분하는 능력이 그 자리에서 가장 가치 있는 능력이 됩니다.
- 00:40이 모듈은 그러한 판단을 위한 구조를 제공합니다. 다섯 가지 렌즈와 다섯 가지 질문을
- 00:46AI가 만드는 모든 것에 물어보세요. 첫 번째 렌즈는 기능적 무결성입니다. 실제로 작동합니까?
- 00:52버그, 오류, 보안 취약점. 대부분의 코드 리뷰가 여기서 멈춥니다. 필요하지만,
- 00:58충분하지는 않습니다. 우리 프로젝트 예시에서 AI는 대기 시간을 표시하는 견고한 로직을
- 01:04구축했습니다. 하지만 환자 우선순위를 고려했습니까? 상충하는 데이터 포인트와 어떤 것을 표시할지 결정하는 것은 어떻습니까?
- 01:09어떤 것을 표시할지? 빌드할 때 기능 테스트, 단위 테스트,
- 01:15통합 테스트, 회귀 테스트, 엣지 케이스, 엔드투엔드 테스트를 포함한 전체 범위를 고려하세요. 그리고 여기 중요한 습관이 있습니다.
- 01:21AI는 코드와 함께 테스트를 작성해야 하며, 코드 이후가 아니라야 합니다. 프롬프트를 입력할 때,
- 01:27같은 패스에서 테스트 케이스를 작성하도록 요청하고, 정기적인 체크포인트를 포함하세요.
- 01:32실행되지 않은 테스트 스위트는 안전망이 아니라, 단지 잘못된 안전감일 뿐입니다.
- 01:37두 번째 렌즈는 운영 준비도입니다. 실제로 잘 작동합니까?
- 01:41성능, 확장성, 신뢰성, 부하가 걸리면 어떻게 됩니까? 수백 명이
- 01:47동시에 새로고침하려고 하면 어떻게 됩니까? AI는 여기서 특정한 사각지대가 있습니다. 그렇다면 어떻게
- 01:53빌드 과정에서 이를 검증합니까? 몇 가지 구체적인 방법으로 AI에게 자체 출력을 스트레스 테스트하도록 요청하고,
- 01:59프로덕션 시나리오를 생성하게 하고, 코드가 이를 처리하는 방식을 확인하세요. 명시적으로 물어보세요,
- 02:05이 코드는 어떤 프로덕션 가정을 합니까? 그러면 놓친 것들이 드러날 것입니다. 첫 번째
- 02:09패스에서. 프로젝트에서 코드가 API 호출이 5초나 오래 걸릴 때를 고려했습니까?
- 02:15화면이 멈추거나, 오래된 데이터를 표시하거나, 우아하게 실패합니까?
- 02:20AI는 그런 것을 고려하지 않습니다.
- 02:22그것은 선택에 달려 있습니다.
- 02:23세 번째 렌즈는 문제 적합성입니다.
- 02:25그것이 올바른 것입니까?
- 02:26사용자의 실제 문제를 해결하는 것입니까, 아니면 사용자가 자신이 있다고 생각하는 문제를 해결하는 것입니까?
- 02:31그 둘은 지난 레슨에서 보았듯이 서로 다를 수 있습니다.
- 02:34환자는 대기 시간에 대해 물었고, 겉보기에는 AI가 예상 대기
- 02:38시간 표시를 만들 수 있습니다.
- 02:39하지만 환자가 정말로 알아야 했던 것은 소아과 의사가 있는지
- 02:43다음 20분 안에 있는지 여부였습니다. 그래야 자녀의 열이 위중한지 아닌지 평가할 수 있었습니다.
- 02:47AI는 명시된 문제를 해결했지만, 그것이 실제 문제인지 확인해야 합니다.
- 02:52네 번째 렌즈는 경험 품질입니다. 실제로 좋은 것입니까? 경험이 명확한 것입니까,
- 02:57직관적이고 접근 가능한 것입니까? AI는 취향이 없고 패턴만 있습니다. AI는 무난한
- 03:02아무도 사용하기를 즐기지 않는 인터페이스를 제공할 것입니다.
- 03:07문제입니다. 환자 안전 문제입니다. 빌더로서 이를 알아차리고
- 03:13그것을 구체적이고 해결 가능한 것으로 번역해야 합니다.
- 03:17레슨. 다섯 번째 렌즈는 책임 있는 영향입니다. 책임이 있는 것입니까? 편향? 프라이버시? 의도하지 않은
- 03:25결과? 누구에게 해를 끼칠 수 있습니까? 사용자에 대해 사실이 아닐 수 있는 가정은 무엇입니까?
- 03:31임상 대기 시간 도구를 다시 살펴보겠습니다. 대기 시간을 추정하는 알고리즘이 훈련된
- 03:37과거 데이터에 기반한 것입니까? 그 데이터가 기존 편향, 더 긴
- 03:42대기 시간이 특정 인구 집단에서 길어지는 데 기여하는 체계적 불평등을 반영한다면, 모델은 동일한 패턴을 재현할 수 있습니다. 그것은 경고하지 않을 것입니다.
- 03:48그저 숫자를 표시할 뿐입니다. 가드레일을 구축하세요. AI가 구축하면서 자신의 편향을 밝히도록 요청하고, 가장
- 03:55중요하게는 모든 가정에 의문을 제기하세요. 대부분의 공학 교육은 처음 두 가지
- 04:01렌즈에서 멈추지만, 빌더는 다섯 가지 모두 필요합니다. 그리고 그것들을 적용하기 시작하면 발견하게 될 것은 다음과 같습니다.
- 04:06가장 큰 문제는 거의 항상 렌즈 1에 있지 않습니다. AI는 실행되는 코드를 생성하는 데 능숙하지만,
- 04:12중요한 제품을 만들기 위해서는 빌더의 감독이 필요합니다.
- 04:16한 가지 더, 충분하지 않은 것을 발견했을 때,
- 04:19자신의 본능을 주목하세요. 직접 나서서 고치십니까,
- 04:22아니면 필요했던 것을 더 잘 설명하러 돌아가십니까?
- 04:25어느 쪽도 틀리지 않지만, 그 패턴은 AI와 함께 작업하는 방식에 대해 무언가를 알려줍니다,
- 04:29그리고 판별력을 기르고 있는지, 아니면 그냥 만들고만 있는지.
- 04:33좋습니다, 이제 이 렌즈들을 적용할 때입니다. 갑시다.
판별의 다섯 가지 렌즈
렌즈 1은 테스트하기 쉽습니다 — 실행해서 확인하면 됩니다. 렌즈 5에 이르면, AI가 대신 내려줄 수 없는 판단을 직접 내려야 합니다.
렌즈 1
기능적 무결성
작동하는가?
✓테스트 데이터뿐 아니라 실제 입력에 대해서도 올바른 출력을 생성함
흔한 AI 실패 사례
단위 테스트는 통과하지만 프롬프트가 다루지 않은 실제 데이터에서는 오류가 발생하는 코드
핵심 요약
- 실행되는 코드도 실패할 수 있습니다. AI의 기본 출력물은 기술적으로는 완전하지만 종종 핵심을 놓칩니다.
- AI에는 예측 가능한 사각지대가 있습니다. 동시성, 보안, 그리고 규모가 커져야만 드러나는 문제들이 그렇습니다.
- 안목은 빌더의 역량입니다. AI는 기능적인 것을 제공합니다. 그것을 쓸 만하게 만드는 것은 여러분의 몫입니다.
실습
Clinic 프로젝트 사용자 테스트
환자나 클리닉 관리자 역할을 맡은 파트너 앞에 여러분의 빌드를 내놓으세요 — 설명하지 말고, 돕지 마세요. 그들이 어디서 혼란스러워하는지, 무엇을 무시하는지, 그리고 여러분이 만들지 않았지만 그들이 원했던 것이 무엇인지 관찰하세요. 바꾸고 싶은 세 가지를 적고 각각이 어떤 렌즈에 해당하는지 적어보세요.
레슨 돌아보기
- 다섯 가지 렌즈 중 자연스럽게 적용하게 되는 것은 무엇이고, 의식적으로 확인해야 하는 것은 무엇인가요?
- AI가 충분히 좋지 않은 결과물을 만들어냈을 때, 여러분의 본능은 직접 고치는 것인가요, 아니면 더 잘 설명하는 것인가요?
다음 단계
여러분은 평소 건너뛰기 쉬운 렌즈들을 통해 Clinic Wait Time Checker를 스트레스 테스트했습니다. 다음으로는 같은 도구를 다른 렌즈로 살펴보겠습니다: 실제로 사용할 때 어떤 느낌인가요?