[생각정리]소프트웨어 개발의 지혜
- 소프트웨어 개발에 대한 생각, 개발자로서의 삶과 회고 등 생각 정리
연휴 때 뭔가 글을 남기고 싶어서 주저리주저리 일기처럼 글을 쓰기 시작하였는데, 주제는 "소프트웨어 개발의 지혜"이다. 소프트웨어 개발자로 살아온 삶을 회고하고, 소프트웨어를 어떻게 만들어왔는지에 대한 생각과 가치에 대해서 정리하였다. 사실, "소프트웨어 개발의 지혜"라는 책이 있는데, 베스트셀러 작가인 로버트C.마틴의 책이다.(해당 책을 보고 쓴 글은 아니지만 비슷한 내용이 있을수도 있다.) 어쨋든 생각의 흐름대로 작성한 글이라서 내용이 매우 지루할 수 있다. 이런 주제에 딱히 관심이 없다면 이 글을 읽는 것을 추천하고 싶지는 않다. 신입 개발자도 이해하기 어려울 수 있다. 굳이 안읽어도 된다.
나는 개발자로서 어떤 가치 및 철학으로, 소프트웨어를 개발하며 살아왔는가?
최근 회사에서 팀 이동 및 보직 변경을 하게 되었다. 회사에 합류한 지 만 2년이 지난 시점이었다. 팀을 이동하는 과정에서 미래에 대한 고민, 소프트웨어 개발에 대한 생각으로 많은 고민을 하였다. 그동안 개발자로서 아무 생각 없이 달려왔는데, 개발자로 어떻게 살아왔는지에 대해서 지금 시점에서 회고하는 시간이 필요하다고 생각했다. 특별히 내세울 것 도 없고, 뛰어난 개발자도 아닌 나의 소프트웨어 개발에 대한 생각을 정리하고, 앞으로 어떻게 개발자로 살아가야 하는지 스스로 정답을 찾아보자.
사실 아직 정답을 찾지 못했지만, 부족한 실력의 평범한 개발자인 필자는... 더 많은 노력을 해야 한다는 사실
히트 리프레시
최근에 읽은 책의 제목은 "히트 리프레시"이다. "사티아 나델라"라는 마이크로소프트 CEO가 쓴 자서전인데, IT 직종이라면 한 번쯤은 읽어볼 만한 책이다. 주요 내용은, 가장 본질적인 가치만 남긴 채 모든 것을 새롭게 바꾼다는 내용이다. 사람은 누구나 더 성장하기 위해 반드시 변화가 필요한 순간에 부딪힌다. 문제는 이런 상황에서도 쥐고 있던 사탕을 내려놓지 못한다는 것이다. 필자는 바로 지금 그런 상황에 부딪혔다. 필자는 포털 서비스 업무만 7년 동안 하였고, 포털에 대한 미련이 컸다. 비록 그동안 개인 기술발전이 많이 없었지만 보람을 느끼고 있었기에 만족한 삶이라고 생각한다. 후회는 없지만, 심각하게 고민을 해보았다. 팀 이동을 고민하면서 계속 생각했던 것은 내가 정말 소중하게 생각하는 가치는 무엇인가?이다.
개발자로서 또는 소프트웨어 개발을 위한 가장 본질적인 가치는 무엇인가??
MS의 CEO 사티아 나델라는 말한다. 사실, 하던 일을 그만두는 것은 새로운 도전을 시작하는 것만큼이나 어려운 일이다. 그렇기에 변화가 필요한 순간 우리에게 필요한 건, [가장 본질적인 가치]라고 말한다.
무슨 일이 있어도 거짓말은 하지 않겠다는 [자신과의 약속],
목표를 위해 남을 짓밟지 않겠다는 [가장 깊은 신념] ,
혹은 모든 것을 걸어서라도 이루고 싶은 [마지막 꿈처럼]
나를 더욱 빛나게 할 "단 하나의 가치"이다.
삶의 가장 밑바닥에 있을 그 순수한 가치야말로 우리 인생의 방향이 되고, 자신을 빛나게 할 본질과 방향을 아는 사람은 그 어떤 변화에도 적응할 수 있을 테니까...
나는 소프트웨어 개발에 대해서, 어떤 생각과 가치로 살아왔는가?
소프트웨어 설계/분석에 대해서
소프트웨어 개발 전에 진행하는 분석/설계는 너무 중요하다. 하지만, 나는 그 중요한 단계는 간결하게 진행하기를 희망한다. 개발 전에 진행하는 너무 과도한 선행 분석/설계는 오히려 프로젝트 진행을 어렵게 할 수 있다. 예전 경험에 따르면, 선행 설계를 몇 달 동안 진행을 하고, 실제 개발단계에 들어가면 그 방향성은 또다시 바뀌게 된다. 제품 담당자 및 경영진의 의견이 추가되다 보면 의견이 덕지덕지 붙어서 프로젝트가 매우 복잡하게 진행되는 경우를 너무 많이 봐왔다. 사실, 소프트웨어가 복잡해지는 이유는 사람의 욕심으로 인해서 복잡해지는 것이다. 그렇지만, 이걸 막을 수는 없을 것이다. 필연적으로 소프트웨어는 복잡해질 수밖에 없다. [도메인 주도 설계 35page]에 이런 글이 있다.
익스트림 프로그래밍은 설계에 관련된 의사결정의 중요성은 인정하지만 선행 설계는 완강희 반대한다. 과도한 설계는 분석 마비라는 증상을 겪어야 했고, 팀원들은 전혀 진전시킬 수 없는 불완전한 설계에 두려움을 느껴야 했다. 대신, 의사소통과 프로젝트의 방향을 빠르게 변화시킬 수 있는 능력을 향상하는데 노력을 기울인다. - 도메인 주도 설계 35page
필자의 생각과 완벽하게 일치하는 글이다. 그렇다면, 모든 설계는 간결하게 진행해도 될까? 간결하게 설계를 진행하지만, 팀 내 동의는 반드시 얻어야 한다. 팀 내 리뷰를 진행하고 팀원들과의 상호존중의 가치를 실현해야 한다. 개발은 혼자 하는 것이 절대 아니다. 이 과정에서 팀 내 개발자들 사이에 마찰이 생기게 된다. 마찰이 심하다면 리더의 중재가 필요하며 이때 리더의 역할이 정말 중요하다. 필자가 생각하는 가치가 "익스트림 프로그래밍"과 유사하기는 하지만 애자일 또는 익스트림프로그래밍을 억지로 도입하겠다는 게 생각은 절대 아니다. 참고로 애자일은 실패한 사례가 더 많다. 실패한 사례의 이유는 다양하지만, 애자일의 진정한 가치를 모르고 무조건 프로세스를 도입하려고 했을 때 실패할 확률이 높다. 어쨌든 설계는 해당 프로젝트의 개발 담당자가 진행하고, 선행 설계는 너무 장시간 진행하지 않는다. 프로젝트의 크기에 따라서 설계 기간을 결정해야 한다. 어느 정도 상세하게 또는 간결하게 설계를 진행해야 하는지에 대해서 정답은 아직 찾지 못했지만, 중요한 것은 설계는 반드시 추후에 변경 가능하도록 사용성 있게 구현해야 한다. 한 번에 완벽한 설계를 만드는 것보다는,
세상의 변화에 대해서 빠르게 적응할 수 있도록 사용성 높게 설계하는 것이 중요하다.
논란의 여지가 많은 내용이다. 도메인마다 조금 다를 수 있다고 생각한다. 필자의 경험은 포털에 한정되어 있기 때문에 매우 제한적이고 개인적인 생각일 수 있다. 금융권이나 제조업 등은 조금 과하더라도 상세한 설계가 필요하지 않을까? 경험해보지 않아서 모르겠지만 도메인에 따라서 지혜롭게 판단하자.
다시한 번 강조하지만, 선행 분석/설계는 너무 중요하다. 단지, 과도한 설계 과정은 피하자는 생각이다.
소프트웨어는 어떻게 유지되어야 하는가?
소프트웨어는 얼마나 자주 변화가 필요한가? 작년 Pivotal의 스프링부트 리드 개발자인 Phil Webb 의 키노트 중, 내 생각과 일치하는 구문이 있어서 참고해본다.
"Software maintenance is not keep it working like before it is keep it being useful in a changing world - Jessica Kerr "
" 소프트웨어 유지는 이전과 같이 동작하게 유지하는 것이 아니라, 변화하는 환경 속에서 항상 쓸모 있도록 하는 것이다."
단, 너무 많은 변화는 오히려 소프트웨어의 품질을 떨어뜨릴 수 있다. 어려운 일이지만, 항상 Useful 하도록 소프트웨어를 유지해야 한다. 그래서 리팩토링은 정말 너무 중요하다. 리팩토링은 다음에 추가되는 기능의 설계/개발를 위한 준비 단계라고 생각한다. 리팩토링을 게을리한다면 다음 개발 건에서 일정이 배로 늘어날 것이다. 리팩토링이 어려운 수준이라면, 과감하게 플랫폼 전환을 하는 것에 대한 고려가 필요하다. 단, 제품 담당자와 충분한 상의를 거쳐서 신중하게 진행해야 한다. 하지만 모든 새로운 플랫폼 또는 특정 기술이 모든 것을 해결해준다는 생각에는 큰 함정이 있다.
SpringOne Platform 2017의 키노트를 보자. 필자가 많은 공감을 얻은 세미나 키노트 영상이다.
https://www.youtube.com/watch?v=MQamx7-bCVI
"A good developer is like a werewolf: Afraid of silver bullets."
"소프트웨어 엔지니어링에 만능 도구는 없다."
새로운 도구는 절대 모든 문제를 한 번에 해결해 주지 않는다. 새로운 도구뿐만 아니라, 표준화된 가이드 역시 한 번에 문제를 모두 해결해 주지 않는다. 이 문제에 대해서는 마이크로서비스 아키텍처에 대해서도 고민을 같이 해봐야 한다. 마이크로서비스 아키텍처는 기본적으로 분산 아키텍처 환경이고, 분산된 마이크로서비스는 어떤 기술을 사용해도 괜찮다. 하지만, 공통으로 사용하는 기능은 예를 들어서 보안이나 로깅 등은 라이브러리를 표준화해서 적용하여 재사용 및 개발 생산성을 높이는 작업을 같이 병행한다. 넷플릭스의 사례에서도 유사한 사례를 확인할 수 있다. 하지만, 시간이 지날수록 해당 공통 라이브러리 역시 레거시 프로젝트로 변하고, 해당 라이브러리를 적용한 모든 프로젝트를 변경해야 하는 상황이 발생할 수도 있다. 어느 수준까지 공통 라이브러리를 사용할지에 대해서는 논란의 여지가 크지만, 필자는 전체 프로젝트를 표준화된 플랫폼으로 통일시키겠다는 의견에 대해서는 명백히 반대하는 입장이다. 마이크로서비스 각각의 프로젝트는 상황에 맞는 기술 사용을 할 수 있고, 좀 더 자율성 있는 개발을 할 수 있도록 해야 한다. 하지만, 마이크로서비스의 치명적인 단점이 될 수 있는 복잡한 서비스 관리의 이슈가 생길 수 있다. 마이크로서비스 아키텍처는 복잡도가 증가하고, 너무 다양한 기술셋으로 서비스 운영이 오히려 어려워질 수 있다. 물론 그 사이 담당자의 퇴사는 더더욱 서비스 운영을 어렵게 만든다. 적당한 균형이 필요하지만 아쉽지만 그것에 대한 정답은 없다.
그 정답은 오직 개발팀 안에서만 찾을 수 있다.
필자는 사내 프레임워크 개발은 반대한다.
단, 무조건 반대하지는 않는다. 대안이 있어야 한다. 대안에 대해서는 Outsider(아웃사이더)님의 좋은 글이 있어서 링크를 남겨놓는다. (내 기준으로는)정말 공감이 가는 글이다.
https://blog.outsider.ne.kr/924.
추가로, 로버트 C.마틴의 "클린아키텍처" 라는 원서를 보면, 프레임워크에 대한 재미난 비유가 있다. 프레임워크를 관리하지 못할거면 아예 시작을 하지 말라고 조언하고 있는데, 비유를 결혼 반지에 표현했다. 결혼 반지를 끼는 순간, 돌이킬수 없는 상황이 생기므로 처음부터 반지를 끼지 말라고 조언한다. 결혼한 사람들에게는 공감되는 비유일 것이다ㅎㅎㅎ
관리하지 못할 무언가 거대한 괴물을 만들어낼거라면, 차라리 사내프레임워크 아예 시작을 하지 말자.
IT개발팀, 리더쉽에 대한 짧은 경험
짧지만 1년 동안 팀을 운영한 경험으로 IT개발팀 조직문화에 대해서 많은 고민을 하였다. 사실 나는 태생적으로 서번트리더에 가깝다. 중요한 개발 건은 팀원에게 기회를 주는 편이었고, 잡다한 일은 당시에는 내가 맡아도 상관 없다고 생각했다. 그래서 실제로 덜 중요하고 잡다한 일을 많이 했다. 필자가 생각하는 최고의 팀은, 자기 조직화된 팀이고 서번트리더는 그 중간에서 조율하는 역할을 수행하는 것이었다. 하지만 이 역할은 일반 조직에서는 맞지 않을 가능성이 매우 높다. 왜냐면, 많은 회사에서는 일방적인(Top-Down) 업무 진행 및 마이크로매니징을 중요하게 생각하기 때문이다. 대부분의 회사에서는 서번트 리더십 보다는, 경영진의 생각을 잘 전달하면서 팀원들을 잘 이끌 수 있는 팀리더가 필요하다. 마이크로서비스 아키텍처 및 서번트리더쉽 등 내가 생각했던 가치들을 실현하기 위해서 가장 중요한 것이 조직문화라는 것을 깨달았고, 조직문화가 뒷받침되어있지 않다면 그 가치들은 아무 의미가 없다.
마이크로서비스 아키텍처, 서번트 리더쉽 은 결국 조직문화가 뒷받침되어야 한다.
자기 조직화된 팀의 자율성, 빠른 실행 및 동기부여
자기 조직화된 팀은 자율성을 갖고, 그에 맞는 책임감을 부여하여 업무를 수행해야 한다. 물론, 연차가 낮은 개발자는 올바른 지도와 개발 방향성 전달이 필요하다. 하지만, 주니어 개발자라도 실력이 충분히 뒷받침된다고 판단되면 전적으로 믿고 맡기는 것이 좋다고 생각한다. 중요한 개발 건이 있다면 기회를 주고 성장할 수 있도록 적극적으로 지원해야 한다. 또한 그런 과정은 가능하면 빠른 결정 및 빠른 실행을 해야 한다. 빠른 실행은, 팀원들에게 큰 동기부여를 줄 수 있다. 물론, 너무 빠른 결정은 주의가 필요하다. 잘못된 판단으로 첫 단추를 잘못 끼울 수도 있기 때문이다. 빠름과 느림 사이에 균형이 중요한데 필자는 웬만하면 조금 더 빠른 실행이 좋다고 생각한다. 대신 빠른 실행은 반드시 가치 있고, 간결하고 하나씩 완성할 수 있게 진행해야 한다.
간결하게, 가치 있게, 하나씩 완성하기
소프트웨어 개발이 아래와 같이 3가지 경우만 있다고 가정하자.(현실에서는 변수가 많다.)
1. 기획자의 요구사항이 명확하고, 제품 출시 날짜가 정해져 있는 경우
2. 프로젝트 막판에 요구사항이 추가되어 제품 출시 직전에 야근을 하거나 스펙아웃 하는 경우
3. 요구사항이 명확하지 않고, 시간이 지날수록 제품을 만들어내는 과정에서 요구사항 변경이 많은 경우
1. 기획자의 요구사항이 명확하고, 제품 출시 날짜가 정해져 있는 경우
보통 소프트웨어는 제품 책임자의 요구사항에 맞게 분석/설계/개발/테스트/배포 단계를 진행한다. 제품 담당자의 기획 요구사항은 명확하기 때문에, 일정이 초반에 정해진다. 제품 배포 날짜도 정해져 있고, WBS 방식의 일정 수립도 가능하다. 필자는 포털업계에서는 대부분의 프로젝트를 이렇게 진행하였고 배포일도 대부분 맞추었다.
2. 프로젝트 막판에 요구사항이 추가되어 제품 출시 직전에 야근을 하거나 스펙아웃 하는 경우
하지만 배포 일정을 제대로 맞추지 못한 프로젝트도 종종 있다. 코딩 오류 또는 요구사항 이해 부족으로 인한 논리적인 오류에 의한 경우도 가끔 있지만, 사실 프로젝트 막판에 추가된 요구사항이 덕지덕지 붙어서 발생한 경우가 대부분이다. 야근을 해서 일정을 맞추거나, 스펙아웃을 해야 한다. 아니면 일정 조정을 한다. 그래도 이 정도 프로젝트는 항상 경험하기 때문에, 긍정적으로 진행할 만하다.
3. 요구사항이 명확하지 않고, 시간이 지날수록 제품을 만들어내는 과정에서 요구사항 변경이 많은 경우
이런 경우가 가장 힘들다. 프로젝트 시작 단계에서부터 불명확한 요구사항을 기반으로 프로젝트 진행하는 경우이다. 비즈니스 요구사항도 명확하지 않고, 무언가를 만들어 내라고는 강요하지만 실제로 기획자의 생각을 도무지 알 수가 없는 경우이다. 필자는 소프트웨어공학을 전공하였고, 요구사항을 취합하는 것에 대해서도 나름 공부를 하였지만, 비즈니스 요구사항이 명확하지 않은 경우에 요구사항을 도출 및 정리해내는 것은 너무 어려운 일이었다. 이런 프로젝트는 중간에 요구사항이 바뀔 가능성도 매우 높은데, 사실 거의 항상 요구사항이 변경된다. 사내 정치, 제품 담당자의 생각의 변화, 개발자의 역량 등 너무 많은 변수로 인해서 프로젝트가 처음과는 다른 방향으로 진행되는 경우가 비일비재하다.
자, 이런 경우에는 반드시 "간결하고, 가치 있고, 하나씩 완성하자"라는 생각으로 프로젝트를 진행해야 한다.
비즈니스 요구사항이 명확하지 않고, 정해진 일정이 없는 프로젝트라면 "간결하게, 가치 있게, 하나씩 완성하기"의 가치를 기준으로 진행해야 한다고 생각한다.
아래 책을 꼭 한번 읽어보자. 정말 좋은 책이다. 국내 번역서도 있다.
소프트웨어 개발의 "본질적인 가치"는 무엇인가?
주저리주저리 쓴 글을 다시 한번 정리해봤다. 내가 생각하는 가장 중요한 가치는 무엇인지?
가치1 - 소프트웨어는 반드시 변화에 빠르게 대응할 수 있도록, 사용성 높게 유지해야 한다.
변화 없이 정체된 레거시 프로젝트는 좋지 않지만, 너무 많은 변화는 오히려 큰 혼란을 줄 것이니 적절한 균형이 필요하다. 그 균형 사이에서 소프트웨어는 사용성 높게 유지해야 한다. 끊임없는 비즈니스 변화에도 빠르게 대응할 수 있는 적응력이 필요하다. 그런 관점에서 필자는 사내 프레임워크는 명백하게 반대한다. 사내 프레임워크는 지속적으로 유지하기도 어렵고, 결국에는 정치적인 이유로 변질되기 때문이다.
가치2 - 자율성, 책임감을 가져야 한다.
내가 말한 자율성은 제품 기획에 대한 자율성이 아니다. 기술 선택 및 시스템 아키텍처에 대한 자율성이다. 물론, 주니어 개발자는 역량 부족으로 인해서 잘못된 판단을 할 수 있다. 옆에서 잘 지도해줘야 한다. 경력 개발자라면 스스로 아키텍처를 정할 수 있어야 한다. 단, 상호 존중이 더 중요하다. 개발 전에 팀 내 아키텍처 리뷰를 진행하고, 상호 존중의 가치를 실현해야 한다. 그리고, 이런 가치가 비로소 동기부여가 되고 즐겁게 개발할 수 있는 힘이 된다.
가치3 - 설계는 정말 중요하지만, 과도한 설계보다는 빠른 설계&실행을 해야 한다.
설계 과정은 정말 중요하지만, 그 과정이 너무 길어지면 안 된다. 왜냐면 동기부여를 떨어뜨리기 때문이다. 설계만 몇 달 진행하다가 끝나는 프로젝트도 꽤 많이 경험했다. 하지만, 이 가치는 특정 도메인에 한해서 적용된다. 왜냐면 과도한 설계가 오히려 필요한 프로젝트가 있기 때문이다. 예를 들어서 금융이나, 제조업 등이다. 이런 경우에는 요구사항이 아주 명확하기 때문에 설계 단계에서 꼼꼼하게 진행하는 것이 좋을 것이다. 하지만, 일반적인 웹서비스는 과도한 설계보다는 빠른 설계와 실행이 중요하다고 생각한다.
가치4 - 요구사항이 명확하지 않다면, [가치있게, 간결하게, 하나씩 완성] 해야 한다.
오해하지 않았으면 좋겠다. 필자의 지극히 개인적인 생각이다.
소프트웨어 개발에 대해서는 어느정도 정리가 되었다. 그럼, 개발자로서의 본질적인 가치에 대해서 생각해보자.
개발자로서의 "본질적인 가치"
그동안 개발자로서 어떤 가치로 살아왔는지 생각해보면 딱히 떠오르지 않는다. 서비스에 대한 애정, 그리고 그 애정에 보람을 느끼는 것을 개발자의 숙명이라고 생각했었는데, 실제로 소프트웨어는 영원하지 않다는 사실을 깨달았다. 서비스 또는 소프트웨어보다 더 중요한 것은 바로 "개발자로서의 본질적인 가치"이다.
가치1. 블로그 주도형 개발자
개발자로서 기술 공유는 너무 중요하다. 또한, 자신의 생각을 글로 표현하는 것은 리더가 되는 가장 중요한 가치라고 생각한다. 사실, 같은 팀에서 함께 일했던 동료들의 모습을 보고 자극을 받았는데, 반만이라도 따라가자 라는 생각으로 시작하게 되었고 아직은 많이 부족하지만, 작년 11월부터 지금까지 약30개의 블로그 글을 작성하였다. 다른 개발자들에 비하면 정말 초라한 수준이지만, 퇴근 후 또는 주말에 작성하는 글이라서 나는 이 정도도 만족하고 있다.
가치2. 주변 개발자의 말에 귀를 기울이고, 배우고, 공유해라
조금 더 호기심을 갖고, 주변의 말에 귀를 기울여야 한다. 세미나는 물론 각종 기술 리뷰에 관심을 갖고, 팀원들의 얘기에 관심을 갖자. 주변에 도움을 받는 만큼, 나의 지식을 적극적으로 공유한다. 사실 기술 블로그 역시 비슷한 맥락이지만, 블로그뿐만 아니라, 말로, 글로, Source로 다양한 방법으로 공유를 하고 개발자 네트워크를 이어가야 한다.
가치3. 일일 커밋
업무 외에 프로그래밍 공부 겸 일일 커밋하는 습관을 키우고 있다. 작년 말부터 github부터 다시 시작하였고, 닥치는 대로 커밋하기 시작하였지만 아직은 많이 부족하다.
가치4. 건강
마음도, 몸도 건강해야 한다. 즐거운 마음, 긍정적인 마음으로 임하자. 그리고, 건강을 위해 규칙적인 운동&생활과 건강검진은 필수이다.
작년까지 필자의 메신저 대화명이 "가치있게, 간결하게, 하나씩 완성하기" 였다면 올해 메신저 대화명은 아래와 같이 바뀌었다.
{"input" : "learn", "output" : "share"}
글을 마무리하면서
이런저런 생각으로 주저리주저리 글을 작성하였는데, 내용이 너무 난잡해진 것 같다. 그래도, 나름 내 생각이 정리가 된 것 같다. 앞으로 나에게 어떤 변화가 있더라도 내가 생각하는 본질적인 가치는 지키면서 개발자로서 행복하게 살아갈 수 있도록 노력하며 살아야겠다.
추가(6/1일)
해당 글에 대한 추가 의견이 있어서 작성한다. 참고로 해당 글이 많은 사람들에게 공유가 되었는데, 개인적으로는 영광이기도 하지만, 부족한 실력으로 이런 글을 작성한 필자 스스로 부끄럽기도 하다. 더 노력하고, 훌륭한 개발자가 되도록 노력하는 수밖에 없다.
추가의견 - 첫번째
해당 글은 필자의 개인적인 생각을 작성한 글이다. 각종 자료를 참고하기는 했지만, 누군가의 글을 보고 복사한 것이 아니다. 이런 얘기를 하는 이유는 최근에 나온 원서가 내 생각과 많이 유사하기 때문이다. 누가 보면 그 책을 보고 쓴 글이라고 착각할수도 있겠다.
"Clean Architecture: A Craftsman's Guide to Software Structure and Design (Robert C. Martin Series) 1st Edition"
해당글의 주제와 같은 "소프트웨어개발의 지혜"라는 유명한 책을 작성한 로버트C마틴의 작년 책이다. 제목은 "클린 아키텍처" 이다. 뭔가 제목이 매우 끌리는 책이다. 해당 원서를 구입해서 읽어봤는데, 일부 내용이 내 글과 매우 유사하다. 소프트웨어를 어떻게 유지할지, 사내 프레임워크를 어떻게 관리할지 등에 대해서 아주 유쾌한 비유와 함께 좋은 내용을 포함하고 있는 원서이다. 유명한 저자의 책이니 아마도 누군가가 번역할 것이고, 국내에도 출판할 것이다. 기회가 된다면 원서를 먼저 읽어보길 바란다.
추가의견 - 두번째
최근에 필자가 여러 경험을 하면서, 깊게 깨달음을 얻었다. 소프트웨어를 유지하는 가장 중요한 키포인트는 바로 사람이고, 사람들의 커뮤니케이션이 가장 중요하다는 사실을 깊게 깨달았다. 소프트웨어를 유지하는 가장 중요한 요소는 바로, 팀원들의 협업 및 커뮤니케이션 이며 그들의 신뢰를 바탕으로 좋은 소프트웨어를 만들 수 있다. 신뢰! 정말 중요하다.
팀원들 사이의 신뢰! 신뢰가 바탕이 되어야 좋은 소프트웨어를 유지할 수 있다.
다음 글은, 기술부채에 대한 글입니다.
