Edit Fields는 단순히 이름을 예쁘게 바꾸는 노드가 아닙니다. 다음 노드가 받을 데이터 계약을 만드는 곳입니다. 여기서 원본 ID를 빼거나 이메일을 잘못된 필드에 매핑하면, 뒤의 Google Sheets·API·분기 노드가 성공 표시를 보여도 업무 결과는 틀릴 수 있습니다.
이 글의 범위: 공식 문서를 바탕으로 한 입력·출력 설계와 가상 데이터 시험표입니다. 이 예제는 실제 n8n 실행 기록이나 외부 스프레드시트 저장 결과가 아닙니다. 고객 데이터·API 키·메일 연결 없이 구조를 먼저 검토하는 방법을 다룹니다.
노드가 실제로 바꾸는 것
n8n Edit Fields (Set) 공식 문서에 따르면 이 노드는 새 데이터를 설정하고 기존 데이터를 덮어쓸 수 있습니다. Mode는 화면에서 필드를 고르는 Manual Mapping과 JSON을 작성하는 JSON Output으로 나뉩니다.
| 결정 | 의미 | 확인하지 않으면 생기는 문제 |
|---|---|---|
| 필드 이름과 값 | 고정값인지 이전 입력을 참조하는 표현식인지 결정 | 원하는 값 대신 글자 그대로의 표현식이나 고정 문구가 저장됨 |
| Include in Output | 입력 데이터 중 무엇을 결과에 남길지 선택 | 다음 노드에 필요했던 원본 ID·버전이 사라짐 |
| Keep Only Set Fields | 설정하지 않은 입력 필드를 버림 | 실수로 필요한 필드까지 제거 |
| Support Dot Notation | customer.name을 중첩 경로로 해석할지 결정 |
글자 그대로의 키가 필요했는데 객체 구조가 만들어짐 |
Manual Mapping에서 INPUT 값을 끌어오면 n8n은 기본적으로 해당 값을 참조하는 표현식을 만듭니다. 고정값을 넣고 싶을 때만 Fixed로 바꿉니다. JSON Output도 편리하지만, 작성한 JSON이 입력에 어떤 필드를 더하고 어떤 출력 포함 설정을 사용하는지 따로 확인해야 합니다.
먼저 정해야 할 최소 데이터 계약
다음 예제는 웹 폼·메일·API 중 무엇을 쓰든 중간 단계에서 사용할 가상 문의 구조입니다. 개인 정보가 아닌 샘플 값입니다.
입력(가상)
{
"source_id": "LAB-FORM-001",
"full_name": "테스트 사용자",
"email_address": "sample@example.invalid",
"message": "샘플 문의입니다",
"submitted_at": "2026-09-21T09:00:00Z",
"debug_note": "이 값은 다음 단계에 보내지 않음"
}
이 입력을 다음 단계용으로 정리한다면, 사람에게 읽기 쉬운 이름과 같은 사건을 식별하는 값을 분리합니다. name은 표시용이고, source_id는 중복·재처리 확인에 필요한 식별자입니다. 제목이나 이름을 식별자로 대체하지 않습니다.
| 출력 필드 | 출처 또는 고정값 | 다음 단계에서의 책임 |
|---|---|---|
source_id |
입력 source_id |
같은 사건 대조 |
name |
입력 full_name |
표시·검토 |
email |
입력 email_address |
허용된 경우에만 대상 확인 |
inquiry |
입력 message |
분류·검토용 원문 범위 |
received_at |
입력 submitted_at |
원래 수신 시각 |
processing_status |
고정값 needs_review |
사람 검토 대기 표시 |
input_version |
고정값 또는 사전에 정한 버전 | 어떤 규칙으로 만든 결과인지 구분 |
processed_at처럼 이 노드가 실행된 시각이 필요하면 received_at과 별도 필드로 둡니다. 둘을 같은 현재 시각으로 채우면 원본 수신 시각이 사라집니다. 상태 필드는 진행 상황을 기록할 뿐, 동시 실행을 잠그거나 중복을 자동 차단하지는 않습니다.
외부 연결 없이 확인하는 4개 가상 시험
아래 표는 테스트 계획입니다. 결과 칸은 기대값이지 이번에 실행해 관찰한 값이 아닙니다. Edit Fields 뒤에는 외부 쓰기 노드를 붙이지 않고 출력만 확인합니다.
| 시험 | 입력 변화 | 기대 확인 | 통과로 오해하면 안 되는 것 |
|---|---|---|---|
| S01 정상 구조 | 위 가상 입력 그대로 | source_id와 7개 계약 필드가 의도대로 보임 | 외부 표 저장·중복 방지 성공 |
| S02 이메일 누락 | email_address을 비움 또는 제거 |
출력 형태와 별도의 검증 경로가 무엇을 하는지 기록 | Edit Fields만으로 발송 금지·필수값 검사가 자동 적용됨 |
| S03 점 표기 | 필드 이름을 customer.name으로 설정 |
Dot Notation 설정에 따라 중첩 객체 또는 글자 그대로의 키인지 확인 | 대상 앱의 열 이름도 같은 방식으로 해석됨 |
| S04 필요한 ID 보존 | Keep Only Set Fields를 켠 구성 | source_id·input_version 등 다음 노드가 쓸 값이 남아 있음 | 불필요한 원문·민감 정보가 모든 로그에서 사라짐 |
S02처럼 필수값이 없을 때는 Edit Fields 다음에 바로 생성·발송 노드를 연결하지 않습니다. 먼저 IF나 Switch에서 명시적인 검증·보류 경로를 만들고, 빈 값이 어떤 자료형으로 들어오는지 실제 입력 규격에서 확인해야 합니다. 빈 문자열·null·필드 누락은 같은 현상이 아닐 수 있습니다.
JSON Output과 Manual Mapping의 선택 기준
처음에는 Manual Mapping으로 각 값의 출처를 확인하는 편이 낫습니다. 필드 수가 늘거나 배열·객체를 한 번에 만들 필요가 있을 때 JSON Output을 고려합니다. 어느 방식을 쓰든 아래 두 결과를 비교해야 합니다.
확인할 출력 1. 필요한 계약 필드의 이름·값·자료형 2. 이전 입력 중 남아 있어야 하는 값과 제외돼야 하는 값 3. 중첩 객체의 실제 구조 4. 각 결과가 어느 입력 항목에서 왔는지
예를 들어 JSON Output에 새로운 필드를 넣었다고 해서 자동으로 이전 입력이 모두 사라지는 것은 아닙니다. Include in Output 설정과 출력 패널을 함께 봐야 합니다. JSON 문법이 맞더라도 필드명이 다음 앱의 열·속성과 다르면 업무상 오류가 됩니다.
개인정보와 원문은 필요한 범위만 넘기기
모든 원본 필드를 “혹시 모르니” 다음 노드로 넘기지 마세요. 다음 단계가 실제로 필요한 필드만 정하고, 고객 정보·비밀키·인증 헤더·디버그 메모는 샘플과 운영 데이터 모두에서 분리합니다. 실행 기록에도 값이 남을 수 있으므로 스크린샷이나 오류 알림에 객체 전체를 복사하지 않습니다.
Google Sheets에 한 건을 기록하는 경로를 설계한다면 Gmail → Sheets 한 건 연결 실습의 수신 시각·로그 시각·ID 구분을 함께 확인하세요. AI로 처리할 입력·결과 열 설계는 입력과 결과 열 나누기에서 이어집니다.
저장 전·후에 남길 기록
흐름 / 버전: 입력 샘플 ID와 민감하지 않은 예제: Manual Mapping 또는 JSON Output: Include in Output / Keep Only Set Fields 설정: 점 표기 설정: 예상 계약 필드 / 실제 출력 필드: 누락·공백·점 표기 시험 결과: 외부 쓰기 여부(없음/있음)와 검증 범위: 다음 수정 또는 미확인 항목:
이 기록을 채웠다고 바로 자동 실행을 켜라는 뜻은 아닙니다. 외부에 쓰기 전에는 테스트 증거·중지·복구 기준에서 ID 보존·중복·중지·복구 항목을 별도로 확인하세요.
2026-09-21 보완: 최신 Edit Fields 문서의 Manual Mapping·JSON Output·출력 포함·점 표기 동작을 기준으로 가상 입력/출력 시험표를 추가했습니다. n8n Cloud 작업 공간이 현재 접근되지 않아 실제 노드 실행·외부 저장은 수행하지 않았습니다.