스토리 홈

인터뷰

피드

뉴스

조회수 2369

CloudWatch에 대하여

OverviewAmazon Web Services(AWS)는 많은 고객들이 이용하고 있습니다. AWS를 이용하여 프로젝트를 운영하고 있다면 각종 서비스의 리소스를 모니터링 하는 게 귀찮게 느껴질 수 있습니다. 이번 글에서는 AWS 리소스를 효과적으로 모니터링할 수 있는 Cloudwatch 서비스를 소개하겠습니다.Cloudwatch는 통합 뷰를 확보하는데 필요한 데이터를 제공합니다. 뿐만 아니라 이벤트 및 리소스를 이용해 경보를 생성할 수도 있습니다.1. Events2. Logs3. Custom Metrics(맞춤형 지표) 생성하기4. Alarm 생성5. Dashboards쉬어가기: Query 언어가 지원하는 여섯 가지 명령 유형1. EventsCloudWatch Events는 정기적인 일정에서 트리거(trigger)되는 규칙을 생성할 수 있습니다.1.규칙 생성을 클릭합니다.2.대상을 호출할 일정을 설정합니다.호출 방식에는 이벤트 패턴과 일정 두 가지가 있습니다. 이벤트 패턴은 json 구조로 표현됩니다. AWS 서비스에서 발생하는 패턴과 일치하면 트리거가 동작합니다. 일정은 지정한 시간과 일치하면 트리거가 동작합니다.cron 또는 rate 표현식을 사용해 예약된 모든 이벤트는 UTC+09:00 시간대를 사용합니다. 최초 단위는 1분입니다.아래는 각각의 필드에 대한 일정 cron식 설명입니다.이번 예제에서는 특정 시간에 트리거되는 일정으로 설정하겠습니다.매일 4시에 동작하도록 설정19 + 9(UTC) - 24(하루) = 새벽 4시3.대상 추가를 선택해 호출할 대상을 지정합니다.Lambda 함수 외에 여러 서비스를 선택할 수 있지만 이번 예제에서는 Lambda 함수를 지정하여 구성하겠습니다.4.규칙의 이름과 설명을 등록하고 규칙 생성을 클릭합니다.5.규칙이 생성된 것을 볼 수 있습니다.2. LogsCloudWatch Logs는 운영 중인 애플리케이션 리소스를 기록하고 액세스할 수 있으며, 관련된 로그 데이터를 검색할 수도 있습니다.1.생성된 규칙이 지정된 시간에 동작하면 CloudWatch Logs에 로그 그룹이 생성된 걸 확인할 수 있습니다.2.Lambda 함수에서 실행된 로그 메시지를 확인할 수 있으며 필터링도 가능합니다.3.로그 그룹에 이벤트 만료 시점을 설정해 오래된 데이터는 모두 자동으로 삭제되도록 설정할 수 있습니다.3. Custom Metrics(맞춤형 지표) 생성하기모니터링하고자 하는 통계치를 직접 선정하고, CloudWatch로 보내 관리하는 지표를 생성해보겠습니다.1.Log Groups에 대한 지표를 생성하겠습니다. 해당 Log Groups에 ‘Filters’를 클릭합니다.2.’Add Metric Filter’를 클릭합니다.3.로그 지표에 대한 필터 패턴을 정의합니다.Filter Pattern* “INFO Success 200” → 세 단어를 모두 포함하는 로그 이벤트 메시지와 일치* “INFO - Start - End” → ‘INFO’ 포함된 메시지 중에 ‘Start’, ‘End’ 제외된 필터 로그 이벤트 메시지와 일치4.필터 및 지표 정보를 입력한 후 ‘Create Filter’를 클릭합니다.Metric Details* Metric Namespace → CloudWatch 지표에 대한 대상 네임 스페이스* Metric Name → 모니터링된 로그 정보가 게시되는 CloudWatch 지표의 이름* Metric Value → 일치하는 로그가 발견될 때마다 지표에 게시하는 숫자 값* Default Value → 일치하는 로그가 발견되지 않은 기간 동안 지표 필터에 보고되는 값5.두 가지 케이스의 필터를 생성했습니다.4. Alarm 생성단일 CloudWatch 지표를 감시하거나 CloudWatch 측정치를 기반으로 하는 수학 표현식의 결과를 감시하는 CloudWatch 경보를 생성할 수 있습니다. 지표가 지정된 임계값에 도달하면 자동으로 이메일을 보내는 Alarm을 만들어보겠습니다.1.추가된 지표 필터에 ‘Create Alarm’ 버튼을 클릭해 경보를 추가합니다.2.경보 세부 정보 및 수행할 작업을 정의합니다.경보 평가경보를 생성할 때, CloudWatch가 경보 상태를 변경하는 조건 세 가지에 대한 설정을 지정할 수 있습니다.기간은 경보에 대해 개별 데이터 포인트를 생성하기 위해 지표 또는 표현식을 평가하는 기간입니다. 초로 표시됩니다. 1분을 기간으로 선택하면 1분마다 하나의 데이터 포인트가 생성됩니다.Evaluation Period(평가 기간)는 경보 상태를 결정할 때 평가할 가장 최근의 기간 또는 데이터 포인트의 수입니다.Datapoints to Alarm(경보에 대한 데이터포인트)는 평가 기간에 경보가 ALARM상태에 도달하게 만드는 위반 데이터 포인트의 수입니다. 위반 데이터 포인트가 연속적일 필요는 없습니다. Evaluation Period(평가 기간)와 동일한 마지막 데이터 포인트의 수 이내면 됩니다.3.경보가 발생할 Alarm 상태와 알림 받을 이메일을 등록합니다.경보 상태/OK/ 지표 또는 표현식이 정의된 임계값 내에 있습니다./ALARM/ 지표 또는 표현식이 정의된 임계값을 벗어났습니다./INSUFFICIENT_DATA/ 경보가 방금 시작되었거나, 측정치를 사용할 수 없거나, 또는 측정치를 통해 경보 상태를 결정하는데 사용할 충분한 데이터가 없습니다.4.이메일 수신함에서 ‘AWS 알림 - 구독 확인’이라는 제목의 메일을 클릭합니다. 내용에 포함된 링크를 클릭해 알림을 수신할 것을 확인합니다. (AWS는 확인된 주소로만 알림을 전송할 수 있습니다.)5.이메일 수신함을 확인해 ‘Confirm subscription’을 클릭합니다.6.등록한 이메일이 확인되었습니다.7.AWS에 이메일이 정상적으로 등록되었는지 SNS Subscriptions 메뉴에서 확인합니다.8.Lambda를 실행해 Alarm 상태를 변경해보겠습니다.9.등록한 이메일 주소로 Alarm 메일이 도착했습니다.5. DashboardsCloudWatch를 통해 리소스를 손쉽게 모니터링할 수 있는 맞춤형 통계 기능입니다.1.Metric Filter에서 추가된 Custom Namespaces를 클릭합니다.2.생성된 Metrics를 선택한 후, Graphed metrics Tab을 클릭합니다.3.Metrics에 표시될 그래프를 설정합니다.1)그래프 제목 : testLambda12)그래프 표시 : 숫자3)그래프 라벨 : testMetrics-400, testMetrics-2004)통계 : 합계5)기간 : 1 Day4.수식을 응용하여 여러 형식의 Metrics 표현식을 추가하겠습니다.지표 수식 함수* METRICS() : 요청에 모든 지표를 반환* SUM(METRICS()) : 모든 지표의 합계* AVG(METRICS()) : 모든 지표의 평균* MIN(METRICS()) : 모든 지표의 최소값* MAX(METRICS()) : 모든 지표의 최대값* ABS(METRICS()) : 각 요소의 절대값* RATE(METRICS()) : 각 요소의 초당 변경 비율5.완성된 지표 Source를 복사합니다.{ "metrics": [ [ { "expression": "SUM(METRICS())", "label": "합계", "id": "e1", "stat": "Sum", "period": 86400 } ], [ { "expression": "AVG(METRICS())", "label": "평균", "id": "e2", "stat": "Sum", "period": 86400 } ], [ { "expression": "MIN(METRICS())", "label": "최소값", "id": "e3", "stat": "Sum", "period": 86400 } ], [ { "expression": "MAX(METRICS())", "label": "최대값", "id": "e4", "stat": "Sum", "period": 86400 } ], [ { "expression": "SUM(METRICS())/SUM(m1)", "label": "SUM(METRICS())/SUM(m1)", "id": "e5", "stat": "Sum", "period": 86400 } ], [ { "expression": "SUM(100/[m1, m2])", "label": "SUM(100/[m1, m2])", "id": "e6", "stat": "Sum", "period": 86400 } ], [ "testMetrics", "testMetrics1", { "id": "m1", "stat": "Sum", "period": 86400, "label": "testMetrics-400" } ], [ ".", "testMetrics2", { "id": "m2", "stat": "Sum", "period": 86400, "label": "testMetrics-200" } ] ], "view": "singleValue", "stacked": false, "region": "ap-northeast-1", "title": "testLambda1", "period": 300 } 6.Dashboard name을 입력한 후 ‘Create dashboard’를 클릭합니다.7.’Add widget’을 클릭해 Number 유형을 선택합니다.8.Source Tab에서 복사해 둔 지표 Source를 붙여 넣고, ‘Create widget’을 클릭합니다.9.위젯이 추가되었습니다. 추가된 위젯은 ‘Save dashboard’ 버튼을 클릭해야 최종 저장됩니다.10.이번에는 로그 메시지 결과를 확인할 수 있는 Query result 유형을 추가해보겠습니다. 먼저 Query result 유형을 선택합니다.11.로그 메시지에 조건을 추가해 필터링합니다.잠시 쉬어가기!: Query 언어가 지원하는 여섯 가지 명령 유형fields : 지정한 필드를 검색합니다. 필드 명령 내에서 함수 및 연산을 사용할 수 있습니다. 만약 @ 기호, 마침표(.) 및 영숫자 문자 이외의 문자가 포함된 로그 필드가 쿼리에 명명되어 있으면 해당 필드 이름은 억음 기호로 둘러싸야 합니다.filter : 하나 이상의 조건으로 필터링합니다. filter statusCode like /2\d\d/ → 필드 statusCode의 값이 200~299인 로그 이벤트를 반환합니다.stats : 로그 필드에 대한 지정된 시간 간격의 집계 통계를 계산합니다.sort : 검색된 로그 이벤트를 정렬합니다.limit : 쿼리에서 반환되는 로그 이벤트 수를 제한합니다.parse : 로그 필드에서 데이터를 추출하고 쿼리로 추가 처리할 수 있는 임시 필드가 하나 이상 생성됩니다.12.추가된 위젯은 이름과 사이즈를 조절한 후, ‘Save dashboard’ 버튼을 클릭해 최종 저장합니다.13.생성한 Alarm을 Dashboard에 추가하겠습니다.14.Dashboard가 완성되었습니다!Conclusion지금까지 CloudWatch 서비스를 소개했습니다. 이 서비스를 이용하면 로그와 지표를 쉽게 시각화할 수 있고, 작업을 자동화할 수도 있는 것을 확인했습니다. CloudWatch를 이용해 애플리케이션을 최적화하고, 원활하게 실행해보는 건 어떨까요. 분명 리소스를 효과적으로 다룰 수 있을 겁니다.글곽정섭 과장 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만
조회수 3162

Apache Spark에서 컬럼 기반 저장 포맷 Parquet(파케이) 제대로 활용하기 - VCNC Engineering Blog

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 모두 많은 사람이 사랑하는 훌륭한 오픈소스 프로젝트입니다. 또한 별다른 설정이나 튜닝 없이 기본 설정만으로도 잘 돌아가는 편이기 때문에 더더욱 많은 사람이 애용하는 프로젝트이기도 합니다.하지만 오픈소스는 완전하지 않습니다. 좋은 엔지니어링 팀이라면 단지 남들이 많이 쓰는 오픈소스 프로젝트들을 조합해서 사용하는 것에서 그치지 않고 핵심 원리와 내부 구조를 연구해가며 올바르게 활용해야 한다고 생각합니다. 기술의 올바른 활용을 위해 비트윈 데이터팀은 오늘도 노력하고 있습니다.
조회수 1545

블로그 운영 방법에서 엿보는 VCNC의 개발문화 - VCNC Engineering Blog

 VCNC에서 엔지니어링 블로그를 시작하고 벌써 새로운 해를 맞이하였습니다. 그동안 여러 글을 통해 VCNC 개발팀의 이야기를 들려드렸습니다. 이번에는 엔지니어링 블로그 자체를 주제로 글을 적어보고자 합니다. 저희는 워드프레스나 텀블러와 같은 일반적인 블로깅 도구나 서비스를 사용하지 않고 조금은 개발자스럽다고 할 수 있는 특이한 방법으로 엔지니어링 블로그를 운영하고 있습니다. 이 글에서는 VCNC 개발팀이 엔지니어링 블로그를 운영하기 위해 이용하는 방법들을 소개하고자 합니다. 그리고 블로그를 운영하기 위해 방법을 다루는 중간중간에 개발팀의 문화와 일하는 방식들에 대해서도 간략하게나마 이야기해보고자 합니다.블로그에 사용하는 기술들Jekyll: Jekyll은 블로그에 특화된 정적 사이트 생성기입니다. GitHub의 Co-founder 중 한 명인 Tom Preston-Werner가 만들었으며 Ruby로 작성되어 있습니다. Markdown을 이용하여 글을 작성하면 Liquid 템플릿 엔진을 통해 정적인 HTML 파일들을 만들어 줍니다. VCNC 엔지니어링 블로그는 워드프레스같은 블로깅 도구를 사용하지 않고 Jekyll을 사용하고 있습니다.Bootstrap: 블로그 테마는 트위터에서 만든 프론트엔드 프레임워크인 Bootstrap을 이용하여 직접 작성되었습니다. Bootstrap에서 제공하는 다양한 기능들을 가져다 써서 블로그를 쉽게 만들기 위해 이용하였습니다. 덕분에 큰 공을 들이지 않고도 Responsive Web Design을 적용할 수 있었습니다.S3: S3는 AWS에서 제공되는 클라우드 스토리지 서비스로서 높은 가용성을 보장합니다. 일반적으로 파일을 저장하는 데 사용되지만, 정적인 HTML을 업로드하여 사이트를 호스팅하는데 사용할 수도 있습니다. 아마존의 CTO인 Werner Vogels 또한 자신의 블로그를 S3에서 호스팅하고 있습니다. VCNC Engineering Blog도 Jekyll로 만들어진 HTML 파일들을 아마존의 S3에 업로드 하여 운영됩니다. 일단 S3에 올려두면 운영적인 부분에 대한 부담이 많이 사라지기 때문에 S3에 올리기로 하였습니다.CloudFront: 브라우저에서 웹페이지가 보이는 속도를 빠르게 하려고 아마존의 CDN서비스인 CloudFront를 이용합니다. CDN을 이용하면 HTML파일들이 전 세계 곳곳에 있는 Edge 서버에 캐싱 되어 방문자들이 가장 가까운 Edge를 통해 사이트를 로딩하도록 할 수 있습니다. 특히 CloudFront에 한국 Edge가 생긴 이후에는 한국에서의 응답속도가 매우 좋아졌습니다.s3cmd: s3cmd는 S3를 위한 커맨드 라인 도구입니다. 파일들을 업로드하거나 다운로드 받는 등 S3를 위해 다양한 명령어를 제공합니다. 저희는 블로그 글을 s3로 업로드하여 배포하기 위해 s3cmd를 사용합니다. 배포 스크립트를 실행하는 것만으로 s3업로드와 CloudFront invalidation이 자동으로 이루어지므로 배포 비용을 크게 줄일 수 있었습니다.htmlcompressor: 정적 파일들이나 블로그 글 페이지들을 s3에 배포할 때에는 whitespace 등을 제거하기 위해 htmlcompressor를 사용합니다. 또한 Google Closure Compiler를 이용하여 javascript의 길이도 줄이고 있습니다. 실제로 서버가 내려줘야 할 데이터의 크기가 줄어들게 되므로 로딩속도를 조금 더 빠르게 할 수 있습니다.블로그 관리 방법앞서 소개해 드린 기술들 외에도 블로그 글을 관리하기 위해 다소 독특한 방법을 사용합니다. 개발팀의 여러 팀원이 블로그에 올릴 주제를 결정하고 서로의 의견을 교환하기 위해 여러 가지 도구를 이용하는데 이를 소개하고자 합니다. 이 도구들은 개발팀이 일할 때에도 활용되고 있습니다.글감 관리를 위해 JIRA를 사용하다.JIRA는 Atlassian에서 만든 이슈 관리 및 프로젝트 관리 도구입니다. VCNC 개발팀에서는 비트윈과 관련된 다양한 프로젝트들의 이슈 관리를 위해 JIRA를 적극적으로 활용하고 있습니다. 제품에 대한 요구사항이 생기면 일단 백로그에 넣어 두고, 3주에 한 번씩 있는 스프린트 회의에서 요구사항에 대한 우선순위를 결정합니다. 그 후 개발자가 직접 개발 기간을 산정한 후에, 스프린트에 포함할지를 결정합니다. 이렇게 개발팀이 개발에 집중할 수 있는 환경을 가질 수 있도록 하며, 제품의 전체적인 방향성을 잃지 않고 모두가 같은 방향을 향해 달릴 수 있도록 하고 있습니다.VCNC 개발팀이 스프린트에 등록된 이슈를 얼마나 빨리 해결해 나가고 있는지 보여주는 JIRA의 차트.조금만 생각해보시면 어느 부분이 스프린트의 시작이고 어느 부분이 끝 부분인지 아실 수 있습니다.위와 같은 프로젝트 관리를 위한 일반적인 용도 외에도 엔지니어링 블로그 글 관리를 위해 JIRA를 사용하고 있습니다. JIRA에 엔지니어링 블로그 글감을 위한 프로젝트를 만들어 두고 블로그 글에 대한 아이디어가 생각나면 이슈로 등록할 수 있게 하고 있습니다. 누구나 글감 이슈를 등록할 수 있으며 필요한 경우에는 다른 사람에게 글감 이슈를 할당할 수도 있습니다. 일단 글감이 등록되면 엔지니어링 블로그에 쓰면 좋을지 어떤 내용이 포함되면 좋을지 댓글을 통해 토론하기도 합니다. 글을 작성하기 시작하면 해당 이슈를 진행 중으로 바꾸고, 리뷰 후, 글이 발행되면 이슈를 해결한 것으로 표시하는 식으로 JIRA를 이용합니다. 누구나 글감을 제안할 수 있게 하고, 이에 대해 팀원들과 토론을 하여 더 좋은 글을 쓸 수 있도록 돕기 위해 JIRA를 활용하고 있습니다.JIRA에 등록된 블로그 글 주제들 중 아직 쓰여지지 않은 것들을 보여주는 이슈들.아직 제안 단계인 것도 있지만, 많은 주제들이 블로그 글로 발행되길 기다리고 있습니다.글 리뷰를 위해 Pull-request를 이용하다.Stash는 Attlassian에서 만든 Git저장소 관리 도구입니다. GitHub Enterprise와 유사한 기능들을 제공합니다. Jekyll로 블로그를 운영하는 경우 이미지를 제외한 대부분 콘텐츠는 평문(Plain text)으로 관리 할 수 있게 됩니다. 따라서 VCNC 개발팀이 가장 자주 사용하는 도구 중 하나인 Git을 이용하면 별다른 시스템의 도움 없이도 모든 변경 내역과 누가 변경을 했는지 이력을 완벽하게 보존할 수 있습니다. 저희는 이런 이유로 Git을 이용하여 작성된 글에 대한 변경 이력을 관리하고 있습니다.또한 Stash에서는 GitHub와 같은 Pull request 기능을 제공합니다. Pull request는 자신이 작성한 코드를 다른 사람에게 리뷰하고 메인 브랜치에 머지해 달라고 요청할 수 있는 기능입니다. 저희는 Pull request를 활용하여 상호간 코드 리뷰를 하고 있습니다. 코드 리뷰를 통해 실수를 줄이고 개발자 간 의견 교환을 통해 더 좋은 코드를 작성하며 서로 간 코드에 대해 더 잘 이해하도록 노력하고 있습니다. 새로운 개발자가 코드를 상세히 모른다 해도 좀 더 적극적으로 코드를 짤 수 있고, 업무에 더 빨리 적응하는데에도 도움이 됩니다.어떤 블로그 글에 대해 리뷰를 하면서 코멘트로 의견을 교환하고 있습니다.코드 리뷰 또한 비슷한 방법을 통해 이루어지고 있습니다.업무상 코드 리뷰 뿐만 아니라 새로운 블로그 글을 리뷰하기 위해 Pull request를 활용하고 있습니다. 어떤 개발자가 글을 작성하기 위해서 가장 먼저 하는 것은 블로그를 관리하는 Git 리포지터리에서 새로운 브랜치를 따는 것입니다. 해당 브랜치에서 글을 작성하고 작성한 후에는 새로운 글 내용을 push한 후 master 브랜치로 Pull request를 날립니다. 이때 리뷰어로 등록된 사람과 그 외 개발자들은 내용에 대한 의견이나 첨삭을 댓글로 달 수 있습니다. 충분한 리뷰를 통해 발행이 확정된 글은 블로그 관리자에 의해 master 브랜치에 머지 되고 비로소 발행 준비가 끝납니다.스크립트를 통한 블로그 글 발행 자동화와 보안준비가 끝난 새로운 블로그 글을 발행하기 위해서는 일련의 작업이 필요합니다. Jekyll을 이용해 정적 파일들을 만든 후, htmlcompressor 통해 정적 파일들을 압축해야 합니다. 이렇게 압축된 정적 파일들을 S3에 업로드 하고, CloudFront에 Invalidation 요청을 날리고, 구글 웹 마스터 도구에 핑을 날립니다. 이런 과정들을 s3cmd와 Rakefile을 이용하여 스크립트를 실행하는 것만으로 자동으로 이루어지도록 하였습니다. VCNC 개발팀은 여러 가지 업무 들을 자동화시키기 위해 노력하고 있습니다.또한, s3에 사용하는 AWS Credential은 IAM을 이용하여 블로그를 호스팅하는 s3 버킷과 CloudFront에 대한 접근 권한만 있는 키를 발급하여 사용하고 있습니다. 비트윈은 특히 커플들이 사용하는 서비스라 보안에 민감합니다. 실제 비트윈을 개발하는데에도 보안에 많은 신경을 쓰고 있으며, 이런 점은 엔지니어링 블로그 운영하는데에도 묻어나오고 있습니다.맺음말VCNC 개발팀은 엔지니어링 블로그를 관리하고 운영하기 위해 다소 독특한 방법을 사용합니다. 이 방법은 개발팀이 일하는 방법과 문화에서 큰 영향을 받았습니다. JIRA를 통한 이슈 관리 및 스프린트, Pull request를 이용한 상호간 코드 리뷰 등은 이제 VCNC 개발팀의 문화에 녹아들어 가장 효율적으로 일할 수 있는 방법이 되었습니다. 개발팀을 꾸려나가면서 여러가지 시행 착오를 겪어 왔지만, 시행 착오에 대한 반성과 여러가지 개선 시도를 통해 계속해서 더 좋은 방법을 찾아나가며 지금과 같은 개발 문화가 만들어졌습니다. 그동안 그래 왔듯이 앞으로 더 많은 개선을 통해 꾸준히 좋은 방법을 찾아 나갈 것입니다.네 그렇습니다. 결론은 저희와 함께 고민하면서 더 좋은 개발문화를 만들어나갈 개발자를 구하고 있다는 것입니다.
조회수 444

컴공생의 AI 스쿨 필기 노트 ⑦합성곱 신경망

안녕하세요! 이번 주 수업에서는 합성곱 신경망에 대해서 배웠어요. 제가 읽은 한 기사에 의하면 대장 내시경 검사에도 딥러닝을 이용하면 종양 식별 능력을 더 높일 수 있다고 해요. 딥러닝을 이용한 검사는 전문가 분석을 통한 대장 내시경 검사보다 종양을 9개 더 많이 발견했고 진단 정확도는 96%인 것으로 나타났어요. (원문 링크) 이 대장 내시경에 우리가 배운 CNN(Convolutional Neural Network), 이미지 기반 딥러닝 모델을 사용했다고 하는데요. 이 대장 내시경에 사용된 CNN에 대해 알아볼까요? (Cover image : Photo by Paul Carmona on Unsplash)CNN(Convolutional Neural Network, 합성곱 신경망) CNN(합성곱 신경망)은 Convolution(합성곱)연산을 사용하는 인공신경망의 한 종류에요. 합성곱 신경망은 주로 이미지 데이터를 다루는 문제에서 사용돼요. 쉽게 말해 합성곱 신경망은 이미지의 특징을 추출하고 잘 조합하여 문제를 해결하는데요.  예를 들어 왼쪽 이미지가 고양이인지 컴퓨터가 알아맞히기 위해서 합성곱 신경망은 고양이가 가져야 할 특징을 한 번에 파악하는 것이 아니라 부분부분 판단하여 종합적으로 결론을 내요. 합성곱 신경망은 사진에 고양이의 특징이 기묘하게 분포되어 있어도 정확하게 고양이의 특징을 찾아내는 높은 적응도를 갖고 있어요.이제 합성곱 신경망의 구조에 대해 알아볼까요?CNN의 네트워크 구조1. 합성곱 층 (Convolutional Layer)합성곱은 두 함수 중 하나를 반전하고 이동시켜가며 다른 하나의 함수와 곱한 결과를 적분해나간다는 아주 어려운 뜻을 가지고 있어요. 다음 예시를 보도록 할게요.여기에 2차원 배열 픽셀을 넣으면 X 인지 O 인지 알아내는 합성곱 신경망이 있다고 해봐요.이 합성곱 신경망은 똑바로 된 X와 O를 넣으면 X 인지 O 인지 정확하게 구분하는데,이렇게 크기가 바뀌고 회전되어 모양이 변형된 이미지를 보고도 X 인지 O 인지 정확히 구분할 수 있을까요?합성곱 신경망은 합성곱 신경을 이용하여 이미지의 특징을 매칭 시킨 결과가 같으면 같은 이미지라고 인식해요.‘X’ 이미지의 특징을 추출하면 위와 같은 매트릭스, 합성곱 필터(Convolution filter(=커널))가 나와요. (세 특징을 잘 조합하면 X 형태가 나오죠?)이제 제일 왼쪽의 합성곱 필터를 가지고서 이미지가 X 인지 알아볼게요. 합성곱 필터와 원본 이미지를 비교할 때는 곱셈을 이용해요. 합성곱 필터의 크기만큼 원본 이미지와 차례차례 곱해서 값을 채워나가요.위의 합성곱 정의에서 두 함수를 하나는 이미지, 또 하나는 필터라고 생각하면, 필터를 이동시켜가며 이미지와 곱한 결과를 적분 즉, 덧셈해 나간다는 뜻이 돼요.합성곱 필터의 크기만큼 값을 다 계산한 후, 계산한 원소를 다 더해서 합성곱 필터의 크기만큼 나눈 평균값을 또 다른 새 매트릭스에 채우게 되는데 이를 특징 맵(Feature map)이라고 불러요. 즉, 특징 맵은 기존의 이미지에 필터를 곱한 결과로 각 픽셀에 쓰여있는 값이 클수록 그 특징을 가지고 있다는 뜻이에요.이렇게 원본 이미지와 합성곱 필터의 곱한 결과로 특징 맵이 나왔어요.나머지 두 개의 합성곱 필터와 곱한 결과로 두 개의 특징 맵을 가질 수 있어요.한 개의 합성곱 층(Convolutional layer)에는 여러 개의 합성곱 필터가 있어요. 합성곱 층에서 기존의 이미지와 필터들을 합성곱한 결과, 처음 이미지는 필터 된 이미지(특징 맵)로 쌓이게 돼요.2. 풀링 층(Pooling Layer)풀링은 가로/세로 방향의 공간을 줄이는 연산으로 합성곱 층의 특징을 압축한 특징 맵을 형성해요. 풀링에는 최대 풀링(Max pooling)과 평균 풀링(Average pooling)이 있는데 이미지 인식 분야에서 주로 사용하는 것은 최대 풀링이에요. 그래서 보통 풀링이라고 하면 최대 풀링이라는 의미로 사용한다고 보시면 돼요.위의 예시는 2x2 최대 풀링을 적용한 예시에요. 아까 구한 특징 맵에서 2x2 픽셀에서 가장 큰 원소 값을 새로운 맵을 채워나가는데 이를 활성화 맵(Activation map)이라고 불러요. 최대 풀링을 사용하면 노이즈가 감소하고 속도도 빨라지며 영상의 분별력이 좋아진다고 해요. 마지막 출력 층은 최대 풀링의 모든 뉴런과 연결되어 출력값이 어떤 클래스에 해당하는지 파악되는데 사용돼요.이렇게 CNN을 이용하면 변형된 이미지라고 하더라도 원래 이미지의 특징을 가지고 있다면 정확히 구분할 수 있어요.코드로 연습해보기아래는 간단한 인공신경망 코드예요.Layer 1 - input:1x28x28 , output : 64x28x28 + Activation function - reluLayer 2 - input: 64x28x28 output:1x28x28Layer 3 - input: 1x28x28=784 output:10class MNIST_Net(nn.Module):    def __init__(self):        super(MNIST_Net, self).__init__() # nn.Module 생성자 호출         # an affine operation: y = Wx + b        layers = []        layers.append(nn.Conv2d(1,64,3,1,1))         layers.append(nn.ReLU())         layers.append(nn.Conv2d(64,1,3,1,1))         layers.append(nn.ReLU())         self.main = nn.Sequential(*layers)        self.fc = nn.Linear(28*28, 10)    def forward(self, x):        # x.view함수는 주어진 인자의 크기로 해당 데이터의 크기를 반환합니다. 즉, (Batch_size,1,28,28) --> (Batch_size,28*28)로 변환합니다.        x = self.main(x)        x = x.squeeze().view(-1, 28*28)        x = self.fc(x)  # 10 으로 10개의 Class에 대한 logit 값을 호출합니다.         return x합성곱 인공 신경망의 내용은 정말 배울 것이 많아서 수업 시간 내에 다 배우기가 조금 벅찼지만 다른 인공 신경망에 비해 재밌어서 집중할 수 있었어요. 이제 앞으로 1번의 이론수업만을 남겨두고 있어서 아쉽기도 하고 또 뿌듯하기도 해요. 앞으로 조원들과 함께 프로젝트를 진행하면서 지금까지 배운 이론을 적용해보게 되는데요. 프로젝트 주제를 정하는 것부터 벌써 쉽지가 않아요. 하지만 열심히 프로젝트를 해서 리쿠르팅 데이 때 실력을 뽐낼 수 있다면 좋겠네요!* 이 글은 AI스쿨 - 인공지능 R&D 실무자 양성과정 7회차 수업에 대해 수강생 최유진님이 작성하신 수업 후기입니다.
조회수 1276

크로키닷컴을 소개합니다 #4

오랜만에 돌아온 크로키닷컴 인터뷰!요즘 채용이 활발하게 진행 중인 크로키닷컴의 [프론트엔드 개발자] 에 관해 궁금해하시는 분들을 위해, Dev.팀에서 근무하고 있는 프론트엔드 개발자 두 분! 영준님, 케빈님을 모셨습니다.Chapter 1. 저를 소개합니다!Q. 영준님, 케빈님 반갑습니다! 간단하게 자기소개 부탁드릴게요.영준 저는 프론트엔드 개발자 김영준이고요, 지그재그의 또 다른 신사업 서비스를 만들어가고 있습니다. 프론트엔드 개발은 5년 정도 했고, 요즘은 신사업 서비스에 새로운 기능이 들어갈 예정이라 그 작업을 열심히 하고 있습니다! 참, 원래 저는 공대 출신은 아니고 디자인과를 졸업했어요.(우와.. 디자이너에서 개발자로 전향하신 특별한 계기가 있으셨나요?)그때 당시 어도비 플래시가 잘 되던 시기였는데, 플래시가 좋아서 그쪽 수업을 많이 들었거든요. 그때부터 관심을 갖게 돼서 첫 회사에는 플래시 개발자로 입사했었어요. 이후에 플래시 사용률이 점차 줄어들면서 프론트엔드 개발 쪽으로 전향하게 되었습니다.케빈 어.. 제 본명은 성훈이고요.(웃음) 저는 원래 풀스택 개발자로 2년 정도 일을 했었어요. 본격적으로 프론트엔드 쪽으로 전향한 지 2년 정도 된 것 같아요. 저도 영준님이랑 비슷하게 공대는 아니고 영상그래픽을 전공했어요. 3D나 특수효과 같은 거? 교양수업으로 HTML 수업을 듣다가 개발에 관심이 생겨서 시작하게 됐습니다!(그렇군요! 케빈님 곧 있으면 입사 100일을 맞이하시게 되는데 소감이 어떠신가요?)프론트엔드 포지션에 온전히 집중해서 일을 해본 건 처음이에요. 이전에 바라 왔던 업무환경에 많이 근접한 것 같고 점차 적응 중에 있습니다.Q. 어떠한 연말을 보내고 계신가요?영준 어! 저 얘기할 거 있어요. 얼마 전부터 회사에서 전세자금 대출 이자를 지원해주기 시작한 덕분에 난생처음으로 독립을 하게 됐거든요. 이자를 지원받게 되니 집도 더 잘 구하게 된 것 같아요! 그래서 요즘은 자취 초년생으로서 이것저것 해보고 있어요. 요리도 해보고 그동안 해보고 싶었던 것들? 하지만 집에서 부모님이 해주시는 게 얼마나 감사한 지도 알게 됐어요. (그래도 다시 돌아가긴 싫으시겠죠?)영준 네, 독립해서 진짜 좋아요. 그래서 요즘 일하는 시간 외에는 인테리어 고민을 많이 하고 있어요. 지금 집에는 아무것도 없거든요. 곧 영준님만의 감성으로 채워질 집!케빈 아.. 저는 딱히 뭐가 없는데..영준 아 아직 입양 안 받았어요?케빈 아! 맞아요. 제가 동물을 입양하려고 준비하고 있어요. 그 동물에 대해서 공부 먼저 하고 제대로 알게 된 다음 입양하려고요. (입양이요? 강아지? 고양이?!) 케빈 페럿이라고 아세요? 페럿을 입양하려고 공부하고 있어요. 돈도 많이 든다고 해서 모으고 있기도 하고요. 그것 빼고는 하는 게 없어요 아직.키우는 분이 별로 없는 희귀한 동물, 페럿! 애교가 많은 동물이라고 하네요 :-)Chapter 2. 직잭러가 되어가는 과정Q. 지그재그로 이직하고 싶었던 특별한 계기나 이유가 있었나요?영준 이직할 때 개발자로서 성장이 가능한 회사를 찾으려고 했어요. 이전 회사가 에이전시이다 보니 코드 리뷰 문화가 없었거든요. 코드 리뷰는 프로덕트에도 좋은 영향을 끼치지만 개발자 개개인의 성장에 더 영향을 많이 끼친다고 생각했거든요.(실제로 겪어본 이후로는 확신합니다!)프로덕트에 대한 이해를 높이는 것은 물론 양질의 코드를 실컷 볼 수 있고, 또 어느 코드 하나 허투루 작성할 수 없어요. 그래서 꼭 코드 리뷰가 있는 회사로 가려고 했는데, 지그재그가 딱 그랬습니다!케빈 저도 코드 리뷰 문화에 한 표! 저는 프론트엔드 분야에서는 늦게 공부를 시작했기 때문에 배울 수 있는 환경이 매우 중요하다고 생각했거든요. 아 그리고 저는 이직을 고려할 때, 그 회사에 대해서 미리 프레스나 github을 다 찾아보는데, 그러다 보면 이 회사는 '이렇게 근무를 하는구나'가 어느 정도 보이더라고요. 근데 지그재그 팀을 찾아보면서 여기서 꼭 같이 일해보고 싶다고 생각했어요. 찾아보시면 지그재그 개발 문화와 관련된 소스코드나 오픈소스 프로젝트가 공개되어 있는데요, 왜 이런 코드를 썼고 이런 규칙을 정했는지 오픈해두고 같이 생각해볼 수 있게끔 되어 있어요.영준 저는 기술 블로그도 재밌게 봤어요.케빈 맞아요. 특히 주니어의 입장에서는 발전에 대한 욕망이라고 해야 하나?(웃음) 욕심이 클 수밖에 없는데 기술 블로그가 지그재그 팀에 대한 궁금증을 풀어주는데 많은 도움이 됐어요.나름 활발한 (?) 지그재그 기술 블로그에도 놀러 오세요! https://devblog.croquis.com/ko/Q. 입사 전 인터뷰 때 가장 인상 깊었던 질문이나 에피소드가 있으신가요?영준 일단 면접 절차 진행이 너무 친절해서 당시 기억이 엄청 좋았어요. 또 정해진 질문지에 대한 뻔한 대답보다, 저에게 fit된 인터뷰를 진행했던 것도 좋았고요. 전 회사에서는 인터렉션 관련된 작업을 많이 했었는데, 쟈니님(CEO)이 인터렉션이 프로덕트에 어떤 도움을 줄 수 있을까에 대한 질문이 되게 참신하고 좋게 다가왔습니다. 물론 제가 답한 것 들 이외에도 어떤 영향을 끼칠 수 있는지 말해주어서 더 좋았어요! 아, 재밌는 에피소드가 하나 있는데.. 쟈니님이 '영준님은 친구들 사이에서 어떤 사람이에요?'라고 질문을 하셔서 '먹는 것 좋아하는 사람이요.'라고 대답했더니, 쟈니님이 '그럼 안 되겠네요. 저희는 밥을 다 사드리기 때문에 영준님이 오시면 거덜 날 것 같아요'라고 하셨어요.(빅웃음) 쟈니님은 워낙 장난이 많으신 분이라 재밌었어요.케빈 저는 2차 인터뷰 때 엄청 떨었어요. 그래서 어떤 질문이 나왔고 어떻게 대답을 했었는지 하나도 기억이 안 나네요. 입사 후 수습기간이 끝나갈 즈음에 쟈니님과 미팅을 한 번 더 했었는데, 쟈니님이 제가 인터뷰 때 떨었던 것과는 너무 다르게 업무 커뮤니케이션을 잘한다는 팀원들의 반응이 많아서 놀랐다고 하셨어요.영준 케빈님 1차 인터뷰 때에도 엄청 긴장되시지 않았어요?케빈 맞아요. 그땐 그래도 기술적인 질문이 많아서 나름 덜 떨었답니다.(?) 그리고 아까 영준님이 답해주셨듯이, 저도 마찬가지로 제가 경험한 것을 중심으로 질문을 많이 해주셔서 수월하게 대답할 수 있었던 것 같아요. 입사한 지 얼마 되지 않아 interviewer로 몇 번 참석했었는데, 지원자분의 경험을 중심으로 대화를 나누는 게 실제로 지원자분에 대해서 더 잘 알아갈 수 있는 좋은 방법인 것 같아요!Q. 입사 전 기대했던 지그재그의 모습과 실제 겪어본 지그재그의 모습은 어때요? 많이 다른가요?케빈 저는 기대했던 것과 크게 다르지 않았어요. 많은 개발자들이 기술적으로 더 성장할 수 없다고 느껴질 때 상실감을 크게 느낄 거예요. 전 직장에서도 서로 토론하고 의견을 공유하는 문화가 있었는데 바쁘다 보니 그 문화가 점점 사라지게 되어 많이 안타까웠죠. 그래서 지금은 지그재그 개발팀의 좋은 문화가 유지될 수 있게, 계속 활발하게 운영이 될 수 있도록 적극적으로 참여하려고 노력하고 있어요. 영준 사실 전 지그재그 팀이 딱딱한 분위기에서 업무를 할 거라고 생각했었어요. 워낙에 빠르게 성장하고 있는 회사이다 보니? 근데 막상 들어와 보니 이만큼 같이 일하는 게 재밌고 캐릭터가 독특한 사람들이 많은 회사는 처음이에요. 그리고 저희가 매주 월요일에 전 직원이 모여서 주간 미팅을 하잖아요. 거기서 팀별로 프로젝트 진행상황을 공유하는데 정확한 데이터 수치를 기반으로 꼼꼼하게 분석하고 리뷰하는 모습에 놀랐어요. 추가적으로 개발에 대한 열정이 있는 동료들이 많았으면 하는 소망도 있었는데, 실제로 만난 지그재그는 개발 욕심 가득한 사람들의 모임이라 매일매일 자극받으며 근무하고 있어요.매주 월요일 전직원이 참여하는 주간 미팅!Q. 지그재그 팀에 들어온 후에서야 비로소 알 수 있었던 좋은 문화나 제도가 있을까요?영준 사내 스터디가 많은 거? 아마 우리 회사가 다른 어떤 회사보다 스터디가 많을걸요? 원한다면 누구든 만들어서 모집할 수 있거든요. 다들 매우 적극적입니다.(그럼 영준님은 몇 개의 스터디에 참여하고 계세요?) 저는 1월에 새로 시작할 스터디까지 하면 두 개요!케빈 개발자들에겐 스터디도 큰 요소일 거예요. 다양한 스터디가 지속적으로 운영되는 게 쉬운 일은 아니라, 기술 블로그를 보면 '진짜 이만큼이나 공부한다고?'라고 의문이 들 수밖에 없으니까요. 아! 그리고 스터디는 아니지만 개발 미식회라는 프로그램이 있어요. 다른 사람들과 함께 의논해보고 싶은 코드가 있거나 혹은 본인이 만든 코드를 공유하고 싶은 사람이 자발적으로 신청자를 받아서 점심을 함께 먹으면서 발표도 하고 의견도 나누는 시간이에요. 한 달에 1-2회 정도 진행이 되고 있어요. 다음 주에 저도 발표하기로 했거든요. 신청자가 없어서 못하게 되면 안 되는데..영준 그리고 발표를 했던 사람은 다음 개발 미식회의 점심 메뉴를 선정할 수 있는 특혜가 주어집니다.(웃음)케빈 오! 그건 몰랐어요. 그리고 저는 저번에 영준님이 발표하실 때에도 신청해서 들었어요. 영준 다들 서로 발표를 하고 싶어서 바쁜 와중에도 열심히 공부해요. 바쁠 땐 듣는 게 좀 부담스러울 텐데도, 다들 적극적으로 들어주려고 하니 고맙죠.영준 님의 개발 미식회 모습! 제가 더 떨리네요 @.@Chapter 3. Dev. 팀은 이런 분을 찾아요!Q. 먼저 Dev. 팀은 어떤 방식으로 일을 하나요?영준 백엔드에 계시는 분들도 그렇고 다른 포지션에 계신 분들도 프론트엔드에 관심이 많으셔서 도와주실 때가 많이 있어요. 아무래도 다들 공부를 많이 하다 보니 그런 것 같아요. 그러다 보니 업무 할 때 같이 고민할 수 있어서 좋죠. 그리고 프로젝트를 일정에 맞추어 진행하다 보면 포기해야 될 부분이 생기기 마련인데요, 지그재그 팀은 유저의 사용성 향상을 위해 기획했던 것들을 최대한 포기하지 않고 가져갈 수 있는 방향을 모색하는 편이에요. 포기하면서 잃는 것도 생각하고 얻게 되는 것도 생각해야 하니 항상 신중해야 합니다.케빈 프로젝트를 진행하면서 문제가 생기면 다 같이 의논해서 풀려고 해요. 그리고 그 과정에서 여러 가지 다른 의견이 나오면 합의점을 찾으려고 하고요. 이건 팀 내에서 뿐만 아니라 유관부서랑 함께 일할 때도 같아요. 팀원들 모두가 개인적인 관점이 아닌 product 관점과 사용자 관점으로 생각하려고 하기 때문이죠. 또 프로젝트를 통해 유저분들에게 더 좋은 경험을 전달해주고자 노력하고 있어요. 그래서 유저분들의 기대에 부응한 부분과 그렇지 못한 부분이 무엇인지에 대해 사용자 데이터를 기반으로 회고하는 과정도 함께 진행하고 있습니다.Q. 회사 안에서 해보고 싶은 특별한 프로젝트가 있으신가요?영준 저는 직잭버디를 뽑는 시스템을 만들고 싶어요. 그리고 의류, 패션에 관련된 새 프로젝트도 해보고 싶네요. (*직잭버디는 신규 입사자의 빠른 적응을 도와드리는 멘토링 프로그램입니다!)케빈 저는 개인적으로 점심시간 메뉴 고르는 룰렛을 만들고 싶어요. 회사 주변에 밥집이 너무 많아서 오히려 메뉴를 고르기가 어려워요. 만들면 잘 쓰지 않을까요? 의견을 받아서 다 같이 만들어봐도 재밌을 것 같아요.Q. 요즘 [프론트엔드 개발자] 채용이 한창인데요, 어떤 분과 함께 일하고 싶으신가요?케빈 개발 환경을 기반으로 여러 개발 항목들을 유저의 관점에서 대조해 봤을 때, 깊게 생각해보고 경험해 본 분이면 좋겠어요. 유저의 관점에서 더 생각해보고 적용하시는 분이라면 지그재그 서비스에 대해 애정을 가지고 일할 수 있을 것 같아요.영준 요구사항에 맞게 동작하는 프로그램을 만드는 것은 물론, 유저의 사용성을 생각하는 개발자였으면 좋겠어요. 예를 들면 모바일 기기에서의 최소 터치 영역을 생각한다든지... 유저를 직접 만나는 최접점에 있는 개발이다 보니, 사용성에 관해서는 가장 관심이 많아야 한다고 생각하거든요. 또 프론트엔드 개발 자체가 빠르게 발전하고 있는데, 왜 이렇게 바뀌고 있는지를 생각하는 개발자면 좋을 것 같아요. 그리고 회사가 커지면서 여러 가지 새로운 서비스들도 생기고 새로운 경험도 많이 하게 될 텐데요, 새로운 걸 만들어 보고 겪어보고 싶은 분이라면 지원해주세요!케빈 평소에 업무를 하실 때 깊이 있게 고민하면서 선택하신 본인의 라이브러리, 도구들에 대해 왜 이런 선택을 했는지.. 또 코드 한 줄 한 줄을 어떤 의도로 작성했는지에 대해 생각해보신 분이라면 어렵지 않게 인터뷰를 진행하실 수 있을 거예요. 또, 그런 분들이 계시다면 저희도 꼭 모시고 싶어요!Chapter 4. 마무리Q. 올해 지그재그 팀에 합류하면서 개인적으로 성장한 부분, 그리고 2020년의 목표나 버킷리스트가 있으신가요?영준 지그재그 서비스가 이커머스가 되어가는 과정을 함께 하면서 성장했다고 느꼈어요. 내년 목표는 신사업 성공시키기! 업무 외적으로는 운동을 열심히 해서 바다에서 사진 찍는 거예요. (몸짱 영준)케빈 저는 Z결제 서비스가 오픈되면서 마케팅 이벤트를 위한 개발을 많이 했는데요, 이벤트에 대한 유저의 반응이 폭발적인 걸 보면서 더 유저의 입장에서 생각하려고 하는 스스로를 보며 성장하고 있다고 느꼈어요. 더 공부하려고 하기도 하고요. 그리고 개인적으로는 내년에 영어공부를 열심히 하고 싶어요. 제가 즐겨하는 PC게임이 있는데, 외국인 유저와 더 편하게 대화하면서 게임하고 싶어서요.(웃음)Q. 다음 인터뷰는 어느 팀에서 하면 좋을까요? 그 팀에 특히 궁금한 것이 있다면요?영준 저는 서버 개발자 또는 데이터 팀이요! 지그재그 서비스의 서버 개발자들은 각자 태스크를 부여받아서 진행하는 방식으로 업무를 한다고 들었는데, 구체적으로 R&R이나 업무 프로세스가 어떤 방식으로 이루어지는지 궁금해요. 그리고 데이터 팀에는 수많은 데이터들을 앞으로 지그재그 서비스의 발전을 위해 어떻게 활용할 수 있을지, 그리고 데이터팀에 계시는 인성님께 어떻게 그렇게 매일 웃으며 즐겁게 지내실 수 있는지 여쭤보고 싶어요.케빈 저는 디자인 팀! 지그재그의 다양한 디자인들을 작업하고 의사결정을 내리기까지의 논의 방식이 궁금해요. 그리고 디자인 팀에도 인원이 늘었는데, 그로 인해 어떠한 변화가 생겼는지도 궁금합니다.지그재그에서는 웹 프론트엔드 개발자를 포함하여 활발하게 채용을 진행하고 있습니다. 지그재그 팀과 함께, 수면 아래 숨겨진 가치를 찾아내는 경험에 동참할 팀원을 꼭 모시고 싶습니다 :-) 궁금하신 점은 언제나 [email protected] 또는 http://facebook.com/zigzagcareer로 연락 주세요!지그재그 [웹 프론트엔드 개발자] 포지션을 소개합니다!이런 일을 합니다.이런 분을 모십니다.이 중 하나라도 가능하시다면 더더욱 좋아요 :)지원 방법채용 절차혜택과 복지   더 많은 공고는 채용 사이트에서 확인 가능합니다! >>> 채용 사이트 바로가기
조회수 4001

리디북스 서비스 장애 복구 후기

지난 8월 26일에는 약 21분간 리디북스 서비스 전체가 중단되는 장애가 있었습니다.사실 서버 스택 일부에만 영향을 주는 장애는 눈에 잘 띄지 않지만 꽤 흔하게 발생하는 일입니다. 기기 1대당 외부적인 요인으로 인한 장애가 평균 2년에 1번 발생한다고 가정하면, 서버가 100대 있을 때는 대략 1주일에 1번꼴로 장애가 발생하는 셈입니다.이런 형태의 장애는 서버 스택의 한 곳에서만 발생하므로, 이중화 혹은 클러스터링을 통해서 극복하곤 합니다. 또한 원인이 명확하므로 해당 기술에 대한 이해도가 높다면 비교적 빠른 시간 내에 복구가 가능합니다.그러나 이번에 리디북스가 경험한 장애는 달랐습니다. 현재 리디북스는 2개의 데이터센터와 클라우드에 인프라가 분산되어 있는데, 이 중에서 1차 데이터센터의 전원 공급에 문제가 생겨 특정 서버 랙에 있는 서버 17대가 동시에 내려간 것입니다. 즉, 소프트웨어나 머신의 물리적인 장애가 아닌, 데이터센터의 장애였습니다. AWS로 비유를 하자면 가용 영역(Availability Zone)의 장애라고 할 수 있겠습니다.원인에 대해이번 장애의 근본적인 원인은 데이터센터가 전원을 정상적으로 공급해주지 못한 것입니다. 물론 데이터센터 혹은 클라우드 서비스(IaaS)는 고객사에게 전원과 네트워크를 안정적으로 제공해주어야 하는 의무가 있습니다.하지만 이들 역시 천재지변이나 사람의 실수에 대한 대비가 100% 완벽할 수는 없습니다. 따라서 이러한 점을 사전에 고려하고 인프라를 설계하지 못한 것이 2차적인 원인입니다.이번 계기를 통해 데이터센터 이중화를 계획하게 되었고, 사용 중인 클라우드 역시 지역(Region) 전체에 장애가 생길 경우에 대한 대비가 되어있지 않아, 이번 계기로 복제 계획(Geo-Replication)을 세우게 되었습니다.구체적인 상황당시 전원이 차단되어 강제 종료된 서버들은 아래와 같습니다.데이터베이스 프록시 x 2메인 리버스 프록시 x 1읽기 분산용 MySQL 슬레이브 x 1서점용 웹 서버 x 3추천 알고리즘 API 서버 x 1알림센터 API 서버 x 2메인 스토리지 서버 x 2출판 플랫폼용 데이터베이스 x 2테스트 및 배치 작업용 서버 x 3그림으로 표현해 보자면, 대략 아래와 같은 상황에서… 아래와 같은 상황이 된 셈입니다.서버 스택의 여러곳에 순간적으로 장애가 발생한 상황공인 IP가 할당된 메인 프록시 서버 중 1대가 내려갔지만, 실제로는 아래와 같이 가상 IP로 구성을 한 상태였기 때문에 대기 중인(stand-by) 프록시가 동작하여 곧 서점에 장애 공지를 띄울 수 있었습니다.[이미지 출처: DigitalOcean™]공지 이후의 움직임우리는 데이터센터의 복구 시점을 명확히 알 수 없어서 신규 구축(provisioning)을 시작함과 동시에, 서버들의 물리적인 위치 이동을 고려하고 있었습니다. 그러나 다행히 10분이 지난 시점에서 전원 문제는 해결되었고, 서버들은 순차적으로 부팅이 완료되었습니다.일부 서버들은 부팅 과정에서 예상치 못한 지연이 발생하기도 하였지만, 모든 서버의 부팅이 완료된 이후에도 서비스는 완전히 정상으로 돌아오지 않았습니다. 당시 우리가 겪었던 문제와 해결책은 아래와 같습니다.A. 읽기 분산용 MariaDB 슬레이브의 복제 지연(replication lag) 문제슬레이브 서버의 부팅이 완료되자 데이터베이스 프록시(HAProxy)는 해당 서버를 정상으로 간주하여 라우팅 대상에 포함하게 되었고, 애플리케이션 서버들은 정상적으로 커넥션을 맺기 시작하였습니다. 하지만 해당 슬레이브는 수십 분간 마스터를 따라잡지 못한 상태였기 때문에 최신 데이터가 보여지지 않는 문제(stale data)가 있었습니다. 우리는 즉시 해당 슬레이브를 제거하였고 지연이 사라진 이후에 다시 서비스에 투입하였습니다.B. 읽기 분산용 슬레이브의 웜업(warm-up) 문제복제 지연은 사라졌지만 서버의 CPU 사용량이 크게 높은 상태가 한동안 유지되었고, 응답속도는 정상적인 슬레이브에 비해서 많이 느렸습니다. 왜냐하면 캐시가 비워진 상태에서 바로 서비스에 투입되어, 캐시 미스가 휘몰아치는 현상(cache stampede)이 발생하였기 때문입니다. 따라서 간단한 쿼리도 평소보다 오래 걸렸고, 그대로 둔다면 커넥션풀이 꽉 차는 현상이 발생할 것으로 예상되었습니다.곧 우리는 HAProxy로 해당 서버의 가중치를 10%로 낮추어 인입되는 쿼리의 양을 조절하였으며 응답속도는 정상 수치로 돌아오게 되었습니다. 이후 스크립트를 작성하여 수동으로 캐시를 채워나감과 동시에 점차 가중치를 높여 처리량을 정상화하였습니다.프로덕션에서 사용하는 서버는 innodb_buffer_pool 이 100G 이상으로 매우 크게 설정되어 있으며, 재시작 시 캐시가 날아가는 현상을 해결하기 위해 innodb_blocking_buffer_pool_restore 옵션을 적용하고 있습니다. 하지만 지금처럼 메모리를 덤프하지 못하고 비정상 종료가 된 상황에서는 해당되지 않았습니다.C. 인메모리 데이터의 보존 문제알림센터는 다양한 프로모션과 개인화된 정보를 전달해주는 공간입니다. 알림센터의 특징은 데이터의 영구 보존(persistency)이 필요하지 않고, 매일 수백만 건의 개인화된 메시지가 기록된다는 것입니다. 이러한 특징은 인-메모리 데이터베이스에 적합하므로 우리는 Redis를 마스터/슬레이브로 구성하여 저장소로 사용하고 있었습니다.어떠한 이유로든 Redis를 재시작해야 할 경우가 생기면, 메모리 상의 데이터가 날아가는 것을 방지하기 위해 주기적으로 스냅샷을 남기고 있습니다만, 이번에는 로그가 마지막까지 기록되지 못한 상태에서 메모리의 데이터가 날아가 버렸습니다.다행히 알림 발송과 관련된 메타정보는 모두 MariaDB에 기록하고 있으므로, 우리는 이를 기반으로 소실된 시점부터의 알림을 순차적으로 재발송할 수 있었습니다. 물론 모든 알림이 신규 상태로 간주되어 아이콘이 잘못 노출되는 문제가 있었지만, 고객님들은 너그럽게 이해해 주신 것 같습니다. 😅그래서 앞으로는?리디북스 DevOps 멤버들은 이번 데이터센터 장애를 통해 현재 인프라의 한계점을 실감하였고, 앞으로의 개선 방향에 대해 고민하게 되었습니다.몇 가지를 정리하면 다음과 같습니다.랙 단위로 장애가 발생할 수 있음을 인지하고 대비하자.같은 기능을 하는 서버를 하나의 랙이나 같은 가용 영역에 두지 말자.2차 데이터센터는 더 이상 옵션이 아닌 필수다.낙뢰나 지진으로 인해 데이터센터에 문제가 생길 수도 있다.긴급하게 프로비저닝이 필요한 상황에 대비하자.문서화가 되어 있더라도 경험이 없다면 동일한 구성에 많은 시간이 소요된다.모든 구성요소들에 대한 Ansible 스크립트를 작성하여두자.캐시 웜업 스크립트도 작성하여 두자.백엔드 구성요소들 간의 불필요한 의존 관계를 끊자.단 한 줄의 코드라도 참조하고 있다면 이는 독립적인 것이 아니다.언제나 서비스 지향적인 설계를 추구하자.Uptime을 관리하자.최대 180일을 기점으로 무조건 리부팅을 하자.재시작 과정에서 다양한 문제와 개선점이 발견될 것이다.커널 패치, 보안 패치를 할 수 있는 것은 덤이다.아래와 같은 긍정적인 면도 발견하였습니다.장애 상황이 실시간으로 Slack 채널을 통해 전파되었음진행 상황에 대해 모두가 동일한 수준으로 이해할 수 있었다.모니터링 연동(integration) 기능 때문에라도, Slack은 유료로 구매할만한 값어치가 충분하다.같은 기능을 하는 서버들이 다른 랙에 많이 분산되어 있었다.인프라가 확장될 때마다 빈 공간에 필요한 서버를 추가했을 뿐이지만, 자연스럽게 물리적인 위치가 분산되는 효과가 있었다.이 외에도 특정 클러스터를 구성하는 노드들을 분산하여 배치시키자.서버별로 오너쉽이 부여되어 있어서 빠르게 복구가 된 점여러 명의 백엔드 개발자들이 병렬적으로 복구를 진행할 수 있었다.마지막으로넷플릭스의 엔지니어들은 무질서한 원숭이(Chaos Monkey)라는 프로그램을 만들어서 운영한다고 합니다. 이 원숭이는 서비스 인스턴스들을 무작위로 중단시키는 역할을 합니다. 다소 황당하게 들리지만, 넷플릭스에는 일부 서비스에 장애가 발생하더라도 나머지 부분은 문제없이 운영되어야 한다는 원칙이 있으므로, 이를 수시로 시뮬레이션하는 과정을 통해 복구 능력을 높여둔다는 것입니다.실제로 이렇게 급진적인 아이디어를 실천할 수 있는 회사는 매우 드물 것입니다. 하지만, 우리는 이번 계기를 통해 무질서한 원숭이의 필요성을 절감하였고, 이로 인해 서버를 주기적으로 리셋하는 정책을 만들게 되었으며 모든 단일 장애점(SPoF)에 대한 대비를 시작하게 되었습니다.장애를 단순히 피해라고만 생각한다면, 서로를 비난하고 책임을 전가하는 상황이 펼쳐질 것입니다. 하지만 고객의 불편함과 맞바꾼 매우 비싼 경험이라고 생각한다면, 보다 튼튼하고 회복탄력적인 시스템을 갖추기 위해 노력하게 될 것입니다. 그러다 보면 언젠가는 데이터센터 전체에 문제가 생겨도 버틸 수 있는 모습으로 진화할 것이라고 생각합니다.#리디북스 #장애복구 #역경돌파 #개발 #개발후기 #개발자 #서버개발 #서버
조회수 2183

비전공자를 위한개발자 되기 5 스텝

안녕하세요. 언제 어디서나 함께하는 코딩 교실 엘리스입니다 :)아이디어만 좋다면 뭐든 실현해볼 수 있는 시대! 지금은 '프로그래밍'이라는 강력한 무기를 통해 원하는 세계를 실현할 수 있는 잠재적 가능성이 폭발적인 때입니다. 그리고 그 기회는 비단 '개발자'라는 특정 직업에 국한하지 않더라도 각계 분야에 펼쳐져 있는데요. 이미 마케터, 기획자, 디자이너, 콘텐츠 창작자, 금융업계 종사자, 지리학자, 연구원 등 다양한 분야의 많은 사람들이 프로그래밍을 통해 각자의 영역과 세계 곳곳을 새로운 곳으로 만들고 있습니다.높은 급여와 삶의 질을 보장하고 나의 꿈을 펼칠 수 있는 탁월한 수단인 프로그래밍.프로그래밍을 업으로 삼고 있는 사람들의 시작은 어땠을까요?이 글에서는 소프트웨어 엔지니어가 되고자 이제 막 마음먹은 분들을 위해 프로그래머가 되기 위한 다섯 가지 짚고 넘어가면 좋을 팁들을 알려드릴게요.STEP 1. 개발 친화적인 환경 찾아가기서당개 삼 년이면 풍월을 읊는다컴퓨터 공학 전공자와 비전공자가 가지게 되는 가장 큰 차이는 무엇일까요? 개발에 대한 이론 지식? 개발 능력?물론 모든 게 상대적인 것이겠지만 일반적으로 한 가지 큰 차이가 있다면 바로 '환경'이라고 할 수 있을 듯합니다. 내 주변에 개발과 관련된 자원이 얼마나 풍부한가 하는 점입니다.전공자가 개발을 시작하고자 마음을 먹으면 주위에서 좋은 리소스를 쉽게 찾을 수 있습니다. 한편 비전공자는 개발 공부를 시작하려고 할 때 레퍼런스로 삼을만한 좋은 예가 없으니 망망대해에 홀로 떠있는 기분이 들 수밖에 없겠죠! 그렇다고 해서 반드시 컴퓨터 공학 전공에서부터 다시 시작하거나 고액의 학원에 다닐 필요는 없습니다. 먼저 개발과 관련된 인적, 물적 자원이 풍부한 곳으로 적극적으로 다가가보세요. 작은 환경의 변화가 큰 변화의 시작점이 될 수 있습니다.엘리스가 추천하는 방법!온라인 커뮤니티 활동하기 : 코딩과 관련된 페이스북 그룹에 가입하여 많은 정보를 접하고 질문도 하면서 활동해보세요. 나와 비슷한 상황인 사람을 만나 서로 도움을 주고받을 수도 있고, 내 롤모델이 될만한 훌륭한 개발자를 만나 공부의 동력이 될지도요!개발 동아리, 스터디 등에 참여하기★ 엘리스 코딩 클래스 활용하기 : PC로도, 모바일 앱으로도 언제 어디서든 프로그래밍을 위한 환경에 접속하세요! 엘리스에 로그인하는 것만으로 공부하기 위한 모든 리소스를 얻을 수 있을 뿐만 아니라 과목별 채팅방을 통해서 함께 공부하고 있는 수강생들, 과목 튜터와의 활발한 대화에 참여할 수 있습니다. STEP 2. 강력한 동기와 조력자 만들기하늘은 스스로 돕는 자를 돕는다컴퓨터 공학 전공자라고 하면 모두 다 개발을 잘할까요? 적어도 아주 조금은 더 잘할까요? 대답은 NO!아무리 많은 이론을 배웠다고 해도 직접 개발을 하지 않는다면 아무런 소용이 없겠지요. 이해도가 다르기 때문에 배움의 속도는 조금 다를 수도 있겠지만 이런 차이보다는 개인의 학습 의지와 동기가 얼마나 분명하냐가 더 중요합니다.막연하게 '개발자'라는 너무 먼 목표만 보고 달리는 것보다는 보다 가까이에 있고 달성하기 쉬운 분명한 목표를 단계별로 설정해보세요. 그리고 '즐거움'을 느낄 수 있는 수단을 찾아 목표 달성을 위한 집중력을 높이세요. 동시에 내가 어려움에 처하거나 헤매고 있을 때 도와줄 조력자가 있다면 금상첨화!Photo by Mimi Thian on Unsplash엘리스가 추천하는 방법!동기 부여를 위한 작은 목표 설정 : 지식 습득 및 학습과 관련된 목표로 그룹 스터디 참여, 부족한 부분의 프로그래밍 강의 완강, 책 한 권 떼기 등이 있을 수 있고, 더 적극적인 형태의 개발 경험을 위해 공모전, 경진 대회 등 기간과 보상이 정해져 있는 대외 활동 참가 및 수상도 좋은 목표가 될 수 있을 거예요.★ 엘리스 코딩 튜터 활용하기 : 엘리스에는 학습을 도와주는 튜터가 있습니다. 엘리스 튜터는 답을 알려주는 사람이 아니라 답을 찾는 법을 알려주는 길잡이입니다. 공부하다가 막힐 때, 길을 잃은 것 같을 때 엘리스 튜터를 멘토로 삼아 보세요! 구독 및 트랙 이용 시 담당 튜터가 배정되어 개인 채팅방을 통해 1:1 튜터링을 받을 수 있고, 클래스 수강 시 단체 채팅방을 통해 언제든 질문할 수 있습니다.STEP 3. 원하는 개발 분야 탐색해보기  콩 심은 데 콩 나고 팥 심은 데 팥 난다개발에는 아주 숱~한 다양한 분야가 있습니다. 그리고 그 분야에 따라 특성도, 익혀야 하는 언어와 기술도 천차만별인데요. 아래 몇 개의 개발 분야와 사용 언어 및 기술에 대해서 적었으니 참고해보세요. 그리고 이보다 더 다양한 개발의 세계를 탐색해보면서 흥미가 가는 분야가 있다면 구체적으로 검색하고 공부를 시작할 계획을 세워보세요.Photo by Victoriano Izquierdo on Unsplash잘 모르겠다 or 코알못이다파이썬은 분야를 막론하고 많은 분야에서 사용되며 익히기에 쉬워 처음 코딩을 시작하는 입문자에게 가장 적합한 언어 중 하나입니다. 개발 언어부터 접해보고 싶다면 파이썬 언어 학습에서 시작해보세요!웹 개발 '콩 심은 데 콩 나고~'라는 속담을 인용했지만, 사실 다양한 개발 영역의 많은 지식들이 서로 겹치는 부분도 있고, 어느 한 분야를 잘할 수 있을 때 다른 분야로 전향하거나 옮겨가는 일은 보다 수월할 수 있습니다. 개발의 시작을 보다 쉽게 하고 싶다면 웹 개발부터 접근해보세요. 공부할 수 있는 자원이 풍부하고 추후 다른 개발 분야로의 전향도 가능하기 때문이에요.프론트엔드프론트엔드 개발은 주로 웹 환경에서 사용자와 맞닿는 가시적인 부분을 개발하는 영역입니다. 사용자가 코드를 작성하지 않고도 컴퓨터에게 명령을 내리는 등의 의사소통을 그래픽적으로 쉽게 할 수 있도록 가시적으로 만들어주는 것이 바로 프론트엔드 개발자의 역할이라고 할 수 있는데요. 예를 들어 엘리스에 로그인하고 싶을 때 '로그인 버튼을 클릭'하여 쉽게 로그인할 수 있는 인터페이스도 프론트엔드에 해당합니다. * 익혀야 하는 기본기 : HTML, CSS, JavaScript* 좀 더 나아가서 : JavaScript의 프레임 워크인 React.js 또는 Vue.js 또는 Angular.js 백엔드/서버백엔드 개발은 웹 환경에서 보통 사용자에게는 보이지 않는 서버(컴퓨터) 단의 개발을 의미하며, 사용자가 웹 상에서 활동함으로 인해 쌓이는 데이터가 모이는 DB(Data Base)를 다루는 영역을 개발합니다.* 익혀야 하는 기본기데이터베이스에 대한 지식 : MariaDB, PostgreSQL, MongoDB 등. 서버 쪽의 언어- 금융, 제약 등 전통적인 대기업 : Java의 프레임 워크인 Spring을 많이 사용- 과거 많이 쓰이던 기술 : Php(학습 속도와 개발 속도가 빠르며 무료!)를 많이 사용- 요즘 떠오르는 기술 : Python 기반 프레임 워크인 Django 또는 Flask. JavaScript의 프레임 워크인 Node.js* 좀 더 나아가서 : 클라우드 컴퓨팅 기술 Amazon AWS 또는 Azure에 대한 지식데이터 사이언스 - 데이터 분석가21세기에 가장 각광받는 직업 중 하나로 떠오른 '데이터 사이언티스트'에 대해서 모두 다 한 번쯤은 들어보셨을 거예요. 데이터 사이언스 분야에도 아주 복잡하고 다양한 영역들이 존재하는데요. 통상 데이터 사이언스라고 하면 수학 및 통계에 대한 지식, 컴퓨터 공학에 대한 지식, 인공지능 및 머신러닝과 관련된 기술을 사용하게 됩니다. 너무 많아 보이나요? 아래에는 데이터 사이언스의 많은 영역 중에서도 '데이터 분석가'로서 꼭 알아야 하는 내용을 적었습니다.* 익혀야 하는 기본기수학적 지식 : 통계, 선형대수학분석을 위한 언어 : Python, R* 좀 더 나아가서 : 머신러닝 기술임베디드 개발계산기, 에어컨, 자동차 등의 기계가 일정 기능을 컴퓨터처럼 수행할 수 있도록 기계 내부의 하드웨어 시스템을 구축하는 것이 임베디드 개발입니다. 사물 인터넷(IoT, Internet of Things)이나 하드웨어 부품과 관련된 분야에 관심이 간다면 임베디드 개발에 대해서 좀 더 알아보세요!* 익혀야 하는 기본기임베디드 개발 언어- 가장 많이 사용하는 언어 : C언어 - 국내 전통적인 대기업 : Java- 수요가 많은 언어 : Python (임베디드 분야에서도 빠지지 않고 자주 사용하는 언어! 국내 채용 사이트에서 임베디드 관련 개발 스택으로 많이 요구.)* 좀 더 나아가서 : 무선 통신 기술에 대한 지식*(공통) 개발자라면 익히고 있어야 할 기본기 : Git을 사용한 버전 관리 방법엘리스가 추천하는 실습 기반 과목HTML/CSS | JavaScript | 모바일 웹 코딩Git과 Git 버전 관리 (6월 오픈 예정)Python 기초 I | Python 기초 IIC 언어 | C++Java 기초 및 심화인공지능/머신러닝 기초 | 프로그래밍 수학데이터 분석 | Numpy, Pandas | 크롤링 | Kaggle 문제R 기초 |  R 패키지 | R 데이터 분석STEP 4. 실습, 프로젝트 기반으로 공부하고 개발 경험 쌓기구슬이 서 말이어도 꿰어야 보배다책을 사고 인강을 결제해도 직접 만들어보면서 익히지 않으면 절대 내 것이 될 수 없는 것이 또 개발!처음 언어를 익히는 단계에서부터 실습 기반으로 직접 코딩하고 그 결과를 확인해보면서 학습하는 것이 중요해요! 필요한 공부를 실습 단위로 쪼개어 직접 구현해보면서 익히고, 좀 더 나아가서는 프로젝트 단위로 구현하면서 실전 기술을 습득해보세요. 또한 실무에서는 혼자 개발하는 것이 아니라 뭐든 '협업'해야 하기 때문에 혼자 하는 프로젝트 외에도 여러 사람들과 함께하는 그룹 프로젝트의 경험이 큰 도움이 될 거예요. 자기소개서, 포트폴리오, 면접 시에도 어떤 프로젝트에서 내가 맡은 부분은 어느 부분이었고 어떻게 주도적으로 이끌었는지가 관건이 될 수 있습니다.엘리스가 추천하는 방법!★ 온라인 코딩 실습으로 기본기 다지기 : 엘리스는 별도의 코딩 환경 세팅 없이 온라인에서 바로 코딩 문제를 풀고 내가 짠 코드의 결과를 확인할 수 있어서 실습 기반으로 학습하기에 탁월한 플랫폼입니다. :) KAIST, SKT, 삼성 SDS 등에서도 활용하는 검증된 플랫폼에서 코딩 실습으로 기본기를 다지세요!프로젝트 단위로 혼자서 만들어보기 : 프로그래밍 언어의 기본에 익숙해졌다면, 직접 A to Z를 구현하는 작은 프로젝트를 통해 실제 필요한 기술이 뭔지 파악해가며 실전 기술을 익혀보세요. 그룹 프로젝트에 참여해서 협업 경험을 통해 익히기 : 취업을 위해서 중요한 것 중 하나인 '협업'능력! 그룹 프로젝트에 참여하여 비단 개발 실력뿐만 아니라 실무에 필요한 다양한 역량 또한 길러보세요.STEP 5. 포트폴리오, 시험 준비하고 개발 직군에 지원하기시작이 반, 그 이상이다!아시겠지만 개발자가 되면 끝인 그런 일은 없겠죠. (어떤 직무에서도 마찬가지일 거예요.) 끊임없는 공부, 새로운 기술 연마, 리팩토링, 문서화, 코딩 공부 코딩 공부!그러니 완벽에서 시작해야 한다는 생각은 버리고 지금까지 최선을 다해온 결과물을 가지고서 개발 직군에 지원하세요. 실제 개발자로 일하게 되면 그 속에서 배우고 성장할 수 있는 자원이 훨씬 더 많아집니다!'자리가 사람을 만든다'라는 말이 괜한 말이 아니니, 더 큰 성장과 가능성이 있는 곳으로 가기 위한 준비와 지원을 주저 없이 해보시길 바라요!Photo by Green Chameleon on Unsplash엘리스가 추천하는 방법!나를 잘 보여줄 포트폴리오 만들기 : (사용한 언어 / 프레임 워크 / 앞의 것을 적용하여 프로젝트에서 내가 한 역할) 별로 정리해두고 내가 커밋한 코드와 함께 보여주기.   블로그 쓰기 : 거창한 것이 아니어도 좋으니 공부하면서 느꼈던 것, 새로 알게 된 지식들, 프로젝트하면서 고민했던 것들을 블로그로 정리해보세요. 내가 구현한 것들을 이미지를 통해서 가시적으로 보여줄 수 있다면 금상첨화!★ 엘리스에서 알고리즘 시험 준비하기 : 이미 많은 수강생 분들이 엘리스 알고리즘 과목을 통해서 코드를 발전시키고 알고리즘 시험 및 취업에 성공하고 있습니다. :) 대기업 입사를 준비하시는 분이라면 엘리스 알고리즘 과목들을 꼭 수강해보세요.이다음의 6번째 스텝은 무엇이 될까요? 아마도 1~5 스텝을 계속 반복해나가면서 익숙해지고, 다른 역할로 각각의 스텝에 참여하게 되는 일이 아닐까요.엘리스는 누구나 프로그래밍을 통해 원하는 일을 할 수 있도록 좋은 강의 콘텐츠와 서비스, 플랫폼으로 여러분의 다섯 스텝에 함께하고자 합니다. :) 막막한 초심자 분들에게 앞으로의 방향성을 그려보는 데에 조금이라도 도움이 되길 바라며 글을 발행합니다.그럼 엘리스에서 만나요! >> 엘리스 아카데미 바로가기* 이밖에 조언, 첨언, 질문 등을 댓글로 남겨주시면 이 글의 독자분들에게 큰 도움이 됩니다.
조회수 295

프로그래밍 수업의 모든 것.

안녕하세요 엘리스입니다. :)엘리스의 프로그래밍 수업은 누구에 의해서, 어떻게, 어떤 생각을 바탕으로 만들어질까요?미래를 이끌어나갈 컴퓨터 사이언스 기술과 그 근간이 되는 교육 사이에서 좋은 프로그래밍 수업을 만들기 위해 치열하게 고민하는 엘리스의 코스 매니저가 직접 이야기합니다! 마침 엘리스는 코스 매니저 채용 중에 있으니 관심이 있다면 눈여겨 봐주세요!코스 매니저가 관여한 프로덕트로 인하여 사용자가 성장을 하고 있다면 그것은 충분히 의미 있는 일.안녕하세요 저는,트라우마를 극복한 프로그래밍 수업 크리에이터.Q. 자기소개 부탁드려요.A. 엘리스의 프로그래밍 과목을 만드는 코스 매니저 이용희입니다.Q. 엘리스에서 일하게 된 이유는 무엇인가요?A. 원래는 프로그래밍에 대한 트라우마가 있었어요. 하지만 기술 창업에 대한 꿈이 있었기 때문에 프로그래밍은 극복해야 할 산이었죠. 엘리스는 가장 뛰어난 기술자들이 모여 창업한 스타트업이에요. 당연히 기술 창업을 가장 가까이에서 경험할 수 있는 매력적인 곳으로 느껴졌죠. 그리고 프로그래밍 교육을 제공한다는 것 역시 기회로 느껴졌어요. 저와 같이 프로그래밍을 미워하고 두려워하는 사람들에게 보다 쉽게 배울 수 있는 환경을 마련해주고 싶다는 기대로 일을 시작하게 되었습니다.Q. 두려운 대상을 향해 몸을 던지셨군요! 그런데 코스 매니저가 프로그래밍을 몰라도 되나요?A. 많이 알면 알수록 당연히 좋아요. 많이 알고 있을수록 시도할 수 있는 것도 많고 학생에게 전달해줄 수 있는 것은 더욱더 많기 때문에요. 하지만 최소한으로는 Class가 뭔지 알고 있으면 OK. 예를 들어서 코드를 보고 이 코드가 어떤 목적을 갖는지 알 수 있으면 직접 코딩을 하지는 못한다고 해도 괜찮아요.Q. 코스 매니징 외에도 라이브 수업 참여, 조교, 챌린지 사회자 등 많은 역할을 하셨는데 이유가 있나요?A. 좋은 수업을 만들기 위한 첫 번째 방법은 코스를 만드는 모든 과정에 참여하는 사람들의 역할을 직접 체험해 보는 것이라고 생각했어요. 학생으로서, 조교로서, 사회자나 라이브 어시스턴트로서. 이렇게 하니까 학생으로서 수업을 접할 때의 감상은 무엇인지, 조교로서 가르쳤을 때는 어떤 어려움이 있는지를 알 수 있었어요. 라이브 수업 어시스턴트로 참여했을 때는 방송하시는 선생님들의 애로사항을 알 수 있겠더라고요.코스 매니징의 정수.프로그래밍적 성장을 도움으로써 가치를 만들어 냅니다.Q. 코스 매니징의 A to Z는? 구체적인 업무 프로세스가 궁금해요.A. 크게 기획 - 모집 - 제작 - 분석의 네 단계로 이루어져 있어요. 1. 수업 기획 -  어떤 과목을 만들 것인가? 주차별로 무엇을 다룰 것인가? 흥미로운 콘텐츠는? 2. 선생님, 조교 모집 - 엘리스가 구상한 수업을 가장 잘 전달할 수 있는 선생님과 조교를 모집. 3. 수업 제작 및 운영 - 실습 문제, 강의 자료 등을 엘리스의 색깔로 제작하여 수업을 운영. 4. 데이터 분석 - 학생들의 피드백과 데이터를 다음 수업의 발전 및 교육자와의 관계 개선에 반영.Q. 업무 방식은? 어떤 메리트가 있나요?A. 처음부터 끝까지 모든 과정을 주도해나가는 방식이에요. 어떤 회사를 가도 프로덕트의 end to end 프로세스를 전부 경험하기는 어려운데 엘리스에서는 그 전 과정을 경험할 수 있어요. 저는 이러한 경험이 교육 업계나 특정 프로덕트에만 적용할 수 있는게 아니라 다른 업계에 간다고 하더라도 충분히 전환될 수 있는 좋은 경험이라고 생각해요.Q. 미래 산업의 근간이 될 교육을 직접 만든다는 중책을 맡고 계신다고 생각하는데요, 좋은 프로그래밍 수업을 만들기 위해 어떤 노력들을 하시나요?A. 그런 영향을 미칠 수 있다는 게 무서운 일인 것도 같아요. 어떤 사람들은 엘리스를 통해서 프로그래밍을 처음 접하는 것일 수도 있는데 그 경험이 불쾌했다면 앞으로 프로그래밍을 배울 생각이 전혀 들지 않을 수도 있는 거잖아요. 그래서 최대한 다양한 피드백을 받아서 수렴하려고 해요. 외적으로는 대학강의, 수많은 수업들을 참고해요. 여러 강의를 보다보면 좋은 예도 많지만 모든 수업이 재미있지는 않아요. 중간에 듣다 마는 경우도 있고요. 그럴 때마다 내가 왜 중단했고 어떤 요소를 바꾸면 엘리스에서는 학생들이 끝까지 들을 수 있을까 고민해서 반영하려고 하죠.Q. 언제 보람을 느끼나요?A. 내가 관여한 프로덕트가 누군가에게 임팩트를 만들어내고 나뿐만 아니라 프로덕트를 사용하는 사람들이 성장을 하고 있다면 그것은 충분히 가치 있는 일인 것 같아요. 저희 플랫폼에서는 대시보드를 통해서, 그리고 학생이 코드를 어떻게 짜고 있는지 보면서 그 결과를 가시적으로 확인할 수 있어요. 누군가 제가 만든 코스를 수강함으로써 실질적으로 성장하는 게 눈에 보일 때 가장 큰 보람을 느끼는 것 같아요.한 번은 한 선생님께서 학생으로부터 ‘선생님 덕분에 취업할 수 있었어요’라는 메시지를 받은 것을 엘리스와 공유해주셨는데 그때 정말 행복하더라고요. 이게 엘리스가 추구하는 거다,라는 생각을 했어요. 엘리스도 하나의 커뮤니티이고 싶거든요. 이 경우에는 학생-선생님-엘리스가 서로의 영향으로 좋은 결과를 만들어 낸 거죠. 이런 접점을 앞으로 더 많이 만들려고 생각하고 있어요.대시보드에 나타나는 학생들의 학습 현황 및 성취도.엘리스는 이런 팀.가치, 성장, 사람. 포기할 수 없는 세 가지가 있는 곳.Q. 함께 일하는 동료들은 어떤 사람들인가요? 총평을 하자면?A. 항상 내가 최고의 사람들과 함께하고 있다라는 확신이 있어요. 각자 자기 분야에서 최고의 실력을 가진 사람들과 함께 일한다는 것만으로도 큰 자극이 되죠. 프로그래밍이든 스타트업 생존 노하우든 항상 뭔가를 새롭게 배우고 성장하게끔 동기부여를 해주는 사람들이에요. 저는 트라우마가 있었을 정도로 프로그래밍을 두려워했지만 이들과 함께 일하며 작은 피드백을 하나 듣는 것만으로도 제 실력이 빠르게 성장한다는 것을 몸소 느낄 수 있었어요. Q. 엘리스의 분위기, 팀 문화는 어떤가요?A. 새로운 것에 도전하는 것을 환영하는 수평적이고 자유로운 팀. 인턴도 아이디어를 제시할 수 있어요. 이 다음이 더 중요한데, 아이디어에서 그치는 게 아니라 활발한 피드백이 오가요. 아이디어를 실행하기 어렵다고 판단하더라도 왜 그렇고 어떻게 발전시킬 수 있는지 이야기하죠. 실행하게 되었을 때는 아이디어를 제시한 사람에게 일에 대한 권한이 전적으로 주어지고요. 저도 처음엔 파트타임 인턴이었지만, 이런 팀문화 덕분에 계속해서 업무 범위를 확장하고 제 역량을 키울 수 있었어요.코스 매니저 채용.Generalist & Infinite LearnerQ. 현재 코스 매니저를 구인하고 있는데요. 코스 매니저에 적합한 성향이 있나요?A. 두 단어가 떠오르네요. Generalist, 그리고 Infinite Learner. 깊게 한 분야를 아는 사람보다는 얕고 넓게 아는 사람이 더 적합하다고 생각해요. 다르게 말하면 새로운 것을 시도하는 것을 좋아하고 새로운 것을 접할 때 포용력이 높은 사람이요. 두 번째로는 배움에 재미를 느끼는 사람. 엘리스는 교육 스타트업이고 코스 매니저는 직접 교육의 경험을 만드는 사람이니 스스로가 배움에서 행복을 느끼는 사람이라면 훨씬 더 재미있게 일할 수 있겠죠. 한 가지 덧붙이면, 데이터 분석을 배우고 싶은 분께 엘리스는 최고의 장소입니다.Q. 코스 매니저로서 갖추고 있으면 좋은 역량이나 자질이 있다면?A. 소통 능력과 균형 감각. 코스 매니저는 수업을 만드는 모든 단계에서 다양한 이해당사자들과 일하게 돼요. 이들과 원활하게 소통하고 의견을 공유하는 게 중요하죠. 그리고 다양한 사람들 사이에서 최고의 균형을 찾아내는 것도 중요해요. 예를 들어서 선생님의 경우 개발만 해왔고 교육이라는 것을 접해본 적이 없는 분들이 대부분이고, 학생은 프로그래밍을 처음 접하면 그 수업이 좋은 건지 아닌지 평가하기 어려워요. 때문에 코스 매니저가 이 둘 사이에 다리를 놓는 중재자의 역할을 하기 위해서는 다양한 시각에서 볼 수 있는 균형 감각이 필요하다고 생각해요.
조회수 1718

StyleShare Engineering Blog?!

변정훈님 강의 모습생각해보기한 번도 생각해본 적이 없다! 왜 글을 작성해야 하는가?! 왜냐하면, 우리는 글로 먹고사는 사람도 아니고, 수려한 글솜씨도 없기 때문에?! 하지만, 이미 우리 사회는 PR의 시대를 뛰어넘어 미디어의 홍수에서 살아가고 있고, 매우 쉽게 무의식적으로 많은 글을 읽고 있다.하지만, 우리가 글을 작성하기 위해서 얼마나 많은 준비가 되어 있을까? 이 글을 쓰고 있는 필자 역시 글을 써본 경험이 거의 없다. 특히 회사의 이름을 걸고 글을 쓴다는 것은 매우 부담스러운 일이다.그래서 우리는 변정훈[Outsider’s Dev Story]님을 초대하여, 그분이 생각하는 블로그 일상과 엔지니어링 블로그에 대한 생각 공유의 시간을 가져보았다.엔지니어링 블로그회사 블로그 운영을 해보았는가?아쉽게도 변정훈 님도 회사 블로그를 운영해본 적은 없다고 하신다. 그 원인을 다음과 같은 이유로 해석을 하였다.주제가 많지 않다.개발보다 우선순위가 떨어진다.누구나 처음부터 글을 잘 적을 수 있는 건 아니다.그렇다. 이 글을 쓰는 중에도 위와 공감할 수 있는 부분이 적지 않다.우선 글을 많이 써보지 못한 필자로서도 어떤 글을 적어야 할지 난감하게 느껴지고, 업무 중에서도 중요도가 떨어지는 것은 분명하다. 마지막으로 주제 선정부터 매우 어렵게 느껴진다.그런 이유로 글쓰기를 즐겨 하시는 변정훈 님 조차 회사 블로그 운영을 잘 이끌어 본 적이 없다고 하신다.변정훈 님의 블로그는 2007년 부터 총 1,300여개 글이 게시되어 있다고 한다.왜 우리는 블로그를 운영하려 하는가?여러 가지가 있겠지만, 필자가 가장 공감한 부분은 이 부분이었다.팀 내 지식/경험 공유잠재적 입사자에게 기술 스택 및 문화 공유팀 전체의 실력 향상그동안 개발일을 해오면서, 몇 년 동안 풀리지 않는 큰 숙제 중에 하나가 좋은 개발자를 찾는 것이었다. 항상 사람을 찾는 것이 어렵다. 좋은 사람의 기준이 높아서인지 더 좋은 기업이 많아서인지 알 수는 없지만, 일하면서 느낀 가장 어려운 문제 중에 하나이다. 결국, 내부의 인력을 더 좋은 사람으로 만들고, 외부의 좋은 사람과도 교류의 장을 만들 수 있다는 희망을 품을 수 있게 되는 것이다.글 작성의 문턱을 어떻게 낮춰야 할까?좋은 점은 쉽게 공감이 되지만, 언제나 가장 어려운 것은 실천이 아닐까 싶다. 특히 회사에서 업무로 이런 일이 발생된다면, 많은 사람들이 엄청난 부담감을 가질 것이고, 결국 회사 엔지니어링 블로그는 대문만 남은 유명무실한 블로그가 될 가능성이 높다.그래서 변정훈 님은 이렇게 제안하셨다.월 1개 보다 적어도 된다.주제를 계속해서 제안하고 만들어 내야 한다.돌아가면서 작성한다.챙겨주는 사람이 필요하다.글도 리뷰하는게 좋다.부담감은 의도적으로 줄여야 …특히 변정훈님은 부담감을 줄이는 방법에 대해서, 팀 공유를 해주셨는데 잠시 소개하면 다음과 같다.나보다 모르는 사람 — 나 — 나보다 잘하는 사람언제나 어떤 기술에 대하여, 나보다 잘 모르는 사람과 나보다 잘 하는 사람이 있다는 것을 인지하고, 나보다 못하는 사람을 위해서 글을 작성한다는 것이다. 그러다 나보다 잘하는 누군가가 어쩌다 피드백을 준다면 오히려 매우 감사하게 새로운 지식을 터득하게 된다는 것이다. 역시 모든일에는 긍정적인 마인드가 중요하다. 세상 어딘가에는 나의 작은 지식이라도 필요로하는 사람들이 분명히 있을테니, 작은 용기를 가지고 세상에 누군가를 위해서 작성한다면, 세상은 분명 아름다워질 것이다.좋은 글, 좋은 주제란 무엇일까?사실 가장 어려운 이야기일지도 모른다. 변정훈님은 이런 내용을 좋다고 표현하셨는데, 잠시 정리하면 다음과 같다.개발팀의 문화어떻게 일하는가?프로젝트 수행 회고실패기개인적으로 실패기가 가장 적기 어려운 글이라고 생각한다. 하지만, 누군가에게는 가장 소중한 경험이 될지도 모르니, 간접경험의 공유는 특히 소중한 것일 수 있다.만약 회사 블로그의 글이 회사 내/외부의 사람들에게 지식 공유와 전달이 목적이라면, 그리고 좋은 문화를 계속 가지고 유지하기 위해서라면, 실패기가 어쩌면 가장 소중한 경험의 공유가 아닐까 생각해본다.질문과 답변을 통한 소통의 시간마지막으로 이 날 소개 받은 좋은 글의 흐름이란 다음과 같았다.하고자 했던 일 (Context)경험한 문제 사황 정리(격리된 상황)시도해 본 방법(내가 아는 지식)왜 동작이 안되는가? 왜 동작하는가?(가설)문제 상황 재현예제 코드관련 링크개념 설명지금까지 적은 이 글을 위의 원칙대로 다시 한번 살펴본다. 부족한 부분이 있는지, 수정할 부분이 있는지…이제 부터 회사 블로그를 더욱더 적극적으로 운영해보자!!!#스타일쉐어 #개발팀 #조직문화 #블로그 #기업문화 #사내복지
조회수 1000

VCNC 개발팀 워크숍을 소개합니다. - VCNC Engineering Blog

VCNC 에서는 최근에 모빌리티 서비스 이동의 기본 타다를 출시했습니다. 신규 서비스를 준비하면서 팀도 새롭게 구성되고 새로운 멤버들이 팀에 합류했습니다. 이러한 변화 속에서도 좋은 개발 문화를 유지하기 위해서 VCNC 개발팀은 큰 노력을 하고 있습니다. 그중에서도 모두가 자랑하고 싶어 하는 VCNC 개발팀 워크숍을 소개합니다.VCNC 개발팀 워크숍최근 VCNC 개발팀 워크숍은 2018년 12월 19일 수요일에 진행되었습니다. 2016년 12월 처음 시작해서 최근까지 총 6번의 워크숍이 열렸습니다. VCNC 가 SOCAR에 인수되어 타다 서비스를 바쁘게 준비했던 2018년 8월을 제외하고 1년에 3번씩(4, 8, 12월) 꾸준히 개최되고 있습니다.VCNC 개발팀 워크숍은 개발팀 멤버들이 업무 외적으로 가지고 있던 각자의 관심사들을 공유하고 개발자들이 할 수 있는 고민을 같이 나눠보기 위한 욕구에 의해 처음 제안되었습니다. 포맷을 어떻게 할지 논의한 끝에 아래와 같은 포맷으로 워크숍을 진행하기로 했고 최근까지 이 포맷으로 워크숍을 진행하고 있습니다.오전 시간에는 모든 멤버가 각자의 관심사에 대해 5~10분 정도로 가벼운 라이트닝 톡을 하자.오후 시간에는 토의 주제를 정해서 몇 가지 깊은 토의를 나눠보자.회사의 업무에서 완전히 벗어나서 집중하기 위해 프로젝터 사용이 가능한 외부 카페를 대관하자.고기 회식을 하자!2018년 12월 제 6회 VCNC 개발팀 워크숍 단체 사진라이트닝 톡라이트닝 톡은 위에 언급했던 대로 모든 멤버가 5~10분 정도의 시간 동안 각자의 관심사에 대해서 다른 멤버들에게 소개하는 시간입니다. 발표 주제는 처음에는 개발로 한정 지었다가 더 폭넓게 관심사를 공유하기 위해 자유 주제로 변경했습니다. 다들 워크숍 전날까지는 어떤 발표를 해야 할지 걱정하며 투덜대지만, 막상 워크숍 당일이 되면 굉장히 흥미로운 주제들을 가지고 참여를 합니다. 라이트닝 톡이라는 의미에 맞게 1회 워크숍에서는 타이머를 켜고 시간 체크를 하면서 간단하게 발표를 했습니다. 그런데 기대했던 것보다 훨씬 좋은 발표들이 나오면서 발표 시간을 유동적으로 해서 발표의 퀄리티를 더 높이기로 했는데, 바로 다음 워크숍에 1시간 10분짜리 장대한 강의가 등장하는 바람에 절제의 중요성을 다시금 느끼면서 다시 타이머를 켜기로 했습니다…2017년 12월 워크숍에서는 PB팀이 상품 협찬을 해줘서 (PB팀 감사합니다!) 최고의 발표를 선정해 밀크 미니 인형을 지급했습니다. 영예의 수상자는 욕망의 흐름 이라는 발표를 정말 욕망의 흐름대로 발표한 Max로 선정되었습니다.<iframe src="https://docs.google.com/presentation/d/e/2PACX-1vQChBaARqlj8XfZx75MtkcejwupwBPt9tgD47sL99L1mHceYnPR2yDJnVAKFq8nFHXG9Pc9QbWBA5Eb/embed?start=false&loop=false&delayms=10000" frameborder="0" allowfullscreen="true" mozallowfullscreen="true" webkitallowfullscreen="true"> 지금까지 워크숍을 6회나 진행했기 때문에 상당한 양의 라이트닝 톡 발표자료들이 모였습니다. 그중에서 몇 가지 발표의 슬라이드를 공유합니다.Glitches of Mario by PrinceOrigami - 종이접기와 수학 by PrinceLattice-based Cryptography by BradTADA-Android 회고 by David기반 작업들을 무엇을 했는가? + RIB 간단 설명Contract by DoogieAd Fraud by HughBB84 - 양자 역학을 이용한 절대적으로 안전한 키 분배 프로토콜 by James불완전성 정리 by James삼단논법 by JamesGAN by MaxReinforcement Learning based on AlphaGo by NelsonSteganography by Nelson재귀의 폭풍 by TedUBER: COSTS & REVENUES by TerryProbabilistic Filter by Youngboom다음 워크숍부터는 발표를 녹화해서 슬라이드와 함께 공유해보도록 하겠습니다.최고의 발표로 선정된 Max종이접기로 각의 3등분선 구하기 실습필자의 발표를 경청하는 멤버들디스크의 위험성을 온몸으로 표현 중 심층 토의VCNC 개발팀 워크숍에서는 회사의 주요 결정사항 혹은 공통으로 관심이 있는 이슈들을 선정해서 모두의 의견을 듣고 공감대를 형성하거나 액션 플랜을 세우는 토의를 진행합니다. 토의의 주제는 발전적이고 열린 커뮤니케이션을 지향하는 멤버들의 특성상 회사 생활 과정에서 자연스럽게 형성됩니다. VCNC 에서는 평소에도 서로의 의견을 공유하는 자리를 자주 가집니다. 그 예로는 매 달 진행하는 매니저와의 1:1 개인 리뷰 제도, 각 팀별 주간 회고 회의, 제품 피쳐 개발 단위로 진행하는 회고 회의 등이 있습니다. 이러한 의견 공유 과정에서 멤버 각자가 생각하는 불만, 문제점, 희망 사항들이 자연스럽게 워크숍의 토의 주제로 발전됩니다. 토의는 특별한 절차 없이 모든 구성원이 자연스럽게 끼어들면서 자신의 의견을 펼치며 진행됩니다. 모두의 의견을 듣는 것이 중요하기 때문에 특별한 주제가 아니라면 적은 인원으로 조를 구성해서 토의한 뒤 의견을 취합합니다. 정리한 내용은 제품팀 및 HR 담당자에게 전달되며 그 후 우리가 해볼 수 있는 시도들을 하거나 새로운 회사의 정책들이 생겨나기도 합니다.둘러앉아서 토의에 집중하는 멤버들 (편안한 자세 가능)아래의 항목들은 실제로 진행했던 토의의 주제들입니다.순수 개발 관련점차 높아지는 개발 복잡성을 어떻게 해결할까?서버-클라 간 프로토콜 문서화 문제제품 개발 프로세스 관련제품 개발 프로세스를 스프린트에서 칸반으로 변경하고 지금까지 겪었던 느낀 점, 문제점 및 해결 방안은?이슈 관리가 잘 안 되는데 원인 및 해결책은?QA가 필요한가? 제품 품질을 높이기 위해선 무엇을 해야 하는가?회사의 문화, 복지 등 전반회사에서 팀 간 커뮤니케이션을 원활하게 하기 위해 Manager 제도가 도입되는데 Manager 는 어떠한 역할을 맡아야 하는가?Manager 제도의 후기 공유 및 개선 방향.어떠한 모습의 회사를 원하는가?필요한 사내 문화 및 복지는 무엇이 있을까?개인의 발전 관련언제 동기부여가 되는가? 저하되게 만드는 요인은?어떠한 사람과 같이 일을 하고 싶은가?어떠한 모니터링 및 피드백을 받고 싶은가?VCNC 개발팀 워크숍의 토의 결과로 회사의 많은 부분이 발전하고 있습니다. QA 팀이 생겼고 해외 및 국내 콘퍼런스 지원 관련 복지 정책이 새로 생겼습니다. 제품 개발 프로세스는 새로운 시도를 거치면서 지속해서 발전해 나가고 있습니다.그 외우걱우걱워크숍에는 풍족한 먹을거리가 함께합니다. 카페를 대관하는 경우에는 무제한으로 음료가 제공되며 점심시간에는 배달을 시켜서 먹으면서 함께 이야기를 나눕니다. 마무리로 저녁에는 고기를 먹고 싶은 만큼 맘껏 먹으면서 역시 이야기꽃을 피웁니다.미니게임워크숍의 포맷이 라이트닝 톡 + 심층 토의 조합으로만 진행되어 느껴지는 지루함을 탈피하기 위해 2018년 4월 워크숍에서는 2인 1조로 팀을 구성해서 미니게임을 진행했습니다. 개발자 감성에 걸맞게 스크래치 게임인 Lightbot 2로 1시간 정도 플레이를 했습니다. 승패가 있는 대결은 아니었지만 다들 피로감을 호소할 정도로 엄청나게 집중하면서 시간을 보냈습니다.워크숍의 핵심은 고기를 굽는 것점심에는 피자를 시켜 먹으며 자유로운 대화를 나눕니다.집중해서 Lightbot 을 플레이하는 플레이어휴식 중에도 즐거운 대화는 계속됩니다. 마치며VCNC 개발팀 워크숍은 앞으로도 계속됩니다. 앞으로도 좋은 회사의 문화를 소개하는 기회를 자주 만들도록 노력하겠습니다. 저희와 함께 VCNC 를 발전시킬 좋은 분들을 기다리고 있으니 많은 지원 바랍니다!
조회수 1693

경험 부족한 스타트업의 devops 도입기 3편

칸반과 스크럼을 섞은 I/O 트렐로 보드코드리뷰코드리뷰를 말씀드리기 전에 I/O의 개발 프로세스부터 소개해 드리겠습니다. 저희 SW 엔지니어들은 칸반보드를 일주일 주기(sprint)로 진행해 나갑니다. devops 도입을 위해 이 개발 프로세스를 설계 하였는데요. Sprint 주기인 working day 5일 동안 이번 주안에 개발을 끝내야 하는 feature 1개와 지난 주에 개발을 마친 feature 1개의 알파테스트 그리고 지지난 주에 개발된 feature 1개의 베타테스트가 동시에 진행됩니다. 즉, 3개의 phase 가 매순간 공존하는 프로세스 입니다.코드리뷰 도구로는 bitbucket의 pull request를 사용하기로 했습니다. I/O에 있는 5명의 SW 엔지니어들은 각자 필수로 리뷰 받야할 짝꿍이 정해져 있습니다. Sprint동안 개발한 피쳐 혹은 hotfix를 merge(배포)하기 위해서는 반드시 pull request과정을 거쳐야합니다. 즉, 짝꿍을 포함한 최대 4명에게 pull request를 요청할 수 있습니다. Sprint동안 개발된 feature는 가급적 매주 목요일에 pull request하기로 하였으며 SW엔지니어들은 목요일엔 코드 리뷰 시간을 할애해 두기로 약속 했습니다.이러한 개발환경 아래 지난 2주간 제가 기억하는 pull request는 4개 였습니다. 총 review해야할 commit 수가 22개로 평균 pull request당 5.5개의 commit 을 리뷰해야 했습니다. 알파테스트에서 발생한 마이너한 hotfix는 pull request없이 merge된 걸로 알고 있어 제가 놓친 commit들도 존재 했습니다. Jira로 Ticket 관리를 안하다보니 위에 첨부된 이미지 처럼 Trello 카드링크가 카드의 제목(유즈케이스)으로 나오지 않아 조금 불편하기도 합니다.Pull reqest에 달린 Comment들.일단, bitbucket으로 코드리뷰를 2주간 진행 해보니 엔지니어간의 유대감이 생기는 느낌이 들었습니다. 그 전에는 구현상의 이슈를 이야기 나누는 수준에서 머물렀는데 이제는 서로가 직접 짠 코드를 공유하다보니 확실히 느낌이 달라졌습니다. 처음으로 목욕탕을 함께 다녀온 친구가 된 느낌이랄까요… 저만 그렇게 느꼈을 수도 있구요. 확실한 건 엔지니어마다의 개발 스타일을 파악할 수 있게되어 엔지니어와 대화할 때 상대방의 스타일에 맞춰서 낭비가 적은 커뮤니케이션을 수행할 수 있게 되었습니다.Exception Hadling feedbackMagic Number feeback뿐만아니라 위의 이미지 두 장 처럼 개발상의 안좋은 냄새를 리뷰과정에서 감지하여 개발자에게 바로바로 피드백해 줄 수 있었습니다. 물론, 좋은 개발 방식이나 설계내용을 배울 수도 있었구요.TDD(테스트주도개발)테스트주도개발의 개발 리듬 : 출처 : 구글 이미지 검색Sprint의 feature scope을 극단적으로 작게 줄여버리니 TDD 공부에 엔지니어들이 매진했습니다. 각자 포지션에 맞는 책을 하나씩 끼고 충분히 TDD을 깊게 파고 들어갔는데요. 결과적으로 안드로이드, iOS 엔지니어는 4주만에 TDD의 기본기를 확실하게 다질 수 있었습니다.안드로이드 엔지니어의 경우 최근 2주 동안 정말 놀랍게 성장했는데요. 지난 I/O diary 8에서 소개된 안드로이드의 switcher sorting 클래스는 SUT로 만들기 쉽지 않은 legacy class였습니다.그러나, 안드로이드 엔지니어가 켄트백의 TDD 책을 14장까지 정독하면서 상황을 완전히 뒤바꿔 버렸습니다. 예제로 나오는 통화 프로그램을 한 줄 한 줄 키보드로 직접 따라 쳐가며 긴호흡으로 책을 정독함으로써 자연스럽게 객체지향으로 변해가는 설계 리펙토링 원리를 피부로 체험할 수 있었는데요. 그덕에 지난 주에 진행된 소프트웨어 세미나에서 공개된 리팩토링된 switcher sorting 클래스 로직은 보기좋게 간결해졌습니다. 기존 코드의 test함수는 switcher sorting 클래스의 많은 기능을 1개의 테스트 함수에서 다 집어 넣고 검증하려다 보니 함수 길이가 50줄 이상 되어 가독성이 무척 떨어졌었는데요. 그러나, 리팩토링된 test class에는 약 5개의 test 함수(setup, teardown 제외)로 적절하게 나뉘어 리뷰어가 참 읽기 좋게 코드가 작성되었습니다. 각 test 함수도 적당한 길이로 짜여서 테스트 코드를 읽으면서 자연스럽게 설계의도를 파악할 수 있었습니다. 이렇게 단시간에 TDD를 체화한 엔지니어니어들을 보면 신기할 따름입니다.느낀점출처 : 구글 이미지 검색devops가 성공적으로 도입되려면 당분간은 완급조절이 핵심인것 같습니다. 새로운 것을 마구잡이로 도입하기보다 지금은 코드리뷰와 TDD에만 집중 할 수 있도록 팀환경을 만들어 줘야 할것 같습니다. 지난 6월 1주차에는 제가 scope 조절에 실패해서 개발 phase의 feature가 무지 무거웠습니다. 그로인해, 안드로이드 엔지니어는 테스트코드를 짤 여유가 없었습니다. 제 실수로 결국 기술부채가 쌓이고 말았습니다. 당분간 기술부채를 털어내기로 해놓고 말과 행동이 다른 사람이 되어버렸습니다. 6월 30일까지는 조바심 내지말고 TDD와 코드리뷰가 몸에 완전히 익을 때까지 feature scope가 충분히 작게 설정되도록 신중에 신중을 가해야할 듯합니다. 과도한 업무량에 좇겨 엔지니어들이 Test code coverage가 낮아지거나 코드리뷰 없이 코드가 배포되지 않도록 팀 완급조절에 지속적으로 관심을 쏟아야 겠습니다.#스위쳐 #Switcher #DevOPS #데브옵스 #개발 #개발자 #문제해결 #도입기 #인사이트
조회수 1619

Java의 json 라이브러리 google-gson

문제 상황안드로이드 어플리케이션을 개발하다 보면 주소록을 다루는 일이 종종 있습니다. 어플리케이션에서 주소록에 관련된 정보를 접근할 일이 있는 어플이라면 ContentResolver를 통해 단말의 주소록에 접근해서 필요한 정보를 가져오게 됩니다.그런데, 최근 개발하고 있는 스포카 어플을 통해 아주 많은 사람의 연락처가 저장된 주소록을 가지고 이런 저런 로직을 실행하는 상황을 테스트 하다보니, OutOfMemory(OOM)에러가 발생하는 현상을 볼 수 있었습니다. 모바일 디바이스들은 PC와 다르게 자원이 제한적이기 때문에 어떻게 하면 OOM을 일으키지 않을 수 있을까 라는 고민을 해야 하는 상황이었습니다.대강 문제가 되었던 클라이언트 사이드의 로직을 살펴보면 이렇습니다.단말의 주소록에 접근하여 필요한 정보를 추출 후 서버에 전송서버에서 정보를 가공하여 필요한 json 문자열을 생성 후 반환, 이 문자열은 주소록에서 보낸 정보의 양에 비례해서 늘어나게 됩니다.클라이언트 측에서 서버 측에서 보낸 json 문자열을 이용하여 JSONObject객체를 만든 후 이 JSONObject를 이용 리스트 완성eclipse의 MAT(Memory Analyzer)을 이용하여 어느 시점에서 OOM이 일어나는지를 추측해보았습니다. 서버에서 보내준 json형식의 문자열을 HttpURLConnection을 통해 전달받고 이를 StringBuilder를 이용하여 완전한 문자열으로 만들던 도중에 OOM이 일어나는 것으로 의심되었는데 이 때문에 JSONObject의 생성자에 json 문자열을 전달하기도 전에 메모리가 가득 차 버리니 매우 난감한 상황이었습니다.대게 주소록에 사람이 그렇게 많지 않으므로 (200~500명 정도) 아무런 문제가 없었지만 10000명 정도의 더미데이터를 주소록에 저장하고 테스트하다 보니 append 메서드를 호출하다 OOM에러를 뱉으면서 어플이 종료되었습니다. 문제는 append 메서드를 호출 시 StringBuilder의 capacity를 넘을 경우 내부적으로는 메모리 재할당과 copy과정이 일어난다는 것이었습니다. 그렇다고 초기 StringBuilder생성시 capacity를 무작정 높게 잡기도 애매한 상황이었습니다.gsongson은 Java객체를 json형식으로 변환하고 그 역으로도 변환할 수 있도록 도와주는 라이브러리입니다. gson의 사용법이 궁금하다면 gson user guide를 읽어보면 되고 api가 궁금하다면 gson api document를 참조하면 됩니다.gson 적용대략 이런 방식으로 프로젝트에 gson라이브러리를 적용하였고, HttpURLConnection을 통해 받아온 InputStream을 이용 바로 객체를 생성할 수 있었습니다. 이전에 StringBuilder를 이용할때 생기는 오버헤드가 사라진 셈이죠. 위와 같은 방식으로 OOM이 생기는 문제 상황을 해결 할 수 있었습니다.위의 예는 상황을 최대한 단순화하여 설명하려고 작성한 예제이고 이 사이트를 통해 더 상세하게 설명된 사용예를 보실 수 있습니다.#스포카 #개발 #개발자 #GSON #Java #인사이트 #google_gson

기업문화 엿볼 때, 더팀스

로그인

/