개발자의 글쓰기, 독서록
추천하지 않습니다
우연한 계기로 이 책의 저자인 김철수 씨가 개발자를 대상으로 진행한 글쓰기 강연을 들었다. 강연을 들으며 저자의 말에 다소 반감이 들어 이 책을 읽게 되었다.
저자 약력
저자는 국어국문학과를 졸업한 뒤 팬스쿨이라는 커뮤니티 사이트 회사를 차려서 4년 정도 운영하다가 2003년부터 직장 생활을 시작했다. 직장에서는 주로 기획 업무를 맡은 것으로 보인다. 직장 생활을 시작한 뒤 1년 단위로 계속 회사를 바꾸다가 코오롱베니트라는 회사에서 8년 정도 근무한 것으로 나오는데 그곳에서도 부서를 몇 번 바꿨다. 2016년에는 다시 직장 생활을 그만두고 자신의 회사를 차렸고 현재까지 경영하고 있는 것으로 나온다.
책 개요
이 책은 개발 직무를 수행하면서 한 번쯤 작성하게 되는 다양한 종류의 글을 다룬다. 책 표지에 나온 대로 변수 네이밍이나 주석, 에러 메시지와 같이 코드에 삽입되는 굉장히 짧은 글부터 개발 가이드나 장애 보고서, 제안서, 기술 블로그 등과 같이 보통 코드와는 별도로 경우에 따라선 꽤나 긴 분량으로 작성하는 글까지 가볍게 훑어본다.
좋았던 점
사실 어느 정도 개발 경력이 있는 사람이라면 책의 세부적인 내용 자체는 별로 새로울 것이 없다. 주석이든 개발 가이드든 해당 글과 비슷한 종류의 글을 한 번이라도 써봤다면 주변 동료나 인터넷 혹은 사내 양식이나 가이드에서 한 번쯤은 접해봤을 내용이다.
이 책의 장점은 바로 그렇게 여기저기 흩어져 있던 내용을 나름의 방식으로 정제해서 한 곳에 모아 놓았다는 점이다. 그동안 이공계를 대상으로 일반적인 관점에서의 글쓰기 방법을 알려주는 책은 종종 봤던 것 같은데 이공계 중에서도 개발자만 콕 집어서 개발자 업무에 특화된 글쓰기를 알려준 책은 많지 않았던 것 같다. 개발자로 10여 년 일하면서 자기 멋대로 작성된 주석이나 에러 메시지, 개발 가이드 때문에 고생한 적이 많았는데 그 고생을 생각하면 이런 책이 나왔다는 사실 자체는 환영할만한 일이다. 그런데 읽어보면 알겠지만 시도했다는 사실 그 자체 말고는 아쉬운 점이 많았다.
아쉬웠던 점
책의 방향은 좋았는데 세부 내용에서 아쉬움이 많았다. 그중 몇 가지를 가져왔다.
금도끼 은도끼
저자는 프롤로그에서 동화 금도끼 은도끼를 요약하는 이야기로 책을 연다. 먼저 저자가 제시한 나쁜 예시를 살펴보자.
옛날에 착한 나무꾼이 나무를 하다가 도끼를 연못에 빠뜨렸다. 그때 산신령이 나타나 금도끼가 네 도끼냐 물었다. 나무꾼은 아니라고 대답했다. 산신령은 은도끼가 네 도끼냐 물었다. 나무꾼은 아니라고 대답했다. 산신령이 쇠도끼가 네 도끼냐 물었다. 나무꾼은 그렇다고 대답했다. 산신령은 나무꾼의 정직함과 효성에 탄복하여 나무꾼에게 세 도끼를 모두 상으로 주었다. 가난한 나무꾼은 부자가 되어 행복하게 살았다.
위 예시를 제시한 뒤 저자는 글을 정말 잘 쓰는 학습자는 군더더기를 다 없애고 핵심만 남겨 간결하게 쓴다며 다음 예시를 제시했다.
나무꾼, 연못에 도끼 유실
산신령, 금, 은, 쇠도끼 제시
나무꾼, 쇠도끼만 인정
산신령, 금, 은도끼 포상
이 예시가 진정 ‘글을 정말 잘 쓰는 학습자’와 ‘그렇지 않은 학습자’를 가를 수 있는 예시라고 생각한 걸까. 위 두 글은 각각의 목적에 따라 형식이 다른 글일 뿐이지 어느 것이 좋거나 나쁘다고 할 수는 없는 예시다. 오히려 책이나 영화의 줄거리를 요약하는 글을 쓸 때는 첫 번째와 같은 형식이 더 적당하다고 생각한다. 두 번째와 같이 글을 쓴 사람은 ‘글’을 잘 쓴다기보다는 ‘보고서’를 잘 쓰는 학습자로 분류하는 게 맞다고 생각한다.
코드 오류
프롤로그에서 아쉬운 점은 위 예시뿐이 아니다. 이후 저자는 정확성과 간결성, 가독성이 서로 상충된다며 정확성을 높이면 간결성과 가독성이 낮아지고, 간결성을 높이면 정확성과 가독성이 낮아지며, 가독성을 높이면 간결성과 정확성이 낮아진다고 얘기한다. 이를 설명하기 위해 입력받은 나이로 성인인지 아닌지를 판단하는 코드를 예시로 들었는데 정확성과 간결성과 가독성이 서로 상충 관계에 있다는 것도 의문이지만 그 관계를 설명하기 위해 가져온 코드 예시는 더욱 부적절했다.
저자는 아래 코드를 먼저 제시한다.
function get(m){
var result;
if(m.year < 20){
result = 0;
}else{
result = 1;
}
}
참고로 위 코드에는 오류가 있다. 저자가 이후에 제시하는 나머지 두 코드에서도 동일하게 발견되는 오류인데 result라는 변수를 함수 내에서 선언한 뒤 결괏값을 담고는 함수가 종료될 때까지 다른 어떤 변수에도 할당하지 않고 그렇다고 반환하거나 프린트하지도 않는다. 저자가 만든 함수를 호출하는 쪽에서는 아마 어떤 결과도 얻을 수 없을 것이다. 설사 위 코드가 의사 코드라고 해도 잘못된 부분이다.
저자는 위 코드가 정확하지 않다고 얘기하면서(오류 때문에 당연히 그렇겠지만 저자의 의도는 다른 곳에 있다) 우리나라 민법의 성년 기준은 20세가 아니라 만 19세이며 여기서 만 19세라는 의미는 19세가 되는 해의 생일이 돼야 비로소 성년이 된다는 뜻이기 때문에 아래와 같이 바꿔야 한다고 얘기했다.
function get(m){
var result;
var todayMonthAndDay = …(생략)
if(m.year > 19){
result = 1;
}else if(m.year == 19){
if(m.monthAndDay >= todayMonthAndDay){
result = 1;
}else{
result = 0;
}
}else{
result = 0;
}
}
이 코드를 제시한 뒤 저자는 두 예시에서 볼 수 있듯 코드를 지나치게 간결하게 쓰면 정확성이 낮아진다고 말하는데 이 말은 아주 잘못된 말이다. 흡사 두 번째 코드를 간결하게 다듬으면 첫 번째 코드가 된다는 말로 들리는데 첫 번째 코드와 두 번째 코드는 그저 서로 다른 요구 사항에 따라 로직을 달리 구현한 다른 코드일 뿐이다. 서로 다른 두 코드가 간결하거나 장황하다는 관계에 놓이려면 적어도 같은 입력을 받았을 때 같은 값이 출력되는 코드여야 한다. 위 둘은 같은 입력을 받았을 때 같은 값이 나오지 않는다. 세상 어느 개발자도 코드를 간결하게 작성한답시고 원래 요구 사항에 부합하지 않는 값을 출력하는 코드를 작성하지는 않는다.
이후 저자는 다시 아래 코드를 제시하며 정확성과 가독성이 높아졌지만 처음 코드와 비교하면 간결하지는 않게 되었다고 주장한다.
const LEGAL_ADULT = 1
const LEGAL_NOT_ADULT = 0
function checkLegalAdult(m){
var legalAdult;
if(m.ageOfMajority > 19){
result = LEGAL_ADULT;
}else if(m.ageOfMajority == 19){
if (m.monthAndDay >= todayMonthAndDay){
result = LEGAL_ADULT;
}else{
result = LEGAL_NOT_ADULT;
}
}else{
result = LEGAL_NOT_ADULT;
}
}
위 코드에는 앞서 나온 두 코드에 존재했던 result 변수 오류 외에 다른 오류가 추가로 존재한다. 아마도 가독성이 높은 코드 예시를 보여주고 싶어서 변수명을 바꾸려고 했던 모양인데 애석하게도 초보 개발자가 흔히 저지르는 실수를 범했다. 변수를 선언하는 곳에서는 result를 legalAdult라는 이름으로 바꿔 놓고 나머지 코드에서는 result 변수 이름을 그대로 남겨놓은 것이다. 결과적으로 legalAdult라는 변수는 선언한 뒤 어느 곳에서도 쓰이지 않고 있으며 대신 어디에서도 선언되지 않은 result라는 변수에 소중한 결과 값을 담고 있다. 물론 그 result도 앞선 예시와 같이 함수가 끝나면 그대로 사라져 버릴 것이다. 다른 변수 선언에서는 꼬박꼬박 세미콜론을 붙여 놓고 상수 변수 선언에서는 세미콜론을 빠뜨린 것은 덤이라고 할 수 있고.
이후 내용에서도 아쉬운 점이 있었다. 저자는 ‘정작 개발자에게 필요한 변수 이름, 네이밍 컨벤션, 주석 …. 어디서도 배울 수가 없다‘라고 말하는데 보통 프로그래밍 언어를 다루는 책에서 꼭 다루는 게 변수 이름과 네이밍 컨벤션, 주석에 관련된 내용이다. 아마도 저자는 그런 책을 잘 읽어보지 않은 모양이다.
만약 서점에서 제목에 끌려 책을 들고 읽다가 이런 프롤로그를 읽게 됐다면 그대로 내려놓았을 것이다. 그냥 덮고 다른 책을 읽을까 잠시 고민했지만 산 게 아까워서 조금 더 읽어보기로 했다.
띄어쓰기와 외래어 표기법을 무시하자?
또 크게 아쉬웠던 부분은 1장에서 띄어쓰기를 설명하며 ‘비즈니스 세계에서 띄어쓰기는 그리 중요하지 않다. 불과 70년 전까지만 해도 한글에는 띄어쓰기가 없었다. 우리는 띄어쓰기 없이도 충분히 생각을 전달하고 의미를 이해할 수 있다.’라고 말한 부분과 '외래어를 한글로 쓰고 말할 때 국립 국어원의 외래어 표기법을 굳이 지킬 필요는 없고 프로젝트 혹은 팀 내에서 일관성만 지키면 된다'고 말한 부분이다.
물론 국립 국어원에서 정한 한글 맞춤법의 띄어쓰기가 굉장히 복잡하고 어려우며 규칙에 일관성이 없다는 것에는 동의한다. 예를 들어 ‘띄어쓰기’는 붙여 쓰지만 ‘띄어 쓰다’는 띄어 써야 하는 게 국립 국어원에서 정한 띄어쓰기 규칙이다.
그럼에도 띄어쓰기는 중요하다. 특히나 오해의 소지를 최소화해야 하는 기술 문서에서는 더더욱 중요하다. 기술 문서에서 띄어쓰기 때문에 발생하는 오해는 널리 알려진 ‘아버지가방에들어가신다’와 같은 예문처럼 독자가 직관적으로 파악하는 게 어려울 것이다. 기술 문서 독자의 대부분은 해당 기술에 대한 지식이 부족한 사람들일 것이고 만약 이들이 띄어쓰기 때문에 두 가지 해석이 가능한 문장을 만나게 된다면 이들은 이 문장을 둘 중 어떤 방향으로 해석해야 맞을지 선뜻 판단할 수 없을 것이다.
모든 문서의 목표는 독자에게 내가 말하고자 하는 바를 정확히 전달하는 것이다. 띄어쓰기 오류를 100% 줄이는 것은 어렵겠지만 그럼에도 최선을 다해 오류를 줄이는 것이 목표여야 한다. 저자의 생각은 아주 위험한 생각이다.
저자가 굳이 따를 필요가 없다고 말한 외래어 한글 표기법 역시 마찬가지다. 물론 나 역시 외래어 한글 표기법에 따라 표기하면 굉장히 어색해지는 단어들이 있다는 것에 동의한다. 예를 들어 ‘solution’은 ‘솔루션’이 아니라 ‘설루션’이 맞는 표기이고 SNS에서 많이 사용하는 ‘follow’는 ‘폴로’라고 표기하는 게 맞다. 그럼에도 우리가 최대한 따르려고 노력하는 이유는 사회 전체적으로 일관성을 지키는 가장 쉬운 방법이 국립 국어원에서 정한 외래어 한글 표기법에 따르는 것이기 때문이다. '국립 국어원의 외래어 표기법을 굳이 지킬 필요는 없고 그저 일관성만 지키면 된다'고 하는 저자의 말은 어느 정도 모순이라고 할 수 있다. 팀이나 프로젝트는 물론 회사 내에서 혹은 외부 고객을 만나 프레젠테이션을 하거나 오픈 소스로 공개하는 등 모든 경우에서 가장 쉽게 일관성을 지키는 방법은 결국 국립 국어원에서 정한 규칙을 따르는 것이다. 책에서 저자가 예시로 든 ‘윈도우’와 ‘윈도’는 결국 ‘윈도’로 통일될 것이다. 언론에서는 이미 아래 기사들처럼 ‘윈도’라는 표현을 적극적으로 사용하고 있다.
https://zdnet.co.kr/view/?no=20210706175657
https://www.yna.co.kr/view/AKR20210702073200009?input=1195m
또한 앞으로 과거에 ‘윈도우’라고 불렀던 시절을 알지 못하고 바로 ‘윈도’라는 표현을 접한 세대들이 점점 늘어날 것이기 때문에 저자의 조언을 따라 개발 가이드 같은 곳에 ‘윈도우’라고 표기한다면 금방 다시 ‘윈도’로 바꿔야 할 가능성이 농후하다. 표현이 너무 어색해서 사용하기 어렵다는 생각이 든다면 차라리 원어 그대로 ‘Windows’라고 표현하는 것도 좋은 방법이다.
앞서 언급했듯 나 역시 국립 국어원에서 정한 띄어쓰기 규칙이 불합리하다고 생각하고 있으며 때때로 외래어 표기법을 따르지 않을 때도 있다. 그럼에도 함부로 띄어쓰기가 중요하지 않다고 말하거나 국립 국어원에서 정한 외래어 표기법을 지킬 필요가 없다고 말해선 안된다고 생각한다. 그것도 글쓰기를 가르치는 사람이라면 더더욱 그래서는 안된다고 생각한다.
재발 가능성 20%
저자는 4장에서 장애 보고서 작성과 관련해 조언을 하며 원하는 것을 얻으려면 개발자가 정치적으로 글을 써야 한다고 말한다. 아래 해당 부분을 가져와 봤다.
그런데 윗사람은 보통 확정적인 대답을 원한다. 딱 부러지게 그렇다 아니다라는 대답을 원한다. 심지어 재발 가능성을 백분율로 말해주기까지 원한다.
…
윗사람이 모호한 표현을 싫어하는 이유는 의사결정을 내리기 어렵기 때문이다. 의사결정을 내리려면 아랫사람에게 정확한 정보를 들어야 하는데, 아랫사람이 모호하게 말하면 의사결정을 할 수 없다. 그래서 개발자는 좀 더 정치적으로 말할 필요가 있다. 재발할지도 모른다면 그냥 재발 가능성을 20%라고 말하면 된다. 다음은 재발 가능성을 퍼센티지별로 표현해 본 것이다.
누군가에게 보고할 때 위와 같이 말장난을 하는 개발자가 얼마나 될까 싶지만, 만약 정말로 저런 표현을 썼다면 이는 윗사람이 해결해 줘야 하는 일이다. 해당 개발자가 문제를 좀 더 명확하게 파악할 수 있도록 관련 부서 간 협의를 중재해 주거나 아니면 다른 개발자에게 도움을 받을 수 있도록 조치를 취해줘야 하는 것이지 이런 말장난 같은 표를 주고 이렇게 보고하라고 하면 안 될 일이다.
나는 아랫사람에게 이런 표현을 강요하고 싶지 않고 이런 표현을 강요하는 윗사람과 절대 같이 일하고 싶지 않다. 정말 저런 식의 정치적 말하기를 해야 하는 순간이 있을 수도 있다. 그럴 때에도 정치적 말하기는 개발자가 아니라 경영자가 해야 할 일이다. 그에 따른 책임 또한 경영자가 져야 한다. 무슨 폭탄 돌리기도 아니고 이런 식으로 말하는 게 대체 누구에게 도움이 된다는 말인가. 이런 말하기로 득을 보는 건 아첨꾼이나 무책임한 경영자 정도라고 생각한다. 이 책의 저자는 자신의 회사를 차려 경영하고 있는 경영자다. 그는 이런 식의 말하기를 아랫사람에게 강요하며 경영하고 있는 것인가.
저자가 말하는 기술 블로그 쉽게 쓰는 방법
저자는 기술 블로그를 쉽게 쓰는 방법을 알려준다면서 그동안 대부분의 글쓰기 교육에서 말해왔던 사실을 부정한다. 관련 부분을 옮겨왔다.
이런 식의 주제 우선 글쓰기, 독자 중심 글쓰기, 주장하는 글쓰기가 학교를 벗어난 개발자의 글쓰기 방식을 지배해왔다. 그래서 주제가 불분명하고, 독자 수준이 천차만별이고, 딱히 주장할 것이 없는 기술 블로그를 써야 할 때는 생각이 정리되지 않고 목차도 못 잡고 한 줄도 못 쓴다.
예를 들어 개발기를 보자. 개발기에는 딱히 주제라 할 만한 것이 없다. 억지로라도 주제를 짜내 봤자 ‘힘들었던 개발 과정’이거나 ‘열심히 해봐라’ 식의 메시지밖에는 없다.
여기까지 말한 저자는 ‘주제 의식을 버리고 소재 의식으로 쓰자’며 다음과 같이 말한다.
소재 우선 글쓰기는 주제 의식이 아니라 소재 의식을 갖고 쓰는 것이다. 주제 의식이 민족이나 권선징악, 자존감이나 자본주의 같은 추상적 가치를 기반으로 한다면 소재 의식은 특정한 대상이나 상황에 대한 자기만의 관점이나 생각이나 해결 방안을 뜻한다.
예를 들어 우아한 형제들 기술 블로그에 올라온 글 중에 “데이터베이스의 자동 증가 값을 기본키로 사용할 수 없을 때는?”이 있다. 데이터베이스의 자동 증가 값을 기본키로 사용할 수 없는 상황이 벌어졌고, 그 상황을 어떤 방법으로 해결한 내용을 기술 블로그에 올린 것이다. 이런 것이 바로 소재 의식이다.
이 책의 저자는 주제를 너무 어렵게 생각한 것 같다. ‘Basic 고교생을 위한 문학 용어사전’이란 곳에서 정의한 주제 설명의 첫 문장을 가져와 봤다.
글의 중심적인 내용이나 중심 생각, 혹은 작가가 표현하고자 하는 의도나 세계관의 반영체, 작품에 나타난 중심 사상을 말한다(https://terms.naver.com/entry.naver?docId=940134&cid=47319&categoryId=47319).
또한 국립 국어원에서는 주제를 아래와 같이 정의하고 있다.
대화나 연구 따위에서 중심이 되는 문제.
위 정의에서 볼 수 있듯이 주제란 꼭 추상적인 것만을 가리키는 게 아니다. 주제란 누군가 쓴 글의 중심적인 내용이나 중심 생각, 혹은 글쓴이가 표현하고자 하는 의도를 통칭하는 말이다. 글이 있으면 주제는 있을 수밖에 없다. 저자가 말한 소재 의식, '특정한 대상이나 상황에 대한 자기만의 관점이나 생각이나 해결 방안'이 바로 주제다. 저자가 가져온 예시 '데이터베이스의 자동 증가 값을 기본키로 사용할 수 없을 때는?'의 주제는 저자가 말한 그대로 '데이터베이스의 자동 증가 값을 기본키로 사용할 수 없는 상황이 벌어졌고, 그 상황을 어떤 방법으로 해결했다'가 될 것이다. 간단하다. 억지로 짜낼 필요는 전혀 없다. 다루는 주제가 거국적일 수도 있고 지엽적일 수도 있다. 추상적일 수도 있고 구체적일 수도 있다. 그런 차이는 있을 수 있어도 주제가 없는 글은 있을 수 없다. 아무렇게나 벽에 휘갈겨 쓴 낙서에도 낙서한 사람의 의도가 담겨 있다. 남에게 자신의 실력을 과시하려는 의도였든 신세를 한탄하기 위한 의도였든 순간의 감정을 기록하기 위한 의도였든 깨끗한 담벼락을 내가 최초로 오염시키고 싶다거나 분필이나 스프레이를 낭비하고 싶다는 의도였든 그게 뭐였든 간에 모든 글에는 글쓴이의 의도가 담겨 있게 마련이고 그게 바로 글의 주제가 된다.
저자가 진짜로 하고 싶었던 말은 주제를 너무 거창하게 잡지 않아도 된다는 말이 아니었나 싶다. 캐주얼하게, 친구나 옆자리 동료와 잡담을 나눌 때의 수준으로 주제를 잡고 글을 써도 된다는 말을 하고 싶었던 것 같다.
저자의 경솔한 언행
내가 들었던 강연에서 저자는 ‘~자(者)’로 끝나는 직업과 ‘~가(家)’로 끝나는 직업의 차이를 설명했다. 작가와 같이 가로 끝나는 직업은 어떤 분야에서 일가를 이루었다는 뜻이며 아무나 할 수 없는 일을 하는 사람이라고 설명했고, 편집자와 같이 자로 끝나는 직업은 그다지 대단하지 않아 아무나 할 수 있는 일을 하는 사람이라고 설명했다. 아무리 평소에 그렇게 생각하고 있었다고 하더라도 개발자(者) 집단에 ‘개발자의 글쓰기’를 주제로 강연하러 온 사람이 할 말은 아니었다.
저자의 경솔한 언행은 거기서 끝나지 않았다. 그는 회사에서 전사원을 대상으로 연 강연에서 굳이 그 회사의 임직원이 작성해서 외부로 공개한 문서의 일부를 강연 예문으로 들고 나타나서 문서 작성자의 실명을 호명하며 공개적으로 문서의 단점을 지적했다.
기본적인 예의조차 갖추지 못한 사람의 강연을 듣다 보니 이 책이 궁금해졌는데 읽어 본 결과 역시 시간 낭비였다는 생각이 들었다.
추천하지 않습니다
결론적으로 개발자가 굳이 읽어 볼 필요는 없는 책이다. 당신이 개발자로 일하다가 어떤 문서를 작성하게 됐다면 이 책을 읽을 시간에 인터넷에서 자료를 검색해 보는 것을 추천한다.
