수동 QA (품질 보증)수동 QA 엔지니어

동적 재무 보고 모듈을 수동으로 검증할 때, 웹 인터페이스에서 복잡한 **Excel** 워크북을 생성하고 **VBA** 매크로, **피벗 테이블**, 및 **파워 쿼리** 데이터 연결을 포함하는 경우, **Microsoft Excel** 2016/2019/**Microsoft 365**, **LibreOffice Calc**, 및 **Google Sheets**와의 버전 간 호환성을 보장하고 **CSV** 주입 공격을 방지하며 모든 대상 플랫폼에서 **UTF-8** 국제 문자 렌더링이 올바르게 이루어지는지 확인하기 위한 체계적인 테스트 방법론은 무엇인가요?

Hintsage AI 어시스턴트로 면접 통과

질문에 대한 답변

기업 보고 시스템은 종종 레거시 인프라와 현대 클라우드 플랫폼을 연결하므로, 10년 이상의 릴리스 주기를 아우르는 오피스 제품군에 대한 지원이 필요합니다. 복잡성은 Excel 파일 형식—레거시 XLS에서 매크로 지원이 있는 최신 XLSM까지—이 Microsoft Excel 2016, 2019 및 Microsoft 365 구독에서 서로 다른 동작을 보이기 때문에 발생합니다. 오픈 소스 대안인 LibreOffice Calc도 마찬가지입니다. 조직들은 준수 문제로 인해 특정 버전을 요구하는 경우가 많아, 한 환경에서 운송 비용을 올바르게 계산하는 파일이 다른 환경에서 유니코드 데이터를 손상시키거나 보안 기능을 비활성화할 수 있는 단편화된 생태계를 만들어냅니다.

자동 계산을 위한 VBA 매크로를 포함한 워크북을 동적으로 생성할 때, 테스터들은 Excel 2016이 서명되지 않은 코드를 격리하거나 매크로 실행을 완전히 방해하는 방해적인 노란색 보안 리본을 표시할 위험에 직면합니다. 외부 데이터베이스에 대한 파워 쿼리 연결은 Excel 365에서는 매끄럽지만 LibreOffice Calc에서는 정적이고 새로 고칠 수 없는 값으로 나타나 비즈니스 사용자가 즉시 감지하지 못할 수 있는 데이터 노후화를 초래합니다. 더구나 UTF-8로 인코딩된 국제 문자—특히 오른쪽에서 왼쪽으로 읽는 스크립트나 CJK 이두어—는 보통 구형 Excel 버전에서는 ASCII 모지베이크로 렌더링됩니다. 가장 중요한 것은, 셀 값이 =, +, -, 또는 @와 같은 수식을 유발하는 문자로 시작할 경우 수식 주입 공격이 여전히 가능하다는 점입니다. CSV로 내보낸 파일을 데스크톱 응용프로그램에서 다시 열 때 악성 cmd.exe 명령이 실행될 수 있습니다.

체계적인 방법론은 라이센스 충돌을 방지하고 깨끗한 기준 테스트를 보장하기 위해 서로 다른 Excel 버전을 호스팅하는 격리된 VM 환경 또는 Docker 컨테이너를 설정하는 것을 필요로 합니다. 테스트 데이터에는 "=CMD|' /C calc'!A0" 및 "@HYPERLINK" 문자열과 같은 악의적인 페이로드를 포함해야 하며, 출력을 정리하는지 확인하기 위해 탭 문자를 추가하거나 단일 따옴표를 추가하여 수식 실행을 무효화해야 합니다. 유니코드 유효성을 검증하기 위해, BOM 마커 및 복잡한 스크립트를 포함한 파일을 생성한 후, Google Sheets, LibreOffice 및 레거시 Excel 버전에서 렌더링을 확인하고 문자 대체 오류가 있는지 확인해야 합니다. VBA 매크로 테스트는 다양한 Windows 보안 영역 및 그룹 정책 구성에서 디지털 서명 유효성을 검증해야 하며, 웹의 표시 마크(MOTW) 제한이 정당한 비즈니스 매크로를 차단하지 않도록 해야 합니다. 마지막으로, 애플리케이션이 User-Agent 헤더를 통해 클라이언트 기능을 감지하는 점진적 향상 테스트를 구현하여, 능력이 있는 클라이언트에게 매크로가 포함된 XLSX를 제공하고 레거시 시스템에는 명시적인 데이터 유형 선언이 포함된 정리된 CSV를 제공해야 합니다.

실제 상황

다국적 물류 회사에서, 나는 치수 중량 및 연료 추가 요금을 계산하기 위한 자동 VBA 매크로가 포함된 Excel 파일을 생성하는 선적 명세서 내보내기 기능을 테스트했습니다. 이 시스템은 낮은 연결성의 창고 환경에 있는 견고화된 노트북에서 에어갭 Excel 2016 설치를 사용하는 현장 요원들을 지원해야 했으며, 본사 직원들은 클라우드 기반 파워 쿼리 연결을 통해 실시간 SQL Server 데이터베이스를 사용하는 Microsoft 365를 이용했습니다. 내보내기 기능은 또한 라이센스 비용 때문에 Linux 시스템에서 LibreOffice Calc를 선호하는 국제 고객들도 서비스해야 했기에, 초기 개발 팀이 예상하지 못한 세 가지 호환성 요구 사항이 있었습니다. 상황을 복잡하게 만든 것은 선적 설명서에 아랍어 및 만다린 문자가 포함되는 경우가 많았고, 추적 번호는 종종 수식처럼 보이는 더하기 기호 또는 등호 기호로 시작했습니다.

초기 테스트에서는 생태계 전반에 걸쳐 치명적인 실패가 발생했습니다. 회사의 그룹 정책 설정이 있는 Excel 2016 설치는 모든 서명되지 않은 VBA 매크로를 차단하여, 창고 직원들이 시스템 오류로 해석하는 모호한 보안 경고를 표시하며 운영 지연을 초래했습니다. LibreOffice Calc 사용자는 파워 쿼리 연결이 새로 고칠 수 있는 능력이 없는 정적 값으로 나타나는 것을 발견하여, 매일 변동하는 환율을 기반으로 주간된 화물 요금에 대한 결정이 잘못될 수 있었습니다. 가장 심각한 문제는 아랍어 선적 설명서가 BOM 헤더가 없는 구형 Excel에서는 지저분한 ASCII 문자로 내보내져 버려졌고, "="로 시작하는 추적 번호는 Google Sheets에서 수식으로 해석되어 "#NAME?" 오류를 대신 표시했습니다.

첫 번째 접근은 모든 고급 기능을 제거하고 구분 기호로 쉼표와 인용된 텍스트 필드를 사용하는 일반 CSV 파일을 내보내는 것이었습니다. 이 전략은 모바일 장치 및 여전히 원격 창고에 존재하는 레거시 시스템을 포함한 모든 플랫폼에서 보편적인 호환성을 보장했습니다. 그러나 이는 현장 요원들이 화물 가격 책정을 위해 의존하는 자동 치수 중량 계산을 제거하여, 수동으로 수학을 해야 하며 15%의 오류율 증가와 처리 시간이 현저하게 느려지는 문제를 일으켰습니다. 또, CSV 파일은 팀 간 이메일을 통해 전송될 때 우연한 데이터 조작이나 버전 관리 충돌에 대한 보호를 제공하지 않았습니다.

제안된 두 번째 해결책은 코드베이스 내에서 세 개의 별도 내보내기 파이프라인을 유지하는 것이었으며: 하나는 구형 Excel용 레거시 XLS 형식을 생성하고, 하나는 전체 매크로 지원이 있는 XLSM을 생성하며, 하나는 LibreOffice 호환성을 위한 ODS (OpenDocument Spreadsheet)를 생성하는 것이었습니다. 이 접근 방식은 각 사용자 세그먼트에 최적의 원주율 경험을 제공할 것처럼 보였지만, 개발 팀의 유지 관리 부담을 세 배로 증가시키고 테스트 사례의 조합 폭발을 초래했습니다. 운송 요금 계산 논리에 대한 수정은 세 가지 고유한 생성 모듈에서 동기화된 업데이트가 필요했으며, QA 팀은 Microsoft의 보안 패치가 VBA 실행에 영향을 미칠 때마다 회귀 테스트의 악몽에 직면했습니다.

세 번째 접근은 동적 기능 감지 시스템을 구현하여 매크로 요구 사항과 대체 지침을 나타내는 메타데이터를 포함한 단일 XLSX 파일을 생성하는 것이었습니다. 웹 애플리케이션은 클라이언트의 User-Agent 문자열을 감지하여 적절한 보안 설정을 제안하며, 백엔드는 모든 UTF-8 내보내기에 BOM 마커를 포함하고 수식 주입 공격을 무효화하기 위해 동적 콘텐츠의 접두사에 탭 문자를 추가합니다. 매크로를 실행할 수 없는 클라이언트의 경우, 워크북에는 '계산된 값' 대비 '실시간 수식'을 명확하게 보여주는 시각적 지시기와 함께 숨겨진 워크시트에 미리 계산된 값이 포함되어 LibreOffice 사용자에게도 데이터의 정확성을 보장합니다.

우리는 파일 요원들과 본사 분석가들을 대상으로 파일 테스트를 진행한 후 솔루션 3을 선택했으며, 이는 사용자 경험과 장기적인 유지 관리 용이성 간의 균형을 이루었습니다. 기능 감지는 삭제된 접근 방식을 비교했을 때 지원 티켓을 40% 감소시켰으며 단일 코드베이스 요구 사항은 세 가지 중복 전략의 기술 부채를 피했습니다. 탭 접두사 보안 조치는 데이터 사용성에 영향을 미치지 않고 제3자 침투 테스트를 통과했으며, ExcelLibreOffice가 숫자 셀에서 선행 공백을 무시하지만 접두사가 있는 수식을 문자 그대로로 간주한다는 이점을 가졌습니다. 또한, BOM 헤더의 포함은 다른 플랫폼과의 호환성을 깨지 않고 국제 문자 렌더링 문제를 해결했습니다.

구현 후, 내보내기 기능은 모든 테스트된 플랫폼에서 99.2%의 성공적인 열기 및 렌더링 비율을 달성했습니다. "손상된 수식"과 관련된 지원 티켓은 첫 달 이내에 0으로 떨어졌으며, 아랍어 문자 렌더링 문제는 구형 Excel 설치에서 완전히 해결되었습니다. 보안 팀은 탭 접두사 방법론을 CSV 주입 공격에 대한 충분한 완화 조치로 공식적으로 승인했으며, 현장 요원들은 Power Query 연결의 점진적인 정체가 데이터 신선도에 대한 혼란을 방지했습니다.

후보자들이 자주 놓치는 것

어떻게 수동으로 검증하여 Power Query 연결이 OAuth 2.0 인증 토큰 만료를 Excel에서 우아하게 처리하는지, 특히 새로 고침 토큰이 Windows Credential Store에 저장되고 사용자가 예약된 새로 고침 시도 동안 오프라인인 경우에?

이 시나리오 테스트에는 시스템 시계와 네트워크 상태를 조작하여 실제 조건을 시뮬레이션해야 합니다. 먼저, OAuth 2.0이 필요한 API에 대해 Power Query 연결을 설정하고, MFA를 포함한 인증 흐름을 완료하며 초기 데이터 로드가 성공적으로 이루어지는지 확인합니다. 그런 다음, 모든 네트워크에서 머신을 분리하고 시스템 시계를 가속하여 토큰 만료를 강제한 후, 쿼리를 새로 고치려고 시도하여 Excel이 사용자 친화적인 "인증 필요" 대화를 표시하는지 혹은 처리되지 않은 HTTP 401 예외로 충돌하는지를 확인해야 합니다. 온라인인 경우, Windows Credential Store 항목을 Credential Manager를 사용하여 모니터링하여 오래된 토큰이 삭제되고 새로운 토큰이 적절한 DPAPI 암호화 플래그로 저장되는지 확인해야 합니다. 또한, Windows Credential Store 대신 macOS Keychain을 사용하는 Excel for Mac에서 재인증이 필요할 수 있어 자동화된 워크플로우에 영향을 미칠 수 있음을 고려해야 합니다.

HTTPS를 통해 제공되는 웹 애플리케이션에서 다운로드된 Excel 파일의 VBA 매크로 디지털 서명이 유효하고 신뢰할 수 있는지 확인하는 체계적인 접근 방식은 무엇인가요? 특히 Internet ExplorerEdgeMark of the Web (MOTW) Alternate Data Streams (ADS)를 추가하여 유효한 인증서가 있더라도 Protected View 또는 Windows Defender Application Control (WDAC) 차단을 트리거할 수 있습니다.

수동 테스트는 다운로드한 파일에 첨부된 Zone.Identifier 스트림의 검증을 포함해야 하며, Windows Explorer에서 파일 속성을 확인하여 "차단 해제" 체크박스가 보이는지 확인하거나 PowerShell Get-Content -Path file.xlsm -Stream Zone.Identifier를 사용할 수 있습니다. 보안 영역(인터넷, 신뢰할 수 있는 사이트, 로컬 인트라넷)에 따라 매크로가 활성화된 Excel에서 파일을 열고 MOTW가 매크로 실행을 방지하는 Protected View를 발생시키는지 확인하여야 합니다. WDAC 또는 Attack Surface Reduction (ASR) 규칙이 그룹 정책을 통해 활성화된 경우, 귀 조직의 코드 서명 인증서에서 서명된 매크로가 기계 수준에서 신뢰할 수 있는 게시자 인증서 저장소에 나열되어 있는지 확인하여야 합니다. 악성 인증서를 시뮬레이션하여 인증서 체인 검증을 테스트하고, Excel이 명확한 보안 경고와 함께 실행을 차단하는지 확인해야 합니다.

**사용자가 XLSX 파일을 CSV로 변환하여 내보내는 응용프로그램에서 CSV 주입 방지 기능을 테스트할 때, 파일이 다른 Excel 형식으로 저장될 때 수식 무효화 기술이 올바르게 유지되는지 어떻게 검증하나요? 특히 **CSV UTF-8 (쉼표로 구분)CSV (Macintosh) 또는 CSV (MS-DOS) 인코딩의 경우.

이는 다양한 Excel "다른 이름으로 저장" 형식에서 라운드 트립 변환 워크플로를 테스트해야 합니다. 이들 각각은 접두사 문자를 다르게 처리합니다. 먼저, 악의적인 페이로드가 있는 XLSX 파일을 생성하고 탭 문자가 접두사로 추가된 후, CSV UTF-8로 저장하고 **Notepad++**에서 다시 열어 탭이 여전히 존재하고 파일이 BOM 마커를 유지하는지 확인합니다. 그런 다음, 동일한 파일을 CSV (MS-DOS) 형식으로 저장하고 다시 열어 탭 문자가 제거되었거나 공백으로 변환되었는지 확인하여 수식 주입 취약점을 다시 활성화할 수 있습니다. Google SheetsLibreOffice Calc로 가져오기 테스트를 통해 이러한 응용프로그램이 접두사가 있는 접근 방식을 인정하는지를 확인하고, 이는 공백을 제거하거나 콘텐츠를 여전히 수식으로 해석하는지를 확인해야 합니다. 마지막으로, 무효화된 CSV 파일이 다시 Excel에 가져와질 때, 선행 탭이 최종 사용자에게 표시되지 않도록 해야 하며, 즉 Excel의 "텍스트 형식에 맞추기" 마법사가 정리된 셀 콘텐츠를 잘라내지 않도록 적절히 처리하는지를 확인해야 합니다.