2025년 8월 10일·7분
프롬프트 작성이 웹, 백엔드 및 모바일의 핵심 역량이 되는 이유
프롬프트 작성은 단순한 트릭에서 공학적 기술로 진화하고 있습니다. 웹, 백엔드, 모바일 앱을 위한 실용적 패턴, 도구, 테스트 및 팀 워크플로를 배우세요.
프롬프트 작성은 단순한 트릭에서 공학적 기술로 진화하고 있습니다. 웹, 백엔드, 모바일 앱을 위한 실용적 패턴, 도구, 테스트 및 팀 워크플로를 배우세요.
엔지니어링에서의 프롬프트는 단순한 “AI와 대화”가 아닙니다. 프롬프트는 어시스턴트를 특정하고 검증 가능한 결과로 이끄는 검토 가능한 입력을 제공하는 행위입니다—티켓, 스펙, 테스트 플랜을 쓰는 것과 유사합니다.
좋은 프롬프트는 보통 다음을 간결하게 담고 있습니다:
실제 프로젝트에서는 단순히 “로그인 페이지”를 요청하는 것이 아닙니다. 대신 “우리 디자인 토큰에 맞고, 이메일 포맷을 검증하며, 인라인 오류를 표시하고, 검증과 제출 상태에 대한 유닛 테스트가 있는 로그인 폼”처럼 구체화합니다. 프롬프트는 누군가가 검토하고 수정하고 재사용할 수 있는 구체적 산출물이 되며—종종 코드와 함께 리포지토리에 커밋됩니다.
이 글은 반복 가능한 관행에 초점을 맞춥니다: 프롬프트 패턴, 워크플로, 프롬프트 테스트, 팀 리뷰 습관 등.
과대 광고나 “마법 같은 결과”는 피합니다. AI 지원은 유용하지만, 엔지니어가 기대를 명시하고 사람이 생성한 코드처럼 출력물을 검증할 때만 가치가 있습니다.
\n프롬프트 작성은 ‘있으면 좋은 기술’에서 아이디어를 검토 가능한 결과로 빠르게 바꾸는 일상적 엔지니어링 역량으로 이동하고 있습니다.
AI 지원 도구는 UI 변형을 초안하거나, API 형태를 제안하거나, 테스트 케이스를 생성하거나, 로그를 요약하는 데 몇 초면 충분합니다. 속도는 실재하지만, 프롬프트가 충분히 구체적이어야 실제로 평가 가능한 출력을 얻을 수 있습니다. 모호한 의도를 선명한 지시로 바꿀 줄 아는 엔지니어는 시간당 더 많은 사용 가능한 반복을 얻고, 이는 스프린트 전반에 누적됩니다.
아키텍처 노트, 수용 기준, 마이그레이션 계획, 릴리스 체크리스트, 사고 보고서 같은 작업이 자연어로 이동하고 있습니다. 이들도 여전히 ‘스펙’입니다. 프롬프트 작성은 이러한 문서들이 모호하지 않고 테스트 가능하도록 제약, 엣지 케이스, 성공 기준, 명시적 가정을 포함해 쓰는 기술입니다.
좋은 프롬프트는 미니 디자인 브리프처럼 읽힙니다:
AI 기능이 IDE, 풀 리퀘스트, CI 체크, 문서 파이프라인에 통합되면서, 프롬프트는 가끔 쓰는 채팅 메시지가 아니라 일상 엔지니어링 흐름의 일부가 됩니다. 코드 요청 → 테스트 요청 → 리스크 리뷰 요청처럼 각 단계는 일관된 재사용 가능한 프롬프트 구조의 혜택을 봅니다.
디자인, 제품, QA, 엔지니어링이 점점 공유 AI 도구를 통해 협업합니다. 명확한 프롬프트는 ‘boundary object’가 되어 모두가 읽고 비판하고 ‘완료’가 무엇인지 정렬할 수 있게 합니다. 그 공유된 명확성은 재작업을 줄이고 리뷰를 더 빠르고 침착하게 만듭니다.
“로그인 페이지를 만들어” 같은 모호한 요청은 모델이 무엇을 의미하는지 추측하게 만듭니다. 테스트 가능한 프롬프트는 입력, 예상 출력, 엣지 케이스와 어떻게 올바른지를 알 수 있는지를 명시하는 미니 스펙처럼 읽힙니다.
시스템이 무엇을 받고 무엇을 만들어야 하는지부터 쓰세요.
예: “폼을 작동시켜” 대신 “이메일이 잘못되면 인라인 오류 메시지를 표시하고 제출을 비활성화; API가 409를 반환하면 ‘Account already exists’ 표시하고 입력값 유지”처럼 구체적으로 쓰세요.
제약은 출력을 현실에 맞게 고정하는 방법입니다.
다음과 같은 구체사항을 포함하세요:
단순히 코드를 요청하는 대신 결정과 대안을 설명하게 하세요. 리뷰를 쉽게 하고 숨은 가정을 표면화합니다.
예: “두 가지 접근을 제안하고 유지보수성과 성능 측면에서 장단점을 비교한 뒤 권장 옵션을 구현하라.”
예시는 애매함을 줄이고, 비예시는 오해를 막습니다.
약한 프롬프트: “사용자 업데이트 엔드포인트를 만들어.”
강한 프롬프트: “PATCH /users/{id} 설계. JSON { displayName?: string, phone?: string } 수용. 알 수 없는 필드는 거부(400). 사용자를 찾지 못하면 404. 전화번호는 E.164로 검증. 업데이트된 사용자 JSON 반환. 잘못된 전화, 빈 페이로드, 인증되지 않음 케이스에 대한 테스트 포함. 이메일은 변경하지 말 것.”
실용적 규칙: 프롬프트에서 테스트 케이스를 몇 개 바로 쓸 수 없다면 아직 충분히 구체적이지 않습니다.
웹 프롬프트는 모델을 주니어 팀원처럼 대할 때 가장 잘 작동합니다: 모델은 문맥, 제약, 그리고 ‘완료 정의’를 필요로 합니다. UI 작업에서는 디자인 규칙, 상태, 접근성, 검증 방법을 명시하는 것이 중요합니다.
“로그인 폼을 만들어” 대신 디자인 시스템과 엣지 케이스를 포함하세요:
예시 프롬프트: “우리 Button/Input 컴포넌트를 사용해 React LoginForm 생성. 제출 시 로딩 상태 포함, 인라인 검증과 접근 가능한 오류 메시지 포함. 모든 상태에 대한 Storybook 스토리 제공.”
리팩터링은 가드레일을 설정하면 더 원활합니다:
“이 컴포넌트를 리팩터링해 UserCardHeader와 UserCardActions를 추출하세요. 기존 props API를 유지하고 CSS 클래스명을 보존하며 시각적 출력은 변경하지 마세요. 이름을 바꿔야 한다면 마이그레이션 노트를 제공하세요.”
이렇게 하면 의도치 않은 깨짐을 줄이고 네이밍과 스타일 일관성을 지킬 수 있습니다.
마크업 뿐 아니라 마이크로카피와 상태 문구를 명시적으로 요청하세요:
“빈 상태, 네트워크 오류, 권한 거부에 대한 마이크로카피를 제안하라. 톤은 중립적이고 간결하게 유지. 카피와 어디에 표시되는지 반환.”
프론트엔드 버그의 프롬프트는 증거를 번들로 묶어야 합니다:
“다음 재현 단계, 콘솔 로그, 스택 트레이스가 주어졌을 때 가능한 원인을 제안하고 수정안을 신뢰도 순으로 정렬하라. 브라우저와 유닛 테스트에서 검증하는 방법 포함.”
제약과 검증을 포함한 프롬프트는 더 일관되고 접근성 있는, 검토 가능한 UI 출력을 만듭니다.
백엔드 작업은 부분 실패, 모호한 데이터, 재시도, 성능 문제 등 엣지 케이스가 많습니다. 좋은 프롬프트는 채팅에서 쉽게 넘겨짚을 수 있는 결정을 고정하는 데 도움이 됩니다.
“API를 만들어”라는 요청 대신 검토 가능한 계약을 산출하도록 요구하세요.
다음을 요구하세요:
예시 프롬프트:
Design a REST API for managing subscriptions.
Return:
1) Endpoints with method + path
2) JSON schemas for request/response
3) Status codes per endpoint (include 400/401/403/404/409/422/429)
4) Pagination and filtering rules
5) Idempotency approach for create/cancel
Assume multi-tenant, and include tenant scoping in every query.
(위 코드 블록은 번역하지 않고 원문 유지됨)
일관된 검증과 안정적인 “오류 형식”을 요구하세요. 클라이언트가 문제를 예측 가능하게 처리할 수 있어야 합니다.
유용한 제약들:
모델은 명시하지 않으면 옳지만 느린 코드를 생성하는 경향이 있습니다. 예상 트래픽, 레이턴시 목표, 데이터 크기를 프롬프트에 포함하고 트레이드오프를 요청하세요.
좋은 추가 항목:
기능의 일부로 가시성을 다루세요. 모델에게 무엇을 측정할지, 무엇이 액션을 유발할지 프롬프트에 포함시키세요.
모델에게 출력하게 하세요:
모바일 앱은 단순한 ‘나쁜 코드’ 때문만이 아니라 실제 기기 환경 때문에 실패합니다: 네트워크 단절, 배터리 소모, 백그라운드 실행 제한, 작은 UI 실수가 접근성 문제로 이어지는 등. 모바일 프롬프트는 기능이 아니라 제약을 전제로 설계하도록 요구해야 합니다.
“오프라인 모드 추가” 대신 트레이드오프가 명확한 계획을 요구하세요:
이런 프롬프트는 모델이 행복 경로를 넘어 생각하게 하고 검토 가능한 결정을 내리게 합니다.
모바일 버그는 사용자가 뒤로 누르거나 기기를 회전하거나 딥링크에서 돌아왔을 때 ‘대체로 맞는’ 상태가 깨지며 발생합니다.
다음과 같은 흐름을 설명하는 프롬프트를 사용하세요:
“화면과 이벤트는 다음과 같다 (login → onboarding → home → details). 상태 모델과 네비게이션 규칙을 제안하라. 프로세스 종료 후 상태 복원 방법, 중복 탭 및 빠른 뒤로가기 처리 방법 포함.”
간단한 흐름도나 라우트 목록을 붙이면 모델이 전환 체크리스트와 실패 모드를 생성할 수 있습니다.
일반적인 UI 조언이 아니라 플랫폼별 리뷰를 요청하세요:
“이 화면을 iOS Human Interface Guidelines / Material Design 및 모바일 접근성에 대해 검토하고 구체적 문제(터치 타겟 크기, 대비, 동적 타입/폰트 스케일링, 화면 읽기 레이블, 키보드 네비게이션, 햅틱 사용)를 나열하라.”
충돌 리포트는 스택 트레이스와 컨텍스트가 결합될 때 실행 가능해집니다:
“이 스택 트레이스와 기기 정보(OS 버전, 기기 모델, 앱 버전, 메모리 압박, 재현 단계)로 가능한 근본 원인을 제안하고 추가할 로그/메트릭, 안전한 수정과 롤아웃 계획을 제시하라.”
이 구조는 “무슨 일이 있었는가?”를 “다음에 무엇을 할 것인가?”로 바꿉니다—모바일에서 프롬프트의 가치가 가장 크게 발휘되는 지점입니다.
좋은 프롬프트는 재사용 가능합니다. 최상(最好)의 프롬프트는 작은 사양처럼 읽힙니다: 명확한 목적, 행동하기에 충분한 문맥, 검사 가능한 출력. 이러한 패턴은 UI 개선, API 설계, 모바일 크래시 디버깅 모두에 적용됩니다.
신뢰할 수 있는 구조는:
이 구조는 웹(접근성 + 브라우저 지원), 백엔드(일관성 + 오류 계약), 모바일(배터리 + 기기 제약) 전반에 걸쳐 모호함을 줄입니다.
이미 필요한 것이 명확할 때는 직접 출력을 사용하세요: “TypeScript 타입 + 예시 페이로드 생성”처럼. 빠르고 불필요한 긴 설명을 피할 수 있습니다.
결정이 중요한 경우에는 트레이드오프와 간단한 이유를 요청하세요: 페이징 전략 선택, 캐싱 경계 결정, 불안정한 모바일 테스트 진단 등. 실용적 절충안은: “핵심 가정과 트레이드오프를 간단히 설명한 뒤 최종 답을 제시하라.”
프롬프트를 미니 계약처럼 다루어 구조화된 출력을 요구하세요:
이렇게 하면 결과를 검토하기 쉽고, diff 친화적이며 스키마 검증으로 CI에 통합할 수 있습니다.
가드레일을 추가하세요:
팀이 AI를 정기적으로 사용하면 프롬프트는 ‘채팅 메시지’가 아니라 엔지니어링 자산처럼 행동합니다. 품질을 빠르게 개선하는 가장 쉬운 방법은 프롬프트를 코드와 동일하게 다루는 것입니다: 명확한 목적, 일관된 구조, 변경 이력 추적.
소유권을 할당하고 프롬프트를 버전 관리하세요. 프롬프트가 변경되면 왜 변경되었는지, 무엇이 개선되었는지, 무엇이 깨졌는지 답할 수 있어야 합니다. 가벼운 접근법은 각 리포지토리에 /prompts 폴더를 두고 워크플로별 파일(예: pr-review.md, api-design.md)을 하나씩 두는 것입니다. 변경은 풀 리퀘스트로 리뷰하세요.
채팅 기반 인터페이스를 제공하는 플랫폼을 사용하더라도(예: Koder.ai), 프로덕션 코드를 생성하는 입력은 버전화되거나 재사용 가능한 템플릿으로 캡처되어야 합니다. 그래야 팀이 스프린트 간에 결과를 재현할 수 있습니다.
대부분 팀은 PR 리뷰, 사고 요약, 데이터 마이그레이션, 릴리스 노트 같은 반복 작업을 합니다. 입력(문맥, 제약, 완료 정의)과 출력(형식, 체크리스트, 수용 기준)을 표준화하는 프롬프트 템플릿을 만드세요. 이렇게 하면 엔지니어 간 편차가 줄고 검증이 쉬워집니다.
좋은 템플릿은 보통 다음을 포함합니다:
특히 보안에 민감한 영역, 규정 준수 관련 변경, 프로덕션 DB 수정, 인증/결제 관련 변경 등은 사람이 반드시 승인해야 한다는 규칙을 문서화하세요. 이 규칙을 프롬프트 옆이나 /docs/ai-usage.md에 두어 누구도 기억에 의존하지 않게 하세요.
도구가 지원하면 ‘안전한 반복’ 메커니즘을 워크플로에 포함하세요. 예를 들어 Koder.ai 같은 플랫폼은 스냅샷과 롤백을 지원해 생성된 변경을 실험하고, diff를 리뷰하고, 문제가 있으면 깔끔하게 되돌릴 수 있게 합니다.
프롬프트가 1급 자산이 되면 재현성, 감사 가능성, 더 안전한 AI 지원 전달을 얻을 수 있습니다—팀 속도를 늦추지 않으면서 말입니다.
프롬프트를 평가할 수 없다면 개선할 수 없습니다. “대체로 작동한다”는 취약합니다—특히 같은 프롬프트가 팀에서 재사용되고 CI에서 실행되거나 새로운 코드베이스에 적용될 때 그렇습니다.
프롬프트에 대한 “알려진 입력 → 기대 출력” 소규모 스위트를 만드세요. 핵심은 출력을 검사 가능하게 만드는 것입니다:
예: API 오류 계약을 생성하는 프롬프트는 항상 같은 필드, 일관된 네이밍과 상태 코드를 생성해야 합니다.
프롬프트를 업데이트할 때 새 출력과 이전 출력을 비교하고: **무엇이 왜 바뀌었는가?**를 물어보세요. Diff는 누락된 필드, 다른 톤, 순서 교체 같은 회귀를 명확히 보여주어 리뷰어가 동작 변화에 집중하게 합니다.
프롬프트는 코드와 같은 규율로 테스트할 수 있습니다:
플랫폼 워크플로로 전체 애플리케이션(웹, 백엔드, 모바일)을 생성하는 경우, 이러한 검사는 더욱 중요합니다. 속도는 리뷰 처리량을 높여야지 엄격성을 낮추면 안 됩니다.
마지막으로 프롬프트가 실제 전달 능력을 개선하는지 추적하세요:
프롬프트가 시간을 절약하지만 재작업을 늘리면 이는 ‘좋다’가 아니라 단지 빠른 것뿐입니다.
LLM을 엔지니어링에 도입하면 ‘기본적으로 안전한(safe by default)’의 의미가 바뀝니다. 모델은 어떤 세부가 기밀인지 알 수 없고, 그럴듯해 보이는 코드에 취약점을 숨길 수 있습니다. AI 지원을 CI, 의존성 스캔, 코드 리뷰처럼 가드레일이 필요한 도구로 취급하세요.
채팅에 붙여넣는 모든 것은 저장되거나 로깅되거나 검토될 수 있다고 가정하세요. API 키, 액세스 토큰, 개인 인증서, 고객 데이터, 내부 URL, 사고 세부는 절대 포함하지 마세요. 대신 플레이스홀더와 최소 합성 예시를 사용하세요.
디버깅에 도움이 필요하면:
팀용 레다액션 워크플로(템플릿과 체크리스트)를 만들어 사람들이 시간 압박에 따라 제멋대로 규칙을 만들지 않게 하세요.
AI가 생성한 코드는 주입 공격, 불안전한 기본값, 누락된 권한 검사, 취약한 의존성 선택, 부실한 암호화 같은 고전적 문제를 도입할 수 있습니다.
실용적 프롬프트 습관으로는 모델에게 자체 산출물을 비판하게 하는 것입니다:
인증, 암호화, 권한 검사, 접근 제어 같은 민감 영역에 대해선 ‘보안 리뷰 프롬프트’를 정의 완료 조건의 일부로 만드세요. 인간 리뷰와 자동화 검사(SAST, 의존성 스캔)와 짝지어 적용해야 합니다. 내부 표준이 있으면 프롬프트에 링크로 포함하세요(예: “/docs/security/auth을 따르라”).
목표는 AI를 금지하는 것이 아니라 안전한 행동이 가장 쉬운 행동이 되게 하는 것입니다.
프롬프트 작성은 개인의 트릭이 아니라 팀 기술로 확장될 때 가장 효과적입니다. 목표는 추상적 ‘더 나은 프롬프트’가 아니라 오해 감소, 빠른 리뷰, 예측 가능한 AI 지원 결과입니다.
프롬프트를 쓰기 전에 팀이 완료 정의에 합의하세요. “더 낫게 만들어라”를 수검 가능한 기대치로 바꾸세요: 수용 기준, 코딩 표준, 네이밍 컨벤션, 접근성 요구, 성능 예산, 로깅/가시성 요구 등.
실용적 방법은 프롬프트에 작은 “출력 계약”을 포함하는 것입니다:
팀이 일관되게 하면 프롬프트 품질은 코드처럼 검토할 수 있게 됩니다.
페어 프롬프트는 페어 프로그래밍을 닮았습니다: 한 사람이 프롬프트를 쓰고 다른 사람이 그것을 검토하며 가정을 적극적으로 탐구합니다. 리뷰어는 다음과 같은 질문을 던져야 합니다:
이렇게 하면 애초에 모호함을 잡아내고 AI가 잘못된 것을 자신있게 만들지 못하게 할 수 있습니다.
코드베이스에서 나온 예시로 가벼운 프롬프트 플레이북을 만드세요: “API 엔드포인트 템플릿”, “프론트엔드 컴포넌트 리팩터 템플릿”, “모바일 성능 제약 템플릿” 등. 위키나 리포지토리 같은 엔지니어가 이미 사용하는 곳에 보관하고 PR 템플릿에 링크하세요.
조직이 단일 플랫폼에서 교차 기능 빌드를 한다면(제품 + 디자인 + 엔지니어링) 그곳에도 템플릿을 표준화해서 두세요. 예를 들어 Koder.ai 팀은 종종 계획 모드(먼저 범위와 수용 기준 합의)로 표준화하고, 그다음 구현 단계와 테스트를 생성합니다.
버그나 사고가 불명확한 프롬프트에서 기인했다면 코드만 고치지 말고 프롬프트 템플릿을 업데이트하세요. 시간이 지나면 최고의 프롬프트가 조직의 기억이 되어 반복적 실패와 온보딩 시간을 줄여줍니다.
AI 프롬프트 도입은 대규모 ‘AI 이니셔티브’가 아니라 작은 엔지니어링 변화로 시작할 때 가장 잘 작동합니다. 다른 생산성 관행처럼 좁게 시작해 영향 측정 후 확장하세요.
팀당 3–5개의 사용 사례를 선택하세요. 빈도 높고 위험 낮고 평가 쉬운 항목을 고르세요. 예:
‘좋음’의 기준(시간 절약, 버그 감소, 문서 명확화)을 적어 팀에 공유하세요.
작고 집중된 프롬프트 템플릿 라이브러리(5–10개)를 매주 반복 개선하세요. 각 템플릿은 문맥, 제약, 기대 출력, 간단한 완료 정의를 포함해 집중적으로 구성하세요. 템플릿은 엔지니어가 이미 사용하는 곳(리포지토리 폴더, 내부 위키, 티켓 시스템)에 보관하세요.
플랫폼 접근을 평가 중이면 생성→테스트→배포→소스 내보내기 전체 수명주기를 지원하는지 확인하세요. 예: Koder.ai는 채팅 기반 빌드로 웹, 백엔드, Flutter 모바일 앱을 생성하고 소스 코드 내보내기와 배포/호스팅 기능을 제공하므로, 프롬프트가 단편을 넘어 재현 가능한 빌드로 이동할 때 유용합니다.
거버넌스는 간단하게 유지해서 배송을 지연시키지 마세요:
팀이 도움된 프롬프트 하나를 데모하는 30분 세션을 진행하세요. 몇 가지 메트릭(사이클 타임 감소, 리뷰 코멘트 감소, 테스트 커버리지 향상)을 추적하고, 성과가 없으면 템플릿을 사용 중단하세요.
더 많은 패턴과 예시는 /blog를 참고하세요. 팀 규모 지원을 위한 툴링이나 워크플로를 평가 중이라면 /pricing을 참조하세요.
프롬프트는 어시스턴트를 특정하고 검증 가능한 결과로 이끄는 검토 가능한 입력을 작성하는 행위입니다. 티켓이나 스펙, 테스트 플랜처럼 출력물을 명시된 제약과 수용 기준에 대해 평가할 수 있어야 한다는 점이 핵심입니다. 단순히 “보기 좋다” 수준이 아니라 명확히 검증 가능한 상태여야 합니다.
실용적인 프롬프트는 보통 다음을 포함합니다:
프롬프트에서 테스트 케이스 몇 개를 바로 쓸 수 없다면 아직 너무 모호할 가능성이 큽니다.
모호한 프롬프트는 모델이 제품 규칙, 디자인 시스템, 오류 의미론을 추측하게 만듭니다. 요청을 요구사항으로 바꾸세요:
예: 409가 반환될 때의 동작, 변경 불가능한 필드, 각 오류에 표시할 UI 문구를 명시하세요.
제약은 ‘보기는 좋은데 틀린’ 출력을 막습니다. 다음과 같은 항목을 포함하세요:
제약이 없으면 모델이 임의의 가정으로 빈칸을 채우게 됩니다.
사전에서 디자인과 품질 요구를 명시하세요:
이렇게 하면 디자인 시스템으로부터의 이탈이 줄고, ‘완료’ 기준이 명확해져 리뷰가 빨라집니다.
검토 가능한 계약을 요구하세요:
잘못된 페이로드, 인증 실패, 빈 업데이트 같은 엣지 케이스를 포괄하는 테스트를 요구하세요.
실제 디바이스 제약과 실패 모드를 포함하세요:
모바일 프롬프트는 행복 경로뿐 아니라 복구 경로와 흐름을 묘사해야 합니다.
**직접 출력(direct output)**은 작업이 명확할 때 사용하세요(예: “TypeScript 타입 + 예시 페이로드 생성”). 결정을 요하는 경우에는 트레이드오프와 간단한 이유를 요청하세요(페이징 전략, 캐싱 경계, 불안정한 테스트 진단 등).
실용적 절충안: 중요한 가정과 장단점을 간단히 적게 한 뒤 최종 산출(코드/계약/테스트)을 요구하세요.
구조화된, 린트할 수 있는 출력을 요구해 결과를 검토하고 diff하기 쉽게 만드세요. 예:
changes, assumptions, risks, tests를 가진 JSON구조화된 출력은 모호함을 줄이며 회귀를 쉽게 식별하고 CI에서 스키마 검증을 가능하게 합니다.
유출과 위험한 출력을 줄이는 프롬프트와 워크플로를 사용하세요:
AI 산출물은 리뷰되고 검증되기 전까지 신뢰하지 않는다는 관점으로 다루세요.
{
"changes": [{"file": "", "summary": "", "patch": ""}],
"assumptions": [],
"risks": [],
"tests": []
}