etc

적당히 괜찮은 소프트웨어 개발하기

good enough software, pragmatic programmer, 실용주의 프로그래머

사내 스터디 발표를 위해 준비한 자료를 블로그에 올려놓습니다.

SlideShare: https://www.slideshare.net/YoungCheolSon/developing-good-enough-software

적당히 괜찮은 소프트웨어 개발하기

Developing good enough software

Inspiration

실용주의 프로그래머: 4장 적당히 괜찮은 소프트웨어

스타트업은 처음이라 😇

이전 SI 회사에서 팀이 개발 방향에 대한 고민없이 공장에서 물건을 찍어내듯 기능을 구현하고 당장 기능 구현, 버그 처리에 급급한 환경에서 일하다보니 기능 구현도 중요하나 이를 구현하는 방향에 대해서도 고민을 많이 하게 되었다. 하지만 절대적인 경험, 경력이 적다보니 고민의 시간이 길어지고 그러다 보니 기능 구현이 생각한 것 이상으로 시간이 더 걸리게 되었다.

서비스 기업으로써 새로운 기능을 빠르게 시장에 내놓는것이 시장을 리딩하는데 있어 중요한 요소이나 주니어 개발자로서 개발 속도 ⇔ 코드 퀄리티 딜레마가 있다.

적당히 괜찮은 소프트웨어

우리는 종종 뭔가 나아지게 하려다가 괜찮은 것마저 망친다.
– 리어왕 1.4

적당히 괜찮은 것은 어떤 것인가?

(from Naver dictionary)

적당히 괜찮은이라는 문구는 너절하거나 형편없는 코드를 의미하지 않는다.
시스템이 성공하려면 사용자의 요구사항을 충족해야 한다.

  • 실용주의 프로그래머

**적당히**라는 단어가 줄 수 있는 부정적인 어감이 적당히 괜찮은 소프트웨어가 단지 적당히 만들어낸 결과물이라고 생각 할 수 있다.

하지만 적당히 괜찮은이라는 문구는 너절하거나 형편없는 코드를 의미하지 않는다.
사용자의 요구사항을 충족하는 어느정도 정돈되고 잘 동작하는 소프트웨어를 말한다.

적당함은 왜 필요한가?

완벽은 불가능하다

“Give them the third best to go on with; the second best comes too late,
the best never comes.” (by Robert Watson-Watt)

이미 괜찮은 프로그램을 과도하게 장식하거나 지나칠 정도로 다듬느라 망치지 말라.

완벽하지 않을 수도 있다. 걱정하지 마라. 완벽해지기란 불가능하다.

이미 범용적으로 사용되고 판매되는 소프트웨어들도 결함이 있다.

사용자는 제품이 완벽하지 않아도 상관하지 않는다

사용자들은 완벽한 버전을 위해 일년을 기다리느니 차라리 오늘 당장의 불편한 소프트웨어를 사용하고싶어한다.

Late is never better

Product A와 B가 있다고 했을 때

  • A: 기능은 하지만 가끔씩 오류가 나서 사용자가 주기적으로 저장을 하지 않으면 자료가 날아가는 경우가 있다.
  • B: A에 비해 저렴하고 추가 기능이 여러가지 있다. 하지만, 아직 출시가 되지 않은 제품이다.

이미 시장에는 A를 사용하는 유저들이 많다. 1년 뒤 B가 출시 되면 사용자들이 A를 버리고 B로 쉽게 갈아탈까?
⇒ 그렇지 않을 것이다.

이미 A를 사용하면서 생긴 관성을 거스르기 힘들다.

  • 파일 포맷
  • 다른 제품을 배워야하는 노력

비록 A가 결함은 있지만 사용자가 원하는 기능을 잘 수행하고 있다.

빠르게 제품을 내놓아 시장을 선점을 하는 것이 중요한 서비스 기업의 특성 상 제품을 시장에 빠르게 내놓는 것이 제품의 몇몇 결함보다 중요할 수 있다.

타협하기 (Negotiating)

품질을 통제할 수 있다면 좋겠지만 실세계에서는 진정으로 완벽한 것을 만들어 내기란 불가능하다. 그렇기 때문에 타협의 과정이 필요하다.

시스템이 성공하려면 생산해 낸 것이 어느 정도면 적당히 괜찮은지를 결정하는 타협의 과정에 사용자가 참여할 기회를 가져야 한다. 사용자는 본인이 원하는 요구사항을 확인할 수 있는 직접 만져볼 수 있는 제품을 일찍 준다면, 피드백을 통해 더 나은 솔루션에 도달할 수 있을 것이다.

또한 회사는 타협하는 시점에 어느정도 결함은 안고 가는 전략을 취할 수 있다.

마무리

개발자는 (적은) 한정된 시간에 (많은) 주어진 업무를 처리하기 위해 유혹에 빠지기 쉽다.
당장의 편의를 위해 빠른 길을 선택하면 당장의 몇 초를 절약할 수 있을지라도, 나중에는 몇 시간을 잃을 수 있다.
나중의 고통을 피하기 위해서는 훈련과 미연에 시간을 기꺼이 투자할 의지가 있어야한다.

x: Release Version, y: Cost

그렇기에 개발자는 스스로 본인의 업무에 책임을 지고 더 좋은 품질을 갖는 결과물을 만들어내려는 자세를 지녀야한다.

이러한 자세는 전문가로서 훌륭하고 마땅히 가져야하는 자세라고 생각하지만 제품을 직접 개발하는 입장에서 (존재하지 않는) 완벽을 향해 달려가다 스트레스를 받으면서 제풀에 지치는 것 보다 어느정도 적당한 수준에서 타협을 통해 생산성을 높이는 것 또한 개발자 뿐만 아니라 회사에게도 좋은 전략이라고 생각한다.

적당히 괜찮은 소프트웨어를 통해 개발자는 보다 생산성이 올라갈 것이며, 사용자는 결과물에 한층 더 행복해 할 것이다.

참고 자료

Share