'깨진 창문'을 고치지 않은 채로 내버려 두지 말라. 나쁜 설계, 잘못된 결정, 혹은 형편없는 코드 등이 모두 깨진 창문이다. 발견하자마자 바로 고쳐라. 적절히 고칠 시간이 없다면 일단 판자로 덮는 것만이라도 하라. 불쾌한 코드를 주석 처리 하고나, '아직 구현되지 않았음'이러고 메세지를 표시하고나, 가짜 데이터를 대치해 놓거나 하라. 더 이상의 손상을 예방하기 위해 어떤 조치든 취하교 여러분이 상황을 잘 관리하교 있음을 보여줘라
깨진 창문이론은 학부생 시절 사회심리학 시간에 알게된 이론이다. 그냥 알고만 있고 활용하지 않은 나를 돌아보게 된다. 그리고 이 이론은 결국 우리 삶 어떤 곳에든 적용될 수 있는 논리라는 걸 알게 됐다. 애초에 깨진 창문을 만들지 말자. 생기더라도 깨진 창문이 있다면 더이상 손상되지 않도록 표시해야 한다. 그래야 더는 망가지지 않는다.
그건 바로 공식 요구사항정의서와 별도로 개인용 요구사항 정의서를 정의하는 것이 편할 수 있다는 점입니다.(어쩌면 더 효율적일 수 있습니다.)
일반적으로 프로젝트는 모듈별로 담당 기획자가 나뉩니다. 그리고 요구사항정의서 작성은 모듈별 담당 기획자가 완성한 후 취합하는 형식으로 완성됩니다.
이 부분에서 공식 버전과 별도로 개인용 요구사항 정의서 문서의 필요성을 경험했습니다.
공식버전의 경우 요구사항의 중복없이 완성됩니다. 그래서 취합하는 과정에서 유관하다 판단해 제 모듈에서 작성되었더라도 타 모듈과 내용이 중복될 경우 둘 중 하나의 모듈에선 빠지게 됩니다. 이 사실을 프로젝트 기간 동안 계속 염두하고 있으면 좋지만..시간은 언제나 부족하고..그럼 요구사항 정의서에서도 제 모듈에 정의된 요구사항 정의서만 보는 상황이 발생합니다. 물론 기획자라면 자신의 모듈것만 볼 게 아니라 타 모듈이라도 관련된 내용이라면 계속 확인하는 게 당연하지만 놓치는 상황이 분명 발생할 수 있습니다. 따라서 저는 이번 프로젝트를 통해 개인용과 공식 버전 요구사항 정의서의 필요성을 느꼈는데요.
다만 이렇게 문서를 분리하다보면 요구사항 정의서가 수정될 경우 문서를 2개 업데이트해야하는 상황이 발생하기에 이 경우에도 역시 업데이트가 되었음에도 놓치는 요구사항이 생길 수 있습니다. 그럼 어떻게 해야하나?
여기서 "개인용"이라는 부분을 놓치면 안되는데요. 즉, 공식 요구사항의 양식을 따를 필요가 없다는 점입니다. 모든 컬럼을 따를 필요없이 개인용 요구사항정의서에는 요구사항ID만 기록해두는 것입니다. 이러면 내용을 관리할 필요도 없기에 요구사항 내용 혹은 협의된 내용이 수정되어도 이를 따로 개인용 문서에 반영해야할 일이 생길리 없겠죠. IA를 관리하듯 요구사항 ID만 관리하면 되는 것입니다. 그럼 타 모듈에 정의된 요구사항이라도 놓칠 염려를 덜 수 있겠죠?
이 글은 제 개인적인 경험을 바탕으로 작성되었습니다. 댓글을 통해 부족한 부분은 채우고, 다른 부분은 맞춰갈 수 있길 희망합니다.
해당 문서는 결국 이번 프로젝트에서 뭘 할 것이냐를 공식적으로 약속한 내용을 담고 있다. 따라서 프로젝트 진행에 있어서 범위를 정의하는데 근간이 되는 문서이기도 하다.
요구사항 정의서는 사용자 인터뷰 등을 통해 도출된 요구사항을 분석하여 정리된 문서이다. 여기서 "분석"이라는 점이 중요한데, 수행사 관점에서는 결국 해당 문서에서 이행하기로 약속한 기능을 "구현"해야하는 의무를 갖고 있다. 따라서 모든 요구사항을 기능 단위로 분리하고, 구현 관점에서 제한된 인력과 기간 내에 수용 가능한 요구사항인지를 분석해야 한다.
*기획자 입장에선 현업의 요구사항을 상당 부분 수용해주고 싶다. 그러나 프로젝트 입장에선 기한 내 불가능한 요구사항을 수용할 경우, 수행사 프로젝트팀의 고생을 떠나서 기한 내 아예 오픈을 못해버리는 불상사가 발생할 수도 있다. 그리고 기한 초과는 곧 예산 초과로 이어진다. 이러면 최악의 경우 법적 다툼으로까지 이어질 수 있다..
기능 단위의 분석이라 하면 요구사항 하나에 2가지 이상의 기능을 담는 걸 지양해야 한다는 것을 의미한다. 이는 요구사항에 따라 수용할 수 있을 수도, 없을 수도 있기 때문이다. 즉, 요구사항A에 기능A와 기능B 개발을 포함할 때, 기능A는 수용 가능한데 기능B는 그렇지 못할 수 있다. 물론 이 경우, 요구사항 정의 단계에선 부분 수용이라하고 고객사와 협의를 통해 요구사항을 수용 가능한 요구사항으로 수정할 수 있는 여지가 있다. 그러나 요구사항 다 확정하고 구현 단계에서 수행사가 막상 개발하려니 기능A는 되는데 기능B는 안된다고 해버릴 순 없는 노릇이다. 따라서 기능 단위의 요구사항 분리가 개인적으로 중요하다고 생각한다.
*이는 개발 관점에서 기능단위이다. 요구사항을 가령 체크박스 옵션 단위나 지나친 세분화하는 것 또한 지양해야한다. 요구사항이 너무 많아질 경우 관리가 어려워지기 때문이다.
요구사항 정의서는 또한 분석된 내용을 토대로 작성되는데, 여기서 중요한 점은 단순히 프로젝트 범위만 정의하면 안된다는 점이다. 요구사항은 수행사가 검토 후 고객과 협의를 결정되는데, 여기서 수용하기로 했다면 구체적으로 어떤 기능을 수용했는지, 그리고 미수용으로 결정되었다면 무엇 때문에 어떤 걸 미수용하기로 했는지 구체적으로 정의되어 있어야 한다.
이러한 사유들을 정의서에 포함해야 하는 이유는 아무리 워터폴 방법론을 채택하더라도 설계 또는 구현 단계에서도 여전히 요구사항은 추가되기 때문이다. 물론 모든 요구사항을 반영할 수 있다면 좋겠지만, 프로젝트는 제한된 자원 안에서 진행되기에 끊임없이 추가되는 요구사항은 프로젝트의 실패를 야기할 가능성이 높다.
따라서 추가되는 요구사항에 대해 가능한 범위를 한정지어야 하는데, 이때 요구사항 정의서에 정의된 사유를 통해 미수용했던 요구사항, 즉 이번 프로젝트에서 진행불가한 요구사항을 받아들이는 사고의 발생 가능성을 줄일 수 있다.
+ 요구사항 정의서를 정리하는 순서는 아래와 같다
사용자 인터뷰 등을 통한 요구사항 조사
기능 단위 요구사항 정의
수행사 검토를 통한 요구사항정의서 정리
고객사-수행사 협의를 통한 요구사항 확정
수행사 검토를 통한 수용여부 확정 - 수행사의 프로젝트팀 전체가 함께 검토함
수행사-고객사 협의를 통한 최종 요구사항 확정
이 글은 제 개인적인 경험을 바탕으로 작성되었습니다. 댓글을 통해 부족한 부분은 채우고, 다른 부분은 맞춰갈 수 있길 희망합니다.
Promise로 비동기 처리가 가능합니다. 비동기 처리라 하면, 따로따로 처리할 수 있다는 걸 의미합니다. JavaScript는 원래 위에서 아래로, 순서대로, 차례차례 처리됩니다(동기식 처리).
Promise는 Producer와 Consumer로 나뉩니다.
Producer
Promise 생성
const promise = new Promise(function(resolve, reject){});
Promise는 executor라는 함수를 가집니다. 얘는 JavaScript에서 자체 제공하는 콜백 함수입니다.
executor는 resolve와 reject라는 인자를 받습니다(꼭 resolve와 reject라고 쓰진 않아도 됩니다).
성공했을 때 resolve, 에러 떴을 때 reject가 실행된다고 생각하면 됩니다.
Promise의 특성 : state, value
Promise는 처음에는 pending state와 undefined value를 가집니다.
이후 executor에 의해 promise는 둘 중 하나의 state와 value를 가집니다.
executor가 실행되서 성공했을 때는 fulfilled state와 resolve에서 받은 value를 가집니다.
executor가 실행되서 에러가 떴을 때는 rejected state와 error를 value로 가집니다.
fulfiiled 또는 rejected된 promise를 settled promise라고 합니다. 한번 fulfiiled 또는 rejected가 된 promise는 더이상 state를 변경시키지 않습니다. 그래서 executor에 resolve 또는 reject와 관련된 내용이 2개 이상 있을 경우, 가장 먼저 실행된 애만 받고 나머지는 무시합니다.
Consumer
Promise가 생성되었으니 생성된 애를 써야합니다. 이때 사용되는 method로 .then, .catch, .finally가 있습니다.
.then
.then은 성공과 에러 값을 받습니다. Promise.then(성공, 에러)로 구성되는데 Promise.then(성공) 처럼 성공만 쓸 수도, Promise.then(,에러) 처럼 실패만 쓸 수도 있습니다.
에러만 처리하고 싶을 때 Promise.catch()로 쓰거나, Promise.then(성공).catch(에러)로 구분지어 쓸 수 있습니다.
.finally
.finally는 인자를 받지 않고 프로미스가 실행되면 항상 실행됩니다. 이점은 .then(성공, 에러)와 유사해 보이지만, 다른 점은 finally에는 state가 없어도 된다는 점입니다. 그래서 받고 있는 인자도 없습니다. 그리고 또 중요한 점은 인자를 받지 않고 상태를 통과시키기에 .finally().then()이나 .finally().catch() 와 같이 작성할 수 있습니다.
넷플릭스 1분기 가입자 실적 - 이전 월가 애널리스트 예측치 : 250만~270만명 증가 - 실제 실적 : 20만명 감소(11년만에 처음) - 원인 : 러시아 스트리밍 서비스 중단(70만명 감소) , OTT 서비스 시장 과열화 - 여파 : 시간외거래에서 주가 26% 폭락, 넷플릭스가 OTT대장주격이기에 OTT산업 전체 주가 하락(테크주도 하락..) - 전망 : 2분기 200만명 감소 예상 - 대안 : IP를 활용한 게임 산업 진출, 기존 구독 모델 점검(구독료인하와 함께 광고노출, 비밀번호 공유 제한)
금융당국 "음원저작권 조각도 증권이다" -> 뮤직카우, 증권 관련 규제를 지키기위한 사업구조 개편 필요 -> 6개월 유예기간을 받아 당장 영업정지는 면함
테슬라, 시장예상치를 뛰어넘는 호실적 발표
출처 : NEWNEEK, DAILY_BITE, 디그, UPPITY, 순살
추가 정리
OTT 관련 추가 이슈 - 망이용대가법 국회 논의 시작 *망이용대가 지불에 대한 SK브로드밴드(통신사)와 넷플릭스의 1심재판에서 재판부는 SK브로드밴드의 손을 들어줬다. https://n.news.naver.com/article/031/0000667471
- 왓챠 티웨이항공과 제휴해 항공권 예약손님 대상 10일 프리미엄 이용권 제공. 왓챠홀 개관
- 티빙 현대자동차와 제휴하여 현대자동차 인포테인먼트 시스템에서 티빙 다운로드 없이 서비스 이용할 수 있도록 서비스 플랫폼 구축중 https://n.news.naver.com/article/018/0005195935
뮤직카우 증권시장거래 규제대상에 포함에 따른 관련 이슈 - 조각투자 플랫폼도 연쇄 영향 예상(뱅카우, 피캋프로젝트 등) - 금융위, 조각 투자 등 신종 증권 사업 관련 가이드라인 발표 예정 https://n.news.naver.com/article/011/0004044613
- 뮤직카우 사례(비전형 증권성 개념 확장 첫 사례)로 가상자산, NFT도 금융감독 대상으로 포함될 가능성이 생김 https://n.news.naver.com/article/052/0001729120