VCNC에서는 데이터 분석을 위해 다양한 로그를 수집, 처리하는데 대부분은 JSON 형식의 로그 파일을 그대로 압축하여 저장해두고 Apache Spark으로 처리하고 있었습니다. 이렇게 Raw data를 바로 처리하는 방식은 ETL을 통해 데이터를 전처리하여 두는 방식과 비교하면 데이터 관리비용에서 큰 장점이 있지만, 매번 불필요하게 많은 양의 데이터를 읽어들여 처리해야 하는 아쉬움도 있었습니다.이러한 아쉬움을 해결하기 위해 여러 논의 중 데이터 저장 포맷을 Parquet로 바꿔보면 여러가지 장점이 있겠다는 의견이 나왔고, 마침 Spark에서 Parquet를 잘 지원하기 때문에 저장 포맷 변경 작업을 하게 되었습니다. 결론부터 말하자면 74%의 저장 용량 이득, 10~30배의 처리 성능 이득을 얻었고 성공적인 작업이라고 평가하지만 그 과정은 간단하지만은 않았습니다. 그 과정과 이를 통해 깨달은 점을 이 글을 통해 공유해 봅니다.Parquet(파케이)에 대해Parquet(파케이)는 나무조각을 붙여넣은 마룻바닥이라는 뜻을 가지고 있습니다. 데이터를 나무조각처럼 차곡차곡 정리해서 저장한다는 의도로 지은 이름이 아닐까 생각합니다.Parquet을 구글에서 검색하면 이와 같은 마룻바닥 사진들이 많이 나옵니다.빅데이터 처리는 보통 많은 시간과 비용이 들어가므로 압축률을 높이거나, 데이터를 효율적으로 정리해서 처리하는 데이터의 크기를 1/2 혹은 1/3로 줄일 수 있다면 이는 매우 큰 이득입니다. 데이터를 이렇게 극적으로 줄일 수 있는 아이디어 중 하나가 컬럼 기반 포맷입니다. 컬럼 기반 포맷은 같은 종류의 데이터가 모여있으므로 압축률이 더 높고, 일부 컬럼만 읽어 들일 수 있어 처리량을 줄일 수 있습니다.https://www.slideshare.net/larsgeorge/parquet-data-io-philadelphia-2013Parquet(파케이)는 하둡 생태계의 어느 프로젝트에서나 사용할 수 있는 효율적인 컬럼 기반 스토리지를 표방하고 있습니다. Twitter의 “Julien Le Dem” 와 Impala 프로젝트 Lead였던 Cloudera의 “Nong Li”가 힘을 합쳐 개발한 프로젝트로 현재는 많은 프로젝트에서 Parquet를 지원하고 컬럼 기반 포맷의 업계 표준에 가깝습니다.Parquet를 적용해보니 Apache Spark에서는, 그리고 수많은 하둡 생태계의 프로젝트들에서는 Parquet를 잘 지원합니다.val data = spark.read.parquet("PATH") data.write.parquet("PATH") Spark에서는 이런 식으로 손쉽게 parquet 파일을 읽고, 쓸 수가 있습니다. 데이터를 분석하기 전에 원본이라고 할 수 있는 gzipped text json을 읽어서 Parquet 로 저장해두고 (gzipped json은 S3에서 glacier로 이동시켜버리고), 이후에는 Parquet에서 데이터를 읽어서 처리하는 것 만으로도 저장용량과 I/O 면에서 어느 정도의 이득을 얻을 수 있었습니다. 하지만 테스트 결과 저장용량에서의 이득이 gz 23 GB 에서 Parquet 18GB 로 1/3 정도의 저장용량을 기대했던 만큼의 개선이 이루어지지는 않았습니다.Parquet Deep Dive상황을 파악하기 위해 조금 더 조사를 해보기로 하였습니다. Parquet의 포맷 스팩은 Parquet 프로젝트에서 관리되고 있고, 이의 구체적인 구현체로 parquet-mr 이나 parquet-cpp 프로젝트 등에서 스펙을 구현하고 있습니다. 그리고 특별한 경우에는 Spark에서는 Spark 내부에 구현된 VectorizedParquetRecordReader 에서 Parquet 파일을 처리하기도 합니다.파일 포맷이 바뀌거나 기능이 추가되는 경우에는 쿼리엔진에서도 이를 잘 적용해주어야 합니다. 하지만 안타깝게도 Spark은 parquet-mr 1.10 버전이 나온 시점에도 1.8 버전의 오래된 버전의 parquet-mr 코드를 사용하고 있습니다. (아마 다음 릴리즈(2.4.0)에는 1.10 버전이 적용될 것으로 보이지만)Parquet 의 메인 개발자 중에는 Impala 프로젝트의 lead도 있기 때문에, Impala에는 비교적 빠르게 변경사항이 반영되는 것에 비하면 대조적입니다. 모든 프로젝트들이 실시간적으로 유기적으로 업데이트되는 것은 힘든 일이기 때문에 어느 정도는 받아들여야겠지만, 우리가 원하는 Parquet의 장점을 취하기 위해서는 여러 가지 옵션을 조정하거나 직접 수정을 해야 합니다.VCNC 데이터팀에서는 저장 용량과 I/O 성능을 최적화하기 위하여 Parquet의Dictionary encoding (String들을 압축할 때 dictionary를 만들어서 압축하는 방식, 길고 반복되는 String이 많다면 좋은 압축률을 기대할 수 있습니다)Column pruning (필요한 컬럼만을 읽어 들이는 기법)Predicate pushdown, row group skipping (predicate, 즉 필터를 데이터를 읽어 들인 후 적용하는 것이 아니라 저장소 레벨에서 적용하는 기법)과 같은 기능들을 사용하기를 원했고, 이를 위해 여러 조사를 진행하였습니다.저장용량 줄이기102GB의 JSON 포맷 로그를 text그대로 gzip으로 압축하면 23GB가 됩니다. dictionary encoding이 잘 적용되도록 적절한 옵션 설정을 통해 Parquet로 저장하면 6GB로, 기존 압축방식보다 저장 용량을 74%나 줄일 수 있었습니다.val ndjsonDF = spark.read.schema(_schema).json("s3a://ndjson-bucket/2018/04/05") ndjsonDF. sort("userId", "objectType", "action"). coalesce(20). write. options(Map( ("compression", "gzip"), ("parquet.enable.dictionary", "true"), ("parquet.block.size", s"${32 * 1024 * 1024}"), ("parquet.page.size", s"${2 * 1024 * 1024}"), ("parquet.dictionary.page.size", s"${8 * 1024 * 1024}"), )). parquet("s3a://parquet-bucket/2018/04/05") 비트윈의 로그 데이터는 ID가 노출되지 않도록 익명화하면서 8ptza2HqTs6ZSpvmcR7Jww 와 같이 길어지기에 이러한 항목들이 dictionary encoding을 통해 효과적으로 압축되리라 기대할 수 있었고, Parquet에서는 dictionary encoding이 기본이기에 압축률 개선에 상당히 기대하고 있었습니다.하지만 parquet-mr 의 구현에서는 dictionary의 크기가 어느 정도 커지면 그 순간부터 dictionary encoding을 쓰지 않고 plain encoding으로 fallback하게 되어 있었습니다. 비트윈에서 나온 로그들은 수많은 동시접속 사용자들의 ID 갯수가 많기 때문에 dictionary의 크기가 상당히 커지는 상태였고, 결국 dictionary encoding을 사용하지 못해 압축 효율이 좋지 못한 상태였습니다.이를 해결하기 위해, parquet.block.size를 default 값인 128MB에서 32MB로 줄이고 parquet.dictionary.page.size를 default 값 1MB에서 8MB 로 늘려서 ID가 dictionary encoding으로만 잘 저장될 수 있도록 만들었습니다.처리속도 올리기저장용량이 줄어든 것으로도 네트워크 I/O가 줄어들기 때문에 처리 속도가 상당히 올라갑니다. 하지만 컬럼 기반 저장소의 장점을 온전하게 활용하기 위해서 column pruning, predicate pushdown들이 제대로 작동하는지 점검하고 싶었습니다.소스코드를 확인하고 몇 가지 테스트를 해 본 결과, Spark에서는 Parquet의 top level field에서의 column pruning은 지원하지만 nested field들에 대해서는 column pruning을 지원하지 않았습니다. 비트윈 로그에서는 nested field들을 많이 사용하고 있었기에 약간 아쉬웠으나 top level field에서의 column pruning 만으로도 어느 정도 만족스러웠고 로그의 구조도 그대로 사용할 예정입니다.Predicate pushdown도 실행시간에 크게 영향을 줄 거라 예상했습니다. 그런데 Spark 2.2.1기준으로 column pruning의 경우와 비슷하게, top level field에 대해서만 predicate pushdown이 작동하는 것을 확인할 수 있었습니다. 이는 성능에 큰 영향을 미치기에, predicate 로 자주 사용하는 column들을 top level 로 끌어올려 저장하는 작업을 하게 되었습니다. 여기에 추가로 parquet.string.min-max-statistics 옵션을 손보고 나서야 드디어 10~30배 정도의 성능 향상을 볼 수 있었습니다.매일 15분 정도 걸리던 "의심스러운 로그인 사용자" 탐지 쿼리가 30여초만에 끝나고, cs처리를 위해 한 사람의 로그만 볼 때 5분 정도 걸리던 쿼리가 30여초만에 처리되게 되었습니다.못다 한 이야기parquet.string.min-max-statistics 옵션과 row group skipping에 관해.Parquet 같은 포맷 입장에서 string 혹은 binary 필드의 순서를 판단하기는 어렵습니다. 예를 들어 글자 á 와 e 가 있을 때 어느 쪽이 더 작다고 할까요? 사전 편찬자라면 á가 더 작다고 볼 것이고, byte 표현을 보면 á는 162이고 e는 101이라 e가 더 작습니다. Parquet 같은 저장 포맷 입장에서는 binary 필드가 있다는 사실만 알고 있고, 그 필드에 무엇이 저장될지, 예를 들어 á와 e가 저장되는지, 이미지의 blob가 저장되는지는 알 수 없습니다. 그러니 순서를 어떻게 정해야 할지는 더더구나 알 수 없습니다.그래서 Parquet 내부적으로 컬럼의 min-max 값을 저장해 둘 때, 1.x 버전에서는 임의로 byte sequence를 UNSINGED 숫자로 해석해 그 컬럼의 min-max 값을 정해 저장했습니다. 이후에 이를 개선하기 위해 Ryan Blue가 PARQUET-686에서 parquet-format에 SORT_ORDER를 저장할 수 있도록 했습니다.여기에서 문제는 이전 버전과의 호환성입니다. SORT_ORDER가 없던 시절의 Parquet 파일을 읽으려 할 때, min-max 값을 사용해 row group skipping이 일어나면 query 엔진에서 올바르지 않은 결과가 나올 수 있으니, binary 필드의 min-max 값을 parquet-mr 에서 아예 반환하지 않게 되어있습니다.하지만 이는 우리가 원하는 동작이 아닙니다. 여기에 parquet.string.min-max-statistics option을 true로 설정하면, 이전처럼 binary필드의 min-max값을 리턴하게 되고 rowgroup skipping이 작동하여 쿼리 성능을 크게 올릴 수 있습니다.마치며Spark과 Parquet 모두 많은 사람이 사랑하는 훌륭한 오픈소스 프로젝트입니다. 또한 별다른 설정이나 튜닝 없이 기본 설정만으로도 잘 돌아가는 편이기 때문에 더더욱 많은 사람이 애용하는 프로젝트이기도 합니다.하지만 오픈소스는 완전하지 않습니다. 좋은 엔지니어링 팀이라면 단지 남들이 많이 쓰는 오픈소스 프로젝트들을 조합해서 사용하는 것에서 그치지 않고 핵심 원리와 내부 구조를 연구해가며 올바르게 활용해야 한다고 생각합니다. 기술의 올바른 활용을 위해 비트윈 데이터팀은 오늘도 노력하고 있습니다.

Hexlant는 Blockchain 전문 개발 팀으로, 다양한 기관들의 스마트 컨트랙트 코드를 검수하는 업무도 진행하고 있습니다.지금까지 다양한 컨트랙트 코드들을 리뷰하면서 나왔던 문제점들을 공유하고, 더 나은 방법으로 개발 할 수 있는 방법들에 대해 이야기 해보고자 합니다.transferFrom에 대한 이해ERC-20 표준에 보면, transferFrom 이라는 함수가 있습니다. 일반적으로 많이 쓰이는 기능이 아니다 보니 잘 모르고 넘어가는 경우가 많습니다.function transferFrom(address _from, address _to, uint256 _value) public returns(bool)transferFrom은 남이 가지고 있는 토큰을 누군가에게 보내는 기능입니다.그 누군가는 내가 될 수도 있습니다.이 설명만 보면, 아래와 같은 의문이 생기실 겁니다.어? 남의 토큰을 내 마음대로 옮길 수 있다고??당연히 마음대로 옮기면 안되겠죠.그래서 approve 함수를 통해, 내 토큰을 사용할 수 있는 사람을 지정할 수 있습니다function approve(address spender, uint256 _value) public returns(bool)토큰의 holder는 approve함수를 호출하여 spender에게 일정량 만큼을 사용할 수 있게 허용을 해 줍니다. 그럼 spender는 허용된 범위 안에서 토큰을 마음대로 옮길 수 있습니다.허가되지 않은 토큰의 이동많이 쓰지 않는 기능이다 보니, 이 부분에 대해 고려하지 않고 개발 하는 경우가 있을 수 있습니다.아래는 저희가 리뷰했던 코드 중 일부입니다function approve(address _spender, uint256 _value) public returns (bool success) { require(_spender > address(0)); allowed[msg.sender][_spender] = _value; Approval(msg.sender, _spender, _value); return true; }function transferFrom(address _from, address _to, uint256 _value) public { require(_from > address(0)); require(_to > address(0)); require(balances[_from] >= _value); require(balances[_to] + _value > balances[_to]); balances[_from] = balances[_from].sub(_value); balances[_to] = balances[_to].add(_value); Transfer(_from, _to, _value); }approve 함수를 우선적으로 보면, allowed 테이블에, msg.sender가 _spender에게 얼마만큼 토큰사용을 허용해 주었는지 저장하는것 말고는 특별한 기능은 없습니다.allowed[msg.sender][_spender] = _value;이제 transferFrom 함수를 확인해 보겠습니다.transferFrom은 실제 토큰이 전송되는 부분이니 예가 필요할 것같습니다.Alice에게 10000개의 토큰이 있을 때, Bob이 transferFrom을 다음과 같이 호출했다고 합시다.transferFrom(Alice, Bob, 10000)자 이제 transferFrom코드를 따라가며 토큰이 어떻게 전송이 되는지 확인해 봅시다.require는 안에 들어간 조건이 만족해야만 다음 라인을 실행 할 수 있다는 명령어 입니다. require를 만족하지 못하면, 해당 트랙잭션은 수행되지 않고 실패로 처리됩니다.require(_from > address(0)); require(_to > address(0));위의 두 줄의 조건은 입력된 주소_from, _to는 각각 Alice와 Bob의 지갑 주소이기 때문에 0x*****형태로 0x0000…0000이 아니기에 해당 조건들을 모두 만족합니다.require(balances[_from] >= _value); require(balances[_to] + _value > balances[_to]);Alice의 지갑에는 10000개의 토큰이 있고 _value는 10000개이니까 저 require를 실제 숫자로 대입하면require(10000 >= 100000); require(0+10000 > 0);조건을 충분히 만족합니다.그 다음부분들을 실제로 Alice의 주소에서 Bob의주소로 10000개의 토큰을 옮기는 작업입니다.balances[_from] = balances[_from].sub(_value); balances[_to] = balances[_to].add(_value); Transfer(_from, _to, _value);Alice의 잔액에서 10000개만큼이 빠지고,Bob의 잔액에 10000개가 추가됩니다.balances[Alice] = balances[Alice].sub(10000); balances[Bob] = balances[Bob].add(10000); Transfer(Alice, Bob, 10000);이로서 Bob은 Alice의 토큰 10000개를 자신의 지갑으로 이동시켰습니다.일련의 과정을 요약하면1. 주소 오류 검증 2. 보내려는 토큰이 Alice가 가진 잔액보다 작은지 검증 3. 받았을때 Overflow가 발생하는지 체크 4. Alice의 잔액에서 보내는 만큼의 토큰 수량을 뺀다 5. Bob의 잔액에 보내는 만큼의 토큰 수량을 더한다과정을 보면 Bob이 Alice로 부터 토큰 사용을 허락받았는지 체크하는 부분이 없습니다.따라서 누군가가 보유한 토큰을 다른 사람이 제멋대로 쓸수 있게됩니다.오류수정transferFrom이 정상적으로 동작하려면 어떻게 수정되어야 할까요?function transferFrom(address _from, address _to, uint256 _value) public { require(_from > address(0)); require(_to > address(0)); require(balances[_from] >= _value); require(balances[_to] + _value > balances[_to]); require(allowed[_from][msg.sender] >= _value); balances[_from] = balances[_from].sub(_value); balances[_to] = balances[_to].add(_value); allowed[_from][msg.sender] = allowed[_from][msg.sender].sub(_value) Transfer(_from, _to, _value); }첫 번째로는 당연히 transferFrom을 호출한 사람이 권한이 있는지 확인해야 합니다.require(allowed[_from][msg.sender] >= _value);이 조건을 통해 허용된 수량안에서만 토큰을 옮길 수 있게 만들 수 있습니다.두번째는, 토큰을 옮긴 후 허용량을 줄여주어야 합니다.allowed[_from][msg.sender] = allowed[_from][msg.sender].sub(_value)만일 Alice가 Bob에게 10000개의 토큰을 허용해 주고, Bob이 그중 100개를 사용했다면, 그 다음번에 Bob은 9900개 안에서만 사용할 수 있어야 합니다.#헥슬란트 #HEXLANT #블록체인 #개발자 #개발팀 #기술기업 #기술중심 #실수담

우선 EOS BP 투료를 한 번쯤 해보신 분들은 매번 새롭게 등장하는 BP 후보들은 넘쳐나고 그들의 이름과 공약을 확인하는 것이 귀찮다고 느끼셨을 수 있습니다.또한 어렵게 공약을 확인하고 정말 이 팀이 EOS를 위해 무엇을 할 수 있는지 다른 팀들과 어떤점이 다른지 꼼꼼하게 비교하여 선거한 여러분의 소중한 투표권 파워는 시간이 지날수록 가치가 줄어들게 됩니다.그렇다면 나 대신에 꾸준히 선거를 대신해줄 사람이 있다면 얼마나 좋을까요?사실 이런 문제에 대해 EOS도 알고 있었으며, 어떤 해결 방법이 있을지 생각해왔습니다.그래서 바로 만들어진 것이 EOS Proxy Voting입니다.Proxy란 ‘대리인’이란 의미를 갖고 있습니다.따라서 EOS Proxy Voting은 EOS BP 대리 투표 시스템을 뜻합니다.이 대리인 투표권을 신청하게 되면 여러분은 더 이상 투표에 대해 고민하실 필요가 없게 되는 거예요!이제 이 Proxy 시스템을 어떻게 이용하는지 방법을 소개하고자 합니다.1. 어떻게 Cleos를 통해 다른 사람에게 나의 투표 권한을 넘길 수 있나요?나의 투표 권한을 Cleos를 통해 다른 사람에게 넘기기 위해선 다음과 같은 명령어를 입력해야합니다.간단하지요? 이 명령어는 eosaccount12가 자신의 투표 권한을 proxyvoter34에게 넘기겠다는 의미를 갖고 있습니다.2. 어떻게 툴킷을 통해 다른 사람에게 나의 권한을 넘길 수 있는 건가요?대표적으로 https://eostoolkit.io/vote/setproxy에서 Proxy를 설정하는 방법을 안내해드릴게요! (참고로 https://www.myeoskit.com/#/tools/proxy/https://eosvoter.eosphere.io 에서도 가능합니다. )나의 proxy를 툴킷을 통해 다른 사람에게 넘기기 위해선 먼저 Scatter 구글 확장 프로그램을 설치해야 합니다.Scatter 설치 후 EOS 계정 및 접속 정보를 Scatter에 등록하셔야 합니다. (Scatter에 정보를 등록하는 방법은 곧 업데이트 하도록 하겠습니다.)그렇다면 등록을 다 하셨을 테니 다음으로 넘어가겠습니다.우선 EOStoolkit에 접속하셔서 스캐터 계정으로 로그인하셔야 합니다.로그인 하셨다면 이제 왼쪽 카테고리에서 [Manage Voting] 항목을 보실 수 있을거에요![Manage Voting]를 클릭하시면 Voting에 관한 여러 항목이 촤르르 나오게 되는데 그 중에 [Set Proxy]를 눌러주세요!자 그럼 아래 화면에 나온 대로 그대로 따라하신 후 저장만 해주시면 됩니다.드디어 투표 권한을 지정 Proxy에게 넘기게 되었습니다.3. 어떻게 내가 설정한 Proxy를 해제할 수 있나요?Proxy 지정을 하고 며칠동안 투표에 신경을 쓰지 않았다가 오랜만에 들어간 투표 사이트에서 내가 지정한 대리인이 행사하는 나의 투표권이 마음에 들지 않을 땐 어떻게 해야할까요?해제를 해야겠지요!그렇다면 지금 내가 지정한 Proxy가 마음에 안들어서 해제하고 싶을 때는 어떻게 할지도 알아보겠습니다.Proxy 설정을 했다면, 저 네모박스에 체크되어 있을겁니다. 그 체크를 해지 하면 간단하게 내가 설정한 Proxy를 해제하게 되는 것입니다.아주 간단하네요.그럼 이제 다음은 내가 직접 Proxy가 되기 위해선 어떻게 할 수 있을지 알아보겠습니다.그 방법도 마찬가지로 Cleos 또는 Toolkit 과 Scatter를 통해 할 수 있습니다.4. Cleos를 통해서 내가 직접 Proxy가 될 수 있는 방법은 어떤게 있나요?내가 직접 Cleos를 통해 Proxy가 되기 위해선 다음과 같은 명령어를 입력해야합니다.이 명령어는 proxyvoter34는 Proxy로 지정되었는 의미를 갖고 있습니다.5. 어떻게 툴킷을 통해 내가 직접 Proxy가 될 수 있는 건가요?우선 툴킷을 통해 Proxy로 등록하기 위해선 가장 먼저https://eostoolkit.io/vote/setproxy 에 나의 Scatter 계정으로 로그인해야 합니다.(참고로 https://www.myeoskit.com/#/tools/proxy/https://eosvoter.eosphere.io 에서도 가능합니다. )로그인 하셨다면 왼쪽 카테고리에서 [Manage Voting]을 찾아주세요!찾으셨다면 해당 항목의 아래 항목에서 [Create Proxy] 를 클릭해주세요. 그럼다음과 같은 화면이 나오게 됩니다.아래 나와있는 설명 그대로 적어주시고 저장해주시면 됩니다. 다 완료하셨으면 드디어 Proxy가 되셨어요!6. 더이상 Proxy로 활동하고 싶지 않으면 어떻게 해야 하나요?더 이상 Proxy로서 활동을 하고 싶지 않다면 마찬가지로 [Manage Voting]를 통해 Proxy 철회를 할 수 있습니다.[Manage Voting]를 클릭 후 아래 항목에서 [Resign Proxy]을 누르시면 됩니다. 첫 번째 Resign 버튼은 Proxy 등록을 해지하는 것이고 두 번째 Unregister 버튼은 등록한 정보를 삭제하는 버튼입니다.각각의 버튼을 눌러 그대로 진행하시면 Proxy 철회가 완료될 거예요!자 여기까지 이제 EOS Proxy Voting을 하기 위해Proxy 설정하는 방법을 알아보았습니다. 어렵게 보이지만 Scatter 연동만 하면 Proxy를 설정하거나 내가 직접 Proxy가 되는 것은 어렵지 않습니다!아 참고로, 현재 등록된 모든 Proxy 리스트를 Aloha EOS Proxy Research Portal에서 확인할 수 있습니다.또한 해당 사이트에서 Proxy들이 자신들이 Proxy로 활동하면서 어떻게 투표를 행사할 것인지에 대한 공약도 자세히 나와있으니 한 번쯤 들어가서 보시면 Proxy를지정하는 데에 있어서도, 내가 직접 Proxy가 됨에 있어서도 도움이 될 거예요!#헥슬란트 #HEXLANT #블록체인 #개발자 #개발팀 #기술기업 #기술중심

비트윈 팀은 지난달 비트윈에 Android Wear 앱 기능을 릴리즈했습니다. 즐거운 개발 경험이었지만, 힘들었던 점도 많았습니다. 어떤 과정을 통해서 개발하게 되었고, 내부 구조는 어떻게 되어 있는지, 신경 쓰거나 조심해야 할 점은 어떤 것들이 있는지 저희의 경험을 공유해보려고 합니다. 이 글을 통해 Android Wear 앱 제작을 고민하는 개발자나 팀이 더 나은 선택을 하는 데 도움이 되고자 합니다.Android Wear에 대해¶Android Wear는 최근 발표된 구글의 새 웨어러블 플랫폼입니다. 공개된 지 얼마 되지 않았음에도 불구하고 완성도 있는 디바이스들이 출시된 상태이며, 기존의 웨어러블 기기보다 기능과 가격이 매력 있다는 평가를 받고 있습니다. 또한, 2014 Google I/O에서 크게 소개되고 시계를 참가자들에게 나눠주는 등, 구글에서 강하게 밀어주고 있기 때문에 상당히 기대되는 플랫폼입니다.Android Wear의 알림 기능은 연결된 mobile1 기기와 연동됩니다. 예를 들어 메시지를 받았을 때 mobile과 wear에서 모두 알림을 받아볼 수 있고, Google Now와 연동하여 교통, 날씨 등 상황에 맞는 알림을 제공합니다.또, 여러 가지 앱들의 다양한 기능을 음성으로 제어하도록 하여 사용자에게 기존의 시계와는 완전히 다른 경험을 주고 있습니다.한국에서는 Google Play Store의 기기 섹션에서 구매가 가능합니다.Android Wear 개발하기¶Android Wear는 Android 플랫폼을 거의 그대로 사용하기 때문에, Android 개발 경험이 있는 개발자라면 아주 쉽게 개발을 시작할 수 있습니다. 비트윈에서는 구글의 80:20 프로젝트를 패러디한 100+20 프로젝트를 통해 개발을 진행하게 되었습니다. (하던 일을 다 해내면서 시간을 내어 진행한다는 의미로 100+20 프로젝트입니다. 하지만 가끔은 '20' 부분에 너무 몰입하여 0+20이 되기도 한다는 게 함정입니다...)Activity, Service 등 Android의 기본 component들을 모두 그대로 사용 가능하며, 손목에 찰 수 있는 크기의 화면에서 유용하게 사용할 수 있는 WearableListView, GridViewPager 같은 새 widget들이 추가되었습니다. 구글 개발자 사이트의 wearable training 섹션에서 자세한 안내를 볼 수 있습니다.비트윈의 아이디어¶비트윈 Android Wear 기능의 컨셉은, 항상 몸에 착용하는 Wear의 특징을 살려, '커플이 떨어져 있더라도, 항상 함께 있는 느낌을 주기' 였습니다. 그래서 아래와 같은 기능들이 기획되었습니다.Feel His/Her Heart (그대의 심장박동 느끼기): 상대방의 심장박동을 진동으로 재현해주기Where He/She Is (그/그녀는 어느 방향에 있을까?): 상대방의 위치를 나침반과 같은 형태로 보여주기 (안심하세요. 여러분. 방향만 알려주고 정확한 위치는 알려주지 않습니다!)Feel Memories (메모리박스): 언제든 추억을 떠올릴 수 있도록 비트윈의 기존 기능인 메모리박스(추억상자)를 Android Wear에서 구현하지만 이 아이디어들은 하루 만에 망하게 됩니다.메인 아이디어였던 심장박동 느끼기는 사용자가 요청하면 상대방의 시계에서 심장박동이 측정되어 사용자에게 상대방의 심장박동을 진동으로 재현해주는 멋진 기능이었습니다. 하지만 이 아이디어를 낼 때 심박센서가 탑재된 Android Wear 기기가 없었던 게 함정이었습니다.다음날 Android Wear Bootcamp에 참가하여 심박센서가 작동하는 삼성 Gear Live 기기를 사용해 볼 수 있었습니다. 결과는 충격이었습니다. 생각과는 달리 심박박동 측정 결과가 나오는데 10~20초가 걸리고, 그나마도 측정되는 동안은 올바른 위치에 시계를 차고 가만히 있어야 했습니다. 결국, 이러한 제약 때문에 사용자들이 실제로 유용하게 사용할 수 있는 기능이 될 수 없었습니다.그래서 계획을 수정하여 현실적으로 구현 가능한 기능들을 먼저 만들어 보기로 했습니다.목소리로 답변하기: 상대방에게 온 메시지에 Android Wear Framework에서 제공하는 음성인식을 이용하여 목소리를 텍스트로 바꾸어서 답장하기이모티콘 답변하기: 이모티콘을 사용자가 선택하여 이모티콘으로 답장하기비트윈 메모리박스: 비트윈의 기존 기능인 메모리박스(추억상자)를 Android Wear에서 구현처음의 원대한 계획에서 뭔가 많이 변경된 것 같지만, 기분 탓일 겁니다.내부 구현¶비트윈 Android Wear 앱은 크게 두 가지 기능을 가지고 있습니다. 하나는 상대방에게 메시지를 받았을 때, 메시지 내용을 확인하고 여러 가지 형태로 답장할 수 있는 Notification 기능이고, 다른 하나는 Wear에서 원래 Application의 일부 기능을 시작 메뉴를 통하거나 목소리로 실행시킬 수 있게 해주는 Micro App입니다. 해당 기능들의 스크린샷과 함께 내부 구조를 설명하겠습니다.우선 Notification 부분입니다. 앱 개발사에서 아무 작업도 하지 않더라도, 기본적으로 Android Wear Framework이 스크린샷 윗줄 첫 번째, 네 번째 화면과 같이 예쁜 알림화면과 Open on phone 버튼을 만들어 줍니다. 여기에 추가적인 기능을 붙이기 위하여 WearableExtender를 이용하여 목소리로 답장하기, 이모티콘 보내기 버튼을 덧붙였습니다.비트윈 Android Wear 스크린샷 - Notification둘째로는 Micro App 부분입니다. 여기에는 이모티콘 전송과 메모리박스를 넣었습니다. 이 부분은 일반적인 Android 앱을 만들듯이 작업할 수 있습니다비트윈 Android Wear 스크린샷 - Micro App화면을 보면 무척 단순해 보이지만 내부 구조는 간단하지가 않습니다. 연결된 화면들을 만들어내는 코드가 한곳에 모여있지 않고, 각기 다른 곳에 있는 코드들을 연결하여야 하기 때문입니다. Notification 하나를 만들 때에 Framework에서 만들어주는 1, 4번째 화면, Notification에 WearableExtender를 이용하여 덧붙이는 2, 3번째 화면, 그리고 다시 Framework에서 만들어주는 목소리로 답장하기 화면, 그리고 Wear 쪽의 Micro App을 통해 구동되는 이모티콘 선택 화면과 같이 여러 군데에 나누어 존재하는 코드가 연결됩니다.하나의 앱처럼 느껴지는 화면이지만 각각 다른 곳에 코드가 쓰여있습니다.그러면 이번에는 각 화면이 어떻게 연결되는지 알아보겠습니다.사용자가 상대방으로부터 받은 메시지를 Android Wear의 Notification으로 확인하고, 답장으로 이모티콘을 보내고자 하는 상황을 가정해 봅시다. 사용자가 Send Emoticon 버튼을 눌렀을 때 이모티콘 선택화면을 보여주고 싶은데, 이 행동에 대한 pending intent를 wear 쪽의 micro app이 아닌, mobile 쪽에서 받게 되어 있습니다. 이 때문에 아래의 표와 같이 mobile 쪽에서 pending intent를 받은 뒤 다시 wear 쪽으로 이모티콘 선택 화면을 보여주라는 메시지를 전송해줘야 합니다.이모티콘 전송 과정이번에는 메모리박스를 보겠습니다. 메모리박스도 단순한 화면이지만 mobile 쪽과 통신하여 내용을 불러와야 하므로 생각보다 해야 하는 일이 많습니다. Android Wear Message API와 Data API를 이용하여 데이터를 주고받아 사진을 화면에 보여줍니다.메모리박스를 보여주는 과정개발 시 신경 써야 하는 점¶개발하면서 주의 깊게 신경 써야 하는 점들이 있습니다.첫 번째로 코드 퀄리티입니다.Android Wear는 아직 성숙하지 않은 플랫폼이기 때문에 많은 사람이 받아들인 정형화된 패턴이 없습니다. 앞서 살펴보았듯이, 간단한 기능을 구현하려고 해도 상당히 복잡한 구조를 가진 앱을 만들게 되기에, 코드 퀄리티를 높게 유지하기 어려웠습니다비트윈 팀에서는 EventBus를 활용하여 코드를 깔끔하게 유지하려고 노력하였습니다. 이러한 문제를 해결할 수 있는 Guava의 Concurrent 패키지나, RxJava 등의 도구들이 있으니 익숙한 도구를 선택하여 진행하는 것을 추천합니다. 또한, 구글의 Android Wear 코드랩 튜토리얼의 내용이 매우 좋으니, 한번 처음부터 수행해 보면 좋은 코드를 만들 수 있는 아이디어가 많이 나올 것입니다.두 번째로는 원형 디바이스 지원 및 에러 처리입니다.처음부터 원형 디바이스를 신경 쓰지 않으면 마무리 작업 시 상당한 고통을 받게 됩니다. 원형 디바이스에 대한 대응법은 Android 개발자 트레이닝 사이트의 wearable layout 섹션에 자세히 나와 있습니다. 현재는 원형 디바이스를 처리하는 프레임웍에 약간 버그가 있지만, 곧 수정될 것으로 생각합니다.사용자 입력이 있을 때, 그리고 에러가 났을 때 적절하게 처리해주는 것은 제품의 완성도에 있어 중요한 부분입니다. Android Wear Framework에서 제공하는 ConfirmationActivity등을 활용하여 처리하면 됩니다.마지막으로 패키징입니다.자동 설치 패키징은 비트윈 팀에서도 가장 고생했던 부분입니다. Android Wear는 본체 앱을 설치하면 자동으로 함께 설치되는데, 앱이 정상작동하기 위해서는 몇 가지 까다로운 조건이 있습니다.build.gradle 의 applicationId 를 wear와 mobile 양쪽 모두 똑같이 맞춰야 합니다.Wear app의 AndroidManifest에 새롭게 선언한 permission이 있다면 mobile 쪽에도 포함해 주어야 합니다.기본적으로, 똑같은 key로 서명합니다. 다른 key로 sign 하는 경우는 문서를 참고해서 신경 써서 합니다.위 항목들은 아주 중요한 내용이지만 아직 문서화가 완벽하지 않으니 주의 깊게 진행해야 합니다.후기¶개발 과정에서 여러 가지 어려움이 있었지만, 무척 즐거웠던 프로젝트였습니다!우선 새로운 플랫폼에서 새로운 제품의 아이디어를 내고 만들어내는 과정이 많은 영감과 즐거움을 주었습니다.두 번째로는 Android Wear를 포함한 버전 출시 이후 구글플레이의 Android Wear 섹션 및 추천 앱 섹션에 올라가게 되어 홍보 효과도 얻을 수 있었습니다. 또한, 구글의 신기술을 적극적으로 사용하고자 하는 팀에게는 구글 쪽에서도 많은 지원을 해주기 때문에 도움도 많이 받았습니다.세 번째로는 기존의 Android 개발과 비슷하여 접근하기 쉬우면서도, 원하는 것을 구현하려면 상당히 도전적이어서 재미있었습니다.다만 조심해야 할 점은, 구글에서 적극적으로 밀고 있는 프로젝트라고 해서 다 성공하는 것은 아니라는 점입니다. 얼마만큼의 시간과 자원을 투자할지는 신중하게 생각하면 좋겠습니다.정리¶Android Wear는 새로운 기술과 플랫폼에 관심이 많은 개발자, 혹은 팀이라면 시간을 투자해서 해볼 만한 재미있는 프로젝트입니다. 하지만 완성도 있는 좋은 제품을 만들기 위해서는 생각보다 할 일이 많으니 이를 신중하게 고려하여 결정해야 합니다.구글의 튜토리얼 등에서 지칭하는 것과 마찬가지로, 이 글에서도 Android Wear와 연결된 휴대폰을 mobile이라 하겠습니다.↩저희는 언제나 타다 및 비트윈 서비스를 함께 만들며 기술적인 문제를 함께 풀어나갈 능력있는 개발자를 모시고 있습니다. 언제든 부담없이 [email protected]로 이메일을 주시기 바랍니다!

프로세스 모델 도출은 프로세스 마이닝의 출발점이며, 매우 유용합니다. 원본 데이터로부터 프로세스 흐름 모델을 자동으로 구성하여 실제 프로세스를 알 수 있습니다. 이렇게 도출된 프로세스 모델과 이벤트 로그를 비교하는 것이 적합도 검사(Conformance checking)입니다. 적합도는 이전에 말씀드린 정확도(Precision)와는 다른 개념입니다. 정확도(Precision)는 Underfitting을 피하여 데이터를 정확하게 설명할 수 있으나 정확도가 높을수록 프로세스 모델이 대체로 복잡해지게 됩니다. 하지만 적합도가 높다고 하여 프로세스 모델이 복잡해지는 것은 아닙니다.적합도 검사의 기본 아이디어는 프로세스 모델 위에 이벤트 로그를 재생하는 것입니다.아래 예제 모델에 이벤트 로그 a → c → e → g를 재생하여 적합성 검사를 해보겠습니다.[그림 1] 프로세스 모델 예제먼저 a 이벤트를 수행하였습니다.[그림 2] a 이벤트 수행 후다음으로 c 이벤트를 수행했습니다.[그림 3] a, c 이벤트 수행 후이벤트 로그에서는 다음에 e를 수행해야 합니다. [그림 3]을 보면 e를 수행하기 위해서는 d가 먼저 수행되어야 합니다. 하지만 실제 로그에서는 d 수행 없이 e가 수행되었기 때문에 d를 무시하고 e를 수행합니다.마지막으로 g 이벤트 수행하여 프로세스를 마칩니다.이벤트 로그 재생이 완료되면 액티비티 d에 실행되지 못한 토큰이 남아있게 됩니다. [그림 5] 이벤트 로그 재생 후 남아 있는 토큰프로세스 모델 위에 이벤트 로그를 재생하는 동안 얼마나 많은 토큰을 사용하고(이벤트 수행 횟수) 어떤 이벤트를 생략하고 추가했는지 기록합니다. 이를 통해 기록된 이벤트 로그와 모델의 적합도를 비교할 수 있습니다. 적합도가 1이면 모든 로그가 프로세스 모델에 잘 맞는다는 뜻이고, 0에 가까우면 적합도가 매우 낮다는 의미입니다.적합도 검사는 어디에 활용할 수 있을까요? 사람들이 표준 프로세스와 달리 행동하는 이유를 찾을 때 활용 가능합니다. 왜 사람들이 기존 프로세스를 벗어나는지, 벗어나는 부분에 대해서는 잘 보고되었는지 확인할 수 있습니다. 일반적인 감사(Audit and compliance) 절차에도 활용 가능합니다.다른 사례는 도출된 프로세스 모델의 품질을 측정하기 위해 활용할 수 있습니다. 여러 알고리즘을 사용하여 프로세스 모델을 도출했을 경우 어떤 모델이 가장 적합하고 좋은 모델인지 비교해 볼 수 있습니다.마지막으로 프로세스 설명이 제대로 되어 있는지 실제 행동을 기반으로 확인할 수 있습니다. 예를 들어 어떤 서비스를 제공하는 경우 서비스 실행 방법 매뉴얼과 실제로 제공되는 서비스를 비교하여 일치하는지 확인할 수 있습니다.※ 본 블로그에 사용된 그림은 Van der Aalst 교수님 강의자료를 사용하였습니다.#퍼즐데이터 #개발팀 #개발자 #개발후기 #인사이트

Q) 안녕하세요 Juan Carlos(환 까를로스)님 자기소개 부탁드려요.네 안녕하세요. 지금 immersive 6기에서 개발자가 되기 위해 열심히 공부하고 있는 환 까를로스라고 합니다. 어쩌다보니 immersive 6기에서 전문 네비게이터로 생활하고 있어요.(웃음) 네비게이터는 페어프로그래밍을 할 때 드라이버가 코딩을 할 수 있도록 큰 그림을 그려주는 거라고 생각하시면 되요. 페어와 같이 코딩을 하면서 Immersive를 헤쳐나가고 있습니다.Q) 코드스테이츠 오시기 전에는 어떤 일을 하셨었나요?해외영업을 했습니다. 이 일을 선택한 이유는 조금 특별해요. 제가 취준생이었을 때 회사를 여러 곳을 지원을 했었습니다. 지원한 기업에서 합격 통보를 받았죠. 근데 막상 그 기업에 입사하려고 보니까 지방에서 근무를 해야 하는 거예요. 그전까지는 이런 것들을 생각도 안 하고 있다가, 막상 닥치니까 곰곰이 생각하게 되었어요.'내가 서울을 떠나서 잘 살 수 있을까?' 지방에서 산다는 거에 대해서 크게 생각하고 있지 않았었는데, 막상 닥치니까 고민이 많이 되더라구요. 제가 서울 토박이인데, 고향을 떠나서 사는 거는 제가 너무 힘들 것 같아서 포기하고 지금 현 직장(지금은 퇴사를 했죠)에 다니게 된 거예요. 그리고 제가 공대 출신인데 공대 출신이 서울에서 직장을 잡으려면 영업 밖에 없더라구요. 그래서 영업직을 선택했었습니다.Q) 그럼 직장을 나오게 된 계기가 있으신가요?새로운 것을 수용할 생각이 없는 경직된 조직문화가 너무 안 맞았어요. 저는 신입을 뽑는 이유는 조직이 시장의 흐름이나 세대의 변화에 맞춰 변하기 위해서라고 생각해요. 근데, 전에 팀은 변할 생각을 안 하더라고요. 야근까지 해가면서 업무개선을 해도 기존 방식을 고수하자는 피드백이 계속되니 열정이 사라지는 것을 느꼈죠. 제가 4년 정도 다녔는데, 퇴사를 고민하고 3시간 만에 결정하고 사표를 내고 나왔어요.저는 뭔가 다양한 경험을 하고 제 스스로가 발전하는 걸 좋아하는데, 발전한다는 느낌이 없었죠. 부서를 여러 곳으로 옮긴 이유도 제가 정확히 뭘 좋아하는지 모르니까 이것저것 해보면 알지 않을까 생각했어요. 영업 파트에서 일하면서도 기획부터 경영지원까지 다양한 일을 맡았었죠.Q) 3시간이면 정말 짧네요! 보통은 여러 번 고민하기 마련인데요. 그럼 퇴사하시고 나서는 무엇을 하셨나요?음... 사실 퇴사하고 나서 제가 맡았던 고객들이 경쟁사로 이직할 수 있게 도와주겠다고 하셔서 고민을 많이 했어요.  근데, 이왕 퇴사했는데 새로운 걸 해보고 싶었어요. 한 군데 계속 있으면 뭐랄까.. 나태해지는 것 같아서요.- 다른 분야의 직장을 잡으신 건가요?일단은 여행 가야지라고 생각해서, 스페인으로 떠났어요.  첫 번째로는 스페인의 순례길을 가기로 했죠. 1000km 정도 되는 길을 걸었던 것 같아요. 순례길을 걸으면서 다양한 사람들을 만나고 생각도 정리도 좀 하고 그랬어요. 거기에는 전 세계 퇴사한 사람이 다 모이는 것 같아요. 숙소에서 만난 친구들에게 물어보면 죄다 회사를 퇴사하고 왔다고 하더라구요(웃음) 그리고 그곳에서 개발자가 돼야겠다는 마음을 먹었습니다.Q) 어떤 경험을 하셨길래 그곳에서 개발자가 돼야겠단 마음을 먹으셨나요?먼저 이 얘기를 해야 하겠네요. 사실 제가 여행경비가 이렇게 많이 들지 몰랐어요. 순례길을 여행하다가 돈도 떨어져 가는데 직업이 있는 채로 순례길을 도는 사람들을 만나게 된 거예요. 세 명을 만났는데, 세 명 다 소프트웨어 엔지니어였습니다. 처음에는 브라질 개발자를 만났어요. 그때까지만 해도 별생각이 없었죠. 다음으로는 러시아 개발자를 만났습니다. 러시아 개발자 친구를 보면서 아 이런 게 디지털 노마드구나라는 생각을 갖게 되었죠. 그리고 마지막으로 스페인 개발자 친구를 만나니까 정말 개발자라는 직업이 부럽게 느껴지더라구요. Q) 디지털 노마드를 보고 개발자가 돼야겠단 결정을 하신 거네요! 그럼 코드스테이츠를 선택해주신 이유가 있으신가요? 아까 제가 생각보다 여행 경비가 많이 드는지 몰랐다고 했잖아요. 순례길만 여행하는데도 여행 경비가 다 떨어진거에요(웃음) 그래서 어쩔 수 없이 세계 여행의 꿈을 접고 한국으로 오게 되었죠. 그리고 한국으로 돌아오는 비행기 안에서 개발자가 되기로 결심을 했습니다. 내가 여행을 다니고 하고 싶은 것을 하면서도 일도 하고 그게 너무 좋아 보이는 거에요. 물론 한국의 현실은 많이 다르겠지만 그래도 개발자라면 가능하지 않을까라고 생각을 했습니다. 그리고 그 비행기에서 핸드폰으로 코딩 관련해서 검색을 하다가 코드스테이츠를 알게 되었어요. 알아보니까 교육철학도 좋고 저에게도 괜찮은 방식을 것 같아서 그 비행기 안에서 바로 결정을 하게 되었습니다. 퇴사할 때와 마찬가지로 일사천리로 결정을 했습니다.- 비행기 안에서 모든 결정이 이루어졌네요! 3시간 만에 퇴사를 결정하신 것 같이요!뭐 망설일 이유가 있나요. 자신감과 결단력 그게 제 장점이니까요(웃음)Q) 그럼 이제 Immersive 얘기를 해볼게요. Immersive에서의 생활은 어떠세요?생각했던 것보다 여유가 있어서 좋아요. 그전에는 되게 불안하고 빡빡하고 그럴 것 같은데 막상 해보니까 할만하더라고요. 그리고 일단 사람들이 너무 좋아요. 같이 지내는 사람들이 좋으니까 Immersive도 할만한 것 같아요.Q) 그러면 지금 Immersive에서는 어떤 것을 배우고 있나요?서버를 배우고 있어요. 프론트 쪽 하구요. 프로젝트를 하고 적용을 해봐야 완전히 내 것으로 만들 수 있을 것 같아요. 역시 직접 적용을 해봐야 정확히 알 수 있을 것 같습니다.서버를 배우고 있어요. 프론트 쪽 하구요. 자바스크립트라는 언어의 다양한 문법을 매일 체험해보고 있어서, 매일매일이 새롭습니다. (뭔가 이해할 만 하면 다른걸 배워서..) 프로젝트를 해봐야 완전히 내것으로 만들 수 있을 것 같아요.Q) 앞으로 어떤 개발자가 되고 싶으세요?거창하게 세상을 바꾸는 개발자! 이런 건 제 스타일은 아니에요(웃음) 저는 제가 하고 싶은 것을 하는 개발자. 만들고 싶은 것을 만드는 개발자가 되고 싶어요. 세상을 바꾸는 개발자도 내가 좋아하는 것, 내가 하고 싶은 것, 내가 만들고 싶은 것을 만드는 개발자가 되었을 때 가능하지 않을까요?Q) 프로젝트를 곧 하게 될 텐데 어떤 프로젝트를 하고 싶으신가요?제 경험에 기반한 프로젝트에요. 우리는 회사에서 주는 돈 그냥 받잖아요. 제가 회사를 나오고 받았던 돈들을 확인해보니 제대로 받지 못했다는 것을 알았어요. 그래서 사람들이 노동의 정당한 보상을 알고 받을 수 있도록 도와주는 프로그램을 만들고 싶어요. 주변만 봐도 대부분의 사람들이 이런 문제로 인해 문제를 가지고 있다고 생각해요.Q) 1년 후에 개발자가 되었다고 생각하면 어떤 모습일까요?개발자가 될 수 있을까요?(웃음) 아마 1년 후엔 야근에 쩔어있지 않을까요? 저는 이게 내 일이다라는 생각을 하면 엄청 파고드는 스타일이거든요. 개발자로 처음 들어간 직장에 남아 있거나 이직을 하고 있을 것 같아요. 사실 저는 계획을 잘 안 세우거든요. 그러니까 아무 준비 없이 퇴사하고 개발을 배우고 있죠. 설마 굶어죽기야 하겠어요?Q) 마지막으로 하고 싶은 말이 있나요?제가 퇴사하면서 방 정리도 같이 하게 됐어요. 정리를 하다 보니까 우연찮게 제 학창시절 생활기록부를 보게 되었습니다. 생활기록부에 장래희망을 적는 칸이 있잖아요. 근데 제가 깜짝 놀란 게 거기에 중학교 때부터 고등학교 때까지 줄곧 프로그래머로 적혀있던 거에요. 그동안 까맣게 잊고 살았는데 신기했어요.그리고 또 생각을 해보니까 대학교 때도 제가 컴공과는 아니지만 공대라서 C++을 해야했는데 그 과목에서 처음으로 A+을 받은 기억이 나더라구요. 이런 생각이 들면서 결국 나는 프로그래머를 선택할 운명이었나? 이런 생각도 들고. 결국에는 돌아돌아 이 길로 온 것 같아요. 그래도 돌아왔다고 해서 늦었다거나 아쉽지는 않아요. 제가 지금까지 걸어온 길이 분명히 프로그래밍을 하는데 도움이 된다고 생각하고 있으니까요.네 지금까지 환 까를로스님과의 인터뷰를 진행했었는데요. 정말 비하인드스토리가 엄청나네요. Immersive 성공적으로 수료하시고 원하시는 개발자가 되기를 바랍니다. 앞으로도 다양한 스토리를 가진 Immersive 수강생분들의 이야기로 찾아뵙겠습니다.

개발자들이 Database 프로그램을 선택한 이유Database(이하 DB) 프로그램을 처음 접한 건 Dos에서 사용하는 Database III plus였습니다. 이때는 학생이었기 때문에 프로그램 개발에 관심이 많았지만 대량의 데이터를 다룰 일은 없었습니다. 다음으로 접한 건 clipper였습니다. 과거 C언어를 하던 사람이면 자료 처리를 위해 한 번쯤은 접해봤을 겁니다. 이때까지는 Dos를 주로 사용했고, 간단한 자료를 다루었기 때문에 File 처리만으로도 충분한 결과를 얻을 수 있었죠.그렇다면 DB는 다중 사용자 환경이 되고 바로 사용하게 되었을까요? 예전에 다중 사용자들이 사용했던 걸 꼽자면 PC 통신과 Web이 있을 것입니다. 초창기의 Web은 PHP, ASP가 개발되기 전이었고 Java는 C보다 성능이 낮아 CGI를 C로 구현했으니 게시판이나 자료실 등도 C로 개발했습니다.규모가 큰 PC 통신은 DB를 사용했지만 사설 BBS나 01410 등에 들어가는 외부 업체는 File로 처리했습니다. 이 시기에 사설 BBS나 01410 서비스를 제공하는 업체들은 Workstation을 구입하거나 x86 계열을 구입해 운영체제 (SCO UNIX, Free BSD, Linux 등)를 사용했지만 이때 역시 C로 개발을 했었습니다. 이런 환경에서 점점 File 처리의 한계가 나타나기 시작했던 것이죠.C File lock 예)int iFd, iResult; iFd = open(“LockTest”,O_RDWR);  iResult = lockf(iFd, F_LOCK,10L); /* 필요한 작업 처리 */ close(iFd); 유저가 늘어나고 운영 체제 내부적으로 동시에 처리하는 프로세스가 증가하면서 자료가 깨지는 현상이 나타납니다. 개발자들은 어쩔 수없이 DB를 선택하기 시작했습니다.DB의 장점들DB를 도입하면 여러 가지 장점이 생깁니다. SQL 문장만 익히면 프로그램으로 일일이 구현해야 했던 것들을 명령어만으로 수행할 수 있고 자료의 무결성 또한 보장해 주며, 개발의 생산성까지 높입니다. 만약 특정 날짜의 자료들을 읽어와서 제목 순으로 보여줘야 할 경우, 프로그램으로 개발한 자료를 날짜 별로 읽어 배열에 담고 Quick sort 알고리즘을 적용해 정렬한 후 자료를 보여줘야 합니다. 하지만 DB에서 SQL 문장을 사용하면 간단하게 완성할 수 있습니다. SELECT * FROM TABLE WHERE DATETIME = 날짜 ORDER BY TITLE ; 조심 또 조심!하지만 DB 역시 만능은 아니기 때문에 모든 자료를 처리할 수는 없습니다. 예를 들어 문서(pdf, doc, hwp등) , 이미지(jpg, gif 등), 압축(zip,rar 등) 등의 바이너리 파일입니다. (물론 DB에서 BLOB 자료형을 지원하므로 하드웨어 자원과 성능만 받쳐준다면 불가능한 것은 아닙니다.) 하드웨어 자원과 성능에는 한계가 있기 때문에 DB로 해야 할 일과 하지 말아야 할 일을 구분해야 합니다. 만약 이를 생각하지 않고 DB에 모든 자료를 넣는다면 어떤 문제가 생길까요? 크게 두 가지가 있습니다.첫 번째는 바이너리를 파일을 읽고 쓸 때 발생하는 시간이 문제가 될 수 있습니다. 그 이유는 DB가 Connection Pool로 접속을 관장하는데, 이는 한정된 자원으로 최소한의 시간을 사용해야 많은 유저가 사용할 수 있기 때문입니다. 만약 바이너리 파일을 DB에 올리면서 오랜 시간 접속을 유지한다면 그만큼 다른 유저가 사용할 수 없을 테고, 결국은 DB에서 감당할 수 있는 유저의 수가 줄어들 것입니다.두 번째는 백업의 문제가 있습니다. 우리는 DB에 장애가 발생할 때를 대비해 DB 전체 백업을 합니다. 그런데 DB에 바이너리 파일이 들어가면 백업 시간이 많이 늘어나 원하는 시간 안에 백업을 하지 못하는 일이 발생할 수도 있습니다. 따라서 DB에 바이너리 파일을 넣을 때는 아주 적은 용량의 파일만 넣어야 합니다. 배치에 대하여: OLTP, OLAPDB 용량이 커지면 Query를 수행해도 원하는 결과를 볼 수 없고 DB에 부담을 많이 주는 Query가 발생합니다. 그래서 주기적으로 Query를 돌려 결과를 테이블에 넣고 필요할 때마다 이를 볼 수 있게 배치 처리를 하며 해결합니다. 일, 월, 년 단위의 집계 자료를 구축하면서 시스템에 부하를 줄 수 있기 때문에 보통 야간에 처리를 하죠. 그런데 만약 DB 용량이 너무 커져서 전일자 집계를 배치로 처리하지 못하는 일이 발생하면 어떻게 할까요?여기서 사용할 수 있는 것이 OLAP(OnLine Analytical Processing) DB입니다. 일반적으로 유저가 사용하는 건 OLTP(OnLine Transaction Processing) 입니다. 대표적으로 Oracle, MySQL PostgreSQL 등이 있습니다. 여기서 MySQL 을 제외하고 Oracle과 PostgreSQL 은 Partition, HASH 조인, Parallel을 지원하여 OLAP 환경에서도 어느 정도 사용 가능합니다.OLAP DB는 주로 DW 환경에서 사용하며 대표적으로 Teradata와 Oracle Exadata 등이 있습니다. OLAP DB 와 비교가 안 될 정도를 빠르게 배치 작업을 처리할 수 있습니다. (자세한 내용은 다음 글에서 설명하겠습니다.)Conclusion지금까지의 이야기를 정리하면 ‘여러 유저가 동시에 안정적으로 자료 처리를 하려면 DB를 사용하고, 자료의 양과 처리 형태(OLAP, OLTP) 에 따라 DB를 선택하면 된다’는 것이었습니다. 자세한 설명을 하자면 각 DB별 특성을 기술해야 하기 때문에 오늘은 전체적인 내용부터 살펴봤습니다. 다음 글에서는 유저가 사용하는 OLTP에 대해 살펴보겠습니다. 글한석종 부장 | R&D 데이터팀[email protected]#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유

Overview“나 혼자 프로젝트를 하니 주석은 안 달아도 무방해요” 이렇게 말하는 개발자는 그 코드를 가장 많이 보는 것도 자신이라는 사실을 잊고 있을지도 모릅니다. 구린 코드를 보고 욕했는데 3개월 전 자신이 작성한 코드란 걸 알면 그제서야 얼굴이 붉어지기 일쑤죠. 작은 습관이지만 약간의 변화만 준다면 분명 즐겁고 생산적인 개발을 할 수 있을 겁니다. 얼굴 붉어질 일도 없고요. 오늘은 그 노하우를 전해드립니다. 혼돈을 피하는 여섯 가지 코드 작성법조건문은 긍정적으로 쓰자조건문의 성능은 생각하지 말자조건 검증을 깔끔하게 하자주석은 적절하게, 적당하게 하자상수를 활용하자복잡한 코드는 풀어서 쓰자과거의 나 자신아, 넌 나에게 똥을 줬어1.조건문은 긍정적으로 쓰자”쟤가 그 아이가 아니지 않지 않나?!” 프로그램 코드를 마지막으로 실행하는 건 컴퓨터지만 코드를 작성하고 관리하는 건 결국 사람입니다. 수많은 조건문이 존재하는 프로그램에서 조건이 부정적이라면 한 번 더 생각해야 합니다. 반대로 조건문을 긍정적으로 작성하면 보다 편리하게 개발을 진행할 수 있습니다. 가능하다면 긍정적인 마인드로 조건문을 적어봅시다.<?php // 예제는 PHP로 작성 되었습니다. $title = $_POST['title']; // 공지사항 제목 if (empty($title)) {     echo '제목을 입력해주세요';    return; } // 위의 경우보다 한번 더 생각해야한다. if (!isset($title)) {     echo '제목을 입력해주세요';    return; } cf)비슷한 사례 for 증감식을 i– 처럼 적는 경우 꼭 필요한 경우가 아니라면 삼가는 것이 좋다. for로 작성 가능한 반복을 while로 구현하는 경우 for는 끝이 명확하지만 while은 언제나 불안하다. 2.조건문의 성능을 생각하지 말자간혹 조건문에 성능을 고민해 줄여보려는 개발자가 있습니다. 10개의 and 조건을 2개로 줄인다면 얼마나 이득일까요? 하지만 이것은 티도 나지 않는 적은 양입니다.1) 조건문을 압축하지 마세요. 시간이 지나면 자신의 코드가 마치 보물지도처럼 보일 수도 있습니다. 조건문을 최적화하려고 하기보다는 보기 좋고 읽기 편하게 변경합시다. 3.조건 검증을 깔끔하게 하자만약 게시물에 글을 쓰는 프로그램을 제작한다면 요청된 값들이 정상인지 확인해야 합니다. ‘게시물 제목이 있고, 글 내용이 있고, 글 분류가 정상이고, 뭐뭐 하면 등록!’이라고 작성하면 논리적인 접근으로 보이지만 코드의 상태는 그렇지 않습니다.<?php $title = $_POST['title']; // 공지사항 제목 $content = $_POST['content']; // 공지사항 내용 $category = $_POST['category']; // 공지사항 분류 if (!empty($title)) {     if (!empty($content)) {         if (!empty($category)) {             // 게시글을 등록한다.!         } else {             echo '카테고리를 선택해주세요';         }     } else {         echo '내용을 입력해주세요';     } } else {     echo '제목을 입력해주세요'; } if문 블럭이 중첩되어 가로 스크롤 압박에 시달릴 것이기 때문입니다. 또한 나중에 수정하려면 많이 고생해야 합니다. 조건 검증을 하는 코드라면 아닌 경우를 체크하는 것이 더 좋습니다. 아래와 같은 형태로 작성하는 게 깔끔하고, 유지 보수에도 도움이 됩니다. 게시물 제목이 없으면 오류 출력글 내용이 없으면 오류 출력글 분류가 정상이 아니면 오류 출력그 외 등등…<?php // 예제는 PHP로 작성 되었습니다. $title = $_POST['title']; // 공지사항 제목 $content = $_POST['content']; // 공지사항 내용 $category = $_POST['category']; // 공지사항 분류 if (empty($title)) {     echo '제목을 입력해주세요';     return;  } if (empty($content)) {     echo '내용을 입력해주세요';     return;  } if (empty($category)) {     echo '카테고리를 입력해주세요';     return;  } // 게시글을 등록한다.! 4.주석은 적절하게, 적당하게 하자주석이 많아야 좋을까요, 아니면 적어야 좋을까요? 이 논제는 여전히 개발자 사이에서 뜨거운 감자입니다. 다양한 의견이 있지만 저는 ‘적당한게 좋다’고 생각합니다. 주석이 없어서 고생한 적도 있지만, 주석이 너무 많거나 쓸모없었던 적도 겪어봤기 때문입니다. 가끔 “코드 한 줄마다 주석을 달아”라는 미친 선임도 있었고 “주석이 필요 없게 깔끔하게 짜”라고 말하는 기괴한 선임도 있었습니다. 사고의 최종 결과물인 프로그램 코드가 아무런 설명 없이 다른 사람 혹은 미래의 자신을 이해시키는 건 불가능한 일이라고 생각합니다. 다양한 테크닉과 아름다운(?) 코딩으로 주석을 줄여나갈 수는 있겠지만 꼭 필요한 곳엔 적어야 한다고 생각합니다. 4-1) 주석이 꼭 필요하다고 생각할 때 깊은 사고의 결과를 코드로 작성하였고, 다음에 왜 그렇게 작성했는지 헷갈릴 것 같을 때함정 카드가 발동되어 헤맬 것 같은 코드일 때코드가 길어져 기능의 단위별로 나눠서 보는 게 좋을 때기술된 함수나 클래스가 이름과 다르게 동작하는 코드일 때한참 디버깅 후에 허무함을 안겨준 코드일 때함수 클래스 파일에 대한 주석일 때변수가 특이성을 가지고 있거나, 타입별로 세팅되는 값일 때플러그인이나 라이브러리 사용법을 공유할 때 4-2) 주석을 줄여 나가야 한다고 생각할 때 조건문의 내용을 한글로 다시 기술하고 있을 때프로그램과 관계 없는 내용일 때변수명으로 설명이 가능한 내용을 기술하고 있을 때4-3) 주석이 잘못 되었다고 생각할 때 나만 이해할 수 있는 단어나 문장으로 기술된 주석일 때주어가 없는 주석일 때5.상수를 활용하자코드값에 따라 분기를 작성 중이라면 상수를 활용하는 게 좋습니다. ‘F’보다는 FACEBOOK_SERVICE 가 더 직관적이기 때문입니다.<?php // 예제는 PHP로 작성 되었습니다. if ($userAccountType == 'F') {     // 페이스북 유저 처리 로직 } /** 유저 구분 값 페이스북 */ define('ACCOUNT_TYPE_FACEBOOK', 'F'); // 코드는 좀 더 길어보이지만 별다른 주석 없이도 어떤 코드인지 알 수 있다. if ($userAccountType == ACCOUNT_TYPE_FACEBOOK) {     // 페이스북 유저 처리 로직 } 상수는 프로그램마다 다양한 형태로 지원되기 때문에 선언 후 참조해서 쓴다면 주석을 줄이는 데에 많은 도움이 될 것입니다.6.복잡한 코드는 풀어서 쓰자여러 가지 사고의 결정이 다시금 엮여서 또 다른 결과를 만들어야 하는 복잡한 코드입니까? 우선 서술형 문장으로 먼저 정리하십시오. 그 다음 오류가 없다면 이어서 작성하는 것이 좋습니다. 2)// 기획전이 시작 되면 세팅한 값으로 할인을 하고 // 기획전이 끝나면 원래의 할인율로 돌아오게 하는 프로그램 이다. 1. 대상 기획전을 찾는다.     * 기획전 시작일이 오늘인가? 종료일이 오늘인가? 2. 트랜잭션을 연다. 3. 대상 기획전 건수 만큼 루프를 돌며     1. 조건 체크         case 1. 시작일이 오늘이면             1. 상품 상태를 기획전 데이터로 업데이트         case 2. 종료일이 오늘인면             1. 상품 상태를 시작일 이전 히스토리 데이터로 변경     2. 상품 히스토리를 남긴다. 4. 커밋한다. 저는 사고의 결과를 주석 형태로 작성하고, 순번을 달아서 진행을 정리합니다. 다음으로 정리된 내용을 검증하고, 주석을 중간 크기로 작성해 쪼갭니다. 그 밑에 코드를 작성하면 두 마리 토끼를 잡을 수 있습니다. 중간 크기의 주석은 프로그램의 진행 단위를 나눠서 보기 편하고, 단계별로 검증할 때에도 유용합니다.<?php /***************************************************** * 1. 대상 기획전을 찾는다. *     - 기획전 시작일이 오늘인가? 종료일이 오늘인가? **************************************************** */ // 세부 로직은 생략함 $list = getPlainedPromotionList(); /*****************************************************  * 2. 트랜잭션을 연다. **************************************************** */ beginTransaction(); /*****************************************************  * 3. 대상 기획전 건수 만큼 루프를 돌며 *****************************************************/ foreach ($list as $obj) { /*****************************************************  *        case 1. 시작일이 오늘이면  *            1. 상품 상태를 기획전 데이터로 업데이트 *****************************************************/     if ($obj['startDate'] == $today) {         updateProductDistRate($obj['productNo'], $obj['distRate']);    } /*****************************************************  *        case 2. 종료일이 오늘인면  *            1. 상품 상태를 시작일 이전 히스토리 데이터로 변경  *****************************************************/     if ($obj['endDate'] == $today) {        recoveryProductFromHistory($obj['productNo']);    } /*****************************************************  *    2. 상품 히스토리를 남긴다. *****************************************************/     addProductHistory($obj['productNo']); } /*****************************************************  * 4. 커밋한다. *****************************************************/ commit(); Conclusion영화 <인터스텔라(Interstellar, 2014)>의 주인공 쿠퍼(매튜 맥커너히)가 책장 너머 다른 차원에서 과거의 자신에게 신호를 보냈던 명장면이 생각납니다. “ STAY” 그의 메시지는 분명 후회의 몸부림이었을 겁니다. 마찬가지로 당신이 조건문을 부정적으로 만들고 있다면 잠시 키보드에서 손을 떼는 게 좋습니다. 다른 차원의 자신이 어딘가에서 메시지를 보내고 있을지도 모르니까요. “STOP….” 참고 1) 1초에 수백억 번 이상 연산이 가능한 컴퓨터에선 10회와 2회의 차이가 거의 없다. 2) 동료에게 정리한 문장을 이해시킬 수 있다면 정리가 잘 되었을 확률이 높다. 글천보성 팀장 | R&D 개발2팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유

이 포스팅은 총 4부로 이어지며 현재는 4부입니다.1부 : Android, MVC, MVVM, MVP2부 : Android 와 Annotation3부 : AndroidAnnotations 과 MVC4부 : AndroidAnnotations 과 테스트앞선 3개의 포스팅을 통해 AndroidAnnotations 과 MVC 가 view 에 관여하는 동작들이 모두 View 로 분리된 것을 확인할 수 있습니다.이러한 구조덕분에 Model 에 대한 테스트와 View 에 대한 테스트가 명확히 구분지어지게 되었습니다.Test 코드를 작성함에 있어서 View 에 대한 테스트가 다소 어려움이 있다는 것을 감안한다면 Model 에 대한 테스트만 집중할 수 있는 구조가 테스트에 대한 접근을 더욱 쉽게 해줍니다.다음은 앞선 포스팅에서 정의된 코드 중에서 Model 에 대한 테스트입니다.※ 테스트코드는 Robolectric 을 이용하여 작성하도록 하겠습니다.Model Test@RunWith(RobolectricGradleTestRunner.class) public class MainModelTest { private MainModel mainModel; @Setup public void init() { mainModel = new MainModel(Robolectric.application); } @Test public void testGetReleaseState() { // given String version = "3.19" // not yet released // when boolean isReleased = mainModel.getReleaseState(version); // then assertThat(isReleased, is(equalTo(false)); // given version = "3.18" // released // when isReleased = mainModel.getReleaseState(version); // then assertThat(isReleased, is(equalTo(true)); } }위와 같이 Model 만 별도로 테스트가 용이해졌습니다.Presenter TestPresenter 에 대한 테스트는 Model 에 대한 테스트와 다릅니다.Activity 에 커플링이 높기 때문에 해당 Activity 를 직접 바인딩해야 합니다.@RunWith(RobolectricGradleTestRunner.class) public class MainViewTest { private MainActivity mainActivity; private MainView MainView; @Setup public void init() { mainActivity = Robolectric.buildActivity(MainActivity.class).create().start().resume().get(); MainView = mainActivity.mainView; } @Test public void testGetVersionText() { // given String version = "3.19" // when MainView.versionEditText.setText(version); // then assertThat(MainView.getVersionText(), is(equalTo(version)); } }Jandi Team은 View 를 테스트하기 위해서 Presenter 와 Activity 의 패키지 Level 을 같은 Level 로 유지하고 있습니다.AndroidAnnotations 에서 DI 를 설정하기 위해서는 해당 변수나 메소드는 최소 Package Scope 로 정의해야하기에 위와 같은 형태의 Field 접근을 볼 수 있습니다.정리AndroidAnnotations 를 활용한 MVC 패턴의 전환의 또다른 이점은 이와 같이 테스트를 명확히 분리할 수 있다는 장점을 주었습니다. 물론 이 방법은 MVVM, MVP 로 구현하였을때보다 나은 형태라 할 수는 없으나 View 에 대한 테스트가 좀 더 용이해진 것이라 생각합니다.※ Activity 는 왜 테스트하지 않나요?MVP 패턴에서 Activity는 Controller 의 모습을 지니고 있습니다. 이는 Unit Test 가 아닌 Behavior 테스트에 가까운 모습이며 다른 방식으로의 테스트코드 구현이 필요하다고 생각합니다.#토스랩 #잔디 #JANDI #개발 #개발자 #개발팀 #기술스택 #일지 #후기 #꿀팁 #인사이트

Kubernetes을 활용한 분산 부하 테스팅동명의 글이 Google Cloud Platform에도 있으니 여기서는 여태까지 한 삽질과 교훈에 집중한다.첫 시도 ngrinder처음에는 ngrinder로 부하 테스트 환경을 구축하려 했다. 몇 달 전에 부하 테스트를 진행할 때 잠시 쓴 적이 있었기 때문에 굳이 다른 솔루션을 찾을 이유가 없었다. 하지만 결국 후회하고 다른 솔루션으로 넘어갔는데 그 이유를 중요한 순으로 꼽자면로컬 개발환경과 실제 환경이 차이가 많다. 로컬에서는 JUnit 기반으로 개발과 디버깅이 가능하다. 하지만 이렇게 작성한 코드를 ngrinder에 넣으려 하면 외부 라이브러리가 문제가 된다. .jar 등 패키지 파일을 업로드하는 방식이 아니라 Groovy 스크립트 따로 스크립트에서 사용하는 라이브러리 따로 업로드를 해야 하는데 상당히 번거롭다.웹 UI를 통해 설정한 내용이 내장 데이터베이스에 바이너리로 들어가기 때문에 ngrinder 데이터를 관리하기가 힘들다.개발이 활발하지 않다. 주력 개발자가 Naver를 떠났다는 이야기도 있긴 한데 아무튼 커밋 히스토리를 보면 개발이 정체되어 있는 건 분명하다.설계가 진보적이지 않다. 예를 들어 현재 쓰레드의 ID를 시스템이 직접 계산해서 주입하지 않고 개발자가 주어진 코드 스니펫을 Copy & Paste 해야 하는 이유를 모르겠다.등이 있다. 이런 까닭에 좀더 간단한 솔루션을 찾아보았다.대안몇 가지 대안을 살펴보았는데Artillery는 테스트 스크립트를 yaml로 기술하기 때문에 얼핏 쉬워보이지만 이런 식의 접근 방법은 매번 실망만 안겨주었다. 조금만 테스트 시나리오가 복잡해지면 일반적인 코딩보다 설정 파일이 훨씬 짜기가 어렵고 이해하기도 어렵다.config: target: 'https://my.app.dev' phases: - duration: 60 arrivalRate: 20 defaults: headers: x-my-service-auth: '987401838271002188298567' scenarios: - flow: - get: url: "/api/resource"Gatling은 아직 분산 서비스를 지원하지 않아서 제외했다. 팀 내에 Scala 개발경험이 있는 사람이 극소수인 점도 문제였다.Locust로 정착이런 까닭에 Locust로 넘어왔다. 장점은파이썬 스크립트로 시나리오를 작성하니 내부에 개발인력이 충분하다.로컬환경과 실제 부하테스팅 환경이 동일하다. 즉, 디버깅하기 쉽다.Locust 데이터를 Dockerize하기 쉽다.한마디로 ngrinder에서 아쉬웠던 점이 모두 해결됐다. 반면 ngrinder에 비해 못한 면도 많긴 하다.통계가 세밀하지 않다.테스트 시나리오를 세밀하게 조정하기 힘들다.현재로썬 그때그때 가볍게 시나리오를 작성해서 가볍게 돌려보는 게 중요하지 세밀함은 그리 중요하지 않아서 Locust가 더 나아 보인다. 시나리오는 몰라도 통계의 경우, DataDog 같은 모니터링 시스템에서 추가로 정보를 제공받기 때문에 큰 문제도 아니긴 하다.결과물Locust on KubernetesGoogleCloudPlatform/distributed-load-testing-using-kubernetes에 있는 소소코드를 참고로 작업하면 된다. 단지 Dockerfile의 경우, 테스트 스크립트만 바뀌고 파이썬 패키지는 변경사항이 없는 경우에도 파이썬 스크립트 전체를 새로 빌드하는 문제가 있다.# Add the external tasks directory into /tasks ADD locust-tasks /locust-tasks# Install the required dependencies via pip RUN pip install -r /locust-tasks/requirements.txt 그러므로 이 부분을 살짝 고쳐주면 좋다.ADD locust-tasks/requirements.txt /locust-tasks/requirements.txtRUN pip install -r /locust-tasks/requirements.txtADD locust-tasks /locust-tasksngrinder on Kubernetesngrinder를 Kubernetes v1.4.0 위에서 돌리는데 사용한 설정은 다음과 같다. 참고로 dailyhotel/ngrinder-data는 ngrinder의 데이터만 따로 뽑아서 관리하는 도커 이미지이다.ControllerapiVersion: v1 kind: Service metadata:  name: ngrinder  labels:  app: ngrinder  tier: middle  dns: route53  annotations:  domainName: “ngrinder.test.com” spec:  ports:  # the port that this service should serve on  — name: port80  port: 80  targetPort: 80  protocol: TCP  — name: port16001  port: 16001  targetPort: 16001  protocol: TCP  — name: port12000  port: 12000  targetPort: 12000  protocol: TCP  — name: port12001  port: 12001  targetPort: 12001  protocol: TCP  — name: port12002  port: 12002  targetPort: 12002  protocol: TCP  — name: port12003  port: 12003  targetPort: 12003  protocol: TCP  — name: port12004  port: 12004  targetPort: 12004  protocol: TCP  — name: port12005  port: 12005  targetPort: 12005  protocol: TCP  — name: port12006  port: 12006  targetPort: 12006  protocol: TCP  — name: port12007  port: 12007  targetPort: 12007  protocol: TCP  — name: port12008  port: 12008  targetPort: 12008  protocol: TCP  — name: port12009  port: 12009  targetPort: 12009  protocol: TCP  selector:  app: ngrinder  tier: middle  type: LoadBalancer  — - apiVersion: extensions/v1beta1 kind: Deployment metadata:  name: ngrinder spec:  replicas: 1  template:  metadata:  labels:  app: ngrinder  tier: middle  spec:  containers:  — name: ngrinder-data  image: dailyhotel/ngrinder-data:latest  imagePullPolicy: Always  volumeMounts:  — mountPath: /opt/ngrinder-controller  name: ngrinder-data-volume  — name: ngrinder  image: ngrinder/controller:latest  resources:  requests:  cpu: 800m  ports:  — containerPort: 80  — containerPort: 16001  — containerPort: 12000  — containerPort: 12001  — containerPort: 12002  — containerPort: 12003  — containerPort: 12004  — containerPort: 12005  — containerPort: 12006  — containerPort: 12007  — containerPort: 12008  — containerPort: 12009  volumeMounts:  — mountPath: /opt/ngrinder-controller  name: ngrinder-data-volume  volumes:  — name: ngrinder-data-volume  emptyDir: {}AgentsapiVersion: extensions/v1beta1 kind: Deployment metadata:  name: ngrinder-agent spec:  replicas: 5  template:  metadata:  labels:  app: ngrinder-agent  tier: middle  spec:  containers:  — name: ngrinder-agent  image: ngrinder/agent:latest  imagePullPolicy: Always  resources:  requests:  cpu: 300m  args: [“ngrinder.test.com:80”]구 블로그 시절의 댓글#데일리 #데일리호텔 #개발 #개발자 #개발팀 #기술스택 #도입후기 #일지 #Kubernetes #인사이트

우리는 고객이 무엇에 관심 있어 하고 무엇에 관심 없어하는지, 어떤 것을 보았을 때 클릭해 들어가고 어떤 것을 보았을 때 사이트에서 이탈하는지 궁금해 합니다. 이러한 정보를 얻기 위해 봐야 할 것은 역시 웹서버의 접속 로그입니다.처음에는 매일 생성되는 로그 파일을 일일이 파싱해서 원하는 정보를 DB에 쌓는 방법을 이용했지만, 이러한 방식은 한계가 있었습니다. 저장할 수 있는 데이터의 양에 심각한 제한이 있었고, 따라서 처음에 얻고자 했던 데이터 이상의 것을 새로 추출할 수도 없었습니다.그래서 지금은 웹서버 로그를 하둡(Hadoop) 클러스터에 쌓고 있습니다. Google Analytics 같은 외부 분석툴을 사용하기도 하지만, 아무래도 데이터를 우리 손에 직접 들고 있는 것이 더 유연한 분석을 제공할 수 있지요. 클러스터에서 로그를 분석하려면 가장 먼저 로그 수집 시스템을 만들어야 합니다.이번 포스팅에서는 이 로그 수집 시스템이 어떻게 만들어져 있는지, 그리고 그보다 더 중요한 시스템의 모니터링을 어떻게 하고 있는지 설명하려고 합니다.Flume 에이전트 설정하기Apache FlumeApache Flume은 로그와 같은 데이터의 흐름(streaming)을 제어할 수 있게 해주는 도구입니다. 단순하면서도 확장성 높은 구조로 되어 있기 때문에 많은 시스템에서 채택하는 도구가 되었고, 리디북스에서도 Flume 을 사용하게 되었습니다.Flume 의 기본 구조는 단순합니다.기본적인 에이전트 구성 (이미지 출처: Apache Flume 홈페이지)에이전트(agent)는 Source, Channel, Sink 로 이루어진 자바 프로세스이다.소스(source)는 외부에서 이벤트를 입력받아 채널(channel)로 전달하고, 채널은 이벤트를 저장하고 있다가 싱크(sink)로 전달한다. 싱크는 이벤트를 외부로 출력한다.한 에이전트의 Sink와 다른 에이전트의 Source가 같은 타입이면, 에이전트 간에 이벤트를 전달할 수 있다.굉장히 간단하지만 강력한 모델입니다. Flume 은 Avro, Thrift, Exec, HDFS, Kafka 등 다양한 라이브러리를 적용한 소스와 싱크를 미리 제공하고 있기 때문에, 사용자는 자기 입맛에 맞게 이를 조합해서 시스템을 구성할 수 있습니다.예를 들면 아래와 같습니다.좀 더 복잡한 에이전트 구성 (이미지 출처: Apache Flume 홈페이지)초기 에이전트 구성: Avro를 통해 클러스터에 로그 전송저희가 맨 처음 설정한 Flume 에이전트의 구성은 다음과 같습니다.초기 에이전트 구성각 웹서버ExecSource: exec 명령으로 실행된 프로세스의 표준 출력을 이벤트로 입력받음. (tail -F <로그파일>)MemoryChannel: 메모리상의 큐(queue)로 구현된 채널AvroSink: 클러스터에 상의 에이전트가 실행하는 Avro RPC 서버로 이벤트를 전송하둡 클러스터AvroSource: 웹서버의 에이전트가 Avro RPC 로 보내는 이벤트를 수신MemoryChannelHDFSSink: HDFS 상의 지정된 경로의 파일에 이벤트 내용을 출력각 웹서버에는 에이전트가 하나씩 실행되어서, 로그 파일에 새로 추가되는 로그를 클러스터에 전송합니다. 클러스터 상의 에이전트는 단 한 개 존재하는데, 웹서버로부터 전송받은 로그를 HDFS(Hadoop File System) 에 파일로 출력하는 역할을 합니다. 웹서버 에이전트와 클러스터 에이전트 간의 통신은 Avro RPC 로 하게 하였습니다. Flume 에서 기본적으로 AvroSource 와 AvroSink 를 구현하여 제공해 주는 것을 이용했습니다.사실은 클러스터 상의 에이전트가 Avro 서비스를 통해 데이터를 모아 주지 않고, 웹서버 상의 에이전트가 HDFSSink 를 이용해서 직접 클러스터에 파일을 쓰게 하더라도 대부분의 경우는 상관없습니다. 하지만 리디북스의 경우는 그렇게 할 수 없었는데, 왜냐하면 웹서버와 하둡 클러스터가 서로 다른 네트워크 상에 있기 때문입니다.리디북스의 웹서버는 국내 IDC에 존재하지만 하둡 클러스터는 Miscrosoft Azure 클라우드 내의 가상머신으로 실행되고 있습니다. 따라서 하둡의 네임노드(namenode)가 인식하는 각 노드의 사설 IP 주소를 웹서버들이 쉽게 접근할 수 없습니다. 이를 우회하는 다양한 방법을 시도해 보았지만 최종적으로는 Avro 서비스를 중간에 두어 해결하였습니다.모니터링 알람 설정하기JSON 리포팅 사용다음은 에이전트 프로세스를 모니터링하는 문제가 있었습니다. 예기치 않은 에러로 에이전트가 종료되어서 로그가 수집되지 않고 있는데 며칠 동안 모르고 있어서는 안되겠지요.Flume 에서는 모니터링 인터페이스도 여러가지를 제공하고 있는데, 그 중 가장 이용하기 간편한 것은 HTTP 를 통한 JSON reporting 이었습니다. 에이전트 자체가 HTTP 서비스로 작동해서, 특정 포트로 요청을 보내면 에이전트의 상태를 JSON 으로 정리하여 응답을 주게 되어 있습니다. 에이전트 실행시에 옵션 몇 개만 추가하면 바로 설정할 수 있기 때문에 매우 간단합니다.Health 페이지를 이용한 모니터링그런데 이 리포팅이 제대로 나오지 않으면 어떻게 알림을 받을 수 있을까요? 각 서버마다 JSON 리포팅을 요청해서 응답이 제대로 오지 않으면 이메일을 보내는 스크립트를 만들어서 cron 으로 5분마다 실행하는 방법도 있습니다. 하지만 이 스크립트가 제대로 동작하지 않거나, 이게 실행되는 서버가 다운되면?결국 스스로를 믿지 못하고 택한 방법은 외부 서비스 Pingdom을 이용하는 것이었습니다. 단, 외부 서비스가 각각의 웹서버에 직접 접근하여 리포팅을 요청하는 방식은 보안상 문제가 될 수 있어서 아래와 같이 보완하였습니다.웹 서비스 상에 health 페이지 구현. 이 페이지는 각 웹서버의 에이전트의 JSON reporting 포트로 요청을 보내서, 결과를 종합해서 다시 JSON 으로 보여줌.모든 에이전트가 정상적으로 리포트를 보내면 {“status”: “OKAY”} 를, 아니면 {“status”: “ERROR”} 를 보여줌.이 health 페이지의 내용을 모니터링하도록 Pingdom 설정. {“status”: “OKAY”} 가 응답에 없으면 알람 메일이 오도록 함.{ "status": "OKAY", "metrics": { "192.168.0.101": { "SOURCE.log_src": { ... }, "SINK.avro_sink": { "BatchCompleteCount": 562110, "ConnectionFailedCount": 294, "EventDrainAttemptCount": 56246850, "ConnectionCreatedCount": 31, "Type": "SINK", "BatchEmptyCount": 16, "ConnectionClosedCount": 30, "EventDrainSuccessCount": 56243927, "StopTime": 0, "StartTime": 1459135471379, "BatchUnderflowCount": 610 }, "CHANNEL.mem_channel": { ... } }, "192.168.0.102": { ... } } }Health 페이지의 Json내용JSON 리포팅의 문제이렇게 설정해 놓고, 며칠간 로그가 HDFS 상에 잘 수집되는 것을 확인하고 만족해 했습니다. 그런데 며칠간 신경을 쓰지 않은 사이, 다시 에이전트를 확인해 보니 모든 웹서버 에이전트가 죽어 있었습니다. HDFS에 로그도 쌓이지 않았구요.확인해 보니, MemoryChannel 의 설정 문제였습니다. byteCapacity 값을 실수로 너무 작게 설정해서, 채널 큐가 메모리 부족으로 터져나간 것이죠. 해당 문제는 byteCapacity 값을 늘려서 간단하게 해결했습니다.문제는 알람이 오지 않았다는 것이었습니다. 문제를 재현해 본 결과, 채널이 터져서 에이전트 실행이 중단되어도, 에이전트 프로세스는 죽지 않고 ExecSource 에서 실행한 자식 프로세스(tail -F)만 죽어 있었습니다. 이렇게 되면 JSON 리포팅도 정상적으로 나오기 때문에, 결국 JSON 리포팅으로는 이런 유형의 에러를 잡지 못한다는 결론이 나왔습니다.클러스터에 모니터링 설정하기결국 웹서버상에서 모니터링하는것 보다는 데이터를 최종 전달받는 하둡 클러스터 상에서 모니터링하는 것이 안정적이라 판단하였습니다. 다행히도, 하둡 클러스터에서 사용할 수 있는 꽤나 좋은 모니터링 도구가 이미 있었습니다.CDH 의 알람 트리거리디북스에서는 기본 하둡 패키지가 아닌, Cloudera에서 제공하는 하둡 배포판인 Cloudera CDH를 사용하고 있습니다. CDH는 클러스터 상에서 사용되는 서비스마다 각종 테스트를 자동으로 실행하여, 테스트가 통과되지 않을 때마다 메일로 알람을 보내줍니다. 그리고 웬만한 필수 테스트는 기본적으로 설정되어 있지만, 사용자가 커스텀 서비스를 직접 제작할 수도 있습니다. CDH가 각 에이전트의 소스, 채널, 싱크마다 초당 전송한 이벤트 개수 등의 측정치(metric)을 모두 기록하고 있기 때문에, 이 값들이 일정 수준 이상/이하가 될 때마다 알람이 트리거되도록 설정할 수 있습니다.CDH의 알람 트리거 편집 화면웹서버마다 알람 설정하기그런데 이것으로 끝이 아닙니다. 클러스터 에이전트는 각 서버에서의 트래픽이 모두 모이는 곳이기 때문에, 여기에서 모니터링을 하는 것은 웹서버 상에서 모니터링하는 것보다 기준이 애매해집니다.10대의 웹서버 중에 한 대만 문제가 생겼을 경우, 클러스터 에이전트가 받는 트래픽은 0으로 줄어드는 것이 아니라 90%로 줄어듭니다. 알람을 트리거하는 역치(threshold)를 평소 트래픽의 90%로 잡아야 한다는 것이지요. 그런데 트래픽이라는 것이 원래 날짜와 시간에 따라 달라지기 때문에, 이 역치값을 고정된 값으로 정할 수가 없습니다. 트래픽이 높은 때를 기준으로 하면, 트래픽이 낮아지는 새벽 시간마다 가짜 알람(false alarm)이 오게 되겠지요. 그렇다고 트래픽이 낮은 때를 기준으로 하면, 트래픽이 높은 때 웹서버 에이전트가 죽더라도 새벽이 될 때까지 알 수 없습니다.결국 클러스터 단에서도 각 웹서버마다 트래픽을 구분해 주어야 한다는 결론이 나옵니다. 다행히 한 에이전트가 여러 개의 채널과 싱크를 가질 수 있고, 이벤트 헤더의 내용에 따라 소스가 어느 채널로 이벤트를 보낼지 결정해 주는 채널 셀렉터 (Channel Selector)라는 것이 있습니다.웹서버 에이전트의 소스에서는 각 이벤트 헤더에 자기 호스트명을 달아 준다. (Interceptor 는 각 이벤트에 원하는 헤더를 달아주는 역할을 한다. HostInterceptor 이용)클러스터 에이전트는 1개의 소스와, 웹서버 대수만큼의 채널 및 싱크가 있다.클러스터의 소스는 이벤트의 host 헤더를 보고 그에 해당하는 채널로 이벤트를 전달한다. (MultiplexingSelector 사용)각 채널은 자신에게 대응되는 싱크에 이벤트를 전달하고, 싱크는 각자의 HDFS 경로에 이벤트를 파일로 출력한다.최종 에이전트 구성: 채널 셀렉터로 트래픽 나누기최종적으로 나온 에이전트의 구성은 다음과 같습니다.최종 에이전트 구성그리고 에이전트 설정 파일은 아래와 같이 작성했습니다.... log_to_avro.sources.log_src.type = exec log_to_avro.sources.log_src.command = tail -F /path/to/log/file log_to_avro.sources.log_src.restart = true log_to_avro.sources.log_src.channels = mem_channel log_to_avro.sources.log_src.interceptors = ts_ic host_ic # 호스트 인터셉터 설정 log_to_avro.sources.log_src.interceptors.ts_ic.type = timestamp # 이벤트 헤더에 timestamp 삽입 (날짜별 구분을 위해) log_to_avro.sources.log_src.interceptors.host_ic.type = host # 이벤트 헤더에 호스트명 삽입 (호스트별 구분을 위해) log_to_avro.sources.log_src.interceptors.host_ic.useIP = true # 호스트명 대신에 IP 사용 log_to_avro.channels.mem_channel.type = memory log_to_avro.channels.mem_channel.capacity = 10000 log_to_avro.channels.mem_channel.transactionCapacity = 10000 log_to_avro.channels.mem_channel.byteCapacityBufferPercentage = 20 log_to_avro.channels.mem_channel.byteCapacity = 10485760 log_to_avro.sinks.avro_sink.type = avro log_to_avro.sinks.avro_sink.channel = mem_channel log_to_avro.sinks.avro_sink.hostname = hostname.of.cluster.agent log_to_avro.sinks.avro_sink.port = 4141 ...웹서버 에이전트 설정파일... avro_to_hdfs.sources.avro_src.type = avro avro_to_hdfs.sources.avro_src.bind = 0.0.0.0 avro_to_hdfs.sources.avro_src.port = 4141 avro_to_hdfs.sources.avro_src.channels = c_101 c_102 avro_to_hdfs.sources.avro_src.selector.type = multiplexing # Multiplexing Selector 설정 avro_to_hdfs.sources.avro_src.selector.header = host # 호스트 이름으로 채널 나누기 avro_to_hdfs.sources.avro_src.selector.mapping.192.168.0.101 = c_101 # 192.168.0.101 에서 온 이벤트는 c_101 채널로 avro_to_hdfs.sources.avro_src.selector.mapping.192.168.0.102 = c_102 # 192.168.0.102 에서 온 이벤트는 c_102 채널로 # 채널 c_101 설정 avro_to_hdfs.channels.c_101.type = memory avro_to_hdfs.channels.c_101.capacity = 10000 avro_to_hdfs.channels.c_101.transactionCapacity = 10000 avro_to_hdfs.channels.c_101.byteCapacityBufferPercentage = 20 avro_to_hdfs.channels.c_101.byteCapacity = 10485760 # 싱크 k_101 설정 avro_to_hdfs.sinks.k_101.type = hdfs avro_to_hdfs.sinks.k_101.channel = c_101 avro_to_hdfs.sinks.k_101.hdfs.fileSuffix = .log.gz avro_to_hdfs.sinks.k_101.hdfs.path = hdfs://namenode/path/to/logs/dir/%Y%m%d/%{host} # 날짜별, 호스트별로 다른 디렉토리에 avro_to_hdfs.sinks.k_101.hdfs.rollSize = 104857600 avro_to_hdfs.sinks.k_101.hdfs.rollInterval = 7200 avro_to_hdfs.sinks.k_101.hdfs.rollCount = 0 avro_to_hdfs.sinks.k_101.hdfs.fileType = CompressedStream avro_to_hdfs.sinks.k_101.hdfs.codeC = gzip # 채널 c_102 설정 avro_to_hdfs.channels.c_102.type = memory avro_to_hdfs.channels.c_102.capacity = 10000 avro_to_hdfs.channels.c_102.transactionCapacity = 10000 avro_to_hdfs.channels.c_102.byteCapacityBufferPercentage = 20 avro_to_hdfs.channels.c_102.byteCapacity = 10485760클러스터 에이전트 설정파일p.s. Flume 설정 파일은 변수 또는 외부 파일 include 등을 지원하지는 않아서, 위와 같이 반복되는 설정을 여러 번 써 주어야 합니다.호스트마다 CDH 알람 트리거 설정그리고 CDH 상에서도 웹서버 호스트의 개수만큼 알람 트리거를 만들어 줍니다. 초당 이벤트 개수가 0에 가깝게 떨어지면 알람이 오도록 해 주면 됩니다. 채널/싱크 중 어느 것을 기준으로 해도 크게 상관은 없는데, 저희는 싱크가 초당 이동완료한 이벤트 개수를 기준으로 했습니다.CDH에서의 알람 트리거 상태 화면이렇게 해 놓으면 또 한가지 좋은 점은, CDH가 알아서 차트를 그려 주기 때문에, 웹서버마다 트래픽 추이를 한눈에 볼 수 있다는 것입니다.HDFSSink의 초당 이벤트 개수 그래프맺음말지금까지 Apache Flume 과 CDH 를 사용해 로그 수집 시스템을 구성하고 모니터링을 설정한 후기를 살펴 보았습니다. 이 과정에서 느낀 점들을 한번 정리해 보겠습니다.첫째, 일견 간단해 보이는 기능이었지만 의외로 많은 시행착오를 거쳐야 했습니다. 아무리 간단해 보이더라도 각자의 상황에 맞추어 시스템을 설계하는 데에는 그에 맞는 고민을 거쳐야 합니다.둘째, 처음에는 로그가 일단 수집되게 하는 것이 가장 중요하다고 생각했는데, 실제로 겪어보니 모니터링이 훨씬 어렵고 중요한 문제라는 것을 알게 되었습니다. 어떤 기능이 일단 실행되도록 설정을 해 놓더라도, 그것이 매일 문제없이 실행됨을 보장받는 것은 또 다른 문제입니다.셋째, Health 페이지와 Pingdom을 이용한 웹서버 측의 모니터링은 JSON 리포팅의 문제 때문에 큰 쓸모가 없게 되었습니다. 하지만 꽤 유용한 테크닉이라는 생각이 들고, 어딘가에서는 비슷하게 이용할 수 있을 것 같습니다.마지막으로 CDH 쓰면 좋습니다. 많은 것들이 편해집니다.P.S. 리디북스 데이터팀에서는 이러한 로그 시스템을 함께 고민하고 만들어나갈 분들을 찾고 있습니다. 많은 관심 부탁드립니다.#리디북스 #개발 #서버 #서버개발 #모니터링 #로그 #Flume #CDH #로그수정 #인사이트

안녕하세요. 크몽 개발팀 입니다!   지난주에는 개발하기 전 개발환경 셋팅에 필요한 개발도구들을 소개해 드렸습니다.그러나 개발환경을 셋팅하기 전에 먼저 결정해야 할 것이 있습니다.바로 어떤 프로그래밍 언어로 개발을 할것인가 하는 문제 인데요~언어의 종류가 많고 사용하는 언어마다 특성이조금씩 다르기 때문에 결정하는 것이 어려울 때가 많습니다. 오늘은 다양한 종류의 언어 중에서 요즘 개발자 분들사이에서 화제가 되고 있는 'Swift(스위프트)'라는 언어를 소개해보려고 합니다.    2014년 6월 2일 미국 샌프란시스코 모스콘웨스트컨벤션센터에서 열린애플 WWDC(WorldWide Developers Conference)에서발표 마지막에 새로운 프로그래밍 언어 'Swift(스위프트)'를 공개했습니다.Swift는 C와 Objective-C의 중간에 있는 언어로서iOS와 OS X 기반의 애플리케이션 개발을 위한 언어입니다. 간단하게 장점들을 말씀드리면 고성능 앱을 개발 하기 위하여LLVM의 발전된 코드 분석기를 이용해 컴파일과 최적화를 수행합니다. 이 결과 Python 기준으로 오브젝트 정렬 속도는 3.9배,RC4 인크립션 처리속도는 220배나 빠른 처리속도를 가지고 있습니다. 그리고 현대적인 언어에서 지원하는 주요 기능들을 대거 흡수하고,Cocoa 및 Cocoa Touch frameworks의 모든 부분에서 접근이 가능합니다.또한 C와 Objective-C에서 써오던 기존 방식 또한 그대로 도입할 수있기 때문에 기존에 개발하던 업무에 지장을 주지 않습니다.   마지막으로  읽고 쓰기 쉬운 문법으로 코드를 작성하기 때문에유시보수 시 적은 양의 코드가 사용됩니다.그리고 소스를 코딩한 후 그 결과를 실시간으로 볼 수 있습니다. [출처] 애플 스위프트 언어 (Swift) - 앱 개발을 위한 애플의 새로운 언어|작성자 마스터 현재 9월에 애플에서 Swift 정식버전이 출시 되었고Swift로 작성된 애플리케이션의 iOS 앱스토어 승인도 시작되었습니다.또한 Xcode 6 시험판을 내려받아서 사용할수 있고,iTunes Store와 App Store를 통해 Swift 프로그래밍 언어 전자책을 다운받을 수 있다고 합니다.  개발된지 오래 되지 않아서 아직 Objective-C를 함께 사용하고있지만 쉽게 접근할 수 있는 언어이기 때문에점점 Swift를 사용하는 개발자 분들이 많아질 것으로 보입니다 ^^ 이상 포스트를 마치겠습니다. #크몽 #개발팀 #신입개발자 #신입사원 #경험공유