놀고 먹고픈 개발자

개발자로서 이메일 작성해야 할 때 막막한 순간이 한두번이 아니다.
오늘은 그 어려움을 공유하고자 글을 끄적이게 되었다.

나 . 름 . 문과 출신이라 글쓰기는 문제없겠거니~ 생각했지만, 개발 분야에서는 완~전 신생아 걸음마 수준의 글쓰기 능력으로 전락해버렸다. (사실이늬?)

필자가 이메일을 작성하면서 어려움을 느끼는 순간은 다음과 같은 경우이다.

(일단 쫌 있어보이게, 쫌 전문적으로, 적어도 내가 신입티는 나지 않게 작성해야한다는 생각을 가지고 시작한다.)

1. 나는 이해됐는데.. 이걸 어떻게 설명하지..? 아니 이걸 글로 어떻게 써야돼..? 하는 순간들
- 대상
 > 고객인 경우 : 문의 요청을 하거나 문의 답변을 작성할 때
 > 상사인 경우 : 이슈 사항에 대해 보고할 때

2. 개발자언어를 사용자언어로 전환해야 하는 순간들
 - 개발적이지만 너~~~무 개발적인이지 않은 단어를 선택해서 전달해야할 때

3. 1번 2번 둘 다 상황일 때.. ( 최악이다.. ㅜ0ㅜ )

예를 들어서 )

상황 : 스토리지에 연결해서 저장되어 있는 메일 파일을 가져와서 보여줘야 하는데 보이지 않는 장애가 발생함.

원인은 업로드 시 스토리지에 한 번 연결하여 업로드 후, 완료되면 연결을 끊어줘야 하는데 끊어주지 않아서 다음 스토리지 연결할 때 연결 오류가 발생하여 메일이 열리지 않았던 것이다.

근본적인 원인을 찾아보니 소스상에서 InputStream 사용을 해놓고, close 해주지 않아 발생한 문제였다. (try-catch에서 finally{} 부분의 자원해제.. )
곧바로 누락된 close 처리를 하여 해결할 수 있었다.

이런 장애 이슈 발생 시,  사용자에게 해당 상황과 원인/해결을 개발적으로 전문적이면서 그렇게 개발적인 언어를 사용하지 않고 어떻게 설명을 해야할까.

필자가 초안으로 작성했던 건 다음과 같다.
<수정 전>

나름 스스로 잘 작성했다고 생각하고 동료에게 검토요청을 하였으나, 수정할 부분이 꽤 있었다..
제일 중요한 부분은 원인과 조치 사항 부분이다.

원인이 저건 맞지만, 저렇게 작성하였을 때 문제는 고객(사용자)에게 '우리 소스가 애초에 개발이 잘못되었다.' 라는 걸 너.무. 솔직하게 이실직고 하는 것밖에 안되는 것이었다. 우리회사의 신뢰성을 깨뜨리는 것밖에..

업무 처리를 하면서 상황에 맞게 처리하는 것을 우리는 "유연성"이라고 하는데, 필자가 작성한 부분이 딱 그 유연성이 떨어지는 문장이었다.

동료가 제안한 문장은 '커넥션 풀부족으로 인한 오류' 였다.
inputStream 이니, close 니 하는 너~~무 개발적인 언어가 아니면서 동시에 전문적인 개발 언어를 사용자화한 문장이었다.
여기서 말하는 사용자는 전문적으로 개발을 잘 아는 사람은 아니지만 비슷한 분야에서 일하고 있는 전산관리자일 가능성이 매우 크다.
그렇게 생각해보면 관리자 입장에서 충분히 이해할 수 있는 문장일 것이라는 생각이 들었다.
어떻게 저런 문장을 생각할 수 있었는지.. 놀라울 따름이었다. 동료의 조언을 받고 다음과 같이 수정하였다.
<수정 후>

한층 간결해졌다.

예시를 들어 설명하다 보니, 앞으로 메일을 작성할 때 어떤 부분을 더 고려해야할지 조금은 알 것 같다.

개발기술 관련된 서적을 많이 찾아보는 것도 도움이 될 것 같다.
우리가 이해하고 소스적인 부분을 어떻게 공통(대상이 누구든 이해할 수 있는) IT 용어로 전환해서 작성했는지도 눈여겨 봐야할 것이다.

읽어주셔서 감사합니다 :-)

+) 가끔씩 이렇게 메일 작성하면서 곤란하거나 어려웠던 부분을 공유해보겠습니다.!