2025년 6월 17일·7분
AI가 개발자 업무에서 대체하는 것(그리고 대체하지 않는 것)
AI가 개발자의 어떤 업무를 대체하고, 어디서 보조하며, 어떤 책임이 여전히 인간에게 남는지에 대한 실무 중심 요약.
AI가 개발자의 어떤 업무를 대체하고, 어디서 보조하며, 어떤 책임이 여전히 인간에게 남는지에 대한 실무 중심 요약.
“AI가 개발자에게 무엇을 할 것인가”라는 대화는 빠르게 혼란스러워집니다. 우리는 종종 도구와 책임을 뒤섞기 때문입니다. 도구는 코드를 생성하거나 티켓을 요약하거나 테스트를 제안할 수 있습니다. 책임은 제안이 틀렸을 때 팀이 여전히 부담해야 하는 것입니다.
이 글은 대체, 보조, 영향 없음이라는 단순한 프레임워크를 사용해, 마감일, 레거시 코드, 프로덕션 사고, 신뢰할 수 있는 결과를 기대하는 이해관계자가 있는 실제 팀의 일상 업무를 설명합니다.
대체는 AI가 명확한 가드레일 아래에서 대다수 경우 작업을 끝까지 완료할 수 있고, 사람의 역할은 감독과 샘플 검사로 이동한다는 뜻입니다.
예시는 경계가 있는 작업인 경우가 많습니다: 보일러플레이트 생성, 언어 간 코드 변환, 반복적인 테스트 케이스 초안 작성, 초안 문서 생성 등.
대체가 인간의 책임이 사라진다는 뜻은 아닙니다. 출력물이 프로덕션을 깨뜨리거나 데이터를 유출하거나 기준을 위반하면 여전히 팀의 책임입니다.
보조는 AI가 개발자를 더 빠르거나 더 철저하게 만들지만, 인간의 판단 없이는 신뢰할 수 있게 작업을 끝내지 못한다는 뜻입니다.
전문 엔지니어링에서 흔한 경우입니다: 유용한 초안, 대체 접근 방식, 빠른 설명, 잠재적 버그의 쇼트리스트를 얻을 수 있지만, 무엇이 정확하고 안전하며 제품에 적절한지는 여전히 개발자가 결정합니다.
영향 없음은 핵심 책임이 인간 주도 상태로 남아 있음을 의미합니다. 맥락, 트레이드오프, 책임 소재가 프롬프트로 잘 압축되지 않기 때문입니다.
예: 요구사항 협상, 시스템 수준 제약 선택, 사고 처리, 품질 기준 설정, 단일한 "정답"이 없는 결정을 내리는 일 등.
도구는 빠르게 변합니다. 책임은 천천히 변합니다.
그래서 "AI가 이 코드를 쓸 수 있나?"라고 묻기보다는 "결과의 소유권은 누구에게 있나?"라고 물어보세요. 이 관점은 정확성, 신뢰성, 책임성을 현실적으로 유지하게 해 주며—인상적인 시연보다 더 중요한 것들입니다.
사람들이 AI가 개발에서 무엇을 "대체"하는지 물을 때, 그들은 종종 작업을 의미합니다: 함수를 작성하라, 테스트를 생성하라, 문서를 초안하라. 그러나 팀은 작업을 배포하는 것이 아니라 결과를 배포합니다. 그래서 개발자 책임이 중요합니다.
개발자의 업무는 보통 코드 작성 시간보다 더 넓은 영역에 걸칩니다:
이 책임들은 전체 라이프사이클에 걸쳐 있습니다—"무엇을 만들어야 하나?"에서 "안전한가?"와 "3시에 고장 나면 어떻게 할 것인가?"까지.
각 책임은 사실 작은 결정들의 묶음입니다: 어떤 엣지케이스가 중요한가, 어떤 지표가 건강을 나타내는가, 언제 범위를 줄일 것인가, 수정이 안전하게 배포 가능한가, 이해관계자에게 트레이드오프를 어떻게 설명할 것인가. AI는 이 작업의 실행(코드 초안, 테스트 제안, 로그 요약)을 도울 수 있지만, 책임은 결과를 소유하는 것에 관한 문제입니다.
문제는 종종 핸드오프 경계에서 발생합니다:
소유권이 불분명하면 일이 구멍으로 빠집니다.
책임에 대해 이야기하는 유용한 방법은 결정권입니다:
AI는 실행을 빠르게 할 수 있습니다. 그러나 결정권—그리고 결과에 대한 책임—은 여전히 사람 이름 옆에 있어야 합니다.
AI 코딩 어시스턴트는 작업이 예측 가능하고 저위험이며 검증하기 쉬울 때 진짜로 유용합니다. 빠른 주니어 동료처럼 생각하세요: 첫 초안을 잘 만들지만 명확한 지시와 신중한 검토가 필요합니다.
실무에서는 일부 팀이 "vibe-coding" 플랫폼(예: Koder.ai)을 사용해 이런 대체 가능한 덩어리를 가속합니다: 스캐폴드 생성, CRUD 흐름 연결, 채팅에서 UI/백엔드 코드의 초기 초안 생성 등. 핵심은 같음: 가드레일, 리뷰, 명확한 소유권.
많은 개발 시간은 프로젝트 스캐폴딩과 레이어 간 연결에 쓰입니다. AI는 종종 다음을 생성할 수 있습니다:
가드레일은 일관성입니다: 기존 관행과 일치하는지 확인하고 새로운 패턴이나 불필요한 의존성을 만들어내지 않도록 하세요.
변경이 대부분 기계적인 경우—심볼 이름 변경, 포맷 변경, 단순한 API 사용 업데이트—AI는 잡무를 가속할 수 있습니다.
그럼에도 불구하고 대량 편집처럼 다루세요: 전체 테스트 스위트를 실행하고, diff를 스캔해 의도치 않은 동작 변화를 찾고, 요청한 리팩터를 넘어서서 "개선"하지 않도록 주의하세요.
AI는 README, 인라인 주석, 변경 로그 항목을 코드와 커밋 노트를 기반으로 초안 작성할 수 있습니다. 이는 가독성을 빠르게 높이지만, 자신감 있는 잘못된 주장(confident-sounding inaccuracies)을 만들 수도 있습니다.
권장 관행: 구조와 문구는 AI에 맡기고, 특히 설치 단계, 구성 기본값, 엣지케이스 같은 모든 주장을 검증하세요.
명세가 명확한 순수 함수에 대해서는 AI가 생성한 단위 테스트가 초기 커버리지를 제공하고 엣지케이스를 상기시켜줄 수 있습니다. 가드레일은 소유입니다: 어떤 것이 중요한지 선택하고, 실제 요구사항을 반영하는 어설션을 추가하며, 테스트가 올바른 이유로 실패하는지 확인하세요.
긴 Slack 스레드, 티켓, 인시던트 로그가 있으면 AI가 이를 간결한 노트와 액션 아이템으로 바꿀 수 있습니다. 전체 컨텍스트를 제공하고 공유하기 전에 핵심 사실, 타임스탬프, 결정들을 검증하세요.
AI 코딩 어시스턴트는 이미 원하는 바를 알고 있고 이동 속도를 높이는 상황에서 가장 잘 작동합니다. 타이핑 작업 시간을 줄이고 유용한 컨텍스트를 표면화해 주지만, 소유권, 검증, 판단의 필요를 없애지 않습니다.
명확한 명세(입력, 출력, 엣지케이스, 제약)가 주어지면 AI는 합리적인 시작 구현을 초안할 수 있습니다: 보일러플레이트, 데이터 매핑, API 핸들러, 마이그레이션, 단순한 리팩터 등. 이득은 모멘텀입니다: 빠르게 실행 가능한 무언가를 얻습니다.
단점은 첫 패스 코드가 미묘한 요구사항(오류 의미론, 성능 제약, 하위 호환성)을 놓치기 쉽다는 점입니다. 인턴의 초안처럼 다루세요: 유용하지만 권위적이지는 않습니다.
캐싱 대 배칭, 낙관적 대 비관적 잠금 등 접근 방식 사이를 선택할 때 AI는 대안을 제시하고 장단점을 나열할 수 있습니다. 브레인스토밍에는 유용하지만, 이 트레이드오프는 실제 시스템의 현실(트래픽 형태, 데이터 일관성 요구, 운영 제약, 팀 관행)에 맞춰 검증돼야 합니다.
AI는 익숙하지 않은 코드를 설명하고 패턴을 지적하며 “이게 무엇을 하는가?”를 평이한 언어로 번역하는 데 강합니다. 검색 도구와 결합하면 "X가 어디서 사용되는가?"와 같은 질문에 답하고 영향을 받을 가능성이 있는 호출 지점, 설정, 테스트 목록을 생성하는 데 도움이 됩니다.
더 명확한 오류 메시지, 작은 예제, 붙여넣기 가능한 스니펫 같은 실용적인 삶의 질 향상을 기대하세요. 이들은 마찰을 줄이지만, 사용자나 프로덕션 시스템에 영향을 미치는 변경에 대해서는 신중한 리뷰, 로컬 실행, 타겟 테스트를 대체하지 못합니다.
AI는 요구사항 작성과 다듬기를 도울 수 있지만, 무엇을 만들어야 하고 왜 중요한지 신뢰할 만하게 결정할 수는 없습니다. 제품 이해는 비즈니스 목표, 사용자 불편, 조직적 제약, 엣지케이스, 잘못했을 때의 비용에 뿌리를 둡니다. 이러한 입력은 대화, 역사, 책임 속에 있고—모델은 요약은 할 수 있어도 진정으로 소유하진 못합니다.
초기 요청은 종종 "온보딩을 더 부드럽게 만들자"거나 "지원 티켓을 줄여라"처럼 들립니다. 개발자의 일은 이를 명확한 요구사항과 수용 기준으로 번역하는 것입니다.
그 번역은 주로 사람의 일입니다. 왜냐하면 탐색적 질문과 판단이 필요하기 때문입니다:
AI는 가능한 지표나 수용 기준을 제안할 수 있지만, 어떤 제약이 실제인지 모르면 이를 알려주지 않고, 요청이 자기모순일 때 반박하지도 않습니다.
요구사항 작업은 불편한 트레이드오프가 드러나는 곳입니다: 시간 대 품질, 속도 대 유지보수성, 새 기능 대 안정성. 팀은 위험을 명시하고 옵션을 제안하며 이해관계자들을 결과에 대해 정렬시켜줄 사람을 필요로 합니다.
좋은 스펙은 단순한 텍스트가 아닙니다; 그것은 결정 기록입니다. 테스트 가능하고 구현 가능해야 하며, 입력/출력/엣지케이스/실패 모드가 명확해야 합니다. AI는 문서 구조화에 도움을 줄 수 있지만, "이건 모호하니 결정이 필요하다"라고 말하는 책임은 인간에게 남습니다.
시스템 설계는 "무엇을 만들까?"를 "무엇에 기반해 만들고, 고장 났을 때 어떻게 동작할까?"로 바꾸는 단계입니다. AI는 옵션을 탐색하는 데 도움을 줄 수 있지만 그 결과를 소유할 수는 없습니다.
모놀리식, 모듈형 모놀리식, 마이크로서비스, 서버리스, 관리형 플랫폼 중 어느 것을 택할지는 정답이 한 가지인 시험 문제가 아닙니다. 맞춤 문제입니다: 예상 스케일, 예산 한도, 출시 시간, 팀의 기술 수준이 결정 요인입니다.
어시스턴트는 패턴을 요약하고 참조 아키텍처를 제안할 수 있지만, 팀이 주간 온콜로 교체되는지, 채용이 느린지, 데이터베이스 공급자 계약이 다음 분기에 갱신되는지 같은 세부를 알지는 못합니다. 이런 세부가 아키텍처의 성공을 자주 좌우합니다.
좋은 아키텍처는 대부분 트레이드오프입니다: 단순성 대 유연성, 성능 대 비용, 오늘의 속도 대 나중의 유지보수성. AI는 장단점 리스트를 빠르게 만들어 문서화에 유용합니다.
하지만 트레이드오프로 인해 손해가 날 때 우선순위를 정하는 일은 비즈니스적 선택입니다.
서비스 경계 정의, 누가 어떤 데이터를 소유하는지, 부분적 장애 시 어떻게 동작할지는 깊은 제품 및 운영 맥락을 필요로 합니다. AI는 "결제 공급자가 다운되면?" 같은 실패 모드를 브레인스토밍하는 데 도움을 줄 수 있지만, 기대 동작, 고객 메시지, 롤백 계획을 결정하는 건 인간입니다.
API 설계는 계약을 설계하는 것입니다. AI는 예시 생성과 불일치 점 탐지에 도움을 주지만, 버전 관리, 하위 호환성, 장기 지원 범위를 결정하는 것은 여러분입니다.
아마 가장 중요한 아키텍처 결정은 "아니오"라고 말하거나 기능을 삭제하는 것입니다. AI는 기회 비용이나 정치적 리스크를 측정할 수 없습니다. 팀이 해야 합니다.
디버깅은 AI가 인상적으로 보이기도 하고 가장 시간을 낭비하게 만들기도 하는 영역입니다. 어시스턴트는 로그를 스캔하고 의심스러운 코드 경로를 지적하거나 "그래 보이는" 수정을 제안할 수 있습니다. 그러나 근본 원인 분석은 설명을 생성하는 것을 넘어서 이를 입증하는 것입니다.
AI 출력은 결론이 아니라 가설로 취급하세요. 많은 버그는 여러 개의 그럴듯한 원인이 있고, AI는 붙여넣은 코드 조각과 맞아떨어지는 깔끔한 이야기를 선택하는 경향이 있습니다.
실용적 워크플로우:
신뢰할 수 있는 재현은 미스터리를 테스트로 바꾸기 때문에 디버깅의 슈퍼파워입니다. AI는 최소 재현 사례 작성, 진단 스크립트 초안, 추가 로깅 제안 등을 도울 수 있지만, 어떤 신호가 중요한지(요청 ID, 타이밍, 환경 차이, 기능 플래그, 데이터 형태, 동시성)는 사람이 결정합니다.
사용자가 "앱이 멈췄다"고 보고하면, 이를 어떤 엔드포인트가 지연했는지, 어떤 타임아웃이 발생했는지, 어떤 오류 예산 신호가 변했는지로 번역해야 합니다. 이는 제품 사용 방식과 "정상"의 맥락을 필요로 합니다.
제안이 검증할 수 없다면 그것을 틀렸다고 가정하세요. 테스트 가능한 예측(예: "이 문제는 대용량 페이로드에서만 발생할 것이다" 또는 "캐시 워밍 후에만 발생한다")을 하는 설명을 선호하세요.
원인을 찾은 후에도 어려운 결정이 남습니다. AI는 트레이드오프를 개요로 제시할 수 있지만 인간이 대응을 선택합니다:
근본 원인 분석은 궁극적으로 책임입니다: 설명, 수정, 재발 방지에 대한 소유권을 지는 것.
코드 리뷰는 스타일 체크리스트 그 이상입니다. 팀이 무엇을 유지보수하고 지원하며 책임질 것인지를 결정하는 순간입니다. AI는 더 많이 볼 수 있게 도와줄 수 있지만, 무엇이 중요한지, 제품 의도에 맞는지, 팀이 수용하는 트레이드오프인지 결정할 수는 없습니다.
AI 코딩 어시스턴트는 지치지 않는 두 번째 눈처럼 행동할 수 있습니다. 빠르게 할 수 있는 것들:
이렇게 사용하면 PR을 연 시점과 위험을 발견한 시점 사이의 시간을 단축할 수 있습니다.
정확성 검토는 단순히 코드가 컴파일되는지 여부만이 아닙니다. 사람은 변경을 실제 사용자 행동, 프로덕션 제약, 장기 유지보수와 연결합니다.
리뷰어가 결정해야 할 것들:
AI를 최종 승인자가 아닌 두 번째 리뷰어로 취급하세요. 특정 점검(보안, 엣지케이스, 하위 호환성)을 요청한 다음, 범위, 우선순위, 팀 기준 및 제품 의도에 부합하는지에 대해 인간이 판단하세요.
AI 코딩 어시스턴트는 테스트를 빠르게 생성할 수 있지만, 테스트 품질의 소유권은 도구가 아닌 사람에게 있습니다. 테스트 스위트는 무엇이 깨질 수 있고 무엇이 절대 깨져선 안 되는지, 어떤 엣지케이스를 증명할지에 대한 베팅입니다. 그 베팅은 제품과 엔지니어링의 결정—여전히 사람의 몫입니다.
어시스턴트는 단위 테스트 스캐폴딩, 의존성 모킹, 구현에서 보이는 "해피 패스" 커버리지를 잘 생성합니다. 그러나 어떤 커버리지가 중요한지는 신뢰할 수 없습니다.
사람이 정의해야 할 것들:
대부분의 팀은 "더 많은 테스트"가 아닌 층화된 전략이 필요합니다. AI는 이러한 테스트를 작성하는 데 도움이 되지만 선택과 경계 설정은 인간 주도입니다:
AI 생성 테스트는 종종 코드에 너무 밀접하게 매칭되어 취약한 어설션이나 과도하게 모킹된 설정을 만들어 실제 동작이 실패할 때도 통과할 수 있습니다. 개발자는 다음으로 방지합니다:
좋은 전략은 배포 방식에 맞춥니다. 더 빠른 릴리스는 더 강한 자동화 검사와 명확한 롤백 경로가 필요하고, 느린 릴리스는 병합 전 검증을 더 많이 허용할 수 있습니다. 품질의 소유자는 도구가 아니라 팀입니다.
품질은 커버리지 백분율이 아닙니다. 측정할 것은 테스트가 결과를 개선하는지입니다: 프로덕션 인시던트 감소, 복구 속도 향상, 안전한 변경(작은 롤백, 빠른 자신감 있는 배포). AI는 작업을 가속하지만 책임은 개발자에게 남습니다.
보안 작업은 코드 생성보다 현실적 제약 하에서 트레이드오프를 하는 일입니다. AI는 체크리스트와 일반적 실수를 알려줄 수 있지만, 위험 결정의 책임은 팀에 있습니다.
위협 모델링은 일반적 연습이 아니라 무엇이 중요한지가 비즈니스 우선순위, 사용자, 실패 모드에 따라 달라집니다. 어시스턴트는 일반적 위협(인젝션, 인증 붕괴, 안전하지 않은 기본값)을 제안할 수 있지만, 여러분 제품에 진짜로 비용이 큰 것(계정 탈취 vs 데이터 유출 vs 서비스 중단)과 어떤 자산이 법적 민감도가 높은지는 알지 못합니다.
AI는 알려진 안티패턴을 인식하는 데 능하지만, 많은 사고는 권한 엣지케이스, 임시 관리자 엔드포인트, 승인 우회를 초래하는 워크플로우 같은 앱 특유의 세부에서 옵니다. 이러한 위험은 시스템의 의도를 읽어야 파악됩니다.
도구는 키를 하드코딩하지 말라고 상기시킬 수 있지만 전체 정책을 소유할 수는 없습니다:
AI는 오래된 라이브러리를 지적할 수 있지만 팀은 버전 고정, 출처 검증, 전이 의존성 검토, 위험을 수용할지 완화할지 결정하는 관행을 유지해야 합니다.
준수는 단순히 "암호화 추가"가 아닙니다. 통제, 문서, 책임성: 접근 로그, 승인 흔적, 인시던트 절차, 그리고 이를 따랐다는 증거가 필요합니다. AI는 템플릿 초안을 작성할 수 있지만, 감사자(및 고객)가 의존하는 증거를 검증하고 서명하는 것은 사람입니다.
AI는 운영 작업을 빠르게 만들 수 있지만 소유권을 대체하지는 않습니다. 신뢰성은 결정의 연쇄이며, 잘못된 결정의 비용은 보통 느린 결정의 비용보다 큽니다.
AI는 운영 산출물(런북, 체크리스트, "X면 Y 시도" 플레이북) 초안 작성과 유지보수를 도울 수 있습니다. 또한 로그 요약, 유사 알림 군집화, 첫 가설 제안을 통해 다음을 빠르게 반복하게 해줍니다:
이것들은 훌륭한 가속기지만 실제 작업 자체는 아닙니다.
인시던트는 거의 스크립트를 따르지 않습니다. 온콜 엔지니어는 불분명한 신호, 부분 장애, 시계와 싸우면서 지저분한 트레이드오프를 다룹니다. AI는 가능 원인을 제안할 수 있지만, 다른 팀을 호출할지, 기능을 비활성화할지, 데이터 무결성을 지키기 위해 단기 고객 영향을 수용할지 등의 결정을 신뢰성 있게 내릴 수는 없습니다.
배포 안전성도 인간 책임입니다. 도구가 롤백, 기능 플래그, 단계적 릴리스를 추천할 수 있지만, 비즈니스 맥락과 blast radius를 고려해 가장 안전한 경로를 선택하는 건 팀입니다.
AI는 채팅, 티켓, 모니터링에서 타임라인을 초안하고 주요 이벤트를 뽑아낼 수 있습니다. 인간은 여전히 중요한 부분을 수행합니다: "잘한 것"의 정의, 수정 우선순위 결정, 동일한 증상 재발을 막기 위한 근본적 변경 수행(단순 증상 대응이 아님).
AI를 운영 문서화와 패턴 발견에 대한 공동 조종사로 사용하면 속도를 얻고도 책임을 포기하지 않을 수 있습니다.
AI는 "CQRS가 뭐야?", "왜 이것 때문에 데드락이 발생하지?", "이 PR을 요약해줘" 같은 개념을 즉시 설명할 수 있습니다. 이는 팀의 속도를 올려줍니다. 그러나 직장의 커뮤니케이션은 단지 정보 전달이 아니라 신뢰를 쌓고 공유된 습관을 만들며 사람들이 의지할 수 있는 약속을 하는 일입니다.
신규 개발자는 단순한 답변뿐 아니라 맥락과 관계를 필요로 합니다. AI는 모듈 요약, 학습 경로 제안, 용어 번역을 도울 수 있지만, 이 코드베이스에서 무엇이 중요한지, 팀이 선호하는 트레이드오프, 문제가 느껴질 때 누구에게 물어볼지를 가르치는 건 인간입니다.
대부분의 프로젝트 마찰은 제품, 디자인, QA, 보안, 지원 같은 역할 간에 나타납니다. AI는 회의록 초안, 수용 기준 제안, 피드백의 어투 완화 등을 도울 수 있지만, 우선순위 협상, 모호함 해결, 이해관계자가 실제로 동의하지 않은 상태에서 "동의한다"고 표현하는 것을 알아차리는 것은 사람의 몫입니다.
책임이 모호하면 팀은 실패합니다. AI는 체크리스트를 생성할 수 있지만, 책임을 집행하지는 못합니다. 인간은 무엇이 "완료"인지(테스트? 문서? 롤아웃 계획? 모니터링?)와 병합 이후 누가 무엇을 소유하는지를 정의해야 합니다—특히 AI 생성 코드가 복잡성을 숨길 때 중요합니다.
이것은 도구가 실행하는 작업(실행을 도와주는 행동)과 팀이 최종적으로 책임지는 책임(결과에 대한 소유권)을 구분합니다.
팀은 단순히 "작업"을 전달하는 것이 아니라 결과물을 배포합니다.
AI가 코드나 테스트 초안을 작성하더라도 팀은 여전히 다음을 책임집니다:
“대체”는 경계가 명확하고 검증하기 쉬운 저위험 작업을 의미합니다. 오류가 쉽게 발견되고 복구 가능해야 합니다.
적합한 예시:
오류가 분명하고 비용이 낮아야 합니다. 실무 가드레일 예시:
실무 엔지니어링은 모델이 추론하지 못하는 숨은 제약이 많은 경우가 많기 때문입니다:
AI 출력은 초안으로 보고, 시스템에 맞게 사람이 조정해야 합니다.
AI를 가설과 증거 계획을 만드는 데 사용하세요. 결론으로 받아들이지 마십시오.
실용적인 루프:
검증할 수 없는 제안은 틀렸다고 가정하세요.
AI는 더 많은 문제를 찾아내는 ‘두 번째 눈’ 역할을 할 수 있지만, 사람이 무엇을 배포할지 결정해야 합니다.
유용한 AI 리뷰 프롬프트:
그 다음에는 의도, 유지보수성, 배포 위험을 사람 판단으로 결정하세요(릴리스 차단 항목과 후속 작업 구분 등).
AI는 많은 테스트를 초안할 수 있지만, 어떤 커버리지가 실제로 중요한지는 결정하지 못합니다.
사람이 책임져야 할 것들:
AI는 스캐폴딩과 엣지케이스 브레인스토밍에 사용하고, 품질 소유권은 사람에게 두세요.
신뢰성은 불확실성 속에서의 일련의 결정입니다. AI는 문서와 패턴 파악을 도와주지만, 결과 책임은 팀에 남습니다.
AI가 일상적으로 도울 수 있는 분야:
그러나 인시던트 중에 다른 팀을 호출할지, 기능을 비활성화할지, 단기 고객 영향을 수용할지 등은 인간이 결정해야 합니다.
팀 내에서의 소통은 정보 전달을 넘어 신뢰를 쌓고 약속을 만드는 일입니다. AI는 개념 설명과 요약을 도와주지만, 맥락을 가르치고 기대를 형성하는 일은 사람 몫입니다.
예시:
책임 있는 AI 사용 체크리스트: