LabHub

디버깅 실전 · 환경 문제 구분 · 실습

환경 차이 좁히기

LabHub 에서 이어서 보기

목표

"우리 서버에서는 되는데요" 라는 말을 들었을 때, 코드가 아니라 환경을 의심하고 그 차이를 30분 안에 특정할 수 있게 됩니다.

왜 중요한가

환경 문제는 코드 결함보다 찾기 어렵습니다. 코드는 읽으면 보이지만 환경은 읽을 것이 없기 때문입니다. 그래서 순서가 필요하고, 그 순서를 스크립트로 굳혀 두면 고객사와의 왕복이 세 번에서 한 번으로 줄어듭니다.

이 실습에서 다루는 세 가지는 현장 빈도 순입니다. 환경변수는 설정한 곳과 읽는 곳이 다른 것이 대부분입니다. 인코딩은 한글 고객 데이터에서 압도적으로 자주 터지는데, 윈도우에서 만들어진 CSV 는 UTF-8 이 아니라 EUC-KR(CP949)인 경우가 많고, 잘못 읽힌 문자열은 오류 없이 조용히 저장됐다가 몇 주 뒤 검색이 안 된다는 신고로 돌아옵니다. 권한은 자격 증명 파일에서 특히 무겁습니다 — 토큰이 644 로 놓여 있으면 같은 서버의 다른 사용자가 전부 읽을 수 있고, 보안 점검에서 이것 하나로 프로젝트 전체의 신뢰가 깎입니다.

/opt/app/envcheck.sh 는 고칠 대상이 아닙니다. 환경을 거기에 맞추는 것이 과제입니다.

단계

1. /root/env 디렉터리를 만드세요.
2. bash /opt/app/envcheck.sh 를 그대로 실행해 실패 출력을 /root/env/fail.txt 에 저장하세요.
3. 실패 메시지가 지목한 환경변수 이름을 /root/env/missing_var.txt 에 적으세요.
4. /opt/data/customers_kr.csv 를 UTF-8 로 변환해 /root/env/customers_utf8.csv 로 저장하세요. 한글이 제대로 읽혀야 합니다.
5. 변환한 파일에서 헤더를 뺀 고객 행 수를 /root/env/kr_rows.txt 에 적으세요.
6. /root/env/token.txt 를 만들고 권한을 600 으로 맞추세요.
7. 필요한 환경변수를 주고 envcheck.sh 를 다시 실행해, 성공 출력을 /root/env/result.txt 에 저장하세요.
8. /root/env/report.md 에 무엇이 달랐는지 적으세요. 환경변수 이름, 원본 파일의 인코딩 이름, 적용한 권한 숫자가 모두 들어가야 합니다.

참고

단계 8개

  1. 작업 디렉터리 만들기
  2. 실패 재현해서 저장하기
  3. 누락된 환경변수 이름 적기
  4. 한글 CSV 되살리기
  5. 고객 행 수 세기
  6. 토큰 파일에 최소 권한 주기
  7. 점검 통과시키기
  8. 환경 차이 보고서 쓰기