-기능적으로 동일한 객체를 필요할 때마다 매번 새로 생성하기보다는 하나의 객체를 재사용하는 것이 좋을 때가 많다. 재사용을 하면 객체 생성에 소요되는 비용(시간과 자원)이 절감되어 실행 속도가 더 빨라지고 코드도 보기 좋게 작성할 수 있다. 불변(immutable) 객체는 항상 재사용이 가능하다.
-불필요한 객체 생성을 막기 위한 첫번째 좋은 방법은 static 팩토리 메소드를 사용하는 것 -불변객체가 아닌 가변객체더라도 상태가 변경되지 않는 것이 보장되면 재사용 가능하다.
-재사용을 막기 위한 static 팩토리 메소드에서 늦 초기화 ( lazy initialization ) 을 하는 경우가 있는데, 후에 다루겠지만 두드러진 성능 개선이 나타나진 않고, 오히려 코드가 꼬일 가능성이 높다.
-자바 1.5 이상 버전에서는 오토박싱( autoboxing ) 을 통해 불필요한 객체를 의도치 않게 생성한다.기본형(primitive) 데이터를 박스화(boxed primitive) 클래스로 자동변환 하는 것을 오토박싱이라고 하며,반대의 경우를 오토언박싱 ( autounboxing ) 이라고 한다.
오토박싱이나 오토언박싱이 생길 때는 성능 측면을 잘 고려해야 한다. 즉 의도하지 않은 오토박싱이 생기지 않도록 해야 한다.
-우리가 직접 객체 풀 (object pool) 을 만들고 유지하여 객체 생성을 피하려는 방법은 좋지 않다. 풀에 유지할 객체들이 대단히 무거워 생성 비용이 많이 드는 것이 아니라면 복잡한 코드가 된다. 덧붙여 메모리 할당과 해지가 늘어나며 성능 저하가 나타나기 쉽다. 생성 비용이 많이 드는 대표적인 객체들은 데이터베이스 연결(connection)이다.
-반대로 방어복사 ( defensive copying) 가 필요한 경우도 있다. 단, 방어복사를 잘못 사용했을 때 불이익은 중복 객체를 생성하여 받는 불이익보다 훨씬 크기 때문에 주의하자.
-Summary 가급적 객체들을 불변객체로 만들어 재사용하라. static 팩토리 메소드를 이용하여 쓸데없이 객체를 계속 만들지 말아라. 의도치 않은 오토박싱과 오토언박싱을 주의하라. 데이터베이스 연결과 같이 init 타임이 오래걸리는 경우를 제외하고는 가급적 object pool 을 스스로 만들고 관리하지 말아라.
전세계적으로 스마트폰, 태블릿, PC 등모바일 기기의 확대에 따라 모바일 앱 마켓이 급속도로 성장하고 있습니다.
앱 마케팅에 대한 이해를 돕기전에 다음과 같은 광고 프로세스에 대해 간단하게 설명하고 시작해보겠습니다. 마케팅을 하기 전 중요한 내용이라 정리해 보았습니다.
1. 광고 프로세스
광고주의 광고가 고객에게 전달되는 과정입니다. 에이전시에서도 1단계 대형 에이전시가 수주를 하고 2단계 에이전시로 외주로 진행 3단계..4단계 등으로 광고를 외주를 주거나 직접 광고를 진행합니다. 여기서 간단하게 설명하자면, 다양한 플랫폼에서 고객으로 전파되는 것이죠. 기본적으로 우리가 알고 있는 여러 플랫폼 매체가 있을 것입니다.
지식정보 전달 : 뉴스, 컨텐츠등의 플랫폼 ( 직접 or 에이전시를 통한 광고진행)
종합포탈 플랫폼 : 직접 광고주와 체결 (ex 네이버 직접 광고 등록 배너 하단 리스트 등.)
앱(어플리케이션) : 직접 광고주와 체결 (배너, 전면광고, URL 등등)
국내 모바일 광고 시장 지형도 : 참조 버즈빌
▲ 국내 모바일 광고 시장 지형도 : 참조 버즈빌
간편하게 정리를 하자면 다음과 같습니다.
결국 고객에게 광고를 위해서는 구매자 판매자 중개자 등과 같은 다양한 조건들이 생깁니다.
▲광고주의 광고가 고객에게 전달되는 구조도
2. 앱 마케팅 계획 구조
본격적으로 앱 마케팅을 어떻게 진행해야 되는지 정리해 보겠습니다. 광고 process에 대한 간단한 구조를 확인 했으니, 우리는 앱 마케팅을 어떻게 해야 하는지에 대해 논의해 보겠습니다. 아래는 광고 중에 앱(Android/IOS) 마케팅에 대해 리텐션을 만들어 내는 3가지 기본 사이클에 대해 정의 해 보았습니다.
▲ 사용자 리텐션을 만들어 내는 3가지 기본 사이클
왜? 위와 같은 마케팅 계획 전략을 세워야 하는 것일 까요? 라고 물어 보신다면 다음과 같은 자료를 보시면 이해가 가실 내용입니다.
▲ 앱 설치 후 모바일 APP유저 월별 유지율
레드오션인 앱스토어에서 생존하기 위해서는 점차 마케팅이 차지하는 중요도는 더욱 높아지고 있으며, 공격적인 마케팅은 선택이 아니라 생존을 위한 필수 전략입니다. 그래서 다양한 마케팅 중에 광고를 어느시점에 어떻게 전달하는 지도 중요합니다.
점차 월별 유지율이 감소하는 경향은 일반적인 앱 사용 형태입니다.
▲ 모바일 앱 마케팅 요소
마케팅 비용을 집행한다고 해서 수익이 정비례로 증가하는 것은 아니다.
전략 없이 무작정 사용자를 늘이기 위한 광고 집행은 효과가 없다.
마케팅을 집행하는 목표는 일차적으로 앱의 수명(Life Cycle)을 늘리는 것이다.
앱 수명이 증가하는 만큼 이용자의 Retention이 증가한다.
앱 수명이 2배 증가하면 매출은 약 1.5배가 증가한다.
바이럴을 통한 유입이 많다고 매출이 직접적으로 증가하는 것은 아니지만 광고비 지출이 줄어 순수익이 증가하게 된다.
수익을 극대화하기 위해서는 ARPDAU를 높이는 전략을 세우는 것이 중요하다.
3. 마케팅에 대한 이해
온라인 대비 모바일은의 특수성과 제약을 고려하여 광고를 진행하기 전에 여러 사항을 고려해야 합니다. 출시 후 30일 동안 집중적인 마케팅 리소스를 투입하여 초기 사용자 반응을 확인해야 합니다.
1. 텍스트를 많이 넣지 마라.
-모바일 광고 영역이 작아진다.
2. 소재를 최적화 하라.
-작은 화면상에서 선명한 이미지가 노출될 수 있도록 하라.
3. 적용 가능 포맷에 대해 고려하라
-Flash의 경우 IOS 적용 불가.
-Gif 포맷의 애니메이션 경우 매체 별 적용 가능 여부 확인 필요.
4. 모바일 캠페인은 간소하게 진행하라
-이벤트를 간소화 하라.
(모바일 네트워크의 한계 / 장시간 집중할 수 없는 환경 등)
5. 모바일에 최적화 된 이벤트를 기획하라
● CPI(Cost per install) : 앱을 다운받은 유저에게 일정한 리워드(보상) 지급, 앱 다운로드를 유도함
● CPC(Cost Per Click) : 노출에 대한 광고비는 지불하지 않고, 클릭하여 고객이 방문한 경우에만 광고비를 지불하 는 종량제 방식의 키워드광고 ● CPM(Cost per mille) : 소비자 1천명에 대한 노출비용으로, 매체 도달상의 효율성을 평가하는 광고 ● CPA(Cost Per Action) : 파트너들의 자연스러운 앱소개 활동을 통해서 자발적인 앱설치 후 실행을 확산시키는 광고 방법 ●ARPDAU (Average Revenue Per Daily Active User) : 일단 돈을 낸 유저들이 평균적으로 얼마나 매출을 발생시 키는가를 의미한다. ●ARPU(Average Revenue Per User) : 개인당 평균 매출 단가
4. 앱 마케팅 도구의 이해
과금 형태 및 월별 다운로드 가능 수에 따라 적정 매체 설정을 하고 리워드 매체에 따른 조건을 고려하여 집행해야 함
▲ 앱 마케팅 도구의 이해 [그림-1]
광고 목표에 따라 매체 선택을 고려해야 하며, 매체 커버리지, 타켓접근성 등을 고려대상.
▲ 앱 마케팅 도구의 이해 [그림-2]
과금 형태 및 월별 다운로드 가능 수에 따라 적정 매체 설정을 하고 리워드 매체에 따른 조건을 고려하여 집행해야 함
간편하면서도 만들기 용이한 템플릿을 소개시켜 드리겠습니다. 무엇보다 내용이 가장 중요합니다. 그렇지만 그 내용을 어떻게 표현해야 하는지 궁금해 합니다. 그래서 보통 PPT로 작업할때 디자인 작업에 최소한의 시간을 써야 합니다. 그것이 내용을 더욱 알차게 만들 수 있는 방법이라 생각합니다. 제가 작업한 건축학과 졸업 PPT를 참고해 주세요.
DAPP 서비스를 기획하고 개발하고 있다면, 기획자/개발자가 가장 고충을 겪는 부분일 거라 생각이 됩니다. 가스를 계산하기 위해서는 총 3가지의 개념이 필요합니다. 가스를 설정하기 위해서는 이더리움이라는 코인의 개념을 알아야 합니다. 블록체인 서비스 기획자가 알아야할 기본적인 상식 Part-1를 참고해 주세요.
#GASÐ
"DAPP 서비스를 기획시 일반적으로 가스(GAS)를 누가 낼 것인가가 가장 중요한 핵심 입니다."
일반적인 Web 사이트와는 다르게 이더리움 기반 DAPP 서비스는 블록체인상에 올라갈 경우 가스(GAS)가 발생됩니다. 이부분의 기획과 설계를 잘해야만 문제점이 없습니다. 만약 플랫폼 제공자가 블록체인상에 올라가는 가스(GAS) 비용을 전부 부담한다면, 사용자가 많아짐에 가스(GAS)가 많이 사용됩니다. 그러면 이더리움(ETH)의 보유량 또한 많은 소비를 이루기 때문에 플랫폼 제공자는 부담을 느낄 수 밖에 없습니다. 그래서 트랜잭션 처리시 꼭 인지하고 기획해야 됩니다. 모든 데이터가 다 블록체인화 되면 문제의 소지가 있기 때문에, 어떤 정보를 블록에 담을 것인가?.그래서 다음과 같은 상반된 개념이 있습니다. ON/OFF Chain 의 개념입니다.
ON Chain : 블록에 담을 것
OFF Chain : 블록에 담지 않을 것
#트랜잭션
트랜잭션을 수동으로 보내려면 함수의 인코팅 된 매개변수를 번환. Web3.eth에 트랜잭션을 전송하는 시뮬레이션을 보면 전송하는 Data의 용량에 따라 가스의 전송도 변환되어 전송이 가능하다.
var contractData = contractObject.new.getData(someparam, another, {data: contractBytecode});
var estimate = web3.eth.estimateGas({data: contractData})
트랜잭션 실행 코어 이더리움 프로그래밍
3. 기획자가 바라보는 가스(GAS)의 정의
상위 가스에 대한 내용을 어느 정도 이해했다면, 다시 근본적인 문제점을 가지고 고민합니다. 여러 블로그에서 소개해준 가스 비용 정산 및 트랜잭션에 대한 내용을 담기보다는 기획자가 생각하고 고민해야 되는 부분의 고충을 적어 보았습니다.
#블록체인 #서비스기획자 #토큰이코노미
● 다음과 같은 질문 사항에 대해 스스로 답변이 가능해야 합니다. (기획)
1. 블록체인에 꼭 담을 내용인 것인가? (토큰 이코노미에 대한 설계가 있는가?)
2. RDBMS로 관리해도 문제 없는 사항인가? ( 반드시 On Chain화 시킬 필요가 있는지?)
본격도입을 위해서는 이더리움재단 내부합의 및 기존 노드운영자들의 합의가 필요하여 상당한 시간이 소요될 것으로 예상된다.
3) 고려사항
현재 네트워크 노드 부담하는 하드웨어 비용증가를 고려해야
하위 네트워크 내부 트랜잭션에서 기존 트랜잭션의 방식 사용성이다.
네트워크 간 트랜잭션은 트랜잭션 요청 영수증 기반처리에 대한 부분을 고려해야 한다.
◎샤딩(Sharding) 블록체인 형태
◎샤드 간 트랜잭션
( 영수증 기반 처리 )
◎샤딩(Sharding) 관련 이슈
중앙화 이슈.
보안성 이슈.
1% attack : 100개 샤드 시스템으로 오직 1%의 hash rate로 샤드 지배 가능성이 있음.
샤드 간의 커뮤니케이션이 너무 빈번하게 일어난다면, 커뮤니케이션으로 인한 시간 지연의 문제가 발생함.
◎샤딩(Sharding) 적용가능 방식
네트워크 샤딩
트랜잭션 샤딩
스테이트 샤딩
1) 네트워크 샤딩
임의로 네트워크가 무작위로 느드를 샘플링하여 블록 단위로 샤드를 형성하는 것이다.
네트워크가 샤드의 구성원에 대한 동의를 구하지 않아 구성원들이 원하는 방향으로 가지 않는 경우, 구성원들의 불만을 해결하지 못한다는 단점이 있다.
2) 트랜잭션 샤딩
트랜잭션 해시의 마지막 몇 비트를 기반으로 샤드를 결정하고 트랜잭션의 유효성을 확인한다.
사용자가 악의적인 경우, 동일한 두입력이지만 출력이 다른 트랜잭션을 생성할 수 있다.
이중 지출을 방지하기 위해 유효기간이 진행되는 동안에 샤딩이 된 조각의 노드들간의 통신이 필요하다.
3) 스테이트 샤딩
Account-based model 이다.
상태가 지정된 블록체인에서 특정 샤드는 상태의 일부만을 유지한다.
교차분할 트랜잭션을 수행하지 못하도록 제한됨.
시스템의 상태가 모든 샤드에 복제되어 있지 않기 때문에 네트워크는 더이상 오프라인 샤드에 대한 트랜잭션의 유효성을 검사하지 못하게 된다.
오프라인 샤드를 유지하기 위해 백업 노드를 갖게된다면 중앙집중식이 되어 보안성에 위협이 된다.
네트워크가 한 번씩 재편성될 때 한번에 네트워크를 전환하게 되면 일부 동기화가 완료될 때 까지 전체 시스템을 사용할 수 없게 될 수도 있다.
◎샤딩(Sharding) 관련 과제
1) 난수생성
난수를 사용하여 검증자를 샤드에 배정하는데,공격자가 난수를 예측하거나 조작할 수 있다면,샤딩 보안에 문제가 생길 것이다.기존의RANDAO난수 생성방식을VDF(Verifiable Delay Function)를 통하여 개선하는 중이다.
2) 빠른 샤드 전환
샤드에 대한 공격 성공 가능성을 줄이고자 한다면 검증자를 빠르게 전환해야 한다.이를 위하여 이 전부터 터look ahead time을 두어 검증자가 자신이 맡을 샤드 블록을 미리 동기화 시킨다.미리 동기화하기 위해서는 동기화할 자료를 줄여서 빠르게 검증자를 준비할 수 있는stateless client를 제안한다. stateless client는 블록 헤더만을 저장한다.하지만 블록헤더만을 저장하기 때문에 거래에 대한 검증은 불가능하다.거래 검증을 하려면 거래를 만들 때,검증에 필요한witness를 첨부해야 한다.아니면 영지식을 사용하여witness의 크기를 줄이는 방법도 제안되었다.
3) 자료 가용성
만약 모두가 stateless client라면 블록의 내용을 손실할 수 있다.그렇기 때문에 누군가는state를 저장하고 있도록 해야한다.이를 위해 적절한 보상과 검증(Proof of Custody)가 필요하다. Fisherman딜레마는Erasure Coding으로 해결 가능하다.
4) 검증자간 효율적인 통신
샤드 배정이 자주 바뀌는 상황에서 샤드 검증자들끼리의 효율적인 P2P통신은 필수적이다.이를 위해, libp2p의floodsub와gossipsub (meshsub)이 사용된다.
5) 샤드 간 비동기 통신
거래 당사자나 스마트 계약이 여러 샤드에 나누어져 있다면 샤드 간의 통신(cross-shard communication)이 필요하게 된다.하지만 여러 단계를 거치게 되므로 시간이 오래 걸리므로 결국 메인 체인에 무리를 주게되고 이렇게 샤드 간 통신이 너무 자주 일어난다면 샤딩이 가지고 있는 장점은 사라지게 된다.이에 이더리움은crosslink를 가지고 메인체인의 무리를 덜고, yanking으로 필요한 스마트 계약을 현재 샤드로 가져와 샤드 간의 통신을 줄이고자 한다.또한 현재 지연상태 전이(delayed state transition)을 통한 샤드 간의 비동기 통신도 구상 중에 있다고 한다.
