devpeople

오늘은 쿠키와 세션에 대해 알아보도록 하겠습니다.

앞서 쿠키와 세션을 이해하기 위해선 HTTP 프로토콜의 특성을 이해해야 합니다. HTTP(HyperText Transfer Protocol)는 ‘Connectionless, Stateless’한 특성을 가지는데, 이러한 특성을 보완하기 위해 쿠키와 세션을 사용하기 때문입니다. 먼저 HTTP란 HTML 문서 파일과 같은 리소스를 가져올 수 있도록 해주는 프로토콜입니다. Web에서 이루어지는 클라이언트와 서버 간의 모든 데이터 요청과 응답은 HTTP를 통해 이루어집니다.

이러한 HTTP 특성을 바로 쿠키와 세션으로 보완할 수 있습니다. 만약 쿠키와 세션을 사용하지 않으면 HTTP의 특성으로 인해 사용자가 웹사이트에 로그인한 후에도 매 페이지 이동 시 마다 계속 다시 로그인을 해야 하는 매우 불편한 상황이 발생될 것입니다. 바로 HTTP는 ‘Connectionless, Stateless’한 특성을 지녔으니까요!

쿠키란 클라이언트(브라우저) 로컬에 저장되는 키와 값이 들어있는 작은 데이터 파일입니다. 쿠키 파일에 대한 유효 기간을 사용자가 임의대로 명시할 수 있고, 브라우저가 종료되어도 유지된다는 특징이 있습니다. 또한 사용자가 따로 요청하지 않아도 브라우저는 서버에 Request(요청)할 때에 Request Header에 쿠키를 넣어서 자동으로 전송합니다. 브라우저에 하나의 쿠키는 최대 4KB까지 저장 가능합니다. 쿠키의 예시로는 인터넷 쇼핑몰의 장바구니 기능 또는 자동로그인 체크 기능 등이 있습니다.

세션은 쿠키를 기반으로 하며 정보 파일을 서버 측에서 관리합니다. 서버에서는 클라이언트를 구분하기 위해 세션 ID를 발급하여 브라우저가 서버에 접속 후 브라우저를 종료할 때까지 정보 파일을 유지합니다. 물론 세션도 쿠키와 같이 사용자가 임의대로 유효기간을 명시할 수 있습니다. 정보를 브라우저가 아닌 서버에서 가지고 있기 때문에 쿠키보다 보안은 좋지만, 동시 접속 사용자가 많아질수록 서버의 메모리를 많이 사용함으로서 성능 저하의 요인이 될 수 있습니다. 세션의 예시로는 로그인과 같이 보안상 중요한 작업을 수행할 할 때 사용됩니다.

지난 포스팅에서 살펴보았듯이 이젠 웹 프론트엔드 생태계에서 CSR(Client Side Rendering)은 흔히 사용되는 프론트엔드 개발 방식이 되었습니다. SPA(Single Page Application) 구조를 통해 페이지를 렌더링하여 사용자에게 빠른 인터렉션을 제공해주는 것이죠. 그럼 SPA란 정확히 무엇일까요? 오늘은 SPA에 대해 자세히 알아보도록 하겠습니다

과거 전통적인 웹 사이트는 지금과는 달리 하나의 문서(예: HTML 파일)에 전달되는 정보의 양이 적었습니다. 그래서 어떠한 페이지에서 버튼을 클릭했을 때 해당 페이지의 일부 영역만 변경되어도 서버에서 완전히 새로운 페이지를 재렌더링하여 전송해주는 방식이었죠. 하지만 웹 시장이 발전됨에 따라 한 페이지에 해당하는 정보의 양을 매우 커졌고, 이에 서버에서 매번 새로운 페이지를 전송해주는 것이 점점 버거워지게 되었습니다. 그래서 이러한 문제를 해결하기 위해 등장한 기술이 바로 Single Page Application(이하 SPA)입니다. 이름에서 유추할 수 있듯이 SPA란 ‘단일 페이지 어플리케이션’을 의미합니다. 즉, 어떠한 웹 사이트의 전체 페이지를 하나의 페이지에 담아 동적으로 화면을 변경해 표시하는 기술이죠. 브라우저는 최초에 한 번 서버에 요청하여 페이지 전체를 로드하고, 이후부터는 특정 변경 사항이 일어나는 부분만 Ajax와 같은 기술을 통해 데이터를 바인딩하는 방식으로 동작합니다. 이처럼 기존에 매번 서버에 요청하여 서버가 새로이 페이지를 렌더링하여 제공해주던 방식과 크게 다른 점이 SPA의 특징입니다. 이러한 동작 방식으로 사용자에게 빠른 인터렉션을 제공할 수 있습니다. 하지만 SPA도 문제점은 있습니다. 바로 자바스크립트로 DOM 조작이 빈번하게 일어나 브라우저의 성능을 저하한다는 문제입니다. 그래서 Virtual DOM이라는 개념이 생겨났습니다. SPA 프레임워크인 React, Angular, Vue는 대표적으로 Virtual DOM을 이용해 SPA를 구현하는 기술들입니다. 가상의 DOM 트리로 HTML 정보를 저장하고 있다가, 이 트리에 변경이 발생하면 모든 변화를 모아 단 한 번 브라우저를 호출해 화면을 갱신하는 방법을 사용합니다. 이러한 방법을 통해 브라우저와의 불필요한 상호작용을 줄이면서 사용자에게 빠른 인터렉션을 제공할 수 있게 됩니다. 마지막으로 SPA의 장단점을 다시 한번 정리하자면, 장점은 화면에 필요한 부분의 데이터만 받아서 렌더링 하므로 처리 과정이 효율적이며 속도가 빠릅니다. 그래서 사용자에게 보다 더 나은 사용성을 제공합니다. 반대로 단점은 처음 화면을 로딩할 때, 모든 화면의 정보를 모두 다운로드해야 하므로 로딩 속도가 다소 걸립니다. 또한 SEO에 불리하며, 자바스크립으로 인한 DOM 조작이 빈번하게 일어나 브라우저의 성능을 저하합니다. 따라서 내가 만들고자 하는 서비스가 사용자에게 빠른 인터렉션을 제공해야하는 서비스라면 React나 Vue와 같이 SPA 프레임워크로 개발하는 것이 좋고, 반대로 단순히 간단한 정보를 제공하는 서비스라면 복잡한 기술 사용 없이 기존의 웹 사이트 개발 방식대로 개발하는 것도 좋습니다.

일반 사용자가 보았을 땐 똑같은 모바일 앱이지만 실제 개발 방법에 따라 모바일 앱 종류는 여러가지로 나뉘어집니다. 오늘은 다양한 모바일 앱 종류 중 모바일 웹엡, 네이티브 앱 , 하이브리드 앱에 대해 알아보도록 하겠습니다.

안녕하세요.

devpeople에서 개발 리드를 맡고 있는 Yaro입니다.

devpeople은 MVP 전문 개발사로 대표님들의 아이디어를 실현하기 위해 꼭 필요한 기능만 추가하여 빠른 출시를 목표로 합니다.

추가로 개발 지식을 필요로 하는 대표님 또는 팀원을 위한 기업 교육도 진행하고 있습니다.

제가 스타트업에서 대표님들의 아이디어를 현실로 만들어 드리면서 겪었던 이야기를 한번 풀어 보려고 합니다.

개발에 들어가기 전 항상 대표님과 사전 미팅을 오래 하게 되는데, 그 이유는 대표님들과 이야기를 오랫동안 나누어 보아야 원하시는 바를 정확하게 개발에 녹여 낼 수 있기 때문입니다.

물론 대표님이 정말 바쁘시다는 것도 알고 있습니다. 하지만 경험상 대표님이 없고 창엄팀 멤버분들만 있을 경우 대표님이 생각하시던 그림과는 다른 결과물이 나오는 경우도 종종 있었습니다.

서비스명을 정하실 때 고려하실 포인트는 당연히 ‘서비스와 관련성 있으면서 발음하기 편한 쉬운 이름'이 제일 좋을 것입니다.

안녕하세요. 최근 데브피플이 예비, 초기 스타트업을 위한 MVP 패키지를 출시함에 따라 정말 많은 고객들이 MVP 개발을 의뢰해주고 계시는데요. 여러분들의 많은 관심과 성원 감사드립니다 그래서 오늘은 예비, 초기 창업자라면 누구나 들어보셨을 ‘MVP’란 무엇인지, 어떤 성공 사례가 있는지 알아보도록 하겠습니다.

MVP(Minimum Viable Product)란 ‘에릭 리스'에 의해 만들어진 용어로, 고객의 요구사항에 맞춰 최소한의 필수 기능을 구현한 제품을 말합니다. 초기 스타트업은 빠르게 서비스를 출시해 실제 유저들이 필요로 하는 서비스인지 검증받는 것이 매우 중요합니다. 아무리 좋은 아이디어라도 빠르게 변화하는 IT 트렌드 속에서 실제 결과는 예상과 다를 수 있으니까요.

그래서 처음부터 대규모 서비스를 만들기보단 꼭 필요한 핵심 기능을 구현하여 시행착오에 따른 시간과 비용을 최소화하는 것이 MVP 개발의 가장 큰 핵심입니다. MVP 개발은 경쟁사보다 빠른 시장 진입을 통해 실제 유저의 데이터를 분석할 수 있습니다. 더 이상 가설이 아닌 실제 데이터를 통해 인사이트를 얻을 수 있죠. 그리고 이를 통해 점차 서비스를 고도화시키며 제품을 완성해 나가기 때문에 가장 리스크가 적고 효율적인 개발 방식입니다. 또한 최소한의 기능만을 개발함으로써 개발 비용이 적어 구글 광고, 네이버 광고와 같은 마케팅 비용이나 여러 필요한 예산을 더 확보할 수 있습니다.

소유한 호텔은 하나도 없지만 전 세계에서 가장 큰 숙박 네트워크를 제공하는 에어비엔비의 첫 시작은 간단한 블로그에서 시작되었습니다. 지금과 같이 세련된 UX를 가진 서비스가 아닌 가장 기본 기능에만 충실하였습니다. 숙소 사진, 위치, 가격, 그리고 호스트 연락처 정도의 간략한 정보만 제공해주었죠. 이후 에어비엔비는 지속해서 유저의 피드백과 경험을 서비스 기능에 반영하며 업데이트하였습니다. 유저의 다양한 니즈에 따라 호스트와의 대화, 슈퍼 호스트 체계, 보안 결제 등 서비스를 개발해 나아가 프로덕트의 가치를 높였습니다. 초기 에어비엔비의 MVP 제품은 전혀 세련되지도 않고 다양한 기능을 제공하지 않았지만, 기본 기능에 충실하였고 고객의 피드백을 받으며 끊임없이 개선하여 220개 이상의 국가의 10만 도시의 7백만 개의 숙소를 가진 지금의 에어비엔비가 되었습니다.

중소기업이나 스타트업 대표님들이시라면 한 번쯤 위와 같은 고민을 해보셨으리라 생각합니다.

오늘은 이런 고민을 안고 계신 대표님들을 포함하여, 시스템 개발을 의뢰하는 분들께 도움이 될 수 있도록 상황별 올바른 기획서 제작 방향성에 대해 말씀 드리고자 합니다. 외주사로 일하면서 기획서의 중요성은 몇 번을 강조해도 지나치지 않는다는 생각이 드는데요, 기획서는 스타트업의 상황에 따라 크게 세 가지 방향을 중점으로 제작되어야 합니다.

초기 스타트업의 경우, 개발을 의뢰할 때 가장 범하기 쉬운 기획 상의 오류는 바로 개발 기획서에 ‘아이디어'만 존재하였을 때 입니다.

특히 창업 경험이 적거나 처음이라면, 초기 작성된 개발 기획서에는 제품에 대한 아이디어의 방향성 위주의 기술이 중점이 되는 경우가 많습니다. 어떤 제품을 개발하고 싶은지에 대한 방향성을 공유하는 것 자체는 좋지만, 해당 설명 하나만으로 개발에 대한 모든 프로세스가 개발자 머리속 안에 그려지는 것은 아닙니다.

또한 사람마다 그리는 생각이 정말 천차만별이기 때문에, 의뢰하실 때 예상했던 그림과 결과물이 너무 달라 당황하시는 경우도 개발 기획서가 모호하게 작성되었을 때 흔히 볼 수 있는 이슈입니다.

구현하고 싶은 프로덕트에 대해 명확한 방향성, 기준을 담은 기획서를 작성해보세요.

‘이런 정보까지 담아야하나?’하는 부분까지 개발 기획서에 담아주셔서 개발자에게 최대한 많은 정보를 제공해주시고, 자칫 놓친 부분이 없는지 외주사와 충분히 점검해주시는 것을 추천 드립니다.

기간, 수정 및 변경 요청의 제한, 요구사항에 대한 사전 체크 등을 미리 생각하고 이를 최대한 계획서에 반영하는 것이 가장 이상적입니다.

물론 일이 진행되는 과정에서 초반에 예상하지 못했던 상황이 발생할 순 있습니다. 조율이 될 수 있는 상황이라면 좋겠지만, 대부분 각자의 일에 쫓겨 적절한 보상이나 대안이 논의되기 힘들고 결론적으로 인볼브 된 이해관계자 모두에게 민감한 이슈로 프로젝트에 차질이 생기는 경우가 있습니다.

안녕하세요! 데브피플에서 기획 업무를 담당하고 있는 Esther입니다 저번 포스팅엔 제가 기획자로서 데브피플 홈페이지 개발에 참여하게 된 이야기를 공유해 드렸는데요. 오늘은 ‘기획자는 꼭 개발을 알아야 할까?’라는 주제에 대해 함께 이야기를 나눠 보고자 합니다.

아마 기획자라면 누구나 ‘개발자와 소통을 잘하기 위해 개발 공부를 해야 할까?’라는 고민을 해보셨으리라 생각됩니다. (개발자 출신 기획자가 아니라면요 ) 왜냐면 기획자는 업무 특성상 개발자와 긴밀한 소통이 필요한 직무이기 때문이죠. 하나의 웹 서비스를 기획한 후 개발 작업을 통해 프로덕트가 완성되기까지 기획자는 끊임없이 개발자와 커뮤니케이션을 하게 됩니다. 그렇기 때문에 기획자가 기본 개발 지식을 알고 개발자에게 업무 요청을 한다는 것은 전체 프로덕트 제작 과정에 큰 이점이 됩니다.

예를 들어, 게시판에 ‘좋아요’ 체크 기능을 개발자에게 요청한다고 가정해 보겠습니다. 만약 개발 지식이 전혀 없는 기획자라면 단순히 버튼 하나 추가되는 것으로 생각해 ‘개발 작업 일정은 하루면 되겠지? 금방 끝나겠지?‘라고 생각할 수 있을 거예요. 하지만 어느 정도 기본 개발 프로세스를 이해하는 기획자라면 ‘좋아요’ 체크 기능이 단순히 버튼만 추가하면 되는 것이 아니라, 추가로 데이터 설계가 필요하다는 것을 유추할 수 있습니다. 유저가 ‘좋아요’ 버튼을 눌렀다는 정보를 기억해야 하고, 해당 게시글의 ‘좋아요’ 수가 증가 되었다는 정보를 기억하기 위한 데이터 설계가 꼭 필요하기 때문이죠. 그럼 이전에 데이터 설계된 것이 전혀 없는 상황이라면 해당 기능을 개발하는데 하루, 이틀 정도가 아닌 더 많은 시간을 필요로 하게 될 것입니다. 만약 위와 같이 개발 프로세스를 이해하지 못하고 개발자에게 ‘이 기능 하루 만에 만들어주세요'라고 했다면, 개발자는 ‘어렵다. 안된다.’라고 말하면서 서로 의견이 충돌하게 되겠죠? 따라서 기획자가 개발 프로세스, 즉 과정을 이해한다는 것은 개발자와의 원활히 소통을 할 수 있게 되어 전반적인 업무 능률이 향상됩니다. 자 이제, 기획자가 개발 공부를 해야 하는 이유를 다들 공감하시겠죠?

‘개발은 파이썬으로 시작해라'라는 말을 들어보신 적 있으신가요? 아마 비전공자는 어떻게 개발 공부를 시작해야 할지 막막해 인터넷 검색을 해보신 분이라면 여러 번 보셨을 만한 문장일 거예요. 그럼 과연 기획자가 개발 공부를 하는데 파이썬과 같은 프로그래밍 언어를 꼭 배워야 하는 것일까요? 아니요! 그렇지 않습니다. 기획자가 개발 공부를 하는 이유는 실무에서 개발자와의 커뮤니케이션을 위한 개발 지식이 필요한 것이지 개발자가 코드를 어떻게 작성했고, 그 코드를 이해하기 위해 공부하는 것이 아니니까요! 그러므로 개발자와 협업하는 기획자, 디자이너, 또는 개발자를 고용하는 창업자에게 필요한 개발 지식은 바로 ‘IT 개발 지식'입니다. 즉, 개발자와 소통 시 자주 사용하는 개발 용어나 개념을 익히는 것이죠. 그럼 비개발직군인 기획자, 디자이너, 또는 창업자가 알아두면 좋은 IT 개발 지식 중 두 가지 개념을 소개해 드리겠습니다  

먼저 클라이언트(Client)란 서버와 이어진 소프트웨어 즉, 핸드폰이나 노트북, 인터넷 브라우저(크롬, 사파리 등)를 말합니다. 그리고 서버(Server)는 클라이언트의 요청을 받아 처리하고 응답을 보내는 소프트웨어입니다. 쉽게 말해, 클라이언트는 서비스 사용자이며 서버는 서비스 제공자라고 볼 수 있습니다. (**해당 클라이언트, 서버 개념은 홈페이지 제작 기준입니다. 앱이나 기타 소프트웨어에서의 개념과 다를 수 있습니다.) 예를 들어, 유저가 노트북에서 인터넷 브라우저 크롬을 이용해 데브피플 홈페이지에 접속한다면 이때 클라이언트는 인터넷 브라우저 크롬이 됩니다. 즉, 유저가 인터넷 브라우저 크롬을 이용해 데브피플 홈페이지 서버에 페이지를 요청한 것입니다. 그럼 클라이언트의 요청에 따라 페이지를 응답해 준 것은 바로 서버, 즉 데브피플의 서버 프로그램입니다. 서버가 클라이언트에게 홈페이지 데이터를 전송해 주었기 때문에 클라이언트가 홈페이지를 볼 수 있게 된 것이죠. 이처럼 앱이나 웹사이트는 클라이언트와 서버 상호작용의 연속으로 이루어 집니다.

데이터베이스(Database)란 어떠한 데이터들의 모음입니다. 즉, 데이터들을 한 곳에 모아둔 창고라고 볼 수 있습니다. 예를 들어, 많은 고객분이 데브피플의 홈페이지에서 견적 문의 신청서를 작성해 주셨을 때 그 데이터들을 저장해 보관하는 장소이죠. 그럼 위에서 살펴본 클라이언트, 서버와는 어떤 상관관계를 가졌을까요? 만약 유저가 어떤 홈페이지에 로그인하려고 아이디와 비밀번호를 입력한다면 서버는 그 데이터를 받아 데이터베이스에 해당 유저의 아이디와 비밀번호가 일치하는 데이터가 있는지 찾게 됩니다. 그럼 서버는 일치하는 데이터가 있다면 로그인 성공을 응답해 줄 것이고, 일치하지 않는다면 로그인 실패를 응답해 줄 것입니다. 이처럼 서버는 저장된 정보를 데이터베이스를 통해 효율적으로 데이터를 조회하고 생성 및 수정, 삭제 등의 처리를 할 수 있습니다.

안녕하세요! devpeople에서 기획 업무를 담당하고 있는 Esther입니다. 오늘은 기획자인 제가 어떻게 devpeople 홈페이지를 기획하고, 또 개발까지 하게 되었는지 그 자세한 이야기를 공유하고자 합니다. 아마 ‘어떻게 기획자가 개발을 했지?’라고 의아하실 거 같은데요. 기획자의 고군분투 개발 스토리가 궁금하시다면 재밌게 끝까지 읽어주세요~  

먼저 devpeople에서 기획자인 제가 하는 일은 클라이언트의 요구사항에 맞춰 웹사이트에서 제공할 구성 내용을 기획하고, 디자이너, 개발자와의 협업을 통해 웹사이트를 구축하는 업무를 담당하고 있어요. 즉, 하나의 프로젝트를 기획하고 전반적인 총괄 역할을 하고 있습니다 그래서 기획자에게 가장 중요시 되는 역량이 바로 ‘커뮤니케이션' 능력이에요. 디자이너와 개발자가 기획 의도와 목적을 정확히 이해하고 작업할 수 있도록 지속적인 커뮤니케이션을 통해 최상의 결과물을 만들어내야 하거든요. 그런데 종종 업무를 하면서 가장 어려운 점이 ‘개발자와의 소통' 문제였어요. 아무래도 기획자나 디자이너는 비개발직군이다 보니 보통 개발지식이 부족 하거든요 예를 들어, 제가 개발자님에게 기능 작업 요청을 드렸을 때 개발자님이 ‘A 기능은 수정하는데 일주일 정도 소요돼요’, ‘B 기능은 DB 전체를 변경해야 해서 당장 구현하기 어려워요’ 라고 말씀하시면 바로 이해하기는 어렵더라고요. 제가 생각하기엔 간단한 수정 요청인데 왜 일주일이 걸릴까 부터 DB는 무엇인지 궁금증이 꼬리에 꼬리를 물어 점점 답답함만 커져 갔습니다. 그래서! 결국 저는 이런 궁금증과 답답함을 해소하고자 개발 공부를 시작하게 되었습니다

비전공자인 제게 처음 개발은 제 2 외국어를 배우는거 같았어요. 이해는 잘 안되지만 일단 무작정 외우고 코드를 따라 쳤었어요. 그런데 처음이라 굉장히 어려우면서도 또 굉장히 재밌더라구요?! 컴퓨터 까만 화면에 한 줄의 코드를 따라 작성했더니 크롬 화면에 “Hello, World”가 떴을 때의 그 경이로움..!   신기하고 재밌어서 그 후로 개발에 빠져 매일 공부를 했습니다. 그리곤 공부하다가 모르는게 있을 땐 저희 devpeople의 풀스택 개발자인 Yaro에게 질문 하곤 했어요. Yaro는 정말 모르는게 없고 또 언제나 친절하게 알려주셔서 제겐 Best Teacher 였습니다! ( Yaro가 쓰라고 시킨거 절대 아닙니다  ) 그렇게 계속 개발 공부를 하다보니 어느새 개발자님의 이야기가 무슨 말인지 조금씩 이해할 수 있게 되었어요. DB가 무엇인지, 사용자가 입력한 데이터가 어떻게 서버로 전송 되는지 등 전반적인 개발 과정을 이해하게 되었죠. 개발에 대한 이해가 생기니 개발자님과의 커뮤니케이션도 더욱 원활히 할 수 있게 되어, 결론적으로 기획 업무에도 많은 도움이 되었습니다. 어려운 개발 공부였지만 역시 도전하길 잘 했다 싶었죠! 그러던 어느 날, Yaro의 제안으로 제가 devpeople 리뉴얼 홈페이지 개발할 수 있는 기회를 얻게 되었어요! 이론 공부만 하던 제가 실전으로 개발을 한다니..! 엄청 떨리면서도 기대됐어요. 좋은 기회인거 같아 바로 하겠다고 하고 Yaro와 함께 devpeople 홈페이지를 개발하게 되었습니다.

일단 제가 직접 기획부터 개발까지 작업한 devpeople 홈페이지 보고 가실께요 ~        

새롭게 리뉴얼된 데브피플 홈페이지는 React(리액트)기반에 Next.JS와 TypeScript(타입스크립트)를 사용하여 구현하였어요. 풀스택 개발자인 Yaro가 백엔드 작업을, 제가 프론트엔드 작업을 진행하였습니다. 이전에 리액트는 혼자 개발 공부하면 잠깐 사용해 봤었는데 타입스크립트는 완전 처음이였어요. 그래도 일전에 타입스크립트는 기존 자바스크립트에 타입만 추가된 언어이다 라고 알고 있어서 금방 익힐 수 있겠지 싶었죠. 하지만 현실은 제 생각보다 더 어려웠습니다   그래서 직접 개발하면서 느낀 타입스크립트 사용후기에 대해 간략히 이야기하고 나누어 볼게요. 아, 일단 타입스크립트란 무엇인지 간단히 알아볼까요? 먼저, 타입스크립트는 자바스크립트의 모든 기능을 포함하면서 추가적인 다른 기능이 포함된 프로그래밍 언어에요. 그리고 이 둘의 가장 큰 차이점은 타입(Type)의 유무이죠. 기존의 자바스크립트는 변수를 선언할 때 타입을 선언하지 않고, 값을 할당하는 시점에 변수의 타입이 동적으로 결정됩니다. 이러한 자바스크립트의 동적타입 특징은 복잡한 프로그램을 제작할 때 불편하게 작용되는데요. 변화하는 변수 값을 추적하기 어렵고, 개발자의 의도와는 상관없이 자바스크립트 엔진에 의해 암묵적으로 타입이 자동 변화돼요. 그래서 자바스크립트는 타입에 유연성이 높은 만큼 신뢰성을 떨어지게 되는 것이죠. 그래서 이러한 자바스크립트의 단점을 개선하기 위해 만들어진게 바로 타입스크립트입니다.

외주사를 운영하다보면 하루에도 정말 다양한 사업의 문의를 받게 됩니다.

매번 찾아주심에 감사함을 느끼는 한 편, 문의를 끝내고 나면 매번 다른 문의 전화임에도 불구하고 묘하게 같은 답변을 드리고 있는 듯한 느낌을 갖게 되는데요.

이제 막 창업을 시작하신 분들부터 이미 안정적인 사업을 꾸려가시는 분들까지 사업의 크기가 모두 다른 클라이언트임에도 외주 문의에 대한 내용에 차이가 있을거라는 예상과는 달리 왜 비슷한 느낌을 받게 되는 지 그 이유에 대해서 정리해보고자 합니다. (아울러 이 글이 현재 외주를 고민하고 계신 창업주 분들께 도움이 되었으면 좋겠습니다.)

안녕하세요. 스타트업코드의 대표자 void입니다. 스타트업코드로서 첫 글을 쓰게 되었습니다. 저와 저희 devpeople은 스타트업 대상으로 외주 및 개발 분야 멘토링을 영위하고 있습니다. 스타트업 대상으로 외주 및 멘토링을 하면서 느낀점은 대표님들께서 사업에 대한 계획은 디테일하게 생각하셨지만 개발과 관련한 계획은 많은 생각을 못하신다고 생각했습니다. 그래서 이제부터 개발에 대한 계획을 세우실 수 있도록 다양한 이야기를 해볼까 합니다.

첫 주제는 ‘스타트업에서 IT서비스를 개발하는 관점’입니다. 스타트업 서비스 개발을 대규모 서비스 개발과 비교하며 말해보도록 하겠습니다. 대규모서비스, 대기업에서의 개발과 스타트업 서비스 개발 차이는 무엇일까요? 저는 이 차이를 음식점 창업으로 비유를 들고 싶습니다.

처음부터 시장의 문제점을 한 번에 해결할 제품을 만들어내는 것은 거의 불가능에 가깝습니다.