윕 프로젝트만 모아서 시작편 브런치 북을 만들었다. 2권은 개발편으로 프로젝트 개발에 집중해서 작성할 예정이다. https://brunch.co.kr/brunchbook/webproject1[브런치북] 웹 프로젝트 1 - 시작편 -웹 사이트나 모바일 앱은 어떻게 만들어지는 것일까? 이용이나 사용은 많이 하지만, 어떻게 제작되는 것인지는 막연하게 알고 있는 듯 하다. 이런 제작 과정을 단계별로 세세하게 풀었다. 특히 brunch.co.kr

소통 방식은 여러 가지가 있다. 직접 대화를 하거나 전화 통화, 영상 통화 등 다양한 방식으로 소통한다. 이런 직접적인 소통방식은 빠르기는 하지만, 쉽게 잊어버리고, 무수히 많은 대화가 오가면 무슨 말을 했는지도 모르고, 그냥 수다로 끝날 수도 있다. 소통을 하더라도 직접 연결해서 하는 것보다 좀 더 생각을 정리하고, 자료로 만들어야 하는 것들은 팩스나 메일, 우편을 통해서 간접적으로 소통한다. 빠르지는 않지만, 생각을 정리할 수 있고, 목적이 확실한 편이다. 팩스나 메일로 수다를 떠는 것은 본 적이 없다. 사람과의 소통에 피로감을 있었는지 기계와 소통하는 경우도 부쩍 많아졌다. 또한 독신이거나 혼자 사는 경우도 많아져 기계와 소통하는 것에 재미를 느끼는 사람도 많아진 듯하다. 기계와 소통한다는 것이 조..

스파이 영화를 생각해보자. 스파이 영화라면 단연코 007 시리즈다. 미션 임파서블이 나오면서부터 007 시리즈는 한층 꺾이고, 킹스맨이 나오면서 코미디를 가미한 스파이 영화가 주를 이루었다. 영화 이야기를 하려고 한 게 아니다. 스파이 영화의 주무대인 악당이 있는 건물에 잠입해서 임무를 완수하는 시나리오를 생각해보자. 오션스 일레븐처럼 범죄 영화를 생각해도 좋다. 건물에 잠입하기 위해서는 무작정 찾아가서 임무를 완수하는 영화는 없다. 그렇게 해서 임수를 완수한다면 영화를 만들 이유도 없다. 일단 잠입하기 위해서는 시뮬레이션을 해봐야 한다. CCTV가 어디에 있는지 어디로 잠입 가능한지, 경비원들이 몇 명이 있는지 교대 시간이 있는지 등등 모든 상황을 고려해서 계획을 세우고 시뮬레이션으로 실수 없이 성공해..

음식점을 하나 만든다고 생각해보자. 어떤 음식점인지는 상관 없다. 떼돈을 벌 수 있다는 희망찬 생각으로 매장을 만들어보자. 작게 시작한 매장에는 굳이 홀 인원이 필요 없을 것 같다. 주방과 홀을 같이 병행해서 해도 큰 문제는 없다. 홍보도 전단지를 직접 나누어 줘도 큰 무리는 없다. 고객이 많아 지면 홀 인원을 따로 두어야 원활하게 돌아간다. 주문이 많은데 음식을 하고 홀서빙까지 병행하면 시간도 늦어지고, 주문도 꼬이게 된다. 많이 팔리는 음식은 미리 만들어두는 것도 좋은 방법이다. 만두 같은 경우, 주문이 들어오고 나서 반죽을 하고 피를 만들고 속을 만들기 시작하면 너무 많은 시간이 소요된다. 미리 만들어 놓고 주문시에 찌거나, 데워주면 된다. 홍보 또한 전단지를 직접 나누어 주기는 매장을 비울 수 없..

프로젝트 관리는 대부분 오피스 제품을 많이 사용한다. 요구사항 정의와 일정 관리인 WBS는 엑셀파일로 관리하고, 기획 스토리보드는 파워포인트나 PDF로 관리되며, 테스트 시나리오는 엑셀파일, 정책서나 문서는 워드문서로 관리한다. 오피스 제품군만 있으면 대부분의 관리가 가능하다. 하지만, 개발소스는 오피스 제품으로 관리하기 힘들다. 혼자서 개발하면 소스는 혼자서 가지고 있어서 상관없지만, 여러명이서 같은 소스로 개발하기 위해서는 소스 관리가 필요하다. 각자의 컴퓨터에서 개발한 후에 통합하는 과정을 거치면 내 소스가 사라질 수도 있고, 상대방 소스가 사라질 수도 있다. 그리고 소스에서 어디가 어떻게 수정이나 추가됐는지도 모호해지고, 누구의 소스인지도 모른다. 이럴 경우 프로그램 자체가 제대로 돌아가길 바라는..

개발된 사이트의 품질을 높이기 위해서는 테스트가 중요하다. 테스트를 통해 많은 오류와 버그, 불필요성, 불편성 등을 찾아내고 수정에 수정을 하다보면 그만큼의 품질은 좋아진다. 다만, 테스트 중에 새로운 기능을 추가하는 것은 사이트를 망치는 지름길이다. 개발된 기능도 테스트가 진행중인데, 새로운 기능을 추가하게되면 다시 만들고, 똑같은 테스트를 해야하기 때문에 시간이 배 이상으로 늘어난다. 새로운 기능에 대해서만 테스트하는 걸로 생각해서는 안된다. 새로운 기능이 추가되면, 기존에 복잡하게 얽혀 있는 코드들에게도 영향을 미치기 때문이다. 테스트 시나리오에 있는 내용대로 반복해서 테스트하기에는 시간이 오래 걸린다. 테스트 시나리오는 전 화면에 대한 테스트 내용이 있기 때문에 문서의 내용도 길고, 테스트할 요소..