놀고 먹고픈 개발자

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

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

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

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

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

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

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

예를 들어서 )

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

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

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

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

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

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

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

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

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

한층 간결해졌다.

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

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

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

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

[사람-관계-일]
힘들다. 사람도, 일도 모든 것에 지쳐가고 있다.
몇 번이나 다시 일어서려 했지만 얼마 못 가 자꾸 주저앉게 된다.
무엇이 문제인지 모르겠다. 사실은 아는데 모르는 척하는 걸까.
모든 것이 싫어지는 요즘이다.
내가 뭘 잘하는지도 모르겠고, 일을 하면서 내 자존감이 너무 낮아져서 회사에 출근하기가 싫은 마음도 생긴다.

[ '나' 분석 ]
나는 왜 우울한가.
지금
왜 이렇게도 우울한가.
왜 이렇게도 기분이 다운되어 있나.
왜 이렇게도 무기력한가.
스스로 답답함을 느끼는 순간
- 상대방이 한 말을 한 번에 이해를 하지 못한다.
- 한 번 얘기한 걸 기억하지 못하고, 두 번 이상 말하게 만든다.
- 이해가 느리다.
=> 결과 : 나의 부족함 때문에 자신감이 사라지고 -> 그러니까 자존감이 낮아지고..
 -> 회사가기 싫고. -> 부정적인 생각이 들고. 악순환이네;ㅜ

.

.

.

.

[근본적인 원인과 해결책]
이렇게 글을 작성하면서 느낀 건데, '속도의 차이' 에서 해결책을 찾을 수 있을 것 같다.

나는 비전공 개발자이다.

비전공에 대한 편견이 싫어서 스스로 구분 짓는 걸 너무나 싫어하는데, 가끔은 정말로 전공자와 비전공자의 차이가 있는 것인지 의심이 들 때가 있다. 특히 동료를 보면 그렇게 느껴진다.
자격지심일까.
그 친구는 이해가 정말 빠르다. 자기가 이해한 것을 남에게 설명을 잘한다.
가장 큰 장점은 문제에 대한 핵심을 정말 잘 파악한다. 그래서 해결을 하기 위한 솔루션도 금방 찾는다.
빠르게 문제의 핵심을 파악해서 어디 부분을 어떻게 고쳐야 할지 정확하게 아는 것이다.
일 잘하는 사람은 이렇구나를 이 친구에게서 느끼고 있다.

실무를 접하며 개발자라는 직업이 단순히 기능을 만드는 것이 아님을 알게 되었다.
이 직업의 가장 큰 핵심 역량은 문제 파악과 해결 능력이다..
하지만, 생각해보면 모든 직업이 그렇지 않을까?
우리가 마주하는 모든 상황에는 늘 문제가 존재한다. 마케팅도, 영업도, 기획도, 경영도, 모두 분야에서 말이다.
그 어떤 직업에서든 요구하는 핵심 역량은 문제 해결 능력인 것이다.
실무를 하다 보니까 취업준비 때 왜 그렇게도 기업들이 문제 해결 능력이라는 역량에 대해서 보고 싶어 했는지 알겠다.
이 역량이 정말로 선천적으로 타고나야만 가능할까? 그건 아닌 것 같다.
어떤 문제를 파악하는 데에 유전적 요소가 있는 것은 아니니까.
내가 내린 정답은 '빠른 이해도'이다..
이해도 이해지만, 기업은 ‘빠른 이해를 추구한다. 우리에게 주어진 시간은 한정적이기 때문이다.
문제를 정확히 파악해도, 주어진 시간 내에 ‘빠르게’ 하는 것은 능력인 것이다.
주변에 일 잘하는 동료들을 보면 얼추 맞아떨어지는 얘기라고 생각된다.
반면, 나는 말이지... 빠르게......가 안된다...
속도가 느리다.
속도는 노력으로 되는 부분일까?
.
.
.
.( 생각 중 )
.
.
.
- 나는 된다고 생각한다!
왜 그런지는 먼저 일 잘하는 그들을 분석해보자.

그들은 왜 그렇게도 속도가 빠를까?
- 깊은 지식과 다양한 경험이 그것의 기반이지 않을까.
: 지식은 그들이 배운 전공 지식과 다양한 프로젝트에서 비롯된 경험들인 것이다.
그럼 나는 그들의 언저리라도 가려면 어떤 노력을 해야 하는가?
- 부지런히 (정확한)개념을 쌓아야 한다. ( 전공지식이든, 뭐든, 정확한 개념 숙지를 하며 기반을 다져야 한다. )
- 다양한 프로젝트 경험을 해야 한다.
나의 문제는 정. 확. 히. 부족한 나의 지식과 경험에서 비롯된 일처리의 어려움 이 그것이었다. (이마 탁!)
정답은?
-> 시간을 내어 지식과 경험을 쌓으면 된다.

단지 이것이 정말 어렵다는 것이다. 그래서 어쩌면 나는 문제에 대한 정답을 알고 있었으면서 모른 척하지 않았던 게 아닐까 의구심이 든다. 나는 그들의 하이라이트만 보고 있었던 것이다.
비유하자면 탑스타의 화려한 모습만 보고, 그 자리에 오르기까지의 과정은 보지 않은 것과 같은 것이다.
그들도 분명 시간을 들여 공부하고 시행착오를 겪었던 경험이 있었을 텐데 말이다.
어쩌면 내 스스로가 자존감을 갉아먹고 있었던 것이 아닐지도 모른다는 생각이 들었다.
그래서 비전공자는 전공자보다 더 많은 노력을 기울여야 한다.
이 사실은 저명한 사실이지만, 자꾸 잊어버리게 된다.
이 분야로 진로를 변경할 때 나는 어떤 초심이었는지 되새겨볼 필요가 있다.

뒤늦은 성장에는 뼈를 깎는 고통이 수반되어야하는 것임을 느끼는 요즘이다.

글의 시작은 우울했지만, 이렇게 나를 분석하고 (사실은 알고 있었던) 정답을 알게 되니까 다시 자신감이 생긴다.
내일은 또 어떤 면박을 당할지, 어떤 예상치 못한 일들이 기다리고 있을지 정말 두렵고 마주하기 싫지만,
그럼에도 불구하고 내일은 오며, 머피든 샐리든 둘 중의 하나의 법칙에 따라 일어날 일은 일어나므로,
굴하지 않고! 자신감 있게! 모르면 알면 되니까! 마인드로 헤쳐나가 보겠다.

출처 : https://techblog.woowahan.com/8484/

어느 날 기술블로그 라는 것에 꽂혀 찾아보다가 해당 글을 발견했고, 그분들의 소중한 경험이 녹아있는 공부방법 글을 읽다가 감명받아 몇 글자 끄적여 보았다. (중간중간 그분들의 글을 인용하였습니다.) 

개발 철학에 대한 고민

"어떤 개발자가 끝까지 살아남을 수 있을까.
어떤 개발자가 유능한 리더가 될 수 있을까.
어떤 개발자가 효율적으로 일을 할 수 있을까."

좋은 개발자가 되기 위해서는 어떤 노력들이 필요할까.

학습방법
개발에 대해서 나만의 공부 방법을 아직 찾지 못한 것 같다. 어떻게 해야할지는 알겠으나, 그 방법을 온전히 나의 것으로 만들지 못했다. 나만의 학습방법을 찾는 것이 중요할 것 같다.

기억장치
개발을 잘 하는 것은 내가 짠 코드에 대한 기억, 내가 배운 개념의 기억이 모두 탑재되어 있어야 한다.
적어도 내가 짠 코드, 내가 진행하고 있는 프로젝트에 대해서는 정확한 구조 및 상세 내용을 암기해서라도 내 머릿속에 박혀 있어야한다. 그게 일 처리 속도를 올려주며, 소통을 원활하게 할 수 있게 해줄 수 있는 지름길 같다.

왜라는 이유
내가 코드를 그런 방식으로 짠 이유. 즉 논리가 머릿속에 박혀야 한다. 그래야 나만의 소신으로 의견을 낼 수 있기 때문이다. 그렇지 않으면 말문이 막히게 되는 그런.. 마주하기 싫은 상황에 내놓이게 될 것이다.
항상 모든 상황에는 근본적인 문제가 있다. 그 문제를 해결하기 위해 기능 위에 기능이 얹어지고 덩치가 불어난게 아닐까.
왜라는 질문에 왜를 붙이며 생각을 넓혀 나가자.

개발을 바라보는 태도
"지금 내가 해야하는 일은 완벽한 정답을 찾는 것이 아닌 계속해서 틀리며 이게 왜 틀린지 알아는 것이 정말 중요하다."
그것들은 정확히 내 머릿속에 입력해야되고, 잊어버리지 않아야 한다. 계속해서 리마인드 하는 것이 정말정말 중요하다. 특히 나같은 경우는 말이다.

"누군가는 정말 섬세하게 공부하고, 누군가는 개발자로서의 신념이 뚜렷하며, 누군가는 정말 재미있게 개발 자체를 즐긴다. 또 누군가는 커뮤니케이션을 정말 잘하고, 말을 상냥하게 하며, 리더쉽이 있다. 이렇게 제 각기로 빛나는 사람들 사이에 있다 보면 끊임없이 스스로를 되돌아보게 되고, 더 좋은 개발자를 넘어서 더 좋은 사람이 되어갈 수 있을 것 같은 기대감에 휩싸인다."

비난 받는 것에 두려워 하지 말며, 좋은 기회로 발판 삼자. 

나는 할 수 있다.