트러블 슈팅 - C# path

트러블 상황

동료분이 3일 정도 고민하던 문제가 있었는데 동료분의 연차로 인해 제가 이 문제를 이어받게 되었습니다. (1번, 2번은 어떻게 해결이 된 상황이었습니다)

dll을 추가하였고 dll 안에서 또 다른 프로그램을 실행해서 웹서비스를 통해 다시 경로값을 string 배열로 리턴해주는 구조였습니다. 서버에 올려서 사용해야 했기 때문에 디버깅이나 오류 메세지를 보기도 힘든 상황이었는데 값의 리턴이 성공할 때도 있고 실패할 때도 있었습니다.

트러블 원인 및 해결

1. 서버에서 dll 안에 또 다른 프로그램 접속(웹서비스 포함)시 방화벽 문제

2. 서버에서 폴더 접근 권한 문제

3. System.IO.File.ReadAllBytes() 는 .(dot)으로 확장자를 구분하던 문제  

(1번, 2번은 해결된 상황이었고 3번을 제가 해결해야 하는 상황)

3번은 아직 어떠한 문제인지 몰랐으나 수많은 삽질의 경험으로 'path에 문제가 있을 확률이 높겠구나'란 생각부터 했습니다. 그래서 처음에는 path에 한글 인코딩 문제로 보았고 검색해보니 비슷한 이슈들이 조금 있었습니다. C#의 default 인코딩은 Unicode(UTF-16)입니다. 그래서 UTF-8로 고치면 무언가 바뀌지 않을까하고 시도해보았지만 결국 path의 인코딩 값은 같았습니다.

공백과 이것저것 시험해보았지만 원인을 파악하기 힘들어서 최후의 수단으로 값을 성공적으로 리턴하는 path를 기준으로 환경을 비슷하게 맞추기였습니다. 처음엔 한글, 공백, _ 등 변수가 있을 만한 것들을 제외하고 경로를 단순화하니 실행히 되었습니다. 그렇게 한 단계 한 단계 하다보니 기존 경로에 0 . xxxx 라는 폴더명이 걸렸습니다.

이제껏 다른 곳에 정신이 팔려있어 보지 못했던 그 점 하나가 원인이였던 것입니다. 생각해보면 path 하나를 인자로 사용하는 함수가 확장자를 판단할 때 . 하나로 나눌 수 밖에 없는 것은 너무나도 당연한 것이었습니다. 그래서 . 을 제외한 경로로 새로 설정하고 돌려봤더니 아니나 다를 까 성공. 배포 또한 정상적으로 진행할 수 있었습니다.

느낀 점

이전에는 어떤 트러블을 만나면 무엇이 원인인지 정의하는 것에 시간이 많이 소요되었지만 확실히 정의에 드는 시간이 단축 되었습니다. 그러나 아직 문제를 해결 할 때 논리에 입각한 정확한 해결 방법보다는 경험에 의존한 해결 방식을 사용하고 있다는 것을 깨달았습니다. 경험으로 해결하는 것이 나쁜 것은 아닐 수 있지만 이제껏 경험해보지 못한 트러블에 대해서는 매우 취약할 수 밖에 없는 것이 사실입니다. 

하나를 공부하더라도 정확하게 공부하여 튼튼한 기초를 쌓는 것이 좋은 개발자가 되는 가장 빠른 길일 것입니다.