Diligence와 작업 공유하기
Diligence와 작업 공유하기 · 3 min
빌더 모델에서의 diligence는 완전한 소유권을 의미합니다: 당신은 제품이 존재해야 하는지부터 출시 후 사용자에게 제대로 서비스되고 있는지까지 책임을 집니다. 이 레슨에서는 출시가 의미하는 것, AI가 경고해주지 않는 기술적 현실, 무언가가 라이브가 되는 순간 테스트가 왜 당신의 안전망이 되는지, 그리고 자신의 작업을 폐기하는 과소평가된 기술을 다룹니다.
한국어 대본
- 00:00안녕하세요. 제 이름은 Martina이고 Anthropic에서 엔지니어로 일합니다.
- 00:09이 코스 전반에서 위임하고, 설명하고, 판별해 보았습니다.
- 00:12이제 작동하는 클리닉 앱이 있고, 출시할 때가 거의 되었습니다.
- 00:154D 프레임워크에서 성실은 AI로 만든 것에 책임을 지는 것을 의미합니다.
- 00:20본질적으로 AI 사용이 투명하고 윤리적이며 책임을 다하는지 확인하는 것입니다.
- 00:25여기에는 AI 사용에 대해 투명하게 밝히고 이를 공개하며,
- 00:28AI가 만든 출력에 책임을 지고, 출시 전에 작업을 검증하며,
- 00:32만든 것이 다른 사람에게 미칠 영향을 고려하고, 조직이나 업계에서 AI 사용을 규율하는 정책, 개인정보 보호,
- 00:37전문 표준을 준수하는 일이 포함됩니다.
- 00:41무엇을 중요하게 여겨야 하는지 말하는 대신, 엔지니어로서 제
- 00:45일상에서 성실이 어떤 모습인지 보여 드리겠습니다.
- 00:50AI를 사용하면 직접 작성하지 않은 코드의 소유자가 될 수 있습니다.
- 00:53자신의 코드를 따라잡는 방법은 코드를 이해하고, 여러 상황에서 시험하고, 테스트하고, 자신이 놓친 부분을 포착하는 시스템을
- 00:59마련하는 것입니다. 제 경우에는 세 가지 습관으로 정리됩니다. 직접 코드를 작성하면
- 01:04작성해 나가는 과정에서 미처 생각하지 못한 것들이 있다는 사실이 분명해집니다. 어떤 엣지 케이스,
- 01:09내려야 하는 줄 몰랐던 어떤 결정이 있을 수 있습니다. AI를 사용하면 이런 결정이 때로
- 01:14한 번도 드러나지 않은 채 내려지기도 합니다. 그래서 저는 의도적으로 그 단계를 재현해
- 01:18그런 질문을 드러내고 실제로 의견을 낼 수 있게 합니다.
- 01:22엣지 케이스가 떠오르면 모델에게 이렇게 말합니다.
- 01:25"사용자가 다른 사용자의 파일을 볼 수 없는지 다시 확인해 줄 수 있습니까?"
- 01:29Claude가 상당한 규모의 무언가를 만들고 나면 직접 이렇게 묻습니다.
- 01:32"어떤 가정과 절충을 했습니까?"
- 01:34"제가 알아야 할 보안 위험은 무엇입니까?"
- 01:36그러면 중요한 결정에 자신이 참여할 수 있습니다.
- 01:39Claude가 풀 리퀘스트 대부분을 작성했다면 설명에 그렇게 적습니다.
- 01:43면책 문구가 아니라 정보로 적습니다.
- 01:45AI가 인간과는 다른 형태의 실수를 하기 때문에 이는 중요합니다.
- 01:49폐기된 API를 자신 있게 사용하거나, 로컬하게는 깔끔하지만 코드베이스와 일관되지 않은 코드를 작성하거나,
- 01:55명시하지도 않은 사례에 대한 동작을 지어내는 식입니다. 이를 아는 리뷰어라면 자신의
- 02:00리뷰를 더 알맞게 조정할 수 있습니다. AI가 만드는 상황에서는 자신의 역량을 벗어났다고 느끼기 쉽습니다. 이전에는 사실상 불가능했던,
- 02:05이해하지 못하는 작동하는 코드를 얻게 될 수도 있습니다. 하지만 이해할 수 없는 것이
- 02:09아니라, 이제는 별도의 단계가 된 것뿐이며 AI가 그 과정도 도울 수 있습니다. Claude는
- 02:14기꺼이 곁에 앉아 차분히 설명해 줍니다. 시간이 조금 걸리지만, 그 과정이 다시
- 02:20루프 안으로 돌아오게 합니다. 여기서 중요한 점은 AI 이전부터 존재한 엔지니어링 모범 사례가 여전히 적용된다는 것입니다.
- 02:26AI를 사용한 뒤에도, 어쩌면 더 중요하게 적용됩니다. 이제 더 빠르게 출시하면서 자신이 출시한 것 중 더 적은
- 02:30부분만 이해하고 있기 때문입니다. 무언가를 망가뜨리지 않았는지 확인하는 가장 쉬운 방법은 여전히 테스트입니다.
- 02:35이렇게 빠르게 움직일 때도 그렇습니다. 탄탄한 테스트 모음은 중요한 동작을 확실히 고정해 주므로 계속
- 02:41안심하고 반복 개선할 수 있습니다. 옵저버빌리티는 사라지지 않았습니다. 실제
- 02:46사용자가 사용하기 시작했을 때만 드러나는 것도 있으므로 로그, 오류 추적, 대시보드가 필요합니다. 문제는
- 02:52사용자 이메일이 아니라 자신의 데이터에서 발견해야 합니다. 무언가 빠져나갔을 때를 대비해 기능 플래그도 여전히 유용합니다. 이런
- 02:57안전망을 마련해 두어야 안전하게 빠르게 움직일 수 있습니다. 검증, 투명성, 이해,
- 03:03테스트는 한쪽 끝에, 옵저버빌리티는 다른 쪽 끝에 있습니다. 이 중 어느 것도 엔지니어링에 새로운 것은 아닙니다.
- 03:07AI는 이를 실현하도록 도와주는 새로운 도구일 뿐입니다.
핵심 요점
- 당신은 결과물이 아니라 결과를 책임집니다. "AI가 작성했다"는 아무것도 설명하지 않으며 아무것도 정당화하지 않습니다.
- 출시에는 고유한 기술 용어(마이그레이션, 버전 관리, 속도 제한, 기능 플래그)가 있으며, 당신이 묻지 않으면 AI는 이를 드러내지 않습니다.
- 테스트는 출시 후 반복 작업을 안전하게 만듭니다. 테스트 우선 습관이 있기 때문에 자신 있게 계속 변경할 수 있습니다.
- 자유롭게 프로토타입을 만들고, 선택적으로 출시하세요. 저렴한 코드는 정직한 평가와 결합될 때만 가치를 창출합니다.
- 접근성은 설계 결정입니다. 무언가를 출시했다고 말하기 전에 당신의 가정이 누구를 배제하는지 확인하세요.
연습 문제
Clinic 앱 출시하기
출시는 diligence가 현실이 되는 지점입니다 — 배포하기 전에 다음 각 항목에 솔직하게 답해보세요.
이 항목들을 모두 검토한 후, 앱을 배포하거나 프로토타입으로 호스팅하고, 실제 사용자 세 명과 공유한 다음, 배운 내용을 바탕으로 한 번의 반복 작업을 수행하고, 변경 사항을 검증하는 테스트를 작성하세요.
- 이해 — 코드가 무엇을 해야 하는지가 아니라, 실제로 무엇을 하는지 설명할 수 있나요?
- 테스트 — 수락 테스트가 여전히 통과하나요? 엣지 케이스를 테스트했나요 — 휴진 중인 클리닉, 누락된 데이터, 대기 시간 0?
- 접근성 — 당신의 빌드가 잘 서비스하지 못하는 대상은 누구인가요?
- 책임 — 이 결과물이 잘못 해석되거나 오용될 수 있나요? AI의 역할에 대해 투명했나요?
- 피드백 루프 — 출시 후 제대로 작동하는지 어떻게 알 수 있나요?
레슨 회고
- 이 과정을 시작할 때부터 AI 통합에 대한 당신의 생각이 어떻게 바뀌었나요?
- 배운 내용을 바탕으로 AI와의 작업에서 다르게 할 한 가지는 무엇인가요?
다음 단계
당신은 Clinic Wait Time Checker를 만들고, 평가하고, 출시했습니다. 마지막 레슨에서는 전체 4D Framework를 종합하고, 이미 진행 중인 실제 작업을 가지고 마무리하게 됩니다.