개발자의 삶 - 개발자의 글 쓰기

오랜만에 괜찮은 글이 있어 내 블로그로 퍼왔다.

좋은글이니 한번 읽어보자.

출처 : (https://subokim.wordpress.com/2016/09/22/wt-of-dever/)

---------------------------------------------------------------------

우스갯 소리로 개발자가 되면, 코드만 들여다 보고 있을 줄 알았습니다.

성격 때문인지 이것저것 따져 묻기 좋아해서 인문학적 소통에는 소질이 없었습니다.

나이가 들면서 다소 발전했음에도 불구하고 여전히 소통은 어렵습니다.

글쓰기를 배우면 좀 쉬울 줄 알았습니다. 하지만, 글로 정리하면

경험이 일반화 된 이론처럼 보여질 수 있습니다. 그러면 글이 싸움꾼을 불러 옵니다.

경험이 필요한 사람에게 읽혀서 참고가 되면 좋을텐데 그렇지 않습니다.

다른 경험을 가진 사람은 괜히 공격을 합니다. 아직 경험하지 못한 사람은

머릿 속으로 상상을 해서 공격 합니다. 그래서 아직 정리 되지 못한

글 들이 메모장에 차곡차곡 쌓이고만 있습니다.

글솜씨가 필요한 경우

각설하고, 개발자가 되어서도 글 쓰기를 해야 합니다.

코드를 짜는 것과는 다릅니다.

어떤 글쓰기를 해야 하는지 정리해 보았습니다.

이글의 대상은 [사회 초년생 개발자]들입니다.

01. 소스에 주석달기

옛날 언어(COBOL …)는 절차형 언어였습니다. 모듈 단위로 개발했습니다.

그래서 모듈의 맨 앞 부분에 주석을 달았습니다. 하지만,

자바와 같은 객체 지향언어는 그러기 힘듭니다. 객체의 성질과 움직임을

모두 정리해야 하는데 양이 만만치 않습니다. 이벤트 처리방식이면

더욱 주석을 붙이기가 어렵습니다. 그래서 요즘은 과거와 같은

긴 글 주석은 잘 사용하지 않습니다. 대신 설계서를 이용합니다.

참고로 옛날에는 어플리케이션이 복잡하지 않아 소스에 직접 주석을 달고,

전체적인 구성은 수첩에 그려서 관리했습니다. 요즘은 어플리케이션이

복잡해져서 설계서가 없으면 전체를 이해하기 어렵습니다. 

더구나 요즘은 이클립스 같은 IDE가 훌륭합니다. 그래서,

굳이 긴 주석 없이도 소스분석이 어렵지 않습니다. 그러다보니 최근에는

주석달기가 [자연어 기반 네이밍]이나 [간단한 개발자 노트(위키)]로

대체되고 있습니다. (어플리케이션 설계서를 Free Format으로 만듭니다.

그래서 넓은 의미의 주석이라고 할 수 있습니다.) SI 현장에서는 아직도

관습을 따르고 있습니다. 그래서 과거식 주석을 강요하는 경우도 있습니다.

어쨌든 주석달기는 꽤 재미있는 글쓰기입니다. 주석을 읽는 사람은

내가 아닌 다른 개발자입니다. 그리고 왜 이게 만들어졌는지 모르는 사람입니다.

하지만, 나 다음으로 이 모듈을 고칠 책임자들입니다.

그래서 코드와 주석을 보면 만든 개발자의 성품을 짐작할 수 있습니다.

다음 개발자에게 부끄럽지 않으려면 주석을 포함해서

[개발문서 잘만들기]를 해야 합니다. 깔끔한 엑셀문서가 아닙니다.

다음 개발자가 잘 유지보수할 수 있도록 [필요한 내용]들을 만들어야 합니다.

※ 참고로 최근에 ‘주석 잘달기 캠페인’을 벌이는 곳이 있다면,

윗 분이 현장을 떠난지 오래 되거나 개발에 대한 이해가

부족한 분일 가능성이 큽니다. SI 현장에서는 흔한 일입니다.

QA가 달라고 합니다. / 반면 주석을 다양하게 달 수 있는데

이건 이 포스팅에서는 패쓰합니다.

02. 장애 보고서 쓰기

장애 보고서 쓰기를 어려워 하는 개발자들이 많습니다.

보고서를 써줘도 자꾸 뭔가를 묻기 때문입니다. 잘 설명해주면 오히려

대안을 내라고 닥달하거나, 능력 밖의 추가 조치를 요구하기도 합니다.

그래서 잘 써주기도 그렇고 안 써주기도 그런 것이 장애보고서입니다.

하지만, 장애 보고서는 개발자 밖에 쓸 수가 없습니다.

왜냐하면 소프트웨어도 일종의 기계적(전자공학적) 산출물이어서

개발자가 아니면 원인을 알 수 없기 때문입니다.

그런데 재미난 것은 장애 보고서를 보는 사람은 개발자가 아닙니다.

대부분 인문학적 소양에 기반을 한 관리자들입니다.

좋은 보고서는 관리자들 수준에 맞춘 것입니다.

그리고 그들에게 앞으로 어떻게 하라는 지침까지 담으면 좋습니다.

하지만 이런 보고서는 공학도인 개발자가 쓰기에 너무 어렵습니다.

인문학적 언어는 공학도의 관점에서 수많은 어폐와 건너뛰기가 들어 있기 때문입니다.

03. 시스템 제안서 쓰기

외주용역을 하는 업체에 취업을 하게 되면, 제안서를 쓸 일이 많습니다.

제안서란 고객의 문제를 풀기 위해 필요한 [추상화된 가상 시스템 설계서]입니다.

회사입장에서는 외주용역을 수주하기 위한(돈을 벌기 위한) 일종의 영업용 자료입니다.

이 제안서를 보는 사람들은 고객사의 사업담당자 또는 전산실 직원들입니다.

둘 다 내가 제시하는 해결책을 전혀 모르는 사람들입니다.

그런데 이 제안서는 결코 영업이 쓸 수 없습니다.

공학적 고민의 결과물이기 때문입니다. 적어도 구현을 책임질 사람 PM이 써야 합니다.

그리고 디테일은 개발할 개발자가 써야 합니다. 그래야만 가상의 해결책이

논리적으로 말이 됩니다. 그래야만 수주 후에도 예상 범위 내에서

원활히 구현할 수 있습니다. 또, 그래야만 초기 예산의 범위에서 벗어나지 않게 됩니다.

그런데, 문제는 이 제안서는 개발자 시각에서는 인문학적 요소가

풍부한 소설책이라는 것입니다. Free Format 이니까 파워포인트를 많이 씁니다.

그래서 제안서는 개발자이면서 훈련된 사람만 쓸 수 있습니다.

즉, 훈련이 필요합니다. 참고로 국어시간에 배우는 것과는

완전히 달라 필드에서 배워야 합니다.

개발자 생활을 하다 보면 반드시 제안서는 거의 한 번씩은 쓰게 됩니다.

관련이 없다면 잘 쓰지 않아도 되지만, 제안서를 읽을 수는 있어야 합니다.

이것을 구현하는 사람이 내가 될 수 있기 때문입니다.

04. 다양한 보고서 쓰기

일을 잘해서 진급을 하다 보면 팀장을 넘어서게 됩니다.

팀장을 넘어서면 대부분 보고서 속에서 하루를 보내게 됩니다.

또는, 강연 자료나 연구보고서를 만들어야 할 일들이 있습니다.

보고서란 다양한 이해관계자를 설득하거나 이해시키기 위해

그들의 용어로 변환되는 과정입니다. 문제는 이 과정에서 축약과 변형이 일어납니다.

어떤 것은 키워집니다.  그래서 좋은 문서는

인용될 수는 있어도 재활용되지는 않습니다.

개발자가 어플리케이션을 이렇게 짜는 것은 절대 안됩니다.

임의로 데이터를 변형한다는 것은 의사가 히포크라테스 선서를 어기는 것과 같습니다.

하지만, 보고는 그런 걸 해야 합니다. 그래서 개발자에게는 매우 어려운 일입니다.

이 축약과 변형의 원리를 이해하고 배워야 합니다.

그래서 필요한 것들이 글쓰기 스킬들입니다.

어떻게 글을 쓸까?

그런데 뼈속까지 개발자인 사람들에게 글쓰기는 너무도 어려운 Language입니다.

팀장과 임원들간의 의사소통도 그렇습니다.

아무리 장애보고서를 상세히 써줘도 한 마디로 요약해서 달라고 합니다.

이럴 때 고민해 볼만한 내용이 있어 스크랩해 봅니다.

01.도서 [대통령의 글쓰기]에서 말하는 글쓰기 요령

1.자네 글이 아닌 내 글을 써주게. 나만의 표현방식이 있네. 그걸 존중해주게.

2.자신 없고 힘이 빠지는 말투는 싫네. '~같다'는 표현은 삼가게.

3.'부족한'제가와 같이 형식적이고 과도한 겸양도 예의가 아니네.

4.굳이 다 말하려고 할 필요 없네. 경우에 따라서는 질문을 던지는 것으로도 연설문이 될 수 있네.

5.비유는 너무 많아도 좋지 않네.

6.쉽고 친근하게 쓰게.

7.글의 목적이 무엇인지 잘 생각해보고 쓰게. 설득인지, 설명인지, 반박인지, 감동인지.

8.연설문에는 '~등'이란 표현은 쓰지 말게. 연설의 힘을 떨어뜨리네.

9.때로는 같은 말을 되풀이하는 것도 방법이네.

10.짧고 간결하게 쓰게. 군더더기야말로 글쓰기의 최대 적이네.

11.수식어는 최대한 줄이게. 진정성을 해칠 수 있네.

12.기왕이면 스케일을 크게 그리게.

13.일반론은 싫네. 누구나 하는 얘기 말고 내 얘기를 하고 싶네.

14.치켜세울 일이 있으면 아낌없이 치켜세우게. 돈 드는거 아니네.

15.문장은 자를 수 있으면 최대한 잘라서 단문으로 써주게. 탁탁 치고 가야 힘이 있네.

16.접속사를 꼭 넣어야 된다고 생각하지 말게. 없어도 사람들은 전체 흐름으로 이해하네.

17.통계 수치는 글의 신뢰를 높일 수 있네.

18.상징적이고 압축적인, 머리에 콕 박히는 말을 찾아보게.

19.글은 자연스러운게 좋네. 인위적으로 고치려고 하지말게.

20.중언부언하는 것은 절대 용납 못하네.

21.반복은 좋지만 중복은 안되네.

22.책임질 수 없는 말은 넣지 말게.

23.중요한 것을 앞에 배치하게. 사람들은 뒤를 잘 안보네. 단락 맨 앞에 명제를 던지고,

뒤에 설명하는 식으로 서술하는 것을 좋아하네.

24.사례는 많이 들어도 상관없네.

25.한 문장 안에서는 한 가지 사실만을 언급해주게. 헷갈리네.

26.나열은 하는 것도 방법이네. '북핵 문제, 이라크 파병, 대선자금 수사...'

나열만으로도 당시 상황의 어려움을 전달할 수 있지 않나?

27.같은 메시지는 한 곳으로 응집력 있게 몰아주게. 이곳저곳에 출몰하지 않도록

28.평소에 사용하는 말을 쓰는 것이 좋네. 영토보다는 땅. 식사보다는 밥,

치하보다는 칭찬이 낫지 않을까?

29.글은 논리가 기본이네. 멋있는 글을 쓰려다가 논리가 틀어지면 아무것도 안 되네.

30.이전에 한 말들과 일관성을 유지해야 하네.

31.여러 가지로 해석될 수 있는 표현은 쓰지말게. 모호한 것은 때로 도움이 되기도 하지만,

지금 이 시대가 가는 방향과 맞지 않네.

32.단 한 줄로 표현할 수 있는 주제가 생각나지 않으면, 그 글은 써서는 안되는 글이네.

02.어떤 곳에 해당되는 내용인가?

개발자의 의사소통 레벨이 높아지는 것은 IT의 발전에 굉장히 큰 도움이 됩니다.

공학자와 인문학자가 만날 때 전문성과 일반성이 결합되기 때문입니다.

저는 좋은 개발자가 되려면 인문학적인 [커뮤니케이션 스킬](글쓰기, 말하기)도

함께 연습할 필요가 있다고 봅니다. 인문학자들이 소프트웨어적

사고를 하는 것은 거의 불가능에 가깝다고 보기 때문입니다. (현실적 경험상)

개발자의 장애보고서는 대부분 소프트웨어의 결함과 공학적

[설명문], [논문]입니다. 하지만, 훌륭한 개발팀장의 보고서는

원인/경과/결과/계획으로 잘 구분된 [스토리]입니다. 하지만,

이런 [스토리]가 사람을 움직이고 기업들을 움직입니다. 그리고, 

내 일을 덜어줄 새로운 개발자를 채용해 줍니다.

천재를 제외하고 대부분의 사람들은 커뮤니케이션 스킬을 타고 나지 않습니다.

그래서 공부해서 익혀야만합니다. 책방에 가면 책이 있습니다.

코드책만 보지 마시고, 이런 책도 손에 쥐어보기 바랍니다.

※ 경고. 축약, 변형에 재미를 느끼다 보면 주화입마에 빠져

거짓말쟁이가 될 수도 있습니다. 거짓말장이 개발자는 이직이 매우 힘듭니다.

생각보다 소문이 빨리 퍼집니다. / 열심히 노력함에도 불구하고

좋아지는 것에는 한계가 있습니다. 너무 애쓰지 말고 하는 데까지만 하십시요

 그 다음은 다른 사람들의 몫입니다.