스토리 홈

인터뷰

피드

뉴스

조회수 1905

StyleShare 서비스의 구조

안녕하세요. 스타일쉐어에서 서버사이드 개발을 하고있는 김현준입니다. 스타일쉐어의 엔지니어링 블로그의 첫 글에서는 저희 서비스의 스택을 소개하도록 하겠습니다. 사실은 Instagram의 스택과 유사한 면이 많아 글 또한 많이 유사할 것 같네요.서버먼저 스타일쉐어는 서버의 운영 체제로 Ubuntu 12.04 (Precise Pengolin)를 사용합니다. 모든 서버는 아마존 웹 서비스(Amazon Web Services)의 Elastic Compute Cloud(EC2) 위에서 돌아가고 있습니다. 스타일쉐어는 EC2 이외에도 Simple Storage Service(S3)와 같은 AWS의 다양한 서비스를 사용하고 있는데요, AWS를 사용하는 가장 큰 이유는 유연한 확장성(Scalability)이라 말할 수 있을 것 같습니다. EC2의 서버는 모두 가상 머신이기 때문에 관리 콘솔에서의 쉬운 조작으로 서버를 끄고 켤 수 있을 뿐만 아니라, 장애가 생겼을 때도 간편하게 장애가 생긴 서버를 내리고, 새로운 서버로 대체할 수 있는 이점이 있습니다. 이 모든 기능은 API로도 제공되고 있기 때문에, 자동화도 가능합니다. 실제로 스타일쉐어에서도 웹 요청을 처리하는 웹 서버들과 작업을 처리하는 워커들에 대해서 오토-스케일러를 구현해 사용하고 있습니다.로드 밸런싱스타일쉐어의 웹 서버들은 AWS의 Elastic Load Balancing(ELB)에 등록되어 있어서 ELB가 수많은 요청들을 여러 서버들에게 차례로 나누어 보냅니다. 보내어진 요청들은 각각의 서버에서 nginx를 거치며 또 한번 여러 개의 프로세스로 분배되어 처리됩니다.웹 어플리케이션스타일쉐어의 웹 어플리케이션은 Werkzeug 기반의 웹 프레임워크 Flask와 ORM 프레임워크인 SQLAlchemy 위에서 Python으로 구현되어 있습니다.데이터스타일쉐어의 대부분의 데이터는 PostgreSQL에 저장되고 있습니다. 여러 대의 PostgreSQL 인스턴스의 풀링(Pooling)을 하기 위해서 pgpool을 사용합니다. 서비스의 성능 향상을 위한 캐싱 도구로는 Memcached를 사용합니다.스타일쉐어에 올라오는 사진들을 비롯한 대부분의 이미지들은 Key 기반의 스토리지인 AWS S3에 저장하고, 관리합니다. S3의 가장 큰 장점은 사용자가 용량 제한과 파티셔닝에 대해 신경쓰지 않아도 된다는 점일 것입니다. 앞으로도 무한히 많은 사진이 올라올 서비스를 만드는 저희로서는 아주 유용하답니다. 이미지 뿐만 아니라, 서비스를 배포할 때마다 만드는 패키지와 매일매일 데이터베이스 백업 모두 S3에 저장되어 있습니다.작업 관리대부분의 서비스와 마찬가지로, 스타일쉐어도 웹 어플리케이션 서버와 별개로 무거운 작업(Task)을 처리하기 위한 워커(Worker) 서버를 따로 구동하고 있습니다. 여기서 작업이란 계속해서 쏟아지는 웹 요청을 처리하기도 벅찬 웹 어플리케이션에서 처리하기에는 비교적 오래걸리는, 예를 들면 알림(푸시)과 메일을 보내거나, 이미지 프로세싱과 같은 일들을 이야기합니다. 이러한 작업들을 비동기적으로 처리하기 위해 저희는 Celery와 RabbitMQ를 사용합니다. Celery는 Python으로 구현된 비동기 작업 워커이고, RabbitMQ는 워커로 넘길 작업을 관리하는 AMQP 프로토콜 기반의 브로커(Broker) 큐입니다.오픈 소스?스타일쉐어 서버는 비동기 네트웍(asynchronous I/O)을 구현하기 위해서 gevent를 사용합니다. 그 외에 배포(deploy)를 위한 Fabric과 boto나, 내부 문서화를 위해 사용하는 Sphinx 등이 스타일쉐어에서 주로 사용하는 라이브러리/프로젝트 입니다.오픈 소스.위에 적은 것처럼, 스타일쉐어의 구현의 많은 부분이 오픈 소스 프로젝트에 크게 의존하고 있습니다. 훌륭하고 건강한 오픈 소스 생태계 덕분에 우리는 스타일쉐어를 훨씬 더 수월하게 만들고 지탱할 수 있었습니다. 그래서 저희도 도움을 받은 만큼 기여하고, 구성원으로서 더 나은 생태계를 만드려 합니다. 그 중 하나가 바로 이 스타일쉐어 엔지니어링 블로깅 활동이고, 다른 하나가 저희 팀의 오픈 소스 프로젝트 활동입니다. 스타일쉐어 팀의 오픈 소스 활동들은 StyleShare’s GitHub에서 살펴보실 수 있답니다. 여러분들의 관심어린 피드백과 기여도 언제나 감사히 환영합니다.그 외의 도구들스타일쉐어 실 서비스에서 발생하는 오류와 버그를 추적하기 위해 사용하는 Exceptional도 매우 유용합니다. Flask 프레임워크에서 Exceptional 서비스를 쉽게 이용할 수 있도록 도와주는 Flask 확장 모듈인 Flask-Exceptional이 공개되어 있습니다.함께해요저희와 비슷한 환경에서 개발하시는, 같은 도구를 사용하시는, 저희에게 도움을 주고 싶으시거나, 저희에게 (저희가 도와드릴 수 있다면) 도움을 받고 싶으신, 또는 그저 많은 이야기를 나누고 싶은 분들까지 많은 분들과의 소통과 교류가 많았으면 좋겠습니다. IRC를 하시는 분들은 오징어 네트워크(irc.ozinger.org)의 #styleshare-tech 채널로 놀러오세요.#스타일쉐어 #개발 #서버개발 #서버환경 #업무환경 #개발자 #인사이트
조회수 1633

Infrastructure dashboard

와탭랩스는 IT 서비스를 운영하는 개발팀과 운영팀에 도움이 되는 솔루션과 서비스를 만드는 스타트업입니다. IT 서비스를 잘 운영하게 위해서는 Infrastructure의 전반적인 상황을 항시 체크할 수 있어야 하는데요. 이런 기능을 하는 대표적인 화면이 대시보드 입니다. 최근 와탭랩스는 Infrastructure 모니터링 서비스에 대시보드를 넣는 작업을 진행하고 있는데요. 와탭랩스는 대시보드를 통해 Infrastructure를 운영하는 개발팀과 운영팀에 어떻게 도움을 줄 수 있도록 할 것인지 소개하겠습니다. 1. IT 서비스 운영에 사용된 인프라 자산 현황을 알아보자지금 회사에서 사용하는 서버의 대수를 알고 계신가요? 현재 동작하는 서버는 몇대인지 혹시 죽어있는 서버가 있는지 등에 대한 정보는 운영팀에서 항상 체크하는 정보입니다. 하지만 개발팀에서는 잘 모르는 정보이기도 하죠. 이런 기본적인 정보가 대시보드에 나온다면 평소 서비스를 운영하는 감을 잡는데 도움이 됩니다. 이런 정보들은 간략한 수치로도 표현할 수 있는데요. 우리는 아래와 같은 데이터를 수집할 수 있습니다. 서버 기본 정보 (inactive servers / all servers)우리가 사용하는 총 서버의 수자와 비활성화된 서버의 숫자는 우리가 항상 알고 있어야 하는 정보입니다.운영체계별 서버 정보 (Linux / Windows / Unix)운영체계를 섞어 사용하는 경우에는 운영체계에 따라프로젝트가 나눠지기도 합니다. 그렇기 때문에 운영체계별로 서버의 총량과 비활성화된 서버 정보를 알면 도움이 됩니다. 프로세스 수프로젝트의 프로세스 수는 일정한 경우가 많습니다. 전체 프로세스의 숫자가 변경된다면 서비스의 운영 상황에 대해 의문을 가져야 합니다. 이벤트 개수24시간동안 발생한 전체 이벤트의 개수와 아직 해결하지 못한 이벤트의 개수를 보여줍니다. 하루동안 얼마나 많은 이벤트가 발생하는지 그리고 아직 해결하지 못한 이벤트가 있는지 알수 있습니다. 디스크 사용량/전체 용량디스크 사용량은 일반적으로 큰 변화를 가지지 않습니다. 디스크 사용량이 평소와 다르다면 서비스의 장애가 발생했거나 발생할 가능성이 높습니다. 메모리 사용량 / 전체 용량메모리 사용량은 일반적으로 큰 변화를 가지지 않습니다. 메모리 사용량이 평소와 다르다면 서비스의 장애가 발생했거나 발생할 가능성이 높습니다. 수치 데이터의 예 2. 서비스를 구성하는 인프라의 CPU 흐름 전체를 알아보자 CPU 사용량은 변화량이 많은 지표입니다. 변화량을 비교하는 챠트로는 라인 차트가 가장 많이 쓰이지만 라인 차트는 개수가 많아지면 전체 상황이 보이지 않는 문제점을 가지고 있습니다. 또한 실시간으로 추가되거나 삭제되는 인프라가 생기는 클라우드 인프라 상황에서 라인챠트는 표현의 한계를 가지고 있기도 합니다. 이런 문제를 해결하기 위한 방법으로 아래와 같은 온도 차트를 사용할 수 있습니다. 온도 차트는 단위 영역에 밀도에 따라 색상으로 깊이를 표현하는 방식입니다. 최근 많은 양의 데이터를 표현하는 방식으로 많이 사용되고 있습니다. 온도 차트의 예3. 경고가 발생했는지 또는 해결 되었는지 알고 싶다.  CPU 사용량이 설정치 이상으로 높아지거나 디스크 사용량이 높아지거나 프로세스가 사라지는 등 다양한 상황에 대한 이벤트가 발생할 수 있습니다 이런 상황을 쉽게 확인할 수 있다면 서비스 운영 상황에 도움이 됩니다. 이벤트 관리의 예이런 스토리를 기반으로 와탭랩스에서 대시보드를 기획하고 있습니다. 개발자와 디자이너가 함께 토론하고 논의하면서 화면과 스토리를 더 다듬게 되면 첫번째 화면이 나올 예정입니다. 아래는 기획과정에서 나온 화면 리소스 입니다. 아직 기획 단계이기는 하나 첫번째 대시보드가 완성되면 이 페이지가 메인으로 올라갈 예정입니다. 대시보드는 데이타의 종류와 위치등을 수정할 수 있으면 좋지만 우선은 고정형으로 개발하여 제공할 예정입니다. 이번 대시보드는 서비스 첫번째 의미가 강한 메인 화면의 성격에 더 초점을 맞추고 있습니다. 아직 몇몇 논의되는 사항이 많은 화면이지만 빠르게 개발하여 가능한 이른 시일에 소개드리도록 하겠습니다. #와탭랩스 #개발자 #개발팀 #인사이트 #경험공유 #일지
조회수 4614

신입 개발자를 위한 코드의 정석

Overview대학을 수석으로 졸업했지만, 정작 회사에서는 A부터 Z까지 제대로 할 줄 아는 게 없었습니다. 실수를 남발할 때마다 느꼈던 좌절감은 아직도 생생하지만 되돌아보면 그때의 삽질이 소중한 피와 살이 되었지요. 오늘은 헤매고 있는 신입 개발자를 위한 글을 쓰려고 합니다. 신입 개발자, 당신! 내 이야기를 편하게 듣고 가지 않으실래요? 남을 위한 코드, 클-린 코드“너랑 같이 일하는 사람은 어떻게 보라는 거야?” “한 명이 짠 코드인데, 어째 한 사람이 짠 것 같지가 않다..” “이게 네 스타일이냐?” 대학생이었을 땐, 대부분 혼자서 프로젝트를 진행했습니다. 다른 사람이 제 코드를 보는 일도 거의 없어서 띄어쓰기나 들여쓰기 등에 통일이 없었고, 함수의 네이밍도 전혀 고려하지 않았습니다. 이게 나쁜 습관이었다는 걸 입사하고 알게 되었죠. 이 습관을 고치려고 코딩 컨벤션(coding convention)을 지키는 것에 꽤 오랜 시간을 들여야만 했습니다. 우리는 협업을 하는 사람들입니다. 사람들이 더러운 방보다 깨끗한 방을 좋아하는 것처럼, 당신과 협업하는 개발자도 보기 어려운 코드보다 깨끗한 코드를 더 좋아합니다. 클린 코드를 작성하기 위한 세 가지 기본 원칙을 잠시 소개합니다. 클린 코드를 위한 세 가지 기본 원칙 코드를 최초로 작성한 사람이 끝까지 유지보수를 한다는 보장은 없다.이미 잘 정리된 코드는 효율성이 증가한다. 정리할 시간에 코드 한 줄을 더 분석할 수 있으니까!리팩토링은 미루었다가 한꺼번에 하는 것이 아니다. 코드를 작성하는 매순간 함께 하는 활동이다.작은 것 하나부터 습관을 들여보세요. 분명 깔끔하고 보기 좋은 코드를 만드실 수 있을 겁니다. 머지 않아 “남을 위한 코드는 곧 나를 위한 코드”라는 것도 알게 될 거고요. 책의 한 구절이 떠오르네요. “우리는 저자이다. 저자에게는 독자가 있다. 그리고 저자에게는 독자와 잘 소통해야할 책임이 있다.”⌈Clean Code⌋의 저자, Robert C. Martin 설마가 사람 잡는다, 철저한 검증만약 누군가 검증 단계에서 잊지 말아야할 것이 뭔지 묻는다면 이렇게 대답하고 싶습니다. “절대 사용자가 입력한 값을 신뢰하지 말라. 프론트엔드에서도, 백엔드에서도.” 모든 사용자가 각 항목에 맞게 올바른 정보만 입력해준다면 얼마나 좋을까요? 세상에는 다양한 사용자가 있습니다. 너무 바빠서 얼른 회원가입을 해야하는 사용자는 항목을 채우지도 않고 신청 버튼을 누를 수도 있습니다. 영어로 입력해야 하는 항목엔 한글을 입력한 사용자도 있을 겁니다. 이런 휴먼 에러(human error)뿐만 아니라 의도적으로 비정상적인 요청을 시도하는 사용자도 분명 있습니다. 이 때문에 개발자는 기능에 대해 항상 검증해야 합니다. 바로 이렇게요!그런데 프론트엔드에서 유효성 검사를 하면, 백엔드에는 유효한 값만 넘어온다고 보장할 수 없습니다. 자바스크립트는 브라우저 엔진에 따라 다르게 동작할 수도 있습니다. 또 자바스크립트에서 다루는 값들은 크롬의 개발자도구(option + command + i)를 이용하면 얼마든지 값을 변조하거나 검증을 회피할 수 있습니다. 또 불온한 시도가 아니더라도 다양한 예외 케이스들이 존재하기 때문에 백엔드에서도 무조건 검증해야 합니다.페이스북 페이지의 개발자 도구를 열었을 때 노출되는 화면입니다. 얼마나 나쁜 사람들이 많으면 경고화면까지 만들었을까요?누군가 질문할 수도 있겠군요. “프론트엔드의 검증이 의미가 없다면, 백엔드에서만 검증을 해도 되지 않을까요?” 네, 아닙니다.(단호) 많은 양의 일을 한꺼번에 하는게 힘든 것처럼 무분별한 요청이 서버에 쏟아지면 서버도 사람처럼 지치고 말 겁니다. 응답이 느려지는 등의 문제가 생길 수도 있고, 결국 사용자가 불편해질 것입니다. 그러므로 가장 좋은 검증 방식을 3단계로 정리하면 아래와 같습니다. 고수가 되는 검증 방식 3단계프론트엔드에서 먼저 값 검증을 하여 빠른 사용자 경험을 제공한다.백엔드에서 다시 한 번 더 검증을 거쳐 상황에 적절한 응답 코드를 내려준다.프론트엔드는 상황에 맞게 적절한 UX와 메시지를 보낸다. 동작 그만! 정리는 하고 코딩하자!예전에는 요구사항이 있으면 바로 키보드 위에 손부터 올렸습니다만, 그건 좋은 태도가 아니었습니다. 팀장님이 “이 경우엔 어떻게 하지?”라고 질문하면 아무 대답도 하지 못했기 때문이죠. 팀장님은 늘 “항상 먼저 생각하고 코딩하자!“라고 조언하십니다. 맞습니다. 최대한 모든 경우의 수를 머릿속에 정리하고 코딩을 시작해야 합니다. 시간이 없다는 핑계로 무작정 시작하면 분명 문제가 발생합니다. 또 구현할 기능만 몰두하지 말고, ‘이 기능이 다른 기능에 영향을 미칠 수 있을까?’를 고민하면 훨씬 좋은 코드를 만들 수 있을 겁니다. “이런 거 다 생각하고 짜면 도대체 코딩은 언제 하라고?” “얼른 선임 분들에게 코딩하는 내 모습을 보여줘야 하는데!” “당장 코드 안 짜고 있으면 노는 것처럼 보이지 않을까?” 혹시 이런 생각을 하고 계신가요? 나도 그런 생각을 했던 적이 있습니다. 하지만 요구사항을 확실하게 정리한 후, 코드를 짜는 게 더 효율적입니다. (그렇지 않으면.. ‘수정’이란 이름 아래 모든 것을 뒤엎고 처음부터 다시 시작해야할 수도 있습니다.) ‘더 나은 개발자가 되는 8가지 방법(8 Ways to Become a Better Coder)’이란 글에는 이런 내용이 있습니다. “동작하는 코드는 끝이 아니라 시작이다.” 신입 개발자는 종종 요구사항에 따라 동작하는 코드만 짜면 된다고 여길 때가 있습니다. 물론 사회생활에 적응하느라 정신 없는 와중에 그나마 자신의 코드가 요구사항대로 동작하면 무척 뿌듯할 겁니다. 하지만 동작만 한다고 절대 지나치지 말아주세요. 위에서 언급한 것처럼 깨끗한 코드가 되도록 리팩토링을 하고, 검증하고, 동작이 제대로 되는 것인지 의심하면서 꾸준히 노력해야 합니다. 마지막으로 항상 중요하게 생각하는 문장 하나를 남기고 글을 마치겠습니다.“진정으로 훌륭한 프로그래머는 적극적으로 어디가 잘못되었지를 찾는다. 자기가 놓친 결함은 결국 ‘사용자’가 발견하게 된다는 것을 알고 있기 때문이다.” Esther SchindlerConclusion지금까지 다룬 내용은 결국 같은 맥락입니다. 모든 개발조직은 좋은 품질의 소프트웨어를 개발할 줄 아는 개발자, 협업할 줄 아는 개발자를 원합니다. 누군가 “당신은 잘 지키고 있는가”라고 질문한다면, “저 또한 노력하고 있습니다.”라고 답변하고 싶습니다. 같은 자리에 머무르는 개발자가 될 것인지, 부족함을 알고 항상 배우고 나아가는 개발자가 될 것인지는 스스로의 몫이라고 생각합니다. 이 글을 끝까지 읽은 신입 개발자 당신! 같이 노력하지 않으실래요? :-) 참고 Robert C. Martin, 「Clean Code」, 케이엔피북스(2010)Esther Schindler, 8 Ways to Become a Better Corder, New Relic, 2018.03.02.유석문, 「프로그래머 철학을 만나다 - 소프트웨어를 사랑하는 기술」, 로드북(2014)임백준, 「읽기 좋은 코드가 좋은 코드다」, 한빛미디어(2012)팀장들이 꼽은 신입 PHP 개발자가 가급적 빨리 알았으면 하는 것들프론트에서”만” 유효성 검사가 문제인 경우남을 위한 코드 만들기 - 클린코드글김우경 대리 | R&D 개발1팀kimwk@brandi.co.kr브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유
조회수 1444

Humans of TODAIT : 전설의 전성윤을 만나다

‘Humans of TODAIT’의 두번째 주인공, 투데잇 안드로이드 개발자 전성윤을 만나봤습니다. 투데잇의 전설(★)이 된 그의 이야기를 함께 들어볼까요?(2016.08)✓ 전설윤, 그는 누구인가Q. 자기소개 부탁드려요.안녕하세요! 투데잇에서 안드로이드 개발자를 맡았던 전성윤입니다. 퇴사자 인터뷰를 하려니까 투데잇을 떠나는 게 정말 실감나네요. 작년 2015년 10월 경, ‘SW 마에스트로’ 과정에서 만난 분께서 대표님을 소개해주셨고, 좋은 인연으로 연결되어 투데잇과 함께 일하게 되었어요. 처음엔 안드로이드 개발자로 들어왔다가 지금은 안드로이드 개발 팀장직까지 맡고 있습니다. (당시 2016.08)Q. 투데잇을 떠나는 이유는 무엇인가요?사실 처음 입사할 때도 1년 정도 생각하고 있었어요. 일하다보니 투데잇이 너무 좋아져서 나가고 싶지 않았지만, 아무래도 군문제와 학교 복학 문제가 마음에 걸리더라고요. 그래서 여러 고민 끝에 할 수 없이 나가게 된 케이스예요. 결국 아쉽지만 이번 8월을 마지막으로 투데잇과 헤어지게 되었죠.Q. 별명이 전설윤이라고 하던데, 왜 전설이라고 불리는 건가요?저도 이번 인터뷰를 통해서 생각해보게 된 건데요. ‘전설’이라는 칭호가 지금은 한물 간 사람에게 붙는 것이 아닌가 싶어요. 다른 팀원분들이 들어오시게 되면서 자연스럽게 리즈시절이 지나게 되었죠. (웃음)다른 이유가 아니라, 혼자만 잘하는 것이 아닌 다 함께 잘하기 위해 애썼기 때문인 것 같아요. 업무에 있어 버려야 할 습관 같은 작업 처리 팁에 대해 새 팀원분들께 적극적으로 공유했고 적당한 선에서 체크해드렸어요. 7–8개월의 짬 덕분인지 기획 단계에서부터 개발 단계 때 준비할 것들이나 구현 방법들이 곧장 떠오르는 경지에 이르더라고요. 이런 점들이 다른 팀원분들이 좋은 퍼포먼스를 낼 수 있게 이끌어주는 역할을 했던 것 같아요. 또 그 분들도 잘 하는 방법에 대해 치열하게 고민했고 실제로도 다들 너무 잘해주셔서 결론적으로 이제는 혼자가 아닌 다 함께 잘하게 된 거죠.✓ 보안 전문가에서 투데잇 안드로이드 팀장으로 레벨 업!Q. 투데잇 안드로이드 팀장까지, 성윤님의 입사 초반부터 지금까지 업무 성장과정이 듣고 싶어요!입사 초기에는 솔직히 맘고생 많이 했어요. 내가 지금 당장 회사에 기여할 수 있는 점이 무엇일까 의욕적으로 많이 고민했지만, 그에 비해 개발 능력은 많이 떨어졌죠. 초기에는 무엇보다 제 개발 능력 수준에 대해 정확히 몰랐고 커뮤니케이션하는 방법이 미숙했던 것 같아요. 그 때마다 대표님, 개발팀장님께서 진심어린 피드백과 따끔한 조언을 계속 해주셔서 해결할 수 있었죠. 두 분의 노력덕분에 중반부터는 업무 처리 능력도 커뮤니케이션 능력도 많이 향상됐어요,이후에 본격적으로 개발자분들이 더 들어오고 협업이 시작되면서 1인 개발자에서 2인 개발자 체제로 바뀌게 되었고, 자연스럽게 그에 따른 새로운 이슈들이 생길 수 밖에 없었어요. 다른 개발자분들에게 업무 분담하고 리드하는 부분에서 어려움을 느꼈지만, 함께 잘 해결해나갈 수 있었죠 지금은 기획적인 틀을 잡고 누군가에게 일을 맡기고 내 일을 해내고 하는 여러 부분에서 팀장의 위치에서 역할을 잘 해내는 것 같아요. (웃음)Q. 그렇다면 특별히 힘들거나 어려웠던 일정은 무엇이 있었나요?되게 좋은 질문이에요! 전 개발자다보니까 이런 질문이 너무 좋네요. (웃음)구매페이지와 그룹 기능 작업이 좀 힘들었어요. 그 중에서도 프로버전 구매페이지 작업이 가장 힘들었는데요. 작업 자체가 힘들다기보다는 구매페이지에서 에러가 나면 유저의 신뢰도에 큰 영향을 주기 때문에 한치의 실수도 용납되지 않는 부분이라는 점이 부담이 됐죠. 처음엔 실수도 많았는데, 그 이후에 치밀하게 설계한 덕분에 두 번째부턴 버그가 터져도 바로 대처할 수 있었어요. 개인적으로 개발적으로 많이 성장한 느낌을 받았죠.그룹 기능 개발은 클라이언트 쪽에서 해결해야 하는 부분이 많아서 힘들었어요. 하지만 릴리즈 이후 유저분들이 격렬하게 환호해주신 덕분에 뿌듯하게 잘 마무리할 수 있었죠. 두 작업 다 힘들었지만, 굉장히 보람됐던 작업으로 기억에 남아요.Q. 유저들의 피드백을 보면서 얻은 게 많다고 하던데, 좀 더 말해주세요!“실제 유저와 소통하고 친근한 서비스를 제공하려고 노력하다보니 유저들의 피드백이 얼마나 소중한 건지 알게되더라구요.”투데잇을 다니기 전까지만 해도 저는 별 5개 짜리 리뷰가 당연하게 받아야할 칭찬이라고 생각했어요. 그래서 사실 크게 반응하지 않았었는데, 실제 유저와 소통하고 친근한 서비스를 제공하려고 노력하다보니 유저들의 피드백이 얼마나 소중한 건지 알게되더라구요. 당연히 좋은 피드백은 정말 힘이 많이 되었고, 좋지 않은 피드백도 굉장히 감사했어요. 사실 유저 입장에서 그냥 지워버리면 그만인건데, 우리 앱의 장점을 알아봐주시고, 개선할 점을 말해주시고 또 기다려주시는 거잖아요. 그런 유저분들 보면서 빨리 개선해드리고 싶단 생각이 들죠. 그 어떤 피드백보다 더 큰 동기부여가 되더라고요.✓ 투데잇 TALK“투데잇팀은 서로 부담없이 정말 효율적으로 커뮤니케이션을 해서 어떻게 하면 서로의 업무 컨텍스트를 빠르게 마무리할지 고민해요.”Q. 투데잇의 힘은 이거다!음 투데잇의 힘은 서로를 존중하고 커뮤니케이션을 중시하는 데에서 나오는 것 같아요. 결국 모든 문제의 결착점은 커뮤니케이션이거든요. 사소한 거라도 시기에 맞춰서 커뮤니케이션이 되어야 하는데, 개발팀과 비개발팀간의 커뮤니케이션이 사실 어렵잖아요. 하지만 투데잇팀은 서로 부담없이 정말 효율적으로 커뮤니케이션을 해서 어떻게 하면 서로의 업무 컨텍스트를 빠르게 마무리할지 고민해요. 누군가 못한 부분이 있더라도 절대 무시하지 않고, 서로의 업무를 존중하고 정식적으로 피드백을 공유하면서 문제를 잘 해결하기 위한 고민을 하죠.Q. 투데잇에서 제일 기억에 남는 순간이 있다면?투데잇에서는 많이 힘들었을 때부터 행복했을 때 그리고 소소한 일상들까지 전부 다 기억에 남아요. 워크샵이라고 가평에 가서 일한 적이 있었는데, 정말 놀지도 못하고 거의 일만했거든요. 근데 밖에 나와서 그런지 그 자체가 너무 재밌었어요. 일하면서도 되게 색다르고 즐거웠죠. (웃음) 제주도로 워크샵 갔을 때도 너무 재미있었고, 정말 매일 매순간이 기억에 남아요. 팀 분위기가 너무 좋아서 그런지 특별한 일들 뿐만 아니라 개발팀 회의할 때나 회사 메신저에서 웃고 떠들고 했던 것들처럼 아주 소소한 일상들까지 모두 에피소드였던 것 같아요. 깜짝 생일파티도 그렇고 되게 예정없이 나온 에피소드가 많았거 든요. 그런게 진짜 참된 에피소드 아닐까요?✓ 마지막으로…Q. 애정이 컸던 만큼 투데잇을 떠나기 많이 아쉬울 것 같아요.네 많이 아쉽죠. 전 투데잇에서 10개월 동안 정말 하루종일 개발만 했어요. 일 하는 게 너무 좋아서 거의 자취하다시피 야근도 매일 했었거든요. 좋아하는 사람과 좋은 분위기에서 재밌게 일하기도 했고, 또 어떤 목표를 이루기 위해 정말 치열하게 고민하고 일할 수 있었는데 이 부분들을 더이상 느끼지 못한다는 점이 많이 아쉬워요.음 아쉬운 사건을 말하라면, 맨 처음으로 앱 안에 코틀린을 적용해볼 때 너무 시간을 오래 끌었던 일이 있었어요. 잘 적용시킬 방법에 대해 혼자 고민하고 정리해보다가 늦어졌었는데, 다른 분들 일정에 피해를 준데다가 실수도 한두개가 아니었거든요. 그 때 제가 계획대로 잘 처리했으면 마케팅적으로나 여러 시도들을 해볼 수 있지 않았을까?하는 아쉬움이 들죠. 결국 개발자가 세운 일정에서 해내는 여부에 따라 회사에 큰 영향이 가고, 다른 팀에도 막대한 영향이 갈 수 있다는 걸 뼈저리게 깨달았어요. 그래도 이 사건 덕분에 업무적으로도 많이 성장할 수 있었던 것 같아요. 몸소 당해봤으니 그럴 수 밖에 없죠. (웃음)Q. 투데잇을 떠나며 마지막으로 하고 싶은 말이 있다면?“충분히 치열하게 일했고 다함께 즐겁게 소통하면서 일했기 때문에 언젠가 또 다시 만나지 않을까 싶어요.”개인적으로 아쉬운 점은 있지만, 충분히 치열하게 일했고 다함께 즐겁게 소통하면서 일했기 때문에 언젠가 또 다시 만나지 않을까 싶어요. 모든 투데잇 사람들과 연을 이어가고 싶기도 하고 특히 대표님께 보답하고 싶다는 마음이 크거든요. 처음 들어갔을 때, 아무 준비 안 돼있는 상태였던 절 믿어주시고 함께 일할 수 있는 기회를 주셨어요. 앞서 말한 것처럼 일하면서 초반에 실수도 많이 했는데 꾸준히 믿고 지금의 포지션까지 저를 밀어주셨다는 점이 너무 감사하거든요. 대표님께 보답하자! 투데잇에 보답하자!가 마지막으로 하고 싶은 말이에요. 저 나가더라도 아는 척해주셔야 해요..!Q. 투데잇을 꿈꾸는 개발자에게 한마디!음 투데잇에 들어오는 건 어쩌면 쉬울 수도 있어요. 저 같은 경우 30분 정도 면접을 보고 당일에 바로 함께하기로 했거든요. 하지만 중요한 건 본인이 ‘함께 성장하고 싶은 사람’인가?에 대해 생각해보셔야 해요. 또 투데잇과 방향성이 맞는지 스스로 생각해보고, 성장하기 위해선 어떤 태세를 취해야 하는지 고민해보아야 하죠. 만약 이런 성향이 맞지 않는 사람이라면 아마 들어오시더라도 투데잇과 잘 맞지 않아서 힘들 수도 있거든요. 투데잇에 들어오고 싶은 분들은 이런 부분들에 대해 한 번 깊게 고민해보셨으면 좋겠어요.#투데잇 #팀원소개 #팀원인터뷰 #팀원자랑 #기업문화 #조직문화 #개발자 #개발팀
조회수 1040

레진 기술 블로그 - AWS Auto Scalinging Group 을 이용한 배포

레진코믹스의 서버 시스템은 잘 알려진대로 Google AppEngine에서 서비스되고 있지만, 이런저런 이유로 인해 최근에는 일부 컴포넌트가 Amazon Web Service에서 서비스되고 있습니다. AWS 에 새로운 시스템을 셋업하면서, 기존에 사용하던 PaaS인 GAE에서는 전혀 고민할 필요 없었던, 배포시스템에 대한 고민이 필요했습니다. 좋은 배포전략과 시스템은 안정적으로 서비스를 개발하고 운영하는데 있어서 필수적이죠.초기에는 Beanstalk을 이용한 운영에서, Fabric 을 이용한 배포 등의 시행착오 과정을 거쳤으나, 현재는 (스케일링을 위해 어차피 사용할 수밖에 없는) Auto Scaling Group을 이용해서 Blue-green deployment로 운영 중입니다. ASG는 여러 특징 덕분에 배포에도 유용하게 사용할 수 있습니다.ASG를 이용한 가장 간단한 배포는, Instance termination policy 를 응용할 수 있습니다. 기본적으로 ASG가 어떤 인스턴스를 종료할지는 AWS Documentation 에 정리되어 있으며, 추가적으로 다음과 같은 방식을 선택할 수 있습니다.OldestInstanceNewestInstanceOldestLaunchConfigurationClosestToNextInstanceHour여기서 주목할 건 OldestInstance 입니다. ASG가 항상 최신 버전의 어플리케이션으로 스케일아웃되게 구성되어 있다면, 단순히 인스턴스의 수를 두배로 늘린 뒤 Termination policy 를 OldestInstance 로 바꾸고 원래대로 돌리면 구버전 인스턴스들부터 종료되면서 배포가 끝납니다. 그러나 이 경우, 배포 직후 모니터링 과정에서 문제가 발생할 경우 기존의 인스턴스들이 이미 종료된 상태이기 때문에 롤백을 위해서는 (인스턴스를 다시 생성하면서) 배포를 다시 한번 해야 하는 반큼 빠른 롤백이 어렵습니다.Auto scaling lifecycle 을 이용하면, 이를 해결하기 위한 다른 방법도 있습니다. Lifecycle 은 다음과 같은 상태 변화를 가집니다.기본적으로,ASG의 인스턴스는 InService 상태로 진입하면서 (설정이 되어 있다면) ELB에 추가됩니다.ASG의 인스턴스는 InService 상태에서 빠져나오면서 (설정이 되어 있다면) ELB에서 제거됩니다.이를 이용하면, 다음과 같은 시나리오로 배포를 할 수 있습니다.똑같은 ASG 두 개를 구성(Group B / Group G)하고, 그 중 하나의 그룹으로만 서비스를 운영합니다.Group B가 라이브 중이면 Group G의 인스턴스는 0개입니다.새로운 버전을 배포한다면, Group G의 인스턴스 숫자를 Group B와 동일하게 맞춰줍니다.Group G가 InService로 들어가고 ELB healthy 상태가 되면, Group B의 인스턴스를 전부 Standby로 전환합니다.롤백이 필요하면 Standby 상태인 Group B를 InService 로 전환하고 Group G의 인스턴스를 종료하거나 Standby로 전환합니다.문제가 없다면 Standby 상태인 Group B의 인스턴스를 종료합니다.이제 훨씬 빠르고 안전하게 배포 및 롤백이 가능합니다. 물론 실제로는 생각보다 손이 많이 가는 관계로(특히 PaaS인 GAE에 비하면), 이를 한번에 해주는 스크립트를 작성해서 사용중입니다. 대략 간략하게는 다음과 같습니다. 실제 사용중인 스크립트에는 dry run 등의 잡다한 기능이 많이 들어가 있어서 걷어낸 pseudo code 입니다. 스크립트는 사내 PyPI 저장소를 통해 공유해서 사용 중입니다.def deploy(prefix, image_name, image_version): '''Deploy specified Docker image name and version into Auto Scaling Group''' asg_names = get_asg_names_from_tag(prefix, 'docker:image:name', image_name) groups = get_auto_scaling_groups(asg_names) # Find deployment target set future_set = set(map(lambda g: g['AutoScalingGroupName'].split('-')[-1], filter(lambda g: not g['DesiredCapacity'], groups))) if len(future_set) != 1: raise ValueError('Cannot specify target auto scaling group') future_set = next(iter(future_set)) if future_set == 'green': current_set = 'blue' elif future_set == 'blue': current_set = 'green' else: raise ValueError('Set name shoud be green or blue') # Deploy to future group future_groups = filter(lambda g: g['AutoScalingGroupName'].endswith(future_set), groups) for group in future_groups: asg_client.create_or_update_tags(Tags=[ { 'ResourceId': group['AutoScalingGroupName'], 'ResourceType': 'auto-scaling-group', 'PropagateAtLaunch': True, 'Key': 'docker:image:version', 'Value': image_version, } ]) # Set capacity, scaling policy, scheduled actions same as current group set_desired_capacity_from(current_set, group) move_scheduled_actions_from(current_set, group) move_scaling_policies(current_set, group) # Await ELB healthy of instances in group await_elb_healthy(future_groups) # Entering standby for current group for group in filter(lambda g: g['AutoScalingGroupName'].endswith(current_set), groups): asg_client.enter_standby( AutoScalingGroupName=group['AutoScalingGroupName'], InstanceIds=list(map(lambda i: i['InstanceId'], group['Instances'])), ShouldDecrementDesiredCapacity=True ) def rollback(prefix, image_name, image_version): '''Rollback standby Auto Scaling Group to service''' asg_names = get_asg_names_from_tag(prefix, 'docker:image:name', image_name) groups = get_auto_scaling_groups(asg_names) def filter_group_by_instance_state(groups, state): return filter( lambda g: len(filter(lambda i: i['LifecycleState'] == state, g['Instances'])) == g['DesiredCapacity'] and g['DesiredCapacity'], groups ) standby_groups = filter_group_by_instance_state(groups, 'Standby') inservice_groups = filter_group_by_instance_state(groups, 'InService') # Entering in-service for standby group for group in standby_groups: asg_client.exit_standby( AutoScalingGroupName=group['AutoScalingGroupName'], InstanceIds=list(map(lambda i: i['InstanceId'], group['Instances'])) ) # Await ELB healthy of instances in standby group await_elb_healthy(standby_groups) # Terminate instances to rollback for group in inservice_groups: asg_client.set_desired_capacity(AutoScalingGroupName=group['AutoScalingGroupName'], DesiredCapacity=0) current_set = group['AutoScalingGroupName'].split('-')[-1] move_scheduled_actions_from(current_set, group) move_scaling_policies(current_set, group) 몇 가지 더…Standby 로 돌리는 것 이외에 Detached 상태로 바꾸는 것도 방법입니다만, 인스턴스가 ASG에서 제거될 경우, 자신이 소속된 ASG를 알려주는 값인 aws:autoscaling:groupName 태그가 제거되므로 인스턴스나 ASG가 많아질 경우 번거롭습니다.cloud-init 를 어느 정도 최적화해두고 ELB healthcheck 를 좀 더 민감하게 설정하면, ELB 에 투입될 때까지 걸리는 시간을 상당히 줄일 수 있긴 하므로, 단일 ASG로 배포를 하더라도 롤백에 걸리는 시간을 줄일 수 있습니다. 저희는 scaleout 시작부터 ELB에서 healthy 로 찍힐 때까지 70초 가량 걸리는데, 그럼에도 불구하고 아래의 이유 때문에 현재의 방식으로 운영중입니다.같은 방식으로 단일 ASG로 배포를 할 수도 있지만, 배포중에 혹은 롤백 중에 scaleout이 돌면서 구버전 혹은 롤백 버전의 인스턴스가 투입되어버리면 매우 귀찮아집니다. 이를 방지하기 위해서라도 (Blue-green 방식의) ASG 두 개를 운영하는게 안전합니다.같은 이유로, 배포 대상의 버전을 S3나 github 등에 기록하는 대신 ASG의 태그에 버전을 써 두고 cloud-init 의 user-data에서 그 버전으로 어플리케이션을 띄우게 구성해 두었습니다. 이 경우 인스턴스의 태그만 확인해도 현재 어떤 버전이 서비스되고 있는지 확인할 수 있다는 장점도 있습니다.다만 ASG의 태그에 Tag on instance 를 체크해 두더라도, cloud-init 안에서 이를 조회하는 경우는 주의해야 합니다. ASG의 태그가 인스턴스로 복사되는 시점은 명확하지 않습니다. 스크립트 실행 중에 인스턴스에는 ASG의 태그가 있을 수도, 없을 수도 있습니다.굳이 인스턴스의 Lifecycle 을 Standby / InService 로 전환하지 않고도 ELB 를 두 개 운영하고 route 53 에서의 CNAME/ALIAS swap 도 방법이지만, DNS TTL은 아무리 짧아도 60초는 걸리고, JVM처럼 골치아픈 동작 사례도 있는만큼 선택하지 않았습니다.물론 이 방법이 최선은 절대 아니며(심지어 배포할때마다 돈이 들어갑니다!), 현재는 자원의 활용 등 다른 측면에서의 고민 때문에 새로운 구성을 고민하고 있습니다. 이건 언젠가 나중에 다시 공유하겠습니다. :)
조회수 2048

Android Gradle Tips

안드로이드와 GradleAndroid 가 Gradle 을 이용하기 시작한 것도 3년이 다 되어 갑니다. 이제는 많은 유저가 당연히 Gradle 을 Android 기본 개발 환경으로 사용하고 있습니다.하지만 기본 설정으로만 Gradle 을 사용하는 사용자들이 많습니다. 게다가 구글에서 Android Gradle Build DSL 을 끊임없이 변경했기 때문에 많은 사용자들이 이를 이해하기도 전에 변경이 되는 경우가 매우 빈번했습니다.Gradle Dependency 분리하기안드로이드 자동화 툴위 두번의 포스팅을 통해서 TossLab 에서 사용하고 있는 Gradle 에 대해서 소개를 해드렸습니다.오늘은 Android 팀이 사용하는 Custom 설정들에 대해서 정리하도록 하겠습니다.1. 초기화 값 검증 및 설정하기개발자들이나 CI 에서 관리해야하는 속성 값에 대해서는 각각 다르게 설정할 필요가 있습니다.안드로이드 팀은 3개의 추가적인 속성값을 추가하여 사용하고 있습니다.# gradle.properties inhouse_version=2 # 배포/qa 버전의 hofix version 을 관리학 ㅣ위함 report_coverage=false # coverage 측정에 대한 on/off 기능 dev_min_sdk=21 # minSDK 의 개별적인 관리를 위함 위의 3개의 값은 존재 하지 않으면 빌드가 되지 않도록 하는 강제사항으로 만들었으나 새로운 개발자가 입사하게 되었을 때 또는 CI 서버에 실수로 기입하지 못하게 되었을 때 Project Import 나 빌드가 아예 되지 않는 현상이 발생하였기에 초기 값을 설정할 수 있도록 하였습니다.report_coverage 는 5. Android Gradle DSL 에서 buildTypes.debug.testCoverageEnabled 에서 사용되며 이 값은 설정에 따라서 디버그 과정에서 변수값들이 제대로 노출되지 않게 됩니다. report 가 필요한 CI 서버 용으로 만들어진 값입니다.// valid.gradle def checkValidProperties() { println "Properties Valid Checking.........." if (!project.hasProperty("inhouse_version")) { println "set up to gradle.propeties --> inhouse_version = 1 (default)" project.ext.inhouse_version = 1 } if (!project.hasProperty("report_coverage")) { println "set up to gradle.propeties --> report_coverage = false (default)" project.ext.report_coverage = false } if (!project.hasProperty("dev_min_sdk")) { println "set up to gradle.propeties --> dev_min_sdk = 19 (default)" project.ext.dev_min_sdk = 19 } println "Properties Valid Check OK" } checkValidProperties() // ------------------------------- // build.gradle apply from: 'valid.gradle' 위와 같이 설정한 뒤 gradle.properties 에 아무런 값을 설정하지 않고 빌드를 하게 되면 빌드 최초에 다음과 같은 log 를 보실 수 있습니다.================================================================================ Properties Valid Checking.......... set up to gradle.propeties --> inhouse_version = 1 (default) set up to gradle.propeties --> report_coverage = false (default) set up to gradle.propeties --> dev_min_sdk = 19 (default) Properties Valid Check OK ================================================================================ 2. APK Copy 하기QA 팀 전달 또는 스토어 배포시에 Android Studio 의 기본 기능을 이용하지 않고 Gradle Task 를 사용하여 빌드를 하게 되면 /app/build/outputs/apk 에 있는 패키지를 복사하는 것이 여간 귀찮은 작업이 아닐 수 없습니다.그래서 Gradle 에서 기본적으로 제공되는 Copy Task 를 이용하여 APK Copy Task 를 만들었습니다.// apk-copy.gradle android.applicationVariants.all { variant -> // 1. Copy Task 생성 def task = project.tasks.create("copy${variant.name}Apk", Copy) task.from(variant.outputs[0].outputFile) // 2. 바탕화면 Task 로 복사 task.into("${System.properties['user.home']}/Desktop/") // 3. 복사하는 과정에서 APK 이름 변경 def targetName = "jandi-${variant.baseName}-${variant.versionName}.apk" task.rename ".*", targetName task.doFirst { println "copy from ${source.singleFile.name} to $destinationDir" } task.doLast { value -> println "completed to copy : $targetName" } } // --------------- // build.gradle apply from: 'apk-copy.gradle' 위의 Task 는 총 3개의 단계로 구분할 수 있습니다.Copy Task 생성~/Desktop 으로 복사복사 할 때 APK 이름 변경Task 를 정의하는 과정에서 application 의 flavor, build-type, version 을 기반으로 복사하도록 한 것입니다.위와 같이 설정하면 다음과 같이 사용할 수 있습니다.# flavor : qa , build-type : Debug $> ./gradlew assembleQaDebug copyqaDebugApk # 또는 줄여서 아래와 같이 쓸 수 있습니다. $> ./gradlew aQD copyQDA Application Variant 에 대한 변수는 링크에서 확인하실 수 있습니다.3. CI TasksCI 용으로 CheckStyle 과 PMD 를 사용하기 때문에 관련 설정 또한 별도로 처리하였습니다.task pmd(type: Pmd) { source 'src/main' include '**/*.java' ruleSetFiles = files('../pmd.xml') ignoreFailures = true } task checkstyles(type: Checkstyle) { configFile file('../checkstyle.xml') source('src/main') include '**/*.java' classpath = files() showViolations = true ignoreFailures = true } // --------------- // build.gradle apply from: 'ci-tasks.gradle' CheckStyle 과 PMD 설정에 필요한 정보 또한 별도의 script 로 설정하였습니다.4. Gradle Properties빠른 빌드를 위해 추가적인 설정을 하고 있습니다.# gradle.properties # 백그라운드 빌드 org.gradle.daemon=true # 동시 빌드 org.gradle.parallel=true # jvm heap size org.gradle.jvmargs=-Xmx4346m # build jdk org.gradle.java.home=/Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home 위의 설정 중에서 제일 보셔야 할 것이 org.gradle.jvmargs 입니다. Android Gradle 설정 중에서 위의 값이 적으면 빌드속도가 현저히 느려집니다.빌드 할 때 console log 를 확인하시고 값을 적절하게 맞춰주실 것을 권장합니다.5. Android Gradle DSL 추가 정의하기 // build.gradle // ...중략 android { // 특정 Flavor에서 Release Build 막기 android.variantFilter { variant -> if (variant.buildType.name.equals('release') && (variant.getFlavors().get(0).name.equals('qa') || variant.getFlavors().get(0).name.equals('dev'))) { variant.setIgnore(true); } } buildTypes { debug { debuggable true testCoverageEnabled = project.hasProperty("report_coverage") && report_coverage.toBoolean() } // ..중략... } productFlavors { dev { // demo version applicationId 'com.tosslab.jandi.app.dev' versionName(defaultConfig.versionName + ".dev." + inhouse_version) minSdkVersion project.hasProperty("dev_min_sdk") ? dev_min_sdk : 19 } // ..중략.. } // 빌드 과정에서 CPU 와 Ram 최적화 하기 dexOptions { javaMaxHeapSize "2g" maxProcessCount Math.max(1, ((int) (Runtime.getRuntime().availableProcessors() / 2))) } } variant-filter 를 이용해서 qa 나 dev 용 빌드는 release 버전이 빌드되지 않도록 하였습니다.buildTypes 와 productFlavors 에서는 앞서 설정한 gradle-properties 에 대해서 설정에 따라 기본값이 지정되도록 하였습니다.dexOptions 설정은 개발하는 기기의 PC 환경에 따라 다를 수 있습니다.Android DSL 에 의하면 Dex 빌드 과정에서 최종적으로 사용하는 메모리는 heapsize * process-count 라고 합니다.heapsize 기본값 : 2048MBprocess-count 기본값 : 4참고문서6. Android Resource Image 의 EXIF 정보 삭제하기보통 디자이너가 Photoshop 과 같은 툴을 이용하여 이미지를 만들게 되면 자동으로 adobe 와 관련된 exif 정보가 붙게 됩니다. 그래서 빌드 할 때 libpng warning : iCCP ... 와 같은 warning 메세지를 보실 수 있습니다. 이는 Android Build 과정에서 aapt 가 이미지 최적화 하는 과정에서 불필요한 exif 정보로 인해서 오류를 내게 됩니다.따라서 exif 정보를 초기화 해주는 작업이 필요합니다.맥 사용자에 한해서 지원됩니다.HomeBrew 를 이용해서 exiftool 을 설치하셔야 합니다. exiftool 설명find . -path '*src/main/res/*' -name '*.png' -exec exiftool -overwrite_original -all= {} \; 저는 별도로 쉘 스크립트를 만들어서 실행합니다.아래를 복사해서 붙여넣기로 실행하시면 됩니다.echo "find . -path '*src/main/res/*' -name '*.png' -exec exiftool -overwrite_original -all= {} \;" > exif_clean.sh chmod 744 exif_clean.sh 관련 정보 : adt-dev google group 에서 제시된 해결책Wrap up안드로이드 팀은 Gradle 을 이용하여 반복적일 수 있는 작업을 자동화 하고 다양한 초기화 설정과 편의를 가지고자 하였습니다.초기화 값 검증 및 설정Apk 복사 자동화CI Task 정의Gradle Properties 지정Android Gradle DSL 정의Android Resource Image EXIF 삭제Gradle 을 얼마나 잘 활용하냐에 따라서 조직에 필요한 Task 를 금방 만드실 수 있습니다. 이번 포스팅이 도움이 되었기를 바라며 활용해보실 것을 권장합니다.#토스랩 #잔디 #JANDI #개발자 #개발팀 #앱개발 #안드로이드 #인사이트
조회수 42907

프론트엔드 개발자(Front-End Developer)에 대해 알려드립니다!!

안녕하세요 크몽 개발팀입니다. 오늘은 일상적인 'IT 이야기'가 아닌 제가 맡고 있는 직책인'프론트엔드 개발자(Front-End Developer)'에 대해 포스팅을 해보고자 합니다.여러분들은 혹시 'Front End'라는 용어에 대해 알고 있으신가요? 저도 제일 처음 이 단어를 들었을땐 이게 대체 무슨 단어인가 했습니다.이 용어 외에도 'Back End'라는 단어도 있는데요, 물론 처음만나는 단어가 두개인만큼 두배로 어려워보일 수 있겠지만.. 놀라셨을 가슴 한번 쓸어내려드리고 전~혀 어렵지않다는 것을 차차 설명해드리겠습니다.----------------------------------------------------------------------------------------'프론트엔드'란??우선, 'Front End'라는 단어는 어떤의미의 단어일까요? 'W사'의 사전을 통해 알아보겠습니다.   한마디로 말씀드려서 '프론트엔드'는 사용자들에게 보이는 영역을 책임을 지는 것이며 '백엔드'는 시스템적인것으로 눈으로 보이지는 않지만 말 그대로 뒤에서 전산 처리를 하는 것을 말합니다.즉, '프론트엔드'는 시스템적으로 멋지게 만들어진 아이맥의 내부를 감싸는 껍데기를소비자들이 사고 싶게 만드는 디자인으로 구현하는 작업을 말하는 것입니다.크몽의 '조너선 아이브'같은 존재(?)라고 말씀드릴 수가 있겠군요.. 하하하하 (자뻑 죄송합니다(__);;)  '프론트엔드 개발자'의 목표는?'프론트엔드 개발자'의 미션은 두가지라고 말씀드릴 수가 있습니다.    첫번째로, 사용자들이 홈페이지를 친숙하고, 직접적으로 보여지도록 개발하는 것인데 딱 두가지!! 개발스킬과 미적감각을 동반하여야 합니다.여기서 중요한점은!! 쿤이는 디자인을 좋아라하지만 영감이 떠올릴만한 미술관과는 거리가 있다는 점점점점점점...앞으로 열심히 다녀보겠습니다!다시 본문으로 돌아가서..두번째는, 끊임없이 변화하는 웹세상에서 어떤툴과 테크닉을 썼는지 알고 있어야 한다는 점입니다.이 부분은 변화를 사랑하는 쿤이에겐 식은죽 먹기보다 쉽다고 하는게 맞겠네요!! (제발 그렇다고 해줘요..ㅠㅠ) '프론트엔드 개발자'가 쓰는 툴은?'프론트엔드 개발자'가 쓰는 툴의 몇몇은 웹사이트의 UI를 개발하는 툴에서 구할 수 있습니다. 첫번째로, 'HyperText Markup language'라고 불리는 'HTML' 되겠습니다.이 마크업언어는 어떤 웹사이트에서 중추적인 역활을 하는 그런 녀석입니다. 이 녀석은 말이죠... 자신의 이름을 문서의 앞뒤에 안써주면 자신의 정체도 모르는 그런녀석이구요,이 녀석의 명령어(태그)를 쓸땐 말이죠 명령어 끝에 닫는태그를 안해주면 크게는 문서 전체를 뒤죽박죽으로 만드는 그런 녀석이에요.어떨때는 파트너('CSS')와 함께 어디 놀러갈땐 각 장소(인터넷 익스플로어, 크롬 등..)에 따라 다른 매력을 발산해줘서 양파같이 까도까도 속을 모르는 그런 녀석이에요.두번째는, 'Cascading Style Sheet'라고 불리는 'CSS'입니다이 스타일 시트는 프레젠테이션효과를 주며 우리의 웹사이트가 단 하나밖에 없다는 희귀성을 부여할 수 있습니다. 이 녀석은 아까 말씀드렸듯이 'HTML'의 파트너에요. 남자는 여자하기 나름이란 말과 같이 'HTML'은 'CSS'하기 나름이라고 말씀드릴수가 있을 것같네요. 직접적으로 말씀드리자면 'HTML'이 몸이라고 보시면 'CSS'는 옷입니다. 'CSS'가 어떻게 스타일을 주는가에 따라서 웹사이트가 최신스타일룩을 보여줄 수도 있으며 잘못 쓴다면 90's 힙! to the 합!스타일을 보여 줄 수도 있습니다. 그래서 많은 사이트들이 사용자들에게 직접적으로 보여지는 스타일에 대해 신경쓰는 것이 이러한 이유라고 말씀드릴 수가 있습니다.세번째는, 'Content Management System'인 'CMS'입니다우리 한글로 표현하자면 내용관리시스템이란 것인데 아마 생소하실 것이라고 생각 듭니다. (실은 저도 생소했습니다ㅎㅎ)이 녀석은 한마디로 웹 사이트의 내용을 관리하는 시스템인데요.내용 관리 애플리케이션('CMA')과 내용 배포 애플리케이션('CDA')이 있는데요,그냥 약자로만 봤을 때엔 저기 아무 증권사나가서 한번쯤은 가입해야 될 것같은 분위기죠? 단호하게.. 아닙니다!! 연이자 2%할 것같은 'CMA'가 하는 일은 'HTML'에 들어갈 내용, 변경, 제거 등의 관리 프로그램이고,왠지 아이들의 미래를 위해 들어야될 것같은 'CDA'는 웹 사이트의 모든 수치(현행화)를 보고 편집할 수 있는 정보편집 프로그램입니다.우리가 흔히 볼 수 있는 형태로는 웹 기반 편찬(마법사템플릿 등), 형식 관리, 계정 제어, 데이터의 색인,테이터 탐색, 키워드 검색 등이 있을 수 있겠습니다.프론트엔드 개발자가 유의할 점은?프론트엔드개발자는 다음 두가지의 사항에 대해 유의해야 합니다.첫번째는, 접근성입니다. 앞서 말씀드렸듯이 이용자들에게 친숙한 모습으로 다가가야합니다.한번도 보지도 듣지도 못한 그런 UI로 이용자들에게 다가간다면 과연 잘 사용할 수 있을지가 문제일 겁니다.그런 맥락에서 말씀드리자면 모든기기에서 항상 똑같은 모습으로 이용자들을 맞이한다면각 기기에서 최적화 되지못한 화면들이 나와 이용자들에게 혼란을 줄지도 모를 일입니다.그렇기때문에 동적인 사이트를 만들어야 된다는 생각을 프론트엔드 개발자는 생각하고 있어야합니다.두번째는, 사용 간편성입니다. 만약 접근성이 좋아졌다고 하더라도 검색엔진에 최적화되지않은 사이트라면전세계적 검색사이트인 G사에서 사이트안의 컨텐츠와 연관된 내용을 검색하더라도 상위에 랭크 안되는 경우가 많습니다.그렇게 된다면 검색사이트로 원하는 사이트를 찾아들어가는 지금으로는 많은 잠재이용자들의 유입을 막아 더 이상 서비스가 성장하지못하는 상황까지 갈 수 있습니다.---------------------------------------------------------------------------------------- 이렇게 제가 하는일에 대해 포스팅을 하다보니 제가 맡은 업무가 우리 크몽서비스에 얼마나 큰 영향을 주는지 알 수 있었는데요... 갑자기 제 어깨에 곰한마리가 앉은 것같은 느낌이 드네요ㅠㅠㅠㅠ (아~ 피로야가라~!!!) 지금까지 제가 공부한 내용들을 간략하게 포스팅해보았는데요.담번엔 배운것들을 쓰는 과정을 시간이 허락한다면 보여줄 수 있는 포스팅으로 찾아 뵙겠습니다. :)#크몽 #개발자 #개발팀 #프론트엔드 #인사이트 #팀원소개
조회수 1749

소프트웨어 개발자에게 성공이란...

소프트웨어 개발자들이 생각하는 ‘성공’이라는 단어와 키워드에는 어떤 것들의 의미를 포함하고 있을까? 한편으로는 단편적이고 획일적인 ‘성공’이라는 단어에 너무 많은 개발자들이 매몰되어 있는 것 아닌가 하는 생각을 해본다. 필자 스스로 실무경력 20년을 넘겨서 소프트웨어 개발을 하고 있는 경험을 바탕으로 주변의 성공한 개발자들에 대해서 혼자 생각해 보았다.일반적으로 의미의 ‘성공’이라는 것이 무엇을 의미하는 것인가에 대한 정의는 이번 칼럼의 말미에서 이야기하도록 하자. 정말 많은지 모를 대한민국에서 성공한 개발회사나 개발된 서비스들을 살펴보는 것부터 시작을 하는 것이 정답인지는 필자도 잘 모르겠다. 성공적인 서비스나 소프트웨어, 프로그램은 세상에 선보인다는 것. 그러한 것을 만들어낸 순수한 아이디어나 원천기술로 무장한 기술로 축적되었고, 그 아이디어를  뛰어넘어, 새로운 기술이라고 할 수 있는 것을 보유한 제품이나 상품들이 얼마나 되는지에 대해서부터 냉정하게 필자는 잘 모르겠다라고 먼저 인지하고 넘어가자. 아니, 다시 말하자면, 냉정하게 국내에서 그런 것을 본적이 별로 없는  듯하다.더욱더 삐딱하게 이야기하자면, 국내에서 성공한 개발 서비스들은 대부분 아류작이거나 남의 아이디어를 도용한 제품과 서비스들이 대부분이 아닌가라고 생각한다. 심지어는 특정 솔루션 시장은 오픈소스를 그대로 제품에 반영해 두고서는 자신의 제품인 것처럼 위장하는 사례까지 보이고 있으니, 과연 대한민국 소프트웨어 시장은 과연 얼마나 ‘성공’이라는 키워드를 그대로 사용해도 되는지에 대해서 매우 의문시된다.(물론, 필자의 삐딱한 시선에서만 그렇게 보일지도 모른다.)대한민국의 소프트웨어 시장에서 1위를 지키고 있다고 하는 서비스와 제품들이 되려면 어떻게 해야 하는가?. 삐딱하게 이야기하자면, 오로지, 대한민국에서 성공한 개발회사나 개발자가 되려면, 창의적인 아이디어나, 독특한 아이디어로 무장하는 승부수를 던지기 보다는, 해외의 서비스 중에 알차고, 괜찮은 것들에 대해서 관심을 가지는 것이 중요하다고 생각한다. ( 그래서, 영어공부를 잘해야 하는지도 모르겠다. )필자가, 대기업과 신규사업기획을 할 때에 작업하는 내용을 보고서는 경악을 금치 못했던 경험을 한적이 있다. 정말 상당한 컨설팅 금액( 수십억을 넘긴 비용 )을 지불해서, 대기업이 유명한 컨설팅업체를 통해서 신규사업에 대한 기획과 아이디어에 대한 컨설팅을 받는 것에 전문가의 한 사람의 참여했었다. 그런데, 그 중요한 작업의 모티브는 해외에서 이미 성공적으로 안착한 서비스에 대한 분석과, 한국에서의 서비스 시에 벌어질 일에 대해서 예측을 하는 일을 하고 있었다는 점이다. 새로운 아이디어가 아니라는 점이다.물론, 성공한 서비스를 도입해서, 로컬 화한다는 것 또한 매우 어려운 일이라고 생각하지만, 대부분의 새로운 기획이나 신규 서비스에 대한 작업들의 대부분을 이런 식으로 진행한다는 이야기를 들었을 때에 받은 충격은 정말 놀라운 경험이었다, 물론, 지나고 나서 생각해보니, 그렇게 놀랄만한 경험도 아니었는지 모르겠다. 대부분의 대기업들이 이런 식으로 한다는 이야기를 듣고 더 놀라기는 했지만. 물론, 이렇게 로컬화 한다는 것 자체도 대단한 도전이고 어려운 점이라는 것은 인정한다고 하지만, 이런 로컬화와 아류작에 대해서 비판적인 시야를 가진 필자의 생각은 그렇다.성공한 서비스들은 대부분 아류작들이다?냉정하게 국내에서 성공한 대부분의 서비스들은 아류작들이고, 복제본들이고, 독창적인 아이디어보다는 해외 서비스를 대부분 국내에 안착한 서비스라고 생각한다. 심지어 독창적인 mp3 플레이어마저도, 아이팟의 생태계가 한층 더 발전적인 시장을 창출했으니, 국내에서 만들어진 디지털적인 요소들 중에 독창적인 것이 얼마나 있는가?필자는 생각한다. 예술에 있어서 복제와 창작의 차이는 매우 크다는 것을. 물론, 소프트웨어 개발이 이런 예술에 비견될 정도의 가치를 부여해서 그런 것 만은 아니다. 소프트웨어 개발은 아이디어와 구현하고자 하는 추진력과 열정이 결합되어져서 만들어지는 최고의 가치 구현을 위한 세계이기 때문에 그렇게 생각할 뿐이다.필자가 좋아하는 만화 중에 ‘맛의 달인’이라는 만화에 나온 표현을 그대로 옮기자면 다음과 같은 장면이 나온다. 프랑스의 유명한 요리를 그대로 일본에서 구현하지만, 그 요리에 대한 평가는 ‘프랑스의 요리를 그대로 구현한 요리이다’. ‘매우 아름답지만 최저의 요리’라는 평가를 받는다. 그러한 최저의 요리라는 평가를 받은 이유는 ‘로컬화 한다는 것은 실정에 맞게 고치고, 연구 개발한 맛이라면 완벽하겠지만. 너무도 프랑스 요리와 똑같이 만든 것은 처절한 아류라는 점이다. 지금 먹은 요리에는 프랑스 요리사의 모습이 그대로 남아있다는 점. 원형이 프랑스의 것을 그대로 답습했다는 것.오리지널을 복사했다는 냉정한 평가는 정말 명확하다. 요즘 가장 국내에서 최근에 성공한 서비스를 이야기한다면, 카카오톡과 애니팡을 예로 들 수 있겠다. 다른 사람들은 어떻게 평가할지 모르지만, 정말 대단한 성공을 가진 것은 사실이다. 하지만, 둘 다 원형을 그대로 복사했을 뿐, 새로운 것은 아무것도 없다는 점이다. 아니, 오히려. 기존의 원형을 대한민국의 안 좋은 통신사의 서비스와 결합한 케이스라고 평가를 해야 정확하지 않을까 한다. 원형을 오히려 퇴보시킨 서비스라고 평가하고 싶다.카카오톡은 WatsApp을 그대로 복제했다. 대표적으로 등록되어진 전화번호로 연계하는 원형의 아이디어를 그대로 받아들였다. 하지만, 카카오톡의 새로운 신규 비즈니스 모델인 게임센터는 자체적인 생태계를 만들어서 통제하려 하는 기존의 통신사의 방식과 그다지 차이가 없다고 보인다. 뭐, 돈을 벌어야 하는 기업의 입장을 반대하는 것이 아니다. 단지, 필자의 삐딱한 시선으로는 진보를 위한 선택이 아니라, 퇴보를 위한 선택이었다는 점이 불편할 뿐이다.애니팡도 마찬가지이다. 기존의 게임방식을 그대로 복제했다. 그리고, ‘하트’라는 이름으로 무분별한 ‘스팸’을 활성화해서, 기존 통신사들이 SMS에서 얻어들이는 대량 SMS 발송을 통한 이익을, 그대로 실현한 점이다.물론, 카카오톡이나 애니팡의 ‘이익 실현 구조’는 매우 성공적으로 국내에 론칭한 것은 사실이고, 이러한 구조로 ‘돈’을 벌어야 한다는 점이 매우 안타까울 뿐이다. 개인적으로는 ‘국내’에서는 어느 정도 ‘돈을 버는 성공은’할 수 있지만, 해외에서까지 성공적으로 론칭할 것인지는 조금 의심스럽다. ( 어차피, ‘돈’을 벌면 성공이라는 관점으로는 매우 대성공이다. )넥슨의 카트라이더와 마리오 카드와 같이 일일이 나열하기에는 너무도 많은 사례들이 있어서 굳이 더 나열하지 않겠다.다만. 정말 중요한 것은 복사보다는 진짜가 더 좋다는 점이다. 가령, 오리지널이 존재하는 영역이나 예술과 같은 고부가가치의 영역에서는 ‘화가나 작가가 다른 사람의 작품을 흉내내면  웃음거리밖에 되지 않는다’는 점을 이야기하고 싶다. 필자 개인적으로는 ‘그런 웃음거리를 통한 수익실현’을 그렇게 높게 평가하고 싶지 않기 때문이다.대표적으로 통신사는 ‘스팸’과 ‘보이스 피싱’을 해결하지 못하는가? 에 대해서 필자는 그렇게 생각한다. ‘대량 SMS수입’을 포기하지 못하고, ‘전화번호를 통한 대량 통화의 수익’을 포기하지 못하는 구조적인 문제 때문에 그렇다고 생각한다.과거에 문제가 된 iOS6로 업데이트가 되면서 SKT 아이폰4S에서 발생한 전화번호 호출의 문제, ‘112 신고가 안 되는 아이폰’이라는 기사와 사건에 대한 문제의 근본적인 원인은 SKT가 국제표준 방식을 따르지 않아서 발생한 문제라는 것을 모르는 사람들이 정말 많다. 이 문제를 더 파고들어가면, 부당한 SMS수입을 얻고 있는 국내 통신사들의 부도덕한 점도 드러난다. 2003년 이후 3G 서비스(WCDMA)가 도입되었지만, 문자 메시지 국제표준이 기존의 80 byte에서 140 byte로 늘어났지만, 정작 통신사들은 국제표준규격을 지키지 않으면서 연간 수백억의 이익을 부당하게 얻어냈다. 다만. 아이폰4s 출시 당시 KT는 140바이트를 맞추었지만, SKT는 아직도 80 byte였다는 점을 예로 들고 싶다.국제표준을 따르거나, 해외의 서비스가 ‘돈’이 되는 것에는 빠르지만, ‘돈’이 안 되는 기준에는 미온적이고, 대처가 느린 것에 대해서는 참으로 훌룡(?)한 성공적인 방법이라고 평가를 굳이 필자와 같은 주변 사람이 할 필요가 있을까 한다. 그런 훌륭한 평가는 비싼 컨설팅 비용을 지불한 뛰어난 전문가들이 할 것이기 때문에...내 주변에 성공한 개발자와 성공한 벤처 사업가...성공한 개발자. 고급 승용차를 몰고, 출근하는 개발자의 모습을 본다면, 성공한 개발자의 향기를 느낄 수 있을까? 물론, 일반적으로 그럴 수 있다고 생각한다.자본주의 사회에서 ‘돈’은 그 사람을 평가하는 가장 기본적인 ‘수단’이기 때문이다. 성공하지 못한 필자는 아니지만, 필자 주변에는 고급 승용차인 BMW나 벤츠를 직접 몰고 다니는 성공한 개발자들이 여럿 있다. 그리고, 상당히 많다. 사업을 하는 사람으로부터, 프리랜서인 사람까지 매우 다양하다.분명, 그들은, 자신만의 서비스와 제품을 실현하였고, 시장에서도 안정적인 자신만의 브랜드를 확립하였고, 후배들로 존경을 받고 있으며, 직원들에게 비전과 꿈을 주고 있으며, 새로운 기술과 시장에 대해서 언제나 도전하고 있는 사람들이 있다.그들은 충분히 ‘성공’한 사람들이다.‘복제’와 ‘아류작’이 아니더라도. 독특한 자신들만의 서비스와 제품을 구현하여 성공한 개발자들이 분명 존재한다.그들의 성공요인을 주변의 사람으로서 살펴본다면, 몇 가지의 요인이 있다고 정의할 수 있다. 그것들을 필자의 주관적인 생각으로 정리해보면, 크게 4가지 정도로 정리할 수 있다고 본다.하나. 그들은 뛰어난 개발자는 아니었다.그들은 아주 탁월한 능력을 소유한 개발자들은 아니었다는 점이다. 그리고, 아주 뛰어난 학벌을 가진 개발자들도 아니었다. 개발자 동호회에서 만난 친구도 있고, 직장생활이나 사회생활에서 만난 사람도 있었지만. 그들은 아주 탁월한 재능을 지녔거나, 엄청난 코딩능력, 뛰어난 직관을 지닌 사람만은 아니었다.순수한 개발 능력만 놓고 본다면, 오히려, 뒤처지는 개발자들이었는지도 모른다. 하지만, 뛰어난 개발자들이나 아이디어를 가진 사람들과 친하게 지냈으며, 그들의 도움을 자연스럽게 얻어내는 소통의 달인은 아니었지만, 개발자 커뮤니티에 매우 즐겁게 활동을 하던 사람들이었다.둘. 그들은 우직하지만, 묵묵하게 자신의 상품과 아이디어를 다듬었다.그들은 하나의 아이디어가 실현되는 것을 쉽게 포기하지 않았다. 사업을 하기 전에는 그 아이디어를 실현하기 위해서 애썼고, 속한 회사가 아이디어에 대해서 낮은 평가를 하는 것에 대해서도 크게 실망하지 않았다. 오히려, 반대를 해도 해당 서비스와 제품, 기술에 대한 애정이 정말 높았으며, 그것을 실현하려고 매우 애썼다.처음에는 언제나 소프트웨어는 단순한 것부터 시작한다.그 단순한 것을 꾸준하게 다듬고, 소프트웨어에서 제품으로 다듬어서 시장에서 가치를 인정받을 수 있도록 수년 이상을 투자하고 노력해야만 얻어진다. 그것은 스티브 잡스도 똑같았다. iOS는 하루 이틀 만에 나온 소프트웨어가 아니기 때문이다.심지어, 몇 년 동안 밥을 굶더라도, 자신이 생각하는 가치를 실현하기 위해서 포기하지 않고 도전했던 우직한 도전이 오히려 성공을 만들어 내었다. 분명, 훌륭한 소프트웨어는 뛰어난 기술로 만들어지는 것만은 아니다는 것을 요 근래에서야 필자도 느낀다.필요한 가치가 적정한 가격에 구현되어진 것이 정말 필요하다는 점이다. 뛰어난 기술이 뛰어난 제품을 만드는 것이 아니라, 뛰어난 제품이 뛰어난 기술을 만든다는 것이다. 그것이 사용자들로 하여금, 또 다른 가치를 얻을 수 있는 기능을 제공한다는 것에 대해서 굳이 설명하지 않더라도, 그들은 그 아이디어와 생각을 실현하기 위해서 자신만의 길을 걸었다.정말 우직할 정도로... 필자 주변의 그들은, 몇 년을 일 년에 몇백만 원을 벌더라도, 그 꿈을 포기하지 않았다.셋. 시장과 세상의 시선을 그렇게 두려워하지 않았다. 자신의 ‘가치’와 ‘비전’을 실현했다.자신의 아이디어와 자신의 서비스, 제품을 지키기 위해서 약간의 주변 사람들에게 욕을  얻어먹는 것을  두려워하지 않는다. 필자가 아는 어떤 기업은 시장에서는 냉혈안이라는 말도 듣고, 불법 복제된 제품에 대해서는 가차 없는 소송도 불사하는 어떤 기업을 알고 있다. 하지만, 그 회사와 그 사장에 대해서 필자는 비난하지 않는다. 왜냐하면, 그는 기업 내부의 직원들에게는 절대 급여를 밀리지 않고, 야근을 시키지 않는 최고의 사장이었기 때문이다.시장과 타인에게는 가차 없지만, 자신이 생각한 비전을 실현한 회사를 만들기 위해서 언제나 최선을 다하는 사람이었을 뿐이다. 그리고, 자기 것을 지키기 위해서 애를 썼고, 직원들과의 거리도 언제나 적절하게 유지했다. 냉정하게 기업과 사업이라는 것은 자선사업이 아니라는 것을 잘 알고 있었다. 충분하게 돈을 벌고, 외제 승용차를 사장은 타고 다니지만 ( 외제 승용차를 타는 것도, 대한민국은 간단하다. 법인세를 충분하게 낼 정도로 수익이 생기면, 그 수익으로 차를 리스해서 타면 간단하다는 대한민국의 세법 구조 때문이다. ), 모든 직원들에게 그 이익을 100% 나누어주지는 않는다. 직원은 직원일 뿐이니까.그들은 회사의 재정이 힘들어지면 소속된 직원을 힘들기 전에 내보낼 줄도 알고, 필요하다면... 해고도 그리 어렵지 않게 결정하는 사람도 있다, 영업기밀을  들고나간 직원과 소송도 불사했다. 차라리, 친구와 따로 술을  마실지언정, 직원들과의 ‘관계’는 냉정하고 쿨한 관계를 유지했다. (물론, 그렇지만. 인간관계가 깨어지는 것을 매우 괴로워하는 사람들이다. 다만, 아래 직원들에게 속시원히 이야기를 못할 뿐이다. )넷. 필요한 기술자나 기술은 기필코 얻으려 노력했다.그들은 자신이 부족한 점을 잘 이해하고 있었다. 부족한 것을 오히려, 더 널리, 많이 이야기를 하였다. 그리고, 그것을 커버하기 위해서 매우 많은 노력을 한다. 다 잘하고자 하는 팔방미인이 되는 것이 아니라, 자신이 부족한 점을, 자신이 가장 잘하는 것으로 커버하려 애쓴 것이다. 전문적인 기술을 소유한 사람에게 도움 요청하는 것을 부끄러워하지 않고, 도와준 사람에게 충분한 대우나 접대를 잊지 않았다. 그래서, 그들이 도와달라고 하면, 주변의 전문가들이 아낌없이 그를 도와준다.그 이외에서 그들은 그렇게 ‘성실’하게 일하는 친구들은 아니었다. 실제, 사장이었던 그들이 직원의 입장으로 회사를 다닐 때에는 근태 문제로 지적을 받은 친구들도 꽤 많다는 점이다. 아마도, 사업이나 자신이 좋아하는 일을 하는 것과, 어떤 일이 주어진 상태에서 일을 하는 것은 분명 다른 지도 모르겠다. 직원일 때에 불성실하지만, 자신의 일을 할 때에 성실한 것은 전혀 상관관계가 없어 보인다. 한편으로는 ‘사장’이나 ‘자신의 일’을 하는 사람의 경우에는 특별하게 ‘근무시간’이라는 것 자체는 큰 의미가 없다는 점이 더 정답일 것이다. 하여간, 그들은 성공한 개발자들이고, 성공한 기업인이 되어 있었다. 자신만의 제품이나 서비스를 만들면 자연스럽게 ‘사장’이 되어버리는 것이 소프트웨어 업계의 현실인 듯하다.그렇다면, 대한민국에서 ‘성공’이란 ‘돈’을 의미하는가?강남의 최고급 아파트와 외제 승용차가 성공을 의미할까?자신의 뛰어난 기술력으로 커뮤니티에서 인정받고, 유명해진 명예를 얻는 것이 성공을 의미할까? 다른 사회현상을 생각하면서 다시 한번 비교해보자.요즘 개발자들도 오디션 프로에 영향을 받은 듯하다. 요즘 연예계 지망자들이나 배우나, 가수를 꿈꾸는 친구들이 선배나 멘토들에게 묻는 것이 언제나 똑같다고 한다.그것은 ‘빠르게 성공’하고 ‘빠르게 명예’를 얻는 방법이 무엇이냐 묻는 것이다.어렵고 복잡하고, 길게 걸리는 방법은 무시하고, 오디션 프로에서 1등을 해서, 빠르게 성공하는 방법만을 생각한다고 한다.물론, 그 방법도 있을 것이다.소프트웨어의 세계에도 똑같은 방법이 있다. 대표적인 방법이 유명대학을 가서, S 멤버쉽이 되고, 대기업에 입사해서 경력을 쌓은 다음, 해외의 서비스를 적당하게 분석하다가, 성공적으로 론칭한 서비스를 재빠르게 국내에 도입해서 성공에 이르게 하는 방법이 아마도 가장 빠른 방법일 수 있겠다.물론, 이 방법으로 ‘성공’을 쟁취하려 하는 개발자라고 하더라도. 비난하지 않는다.분명, 그 길은 대다수 ‘성공’이라고 부른다. 하지만, 그 길을 선택하고 집중하는 것 또한 매우 어렵고 힘든 길이다. 선택한다고 얻을 수 있는 길도 아니다.가령, 이 글을 읽는 독자가 학생이라면. 가장 먼저 명문대학을 가는 것부터 시작해야 할 테니, 당장, 이 내용을 덮어버리고, 국영수를 공부하는 것에 몰두해야 하기 때문이다.사실, 가장 넓게 알려진 성공으로 가는 길은 가장 가기 어려운 길인지도 모른다. 경쟁이란 정말 어렵고 힘들 것이라는 것을 잊지 말자.본론으로 다시 돌아와 보자. 개발자로서 '성공'이란 무엇을 의미하는가? 아니, 개발자로서 비전을  갖는다는 것은 무엇을 의미하는가?  원천적으로 개발자의 삶이란 어떻게 살아야 하나요라고 묻는다면,이 문제는 정말 어렵고, 사람마다 다르기 때문에 최선을 다하는 것이 정답이라라는 교과서적인 답변만 늘어놔야 하는지도 모르겠다.이점에 대해서는 이제는 폐간했지만 오랫동안 개발자들의 벗이 되었던 마이크로소프트웨어 잡지에 대해서 원망을  슬쩍해보자.그것은, 나에게 ‘정말 대단히 큰 재미’를 선사했다는 것이 나에게 가장 처음 다가온 충격이었는지도 모른다. 처음에 가진 꿈은 그냥, ‘소프트웨어 개발’을 통해서 삶을 영유할 수 있는 것만으로 나는 행복했다는 점이다. 그래서, 이 소프트웨어의 세계로 진입하게 된 마이크로소프트웨어에 대해서 원망을 해야 하는지도 모르겠다.하지만 필자는 소프트웨어로써 ‘개발자로서 성공’을 하기 위해서, 이 직업과 삶을 선택한 것이 아니라, ‘개발자로 살기 위해서’이 삶을 선택한 것이었다. 나이를 먹고, 무언가를 목표로 살아온 경험을  되돌아본다면, ‘돈’과 ‘명예’를 선택하지 않았을 때에, 오히려, ‘돈’과 ‘명예’를 얻지 않았는가 하다. 오히려, ‘돈’을 선택하던 시기에 ‘돈’을 더 많이 잃어버린 경험도 가지게 되었다.이제는 주변을  되돌아보면, 필자는 꽤 넓은 스펙트럼을 가지게 되었다는 것을 느끼게 된다. 한때는 고인이 되셨지만 대통령이셨던 분부터, 수천억을 소유한 재벌 총수, 의료재단과 대학법인을 소유하신 분, 병원의 원장님들을 비롯한 분들을 비롯하여, 출판계, 영화계, 물론. 다수의 소프트웨어 개발자들까지. 매우 넓은 사람 관계를 만들어본 것 같다.그중에 소프트웨어 개발자들은 참 착하고 바보스러운 사람들이 많은 것 같지만, 한편으로는 너무도 욕심이 많은 사람들이 존재하는 참, 신기한 동네이다.그리고, 여러 계층을 경험해보니. 모든 계층은 똑같이 피라미드 구조를 가지고 있다는 점이다. 대부분 다 똑같았다. 하층의 사람들은 싼 가격에 노동력과 지식을 제공하고, 상위 레벨에서는 적절한 대우 이상과 재미있고 신기한 일들을 많이 한다는 점이다. 이 부분은 어느 계층이나 똑같다.대표적으로 출판일을 경험했을 때에 자신의 이름이 들어간 편집장이 되는 사람과, 그것을 목표로 기획자로 일하는 직원의 급여 수준이나 처우, 대우는 정말 최고급 아키텍트와 SI 개발자를 비교하는 것 이상으로 그 상대 감은 소프트웨어 개발세 상의 것 이상으로 매우 컸다.행복한 개발자라고 한다면, ‘개발이 정말 재미있고’, ‘개발도 잘하고’, ‘소프트웨어 개발 피라미드의 상층부의 일’을 하고 있다는 사람이 있다면. 그 사람은 정말 행복할 것이다. 뭐, 그런 사람은 이 글을 읽고 있지도 않을 것이다.그러나, 개발이 재미있지 않거나, 개발을 뛰어나게 잘하지도 못하고, 소프트웨어 개발 피라미드의 하층부에서 일하고 있다면, 어떻게 생존해야 하는 가에 대해서 정말 심각하게 고민해야 한다.이 글을 읽는 독자가 이제 개발자의 길을 시작한 사람이라면 고민해라, 소프트웨어 개발을 비롯한 모든 전문적인 직업들은 새로운 것을 배우고, 익히고, 소모하면서 계속 변화되는 것을 즐길 줄 알아야 재미있는 직업이다. 그런 것이 아니라면, 정말 힘들고, 피곤하고 어려운 것이 전문직과 같은 직업이다. 만일 그런 것이 힘들다면 다른 일을 알아보는 것이 현명하다.소프트웨어 개발자들과 가장 비슷하게 일하는 웹디자이너들의 푸념이 있다.‘낮은 급여에 야근은 허구한 날, 거기에. 불투명한 미래’에 대한 그들의 이야기를 들으면서, 흔히 소프트웨어 개발자들은 그 질문에 답변한다. ‘너희들은 모니터라도 크지’라고. 대부분의 프로젝트들은 ‘분석’에 의해서 ‘일정’을 만들지 않고, ‘일정’을 통해서, ‘품질’을 선택한다고 봐야 한다.‘정말 하고 싶은 것이 무엇인가?’개발자들에게 물어보면, 대부분 당황하는 경우가 많다. 이것은 개발자이기 때문에 답변을 못하는 것이 아니라, 자신의 비전이나 꿈에 대해서 명쾌하게 정의하지 못하고 있기 때문이다. 주변의 초보 개발자들에게 이야기하고 싶은 점은...가끔은 수필집이나 여행기, 그리고. 다른 사람의 생각과 꿈에 대한 글을 많이 읽어보라고 권하는 것이다. 그러면, 그 비전과 꿈에 대해서 이야기해달라는 사람들이 꽤나 있고는 하다.문제는 그 비전은 누가 정해주는 것이 아니라, 자신이 생각하거나, 자신이 발견하는 것이 옳지 않냐고 다시 이야기를 해준다. 물론, 이렇게 이야기하는 사람도 있다.‘저는 이번 프로젝트에서 인정을 받아서, 다음 프로젝트를 수행할 때에는 팀장이 되고 싶어요!’라고 이야기할 수 있다. 하지만, 이런 ‘단기적인 비전’을 말하는 것은 아니다. 이런 ‘단기적인 비전’만을 따라가다 보면, 냉정하게 수단만 중요시 여기게 되고, 목적 자체를 잃어버린 인생의 방랑자가 될 가능성이 매우 크다.내가 생각하는 ‘성공’이란 과연 무엇인가?또 하나는, 그 ‘성공’의 목표를 너무 작게 가져도 문제이고, 너무 커도 문제라는 점이지만, 그래도, ‘꿈’과 ‘목표’가 있다는 것 자체가 재미있고, 신기하지 아니한가?‘성공은 자신이 정한 것을 이루는 것’을 의미한다고.그럼 ‘꿈’을 어떻게 정의하나요?1. 10년, 20년, 30년 후의 자신의 모습을 상상해보고 정의해봐라.2. 현재 내가 좋아하는 모든 것들을 적어봐라.3. 내가 가장 잘하고 가장 인정받는 것을 적어봐라.보통은 이렇게 끄적거리다 보면, 무언가가 조금은 구체적인 비전이 나올 수도 있지만, 아무렇지도 않은 것이 나올 수 있다. 하지만, 일단, 끄적이기 시작했다면, 다음번에는 좀 더 잘할 수 있다는 것이 중요하다. 가장 중요한 것은 ‘내가 비전에 대해서 생각하기 시작했다’는 점이다. 일단 작심 3일이라도 중요한 결정이다. 그것은, ‘결정’을 하고 ‘결심’을 하기 시작했다는 것이기 때문이다.일단, ‘써야 한다’. ‘생각은 생각일 뿐이다’주변의 개발자들이 가장 잘 못쓰는 말 중의 하나가 ‘머릿속에 다 있다’라는 말이고, ‘글로 쓰기에 너무 어려운 이야기’이다라는 이야기가 가장 잘못된 것이라는 것을 잘 모르는 경우가 많다.‘머릿속에 다 있다’라는 이야기는 한번 생각은 해봤으나, 결론을 내리지 못하였다는 이야기로 들리고, ‘글로 쓰기 어렵다는 이야기’는 그만큼 정리가 안되고, 그 일에 대해서 잘 모른다는 이야기와 똑같다.10년 20년 특정 도메인에서 일한 베테랑이라고 하는 개발자와 일을 할 때에, 자신이 하는 일은 너무도 복잡하여, 설계도나 다이어그램, 순서도, 타이밍 차트 등을 그릴 수 없다는 사람들이 있다.그들과 이야기하고, 그 업무를 다이어그램과 설계도로 만들어 주어도, 그들은 그것 말고, 설명이 안 되는 그 무언가가 있다고 이야기를 한다. 물론, 필자는 그때에 이렇게  이야기해준다.‘만일 그러한 것이 존재한다면. 그것은 당신만이 생각하는 경험이나 당신이 소중하게 생각하는 가치인지 모른다. 하지만, 그것은 어떤 지식이 되기에 매우 부족한 것일 수 있다. 지식은 설명하기 쉽고, 이해하기 쉬운 것이 지식이다. 설명하기 어려운 경험은 정규화되거나 전달되어지기 매우 어렵다’더 쉽게 이야기하면. ‘쉽게 설명하거나 글자로 남기지 못한다면, 당신은 그것에 대해서 잘 알고 있지 못한 것입니다’비전이나 목표 잡기가 너무 어려워요?!그렇다면, 당장 휴일에 컴퓨터를 내버려두고, 아이폰이나 패드와 같은 스마트하다고 우기는 디지털기기를 집안에 던져두고 여행을 떠나는 것이 현명한 방법이겠다. 그리고, 다른 매체를 들여다보고, 개발자 이외의 사람들을 만나서 이야기해보라라고 권유해야 하는 것이 맞을  듯하다.생각 이상으로 소프트웨어 개발자의 세계는 정말 좁다. 그리고, 단편적인 지식들과 단편적인 경험들만이 존재하는 세상인지도 모른다. 그래서, 소프트웨어 개발자들은 ‘관심의 폭을 넓히고,’ ‘자신을 확장’하는 것이 결론적으로는 더 뛰어난 개발자가 된다는 것을 나중에야 깨달을 것이다. 마지막으로 이야기한 한다면, 소프트웨어 개발자에게 ‘성공’이란 일단... 전혀 해보지 않았던 것을 도전해보는 것, 그리고. 삶은 소프트웨어 개발처럼 버전을 나누어서 설명하기 어렵다는 것을 이해하고. 무언가 계속 새로운 것에 도전한다는 것이 진정한 ‘성공’ 아닌가 한다.#와탭랩스 #와탭 #개발자 #개발 #프로그래머 #성공 #성공한개발자
조회수 1884

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

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 개발팀의 문화에 녹아들어 가장 효율적으로 일할 수 있는 방법이 되었습니다. 개발팀을 꾸려나가면서 여러가지 시행 착오를 겪어 왔지만, 시행 착오에 대한 반성과 여러가지 개선 시도를 통해 계속해서 더 좋은 방법을 찾아나가며 지금과 같은 개발 문화가 만들어졌습니다. 그동안 그래 왔듯이 앞으로 더 많은 개선을 통해 꾸준히 좋은 방법을 찾아 나갈 것입니다.네 그렇습니다. 결론은 저희와 함께 고민하면서 더 좋은 개발문화를 만들어나갈 개발자를 구하고 있다는 것입니다.저희는 언제나 타다 및 비트윈 서비스를 함께 만들며 기술적인 문제를 함께 풀어나갈 능력있는 개발자를 모시고 있습니다. 언제든 부담없이 jobs@vcnc.co.kr로 이메일을 주시기 바랍니다!
조회수 6753

KT 채용 필수 정보! 실무자가 직접 말하는 KT 人사이드(IT 직무 편)

다가오는 하반기 공채 시즌에 앞서, 지난주 KT 직원들이 직접 말하는 KT 人사이드 ‘영업/마케팅’ 직무 편 잘 보셨나요? 자율적이고 수평적인 회사 분위기와 신입사원에게 주도적으로 역량을 펼칠 기회를 주는 KT의 기업문화를 간접적으로 접할 수 있었는데요. 알면 알수록 빠져드는 KT의 매력! 이번 주에도 더욱 빠져보시라고 새로운 인터뷰를 준비했습니다. KT 人사이드 영업/마케팅 직무 편 보러 가기 지난주에 이어 이번 주에는 KT 기술의 핵심! IT 직무를 맡고 계신 KT人들의 이야기를 들어보려고 합니다. 그들이 말하는 사람을 향한 KT의 기술! 지금. 들어갑니다.  “KT는 다양한 기술 분야를 융합한, 성장 가능성이 가장 큰 곳입니다.”- KT 기업사업컨설팅본부 IoT컨설팅팀 조아영 Q. 현재 어떤 직무를 담당하고 계신가요?A. IT 컨설팅이라는 직무를 맡고 있습니다. 제 직무는 기업 및 공공고객들에게 저희 KT 상품을 제안하는 일이며, 저는 그 중에서도 IoT컨설팅팀에서 일하고 있습니다. ‘IoT를 B2B에 어떻게 적용하느냐’라고 많이들 궁금해하시는데, 원격검침부터 차량, 통신까지 다양한 분야에 적용을 하고 있습니다. 신사업이니 만큼 정형화된 제안보다는 조금 더 사업을 주도적으로 진행하면서 컨설팅하는 재미가 있습니다. 그리고 ‘IT컨설팅’은 프로젝트 수주 전까지 제안서를 작성하고 컨설팅하는 직무가 주 업무이고, ‘IT수행’은 프로젝트 수주 이후에 협력사와 같이 프로젝트를 진행하는 것이 주 업무라고 할 수 있습니다. Q. KT를 선택한 이유는 무엇인가요?A. KT는 기존 사업인 통신기술(CT)뿐 아니라 정보기술(IT)까지 광대한 사업영역을 가지고 있습니다. 두 분야를 융합하여 확장할 가능성이 매우 크다고 생각해 선택하게 되었습니다. 특히 IT컨설팅을 지원한 이유는, 컴퓨터를 전공하며 습득한 이공계적 지식과 더불어 대학 신문사 활동을 통해 얻게 된 논리적 사고, 커뮤니케이션 능력을 함께 활용하여 역량을 발휘할 수 있을 것이라 생각했기 때문입니다. 현실적으로는 전공을 살리면서 광화문에서 근무할 수 있다는 점 또한 큰 장점으로 다가왔습니다.Q. 하루 일과를 설명해주세요.A. 일과는 근무장소에 따라 크게 두 가지 경우로 나뉩니다. 광화문에서는 주로 선제안이나 보고 등 일상적인 업무가 주를 이룹니다. 선제안을 위해서는 보통 타 부서와의 회의, 고객사 방문, 선제안서 작성 등을 합니다. 시장 조사, 실적 파악 등 내부 보고를 위한 보고서 작성 업무도 함께 진행되곤 합니다. 프로젝트에 투입이 되면 보안 상의 이유로 제안센터에 가게 됩니다. 보안이 철저한 제안센터에서 제안서를 작성하는데, PM(Project Manager)의 지휘 아래 각PL(Part Leader)들은 제안요청서에 맞게 담당한 부분을 작성해 나갑니다. 매일 유사하게 반복되는 업무보다 마감에 따라 업무강도에 강약이 있는 사이클식 업무를 선호한다면 컨설팅 직무에 적합하다고 생각합니다. Q. 지원자에게 마지막으로 전하고 싶은 취업 팁은?A. KT는 지원자들의 자소서를 모두 읽기로 유명한 기업입니다. 취업의 첫 시작인 자소서에 진심이 보인다면 아주 특별한 스펙이 없다 하더라도 가능성이 충분하다고 생각합니다. KT의 면접 분위기 또한 비교적 정중하다고 생각합니다. 면접관마다 다르겠지만, 입사 후에도 느낀 전반적인 회사의 분위기는 온화하다는 것입니다. 면접관들 모두 최대한 피면접자의 이야기를 들어주려고 노력하신다는 점을 기억해 주세요. 식상한 말이지만, 면접 때 너무 꾸며낸 모습을 보여주려고 하지 마세요. 자소서와 면대면 상황에서 일관되고 자연스러운 모습을 보여준다면 좋은 결과가 있을 것이라 생각합니다. 제 경험에 비추어 생각해보면, 말을 유창하게 잘하는 것도 중요하겠지만 내용이 논리적이고 일관되냐가 더 중요했던 것 같습니다.“KT인에게는 동료와의 커뮤니케이션이 가장 중요한 포인트입니다.”- kt skylife 기술본부 ICT운영팀 손형락Q. 현재 어떤 직무를 담당하고 계신가요?A. ICT운영팀에서 고객시스템 운영을 맡고 있습니다. 스카이라이프의 고객님들을 맞이하기 위한 고객정보관리시스템을 관리합니다. 고객님들을 유치할 때 필요한 시스템을 고객센터 및 파트너社에 최상의 품질로 제공하기 위해 노력합니다. 시시각각 변화하는 영업환경에 대응하면서, 시스템을 관리 해야 하기 때문에 중요한 업무라 생각합니다. Q. kt skylife를 선택한 이유는 무엇인가요?A. kt skylife는 국내 유일의 위성방송 사업자입니다. 유일하다는 것은 그만큼 시장에서의 경쟁력이 있다는 것을 의미합니다. 경쟁사에서 시도하지 못하는 기술을, 위성을 통해 우리만의 기술로 사용할 수 있을 것입니다. 하루가 다르게 변해가는 시장에서 유일하다는 것은 기업의 가장 중요한 매력 포인트라고 생각합니다.Q. 하루 일과를 설명해주세요.A. 9시 출근이나 항상 30분 일찍 도착합니다. 혹시 모를 장애에 대비하기 위한 습관이라고나 할까요. 퇴근 후에 온 메일이 있는지 확인하고, 그날의 업무를 정리합니다. 스케줄대로 움직이다 보면 어느새 6시. 오전∙오후 시간 모두 각 사업부서와 협의하기 위한 시간으로 사용하지만, 짬짬이 나는 시간들을 잘 활용하면 6시에 퇴근할 수 있습니다. 6시 이후에는 어학 공부 및 새로운 IT 트렌드를 접할 수 있는 각종 세미나에 다니며 틈틈이 자기 계발을 위해 시간을 보내고 있습니다. Q. 지원자에게 마지막으로 전하고 싶은 취업 팁은?A. 상대방의 의견을 들을 수 있는 자세가 되어 있어야 합니다. 어떤 집단에 들어간다는 것은 그 때부터 스스로를 조금은 놓아야 한다고 생각합니다. 회사생활은 혼자서는 해낼 수 없는 중요한 업무들로 가득 차 있습니다. 동료들과 함께 나아갈 수 있는 사람임을 어필할 수 있다면 좋은 점수를 받지 않을까요? 커뮤니케이션이 가장 중요한 포인트인 것 같네요.  “KT는 생활 밀착형 복지 혜택이 좋은 기업입니다.“- KT 소프트웨어개발단 GIS정보제공서비스개발TF 송민정Q. 현재 어떤 직무를 담당하고 계신가요?A. 현재 GIS(지리정보시스템)의 검색 파트에서 개발 업무를 담당하고 있어요. 구체적으로는 크게 3가지로 나눌 수 있는데 데이터 정제 및 현행화 모듈 개발, 검색 엔진 개발 및 질의 최적화, 테스팅 도구 개발을 진행하고 있습니다. GIS 분야, 특히 검색 서비스는 올해 제가 처음 하는 분야라 기술 리서치 하는데 상대적으로 시간을 많이 쓰고 있어요. 또한 기존 서비스와의 차별점을 내세우기 위해 고객 요구 사항뿐만 아니라 자체적으로 요구 사항을 만들어 적용해 보기도 합니다. 국내외 유수 기업 고객의 지도 서비스, 나아가 KT 내비와 지도의 검색서비스로 출시될 생각에 벌써 가슴이 설레네요. Q. KT를 선택한 이유는 무엇인가요?A. 대학교 때 친하게 지냈던 선배가 KT로 입사했어요. 그래서 자연스럽게 업무 환경이나 조직 분위기에 대해 알 수 있었는데, 그때 저에게 있어 KT 기업 이미지가 긍정적으로 생기기 시작했던 것 같아요. 대부제도나 경조사 지원정책, 자녀를 임신하거나 출산한 여성에게 친화적인 제도 등 생활 밀착형 복지가 잘 되어 있다고 들었는데, 실제로 입사 후에 혜택을 많이 받고 있어요. 또한 다양한 ICT 사업시도를 하고 있는 KT에서 SW개발자에 대한 중요성이 점점 강조되고 있고, 전폭적인 지원을 해주고 있다는 소식도 선택의 큰 이유였던 것 같아요.Q. 회사에서 가장 보람 있었던 일은 무엇인가요?A. 입사 1년 차에 담당했던 'KT 패밀리박스' 앱 서비스 개발 업무 때의 일이에요. 경험이 부족한데도 믿고 맡겨주신 선배님 덕분에 앱 리뉴얼 서버 개발에 상당 부분 참여하게 되었습니다. 지금 생각해보면 그때 같은 상황을 기회라고 하는 것 같아요. 크고 작은 실수가 있었지만 모두 한마음으로 이해해 주셨어요. 출시 임박해서는 여타 서비스 개발이 그러하듯이 다소 고된 시간이 있었지만, 사업부서와 협업이 잘되어 그 어느 때보다 즐겁게 일했어요. 무엇보다 자식 같은 서비스가 출시되었을 때의 기쁨은 이루 말할 수가 없었네요. Q. 하루 일과를 설명해주세요.A. 매일 오전 10시에 20-30분간 진행되는 팀 미팅이 있어요. 어제 한 일, 오늘 할 일, 이슈사항을 공유합니다. 월/수/금요일 점심시간에는 운동 동호회 활동을 해요. 회사 헬스장에서 트레이너 선생님을 모시고 회원들과 40여 분 운동을 하며 체력 관리도 하고 스트레스도 풀어요. 오후에는 특별한 일이 없으면 업무에 집중해서 개발 업무를 해요. 비교적 자유롭게 동료들과 대화하며 문제를 해결하거나 토론을 해요. 동료와 한 자리에 앉아 페어 코딩을 할 때도 있어요. 6시가 넘으면 팀장님께서는 퇴근을 장려하세요. 더하고 싶거나 잔업이 있는 경우에는 자율적으로 야근을 하지만, 가급적 일과 시간에 마치려고 노력하는 편입니다.“KT에는 격려와 조언을 아끼지 않는 선배님들이 있습니다.“- kt telecop 차세대IT추진단 IT구축팀 편광일Q. 현재 어떤 직무를 담당하고 계신가요?A. 저는 IT구축팀에서 ‘케이티텔레캅’ App을 담당하고 있습니다. ‘케이티텔레캅’ App은 kt telecop 서비스, 요금 조회, 상담 등 고객님들께 꼭 필요한 서비스를 하나의 App을 통해서 해결할 수 있는 기능을 가지고 있습니다. 저는 이런 ‘케이티텔레캅’ App과 관련하여 사업부서와 Daily Meeting을 하고, 추가 기능 개발 및 유지 보수를 진행합니다. 또한, 새로운 기능 개발에 있어서 협력업체와 co-work할 경우 협력업체 선택, 프로젝트에 대한 전반적인 일정 관리, 새로운 기능에 대한 전략을 제시합니다. Q. 회사에서 가장 보람 있었던 일은 무엇인가요?A. 제가 회사에서 가장 보람 있었던 일은 ‘케이티텔레캅’ App 기능 중 하나를 개발한 것입니다. 개발 당시 신입사원인 저에게 큰 부담이 되어 홀로 인터넷, 서적 등을 참고하며 수차례 야근도 했습니다. ‘과연 내가 해낼 수 있을까?’라는 생각을 할 때쯤 팀 선배님들께서 이를 알아차리고, 격려와 함께 부족한 부분에 대한 조언과 자료 공유를 통해 하나씩 차근히 진행할 수 있도록 도와주셨습니다. 그 결과 무사히 프로젝트를 완료할 수 있었고, 이는 저를 응원해 주고 격려해 주는 선배님들이 있었기에 가능했다고 생각합니다. 신입사원 분들도 업무를 진행 할 때, 힘든 점이 있다고 혼자 고민하기보다 선배님 혹은 동기들에게 도움을 요청하면 더 좋은 결과를 얻을 수 있을 것입니다.Q. 하루 일과를 설명해주세요.A. 출근 후, 팀 동료들과 반가운 인사를 나누며 하루를 시작합니다. 오늘 해야 할 일들을 우선순위로 작성하고, 월/수/금요일에는 KT그룹의 사내방송(KBN)을 시청합니다.9시 - 팀 회의를 통해 그날의 이슈사항과 각자 할 일에 대해 공유합니다.10시 - 회사 내 시스템을 모니터링하며 실시간 상황을 체크합니다. 협력사와 함께 프로젝트 개발 이슈를 정리하고, 보완해야 할 부분은 직접 개발합니다.12시 - 즐거운 점심시간입니다! 저희 회사 지하에 위치한 구내식당 밥의 맛과 영양은 정말 최고입니다^^ 식사를 마치면 팀장님과 팀원들 모두 사다리 타기, 다트 등을 통해 음료 사주기 시간을 갖습니다.13시 - 점심 먹고 졸린 시간인 만큼 팀 내부적으로 안마해주기, 재미있는 이야기 하기 등으로 식곤증을 극복합니다.14시 - 사업부서와 시스템에 대한 추가 요구사항이나 이슈에 대해 공유하는 회의를 진행합니다. 회의를 통해 새롭게 도출된 요구사항을 시스템에 반영하고 수정∙보완합니다.18시 - 하루의 일과를 마치고 퇴근시간을 갖습니다. 특히, 매주 수요일은 ‘가족사랑의 날’이기 때문에 본부장님, 팀장님들과 함께 정시 퇴근합니다. Q. 지원자에게 마지막으로 전하고 싶은 취업 팁은?A. 대부분 취업준비생들은 자기소개서를 작성할 때, 회사 홈페이지 혹은 기사를 참고하면서 쓰곤 하는데, 저는 다른 지원자들보다 차별화를 두기 위해서 직접 본사에 찾아가 선배님들에게 많은 이야기를 들으려고 노력했습니다. 또한, ‘우수기업-청년 채용박람회’에 참석해 kt telecop 부스에서 인사지원팀 과장님들과 이야기를 나누며 회사에 대한 정보를 얻고, 저에 대해 강한 어필을 했습니다. 이 때 보여드린 ‘저의 입사 의지와 진정성이 합격에 결정적인 역할을 하지 않았나!’라는 생각을 하게 됩니다. 신입 공채를 지원하는 후배님들도 남들과는 다른 차별성을 갖고 우리kt telecop에 지원하게 된다면, 분명 좋은 결과를 얻을 수 있을 것입니다.지난주 영업/마케팅 직무에 이어 지금까지 IT 직무를 맡고 계신 KT人들의 이야기를 들어봤는데요. KT의 핵심 기술을 담당하고 있는 KT人들의 인터뷰를 보니, KT가 바라는 인재상에 대해 감이 잡히는 것 같지 않나요? 특히, IT 직무에 필요한 주요 역량으로는 동료∙고객사와의 원활한 커뮤니케이션 능력과 더불어, 체계적인 분석력과 참신한 개발능력이 필요할 것 같습니다. 이와 함께, IT분야에 종사하는 KT人들의 취업 핵심 팁은 자소서를 진솔하고 꼼꼼하게 쓸 것, 면접 시 자연스럽고 일관된 태도를 보이는 것, 그리고 입사 후 동료들과 협력하여 직무를 수행해낼 수 있는 가능성을 보이는 것! 여러분도 모두 해낼 수 있을 겁니다. KT 직무 인터뷰는 다음주에 더욱 풍성한 이야기로 찾아오겠습니다. 안녕!#kt #기업문화 #사내문화 #조직문화 #복지혜택 #kt공채 #하루일과 #kt일상 #구성원인터뷰 #직무정보
조회수 1248

소프트웨어 엔지니어 용현님을 소개합니다

Read in English같이 일하고 있는 직장 동료들에 대해 얼마나 알고 계시나요? 엑스브레인처럼 작은 팀의 경우에는 함께하는 한 분 한 분이 팀 전체 분위기에 끼치는 영향이 상당하답니다. 또한, 머신러닝 툴 ‘다리아’로 저희가 꿈꾸는 데이터 사이언스계의 변혁을 일으키려면, 이를 위해 일하는 팀 또한 서로 잘 알고, 협력할 줄 알아야겠죠.각각 개성이 넘치지만, 서로 모여 엑스브레인의 매일매일을 풍족하고 즐겁게 만들어가는 팀을 소개합니다! 각 멤버들의 일상과 엑스브레인에서의 직무에 대해서도 알아보고, 또 뉴욕타임즈에 실린 “상대방과 사랑에 빠질 수 있는 36가지 질문” 중 직장 동료에게 할 수 있을 만한, 가장 흥미로운 질문들을 추려서 진행한 인터뷰를 통해 엑스브레인 팀 멤버 개개인의 색다른 매력을 만나보세요.(그렇다고 진짜로 사랑에 빠지시면 곤란합니다…)올해 8월에 합류하신 용현님은 종민님과 함께 다리아의 소프트웨어를 책임지고 있는 엑스브레인의 엔지니어이십니다. 자칭 노잼이라고 하시지만, 사실 VR의 미래와 축구에 관심이 정말 많으신 분이죠. 가끔 모니터에 코드 대신 축구게임을 띄워놓고 계신 걸 목격하기도 했답니다…액티브한 엑스브레인을 지향하는 용현님을 만나보세요!창밖을 바라보는 용현님은 무슨 생각을 하는걸까요…(궁금)안녕하세요 용현님! 엑스브레인에서의 용현님의 역할에 대해서 얘기해주세요용현: 저는 소프트웨어 엔지니어로서 종민님과 함께 소프트웨어 인프라를 개발하고 테스팅하는 역할을 하고 있습니다.용현님의 엑스브레인에서의 하루 일과는 어떻게 되나요?용현: 요즘은 점심 때쯤 나와서, 그때그때 관련된일을 합니다. 오늘은 MS SQL이라는 다른 데이터베이스에서 데이터를 가져오는 테스팅을 했습니다. 가끔은 산책을 즐기기도 하고, 주로 저녁 식사 후 작업을 하다가 퇴근합니다.용현님의 직무 중 가장 즐기는 일은?용현: 머신러닝 모듈을 클라우드 시스템에 분산처리 하기 위해서는 수진님이 개발하신 걸 스파크로 바꾸고, 코드를 보고 변형해가면서 분석해 보는게 제일 재밌는 것 같아요.반대로, 가장 하기 싫은 일은?용현: 시스템을 테스트하기 위해 환경을 구축하는 일이 가장 어렵습니다. 가끔 지시대로 해도 잘 안되는 경우가 발생하거든요.용현님 책상에 있는 물건 중 용현님을 가장 잘 대변한다고 생각하는 아이템은?용현: 책상에 있는게 별로 없어서…아마 랩탑이겠죠? 입사할 때 회사에서 제공해준 거대한 랩탑.“거대한 랩탑"어떤 계기로 소프트웨어 엔지니어가 되셨는지?용현: 원래는 전공으로 역사를 정했는데, 주변의 컴퓨터 공부를 하는 사람들을 보면서, 직접 결과물을 고안해내고 만드는 과정이 신기했어요. 내가 생각하는 대로 아웃풋을 만들 수 있다는 점이 매력적이어서요.왜 엑스브레인인가요?용현: 일단 신입 개발자로서 아직 개발되고 있는 단계의 제품 개발에 합류할 수 있는 기회를 얻고 싶었어요. ‘다리아’ 개발 과정을 초기부터 일련으로 지켜볼 수 있다는게 신기하고. 또 프로그래밍 공부를 늦게 시작한 편이라 수학적인 배경이 부족하다고 느낀 적이 많았는데, 작업을 하면서 그런 쪽으로도 많이 배울 수 있어서 좋고요.팀 내 가장 최근 합류한 멤버 중 하나로서, 용현님이 생각하시는 엑스브레인의 비전을 말해주세요.용현: 엑셀처럼 일상에서 쉽게 접하고 쓸 수 있는 머신러닝 툴의 대명사가 되는게 목표이지 않을까요?작업할 때 주로 듣는 플레이리스트 top 3 공유해 주세요용현: 코딩할 때는 주로 EDM을 듣는 편입니다. 집중이 잘되기도 하고요. Hardwell On Air이라는 스테이션을 자주 듣습니다. 최근에 나온 에픽하이 트랙도 자주 듣고 있고요.씨네마 소사이어티 때 추천하고 싶은 영화가 있다면?용현: 와치맨 (2009). 빌런이기도 한 주인공 로셱이 매우 매력적이고, 재미있습니다.10년 뒤 지금, 용현님은 어떤 모습일까요?용현: 일하는 건…지금의 모습만 유지되었으면 좋겠네요. 데드라인에 크게 쫓기지 않고, 공부도 하면서 자기계발할 시간도 갖고, 시간이 나면 친구들과 축구도 할 수 있는 사람이 되어 있었으면 좋겠어요.이 세상의 어떤 사람과도 저녁 식사를 할 수 있다면, 누구와 같이 먹고 싶나요?용현: 딱히 생각이 나지는 않지만… 주커버그? 세상에 대한 다양한 비전이 있는 거 같아서요.만약에 한 명의 엑스브레인 멤버와 식사를 해야 한다면 누구와 하실 건가요?용현: 새로 오신 정갑님과 친해질 겸 식사 같이 하고 싶네요. 이야기도 잘 하시는 것 같고 재밌을 것 같아요.유명해지고 싶나요? 어떤 방법으로요?용현: 아니요.용현님에게 “완벽한” 날이란 어떤 날인가요?용현: 일과를 끝내고 침대에 들어가서, 내일의 일을 걱정하지 않고 잠들 수 있을 정도로 보람찬 하루일 것 같아요.90살까지 살 수 있고 마지막 60년을 서른 살의 마음, 혹은 서른 살의 몸으로 살 수 있다고 해봅시다. 몸과 마음 중 어느 쪽을 택할 건가요?용현: 30살의 몸이요. 마음이란게 젊을수록 꼭 좋은 건 아닌 거 같아요.용현님의 인생에서 가장 감사하게 생각하는 것은 무엇인가요?용현: 이때까지 하고 싶은 것, 배우고 싶은 것을 할 수 있었던 배경이 아닐까요? 또 전공을 바꾼다거나 진로를 선택할 때 독립적으로 정할 수 있었던 부분…그런 특권에 감사하고 있습니다.내일 아침 눈을 떴을 때 어떤 능력이나 특성을 가지게 된다면 어떤 것이었으면 좋겠어요?용현: 하려고 마음 먹은 일을 끝까지 해나가는 행동력, 추진력!오랫동안 하고 싶었던 일이 있나요? 왜 그 일을 하지 않았나요?용현: 요리를 늘 배우고 싶었어요. 학교 다닐 때는 기숙사에 살아서 그럴 기회가 없었고.. 지금이라도 시작하고 싶네요 :)지금까지 용현님 인생에서 가장 잘해낸 일은 무엇인가요?용현: 무언갈 배우는데 최선을 다한 것일 것 같아요..학교 내에서든 밖에서든.엑스브레인에서 가장 기억에 남는 일이 있다면?용현: 주로 야외에서 했던 이벤트? “규원 산악회”라던지, 함께 축구한다던지… 팀빌딩도 되는 것 같고요.1년 뒤 갑자기 죽을 것이라는 사실을 알게 된다면 지금 용현님의 삶의 방식 중 어떤 걸 바꿀 건가요? 왜 그렇죠?용현: 요즘 푹 쉬지를 못했는데…잠을 더 많이 잘 것 같네요.상대방과 가까운 친구가 되기 위해 상대방이 나에 대해 알아야 할 것을 말해보세요.저는 성격이 무던한 편이라, 누구와도 잘 지내는 편입니다.혹시 농담의 대상으로 삼아서는 안 된다고 생각하는 것이 있다면 어떤 것들이 있을까요?용현: 약자에 관한 농담, 그리고 상대방의 약점에 관한 농담은 삼가야 된다고 봅니다 .내가 생각하는 엑스브레인의 엑기스는?용현: 자율, 배려, 배움….너무 진지한가요?#엑스브레인 #팀원소개 #팀원인터뷰 #기업문화 #조직문화 #팀원자랑

기업문화 엿볼 때, 더팀스

로그인

/