23.12.11~23.12.17

업무

onboarding package 아키텍처 변경

문제점

지난주 금요일. PoC 대상 기업의 기획안을 전달받아 우리 서비스를 적용했다.

기존 생각했던 기능에서 크게 벗어나지는 않았지만,

실 production 환경에서 테스트를 해보니 이것저것 수정할 사항들이 발견되었다.

 

그런데 그 과정에서, 시스템 복잡도가 걷잡을 수 없이 커져버렸다는 생각이 들었다.

 

해당 패키지를 처음 개발했을 당시만 해도 명확한 기획안이나 요구사항이 존재하지 않았다.

따라서 구체적인 협업 방향이 나오기 전까지는 어떻게 되든 반드시 필요한 기능을 부분적으로 개발하고자 했고,

'온보딩 요소들을 생성한다', '사용자 페이지에서 특정 요소를 찾는다' 등의 개별 기능들만 존재했었다.

 

점차 협업 기업이 늘어나며 요구 사항이 구체화되었는데

요구 사항 하나 하나는 그렇게 복잡하지 않았기 때문에, 기존 로직을 최대한 수정하지 않는 선에서 이를 반영했다.

그리고 이것이 큰 실수였다.

 

이러한 상황이 반복되자...

기능 자체는 어찌저찌 동작하지만

각 모듈들이 서로 어떠한 관계로 구성되어 있는지,

애플리케이션 전체 구조는 어떻게 작성되어 있는지 파악하기가 불가능한 지경이 되고 말았다.

 

그리고 이는 필연적으로

1) 기존 기능 수정의 어려움 (해당 변경사항이 어디에 영향을 미칠지 알 수 없음)

2) 신규 기능 추가의 어려움 (새로 만들고자 하는 기능이 어떤 모듈과 연관되어 있는지 파악할 수 없음)

3) 협업의 어려움 (특정 모듈의 기능과 책임을 공통 언어로 표현할 수 없음)

과 같은 문제점으로 이어졌다.

 

이러한 상황 속에서 무언가를 추가적으로 개발하는 건 무의미한 행위라 판단,

본격적인 Poc 전 위 문제점들을 해결하고자 했다.

 

해결 방안

위에서 언급했던 문제점들이 발생한 가장 큰 원인으로는

→ 디자인 패턴, 그중에서도 아키텍처 패턴의 부재 를 꼽을 수 있다.

(사실 내가 저질렀던 실수와 문제점, 고민들은... 예전 선배 프로그래머들이 모두 겪었던, 아주 흔해빠진 이야기다)

 

아키텍처 패턴이 존재하지 않았기 때문에

새로운 요구사항을 구현하기 위한 모듈의 역할과 관심사는, 해당 모듈을 개발하는 그 당시의 상황과 생각에 의존할 수밖에 없었다.

하지만 개발 당시의 상황과 생각은 (당연히) 매번 달라질 수밖에 없었고...

이로 인해 일관되지 않은 추상화 레벨의 모듈들이 얼기설기 이어진 형태의 서비스가 탄생하고 만 것이었다.

 

그렇다면 이를 어떻게 해결할 수 있을까?

→ 각 기능과 책임을 명확하게 정의한 개념을 설계하고, 각 개념 속에 속하는 모듈들을 개발하면 되지 않을까?

기존에 작성된 모듈들의 흐름을 크게 추상화해 보니...

현재 시스템은 위와 같은 6개의 레이어로 분리할 수 있었다!

아하. 그렇다면 각 레어어를 정의하고, 해당 정의에 맞는 모듈들을 개발하면 되는 걸까?

 

이 역시 해결방안이 아니라는 생각이 들었다! 왜? 

1) 위 6개의 레어어는, 지나치게 내 생각에만 의존한다 (협업의 어려움)

2) 각 레이어에 속하지 않는, 새로운 요구사항이 발생할 경우, 해당 변경사항이 다른 레이어에 불필요하게 전파될 가능성이 크다 (기능 추가, 수정 어려움)

→ 처음 겪었던 문제사항이 반복 돼버리고 만다.

 

그런데... 위 단계를 가만히 보고 있으니, 아주 뻔한 단어가 떠올랐다.

유레카... 각 단계를 한번 더 추상화하고, 각 레이어 별 관계를 파악해 보니

소프트웨어 아키텍처 패턴의 기본 중의 기본인 MVC 패턴에 그대로 대입할 수 있었다!

(구체적인 패턴 적용은 별도 포스팅으로 작성할 예정)

 

주중에 하기에는 기한을 맞추지 못할 것 같아, 주말을 쏟아 애플리케이션 전체를 MVC패턴에 맞게 변경했고...

그 덕분에 월화 동안 PoC 기업의 요구사항을 빠르게 반영해 제공해 줄 수 있었다!!!

PoC 기업 mvp 제공

협업 기업에서 제공해 준 기획안에 맞게, 우리 서비스를 적용해 제공했다.

목요일에 수술이 있어서 무려 이틀반 동안 휴가를 써야 했었는데...

1차 개발안을 수요일 오전 안에 제공하고, 요청 사항 발생 시 수술 이후 병실에서 개발하기로 일정을 산정했다.

 

div삽입 익스텐션, 사용자 페이지 dom구조 등의 케이스가 속속 등장하면서

과연 일정에 맞출 수 있을까?하는 생각도 잠시 들었지만...

주말 간의 노력이 헛되지 않았던 걸까, 무사히 모든 요구사항을 구현한 후 성공적으로 개발 내용을 전달할 수 있었다.

피드백 사항들을 수술 후 반영할 예정!

 

회고

선대 개발자

MVC 패턴을 적용한 후... 이런 생각이 들었다.

지금은 View와 Model이 하나뿐이기 때문에, 위 패턴으로도 유지보수와 확장이 어렵지 않을 테다.

하지만... 만약 애플리케이션이 복잡해진다면?

여러 개의 View와 Model이 생기고, 하나의 변경사항이 수십 개의 Model과 View에 반영되어야 한다면?

→ Flux 등의 패턴이 새로운 대안이 될 수 있을 테다.

 

그런데 이런 생각을 하고 나니,

마치 내가 소프트웨어의 역사를 걷고 있단 생각이 들었다!

 

사실 위 패턴들을 모르는 게 아니었다. 오히려 아주 잘 알고 있었다. (디자인 패턴은 언제나 재미있으니)

하지만 이전까지는 각 아키텍처들의 등장 배경, 구현 방안, 한계 등을 그냥 글을 통해 읽고 이해하는 정도였다.

 

아무것도 없던 패키지를 직접 0부터 개발하다 보니

이전에 읽었던 선대 개발자들의 실수를 그대로 답습하는 내 모습이 슬프면서도 웃겼다. 하하!

그리고 혼자서 끙끙거리며 떠올린 해결책 역시... 선대 개발자들이 제시했던 해결책과 방향이 비슷해 신기하고 놀라웠다.

 

그러면서 든 생각으론

1) 새로운 개념을 항상 그 등장 배경이 존재한다. 어쩌면 사용 방법보다, 이를 이해하는 것이 더 중요하다.

2) 시행착오를 겪겠지만, 그럼에도 불구하고, 최대한 많은 지식을 습득하는 것도 중요하다. 알아야 나중에 써먹는다.

3) 소프트웨어 세계에서, 은빛 탄환은 없다. 절대로!

 

이왕 이렇게 된 거

결국 십자인대 수술을 받았다. (지금도 입원한 채 회고를 작성 중)

고생할 가족들에게도 미안하고... 한창 바쁜 와중 사무실을 비워, 팀에게도 미안한 마음이 컸다.

약간의 죄책감도 보너스.

 

하지만 벌어진 일을 되돌릴 방법은 없다.

이왕 이렇게 된 거 회복도 잘하고, 건강하게 나아 다시 돌아올 수 있게 힘쓰는 수 밖에!