devpeople

blog featured
안녕하세요.
데브피플에서 프론트엔드 개발을 담당하고 있는 Woody입니다.
네이버, 카카오 등 IT 대기업뿐만 아니라 우아한형제들, 토스 등 빠르게 성장하는 스타트업들 역시 이미 코드 리뷰 문화가 필수적으로 자리잡고 있습니다. 또한 많은 개발자들은 코드 리뷰 문화를 실천하는 회사에서 일하고 싶다고 말할 정도로 코드 리뷰 문화가 있는 회사는 좋은 회사라는 이미지로 자리매김하고 있습니다. 오늘은 코드 리뷰가 무엇인지, 코드 리뷰가 왜 중요한지 설명드리겠습니다.

코드리뷰란?

코드 리뷰란 내가 작성한 코드를 다른 개발자들이 검토하는 활동으로 타인의 시각에서 예상치 못한 오류와 발생 가능성을 찾아내고 이러한 과정을 통해 더 나은 코드를 만들 수 있습니다. 코드 리뷰의 핵심은 프로젝트의 코드 스타일을 유지하거나, 예상되는 문제점을 빠르게 파악하는 것뿐만 아니라 코드에 대한 책임이 작성한 개인에게 있지 않고 우리 모두에게 있다는 문화를 만들 수 있습니다. 아래에서 이러한 코드 리뷰 과정은 어떤 방식으로 진행되는지 알아보겠습니다.

코드리뷰 과정

1.
코드 작성자는 코드 리뷰 도구를 이용해 코드 변경 내용과 작업 내용을 정리 후 동료 개발자들에게 코드 리뷰를 요청합니다.
2.
요청받은 리뷰어는 작업한 코드 내용을 검토한 후 피드백을 남깁니다.
3.
코드 작성자는 이를 반영 후 다시 리뷰를 받습니다.
코드리뷰 문화
안녕하세요.
데브피플에서 프론트엔드 개발을 담당하고 있는 Woody입니다.
서비스 개발 과정에서 테스트 코드 작성을 실천하면 더 나은 결과물을 만들 수 있다는 글을 많이 볼 수 있습니다. 실제로 테스트 코드는 서비스의 안정성을 높이고, 기능 추가 및 수정으로 인해 발생할 수 있는 부작용(Side-effect)을 줄일 수 있습니다. 하지만 테스트 코드를 작성하려면 개발 시간이 증가하고, 이를 관리하는 추가적인 유지보수 비용이 발생할 수 있습니다. 오늘은 테스트 코드가 무엇인지, 장단점에 대해서 설명드리겠습니다.

테스트 코드란?

테스트 코드(Test code)는 소프트웨어의 기능과 동작을 테스트하는 데 사용되는 코드입니다. 소프트웨어 테스트는 소프트웨어의 결함을 찾아내고 수정하는 과정에서 매우 중요합니다. 테스트 코드는 개발자가 작성한 코드를 실행하고 예상된 결과가 정상적으로 나오는지 확인하는 데 사용됩니다.
테스트 코드에는 단위 테스트(Unit Testing), 통합 테스트(Integration Testing), E2E(End to End Testing) 등의 다양한 종류가 있으며, 각각의 테스트는 특정한 측면에서 소프트웨어의 동작을 테스트합니다. 이처럼 테스트를 구분하는 이유는 테스트 대상의 범위가 다르기 때문입니다.
개발자는 테스트 코드를 작성함으로써, 개발 과정 중 예상치 못한 문제를 미리 발견할 수 있고, 코드 수정이 필요한 상황에서 유연하고 안정적인 대응을 할 수 있습니다. 이는 곧 서비스의 품질 및 안정성과 직결되어 있습니다.

테스트의 종류

1. 단위 테스트란?

단위 테스트(Unit Test)는 소프트웨어 개발에서 일반적으로 사용되는 테스트 중 하나로, 개별적인 코드 단위(하나의 기능을 하는 코드)가 의도한 대로 작동하는지 확인하는 과정입니다. 예를 들어, 쇼핑몰 서비스에서 상품을 장바구니에 담는 기능을 테스트한다고 가정해 보겠습니다. 단위 테스트는 아래 예시 이미지와 같이 장바구니에 담기를 클릭했을 때 장바구니에 데이터가 담기는 예상 결과를 주는지 코드 단에서 한 번 더 테스트함으로써, 기능이 올바르게 동작하는지 확인할 수 있습니다.
장바구니 담기 기능 예시(쿠팡)
테스트 코드의 필요성
안녕하세요.
데브피플에서 프론트엔드 개발을 담당하는 Woody입니다.
최근 개발 수요가 늘어나면서 많은 기업이 개발 인력 충원에 앞장서고 있습니다.
하지만 개발자를 채용하고 바로 개발에 착수하기에 앞서, 우리 사업이 어떤 단계에 있느냐를 먼저 파악하는 것이 중요하다고 생각합니다.
만약 비즈니스 초기 단계이며 MVP 개발이 우선되어야 하는 상황이라면 서비스를 만들 수 있는 노 코드 툴의 도입이 더 나은 선택일 수 있다고 생각합니다.
저희 데브피플 개발팀에서는 서비스 단계 및 규모에 따른 생산성 향상을 위해 코딩 또는 노코드를 선택해 서비스를 개발하고 있습니다.
오늘은 코딩과 노코드 그리고 둘을 비교한 장단점에 관해서 설명하겠습니다.

코딩(Coding)이란?

코딩, 프로그래밍은 개발자가 직접 프로그래밍 언어를 사용하여 프로그램에서 작업을 수행하기 위해 코드를 통해 컴퓨터에게 명령해 소프트웨어를 만드는 방식입니다.
코딩하기 위해서는 개발자가 오랜 시간 프로그래밍 언어를 다루는 방법을 훈련하고 이 기술을 활용해 소프트웨어를 만들 수 있습니다.

장점

코딩, 즉 프로그래밍 언어를 통해 소프트웨어 개발의 가장 큰 장점은 서비스의 모든 부분에서 제한 없이 커스터마이징 및 제어가 가능하며, 여러 가지 복잡한 문제를 해결할 수도 있습니다.
예를 들어 어느 위치든 자유롭게 컴포넌트(텍스트, 버튼 등)를 배치하거나, 복잡한 수식 등을 다루는 등의 소프트웨어를 만들 수 있습니다.
코딩과 노코드 개발
안녕하세요.
데브피플에서 프론트엔드 개발을 담당하고 있는 Woody입니다.
오늘은 저희 데브피플 개발팀에서 프로젝트의 생산성을 극대화하기 위한 디자인 시스템(Design system)과
컴포넌트(Component)에 대해서 설명드리겠습니다.

컴포넌트(Component)란?

컴포넌트 예시 이미지
컴포넌트(Component)란 재사용 가능한 독립된 조각을 의미합니다. 위 이미지에서 볼 수 있듯이 독립된 컴포넌트들을 조합해서 하나의 페이지를 구성할 수 있습니다. 단순하게 생각하면 다양한 레고 조각들을 결합해서 하나의 결과물을 만드는 것과 같다고 생각하면 됩니다. 또한 레고 조각들은 각자 자신이 사용될 수 있는 명확한 역할(기능)을 가지고 있으면서 다양한 위치에서 재사용되는 것을 알 수 있습니다. 이러한 독립적인 역할(기능)을 가진 레고 조각이 만들어지는 과정에서 다양한 위치에서 사용될 수 있듯이, 하나의 독립된 컴포넌트도 다양한 화면에서 재사용될 수 있습니다.
그렇다면 개발적인 측면에서 컴포넌트의 재사용이 가능하다는 것은 어떤 장점들이 있을까요?
컴포넌트 사용 비교
첫 번쨰는 유지보수 관점입니다. 현재 진행 중인 프로젝트가 컴포넌트 기반으로 이루어져 있다는 가정하에, 위의 이미지와 같이 다양한 페이지에서 사용되고 있는 버튼의 디자인을 변경해야 하는 상황이 발생한다면, 컴포넌트 방식은 하나의 버튼 컴포넌트의 스타일만 수정하면 간단하게 모든 스타일 변경되는 것을 확인할 수 있습니다.
두 번째는 생산성 관점입니다. 위의 이미지에서 보이는 것과 같이 대부분의 페이지에서 동일한 버튼이 사용되는 경우가 많습니다. 컴포넌트 기반의 개발로 매번 버튼 태그 및 CSS 생성 작업 없이 사전에 구현한 컴포넌트를 사용해 간단히 작업을 끝낼 수 있습니다. 이렇듯 우리 데브피플은 컴포넌트 기반으로 개발을 진행함으로써, 프로젝트 생산성은 향상되고, 짧은 기간 안에 서비스를 출시할 수 있는 것입니다.
그렇다면 컴포넌트 방식으로 인한 단점은 존재하지 않을까요?

컴포넌트 기반 개발의 단점

컴포넌트와 디자인 시스템
안녕하세요.
데브피플에서 프론트엔드 개발을 담당하고 있는 Woody입니다.
저희 데브피플 개발팀에서는 서비스의 성능 개선뿐만 아니라 발전해가는 웹과 관련된 다양한 기술적인 내용들을 공유하면서 항상 더 나은 서비스를 만들기 위해 노력하고 있습니다. 이런 내부적인 활동과 관심을 통해 저희는 현재 Next.js를 주력 프레임워크로 채택하여 사용하고 있습니다. React에서 더 나아간 Next.js가 무엇인지? Next.js의 필요성? 에 대해서 설명해드리겠습니다.

Next.js란 무엇인가?

Next.js는 SSR(Server Side Rendering), SSG(Static Site Generation) 생성 등의 기능을 제공하는 React 기반 프레임워크입니다.

Next.js의 필요성?

Next.js의 필요성을 쉽게 이해하기 위해서 React 동작 원리에 대해서 먼저 이야기해보면 도움이 될 것이라고 생각합니다.
React는 CSR(Client Side Rendering) 방식으로, 최초 로드 시 빈 index.html 생성과 모든 페이지의 JS 파일을 사전 로드함으로써, 사용자에게 빠른 인터렉션 경험을 제공합니다.
Next.js란?
오늘은 쿠키와 세션에 대해 알아보도록 하겠습니다.

# HTTP 특징

앞서 쿠키와 세션을 이해하기 위해선 HTTP 프로토콜의 특성을 이해해야 합니다. HTTP(HyperText Transfer Protocol)는 ‘Connectionless, Stateless’한 특성을 가지는데, 이러한 특성을 보완하기 위해 쿠키와 세션을 사용하기 때문입니다. 먼저 HTTP란 HTML 문서 파일과 같은 리소스를 가져올 수 있도록 해주는 프로토콜입니다. Web에서 이루어지는 클라이언트와 서버 간의 모든 데이터 요청과 응답은 HTTP를 통해 이루어집니다.
•
HTTP 특성
이러한 HTTP 특성을 바로 쿠키와 세션으로 보완할 수 있습니다. 만약 쿠키와 세션을 사용하지 않으면 HTTP의 특성으로 인해 사용자가 웹사이트에 로그인한 후에도 매 페이지 이동 시 마다 계속 다시 로그인을 해야 하는 매우 불편한 상황이 발생될 것입니다. 바로 HTTP는 ‘Connectionless, Stateless’한 특성을 지녔으니까요!

# 쿠키 (Cookie)

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

# 세션 (Session)

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

# 쿠키와 세션의 차이점

쿠키와 세션

# 브라우저 렌더링이란?

CSR과 SSR의 장단점
지난 포스팅에서 살펴보았듯이 이젠 웹 프론트엔드 생태계에서 CSR(Client Side Rendering)은 흔히 사용되는 프론트엔드 개발 방식이 되었습니다. SPA(Single Page Application) 구조를 통해 페이지를 렌더링하여 사용자에게 빠른 인터렉션을 제공해주는 것이죠. 그럼 SPA란 정확히 무엇일까요? 오늘은 SPA에 대해 자세히 알아보도록 하겠습니다
# SPA (Single Page Application)
과거 전통적인 웹 사이트는 지금과는 달리 하나의 문서(예: 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 프레임워크로 개발하는 것이 좋고, 반대로 단순히 간단한 정보를 제공하는 서비스라면 복잡한 기술 사용 없이 기존의 웹 사이트 개발 방식대로 개발하는 것도 좋습니다.
SPA란 무엇인가
일반 사용자가 보았을 땐 똑같은 모바일 앱이지만 실제 개발 방법에 따라 모바일 앱 종류는 여러가지로 나뉘어집니다. 오늘은 다양한 모바일 앱 종류 중 모바일 웹엡, 네이티브 앱 , 하이브리드 앱에 대해 알아보도록 하겠습니다.

# 모바일 웹앱 (Mobile Web Application)

•
모바일 웹앱이란?
•
장점
•
단점
•
모바일 웹앱과 모바일 웹의 차이점

# 네이티브 앱 (Native Application)

•
네이티브 앱이란?
•
장점
•
단점
내 서비스는 어떤 모바일 앱이 좋을까?
안녕하세요.
devpeople에서 개발 리드를 맡고 있는 Yaro입니다.
devpeople은 MVP 전문 개발사로 대표님들의 아이디어를 실현하기 위해 꼭 필요한 기능만 추가하여 빠른 출시를 목표로 합니다.
추가로 개발 지식을 필요로 하는 대표님 또는 팀원을 위한 기업 교육도 진행하고 있습니다.
제가 스타트업에서 대표님들의 아이디어를 현실로 만들어 드리면서 겪었던 이야기를 한번 풀어 보려고 합니다.

외주 개발 시 대표님이 직접 개발 기획에 참여해야 하는 이유

개발에 들어가기 전 항상 대표님과 사전 미팅을 오래 하게 되는데, 그 이유는 대표님들과 이야기를 오랫동안 나누어 보아야 원하시는 바를 정확하게 개발에 녹여 낼 수 있기 때문입니다.
물론 대표님이 정말 바쁘시다는 것도 알고 있습니다. 하지만 경험상 대표님이 없고 창엄팀 멤버분들만 있을 경우 대표님이 생각하시던 그림과는 다른 결과물이 나오는 경우도 종종 있었습니다.

서비스명은 고유할수록 좋습니다.

서비스명을 정하실 때 고려하실 포인트는 당연히 ‘서비스와 관련성 있으면서 발음하기 편한 쉬운 이름'이 제일 좋을 것입니다.
초기 스타트업 대표님이 웹페이지 만들 때 신경 써야 할 점 1편, SEO

# 국내 웹 브라우저 현황

코로나 19를 계기로 디지털 의존도가 매우 높아진 요즘, 여러분은 인터넷을 이용할 때 어떤 브라우저를 사용하고 계신가요?
Statcounter의 대한민국 웹 브라우저 2022 시장 점유율 현황에 따르면 구글 크롬(chrome) 53.95%, 사파리(safari) 12.85%, 삼성 인터넷 12.77%, 네이버 웨일 0.04%, 엣지 8.15%, 파이어폭스 1.2%를 차지하고 있습니다.
대한민국 웹 브라우저 2022 시장 점유율 현황 - Statcounter
그리고 오는 6월 15일, 인터넷 익스플로러가 공식적으로 지원이 종료 됨에 따라 다소 미미하지만 국내 웹 브라우저 시장에 지각변동이 일어날 것이라고 예상하고 있습니다. 한 때 국내 웹 브라우저 시장 점유율 90%까지 차지한 인터넷 익스플로러는 어쩌다 지원 종료가 되게 되었을까요? 그 이유는 크게 두가지로 볼 수 있는데 첫번째로는 보안이 취약하다는 점, 그리고 두번째로 HTML, CSS, JavaScript 구형 표준 사용으로 인한 호환성 문제가 있습니다. 아마 웹 프론트엔드 개발자나 웹 퍼블리셔라면 그동안 인터넷 익스플로러의 호환성 문제로 인해 가장 많은 고통을 겪으셨으리라 생각되는데요 인터넷 익스플로러는 자신만의 전용 개발 코드 규격이 존재하며 HTML, CSS, JavaScript 최신 표준 문법이 아닌 구형 표준 문법을 사용합니다. 이로 인해 최신 표준에 맞춰 작성한 코드가 인터넷 익스플로러에선 제대로 작동하지 않는 문제들이 생겨나게 된 것이죠. 그래서 웹 페이지 개발 시 Babel과 같은 자바스크립트 컴파일러를 사용해야 합니다. 즉 최신 버전의 javascript 문법은 인터넷 익스플로러가 이해하지 못하기 때문에 babel을 통해 인터넷 익스플로러가 이해할 수 있는 문법으로 변환시켜주는 것이죠. 또한 다양한 브라우저에서 호환이 가능한지 ‘크로스 브라우징'을 꼼꼼히 확인해야 합니다. 그래야 크롬에서 잘 보여지는 웹 페이지가 사파리에선 잘 안보이는 등 여러 에러 상황을 방지할 수 있습니다.

# 크로스 브라우징의 중요성

먼저 크로스 브라우징(Cross Browsing)이란 여러 웹 브라우저에서 웹 페이지가 정상적으로 작동하도록 만드는 작업을 말합니다. 즉 크롬이나 사파리 등 다양한 브라우저 상에서 웹 페이지가 개발자가 의도한 대로 잘 보여지도록 개발하는 것이죠. 우리가 사용하는 웹 브라우저는 각기 다른 기술(렌더링 엔진)이 존재하여 동일한 개발 코드라도 웹 브라우저 별로 표현하는 것에서는 차이점이 발생할 수 밖에 없습니다. 그렇기 때문에 동일한 웹 사이트라 하더라도 어떤 웹 브라우저로 보느냐에 따라 조금씩 다르게 보일 수 있습니다. 따라서 수많은 웹 브라우저에서 모두 동일하게 웹 페이지를 보여준다는 것은 현실적으로 거의 불가능한 이야기입니다. 하지만 ‘크로스 브라우징'을 통해 최대한 다양한 브라우저에서 개발자가 의도한 대로 이상 없이 작동하도록 만들어 주어 사용자가 웹 페이지를 이용하는데 불편함을 겪지 않도록 해야 합니다. 그럼 크로스 브라우징 작업을 하기 위해선 무엇을 해야 할까요? 가장 먼저 해야 할 일은 바로 우리가 만들 웹 페이지가 어떤 브라우저까지 대응할 것인지를 정해야 합니다. 예를 들어 ‘빠르게 서비스를 출시하기 위해 사람들이 가장 많이 사용한 크롬만 대응하겠다’, ‘애플 관련 악세서리를 판매하는 웹사이트니깐 사파리는 꼭 대응해야 한다.’ 등등 웹 페이지 사용자 또는 특징을 고려해 정하는 것이 좋습니다. 이 후 실제 개발하면서 QA를 통해 각 브라우저에서 정상적으로 작동하는지 테스트를 진행하면 됩니다. ‘Can I Use’ 와 같이 각 브라우저에 호환성을 검토할 수 있는 사이트를 이용하면 더욱 편리합니다   그리고 각 브라우저마다 다른 CSS 기본 스타일 속성을 reset.css를 이용해 초기화 작업을 하는 방법이 있습니다. 하지만 이것도 어느 정도 문제를 해결하는 것이지 결국 브라우저마다 렌더링 과정이 다르기 때문에, 꼼꼼히 각 브라우저마다 확인하여 크로스 브라우징 체크를 해야하는 것이 매우 중요합니다.
국내 웹 브라우저 현황 및 크로스 브라우징의 중요성
안녕하세요. 최근 데브피플이 예비, 초기 스타트업을 위한 MVP 패키지를 출시함에 따라 정말 많은 고객들이 MVP 개발을 의뢰해주고 계시는데요. 여러분들의 많은 관심과 성원 감사드립니다 그래서 오늘은 예비, 초기 창업자라면 누구나 들어보셨을 ‘MVP’란 무엇인지, 어떤 성공 사례가 있는지 알아보도록 하겠습니다.

# MVP란?

“사람들이 원하는 그 무언가를 만드는 것, 그것이 가장 기초적인 문제입니다. 시장에서 버려진다면, 아마도 그건 사람들의 욕구를 충족하지 못했을 겁니다.” – Y Combinator의 공동 창업자이자 투자자, 폴 그레이엄
MVP(Minimum Viable Product)란 ‘에릭 리스'에 의해 만들어진 용어로, 고객의 요구사항에 맞춰 최소한의 필수 기능을 구현한 제품을 말합니다. 초기 스타트업은 빠르게 서비스를 출시해 실제 유저들이 필요로 하는 서비스인지 검증받는 것이 매우 중요합니다. 아무리 좋은 아이디어라도 빠르게 변화하는 IT 트렌드 속에서 실제 결과는 예상과 다를 수 있으니까요.
그래서 처음부터 대규모 서비스를 만들기보단 꼭 필요한 핵심 기능을 구현하여 시행착오에 따른 시간과 비용을 최소화하는 것이 MVP 개발의 가장 큰 핵심입니다. MVP 개발은 경쟁사보다 빠른 시장 진입을 통해 실제 유저의 데이터를 분석할 수 있습니다. 더 이상 가설이 아닌 실제 데이터를 통해 인사이트를 얻을 수 있죠. 그리고 이를 통해 점차 서비스를 고도화시키며 제품을 완성해 나가기 때문에 가장 리스크가 적고 효율적인 개발 방식입니다. 또한 최소한의 기능만을 개발함으로써 개발 비용이 적어 구글 광고, 네이버 광고와 같은 마케팅 비용이나 여러 필요한 예산을 더 확보할 수 있습니다.

# MVP 성공 사례 1 - AIRBNB

소유한 호텔은 하나도 없지만 전 세계에서 가장 큰 숙박 네트워크를 제공하는 에어비엔비의 첫 시작은 간단한 블로그에서 시작되었습니다. 지금과 같이 세련된 UX를 가진 서비스가 아닌 가장 기본 기능에만 충실하였습니다. 숙소 사진, 위치, 가격, 그리고 호스트 연락처 정도의 간략한 정보만 제공해주었죠. 이후 에어비엔비는 지속해서 유저의 피드백과 경험을 서비스 기능에 반영하며 업데이트하였습니다. 유저의 다양한 니즈에 따라 호스트와의 대화, 슈퍼 호스트 체계, 보안 결제 등 서비스를 개발해 나아가 프로덕트의 가치를 높였습니다. 초기 에어비엔비의 MVP 제품은 전혀 세련되지도 않고 다양한 기능을 제공하지 않았지만, 기본 기능에 충실하였고 고객의 피드백을 받으며 끊임없이 개선하여 220개 이상의 국가의 10만 도시의 7백만 개의 숙소를 가진 지금의 에어비엔비가 되었습니다.
예비, 초기 스타트업을 위한 MVP
그동안 저희가 스타트업 대표님들과 외주를 고민하시는 분들께 강조하여 말씀드렸던 내용은 기획서의 중요성이었습니다.
그러나, ‘이것’이 제대로 성립되어 있지 않다면 아무리 잘 쓴 기획서여도 무용지물이 되지요. 그것은 바로 계약서입니다. 스타트업의 규모나, 일의 마감기한에 따라 계약서를 약식으로 작성하거나 혹은 과업 진행 중이나 과업 종료 후에 계약서를 작성하는 경우도 종종 목격한 적이 있는데요, 이는 굉장히 위험 부담이 큰 협업이라고 생각합니다.
그런데 계약서를 잘 쓰기 위해 어떻게 해야할까요?
직접 변호사를 만나 자문을 구해야 할지, 만든다면 어떤 조항을 넣어야 할지. 챙길 것이 너무나도 많은 대표님들에게 계약에 관련한 한가지 꿀팁을 제공해 드리려고 합니다.
외주 시 기획서보다 중요한 그것, ‘계약서’
마케팅, 영업 등등.. 신경써야 할 비즈니스가 너무 많아서 개발은 외주를 맡겨야 할 것 같은데, 도대체 어떻게 외주를 맡겨야 안전하게 처리할 수 있을까?
중소기업이나 스타트업 대표님들이시라면 한 번쯤 위와 같은 고민을 해보셨으리라 생각합니다.
오늘은 이런 고민을 안고 계신 대표님들을 포함하여, 시스템 개발을 의뢰하는 분들께 도움이 될 수 있도록 상황별 올바른 기획서 제작 방향성에 대해 말씀 드리고자 합니다. 외주사로 일하면서 기획서의 중요성은 몇 번을 강조해도 지나치지 않는다는 생각이 드는데요, 기획서는 스타트업의 상황에 따라 크게 세 가지 방향을 중점으로 제작되어야 합니다.

1. 아이디어만 있는 초기 스타트업 상황 : 당장 머릿속에 그려질 만큼 자세한 기획서

초기 스타트업의 경우, 개발을 의뢰할 때 가장 범하기 쉬운 기획 상의 오류는 바로 개발 기획서에 ‘아이디어'만 존재하였을 때 입니다.
특히 창업 경험이 적거나 처음이라면, 초기 작성된 개발 기획서에는 제품에 대한 아이디어의 방향성 위주의 기술이 중점이 되는 경우가 많습니다. 어떤 제품을 개발하고 싶은지에 대한 방향성을 공유하는 것 자체는 좋지만, 해당 설명 하나만으로 개발에 대한 모든 프로세스가 개발자 머리속 안에 그려지는 것은 아닙니다.
또한 사람마다 그리는 생각이 정말 천차만별이기 때문에, 의뢰하실 때 예상했던 그림과 결과물이 너무 달라 당황하시는 경우도 개발 기획서가 모호하게 작성되었을 때 흔히 볼 수 있는 이슈입니다.
구현하고 싶은 프로덕트에 대해 명확한 방향성, 기준을 담은 기획서를 작성해보세요.
‘이런 정보까지 담아야하나?’하는 부분까지 개발 기획서에 담아주셔서 개발자에게 최대한 많은 정보를 제공해주시고, 자칫 놓친 부분이 없는지 외주사와 충분히 점검해주시는 것을 추천 드립니다.

2. 기획, 디자인, 퍼블리싱 등 어느 정도의 준비를 마친 단계 : 제품 외의 요소(기간, 수정, 단가 등)에 대한 최종 합의 사항을 담은 기획서

기간, 수정 및 변경 요청의 제한, 요구사항에 대한 사전 체크 등을 미리 생각하고 이를 최대한 계획서에 반영하는 것이 가장 이상적입니다.
물론 일이 진행되는 과정에서 초반에 예상하지 못했던 상황이 발생할 순 있습니다. 조율이 될 수 있는 상황이라면 좋겠지만, 대부분 각자의 일에 쫓겨 적절한 보상이나 대안이 논의되기 힘들고 결론적으로 인볼브 된 이해관계자 모두에게 민감한 이슈로 프로젝트에 차질이 생기는 경우가 있습니다.
개발 외주사를 여행하는 창업 대표들을 위한 안내서
안녕하세요! 데브피플에서 기획 업무를 담당하고 있는 Esther입니다 저번 포스팅엔 제가 기획자로서 데브피플 홈페이지 개발에 참여하게 된 이야기를 공유해 드렸는데요. 오늘은 ‘기획자는 꼭 개발을 알아야 할까?’라는 주제에 대해 함께 이야기를 나눠 보고자 합니다.

# 기획자는 꼭 개발을 알아야 할까?

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

# 개발 공부 어디까지 해야 할까?

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

# 알아두면 좋은 IT 개발 지식 Ⅰ. 클라이언트와 서버

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

# 알아두면 좋은 IT 개발 지식 Ⅱ. 데이터 베이스

데이터베이스(Database)란 어떠한 데이터들의 모음입니다. 즉, 데이터들을 한 곳에 모아둔 창고라고 볼 수 있습니다. 예를 들어, 많은 고객분이 데브피플의 홈페이지에서 견적 문의 신청서를 작성해 주셨을 때 그 데이터들을 저장해 보관하는 장소이죠. 그럼 위에서 살펴본 클라이언트, 서버와는 어떤 상관관계를 가졌을까요? 만약 유저가 어떤 홈페이지에 로그인하려고 아이디와 비밀번호를 입력한다면 서버는 그 데이터를 받아 데이터베이스에 해당 유저의 아이디와 비밀번호가 일치하는 데이터가 있는지 찾게 됩니다. 그럼 서버는 일치하는 데이터가 있다면 로그인 성공을 응답해 줄 것이고, 일치하지 않는다면 로그인 실패를 응답해 줄 것입니다. 이처럼 서버는 저장된 정보를 데이터베이스를 통해 효율적으로 데이터를 조회하고 생성 및 수정, 삭제 등의 처리를 할 수 있습니다.
기획자는 꼭 개발을 알아야 할까?
안녕하세요! devpeople에서 기획 업무를 담당하고 있는 Esther입니다. 오늘은 기획자인 제가 어떻게 devpeople 홈페이지를 기획하고, 또 개발까지 하게 되었는지 그 자세한 이야기를 공유하고자 합니다. 아마 ‘어떻게 기획자가 개발을 했지?’라고 의아하실 거 같은데요. 기획자의 고군분투 개발 스토리가 궁금하시다면 재밌게 끝까지 읽어주세요~  

# 기획자인 내가 개발을 하게 된 이유

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

# 과연 기획자도 개발을 할 수 있을까?

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

# 기획자의 생생한 개발 후기 (feat. 타입스크립트 저만 어렵나요?)

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

 외주사가 만나는 클라이언트

외주사를 운영하다보면 하루에도 정말 다양한 사업의 문의를 받게 됩니다.
매번 찾아주심에 감사함을 느끼는 한 편, 문의를 끝내고 나면 매번 다른 문의 전화임에도 불구하고 묘하게 같은 답변을 드리고 있는 듯한 느낌을 갖게 되는데요.
이제 막 창업을 시작하신 분들부터 이미 안정적인 사업을 꾸려가시는 분들까지 사업의 크기가 모두 다른 클라이언트임에도 외주 문의에 대한 내용에 차이가 있을거라는 예상과는 달리 왜 비슷한 느낌을 받게 되는 지 그 이유에 대해서 정리해보고자 합니다. (아울러 이 글이 현재 외주를 고민하고 계신 창업주 분들께 도움이 되었으면 좋겠습니다.)

 왜 개발 외주는 어려울까?

1.
커뮤니케이션이 힘들어요!
2.
채용 vs 외주?

 데브피플에서 제안하는 올바른 외주의 타이밍

1.
창업 초기, 빛나는 미래를 꿈꾸는 창업 스타터분들
2.
창업 중후반, 사업의 안정화는 물론 또다른 폭발적인 성장을 꿈꾸는 창업주 분들
개발 외주, 언제 이용하는게 좋을까?
안녕하세요. 스타트업코드의 대표자 void입니다. 스타트업코드로서 첫 글을 쓰게 되었습니다. 저와 저희 devpeople은 스타트업 대상으로 외주 및 개발 분야 멘토링을 영위하고 있습니다. 스타트업 대상으로 외주 및 멘토링을 하면서 느낀점은 대표님들께서 사업에 대한 계획은 디테일하게 생각하셨지만 개발과 관련한 계획은 많은 생각을 못하신다고 생각했습니다. 그래서 이제부터 개발에 대한 계획을 세우실 수 있도록 다양한 이야기를 해볼까 합니다.
첫 주제는 ‘스타트업에서 IT서비스를 개발하는 관점’입니다. 스타트업 서비스 개발을 대규모 서비스 개발과 비교하며 말해보도록 하겠습니다. 대규모서비스, 대기업에서의 개발과 스타트업 서비스 개발 차이는 무엇일까요? 저는 이 차이를 음식점 창업으로 비유를 들고 싶습니다.
처음부터 시장의 문제점을 한 번에 해결할 제품을 만들어내는 것은 거의 불가능에 가깝습니다.
대규모 서비스 개발과 스타트업 서비스 개발 차이는 무엇일까?
사업계획서와 커리큘럼 GPTs 를 만들어보면서 한 가지 생각을 하게 되었습니다.
사용자가 입력하는 질문 데이터와 그 질문에 대해 GPT가 생성하는 데이터를 수집해서 빅데이터를 만들게 되면 프롬프트 엔지니어링을 하는데 있어서 더 좋은 결과값을 만들 수 있지 않을까 라는 생각입니다.
사용자는 개개인마다 스타일이 있고 질문을 하는 방법과 어체 또한 다를 것입니다. 그리고 GPT는 요구에 따라서 답변이 달라지게 될 것입니다. 이 데이터를 종합해서 프롬프트를 답변이 잘 나오는 방향으로 튜닝할 수 있지 않을까라는 생각이 들어 방법을 구상해보았습니다.
처음 구상한 방법은
1.
사용자가 질문을 함
2.
GPT 가 답변을 생성함
3.
답변을 보여주기 전 구글 시트에 질문과 답변 내용을 저장
4.
답변을 보여줌
위와 같은 프로세스를 구상하였습니다. 그래서 자동화 툴을 찾아보던 중 Zapier 를 사용해야겠다는 결론을 내리고 바로 세팅을 하기 시작했습니다.
Zapier 를 사용하기 위해선 트리거와 액션이라는 개념을 알아야합니다.
트리거는 간단하게 설명하면 액션이 작동할 수 있도록 이벤트가 발생하는 조건을 설정하는 것이고, 액션은 트리거 조건이 부합하는 경우 작동할 내용을 설정하는 것입니다.
[GPTs, Zapier] GPTs 에 Zapier를 사용해서 자동화 하기
이번에는 교육 커리큘럼을 대신 만들어줄 수 있는 커스텀 GPT를 제작해보았습니다.
교육 컨텐츠를 만들 때 가장 먼저 신경쓰는 부분이 커리큘럼입니다. 제대로 된 커리큘럼이 만들어져야 해당 커리큘럼을 보고 컨텐츠를 만들 수 있기 때문입니다. 때문에 커리큘럼을 제작하는 데 있어 수많은 레퍼런스를 찾아봐야하고 시간을 많이 소비합니다.
이 시간을 짧게 소비해서 빠르게 컨텐츠를 제작할 수 있도록 커리큘럼의 방향, 초안을 작성해줄 수 있는 커스텀 GPT를 만들어 보았습니다.
사업계획서 GPT와 동일하게 템플릿은 ‘후카츠 프롬프트’를 사용해서 진행하였습니다.
가장 먼저 위와 같이 후카츠 프롬프트 템플릿을 세팅하였습니다. 커리큘럼을 짜기 위한 정보는 대부분 학습된 데이터와 웹 서칭 기능을 통해 가져올 수 있기 때문에 자세한 정보를 넣기보다는 가볍게 작성하였습니다.
위의 시스템 프롬프트를 사용했을 때 커리큘럼은 괜찮게 나오지만 난이도가 너무 높았습니다. 학습 데이터가 아무래도 기초보단 심화 내용이 많기 때문입니다. 그래서 제약조건을 추가 해주었습니다.
위의 제약조건을 추가하여 난이도는 조절하는데 성공 하였습니다. 하지만 한 가지 아쉬운 점이 있다면, 커리큘럼의 각각 섹션에 대한 세부내용까지 GPT가 작성해주는 것이 목표였습니다.
[GPTs] 커리큘럼 제작 모델 만들기
GPTs 를 사용해 커스텀 GPT를 만들 수 있습니다.
커스텀 GPT를 프롬프트 엔지니어링과 결합해서 사업계획서 작성 모델을 만들어보기로 하였습니다.
기본 템플릿은 ‘후카츠 프롬프트'를 기반으로 작성하였고, 상세 기법으로는 페르소나 부여 기법, 마크다운 활용 기법을 대체적으로 사용 하였습니다.
커스텀 GPT를 만들기 전 생각을 해보았습니다.
사업계획서를 만들기 위해선 회사의 정보, 사업 아이디어, 문서 형식이 필요할 것입니다.
회사의 정보와 사업 아이디어를 통해서 GPT가 글을 작성하고, 그 내용을 문서 형식에 맞춰서 가공해야하기 때문입니다. 그래서 기본적인 ‘후카츠 프롬프트’ 형식을 사용하였고, 아래와 같이 작성하였습니다.
역할은 우리 회사 대표님이신 void 로 지정해서 진행하였습니다. 이렇게 한뒤 회사 정보, 문서 형식, 요청 내용을 프롬프트로 작성해서 전송했는데 사업계획서에 작성하기에는 애매한 문장 구성으로 출력이 되는 것을 확인할 수 있었습니다. 대표적으로 사업계획서를 작성할 때에는 두괄식으로 작성해야하는데 모든 문장이 ~입니다. ~요. 라고 끝맺음을 하고 있었습니다. 그래서 제약조건과 정보 부분을 조금 수정해주었습니다.
[GPTs] 사업계획서 작성 모델 만들기
ChatGPT가 2022년 11월 등장하게 되면서 IT업계의 판도가 많이 바뀌고 있는 추세입니다. ChatGPT는 등장 이후로 엄청난 기술의 발전으로 주목받았고 GPT-4 까지 업데이트를 진행하면서 인공지능이라는 신기술을 일반인들도 보다 쉽게 쓸 수 있도록 만들어주고 있습니다.
ChatGPT가 등장하면서 여러가지 의견들의 나뉘고 있는 상황입니다. 인공지능을 경계해야한다는 입장과 인공지능을 더 발전시켜야한다는 입장입니다.
저는 인공지능을 경계해야할 지, 더 발전시켜야할 지에 대해서는 중립적인 입장입니다. 하지만 변하지 않는 생각 하나는, 이 기술을 무조건 배척해야할 것이 아니라 어떻게 사용해야 우리가 더 도움을 받을 수 있을지에 대한 생각입니다.
ChatGPT는 확률 예측형 ai 모델입니다. 우리가 직접 사용할 때는 마치 지능을 갖고 있는 GPT 모델이 정말 자의식을 갖고 우리와 대화하는 것처럼 보이기 때문에 인공지능이 무섭고 낯설다고 느껴질 수 있습니다. 하지만 GPT 모델의 동작원리를 보면 한 단어를 작성할 때마다 그 뒤에 올 단어를 쭉 나열한 뒤 가장 확률이 높은 단어를 출력하는 방식으로 문장을 완성합니다. 이 데이터는 학습된 데이터를 기준으로 진행되고요.
그렇기 때문에 자의식을 가진 인공지능을 제어할 수 없다는 생각은 아직까진 너무 멀리 바라보고 있는 것 같다는게 제 생각입니다.
카카오톡도 등장 당시에는 엄청난 혁명이라고 모두들 생각했습니다. 문자 메시지와 메일을 주로 쓰던 사람들에게 문자 메시지의 간편함과 메일의 무료라는 장점을 모두 합쳐놓은 서비스가 등장한 것이니까요. 하지만 지금 본다면 카카오톡이 엄청난 혁명까지는 아니라고 생각할 사람들이 많을 것입니다.
시대가 흐르면서 트렌드가 바뀌기 때문입니다. 이 생성AI가 과거의 카카오톡과 같은 위치라고 생각합니다. 지금은 사람들이 GPT에 대한 거부감이 있을 수 있지만, 이를 잘 활용한다면 우리의 삶이 더 편해질 것이라고 생각합니다.
1973년, 세계 최초로 휴머노이드 로봇이 등장 하였습니다. 일본의 ‘가토 이치로’ 라는 사람이 선보인 ‘와봇 1호’ 였습니다. 휴머노이드 로봇이 등장 했을 당시에도 여론은 2가지로 나눠졌습니다. 이 로봇을 잘 발전시켜서 인간이 편리해질 수 있게끔 발전시켜 사용하자는 여론과 휴머노이드 로봇이 발전되서 로봇과 인간의 전쟁이 일어날 수 있다는 여론이었습니다.
실제로 1970년 일본의 로봇 공학자 ‘모리 마사히로’의 논문 ‘불쾌함의 골짜기’를 본다면 그 당시에 휴머노이드 로봇의 인식이 어땠는지를 알 수 있습니다. 인간은 로봇이 ‘인간’의 모습과 비슷할 수록 호감도가 증가하지만 그 유사성이 일정 수치에 도달하게 되면 호감도가 반감되어 오히려 강한 불쾌감을 일으키게 된다는 연구 내용이다.
[GPTs] 생성AI 등장