구조화 프롬프트 작성법: json 프롬프트는 필드를 어떻게 설계해야 할까

짧은 문장형 프롬프트는 한 줄짜리 인라인 코드를 쓰는 것과 비슷해요, 돌아가긴 하지만 요구사항이 복잡해지면 한 줄에 다 욱여넣어서 누구도 읽기 힘들어져요. 구조화 프롬프트는 인터페이스를 정의하는 것에 더 가까워요—피사체, 장면, 조명 같은 정보를 필드로 나누고 각각 값을 부여하면, 모델도 읽기 편하고 본인도 어느 필드가 어느 효과에 대응하는지 알기 쉬워서 수정하기도 편해요. 이 글은 신비주의 없이, 필드 설계라는 관점에서 이 작성법을 하나씩 풀어볼게요.

언제 구조화를 써야 하고, 언제 필요 없을까

판단 기준은 간단해요: 요구사항 안의 독립 변수가 세 개를 넘으면 필드로 나눠야 해요. 단순한 화풍 변환 이미지는 "이 사람+이런 화풍" 두 변수뿐이라 한 문장이면 충분해요, 억지로 필드를 열 개로 쪼개면 오히려 과설계고 본인 시간만 낭비하는 거예요. 하지만 다중 참조 이미지, 화면 속 텍스트, 여러 정보 블록(예: 제품 사진 9분할, 다중 뷰 설정 이미지)이 들어가면, 변수 개수가 늘어나는 순간 짧은 문장형 프롬프트로는 정보 밀도가 부족해져요, 이때 구조화 작성법을 써야 해요.

이 경계를 판단하는 방법은 아주 직관적이에요: 요구사항을 한 번 읽어보고 그 안에 "그리고"가 몇 개인지 세어보세요, "그리고"가 세 개를 넘으면 필드를 나눠야 해요.

자주 쓰는 필드 설계, 기본 필드 여섯 개면 대부분의 상황에 충분해요

• style: 전체적인 스타일 수식어, 한 문장으로 톤을 정해요, 예를 들어 "시네마틱한 사실적 사진"
• subject: 피사체가 누구인지, 어떤 상태인지, 가장 모호하게 쓰기 쉬운 필드라 동작과 표정까지 구체적으로 써야 해요
• scene: 장면과 소품, 공간 관계를 설명해요, 피사체와 환경의 상대적 위치를 빠뜨리면 안 돼요
• lighting: 광원 방향, 강도, 색온도, 이 필드를 따로 뽑는 이유는 완성 사진의 질감에 미치는 영향이 가장 크기 때문이에요
• camera: 구도 비율, 렌즈 각도, 초점 위치, 순전히 기술적인 파라미터라 콘텐츠 레이어와 분리해서 써요
• negative（모델이 지원한다면）: 나오면 안 되는 요소를 명확히 해요, 예를 들어 "손가락이 추가로 나오면 안 됨, 배경에 잡동사니가 있으면 안 됨"

필드 순서에도 요령이 있어요, 인터페이스 파라미터와 마찬가지로 핵심 파라미터를 앞에, 선택 파라미터를 뒤에 두세요: 먼저 subject, 그다음 scene, 그다음 lighting, 마지막이 camera, 네거티브 항목은 따로 구조 맨 뒤에 두고 긍정적인 묘사와 섞지 마세요.

템플릿 1: 인물사진류, 전체 필드 예시

style: 필름 질감의 사실적 사진, 그레인 약간
subject: 워크재킷을 입은 여성 한 명, 편안하게 앉은 자세, 시선은 카메라 바깥쪽을 향함
scene: 낡은 공방 내부, 배경에 흩어진 공구와 기어 장치, 기계적인 분위기의 장면을 연출
lighting: 측면 창광 하나, 강한 빛으로 가장자리가 뚜렷함, 색온도는 중성에서 약간 차가운 쪽
camera: 상반신 구도, 얕은 심도, 세로 4:5

이 공방 인물사진이 바로 이 필드대로 만들어진 거예요, 장면 소품과 조명을 따로따로 필드로 나눠 설명했지 한데 뒤섞어 쓰지 않았어요, 이런 인물사진 요청은 필드를 명확히 나눈 뒤로 재작업률이 눈에 띄게 낮아졌어요.

템플릿 2: 이커머스 정물류, 전체 필드 예시

style: 드라마틱한 명암의 푸드 사진, 고대비
subject: 바닐라 아이스크림을 곁들인 브라우니 한 조각, 초콜릿 소스가 막 부어지는 순간
scene: 짙은 색 나무 테이블, 배경은 흐림, 불필요한 소품 없음
lighting: 측역광, 초콜릿 소스의 흐르는 질감과 광택을 부각
camera: 클로즈업 구도, 정사각형 1:1, 소스를 붓는 순간에 초점

이 푸드 정물 사례는 "동작의 순간"을 subject 필드 안에 따로 명확히 넣었어요, 그래서 소스 붓는 흐름감이 정지된 흐물흐물한 모양으로 나오지 않았어요, 이커머스 제품 카테고리의 정물 요청에는 다 이 필드 구조가 적용돼요.

템플릿 3: 다중 뷰와 피규어류, 전체 필드 예시

style: 3D 렌더링 질감, 컬렉터급 디테일
subject: 돌 블록으로 조립된 인간형 실루엣 조각상, 층별 조립 흔적이 뚜렷하게 보임
scene: 미니멀 전시대, 회색 배경으로 방해 요소 없음
lighting: 탑라이트에 양쪽 보조광 추가, 소재 텍스처를 부각
camera: 정면 구도, 정사각형 1:1, 가운데 대칭

이 실루엣 조각상 사례의 층별 조립 디테일은 subject 필드에 "층별 흔적이 뚜렷하게 보임"이라는 요구를 명확히 써넣어서 남은 거예요, 이 문장을 안 쓰면 모델이 이음매를 매끈하게 없애버릴 확률이 높아요.

다중 뷰, 두 인물 대조처럼 "같은 캐릭터의 여러 상태"가 필요한 요청은 필드 설계에서 하나를 더 추가하세요—각 구역별 차이점을 명확히 설명하는 거예요, 어디가 바뀌어야 하고 어디는 바뀌면 안 되는지 모델이 알아서 판단하게 두지 마세요.

이 실사-만화 대조 사례는 프롬프트 안에 "왼쪽은 사실적인 질감 유지, 오른쪽은 만화 렌더링으로 전환, 의상 스타일은 동일하게"라는 문장을 따로 넣었어요, 이 차이 설명이 바로 구조화 작성법에서 따로 뽑아야 할 필드예요, 크리에이티브 카테고리에는 이런 이중 대조 요청이 적지 않아요.

어떤 모델이 이 방식을 잘 받아들이고, 어떤 모델은 안 그럴까

이 필드화 작성법이 모든 모델에 다 통하는 건 아니에요. Nano Banana Pro는 구조화된 긴 프롬프트를 확실히 더 완전하게 해석해요, 필드를 세밀하게 나눌수록 실행이 더 정확해요, 앞의 템플릿 사례들도 대부분 이 모델에서 나온 거예요; GPT Image 2는 다른 노선을 타요, 구조화된 전체 설명을 대화형의 연속 수정으로 "번역"하는 데 더 능해서, 필드 전체를 억지로 다 밀어 넣는다고 사람 말로 직접 요청하는 것보다 꼭 효과가 좋은 건 아니에요, 구체적인 차이는 GPT Image 2 대 Nano Banana Pro 비교 이 실측 비교 글을 보세요; 속도가 더 빠른 Nano Banana는 둘 사이 어딘가에 있어요, 필드를 너무 세밀하게 나누지 말고 큰 것부터 잡는 게 더 안정적이에요.

이 피규어 그리드 사례는 GPT Image 2로 구조화 그리드 레이아웃 요청을 실행한 거예요, 필드화 작성법이 이 모델에서도 통하긴 하지만, 앞의 Nano Banana Pro 사례들만큼 성공률이 안정적이지 않아요, 이것도 "구조화 작성법의 효과는 모델마다 다르다"는 결론을 뒷받침해요, 아무 모델에나 그대로 적용해도 똑같이 잘 통하는 게 아니에요.

필드 설계 방식이 익숙해지면, 짧은 문장형 프롬프트의 만능 구조 공식을 다시 보면 본질적으로 같은 이야기라는 걸 알게 돼요, 다만 구조화 작성법은 공식 안에 숨어 있던 순서를 필드로 명시적으로 나눈 것뿐이에요, 요구사항이 어느 정도 복잡해지면 필드를 나누는 게 문장을 쌓는 것보다 유지보수하기 좋아요. 가중치 제어를 필드와 어떻게 결합하는지 궁금하다면 프롬프트 가중치 글을 참고하세요; 대화형 수정 노선의 완전한 설명은 GPT Image 2 프롬프트 가이드에 있어요. 홈페이지 image.faxianai.com에는 전체 사례 라이브러리가 있고, 모델 백과에는 각 모델의 필드 적응 상황이 정리되어 있어서 바로 참고해서 고쳐 쓸 수 있어요.