■ MongoDB

[MongoDB] 몽고디비 인덱싱에 대하여..

인덱싱은 개념은 쉽지만 막상 대규모에 적용하려면 상당히 까다로운 문제에 직면하게 된다.

그중 몽고디비에서 아주 사소하지만 반드시 알아둘 것들을 정리해 보았다.

1. 몽고디비에서 부정(negation)에 대한 쿼리는 되도록 사용하지 말자.

부정에 대한 쿼리는 일반적으로 잘 작동하지 못할 수 있다. 작동을 잘 못한단 의미는 잘할수도 있고 아닐수도 있다는 의미다.

좀 더 깊이 가보자. 예를 들면

{
  nick: {
    $ne: /^hwa/
  }
}

다음과 같은 쿼리가 있다고 했을경우,  hwa로 시작되지 않는 문자열을 위해 모든 쿼리를 검색한다.

이는 hwa로 시작되는 문자열을 찾는 것과는 다르게 매우 비효율 적이다.

세세한거 따지기 싫다면 왠만하면 부정은 쿼리에 사용하지 말자. (부정의 반대는 긍정이므로 반드시 대칭되는 쿼리가 있을것이다.)

 

2. 위에서 /^hwa/ 라는 쿼리를 썼다. 정규식은 일반적으로 인덱싱이 되지 않는다. 하지만 접두어(prefix)의 경우 인덱싱이 가능하다.

 

3.  복합인덱스 순서에서 범위필드에 인덱싱은 항상 마지막으로 작성한다. 범위필드는 마지막에 해당하는 모든 쿼리를 찾고 최종적으로 제한하는 역할을 한다.

 

4. 몽고디비에서는 하나의 쿼리당 하나의 인덱스만을 사용할 수 있다. 하지만 OR쿼리는 $or: [] 안에 있는 배열의 개수만큼 인덱스를 이용하여 쿼리를 수행한다. 당연한 말이겠지만 여러개의 검색된 n개의 도큐먼트 집합이 있다는 의미이며, 몽고디비는 이 도큐먼트 집합들을 합치는데 또다른 비용을 소모한다. 가능하면 $in으로 가자.

 

5. 다음과 같은 내장된 도큐먼트에 대한 인덱스를 수행할 경우,

ensureIndex({'user.nick': 1});

반드시 쿼리문 작성 또한

find({'user.nick': 'hwarang'})

위 처럼 되야한다. 만약

find({user:{nick:'hwarang'}})

다음과 같다면 인덱스는 user에 대한 인덱스를 수행할 것이다.

 

6. 배열에 대한 인덱스는 다중키 인덱스라고 하는데, 이는 배열의 모든 요소에 인덱싱을 하는 것이다. 따라서 대체로 일반 인덱스보다 비용이 많이 든다. 또한 두개이상의 배열을 한번에 인덱싱 할수 없다. 예를들면

ensureIndex({friends: 1, family: 1});
find({friends:['1', '2'], family:['0', '1']};

다음과 같은 상황에서 friends와 family 두개의 키로 인덱스를 생성했는데 두개 모두 배열이다. 즉 두개이상의 배열을 한번에 인덱싱할 수없다는 원칙에 의거하여 에러가 날 것이다. 왜 안되는지에 대한 이유는, 다중키 인덱스는 각 요소마다 인덱싱을 한다고 했는데 2개의 배열은 n*m개 3개의 배열은 n*m*s개의 인덱스가 생성될 것이기 때문이다. (이는 심하게 비용낭비이다.)

 

7.  인덱싱할 필드는 카디널리티가 낮은것을 선택하자.  이유는 높은 카디널리티를 갖고 있는 필드는 인덱싱의 위력을 발휘하지 못한다. 낮은 카디널리티일수록 인덱싱의 진가가 발휘된다. (카디널리티는 한 필드의 중복성의 정도를 나타낸다. 만약 필드가 enum타입을 갖고 있다면 낮은 카디널리티가 된다. 가장 높은 카디널리티는 unique key (pk)가 된다.)

Standard
□ For the rest of us

Win or learn, never lose

슬로그업 홈에 ‘Services’ 탭이 생겼다. 그렇다. 마침내 봄블링이 출시됐다. 길고, 길었다. 짧고도 짧았다. 6개월이란 시간의 물리적 질감은 터무니없이 짧아 개발에 허덕였고, 완성이 지연되던 6개월의 심리적 체감은 길고 길었다.

 

그래도 너무 늦지 않게 완성된 것 같다.

 

공식 출시일은 사실 오늘이다. 이제부터 본격적인 마케팅에 들어간다. 그전에 잠깐 기본적인 SEO 작업과 SNS 홍보만 가볍게 해봤는데 반응이 나쁘지 않았다. SNS 홍보 첫날 유저 100명을 넘었다. 이틀째 첫 유료아이템 결제가 이뤄졌다. 일단 첫발은 사뿐히 뗀 것 같다. 그래도 이제 시작이고 갈 길이 머니까 깝치지 말고 차분해야겠다.

 

서비스 슬로그업 베타를 오픈해보긴 했지만, 어느 정도 만족할만한 완성도를 갖춘 제품을 출시해본 것은 봄블링이 처음이다. 화랑이는 앱이나 웹을 많이 만들어봤지만, 난 사실 슬로그업 하기 전엔 카톡도 안 깔고 살던 사람이었다.

 

묘하다. 뭐랄까. 처음 수영장에 엄지발가락을 집어넣을 때처럼 조금은 두렵고 등골이 서늘하니 짜릿하다.

 

난 몸의 예고에 둔감해서 항상 몸에 변화가 오면 뒤늦게 눈치채곤 한다. 아파야 아픈줄 안다. 그냥 담담한줄 알았는데 그래도 출시한다고 꽤 신경을 쓰고 있나보다. 아침에 보도자료 돌려야 해서 일찍 잠자리에 누웠는데 도대체 잠이 오질 않았다. 멀뚱멀뚱 눈앞의 어둠을 올려다보다가, 두 시간 후에도 분명히 이렇게 누워있을 것 같은 또렷한 각성상태임을 깨닫고 잠들기를 그만뒀다. 컴퓨터를 켜고 앉았다. 밤새 일했다.

 

어렴풋이 알 것 같다. 지난 1년간 누적된 정서의 발현일 것이다. 스타트업에서 일하는 사람의, 작은 승리와 작은 실패들로 이뤄진 징검다리를 건너는 자의 희망, 걱정, 승리감, 좌절, 불안감, 조바심, 용기, 고립감, 그리고 그래도 끝까지 하면 할 수 있다는 다짐들이 녹은 1년이었다. 순도 높은 1년이었다.

 

미친.. 새벽감성은 역시 위험하다. 더 이상 쓰면 손발이 다 오그라들어서 물고기가 될 것이다. 그렇다고 이대로 글을 끝낼 순 없으니까 노래나 하나 듣자. 이적의 거짓말 거짓말 거짓말. 스타트업이 들어야 할 음악이다.

 

잠깐이면 될 거라고 했잖아. 여기 서 있으라 말했었잖아.
거짓말 거짓말 거짓말

물끄러미 선 채 해가 저물고
웅크리고 앉아 밤이 깊어도
결국 너는 나타나지 않잖아
거짓말 음 거짓말

우우 그대만을
하염없이 기다렸는데
우우 그대 말을
철석같이 믿었었는데
우우우우우
찬 바람에 길은 얼어붙고
우우우우우
나도 새하얗게 얼어버렸네

 

이 가사를 좀 보소. 이건 스타트업의 BGM이 아닐 수 없다. “잠깐이면 될 거라고 했잖아.. 거짓말 거짓말 거짓말.” 두세달이면 만들 수 있을줄 알았다 슈밤.

 

아 이제 진짜 시작이다. 재밌을 것 같다. 우린 아직 갈길이 멀다. 다행이다.

 

클릭하면 봄블링 소개 페이지로 이동됩니다.

클릭하면 봄블링 네이버블로그 소개 페이지로 이동됩니다.

 

Standard
■ Javascript

[Angular.js] 앵귤러JS – ng-repeat에 있는 track by에 대한 설명

angular.js에서 ng-repeat를 사용할때track by란 것이 있습니다.

이것에 대해서 알아보도록하겠습니다.

ng-repeat는 directive입니다. 우리나라 말로 지시자라고 하는데, 앵귤러에서는 해당 지시자를 활용해서

여러가지 templete적인 부분과 plugin 형태의 개발을 함축해 놓았습니다.

 

ng-repeat를 이용해서 기존 템플릿의 for문을 구현할 수 있습니다.

<any ng-repeat="value in array"> </any>

를 사용하면 <any></any> 사이에 해당 scope가 자동으로 생기게 됩니다.

그러면서 $index, $first, $middle … 등과 같은 이미 정의된(pre-defined) 요소들의 값이 할당됩니다.

 

그런데 잘나가다가 하나 이상한 것이 들어오게 됩니다. 그것은 바로 track by란 놈인데,

표현식은 다음과 같습니다.

<any ng-repeat="value in array track by exp"> </any>

exp 부분에 해당하는 속성을 넣어주어야 합니다.

해당하는 속성이란 부분이 매우 애매한데 좀더 풀어서 설명하도록 하겠습니다.

자바스크립트에서 배열은 타 언어와 다르게 중복값을 허용합니다.

즉 array부분에 중복값이 있다면 반드시 distinct할 exp를 작성해 주어야 합니다.

쉽게 예제를 보면

 

<any ng-repeat="v in [0,0,1]"></any>

란 코드가 있을때 0,0 두개의 중복값이 있습니다. track by를 작성해 주지 않으면 각각은 모두 별개의 값으로서 인식되나 키값은 중복값을 허용하지 않게됩니다. ($$hashKey 이용)

여기선 $$hashKey에 키값으로 0이 2개가 들어가서 결국엔 [0, 1]과 같은 해쉬가 생성됩니다.  따라서 for문은 3바퀴를 도는데 값은 두개밖에 없습니다.

즉 에러가 나게 됩니다.

따라서

<any ng-repeat="v in [0,0,1] track by $index"></any>

라고 작성하면 $hashKey가 아닌 $index(위치)를 통해서 다른 3개의 DOM을 생성합니다.

 

그럼 간단하게 track by에 대해서 설명을 마치겠습니다. 안녕~

Standard
■ Android

안드로이드 앱내결제 (Android In App Billing)

오랜만에 안드로이드(Android) 포스팅입니다.

오늘은 안드로이드의 앱내결제(In App Billing, 이하 IAB)에 대해서 알아보도록 하겠습니다.

IAB는 어플리케이션 개발에서 매우 중요한 부분이기 때문에 결제플로우의 명확함, 보안성 등을 모두 고려해야합니다.

또한 현재 안드로이드에서는 draft상태인 앱에서는 결제테스트가 잘되지 않기 때문에 여러가지 고려해야할 상황에 놓이게 됩니다.

기본적인 SDK Manager나 기본상황은 모두 생략하겠습니다. 또한 개발환경은 Mac환경이고, 안드로이드 스튜디오(Android Studio)를 기준으로 설명합니다.

서버는 node.js 서버입니다.

 

1. 구현

1-1.  기본설정

먼저 aidl파일을 import해야합니다. 이파일은 SDK Manager로 다운받은 이후 설치된 sdk폴더를 기준으로

extras/google/play_billing 폴더 내에 있습니다. 또한 sample폴더내에서 MainActivity.java 파일을 찾으신후 그 옆에 있는 util 폴더를 복사해옵니다.

aidl은 (Android Interface description language) 인터페이스만 정의된 언어입니다.

간단하게 말해서 이기종 혹은 다른 방식의 안드로이드 앱들간, 프로세스간 등의 통신이 필요할때의 프로토콜이 되는 기준을 인터페이스만으로 정의한 것입니다.

여기선 IPC (Inter process communication) 를 위해서 사용됩니다.

스크린샷 2015-01-05 오후 3.14.36

폴더 구조는 다음처럼 됩니다. 이클립스와는 구조가 다르니 확인해보세요!

aidl안에 패키지가 정의되어있습니다.

이때 주의할 것은 aidl폴더내 패키지를 만들때 한번에 “com.android.vending.billing”으로 만들면 안되고,

“com” 을 먼저 만들고 그 내부에 “android” 그내부에 “vending”, “billing”이런식으로 만들어야 합니다.

즉 패키지가 실질적으로 “com/android/vending/billing”의 형태가 될 것입니다.

다음으로는 안드로이드 기본

2-2. 랩퍼 구현.

이제 구현을 쉽게 하기위해 추상화된 형태의 헬퍼클래스를 구현해보도록 하겠습니다.

코드설명은 주석으로 읽어보시면 되겠습니다.

public class InAppBillingHelper {

    public static final String TAG = "InAppBillingHelper";
    
    // onActivityResult에서 받을 requestCode.
    public static final int REQUEST_CODE = 1001;

    // publicKey 개발자콘솔에서 앱을 생성후 얻을 수 있다.
    private String mPublicKey;
    
    // 테스트를 하기 위한 테스트용 productId(SKU)
    private static final String TEST_SKU = "android.test.purchased";

    // 구매되고 소진되지 않은 아이템을 캐시해놓을 변수.
    private ArrayList<String> mOwnedItems = new ArrayList<>();
    
    // 가져온 util클래스에서 제공하는 클래스. 아이템리스트를 갖고 있다.
    private Inventory mInventory;
    
    // 가져온 util클래스의 실제 헬퍼클래스
    private IabHelper mHelper;
    
    // 자체적으로 서버와 통신할 서비스 클래스. (여기선 구현은 생략)
    private ItemService mItemService;
    
    private Activity mActivity;
    
    // 테스트 여부인지.
    private boolean mIsTest;

    // 실제 우리가 알고있는 아이템목록. (어플리케이션 서버로부터 받아오면됨.)
    public List<String> mItems = new ArrayList<>();

    // 로드 이후 호출될 리스너.
    public interface InventoryLoadListener {
        public void onBefore();
        public void onSuccess(Inventory inventory);
        public void onFail();
    }

    public void init(Activity activity) {
        mActivity = activity;
        mItemService = new ItemService(activity);
        mIsTest = false;
    }

    // 공개키가 없는 생성자.
    public InAppBillingHelper(Activity activity) {
        init(activity);
    }

    // 공개키가 있는 생성자.
    public InAppBillingHelper(Activity activity, String publicKey) {
        mPublicKey = publicKey;
        init(activity);
    }

    // 테스트 여부의 세터.
    public void setTest(boolean isTest) {
        mIsTest = isTest;
    }
}

 

아주 기본적인 클래스입니다.

우리는 IabHelper를 통해서 실질적으로 통신할 것입니다. 이 헬퍼클래스는 내부적으로 구글 서버와 통신하여 우리에게 응답을 주는 코드들을 랩핑해 놓은 것입니다.

또한 ItemService는 신경쓰지 않아도 됩니다. 자체적으로 어플리케이션 서버와 통신하기 위한 Rest클래스 입니다.

이어서 계속 코딩해 보겠습니다.

public class InAppBillingHelper {

    ....

    public void startSetup(ArrayList<String> items, final InventoryLoadListener listener) {
        // before() 를 호출함 으로서 로딩바를 보여주는 등의 액션을 취할 수 있다.
        listener.onBefore();

        // 실제 구글 서버에 요청할 sku리스트.
        mItems = items;

        // 서버에서 테스트 sku목록까지 넣어놓았었다면 제외.
        for (int i = 0; i < mItems.size(); ++i) {
            if (mItems.get(i).equals(TEST_SKU)) {
                mItems.remove(mItems.get(i));
                break;
            }
        }

        // 실제 util에서 가져온 헬퍼생성.
        mHelper = new IabHelper(mActivity, mPublicKey);

        // startSetup함수를 호출함으로서 현재 통신가능여부를 확인하고, 정상적으로 커넥션이 이루어졌는지 확인할 수 있다.
        mHelper.startSetup(new IabHelper.OnIabSetupFinishedListener() {

            @Override
            public void onIabSetupFinished(IabResult result) {
                if (!result.isSuccess()) {
                    listener.onFail();
                } else {
                    // 성공적으로 연결이 되었다면 이제 실질적인 아이템을 로드해야한다.
                    loadItemInventory(listener);
                }
            }
        });
    }
}

이제 초기화를 위해 실질적으로 startSetup메소드를 호출하였습니다. 최종적으로는 loadItemInventory를 구현함으로서 마무리될 것이다.

해당 메소드는 아래에서 구현하도록 하겠습니다.

public class InAppBillingHelper {

    ....

    // 아이템을 로드하는 메소드
    private void loadItemInventory(final InventoryLoadListener listener) {
        // 실제 아이템목록을 받아올 수 있음.
        // mItems에 올바른 값이 할당되어야 함.
        // 만약 mItems가 null값이라면 queryInventoryAsync메소드는 콜백이 호출될때 성공했다고 나오지만
        // 어떠한 아이템 리스트 값도 받아올 수 없음.
        mHelper.queryInventoryAsync(true, mItems, new IabHelper.QueryInventoryFinishedListener() {

            @Override
            public void onQueryInventoryFinished(IabResult result, Inventory inv) {

                // IabResult 값에는 다양한 에러코드및 성공여부를 담고 있음.
                if (result.isSuccess()) {
                    // 멤버변수로 받아온 아이템리스트를 갖고 있는 inventory를 담음.
                    mInventory = inv;

                    // mInventory에는 구매는 했지만 소진되지 않은 값을 얻어올 수 있음.
                    // 따라서 새롭게 받아온 인벤토리를 통해 갱신하기 위해 클리어.
                    mOwnedItems.clear();

                    // 이제 mItems의 sku값을을 갖고 inv에 조회하여 소진되지 않은 아이템 목록을 담음.
                    for (String sku : mItems) {
                        if (inv.hasPurchase(sku)) {
                            mOwnedItems.add(sku);
                        }
                    }

                    // 테스트sku는 가끔 소진되지 않을 때가 있음. 이럴땐 무조건 헬퍼가 수행될 때 소진시킴.
                    if (mInventory.hasPurchase(TEST_SKU)) {
                        // consumeItem에 첫번째 인자는 해당 sku이며, 두번째 인자는 Purchase 인스턴스가 됨. 이후에 다시 설명.
                        consumeItem(TEST_SKU, null);
                    }

                    listener.onSuccess(inv);
                }
                else {
                    listener.onFail();
                }
            }
        });
    }
}

 

여기서 아이템 소진, 구매가 별도로 있다는 것을 알 수 있습니다. 보통 플로우로, 먼저 아이템을 구매하고, 구매가 성공하면 어플리케이션 서버에 아이템구매요청을 해서 실제 어플리케이션 내부에서 쓰일 캐시나 아이템을 지급하고, 요청이 성공되면 comsume 즉 소진을 하여 다시 재구매가 가능하게 합니다.

여기서는 즉 unmanaged item에 대해서 설명한 것인데, unmanaged는 소진가능한 아이템이라고 보시면 됩니다. 그밖에도 managed 아이템 및 subscription 아이템이 있습니다. managed 아이템은 한번 구매하면 다시 구매할 수 없는 아이템이며,subscription 같은 경우는 말그대로 구독아이템입니다. (기간을 정해놓고 일정 기간간격으로 지속적으로 구매되어지는 아이템)

여기서는 아이템을 구매하고 해당 앱에서 처리를 한 후 재구매가 된다고 가정하였습니다.

    

public class InAppBillingHelper {

    ....

    // 실제 구매 (인앱결제)
    public void purchaseItem(final String sku) {

        // 만약 test가 true라면 테스트SKU를 갖고 구매요청을 한다.
        final String refinedSKU = mIsTest ? TEST_SKU : sku;

        // 구매후 소진되지 않은 아이템이라면 다시 구매할 수 없다.
        if (!mOwnedItems.contains(refinedSKU)) {

            // 실제 구매 & 결제요청
            // 해당 메소드를 호출하면 내부적으로 팝업창형태의 결제창이 나온다.
            mHelper.launchPurchaseFlow(mActivity, refinedSKU, REQUEST_CODE, new IabHelper.OnIabPurchaseFinishedListener() {

                @Override
                public void onIabPurchaseFinished(IabResult result, final Purchase info) {
                    if (result.isSuccess()) {

                        // 구매되고 소진되지 않은 목록에 캐시.
                        mOwnedItems.add(info.getSku());
                        
                        // 실제 어플리케이션 서버에서 소진되도록 호출.
                        consumeItemForServer(info);
                    } else {
                        if (result.getResponse() == 0) {
                            // 구매가 실패하였고 이유가 아직 소진되지 않은 것이라면
                            // 소진을 위해 서버에 요청.
                            consumeAllItemsForServer();
                        }
                        CommonHelper.showMessage(mActivity, result.getResponse() + "");
                        ErrorHandler.handleLocalError(mActivity, LocalErrorCode.ITEM_PURCHASE_ERROR);
                    }
                }
            });
        } else {
            // 이미 구매한 아이템이라면 모두 소진시킨다.
            consumeAllItemsForServer();
        }
    }
}

 

이제 구매요청을 합니다. 여기서 REQUEST_CODE가 있는데, 바로 이 요청을 하는 순간 해당 mActivity의 onActivityResult를 통해서 응답을 준다는 의미입니다.

만약 구매가 성공하면 소진을 위해 어플리케이션 서버에 요청을 하게 됩니다.

public class InAppBillingHelper {

    ....

    // 외부 액티비티나 프래그먼트의 onActivityResult함수에서 호출해야 한다.
    // 해당 메소드가 호출되지 않으면 정상적으로 프로세스가 끝나지 않는다.
    // mHelper.handleActivityResult 내부에서 onIabPurchaseFinished메소드가 호출된다.
    public void onActivityResult(int requestCode, int resultCode, Intent data){
        if (!mHelper.handleActivityResult(requestCode, resultCode, data)) {
            onActivityResultError(requestCode, resultCode, data);
        }
    }

    // 해당 메소드를 상속받아 오버라이딩하여 에러를 처리할 수 있다.
    public void onActivityResultError(int requestCode, int resultCode, Intent data) {

    }
}

이제 onActivityResult에서호출할 헬퍼 메소드를 작성합니다.

에러처리는 콜백이 아닌 상속을 통해서 해결하였습니다.

 

public class InAppBillingHelper {

    ....

    // 실제 어플리케이션 서버에 아이템 구매요청을 한다.
    private void consumeItemForServer(final Purchase purchase) {

        final String refinedSKU = mIsTest ? TEST_SKU : purchase.getSku();

        // mItemService는 내부적으로 rest방식의 통신을 어플리케이션 서버와 해주는 통신인스턴스이다.
        // 각자 서버와 통신에 맞게 구현.
        mItemService.purchaseItem(refinedSKU, purchase.getToken(), new ItemPurchaseListener() {
            @Override
            public void onBefore() {
                FullScreenProgressBar.show(mActivity);
            }

            @Override
            public void onSuccess() {
                if (mActivity != null) {
                    FullScreenProgressBar.hide();
                }
                CommonHelper.showMessage(mActivity, "Success!~");
                // 통신이 성공하면 실제 소진을 시킨다.
                // 여기서 두번째 인자로 purchase 인스턴스를 준다.
                // 이때에는 mInventory가 갱신이 되어 있지 않는 경우가 종종있다.
                // 따라서 mInventory에서 purchase를 가져오는 것이다니고
                // 해당 구매 콜백으로 부터 가져온다.
                consumeItem(refinedSKU, purchase);
            }

            @Override
            public void onFail(com.slogup.frameworks.models.Error error) {
                if (mActivity != null) {
                    if (error != null) {
                        ErrorHandler.handleNetworkError(mActivity, error);
                    }
                }
            }
        });
    }
}

이제 어플리케이션 서버에 구매요청을 하고 성공하면 소진시키기 위해 consumeItem을 호출합니다.

여기서 mInventory갱신 문제가 있는데, 실제 구매를 하면 mInventory의 값이 갱신된다. 하지만 갱신이 잘되지 않는 경우가 종종있어서

mInventory.getPurchase(sku)를 호출하기 보단 purchase값을 그대로 가져다 쓰는게 좋습니다.

만약 여기서 null을 입력하면 mInventory.getPurchase(sku)를 통해서 가져옵니다.

 

// 실제 소진 처리.
    private void consumeItem(String sku, Purchase purchase) {

        final String refinedSKU = mIsTest ? TEST_SKU : sku;

        if (purchase != null || mInventory.hasPurchase(refinedSKU)) {

            // purchase가 있다면 해당 구매 인스턴스를 통해 처리하고, 그게 아니라면 mInventory를 통해처리
            // 보통 구매성공, 소진실패일 경우일때 mInventory.hasPurchase(refinedSKU)를 통해서 가져오면 된다.
            Purchase refiendPurchase = (purchase == null) ? mInventory.getPurchase(refinedSKU) : purchase;
            
            // 소진처리.
            mHelper.consumeAsync(refiendPurchase, new IabHelper.OnConsumeFinishedListener() {
                @Override
                public void onConsumeFinished(Purchase purchase, IabResult result) {
                    if (result.isSuccess()) {
                        // 소진에 성공하면 캐시된 값을 지운다.
                        mOwnedItems.remove(purchase.getSku());
                    } else {
                        ErrorHandler.handleLocalError(mActivity, LocalErrorCode.ITEM_FATAL_ERROR);
                    }
                }
            });
        }
        else {
            ErrorHandler.handleLocalError(mActivity, LocalErrorCode.ITEM_FATAL_ERROR);
        }
    }

이제 소진처리를 해봅니다. 특별한 것은 없고 헬퍼메소드를 호출하고 캐시된 값만 지우면 됩니다.

 

public class InAppBillingHelper {

    ....

    private static int sPurchaaseCount = 0;
    public void consumeAllItemsForServer() {

        if (mOwnedItems.size() > sPurchaaseCount && mOwnedItems.get(sPurchaaseCount) != null) {

            final String sku = mOwnedItems.get(sPurchaaseCount);
            Purchase purchase = mInventory.getPurchase(sku);

            if (purchase != null) {

                String token = purchase.getToken();
                mItemService.purchaseItem(sku, token, new ItemPurchaseListener() {

                    @Override
                    public void onBefore() {
                        FullScreenProgressBar.show(mActivity);
                    }

                    @Override
                    public void onSuccess() {
                        sPurchaaseCount++;
                        consumeItem(sku, null);
                        consumeAllItemsForServer();
                    }

                    @Override
                    public void onFail(com.slogup.frameworks.models.Error error) {
                        if (mActivity != null) {
                            if (error != null) {
                                ErrorHandler.handleNetworkError(mActivity, error);
                            }
                        }
                    }
                });
            }
            else {
                handleError();
            }
        }
        else {
            handleError();
        }
    }

    private void handleError() {
        sPurchaaseCount = 0;
        mOwnedItems.clear();
        if (mActivity != null) {
            FullScreenProgressBar.hide();
        }
    }
}

마지막코딩으로 재귀적으로 소진요청에 실패했던 값들을 모두 소진시키는 함수를 만듭니다.

여기서 주의할 점은 이미 서버상에서 소진된아이템은 어플리케이션 서버에서 저장하고 값을 비교해서 적절하게 처리해줘야 한다는 점입니다.

 

이제 한가지만 더 세팅해주면 됩니다. 그것은 바로 퍼미션!

<uses-permission android:name="com.android.vending.BILLING" />

이렇게 간단하게 헬퍼메소드를 만들었습니다. 이제 개발자콘솔을 설정해 보도록 하겠습니다.

 

2. 개발자콘솔 설정.

2-1. 앱생성

먼저 개발콘솔에 접속합니다. https://play.google.com/apps/publish/

다음으로 Add new application을 눌러 새로운 어플리케이션을 만듭니다.

스크린샷 2015-01-05 오후 3.05.11

 

이어서 Title을 적고 Prepare Store Listing버튼을 누릅니다.

여기서 title은 현재 자신이 갖고 있는 앱리스트에서 key값이 아닙니다. 즉 중복 타이틀이 가능하다는 이야기입니다. (키가 되는것은 패키지명입니다.)

 

2-2.  앱 업로드

앱은 테스트를 위해 Application Id값을 변경해서 올려주시기 바랍니다. 왜냐하면 publish가 되어야 테스트가 가능한데, 그렇게 되면 해당 패키지명을 계속 써야하기 때문입니다. 위에 퍼미션 설정이 되어있지 않은 앱은 인앱 아이템리스트를 넣어줄 수 없습니다.

스크린샷 2015-01-05 오후 4.23.48

 

앱이 올라가고, published가 된상태가 되면 다음과 같은 화면을 볼수 있습니다.

스크린샷 2015-01-05 오후 4.26.37

 

위에 보는 바와 같이 unmanaged product로 샘플 아이템이 등록되어있습니다.

또한 status가 active상태로 해놔야 실제로 응답을 받을 수 있습니다.

추가적으로 우리는 공개키가 필요합니다. 왼쪽 메뉴중 젤아래 Services & APIs에 가면 공개키를 쉽게 얻을 수 있습니다.

 

2.3. 테스터 등록.

다음으로 테스터를 등록하고, 어플리케이션서버에서 적절하게 벨리데이션할수 있도록 준비해 보도록 하겠습니다.

스크린샷 2015-01-05 오후 4.30.30

해당 설정에서 API access탭으로 가면 제일 아래 Service accounts라는것이 보입니다. create service account버튼을 눌러 안내에 따라 계정을 만듭니다.

해당 계정은 어플리케이션 서버와 구글 인증서버간 OAuth요청을 위해 필요합니다.

여기서 왜 OAuth인증이 필요한지는 바로 해당 구매된 아이템을 verify하기위한 uri 리소스를 구글에서 제공해주는데 이때 로그인이 필요합니다. 하지만 우리는 verify를 어플리케이션 서버내에서 호출해야하고 따라서 두 서버간 (어플리케이션 서버가 클라이언트역할) 인증을 위해 OAuth를 이용하는 것입니다.

이제 아래 그림과 같이 acocunt details탭으로 이동합니다.

스크린샷 2015-01-05 오후 4.30.06

 

제일 아래 Licensse testing이란 제목이 보이는데 여기서 방금 얻은 계정을 등록합니다. 또한 실제 디바이스에서 테스트할때 로그인되어있을 구글계정(이메일)을 등록합니다. (컴마로 구분)

스크린샷 2015-01-05 오후 4.36.26

 

다음으로 user accounts & rights 탭으로 이동합니다. 그리고 invite new user버튼을 눌러 oauth를 위해 생성한 계정을 초대하고 권한을 View financial reports 가 체크되도록 줍니다. 보통 관리자로 주면 됩니다.

다음으로 API access탭의 Service accounts에서 create service account버튼을 누르면 나타나는 개발자콘솔 페이지링크로 이동하여 API 및 인증 탭에 사용자 인증정보로 이동합니다.

스크린샷 2015-01-05 오후 4.41.48

여기서 새클라이언트 ID만들기를 하고 얻은 값들은 무시하고 새 JSON키 생성버튼을 눌러 얻은 값을 저장해 놓습니다.

그럼 이제 테스터 등록 및 서버에서 유효성검사를 하기 위한 준비를 맞췄습니다.

 

서버에서 유효성 검사하는 부분은 다음 포스팅에서 해보도록 하겠습니다.

그럼 안녕~~

 

 

 

Standard
□ For the rest of us

봄블링의 아마도 최종 기기테스트

디바이스 테스트 하러 성수동 서울앱창업센터에 와있다. 개발자 팀원들은 QA 과정에서 나온 문제점을 바로바로 고치고 있다. 그 사이 나 혼자 잠깐 짬이 나서 끄적이러 들어왔다.
참 재밌는 게 까도 까도 고칠 게 계속 나온다. 이제는 더 이상 없겠지, 이젠 진짜 없겠지 해도 까보면 또 있다.
오늘은 킷켓에서 갤러리가 안 되는 현상이 새로 발견됐다. 망할 안드로이드… 제발 업데이트좀 쉬엄쉬엄 하라고 미친 개발 덕후 색기들아!

 

 

 

K-62

 

여기 성수동 센터 친절하고 참 좋다. 무엇보다 분위기가 자유롭고 널널해서 눈치 안 보이는 게 맘에 든다.

아이폰, 갤럭시, 넥서스, 베가, 옵티머스 등 폰과 태블릿 디바이스 약 100개가 구비돼있어 웬만한 기종은 다 테스트해볼 수 있다.

별도의 예약 없이 그냥 와서 선착순으로 자리 잡고 쓰면 된다. 시간 제한 그런 거 없ㅋ슴ㅋ.
단점이라면 근처에 밥 먹을 만한 곳이 없다. 앞에 급식형 밥집이 하나 있는데 맛이 없ㅋ슴ㅋ.

여기 말고도 테스트베드 지원하는 센터가 몇 군데 있는데, 내가 정리해놓은 곳은 아래와 같다.

 

-테스트베드 지원 센터

 

1. 앱창작터 스마트폰 테스트베드: 가산에 위치 / 여긴 기기 대여도 가능.
http://www.changupnet.go.kr/home/appnurim/book/equipList.do

 

2. 앱센터 (비영리기관): 강남에 위치 / 여긴 스마트워치 등 웨어러블 기기도 보유.
http://appcenter.kr/archives/736

 

3. SK상생혁신센터: 서울대 내 위치 / 여긴 학교 안이라 예약이 좀 빡빡하다.
https://oic.skplanet.com/front/mdrsrv/dailyMDRsrv.action

 

4. 서울앱창업센터: 건대 옆 성수동 위치 / 지금 있는 내가 앉아있는 곳으로, 가장 추천하는 곳이다. 센터 내에 인큐베이터가 있어 평일 10시부터 저녁 11시, 토/일 저녁 6시까지 열려있다.더불어  1~2만원으로 제품촬영실과 장비를 쓸 수 있고, DSLR은 대여도 해준다.

http://www.seoulappcenter.co.kr/?page_id=50

 

봄블링이 글로벌 마케팅 지원사업에 선정됨에 따라 샤오미 보유한 곳을 찾아봤는데, 아쉽게도 아직까진 한 군데도 없다.
우리나라에선 아직까지 샤오미의 무서운 기세에 대해 너무 무감각한 것 같다.

 

이런 지원센터들 중엔 테스트베드 외에도 오프라인 공간을 빌려주는 곳도 있다.
나중에  서포터즈 같은 거 운영하면 모일 장소가 필요할테니 이것도 알아두면 나쁘지 않다.

 

-오프라인 공간 무료 대여

 

1. 본투글로벌

https://www.born2global.com/

 

2. 스타트업 얼라이언스
http://startupall.kr/contact/#contact6

 

3. 기타 각종 창업보육센터 회의실은 말만 잘하면 빌려줌

 

4. 스마트세계로누림터: 여긴 스튜디오 및 고가의 촬영장비를 무료로 지원해준다. 가서 앱이라고 뻥치고 여자친구 화보를 찍어주자.
http://platum.kr/archives/31969

 

 

Standard
□ For the rest of us

스타트업의 겨울나기

지금 나는 전기방석에 위에 쪼그리고 앉아있다. 쪼그린 이유는 발가락이 시려워서다. 전기방석에 녹이는 중이다.
무릎엔 담요를, 그 위엔 또 외투를 덮고 있다. 키보드 치는 손엔 손가락 끝만 나온 장갑을 끼고있다.

슈밤… 춥다.
여자친구가 없어서 더 춥다.

난방기구가 있긴 하지만 꼴에 남자라고 여직원 쪽에 두었다. 난방기구 이름은 ‘헬런’이다. 여자 이름이라서 그런 건지 나완 인연이 없다. (엉엉)

센터 같은 곳에 입주한 스타트업이 처음으로 부러워진 시기다. 우리 사무실은 춥다. 근처가 한강이고, 5층인데다, 창도 많아서 그렇다. 여름엔 에어콘 안 틀어도 선선하고 참 좋은데.

겨울철 난방비를 무시할 수 없는 우리같은 가난한 스타트업은 몸으로도 좀 때워야 된다. 헝그리정신! (콧물을 마시고 있다…)

그래서 오늘은 사무실 온열기구 구입에 관한 별 거 아닌 팁을 남겨보고자 한다. 진짜 어마어마하게 별 거 아니다.

 

1. ‘USB 온열기구’를 사자! 

USB 곰발바닥, USB 장갑, USB담요 등 USB 온열기구를 추천한다. 일단 무척 싸다. 거기다 전기세가 안 나간다.
가격대비 효율은 이거만한 게 없다.

특히 곰발바닥 강추다. 발만 따뜻해도 한결 낫다.
두 가지 주의할 점이 있는데, 살 땐 소형, 대형 중에 대형을 권한다. 소형은 넘 작다. 얼마 차이 안 나니까 대형을 사자.
그리고 이게 싸다보니까 내구도가 인정사정 없이 약하다. USB 선 안 끊어지게 조심하자. -_-

 
2. 무릎담요도 같이 사자.

싸다. 난방비 안 든다. 얇은 무릎담요라도 생각보다 훨씬 따뜻하다.
아주 저렴한 극세사 담요를 샀는데 첨엔 얇아서 괜히 샀나 했다가 써보고 감동했다.

 
3. 온열기구는 제품 가격보다도 전기를 얼마나 처먹는지가 더 중요하다.

그래서, 라디에이터는 권하고 싶지 않다. 또 살 거면 ‘회전’이 되는 걸 사는 게 좋다.
정리하면, 온열기구의 3요소는 (1)전력효율 (2)온열면적(회전) (3)가격 되시겠다.

헬런은 다 좋은데 회전이 안 된다. 도도한년 같으니…

 

4. 창문에 뾱뽁이를 붙이자.

가격대비 효율의 최강자는 뾱뾱이다. 찬공기를 쳐내고 더운공기를 되돌려보내기 때문에 내부온도가 최소 1도 이상 오른다.
우린 몰라서 젤 싼 거 샀는데, 나중에 보니 3겹 4겹 뾱뾱이도 있었다. 가급적 여러 겹으로 사는 것을 권한다.

 
5. 여자친구를 사겨라.

슈밤..

 
6. 비타민을 챙겨 먹자.

우리는 비타민은 최고급으로 참 잘 챙겨먹는다. 확실히 먹는 게 덜 피곤하고 감기도 안 걸린다. 겨울엔 특히 잘 챙겨 먹고 힘내자.

 

 

Standard
□ For the rest of us

지재권, 딱 알아야 될만큼만 쏙 빼먹기

매주 토요일마다 ‘상천이형의 토요특강’이란 걸 하고 있다.

내가 어디서 주워듣고 오거나 공부해서 알게 된 스타트업 관련 지식들을 공유하는 시간이다.
일주일에 한 번은 머리도 식힐 겸 개발과 무관한 장르에 대한 감을 잡으며 노는 거다.

그중 지식재산권에 대한 내용을 정리해 공유해본다. 여기 있는 내용만 알아도 초기 스타트업 운영하는 데는 전혀 지장 없다.


 


 

 지재권, 딱 알아야 될만큼만 쏙 빼먹기 

 

by 상천이형®

from 상천이형의 토요특강

 


 

 

졸라 오그라드는 이것은 제목 페이지다.  그대로 가져다 넣었다. 왜냐?  당신께 질문을 하나 드리기 위함이다.

 

Q: 위 ®과 ™은 무엇을 의미하는 마크인가?


이 질문에 답하실 수 있으신가? 그럼 오늘 내용이 이해하기 쉬울 것이다.
만약 답을 못했다 하더라도 전혀 문제 없다. 오늘 배우면 되니까.
답은 끝에 알려드리겠다. 자, 가보자 ㄱㄱ

 

       1. 특허의 종류

 

IT스타트업이라면 특허는 크게 특허(+실용신안)/상표권/디자인권 3가지가 있다고 정리하면 된다.
분야별 저작권(ex. 건축물저작권, 어문저작권 등)이란 것도 있긴 하지만 그건 필요할 때가 되면 그때가서 공부해도 무방하다. 특허/상표권/디자인권이 뭔지 모르는 사람은 없을테니까 개론적인 얘기는 생략하겠다.

 

(1) 특허 (+ 실용신안)

 

입 아프게 특허의 정의나 취지 등은 설명하지 않겠다.
개론적인 이야기는 쫌만 검색만해도 다 나오는데 굳이 나까지 쓸 필요는 없는 것 같다. 포인트만 간략히 요약하겠다.

– 특허의 구성요소는 신규성 & 진보성이다. (+산업상 이용가능성. 이건 뭐 당연히 적용되는 거다.)

– ‘불’은 특허가 없다. 돌이나 열역학 제2법칙도 특허 없다. -> 자연현상의 단순발견은 특허로 인정되지 않는다.

– 특허등록은 결국 ‘설득력’ 문제다. 특허는 내 제품(서비스)이 신규성과 진보성이 있다고 심사역을 설득하는 일의 문제다.

– ‘출원’을 먼저 하는 게 중요하다. 특허분쟁 걸리면 먼저 출원한 쪽이 이긴다.

*특허가 뭔지 혹시 잘 모르는 사람이 있다면 아래 링크 참고.

1. 특허의 정의: http://ko.wikipedia.org/wiki/%ED%8A%B9%ED%97%88

2. 특허/실용신안 심사기준 http://www.kipo.go.kr/kpo/user.tdf?a=user.html.HtmlApp&c=10103&catmenu=m07_01_03

 

-오키 특허는 알겠어. 근데 실용신안은 뭐여?

특허심사가 꽤 오래 걸리니까 ‘심사 없이 등록가능한 비교적 가벼운 대체 특허’ 개념으로 만들어진 것이 실용신안이다. But 지금은 법이 바뀌어서 특허심사가 똑같이 적용됨. 고로 특허와 실용실안은 같은 개념으로 생각해도 무방하다.

실용신안은 제품의 ‘고도성’이 필요없다(ex. 장수돌침대). 즉, 심사가 비교적 널널하다.
그럼 혹시 특허 말고 실용신안 받는 게 개이득??

에이, 근데 실용실안권 등록은 물품(tangible)만 가능하다.

정리하면 아래와 같다.

 

특허 실용실안
효력

비슷

비용

비쌈

저렴
보호기간

20년

10년

심사강도

상대적으로 높음

상대적으로 널널

범위

BM특허도 가능

물품만 가능

 

(2) 디자인권

– 디자인권 받으려면 ‘공업상 이용가능성’이 인정돼야(찍어낼 수 있어야) 한다.
ex) 아파트디자인 얜 디자인권 X. 건축저작물 O.

– 디자인권 출원할 때 꼭 무색으로 내자. 색을 안 넣고 제출해야 권리범위가 더 넓다.

 

(3) 상표권

– 상표권: 기호, 문자, 도형, 입체적 형상, 색체 + 홀로그램, 동작, 소리상표, 냄새상표 (오호 소리와 냄새도 상표가 된다)

– 상표=서비스표: 상표권 등록을 해보면 처음에 상표는 뭐고 서비스표는 뭔지 헷갈리게 될 것이다.
둘이 똑같은 거다. 다만 사업영역에 따라 분류가 다를 뿐이다. -> 1~34-상품류 / 35~45-서비스업류

– 10년간 보호. 갱신 가능.

– ‘보통명칭’은 상표가 될 수 없음.

ex. 종로학원: 상표등록 안 돼서 ‘종로M스쿨’로 개명했다.
신당동떡볶이: 이런 일반명사는 상표등록 불가능. 너도나도 원조라고 우기게 된 배경이다.

 

- 만약 서비스 이름이 영어라면, 한국어와 영어 동시에 등록이 될까?

상표등록에선 이 부분이 가장 지랄같은 부분이다. 잘 알아둬야 한다.

우선 상표에 영어와 한글이 섞인 경우 개별신청/혼합신청 둘 다 가능하다.
ex. (1) 봄블링 (2) bombling (3) 봄블링 bombling 셋 다 가능.
But 혼합신청 하는 경우엔 혼합해서 쓴 상표(3)만 보호받을 수 있다. 만약 경쟁사가 한글(1) 혹은 영어(2)만 쓴다면 제제할 수 없다.

-> Then how? : 당연히 한글, 외국어 따로따로 등록하는 게 가장 안전하다.
한푼이 아쉬운 초기스타트업이라면 메인로고의 언어로 등록하는 것을 추천한다.

 

- 동일한 상표라 해도 장르(1~45류)가 다르면 등록할 수 있다.

키프리스(특허청에서 운영하는 특허검색 사이트: http://www.kipris.or.kr/) 에서 ‘카카오톡’을 검색해보면 웬 주류판매업까지 다 등록이 돼있다.
사업영역이 다르면 동일 상표라도 다 등록이 가능한 것이다(But 유사성이 높은 장르는 심사에서 탈락된다). 웬 주류판매업 같은 장르에 카카오톡이란 이름을 등록해둔 사람은, 물론 혹시 돈 될까 싶어서다.

-> Then how? :  유사 장르는 여러 개 등록해두는 게 안전하다. 상표권 출원비 부담이 없다면 그냥 싹다 해놓자.
ex. 봄블링은 9류:컴퓨터 소프트웨어와 45류:법인서비스 둘 다 등록해뒀다. (앱은 일단 이거 두 개만 해놓으면 거의 안전하다고 봐도 된다.)

 

상표권 등록 팁을 하나 드리자면, 키프리스에서 특허를 검색해보면 변리사 사무실을 통해서 등록했는지, 스타트업 팀원이 직접 한 건지도 나온다. 동종업계 경쟁사들을 검색해서 그중 변리사사무실을 통해 등록한 곳을 찾자. 몇 개 비교해보고 걔들이랑 똑같은 장르를 등록해두면 된다.

또 하나. 하나의 특허 기본료당 20개의 ‘지정상품’을 등록할 수 있으니 가급적 걸칠 수 있는 건 다 넣어두자. (지정상품이 뭔지는 해보시면 금방 안다. 쉽다. 여기선 그냥 이렇게만 한번 보고 지나가시면 된다.)

103


 

 2. 선출원주의와 국지주의 원칙

 

한국을 포함 중국, 미국 등 대부분의 국가는 파리협약에 따라 ‘선출원주의, 국지주의’를 원칙으로 한다.

 

-선출원주의: 먼저 등록하는 놈이 임자란 소리.
즉, 내가 먼저 개발한 기술이라 한들 나보다 먼저 경쟁사에서 등록해버리면 경쟁사가 권리를 갖게 된다.

ex. 티몬 케이스

5월 10일 티몬 사이트 정식오픈. 보름 후 상표등록 신청함.
한데 경쟁사에서 5월 11일에 먼저 출원한 사실을 뒤늦게 알게 됨.
(아예 엿 먹일라고 티몬 페이지 접속해서 로고 우클릭-저장 한 다음 특허청에 제출).

-> 티몬 상표권이 경쟁사의 권리로 넘어감, ‘티켓몬스터’라는 이름을 사용하지 못하게 될 위기에 처함. 경쟁사 측에선 짭짤한 걸 요구함. 결국 “사이트 이름을 바꿔야 하는데 어떤 게 더 좋겠냐”고 공지 배너 띄워서 유저투표까지 했음.

-> 이때 시리즈A 투자자들이 들어온 시기였는데 “뭐야 병신들아 빨랑 해결해”하며 투자가 미뤄짐. 그러나 인생은 참 재밌음. 티몬에게 운이 따름. 이게 노이즈마케팅이 돼서 다음달 매출액 500% 상승. 벨류에이션 다시. (…) 우여곡절 끝에 결국 티몬 이름 계속 사용.

->> 교훈: 오픈 전에 BM특허 등의 특허권과 아니면 최소한 상표권, 로고 디자인권 출원은 마쳐두자.

 

-국지주의: 한마디로 지재권은 국가별로 다 따로따로등록해야 한다는 거다.


 

 

      3. 경쟁업체의 지재권 공격 방어법

  

(1) 경쟁업체가 특허로 공격 들어오면 원천을 찾아내서 무효화 신청을 할 수 있다

쉽게 말해 특허권자(경쟁업체)가 특허를 낸 시점 이전에 먼저 그 기술을 사용한 곳이 있다는 사실을 입증하면 상대방의 특허 자체가 말소되는 것이다.

-> 사례: 마소 vs IBM(승), 미유테크놀로지 vs 카카오(승).

*But 입증 자료 찾을라면 졸라 노가다해야 함.

 

(2) 특허등록 돼있어도 3년간 사용한 흔적 없으면 말소시킬 수 있다.

‘3년불사용취소심판이란 게 있다. 쉽게 말해 ‘지재권 헌터 방지법’이다. 특허등록을 해놓고 3년동안 안 쓸 경우 걸 수 있다. 특허권자가 3년 내에 썼다는 걸 입증 못하면 말소.

 

(3) 국제특허 헌터, 6개월은 걱정 없다

지재권이 기본적으로 국지주의를 원칙으로 하긴 하지만, 파리협약 가입국(앱 팔 수 있는데는 다 가입국이다)이라면 6개월간의 타국 특허출원 우선권을 갖는다. 즉, 한국에서 1월에 상표권을 출원했다면, 7월까지 미국 등 외국에서의 상표권 출원 우선권을 갖는 것이다.


 

 

     4. 국제특허와 PCT

  

특허는 국지주의이기 때문에 보호 받으려면 국가별로 내야 한다고 했다. 그러나 여기서 문제점 노출. 미국 내에서 잘 되는 사업을 보고 중국 내 헌터가 특허 내버리면?

이런 경우를 막고 권리 보호를 위해 PCT(국제출원제도) 라는 게 만들어졌다.


-
국제출원제도: 쉽게 말해 여기 특허 출원을 넣으면 PCT 가입국가 150 개국 모두에 출원하는 효과를 획득하는 것이다. 최초 출원일부터 30개월 간 권리를 보호해준다(=2년 6개월간 시간을 확보).

*But 변리사들은 “3개국 이상 출원할 것 아니면 그냥 국가별로 하는 게 낫다”고 조언함.

 

-> 여기서 문제.

Q: 그렇다면 국가별로 다 출원해야 하나? 스타트업 돈 없는데…

A: 글로벌진출에 대한 확실한 계획이 있다면 최소한 미국은 해두는 게 좋다.

 

만약 특허 침해에 걸렸을 때 다른 국가들은 ‘손해 본 만큼만 배상’을 원칙으로 하지만 미국은 ‘징벌적 배상’을 원칙으로 한다. 때문에 엄청나게 큰돈을 물어내야 하는 불상사가 종종 생긴다.

특히 미국엔 소위 ‘특허괴물(비생산기업)’이 중국 다음으로 많다. 특허 사모아서 풀 만들어놓고 나중에 “너네가 우리 특허 침해하고 있다. 로열티 내놔라”라고 연락하는 게 얘네들 일이니 조심하자.

*얘네들 땜에 구글과 IBM이 Intellectual Ventures라는 특허 방어 펀드를 만들기도 함. 우리나라엔 Intellectual Discovery가 이런 역할. 자회사가 바로 아이디어 브릿지.


 

 

         5. 비용은 얼마?

 

특허 등록하는 데는 특허청에 내는 ‘출원신청비‘, ’등록비’와 변리사한테 주는 ‘출원비’, ‘등록포상금(성공보수)’이 들어간다. 더불어 등록이 완료된 특허엔 매년 ‘특허유지비(연차료)’를 내야 한다(못 내면 권리 상실).

 

-지재권 비용 요약

※모든 비용은 1건, 전자등록 기준. 서면등록, 부분심사, 가산료 등의 옵션에 따라 비용 달라질 수 있음.
특허로 수수료안내 페이지 참고. http://www.patent.go.kr/jsp/ka/menu/fee/main/FeeMain01.jsp

 


(1)
특허 (BM특허 기준. 일반특허는 항목당 50만원 정도씩 더 쌈)

BM특허는 일반적인 경우 400~600만원 들어간다. 특허내용과 특허사무실 끕에 따라 다르다.

 

등록비: 몆 만원

출원비: 200만원 내외(청구항 개수 등 ‘얼마나 품이 들어가는 특허냐’에 따라 비용이 조금씩 달라짐)

성공보수: 출원비의 70~100% (요샌 대부분 100%)

특허유지비: 연 30만원 내외

+

거절이유 대응비: 1회당 30만원 내외

우선심사 신청비: 사유에 따라 50~150만원

 

(2) 상표권

-변리사 통해서 했을 때: 착수시(출원까지) 2~30만원. 등록되면 동일한 비용의 성사금. 의견서 제출, 우선심사 청구 등 하면 추가비용.

-개인이 했을 때: 특허 1개당 출원까지 6만2천원(지정상품 20개 초과 시 1개당 2천원 추가). 등록비 세후 약 22만원.

 

(3) 디자인권

개인: 출원 9만4천. 등록비는 7만5천원부터 시작해 해마다 몇만원씩 비싸짐.

 

(4) 국제특허 & 해외 상표권

-국제특허: 500백~1천만원. (특허종류, 사무실 끕마다 다름)

-해외상표권: 200만원 내외.


 

 

       6. 변리사 없이 직접 할 순 없을까?

 

할 수 있다.
그러나 BM특허의 경우 변리사 통하는 게 낫다. 공부할 게 많아 스타트업 팀원이 하기엔 비효율적이다.
또한 특허법을 잘 모르는 일반인이 어설프게 하면 등록됐다 하더라도 있으나 마나한 특허가 될 수도 있다.

 

상표권, 디자인권은 직접 하자. 쫌만 공부하면 된다. 우리같은 초기 스타트업은 한푼이 아쉬운데 괜히 돈 쓰지 말자.


 

 

       7. 중국 지재권 핵심 요약

 

봄블링은 중기청의 글로벌마케팅 사업 지원을 받고 있다. 중국에도 동시 출시할 예정이다.
그래서 관련 중국 지재권에 대해 어느 정도 숙지하고 있는데, 여기에 포인트만 간략히 요약해둔다.
솔직히 말하면 복잡한 건 우리도 잘 모른다.

 

※ 중국은 시진핑 체제 이후 법치주의 중시 풍조가 확산되고 있음. 2014년 중순 상표법 개정으로 상당히 개선 됨.

※ 중국 법인설립에 관한 내용은 생략하겠음. 관심있는 사람은 ‘시나 스트럭처’에 관해 알아보시면 됨.

 

- 중국도 파리협약 가입국가다. 속지주의, 선출원주의.

 

- 상표권 등록에 필요한 서류

  1. 위임장 (출원인 날인, 2부)
  2. 출원인의 사업자등록증 사본(출원인 날인, 2부, 한국사업자등록증)
  3. 상품견본 (서명한 전자문서)
  4. 지정상품 또는 서비스
  5. 출원인의 영문, 중문 명칭 및 주소

 

- 상표등록 소요기간

접수일로부터 9개월 내에 기초 심사절차를 거쳐 거절사유가 없을 시 상표등록 출원을 공고함.

공고일로부터 3개월 내에 이의가 제출되지 않으면 상표 등록 완료. (이의제출 시 3~4년 걸릴 수도)

 

- 유의점

한국기업이 한국에서 처음 상표등록을 출원한 날로부터 6개월 내에 중국에서도 동일 상품에 동일 상표의 등록출원을 제출할 경우 파리협약에 따라 우선권이 부여됨.

사업과 밀접히 관련된 다른 상품류도 지재권을 획득할 필요가 있음.

중국은 벌금이 졸라 싸서 모방업체와 헌터들이 드글드글 함. ‘3년불사용취소심판’ 등 헌터 대응책 알아둘 필요 있음.

※ 바이두에서 지역 이름 + 공산행정관리국 검색하면 기업의 신용도 볼 수 있음.
※ 홍콩은 중국 귀화 이후 경제적으로 손해를 봤기 때문에 중국에서 홍콩에 각종 혜택을 주고 있다. 이게 홍콩경유의 이유.
※ 중국에서 3만불 이상 매출 발생 시, 약 15%의 세금을 내고 증명서를 받아야 한국으로 돈 뺄 수 있다.


 

 

        8. 난 쫌더 공부해서 똘똘이가 될래!

 

※ 핵심의 핵심만 정리함. 더 자세한 내용을 원하시면 이메일 주세요. 각종 정리해둔 파일을 통째로 보내드리겠습니다. (coo@slogup.com)

 

 

특허권 공유: 특허도 주식처럼 ‘지분’ 개념으로 여러 사람이 나눠가지거나 양도할 수 있음.

 

– 1년 20만건의 특허를 800명 심사관이 전부 봐야 한다. 지재권 서류도 재밌게 써라.

※페인킬러: 심사관을 지루함으로부터 잠시 해방시켜주는 재밌는 지원서. 의외의 승리를 거두기도 한다.

 

– 보통 선행기술 서치는 변호사들한테 맞기면 30분정도 한다 함. However, 심사관들은 6시간 이상 털어본다.

-> 선행기술 조사에 돈 쓰지 말자키프리스와 구글링으로 직접 몇 시간 해보면 충분하다.

 

– 특허의 구성요소 둘 중 하나인 신규성 박람회, 대회, SNS포스팅 등에서 오픈되는 순간 상실된다.

-> 박람회, 창업대회 나가기 전에 지재권 확보 필수.

 

– 대기업이랑 합작해서 같이 공동발명 했다. 근데 얘네가 말도 없이 해외출원 혼자 하면 소송 걸 수 있다.

 

– 공지예외주장출원을 알아두자 (신규성 상실 예외 적용)

이거 걸면 발명의 내용을 공개한 후에도 특허출원을 할 수 있다.

공개시점 1년 이내에만 신청할 수 있음(별도 비용추가 X).

but 공개시점부터 공개예외신청 시점 사이에 내 기술보다 더 뛰어난 게 나왔으면 무효될 수도.

 

– 우선심사 신청: 급행료 60만원 내면 3개월만에 등록 해줌. 최소 프로토타입 필요.

-> 투자, 제휴 유치 등을 앞두고 있는 상황이라면 이거 해야될 때도 있다.

 

– 구성요소가 많으면 권리범위가 줄어든다. 권리범위가 줄면 등록가능성은 높아진다.

 

– 하나의 제품이라도 요소들을 나눠 여러 개의 특허를 등록해 파트별로 개별 보호해야 카피켓을 확실히 막을 수 있다.

-> 키프리스에서 ‘한경희 스팀청소기’를 검색해보시면 이해가 될 것이다. 청소기 하나에 부품마다 다 개별적인 특허가 등록돼있다.

 

 

휴 기네. 자 끗!

 

아 맞다 퀴즈.
®은 Registered, 즉 특허등록이 완료된 상태를,  ™은 Trade Mark, 즉 특허출원 상태를 표시하는 기호다.

 

진짜 끗!

 

5 copy

마무리는 안구정화. *-_-*

 

 

 

Standard
□ For the rest of us

9가지 정부지원서류 합격 팁 – 시의적절한 정부지원사업은 개이득

 

음 무슨 얘길 써볼까 고민하다가 가끔씩은 뭔가 실용적인 정보들을 공유하면 좋겠다는 기특한 생각을 하게 됐다(헐 내가 이런 생각을). 흐흐 맨날 드립만 칠 순 없지 않겠는가.

 

개발에 관한 내용들은 화랑이가 포스팅하고 있으니 여기선 개발 외적인 내용들을 다루려 한다. 마케팅, 지재권, 정부지원, 법률, 데이터분석 등 스타트업 하면서 알아야 할 내용들을 끄적여 볼 참이다. 실은 나도 별로 아는 게 없으니, 경험(a.k.a 삽질)을 통해서 깨달은 내용 + 잘 아는 사람들 말을 집중해서 듣고 꼼꼼히 옮겨적는 전략으로 갈 거다.

 

2217_3943_1324

 

창조경제 만쉐!

 

‘지금처럼 창업이란 걸 하기 좋은 시기가 앞으로 또 올까?’ 지금까지 이런 생각을 나는 꽤 여러 번 했다. 닷컴붐 때보다도 지금이 더 좋은 것 같다. 창업시기별 정부지원 프로그램, 각종 무료 교육과 강연, 인큐베이터 & 엑셀러레이터, 엔젤투자 등등. 열심히만 하면 주변에서 물심양면 도와주는 알흠다운 세상이다.

 

그중 예비창업자 & 초기 스타트업한테 가장 도움 되는 것 중 하나가 정부지원이다.

 

슬로그업은 지금까지 5건의 정부지원을 받았다. 창업자금 및 시제품제작비 지원(창업선도대학), 인건비 지원 2건(성장유망산업, 청년창직인턴제), 마케팅 지원(타깃국가 현지화 및 글로벌마케팅 지원사업), 멘토링 지원(Born global 스타트업 캠프) 등이다. 중복지원 불가 등의 이유로 서류는 통과했으나 포기한 사업도 몇 개있다. 잠깐 손을 멈추고 기억을 돌아보니 그동안 총 9개의 정부지원 서류를 썼고, 그중 제일 처음에 썼던 서류를 제외한 8개가 합격했다.

 

정부지원 서류평가는 포인트 몇 가지만 확실히 챙기면 통과하기가 그렇게 어렵지 않을 수 있다. 내가 생각하는 중요한 포인트를 정리하면 이렇다.

 

 

  1. 정부지원 서류를 ‘20장짜리 잡지 한 권이라 생각하고 접근하자.

 

IMG_0466

스스로 마치 잡지 편집장이 된 듯한 느낌으로 전체를 바라보자. 잡지를 만드는데 있어 가장 중요한 3요소는 콘텐츠, 레이아웃, 사진이다. 정부지원 서류도 꼭 같다. 읽기 편한 레이아웃을 짠 뒤 그 속에 사업 아이템이라는 콘텐츠를 짜임새 있게 정리하고, 적재적소에 이미지를 배치하면 된다.

 

더불어 ‘20장 잡지’로서의 접근은 전체적인 통일성과 완결성을 가져다준다. 내 사업아이템을 설명하는 이 잡지에서 논리의 흐름은 어때야 하는지, 잡지 전체를 봤을 때 어느 정도 시점에서 어떤 내용이 들어가야 하는지 생각하면 서류의 구조가 잡힌다.

 

  1. 여백은 없어도 되는 부분이 아니다.

여백은 그냥 빈 칸이 아니다. 나는 여백이 당락에 영향 미치는 중요한 요소 중 하나라고 생각해 글을 줄이는 경우가 있더라도 여백은 꼭 넣었다. 여백의 역할은 ‘레이아웃’ 구성이다. 사이 공간 없이 빽빽한 글을 보면 피로감이 들게 마련이다. 첫 인상에서 ‘읽기 싫다’는 느낌을 주면 심사역이 콘텐츠를 평가하는데 있어 좋게 작용할 리가 없다.

 

자, 당신 책상 왼편에 서류가 3.5m 높이로 쌓여있다고 상상해보자. 당신은 겨우 몇 시간 안에 그 서류를 전부 읽고 점수 매겨야 한다. 넉넉잡아도 서류 하나 당 할애할 수 있는 시간은 5분 이내다. 재미없고 빡빡한 서류들을 읽어나가는 동안 당신의 집중력은 점차 떨어진다. 눈도 뻑뻑하고 머리도 아파오기 시작한다. 잠깐 안경을 벗어놓고 슬쩍 보니 아직도 서류는 2.5m 이상 남아있다.

 

이게 실제로 심사역들이 겪는 고충이다. 정부지원 서류가 반드시 친절해야 하는 이유다. 친절해보이기 위해 내가 썼던 방법을 소개하면 이렇다.

 

(1) 문장을 짧게 썼다. 내용이 길면 중간에 끊고 새 문장에 썼다.

(2) 챕터의 시작과 끝, 문단의 사이사이에 적당한 여백을 넣어줬다.

(3) 여백과 더불어 제목과 내용의 폰트를 다르게 해서 ‘레이아웃’을 구성했다.

(4) 이미지, 사진, 표, 차트 등 비문자로 설명할 수 있으면 텍스트를 최대한 줄였다. 또 글이 너무 빽빽하다 싶으면 관련있는 이미지를 억지로 구해서라도 중간에 배치했다.

(5) 계속 읽어보고 졸라 많이 고쳤다. 심사역 코스프레 하면서 이해안될 것 같은 부분, 불편할 것 같은 부분을 수십 번 수정했다.

 

Less-is-More

 

  1.  모든 내용이 들어가야 할 필요는 없다. 강조하고 싶은 내용만 강조하면 OK.

창업자 입장에선 다 중요하다. 그래서 어떻게든 놓치지 않고 모든 내용을 말해주고 싶어 한다. 그러나 같은 사업군의 수많은 서류를 보는 심사역 입장에선 다 그 내용이 그 내용일 수밖에 없을 것이다. 차라리 덜어낼 부분은 과감히 덜어내자. 강조하고 싶은 것 딱 몇 가지만 확실히 각인시키자. 안해도 될 내용까지 다 우겨넣어서 시선을 분산시키지 말고 딱 중요한 거 몇 가지만 임팩트있게 꽂아주자.

 

 

  1. 창업자와 팀 소개, 아이템 소개, 수익모델이 가장 중요한 항목이다.

중요한 항목을 딱 세 가지만 꼽자면 이거 세 개인 것 같다. 시장조사, 마케팅 전략 등은 상대적으로 덜 중요하고, 상황에 따라 아예 안 읽는 심사역도 있다고 들었다. (실제로 시장조사 부분에서 문단 전체를 잘못 복사 붙여넣기 한 상태로 냈었는데 통과한 경험이 있다.) 시장조사처럼 품이 많이 드는 항목에서 시간 뺏기지 말고 아이템 소개에 우선순위를 두자.

 

 

  1. 쓰기 전에 합격 사업계획서를 먼저 읽어보자.

당연한 얘기지만 이건 구하기가 쉽지 않다. 경험상 아무리 구글링 돌려도 잘 안 나온다. 성장유망산업 서류 쓸 때 딱 한번 인사담당자 모임 카페에서 찾은 적이 있었다. 그 외엔 몇 시간 구글링 해도 안 나왔다.

 

유일하게 두 군데서 나온다. 크몽 같은 재능판매 사이트와 비즈폼 같은 곳에서 5천원~몇 만원에 파는 유료자료들이다. 나는 짠돌이라서 그냥 무료로 볼 수 있는 장까지만 보고 내려받진 않았다. 무료로 볼 수 있는데까지만 봐도 감 잡는데는 충분하다. 그러고 나서 정부지원사업 홈페이지에 들어가 사업 담당자들이 올린 그 해 사업 공고 및 여러 설명 자료들을 내려받아 읽어본 뒤 그 정도의 톤과 양식으로 작성했다. 합격했으니까, 결과적으로 이건 괜찮은 전략이었다.

 

*혹시 합격 서류 찾다 못 찾아서 여기까지 흘러오신 분이 있으면 리플 남겨주세요. 이메일로 보내드릴게요. 대신 합격하면 소개팅좀 시켜주세요.

 

photo

 

 

  1. 마감까지 여유가 있다면 다 쓴 뒤 바로 보내지 말고 며칠의 시간을 두고 다시 읽어보자.

두 가지 이유 때문이다. (1) 글은 고칠수록 좋아진다. (2) 초고 작성을 막 끝낸 후엔 오류가 잘 보이지 않는다. 이건 정부지원 서류의 문제가 아닌 글의 속성이기 때문에 모두 이해하는 내용일 것이다. 길게 설명하지 않겠다.

 

 

  1. 전반적으로 쉽게 쓰자. 그러나 어려운 단어도 사이사이 넣어주자.

논술공부 해본 사람이라면 이해할 것이다. 논술이랑 똑같다. 전반적으로 쉽게 쓰면서도, 사이사이 고급어휘를 섞어주면 있어보이고 좋다.

 

 

  1. 웬만하면 법률사무소나 재능판매자한테 맞기지 말고 쓰는 훈련을 하자.

 

10632452_1458175161113123_233515159_a

 

페이퍼웍에 정말 끔직하게 자신 없고, 지원금은 반드시 필요한 절박한 경우가 아니라면 맡기지 말고 내가 하자. ‘학습’의 문제 때문이다. 못한다고, 자신없다고 안 하면 계속 돈 써야 한다. 나중에 IR을 하든 뭘 하든, 내 사업을 정리하고 설득력있게 언어로 풀어내는 능력은 꼭 필요하다. 괜히 쫄아서 이런 좋은 연습기회를 건너뛰지 말자.

 

당연한 말이지만 정부지원서류도 쓰다보면 는다. 내 경우, 20장 내외 지원서를 처음 쓸 때 1주일 잡고 썼었다. 꽤 머리를 싸매고 열심히 썼는데 떨어졌다. 마지막으로 낸 동일한 분량의 지원서는 거의 하루만에 아주 쉽게 썼다. 그리고 합격했다. 쓰다보면 일종의 프레임워크가 생긴다. 쓰다보면 늘고, 늘고나서 보면 별 거 아니다.

 

더불어 지원서를 쓰는 동안 내 사업아이템을 일목요연하게 정리하게 된다. 양식에 맞춰 쓰다보면 생각지 못했던 부분까지 들여다보고 보완하게 된다. 즉, 결과적으로 서류 통과 후에 있을 PT에 크게 도움 된다.

 

 

  1. 존댓말, 반말, 축약문 여부는 상관 없다.

난 이게 정말 궁금해서 한참 찾아보고 물어봤는데 알려주는 데가 없었다. 결국 알아낸 답은 ‘상관없다’는 거였다(슈밤..). 존댓말(이거 졸라 좋은 사업입니다), 반말(이건 졸라 좋은 사업이다), 축약문(이건 졸라 좋은 사업임) 셋 다 써봤고, 셋 다 붙어봤다. 이건 전혀 상관없는 듯하다.

 

끗! 헥헥.. 분량조절 실패할 줄 알았다.

Standard
□ For the rest of us

Where’re we at

봄블링 제작이 막바지에 이르렀다.
채팅서버 외 몇몇 자잘한 기능만 추가하면 일단 릴리즈 할만큼은 되었다.

당초 계획한 릴리즈 날짜는 11월 중순이었다. 흐흐 그러나 당연히도 계획대로는 되지 않았고 무사히(?) 한 달 정도 지연될 것 같다.

안드로이드와 아이폰 클라이언트를 같이 만들고 있는데, 아이폰 쪽이 좀더 빠르다.
중기청의 글로벌마케팅 지원사업에 선정됨에 따라 그간 중국시장에 내놓을 아이폰에 중점을 뒀기 때문이다.
그랬더니 지원사업 일정이 지연되고 있다. 역시 될놈은 된다. *^^*

봄블링은 ‘게임데이팅’이다. 소셜데이팅에 게이미피케이션 요소가 듬뿍 담겨있다.
“데이팅 서비스 만들고 있다”고 말하면 사람들이 반사적으로 묻는 말이 있다. “거기 레드오션 아냐?”

맞다. 소셜데이팅 시장은 대표적인 레드오션이다. 근데 이게 뜯어보면 재밌다.
약 400개에 달하는 데이팅 서비스들은 전부 단  3가지 형태로 나뉜다.

1.  매칭 알고리즘을 통해 매일 정해진 시간에 연결해주는 방식 (이음 등)
2.  LBS 데이팅 (1km, 옷깃 등)
3. 라운드별로 밟아올라가는 ‘이상형 월드컵’ 형태 (너랑나랑 등)

백이면 백 셋 중에 하나다. 혹은 세 가지 요소를 섞었다. 한마디로, 다 똑같이 만든다는 것이다.
더 재밌는 건 디자인도 거의 다 비슷하고(“변태들 하는 앱 아니에요”라고 말하고 있는 듯한 귀염귀염 캐릭터와 여성향 색상)
마케팅도 다 그 밥에 그 나물로 한다.

(최근 이 세 분류에 해당하지 않는 새로운 모델이 하나 나왔다. 윌즘의 ‘관심있어요’라는 제품이다. 윌즘 짜응!)

딱 100만 유저를 놓고 똑같은 비즈니스모델에 똑같은 디자인을 입힌 제품 400개가 똑같은 마케팅을 하고 있는 것이다.
이러면 영락없이 레드오션이다.

landingp_bombling

포토샵 공부하면서 만들어본 페이지. 근데 써먹을 데가 없어 썩혀두고 있다. -,.-

봄블링은 위 세 가지 분류 바깥에 있다. 소셜데이팅이 아니라 ‘게임데이팅’이란 말을 새로 만들어 쓰는 이유다.

미투앱을 만드는 업체한텐 데이팅 시장이 분명 ‘이젠 하면 안되는 레드오션’으로 여겨질 것이다.
우리한텐 아니다. 레드오션이란 말이 ‘저렇게 많은 제품이 몰릴만큼 돈이 도는 시장’으로 해석됐다.
아주 새롭고, 심지어 더 재밌는 모델을 가지고있기에 나올 수 있는 자신감이었다.

그럼 혹자는 이렇게 반문할 수 있다. “그게 더 새롭고 재밌다는 건 너네 생각 아냐?”
맞다. 개발하며 거친 여러번의 클로즈테스트 과정에서 재밌다는 확신을 갖게되긴 했지만, 엄밀히 말하면 아직까진 우리만의 생각이다.

판단은 우리가 아니라 소비자의 몫이다. 결과는 시장이 말해줄 것이다.
지금은 알 수가 없다. 지금은 그저 스스로를 믿고 열심히 또 재미나게 만들고 있을 뿐이다.
우린 아직 많이 부족하기 때문에 남들 일하는 시간의 거의 두배를 일한다. 11시 칼퇴근! (이거 묘하게 중독성있다.)

새로운 팀빌딩 이후 이게 우리의 첫 제품이다.
만약 봄블링이 지금 우리의 한계를 솔직히 드러낸다면, 겸허히 받아들이고 묵묵히 인정하려 한다.
누구나 출발선이 필요한 거니까.

스스로한테 쪽팔린 제품만 아니면 일단 OK!

 

 

 

 

 

 

Standard
□ For the rest of us

For the rest of us

슬로그업이 일하는 하루들을 이곳에 공유하고자 합니다.

언론이나 책이 보여주는 스타트업 이야기들은 대부분이 성공사례입니다.
그쯤은 되어야 지면 한 장을 얻을 수 있죠.
근데 그런 대단한 이야기들, 막상 모아놓고 보면 좀 뻔한 얘기들 아니던가요?

명문대 출신 대표가 대기업을 박차고 나와 성공했다,
누가 수십억 투자를 받았는데 비결이 이러하더라.
대부분 이렇죠.

여기 좀 특별한 이야기가 있습니다.
성공인지 실패인지 아직은 모를 한 스타트업의 이야기입니다.

복잡한 건 잘 모르겠고, 그냥 일하는 게 재밌어서  11시 칼퇴근을 하는 이상한 놈들의 이야기입니다.
쓰고나서 보면 필시 ‘삽질의 역사’가 적혀있겠죠. 우리랑 비슷한 사람들이 보면, 어쩌면 그래서 도움 될 수도 있을 것입니다.
아, 제가 드립 꿈나무라 혹시 재밌을지 모릅니다(아님 말고).

잘난 소수의 뻔한 성공담이 아닌 ‘당신과 우리의 이야기’를 쓰겠습니다.

 

For the rest of us - 작은 성공들과 작은 실패들의 징검다리를 건너는 이야기

‘For the rest of us’ 시작하겠습니다. ^^

*제목은 마이크와 밥의 팟캐스트 ‘STARTUPS: FOR THE REST OF US’에서 따왔습니다.

 

Standard