김민태의 React와 Redux로 구현하는 아키텍처와 리스크관리(2)
패스트캠퍼스 The Red
2. 안정적인 프로덕트를 위한 아키텍처 설계와 리스크 관리
5) 유지, 개선 관점에서의 리스크 관리
개발자가 작성하는 코드는 결국
레거시가 된다
코드의 생명주기
시간이 지나면 개발자가 작성한 코드의 컨텍스트가 희미해진다
레거시 코드 어떻게 바라보아야 하는가1. Respect 존중하자
- 코드가 나쁘다, 구조적 한계가 있다
- 역설적으로 그 코드 덕분에 현재 서비스가 존속되는 것일수도 있다. (서비스의 생명력 지속)
- 코드의 의인화 : 나와 코드를 분리 (감정이입 x, 자기자신 투영 x)
- 예전에는 최신이었으나 현재는 낙후된 코드일수도 있지만 전혀 없다 (존중)
- 개선하기 어려운 레거시 코드를 개선하기 위한 전략
- Visualization :
문제를 가시화 한다(추상적이지 않은 구체적인 문제 제기)- 코드 분석, 전체 아키텍처 포함
- 대부분의 개발자들이 내놓는 솔루션 : 재개발만이 유일한 방법
- 개발자가 이 제품은 답이 없어라고 할 때 회사 내 이해관계자들의 다양한 반응
- 명확하지 않은 분석이라면
시각화되지 않은 문제는 불만일 뿐이다.
2. 레거시 코드 분석 실패의 이유
- 기술 난이도가 너무 높은 경우 : 역량 한계 후 함께 해결책 찾기
- 잘못된 구조로 규모가 커진 코드 : scale-up이 될 것을 감안하지 않고 만든 경우 (아키텍처 개선하지 못한)
- 분석 후 문서화 : 구체적으로 기술하지 않으면 회사 내 이해관계자들은 이해하지 못할 수 있음
- 재개발하기 위한 비용과 리스크 산출
- 기존 코드와 병행 및 병행하지 못하는 것, 쪼개 기능, 현재 상태에서 새로운 기능을 추가하는 등의 개발자적인 측면에서 분석
6) 안정적인 프로덕트를 위한 코드 구조와 관리
Code Life Cycle코드 생명주기
코드의 볼륨이 커질 뿐 실제 모든 요소는 코드 생명주기를 갖고 있다
생명 주기는 왜 있어야 할까?
- 프로그래밍, 코드로 이루어진 세계에 왜 생명주기라는 인간의 컨셉이 들어가 있을까?
- 모든 것이
유한하기 때문 : 자원의 유한함
자원은 왜 유한한가
- 컴퓨터 시스템, 컴퓨팅 파워
- 사이즈는 커질 뿐 무한하지 않다
유한한 자원들을 효과적으로 쓰는 방법을 잘 이해하는 것이 중요하다- 이러한 변화에 잘 어우러져서 서비스, 시스템을 잘 구성하는 것이 좋은 아키텍처
- 프론트엔드 개발이라고 한다면?
함수모듈컴포넌트
- 프론트엔드 개발은 1년 이상 쓰이는 코드가 없음 : 많은 변화를 겪게된다
- 새로운 함수나 모듈 등으로 교체하려면?
- 각각의 생명주기가 다른 요소를 어떻게 다룰 것인가
- 점진적 개선 -
종속성 관리- 각각의 유형이 독립적으로 분리되도록
- 소프트웨어 아키텍처 패턴, 디자인패턴 등으로 다르게 불리우나 이러한 모든 개념들은
사실상 모두 생명주기가 다른 것들을 어떻게 유기적인 패턴으로 결합시킬 것인가의 방법론제안임
프론트엔드 앱을 전부 분해본다면..?
어떻게 구체적으로 개선할 수 있을까?1) 유형별
- HTML : 기본구조
- CSS : 스타일
- Code - Logic - Rule : 비즈니스 로직과 외부 configuration, 같은 코드가 다르게 동작하는 방식
- Domain - Data - State : 비즈니스에서 다루는 영역
- Effect : 비동기 작업들, 애니메이션, 이벤트시스템, UI 인터랙션
=> 유형이 다른 요소들 구분
- HTML과 JS가 섞여있는 구조
- Code와 Data가 묶여있는 구조 : Data는 자주 바뀌는 것 간과, 상대적으로 변경비용이 훨씬 높음, 가능하면 Code는 안 바뀌는 것이 좋다, Code와 Data 분리
- 부수효과가 발생할 수 있는 환경 : 네트워크, 비동기작업
- 유형들이 결합된 것을 분리시키는 아키텍처 고안
2) 변형주기별
- Design - Visual - Struct : 비주얼 구조, 화면 전환 패턴
- Config : 설정파일, 앱이 어딘가에 접근하기 위한 정보들 ex) 서버 접속 정보 (만일 변경된다면 클라이언트에서 받아오는 정보가 바뀌게 되는)
- Assets - Information : 정적 자원들(이미지, 동영상 등), 서비스 약관들
=> 코드를 통해서 변경처리 시 드는 운영에서 처리해줘야 하는 문제들
ex) 서비스가 잘 되면 약관은 계속 변경된다 - 분리되어 있다면 배포를 하지 않고도 운영비용 절감 가능
3) 오너십별
- 회사가 제품 변경과 관련하여
법적권리, 구조적, 기술적 권리를 갖고 있는가?- Library/Framework : 기술적 오너십 (분리하기 어려움)
- 실제로 할 수 있어도 이런 문제로 할 수 없는 문제
Dependency가 있을 수 밖에 없는 경우- 외부 서비스 : API, 인증 key 별도
=> 대부분은 커뮤니티나 시장에서 검증된 해결방법을 도입
=> 문제 발생 시 리스크 관리 측면 고려 (선택 신중)
=> 변경이 있어도 위험도, 영향도가 낮은 방법은 어떤 것이 있을까 고민들
=> 문제가 되더라도 빠른 alerting을 받을 수 있는 방법 고안 ex) 카카오API 인증key
4) 위치별
- 내부 서비스/외부 서비스 측면 분리
- 서버와 커뮤니케이션에 관련 : Public이냐 Private이냐
내부 조직에서 개발할 수 없다면외주 개발
외주 핸들링 시 외주 개발자(사람)의 문제라기보다는
구조적인 문제가 발생한다.문제점 :
외주 개발자는 오너십을 가질 수 없다.(책임, 권한 문제)
ㄴ 대부분 요구사항을 받고 분석, 납품하고 끝남 (계약 기간, 업무 범위적)
ㄴ 그러나현대 서비스는 납품 이후가 시작이다
ㄴ 납품 후 릴리즈가 되면 끝나는가? 절대 아니다
ㄴ 릴리즈가 된 이후부터 계속 끊임없이 발전되고 운영되어 나가는 것이 현대 SW 방식
ㄴ 제품 라이프사이클과 외주 개발 시스템을 함께 가져가기 어려운 문제
- 외주개발을 한다면 코드 안에 내부에서 정한 가이드라인이 포함될 수 있어야 한다
- 가이드라인을 정한 후 내부에서도 그렇게 운영한다는 것이 생각보다 쉽지 않음
- 가이드라인과의 검사(싱크 맞추기)
- 프론트엔드 개발같이 생명주기가 짧은 경우라면 고려할 문제가 있음 (구조적인 문제로 인한)
- 내부에서 진행하기 어렵다면 PaaS 서비스 채택하는 것도 하나의 방법 (모듈 형태로 제공되는 서비스)
💬 어쩌다보니 레거시라고 할 수 있는 회사들에 다녀본 나로서는...(물론 그 회사들도 현대화를 위한 노력을 진행중이지만) 레거시, 기술부채가 꼭 나쁘다고만은 할 수 없다고 생각한다. 강의에서처럼 그 레거시들 때문에 오히려 사업적인 측면에서는 안정적으로 운영되거나 확장된 것을 간접적으로 관찰해봤기 때문에.. 다만 현대 서비스에서 레거시 누적률이 높으면 일단 프론트엔드 개발 측면에서만 보면 새로운 언어, 새로운 프레임워크가 너무 많이 나오고 있어서 그에 맞는 새로운 인력을 수혈하기 어렵다는 부분이 제일 큰 거 같다. 그런데 또 역으로 생각하면 아직 검증되지 않은(여기서 말하는 내가 생각하는 검증이란 보수적인 결정을 취할 수 밖에 회사들에서 도입) 것을 실험적으로 도입한다고 하면 아마도 다소 난항이 있을 것 같다. 그래서 사실 React를 조금 파보긴 했지만, 우리가 이름만 들으면 아는 회사들(스타트업, 유니콘 말고 흔히 떠올릴 수 있는 전통 대기업, 금융권)의 메인에서 진행하거나 성공한 케이스나 솔루션이 나와야 어느 정도 보편적으로 전파되지 않나 이런 생각도.. (물론 퍼블리싱하다가 React 공부해보면 노가다는 줄어든다는 것을 느낀다. 대부분의 퍼블리셔에서 프론트엔드 개발자로 전향하는 사람들이 느끼는 공통점.. 다만 솔직히 러닝 커브가 높긴 하다, 알아야 하는 배경지식도 jQuery 배울 때랑은 달랐다..) 그런데 이러한 것의 도입이 하나만 바꾸거나 추가한다고 딱 될 일이 아니라는 것이 문제라는 거다..
💬 사실 그런 케이스가 있을까 하고 찾아보고 있는데 거의 올해부터 프로젝트가 진행중인 경우가 OKKY 같은 곳에 있기한 거 같은데 아직 많진 않은거 같다. 올해가 지나야 알 수 있을까? (결국 한국에서 돈 벌려면 자바스프링 환경인가..)
📖 참고 자료
💬 김민태 개발자님 강연 때문에도 그렇고 유튜브 알고리즘을 통해 보게 된 영상인데 흥미로운 관점도 하나 있었다.
- 때로는 문제를 해결하는 가장 좋은 방법이 정책을 바꾸고 프로그래밍을 안하는 것일수도 있다
- 우리가 풀고자 하는 문제가 무엇인지를 정확히 이해하는 것
여기에 노력의 80%가 들어가야 되지 않을까?
이게 제대로 되면 오히려 문제 해결 방법은 따라오게 된다- 당신이 만들어낸 코드로 만들어낸 비즈니스 가치가 무엇인가?
💬 외주에 대한 내용이 나오니까 또 내가 경험해서 느낀 것은.. 음, NICE에서 파견으로 일하면서 나는 IT감독/감리라는 말을 처음 들어봤다. 그 회사 특성이 다소 특수한 부분도 있기 때문도 있지만, 그런 부분을 굉장히 중요시 하는 것 같았다. 그 이후 나중에 찾아본 것...
📖 참고 자료
