면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.
클라우드가 아닌 온프레미스 환경에서 배포되는 내부 도구를 개발한 경험이 있습니다. 클라우드 환경과 달리 고객 인프라가 다양해 환경 차이로 인한 문제가 자주 발생했습니다. 가장 큰 도전은 설치 환경을 예측할 수 없다는 점이었는데, Docker로 패키징해서 런타임 의존성 문제를 줄이고 설치 스크립트에서 환경 사전 검증 단계를 추가했습니다.
온프레미스 제품에서 로그와 진단 도구 설계가 클라우드보다 훨씬 중요했는데, 직접 접근이 어려운 환경에서 원격 디버깅은 로그가 전부였습니다. 이 경험이 지금도 기능 설계 전에 모니터링 가능성을 먼저 고려하는 습관으로 이어졌습니다.
온프레미스 환경에서 배포하면서 고객 인프라 환경이 예상과 달라 설치에 실패하는 상황이 생겼습니다. Docker로 패키징했는데 특정 OS 버전에서 컨테이너 런타임 설정이 달라 시작이 안 됐습니다. 이 환경을 재현하지 못한 채 원인을 추측하다가 시간이 길어졌습니다.
고객사 담당자에게 환경 정보를 상세히 요청하고, 팀 내 인프라 경험이 있는 선배에게 상황을 공유했습니다. 선배가 OS 커널 버전과 컨테이너 런타임 조합에서 알려진 이슈가 있는지 확인하는 방법을 알려줬고, 그 방향으로 좁혀 나가서 원인을 찾을 수 있었습니다.
이 경험에서 온프레미스 배포는 고객 환경의 다양성이 클라우드보다 훨씬 크기 때문에, 모르는 환경 문제에서 혼자 추측하는 것보다 환경 정보를 먼저 수집하고 경험 있는 사람과 공유하는 것이 훨씬 빠른 방법이라는 것을 배웠습니다.
온프레미스 배포에서 겪은 환경 문제들을 문서로 남기지 않으면 다음 배포 시 같은 문제가 반복된다는 것을 경험했습니다.
첫 배포 이후 비슷한 환경 이슈가 두 번 더 발생했는데, 매번 처음부터 원인을 찾는 과정이 반복됐습니다. 이전 이슈 해결 방법이 어딘가에 남아 있었지만 체계적으로 정리되지 않아서 쉽게 찾을 수 없었습니다.
이후 배포 후 발생한 환경 이슈를 '증상-원인-해결 방법'으로 정리하는 로그를 만들었습니다. 다음 배포 시 비슷한 증상이 나오면 이 로그를 먼저 확인하도록 팀 프로세스에 포함했습니다. 세 번째 비슷한 환경 이슈에서 로그를 참조해 빠르게 해결한 것을 확인하면서, 문서화의 효과를 실감했습니다.
온프레미스 배포는 환경이 다양해 완전히 같은 문제가 반복되지는 않지만, 비슷한 유형의 문제는 반복됩니다. 해결 이력을 쌓는 것이 가장 실용적인 대응 자산이라는 생각이 남아 있습니다.
같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.
진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.