소프트웨어 개발은 단순히 코딩만 하는 것은 아닙니다. 프로그래밍이 많은 몫을 차지하지만 코딩할 줄 아는 것만으로 좋은 개발자는 아닙니다. 먼저 프로그램을 어떻게 개발을 해야 할지 사용자 요구사항을 분석하고 설계하는 능력이 있어야 합니다. 집을 지을 때 어떻게 지어달라는 이야기를 듣는 것처럼 사용자가 원하는 내용을 먼저 파악을 해야 합니다. 자신이 무엇을 만드는지 제대로 이해하지 못한 채 바로 코딩으로 들어가는 개발자들이 많습니다. 정교한 설계 없이 바로 코딩으로 들어가면 백발백중 실패한 소프트웨어가 됩니다.
소프트웨어 개발은 언제나 무엇을 개발할지를 이해함으로부터 시작해야 합니다. 사용자들이 불편한 것이 있는데 자동화하는 소프트웨어를 개발한다고 가정을 해봅니다. 어떤 부분을 소프트웨어로 개발을 할지 명확하게 정리가 되어 있어야 합니다. 코딩을 시작하기 전에 해결할 문제를 이해하고 사용자의 요구사항을 알아내는 것이 가장 먼저 해야 할 일입니다. 고객의 요구사항을 충분히 파악을 해야 합니다. 요구사항이 몇 번이고 번복이 되기 때문에 요구 사항을 SRS(Software Requirements Specification)으로 작성을 해놓아야 합니다.
건물로 치면 설계 도면과 같은 것입니다. 건설업자가 개성대로 짓는 것이 아니라 건축주가 원하는 설계 도면을 바탕으로 건물을 짓는 것과 같습니다. 소프트웨어도 SRS문서에 기반하여 소프트웨어를 짓습니다. 요구 사항이 번복이 되었을 때 SRS문서를 업데이트 후 버전을 올려서 저장을 해놓아야 합니다. SRS문서는 바탕으로 개발을 해야 어떤 소프트웨어를 개발할지 정확히 알 수 있는 나침반과 등대 역할을 해줍니다. SRS 문서를 작성하기 전에 아직 코딩을 시작하면 안 됩니다. SRS문서 없이 지금 코딩하면 배가 산으로 갑니다. 코딩하고 싶어도 참아야 합니다. 일단 사용자 요구사항이나 개발 내용이 파악되었으면 그 내용을 어떻게 구현할지 설계를 해야 합니다. 설계된 내용도 SRS문서에 업데이트를 해놓습니다. 애자일 소프트웨어 개발을 선호한다 하더라도 설계는 필요합니다. 설계가 없이 개발하는 것은 기둥도 세우지 않고 벽돌을 쌓아나가는 것과 같고 며칠 안에 무너집니다. 설계가 부실한 소프트웨어는 아슬아슬하게 줄타기하는 것과 같아 언제 떨어질지 모릅니다. 멍든 사과처럼 한번 멍들게 되면 회복이 어렵고 좋은 소프트웨어를 만드는 것이 물 건너가는 것입니다.
개발자는 고생은 고생대로 하고 열매가 없으니 소프트웨어 개발자 직업에 대해 회의를 갖기 시작합니다. SRS 문서를 잘 작성해놓아야 모두가 행복할 수가 있습니다. 소프트웨어 프로젝트에서 SRS 문서를 잘 작성하면 이점도 많습니다. 관련 부서와 협력하고 프로젝트를 체계적으로 관리하게 됩니다. 아키텍트와 신참 개발자 등의 인재 양성에도 유리합니다. 무엇보다 회사 사활이 걸린 프로젝트 성공 확률이 대거 높아집니다. 또 프로젝트 종결 후에도 제품 유지 보수가 용이하며 글로벌 회사를 상대할 역량을 갖추게 됩니다.
SRS 문서를 잘 작성하면 프로젝트 성공확률이 커집니다. 프로젝트의 실패 원인은 기술적인 벽을 넘지 못하는 것도 있지만 대부분 시간이 부족해 일정을 못 맞춘 때입니다. 스펙을 잘 작성한다는 의미는 프로젝트가 빨리 끝난다는 것과 일맥상통합니다. SRS 스펙 문서를 아무리 잘 적었다 할지라도 프로젝트를 빨리 끝내는 데 도움을 주지 못한다면 무의미한 문서입니다. 즉, 형식적으로 SRS 문서를 만들지 말라는 것입니다. 모든 개발이 다 끝난 후에 인증을 위해 형식적으로 작성하는 경우는 최악입니다. 프로젝트 시작 전에 잘 작성된 SRS 문서를 만들고 개발을 한다면 자원과 비용이 적게 듭니다.
SRS 문서는 프로젝트를 빨리 좋은 품질로 끝나게 만들어주는 비밀 병기입니다. 사내에서 프로젝트에 대한 신뢰도가 높아지며 경영진이나 마케팅팀은 프로젝트가 당초 계획대로 완료된다는 믿음을 갖게 됩니다. 잘 작성된 SRS 스펙 문서 기반으로 개발하면 프로젝트가 산으로 가지 않습니다. 고객과 약속을 지키고 비즈니스가 더욱 확장이 되게 됩니다. 잘 작성한 SRS문서는 무엇을 해야 할지 명확히 정의가 가능하고 서로 협력이 쉬워집니다. SRS 문서는 개발자들에게 길을 알려주는 내비게이션과 같아 우왕좌왕하지 않게 만듭니다. SRS 문서는 곧 길이요 진리요 생명입니다.
많은 개발자들이 일하며 오합지졸이 되지 않고 스펙을 통해 정예 군사가 되어 각자 전문분야의 일을 하고 서로 협력을 하니 예비군이 아닌 정규군이 됩니다. 스펙 중요성을 어느 한 사람만 외친다고 되는 것은 아니고 중요성에 대한 전반적인 공감대가 형성이 되었을 때 모두가 스펙을 최선을 다해서 작성을 하게 됩니다.
잘 작성된 SRS문서는 프로젝트를 체계적으로 관리해야 합니다. 작은 단위로 관리를 하고 팀 간의 종속관계가 최소화되어 프로젝트 복잡도가 감소합니다. SRS 문서 없이 개발을 하게 되면 홍수 때에 마실 물이 없는 것처럼 아무리 개발자가 많아도 무용지물입니다. SRS 문서가 있어야만 인원별로 업무를 할당하고 업무 간에 조율해주는 역할들을 해주게 됩니다. SRS문서는 프로젝트를 계획하는데 많은 정보를 제공하고 체계적으로 관리를 하게 되어 프로젝트를 성공으로 이끕니다. 잘 작성하다 보면 소프트웨어 개발자 중에서 가장 중요하고 인정받는 분야가 아키텍트를 양성하게 됩니다. 즉, 소프트웨어의 전반을 설계하는 개발자가 많이 나오게 됩니다.
아키텍트는 많은 이해관계자들과 토론하고 의견을 수렴해서 정리합니다. 컴포넌트를 나누고 리뷰 피드백을 받아 SRS 문서를 발전시켜 나갑니다. 이렇게 직접 SRS 문서를 작성하는 과정을 거치면서 자연스럽게 능력 있는 아키텍트가 양성됩니다. 어떤 교육보다는 현장에서 부딪히며 아키텍트를 양성하는 것이 훨씬 더 효율적입니다.
SRS 문서를 기반으로 개발하면 유지 보수가 쉬워집니다. 문서화가 제대로 되어 있지 않으면 소프트웨어는 시간이 갈수록 유지보수가 더 어려워집니다. SRS 문서 자체가 후배에게는 좋은 교과서가 되어 후배를 가르치기도 쉽습니다. SRS문서로 자기 학습이 된 상태라면 서로 대화가 되기에 가르치기가 수월합니다. SRS문서는 회사의 경쟁력이 됩니다. 소프트웨어 회사의 최고 복지는 코딩 잘하는 옆 동료와 더불어 ‘잘 작성된 SRS 문서’입니다. 이 문서가 잘 되어 있어야 개발자들이 고생을 안 하고 야근도 줄일 수 있습니다. 일정 안에 견고한 소프트웨어를 만들 수 있고 SRS 문서들을 꾸준히 작성하여 역량을 키운다면 글로벌 회사와 경쟁할 수 있는 힘이 생깁니다.
SRS 문서가 없이 개발을 하면 앞이 안 보이는 안개 낀 곳에서 개발을 하는 것과 같습니다. SRS 문서만 잘 작성을 해놓았다면 글로벌 회사가 될 수 있는 자격 요건중 하나는 갖추게 됩니다.
사용자 요구사항과 분석, 설계가 마치면 코딩의 단계로 들어섭니다. SRS 문서에 기반하여 각 기능들을 나누어서 코딩 작업을 합니다. 라이브러리, 엔진, 서버, 클라이언트, 모듈 등을 각 담당자 별로 나누어서 개발을 시작합니다. 소프트웨어는 일정에 맞춰서 빠르게 개발하는 것이 중요합니다. 소프트웨어 시장은 변동도 심하고 빠르게 변해서 오랜 개발 끝에 제품을 내놓으면 시장에서는 먹히지 않는 제품이 됩니다. 경쟁사들이 먼저 내놓거나 다양하고 새로운 기술들을 내놓아서 새 제품이 빛을 보지 못합니다. 그래서 소프트웨어 공학이 중요합니다. 소프트웨어 공학의 목적은 ‘소프트웨어를 최소 비용으로 최단기간에 개발하는 방법’이다.
우리가 코딩을 할 때도 항상 최소 비용으로 최단기간에 개발할 수 있도록 염두에 두어야 합니다. 개발자는 항상 코딩 생산성을 고민하여 개선을 해나가야 합니다. 개발 속도가 빠른 개발 언어가 나왔다면 스터디를 해서 새로운 언어로 갈아타야 한다. 20년 전에 배운 것을 익숙하다고 아직도 사용하고 있으면 안 되고 익숙한 것은 추억으로 남겨두고 새로운 기술을 배워서 개발의 생산성을 높여야 합니다.
SRS문서가 분석과 설계가 정교하게 되어 있다면 병렬로 개발하는 것이 빠릅니다. 프로젝트 규모가 크고 참여 인원이 많을수록 개발 분야를 나눠 병렬로 개발해야 속도가 빠릅니다. 병렬 개발 경우 컴포넌트를 잘 나누고 인터페이스를 정교하게 정의를 해야 합니다. 인터페이스는 상호 간의 약속입니다. 서로 약속을 지키지 않으면 소프트웨어는 거대한 괴물이 되어 동작중에 어느 순간 멈춰버립니다. 괴물이 된 소프트웨어는 사용자에게 불편을 주어 영원히 그 제품을 보지 않을 수도 있습니다. 한번 신뢰가 가지 않는 소프트웨어의 고정관념은 몇 년 안에 쉽게 바뀌지 않습니다.
코딩이 완성되면 주기적으로 버전을 배포해서 테스트 과정을 거쳐야 합니다. 애자일 방식이건 폭포수 방식 개발이건 간에 개발 중간 버전마다 테스트가 되어야 합니다. 이때 버그가 발견되면 담당자는 그 버그를 해결해야 합니다. 어떤 때는 코딩하는 시간보다 버그를 잡는 시간이 많을 때도 있고 문제가 잘 해결이 되지 않을 때는 개발자 마음이 무겁습니다. 밥을 먹어도 입맛이 없습니다. 그런데 문제가 해결이 되었을 때는 행복감이 넘칩니다.
코딩을 하면서 버그를 안 만나면 좋겠지만 그 녀석은 항상 개발자를 따라다닙니다. 버그는 개발자의 마음과 정신을 갉아먹고 새치를 늘어나게 합니다. 한번 코딩으로 버그 없이 한 번에 사용자에게 바로 배포되는 소프트웨어가 나오는 날을 기대해봅니다. 버그를 최소화하는 것이 사용자에게 신뢰를 받을뿐더러 개발자 자신에게도 자유 시간을 줍니다. 버그에 발목을 잡히면 자유 시간이 줄어 피폐한 삶을 살게 됩니다. 친구도 만나야 하고 주식과 비트 코인도 공부해야 하는데 버그 때문에 시간이 없어 할 수가 없습니다. 경제 공부 못하다 보니 버그가 많은 개발자는 가난해지게 됩니다. 그만큼 다른 공부를 할 시간이 없기 때문입니다.
테스트와 기능 검증이 끝났다면 배포를 해야 합니다. 배포란 완성된 소프트웨어를 서버에 설치하거나 앱스토어에 올리는 등의 방법입니다. 최종 사용자에게 소프트웨어를 전달하는 과정입니다. SRS문서와 소스코드는 소스 관리 툴을 사용해서 버전별로 잘 관리를 해야 합니다.
그다음 단계가 유지 보수를 해줘야 합니다. 사용자가 사용을 할 때 문제점이 있거나 추가적인 요구사항이 발생했을 때 다시 코딩을 해야 합니다. 수정된 새로운 버전을 만들고 검증을 다시 하고 사용자에게 배포합니다. 기능 구현에 드는 수고보다 유지 보수에 드는 수고를 줄이는 것이 더 중요합니다. 유지 보수에 드는 수고는 시스템의 복잡성에 비례하는데 개발은 단순하게 설계하고 코딩하는 것이 가장 좋습니다.
개발자로서의 가장 멋진 모습은 분석, 설계를 잘하며 개발 속도가 빠른 개발자가 최고의 개발자입니다. 건축물로 치자면 설계와 시공을 동시에 하며 빠르게 건물을 짓는 것과 같습니다. 해결하지 못하는 문제가 없고, 모든 동료가 존경하는 매우 훌륭한 개발자는 누구나 될 수 있습니다. 요즘 개발자라고 하면 예전처럼 천시는 하지 않고 가끔 멋있다는 소리를 듣는 것을 보면 그만큼 개발자 인식이 예전보다는 좋아졌습니다. 좋은 개발자를 정의한다면 자신 경력을 관리하고 목표를 성취하며 삶을 즐기면서 살아가는 사람이라고 생각합니다. 한발 더 나아가 더 좋은 개발자가 되고 싶다면 개발 영역에만 집중하지 말고 더 넓은 곳으로 삶을 확장해나가는 것입니다. 개발과 전혀 다른 분야로 확장을 해나가는 것입니다.
개발자는 자신이 개발한 소프트웨어가 사람들에게 유용하게 사용되고 편리하게 사용을 할 때 보람을 느낍니다. 개발자는 상상한 것을 꿈꾸던 것을 현실로 만들어 낼 때 희열을 느낍니다. 상상한 대로 현실에서 이루어지는 것을 보면 개발자로서 자부심이 있습니다. 꿈과 상상을 현실로 만드는 것이 개발자들이 하는 일입니다.