REACT.JS를 참고한 기획
이론은 이론일 뿐 따라하지 말자
친구와 OOP를 공부하고 있는중에 샘플로 하고 있는 react.js기반 프레임워크에서 기획에 적용할 수 있는 부분을 생각해 보고 실제로 간단한 예시로 설명해서 언젠가 써먹을 수 있도록 하기 위한 기록이다.
주의 : 이 방식은 당장 실무에서 사용하지 않는것이라고 미리 이야기 해둔다. 당연히 시간도 많이 걸리고 개발자들의 성향을 고려해서 작업해야 하기 때문에 범용적인 기획 방법이 아니다. 이 글을 읽는 사람에게는 이렇게 하려는 사람도 있구나.. 정도만 생각하길 바란다. 앞으로도 마찬가지이지만 이론이나 방법론에 대한 정설을 이 블로그에서 찾으려면 포기했으면 좋겠다.
컴포넌트 개념을 기획에?
기능들 각 하나를 컴포넌트라 하고 부모와 자식을 정의하며 자식들간 서로 존재자체도 모를 수 있지만 부모는 자식에게 영향을 준다.. 라는 말이긴 한데 정확하게는 아니지만 대략 이렇게 차용할 수 도있다. 중요한것은 컴포넌트 기반으로 페이지들을 정의하는것을 연습하고자 한다.
장점
수정이나 추가하는 작업에서 의사소통이 편리할 수도 있다. 작업자끼리 같은말을 다른언어로 알고 있는 부분을 최소화 할 수 있다. 기획에서는 일부 컴포넌트들을 만들어 놓고 저장하면 기획과정 중 동일한 항목은 복사해서 붙여 쓸 수 있다. (반복적인 공통요소는 그냥 복사하는 얍삽한 기획자가 되는것을 권장한다. 일하다보면 시간이 부족하여 야근하는 경우를 줄이는 방법으로...)
또한 마인드맵과 같은 기획이 최종적으로는 만들어 진다. 페이지별 기획과 함께 컴포넌트별 분기를 보기 편하게 작성 할 수 있다.
단점
처음만들 때 오랜 시간이 걸리며 일반화 하는 기준을 만들기가 쉽지 않다. 가장 간단한 기능부터 만들려고 하면 우리의 고객은 그 기능조차 분할해 버리는 사태를 만들기도 하기 때문이다. (예를들면 기본 alert창을 특별한 디자인 해서 별도의 기능으로 만들어 달라고 한다면.. 그것마저 분할할 생각을 미처 못했기 때문에 만들지 않을것이라는 이야기이다.)
일단 시작부터 하자
간략하게 설명하면 이런그림이 된다.
간단한 예시그림위의 그림은 간단하게 첫 단계로 나누어 놓은 그림이다. 이런 방식으로 계속 가지를 만들어 가면서 그려내는 방식이다. ios app 개발자들에게는 익숙한 화면이 될 지도 모른다. 실제로 ios 의 스토리보드를 사용하면 이런 방식으로 개발 할 수 있기 때문이다. 웹에서는 react.js에서 이렇게 나누어서 개발하는 방식을 사용 할 수 있다.
일하다 급할때는 도움이 된다.
개발 수정은 용이하다 . 개발중에 기획이 변경되는 경우는 정말 셀 수 없이 많다. 화면설계업데이트는 나중에 하고 개발을 먼저 진행해야 하는 부득이한 경우 좀더 빠르게 진행 할 수 있다. 실제로 일해보면 개발할 때마다 기획이 틀어지는 경우를 많이 보게 된다. 고객의 변심이 있을 수도 있고, 심하면 상세 로직이나 규칙들을 정하지도 않은 채 기획에 들어가서 개발할 때 변경되기도 한다. 백오피스 변경도 어려운판에 ui 변경까지 하면 더더욱 힘든 상황에 몰리게 된다. 이런걸 모르는 고객들은 그거 하나 바꾸는게 뭐가 힘드냐 하는 말로 힘을 빼는상황을 너무나 많이 봐왔다. 위의 방법은 그것을 아예 막을수는 없지만 최소한의 시간을 들일 수 있도록 대비라도 할 수 있을 것 같다.
혹시라도 이렇게 하고 싶으면
개발자 성향을 잘 알아보고 알아보고 해야 할 것 같다. 개발자마다 페이지 별로 개발하는것이 더 편한 방법이라고 한다면 위의 방법을 굳이 사용할 필요가 없다. 이렇게 기획하는 의도는 커뮤니케이션과 유지보수에 얼마나 잘 대응 할 수 있는가 인데.... 개발자마다 방법을 받아들이는 방식이 다르기 때문이다. 잘 물어보고 상황에 따라 적용해야 할것이다.
이번 글을 작성하면서 생각난 것
고객인터뷰는 우리가 사용하는 방법론에도 당연하다는 듯이 써 있는데.. 내부에 일하는 개발자 인터뷰나 동료 인터뷰는 어느 방법론에도 써 있는 책을 본적이 없다. 가만히 생각해보니까... 개발자들이 나는 어떻게 개발하며 어떤 방식으로 대화하길 원한다는 이야기를 귀기울여 본적이 없는것 같다. 고객만 맞춰야 한다고 생각하다가 실제 작업자들에 대한 성향 파악은 그냥 무시하는것 아닌가 반성해 본다. 왜 이러한 부분을 고민하는지 물어본다면 어디까지나 유지보수가 잘 될 것인가. 라는 부분이 경제적 관점과 관련이 있어서 인것 같다. 유지보수 비용은 곧 돈이고 구축 이후 운영에 대한 문제 대응에서 많은 생각이 필요할 것 같다.
