티스토리 뷰

Log/.TIL

[TIL]180423-0429

가그린민트 2018. 4. 30. 09:05

4 / 23 (월) ~ 29 (일)

1. 독서

"우리가 가끔 습관화되다시피 한 맥빠지는 냉소주의에서 벗어나고 싶기 때문이 아닐까?"

다양한 프레임으로 읽힐 수 있다는건 아마 좋은 책이라는 의미겠지. 이전의 나는 무엇을 보았을까

어둑한 초침의 그늘을 삶의 광학으로 바라보는 시점에 이르러 곧 이것은 허상, 포장 전 위선임을 깨닫는다. 

2. 공연

실험적인 곡들은 신선했지만, 바흐 파르티타 제 2번 샤콘느는 전혀 처음 듣는 느낌이었다. 오랫만에 찾아서 듣다보니 연조용 악보가 50본이 넘고 특히 아르페지오 부분에 대한 해석의 차이가 크다는 글을 읽었다. 요새의 아티스트들은 표현력에도 좋아서 시각적 감수성도 충만하고.. 더블베이스 연주가 여러모로 좋았던 시간

3. 운동

자전거를 타기 시작했고(소래 생태습지공원 - 인천대공원), 차주부턴 주말 수영도 다닐 계획이다. 무언가를 배우고 싶지만 직장 근처는 넘흐 비싸다. 근력도 키워야하고.. 

4. 리팩토링

Legacy 코드를 읽을 때 Test 작성 후 Coverage를 높여가는 작업을 하다보면 기능도 이해되고 리팩토링도 자연히 진행된다. 최근 IDE를 활용하여 리팩토링하는 경험을 하고 있고, 테스트코드 작성이나 필드/메소드명 등을 좀 더 신경쓰고 있다. 그리고 (높은)Cohesion, (낮은)Coupling에 대한 관점으로 '메소드가 클래스의 필드를 몇개나 쓰고 있나'에 초점을 두고 있다. 단단한 테스트 코드는 어떻게 작성하여야 할지, 요구사항의 추상화 수준이 코드와 동일하게 이루어지려면 어떠해야 할지 고민하는 요즘이다. 

그리고 성능 최적화를 위한 분석용으로 주로 사용하는 프로파일러가 무엇이 있을지, 페어프로그래밍은 업무에 어떤 단계로 적용하는 것이 좋으며 효율성/성과측정 등의 이슈와 관련하여 어떻게 설득해나가야 할지에 대한 궁금증이 여전히 남아있다.

2장 리팩토링 개론을 간략히 정리해보면,

리팩토링은 무엇인가

겉으로 드러나는 기능은 그대로 둔 채, 알아보기 쉽고 수정하기 간편하게 소프트웨어 내부를 수정하는 작업
1) 리팩토링은 소프트웨어를 더 이해하기 쉽고 수정하기 쉽게 만드는 것이다.
2) 리팩토링은 겉으로 드러나는 소프트웨어 기능에 영향을 주지 않는다.
소프트웨어 개발에 리팩토링을 적용할 때 기능 추가와 리팩토링이라는 별개의 두 작업에 시간을 분배하는데, 각 작업의 일관성을 유지해야 한다.
(켄트백은 이를 모자 두 개에 비유)

리팩토링은 왜 해야 하나

1) 소프트웨어 설계가 개선되고(중복 코드를 없애므로), 2) 소프트웨어를 이해하기가 더 쉬워지며, 3) 버그를 찾기가 쉬워지고, 4) 소프트웨어 개발 속도를 높여준다.

리팩토링 관련 문제들

1. DB
- 애플리케이션은 보통 데이터베이스 스키마와 강력히 결합되어 있으며, 스키마 수정시 데이터 이전도 이루어져야 하는데, 시간이 오래걸릴 뿐만 아니라 위험성이 높다.
- 이 경우 객체 모델과 데이터베이스 모델 사이에 별도의 Layer를 두는 방법으로 해결 할 수 있다. 
2. 인터페이스 변경
- 기존 인터페이스가 새 인터페이스를 호출하게 하여 해결할 수 있으며, deprecation 타입을 작성하여 알려야 한다. 
또한 인터페이스는 함부로 published 타입으로 만들지 말자.

리팩토링과 설계

리팩토링을 실시하더라도, 여전히 사전 설계는 해야 하지만, 사전 설계 과정에서는 완벽한 솔루션을 찾을 필요 없이 적당한 솔루션만 생각하면 된다.
작업의 중점이 리팩토링으로 이동함에 따른 장점은 설계가 단순해진다는 점이다.(처음부터 모든 부분을 유연하게 만들려고 하면, 시스템이 훨씬 복잡해진다.)

리팩토링과 성능

개발자가 성능 최적화 전까지는 성능에 신경쓰지 않고 프로그램을 잘 쪼개진 방식으로 제작하면, 이 후 최적화 단계에서 더 정밀한 분석을 하고 집중할 수 있다. 

3장의 내용은 책 전반의 내용을 참조하고 있어 1회독하고 다시 읽어야 이해할 수 있지않을까한다. 


일단 기억에 남는 부분을 간단히 추려보자.(어차피 상세히 정리해봐야 실제 코딩할 땐 1도 기억안날듯 싶다.)

Duplicated Code, Long Method는 주로 Extract Method로, Large Class는 Extract Class로 해결 가능하며, Long Parameter List(과다한 매개변수)의 경우 매개변수 세트를 객체로 전환하면 된다. Divergent Change(수정의 산발)은 한 클래스에 여러 수정이 발생하는 문제이고, Shotgun Surgery(기능의 산재)는 하나의 수정으로 여러 클래스가 바뀌게 되는 문제이다. 수정의 산발의 경우 Extract Class로, 기능의 산재의 경우 Move Method 등으로 해결하자.

객체의 핵심은 데이터와 그 데이터에 사용되는 프로세스를 한 데 묶는 것인데, Feature Envy(잘못된 소속)의 경우 Move Nethod를 사용해서 더 자주 접근하는 클래스로 옮겨야 한다.(낮은 의존성, 강한 응집도를 고려하여 리팩토링하도록 하자)

Data Clumps의 경우 Extract Class 기법을 적용하면 되는데, Feature Envy 및 Shotgun Surgery 등을 함께 고민하자

Primitive Obesession을 어느 수준까지 할 것인가에 대한 고민이 여전히 든다.

Switch Statements은 다형성(재정의)를 이용하여 해결할 수 있다.

리팩토링하다 불필요하게 된 클래스(Lazy Class)는 제거하여야 하며, Speculaive Generality(막연한 범용코드)를 작성하지 말자.

Temporary Field는 클래스로 빼도록하고, Middle Man(과잉 중개 메서드)는 메서드에 내용을 직접 삽입하도록 하고, Inappropriate Intimacy(지나친 관여)가 있을 경우 클래스를 분리하도록 하자.

Comments(불필요한 주석) 주석을 넣어야겠다는 생각이 들 땐 먼저 코드를 리팩토링해서 주석을 없앨 수 있게 만들어보자. 그 외에 Parallel Inheritance Hierarchies, Alternative Classes with Different Interface, Incomplete Library  Class, Data Class, Refused Bequest 등의 구린내가 있으며, Message Chains의 경우 해결방법은 추후에 다시 봐야 할듯 싶다.

5. Case Study

내부 스터디라기엔 기대보다 수준이 높았고, 매달 진행된다는 부분과 현재 우리 팀의 호흡을 비교해보면 여러 생각이 들게된다. 중복해서 강조된 부분은 '광고가 아닌 마케팅'이다. 광고를 대행한다고 정명되면 '나도 할 수 있는데 맡기는게 효율적인, 혹은 내가 하기 싫은 일을 다른 사람에게 맡기는 유형의 서비스'로 전락한다는 데에 대한 거부감이 내재된 인상이었다. 결국 고용주가 원하는 것은 매출 혹은 자신들의 미래이므로, 그에 대한 컨설팅을 하자는 것이었고, 그에 대한 경험치가 지금껏 꽤 쌓인 인상이었다. 다소 내부 정보가 많아 여기에 많은걸 풀어내긴 한계가 있기에 기억에 남는 부분과 알게된 지식만 기록해둬야겠다.


문제 발견 -> 행동분석 (-> 문제 정의 및 가설설정 -> 개선안 제작 ->  테스트 및 검증) :반복

문제발견 : 검색까지 해서 들어왔는데 왜 103명도 계산하지 않음?
행동분석 : 정성적 분석(직관에 기인한 아이디어) + 정량적 분석(데이터에 기인) :가설과 검증관계 -> 인사이트 도출
// 정성적 : 메인 카피의 가독성과 시인성 부족 , 입력필드의 주목성과 명시성 부족
// 정량적 : 유입 후 보험료 계산까지 체류시간이 짧음, DB필드 재 입력 세션 비중이 높음
           정보탐색을 위한 클릭 多, 도달률이 낮은 최하단 버튼영역 클릭 多

가설설정 : 최초 노출영역의 텍스트 및 컨텐츠 양 조절 -> 전달력 강화
          DB 사용성 개선을 위해 항목을 줄임

Google Opimize 로 A/B Test, Redirection Test 진행

Growth Hacking : 계획적인 페이지 기획 -> 정확한 검증 -> 기획의 고도화 & 성장
관심(인지) - 고려 - 구매 - 재구매(충성화)
ex) 운동화에 관심이 있는 - 필요한 - 나이키운동화를 사려는 - 매니아
Google Analytics in Real Life - landing page optimization
// 구매에 관심이 없는 유저에게 구매 강요 -> 피로감 증대
// 모든 단계의 유저들은 소중
// 각 단계의 유저들에는 접근법이 모두 다르다 -> 하지만 여기에 대한 대응 방안, 적용 사례 및 데이터가 없다는 지적이 있었다.
마케팅(엑셀레이터) : 어떻게 끌어올지 
        | See, Think 단계로 타겟 유저군을 확장하자

컨텐츠(엔진) : 끌어온 유저에게 무엇을?
        | See, Think : 브랜드 인지도 증대/사이트내 다양한컨텐츠 탐색/재방문 유도
                        -> 브랜드 스토리강조, 상품기능, Value 소개, Wish list, 정보 공유기능
        | Do, Care  : 구매유도
                        -> 가격 혜택 강조, 쉬운 구매 프로세스, 구매 프로세스 진입 유도
성과측정(네비게이터) : 각 단계의 유저들을 위한 별도의 지표로 성과 측정
            보통은 Do 단계에 집중해서만 성과를 측정해서 문제
        | See   : 브랜드 인지도 증대 -> 브랜드 리프트 서베이 광고 노출 /조회
        | Think : 재방문 유도 -> 페이지 뷰 수, 체류시간/이탈율, 지원 전환, 재방문율
        | Do, Care  : 구매유도-> 리드 수, 전환 수, 구매 수, 매출액 등
1.1. 전체 타겟팅 리스트
1. 인구 통계
    성별 | 연령 | 자녀유무 | 가구소득
    Google Login -> 구글 계정 기준으로
    X -> 쿠키 기반으로 
2. 콘텐츠
    키워드 | 주제 | 게재위치
    키워드 : 문맥타겟팅(컨텐츠키워드:직접 선택한 키워드에만 노출/잠재고객: 관련성있는 컨텐츠에도 노출)
    주제 : 특정주제와 관련된 웹사이트,앱,동영상에 광고 노출
    게재위치 : 선택한 위치 지면에 타겟팅(Google Display Network or Youtube)
3. 잠재고객
    관심분야 | 구매의도 | 리마케팅
    관심분야 : 관심있는 사용자에게 도달 
        관심분야 잠재고객 - 소비자 패턴 타겟팅 추가됨
        맞춤 관심분야 잠재고객 - 안드로이드 앱 ID 및 구글 지도데이터 추가(2개 이상의 소스를 mix해서..)
    구매의도 : 적극적으로 소비하려는 사용자에게 도달
        구매의도 잠재고객 - 라이프이벤트 타겟팅 옵션 추가(이사, 졸업 등)
        맞춤 구매의도 잠재고객 - Search, Youtube에 사용가능한 맞춤의도 타겟팅 
    리마케팅 :
        유사잠재고객(통합된 잠재고객) 
        고객일치타겟팅 - CRM 데이터를 바탕으로 타겟팅
1.2. 잠재고객 타겟팅 내 업데이트 사항
2.1. UAC 액션 캠페인 Best Practice
First Open 캠페인과 인앱 액션 캠페인 병행해서 운영 ..?
전환단계별 액션 캠페인을 여러 개 셋팅해서 동시에 운영 ..?
UAC education program (번역도 되있음)
analytics.google.com/analytics/learnwithgoogle/course/1
2.2 검색 리마케팅 캠페인(RLSA)
잠재고객 모수크기는 1000 이상일때 사용할 것
2.3 카루셀광고(Carousel Ad)
기존 PC에 노출되던 라이트박스 상품이 모바일 노출에 적합한 형태로 출시..(모바일에선 마우스오버가 없어 스크롤/스와이프 형태로 노출)


2.4 트루뷰 포 액션
비디오 소재를 이용한 전환(click/light-weight web) 극대화
광고 노출 형태 : CTA 클릭 영역, 버튼 삽입 배너영역, 엔드스크린
입찰 방식은 CPV, 타겟 CPA 2가지
2.5 트루뷰 포 리치
유튜브 도달을 극대화 할 수 있는 트루뷰 베타 상품
트루뷰 인스트림과 동일한 형태를 유지하되 저렴한 CRM을 ..
트루뷰포 리치 | 범퍼 광고(skip 불가능) | 트루뷰 인스트림(기존에 보던거)

Youtube SEO 법칙

앱 사용시간이 카톡 추월
10~20대 충성 사용자가 많음
단순한 동영상 시청 플랫폼이 아닌, 검색엔진
So 브랜드 검색량 및 매출 증대 가능

Search Engine Optimization

SEO가 잘되어 있으면 영상을 머신러닝이 추천할 가능성이 높아지고, 유저의 검색결과에 노출될 가능성이 높아짐
.. 전체 시청시간 중 머신러닝 추천에 의한 시청 시간 비중 70%
.. 유튜브 전체 시청 시간 중 동영상 검색을 통한 시청 시간 비중 30%
SEO 관리 방법
1. factor
많은 사용 시간 + 조회수 를 원함 -> 상순위 노출 :반복
So
User interaction : 시청시간(주목도/재미)과 User Engage(시청자 호감) 개선
    썸네일 중요성(인지)
    Youtube Analytics에서 조회율이 증가하는 부분..
    End Screen 기능 활용하여 유저 이탈 최소화/시청시간 증대
    LCS 관리 확보
metadata : 검색어와 동영상의 관련성을 식별하기 위해 구글과 유튜브가 활용하는 정보
            제목 / 설명 / Tag
            검색어를 포함시키는 것은 기본, 제목~설명~Tag를 검색어가 관통할 수 있도록 설정
golden time : 유튜브는 새로운 컨텐츠에 기회를 제공하며, 첫 48~72시간이 성과를 내느지가 영상의 생명을 결정함

So Golden Time 에 빠른 user interaction이 이루어져야 함!! -> 이건 투자가 필요함..
How?
    Youtube Discovery 상품 활용(트루뷰 Discovery)
    앱 푸쉬(영상 업로드 -> 앱푸쉬 -> 당일 시청 시간 급증)
SEO관리 스마트하게 하는 방법
-- vidIQ(크롬 extension)
1. 일반 키워드 정보 탐색 : 키워드의 월간 검색량 및 경쟁정도를 알 수 있어 어떠한 키워드를 투자의 대상으로 삼을지 결정하게 해 줌
2. 영상 Tag 모니터링 : 상순위 노출되는 영상이나, 경쟁사의 영상이 활용하는 TAG 모니터링을 통해 우리 영상의 TAG 아이디어 획득/ 주요 키워드 순위 모니터링에 활용
3. SEO 점수 확인 및 checklist 점검

차주에 신입사원 교육이 예정되어 있는데 기대가 된다. GA도 공부해야겠고.. 도메인 지식 익히기에 바쁜 요즘이다.


'Log > .TIL' 카테고리의 다른 글

[TIL]180608  (0) 2018.06.08
[TIL]180606  (0) 2018.06.06
[TIL]180319-0325  (0) 2018.03.25
[TIL]180312-0318  (0) 2018.03.14
[TIL]180305-0311  (0) 2018.03.07
댓글
링크
최근에 달린 댓글
«   2024/05   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
Total
Today
Yesterday