01 / DISPLAY OR DAMAGE

지수 표시만 보고
손상 여부를 판단하지 않습니다

열이 좁거나 일반 형식을 사용하면 긴 숫자가 지수 표기로 보일 수 있습니다. 표시만 바뀐 경우에는 열을 넓히고 수식 입력줄을 확인하면 원래 값이 남아 있을 수 있습니다. 하지만 유효숫자가 15자리를 넘는 식별자를 숫자로 취급하면서 끝자리가 사라졌다면 표시 형식의 문제가 아닙니다.

Microsoft의 큰 숫자·앞자리 0 안내 (새 탭)도 숫자 정밀도와 텍스트 보존을 구분합니다. 상품 ID처럼 더하거나 평균을 내지 않는 값은 Text를 먼저 검토하세요. 큰 금액·측정값처럼 계산이 필요한 수라면 이 글의 식별자 보존법으로 정밀한 계산까지 해결된다고 보면 안 됩니다.

02 / REPRODUCE

길이는 16으로 같아도
EXACT는 FALSE일 수 있습니다

빈 시트 A2에 =1234567890123456을 입력합니다. B2는 입력 전에 셀 표시 형식을 Text로 지정하고 1234567890123456을 입력합니다. 이 합성 숫자는 실제 고객·계정 번호가 아닙니다. Text 대신 앞에 작은따옴표를 붙여 입력할 수도 있지만, 이미 손상된 셀 뒤에 붙이는 조치는 복구가 아닙니다.

C2에는 =TEXT(A2,"0"), D2에는 =EXACT(C2,B2)를 넣습니다. E2는 =LEN(C2), F2는 =LEN(B2), G2는 =ISTEXT(B2)입니다. TEXT는 현재 숫자를 문자열로 표시할 뿐 원본을 되살리지 않습니다.

같은 길이라는 이유로 검증을 끝내면 이 차이를 놓칩니다. 서로 다른 두 원본이 같은 숫자로 바뀌면 조회나 중복 검사 결과도 달라질 수 있습니다. 표시된 자릿수를 맞추거나 뒤에 0을 추측해 넣는 방법은 원본을 증명하지 못합니다.

03 / IMPORT AGAIN

변환되기 전 원본으로 돌아가
식별자 열만 Text로 지정합니다

CSV가 이미 손상됐다면 덮어쓰지 말고 닫습니다. 수정하지 않은 원본 CSV나 시스템에서 다시 내보낸 파일을 확보하세요. 백업 없이 끝자리를 알아낼 수 없는 상태는 수식으로 복구한다고 약속할 수 없습니다.

item_id,quantity
1234567890123456,2
1234567890123450,1
0000123456789012,3

1. Data → From Text/CSV로 원본을 선택합니다.구분자와 인코딩을 확인합니다. 이 예제는 쉼표, 두 열, 데이터 세 행입니다.
2. Transform Data에서 자동 자료형 변환을 확인합니다.Changed Type 단계가 item_id를 숫자로 바꿨다면 그 단계를 제거한 뒤, 변환 전 값에서 item_id를 Text로 지정합니다. 숫자로 손상된 결과를 다시 Text로 바꾸는 것과 다릅니다.
3. 수량은 별도로 숫자로 지정합니다.Close & Load 후 item_id 세 문자열을 원본과 대조합니다. quantity 합계는 6이어야 합니다. ID를 합산하거나 숫자로 바꿔 비교하지 않습니다.

일부 최신 Excel에는 Automatic Data Conversions 옵션이 있지만 버전·진입 경로에 따라 다릅니다. 이 글은 해당 옵션이 항상 있거나 모든 가져오기에 적용된다고 가정하지 않습니다. 작업 절차의 기준은 Microsoft의 숫자를 Text로 다루는 안내 (새 탭)와 사용 환경을 함께 확인하세요.

04 / BROWSER ALTERNATIVE

보존용 XLSX가 필요하다면
모든 셀을 Text로 만드는 대안도 있습니다

Column Harbor CSV→Excel 도구 (영문, 새 탭)에 위 CSV를 붙여넣고 Comma로 해석한 뒤 미리보기 세 행과 두 열을 대조할 수 있습니다. XLSX 사본은 브라우저에서 만들어지며 원본 CSV를 덮어쓰지 않습니다. 내려받은 Data 시트에서 item_id 값과 ISTEXT를 확인하세요.

05 / OBSERVED RESULT

손상된 값이 아닌
원본 문자열과 대조합니다

Windows Excel 16.0 build 5574.0의 별도 통합문서에서 숫자 리터럴, 미리 Text로 정한 셀, TEXT·LEN·EXACT·ISTEXT를 계산했습니다. 숫자에서 만든 문자열은 1234567890123450, Text 셀은 1234567890123456이었고 둘의 길이는 모두 16이었습니다. EXACT는 FALSE, Text 셀의 ISTEXT는 TRUE였습니다.

실행한 것은 Excel COM의 고정 수식 계산과 Text 셀 값 지정입니다. 리본 메뉴 클릭, CSV 가져오기, 브라우저 도구의 XLSX 내보내기, 저장 후 재열기나 모든 Excel 버전을 이번에 새로 검증한 결과가 아닙니다. 위 가져오기·브라우저 경로를 사용했다면 자신의 결과 파일을 따로 대조해야 합니다.

1. 첫 행뿐 아니라 값의 충돌도 확인합니다.첫 두 ID의 끝자리가 6과 0으로 구별되고, 세 번째 ID의 앞자리 0이 남아 있어야 합니다.
2. 문자열과 계산 열을 나눕니다.ID는 정확히 보존하고 quantity만 수치로 검토합니다. LEN만 맞거나 합계만 맞는 것으로 끝내지 않습니다.
3. 왕복 저장은 별도 확인합니다.CSV에는 Excel 셀 자료형이 저장되지 않습니다. 내보낸 원문에 문자가 남는지 확인하고 다시 가져올 때도 Text 규칙을 적용합니다.

01 / DIAGNOSE

눈으로 보기 전에
문자 코드를 확인합니다

TRIM은 일반 공백인 ASCII 32를 정리합니다. 앞뒤 공백을 없애고 단어 사이의 연속 공백을 한 칸으로 줄입니다. 웹페이지에서 가져온 값에 자주 섞이는 NBSP는 U+00A0, 십진수 160입니다. Microsoft도 TRIM만으로 NBSP를 제거하지 못한다고 TRIM 문서 (새 탭)에서 구분합니다.

A3의 첫 문자가 의심된다면 =UNICODE(LEFT(A3,1))로 읽습니다. 160이면 NBSP이며 32라면 일반 공백입니다. 끝 문자라면 LEFT 대신 RIGHT를 씁니다. 빈 셀에는 이 검사가 오류를 낼 수 있으므로 비어 있지 않은 표본에서 시작하세요. 첫 문자 코드만 같다고 셀 전체가 같다는 뜻도 아닙니다.

02 / REPRODUCE

원본 옆에서
네 가지 값을 나란히 봅니다

빈 시트의 A1에 raw_text를 쓰고 A2:A5에 아래 수식을 각각 입력합니다. 눈에 보이지 않는 문자를 직접 복사하지 않아도 같은 입력을 만들 수 있습니다. 인수 구분자가 세미콜론인 환경에서는 쉼표를 맞춰 바꾸세요.

="  Seoul  Center  "
=UNICHAR(160)&"Seoul"&UNICHAR(160)&"Center"&UNICHAR(160)
="AB  12"
=UNICHAR(8239)&"Seoul"&UNICHAR(8239)

TSV의 첫 열에는 실제 공백 문자들이 들어 있습니다. 입력 수식으로 만들거나, TSV를 UTF-8·탭 구분·Text로 가져온 뒤 A열 값이 같은지 확인하세요. 파일 가져오기 UI는 이번 실행 검증 범위가 아닙니다. 이 예제의 값은 모두 합성 자료이며 고객 이름이나 실제 상품 코드가 아닙니다.

03 / COMPARE

NBSP를 일반 공백으로 바꾼 뒤
TRIM을 적용합니다

B2에는 =TRIM(A2), C2에는 =TRIM(SUBSTITUTE(A2,UNICHAR(160)," "))를 입력하고 5행까지 채웁니다. SUBSTITUTE의 마지막 인수는 빈 문자열이 아니라 일반 공백 한 칸입니다. 이름 사이의 NBSP를 없애 버리면 SeoulCenter처럼 두 단어가 붙기 때문입니다.

D2에는 =LEN(A2), E2에는 =LEN(B2), F2에는 =LEN(C2)를 입력해 원본·TRIM·대체 후 길이를 비교합니다. G2의 =EXACT(A2,C2)는 대소문자까지 같은지 확인합니다. 길이가 줄었다는 사실만으로 정리가 올바르다고 판정하지 않습니다.

04 / BOUNDARIES

공백을 줄이면
잘못되는 값도 있습니다

A4의 AB 12는 가운데 공백 두 개가 포함된 합성 ID입니다. TRIM 결과는 AB 12로 바뀌고 EXACT는 FALSE가 됩니다. 원본 시스템이 두 값을 다른 키로 취급한다면 정리가 아니라 손상입니다. 표시용 이름을 고치는 규칙을 계정·상품·주문 ID에 그대로 적용하지 마세요.

A5의 U+202F는 코드 8239인 좁은 NBSP입니다. 160만 대체하는 이 수식으로는 남습니다. 코드 8203의 폭 없는 공백 등 다른 문자도 별개의 문제입니다. 문자를 확인하고 업무 규칙에 맞는 대체를 하나씩 정해야 합니다. 한꺼번에 모든 공백을 지우거나 눈에 보이지 않는다는 이유만으로 삭제하면 의미 있는 구분까지 잃습니다.

CLEAN을 추가하면 모두 해결될 것이라고 가정하지도 않습니다. Microsoft CLEAN 문서 (새 탭)는 처리하는 비인쇄 문자 범위를 별도로 설명합니다. 원본 열을 남겨 두고, 바뀐 행 수와 새로 충돌하는 키를 확인한 다음 결과 열만 사용하세요.

05 / VERIFY

수식이 성공한 것과
내 데이터가 안전한 것은 다릅니다

Windows Excel 16.0 build 5574.0의 별도 빈 통합문서에서 위 입력 수식과 TRIM·SUBSTITUTE·LEN·EXACT·UNICODE를 계산했습니다. NBSP 행은 14→14→12, 좁은 NBSP 행은 7→7→7이었고, 합성 ID는 원본과 달라졌습니다. 이 가이드의 원본 문자열과 결과를 실제 셀 값으로 대조했습니다.

1. 원본과 결과를 함께 보관합니다.새 열에서 정리하고 원본 열을 덮어쓰지 않습니다.
2. 사라진 것이 어떤 문자였는지 확인합니다.NBSP인지 다른 유니코드 문자인지, 정리 후 단어가 붙지 않았는지 봅니다.
3. 조회 키의 충돌을 검사합니다.기존에 다른 ID였던 두 행이 같은 값이 되면 정리 기준부터 다시 결정합니다. 병합 결과 행 수·합계도 비교합니다.

01 / OUTCOME

만든 것과 얻지 못한 것

AI로 이미지를 만들고 필요한 사람에게 판매하면 작은 수입원을 만들 수 있지 않을까. Deep Constellation은 그 생각에서 출발했습니다. 미용실과 뷰티숍을 대상으로 헤어 이미지, 홍보 콘텐츠, 게시물 디자인을 제공하려 했습니다.

사이트와 도메인, 견적과 문의 흐름, 이미지 예시와 홍보 영상을 준비했습니다. 인스타그램, 유튜브, 틱톡에 콘텐츠를 게시하며 실제 운영 단계까지 갔습니다. 하지만 확인된 유료 고객이나 재구매 실적을 확보하지 못했고 수익도 만들지 못했습니다.

2026년 10월 3일, 수익성이 낮다고 판단해 추가 활동을 중단했습니다. 제가 선택한 상품과 방식으로는 지속 가능한 수입원을 검증하지 못했습니다. 정확한 사업 손익과 전체 투입 시간은 측정하지 않았으므로 손실 규모를 임의의 숫자로 제시하지 않습니다.

02 / CUSTOMER PROBLEM

문제보다 수단을 먼저 선택했다

처음에는 고객이 이미 겪고 있는 문제보다 내가 가진 수단을 먼저 봤습니다. AI 도구를 사용할 수 있고 웹사이트를 개발할 수 있으니 이 능력을 상품으로 만들려 했습니다. 하지만 내가 할 수 있는 일과 고객이 돈을 내고 맡기고 싶은 일은 같지 않았습니다.

미용실에 홍보가 필요하다고 해서 모든 미용실이 AI 이미지를 구매해야 하는 것은 아닙니다. 실제 시술 사진이 더 중요하거나 직접 만드는 것으로 충분할 수 있습니다. 콘텐츠보다 예약 응대, 촬영, 재방문 관리가 더 급한 문제일 수도 있습니다. 저는 이미지 제작을 먼저 정답으로 정하고 필요한 고객을 찾는 순서로 움직였습니다.

인스타그램에서 디자이너들이 직접 AI 이미지를 만드는 사례도 접했습니다. 그 관찰만으로 업계 전체의 외주 수요가 사라졌다고 말할 수는 없습니다. 다만 고객도 같은 도구를 쓸 수 있을 때 제가 대신 제작할 이유가 무엇인지 다시 묻게 됐습니다. 결과의 품질, 줄어든 시간, 수정과 검수에서 대신 지는 책임을 실제 납품과 고객의 선택으로 입증해야 했습니다.

03 / FALSE PROGRESS

완성도를 수요의 증거로 착각했다

사이트를 개선하는 일은 명확했습니다. 깨진 이미지와 모바일 화면을 고치고 견적 경로를 정리하면 눈에 보이는 변화가 생겼습니다. 테스트를 통과하고 배포된 페이지를 확인하면 완료 여부를 판단할 수 있었습니다.

고객이 구매할 이유를 검증하는 일은 불확실했습니다. 답장이 없을 수 있고 의견을 들어도 구매로 이어지지 않을 수 있었습니다. 확신이 부족할 때마다 고객 검증을 더 깊게 하기보다 결과가 눈에 보이는 개발과 콘텐츠 제작을 선택하기 쉬웠습니다.

9월 초 분석에는 무료 제작 도구와의 경쟁, 구매 의향의 미확인, 수정 시간과 납품 원가의 미측정이 이미 기록돼 있었습니다. 위험을 몰랐던 것이 아니라 다음 단계로 넘어가기 위한 통과 조건으로 충분히 쓰지 못했습니다. 앞으로는 분석 문서의 양보다 그 분석 때문에 어떤 작업을 하지 않기로 결정했는지를 남기려 합니다.

04 / LIMITED SIGNALS

홍보와 할인은 답이 아니었다

이미지 제작에서 실제 매장 공지와 문구를 정리하는 방향으로 범위를 바꿨습니다. 피드 이미지 한 장과 짧은 게시글 문구를 제공하는 19,000원 상품도 준비했습니다. 진입 부담을 줄이는 실험이었지만 가격을 낮추는 일이 필요성을 만들지는 않았습니다.

9월 30일 점검 기록에서 이전 유튜브 홍보 영상은 조회 95회, 계속 시청 비율 4.1%였습니다. 확인 범위에서 새로운 상담 답장도 보이지 않았습니다. 그래서 가격 설명보다 완성 디자인을 먼저 보여주고 영상을 짧게 만드는 개선을 진행했습니다. 이 수치는 10월 3일에 다시 조회한 최신 지표가 아닙니다.

이 관찰은 영상의 초기 이탈을 개선할 근거는 될 수 있지만 가격이 실패 원인이라거나 시장에 수요가 없다는 결론의 근거는 아닙니다. 표본이 작고 적합한 고객에게 얼마나 도달했는지, 방문이 상담으로 얼마나 이어졌는지도 충분히 확인하지 못했습니다.

피드를 잘 운영하는 디자이너는 콘텐츠의 중요성을 알지만 직접 제작할 능력과 체계를 갖춘 사람일 수도 있었습니다. 보기 좋은 잠재 고객 목록과 구매 가능성이 높은 목록은 같지 않았습니다. “우리 이미지를 좋아할까?”보다 “지금 어떤 작업을 어떻게 처리하고, 무엇이 불편한가?”라는 질문이 필요했습니다.

05 / AI COLLABORATION

AI와 협업할 때의 맹점

AI 코딩 에이전트와 개발, 문서화, 이미지 제작, 영상 구성, 홍보 문구를 함께 작업했습니다. 혼자였다면 오래 걸렸을 일을 빠르게 진행할 수 있었습니다. 그 속도는 장점이었지만 잘못된 가정 위에서도 빠르게 움직일 수 있다는 점은 충분히 경계하지 못했습니다.

“다음에 무엇을 만들면 좋을까?”라고 물으면 다음 기능과 콘텐츠를 제안받을 수 있었습니다. 실행할 일이 계속 생기면 앞으로 나아가는 느낌을 받기 쉽습니다. 그러나 할 일이 있다는 사실은 고객이 있다는 사실이 아니었습니다. AI의 긍정적인 평가와 설득력 있는 사업 설명도 고객의 결제를 대신할 수 없습니다.

다음에는 현재 결론에 불리한 근거, 검증되지 않은 가정, 기능을 추가하지 않아도 되는 대안, 중단을 고려할 조건도 함께 묻겠습니다. 제안받은 작업도 고객 학습에 기여하지 않는다면 보류할 수 있어야 합니다.

06 / A DIFFERENT ORDER

다음에는 순서를 바꾸겠다

1. 최근의 반복 문제부터 듣기“있으면 쓰겠어요?” 대신 최근 한 달에 몇 번 했고 어떻게 해결했으며 시간이나 외주 비용이 얼마나 들었는지 묻겠습니다. 현재 쓰는 대안을 먼저 확인합니다.
2. 개발 대신 작은 거래부터 시도하기고객이 이미 가진 자료로 좁은 결과물을 만들고 범위·비용·일정·수정 조건을 먼저 합의합니다. 이행할 수 없는 약속으로 결제만 받아 검증하지 않습니다.
3. 첫 구매와 반복 가능성을 구분하기검수 통과, 감당할 수 있는 총 작업 시간, 다시 맡길 필요를 확인하기 전에는 월 구독이나 자동화 플랫폼부터 만들지 않습니다.
4. 상담부터 전달까지 원가 기록하기생성뿐 아니라 자료 확인, 선별, 수정, 파일 정리와 전달을 합칩니다. 공통 홍보 시간과 도구 비용은 따로 기록해 주문 효율과 사업 전체 수익성을 구분합니다.
5. 확장 전에 예산과 중단 기준 정하기예를 들어 2주·총 10시간 이내로 첫 검증을 제한할 수 있습니다. 반복 문제, 현재 대안의 불편, 자료 제공이나 좁은 유료 작업처럼 행동으로 드러난 관심이 확인되지 않으면 확장하지 않습니다.

구매 의사결정자 3명에게 짧게 최근 경험을 듣는 것부터 시작할 수 있습니다. 인원과 기간은 시장 평균이나 통계적 검증선이 아니라 검증을 기능 개발로 대체하지 않기 위한 개인적인 시작 규칙입니다. 대화를 거의 하지 못했다면 “수요가 없다”가 아니라 “아직 검증하지 못했다”고 기록하겠습니다.

상업적 사용 범위와 자료 권한, 재현 가능한 품질도 카탈로그에 올리기 전에 확인하겠습니다. 이미 구독 중인 도구를 쓴다고 실제 비용을 0원으로 놓지 않고 상담·수정까지 측정할 방법을 먼저 정하겠습니다.

07 / KEEP AND STOP

남길 것과 멈출 것

배포와 로컬 환경의 차이, 공개 파일과 내부 도구의 경계, 이미지 무결성 검사, 수정 가능한 디자인 원본, 영상 생성과 공개 완료의 상태 구분은 개발 경험으로 남습니다. 사이트와 제작 도구, 문서와 홍보물도 포트폴리오로 보존합니다.

하지만 이미지 생성 능력만을 앞세워 확장하지 않겠습니다. 구체적인 고객 요구가 확인되지 않은 상태에서 제작량과 기능 수를 늘리는 추가 활동은 멈춥니다. 많이 만들었다는 이유만으로 다음 시간까지 투입하지 않으려 합니다.

TAKE IT WITH YOU

시작 전에 물을 다섯 가지

1. 누구의 어떤 반복 문제인가?최근 실제 사례를 설명할 수 있는가.
2. 지금은 어떻게 해결하는가?왜 기존 방법을 바꾸려 하는가.
3. 기능 없이 확인할 행동은 무엇인가?호의적인 답변과 실제 행동을 구분할 수 있는가.
4. 제공 범위와 원가는 확인했는가?권한을 확인했고 상담·수정까지 측정할 방법이 있는가.
5. 언제 확장하지 않거나 멈출 것인가?시간을 쓰기 전에 중단 기준을 정했는가.

01 / CAUSE

쉼표 파일이라고
추측하지 않습니다

CSV라는 이름은 흔히 쉼표로 구분된 파일을 뜻하지만, 실제 업무 시스템은 지역 설정이나 내보내기 규칙 때문에 세미콜론이나 탭을 사용할 수 있습니다. Excel이 예상한 구분자와 파일의 실제 구분자가 다르면 한 줄 전체가 셀 하나에 들어갑니다. 이때 확장자를 바꾸거나 모든 문장 부호를 일괄 치환하면 데이터 내용까지 바뀔 수 있습니다.

특히 설명 필드 안의 쉼표는 구분자가 아닐 수 있습니다. 따옴표로 감싼 "Mug, blue"의 쉼표는 제품 설명의 일부입니다. 어떤 기호가 자주 보인다는 이유만으로 구분자로 선택하면 열이 과도하게 늘어납니다.

02 / INSPECT

작은 합성 예제로
경계를 먼저 봅니다

복사본을 메모장 같은 일반 텍스트 편집기로 열고 헤더와 두세 줄을 확인합니다. 다음 예제는 세미콜론으로 나뉜 세 열을 만듭니다.

sku;description;price
00123;"Mug, blue";12.50
00456;"Plate; small";8.00

헤더에서 sku, description, price 사이를 나누는 기호는 세미콜론입니다. 첫 설명의 쉼표와 둘째 설명의 세미콜론은 각각 값 안의 문장 부호입니다. 둘째 설명은 따옴표 안에 있으므로 세미콜론 구분자를 써도 하나의 필드로 남아야 합니다.

03 / IMPORT

가장 안전한 경로는
원본을 다시 가져오는 것입니다

1. 새 통합문서에서 Data → From Text/CSV를 엽니다.실패한 시도가 정리한 표를 덮어쓰지 않도록 새 시트나 새 파일을 사용합니다.
2. 미리보기에서 Delimiter를 Semicolon으로 지정합니다.세 열이 보이고 Plate; small이 하나의 설명에 남는지 확인합니다.
3. 데이터 변환(Transform Data)을 눌러 편집기를 엽니다. 미리보기에서 바로 로드하지 않습니다. Power Query 편집기가 열리면 오른쪽 적용된 단계(Applied Steps)를 확인합니다. 메뉴 이름은 설치 언어와 Excel 버전에 따라 다를 수 있습니다.
4. sku 열은 Text로 지정합니다.자동 변경된 유형(Changed Type) 단계가 sku를 숫자로 바꿨다면 먼저 그 단계를 삭제합니다. 원본의 00123이 다시 보이는지 확인한 뒤 sku 열의 데이터 형식을 텍스트(Text)로 지정합니다. 이미 숫자가 된 123을 Text로 바꾸기만 해서는 앞자리 0이 돌아오지 않습니다.
5. price만 숫자로 변환하고 Close & Load를 선택합니다.숫자 표시가 12.5로 보여도 값 12.50과 수치상 같을 수 있으므로 서식과 값 변환을 구분합니다.

04 / ALTERNATIVE

Text to Columns는
레코드가 온전할 때만

각 A열 셀에 한 레코드가 완전히 남아 있다면 Data → Text to Columns → Delimited 경로를 사용할 수 있습니다. 원본 열을 복사하고 빈 출력 위치를 정한 뒤, 세미콜론과 double quote 텍스트 한정자를 선택합니다. 마지막 단계에서 sku 열을 Text로 지정합니다.

따옴표 안에 줄바꿈이 있어 이미 여러 worksheet 행으로 갈라졌거나, 식별자의 앞자리 0이 사라졌거나, 날짜가 이미 변환됐다면 이 경로로 원래 값을 복원할 수 없습니다. 그때는 수정하지 않은 원본 파일로 돌아가 From Text/CSV를 사용해야 합니다.

05 / VERIFY

열이 생긴 것만으로
성공이라 하지 않습니다

예상 결과는 데이터 레코드 2개, 열 3개, sku 00123과 00456, 설명 Mug, blue와 Plate; small, 가격 합계 20.50입니다. 합계만 맞아도 설명이나 ID가 손상될 수 있으므로 각 항목을 대조합니다.

실제 파일이 크다면 첫 줄과 마지막 줄, 따옴표·문장 부호·빈 필드가 있는 레코드를 표본으로 확인합니다. 원본을 함께 보관하면 다음 새로고침에서 가져오기 설정이 달라졌는지 비교할 수 있습니다.

06 / OBSERVED RESULT

같은 파일, 다른 자료형으로
직접 가져와 비교했습니다

2026년 10월 5일, Windows Excel 16.0 build 5569.0에서 위의 세미콜론 CSV를 실제 Excel QueryTables 텍스트 가져오기 엔진으로 읽었습니다. UTF-8, 세미콜론 구분자, 큰따옴표 한정자, 소수점 .을 명시하고 첫 열만 General과 Text로 바꿔 비교했습니다.

넓은 표는 좌우로 스크롤할 수 있습니다. 키보드는 Tab으로 표 영역에 이동한 뒤 좌우 방향키를 누르세요.

두 설정 모두 세 열과 가격은 맞았습니다. 그러나 General에서는 상품 코드가 달라졌습니다. “열이 나뉘었고 합계가 맞으니 성공”으로 끝내지 않고, 식별자까지 확인해야 하는 이유입니다.

내 파일에서 확인할 수식

위 샘플이 A1:C3에 들어왔다면 빈 셀에서 다음 세 수식을 각각 실행하세요. Text로 보존된 첫 번째 코드는 TRUE, 5, TRUE가 나와야 합니다. General로 변환된 값은 보존된 원본에서 다시 가져옵니다.

=ISTEXT(A2)
=LEN(A2)
=EXACT(A2,"00123")

Microsoft: 텍스트 가져오기 열 자료형 ↗ · 표시 서식만 바꾼 대조 실험 보기 →

01 / MEANING

수식의 문법과
출력 공간은 별개입니다

FILTER, SORT, UNIQUE 같은 동적 배열 수식은 결과 크기에 맞춰 아래와 옆 셀로 펼쳐집니다. 결과가 3행 3열이면 수식을 입력한 셀을 포함해 9개의 셀이 필요합니다. 그중 하나라도 비어 있지 않으면 수식 셀에는 #SPILL이 표시될 수 있습니다.

다만 #SPILL의 원인이 항상 막힌 셀은 아닙니다. 결과가 워크시트 끝을 넘어가거나, 크기를 결정할 수 없는 수식이거나, Excel Table 안에서 동적 배열을 입력한 경우도 있습니다. 경고 메뉴의 설명을 먼저 읽고 원인에 맞는 조치를 선택합니다.

02 / DIAGNOSE

보이지 않는 빈칸도
수식 입력줄에서 확인합니다

수식 셀을 선택하고 경고 아이콘을 엽니다. 막힌 범위 문제라면 Excel 버전에 따라 Select Obstructing Cells를 제공할 수 있습니다. 해당 명령으로 선택된 셀을 Formula Bar에서 확인합니다. 화면상 비어 보여도 공백 한 칸이나 =""을 반환하는 수식이 있을 수 있습니다.

메모나 기존 수식을 안전한 위치로 옮기거나 FILTER 수식을 충분히 빈 영역으로 옮깁니다. 주변 영역 전체를 선택해 Delete를 누르면 보이지 않던 업무 규칙이나 기록까지 지울 수 있으므로 피합니다. 오류 상세가 다른 원인을 말한다면 막힌 셀 찾기를 억지로 적용하지 않습니다.

03 / REPRODUCE

5행 예제로
막힘과 정상 결과를 비교합니다

빈 시트 A1:C6에 헤더 record_id, region, hours와 다음 다섯 행을 입력합니다.

record_id	region	hours
R1	North	2
R2	South	5
R3	North	0
R4	North	4
R5	West	3

K2에 North를 입력하고 F1:H1에 헤더 세 개를 복사합니다. F2 한 셀에만 =FILTER(A2:C6,B2:B6=K2,"No matches")를 입력합니다. 설치 환경에 따라 인수 구분자는 쉼표 대신 세미콜론일 수 있습니다.

정상 결과는 F2:H4의 R1, R3, R4이며 hours는 2, 0, 4입니다. 합계는 6이고 0시간 레코드도 남아야 합니다. 오류를 재현하려면 수식 입력 전에 G3에 note를 넣습니다. FILTER 입력 후 G3의 note를 F2:H4 밖으로 이동하면 세 행이 펼쳐져야 합니다.

04 / STRUCTURE

원본은 Table이어도 되지만
출력 수식은 일반 범위에 둡니다

FILTER의 source가 Excel Table인 것은 유용합니다. 원본 행이 늘 때 구조화 참조가 확장됩니다. 그러나 spill 수식 자체를 Table 계산 열 안에 넣으면 결과가 여러 행으로 펼쳐질 수 없습니다. Table 옆의 일반 worksheet 범위에 수식을 두고 결과가 커질 공간을 확보합니다.

결과 영역에 병합 셀이 있으면 다른 빈 영역을 쓰는 것이 가장 안전합니다. 병합을 해제해야 한다면 병합 셀의 내용과 레이아웃 목적을 먼저 검토합니다. 열 전체 참조 때문에 결과가 시트 끝을 넘는 경우에는 실제 데이터 범위나 Table 열 참조로 범위를 제한합니다.

05 / VERIFY

오류가 사라진 뒤에도
선택 조건을 확인합니다

spill 공간을 비웠다고 FILTER 조건이 맞아지는 것은 아닙니다. 예제에서는 레코드 ID R1·R3·R4, region North, hours 합계 6을 대조합니다. 0을 빈 값으로 오해해 R3을 제외하지 않았는지도 확인합니다. 세 번째 인수 "No matches"는 일치 결과가 없을 때 표시할 문구이며, 막힌 공간을 해결하지는 않습니다.

다른 원인도 Microsoft의 #SPILL 오류 문서에서 확인할 수 있습니다. 이 글에서는 합성 예제(fixture)로 레코드 선택 논리를 검사했습니다. 모든 Excel 버전의 실제 UI를 실행해 검증한 것은 아닙니다.

01 / MEANING

모양이 숫자여도
의미는 숫자가 아닐 수 있습니다

00123과 123은 계산에서는 같은 수지만 상품 코드 체계에서는 다른 문자열일 수 있습니다. 앞자리 0은 길이 규칙이나 지역·분류를 나타낼 수도 있습니다. 이 열을 합산할 필요가 없다면 숫자로 자동 변환하는 이점보다 식별 정보 손실 위험이 큽니다.

먼저 데이터 사전을 확인합니다. 코드의 길이가 고정인지, 빈 값이 가능한지, 문자와 하이픈이 섞일 수 있는지 기록합니다. 이 기준이 있어야 123을 00123으로 만들 때 0을 두 개 붙이는 것이 맞는지 판단할 수 있습니다.

02 / DAMAGE

이미 123이 됐다면
서식은 원본을 기억하지 못합니다

Excel에서 사용자 지정 형식 00000을 적용하면 화면에는 00123처럼 보일 수 있습니다. 하지만 셀의 실제 값은 여전히 숫자 123입니다. 길이가 모두 5자리라는 명확한 계약이 있을 때 표시용으로는 쓸 수 있지만, 원본이 0123인지 00123인지 알 수 없는 상황을 복구하지는 못합니다.

일반 더블클릭으로 CSV를 연 뒤 값이 변한 경우에는 파일을 저장하지 말고 닫은 다음 수정하지 않은 원본으로 돌아가는 것이 안전합니다. 저장해 버렸다면 버전 기록이나 원본 내보내기를 다시 확보합니다.

03 / IMPORT

From Text/CSV에서
변환 전에 Text로 지정합니다

1. 새 통합문서에서 Data → From Text/CSV를 선택합니다.원본 CSV를 직접 더블클릭하지 않습니다.
2. 구분자와 인코딩을 미리보기에서 확인합니다.열이 어긋난 상태에서 자료형만 바꾸면 잘못된 필드를 보존하게 됩니다.
3. Transform Data를 열고 식별자 열을 Text로 지정합니다.자동 Changed Type 단계가 00123을 123으로 만든 뒤라면 그 단계를 제거하고 처음부터 다시 지정합니다.
4. Close & Load 후 수식 입력줄에서 실제 값을 확인합니다.셀 폭이나 표시 형식에 의존하지 않고 00123 자체가 남았는지 봅니다.

item_id,quantity
00123,2
00007,1
A-004,3

BROWSER ALTERNATIVE

설치 없이 보존용
XLSX 사본을 만들 수도 있습니다

CSV를 먼저 Excel로 여는 대신 Column Harbor의 CSV→Excel 도구 (영문, 새 탭)로 텍스트 셀로 된 XLSX를 만들 수 있습니다. 가입이나 파일 업로드 없이 브라우저에서 처리합니다. 원본 CSV는 덮어쓰지 않습니다.

1. 바로 위 CSV 예제를 붙여넣습니다.CSV to convert 입력란에 헤더와 세 행을 넣고 구분자는 Comma로 둡니다. 원본 파일을 쓸 때도 식별자가 이미 손상되지 않았는지 먼저 확인하세요.
2. Create Excel workbook을 누르고 미리보기를 대조합니다.데이터 3행, 열 2개인지 확인합니다. item_id는 00123, 00007, A-004이며 quantity는 2, 1, 3이어야 합니다.
3. Download XLSX로 사본을 내려받습니다.Data 시트의 A2에서 =ISTEXT(A2), =LEN(A2), =EXACT(A2,"00123")을 빈 셀에 각각 입력해 TRUE, 5, TRUE인지 확인합니다. 파일 생성 성공과 내 Excel 환경에서의 결과 확인은 별개입니다.

04 / EXPORT

XLSX와 CSV의
보존 범위가 다릅니다

XLSX는 셀의 자료형과 표시 서식을 함께 저장하지만 CSV는 텍스트 값만 저장합니다. Excel 안에서 Text였던 00123을 올바르게 CSV로 내보내면 문자 0이 파일에 남습니다. 그러나 그 CSV를 다시 더블클릭하면 Excel이 또 숫자로 추론할 수 있습니다.

따라서 저장 성공 여부는 Excel 화면만으로 확인하지 않습니다. 내보낸 CSV 복사본을 텍스트 편집기로 열어 00123이 실제로 쓰였는지 확인하고, 다시 가져올 때도 Text 규칙을 적용합니다. CSV를 전달할 때는 식별자 열이라는 설명이나 가져오기 규칙을 함께 전달하는 편이 안전합니다.

05 / VERIFY

길이와 정확한 값,
왕복 저장을 확인합니다

표본 ID의 문자 길이, 원본과의 정확 일치, 빈 값 개수, 중복 개수를 확인합니다. 아주 긴 숫자형 ID라면 Excel의 15자리 정밀도 한계도 별도 문제이므로 반드시 Text로 다룹니다. 이미 16자리 뒤가 0으로 바뀐 값은 표시 형식으로 복구할 수 없습니다.

화면에 0이 보이더라도 파일과 셀의 실제 값에 0이 남아 있는지 확인하세요. 이렇게 대조하면 가져오기와 내보내기 중 어느 단계에서 값이 달라졌는지 구분할 수 있습니다.

06 / OBSERVED RESULT

같은 00123으로 보여도
셀 안의 값은 달랐습니다

2026년 10월 5일, Excel 16.0 build 5569.0에서 상품 코드가 들어 있는 합성 CSV를 QueryTables 텍스트 가져오기로 읽었습니다. General로 변환한 셀과 Text로 보존한 셀을 비교한 뒤, 숫자 셀에만 사용자 지정 표시 형식 00000을 적용했습니다.

넓은 표는 좌우로 스크롤할 수 있습니다. 키보드는 Tab으로 표 영역에 이동한 뒤 좌우 방향키를 누르세요.

두 번째 셀의 표시 문자열은 00123이었지만, 실제 값은 여전히 숫자 123이었습니다. 다섯 자리가 업무 규칙으로 확정된 표시용 코드라면 이 서식이 유용할 수 있습니다. 다만 원래 값이 123, 0123, 00123 중 무엇이었는지를 복구했다는 증거는 아닙니다.

따라 해 볼 때의 완료 기준

1. 새 파일 두 개에 동일한 원본을 가져옵니다.한쪽은 식별자 열을 General, 다른 쪽은 Text로 지정합니다. 원본은 덮어쓰지 않습니다.
2. General 쪽에만 00000 표시 서식을 줍니다.화면이 비슷해져도 수식 입력줄과 =ISTEXT(A2) 결과를 비교합니다. Text 쪽은 TRUE, 숫자 쪽은 FALSE여야 합니다.
3. 정확한 문자열과 길이를 대조합니다.=LEN(A2)와 =EXACT(A2,"00123")를 함께 봅니다. 표시 형식이 아니라 원본 식별자 보존이 목표입니다.

같은 입력의 구분자·자료형 검증 전체 보기 →

01 / WHY

병합은 한 건만
골라 주지 않습니다

판매 테이블에 고객 C10의 판매가 두 건 있고 주소 테이블에 C10의 유효한 주소가 두 건 있다면, 고객 ID로 병합한 뒤 주소를 펼칠 때 각 판매가 주소 두 건과 결합됩니다. 판매 두 행이 네 행으로 늘어나는 것은 병합 엔진이 중복을 만든 것이 아니라 요청한 키로 가능한 모든 조합을 보여준 것입니다.

합성 예제에서 판매는 네 건이고 금액 합계는 42입니다. 주소 매치 수가 판매 순서대로 2, 2, 1, 0이라면 펼친 결과는 여섯 행이 됩니다. 반복된 판매 금액을 다시 더하면 72로 보입니다. 이때 72는 새 매출이 아니라 주소를 펼치면서 같은 판매가 반복된 결과입니다.

1. 두 CSV를 각각 Power Query로 가져옵니다.Excel의 Data → From Text/CSV에서 파일별로 Transform Data를 열고 customer_id를 두 쿼리에서 같은 Text 자료형으로 확인합니다.
2. Sales를 왼쪽, Addresses를 오른쪽에 놓고 병합합니다.Home → Merge Queries에서 양쪽 customer_id를 선택하고 Join Kind는 Left Outer를 사용합니다.
3. 먼저 매치 수를 기록한 다음 Addresses를 펼칩니다.펼칠 때 address_id만 선택해 판매 ID별 행 수를 비교합니다. 일치하지 않는 C30 판매는 null 주소를 가진 채 남습니다.

02 / AUDIT

중첩 테이블 상태에서
매치 수를 확인합니다

병합 직후에는 오른쪽 결과가 중첩 테이블 열에 들어 있습니다. 주소 열 이름이 Addresses라면 Custom Column에 Table.RowCount([Addresses])를 추가해 각 왼쪽 행의 매치 수를 셉니다. 0은 미일치, 1은 단일 일치, 2 이상은 다중 일치입니다.

원래 판매 ID와 매치 수를 함께 남겨 두면 어떤 행이 늘어날지 펼치기 전에 알 수 있습니다. 진단용으로 Keep Duplicates를 사용한다면 원본 조회의 별도 Reference나 복사본에서만 사용합니다. Keep Duplicates 결과에는 유일한 키가 남지 않습니다. 이 결과를 실제 업무의 병합에 쓰는 lookup으로 돌려 쓰면 정상 고객이 사라집니다.

03 / DECISION

원하는 출력의
행 의미를 결정합니다

모든 주소를 보고 싶은 보고서라면 one-to-many 관계를 유지하고 판매 금액을 주소별 새 매출처럼 합산하지 않습니다. 주소 존재 여부만 필요하다면 중첩 테이블을 펼치지 않고 매치 수가 0보다 큰지 계산할 수 있습니다.

판매당 주소 하나가 필요하다면 선택 규칙이 있어야 합니다. 판매 레코드가 address_id를 갖고 있다면 고객 ID 대신 그 키로 연결하는 것이 가장 명확합니다. “현재 주소”를 선택한다면 고객마다 current=true가 정확히 하나인지, 동률과 누락을 어떻게 처리할지 먼저 정의합니다.

판매 시점에 선택한 주소 ID가 기록돼 있다면 그 값을 사용할 수 있습니다. 다음 파일은 설명을 위해 주소 ID를 함께 넣은 별도 합성 데이터입니다. 실제 데이터에 주소 ID가 없다면 임의로 이 값을 채우지 말고, 담당자와 주소 선택 규칙부터 정하세요.

주소 ID가 포함된 판매 CSV 내려받기

1. 새 판매 파일과 기존 주소 파일을 가져옵니다.두 쿼리의 address_id 열을 Text로 맞춥니다. 주소 쿼리에서 address_id가 중복되거나 비어 있는지 먼저 확인합니다.
2. customer_id와 address_id 두 열로 Left Outer 병합합니다.양쪽에서 Ctrl 키를 누른 채 customer_id, address_id 순서로 선택합니다. 고객과 주소가 모두 같은 행만 연결해 다른 고객의 주소 연결도 피합니다.
3. city를 펼치고 원본 판매 ID와 금액을 대조합니다.S1부터 S4까지 한 행씩, 합계 42가 남아야 합니다. 주소가 없는 S4는 null이며 판매 자체는 유지합니다.

04 / CAUTION

정렬 후 Remove Duplicates가
최신 행을 보장한다고 가정하지 않습니다

Power Query의 Table.Distinct는 중복 레코드 중 어느 행이 보존될지 일반적으로 보장하지 않습니다. 단순히 날짜 내림차순 정렬 후 고객 ID 중복을 제거해 최신 주소가 남을 것이라고 믿으면 새로고침이나 쿼리 최적화에서 다른 결과가 생길 수 있습니다.

최신 레코드가 필요하다면 고객별 최대 날짜를 구한 뒤 원본과 다시 매치하고, 같은 최대 날짜가 여러 건인 상황에 tie-break 규칙을 둡니다. 주소 두 개가 모두 실제로 유효하다면 하나를 삭제하지 말고 보고서의 목적에 맞춰 관계를 보존합니다.

05 / VERIFY

판매 4건·합계 42를
여러 각도에서 대조합니다

원본 판매 ID 네 개가 모두 남았는지, 매치 수가 2·2·1·0인지, 펼친 결과가 여섯 행인지 확인합니다. 한 주소 선택 규칙을 적용했다면 선택된 주소 값과 미일치 고객의 null 처리도 봅니다. 마지막으로 보고서가 판매 단위라면 합계가 42인지 대조합니다.

왼쪽 판매 행 단위의 금액 합계는 42입니다. 펼친 표의 amount를 단순 합산하면 C10의 판매 10과 20이 두 번씩 포함되어 72가 됩니다. 주소를 하나로 줄여야 한다면 먼저 어떤 주소를 남길지 정하고, 그 규칙을 적용한 결과를 원본 판매 ID와 대조하세요.

아래 실습에서는 같은 합성 데이터를 쿼리 안에 넣어 실제 Excel 엔진에서 확인했습니다. 외부 파일이나 DB를 연결할 때의 folding, privacy level, connector 동작까지 검증한 것은 아닙니다.

06 / RUN THE EXPERIMENT

파일 없이 실행하고,
병합 키 하나의 차이를 확인하세요

실무 파일의 경로나 고객 정보를 바꾸기 전에 작은 데이터로 원리를 확인할 수 있습니다. 아래 쿼리에는 판매 네 건과 주소 세 건이 모두 들어 있습니다. 앞의 CSV를 읽지 않는 독립 실습이며, 주소 ID가 포함된 판매 예제를 기준으로 합니다. 로그인이나 외부 서비스 연결은 필요하지 않습니다.

1. 새 통합 문서에서 빈 쿼리를 만듭니다.Windows Excel의 데이터 → 데이터 가져오기 → 기타 원본에서 → 빈 쿼리로 들어갑니다. Power Query 편집기의 홈 → 고급 편집기에서 기존 내용을 지우고 아래 전체 코드를 넣습니다. 메뉴 이름은 Excel 버전과 언어에 따라 다를 수 있습니다.
2. 먼저 audit 모드로 미리 보기를 확인합니다.Mode = "audit"를 유지합니다. sale_id 순서대로 match_count가 2, 2, 1, 0이면 고객 ID만으로 연결할 때 어떤 판매가 반복될지 확인한 것입니다.
3. 첫 번째 Mode 대입문만 바꿔 비교합니다.Mode = "expanded"로 바꾸면 잘못된 금액 합계를, Mode = "corrected"로 바꾸면 고객 ID와 주소 ID를 함께 쓰는 결과를 봅니다. 아래 조건식의 문자열까지 일괄 치환하지 마세요. 닫기 및 로드로 표를 시트에 놓아 amount를 합산해도 됩니다.

전체 M 쿼리 내려받기 (.pq)

// Synthetic learning data only. Change Mode to audit, expanded, or corrected.
let
    Mode = "audit",
    Sales = #table(
        type table [sale_id=text, customer_id=text, address_id=nullable text, amount=number],
        {{"S1","C10","A1",10}, {"S2","C10","A2",20},
         {"S3","C20","A3",5}, {"S4","C30",null,7}}
    ),
    Addresses = #table(
        type table [address_id=text, customer_id=text, city=text],
        {{"A1","C10","Seoul"}, {"A2","C10","Busan"}, {"A3","C20","Incheon"}}
    ),
    ByCustomer = Table.NestedJoin(Sales, {"customer_id"}, Addresses, {"customer_id"}, "matches", JoinKind.LeftOuter),
    Audit = Table.AddColumn(ByCustomer, "match_count", each Table.RowCount([matches]), Int64.Type),
    Expanded = Table.ExpandTableColumn(Audit, "matches", {"city"}, {"city"}),
    KeyCounts = Table.Group(Addresses, {"customer_id", "address_id"}, {{"count", each Table.RowCount(_), Int64.Type}}),
    BadKeys = Table.SelectRows(KeyCounts, each [count] <> 1 or [customer_id] = "" or [address_id] = ""),
    CheckedAddresses = if Table.RowCount(BadKeys) > 0 then error "Address lookup keys must be nonempty and unique" else Addresses,
    ByAddress = Table.NestedJoin(Sales, {"customer_id", "address_id"}, CheckedAddresses, {"customer_id", "address_id"}, "matches", JoinKind.LeftOuter),
    Corrected = Table.ExpandTableColumn(ByAddress, "matches", {"city"}, {"city"}),
    Selected = if Mode = "audit" then Table.RemoveColumns(Audit, {"matches"})
        else if Mode = "expanded" then Expanded
        else if Mode = "corrected" then Corrected
        else error "Mode must be audit, expanded, or corrected",
    Result = Table.Sort(Selected, {{"sale_id", Order.Ascending}})
in
    Result

왜 corrected는 결과를 임의로 한 건씩 지우지 않을까요? 판매가 가리키는 주소 ID와 고객 ID를 함께 비교하므로 S1은 A1, S2는 A2와 연결됩니다. S4는 주소가 없지만 Left Outer 덕분에 판매 금액 7이 남습니다. 중복 삭제로 합계만 맞추는 것과 달리 어떤 주소를 선택했는지도 설명할 수 있습니다.

잘못된 조회 테이블도 넣어 보세요. Addresses의 첫 번째 행 바로 뒤에 {"A1","C10","Duplicate"},를 추가하고 corrected 모드를 실행합니다. 같은 고객·주소 키가 두 건이므로 Address lookup keys must be nonempty and unique 오류로 멈춥니다. audit와 expanded는 문제를 관찰하는 모드여서 이 검사를 적용하지 않습니다. 실무에서는 오류를 숨기기보다 원본 주소의 중복 사유와 담당자를 확인해야 합니다.

미리 보기가 예상과 다르면 첫 줄의 Mode, 입력 행, 마지막 in Result를 먼저 비교하세요. 주소 순서는 보장하지 않으므로 expanded의 같은 판매 안에서 Seoul과 Busan의 표시 순서가 다른 것은 오류가 아닙니다. 반대로 corrected에서 S4가 없어지거나 합계가 달라졌다면 조인 종류와 원본 입력부터 다시 확인해야 합니다.

함수 동작의 기준은 Microsoft의 Table.NestedJoin과 Table.ExpandTableColumn 문서입니다. 이 실험은 해당 동작을 작은 판매 데이터로 재현한 것으로, 모든 보고서에서 행 수를 줄여야 한다는 규칙은 아닙니다.

01 / DEVELOPMENT NOTES

더 구체적인 문장이 더 나쁜 답변일 수 있었습니다

면접 답변 진단에서 AI가 해야 할 일은 지원자의 경험을 더 잘 설명하도록 돕는 것입니다. 그런데 짧은 답변을 긴 성공담으로 바꾸다 보면 지원자가 말하지 않은 성과까지 채워 넣기 쉽습니다. 개발 기록에서는 짧은 원문의 과도한 확장과, QA 초안에 원문 밖 측정 시간·구현 세부사항이 추가된 사례를 확인했습니다.

수치와 기술 이름이 들어가면 글은 전문적으로 보입니다. 하지만 면접관이 “어떻게 측정했나요?”라고 물었을 때 본인의 경험으로 설명할 수 없다면 개선이 아닙니다. 이 제품에서는 문장의 화려함보다 사용자가 책임지고 말할 수 있는 범위를 먼저 두기로 했습니다.

02 / DEVELOPMENT NOTES

필드가 존재하는 것과 사실인 것은 다릅니다

점수, 요약, 약점, 개선 초안, 꼬리질문은 앱이 일정한 형태로 읽을 수 있어야 합니다. JSON Schema 기반 구조화 출력과 앱의 범위 검사는 그 계약을 위한 것이었습니다. 그러나 형태를 통과한 문자열에도 원문 밖 주장이 들어갈 수 있습니다.

그래서 “처리할 수 있는 형식인가”와 “원문보다 더 큰 주장을 만드는가”를 별도의 질문으로 나눴습니다. 프롬프트에는 확인한 사실과 보완 제안을 구분하도록 넣고 출력 뒤에는 숫자·단위와 선정한 주요 기술 표현을 비교하는 보호 로직을 두었습니다.

1. 원문과 초안을 비교합니다숫자·단위·일부 기술 표현을 정규화해 원문 밖 추가 신호를 살핍니다.
2. 의심되면 더 보수적으로 돌려줍니다검증되지 않은 구체성을 그대로 주는 대신, 원문과 실제 경험으로 보완하라는 안내를 제공합니다.
3. 한계를 남깁니다의미 전체를 이해하는 사실 확인기가 아닙니다. 목록 밖 주장과 같은 숫자의 다른 의미는 놓칠 수 있고 안전한 설명을 막을 수도 있습니다.

EXAMPLE / NUMBER TOKENS

작은 검사로 확인할 수 있는 것

아래 JavaScript는 원문에 없던 숫자 표기를 찾는 학습용 축약 예시입니다. 서비스의 실제 보호 함수 전체를 옮긴 코드는 아닙니다. 브라우저 개발자 도구나 Node.js에서 합성 문장으로 확인할 수 있습니다.

function findAddedNumbers(source, draft) {
  const numbers = (text) => new Set(
    text.normalize("NFKC").match(/\d+(?:[.,]\d+)?%?/g) ?? []
  );
  const known = numbers(source);
  return [...numbers(draft)].filter((value) => !known.has(value));
}

findAddedNumbers("조회 쿼리를 수정했습니다.", "응답 시간을 40% 줄였습니다.");
// ["40%"]

빈 배열은 이 함수가 새 숫자 표기를 찾지 못했다는 뜻입니다. 같은 숫자를 다른 의미로 쓰거나, 기술 이름만 추가하거나, 수치를 한글로 풀어 쓰는 경우는 잡지 못합니다. 탐지 결과가 비어 있어도 사실 확인을 통과했다고 처리하지 마세요. 단위·기술 표현 비교와 사람의 원문 대조가 따로 필요합니다.

03 / DEVELOPMENT NOTES

화면은 안전한데 복사는 원본이면 안 됩니다

새 생성 경로만 바꾸면 예전에 저장한 결과는 예전 방식으로 읽힙니다. 화면에 보이는 초안을 보수적으로 바꿨어도 복사 버튼이 가공 전 값을 가져가면 사용자가 실제로 가져가는 문장은 달라집니다.

같은 보호 함수를 새 평가의 후처리, 저장된 결과의 표시, 결과 복사에 적용했습니다. 과거 데이터를 모두 다시 생성하거나 삭제한 것은 아닙니다. 사용자에게 전달하는 세 경로의 기준을 맞췄습니다.

회귀 검사에는 빈 초안, 원문 밖 숫자, 단위 표기, 기술 동의어, 이미 보호된 문구를 넣었습니다. 평가 함수가 실제로 이 경로를 거치는지도 확인했습니다. 보호를 위해 AI를 한 번 더 호출하는 방식은 쓰지 않았습니다.

04 / DEVELOPMENT NOTES

통과한 테스트 수로 답변 품질을 말하지 않기

이 검사는 정해진 사례에서 보호 정책이 유지되는지 확인합니다. 모든 문장에서 환각이 사라졌다는 뜻은 아닙니다. 스키마 검사와 휴리스틱만으로 사용자 경험의 진위를 판정할 수도 없습니다.

결과 출처도 구분했습니다. 규칙 기반 대체 결과가 표시됐다는 사실을 기대한 AI 평가의 성공으로 세지 않았습니다. 유효한 본 평가 뒤의 추가 다듬기만 실패한 경우와, 평가 자체가 실패한 경우 역시 같은 상태로 묶지 않았습니다.

다음으로 사실 추가·누락·과장·구체성을 나눠 보는 사람의 평가와 오탐·미탐 측정이 필요합니다. 이 글에서 그러한 대규모 검증을 완료했다고 말하지 않습니다. 점수 상승 역시 실제 면접 실력이나 합격률 상승과는 별개입니다.

01 / WORK NOTES

결과와 사용량이 따로 움직일 수 있었습니다

Interviewer Lens는 개발자의 면접 답변을 AI로 진단하는 서비스입니다. 진단을 실행하면 답변을 만들고 결과를 저장하고 사용한 횟수도 기록해야 합니다. 눈에 보이는 답변 화면 뒤에 여러 단계가 이어집니다.

코드를 점검했을 때 사용량을 차감한 다음 결과를 따로 저장하는 흐름이 있었습니다. 중간에 실패하면 결과는 없는데 횟수만 줄어드는 상황이 생길 수 있는 구조였습니다. 이것은 점검에서 발견한 실패 가능성이지, 실제 사용자에게 같은 사고가 발생했다고 확인한 기록은 아닙니다.

수정의 기준은 결과 저장과 사용량 반영을 함께 확정하거나 함께 되돌리는 것이었습니다. 둘 중 하나만 성공한 상태를 남기지 않도록 만들고 중간 저장 지점에 의도적으로 오류를 넣어 확인했습니다.

02 / WORK NOTES

응답이 없다는 것이 실패했다는 뜻은 아니었습니다

데이터베이스에서는 저장이 끝났지만 브라우저로 돌아오는 응답만 끊길 수 있습니다. 이때 사용자가 다시 누른 요청을 전부 새 작업으로 처리하면 AI 실행과 사용량 기록이 중복될 수 있습니다.

그래서 같은 요청의 재시도인지 확인하고 이미 확정된 결과가 있으면 그 기록을 다시 확인하는 경로를 연결했습니다. 완료된 결과를 뒤늦은 오류 때문에 실패로 덮어쓰지 않는지도 함께 점검했습니다. 접수 단계에서도 중복 요청이 새 AI 작업을 반복해서 시작하지 않도록 처리했습니다.

1. 접수같은 작업을 다시 요청한 것인지 확인합니다.
2. 확정결과 저장과 사용량 반영을 하나의 처리 단위로 묶습니다.
3. 재확인응답이 끊겨도 이미 완료된 상태를 확인할 수 있게 합니다.

하나의 테스트만으로 충분하지는 않았습니다. 같은 요청이 동시에 들어오는 경우와 마지막 남은 사용 횟수를 여러 요청이 함께 쓰려는 경우도 별도로 검증했습니다.

03 / WORK NOTES

서버에서는 만료됐는데 화면은 계속 기다렸습니다

마지막 화면 흐름 점검에서는 다른 빈틈을 발견했습니다. 서버가 작업 도중 종료되면 작업 예약은 만료돼도 사용자의 화면은 계속 ‘처리 중’으로 남을 수 있었습니다. 내부 상태가 정리되는 것과 사용자에게 다음 행동이 보이는 것은 별개의 문제였습니다.

상태를 조회할 때 만료된 작업을 정리하고 다시 제출할 수 있도록 보완했습니다. 이후 재배포하고 운영 화면에서 제출 버튼과 무료 한도, 최근 기록이 표시되는 흐름을 확인했습니다.

04 / WORK NOTES

코드 준비와 운영 적용을 다른 칸에 적었습니다

작업은 DB 처리 기반을 먼저 만들고 이를 서비스 흐름에 연결한 뒤 운영에 적용하는 순서로 진행했습니다. 앞 단계가 끝났을 때는 준비된 코드를 운영 적용 완료라고 기록하지 않았습니다.

검증도 층을 나눴습니다. 중간 실패 시 되돌아오는지 확인하는 테스트, 실제 데이터베이스 연결 간 동시성 테스트, 서버 요청 흐름과 운영 화면 확인을 구분했습니다. 검증용 입력은 합성 데이터로 준비하고 기존 사용자 기록을 보존하는 조건을 확인했습니다.

조회한 완료 기록에는 안정화 적용과 검증이 남아 있습니다. 다만 이 작업으로 모든 장애를 없앴다고 말할 수는 없습니다. 이 글은 운영 환경의 구성값이나 사용자 답변을 공개하지 않으며 현재 보안 상태 전체를 인증하는 문서도 아닙니다.

05 / REPRODUCE THE DECISION

같은 요청을 다시 보냈을 때 무엇을 확인할까

아래 표는 작업 기록의 검증 기준을 독자가 자신의 서비스에 적용할 수 있게 다시 쓴 공개용 예시입니다. 내부 테스트 코드나 실제 고객 사고 기록은 아닙니다. 합성 요청 ID req-42와 사용 가능 횟수 1회를 가정합니다.

자신의 서비스에서 따라 할 때는 요청 식별자, 결과 저장, 사용량 반영을 한 행씩 기록해 보세요. 실패 주입 뒤에는 DB의 결과 수와 남은 횟수를 함께 조회하고 화면에서 로딩이 끝나는지도 확인합니다. 위 표의 숫자는 설명을 위한 기대값이며 현재 서비스의 실제 이용 한도나 운영 결과를 뜻하지 않습니다.

06 / RUN THE EXPERIMENT

저장 전 실패와 응답 유실은
같은 재시도로 풀리지 않습니다

표만 읽으면 둘 다 “오류가 났으니 다시 실행”으로 보이기 쉽습니다. 아래 작은 프로그램은 확정 전과 확정 후에 각각 오류를 던져 결과 수와 남은 횟수가 어떻게 다른지 보여줍니다. 이 글을 위해 새로 만든 공개 학습 모델입니다. 실제 서비스 코드, AI 응답, 고객 데이터는 사용하지 않습니다.

준비물은 Node.js뿐입니다. 의존성 설치, API 키, DB 연결이 없습니다. 실행해도 네트워크 요청이나 파일 저장을 하지 않습니다. 내려받은 파일이 있는 폴더에서 다음 명령을 실행하면 검증을 통과한 줄이 순서대로 출력됩니다. Node.js가 설치돼 있지 않으면 아래 전체 코드와 출력 비교만으로도 상태 변화를 따라갈 수 있습니다.

재시도 실험 내려받기 (.mjs)

node retry-lab.mjs

// Learning model only: one process, in-memory state, no real AI/DB/payment calls.
import assert from "node:assert/strict";

function createLab() {
  let state = { remaining: 1, results: new Map() };
  function submit(requestId, answer, failure = "none") {
    const prior = state.results.get(requestId);
    if (prior) {
      if (prior.answer !== answer) throw new Error("KEY_REUSED_WITH_DIFFERENT_INPUT");
      return prior;
    }
    if (state.remaining < 1) throw new Error("LIMIT_REACHED");
    const result = Object.freeze({ id: requestId, answer, feedback: "synthetic result" });
    const next = { remaining: state.remaining - 1, results: new Map(state.results) };
    next.results.set(requestId, result);
    if (failure === "before-commit") throw new Error("SAVE_FAILED");
    // One synchronous assignment models a commit; this is NOT a DB transaction.
    state = next;
    if (failure === "after-commit") throw new Error("RESPONSE_LOST");
    return result;
  }
  const snapshot = () => ({ results: state.results.size, remaining: state.remaining });
  return { submit, snapshot };
}

const before = createLab();
assert.throws(() => before.submit("req-42", "sample", "before-commit"), /SAVE_FAILED/);
assert.deepEqual(before.snapshot(), { results: 0, remaining: 1 });
console.log("before-commit: results=0 remaining=1");
before.submit("req-42", "sample");
assert.deepEqual(before.snapshot(), { results: 1, remaining: 0 });
console.log("retry-after-failure: results=1 remaining=0");

const after = createLab();
assert.throws(() => after.submit("req-42", "sample", "after-commit"), /RESPONSE_LOST/);
assert.deepEqual(after.snapshot(), { results: 1, remaining: 0 });
console.log("response-lost: results=1 remaining=0");
const original = after.submit("req-42", "sample");
assert.strictEqual(after.submit("req-42", "sample"), original);
assert.deepEqual(after.snapshot(), { results: 1, remaining: 0 });
console.log("same-key-retry: same-result remaining=0");
assert.throws(() => after.submit("req-42", "changed"), /KEY_REUSED_WITH_DIFFERENT_INPUT/);
assert.throws(() => after.submit("req-43", "sample"), /LIMIT_REACHED/);
assert.deepEqual(after.snapshot(), { results: 1, remaining: 0 });
console.log("changed-input: rejected; new-key: limit-reached");

before-commit: results=0 remaining=1
retry-after-failure: results=1 remaining=0
response-lost: results=1 remaining=0
same-key-retry: same-result remaining=0
changed-input: rejected; new-key: limit-reached

첫 실험은 state = next 이전에 실패하므로 임시로 만든 결과와 차감 값이 확정되지 않습니다. 다시 실행하면 결과 한 건과 차감 한 번이 함께 남습니다. 두 번째 실험은 같은 대입문 이후에 실패합니다. 호출자는 오류를 받지만 이미 상태가 바뀌었으므로 재시도는 기존 결과를 돌려줘야 합니다.

한도 확인보다 기존 요청 조회를 먼저 하는 이유가 있습니다. 이미 성공한 사용자는 남은 횟수가 0이어도 자신의 완료 결과를 다시 받아야 합니다. 반대로 같은 키로 답변을 바꿔 보내는 것은 재시도가 아닙니다. 예제는 이를 거부하고 새 키로 요청하면 새 작업으로 판단해 한도 검사를 적용합니다.

코드를 일부러 바꾸면 어떤 검사가 실패할까요?

1. 한도 검사를 기존 결과 조회보다 앞으로 옮겨 보세요.응답이 유실된 뒤 같은 req-42를 다시 조회하는 줄에서 LIMIT_REACHED가 납니다. 이미 확정된 결과를 되찾을 수 없어진 회귀입니다.
2. state = next를 저장 전 오류 검사 위로 옮겨 보세요.첫 실험의 results=0, remaining=1 검사가 실패합니다. 실패했다고 알려 놓고 이미 결과와 횟수를 바꾼 상태가 됩니다.
3. 입력 비교 조건을 지워 보세요.changed 입력을 거부해야 하는 assert.throws 검사가 실패합니다. 같은 요청 키가 다른 작업에 재사용돼도 예전 결과를 돌려주는 문제가 드러납니다.

내 서비스에 옮길 때 따로 정할 것

요청 키는 인증된 사용자와 작업 종류까지 포함해 범위를 정해야 다른 사용자의 결과를 돌려주지 않습니다. 확정 결과와 사용량은 실제 저장소의 원자적 처리로 묶고 동시에 들어오는 같은 키는 고유 제약 등으로 조정해야 합니다. 결과가 아직 없는 처리 중 상태도 따로 필요합니다. 프런트엔드 버튼 비활성화만으로는 이 조건들을 보장하지 못합니다.

최소한 서로 다른 DB 연결에서 같은 키를 동시에 보내는 경우, 남은 한 번에 서로 다른 키 두 개가 경쟁하는 경우, 확정 직후 연결이 끊기는 경우를 별도로 시험하세요. 확인할 것은 단순한 HTTP 성공 여부가 아니라 결과 ID, 결과 건수, 남은 횟수입니다. 원문 답변이나 토큰을 로그에 남기는 대신 검증용 합성 입력과 요청 식별자를 사용하는 편이 안전합니다.

07 / WORK NOTES

다음 기능보다 먼저 적을 실패 시나리오

다음 AI 기능을 만들 때도 정상 응답만 확인하고 끝내지 않으려 합니다. 두 번 눌렀을 때, 저장 뒤 연결이 끊겼을 때, 기다리던 작업이 만료됐을 때 사용자가 무엇을 보게 될지 먼저 적을 수 있습니다.

확인할 대상은 모델의 문장만이 아닙니다. 요청의 정체성, 결과의 보존, 사용량의 일관성, 다시 시작하는 경로까지입니다. 아래 템플릿은 이 기록을 다른 서비스에서도 사용할 수 있도록 새로 정리한 점검 양식입니다. 위 학습 모델과 템플릿은 그대로 붙여 넣는 운영 코드나 SQL을 대신하지 않습니다.

01 / THE PROBLEM

숫자처럼 보여도
계산할 값은 아닐 수 있습니다.

상품 코드 00123은 숫자 123과 다른 식별자일 수 있습니다. CSV를 열면서 숫자로 해석하면 앞자리 0이 사라질 수 있고 긴 ID는 숫자 정밀도의 영향을 받을 수 있습니다. Microsoft도 이런 값을 보존하기 위한 텍스트 가져오기 방식을 안내합니다. 공식 안내 읽기 ↗ (영문, 새 탭)

Column Harbor는 이 지점에서 출발하는 도구입니다. 파일이 이미 깨졌다고 단정하는 대신, 가져오기 전에 확인할 값과 위치를 보여줍니다. 경고의 의미는 ‘오류 확정’이 아니라 ‘이 값은 한 번 더 살펴보세요’에 가깝습니다.

02 / THE FLOW

파일을 선택해도
서버로 올리지는 않습니다.

점검기는 선택한 파일이나 붙여 넣은 텍스트를 현재 브라우저에서 읽습니다. 내용을 서버에 보내 AI로 분석하는 방식이 아니라, 원본 문자열을 해석하고 정해진 규칙으로 위험 신호를 찾습니다.

1. 원본 읽기UTF-8 텍스트를 읽고 선택한 구분자로 레코드와 필드를 나눕니다.
2. 값은 문자열로 유지상품 코드나 날짜처럼 보이는 값을 임의로 숫자·날짜로 바꾸지 않습니다.
3. 위험과 위치 보여주기앞자리 0, 긴 숫자, 날짜 패턴, 열 개수 등 확인할 부분과 원본 값을 표시합니다.

점검 입력과 결과는 현재 페이지의 메모리에 머무릅니다. 다만 파일이 로컬에서 처리된다는 말이 웹사이트 접속 자체의 완전한 익명성을 뜻하지는 않습니다. 내려받은 점검 보고서에도 원본 값 일부가 들어갈 수 있으므로 공유 전에 확인해야 합니다. 파일 처리 안내 ↗ (영문, 새 탭)

03 / THE BOUNDARY

친절한 자동 수정이
항상 정답은 아니니까요.

03/04/2026이 3월 4일인지, 4월 3일인지는 모양만 보고 확정할 수 없습니다. 123의 원래 값이 00123이었는지도 이미 손실된 파일만으로는 알 수 없습니다. 그래서 점검기는 원본을 덮어쓰거나 복구를 약속하지 않습니다.

브라우저에서 다루는 범위에도 제한을 둡니다. 확인 당시 점검기는 최대 5 MiB의 UTF-8 텍스트, 20,000개 데이터 레코드, 250,000개 셀을 다룹니다. 대용량 처리나 모든 업무 규칙의 검증을 대신하는 도구는 아닙니다.

04 / WHAT COMES NEXT

경고 다음에는,
다음 행동이 있어야 합니다.

위험 신호만 보여주고 끝나지 않도록 점검 결과에서 관련 가이드로 이동할 수 있습니다. 앞자리 0은 텍스트로 가져오는 방법으로, 한 열에 몰린 값은 구분자와 가져오기 설정으로 이어집니다.

이 프로젝트가 맡는 역할은 작습니다. 원본이 어떻게 생겼는지 확인하고 달라질 수 있는 부분을 찾고 다음 행동을 고르는 것. 파일을 바꾸기 전에 한 번 멈춰 볼 수 있는 도구입니다.

01 / EXPECTED VS OBSERVED

계산이 맞아도 검증이 끝난 것은 아니었습니다

앞선 제작 기록에서는 독자가 따라 할 수 있는 예제를 만드는 일을 다뤘습니다. 그 다음에는 한 걸음 더 들어갔습니다. 독립 스크립트의 기대값이 맞더라도 Excel의 가져오기와 자료형 처리까지 확인한 것은 아니기 때문입니다.

실제 Excel을 별도 합성 워크북으로 실행해 값, 자료형, 표시 형식, 조작 순서를 함께 기록했습니다. 신규 원고 검사 32개와 기존 원고 검사 62개를 남겼습니다. 합계 94개는 특정 환경의 검사 행 수이지, 서로 다른 Excel 기능 94개나 모든 버전의 검증을 뜻하지 않습니다.

02 / SAME LENGTH, DIFFERENT VALUE

16자리라는 사실만으로는 충분하지 않았습니다

같은 합성 파일에서 ID 열을 General로 가져온 대조군과 Text로 가져온 경우를 비교했습니다. General 대조군에서는 서로 다른 두 ID가 같은 숫자로 합쳐졌습니다. 두 값 모두 길이는 여전히 16자리였습니다.

원문을 보존한 경로는 QueryTables에서 해당 열을 Text로 지정한 가져오기였습니다. 성공 여부는 원래 문자열과 Value2의 직접 비교, ISTEXT, LEN, EXACT를 함께 사용해 확인했습니다.

Excel의 숫자 정밀도는 유효 숫자 15자리로 제한됩니다. 계산할 숫자가 아닌 긴 식별자는 숫자로 바꾸기 전에 텍스트로 다루는 것이 중요합니다. Microsoft의 앞자리 0·긴 숫자 안내 ↗ (영문, 새 탭)

03 / THE HIDDEN INPUT

수식 밖에도 입력이 있었습니다

SUBTOTAL 실습에서는 필터를 적용한 뒤 행을 수동으로 숨긴 혼합 상태가 예상과 달랐습니다. 이 빌드에서 관측한 결과를 모든 Excel 버전의 일반 규칙으로 바꾸지는 않았습니다.

원고를 ‘필터만 적용하는 실습’과 ‘필터를 완전히 끈 뒤 수동으로 숨기는 실습’으로 나눴습니다. 실습 전에 이전 필터와 숨김 상태를 초기화하고 혼합 상태의 결과는 별도 관측으로 남겼습니다.

1. 초기 상태필터와 숨김을 초기화하고 어떤 행이 보이는지 확인합니다.
2. 한 가지 변화필터 또는 수동 숨김 중 하나를 먼저 적용합니다.
3. 관측과 범위예상값·실제값·실행 순서를 남기고 다른 환경까지 일반화하지 않습니다.

공식과 셀 값만으로 실험을 설명할 수 없었습니다. 작업 순서와 이전 상태도 입력의 일부였습니다.

04 / WHAT IS STILL UNKNOWN

우회에 성공해도 원인은 미해결이었습니다

OpenText에 Text 설정을 전달했는데도 긴 ID가 숫자로 읽히는 현상을 별도로 재현했습니다. 파일 확장자와 인수 전달을 달리하는 시도도 했지만 근본 원인을 확정하지 못했습니다.

따라서 결론은 두 줄입니다. QueryTables의 Text 가져오기에서는 원문 보존을 확인했습니다. OpenText 경로의 원인은 아직 미해결입니다. 성공한 대체 방법을 찾았다는 사실과 원인을 해결했다는 주장을 섞지 않았습니다.

최신 동적 배열 함수, Power Query 편집기·M 실행, 모든 언어와 인코딩 조합은 이번 검증 범위가 아닙니다. 사용한 원고나 샘플이 바뀌면 과거의 PASS도 그 전 버전에 대한 근거로 남습니다.

01 / DEVELOPMENT NOTES

로그인은 늦추되 결과는 이어지게

서비스에 관심을 가진 사람이 곧바로 계정을 만들지는 않았습니다. 첫 가치를 경험하기 전에 면접 답변도 쓰고 로그인도 해야 하는 흐름이 부담일 수 있다고 봤습니다. 그래서 첫 진단은 로그인 없이 입력하고 전체 결과를 보고 복사할 수 있도록 열었습니다.

로그인은 결과를 계정 기록으로 가져오거나 다음 연습으로 이어질 때의 행동으로 옮겼습니다. 단순히 로그인 조건을 지운 것은 아닙니다. 서명된 게스트 쿠키로 주체를 확인하고 봇 검증과 별도 제한을 유지했습니다. 계정 이전에서는 중복 이전과 사용량 반영을 함께 다뤘습니다.

게스트 쿠키나 IP가 한 사람을 완벽하게 식별하는 것은 아닙니다. 로그인 없는 체험과 악용 방지는 함께 설계해야 하지만 그 설계를 사람당 완전한 제한으로 설명하지는 않습니다.

02 / DEVELOPMENT NOTES

결과는 보이는데 복사가 막혀 있었습니다

수정 과정에서 비로그인 상호작용을 한꺼번에 막는 조건이 남았습니다. 결과를 보여주면서 복사 버튼까지 비활성화한 회귀였습니다. 입구는 열었지만 결과를 가져가는 마지막 행동에 장벽을 남긴 셈입니다.

전체 처리 중의 잠금과 로그인해야 가능한 후속 동작의 잠금을 분리했습니다. 이후 확인 단위도 “진단 화면이 열린다”에서 “입력하고, 결과를 보고, 복사하거나 계정에 저장할 수 있다”로 바꿨습니다.

03 / DEVELOPMENT NOTES

로그인 다음에는 빈 답변 칸이 있었습니다

계정을 만들지 않아도 긴 답변을 처음부터 쓰는 일은 쉽지 않습니다. 무엇을 얻는지 충분히 이해하기 전에 노력을 요구하는 문제는 남았습니다. 그래서 질문과 주어진 사실, 보완 전후, 바꾼 이유, 예상 꼬리질문을 읽을 수 있는 공개 예시를 만들었습니다.

예시는 로그인이나 AI 실행 없이 열람하고 같은 질문으로 연습하는 흐름에 연결했습니다. 설명용 답변을 사용자의 입력에 몰래 채우거나 자동 제출하지 않았습니다. 자체 작성 예시는 제품의 사용법을 설명하는 자료이지, 실제 후기나 AI 품질을 증명하는 결과가 아닙니다.

이 경로를 관찰하기 위해 예시 열람, 연습 클릭, 입력 화면 표시, 입력 시작, 서버 접수·완료를 구분했습니다. 이벤트에는 답변이나 이력서 원문을 넣지 않고 필요한 단계와 허용된 식별자만 남겼습니다.

04 / DEVELOPMENT NOTES

숫자가 있다는 이유만으로 비율을 만들지 않기

진단 행에는 게스트 결과를 계정으로 옮긴 복사본과 운영자 QA가 섞일 수 있습니다. 브라우저의 결과 확인 이벤트와 서버의 완료 이벤트를 더하면 같은 작업을 중복으로 셀 수도 있습니다. 계측을 시작하기 전 방문에는 새 식별자가 없으므로 과거 행동을 소급해 복원할 수도 없습니다.

1. 무엇을 한 번으로 셀지사람, 탭 세션, 요청, 저장 행을 서로 바꿔 쓰지 않습니다. 결과 이전 복사본은 새로운 진단과 구분합니다.
2. 어떤 관찰을 제외할지QA 유입과 지정 운영자 활동을 성장 집계에서 분리하고 제외 범위를 기록합니다.
3. 어디까지 연결되는지같은 기간의 같은 탭 관찰도 순서나 인과의 증거는 아닙니다. 기기 이동·추적 차단·미수집 구간은 한계로 남깁니다.

분모가 없으면 전환율은 0%가 아니라 판단 불가입니다. 당시에는 게스트 체험과 예시, 단계별 계측을 구현하고 확인했다는 사실을 말할 수 있었습니다. 반복 사용, 전환 상승, 시장 적합성은 별도로 검증해야 할 질문으로 남았습니다.

01 / WORK NOTES

비슷한 검색어여도 할 일은 반대였습니다

Column Harbor의 영어 가이드는 기존 4편을 보강하고 20편을 추가해 24편으로 확장했습니다. CSV 오류, 숫자와 ID 보존, 날짜, 텍스트 정리, 파일 비교와 결합, 형식 변환의 여섯 주제로 묶었습니다.

분류에서 중요했던 것은 같은 단어가 들어간 글을 모으는 것만이 아니었습니다. ‘숫자를 텍스트로 보존해야 하는 상황’과 ‘숫자가 텍스트라서 합계가 계산되지 않는 상황’은 비슷해 보여도 독자가 해야 할 행동은 반대입니다. 전자는 식별자를 지키는 문제이고 후자는 계산할 값을 다루는 문제입니다.

그래서 제목과 첫 설명에 증상뿐 아니라 어떤 상황을 해결하는 글인지 드러내도록 정리했습니다. 한 글에서 모든 경우를 해결하려 하기보다 독자가 지금 겪는 문제 하나에 맞춰 예제와 절차를 연결했습니다.

02 / WORK NOTES

설명은 있었지만 문제가 안 보이는 예제가 있었습니다

최종 검토 중 날짜 정렬 글에서 문제 상황이 눈에 드러나지 않는 예제를 발견해 수정했습니다. 문장으로 ‘정렬이 잘못된다’고 말하더라도 독자가 같은 샘플로 차이를 확인할 수 없다면 예제는 설명의 근거가 되기 어렵습니다.

변환 글에서는 실행 코드가 내는 결과를 예상 결과와 대조했습니다. 특히 빈 값과 0을 같은 것으로 읽지 않도록 설명을 다듬었고 TSV 변환에서는 저장한 파일을 다시 읽어 원래 값이 보존되는지 확인하도록 절차를 보강했습니다.

여러 파일을 비교하거나 합치는 글은 파일별 샘플을 내려받게 했습니다. 독자가 예제를 다시 만드는 데 시간을 쓰기보다 설명한 차이를 바로 확인하도록 하기 위해서입니다.

03 / WORK NOTES

이미지는 장식보다 확인 도구로

본문에는 원본과 처리 결과를 비교하는 도해 48개를 준비했습니다. 실제 Excel 화면인 것처럼 꾸미기보다 무엇이 달라지는지를 설명하는 도해로 구성했습니다. 큰 화면에서는 좌우로, 좁은 화면에서는 위아래로 읽히도록 점검했습니다.

글마다 이미지, 샘플 다운로드, 관련 글 연결을 확인했습니다. 원고가 완성돼도 내려받을 파일이 없거나 다음 설명으로 가는 링크가 끊겨 있다면 독자에게는 미완성된 안내이기 때문입니다. 공개한 영어 가이드 둘러보기 ↗ (새 탭)

04 / WORK NOTES

공개한 글 수를 검색 성과로 쓰지 않았습니다

후속 작업에서는 브랜드명 검색과 개별 문제 해결 검색어를 나눠 보았습니다. 조회한 작업 기록에서는 홈페이지의 색인을 확인했지만 신규 대표 글은 발견된 뒤 아직 색인되지 않은 상태였습니다. 따라서 홈페이지가 검색에 들어갔다는 사실을 모든 글의 검색 노출로 확대하지 않았습니다.

사이트 이름을 설명하는 정보와 가이드 목록 제목을 보완하고 갱신된 사이트맵을 제출하는 작업이 이어졌습니다. 다만 이 글은 그 작업으로 순위나 방문자가 늘었다고 주장하지 않습니다. 재수집 요청이나 색인 여부는 성과 확인의 일부일 뿐입니다.

Google도 수집, 색인, 검색 결과 제공을 서로 다른 단계로 설명하고 사이트가 지침을 따르더라도 모든 단계의 처리를 보장하지 않는다고 안내합니다. Google 검색의 처리 단계 ↗ (새 탭)

05 / WORK NOTES

다음 원고에는 ‘예상 결과’부터 적기

이번 기록에서 가져갈 수 있는 방법은 간단합니다. 원고 분량을 늘리기 전에 ‘독자가 이 샘플을 사용하면 무엇을 확인하게 되는가’를 한 줄로 적습니다. 그 다음에 입력 파일, 절차, 결과, 잘못 적용하면 안 되는 조건을 맞춥니다.

제작 기록에는 공개 여부를, 검색 기록에는 색인·노출·클릭을 따로 남깁니다. 아직 측정하지 않은 칸은 0으로 채우지 않고 ‘미확인’으로 둡니다. 그래야 다음에 더 쓸지, 기존 글을 고칠지 판단할 근거가 생깁니다.

01 / DEVELOPMENT NOTES

문제는 색상이 아니라 읽는 순서였습니다

처음 홈페이지는 큰 제목, 넓은 소개 영역, 반복된 카드로 구성했습니다. 색과 문구를 바꿔도 같은 화면처럼 느껴지는 문제가 남았습니다. 실제 서비스보다 “어떤 사람의 공간인가”를 설명하는 문장이 더 먼저, 더 크게 읽혔습니다.

소개 내용도 다시 확인해야 했습니다. 면접 답변 진단 도구를 준비 글처럼 다루거나 AI 홍보 콘텐츠 제작 서비스를 사이드 프로젝트 아카이브로 설명하면 카드가 아무리 깔끔해도 목적지를 잘못 안내합니다.

먼저 서비스의 성격을 확인하고 프로젝트를 글·SNS와 분리했습니다. 이 기록을 작성할 당시 홈페이지에서는 대표 프로젝트 세 개의 이름과 용도를 먼저 보여줬습니다. 캐릭터와 소개는 신뢰를 보태되 실제로 써 볼 대상을 가리지 않도록 배치했습니다.

02 / DEVELOPMENT NOTES

그림보다 먼저, 무엇을 하는지

프로젝트 그림은 기능을 짐작하게 해 주지만 그것만으로 용도가 확정되지는 않습니다. 면접 진단 예시, AI 홍보물, CSV 값 비교 앞에 이름과 짧은 목적 설명을 배치했습니다. 코드의 읽기 순서도 시각 순서와 맞췄습니다.

그 다음에는 방문 목적에 따라 이동할 수 있게 했습니다. 프로젝트 바로가기, 글·자료 분류, 검색, 입문 경로, 실험 기록을 연결하되 대표 서비스 카드를 계속 늘리는 방식은 피했습니다. 모든 링크를 똑같이 크게 만드는 대신 어떤 행동을 먼저 할지 정했습니다.

03 / DEVELOPMENT NOTES

정적 홈페이지에 필요한 상태만 두기

HTML·CSS·vanilla JavaScript를 유지했습니다. 링크와 본문은 HTML에 있고 검색·분류·더 보기는 기존 스크립트가 담당합니다. 입문 경로와 템플릿 미리보기는 네이티브 펼침으로 구성해 별도의 앱 상태 없이도 읽을 수 있습니다.

CSV 비교는 합성 상품 코드 하나만 사용하는 설명용 체험입니다. 실제 파일을 받거나 원본을 수정하지 않습니다. 작업 점검 도구도 자동 진단을 붙이는 대신 방문자가 상태를 직접 고르고 기록을 가져가도록 만들었습니다.

점검 상태는 현재 탭의 메모리에만 두고 URL에는 작업 유형만 남겼습니다. 분류한 항목 수를 배포 안전 점수로 부르지 않았습니다. 기능이 많아 보이는 것보다 실제로 제공하는 범위와 저장하지 않는 것을 분명히 하는 쪽을 선택했습니다.

04 / DEVELOPMENT NOTES

잘 보인다는 판단과, 확인 가능한 검사를 나누기

화면에서는 여러 폭의 가로 넘침과 글자 잘림, 키보드 조작을 확인했습니다. 자동 검사에서는 기존 외부 링크, 프로젝트 수, 검색·URL 복원, 내부 경로와 메타데이터, 다운로드 원문과 미리보기의 일치를 다뤘습니다.

작업 점검 도구의 Blob 생성과 오류 대체 경로는 자동 검사했지만 당시 인앱 브라우저에서는 실제 파일 저장과 OS 클립보드 전달을 확정하지 못했습니다. 성공 안내만으로 검증 완료라고 하지 않고 API 없이 텍스트를 직접 선택하는 경로를 추가해 실제 화면에서 확인했습니다.

비공개 출처는 공개 원고와 분리하고 Git·웹 배포에서 제외했습니다. 배포 후에는 필요한 페이지의 응답뿐 아니라 내부 문서가 공개되지 않는지도 확인했습니다. 이런 점검도 완전한 보안 감사나 모든 보조기기의 접근성 검증과는 다릅니다.

정보 순서와 행동 경로, 실패 시 대안이 바뀌었습니다. 클릭률과 전환율의 개선은 별도 관찰이 있어야 합니다. 다음 기능도 공간이 비어 보인다는 이유보다 방문자가 막히는 지점이 확인됐을 때 추가하려고 합니다.

01 / WORK NOTES

완성 파일 다음의 일

Deep Constellation에서는 미용실 홍보에 쓸 AI 이미지를 만들고 게시글과 서비스 페이지로 연결하는 작업을 진행했습니다. 이번 기록의 출발점은 단발 C컬과 아웃컬을 비교하는 게시물입니다. 완성된 이미지가 있어도 그것만으로 게시 준비가 끝난 것은 아니었습니다.

게시할 때는 AI로 만든 예시라는 표시와 실제 시술 결과가 아니라는 설명을 함께 넣었습니다. 이미지의 분위기를 보여주는 일과 특정 매장의 실적을 증명하는 일은 다르기 때문입니다. 제작 완료와 게시 완료도 따로 기록했습니다. 게시하지 않은 파일을 이미 공개한 결과물처럼 세지 않기 위해서입니다.

02 / WORK NOTES

로컬 검사는 통과했는데 배포는 실패했습니다

같은 작업 중 홈페이지의 자동 배포가 실패했습니다. 로컬에서 빌드와 테스트를 확인했는데도 배포 환경에서는 내부 운영 자료를 참조하는 테스트가 실행되지 않았습니다. 공개 배포에서 제외한 문서를 테스트가 여전히 필요로 하는 상태였습니다.

이때 검사를 전부 끌 필요는 없었습니다. 공개 사이트를 검사하는 범위와 내부 운영 키트를 검사하는 범위를 분리했습니다. 내부 전용 테스트는 공개 배포 입력에서 제외하고 로컬에서는 전체 검사를 유지했습니다.

수정 후에는 실제 도메인에서 홈페이지와 소개 페이지, 이미지가 열리는지 확인했습니다. 반대로 내부 운영 자료는 공개 주소로 열리지 않는지도 확인했습니다. 배포 성공 표시만 보는 것과, 공개되어야 할 것과 없어야 할 것을 모두 확인하는 것은 다른 점검이었습니다.

03 / WORK NOTES

소개를 보냈다는 것과, 관심을 얻었다는 것

게시물은 관련성이 있는 소수의 매장에 소개했습니다. 후보를 볼 때 팔로워 수만 기준으로 삼지 않고 최근 활동과 헤어 콘텐츠의 관련성을 함께 살폈습니다. 이미 연락한 대상과 겹치거나 거절 의사를 보인 곳을 다시 접촉하지 않도록 확인하는 절차도 두었습니다.

하지만 메시지 전송과 링크 미리보기를 확인했다고 해서 문의나 주문이 생긴 것은 아닙니다. 이번에 조회한 기록에는 소개를 보낸 사실은 있지만 그에 대한 답변과 구매 전환은 확인되지 않았습니다. 그래서 이 글을 ‘고객 확보 성공기’로 쓰지 않았습니다.

상대의 계정명, 대화 내용, 연락처는 여기에 공개하지 않습니다. 소개 전에 어떤 기준을 확인했는지와 결과를 어디까지 확인했는지만 공개할 수 있습니다.

04 / WORK NOTES

다음부터 남길 세 칸

1. 만든 것최종 파일, 사용할 채널, 게시글, AI 예시 표기까지 준비했는가.
2. 내보낸 것게시물과 서비스 링크가 실제로 열리는가. 내부 자료는 공개되지 않는가.
3. 돌아온 반응답변·문의·주문 중 무엇을 확인했는가. 아직 확인하지 못한 것은 무엇인가.

이 세 칸을 나누면 제작량을 성과로 착각하는 일을 줄일 수 있습니다. 예쁜 샘플을 만드는 일도 중요하지만 전달한 뒤 무엇을 배웠는지 남기는 일까지가 하나의 실험입니다.

공개 페이지를 운영할 때는 호스팅의 상업적 이용 조건도 별도로 확인해야 합니다. 배포가 기술적으로 성공했다는 사실만으로 운영 조건까지 해결된 것으로 기록하지 않는 것도 같은 원칙입니다.

01 / DEVELOPMENT NOTES

영상 한 개보다, 다시 만들 수 있는 묶음

Deep Constellation을 소개하는 짧은 영상은 기존 시즌·오픈·예약용 AI 이미지를 재료로 삼았습니다. 새로운 고객 사례를 만드는 작업이 아니라, 매장 소식이 어떻게 홍보 콘텐츠가 되는지 보여주는 자체 시연이었습니다.

원본 래스터 이미지는 수정하지 않고 문구와 모션을 코드로 합성했습니다. 출력은 1080×1920, 30fps, 24초의 세로 영상이었습니다. 실사 인물이 움직이는 AI 생성 영상으로 소개하지 않았습니다.

제작 산출물도 MP4 하나로 두지 않았습니다. 음악 포함본과 무음본, 커버, 화면 문구의 타이밍 파일, 검수용 프레임, 출력 규격과 해시를 담은 manifest를 함께 남겼습니다. 화면 문구는 이미 영상에 들어 있으므로 타이밍 파일을 음성 내레이션 자막처럼 중복 표시하지 않도록 구분했습니다.

02 / DEVELOPMENT NOTES

전체 렌더 전에, 읽히는지 먼저

작은 포스터 안의 글자를 세로 영상에 그대로 넣으면 화면에는 있지만 읽기 어려울 수 있습니다. 포스터는 시각 예시로 두고 핵심 설명은 별도의 큰 문구로 배치했습니다. 먼저 미리보기 키프레임을 만들고 문자 경계와 최소 크기를 확인했습니다.

당시 검사에서는 일곱 키프레임을 직접 보고 핵심 문구가 설정한 안전 영역 안에 있는지 확인했습니다. 이 검사는 프로젝트에서 정한 레이아웃 기준입니다. 모든 플랫폼과 기기의 버튼·자막 위치를 보장하는 공식 규격이라고 설명하지 않습니다.

03 / DEVELOPMENT NOTES

인코딩이 끝난 것과 재생이 되는 것은 달랐습니다

키프레임이 잘 나왔다고 최종 동영상이 온전하다고 볼 수는 없었습니다. 출력된 두 MP4를 FFmpeg로 끝까지 디코딩하고 브라우저에서 해상도와 24초 재생시간을 확인했습니다. 제작 QA에는 음악 포함본 720프레임과 디코딩 오류 없음이 기록돼 있습니다.

검은 화면 구간과 오디오 클리핑도 설정한 검사 조건으로 살폈습니다. 여기서 “보고 없음”은 그 검사 조건의 결과입니다. 실제 기기의 청취 평가나 모든 재생 환경을 대체하지 않습니다.

배경음은 코드로 새로 합성했고 기존 곡이나 외부 오디오 샘플은 쓰지 않았습니다. 폰트 라이선스 사본도 제작 자료에 보존했습니다. 그렇다고 이후 플랫폼의 자동 권리 판정까지 보장한다고 쓰지는 않았습니다.

04 / DEVELOPMENT NOTES

제작 시점의 미게시와, 이후 공개 완료는 모순이 아닙니다

제작 패키지에는 당시의 published: false가 남아 있습니다. 후속 게시 로그에는 같은 첫 홍보영상의 Instagram·YouTube 공개 확인과, TikTok의 검토 중 상태가 전체 공개로 바뀐 확인이 별도로 기록돼 있습니다.

제작 기록을 덮어써 처음부터 공개됐던 것처럼 만들지 않았습니다. 원본 파일의 식별 정보와 게시 URL·확인 시점을 연결했습니다. 별도로 만든 캠페인 영상의 미게시 상태도 이 영상의 후속 상태와 합치지 않았습니다.

1. 제작 완료파일·규격·디코딩·키프레임을 검사한 상태입니다.
2. 게시 요청과 공개 확인버튼 실행과 처리 완료, 실제 공개 범위를 따로 기록합니다. 처리 중에는 곧바로 중복 업로드하지 않습니다.
3. 반응 확인도달·유지율·문의는 실제 측정 자료가 있어야 합니다. 당시 기록에는 성과 측정이 없었습니다.

이 흐름은 영상도 소프트웨어처럼 복잡하게 만들자는 뜻이 아닙니다. 나중에 다른 파일을 보며 결과를 착각하지 않도록 무엇을 만들었고 어디까지 확인했는지 연결해 두자는 기준입니다.