초기에는 kube-aws가 만들어준 관리자 인증서를 통해 Kubernetes를 관리했는데 역시나 대내외적으로 여건이 바뀌니 변화가 필요했다. 내부적으로는 개발 인력이 늘고 여러 프로젝트가 동시 진행되니 Staging 환경이 급격히 바뀌는데 계정이 하나이니 누가 무슨 작업을 했는지 확인하기 어렵고 외부적으로는 경쟁사의 보안사고 등에 영향을 받아 보안을 강화할 필요가 생겼다. 하여 보안 관련 작업을 여럿했고 그 중 하나가 바로 GitHub와 Kubernetes를 OAuth로 엮는 일이다.기본적으로는 개발자 각자가 자신의 GitHub 계정으로 인증 토큰을 받고 이를 이용해 Kubernetes API에 접근하는 것이다. 전체적인 흐름은 How I built a Kubernetes cluster so my coworkers could deploy apps faster 등을 참고하면 이해하기 그리 어렵지 않다.1. Admin time should be saved (since they are also our developers)2. New users can generate their own credentials without needing the admin3. User credential is always private for security reasons4. Developers have their own space to experiment5. Project spaces can be accessed and changed by multiple users6. In the future, we may want to enable auditing to track changes다만 저들과 달리 Webhook 토큰 인증 플러그인을 직접 짜지 않고 coreos/dex를 이용했다. Dex를 이용하면 GitHub를 비롯해 다양한 OpenID, OAuth 2.0 인증 서비스와 Kubernetes 클러스터를 엮기 쉽다. 더욱이 kube-aws에 Dex가 통합되어서 설치하기도 쉽다.설치하기구구절절 어떻게 설정하는지 설명할 생각은 없는데 회사와 프로젝트에 따라 세부적인 차이가 꽤나 클 수 있기 때문이다. 그러니 대략적인 작업 순서를 간략히 기술하고 끝내려 한다.우선 kube-aws의 cluster.yaml를 보자.# # Enable dex integration - https://github.com/coreos/dex # # Configure OpenID Connect token authenticator plugin in Kubernetes API server. # # Notice: always use "https" for the "url", otherwise the Kubernetes API server will not start correctly. # # Please set selfSignedCa to false if you plan to expose dex service using a LoadBalancer or Ingress with certificates signed by a trusted CA. # dex: # enabled: true # url: "https://dex.example.com" # clientId: "example-app" # username: "email" # groups: "groups" # selfSignedCa: true # # # Dex connectors configuration. You can add configuration for the desired connectors suported by dex or # # skip this part if you don't plan to use any of them. Here is an example of GitHub connector. # connectors: # - type: github # id: github # name: GitHub # config: # clientId: "your_client_id" # clientSecret: "your_client_secret" # redirectURI: https://dex.example.com/callback # org: your_organization # # Configure static clients and users # staticClients: # - id: 'example-app' # redirectURIs: 'https://127.0.0.1:5555/callback' # name: 'Example App' # secret: 'ZXhhbXBsZS1hcHAtc2VjcmV0' # # staticPasswords: # - email: "[email protected]" # # bcrypt hash of the string "password". You can use bcrypt-tool from CoreOS to generate the passwords. # hash: "$2a$10$2b2cU8CPhOTaGrs1HRQuAueS7JTT5ZHsHSzYiFPm1leZck7Mc8T4W" # username: "admin" # userID: "08a8684b-db88-4b73-90a9-3cd1661f5466"우선 GitHub의 Organization Settings 메뉴로 가서 OAuth Apps에 Dex를 추가한다. 이때 Authorization calllback URL은 https://dex.example.com/callback가 된다.GitHub가 준 Client ID와 Client Secret를 cluster.yaml에 적어넣는다.dex: enabled: true url: "https://dex.example.com" clientId: "example-app" username: "email" groups: "groups" selfSignedCa: false # # # Dex connectors configuration. You can add configuration for the desired connectors suported by dex or # # skip this part if you don't plan to use any of them. Here is an example of GitHub connector. connectors: - type: github id: github name: GitHub config: clientId: "GITHUB_OAUTH_APP_CLIENT_ID" clientSecret: "GITHUB_OAUTH_APP_CLIENT_SECRET" redirectURI: https://dex.example.com/callback org: DailyHotel # # Configure static clients and users staticClients: - id: 'example-app' redirectURIs: 'https://kid.example.com/callback' name: 'Example App' secret: 'ZXhhbXBsZS1hcHAtc2VjcmV0'staticPasswords: - email: "[email protected]" # # bcrypt hash of the string "password". You can use bcrypt-tool from CoreOS to generate the passwords. hash: "$2a$10$2b2cU8CPhOTaGrs1HRQuAueS7JTT5ZHsHSzYiFPm1leZck7Mc8T4W" username: "admin" userID: "08a8684b-db88-4b73-90a9-3cd1661f5466"여기서 dex.example.com은 kube-aws가 띄울 dex Deployment와 연결되는 서비스(ELB)의 도메인주소가 되어야 한다. 그런데 kube-aws는 Dex의 External service를 생성해주지 않으므로 아래와 같이 직접 서비스를 생성해야 한다. GitHub가 이쪽으로 콜백을 보내야 하므로 방화벽을 열어야 하고 회사 도메인 인증서를 붙일 것이므로 `selfSignedCa`값은 `false`로 한다.apiVersion: v1 kind: Service metadata: name: dex namespace: kube-system labels: app: dex component: identity dns: route53 annotations: domainName: dex.example.com service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:blahblah service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http service.beta.kubernetes.io/aws-load-balancer-ssl-ports: https spec: ports: # the ports that this service should serve on - name: https port: 443 targetPort: 5556 protocol: TCP selector: app: dex component: identity type: LoadBalancer loadBalancerSourceRanges: - 0.0.0.0/0staticClients / example-app는 Dex에 포함된 예제 프로그램이다. 이를 이용하면 웹 브라우저를 통해 GitHub에 인증하고 토큰을 내려받을 수 있다. DailyHotel/kid 등의 도커 이미지를 사용하면 쉽게 띄울 수 있다. kube-aws는 이 예제 프로그램을 띄우지 않기 때문에 직접 올려야 한다.apiVersion: v1 kind: Service metadata: name: kid namespace: kube-system labels: app: kid dns: route53 annotations: domainName: "kid.example.com" service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:blahblah service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http service.beta.kubernetes.io/aws-load-balancer-ssl-ports: https spec: ports: - name: https port: 443 targetPort: 5555 protocol: TCP selector: app: kid type: LoadBalancer loadBalancerSourceRanges: - 사무실IP/32 --- apiVersion: extensions/v1beta1 kind: Deployment metadata: name: kid namespace: kube-system spec: replicas: 1 template: metadata: labels: app: kid spec: containers: - name: kid image: dailyhotel/kid:latest livenessProbe: tcpSocket: port: 5555 timeoutSeconds: 120 ports: - containerPort: 5555 env: - name: CLIENT_ID value: example-app - name: CLIENT_SECRET value: ZXhhbXBsZS1hcHAtc2VjcmV0 - name: ISSUER value: https://dex.example.com - name: LISTEN value: http://0.0.0.0:5555 - name: REDIRECT_URI value: https://kid.example.com/callback이때 example-app의 REDIRECT_URI는 Dex의 REDIRECT_URI와는 다르다는 점에 주목하자. 옵션의 이름이 비슷하기 때문에 헷갈릴 수 있다. 또한 CLIENT_ID와 CLIENT_SECRET은 cluster.yaml 중 GitHub connector 설정이 아닌 staticClients 설정에서 쓴 값이라는 점도 눈여겨볼 필요가 있다.이 정도만 주의하면 dex를 설치하고 설정하는 것은 어렵지 않다. 이제 인증하는 방법을 알아보자.인증하기웹브라우저로 kid에 방문해서 토큰을 받는다. 첫 화면에서 Login 버튼을 누른 후 GitHub 로그인을 하면 토큰이 나온다.GitHub Public profile 메뉴로 가서 Public email 설정을 확인한다. 공개 이메일이 없다면 하나 추가한다. 로그인시 사용자 아이디로 쓰기 위함이다.kubeconfig 파일을 열고 kubeconfig 파일을 열고 MY_PUBLIC_GITHUB_EMAIL에는 GitHub 공개 이메일 주소를 적고 VISIT_KID_EXAMPLE_COM_AND_GET_TOKEN에는 앞서 받은 토큰을 적는다.apiVersion: v1 kind: Config clusters: - cluster: certificate-authority: credentials/ca.pem server: https://MY_KUBE_CLUSTER name: kube-aws-cluster contexts: - context: cluster: kube-aws-cluster namespace: default user: MY_PUBLIC_GITHUB_EMAIL name: kube-aws-context users: - name: MY_PUBLIC_GITHUB_EMAIL user: token: VISIT_KID_EXAMPLE_COM_AND_GET_TOKEN current-context: kube-aws-context인증 파일의 설정이 정확한지 확인하려면 kubectl --kubeconfig=./kubeconfig version을 실행해보자. 아래와 같이 Client/Server의 버전이 둘다 나오면 정상이다.$ kubectl --kubeconfig=./kubeconfig version Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.1", GitCommit:"b0b7a323cc5a4a2019b2e9520c21c7830b7f708e", GitTreeState:"clean", BuildDate:"2017-04-03T20:44:38Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.2+coreos.0", GitCommit:"79fee581ce4a35b7791fdd92e0fc97e02ef1d5c0", GitTreeState:"clean", BuildDate:"2017-04-19T23:13:34Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}참고 자료johnw188/dex-exampleKubernetes / Authenticating#데일리 #데일리호텔 #개발 #개발자 #개발팀 #기술스택 #도입후기 #일지 #경험공유 #Kubernetes #Github

2014년, 3월 비캔버스 개발을 시작했다. 약 2년이 넘게 시간이 지나면서 많은 방향 전환이 있었다. 단순한 포스트잇 기록 가능한 메모 도구로 시작했지만 이후, 온라인 화이트보드, 프로젝트 관리 툴, 비주얼 블로깅 툴 등 약 4번 이상의 크고 작은 방향 전환이 있었던 것 같다. 작년에 이미 국가와 기업으로부터 3억 원 이상의 자금을 투자받은 상태였기 때문에 조급함만 쌓였던 것 같다. 그런데, 일을 하면서도 전혀 그 분야에 대해 박식해지는 것과 같은 느낌이 들지 않았고 비전도 명확하지 않았다. 하고 싶지 않은 일이라서가 아니었다. 이 분야의 한계가 명확하게 머릿속에 들어왔기 때문이었다. 지금 그러한 경험을 공유하고자 한다. 내 경험으로 협업툴. 특히 프로젝트 관리 툴 시장은 매우 포화상태이며 미래가 없고, 인류를 위해서 조금도 도움이 되지 않는다는 결론에 도달했다.다만, 이런 프로젝트 관리 툴을 만들면 전 세계에서도 경쟁력 있는 회사가 될 수 있겠다.개별 기업 혹은 팀이 자신과 팀이 일하는 워크플로우를 간단하게 A4용지나 액셀등으로 정리하면 그것에 딱 맞게 커스터마이즈 된 툴을 제공한다. 혹은 이제까지 일한 정보들을 바탕으로 그에 최적화된 툴을 만들어준다.  이유는 간단하다. 회사마다 일하는 플로우가 너무나도 다르다. 그렇기 때문에 프로젝트 관리 툴의 최고봉은 아직도 액셀일 수밖에 없다. 전 세계적으로 이름이 조금 알려진 것만 해도 1,000여 개가 넘는 프로젝트 관리 툴이 있는데, 그들 대부분이 작게나마 수익을 올리고 있는 이유도 이와 같다. 워크플로우가 너무 다양하기 때문에 Needs가 매우 파편화 되어 있다. 트렐로, Asana, 스마트시트와 같은 탑 3 프로젝트 관리 툴은 매우 보편적인 형태의 기능을 제공함으로써 시장을 골고루 나눠먹고 있다. 트렐로는 보드 형태의 직관성을, ASANA는 체크리스트 방식, 스마트시트는 액셀 방식으로 서비스를 제공한다. 프로젝트 관리에는 역시 액셀이 짱이다. 다양한 회사가 자신의 워크플로우에 맞게 개인화할 수 있다.컴퓨터라는 도구가 생긴 이래로 우리가 일할 때 해오던 방식은 저기서 끝났다고 봐도 과언이 아니다. 여기에 더해서 페이스북과 같이 SNS를 기업형으로 만든 케이스가 있는데, 써보면 알겠지만 쓰면 쓸수록 불편하다. 애초에 정보의 영속성이 요구되는 기업현장에서 정보를 망각 가능한 말랑말랑한 객체 로보고 두뇌처럼 관리하는 타임라인 방식은 도통 맞지 않는 셈이다.그렇다면, 왜 나는 프로젝트 관리 도구가 미래를 제시하지 못한다고 결론 내렸을까? 그 이유는 매우 간단한데, 툴과 사람의 주객이 전도돼가고 있는 것이 느껴졌기 때문이다. 실제로, 협업 툴을 도입하면 사람들은 그 툴에 모든 워크플로우를 다시 맞춰야 하고, 툴을 배워야 하며 그 툴에 이제까지의 정보를 넣는 등 필요 없는 작업들을 해야 한다. 그저, 검색과 관리의 용이성을 위해 우리는 인간 개개인이 가진 힘을 전체 속에 껴넣는데 불필요한 리소스를 낭비한다고 판단했다. 그리고 올해 초, 한창 힘들었을 시기에 도구에 대해 매우 깊고 조용하게 생각할 시간을 갖게 됐다. 역사적으로, 도구는 인간이 생물학적인 한계를 넘어서게 만들어, 더 나은 세상을 만드는데 기여해왔다.포클레인은 작은 아이도 거대한 힘을 발휘할 수 있도록 만들었고, 자전거는 인간이 맹수보다도 빠르게 이동할 수 있는 힘을 줬다. 애플의 스티브 잡스, 워즈니악이 발명한 개인 컴퓨터는 인간이 신체뿐 아니라 정신적 한계까지 넘어설 수 있는 힘을 줬다. 이렇게 언제나, 인간은 도구를 이용해 한계를 넘고 가치를 창출해왔다. 그것이 인간만이 가진 초월적인 힘이다.결국 도구는 '초월'을 의미하는 것이 아닐까?그런데, 갑자기 모든 것이 달라졌다.도구들의 비약적 발전과 함께 일어난 것은 사람들이 일하는 방식의 변화였다. 작은 공방, 상점 등에서 일해왔던 인류는 무언가를 수행하기 위해 언젠가부터 100명. 200명. 수 천명. 매우 거대한 조직을 만들기 시작했다. 조직의 비대함과 함께 개인의 역량에 대한 기대와 요구는 떨어졌고, 그들을 전체적으로 관리하고 통솔하는데 관리자는 몰두하기 시작했다. 우리는 이미 알고 있다. 나 자신도 누군가의 '관리의 대상'이라는 것을 말이다. 사람 한 명, 한 명은 아마존이나 Ebay에 배치된 상품처럼 DB화 되어 HR관리자에 의해 관리된다. 인터넷 시대로 접어들면서 모든 기업은 종이에 쓰인 아날로그 정보들을 디지털로 옮겨오기 시작했다. 아날로그식 업무를 디지털로 옮겨오면서 발생하는 손실을 막기 위해 ‘관리’가 곧 생산성의 척도가 됐다. 지금 존재하는 생산성 툴의 80%가 이런 방향을 향해가고 있다고 보면 된다.나는 이것이 이미 깨진 항아리를 막기 위한 고군분투인 것으로 보였다. 깨진 항아리를 막아달라는 '니즈'는 분명히 존재하기 때문에, 누군가 달려들어 깨진 항아리를 운 좋게 한번 잘 막을 때마다 시장으로부터 돈을 버는 형태로 사업이 이어지고 있다고 판단했고, 이 분야에선 발전적인 미래가 없다고 생각했다. 그때였다. 간디의 말은 내 심장을 뿌리 깊게 파고들었다.그렇다. 대부분 협업 툴은 물론 우리가 향했던 방향은 '행동'을 만드는 일이었다. 사람들이 일하는 방식을 만들고 우리의 방향을 강요해서 습관으로 만들고, 그 습관의 관성을 유지시키는 것이 비즈니스 모델이었던 것이다. 그 습관을 유지하는 것 자체가 '가치'라는 착시로 보일 것이 분명했다. 이때, 이 방향이 인류를 위해 조금도 도움이 되지 않는다고 강하게 확신이 들었다.그래서, 간디의 말에 더욱 귀를 기울였다. '믿음과 생각.' 이 근본적인 단계에 접근하는 것을 목표로 정했다.평범한 사람의 잠재성도 끌어낼 수 있고 더 나아가 그것 자체로 사람들이 자신의 한계를 넘어선 가치를 만들 수 있는 도구를 만들자. 그들이 평소 내지 못할 법한 생각도 낼 수 있게 만드는, 그런 도구를 만들자.루트번스타인의 '생각의 탄생'을 다시 읽어보기 시작했고 아인슈타인이나 다빈치 등 천재들이 사고하는 방식에 대한 중요한 내용이 담긴 책 초반 부분을 소프트웨어로 옮기기 위해 설계를 시작했다. 위대한 업적을 남긴 사람들은 '개인'이었고 그들은 관리의 대상이 아니었다. 그리고 그들이 사고하는 방식에는 일정한 패턴이 있었는데 그것은 매우 조직화된 사고방식이 아닌 방사형 사고방식을 갖고 있었다는 것이었다. 간단한 예로, 싸이월드를 꾸밀 때의 창의성은 페이스북을 시작한 순간 사라졌다. 배경음은 무엇으로 할까, 다이어리엔 무엇을 쓸까? 아바타는 뭘 입고 있을까. 어디에 꾸며놓을까. 대문글은 비밀글로 할까? 방명록은 비밀글로 할까? '비밀로 써줘~' 멘트는 무엇으로 쓸까? 이런, 우리의 크고 작은 창의적인 수많은 고민들은 어디로 갔을까? 사람들이 '어떻게 느낄지'에 대해 깊이 고민하며, 첫사랑에 빠진 초등학생의 창의성까지도 끌어냈던 우리의 과거는 어디 간 걸까? '개인'이라는 인간 자체의 의미는 '페이스북'이라는 거대한 집단 속으로 들어가 개성을 잃고 그저 거대한 네트워크 속, 한 줄의 DB로 영원히 전락한 것일까?비캔버스는 그러한 고민을 하게 만드는 도구로 만들기로 결심했다. 링크를 단순히 즐겨찾기 할 때도, 별 모양 하나를 눌러 어디에 저장되는지도 모르고 Keep 해놓는 것이 아니라, 자신의 감성과 생각에 맞게 자유롭게 배치하고, 그것을 배치하기 위해 고민하게 만들었다. 자신의 생각, 자신의 관념을 시각화할 수 있는 툴. 하지만 개념적으로 어렵지 않게 파워포인트와 매우 유사한 사용성을 가진 직관적인 툴. 그것이 우리의 방향이 됐다. 대충 만들었지만, 정성과 미묘한 감성이 느껴지지 않는가?이 글을 쓸 때도, 비캔버스로 초안을 잡았다. 내 생각을 포스트잇에 마음껏 적어 뿌려놓고 순서를 배열해보면서 어떤 순서가 나을지를 고민했다. '관리되고 있는 나'에 집중하는 것이 아닌 '생각하고, 일하고, 아이디어를 내는 나'에 온전하게 집중할 수 있는 툴을 만드는 것을 목표로 한 순간, 모든 것이 명확해졌고 일에 속도감도 생기고 재미도 붙었다. 하지만 함께 일하는 협업 툴로 쓰기 위해서는 나의 세계에만 흠뻑 빠져있는 것이 아니라, 다른 사람들에게 내 생각이 담긴 캔버스를 공유했을 때도 누구나 이해하기 쉽고 그 정성이 느껴져야만 한다. 그것을 디자인적으로 풀기 위해 노력해왔다. 위 캔버스를 만드는데 약 1분 30초가 걸렸다. 정확히 구조적인 텍스트로 풀어보자면, 유튜브 영상 2개, 웹 링크 1개, 이미지 7개, 포스트잇 3개가 들어갔다. 하지만 저 캔버스 안에는 단순한 텍스트로 표현할 수 없는 뭔가가 느껴진다. 정보를 모으고 그룹화하는 사람의 심리와 그 정성! 제 아무리 싸이월드를 못 꾸미는 사람의 홈피에 들어가도 그 사람의 정성이 느껴질 수밖에 없듯 말이다. 그리고 그 정성이 담긴 캔버스는 한눈에 직관적으로 이해될 수 있다. 파워포인트와 크게 다르지 않기 때문이다.지금 이 순간, '흠... 비캔버스라... 재미는 있는데, 딱히 필요는 없겠네. 비즈니스 모델이 뭐지?'라고 생각하고 있는 사람들이 있을 것이라 확신한다.그런데 나는 앞으로의 도구는 이러한 방향이 아닐까 진지하게 고민해본다. 도구는 서비스와 다르기 때문에 먼저 가치를 주고 그 가치를 고객이 강하게 받아들이는 역방향의 사업 진행이 가능하다고 판단했다. 비타민과 진통제의 비유를 역으로 들어보자면 지금의 사업개발 풍토라면 사람들은 비타민을 만들지도 않았을 것이고 아무도 먹어볼 수 없다. 비타민을 만들겠다고 말한다면, 사람들이 사업을 할 줄 모른다며 다른 마약성 진통제를 개발하라고 할지도 모른다. 물론 비타민이 필요하다고 말하는 '니즈'는 강하지 않을 것이다. 누구나 돈 되고 니즈 명확하고 시장이 검증된 진통제만을 만들 것이고 결국 우리 인류는 비타민 부족으로 각종 질병에 시달려 명확한 '시장'과 '니즈'가 생길 때까지 비타민을 만나지 못할 것이다.피아노는 어떤가? 피아노를 왜 만드나? 악기를 왜 만드나? 그게 돈 되나? 누가 사나? 피아노라는 도구가 없었다면 모차르트도 베토벤도 쇼팽도 아무도 없다. 더 무서운 것은 우리 인류가 그것에 대한 불편이나 적막함을 전혀 느끼지 못했을 것이라는 것이다. 적막한 세상 속에 살면서도 우리 인류는 그 세상이 적막한지도 모르는 채 살아갔을 것이다. 자본주의의 가장 큰 약점이 여기 있다고 본다. 당장 가시적으로 돈이 보이는 곳이 아니면 누구도 모험을 하지 않는다. 말을 조금 바꾸면 니즈가 없으면 제품도 없다. 인류는 모든 정답과 자신의 욕망, 필요성을 명확히 인지하고 주머니 바깥으로 돈을 빼놓고 기다려야만 한다. 그러면 기업가들이 제품을 만들어 줄 것이다. 세상을 바꾸는 것은 단순한 니즈가 아니다. 자본주의 사회에서 니즈란 돈을 뜻하는데 우리 인류가 살아가는 이유가 돈이 아니다. 주객이 전도되면 안 된다. 그래서, 나에게 가장 무서운 말은 '위대한 생각이고 뭐고 그딴 거 필요 없을 것 같은데. 비타민 말고 진통제 같은 걸 만들어야지, 당신은 진짜 사업 초짜군요!'가 아니다. 그런 이야기를 들을 때마다 인생의 덧없음과 인류를 위해 온전하게 걸어야 할 길에 대해 진지하게 고민해보지 않은 사람이라고 밖에 생각이 안 든다. 우리에게 매우 중요한 순간은 '필요 없을 것 같은데'가 아니라 진짜 필요 없을 때다. 그것이 우리의 실패를 의미한다.'비캔버스 한 달 써봤는데, 너무 쓸모가 없어서 그냥 안 쓰기로 했어요'이 얼마나 공포스러운 말인가? 익숙하지 않은 제품을 의식적으로 쓰기 위해 노력했음에도 쓸모가 없다고 판단을 내릴 정도로 끔찍한 제품을 만들었다니... 이것이 컨저링 2보다도 무서운 진정한 공포다. 하루 종일 도구만 만드는 사람들에게 너무나도 가혹하면서도 강한 자극을 줄 수밖에 없다.다행히, 비캔버스의 고객은 어느새 3만 명이 넘어가고 있고 매일 아침만 되면 사용자들이 들어와 자신만의 비주얼 세계를 구축하기 시작한다. 정말 아름다운 순간이다. 밤에는 북미와 남미에서 유저들이 들어와서 무언가 프로젝트를 진행한다. 가슴이 벅차다는 말은 이럴 때 쓰는 것이 아닐까 심각하게 고민해본다.비캔버스를 이용해 보면 알겠지만, 우리는 고객지원을 장인(개발자)이 직접 하고 있다. 그 이유는 매우 간단한데, 개발자는 개발에 집중을 하다 보면 그저 텍스트로만 이뤄진 제품이 실제 살아 숨 쉬고 그것과 고객과 만나는 생명력을 갖는다는 것을 이해하기 힘들다. 버그가 생기면 버그를 고쳐야겠다는 생각만 가득하지, 그것을 왜 고쳐야 하는지 등에 대한 고민을 하기 힘들기 마련이다. 이 때문에 장인이 직접 고객지원을 함으로써 고객은 자신이 요구한 피드백이나 문제점을 빠르게 해결할 수 있고 장인은 제품이 실제 살아 숨 쉰다는 것을 지각하는 것은 물론 자신이 만든 제품에 대한 사명감과 자부심이 깊어진다.한 가지 더 이득이 있다면, 나도 한 때 개발을 할 때 느꼈지만 개발자들이 Java, Javascript나 Objective-C와 같은 언어에 집중을 하다 보면 인간의 언어로 소통을 하는데 큰 어려움을 겪기 마련이다. 이것이 바로 기계와 인간의 주객이 전도된 대표적인 비극이 아닐까 싶다. 우리 장인들도 고객지원 초기에는 인간의 언어를 구사하는 것에 큰 어려움을 느꼈다. 하지만, 이제는 인간의 언어를 자연어처럼 자유롭게 구사하며 감성을 가진 개발자로서 그 영역을 넓혀가고 있다. 이처럼, 장인의 직접적인 고객지원은 장인정신을 강화하는데도 매우 중요한 역할을 해왔다.도구를 만드는 많은 장인들처럼, 우리 또한 장인정신을 갖고 서비스를 만들고 있다.우리는 협업 툴과 생산성을 넘어선 도구를 만들고 있고, 앞으로도 계속 그럴 것이다. 화이트보드와 마인드맵이 우리의 생각의 폭을 넓혀주는 것처럼, 우리는 그런 도구를 만들고 싶다. 사람들이 자신의 한계를 초월한 가치를 폭발적으로 만들어낼 수 있게 돕는 도구. 인류의 발전적 미래를 고민했을 때 우리의 사업, 우리의 서비스와 그 방향이 일치하는 그런 길을 걷고 싶다.그러한 뜻과 사명이 없다면 조그마한 위기나 상처에도 굴복하고 포기할 것 같다. 수많은 위기를 지금 우리 회사의 장인들과 함께 견뎌왔고 앞으로도 견딜 것이다. 그것을 견디고 우리가 장인정신을 갖게 해주는 비결이 바로 위와 같은, 인류의 발전적 미래를 향한 방향과 우리의 사업적 방향이 일치한다는 그러한 사명의식에서 나온다.사람들의 가치를 끌어올려주는 도구를 만드는 길. 그것이 가시적으로 드러나는데 조금 시간이 걸리더라도 차근차근 조바심 내지 않고 그것을 달성하는데 온 집중을 다할 것을 진심으로 다짐해본다. 비캔버스는 웹사이트 beecanvas.com 에서 만나볼 수 있으며, 아이폰, 아이패드를 위해 아름답게 디자인된 앱을 앱스토어에서 만나볼 수도 있다.고객님들의 위대한 생각과 성과를 위해 어지러운 세상 속에서도 언제나 파이팅할 것을 약속드린다. 마지막으로 아인슈타인의 명언이다.  

ㅡ더 즐겁고 다 행복한그렇게 여행이 시작된다.-서서울예술교육센터 TA 윤윤상작가#서서울예술교육센터 #윤윤상#TA #작가‡ Nice to meet you, Artist meets you ! ‡서울에서 활동하는 예술가들이 만들어내는 창의적인 예술 활동. 서울문화재단의 15개 창작공간 입주작가들을 소개합니다.보물은 발밑에 놓여있거나 고개를 들어서 볼 수 있을 만큼 가까이에 있다는 것을 이렇게 멀리 떠나와서야 알게 되죠.-서서울예술교육센터 TA 윤윤상 작가 작업노트 중서서울예술교육센터 TA 윤윤상 작가그의 이력은 조금 특별하다. 얼핏 들으면 어느 여행가의 이력이 아닐까? 하는 생각이 든다. 2년 6개월 아시아의 곳곳을 여행했다. '예술프로젝트'라고 했지만 그의 일상은 여행이었을 것이다. 여행에서 돌아와 뜬금없이 가구를 팔았다. 꽤 잘 팔았다고 그는 말했다. 그러다 다시 불현듯 자신의 여행 가방을 뒤적여 그의 이야기를 꺼내어 놓기 시작했다.서서울예술교육센터 TA로 활동 중인 윤윤상 작가가 바로 그 사람이다.관광과 거주사이의 여행어떤 경향성에서 완전히 벗어나 보고 싶었어요. 모든 것을 제로(zero)에서 시작해 보고 싶다고 생각했죠. 무엇과도 상관없이 내가 오롯이 생각하는 문맥이 무엇인지를 발견하고 싶었습니다.그가 학교를 졸업하며 '여행'이라는 개인 프로젝트를 결심한 이유였다. 그의 여행은 조금 특별했다. 같은 루트를 두 번 도는 여행이었는데 한번은 가이드북과 같은 기존 여행 정보를 이용하여 관광객들이 흔히 가는 동선을 따라 움직이는 것이었고, 한번은 여행정보에 의존하지 않고 2~3개월씩 한곳에 머무는 여행이었다. 좀 오래 머무는 곳에서는 아예 집을 빌려 생활하고, 현지 아르바이트도 하고, 인연이 된 주민들과의 관계 안에서 그들의 행사를 기획하고 참여해보기도 했다.태국 치앙마이 게스트 하우스 전시 가능한 곳에서는 전시도 했다. 태국 치앙마이 몇 게스트하우스에서 한 전시가 기억에 남는다고 했다."여행 중의 전시다 보니 현지에서 수집된 물건이나 재료로 구성을 해야 했어요. 재밌게도 처음에 관심이 가는 것들이 화려하고, 뭔가 특별해 보이는 것이었다면 시간이 지날수록 일상적인 것들에 더 의미를 두게 되더라고요."치앙마이에서 수집한 첫 아이템은 화려한 꽃이었다. 하지만 점점 모이는 물건들은 샤워타월, 물컵, 색종이 등이었다. 그렇게 전시된 이야기는, 감각적으로 들어오는 강렬하고 표면적 이미지를 쫓는 여행에서 시간과 함께 일상에 이야기를 담아가는 거주의 여행으로 변화를 보여주는 것이기도 했다.국기, 정체성과 이상향어릴 때 86아시안게임과 88올림픽을 지나면서 보았던 하늘에 날리는 알록달록 다양한 국기가 인상적으로 기억에 남아있습니다. 아마 그 이미지 때문에 국기에 관심을 가지게 된 거 같아요.성조기를 테마로 한 작업들윤작가는 특히 국기에 관심이 많다. 미국 유학 시절 이방인으로서 작업을 고민하며 '현지인이 스스로 보지 못하는 그들의 문화를 이방인의 눈으로 보여주자'라는 생각을 했다. 그래서 성조기를 모티브로 작업하기도 했다. 실내에 신발을 신고 다니는 것이 그들에게는 당연하지만 우리에게는 낯선 것이라는 점, 즉 ‘바닥’이라는 문화 차이를 드러내는 방식으로 성조기의 ‘별’과 ‘바닥’이라는 전시공간을 이용하기도 했다고 한다.또한 210개의 전 세계 국기 안에 담겨있는 상징들을 해체하여 개별 요소로 만들어 보았다.“국기를 해체하다 보니 의외로 상징이 몇 개의 카테고리로 단순화되는 것을 알게 되었어요. 국기가 그 나라를 대변한다기 보다는 어떤 이상향을 표현하고 있다는 것을 알게 되었죠. 그렇다면 국기를 만드는 작업이 본인의 내적 욕망을 이야기하는 요소가 될 수 있겠다고 생각했어요."윤작가는 올해 국기에서 뽑아낸 72개 정도의 그래픽을 오픈하고 참가자들은 그 안에서 사진의 이상향을 담은 국기를 조합해 내는 작업으로 서서울예술교육센터에서 650여명의 다양한 부류의 아이들을 만났다.650개의 상상 속 공동체와 그 이상서서울예술교육센터에서 아이들을 만나는 윤작가가보고 싶은 나라, 다녀보고 싶은 학교, 새로운 공동체를 상상하게 함으로 나라. 국경, 사람에 대한 이야기를 타자, 소수자, 어린이의 표현으로 보고 싶었습니다.인터뷰가 있던 날, 서서울예술교육센터에서는 일 년 동안 탄생한 650개의 국기 중 12개가 '환영합니다'라는 제목으로 전시 중이었다. 전시된 국기들 속에는 상상 이상의 메시지들이 담겨 있어서 흠칫 놀랐다. 한국어가 서툰 다문화가정 아이는 축구를 할 때가 가장 행복하다고 했다. 말을 안 해도 되기 때문에 새가 되는 기분이라며 아이의 국기에는 날아가는 독수리 상징이 담겨있었다. '방탄소년단'이 춤을 가르치는 학교에 다니고 싶은 아이는 일곱 개의 별을 자신의 국기에 담아 놓기도 했다.상상의 공동체를 담은 국기들국기는 그래픽 작업 뿐 아니라 실제 국기 형태로 만들어져 서서울예술교육센터 건물 외관에 걸어 전시되어 있기도 했다. 인터뷰를 위해 센터에 도착했을 때 건물에 빼곡히 걸린 낯선 12개의 국기를 보며 무슨 국기가 저렇게 걸려있나 의아했었는데 전시 작품의 일부였다."아이들 하나하나가 어떤 보이지 않는 상상의 공동체를 대변한다고 생각했어요. 그래서 국기도 정상회담의 국기처럼 화려하게 제대로 만들었고, 전시구성도 마치 정상회담 테이블과 같이 해 보았습니다."다음으로 이어지는 ‘사이에’ 있기.인터뷰를 마치고 돌아오며 그가 인터뷰 초반에 보여준 여행 사진 한 장이 계속 기억났다.윤윤상 작가가 여행중 찍은 사진어느 사원에 청소하고 있는 여인의 사진이었다.이 사진을 보여주며 작가는 '우리가 특별하다고 생각하는 무엇이 누군가에게는 일상이기도 한다.'고 했다. 그 사원을 바라보는 사람과 사원의 한편에서 삶을 이어가는 사람 사이를 보여주는 사진이었다.저는 ‘사이에’ 존재하는 것 같아요. 그 시간은 그냥 다음에 일어날 사건에 맡기는 시간이죠.오랜 여행과 약간의 침묵 후 윤작가는 이제 막 이야기를 꺼내기 시작했다. 오래 봉인되었던 여행 가방에서 이제 막 툭 튀어나온 이 이야기는 그가 이야기한 맡겨진 다음의 시간위에서 어떤 이야기들을 만들며 '둘러보기'와 '머물기'의 여행을 해나갈지 궁금해진다.다음이야기를 준비하는 윤윤상 작가글  시민기자단 홍은사진제공  윤윤상디자인  이한솔#서울문화재단 #문화예술지원 #서서울예술교육센터 #TA업무 #직무정보 #공채정보 #인터뷰 #작가

이번 달 스터디를 위해 <원칙> (레이 달리오 저)이라는 책을 읽으며 한 회사를 관통하는 원칙이 모든 구성원을 한 방향으로 생각할 수 있도록 하고 이 것이 큰 효율을 만들어낸다는 것을 느꼈습니다. 그래서 제가 존경하고 무엇보다도 창업 후 20년간 성장해온 여러 기업들의 원칙들을 모았습니다. 수십 년간 전 세계에서 성장을 거듭하는 이유는 기업 내에 공기와도 같은 문화와 그 근간을 이루는 원칙이라고 생각했습니다. (아마존 1994년 창업, 넷플릭스 1997년 창업, 구글 1998년 창업) 기업 별로 주요 원칙의 부제는 달랐지만, 조직 내의 공식/비공식적인 문화와 행동양식의 가이드가 된다는 점에서 그 기능은 같다고 생각됩니다. 그리고 제가 붙인 한국어 단어가 각 원칙의 의미를 왜곡할 수도 있어 한국어, 영어 단어를 병기하였습니다. 아마존 리더십 원칙 Amazon Leadership Principles 1. 고객 집착 Customer Obsession2. 주인의식 Ownership 3. 발명하고 간소화한다. Invent and Simplify 4. 리더는 옳다 Are Right, A lot5. 늘 배우고 호기심을 잃지 않는다. Learn and Be Curious6. 최고의 인재를 채용하고 성장시킨다. Hire and Develop the Best 7. 최고의 기준을 추구한다. Insist on the Highest Standard 8. 크게 생각한다. Think Big 9. 신속하게 판단하고 행동한다 Bias for Action (계획보다 실행 자체를 중시하는 것 by 톰 피터스)10. 검소 Frugality11. 신뢰 얻기 Earn Trust12. 깊은 관여 Dive Deep 13. 명확한 기준: 반대하고 받아들여라. Have Backbone; Disagree and Commit 14. 결과를 가져온다. Deliver Results 출처: https://www.amazon.jobs/principles한국어 번역 참고 기사: http://news.mk.co.kr/newsRead.php?year=2017&no=433634구글의 업무 규칙 10가지Work Rules!1. 일에 의미를 부여하라. Give your work meaning2. 직원들을 믿어라. Trust your people3. 자기보다 더 나은 사람을 채용하세요. Hire people who are better than you4. 성과 관리와 성장을 혼동하지 말라 Don't confuse development with managing performance5. 최악의 직원과 최고의 직원에게 초점을 맞춰라 Focus on the worst and the best (the two tail)6. 인색하면서도 동시에 관대하라. Be frugal and generous 7. 급여는 차등적으로 지급하라 Pay "unfairly"8. 슬쩍 옆구리를 찔러라 Nudge9. 점점 커지는 기대를 관리하라 Manage the Rising expectations10. 즐겨라! 그리고 1번으로 돌아가서 다시 시작하라 Enjoy! Then go back to No.1 and start again출처: http://www.slideshare.net/lxbock/work-rules-48029695한국어 번역본 출처(강은진 님 번역): https://www.slideshare.net/alleciel/work-rules-korean-ver넷플릭스 문화의 7가지 관점Seven Aspect of our Culture1. 우리가 실제로 가치 있게 여기는 것이 가치다. Values are what we Value2. 뛰어난 퍼포먼스 High Performance 3. 자유와 책임 Freedom & Responsibility 4. 통제가 아닌 맥락의 전달 Context, not Control 5. 강하게 연결되어 있되, 느슨하게 짝지어진 조직 구성 Highly Aligned, Loosely Coupled6. 동종 업계에서 최고 임금으로 대우 Pay Top of Market7. 승진과 자기 계발 Promotions & Development 출처: https://www.slideshare.net/reed2001/culture-1798664한국어 번역 출처(스마트스터디 황석인 님 외 5인 번역): https://www.slideshare.net/watchncompass/freedom-responsibility-culture저는 원칙들을 출력하여 모니터 옆에, 업무노트 앞장에 붙여놓으려 합니다. 나중에 회사 벽에 큰 포스터로 만들어서 붙여놓아도 좋겠네요!회사의 원칙을 만들려고 하시는 모든 분, 혹은 업무의 원칙을 고민하시는 실무자분께 참고가 되길 바랍니다. 장아라blankcorp

많은 예비창업자들에게는 불편한 글일 수도 있다.그리고 나는 불편한 글에 추호의 거리낌을 느끼지 않는다."니가 뭔데 이따위 글을 올리냐"라고 반문할 수도 있다.맞는 말이다.그리고 나도 굳이 시간내서 글을 남기는 것이 귀찮은 사람이다.나 말고도 많은 사람들이스타트업에 대해 이야기하고 있으니까.이 이야기가 불편하면 그냥 다른 작가의 글을 읽으러 가라.내 이야기말고 참 좋은 성공스토리, 희망적인 이야기,열정에 기름 붓는 이야기꾼들이 많다.하긴 정책적인 방향이 창업을 더 독려하고 있고,자의반, 타의반으로창업전선에 뛰어들 수 밖에 없는사회적 상황이 크게 작용하고 있지.참고로필자는 군대 갓 전역하자마자2002년에 한 번 창업을 해서 약간의 돈도 벌어보고,직장 생활 두 번 하며, 경력도 좀 쌓고,1년 하고도 반 정도 된 스타트업을 운영하고 있는길에서 흔히 볼 수 있는 흔하디 흔한 창업자이다.적으나마 매출도 있고,월급주고 있는 동료들도 있고,나름 정부지원도 받고,시제품, 금형, 사무실도 마련한...그래도 초기 스타트업치고는 무난하게 생존하고 있는 편이다.(출처: MBC 무릎팍도사 중에서)지인들이 창업을 하겠다고 물으러 오면,"하지마~! 제발~!"이라고 고딕하게 답한다."넌 하고 있잖아""그래! 그래서 하지 말라고 쫌~!"열정으로 창업하라는 말,아이디어만 있으면 창업하라는 말,누구나 쉽게 창업할 수 있다는 말 따위믿지마라.열정? 그거 누구나 다 가지고 있는거다. 단지, 연료가 어느 정도 있느냐의 차이일 뿐이고아이디어? 그거 구현 안되면 다 허상이다.실제로 아이디어 구체화하면서고객/시장조사 해보면,거의 대부분 초기 컨셉에서 바뀐다. 혼자 생각한 아이디어일 수록 허점투성이거든.누구나 쉽게 창업?하긴 창업절차는 매우 쉽다. 그리고 참 쉽게 망한다.현실을 말하자면,동료가 없으면 스타트업 꿈꾸지마라.혼자 할 수있는 회사가 있긴하다.프리랜서처럼,그냥 작게 수익내고,리스크없이 자급자족식 회사라면가능하다.그런데 회사는 성장하면서분명 사람이 매우 절실해 질 순간이 온다.(출처: 중앙경제평론사, 사업은 사람이 전부다 책 표지)그때,믿을만한 미들맨이 있고, 없고는회사존망을 결정한다.그리고 팀빌딩이 된 상태라고 안심할 수는 없다.팀이 커뮤니케이션이나 업무연계라던가이런 부분들이 관리가 되어야하는데이거 쉽지 않거든.게다가 매출이 발생하면더더욱 복잡해지는 경향이 있다.뭐 매출발생까지 도달하기도 솔직히 쉽지 않은 과정의 연속이지만...그리고 자금!나는 솔직히 정부지원금을 받고많은 혜택을 받아회사를 성장시키고 있다.정부지원금을 받으면,회사가 약해진다고받지 말라는 사람들!참 부럽다.그분들은 자금이 나올 루트에 대한 확신이 강한 분들이다.나는 매우 소심하고, 안전제일주의다보니...불확실성에 내 동료들의 인생과 내 가족의 평화를담보로 걸고 싶지 않더라.안그래도 창업한다고준비한 자체 자금이 조금씩 줄어들어도신경이 곤두서는데....앞으로 고정자금이 들어갈 곳이 얼마나 많고,예상 못한 비용까지 감당하기 힘들건데...그걸 어떻게 해결할 것인가.그리고정부에서 지원해주는 자금은 쉬운줄 아나본데...수많은 창업자들과 치열한 경쟁을 해서쟁취하는 과정이 있다.그리고어느 정도 시장의 흐름과 이슈도 따라줘야한다.어떤 스타트업 대표가'자기는 정부지원금 받게 됬는데,그 시스템이 안 맞아서 중도에 포기했다'라고 적은 글을 보고,어느 정도 공감은 하면서도 무모한 대표라 생각한다.글의 내용은 경쟁을 뚫고 결국 정부지원금을 받기로 됬는데지원제도와 담당 공무원과 마찰로 '욱해서' 관뒀다랄까?(참고로 그 분이 욱했을 당시, 나도 그 자리 한 구석에 있었다.)그리고 시간이 흘러서,그분의 글에는 자금이 부족해서 사업을 접었다라고 글이 올라오더라.시제품 만들 돈이 없어서, 외주 맡기려니 돈이 없어서...결과론적인 이야기지만,적어도 우리 회사는 정부지원금으로 시제품을 만들고,외주도 맡기면서, 제품생산 인프라도 구축하고,좋은 기회와 인연이 늘어나면서매출발생까지 이어졌다.같은 공간에서,같은 시간에,같은 지원 시스템을 앞에두고우리는 그 지원금이 절박했기에복잡하고 번거로운 시스템을 따랐고,그분은 바로 야생의 창업세계에 직행하셨다.진짜 우리 솔직해지자.몇몇 예외적인 성공스토리를 제외하고,자금이 준비 안된 상태에서,곧장 야생으로 뛰어들어 생존할 가능성이 높을까?아니면,인큐베이터나 창업보육센터 등에서조금이나마 도움 받고 나가는게 더 나을까?인큐베이팅 받아도 망하는 회사 비율은존속하는 회사 비율보다 훨씬 많다.그래도 맨땅에 헤딩하는 것보다는자금이나 인적 네트워크, 정보 공유 등의 측면에서정부의 지원금과 인큐베이팅 제도를 경험하는 것이 훨씬 리스크를 줄인다.스타트업 대표는 "가오"가 중요한게 아니다.진흙탕에 구르고, 똥을 씹더라도회사가 생존할 수 있다면,직원들 월급을 밀리지 않을 수 있다면,뭐든 다 할 수 있어야 하는게 사장이어야 한다.그냥 무미건조하게 공부하고 창업해라가 아니다.도서관이나 서점에 들락거리면서스타트업 뭐시기,창업 뭐시기 책만보고 공부하란 말은 아니다.물론 책을 많이 보고준비하는 건 기본이고 삶이다.처음엔 이론적 지식과 배경이 필요하고,당연히 책에서 얻는다.그러나 창업을 하고자 한다면,거기서 뛰쳐나와서진짜 예습을 해야한다.찾아라.스타트업 관련한 모임도 많다.창업자들의 커뮤니티도 많다.뒤져보면, 유사한 카테고리의 스타트업 리뷰, 블로그도 많다.그리고 만나라.고객이 될 사람들을 만나고,동료가 될 사람들을 만나고,멘토가 될 사람들을 만나라.세워라.자금계획, 인력계획, 미션 마일스톤, 수익구조 및 매출계획 등구체적으로 수치화할 계획이 너무나 많다.창업한 후에는 더 많은 수정과 보완을 거칠 것이다.처음에 잘 잡야야 그나마 잔업이 줄어든다.시행착오가 줄어든다.이것은 곧시간을 아낄 수 있고,비용을 줄일 수 있다.이런 준비하고 도전해도 망하는 회사가 더 많은게스타트업이다.그럼 당신은 이글을 읽고나에게 반문해야 한다."그러는 넌~!왜 스타트업을 하고 있지?" 라고...나의 대답으로 이번 글을 마무리하고자 한다."우린 그런 위험과 경쟁을 즐기거든.망할 준비따위 이미 오래전에 끝났거든"추신:스타트업 창업자에게 회사의 생존은내 가족의 삶뿐만아니라동료들의 가족까지도 연결된다.그러니까 그냥 허투로 준비하지 말아야 한다.각오를 단디 해야한다.스타트업이었기에 실패했다고핑계대는 가해자가 되지 말고,스타트업이었기에 이해해달라고읍소하는 피해자가 되지 말자.그럴 자신과 근거가 없다면,그냥 스타트업 하지 말자.그리고 정말 하고자 한다면,확실하게 하자.#클린그린 #스타트업 #초기창업 #각오 #인사이트 #조언 #쓴소리 #창업자 #생존기

Overview개발 도중 내용이 복잡하거나 소스가 길면 종종 오픈소스 라이브러리를 사용합니다. 쉽게 원하는 기능을 구현할 수 있기 때문이죠. 그렇다면 오픈소스 라이브러리는 어떻게 앱에 가져와서 사용할까요? 바로 ‘CocoaPods(이하 코코아팟)’을 쓰면 됩니다.What is CocoaPods?코코아팟의 공식 웹사이트에서는 코코아팟을 이렇게 소개하고 있습니다.“CocoaPods is a dependency manager for Swift and Objective-C Cocoa projects”“코코아팟은 스위프트와 오브젝티브-C 코코아 프로젝트를 위한 의존성 매니저(dependency manager)다.”즉, ‘개발자가 편리하게 사용할 수 있게 오픈소스 라이브러리를 프로젝트와 연결해주는 환경 또는 도구’를 말합니다. 이로 인해 다양한 장점을 가지고 있는데요. 우선 코코아팟은 개발자가 개발한 앱에 라이브러리를 추가, 삭제, 업데이트 등의 관리를 할 수 있습니다. 예를 들어, 네트워크 관련 라이브러리를 개발자가 직접 개발하지 않고, Alamofire 라이브러리를 코코아팟으로 앱에 연결해 사용하는 것입니다. 둘째, 라이브러리 버전을 직접 지정하여 사용할 수 있어 업데이트 버전이 나와도 지정한 버전을 계속 사용할 수 있다는 점입니다. 만약 새로운 버전에 맞춰 개발할 준비가 되면 그때 업데이트를 하면 됩니다.CocoaPods에서 facebook을 검색하면 관련된 다양한 라이브러리가 나옵니다.How to use Cocoapods?1.코코아팟 설치하기개발한 앱에 사용할 오픈소스 라이브러리를 찾았다면 코코아팟을 설치해 앱과 연결해봅시다. 먼저 코코아팟을 설치하고 터미널 프로그램을 열어 아래와 같은 명령어를 입력합니다.$ sudo gem install cocoapods 그리고 CocoaPods Master Specs repository에 있는 Podspec file를 컴퓨터에 다운로드합니다. –verbose 명령어를 이용해 현재 진행 상황을 터미널에서 볼 수 있게 합니다.$ pod setup --verbose 이제 코코아팟을 사용할 준비가 되었습니다. Xcode에서 간단한 프로젝트를 만들고 끝냅니다. 이번 글에서는 관광명소를 보여주는 목록 앱을 예제로 만들겠습니다.2.라이브러리 연결하기터미널 프로그램을 이용해 방금 전 만든 프로젝트 경로로 이동하고, Podfile을 만들어 앱에 필요한 라이브러리를 설정합니다. Podfile을 만드는 방법이 두 가지입니다. 첫 번째는 pod init 명령어를 이용해 코코아팟이 기본 틀이 있는 파일을 생성하게 하는 것입니다. 두 번째는 개발자가 직접 빈 파일을 만들어 설정하는 방법입니다. 이번 글에서는 pod init 명령어를 사용하겠습니다. (편리합니다.)$ pod init podfile이 생성된 것을 확인할 수 있습니다.이제 Podfile을 열어 우리가 사용할 라이브러리를 세팅하고 코코아팟 공식 사이트에 접속합니다. 사용하고자 하는 라이브러리를 검색하고 이름 옆 클립보드 아이콘에 마우스 포인터를 올려보세요. Podfile에 복사할 텍스트가 나타날 겁니다. 이 텍스트를 복사하여 Podfile에 붙이고 저장합니다. 이 글에선 URL에서 가져올 이미지를 다루기 위해 SDWebImage 라이브러리를 사용하겠습니다.완성된 Podfile의 모습위의 Podfile을 잠시 설명하자면 프로젝트의 배포 타겟은 iOS 9.0 입니다. ‘use_frameworks!’ 은 코코아팟을 통해 프로젝트에 추가할 라이브러리가 스위프트로 작성되어 있고, 프레임워크를 사용할 것이기 때문에 꼭 추가해야 하는 문장입니다. 라이브러리 옆의 숫자는 4.3 그리고 4.4 이전까지 라이브러리 버전을 사용하겠다는 뜻 입니다. 최소한의 설정을 맞췄으니, 저장하고 다음 명령어를 실행합니다.$ pod install --verbose pod install 완료 후 xcworkspace 파일이 추가된 것을 확인할 수 있습니다.Pod 설치가 완료되면 xcworkspace 파일이 생성된 것을 확인할 수 있습니다. Xcworkspace 파일은 쉽게 말해서 프로젝트들의 컬렉션(collection of projects)입니다. 기존에 제작한 프로젝트(Original project)와 pods 프로젝트(Pods project)를 함께 묶는데, 이 pods 프로젝트 하나로 모든 라이브러리를 관리할 수 있습니다. 기존 프로젝트는 이 pods 프로젝트를 의존하기 때문에 xcodeproj 파일을 열면 연결된 라이브러리들에 대한 정보가 없어서(혹은 발견하지 못해서) Xcode 프로그램이 에러를 발생시킵니다. 그러므로 코코아팟으로 pod을 설치했을 때, 프로젝트는 xcworkspace 파일을 열어 개발해야 연결한 라이브러리들을 잘 사용할 수 있습니다.3.라이브러리 사용하기이제 연결한 라이브러리를 사용해봅시다.1) 예제에서는 SDWebImage 라이브러리를 이용해 URL 이미지 주소로 ImageView에 이미지를 설정하도록 코드를 추가하겠습니다.테이블뷰(UITableViewController) 컨트롤러를 이용해 목록으로 관광명소 이름, 설명, 이미지를 보여줄 것입니다. 관광명소 이름, 설명, 이미지에 맞게 데이터 모델을 만들고 스토리보드에서 UI를 디자인합니다. 테이블뷰 컨트롤러 파일을 새로 생성해서 이 소스 파일에서 라이브러리를 연결해서 기능을 구현해봅시다. 먼저 라이브러리를 이 소스에 연결하도록 import 명령어를 입력합니다.AttractionTableVC.swift import SDWebImage 그리고 아래와 같이 tableView(tableView:cellForRowAtIndexPath:) 함수에 코드를 작성합니다.2)override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> AttractionTableViewCell {         // Table view cells are reused and should be dequeued using a cell identifier.         let cellIdentifier = "AttractionTableViewCell"         guard let cell = tableView.dequeueReusableCell(withIdentifier: cellIdentifier, for: indexPath) as? AttractionTableViewCell else {             fatalError("The dequeued cell is not an instance of AttractionTableViewCell.")         }         let attraction = attractions[indexPath.row]                  // . . .         cell.attractionLabel.text = "\(indexPath.row). \(attraction.nameWithDescription)"         cell.attractionImage.sd_setImage(with: attraction.photoURL, completed: nil)                 // . . .                 return cell     } SDWebImage 라이브러리를 쓴 이유는, URL 이미지 주소를 이용해서 관광명소 이미지를 보여주고 싶었습니다. 하지만 UIImage에 바로 URL 주소를 사용할 수 없었고, Data 형식으로 변환한 다음 사용해야 했습니다. 라이브러리를 안 쓴 다면 아래와 같은 소스를 작성해야 했을 겁니다.// return UIImage which is set from url data     private func imageFromUrl(url: URL) -> UIImage {         var photo = UIImage()          do {             let imageData = try Data.init(contentsOf: url)             photo = UIImage(data: imageData)!             return photo         } catch {             print(error.localizedDescription)             return photo         }     } 하지만 위에서 만든 소스를 SDWebImage 라이브러리를 이용하면 아래처럼 딱 하나의 명령문으로 줄일 수 있습니다.cell.attractionImage.sd_setImage(with: attraction.photoURL, completed: nil) 소스 길이가 확연히 줄어들었습니다. 이외에도 GIF 지원, asynchronous image downloader 등 SDWebImage 라이브러리 GitHub 페이지로 접속하면 자세한 기능들을 만날 수 있습니다.CocoaPods Error브랜디의 앱 프로젝트를 클론해서 작업하면 종종 코코아팟 관련 오류로 당황했던 적이 있습니다. 몇 가지 에러의 해결 방법들을 소개하겠습니다.1.“/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/include/sqlite3.h” not found”-> 대부분의 오류들은 코코아팟을 다시 설치하면 거의 다 해결됩니다.$ sudo gem install cocoapods$ pod install –verbose2.“Could not build module firebase core” Error-> project’s temp file 삭제 (~/Library/Developer/Xcode/DerivedData — Xcode->Preference->Location에 위치함)우선 위의 폴더 경로를 먼저 찾아 Finder로 여세요. 그 다음에 Xcode를 종료해 안전하게 삭제해야 합니다.-> ProjectName, .xcworkspace 삭제-> Podfile.lock 파일과 Pods 폴더 삭제-> $ pod install –verbose-> 새로 생성한 ProjectName.xcworkspace 실행하여 다시 빌드하기-> 그래도 안 된다면?—> $ pod update(or) —> $ pod –version 체크(or) —> $ pod repo update—> Podfile에 ‘Firebase’ 주석 처리—> $ pod install (old Firebase가 제거된다)—> Podfile에 ‘Firebase’ 주석 해제—> $ pod install (new Firebase 설치)—> 해결 완료!Conclusion이제는 새로운 기능을 개발하거나 소스를 수정할 땐 코코아팟에서 관련 라이브러리를 찾아봅니다. 마음에 드는 라이브러리는 곧바로 개발하고 있는 앱 프로젝트에 연결해 적용하기도 하고요. 자신의 언어로 순수하게 소스를 개발하는 것도 좋지만, 좋은 도구를 활용하는 것도 업무에 도움이 될 겁니다. 혹시 마음에 드는 라이브러리 찾으셨다면 저에게도 알려주세요. 코코아팟을 사용하는 iOS 개발자가 되신 걸 축하드립니다!주석 1)각 라이브러리의 GitHub 페이지에서는 소스를 연결하는 자세한 방법들을 소개하고 있다.2)attractions 배열에 미리 만들어 놓은 관광명소 데이터들을 저장한다. 배열에서 선정한 하나의 관광명소 데이터 정보를 이용해 각 테이블 뷰 셀에 알맞게 설정한다. 여기서 테이블 뷰 셀에 있는 attractionImage(UIImageView)에 URL 주소로 이미지를 설정하면 된다.참고문헌 swift3 - Error: Could not build Objective-C module ‘Firebase’ - Stack OverflowGoogle 그룹스An Introduction to CocoaPods (Route 85) - YouTube글김주희 사원 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유

내 블로그를 구독하시던 분들은 인스타슈가라는 인스타그램 마케팅 자동화 툴을 약 5개월째 운영중인걸 알고계실텐데 벌써 3400개 이상의 고객사에서 사용중이고 2500만개 이상의 활동데이터가 싸일 정도로 규모가 커져 버렸다. 이렇게 많은 고객사+개인을 상대하며 비즈니스를 하다 보니 인스타그램 마케팅 관련해서 공통된 질문들을 많이 받게 된다. 이 기회에 이를 정리해 보는것도 의미가 있을 것 같아, 지금까지 인스타슈가 라이브챗을 통해 문의받은 약 600여건의 질문내용 중 가장 빈도높은 것 5개만 뽑아봤다. (인스타슈가 비즈니스가 궁금하신 분들은 인스타그램 마케팅 DO & DON'T을 참고해 주세요~)1. 인스타그램 채널 운영하면 매출이 늘어날까요?인스타그램 마케팅을 처음 시작하시는 분들이 가장 궁금해하는 부분이다. 특히 소규모 업체, 쇼핑몰 등에서 가장 궁금해 한다. 아쉽지만 결론부터 말하면 "직접적으로 연결되지는 않습니다" 이다. 우리가 측정한 데이터로는 평균 컨버젼, 즉 팔로워 수 대비 하루 평균 프로필 링크 클릭율이 약 3~7%대에 형성되는 편이다. 이건 링크 클릭만을 산정한거고 여기서 실 구매로 연결되는 컨버젼까지 감안해 보면 사실 인스타그램으로 다이렉트하게 매출을 일으키는 부분은 통상 1% 미만으로 생각하는게 합리적이다. 즉, 인스타는 매출을 직접적으로 발생시킬 수 있는 마케팅 채널이 절대로 아니다. 그럼에도 불구하고 인스타그램 채널로 마케팅을 하는 이유는? 그건 인스타그램이 FAN-BASED MARKETING 채널로서 매출에 미치는 간접적 효과가 어마하기 때문이다.잘 운영되는 인스타그램 채널은 보통 다음과 같은 특징을 지니고 있다.- 팔로워의 모수보다는 실제 교감이 발생하는 활성 팔로워에 집중한다.- 팔로워들과 댓글로 활발하게 대화한다. ("소통해요" "피드 느낌 좋아요" 이런 댓글들을 말하는게 아니다.)- 제품의 직접적인 어필 보다는 이를 일상적 컨텐츠로 잘 녹여낸 사진들이 올라온다. (이건 있다가 더 자세하게 설명하겠음)- (해당 브랜드가 제법 규모가 있어 다양한 마케팅 채널을 운영중이라면) 인스타그램 채널만의 독자적인 톤&매너, 할인행사 등으로 뭔가 팔로우를 유지할만한 가치가 있게 해준다.위 내용 말고도 컨텐츠 하나하나에 쓰는 내용이나 특정 팔로워를 띄워주기 한다던지, 아무튼 인스타 채널을 잘 운영하는 브랜드의 특징은 "인스타그램 계정을 팔로워 한다는 것의 의미"를 가장 충실히 잘 수행하면서 차곡차곡 팬 규모를 쌓아나가서 이를 통해 간접적인 매출효과 뿐 아니라 브랜드의 신뢰도, 로얄고객층 형성 등의 보다 중장기적 목표를 가지고 운영한다는 점에 있다.2. 우리 브랜드 공식 인스타그램 계정이니까 제품이나 브랜드 관련 컨텐츠만 올려야 할까요?생각보다 많은 기업계정들이 이 부분을 상당히 오해하고 있다. 인스타그램에서 저게 본인 브랜드의 "공식 계정"이니의 여부는 전혀 상관이 없다. 즉, 공식계정이라고 제품샷이 도배된 컨텐츠 운영을 해야한다는 강박관념에 빠져서는 안된다는 뜻이다. 본인이 스타벅스급으로 사람들이 알아서 좋아해주는 브랜드가 아니라면 다음 사항을 유념해야 한다.기업계정을 맞팔해주는 경우는 1) 나도 팔로워를 늘리고 싶은데 기업계정들이 가장 맞팔을 잘해주니까 맞팔해주는 경우, 2) 그 기업계정의 컨텐츠가 진짜 마음에 들거나 내가 평소 관심있었던 분야라서 해주는 이 딱 2개 케이스밖에 없는데, 100명이 맞팔을 한다면 1번이 거의 80% 이상의 비중을 차지한다.자, 그러면 1번의 이유로 들어온 사람들을 내 팔로워로 붙들어서 향후에는 내 브랜드에 관심갖게 만드려면? 당연히 그들 피드에서 컨텐츠가 튀어야 하고 그들 피드를 광고성 컨텐츠로 도배해서는 안된다. 이런상황에서 당신이 계속 특색도 없는 제품관련 샷만 도배한다면 당연히 맞팔을 했다가도 언팔율이 높아질수 밖에 없고, 언팔율이 높아지면 당연 팬을 형성하는것도 불가능해진다.그렇다면 어떤 컨텐츠가 좋은 컨텐츠일까? Bad case를 소개하면 해당 기업에서 컴플레인이 올수 있기 때문에 Good case만 몇가지 소개해 보겠다. (아, 참고로 인터넷이나 책같은 곳에서 말해주는 베스트 케이스니 이런거 보면 뭐 대부분 스벅, 나이키 등등 이런급 계정을 얘기하는데, 그들 인스타가 잘 운영되는건 그들의 인스타그램 전략이 좋아서가 아니라 그냥 그 브랜드 자체가 파워풀해서임을 명심해야한다. 내 브랜드력이 저 급이 아닌데 저 계정들을 베스트케이스라고 보고 배우자.. 정말 1도 도움이 안되는 예시다.)1) 제품샷이지만 "인스타틱하고 엣지가 있는" 컨텐츠들이어서 언팔하고 싶은 느낌이 안드는 계정들여기에 해당되는 계정들은 보통 다음과 같은 공통된 특징이 있다.- 엣지가 있다. 즉, 피드에서 확실히 단일 컨텐츠가 튀어보인다.- 잡지에 나오는 정형화된 모델샷들이 아니다.- 제품 말고도 본인 브랜드들에 대한 다양한 스토리를 소개한다.Wear Your Label (@wearyourlabel)SpheroNineteenth Amendment2) 대기업 브랜드 아니고서야 오피셜 브랜드라고 계정도 오피셜일 필요가 있을까? 창업자 본인의 페르소나로 본인 제품을 잘 띄우고 있는 계정들 (특히 패션, 아트 분야일수록 이 전략이 더 유효한 경우가 많다)여기에 소개된 계정들은 보통 다음과 같은 공통된 특징이 있다.- 창업자 본인을 메인 페르소나로 빼서 자기 제품을 띄우고 있다.- 역시 컨텐츠에 엣지가 있다.- 본인의 라이프를 통해 내 브랜드가 어필하고싶은 메시지를 강하게 전달한다.Jordan Washburn (Well-dressed Wayfarer 창업자)Young Bae (Diamond Tatto Studio 창업자) JI Eon Lee (하플리 창업자)3) 컨텐츠도 나쁘지 않으면서, 팔로워 한명한명을 마치 내 상점에 방문하는 고객을 응대하는것 처럼 정성을 다해 소통하다보니 팔로워 수에 비해 계정 활성도가 매우 뛰어난 계정들여기에 소개된 계정들은 보통 다음과 같은 공통된 특징이 있다.- 사진에 달리는 댓글 하나하나에 영혼없는 응대가 아닌 실제 보이스로 반응해준다.- 적은 규모라도 팔로워들만 대상으로 다양한 이벤트를 상시 운영해서 이 계정을 팔로워할 가치가 있게 한다.- 팔로워 규모가 크지 않아도 댓글이나 (소통해요~ 이런댓글 말고) 라이크수가 왠만한 K찍힌 계정들을 능가한다. (사실 이런 계정들이 진짜 알짜배기 계정들이라 할 수 있음)김해 금란다원 (@twiny2k)랩노쉬 (@labnosh_official)페티앙북스 (@petianbooks)사실 1번, 2번 케이스는 크리에이티브도 뛰어나야 하고, 모델의 역할이 매우 중요해서 스타트업이나 자영업 계정에서 시도하기에는 조금 어려운 면이 있다. 하지만 3번 케이스의 경우 누구나 조금만 노력을 기울이면 쉽게 활성팔로워들을 키워나갈 수 있고, 이들 중 반드시 당신 브랜드의 소비자로 전환되는 루프가 형성될 수 있으니 인스타그램 마케팅을 막 시작하신 분들은 꼭 3번 케이스를 중심으로 연구하길 바란다.3. 팔로워 수가 많을수록 우리 컨텐츠 노출도 비례해서 많아지나요?결론부터 말하면 "그렇지 않습니다"이다. 유저수가 많지 않고 노출 알고리즘이 단순했던 인스타그램 초창기에나 내가 컨텐츠를 포스팅하면 시간순으로 팔로워들 피드에 모두 노출이 됐지만 페이스북에 인수된 이후 지금은 어마어마하게 복잡한 노출알고리즘이 운영중이다. 특히 2016년 3월을 기점으로 어마어마한 변화, 즉 팔로워들의 포스트를 시간순으로 배열하던 방식을 완전히 버렸는데, 이에 대한 내용은 인스타그램의 공식 공지사항을 읽어보자.2016년 3월, 인스타그램은 기존의 시간순 노출을 버리고 새롭게 태어났다.사실 위의 글만 가지곤 인스타그램 알고리즘이 도대체 어떻게 진화하고 있는지 알길이 없으니, 수 많은 사람들의 분석글을 참고해 볼 필요가 있는데, 이 글들을 다 읽어보라고 하면 욕먹을 수 있으니 당신이 기억해야 하는 가장 중요한 내용을 정리해 보면 다음과 같다. 단계별 반응도에 따른 포스트 퀄리티 인덱스 (QI)가 일정 수준을 넘지 않으면 노출량이 줄어든다.무슨 말이냐면, 예를들어 팔로워가 100명이면 100명에게 모두 컨텐츠를 노출하지 않고 평소에 내 사진에 반응이 자주 있었던 사람들, 또는 내 프로필을 자주 방문했던 사람들 위주로 일부 노출한다. 여기서 일정비율 이상의 초기 반응을 얻는 포스트는 QI값이 높아져서 그 다음 그룹에 노출되고, 또 반응이 좋으면 그 다음 그룹... 이렇게 사다리 타기 방식으로 노출이 된다. 따라서, 당신의 QI값이 별로라면 팔로워가 아무리 많아도 노출이 잘 안될 수 있고, 당신의 QI값이 월등하면 적은 팔로워로도 노출 짱짱맨이 될 수 있다. 시중에 있는 유령/허위 네트워크로 5분만에 팔로워 찍어주는 서비스를 절대로 사용해서는 안되는 이유가 바로 여기에 있다. 팔로워가 만명인데 반이상이 허위 팔로워 찍혀있는거면 당연히 QI가 안나오니 컨텐츠 노출이 잘될리가 없다. 보통 팔로워가 막 K 찍혀있는데 컨텐츠에 라이크가 막 50개도 안달려 있거나, 컨텐츠에 라이크가 막 1000개 넘게 찍혀있는데 댓글은 가뭄에 콩나듯 달린 포스트들은 백퍼 이런 케이스에 해당한다.포스트 노출에 가장 중요한 요소는 양적인 팔로워 수 보다는 "활성팔로워 수"인데, 이게 높아야 QI지수가 높아지기 때문이다.** 인스타그램 노출 알고리즘 관련 분석글들 중 가장 잘된것만 몇개 추려봤으니 궁금하신 분들은 아래 링크 글들을 참고해 주길 바란다. (제법 out-dated 된 글들도 있으니 알아서 취사선택 바람)Instagram's got a new way to determine which photos show up in your feed — here's how it works (인스타그램 관계자가 한 말이라 제법 신뢰도가 있는 글)Understanding the Instagram Algorithm: 7 Key Factors and Why the Algorithm is Great for Marketers (위 글을 기반으로 나름의 상상력을 펼쳤는데 제법 그럴싸 해 보이는 글)How the News Feed Algorithms Work on Facebook, Twitter & InstagramHow do news feed algorithms work? (Quora, 첫번째에 있는 Abhinav Sharma의 답변을 참고하자)4. 컨텐츠 올릴때 해시태그를 많이 달 수록 노출이 많아지나요?결론은 "그렇지 않습니다" 이다. 필자도 사실 옛날에는 그런줄 알았다. 해시태그를 달면 해시태그 검색에 걸리고, 해시태그 서핑을 타고 들어온 오가닉 유입, 혹은 얻어걸린 탑 포스트에서 들어오는 유입이 많아질 거라 생각했는데, 어느날 우리 개발자가 "저렇게 해시태그 스팸질을 하는 꼴을 인스타가 그냥 놔둘것 같진 않은데 우리 한번 제대로 파보자" 해서 한달동안 인스타슈가를 통해 쌓인 수천만건의 DB를 분석했더니, 컨텐츠에 달리는 해시태그 수랑 노출량은 전혀 관계가 없다는 결과가 나왔다. 그 이유를 나름 추정해 봤는데, 인스타그램에서 해시태그 스패밍 이슈 해결을 위해 한 포스트에 태그를 많이 달수록 각 태그별 웨잇을 나눠서 분산시키기 때문이다. 무슨 말이냐면, 태그를 0-1개를 달때 1이라면, 10개를 달면 1/10이 10개가 되서 결국 1이 되는 개념이다. 이에대한 자세한 분석 결과는 우리 개발자가 쓴 인스타그램 #해시태그는 많이쓸수록 좋을까? 글을 참고해 주길 바란다.이렇게 해시태그 스팸 + 복붙할 시간에 컨텐츠나 댓글에 신경쓰자5. 라이크를 많이 받아야 탑 포스트에 노출되나요?이것도 결론은 "반드시 그렇지만은 않습니다" 이다. 탑 포스트 노출 로직은 더 베일에 싸여 있는데, 예전에 레딧의 한 유저가 실험을 해 본 글이 유명하다 - How to get to Instagram "top-posts" almost instantly (물론 2년전 글이기도 하고 개인이 자기 계정으로 실험해본거니 신빙성이 떨어지나, 그 로직 자체는 그럴싸 하다) 이 글에 의하면, 컨텐츠를 포스팅 한 후 24시간 이내에 라이크를 일정 수준 이상 받게되면 탑 포스트에 올라가고 (이걸 Growth Index라고 부른다), 한 해시태그에서 일정 기간동안 GI가 높은 포스트들을 번갈아 가면서 보여준다. 즉, 단순히 포스트에 라이크가 가장 많다고 탑 포스트에 계속 올라가 있는게 아니라는 뜻이고, 실제로 필자도 몇번 실험을 해봤는데 이 글의 로직이 어느정도 신빙성 있다.이제 탑포스트에 올라가는것 조차 복잡한 알고리즘이 돌아가고 있고, 계속 GI를 측정하면서 순환되기 때문에 굳이 비싼돈 들여 허위 라이크 구매하는 서비스를 사용할 필요가 없어졌다.지금까지 인스타슈가를 통해 접수되는 질문들 중 사람들이 가장 궁금해하는 토픽 5개를 뽑아 정리해 봤다. 아무쪼록 이 글이 위와 같은 질문을 상습적으로 받는 인스타그램 마케팅 담당자님들 (또는 광고주를 상대하는 대행사 분들)에게 조금이나마 도움이 됐으면 좋겠다.여기 아래부터는 우리가 서비스하는 인스타슈가라는 인스타그램 마케팅 자동화 솔루션을 (대놓고) 광고하려고 하니, 광고에 알러지가 있으신 분들은 여기서 창을 닫아주시기 바란다. (제발 "다 읽어보니 기승전광고네"라고 욕하지 말아주세요 ㅠㅠ)본인 브랜드가 스벅, 나이키 급도 아니고, 그렇다고 엄청난 컨텐츠력이 있는 상황도 아닌데 완전 제로베이스에서 인스타그램 팔로워를 늘려나가는건 결국 엄청난 노가다 작업이 수반된다. 노가다 작업이란건 뭐냐면, 맞팔류 태그들이나 빅태그들을 돌아다니면서 내 비즈니스 타겟에 맞는 사람들 계정을 선팔하며 돌아다니다 보면, 그들 중 일부가 맞팔을 해주게 되고, 이렇게 생긴 팔로워들을 잘 관리하면서 꾸준히 노가다를 하면 계정 활성도가 높은 몇천명대 인스타 계정을 누구나 만들수 있는 방법인데, 참 사람이 하기에는 너무 불쌍하고 고된 작업이다.시중에 이런 작업을 대신 해주는 프로그램들을 돈받고 파는 업체들이 매우 많이 있으나, 대부분은 다음과 같은 문제점을 앉고 있다.1) 설정해놓은 태그에서 최신 포스트의 계정을 무작위로 선팔하기 때문에 성인, 스팸계정, 내 비즈니스와 전혀 상관없는 계정들이 대거 걸리게 된다.2) 인스타그램에서는 사실 위와 같은 프로그램의 사용을 정책상 금지하고 있어서 계정별로 활동 리밋을 12-24시간 기준으로 정해놓는데, 물론 공개된 데이터가 아니다. 위의 프로그램들은 대부분 이런 리밋을 고려치 않고 설계되있고, 유저가 속도를 임의로 조절하면서 돌리도록 되있는데, 이러다가 계정이 기능블락에 걸리다가 심한 경우 disabled 먹는 경우도 다반사다.3) 비즈니스 계정들이 대거 걸린다. 내가 B2B 하는거 아니라면 대부분 인스타에서 "소비자"를 팔로워로 타겟하고 싶을텐데, 맞팔로 걸리는 계정들이 거진 "비즈니스"계정들이라, 심지어 같은 경쟁사들, 동종업체들끼리 모두 맞팔이 되어있는 경우도 다반사다.아무튼, 위에 언급한 문제 말고도 프로그램을 써서 팔로워를 늘리는거에는 정말 수만가지의 문제점들이 있어서, 작년에 우리가 직접 사용할 스크립트를 만들어 우리 계정 + 주변 스타트업 계정들 도와주다 보니 엄청난 퀄리티를 자랑하는 스크립트로 유명해져서 아예 정식 비즈니스가 된게 바로 인스타슈가라는 솔루션이다.인스타슈가 - https://instasugar.co/<iframe width="940.000000" height="529.000000" src="//play-tv.kakao.com/embed/player/cliplink/vdf62MgDwepuMGxRDaeyxpN@my?service=daum_brunch§ion=article&showcover=1&showinfo=0&extensions=0&rel=0" frameborder="0" allowfullscreen="">이 솔루션이 월등한 이유는 다음과 같다.1. 40여가지 이상의 기준으로 타겟할 유저를 결정2. 머신러닝 기반의 봇계정이 돌아다니며 수집하고 있는 160만건 이상의 성인, 스팸계정 DB를 통해 99.8%의 정확도로 스팸계정 필터링3. 해당 계정이 개인 계정인지, 비즈니스 용도인지를 검증하여 비즈니스 필터링 모드가 on 되어 있으면 비즈니스 계정들을 94%의 정확도로 필터링4. 인스타그램의 활동 리밋양을 추정하고 이 범위 내에서 최대효율을 내는 확률모델을 통해 가장 팔로워 전환 확률이 높을것으로 추정되는 계정들만 타겟함5.대시보드 -  현재 프로그램이 움직이는 로그, 타겟팅 해시태그 설정, 프로그램의 상태, 시작 및 정지, 다양한 특수 기능들을 모두 실시간으로 확인 & 통제 가능6. 안정성 - 해당 계정에 기능블락이나 특정 이슈가 생기는걸 실시간 감지하여 자동 정지, 속도 조절, 자동 재생 등이 통합적으로 이루어짐인스타슈가 사이트 회원가입 후 계정 연결하면 무료로 체험해 볼 수 있는 10명 토큰을 지급하고 있으니 관심있으신 분들은 체험해 보길 바란다. (무료라고 기능이 딸리고 그런거 아님. 유료나 무료나 동일한 토큰을 지급해 드립니다.)인스타슈가 웹사이트 바로가기

"모든 사람들의 경제적 자유를 실현하기 위한 구체적인 해결책을 제시하겠습니다." 파운트는 로봇이 자산관리 서비스를 제공하는 로보어드바이저(Robo-Advisor) 회사입니다. 기존의 은행이나 증권사 지점의 금융전문가(PB)들이 제공하는 자산관리 서비스를 기계가 대신해서 대중들에게 제공하는 서비스를 말합니다.영화 속에 등장하는 여느 로봇들처럼 하나의 인격체로서 로봇이 자산관리 서비스를 제공하는 것이면 좋겠지만, 로보어드바이저는 전통적인 퀀트 모델링을 기반으로 기계학습 등의 요소가 접목되어 고객들에게 투자에 좀 더 현명한 판단을 내릴 수 있도록 도움을 주는 기술입니다. 로보어드바이저는 고액자산가만이 누릴 수 있었던 자산관리를 일반 대중들도 누릴 수 있도록 서비스를 확장시켰다는데 그 의의가 있습니다.ㅣ 전통적인 자산관리 vs 로보어드바이저(Robo-Advisor)의 강점전통적인 자산관리는 금융전문가가 직접 투자 포트폴리오를 만드는 서비스였습니다. 하지만, 금융전문가는 사람인 만큼 자산관리 서비스를 제공할 수 있는 고객들이 한정적이었고 그에 따라 높은 수수료를 부담할 수 있는 고액자산가가 주된 고객이었습니다. 하지만, 고도화된 기술 발달에 힘입은 로보어드바이저의 등장을 통해 컴퓨터로 수천에서 수만명의 고객들을 대상으로 서비스를 제공할 수 있어 일반 대중들도 소액 투자금액과 낮은 수수료로 자산관리 서비스를 받을 수 있게 됐습니다. 뿐만 아니라, 자산이 어떻게 운용되고 어디에 투자되는지 등을 알기 위해서는 금융전문가에게 연락을 하거나 직접 만나야만 했지만 로보어드바이저를 통해서는 모바일과 PC를 통해서도 실시간으로 자산관리 현황을 파악할 수 있게 되었죠. 즉, 언제 어디서든 자산관리 서비스를 받아볼 수 있는 접근성에서도 우수하다고 할 수 있습니다. 게다가 사람의 잘못된 감정이 개입되지 않고 데이터를 중심으로 한 투자 의사결정을 내릴 수 있는 강점도 가지고 있습니다.이처럼 로보어드바이저는 저렴한 비용, 접근성, 데이터 중심적인 투자 의사결정 등에 경쟁력이 있습니다.ㅣ 로보어드바이저의 현황 및 전망은?국내는 대략 2015년부터 로보어드바이저 기업들이 등장하기 시작해서, 초기단계지만 최근 들어서는 정부 주도하에 코스콤이 주관하는 테스트베드도 시행하며 점차 성장하는 추세에 있습니다. 국내 대형 은행사와 증권사를 비롯해, 자산운용업계에서도 로보어드바이저 기업들과 협력한 금융상품들이 계속해서 출시되고 있는 것이 이를 반증하고 있습니다. 로보어드바이저 시장은 약 4~5년 전부터 미국에서 태동하기 시작해 매년 80%씩 꾸준히 성장하고 있습니다. 세계적 컨설팅 회사인 A.T Kerney의 보고서(2015년 기준)에 따르면 미국 시장은 2020년까지 연평균 64.56%씩 2.2조 달러까지 증가할 것이라고 보고 있으며, 실제로 세계적인 자산운용사인 블랙록(Black Rock)을 비롯해 골드만삭스 등 유수의 투자은행들도 로보어드바이저 시장에 뛰어들고 있는 상황입니다.ㅣ 파운트의 목표와 투자철학은?로보어드바이저는 인간보다 뛰어난 분석력을 바탕으로 높은 수익률을 담보하는 서비스가 아닙니다. 아직은 많은 고객들이 로보어드바이저를 황금알을 낳는 거위로서, 고도화된 IT기술력을 바탕으로 높은 수익률을 담보하는 서비스라고 이해하는 것 같기도 합니다. 하지만, 이는 시스템(System) 트레이딩의 목표이지 로보어드바이저의 목표는 아닙니다. 파운트는 시장의 위험을 최소화 하면서, 시장 벤치마크 + 알파의 수익률을 추구하는 자산관리 서비스이며, 글로벌 자산배분과 정교화된 알고리즘, 그리고 안정화된 엔진 기술력을 추구하고 있습니다.파운트(fount)의 명칭은 분수(fountain)라는 라틴어에 그 어원을 두고 있습니다. 투명하고 언제나 샘솟는 분수처럼 파운트의 서비스를 통해, 모든 사람들이 경제적 자유의 혜택을 누릴 수 있도록 앞장서겠습니다.

안녕하세요~오늘은 4월 2일, 3일에 진행되었던Live 설명회 비하인드를 풀어보려고 합니다!!ㅎㅎ    먼저, Live 설명회가 무엇이냐? 하면,11번가 2019 상반기 인턴 채용을 맞이하여좀 더 지원자들에게 친숙하게 다가가고~편하게 정보를 제공해 드리기 위해 기획한! 온라인 채용 설명회 입니다!        Live 설명회의 현장! 궁금하지 않으신가요? Go Go!!        입장 통제를 넘어 들어가면..! 두구두구        짜잔! Live 설명회 현장입니다!방송 시작 전 음향 및 장비를 체크하는 리허설 모습입니다.        실무자 분들을 기다리고 있는 빈 자리들!!ㅎㅎ        자리가 채워지고 방송 시작을 기다리고 있는 모습입니다!많이 떨리고 긴장되던 순간이죠 ㅎㅎ            16:00 맞춰서 시작된 Live 설명회!사전녹화 영상이 나가는 동안저희는 실시간 채팅을 살피며Q&A시간을 대비하고 있었답니다! ^^            실제 방송 모습과 현장 모습의 갭차이!!다들 너무 긴장하셨어요 ㅠㅠ (ㅎㅎ)    사진에는 없지만,MD와 서비스 기획 직군 실무자 분들께서도많은 수고를 해주셨답니다!(짱짱!)다음에 기회가 된다면, 좀 더 좋은 화질과 음향으로! ㅎㅎ좀 더 능숙하게 11번가의 자연스러운 모습을 보여드릴 수 있도록 노력하겠습니다!    실제 방송 모습은 11번가 채용의Youtube 채널에서 다시 보실 수 있습니다!!        1시간 동안 사전 질문 및 실시간 채팅 질문들을 모두 대응해드리고 싶었는데,답변 드리지 못한 질문이 많은 것 같아 죄송할 따름입니다 ㅠㅠ    생각보다 많은 분들께서 참여해 주셨고, 시청해 주셨습니다!정말 감사드립니다~! ♡_♡더 도움이 되는 정보를 얻어가실 수 있도록 노력하겠습니다!!    마지막은 자축하는 고기!!!!ㅎㅎ

안녕하세요 대한민국 셀러들의 성공적인 아마존 진출을 도와주는 컨설팅 회사이자 대행사인 주식회사 컨택틱의 이이삭 대표입니다.상품을 소싱하다보면 여러 제조사들 중에 하나를 고르게 되는 상황을 당면하게 됩니다. 이때 어떤 기준을 가지고 각 제조사를 비교하는 게 좋을까요? 4가지만 기억하세요.1. Quality아마존 성공 비법에 대해 이야기할 때 제가 입이 닳도록 하는 얘기가 있습니다. “아마존에서 성공하려면 제일 신경 써야 하는 게 2가지가 있다: (1) 수요가 많고 공급은 적으면서, 그 낮은 공급 안에서 소비자들이 불만을 품고 있는 황금 틈새시장을 공략하는 것이고 (2) 그 시장 속에서 불만 가득한 소비자들의 가려운 곳을 시원하게 긁어줄 수 있는 상품을 준비하는 것이다”결론은 무엇인가요? 결국 소비자들이 만족하는 ‘퀄리티 있는 상품’이 있어야 한다는 것입니다. 소비자들이 만족하지 않으면 마르지 않는 자금도, 뛰어난 마케팅 전술도, 온갖 인맥도 소용없습니다. 퀄리티가 떨어지는 상품은 언젠간 진면목이 드러나기 마련이며, 그렇게 됐을 때, 잘 팔리다 가도 누적되는 악성 후기와 입소문 때문에 판매가 급격히 하락하게 될 것입니다. 그만큼이나 상품의 퀄리티가 중요한 것입니다. 따라서 소싱 단계에서 이 제조사 저 제조사 고민하고 있을 때 가장 우선적으로 고려해야 할 사항은 바로 그 제조사가 제조한 상품의 퀄리티입니다.2. PricePhoto by Rajiv Perera on Unsplash그렇다면 이렇게 물어볼 수 있을 겁니다: “퀄리티는 가격과 비례하지 않나요?” 물론 어느 정도 비례한다는 것은 사실입니다. 하지만 얼마나 많은 정성과 공을 들였는지에 따라 비교적 저렴한 재질/소재로도 충분히 소비자들을 만족시킬 수 있는 제품을 제조할 수가 있습니다. 퀄리티가 떨어지는 상품을 저렴하게 매입하고 저렴하게 판매하기보다, 차라리 돈 몇 푼 더 주고, 누구라도 만족할만한 퀄리티의 제품을 적당한 가격에 판매하는 게 백배 낫습니다.소싱 할 때 그러면 가격적인 부분을 고려할 때 어떻게 판단할 수 있을까요? 도대체 얼마가 ‘적당한’ 매입 가격인 걸까요? 두 가지를 고려하면 됩니다: 1) 해당 시장의 평균 가격대가 얼마인지를 조사하고 2) 원가(매입가)를 제외한 나머지 제반 비용을 계산하는 것입니다. 그러면 거기에 내 수익을 더하면 예상 판매가가 나오게 될 텐데, 당연히 그게 시장 평균 가격대와 너무 큰 차이가 발생하면 안 되겠죠?해당 시장의 평균 가격대를 계산하는 것은 조금만 조사해보면 누구든지 쉽게 알아볼 수 있겠지만, 판매 시 발생할 제반 비용을 정확하게 계산하는 건 솔직히 조금 어려울 수 있습니다. 컨택틱은 아마존 전문 기업이기 때문에 금방 계산할 수 있지만, 여러분들도 혼자서 어느 정도 계산할 수 있도록, 고려해야 하는 비용 항목들이 어떤 것들이 있는지 알려드립니다: 1) FBA 창고에 도착하기 위해 드는 개당 물류비 2) 개당 아마존 판매 수수료 3) 개당 월별 창고 보관료 4) 개당 소정의 마케팅 비용 5) 개당 원가 6) 개당 이익. 이 6가지를 고려해서 결국 최종 판매가가 계산됩니다. 그럼 여기서 원가를 제외한 나머지 비용을 임의로 계산한다면 제조사로부터 물건을 매입할 때 감안할 원가 하한선 또는 상한선이 파악되겠죠?다시 한 번 강조하지만, 제일 중요한 건 상품의 퀄리티입니다. 그다음에는, 비용 및 수익 등을 고려했을 때, 시장 평균가를 고려하여 너무 큰 괴리가 없을 정도의 적합한 원가(매입 가격)을 따져야 합니다.3. MOQ그다음으로 고려해야 할 것은 MOQ(Minimum Order Quantity) 즉 최소 주문 수량입니다. 당연히 제조사 측에서는 매출을 늘리기 위해 이 수치를 최대한 높게 잡으려고 할 것입니다. 하지만 이 수치가 높으면 높을수록 구매를 하는 바이어 입장 (여러분의 입장)에서는 부담이 될 수밖에 없습니다. 따라서 최대한 제조사 측과 협상을 해야 하는데, 뻔한 레퍼토리의 말, 예를 들어 ‘이번에는 소량으로 주문하고, 다음 주문에는 대량으로 주문하겠다’ 등은 당연히 해야 되는 말이고, 다른 바이어들과 나를 구분 짓게 만들 정도의 임팩트 있는 말을 하는 게 중요합니다. 이번 글은 MOQ를 어떻게 조정하는지에 대한 팁을 드리고자 하는 게 아니기 때문에 그 내용은 다른 글에서 다루겠습니다. 어쨌거나, 이 제조사 저 제조사 중에 어느 제조사로 계약을 체결할지 고민할 때 3번째로 고려해야 하는 것은 MOQ 협상 가능 여부입니다. 분명히 시장조사를 통해서 이 시장, 이 상품군이 어느 정도 유력하다는 것을 조사했겠지만, 정말 출시해보기 전까지는 아무도 모르는 게 어쩔 수 없는 현실이기 때문에, MOQ를 최대한 협상 가능한 제조사와 거래하는 게 유리합니다.4. CommunicationPhoto by Startaê Team on Unsplash제조사는 기계가 아닙니다. 그들도 엄연히 ‘사람’들이기 때문에 결국 소통을 하는 내내 관계를 형성하게 됩니다. 원활한 소통을 하고 관계를 형성하려면 당연히 말이 통해야 합니다. 소통이 어려울 정도로 회신이 늦는다거나, 영어실력이 현저히 부족하면 계약 단계에서부터 발주 단계 결제 단계 운송 단계, 심지어 재주문 단계에서도 골치가 아플 수 있습니다. 이런 점들을 고려해서 communication이 원활한 제조사인지 아닌지를 따지는 게 마지막으로 체크해야 할 항목이라고 볼 수 있습니다.컨택틱의 모든 교육은 파트너인 글로벌셀러창업연구소와 접수하고 진행합니다. 교육 신청은 아래 링크나 글로벌셀러창업연구소의 홈페이지를 통해 가능합니다.오프라인 아마존 입문 과정오프라인 아마존 기초/심화 과정온라인 아마존 입문 과정그럼 오늘도 즐거운 글로벌 셀링 되세요!감사합니다.컨택틱서울특별시 서초구 서초대로 356, 606호(서초동, 서초지웰타워)대표 전화: 02-538-3939이메일: [email protected]홈페이지: https://www.kontactic.com네이버 블로그: https://blog.naver.com/kontactic카카오 브런치: https://brunch.co.kr/@allaboutamazon유튜브 채널: https://www.youtube.com/c/kontactic

지금까지 썼던 다섯 개의 글은 2016년에 스토리 펀딩에 연재했던 글을 약간 수정한 것입니다. 2년 전에 썼던 글을 다시 읽고 다시 쓰며 그때의 나보다 지금의 나는 얼마나 성장했을까 생각해봤습니다.  [스토리펀딩] 스트레스 속에 지친 그대에게왜 NO STRESS가 아니고 STRESS COMPANY냐는 질문을 가끔 받곤 합니다만, 스트레스는 나쁜 말이 아닙니다. 스트레스는 우리 몸에서 없앨 수도, 없어서도 안 되는 시스템이기 때문입니다. 누구도 피할 수 없는 스트레스, 당신 삶의 에너지로 만들어 드리겠습니다storyfunding.daum.net 스토리펀딩의 글 리스트처음 스토리 펀딩의 문을 두드리게 된 건, 그동안의 삽질을 기록하고 싶은 의미가 더 컸습니다. 그런데 5화쯤 쓰고 나니 더 이상 쓸 말이 없구나라는 걸 깨달았고, 조금 더 나를 쌓아야겠구나 하는 생각이 들더군요. 그 생각은 첫 번째 글에 달린 댓글을 읽으면서 더더욱 강하게 들었습니다.저거 태운다고 화가 풀리나?처음 이런 댓글을 받고 얼마나 당황했는지 모릅니다. 그 후론 댓글 창을 열어보는 것조차 겁이 나고 두려웠습니다. 그러다 마음을 가라앉히고 생각을 해보기로 했죠. 내가 저런 말을 들은 것이 한두 번인가. 그거 태운다고 뭐 달라지냐, 왜 회사 이름은 스트레스컴퍼니냐, 스트레스 만드는 회사냐, 너나 잘해라... 등등등.  사실 그때마다 웃으며 넘어갔지만, 물론 저는 하나하나 다 마음에 담아두었습니다..  그리고 그것들은 이따금씩 제 맘을 치고 올라와서 저를 괴롭게 만들었습니다. 그렇게 한참을 괴로워하다가 도저히 안 되겠다 생각하고 제가 시도했던 방법은 바로 이것입니다. 그들이 하는 말 하나하나에 반응하지 않고, 그들의 입장이라면 그럴 수 있다고 생각하자. 그리곤 익명의 그들에게 답장을 보냈습니다. 한 명도 빠짐없이.물론! 안 풀릴 수도 있어요.그들이 던진 악플을 회피하지 않고, 무턱대고 분노하지 않고, 상황에 직면해서 상담하듯 그들에게 답장을 쓰다 보니, 제 마음이 가라앉는 것이 느껴졌습니다. 제가 그들을 모르듯, 그들도 제가 어떤 사람인지 모릅니다. 저의 글을 한번 읽었다고 해서 저라는 사람을 다 알 수는 없습니다. 그런 그들이 내게 상처를 던졌다고 해서, 그걸 모두 제가 받아 들고 아파해야 할 이유는 전혀 없으니까요. 그렇게 하나둘씩 제 마음속을 정리하고 나니, 다행히 제 답글을 읽은 분들이 조금씩 제 마음을 이해해주기 시작했습니다.이렇게 모두가 행복하게 잘 살았습니다! 였다면 참 좋았겠지만, 2화에도 3화에도... 역시 악플은 달렸고요. 저는 그때마다 생각했습니다. 이 사람들은 대체 어떤 상처가 있길래, 내 작은 글에 이렇게까지 반응을 하게 되었을까.. 분명 내 글의 어떤 부분이 그들에게 방아쇠가 되어 상처를 건드렸겠지라고 생각하니 마음이 아팠습니다. 그래서 또 저는 마음을 담아서 답장을 썼습니다. 그랬더니 정말 제 마음을 이해해주더라고요. 제게 마음을 다루는 일을 한다는 사람이 이렇게 쉽게 말을 해도 되냐면서 저주의 말을 쏟아내셨던 분이 저의 답글을 보고, 원 글을 삭제하고 제게 사과를 하셨습니다. 이때가 제일 뿌듯했던 순간입니다. 누군가 던진 상처를 내가 상처로 받아들이지만 않는다면, 상처가 되지 않을 수도 있구나!라는 걸 깨달았기 때문입니다.그렇게 저는 보살이 되었습니다. 는 거짓말이고요. 이후로는 누가 내 인생에 악플을 달면, 대체 나에 대해서 뭘 안다고 저런 말을 저렇게 함부로 뱉지!@#$@%%^$^$%$%@$@&*(((**000!!!!라고 생각하기보다 눈을 감고 하나, 둘, 셋을 세면서 마음을 가라앉히고 저 사람도 상처가 있겠지 하고 생각해보게 되었습니다. 모든 감정에는 이유가 있으니까요.그리고 그건내 마음도 똑같습니다. 내 마음에도 이유가 있습니다. 너무나 바보 같은 실수를 해서 나에게 너무나 화가 날 때도, 그때도 그렇게 해야 합니다. 저는 얼마 전에 병원에 가던 길에 배가 고파서 바나나를 사야겠다는 생각이 들었습니다. 그리고 병원 옆에 있던 식료품 가게를 떠올렸죠. 그래서 가게 앞에 닿자마자 저는 주차를 하고 얼른 바나나를 사러 뛰어갔습니다. 제 차 바로 뒤에 주정차 위반 차량 단속이라는 전광판을 달고 있는 차가 빵빵대고 있었는데도 말입니다. 그 때는 그냥 얼른 사 갖고 나오면 되지라고 생각했습니다. 왜냐고요? 그때 제 머릿속에는 바나나밖에 없었으니까요..   그렇게 3,000원짜리 바나나를 사고 굉장히 뿌듯하게 가게를 나서는데, 주정차 위반 단속 차량이 다시 돌아서 제게로 다가오고 있더군요. 제 앞에 빽빽하게 서있던 차들은 어느새 모두 빠져있고, 제 차만 덩그러니 서있었습니다. 아... 그제서야 내가 무슨 짓을 했는지 깨달았고, 갑자기 불안이 엄습해왔습니다. 차를 빼고 병원으로 올라가서 대기하는 동안 저는 미친 듯이 검색을 했습니다. 주정차 위반 단속 차량, 주정차 위반 과태료, 주정차 위반 조회,,,, 를 검색하는 동안 마음속은 타들어갔고, 나는 왜 그 차를 보고도 아무 생각을 하지 못했는가, 왜 나는 그때 바나나를 사야만 했나, 바나나를 안 먹고 그냥 지나쳤다면 이런 일이 없었을 텐데, 과태료가 나오면 어떡하나, 정말 찍힌 건가, 40,000원이면 맛있는 초밥을 신나게 먹을 수 있었는데, 나는 바보인가의 늪에 빠져서 한참을 허우적대다가 눈을 감고 하나 둘 셋을 세며 현실을 인정하기로 했습니다.나는 43,000원짜리바나나를 샀다는 것을...그러고 나니 거짓말처럼 마음이 편해졌습니다. 이미 벌어진 일, 더 이상 그건 내가 어쩔 수 없는 일이니까요. 어쩔 수 없는 일은 그냥 내려놓는 것이 정답입니다. 그렇게 저는 아주 비싼 바나나를 맛있게 먹었습니다.I llike banana.그래서지금은 스트레스를 안 받나요?스트레스컴퍼니를 시작하고서 제일 많이 들었던 질문이 그래서 지금은 스트레스를 안 받냐는 것이었습니다. 그러나 저는 지금도 여전히 스트레스를 많이 받고 있습니다. 그렇지만, 이전에 저는 스트레스를 받을 때마다 가장 가까운 사람들에게 짜증을 내며 내 감정을 정당화시키려고 했다면, 지금의 저는 힘든 감정에 휩쓸리기보다 다시 편안해지기 위해 노력합니다. 화가 나면 누구도 아닌 나 자신이 제일 괴롭다는 것을 알기 때문이죠. 그렇게 기분을 전환시킨 후에 천천히 곱씹으며 나를 화나게 한 것은 무엇인지, 왜 내가 화가 난 것인지를 생각해보곤 합니다. 그렇게 나 자신에 대해서 한 발짝씩 다가가다 보면 내가 중요하게 생각하는 것들이 보입니다. 내가 왜 바나나를 그때 그 시간에 먹을 수밖에 없었는지에 대한 이유 같은 것들 말이죠. 저는 병원을 갔다가 바로 운동하러 가야 했고, 그런데 배가 고팠고, 그래서 운동을 가기 전에 배를 채워야 했고, 그리고 그러기엔 바나나가 제격이었기 때문입니다.그리고 전 스트레스를 받을 때마다 상품을 만듭니다. 스트레스가 주는 에너지를 건설적으로 발휘할 수 있는 대상이 필요하거든요. 그래서 스트레스컴퍼니 상품이 벌써 30개가 넘었습니다. 하하. 그리고 2월에도 또 신상품이 나옵니다. 감정카드 50개. 뚜둔!2017년 스트레스컴퍼니의 상품들, 지금은 더 늘어났습니다.스트레스라는 건 없앨 수도 없고, 또 없어서도 안 되는 우리 몸을 다스려주는 시스템입니다. 누구는 피할 수 없다면, 즐기라고 하지만, 그건 도인들이나 할 수 있는 경지가 아닌가 싶습니다. 저는 아직 도인이 아니기에, 피할 수 없으면 받아들여보기로 했습니다. 그렇게 스트레스를 온몸으로 받아들이며 내가 느끼는 감정들이 내게 말하고자 하는 것들을 천천히 곱씹어 보려 합니다. 모든 감정에는 이유가 있으니까요. 저는 시련이 주는 가르침을 믿습니다.스트레스컴퍼니의 제품들은 스트레스컴퍼니샵에서 구매 가능합니다.ⓒ스트레스컴퍼니 - 무단 전재-재배포 금지#스트레스컴퍼니 #심리스타트업 #스트레스관리 #서비스소개 #제품소개

개발자와 개발 조직에게 소스코드 리뷰는 필수적이다. 팀간의 협업과 대화를 보다 원활하게 만들어 주는 매우 필요한 절차이다. 슬랙과 같은 협업도구가 명쾌하게 의미 있게 활용되려면 개발팀 간의 소스코드 리뷰는 필수적으로 수행되는 것이 좋다.매우 당연한 이야기이지만, 소스코드 리뷰는 거북하고 불편하고 어렵고 힘들다. 그럼에도 불구하고 필수적인 이벤트가 되어야 하는 이유가 너무도 많다. 개발자들에게 코드리뷰에 대한 이슈를 설득하고 실제 행위를 발생시키는 것은 정말 어려운일이다. 더군다나 뜬금없이 코드리뷰 이야기를 회사나 팀리더에게서 갑자기 듣는다면 개발자는 매우 불편해 한다. 그것은 매우 당연한 반응이다. 그러므로, 가능하다면 팀 세팅 초기 시부터 이 소스코드 리뷰 문화는 만들어질 수 있게 노력하는 것이 최선일 것이다.초기에 세팅된다면 그 후에 들어오는 팀원들은 자연스럽게 그 문화에 익숙해진다. 이런 일련의 작업들은 결국 조직과 팀의 단결과 협력, 향후 유지보수에 매우 긍정적인 효과를 준다.매우 당연하지만 개발자들은 팀에 소속되고 빠져나가기를 반복한다. 이를 두려워하지 않는 방법 중에 가장 먼저 선택할 수 있는 것이 바로 코드 리뷰라는 행위다. 인수인계와 유지보수를 위해서 소스코드 리뷰를 각 단계별에 배치해두고, 그 시간을 투자하는 것을  아까워하지 않도록 하자.그렇다면, 소프트웨어의 본체인 소스코드를 타인이 리뷰한다는 것이 왜 어려울까? 그것은 소스코드는 언제나 완성상태가 아니라는 점 때문이다. 개발자의 생각은 무언가 다양한 변화를 예측하고 있고, 그 상세한 준비를 담고 있다. 언제나 소스코드는 완성 상태가 아니라, 변화되어야 하는 시간의 축을 담고 있기 때문이다.하지만, 소프트웨어 품질이 중요한 현재의 시점에서 본다면, 코드 리뷰라는 행위는 정말 필수 불가결한 행위에  해당한다고 생각한다.이런 필수적인 코드리뷰는 그 형태와 범위에 대해서 팀 내부에 잘 정의되어야 한다.그래서, 보통 이 코드리뷰를 어떻게 할 것인가에 대해서 조직이나 담당하는 사람의 경우에는 명쾌한 판단 기준이 있어야 한다. 그러한 ‘판단기준’을 가져야만 명확한  리뷰될 수 있다.이를 두고, 디자이너에게는 크리틱(critique-비평)이 있고, 개발자에게는 코드리뷰가 있다고 정의한다.좋은 비평을 받고 좋은 리뷰를 하려면 다음의 3가지 원칙이 필수이다.1. 리뷰는 언제나 상호 합의가 되어진 상황에서 진행되어야 한다.2. 리뷰어의 해당 결과물에 대해서 객관성을 가지고 서로 인지해야 한다3. 개발자 자신의 작업물에 대해서 정말 객관적으로 바라볼 수 있는 작성가가 선정되어야 한다.특히, 소프트웨어 코드는 정량적인 검토와 정성적인 검토를 구분해야 한다. 이 영역의 구분이 모호해지면, 리뷰는 그 방향성을 상실하게 된다. 그중에 특히, 정량적인 검토와 기본적인 규칙들은 가능한 자동화하고, 소스 형상관리 도구에서 기본적인 것들의 규칙들을 지키도록 권장하여야 한다. 최소한 이 정량적인 것만 자동화하고  규칙화해도 소프트웨어의 품질은 급상승한다.하지만, 코드는 논쟁을 발생시키고, 어떤 것이 우선적인지에 대해서 서술하기 매우 어렵다. 이러한 점은 정성적인 부분에 대해서 검토할 때에 고민하자.코드리뷰의 정도는 어느 정도 해주어야 하는가?그 전부터 주목하는 개발 방법론의 추세는 ‘테스팅’을 주로 하고, SRS와 같은 요구사항에 집중하기 보다는, TDD와 같은 방법으로 완성 산출물을 높이는 방법을 현재에는 주로 사용하고 있다.그것은 과거에는 요구사항을 통해서 결과물이 완성되는 SI성 개발이 주로였다면, 현재에는 요구사항은 계속 변화하고 버그 없는 결과물이 중요시되는 테스트를 얼마나 더 집중적으로 하느냐에 따른 웹서비스의 시대이기 때문에 그 방향성은 시대에 따라서 변화를 많이 하였다. 그래서, 슬프지만, 당장의 성과물을 위해서라면 코드리뷰보다는 테스팅에 집중하는 것이 더 효율적이다. 빠르게 고속 개발하고 테스트를 통해서 버그를 찾은 다음 수정하는 것이 ‘특정 기능들을 나열하고 기능을 만족하는 소프트웨어’의 경우에는 테스트 주도 개발 방법이 가장 적합하다고 할 수 있다.물론, 이러한 방향성이나 전체적인 틀에 대해서는 아키텍트가 잘 결정하여야 한다. 내가 속한 개발 결과물이 어떤 결과물이냐에 따라서 이 방법은 혼용되어져서 사용되어야 하기 때문이다.하지만, 이번 글의 주목적은 코드리뷰. SRS중심이건, TDD중심이건. 코드리뷰는 중요하다는 것을 강조하고 싶다. 특히, 코드리뷰는 ‘기능 나열’이 아닌, 어느 정도 이상의 복잡도나 코드 품질이 필요한 경우에는 필수적으로 수행하는 것이 매우 현명한 행동이다.물론, 코드리뷰 행위가 불필요한 업무들도 많다. 정해져 있는 단순한 업무를 수행하는 경우에는 굳이 할 필요 없다. 국내에서 SI를 하는 경우에는 대부분 코드리뷰가 필요 없는 업무를 하는 소프트웨어 개발자들이 절대 다수인 경우도 많이 보았다.일반적인 SI의 형태라면 워크 스루의 형태만 적합하다. 특정 도메인에 매몰되어 있고, 처리방법이 명쾌하기 때문에, 해당 경험들을 교환하는 것으로도 충분하기 때문이다. 그리고, 자동화된 테스트 수행방법을 최대한 갖추어두는 것이 가장 현명하다.그러므로, 코드리뷰는 어느 정도 솔루션이나 서비스 등을 고려하고 있는 곳에서 더욱 적합하다고 정의한다.코드리뷰는 특정 제품이나 서비스를 발전적으로 지향하고 있는 경우라면 필수적으로 선택해야 한다. 하지만, 일부 제품의 경우에는 발전적인 지향이 굳이 필요 없는 제품 라인업을 가진 경우에도 굳이 수행할 필요 없다.그 경우에는 선택적인 코드리뷰를 지향하면 된다. 비용상의 문제 때문에 굳이 코드리뷰를 억지로 진행할 필요는 없는 경우도 많다. 대부분의 소프트웨어 개발은 테스트 케이스를 잘 만들고, 통과시키는 것으로써 충분한 신뢰를 가지면 충분한 경우가 대부분이다.특히, 시장이 고착상태이거나, 특별한 변화의 폭이 없다면, 그 정도로 충분한 경우가 된다. 다만, 글로벌 서비스나 웹서비스 등의 지속적인 확장이 필요한 경우라면, 코드리뷰는 필수라고 할 수 있다.코드리뷰가 필요 없는 경우 체크리스트는 다음의 5가지 정도를 체크해보자.1. 특정 도메인만 다루는 팀이나 회사의 개발팀인가?2. 지난 2~3년 정도 솔루션이 크게 변한 것이 없으며, 향후로도 기업이나 팀에서 투자가 없을 예정이다.3. 현재 개발자들이 해당 솔루션에 대한 개발일을 5년 이상하고 있다.4. 기능 위주의 SI성 업무를 주로 처리하고 있으며, 복잡한 알고리즘은 존재하지 않는다.5. 비용과 일정상 개발팀에게 리소스 투여가 불가능하다위의 사례에서 1개 이상이라도 체크된다면, 코드리뷰는 성립하기 힘들다. 대부분 단념하고, TDD나 테스트 케이스를 가능한 많이 축적하여 소프트웨어 품질을 올리기를 권장한다.코드리뷰가 필요한 경우의 체크리스트도 다음의 5가지 정도를 체크해보자.1. 다국어와 시장이 다변화된 환경에서 소프트웨어가 구동되어야 한다.2. 코드의 복잡도가 높으며, 단순 기능 나열의 요구사항이 아니라, 소프트웨어 아키텍처가 별도로 구성되기 시작하였다.3. 사용자의 경험성을 증가하기 위하여 매우 많은 변화가 예측된다.4. 현재 개발 중인 서비스는 중단 없이, 지속적으로 발전되어야 하는 서비스이다.5. 목표 요구사항이 계속 변화하고 있고, 프레임워크를 지향하여 소프트웨어 품질의 요구사항이 매우 중요하다.위의 케이스에서 하나라도 해당이 된다면, 코드리뷰는 매우 효과적으로 소프트웨어에 의미 있는 결과물들을 얻어 내기 위한 좋은 방법이 된다.하지만, 다음과 같은 경우도 같이 고려하여야 한다.코드리뷰의 정도와 질에 대한 검토 리스트의 최소 체크리스트는 다음의 3가지이다. 물론, 이 정의는 조직 내의 아키텍트나 아키텍트 롤을 하는 사람이 결정하는 것이 좋다.1. 실험적인 코드인가?2. 1~2명 이상이 공동으로 작업하는 코드인가?3. 향후 버려질 가능성이 높은 코드인가?코드리뷰를 하지 않는 경우에는 해당 코드의 repository나 디렉터리를 완전하게 분리하고, 리뷰가 안된 코드를 명쾌하게 구분할 수 있어야 한다. 그리고, 그 정보는 팀 전체에게 공개되어야 한다.가장 첫 번째는 코딩규칙 가이드라인의 준수 여부를 체크하는 것이다.개발자들 간의 상호 중요한 것은 스타일 가이드이다. 하지만, 정말 지키기 어려운 것 또한 스타일 가이드라고 할 수 있다. 하지만, 스타일 가이드는 가능한 준수해야 한다. 하지만, 100% 준수하려는 것은 매우 비효율적인 상황을 만들 수 있다. 하지만, 이 경우에 최소한 리뷰어가 제시하는 기준이나 변경 방향에는 대부분 수긍하는 것이 가장 현명하며, 이 부분은 해당 팀의 가장 경험이 풍부한 사람이 리드하는 것이 좋다.그래서, 소프트웨어 개발에는 경험이 풍부한 아키텍트의 역할과 선임의 역할이 가장 중요하다. 소셜에서 이야기하는 가장 중요한 포인트는 이런 경험이 풍부한 선임 개발자가 있다면, 돈이 얼마가 들더라도 ‘개발팀’에 모셔야 한다! 가 정답일 것이다.아직까지 이 부분은 ‘공학’으로 해결할 수 없고, ‘엔지니어링’과 ‘경험’에 의존할  수밖에 없다.주석의 경우에도 ‘가독성’이 충 부한 코드에는 서술할 필요 없다. 이 부분에 대해서는 꾸준한 팀원들 간에 코딩 문화에 대해서  커뮤니케이션하면서 주석의 범위에 대해서 공론화하는 것이 현명하다. 그래서, 소프트웨어 개발은 대부분이 ‘커뮤니케이션’이고 ‘소통’이다. 그래서, ‘팀워크’이 가장 중요한 것이고. 변수의 명칭에 대해서도 ‘명확’하다는 선에서 합의해야 한다.테스트가 쉽지 않은 구조는 다른 문제를 야기한다. Junit과 같은 단위 테스트 도구로 손쉽게 정의가 가능한 구조가 아니라면, 변경해야 한다.코드리뷰 후에 분명하고 타당한 지적에도 고집이 세서 변화가 없는 경우에는 한두 번 이야기하고 더 이상 변화가 없다면, 포기하고. 해당 코드를 격리하여 관리하는 것이 현명하다.  팀원들 간에 감정이 상하는 것이 더 위험하다. 사람은 변하지 않는다 감정에 대한 다툼이나 기대를 할 필요가 없다.UI가 중요한 코드는 해당 코드들이 급변할 가능성이 농후하다. 처음부터 공을 들여서 추상화를 실현하지 않으면, 해당 코드 때문에 프로젝트가 심각해질 수 있다. 사용자에게 더 좋은 경험을 전달하려고 하면, UI코드는 계속 변화를 일으킨다.테스트 코드 여부? 로직에 대한 검토, 변수 네이밍 검토와 레이아웃에 대한 것들? 에 대해서는 다음과 같이 판단하고 체크해보자.코드리뷰는 대부분 ‘직관’에 의존한다. 그래서, 정말 어렵고. 경험이 풍부한 사람이 할  수밖에 없다. 다만, 이러한 코드 리뷰 시의 체크리스트 항목을 몇 가지 간단하게 정리할 수 있다. 최소한의 2가지는 꼭 지키자.코드 리뷰 시의 필수 내용 두 가지는 다음과 같다.1. 코드 검토는 1시간 이내에 끝낼 분량으로 검토한다.2. 코드는 200라인 이상을 한 번에 검토하지 마라이 기준이 어겨지면, 리뷰어는 제대로 된 리뷰를 하기 어려울 것이다.  그리고, 이러한 리뷰를 하는 동안 기능에 대한 검토 체크사항에 대해서 나열해 보면 다음과 같이 나열이 될 수 있을 것이다.1. 시스템의 요구사항이 제대로 반영되었는가?2. 시스템의 설계의 규격대로 구현되었는가?3. 과도한 코딩을 하고 있지 않는가?4. 같은 기능 구현을 더 단순하게 할 수 있는가?5. 함수의 입출력 값은 명확한가?6. 빌딩 블록들( 알고리즘, 자료구조, 데이터 타입, 템플릿, 라이브러리, API )등이 적절하게 사용되었는가?7. 좋은 패턴과 추상화( 상태도, 모듈화 )등을 사용해서 구현하고 있는가?8. 의존도가 높은 함수나 라이브러리 등의 의존관계에 대해서 별도 기술하고 있는가?9. 함수의 반환(exit)은 한 곳에서 이루어지고 있는가?10. 모든 변수는 사용 전에 초기화하고 있는가?11. 사용하지 않는 변수가 있는가?12. 하나의 함수는 하나의 기능만 수행하고 있는가?또한, 스타일과 코딩 가이드에 대해서고 검토하고 리딩을 해야 한다.1. 코딩 스타일 가이드를 준수하고 있는가?2. 각 파일의 헤더 정보가 존재하는가?3. 각 함수의 정보를 코드에 대해서 설명하기에 충분한가?4. 주석은 적절하게 기술되어있는가?5. 코드는 잘  구조화되어있는가? ( 가독성, 기능적 측면 )6. 헤더, 함수 정보를 도구로 추출해서 자동으로 문서화할 수 있는 구조인가?7. 변수와 함수의 이름이 일관되게 기술되어 있는가?8. 프로젝트의 가이드를 통한 네이밍 규칙을 준수하고 있는가?9. 숫자의 경우 단위에 대해서 기술하고 있는가?10. 숫자를 직접 서술하지 않고, 상수를 사용하고 있는가?11. 어셈블리 코드를 사용하였다면 이를 대체할 방법은 없는가?12. 수행되지 않는 코드는 없는가?13. 주석 처리된 코드는 삭제가 되었는가? ( 버전 체크가 되었는가? )14. 간결하지만 너무 특이한 코드가 존재하는가?15. 설명을 보거나 작성자에게 물어봐야만 이해가 가능한 코드가 있는가?16. 구현 예정인 기능이 있다면, ToDo주석으로 표시되어 있는가?가장 중요한 아키텍처에 대한 검토를 잊으면  안 된다.1. 함수의 길이는 적당한가? ( 화면을 넘기면  안 된다. )2. 이 코드는 재사용이 가능한가?3. 전역 변수는 최소로 사용하였는가?4. 변수의 범위는 적절하게 선언되었는가?5. 클래스와 함수가 관련된 기능끼리 그룹화가 되었는가? ( 응집도는 어떤가? )6. 관련된 함수들이 흩어져 있지 않는가?7. 중복된 함수나 클래스가 있지 않는가?8. 코드가 이식성을 고려하여 작성되었는가? ( 프로세스의 특성을 받는 변수 타입이 고려되어있는가? )9. 데이터에 맞게 타입이 구체적으로 선언되었는가?10. If/else구분이 2단계 이상 중접되었다면 이를 함수로 더 구분하라11. Switch/case문이 중첩되었다면 이를 더 구분하라12. 리소스에 lock이 있다면, unlock은 반드시 이루어지는가?13. 힙 메모리 할당과 해제는 항상 짝을 이루는가?14. 스택 변수를 반환하고 있는가?15. 외부/공개 라이브러리 사용하였을 경우에 MIT 라이선스를 확인했는가? GPL의 경우에는 관련된 영역에서만 사용해야 한다.16. 블로킹 api호출시에 비동기적인 방식으로 처리하고 있는가?당연하겠지만, 예외처리 관련 체크리스트도 제대로 검토해야 한다.1. 입력 파라미터의 유효 범위는 체크하고 있는가?2. 에러코드와 예외(exception)의 호출 함수는 분명하게 반환되고 있는가?3. 호출 함수가 어려와 예외처리 코드를 가지고 있는가?4. Null포인트와 음수가 처리되는 구조인가?5. 에러코드에 대해서 명쾌하게 선언하고 처리하고 있는가?6. switch문에 default가 존재하고, 예외처리를 하고 있는가?7. 배열 사용시에 index범위를 체크하는가?8. 포인트 사용시에 유요한 범위를 체크하는가?9. Garbage collection을 제대로 하고 있는가?10. 수학계 산시에 overflow, underflow가 발생할 가능성이 있는가?11. 에러 조건이 체크되고 에러 발생 시 로깅 정보를 남기는가?12. 에러 메시지와 에러코드가 에러의 의미를 잘  전달하는가?13. Try/catch 에러 핸들링 사용방법은 적절하게 구현되었는가?요즘 프로그램은 대부분 이벤트성으로 구동되지만, 시간의 흐름에 대한 체크는 프로그램의 뼈대를 이루게 된다. 이 부분에 대해서도 제대로 검토해야 한다.1. 최악의 조건에 대해서 고려하였는가?2. 무한루프와 재귀 함수는 특이사항이 아니라면 없어야 한다.3. 재귀 함수 사용시에 call stack값의 최댓값이 고정되어 있는가?4. 경쟁조건이 존재하는가?5. 스레드는 정상 생성, 정상 동작하는 코드를 가지고 있는가?6. 불필요한 최적화를 통해서 코드 가독성을 희생하였는가?7. 임베디드의 경우에도 최적화가 매우 중요하지 않다면, 가독성을 더 중요하게 해야 한다가장 중요한 검증과 시험에 대해서도 제대로 인지하여야 한다. 그리고, 테스트를 위해서 가능한 최대한 자동화를 하기 위한 방법들을 이용해야 한다.1. 코드는 시험하기 쉽게 작성되었는가?2. 단위 테스트가 쉽게 될 수 있는가?3. 에러 핸들링 코드도 잘  테스트되었는가?4. 컴파일, 링크 체크 시에 경고 메시지도 100% 처리하였는가?5. 경계값, 음수값, 0/1등의 가독성이 떨어지는 코드에 대해서 충분하게 경계하고 있는가?6. 테스트를 위한 fault 조건 재현을 쉽게 할 수 있는가?7. 모든 인터페이스와 모든 예외 조건에 대해서 테스트 코드가 있는가?8. 최악의 조건에서도 리소스 사용은 문제가 없는가?9. 런타임 시의 오류와 로그에 대비한 시스템이 있는가?10. 테스트를 위한 주석 코드가 존재하는가?간혹 등장하는 하드웨어에 대한 테스트도  마찬가지이다. 다음과 같은 기준들을 통해서 검토해야 한다.1. I/O 오퍼레이션 코드에 대한 테스트로 하드웨어가 정상적인 동작을 보장하는가?2. 최소/최대 타이밍 요구사항에 대해서도 하드웨어 인터페이스가 충족하는가?3. 멀티 바이트 하드웨어 레지스터가 read/write오퍼레이션 중에도 값이 바뀌지 않음을 보장하는가?4. 시스템이 잘 정의된 하드웨어 상태로 리셋하는 것을 S/W가 보장하는가?5. 하드웨어의 전압이 떨어지거나 전원이 차단되는 경우에 잘 처리하는가?6. 대기모드 진입 시와 빠져나 올 때에 시스템이 옳게 동작하는가?7. 사용하지 않는 인터럽트 벡터가 에러 핸들러에 연결되어 있는가?8. EEPROM손상(데이터 깨짐)을 막기 위한 메커니즘이 있는가? ( 쓰기 동작 중 powe loss)등구체적으로 코드리뷰를 하고자 한다면, 다음의 코드리뷰에 대한 기법과 적당한 방법을 다음과 같이 설명할 수 있다.이러한 코드 리뷰를 위한 몇 가지 방법들이 알려져 있다. 그것들을 몇 가지 정리하여 보면 다음과 같다. 코드 인스펙션은 가장 정형화된 기법으로 전문화된 코드리뷰팀을 통해서 구분하는 방법이다. 이 방법은 리소스가 풍부하고, 일정에 여유가 있는 경우에만 사용이 가능하다. 대부분 대기업이나 대형 포털에서 구현 가능한 방법이라고 할 수 있다. ( 이런 곳에 있다면 행복해 하자. ~.~ ) 하여간, 비용과 일정 등이 있다면 이 방법이 현명하다. 그리고, 코드리뷰에 대한 품질에 대해서 정량적인 보고와 구성을 만들어 낼 수 있다는 것은 코드 인스팩션의 가장 좋은 장점이다. 이 코드 인스팩션을 하기 위한 롤을 구분하면 다음과 같이 4가지 롤로 구분할 수 있다.1. ModeratorA. 실질적인 매니저로 팀 간의 인터페이스와 리소스, 인프라를 확보하고, 프로세스에 대한 정의와 산출물의 정리를 담당한다.2. ReaderA. 각 산출물을 읽고, 리뷰하고, 방향성을 제시한다. 보통, 지식이 많은 사람이 담당한다.3. Designer/CoderA. Reader의 지시에 따라서 코드를 검증하고 잠재적인 발견 등의 수정 방안을 만든다.4. TesterA. 진행 중인 코드와 권장 수정 코드에 대해서 검증한다.그리고, 코드 인스펙션은 다음과 같은 6단계로 진행된다.1. PlanningA. 계획 수립2. OverviewA. 교육과 역할 정의3. PreparationA. 인터뷰와 필요한 문서 습득, 툴 환경 구축4. Meeting(Inspection)A. 각자의 역할대로 수행5. ReworkA. 보고된 Defect 수정6. Follow-upA. 보고된 Defect가 수정되었는지 확인이러한 절차를 통해서, 코드 인스팩션이 수행되면, 상당히 명쾌한 리뷰가 진행되게 된다. 하지만, 일정과 비용 문제 때문에 이 작업은 대부분의 스타트업에서는 선택하기 어렵다. 그래서 사용하는 방법 중의 하나가 팀 리뷰이다.팀 리뷰는 일정한 계획과 프로세스만 따르는 방법으로, 코드 인스펙션보다는 좀 덜 정형화된 방법으로 진행한다. 보통은 일주일에 한번 정도 팀 리뷰를 수행하거나, 특정 모듈이나 기능이 완료되는 시점을 기준으로 테스트 결과를 가지고 리뷰를 하는 방법을 사용한다.또한, 위험하거나 의견이 필요한 경우에도 팀 리뷰는 유용하다. 일반적인 팀에서 사용하는 방법이다.하지만, 이 역시. ‘리뷰’에 대한 제대로 된 인식이 없다면, 적용하기 어렵다. 그래서, 가끔 사용되는 방법이고, 과거 국내 SI업체들이 주로 사용하던 방법 중의 하나가 ‘웍쓰로’이다.웍 쓰루(Walkthrough)는 단체로 하는 코드 리뷰 기법 중에 비정형적인 방법으로, 발표자가 리뷰의 주제나 시간을 정해서 발표하고 동료들로부터 의견이나 아이디어를 듣는 시간을 가지는 방법으로써 주로 사례에 대한 정보 공유나 아이디어 수집을 위해서 사용하는 방법이다.이 방법은 ‘특정 도메인’에 종속된 코드를 만들거나, 비슷한 SI성 형태의 업무를 수행하는 경우에 적합하다. 그래서, 국내의 SI업체에서는 적극적으로 사용되면 좋겠지만. 이 ‘시간’마저도 부정확하고, 갑을병정의 SI체게에서 ‘정보공유’나 ‘아이디어 수집’과 같은 커뮤니케이션이 자유롭게 일어나는 것은 매우 힘들다.이 웍 쓰루는 동일한 조직 내에서 동일한 목적의식이 분명한 팀에서나 활용이 가능한 방법이다. 웍 쓰루를 SI에서 시도한 경우에는 대부분 실패했거나, 목적의식이 다르기 때문에 불분명한 결론들이 대부분 도출되었다.대부분의 국내 스타트업이나 IT 전문기업들은 ‘리뷰’에 대해서 상급 관리자들이 제대로 허락을 해주지 않는다.대부분은 팀내에서 어떻게든 자체적으로 해보려고 한다. 그래서, 팀장의 권한 선에서 적절하게 리뷰를 하는 방법 중의 하나가 Peer review or over the shoulder review방법이다. 이 방법은 보통 2~3명이 진행하는 코드리 뷰로 코드의 작성자가 모니터를 보면서 코드를 설명하고, 다른 한 사람이 설명을 들으면서 아이디어를 제안하거나 Defect를 발견하는 방법이다.또한, 이 방법은 신입사원이나 인턴사원의 경우에 업무 이해도를 높이면서 해당 코드를 사용할 수 있는 수준으로 활용할 경우에 의미 있는 방법이다. 문제는 이 방법은 개발자의 인력 투입이 거의 두배 이상으로 증가하는 것으로써, 고품질의 영역을 개발하거나, 빠른 시간 안에 신입 개발자의 업무 이해도를 높이는 경우가 아니라면 시행하지 않는다.이렇게도 리뷰가 진행이 되지 않으면, Passaroud는 돌려 보기 방법을 사용한다. 이 방법은 원래 상세한 리뷰 방법은 아니다. 온라인이나 실시간성이 아니라, 리파지토리나 이메일 등을 사용하여 천천히 리뷰하는 방식에 해당하는데, 속도는 느리지만, 중요한 코드이거나, 제품의 기능 개선이 필요한 경우에는 아주 의미가 있다. 보통은 제품의 기능 개선을 위하여 사용하는 방법이다.이처럼 리뷰의 방법에는 다양한 방법이 있지만, 결론적으로는 어느 정도 개발 조직이 서로  커뮤니케이션하고, 목적의식을 통일하고, 적절한 시간 분배를 통해서 리뷰를 할 수 있는 시간을 만들어 내느냐가 리뷰의 핵심이라고 할 수 있다.리뷰를 통해서 소프트웨어의 품질을  끌어올리고, 개발자들과 소통하고, 방향성을 만들어 내며, 새로운 기능 개선 작업을 위해서 리뷰는 다양하게 활용된다. 어떤 관점으로 리뷰를 할 것이고, 어떤 관점으로 리뷰라는 프로세스를 개발 프로세스에 탑재할 것인가에 대해서 진지하게 고민하는 것. 그것이 아키텍트의 첫 번째 역할 아닌가 한다.