TL;DR

  • 설계는 기본이자 안전장치다. 기획 문서가 없어도 개발자가 개발을 할 수 있도록 좋은 설계와 문서를 만들어야 한다.
    • 디테일한 설계 문서는 기획 문서를 대체할 수 있다.
  • IDE를 켜기 전에 요구사항 -> 시나리오(Usecase) -> SequenceDiagram -> ClassDiagram/ERD 와 같은 스케치를 먼저 해야한다.
  • 디테일은 한 번에 완성되지 않는다. 추상적으로 시작하고 TDD와 함께 보완하자.
  • 우리는 코더가 아니라 비지니스 맨이다. 설계/문서는 개발자의 책임이다.
  • 설계가 제일 중요해! 기본이야 기본!

0. 설계가 제일 중요하다. 기본이다.

“출입항이 제일 중요해! 기본이야 기본!”

“전투배치가 제일 중요해! 기본이야 기본!”

“상황보고가 제일 중요해! 기본이야 기본!”

군 복무 시절 함장님은 출입항 상황에는 출입항이, 전투배치 상황에는 전투배치가, 어떤 상황이 있을 때 마다 “~가 제일 중요해! 기본이야 기본!” 이라고 강조하셨다. 밥을 먹을때면 “반찬이 제일 중요해! 기본이야 기본!” 이라며 함장님을 흉내내고 승조원들 모두가 즐거워하는 밈 그 자체였다.

당시에도 함장님이 말씀하시는 “기본"의 의미를 어렴풋이 느꼈지만, 개발자로 커리어를 쌓으면서야 그 말이 강하게 와닿는다. TDD를 공부할 때면 “TDD가 제일 중요해!”, 아키텍처를 배울 때면 “아키텍처가 제일 중요해!”. 모두 맞는 말이다. 모두 중요하다. 기본이다.

하지만 단언컨데 설계가 가장 중요해! 기본이야 기본!

이 글은 내가 설계의 중요성을 실감하게 된 계기와, 이후 어떻게 개발에 임할 것인지를 정리한 기록이다.

작업물은 여기에: Github-PullRequest

1. 설계도 없는 건축은 말이 안된다.

나는 나의 일을 타인에게 설명할 때 주로 건축에 비유를 든다.

서비스를 만드는 것이 집을 짓는 것과 같다면,

기획자는 설계도를 만든다.

백엔드 개발자는 설계도를 기반으로 기초와 구조물을 세운다.

세워진 콘크리트 덩어리에서 사람이 살 수 없으니, 프론트엔드 개발자는 도배를 하고 타일을 붙이고 문을 달아, 사람이 살 수 있는 집으로 단장한다.

“설계도를 기반으로 만든다.” 는 것은 너무나 당연하다. 그런데 우리는 종종 그 당연한 것을 하고 있지 않다. (적어도 나는 그렇다.)

기획자가 없고 기획 문서가 없다고 해서 머릿속 설계로 얼기설기 기능을 완성시킨다. “없어도 되네?” 이런 과정이 반복되고 만들어진 프로그램은 마치 순살자이(?)같다.

  • 겉보기에는 멀쩡한 집 같지만 언제 무너질지 불안하다.
  • 기초 공사가 제대로 안되어있어 수리를 할 수도 없다. (다 지어놓고 철근을 넣는건 불가능하다.)
  • 무너트리고 새로 짓자니 자본이 너무 많이 들어갔다.

순살 자이

그렇다면 개발자는 기획자가 없으면, 문서가 없으면 평생 순살자이나 만들어야하나? 그렇지 않다. 개발자가 스스로 설계하는 과정이 필요하다.

앞으로는 개발을 시작할 때 IDE를 키기 전에,

  1. 요구사항을 정리 (Usecase, 사용자 스토리)
  2. 기능 흐름(Sequence Diagram)
  3. Class Diagram, ERD 등의 UML

를 먼저 작성해야 한다고, 주장하고싶다.

이런 설계 문서들을 작성하다보면, 기획서의 역할을 할 수도 있고, 기획서가 부족했다면 빠져있는 기획을 찾는데도 도움이 된다. 여기서 더 부족한 디테일은 테스트 코드가 보강해줄 수 있다.

이렇게 해야 적어도 사람이 살만한 튼튼한 집을 지을 준비가 끝난다.

2. 어디까지 디테일 해야할까의 고민

정답은 참 간단하다. 우리 모두 알고있다.

“할 수 있는 만큼 디테일 하게”

하지만 이건 참 어렵다. 기획자/문서도 없는 조직이라면 보통 시간, 인력도 모자랄 것이고 상황에 따라서는 도메인 지식이 부족해 디테일한 내용들을 채울 수가 없을 것이다.

그래서 나는 이렇게 하기로 생각했다.

  • 충분한 수준의 디테일을 가진 설계를 만든다.
    • 핵심 구조들과 책임을 결정하고 흐름을 만드는 것으로 충분하다.
  • 나머지 디테일은 TDD와 리팩토링으로 채운다.
    • TDD 사고방식으로 분명 디테일을 채울 수 있다.
  • 한 번 쓰고 마는 문서라는 생각을 하지 않는다. API 문서와 같이 지속적으로 업데이트한다.
  • 설계가 틀렸음을 깨달았다면? TDD로 작성했던 테스트 코드들을 믿자. 뜯어 고쳐야해도 테스트코드가 있다면 두렵지 않다.
    • 다행스럽게도 잘못 설계한 아파트는 돈도 많이 들고 뜯어고치기 어렵지만, 코드는 비교적 쉽다. 시간만 있으면 된다.
    • 테스트코드 덕에 뜯어 고치면서도 보장되는 부분들이 분명히 존재한다.

디테일은 한번에 만족스럽게 나올 수 없다.
아무리 생각해도 안나오는 디테일에 머리를 싸매지 말고, 지속적으로 수정해나가면 된다.

3. 개발자에게 설계 능력이 정말 필요해?

기획자도 있고 문서도 써준다면, 그대로 만들면 되는데 설계하고 문서 작성까지 필요한가? 라는 생각을 한번씩 한적이 있다.
이번주 멘토링에서 들은 말이 내 뒤통수를 쎄게 때렸다.

연구자면 개발만 잘하면 됨. 우리는 비지니스맨이라 다 잘해야함.

- DEVIN

우리는 단순히 코드만 짜는 “코더"가 아니다.

  • 자산인 코드를 잘 만들고 지키는 의무
  • 문서화로 지식을 남기는 의무
  • 협업 가능성을 높의는 의무

3가지는 개발자로써, 비지니스맨으로써의 의무다. 게다가 앞으로는 직업 수명이 짧아진다는 얘기(AI의 영향으로 더)가 심심찮게 들려오는데, 코드만 짜는 사람으로는 먹고 살기 더 힘들어지지 않을까? 설계 능력, 문서화 능력, 커뮤니케이션 능력은 그래서 더 중요하다. AI보다는 사람이 상황을 더 잘 이해하고 잘 수행할 수 있다.

그래서 나는 생각은 바꿨다. 기획자도 없어 문서도 없어 이런데서 개발을 어떻게 하냐! 라고 불평을 하기보다, 기획도 문서도 없는 지금이 기회다.

  • “똥코드"를 급하게 만들어내느라 허비하던 업무시간을 유의미한 업무와 나만의 학습시간으로 만들 수 있지 않을까?
  • 직접 만들어가며 실무와 함께 공부할 수 있지 않을까?

럭키비키 이거 완전 럭키비키잖아!!!!

4. 마무리

최근 배웠던 TDD, 설계에서의 장점, 느낀점은 명확하다.

  • 설계를 하다보면, 첫 설계가 틀렸다는 것을 자주 깨닫는다.
    • 하지만 테스트코드가 있으니 두렵지 않다.
  • 테스트케이스를 떠올리는 속도와 질이 설계를 얼마나 했는지에 영향을 받는다.
    • 잘 설계됐다면 테스트케이스도 좀 더 술술 나온다.
    • 그리고 테스트케이스가 술술 나오다보면 설계에서의 허점이 드러나기도 한다.

결국 나는 이렇게 말하고싶다.

설계가 제일 중요해! 기본이야 기본!

TDD(테스트코드)가 제일 중요해! 기본이야 기본!

둘은 대립하지 않고 서로를 완성시킨다. 루퍼스에 시작에서 가장 중요한 기본 두 가지를 배운 느낌이다.

thanks to loopers..