이 글에 대한 답입니다.

들은 이야기로만 보면 stereotypical인거 같은데 맞다면 고생하실겁니다.

아마 대충 hand-wavy 로 설명하거나 어물거리거나 하려 할 텐데 좀 독하게 하나하나 물어봐야 합니다.

이래야 하는 이유는 둘입니다.

첫째로 그렇게 하지 않으면 쓸만한 정보를 못 얻을 가능성이 높으며,

둘째로 그렇게 봐야 추후에도 최소한의 긴장을 해 주기 때문입니다.

어드민은 잘 모르긴 한데, IIS 등을 쓴다면 의외로 쉽게 풀릴 수도 있습니다.

 - remote server로 로그인/로그아웃 procedure(꼬여있는 경우가 많습니다. 내부 서버라면 windows authentication으로 끝내는 경우도 많습니다만)

 - database structure. : 보통 가장 중요한 정보는 작은 table 한두개에 들어있는 경우가 많습니다. tbl_user, tbl_account 따위에 많습니다. 특히 encryption의 경우에는 어떻게 되는지(encryption method, decryption method, etc) 체크해두시면 후일 disaster를 최소 한번은 피할 수 있을 겁니다.

 여기에 첨언하자면 stored procedure 등을 어디에서 부르는지 알고 하나하나 물어보시면 좋습니다. MSSQL 스튜디오에는 데이터베이스 밑에 Programmability 탭이 있는데, 이 밑에 있는 것만 숙지해도 엔간한 건 해결됩니다.

 - 매일 어떤 일을 하는지 알아보세요. 가장 좋은 건 일을 오라고 해서 어떻게 하루를 보내는지 며칠간 관찰해보는 게 가장 좋긴 합니다만...

그리고 여기부턴 꽤 중요한 건데,

 - web.config : 윈도우 서버 문제의 태반은 이놈에서 옵니다. 이놈하고 build target이 꼬입니다. 특히 .NET 2.0에서 3.5~4.0+로 넘어가는데 (2008에서 2012로 migration하신다고 말씀하셨으니) dll 버전때문에 에러내는 경우가 많습니다.

 필히 하나하나 다 물어보세요. 특히 Web.config에서 디파인되는 Assembly 와 project file reference가 다른 경우엔 하나하나 다 트래킹을 해 줘야 합니다.

 여기에서 매우 중요합니다. 그 사람이 얼마나 오래 일했어도 이걸 다 알고 있을 수는 없습니다. 계속해서 몰아가다 보면 자기가 아는 소스로 검색해서 찾거나 해서 보여줄 겁니다. 여기에서 이 사람이 어디에서 어떤 정보를 얻었는지를 기록해두시면 후에 큰 도움이 될 겁니다.

어드민의 반은 경험입니다. 이 사람이 문제를 어떻게 푸는지를 알면 반 이상은 됩니다.

개인적으로 이 사람을 옆에 앉혀둘 때 히스토리 관련 애드온을 켜둔 브라우저로 작업을 하라고 종용하시는 걸 추천합니다.

크롬의 Better History 애드온을 추천합니다.(https://chrome.google.com/webstore/detail/better-history/obciceimmggglbmelaidpjlmodcebijb?hl=en)

혹시라도 이 사람이 자기 노트북을 들고 오면, 북마크나 브라우징 히스토리 따위를 백업해두세요.

 - 서버가 돌리는 닷넷 프레임워크 버전 vs why they don't match. 서버가 4.0을 서포트하는데 2.0을 돌린다면 이유가 분명히 있습니다.

특히 2.0은 아직까지도 현역일 정도로 성능이 좋고 또 2.0을 타게팅한 stable한 라이브러리가 많습니다.

어드민은 경험이 없어 더 자세하게는 설명하지 못하겠군요.

해커뉴스 Ask HN 등으로 공개적으로 물어보는 건 어떨까요. 스택오버플로우도 좋고요.