스펙에 있어서는 안될 표현들

필자는 여러 개발자들이 작성해 놓은 스펙문서를 볼 기회가 많다. 대부분 99.9% 스펙이라고 하기에는 내용적으로 부족하고 리뷰도 부족한 문서들이지만 우선 각 문장을 하나씩 보다라도 고쳐할 부분이 매우 많다.

스펙(SRS)은 작성을 하고나면 이를 토대로 비즈니스도 하고 설계/구현도 하고 테스트팀은 테스트를 준비한다. 따라서 각 내용은 매우 정확하게 적어야 하며 두루뭉실하게 적으면 안된다. 하지만 정확한 표현을 하는 습관을 가지고 있지 않은 거의 대부분의 개발자들은 무심코 대충 작성을 하게 된다. 이는 수많은 오해를 유발해서 재작업과 품질 저하를 초래한다.

사실 원칙은 간단하다. 오해를 불러일으키지 않게 정확하게 작성해야 하고 범위를 구체적으로 명시해야 한다. 또한 정량적인 테스트가 가능하도록 설명해야 한다. 비즈니스 관련된 부분은 예외이다.

그럼 스펙을 작성할 때 피해야 할 표현들에는 어떤 것이 있나 알아보자.

SMTP를 지원해야 하다.
지원한다는 말은 대단히 모호한 표현이다.  지원해야 하는 범위를 아주 구체적으로 기술해야 한다.

1~5의 값을 가진다.
1,2,3,4,5인지? 1,3,5인지? 1~5의 float값인지? 그 정밀도와 가질 수 있는 값을 정확하게 기술해야 한다.

데이터를 효율적으로 저장해야 한다.
효율적이라는 표현은 모호한 단어로서 피해야 한다. 메모리나 CPU 자원 대비 효율적인지,  Storage 용량을 적게 차지해야 하는지, 성능이 중요한지 구체적으로 적어야 한다. 또한 정확하게 요구되는 수준을 수치로 표시하는 것이 좋다.

사과, 배, 복숭아 등등을 지원해야 한다.
등등은 사용해서는 안된다. 지원해야 하는 모든 항목을 다 나열해야 한다.

기존의 값과 동일하다.
기존이 무엇인지 구체적으로 명시를 하고 해당 문서가 있으면 Link를 걸어줘야 한다.

충분한 메모리를 할당해야 한다.
충분하다는 것이 정확하게 얼마인지를 명시해야 한다.

사용자에게 친숙한 화면을 제공해야 한다.
어떠한 사용자가 친숙함을 느끼기 위해서 제공해야 하는 정확한 요구를 구체적으로 설명해야 한다.

일반적인 조건을 모두 만족해야 한다.
일반적인 조건을 구체적으로 기술해야 한다. 또한 일반적이지 않은 상황에서 시스템이 어떻게 되는지도 설명이 되어야 한다.

필요한 경우 메모리를 추가로 할당한다.
필요한 경우를 정확하게 판단할 수 있는 조건을 구체적으로 설명해야 한다. 수치가 나오면 좋다.

이외에도 수많은 표현들이 있다. 개발자라면 적어도 개발문서에서 이런 표현들이 나오지 않도록 항상 조심하는 습관을 갖는 것이 좋겠다. 이것도 하루아침에 이뤄지지 않는다.

나쁜 습관

소프트웨어 회사가 프로세스를 제대로 정립하고 좋은 툴을 도입하고 개발문서도 잘 써보려고 노력하고 코딩 실력이 뛰어난 개발자들을 보유하고 있어도 넘기 힘든 벽이 있다.

우리나라 개발자들이 코딩 실력이 좋다는 것은 부정하고 싶지 않다. 처음에는 주먹구구식으로 시작을 했다가 회사가 커지고 고객이 많아지면서 문제가 있음을 깨닫고 프로세스도 만들고 기반시스템도 도입하지만 좋아지기는 하지만 기대만큼 큰 효과를 못보는 경우가 많다. 

그 이유는 개발자들의 몸에 베인 나쁜 습관들은 쉽게 고쳐지지 않기 때문이다. 나쁜 습관이 몸에 베인 개발자들도 교과서적으로는 그렇게 하면 안된다는 것을 알고 있어도 한번 몸에 베인 습관은 쉽게 고쳐지지 않는다.

나쁜 습관에 몸에 베인 것도 개발자들 탓은 아니다. 개발자들도 좋은 개발문화를 가진 회사에서 처음부터 일했다면 그런 나쁜 습관들은 경험해보지도 못했을 것이다. 

여기서 가장 중요한 개발문화는 바로 "협업"의 문화이다. "협업"을 생각하지 못하고 행동하는 하나하나가 모두 나쁜 습관들이다. 우리나라 개발자들은 협업을 해볼 기회가 별로 없다. 개발자들 스스로는 몇명씩 팀을 이뤄서 개발들을 해봤으니 "협업"을 해봤고 지금도 "협업"을 하고 있다고 말할 것이다. 하지만 그건 대부분 또하나의 주먹구구식의 일종일 뿐이다. 따라서 그런 팀은 4~5명이 한계이고 그보다 더 커지면 커지나 마나 하고 오히려 효율성이 더 떨어지는 경우도 많다.

그럼 협업의 핵심은 무엇일까요?

첫째, 문서를 통한 협업이다.

우리는 대부분 여럿이 모여서 서로 의논하면서 개발을 하면 협업을 하는 줄 안다. 하지만 그렇게 해서는 커뮤니케이션 비용이 너무 많이 들어간다. 90%는 문서로 말하고 문서로 안되는 나머지 10% 정도만 말로 설명하면 된다. 하지만 대부분 그 반대다. 문서로 10%, 말로 90%를 커버한다. 
여기서 말하는 문서는 "SRS"(스펙문서), "설계문서", "코드"를 모두 포함한다. 또한 이슈관리시스템과 같은 시스템도 포함된다. 
스펙문서를 보고 문서 작성자 외에 다른 개발자들이 설계를 하고 구현을 할 수 없다면 아직 갈 길이 먼 것이다. 
설계문서를 보고 여러 개발자들이 일을 나줘서 흩어져서 일을 할 수 없다면 부족한 설계문서다.
코드에는 Doxygen등의 주석이 달려 있어서 해당 함수나 Class를 사용하는 동료들이 주석만 보고 사용할 수 있어야 한다. 또한 Doxygen등을 통해서 체계적으로 함수나 Class를 검색할 수 있어야 한다.
코드에 의미를 알 수 없는 숫자나 널려 있고 Public 함수들이 수시로 바뀐다면 협업을 제대로 하고 있다고 볼 수 없다. 
잘 설계가 되어서 Public interface들이 한번 정해지면 이에 대한 설명이 잘 달리고 끝까지 바뀌면 안된다.
이러한 것들이 남의 나라 얘기처럼 생각되면 아직 협업은 갈길이 멀다. 

둘째, Peer review이다.

 Peer review를 빼고는 소프트웨어 개발을 얘기할 수 없다. Peer review하면 흔히 코드리뷰를 떠올리는데 코드리뷰는 그 중 일부이다.
Peer review에서 가장 중요한 것은 SRS(스펙) 리뷰이다. 스펙이 있어야 설계가 있고 그래야 코드리뷰도 의미가 있다.
SRS(스펙)는 프로젝트 모든 관련자가 참여하고 리뷰를 하여 완성해 나간다. SRS에는 프로젝트에 관련된 모든 내용이 들어가기 때문에 혼자서는 완성할 수 없고 리뷰를 거쳐서 모든 관련자가 검토를 해야 한다. 그리고 나면 이렇게 잘 완성된 SRS를 가지고 각자 흩어져셔 일을 할 수 있게 된다.
설계는 혼자서 하는 것보다는 여러 개발자와 리뷰를 하면서 좀더 좋은 아키텍쳐를 찾아낼 수가 있다. 개발자 개인이 가지고 있는 지식은 한계가 있어서 여러 사람과 머리를 맞대야 한다. 
설계 시 다른 사람들의 다양한 의견을 받아들일 준비가 되어 있지 않다면 아직 리뷰 문화에 익숙하지 않은 것이다. SRS와 설계는 리뷰를 통해서만 완성도 있게 작성된다.
그리고 코드리뷰이다. 
이렇게 리뷰를 잘 해야만 제품의 버그나 재작업을 획기적으로 줄일 수 있다. 또한 리뷰를 통해서 서로의 지식과 경험이 공유가 되고 각 개발자들이 훨씬 빠르게 성장한다.

협업 문화가 잘 되어 있는 회사는 다른 분야의 개발자들이 입사를 해도 빠른 시간 안에 적응해서 같이 일할 수 있다.
또한 개발자 한두명이 퇴사를 해도 회사가 망할 정도로 휘청이지는 않는다. 
결정적으로 프로젝트를 더 빨리 끝낼 수 있다.

사실 문화라는 것을 말로 설명하는 것은 어렵다. 또한 말로는 다 알 것 같지만 몸에 베이지 않으면 아는 것도 아니요. 모르는 것도 아닌 어중간한 상태가 된다. 그럴 때는 회사에서 중요한 것들을 강제로 시행하는 제도도 필요하다. 물론 핵심을 모르고 무조건 강제로 하면 부작용이 더 클 수 있으므로 현재 가능하고 중요한 것부터 차근차근 해나가야 한다.

확실한 것은 이런 협업의 문화가 없이는 소프트웨어 회사가 즐겁게 일하면서 오래 살아남지 못한다는 것이다.

개발자는 글을 잘 쓰지 못한다?

개발문서 작성은 항상 개발자를 따라다니면서 괴롭힌다.

체계적으로 개발을 하려면 개발문서를 적절하게 작성해야 한다고 다들 이론적으로는 알고 있다. 실제 그렇게 하지 않아도 이를 부정하는 개발자는 그렇게 많지 않다.

물론 핑계는 있다. 워낙 바빠서 문서를 만들 시간이 없다. 다 아는 내용이라서 문서를 작성하는 것은 시간 낭비다.

그럼에도 불구하고 회사에서 문서 작성을 강제로라도 시키면 개발자들은 MS Word를 열어 놓고 코딩할 때 처럼 진도가 나가지 않는다. 이때 주로 하는 얘기가 "머리 속에는 잔뜩 있는데 글을 잘 작성하지 못해서 문서를 작성하기 어렵다"라는 것이다.

이렇게 되다보니 문서만 작성하라고 하면 거부 반응을 보이게 된다.

하지만 이는 개발문서 작성을 피해보려는 핑계에 불과하다.
개발문서를 작성하는데 있어서 의외로 "글쓰는 재주"는 별로 필요하지 않다.

개발자들이 가장 흔히 작성하는 개발문서는 스펙과 설계 문서이다. 사용자 메뉴얼을 쓴다면 "글쓰는 재주"가 아주 많이 필요할 것이다. 하지만 스펙과 설계 문서를 작성하는데는 글쓰는 재주보다는 내용이 더 중요하다. 스펙과 설계 문서의 독자는 대부분 프로젝트 관련자와 개발자이기 때문에 잘 적힌 문장이 아니더라도 필요한 내용만 적히면 문제가 없다.

결론을 말하면 개발자들은 글쓰는 재주가 없어서 개발문서를 잘 작성하지 못하는 것이 아니고 분석을 못해서 "스펙"문서를 작성하지 못하고 설계를 못해서 "설계"문서를 잘 작성하지 못하는 것이다. 

문서는 분석과 설계의 결과물일 뿐이다. 스펙문서는 SRS Template을 보면 적어도 어떠한 내용이 적혀야 하는지 약간의 도움을 받을 수 있다. 설계문서는 Template이나 툴이 중요하다기 보다는 창의력을 발휘하여 설명할 수 있어야 한다.

문서가 잘 작성되었는지의 판가름은 문서작성자 외의 다른 개발자들이 이 문서를 받아서 일을 할 수 있나 보는 것이다. 물론 본인이 혼자서 분석, 설계, 구현을 하는 경우라도 상세도만 약간 줄이면 되며 내용은 빠짐없이 적어야 한다.

다른 사람이 보고 일을 하려면 화려하고 멋진 문장보다는 정확한 내용을 전달하기만 하면 된다. 기본적으로 주어, 목적어 등을 빼먹어서 애매하게 만드는 일은 없어야 한다. 또한 내용도 정량적으로 기술할 수 있어야 한다. 애매하게 "빨라야 한다"라든가 "편리해야 한다"등의 표현은 절절하지 않다. 이정도는 글쓰는 재주가 없어도 조금만 신경쓰면 되는 내용이다.

과거에 잘작성된 문서를 받아서 개발을 해본 경험이 몇번이라도 있으면 본인이 그러한 문서를 작성해서 다른 사람에게 넘기는 일은 어렵지 않을 것이다. 하지만 우리나라에서는 이러한 개발 문화가 없기 때문에 이런 경험을 가진 개발자를 보기란 정말 어렵다. 그래서 스스로 분석, 설계 방법을 터득해야 하는데 정말로 어려운 일이 아닐 수 없다. 간접적인 경험으로 인터넷의 글이나 책을 보곤하는데 이를 통해서는 너무 많은 정보를 접해서 핵심을 놓치고 오히려 방해가 되곤 한다.

결론은 원칙을 잘 생각하는 것이다. 자신이 작성한 문서를 다른 개발자가 보고 개발을 할 수 있게 해야 한다는 것을 잊지 말자 물론 개발뿐만 아니라 QA, Tech pub, Marketing, Sales 등 모든 부서가 일을 할 수 있어야 한다.

글재주가 없어서 문서를 잘 작성하지 못하는 것이 아니라는 것을 받아드리면 개발문서에 한단계 다가간 것이다. 일단 긍정적인 마음으로 시작하는 것이 중요하다. 그러면 메모 한장이라도 작성하는 것이 더 빠르게 개발하는 길이라는 것을 차츰 알게 될 것이다.

개발자는 회사의 부품일까 두뇌일까?

정말 오랫만에 글을 쓴다. 워낙 바빠서 시간을 내기 어렵다는 핑계를 대지만 블로그에 올릴 글이 50개 이상은 준비중이고 한두시간만 시간을 내서 정리해 올리면 되는데 바쁠때는 그것도 잘 안된다. 다시 마음을 잡고 글을 올린다.

여러 회사를 컨설팅하면서 각 회사에서의 개발자들의 가치를 비교해보게 된다.

흔히 프로세스가 아주 잘되어 있어서 개발자들가 퇴사해도 문제가 없는 회사에서는 개발자가 부품 취급 받을 것 같다.

반대로 몇몇 슈퍼 개발자들이 슈퍼 파워를 내서 단시간에 놀랄만한 성과를 내는 회사들에서 개발자들의 가치가 더 높아질 것으로 생각하는 경우가 많다.

하지만 그 반대인 경우가 더 많다.

개발자들에게 선택이 가능하다면 두가지 경우 중에서 어느 경우를 선택하겠냐고 물어보면 대부분 두번째 슈퍼 개발자를 선택할 것이다. 두번째 경우가 회사에서 없어서는 안될 중요한 인물이 되고 연봉도 더 높을 것으로 생각된다.

하지만 회사입장에서는 다른 선택을 하게 된다. 우리나라의 대부분의 소프트웨어 회사들은 두번째 경우이지만두번째 상황을 벗어나려고 발버둥치고 있다.

사실 슈퍼 개발자들이 단시간에 놀랄만한 성과를 내는 것은 별로 놀랄 일도 아니다. 주변에서 워낙 흔히 벌어지고 단지 단기간에 낸 성과의 댓가는 미래에 톡톡히 치르기 때문이다.(물론 이런 빠른 전술이 필요한 경우도 많고 이를 적절히 사용해야 한다.) 이런 환경에서 개발자는 더 가치가 있을 것 같지만 시간이 흐를수록 점점 그 가치는 떨어져 간다. 과거에 만들어 놓은 제품을 다른 사람이 유지보수 하기 어려워서 유지보수에만 매달리다가 점점 유지보수가 어려워지면 회사를 떠나곤 하고 남아있는 개발자들이 고생을 해야 한다. 이 과정에서 회사는 프로세스의 중요성에 눈을 뜨고, 남아 있는 개발자들은 피해의식만 커져간다.

반대로 처음부터 적절한 프로세스를 갖추고 개발하는 회사는 당장은 조금 느려보이지만 문서를 만들고 서로 리뷰도 여러사람과 공유를 하며 프로세스를 따라서 개발을 한다. 여러사람과 공유를 하기 때문에 유지보수도 문제가 없고 이전 프로젝트의 족쇄 없이 새로운 프로젝트를 시작할 수도 있다. 또한 퇴사를 해도 회사에 큰 타격을 주지 않는다. 이런 회사에서는 개발자들이 특히 고참개발자들이 유지보수 등 잡일에 목메이지 않고 그런 일은 신참 개발자들에게 맡기고 회사의 두뇌다운 전략이나 로드맵, 아키텍쳐를 고민할 수 있게 해준다. 회사와 개발자간에 상호간에 Risk가 적으며 서로 발목을 잡지 않는다.

이런 환경에서 성장한 개발자는 더 가치 있는 일의 경험이 쌓여서 이직시에도 더 높은 연봉을 받을 수 있다. 하지만 그렇지 못한 회사에서는 10년을 넘게 일을 해도 느는 것은 공력과 해당 Domain 지식밖에 없게 된다. 이런 회사에서는 회사와 개발자가 서로의 발목을 잡고 성장을 못하게 된다. 이직시에도 경쟁회사처럼 비슷한 일을 하는 회사로밖에 옮기지 못하고 이직후에도 비숫한 문제들을 또 일으키게 된다.

현재 자신의 회사가 어디에 해당하는지 아는 방법이 있다.

회사의 개발 일들이 특정인이 아니면 못하는 구조로 되어 있으면 문제가 있는 경우이다.
또한 특정인이 퇴사하면 과거에 해 놓은 프로젝트가 엉망이라면 고민을 해야 한다.
하지만 특정인이 퇴사하면 미래에 할 프로젝트에 피해가 간다면 개발자들이 진정한 회사의 두뇌로 생각되는 경우일 것이다. 물론 칼로 무를 자르듯이 경계가 명확한 것은 아니다.

개발자가 회사의 부품이 아니고 두뇌가 되는 길은 2,3명 회사이던 1000명 회사이던 적절한 프로세스를 통해서 개발자가 두뇌의 역할을 해줄 수 있는 환경을 조성하는 것이다. 여기서 "적절한" 것이 가장 어렵기는 하지만 그 필요성을 공감하는 것이 첫걸음이다.