4A1G를 알아야 하는 3가지 이유

  • 첫째, KPI를 달성하는 데 효과적인 전략이기 때문에: 시간이 지날수록 퍼포먼스 마케팅 효율이 떨어지는 상황에서도 4A1G를 알고 있으면 막혀있는 곳을 뚫어 목표 KPI를 달성할 방법을 찾을 수 있습니다.
     
  • 둘째, 스스로 마케팅 방향성을 잡을 수 있기 때문에: 사수가 없거나 경험이 적은 마케터라면 현재 상황에서 무엇을 해야 할지 막막할 텐데요. 이럴 때 4A1G를 알고 있으면 어떤 마케팅을 왜 해야 하는지 쉽게 파악할 수 있습니다.
     
  • 셋째, 나무가 아닌 숲을 볼 수 있기 때문에: 4A1G를 통해 전체 그림을 그릴 수 있게 되면 매출 상승에 효과적인 포인트를 알게 되고, 마케터로서의 내 가치를 올려줍니다.

실무에 최적화된 '4A1G 전략' 파헤치기

이번 챕터에서는 제가 '4A1G'라는 마케팅 전략을 만들게 된 배경에 대해서 설명해 드리려고 합니다. 우선 서비스를 성장시키는 마케팅은 어떤 흐름을 가졌는지 아래 맵을 보면서 살펴보죠.

 

반응형

결정 트리는 예/아니오로 답할 수 있는 어떤 질문들이 있고, 그 질문들의 답을 따라가면서 데이터를 분류하는 알고리즘입니다. 간단한 예시를 볼게요.

교통사고가 났을 때, 운전자의 생존 여부를 예측하고 싶다고 할게요. 결정 트리는 질문들과 답으로 이뤄졌다고 했잖아요?

그럼 여기 가장 위에는 “안전벨트를 했나요?” 이 질문이 있을 수 있습니다. 안전벨트를 했으면 여기 왼쪽으로 내려와서 생존, 안 했으면 오른쪽으로 내려가서 사망. 이런 식으로 분류하는 거죠. 질문에 해당하는 내용을 초록색, 그리고 분류에 해당하는 내용을 보라색으로 나타내겠습니다.

지금은 안전벨트를 했는지 안 했는지를 물어보는데요. 데이터가 주행 속도, 즉 특정 숫자 값이라면 주행 속도가 시속 100km를 넘었나요? 이런 질문도 할 수 있습니다. 이때도 똑같이 예측하려는 데이터에 대한 질문의 답에 따라 왼쪽 또는 오른쪽으로 가서 데이터를 분류할 수 있는 거죠.

지금 본 결정 트리는 진짜 엄청 기본적인 거고요. 사실 더 많은 질문들로 이뤄질 수 있습니다. 안전벨트를 했는지, 고속도로인지, 시속이 100km가 넘었는지, 사고자 나이 50을 넘었는지 등을 이용해서 결정 트리를 만들 수 있는 거죠.

질문들에 답을 해가면서 한 단계식 내려갈 수 있는데요. 보라색 박스들은 분류를 갖고 있다고 했잖아요? 위에서부터 질문들에 계속 답을 하다가 내려가면서 이 보라색 박스들에 도착을 하면, 해당 분류 값을 리턴하면 됩니다.

그리고 중요한 게 또 한 가지 있는데요. 한 속성을 딱 한 번만 사용해야 되는 건 아닙니다.

예를 들어서 한 번은 주행 속도가 100을 넘었는지 질문을 할 수 있고요. 밑에 내려가서는 60을 넘었는지 안 넘었는지, 이렇게 하나의 속성으로 여러 개의 질문을 만들 수도 있습니다.

질문들이 있고, 그 질문들에 대한 답들을 따라가면서 데이터를 분류하는 알고리즘. 엄청 직관적이죠?

컴퓨터 과학에서는 이렇게 한 지점에서 시작해서 점점 넓게 퍼져 나가는 걸 트리라고 하는데요. 나무는 뿌리에서 시작해서 여러 개의 가지로 뻗어나가잖아요? 이 알고리즘은

  1. 하나의 시작 지점에서 퍼져나가는 모습이 마치 나무와 비슷하고,
  2. 그리고 한 단계 내려갈 때마다 왼쪽으로 갈지 오른쪽으로 갈지 선택하는

알고리즘이기 때문에 이름이 결정 트리인 거죠.

이 하나하나에 있는 박스를 “노드”라고 합니다. 좀 데 구체적으로는 가장 위에 있는 이 제일 위에 있는 질문 노드를 나무의 뿌리라고 해서 root 노드, 트리의 가장 끝에 있는 이 노드들을 나무의 잎, leaf 노드라고 하는데요. leaf 노드는 항상 사망/생존과 같은 특정 예측값을 갖고 있고, 나머지 노드들은 예/아니오로 답할 수 있는 질문을 갖고 있습니다.

반응형

Git

Git이란?

코드 변경점 기록

버전 관리 도구(형상 관리 도구)

소프트웨어의 변경사항을 체계적으로 추적하고 통제하는 것

하나의 폴더 내에서 코드의 변경점을 기록하기 위해 git을 사용한다

에러 발생시 과거의 코드 기록으로 쉽게 되돌아가기 가능

 

Github

Github란?

백업과 공유가 가능한 온라인 코드 저장소

온라인 백업, 공유, 협업이 가능하다

 

리눅스 필수 명령어

pwd : 현재 내가 작업하는 폴더를 보여달라는 뜻

ls(list) : 내 폴더 안에 있는 폴더 & 파일 내역을 보여줌

ls -a(list all) : 숨겨진 파일도 볼 수 있음

cd 폴더명(change directory) : ls명령어에서 확인된 폴더로 이동 가능

  • cd.. : 한 단계 위의 폴더라는 뜻
  • 폴더명/폴더명 으로 한 번에 더 깊이 들어갈 수 있음

mkdir : 현재 경로에서 폴더를 생성하는 명령어(정확히는 파일의 생성과 파일의 날짜, 시간을 변경하는 명령어)

 

Git 필수 명령어

git init : initialize(초기화하다)의 준말, 프로젝트 시작 전 딱 한 번만 입력하면 됨, 정확한 프로젝트 경로에서 입력해야 함

git add & commit : 코드를 저장하는 명령어

  • git add : 저장하기 전 저장할 파일 지정
  • git commit : 실제로 저장하는 명령어

git status : 저장 여부 확인하는 명령어, 변경 상태 확인

내 프로젝트의 변경사항을 한 번에 지정하는 법

  1. git add.
  2. git commit-m "메세지"
  3. git status : 더 이상 저장할 것이 없음

git log : 저장 내역을 확인하는 명령어

git push : 추가로 수정된 코드를 github에 반영하는 명령어

git clone : github에서 코드를 복사해오는 명령어(git clone <github주소> . 입력

git pull : 다른 사람이 변경한 코드를 내 코드에도 가져오는 명령어

  • 코드 수정 후 git push origin 브랜치명(이때 브랜치명은 main으로 한다)
  • git pull을 먼저 하라는 에러 발생시 git pull origin 브랜치명 입력
반응형

.

필드 유형(Field Types)

아래는 모델을 정의할 때 데이터에 따라 사용할 수 있는 필드 유형으로 우리가 사용했던 필드들과 그외 타입이 비슷한 필드들의 목록입니다. 이 밖에도 다양한 형식의 필드가 있습니다. 아래의 공식문서를 참고하세요. 필드 유형 공식문서 바로 가기

필드명설명개별속성

CharField 최대 길이가 정해진 문자열 필드 max_length (최대 글자수)
TextField 최대 길이가 정해지지 않은 문자열 필드  
EmailField CharField와 같은 문자열 필드지만
입력된 형식이 이메일 형식 인지를 체크하는 필드
max_length=254 (기본값)
URLField CharField과 같은 문자열 필드지만
입력된 형식이 URL 형식 인지를 체크하는 필드
max_length=200 (기본값)
BooleanField True, False 값을 갖는 필드  
IntegerField 정수 형식의 필드  
FloatField 부동 소수점 형식의 필드  
DateField 날짜 형식의 필드 auto_now (수정 될 때 마다 새로운 값으로 갱신)
auto_now_add (생성 될 때 값이 입력 되고 추후 변경하지 않음)
TimeField 시간 형식의 필드 auto_now, auto_now_add
DateTimeField 날짜 시간 형식의 필드 auto_now, auto_now_add

필드 옵션(Field options)

모델 필드를 정의할 때 작성할 수 있는 몇 가지 옵션 항목 입니다. 모든 필드에 대해 적용할 수 있으며 반드시 필요한 것은 아니고 선택적으로 적용할 수 있습니다. 더 많은 필드 옵션이 궁금하다면 아래의 공식 문서를 참고하세요. 필드 옵션 공식문서 바로 가기

필드 옵션설명기본값

null True 일 경우 데이터베이스에 빈 값을 저장할 때
NULL을 사용하게 됩니다.
False
blank True 일 경우 해당 필드를 비워 둘 수 있게 합니다. False
default 필드에 기본값을 지정할 때 사용합니다.  
editable 필드의 수정 가능 여부를 설정합니다. True
help_text 해당 필드를 입력할 때 보여줄 도움말을 설정합니다.  
unique True 일 경우 중복된 값을 입력할 수 없게 합니다. False
verbose_name 사람이 인식하기 좋은 별명을 필드에 설정합니다.

   

 

반응형

 

'클라이언트'와 '서버'

일반적으로 IT 서비스는 클라이언트-서버 구조를 가지고 있다. 요청을 하는 쪽을 클라이언트, 요청에 맞춰 무엇인가를 제공하는 쪽을 서버라고 부른다. 클라이언트와 서버 모두 '프로그램'을 칭한다.

 클라이언트: 가장 쉬운 예로는 앱이 있다. 우리는 쇼핑몰 앱을 키고, 상품을 클릭하고, 댓글을 남기는 등의 활동을 한다. 우리의 활동에 맞춰 클라이언트는 서버에 '홈 화면 불러와줘', '상품 페이지 열어줘', '댓글 표시해줘'라는 '요청'을 서버에 한다. 정리하면, '서버에 화면, 정보 등을 요청하고 응답을 받아 사용자에게 보여주는 역할'을 맡는다. 요청이 '시작'되는 곳이라고 하여 '프론트 엔드'라고도 부른다.

 서버: 서버는 클라이언트의 요청에 응답하는 프로그램이다. 서비스를 제공하기 위한 정보를 가지고 있다가 클라이언트의 요청에 맞춰 제공한다. 홈 화면 정보를 갖고 있다가 요청이 들어오면 제공하고, 상품 페이지 정보를 갖고 있다가 또 제공하는 것이다. 요청을 '마지막'으로 처리하는 곳이라고 하여 '백 엔드'라고도 부른다.

운영 체제

컴퓨터에 프로그램을 설치할 때 '맥용', '윈도우용'이라고 뜨는 것을 본 적이 있을 것이다. 왜 같은 프로그램인데 맥용과 윈도우용으로 나뉠까? 운영 체제가 다르기 때문이다. 비유하자면 운영 체제는 모국어 같은 거다. 맥 나라는 Mac OS 언어를 쓰고, 마이크로소프트 나라는 윈도우 언어를 쓰는 것이다.

응용 프로그램(Application)

쉽게 말하면 컴퓨터에 까는 프로그램과 스마트폰에 다운받는 앱이다. 즉 운영 체제에서 실행되는 소프트웨어를 의미한다. 위에서 맥과 윈도우가 쓰는 언어(운영 체제)가 다르다고 했다. 때문에 개발자는 각 운영 체제에 맞는 개발 언어를 이용해 응용 프로그램을 개발해야 한다.

웹 브라우저

인터넷 익스플로러, 크롬, 사파리 등이 웹 브라우저다. 인터넷 콘텐츠를 조회할 수 있는 응용 프로그램이라고 정리할 수 있다. 표준으로 정해진 HTML이란 언어로 작성되어 있으면 운영 체제에 상관 없이 모든 브라우저에서 화면을 띄울 수 있다. HTML외에 웹 페이지 개발 언어로는 디자인을 입히는 'CSS', 동적인 효과(마우스나 스크롤 움직임에 반응)를 입히는 'JavaScript'가 있다. 

네이티브 앱

응용 프로그램과 웹 브라우저의 개념이 이해되었다면, 이제 '네이티브 앱'과 '웹 앱'을 구분할 수 있다. 네이티브 앱은 스마트폰의 운영 체제에 맞춰 개발된 프로그램이다. 네이티브 앱을 개발하려면 각 운영 체제에서 사용하는 언어를 이용해 코딩을 해야 한다. 한마디로 '착붙'인 앱을 개발하는 거다.

 

 단점: 이렇게 개발한 앱을 플레이 스토어나 앱 스토어에 올려 심사를 받고 통과해야만 앱이 등록되기 때문에(업데이트 할 때도 마찬가지) 다소 번거롭다.

 장점: 카메라, 지문인식, 연락처 조회 등 스마트폰의 기본 기능들을 활용할 수 있고, 각 운영 체제에 최적화됐기 때문에 안정적으로 서비스를 제공할 수 있다. 

웹 앱

퍼블리는 모바일 앱으로 이용할 수도 있지만, 웹 브라우저에서 'www.publy.co'에 접속해도 이용할 수 있다. 이렇게 주소만 있으면 모바일에서 웹 브라우저를 통해 이용할 수 있는 게 웹 앱이다.

 

 단점: 네이티브 앱과는 달리 카메라 등 스마트폰의 기본 기능을 활용할 수 없다. 하지만 최근에는 웹 기술이 발전해 앱 처럼 사용할 수 있는 기능이 많아졌다. 카메라 접근이나 오프라인 작업 등도 가능하게 된 것이다.

 장점: 다운로드 없이도 이용 가능하고, 웹 페이지라 언제든 쉽게 수정할 수 있다. '홈 화면에 바로가기 추가'를 하면 마치 앱을 깐 것 처럼 홈 화면에 앱 아이콘을 추가할 수도 있다.

하이브리드 앱

네이티브 앱과 웹 앱이 섞인 형태다. 네이티브 앱의 안정성과 웹 앱의 편리한 수정・관리라는 장점을 모두 갖고 있다. 일반적으로 앱의 기본 틀은 네이티브 앱으로 만들되, 특정 영역은 브라우저를 띄워 화면을 보여준다.

 

 네이티브 앱 영역: 수정할 때마다 심사를 받아야 하고, 사용자가 앱 업데이트를 해야만 수정 사항이 적용되기 때문에, 자주 바뀌지 않는 영역을 네이티브 영역으로 개발한다.

 웹 앱 영역: HTML 코드만 수정하면 모든 사용자에게 수정된 페이지를 보여줄 수 있다. 그래서 자주 바꿔야 하는 페이지를 웹 영역으로 개발한다.

 

하이브리드 앱은 좋아 보이는 만큼 안드로이드 개발자, iOS 개발자, 웹 개발자까지 필요하기 때문에 내부 리소스와 비용 등이 많이 든다.

웹 서버-웹 어플리케이션 서버-데이터베이스(DB)

서버가 요청을 처리하는 3단계다. 1) 클라이언트의 요청 사항을 해석 2) 필요한 데이터와 해야 하는 일을 체크 3) 데이터가 저장된 곳에 접근해 필요한 데이터를 찾아온다.

 웹 서버: 클라이언트의 요청을 가장 먼저 받는 곳. 요청이 다음 단계로 넘어갈 수 있도록 번역하고, 반대로 요청을 완료해 클라이언트에 제공할 때도 클라이언트 언어에 맞춰 번역해 제공한다.

 웹 어플리케이션 서버: 웹 서버가 번역한 내용에 맞춰 요청을 처리하기 위한 프로그램을 돌린다. 데이터베이스에서 데이터를 받아 요청을 처리하고 웹 서버에 제공한다.

 데이터베이스: 서버에 저장된 데이터의 모음. 웹 어플리케이션 서버로 활용하는 컴퓨터의 저장 공간을 활용할 수도 있고, 처리 성능과 보안 유지를 위해 별도로 분리하기도 한다.

CRUD

데이터를 처리하는 방식으로, 생성하기(Create), 읽기(Read), 수정하기(Update), 삭제하기(Delete)의 앞 글자를 딴 말이다. 데이터는 무조건 이 네 가지 방법으로 처리된다. 어떤 경우에 어떤 데이터를 생성・읽기・수정・삭제할 것인지 구체적으로 기획해야 한다.

 

이를 바탕으로 백 엔드 개발자는 데이터베이스 구조를 설계하고 데이터를 처리하기 위한 로직을 개발한다. 그래서 사용자가 회원가입이나 주문 등을 하면 조건에 따라 클라이언트는 서버에 데이터를 생성・읽기・수정・삭제하기를 요청하고, 서버는 요청에 맞춰 데이터를 처리한다.

관계형 데이터베이스(Relational Database, RDB)

쇼핑몰의 관계형 데이터베이스를 가정해 보자. 모든 회원에게 숫자를 부여하고(마치 대학교 학번처럼), 상품에도 고유한 상품 번호를 부여한다. 이 숫자를 이용해 '누가' '무엇을' 샀는지 표시할 수 있게 된다. 이때 '숫자'를 'Key'라고 한다.

 

정리하면 Key라는 고유 식별자를 부여해 데이터를 보관하고, Key를 활용해 데이터를 연결하여 보관하는 방식을 말한다. 관계형 데이터베이스를 활용하면 가볍게 데이터를 저장하고, 빠르게 데이터를 불러올 수 있다.

'캐시'와 '쿠키'

데이터는 주로 서버 DB에 저장하지만, 경우에 따라 클라이언트 쪽에 저장하기도 한다. 종종 들어본 '캐시', '쿠키' 등이 여기에 해당한다. 인터넷이 끊겨도 유지되어야 하는 정보거나, 사용자 편의를 위해 유지되어야 하는 설정일 때 클라이언트 쪽에 저장한다.

 캐시: 브라우저에* 데이터를 복사해 놓는 임시 장소를 의미한다. 브라우저를 종료하면 데이터도 같이 사라진다. 일반적으로 오디오나 이미지 파일을 미리 복사해 트래픽을 줄이고 로딩을 빠르게 하는 데 쓰인다. 같은 페이지를 두 번째 방문했을 때 그 전보다 빠르게 로딩되는 경우가 바로 캐시에 파일이 저장 되었기 때문이다.

* 캐시는 클라이언트 스토리지에 저장돼 있을 수도 있고, 서버나 CPU 등에 있을 수도 있다. 여기에선 이해하기 쉽게 웹 브라우저의 캐시로 설명했다.


 쿠키: 특정 서버에서 브라우저에 저장한 특정 데이터를 의미한다. 캐시와 다른 점은, 쿠키는 만료기한을 정할 수 있어 브라우저가 꺼져도 만료기한 전에는 데이터가 사라지지 않는다. 주로 사용자의 인증 정보 또는 변경된 옵션값을 저장하는데 사용된다. 예를 들면 자동 로그인, '오늘 하루 그만 보기' 팝업 설정 저장에 활용된다.

앱의 '클라이언트 스토리지'

스마트폰의 앱도 서버 DB가 아닌 클라이언트 쪽에 데이터를 저장하는 경우가 있다. 앱을 다운받으면 스마트폰 저장 공간에 앱 폴더가 생성되며 실행을 위한 파일들이 설치된다. 앱은 이 공간을 활용해 자동 로그인을 위한 인증 정보, 장바구니 정보 등을 저장한다.

 

카카오톡을 사용할 수록 앱 용량이 커지는 이유가 각종 대화 내역, 파일 등이 일정 기간 동안 이 공간에 저장되기 때문이다. 클라이언트 스토리지를 활용하면 서버의 부하를 낮추거나 사용자의 경험을 더 좋게 만들 수 있다.

API

'애플리케이션 프로그래밍 인터페이스(Application Programing Interface)'의 약자. 프로그램과 프로그램이 서로 데이터를 주고 받기 위해 사전에 정한 요청・응답 방식을 말한다. 프로그램끼리 서로 일하는 방법을 약속한 거라고 보면 된다.

 

예컨대 '클라이언트에서 서버에 회원 가입을 요청할 때는 이름, 아이디, 비밀번호, 핸드폰 번호를 기입해야 한다. 그럼 서버가 회원 정보에 저장하고 로그인 완료 페이지를 전달하겠다.' 같은 약속이다.

'에러 코드'와 '성공 코드'

프로그램끼리 주고 받는 언어라고 할 수 있다. 대표적으로 웹에서 사용하는 'http'에서는 숫자 3자리로 표현한다. 개발자들은 이 코드를 보고 요청을 잘 처리했는지 아니면 문제가 발생했는지를 체크한다. 첫 번째 자리 숫자에 따라 결과의 종류를 구분할 수 있다.

 5xx: 서버에서 요청을 처리할 수 없음을 알리는 경고. 서버에 오류가 생겼거나 서버에서 응답이 너무 늦는 경우에 나타난다. 이 코드가 나오면 빠르게 서버 개발자에게 코드와 함께 상황을 알려야 한다.

 4xx: 클라이언트의 요청이 잘못됨을 알리는 경고. 마지막 두 자리 숫자에 따라 클라이언트의 요청 중 어디가 잘못되었는지 알 수 있다. 우리에게 익숙한 404 에러는 클라이언트가 서버에 존재하지 않는 페이지를 요청하거나, 이미 삭제된 페이지를 요청하는 경우 나타난다.

이 외에 100~300번대 코드는 성공 코드로, 서버가 요청을 잘 처리 했을 때 남긴다.

클라우드 컴퓨팅

컴퓨터를 쓰려면 여러 가지가 필요하다. 소프트웨어, 운영체제, CPU, 메모리 등등. 이걸 우리 집에 다 설치하지 않고, 인터넷을 통해 다른 곳에 있는 컴퓨터에 접속하는 것을 클라우드 컴퓨팅이라고 한다. 개발자들은 주로 서버를 구축할 때 클라우드 컴퓨팅을 활용한다.

 

클라우드 컴퓨팅을 제공하는 대표적인 업체로는 AWS(Amazon Web Service)가 있다. AWS에서 필요한 기능을 고르고 이용 기간에 따라 비용을 내면 IT 자원을 원격으로 이용할 수 있다. 사용하는 디스크 스토리지나 응용 프로그램 등을 내가 관리하지 않아도 돼 편리하고, 사용할 때만 돈을 내면 되니 비용도 줄일 수 있다.

백 오피스

백 오피스와 백 엔드를 많이들 헷갈려 하지만, 이 둘은 다른 개념이다. 백 오피스는 관리자가 상품 정보나 결제 내역 등을 관리하는 페이지를 의미한다. 백 오피스도 사용자(회사 직원들)가 있는 하나의 프로그램, 즉 클라이언트다. 서버를 의미하는 백 엔드와는 다르다. 서비스 복잡도에 따라 여려 개의 백오피스를 두기도 한다.

반응형 디자인

다양한 화면 사이즈에 맞춰 화면의 레이아웃이 반응하는 웹 디자인을 의미한다. 반응형 디자인이 적용된 페이지는 하나의 url 주소를 가지지만, PC, 태블릿, 스마트폰 등 화면 사이즈가 각기 다른 디바이스로 보았을 때 페이지의 레이아웃이 각 사이즈에 맞춰 변한다.

퍼블리싱

디자이너는 웹 페이지를 이미지 형태로 디자인한다. 이게 웹 브라우저 화면에서 보여지려면 HTML이나 CSS, Javascript 코딩 언어를 활용해 웹 페이지화 해야 한다. 이를 퍼블리싱이라고 한다. 퍼블리싱은 프론트 엔드 개발의 일부이고, 웹 퍼블리싱에 특화된 개발자를 '퍼블리셔'라고 부른다.

반응형
  • 수치형(numerical) 데이터: 나이, 몸무게, 키
  • 범주형(categorical) 데이터: 혈액형, 성별

많은 머신 러닝 알고리즘은 인풋 데이터, 즉 입력 변수의 값이 수치형 데이터여야 합니다. 저희가 배운 선형 회귀도 손실 함수를 구하고, 경사 하강법을 적용하려면 인풋 데이터가 수치형 데이터여야겠죠? 그럼 범주형 데이터가 있을 때는 어떻게 해야 할까요?

범주형 데이터를 수치형 데이터로 바꿔 주면 됩니다. 어떻게 바꿔 주는 게 좋을까요? 가장 먼저 떠오르는 방법은 1, 2, 3… 과 같은 자연수를 각 카테고리에 지정해 주는 건데요, 예를 들어 A형은 1, AB형은 2, B형은 3, O형은 4. 이런 식으로 데이터를 변환하는 거죠. 이제 혈액형은 숫자 값을 가지게 되니까 입력 변수로 쓸 수 있겠죠?

하지만 이렇게 데이터를 바꿔 주면 혈액형에 크고 작다는 개념이 생깁니다. 예를 들어 ‘A형은 1이니까 가장 작고, O형은 4니까 가장 크고, AB형, B형은 그 사이다’라는 관계가 생기는 거죠. 머신 러닝 알고리즘은 이런 엉뚱한 관계도 학습하기 때문에 오히려 예측에 방해가 될 수 있습니다.

그래서 범주형 데이터를 수치형 데이터로 바꿀 때는 이 방법을 사용하지 않고, One-hot encoding이라는 방법을 사용합니다.

One-hot encoding은 각 카테고리를 하나의 새로운 열로 만들어 주는 방법입니다. 예를 들어 혈액형이라는 열에는 A형, AB형, B형, O형 네 카테고리가 있으니까 이걸 4개의 새로운 열로 만들어 주는 방법입니다.

그다음엔 주어진 데이터가 어떤 혈액형인지에 따라 새로운 열들의 값을 0 또는 1로 채워 줍니다. 처음 데이터 행은 B형이니까 B형 열을 1로, 그리고 나머지 열을 0으로 설정해 주고, 다음 데이터 행은 O형이니까 O형 열을 1로, 나머지 열을 0으로 설정해 주는 거죠. 이제 이 열들은 0과 1, 두 값만 가지기 때문에 범주형 데이터에게 크고 작은 관계가 생기는 것을 막을 수 있는 겁니다.

결론적으로 one-hot encoding을 하면 범주형 데이터에게 크고 작음의 엉뚱한 관계가 생기는 걸 방지하면서도 수치형 데이터로 바꿔 줄 수 있는 거죠.

반응형

템플릿 변수 (Template Variable)

{{ variable }}

템플릿 변수는 템플릿이 렌더될 때 해당 변수가 의미하는 값으로 변환됩니다. 뷰(View)에서 가공한 데이터를 템플릿으로 넘겨주면 템플릿에서는 템플릿 변수를 사용해 넘겨받은 데이터에 접근할 수 있습니다.

템플릿 변수의 점(.) 연산자

템플릿 변수는 점(.)을 사용해서 변수 안쪽 속성에 접근할 수 있습니다.

user = {"name" : "우재", "coffee" : True}

예를 들어 위와 같은 user 변수가 있다면, user.name으로 "우재"라는 안쪽 값에 접근 할 수 있다는 거죠. 이와 같은 점(.) 연산자는 다음과 같은 순서로 변수의 안쪽 속성에 접근을 시도합니다.

  1. 변수를 사전형(dict)으로 생각하고 점(.) 연산자로 Key값 조회
  2. 변수를 객체로 생각하고 내부 속성값 조회 또는 함수 호출
  3. 변수를 리스트(list)로 생각하고 점(.) 연산자로 Index 조회

Django에서 템플릿의 점 연산자를 만나면 자동으로 위의 경우대로 순서대로 처리하며 알맞은 값으로 변환되지만 내가 접근 하려는 템플릿 변수가 어떤 자료형인지 알고 점(.)연산자를 사용해야지만 예기치 못한 에러를 방지 할 수 있습니다.

템플릿 필터 (Template Filter)

{{ variable|filter }}

템플릿 변수에 파이프(|)를 쓰고 템플릿 필터를 사용하면 템플릿 변수를 특정 형식으로 변환 할 수 있습니다.

{{ variable|filter:args }}

일부 필터는 필터 뒤에 인자를 필요로 합니다. Django는 약 60개의 내장 템플릿 필터를 제공하며 개발자가 직접 필터를 정의해서 사용하는 것도 가능합니다. 아래는 몇 가지 내장 템플릿 필터입니다.

default

참조하는 템플릿 변수가 비어 있거나 불린형 False일 경우 변환되는 값을 지정합니다.

{{ variable|default:"coffee" }}

변수가 비어 있거나 False면 coffee 라는 텍스트로 대체 됩니다.

capfirst

맨 첫글자를 대문자로 바꿔 줍니다.

{{ variable|capfirst }}

random

반복 가능한 템플릿 변수에 대해 무작위로 하나를 추출해 변환합니다.

{{ variable|random }}

만약 variable이 참조하는 값이 [ "a", "b", "c", "d" ] 인 리스트형이라면 템플릿 변수가 리스트 내의 하나의 원소로 대체 됩니다.

upper & lower

템플릿 변수를 대문자(upper) 또는 소문자 (lower)로 변환합니다.

{{ variable | upper }} , {{ variable | lower }}

ljust & rjust

주어진 길이 내에서 공백을 넣어 왼쪽 정렬(ljust) 또는 오른쪽 정렬(rjust)을 한 문자열로 변환합니다.

{{ variable|ljust:"length" }}, {{ variable|rjust:"length" }}

variable이 "codeit" 일 때 {{ variable|ljust:"10" }} 이라면 "codeit "이 됩니다. 공백을 표시해서 보면 "codeit_ _ _ _"이런 형태인거죠.마찬가지로 만약 {{ variable|rjust:"10" }} 이라면 " codeit"이 되겠죠?

이 밖에도 몇 가지 필터가 더 있는데 모두 외울 필요는 당연히 없고 필요할 때 찾아서 사용하면 됩니다. 더 많은 템플릿 필터에 대한 정보는 아래 Django 공식 문서를 참고하세요. https://docs.djangoproject.com/en/2.2/ref/templates/builtins/#ref-templates-builtins-filters

템플릿 태그 (Template Tag)

{% tag %}

템플릿 태그는 템플릿을 작성할 때 반복문, 조건문 등의 로직을 사용해서 마치 프로그래밍을 하듯 템플릿을 작성할 수 있게 해줍니다. Django가 기본적으로 제공하는 태그가 있지만, 개발자가 직접 태그를 정의해서 사용할 수도 있습니다.

{% tag %} ~ {% endtag %}

태그의 형태는 단독으로 사용하는 템플릿 태그와 여는 태그와 닫는 태그가 필요한 템플릿 태그가 있습니다. 아래는 몇 가지 기본 템플릿 태그입니다.

for

{% for obj in values %} ~ {% endfor %}

반복 가능한 객체를 반복하며 템플릿을 작성 할 수 있습니다. 아래처럼 말이죠.

{% for food in foods %}
    <li> {{ food.name }} </li>
{% endfor %}

만약 목록을 역순으로 반복하고 싶다면 아래와 같이 사용 할 수 있습니다.

{% for food in foods reversed %}
    <li> {{ food.name }} </li>
{% endfor %}

반복 가능한 객체가 비어 있거나 존재하지 않을 때는 아래와 같이 사용 할 수 있습니다. 아래는 만약 foods라는 객체가 비어있다면 {% empty %} 구문이 실행됩니다.

{% for food in foods %}
    <li> {{ food.name }} </li>
{% empty %}
    <li> There is no food. </li>
{% endfor %}

if

{% if value1 %} ~ {% elif value2 %} ~ {% else %} ~ {% endif %}

파이썬에서 사용하던 조건문과 형태가 비슷하죠? 실제로 사용 할 때도 우리가 아는 조건문의 형태로 사용하면 됩니다.

{% if hungry %}
    <p> Let's eat! </p>
{% elif sleepy %}
        <p> You need some coffee. </p>
{% else %}
    <p> Go back to work. </p>
{% endif %}

with

{% with value1=value2 %} ~ {% endwith %}

복잡한 변수가 있을 때 '별명'을 붙이기 위해 사용합니다. with 구문 내에서는 value1을 value2 대신 사용할 수 있습니다.

이 밖에도 몇 가지 템플릿 태그가 더 있는데, 필터와 마찬가지로 필요할 때 찾아서 사용하면 됩니다. 템플릿 태그에 대한 더 많은 정보는 아래 Django 공식 문서를 참고하세요. https://docs.djangoproject.com/en/2.2/ref/templates/builtins/#ref-templates-builtins-tags

사용자 정의 필터와 태그

. https://docs.djangoproject.com/en/2.2/howto/custom-template-tags/

반응형

'개발자알면좋은 내용들' 카테고리의 다른 글

트리용어  (4) 2024.03.15
  • 최신 정보 습득: 프로그래밍 분야는 매우 빠르게 변화하기 때문에, 최신 기술 트렌드를 따라가기 위해서는 영어로 된 자료를 직접 읽고 이해해야 합니다.
  • 문제 해결: 코딩 과정에서 발생하는 에러 메시지나 해결 방법은 대부분 영어로 제공됩니다.
  • 커뮤니케이션: 해외 개발자들과 소통하거나 오픈 소스 프로젝트에 참여하려면 영어 능력이 필수적입니다.
  • 더 나은 코드 작성: 프로그래밍 관련 자료와 커뮤니티에서 영어로 작성된 코드를 읽고 분석하면서 더 나은 코드 작성 능력을 키울 수 있습니다.

프로그래머가 기르면 좋은 영어 능력

  • 빠르고 정확한 독해: 프로그래밍 관련 문서, 코드, 커뮤니티 게시글 등을 빠르게 읽고 이해할 수 있는 능력.
  • 기술 용어 이해: 프로그래밍 관련 용어와 개념을 정확하게 이해할 수 있는 능력.
  • 기본적인 영문법: 영문법을 어느 정도 이해하고 있어야 합니다.
  • 간단한 영문 작성: 코드에 대한 주석이나 간단한 문서를 영어로 작성할 수 있는 능력.

프로그래머를 위한 영어 학습 방법

  • 프로그래밍 관련 영어 자료 활용: 프로그래밍 관련 책, 문서, 코드, 커뮤니티 게시글 등을 읽고 공부합니다.
  • 영어로 코딩: 해설이 있는 영어 코딩 강좌를 수강하거나, 개인 프로젝트를 진행하면서 영어로 코딩합니다.
  • 해외 개발자들과 소통: 온라인 커뮤니티나 SNS를 통해 해외 개발자들과 소통하며 영어 실력을 향상시킵니다.
  • 영어 학습 앱 활용: 영어 학습 앱을 활용하여 기본적인 영어 단어와 문장을 익힙니다
반응형

+ Recent posts