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

Smart Contract 배포를 위한 준비 과정은 이전글 확인 부탁드립니다.저번시간과 연계하여 이번 시간엔 스마트 컨트랙트를 배포해 보도록 하겠습니다. 지갑 key와 계정 이름등은 본 포스팅에서 그대로 사용하시면 됩니다.배포할 컨트랙트는 eosio.token 으로 eos 개발환경 세팅 시 존재하는 코드를 컴파일하여 실제 사용하는 계정에 setting 하겠습니다. 먼저 컴파일을 위해 ../eos/contracts/eosio.token 으로 이동 하겠습니다.eos/contracts/eosio.token이동 하면 위와 같은 파일들을 확인 하실 수 있습니다.hpp : cpp 파일에서 사용하는 변수, 상수, 함수를 담는 헤더파일cpp : contract 함수를 구현하는 소스 파일eosiocpp 를 통해 소스코드를 컴파일 해보겠습니다. eosiocpp 는 WASM 및 ABI 컴파일러 로써 블록체인에 업로드 되는 .wasm, .wast, .abi 파일을 생성합니다. 또한 기본 스켈레톤 파일을 제공합니다eosiocppwasm 컴파일wasm 파일은 아래 명령어를 사용하여 컴파일 만들 수 있습니다.$ eosiocpp -o eosio.token.wast eosio.token.cppeosiocpp 명령어를 사용하여 컴파일 하게 되면 .wast 파일과 .wasm 파일을 생성하게 됩니다. 각 확장자는 다음을 의미합니다.wast : 텍스트 파일로써 읽을 수 있는 webAssembly 파일wasm : 컴퓨터가 실제로 이해할 수 있는 webAssembly 파일abi 파일 생성$ eosiocpp -g eosio.token.abi eosio.token.cppabi 파일은 JSON과 Binary 간에 사용자 작업을 변환하는 방법에 대해 설명해주는 파일입니다. 실제로 이 JSON 파일을 통해 블록체인 위에서 개발자와 사용자간 상호작용 하는데 도와주게 됩니다.위 2과정을 통해 abi 파일 과 wast 파일을 생성하게 됩니다.compile 결과Contract 세팅하기아래 명령어를 입력하여 contract 를 set 해줍니다.$ cleos set contract hexlanthenry ../eos/build/contracts/eosio.token account : contract 를 배포할 계정이름contract-dir : 계정에 set 할 contract 가 저장된 directoryset contract 수행 결과만약 해당 계정이 RAM 을 보유하고 있지 않다면 다음과 같은 에러가 나타날 것입니다. 이를 해결하기 위해 RAM 을 구매합니다.RAM을 보유없이 contract$ cleos system buyram hexlanthenry hexlanthenry "100.0000 EOS"payer : EOS 를 지불할 계정receiver : RAM 을 사용할 계정amount : 지불할 EOS의 양 ( eos 1.1 기준 소수점4개 자리와 symbol을 무조건 넣어주어야 정상 동작 합니다)contract 확인계정에 contract가 잘 배포 되었는지 확인해 보겠습니다.$ cleos get code hexlanthenry배포한 contract 가 있을때의 code hash배포한 contract 가 없을때의 code hash또한 abi 를 통해서도 확인할 수 있습니다.$ cleos get abi hexlanthenryget abi위 과정을 통해 해당 계정에 실제로 contract 가 잘 배포 되었는지 확인 할 수 있습니다.다음 시간에는 배포된 contract 를 통하여 토큰을 발행 해보고 token에 대한 balance 체크 및 transfer 하는 과정을 진행해 보도록 하겠습니다.+또한 abi를 분석하여 struct 와 action 을 어떻게 확인 하는지에 대한 자세한 방법은 다른 포스팅에서 다루도록 하겠습니다.감사합니다.#헥슬란트 #HEXLANT #블록체인 #개발자 #개발팀 #기술기업 #기술중심

안녕하세요. 언제 어디서나 함께하는 코딩 교실 엘리스입니다 :)아이디어만 좋다면 뭐든 실현해볼 수 있는 시대! 지금은 '프로그래밍'이라는 강력한 무기를 통해 원하는 세계를 실현할 수 있는 잠재적 가능성이 폭발적인 때입니다. 그리고 그 기회는 비단 '개발자'라는 특정 직업에 국한하지 않더라도 각계 분야에 펼쳐져 있는데요. 이미 마케터, 기획자, 디자이너, 콘텐츠 창작자, 금융업계 종사자, 지리학자, 연구원 등 다양한 분야의 많은 사람들이 프로그래밍을 통해 각자의 영역과 세계 곳곳을 새로운 곳으로 만들고 있습니다.높은 급여와 삶의 질을 보장하고 나의 꿈을 펼칠 수 있는 탁월한 수단인 프로그래밍.프로그래밍을 업으로 삼고 있는 사람들의 시작은 어땠을까요?이 글에서는 소프트웨어 엔지니어가 되고자 이제 막 마음먹은 분들을 위해 프로그래머가 되기 위한 다섯 가지 짚고 넘어가면 좋을 팁들을 알려드릴게요.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 스텝을 계속 반복해나가면서 익숙해지고, 다른 역할로 각각의 스텝에 참여하게 되는 일이 아닐까요.엘리스는 누구나 프로그래밍을 통해 원하는 일을 할 수 있도록 좋은 강의 콘텐츠와 서비스, 플랫폼으로 여러분의 다섯 스텝에 함께하고자 합니다. :) 막막한 초심자 분들에게 앞으로의 방향성을 그려보는 데에 조금이라도 도움이 되길 바라며 글을 발행합니다.그럼 엘리스에서 만나요! >> 엘리스 아카데미 바로가기* 이밖에 조언, 첨언, 질문 등을 댓글로 남겨주시면 이 글의 독자분들에게 큰 도움이 됩니다.

비트윈에는 커플들이 서로에게 감정을 더욱 잘 표현할 수 있도록 스티커를 전송할 수 있는 기능이 있습니다. 이를 위해 스티커 스토어에서 다양한 종류의 스티커를 제공하고 있으며 사용자들은 구매한 스티커를 메시지의 첨부파일 형태로 전송을 할 수 있습니다. 저희가 스티커 시스템을 구현하면서 맞딱드린 문제와 이를 해결한 방법, 그리고 프로젝트를 진행하면서 배운 것들에 대해 소개해 보고자 합니다.스티커 시스템 아키텍처¶비트윈에서 스티커 기능을 제공하기 위해 다양한 구성 요소들이 있습니다. 전체적인 구성은 다음과 같습니다.비트윈 서버: 이전에 소개드렸었던 비트윈의 서버입니다. 비트윈의 채팅, 사진, 기념일 공유 등 제품내의 핵심이 되는 기능을 위해 운영됩니다. 스티커 스토어에서 구매한 스티커는 비트윈 서버를 통해 상대방에게 전송할 수 있습니다.스티커 스토어 서버: 스티커를 구매할 수 있는 스토어를 서비스합니다. 스티커 스토어는 웹페이지로 작성되어 있고 아이폰, 안드로이드 클라이언트와 유기적으로 연동되어 구매 요청 등을 처리합니다. 처음에는 Python과 Flask를 이용하여 구현하려 하였으나 결국엔 서버 개발자들이 좀 더 익숙한 자바로 구현하기로 결정하였습니다. Jetty와 Jersey를 사용하였고, HTML을 랜더링하기 위한 템플릿 엔진으로는 Closure Template을 이용하였습니다. ORM으로는 Hibernate/JPA, 클라이언트와 웹페이지간 연동을 위해서 Cordova를 이용하였습니다. EC2에서 운영하고 있으며 데이터베이스로는 RDS에서 제공하는 MySQL을 사용합니다. 이미 존재하는 솔루션들을 잘 활용하여 최대한 빨리 개발 할 수 있도록 노력을 기울였습니다.스티커 다운로드 서버: 스티커는 비트윈에서 정의한 특수한 포맷의 파일 형태로 제공됩니다. 기본적으로 수 많은 사용자가 같은 스티커 파일을 다운로드 받습니다. 따라서 AWS에서 제공하는 CDN인 CloudFront을 이용하며, 실제 스티커 파일들은 S3에서 호스팅합니다. 그런데 스티커 파일들은 디바이스의 해상도(DPI)에 따라 최적화된 파일들을 내려줘야하는 이슈가 있었습니다. 이를 위해 CloudFront와 S3사이의 파일 전송에 GAE에서 운영중인 간단한 어플리케이션이 관여합니다. 이에 대해서는 뒷편에서 좀 더 자세히 설명하도록 하겠습니다.구현상 문제들과 해결 방법들¶적정 기술에 대해 고민하다¶스티커 스토어 서버를 처음 설계할때 Flask와 SQLAlchemy를 이용하여 구현하고자 하였습니다. 개발팀 내부적으로 웹서버를 만들때 앞으로 Python과 Flask를 이용해야겠다는 생각이 있었기 때문이며, 일반적으로 Java보다는 Python으로 짜는 것이 개발 효율이 더 좋다는 것은 잘 알려진 사실이기도 합니다. 하지만 Java에 익숙한 서버 개발자들이 Python의 일반적인 스타일에 익숙하지 않아 Python다운 코드를 짜기 어려웠고, 오히려 개발하는데 비용이 더 많이 들어갔습니다. 그래서 개발 중에 다시 웹 서버는 자바로 짜게 되었고, 여러가지 스크립트들만 Python으로 짜고 있습니다. 실제 개발에 있어서 적절한 기술의 선택은 실제 프로젝트에 참여하는 개발자들의 능력에 따라 달라져야한다는 것을 알게되었습니다.스티커 파일 용량과 변환 시간을 고려하다¶사용자는 스티커 스토어에서 여러개의 스티커가 하나로 묶인 스티커 묶음을 구매하게 됩니다. 구매 완료시 여러개의 스티커가 하나의 파일로 압축되어 있는 zip파일을 다운로드 받게 됩니다. zip파일내의 각 스티커 파일에는 스티커를 재생하기 위한 스티커의 이미지 프레임들과 메타데이터에 대한 정보들이 담겨 있습니다. 메타데이터는 Thrift를 이용하여 정의하였습니다.스티커 zip파일 안에는 여러개의 스티커 파일이 들어가 있으며, 스티커 파일은 다양한 정보를 포함합니다카카오톡의 스티커의 경우 애니메이션이 있는 것은 배경이 불투명하고 배경이 투명한 경우에는 애니메이션이 없습니다. 하지만 비트윈 스티커는 배경이 투명하고 고해상도의 애니메이션을 보여줄 수 있어야 했습니다. 배경이 투명한 여러 장의 고해상도 이미지를 움직이게 만드는 것은 비교적 어려운 점이 많습니다. 여러 프레임의 이미지들의 배경을 투명하게 하기 위해 PNG를 사용하면 JPEG에 비해 스티커 파일의 크기가 너무 커집니다. 파일 크기가 너무 커지면 당시 3G 환경에서 다운로드가 너무 오래 걸려 사용성이 크게 떨어지기 때문에 무작정 PNG를 사용할 수는 없었습니다. 이에 대한 해결책으로 투명 기능을 제공하면서도 파일 크기도 비교적 작은 WebP를 이용하였습니다. WebP는 구글이 공개한 이미지 포맷으로 화질 저하를 최소화 하면서도 이미지 파일 크기가 작다는 장점이 있습니다. 각 클라이언트에서 스티커를 다운 받을때는 WebP로 다운 받지만, 다운 받은 이후에는 이미지 로딩 속도를 위해 로컬에 PNG로 변환한 스티커 프레임들을 캐싱합니다.그런데 출시 된지 오래된 안드로이드나 iPhone 3Gs와 같이 CPU성능이 좋지 않은 단말에서 WebP 디코딩이 지나치게 오래 걸리는 문제가 있었습니다. 이런 단말들은 공통적으로 해상도가 낮은 디바이스였고, 이 경우에는 특별히 PNG로 스티커 파일을 만들어 내려줬습니다. 이미지의 해상도가 낮기 때문에 파일 크기가 크지 않았고, 다운로드 속도 문제가 없었기 때문입니다.좀 더 나은 주소 포맷을 위해 GAE를 활용하다¶기본적으로 스티커는 여러 사용자가 같은 스티커 파일을 다운받아 사용하기 때문에 CDN을 이용하여 배포하는 것이 좋습니다. CDN을 이용하면 스티커 파일이 전 세계 곳곳에 있는 엣지 서버에 캐싱되어 사용자들이 가장 최적의 경로로 파일을 다운로드 받을 수 있습니다. 그래서 AWS의 S3와 CloudFront를 사용하여 스티커 파일을 배포하려고 했습니다. 또한, 여러 해상도의 디바이스에서 최적의 스티커를 보여줘야 했습니다. 이 때문에 다양한 해상도로 만들어진 스티커 파일들을 S3에 올려야 했는데 클라이어트에서 스티커 파일을 다운로드시 주소 포맷을 어떻게 가져가야 할지가 어려웠습니다. S3에 올리는 경우 파일와 디렉터리 구조 형태로 저장되기 때문에 아래와 같은 방법으로 저장이 가능합니다.http://dl.sticker.vcnc.co.kr/[dpi_of_sticker]/[sticker_id].sticker하지만, 이렇게 주소를 가져가는 경우 클라이언트가 자신의 해상도에 맞는 적절한 스티커의 해상도를 계산하여 요청해야 합니다. 이것은 클라이언트에서 서버에서 제공하는 스티커 해상도 리스트를 알고 있어야 한다는 의미이며, 이러한 정보들은 최대한 클라이언트에 가려 놓는 것이 유지보수에 좋습니다. 클라이언트는 그냥 자신의 디스플레이 해상도를 전달하기만 하고, 서버에서 적절히 계산하여 알맞은 해상도의 스티커 파일을 내려주는 것이 가장 좋습니다. 이를 위해 스티커 다운로드 URL을 아래와 같은 형태로 디자인하고자 하였습니다.http://dl.sticker.vcnc.co.kr/[sticker_id].sticker?density=[dpi_of_device]하지만 S3와 CloudFront 조합으로만 위와 같은 URL 제공은 불가능하며 따로 다운로드 서버를 운영해야 합니다. 그렇다고 EC2에 따로 서버를 운영하는 것은 안정적인 서비스 운영을 위해 신경써야할 포인트들이 늘어나는 것이어서 부담이 너무 컸습니다. 그래서, 아래와 같이 GAE를 사용하기로 하였습니다.GAE는 구글에서 일종의 클라우드 서비스(PaaS)로 구글 인프라에서 웹 어플리케이션을 실행시켜 줍니다. GAE에 클라이언트에서 요청한 URL을 적절한 S3 URL로 변환해주는 어플리케이션을 만들어 올렸습니다. 일종의 Rewrite Engine 역할을 하는 것입니다. 서비스의 안정성은 GAE가 보장해주고, S3와 CloudFront의 안정성은 AWS에서 보장해주기 때문에 크게 신경쓰지 않아도 장애 없는 서비스 운영이 가능합니다. 또한 CloudFront에서 스티커 파일을 최대한 캐싱 하며 따라서 GAE를 통해 새로 요청을 하는 경우는 거의 없기 때문에 GAE 사용 비용은 거의 발생하지 않습니다. GAE에는 클라이언트에서 보내주는 해상도를 보고 적당한 해상도의 스티커 파일을 내려주는 아주 간단한 어플리케이션만 작성하면 되기 때문에 개발 비용도 거의 들지 않았습니다.토큰을 이용해 보안 문제를 해결하다¶실제 스티커를 구매한 사용자만 스티커를 사용할 수 있어야 합니다. 스티커 토큰을 이용해 실제 구매한 사용자만 스티커를 전송할 수 있도록 구현하였습니다. 사용자가 스티커 스토어에서 스티커를 구매하게 되면 각 스티커에 대한 토큰을 얻을 수 있습니다. 스티커 토큰은 다음과 같이 구성됩니다.토큰 버전, 스티커 아이디, 사용자 아이디, 유효기간, 서버의 서명서버의 서명은 앞의 네 가지 정보를 바탕으로 만들어지며 서버의 서명과 서명을 만드는 비밀키는 충분히 길어서 실제 비밀키를 알지 못하면 서명을 위조할 수 없습니다. 사용자가 자신이 가지고 있는 스티커 토큰과 그에 해당하는 스티커를 비트윈 서버로 보내게 되면, 비트윈 서버에서는 서명이 유효한지 아닌지를 검사합니다. 서명이 유효하다면 스티커를 전송이 성공하며, 만약 토큰이 유효하지 않다면 스티커의 전송을 허가하지 않습니다.못다 한 이야기¶비트윈 개발팀에게 스티커 기능은 개발하면서 우여곡절이 참 많았던 프로젝트 중에 하나 입니다. 여러 가지 시도를 하면서 실패도 많이 했었고 덕분에 배운 것도 참 많았습니다. 기술적으로 크게 틀리지 않다면, 빠른 개발을 위해서 가장 익숙한 것으로 개발하는 것이 가장 좋은 선택이라는 알게 되어 스티커 스토어를 Python 대신 Java로 구현하게 되었습니다. 현재 비트윈 개발팀에서 일부 웹사이트와 스크립트 작성 용도로 Python을 사용하고 있지만 Python을 잘하는 개발자가 있다면 다양한 프로젝트들를 Python으로 진행할 수 있다고 생각합니다. 팀내에 경험을 공유할 수 있는 사람이 있다면 피드백을 통해 좋은 코드를 빠른 시간안에 짤 수 있고 뛰어난 개발자는 언어와 상관없이 컴퓨터에 대한 깊이 있는 지식을 가지고 있을 것이기 때문입니다.네 그렇습니다. 결론은 Python 개발자를 모신다는 것입니다.저희는 언제나 타다 및 비트윈 서비스를 함께 만들며 기술적인 문제를 함께 풀어나갈 능력있는 개발자를 모시고 있습니다. 언제든 부담없이 [email protected]로 이메일을 주시기 바랍니다!

안녕하세요. 크몽 개발팀 입니다~ 개발자는 무엇인가 개발하기 전에 준비해야될게 있습니다. 바로 개발도구들 과 자신에게 잘 맞는 셋팅이 필요하죠.그래서 이번에 개발환경을 셋팅하면서 알게 된 정보를 공유하기위해 이번 포스트를 작성하게 되었습니다.첫번째 개발도구는 'ampps' 입니다.  ampps는 개발에 있어서 필요한 다양한 개발도구들을 제공해주고 있는데요. 정석대로 하나씩 개발도구들을 설치하게 된다면 많은 시간을 투자해서 설치 및 셋팅을 해야하지만ampps는 한번의 설치만으로 Apache, MySQL, PHP, Python, MongoDB 등등 기본적인 셋팅을 통해 초보개발자이더라도 쉽고 편리하게 사용할 수 있다는점이 가장 큰 장점이라고 생각하고 있습니다.지원되는 운영체제는 Windows, Mac, Linux 모두 지원하기때문에 어느 운영체제는 지원이 안되는 불편함은 없겠네요.사이트 :http://www.ampps.com/ 두번째 개발도구는 'WebStorm' 입니다.  WebStorm은 비쥬얼스튜디오나 이클립스와 같은 통합 개발환경을 제공하고 있습니다.그리고 현재 자바스크립트 프로그래밍에서 절대적인 최고의 에디터로 개발자 사이에서 유명하고 많은 개발자들이 사용하여 개발하고 있습니다. WebStorm의 좋은점은 작성한 코드에서 에러가 있다면 JSHint가 에러부분 밑에 워드프로세서 철자법검사기처럼 빨간 줄로 에러를 표시해 주기때문에 개발자의 실수들을 바로 잡아줄 수 있어서 정말 좋습니다. 그러나 사용자는 30일 평가기간이 끝나면 추가비용을 지불해야 사용할 수 있는데요. 비용을 지불할 만큼 좋은 에디터인점은 변함이 없습니다.  사이트 : https://www.jetbrains.com/webstorm/  앞으로도 공유할 정보들이 생길때마다 크몽팀 블로그에 업데이트 할 예정입니다.포스트 내용에서 찾으시는 정보들을 찾으셨으면 좋겠고 크몽팀 개발자이야기에 많은 관심 부탁드립니다. :)이상 포스트를 마치겠습니다. #크몽 #개발팀 #인턴 #인턴생활 #경험공유

Logstash로 로그를 수집한 후 Elasticsearch와 Kibana로 분석하는 방법을 다룬 글은 많다. 그런데 이상하더라 이 말이지. 로그를 분석하고 경향을 파악하는 정도라면야 괜찮은데 심각한 오류 로그를 발견했을 때 Slack이나 이메일 등으로 알람 받을 수단이 마땅치 않더라. 사람이 키바나 대시보드를 5분마다 확인할 수도 없는 노릇이다. (이건 새로운 차원의 고문?)이런 생각을 먼저 한 사람이 있기 마련이라 Yelp의 elastalert라던가 Elasticsearch의 X-Pack을 활용하면 이런 문제를 해소할 수 있다. 오늘은 그 중에서 후자를 살펴볼 예정이다.경고! X-Pack은 Elasticsearch가 유료 서비스 시장을 열려고 야심차게 미는 모양인데 “자기네가 직접 만들었으니 쿨하겠지?”라고 쉽게 생각하면 하루 안에 절벽 아래로 떨어지는 끔찍한 기분을 맞이할 수도 있다.X-Pack은 가격이 상당한데 Alert 등을 설정하려면 전적으로 RESTful API에 의존해야 한다. 적어도 아직까지는! 이 사실을 깨닫자마자 당황할 수 있는데 침착하자. 이것은 시작일 뿐이다. 여러분이 검색엔진의 초보라면 그 다음 난관은 검색 쿼리를 작성하는 것이다. “나는 그냥 OutOfMemoryError 로그를 발견하면 알람을 보내줬으면 좋겠어"라고 쉽게 생각했겠지만 그 간단한 결과를 얻으려면 험난한 여정을 거쳐야 한다."search" : { "request" : { "indices" : [ "", ], "body" : { "query" : { "bool" : { "must" : { "multi_match": { "query": "OutOfMemoryError", "fields": ["message", "log"] } }, "filter" : { "range": { "@timestamp": { "from": "{{ctx.trigger.scheduled_time}}||-5m", "to": "{{ctx.trigger.triggered_time}}" } } } } } } } }음… 좋다. 일단 이렇게 작성한 쿼리가 제대로 된 것인지 테스트하려면 어떻게 해야 하는가? 검색 API로 대충 테스트해볼 수는 있다.GET logstash-2017.02.2*/_search { "query" : { "bool" : { "must" : { "multi_match": { "query": "OutOfMemoryError", "fields": ["message", "log"] } } } } }어찌어찌 잘 나온다. 그래서 잘 돌 줄 알았지? 그럴 줄 알고 있다가 이런 메시지를 만난다.Trying to query 1157 shards, which is over the limit of 1000. This limit exists because querying many shards at the same time can make the job of the coordinating node very CPU and/or memory intensive. It is usually a better idea to have a smaller number of larger shards. Update [action.search.shard_count.limit] to a greater value if you really want to query that many shards at the same time.음… logstash 인덱스를 매시간마다 분할했더니 샤드가 꽤 많아진 모양이다. 그래서 최근 두 개의 인덱스로 검색 대상을 제한하려고 한다. Date math support in index names라는 문서에 인덱스 이름을 동적으로 바꾸는 법이 나와 있긴 하다. 그런데 막상 내가 짠 게 어떤 값이 나오는지 확인하는 방법은 제대로 안 나온다. 예를 들어 가 logstash-2017.02.22t01로 해석되는지 어떻게 아는가? 많은 삽질 끝에 방법을 찾았다.를 URL 인코딩한다.그렇게 얻은 값 을 가지고 인덱스 조회 API를 호출한다. GET /3Clogstash-{now-1h/d}t{now-1h{HH}}>그러면 다음과 같이 결과가 나와서 인덱스 이름이 어떻게 해석됐는지 확인할 수 있다.{ "logstash-2017.02.23t01": { "aliases": {}, "mappings": { /* 중략 */ } }여기까지는 전적으로 검색 쿼리 작성 경험이 부족해서 발생한 삽질이다. 하지만 애플리케이션 로그 분석을 패턴화하지 않고 이렇게 검색 쿼리를 복잡하게 짜야 한다니 아직 갈 길이 멀다는 생각이 든다. DataDog 또는 NewRelic 같은 상용 서비스를 참고해서 개선하면 좋겠다.이제 결과를 알람으로 보내면 된다. 이래저래 고생하다 대충 아래와 같은 형태로 완성했다.PUT _xpack/watcher/watch/outofmemoryerror { "trigger" : { "schedule" : { "cron" : "0 0/4 * * * ?" } }, "input" : { "search" : { "request" : { "indices" : [ "", "" ], "body" : { "query" : { "bool" : { "must" : { "multi_match": { "query": "OutOfMemoryError", "fields": ["message", "log"] } }, "filter" : { "range": { "@timestamp": { "from": "{{ctx.trigger.scheduled_time}}||-5m", "to": "{{ctx.trigger.triggered_time}}" } } } } }, "sort" : [ { "@timestamp" : {"order" : "desc"}}, "_score" ] } } } }, "condition" : { "compare" : { "ctx.payload.hits.total" : { "gt" : 0 }} }, "actions" : { "notify-slack" : { "throttle_period" : "5m", "slack" : { "message" : { "to" : [ "#ops", "@dev" ], "text" : "로그 모니터링 알람", "attachments" : [ { "title" : "OutOfMemoryError", "text" : "지난 5분 동안 해당 오류가 {{ctx.payload.hits.total}}회 발생했습니다. 가장 최근의 오류는 다음과 같습니다.", "color" : "warning" }, { "fields": [ { "title": "환경", "value": "Prod", "short": true }, { "title": "발생시각", "value": "{{ctx.payload.hits.hits.0._source.@timestamp}}", "short": true }, { "title": "메시지", "value": "{{ctx.payload.hits.hits.0._source.message}}", "short": false }, { "title": "확인명령어", "value": "`GET /{{ctx.payload.hits.hits.0._index}}/{{ctx.payload.hits.hits.0._type}}/{{ctx.payload.hits.hits.0._id}}`", "short": false } ], "color" : "warning" } ] } } } } }4분마다 검색 쿼리를 실행해서 최근 5분 간의 레코드를 감시하기 때문에 동일한 오류에 대해 2회 연속으로 알람을 받을 가능성이 있다. X-Pack은 이를 우회할 방법을 제공하지 않는 것 같다. 그래서 쿼리가 발견한 레코드의 인덱스 ID를 Slack 메시지 중 확인명령어 필드에 넣었다. 알람이 두 번 왔지만 인덱스 아이디가 동일하다면 오류가 한번 발생한 것으로 간주하면 된다.참고 문서위의 Alert를 작성하며 도움을 받은 문서는 다음과 같다.Multi Search Template은 검색 쿼리를 짤 때 도움이 됐다.Search Input 문서는 검색 쿼리 또는 검색 결과를 작성할 때 어떤 변수를 사용할 수 있는지 설명한다. 예) {{ctx.payload.hits.hits.0._source.message}}Watcher APIsSlack ActionDate math support in index names 문서는 인덱스 이름을 동적으로 바꾸는 법을 설명한다.기타Elasticsearch Cloud는 기본적으로 이메일 발송을 지원하기 때문에elasticsearch.yml 설정에 xpack.notification.email를 추가하지 않아도 된다. 아니, 추가하면 잘못된 설정이라며 거부한다. Illegal이라고만 하지 이유를 자세히 알려주지 않기 때문에 삽질하기 쉽니다. Invalid addresses라고 오류 로그가 찍히면 이것은 설정 문제가 아니다. 이메일 설정 메뉴로 가서 Watcher Whitelist에 수신 이메일 주소를 등록하면 문제가 해결된다.테스트용 로그 메시지를 Fluentd로 보내고 싶다면 fluent-cat 명령을 이용한다.echo '{"message":"Dummy OutOfMemoryError"}' | fluent-cat kubernetes.logOriginally published at Andromeda Rabbit.#데일리 #데일리호텔 #개발 #개발자 #개발팀 #인사이트

레진엔터테인먼트는 글로벌(한국, 일본, 미국) 서비스를 운영하고 있기에 다양한 사람들의 재능과 욕구에 관심이 있습니다. 우리는 웹 접근성에 관심을 기울여 조금 특별한 욕구를 가진 사람들의 문제를 해결하려고 합니다. 소수의 특별한 욕구는 모두의 욕구와 연결되어 있다고 생각하기 때문입니다.조금 특별한 욕구를 가진 사람WHO는 세계 인구의 15%에 해당하는 사람들이 장애가 있는 것으로 파악하고 있습니다. 그리고 보건복지부 장애인 실태조사에 따르면 후천적 장애 발생률은 90% 수준입니다. 이런 통계에 따르면 한 개인이 일생을 살면서 장애인이 되거나 일시적으로 장애를 체험하게 될 확률은 무려 13.5%나 됩니다.저는 적록 색약입니다. 약한 수준의 장애로 분류할 수 있죠. 채도가 낮은 상태의 적색과 녹색을 쉽게 구별하지 못합니다. 충전 중 적색이었다가 완충이 되면 초록색으로 변하는 LED가 박혀있는 전자제품은 전부 망했으면 개선하면 좋겠어요. 전 세계 남성의 8%가 색약이고, 여성은 0.5%가 색약입니다. 대부분 적록 색약이고 마크 저커버그도 적록 색약입니다. 만화가 이현세 선생님도 적록 색약이고요. 한편 색약인 사람은 빛의 밝고 어두움을 구별하는 능력이 뛰어난 것으로 밝혀져 있어 저격과 관측에 탁월한 능력을 발휘합니다. 숨어있는 저격수 빨리 찾기 게임을 해 보세요. 위장 사진 1, 위장 사진 2, 위장 사진 3. 색약인 사람이 이길 것입니다.전맹 시각장애인은 마우스 포인터와 초점을 볼 수 없으므로 키보드만을 사용해서 웹을 탐색합니다. 키보드와 음성 낭독에 의존하지만, 키보드 기능을 정말 잘 다루죠. 그래서 키보드 접근성 문제를 해결하면 시각장애인뿐만 아니라 키보드를 능숙하게 사용하는 사람들의 사용성이 높아집니다. 소수의 특별한 요구사항을 해결하는 것이 모두를 위한 설계와 연결되어 있습니다.결국, 누구에게나 특별히 다른 측면이 있고 그것을 고려할 때 "모두를 즐겁게 하라!"라는 우리의 좌우명에 한 걸음 더 가까워질 수 있다고 믿습니다.도저히 풀 수 없을 것 같은 숙제웹 접근성을 소개할 때 많이 듣는 질문이 있습니다.장애인이 우리 서비스를 이용해요?매출에 도움이 돼요?시간과 비용이 많이 필요하지 않아요?이 질문에 대한 제 대답은 다음과 같습니다.이용한다면 기쁠 것 같아요.큰 도움은 안 될 거예요.조금은 그렇죠. 하지만 반환이 있어요.레진코믹스와 같이 이미지 기반의 콘텐츠를 서비스하는데 웹 접근성을 준수하려고 노력한다는 것은 무모한 도전에 가깝습니다. 왜냐하면, 현재로서는 전맹 시각장애인 고려가 없고 논의조차 쉽지 않기 때문입니다.하지만 달에 갈 수 없다고 해서 일찌감치 체념할 필요는 없겠지요. 쉬운 문제부터 하나씩 풀어 나아가길 기대합니다. 로켓에 올라탔으니까 금방 갈 수 있지 않을까요?W3C 표준을 우리 언어로W3C에서는 WCAG 2.1이라는 웹 콘텐츠 접근성 지침을 제시하고 있고요. 국내 표준 KWCAG 2.1 또한 있습니다. 국내 표준은 W3C 표준에서 중요도가 높은 항목을 우리 언어로 정리한 것이기 때문에 결국 어떤 지침을 선택해서 따르더라도 괜찮습니다.하지만 표준 문서는 너무 장황하고 전문 용어가 많아 다양한 분야 전문성을 가진 직원들과 함께 보기에는 한계가 있다고 생각했습니다. W3C 표준을 근간으로 하되 비전문가도 15분 정도면 읽고 이해할 수 있을 만큼 정리된 문서가 필요했고 레진 웹 접근성 가이드라인 사내 표준을 제안하고 공개하게 됐습니다.의미를 전달하고 있는 이미지에 대체 텍스트를 제공한다.전경 콘텐츠와 배경은 4.5:1 이상의 명도 대비를 유지한다.화면을 400%까지 확대할 수 있다.키보드만으로 조작할 수 있다.사용할 수 있는 충분한 시간을 제공한다.발작을 유발하는 콘텐츠를 제공하지 않는다.반복되는 콘텐츠 블록을 건너뛸 수 있다.모든 문서의 제목은 고유하고 식별할 수 있다.링크와 버튼 텍스트는 콘텐츠의 목적을 알 수 있다.섹션에는 의미있는 마크업과 헤딩이 있다.문서의 휴먼 랭귀지 속성을 제공한다.문맥 변경은 예측할 수 있다.폼 콘트롤 요소에 설명을 제공한다.실수를 예방하고 정정하는 것을 돕는다.HTML 문법을 준수한다.WCAG 2.1 지침의 1.1.1 항목 예를 들어 볼게요.All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below. 사용자에게 제공되는 모든 텍스트 아닌 콘텐츠는 아래 나열된 상황을 제외하고 같은 목적을 수행하는 대체 텍스트를 제공한다.원문 표현보다 아래와 같이 다듬은 표현이 좋다고 보는 것이죠.의미를 전달하고 있는 이미지에 대체 텍스트를 제공한다.물론 사내 지침은 너무 단순하게 표현했기 때문에 지침마다 ‘부연 설명, 관련 예시, 기대 효과, 관련 표준, 평가 도구’ 텍스트와 링크를 간략하게 제공하고 있습니다. 사실상 W3C 표준에 대한 링크 페이지라고 생각해도 괜찮습니다. 사실이 그런걸요.맺음말레진 웹 접근성 가이드라인은 사내 유관 부서 담당자분들께 공유하고 동의를 얻어 사내 지침으로 결정하고 공개할 수 있게 됐습니다. 긍정적으로 검토해 주신 사우님들 감사합니다.레진 웹 접근성 가이드라인은 W3C 표준을 요약한 버전에 불과하므로 누구라도 복제(Fork), 개선 요청(Pull Requests), 문제 제기(Issues)할 수 있습니다."Design for all, amuse everyone!"

OverviewiOS 프로그래밍을 하면서 많이 접했던 단어 중 하나는 오토 레이아웃(Auto Layout) 입니다. 스토리보드에서 화면을 만들 때 오토 레이아웃을 이용해서 뷰와 컨트롤의 크기와 위치를 지정합니다. 이미 잘 사용하고 있지만 문득 정확하게 오토 레이아웃은 무엇인지 궁금해져 이번 기회에 써 보기로 했습니다. 오토 레이아웃(Auto Layout)은?오토 레이아웃(Auto Layout)은 제약 조건(Constraints)을 이용해서 뷰의 위치를 지정하는 것입니다. 다시 말하면, 두 뷰 사이의 관계를 제약 조건이라는 것을 이용해서 뷰의 크기와 위치를 지정하는 것입니다. 너와 나의 연결 고리!오토 레이아웃은 여러 해상도를 지원하려고 이 세상에 나왔습니다. 아이폰의 크기가 다양해지면서 해상도도 달라졌는데, 다른 크기에서도 같은 화면을 똑같이 보여주기 위해 오토 레이아웃을 사용합니다. 세로 보기 화면뿐만 아니라 가로 보기 화면까지도 지원합니다. 아이폰SE 혹은 아이폰8 Plus에서도 같은 비율의 화면을 볼 수 있도록 오토 레이아웃을 사용하는 것입니다. 만약 오토 레이아웃을 사용하지 않는다면, 아이폰 기종마다 스토리보드를 만들어야 하죠. 이렇게 되면 스토리보드 파일이 많아집니다. 앱을 실행할 때 아이폰 기종을 확인하고, 그에 맞는 스토리보드를 찾아 화면을 보여주는 번거로움도 생깁니다. 위의 이미지를 보면 아이폰SE와 아이폰8, 아이폰8 Plus 브랜디 앱 화면. 기종이 달라도 보여지는 화면이 똑같다는 것을 볼 수 있습니다. 오토 레이아웃을 이용해서 하나의 스토리보드에서 모두 대응할 수 있는 것이죠.Frame Layout vs Auto Layout전통적으로 앱은 유저 인터페이스를 각 뷰의 프레임(frame)을 프로그래밍 방식으로 계산해 배치합니다. 유저 인터페이스를 배치하려면 뷰 계층의 모든 뷰에 대한 크기와 위치를 계산해야 합니다. 그리고 변경이 발생하면 영향을 받는 모든 뷰에 대해 프레임을 다시 계산합니다.Frame Layout뷰의 프레임을 프로그래밍 방식으로 정의하면 유연해집니다. 어떤 변화가 생겨도 대응할 수 있기 때문입니다. 그러나 모든 변경 사항을 직접 관리해야 하기 때문에 많은 노력이 필요합니다. 설계부터 시작하여 디버그 및 유지 관리까지 많은 것을 관리해야 합니다. 가장 효과적인 방법이지만 난이도도 많이 어려워집니다.이와 달리 오토 레이아웃은 일련의 제약 조건을 사용하여 유저 인터페이스를 정의합니다. 제약 조건은 앞서 말한 것 처럼, 일반적으로 두 뷰 간의 관계를 나타냅니다. 그런 다음 오토 레이아웃은 이러한 제약 조건을 기반으로 각 뷰의 크기와 위치를 계산합니다.Auto Layout화면에 배치하는 모습이 같기 때문에 프레임 방식을 사용해도 되고, 오토 레이아웃을 사용해도 됩니다. 둘 다 스위프트와 오브젝티브 C를 지원하기도 합니다. 각각 장단점이 있지만 가장 많이 사용하는 방법이 오토 레이아웃입니다. 빠르게 적용할 수 있고 많은 시간을 줄일 수 있기 때문입니다.스토리보드에서의 오토 레이아웃iOS 앱 개발은 스토리보드를 이용해서 화면을 만듭니다. 그래서 스토리보드가 익숙한 개발자들이 많은데, 사실은 뷰를 배치하면서 썼던 툴이 오토 레이아웃과 관련된 것이었습니다.스토리보드 오른쪽 하단에 있는 메뉴핀(Pin) 메뉴는 버튼 또는 레이블과 같은 UI 요소에 새로운 제약 조건들을 추가할 수 있습니다. 시계 방향으로 Top, Trailing, Bottom, Leading 제약 조건의 값을 입력할 수 있고, 화살표를 누르면 어떤 뷰와 관계를 가질 것인지 선택할 수 있습니다. 두 뷰와 핀 메뉴를 선택하면 같은 너비와 높이를 설정할 수 있습니다.Pin 메뉴정렬(Align) 메뉴는 다른 뷰와의 가로, 세로 정렬과 같은 정렬 제약 조건들을 추가할 수 있습니다. 정렬하고 싶은 두 뷰를 선택하여 수직 정렬, 수평 정렬을 추가할 수 있습니다.Align 메뉴맨 오른쪽 메뉴인 오토 레이아웃 이슈 툴은 오토 레이아웃 관련된 이슈들을 해결하는 옵션들을 제공합니다. 오토 레이아웃을 현재 설정된 상태로 재설정하는 옵션들입니다. 상단은 선택된 뷰와 관련된 것이고, 하단은 모든 뷰와 관련된 것입니다.Resolve Auto Layout IssuesAlign 옆에 있는 Stack 메뉴는 복잡한 제약 조건 없이 오토 레이아웃의 기능을 쉽게 뷰를 배치할 수 있도록 스택에 쌓아서 묶어주는 스택뷰를 생성합니다. 하나의 묶음으로 만들 뷰들을 선택하여 Stack 메뉴를 선택하면 스택처럼 그룹으로 됩니다. 여기서 뷰 사이의 공간과 정렬들을 설정할 수 있습니다.Stack View로 만든 간단한 뷰, 오른쪽 메뉴에 정렬과 뷰 사이의 공간을 선택할 수 있는 곳이 있습니다.스토리보드에서 뷰를 배치하고 오토 레이아웃 메뉴들을 이용하면 아래 스크린샷과 같이 제약 조건들을 볼 수 있습니다. 어떤 값을 지정하는 것이 아닌 같다는 뜻의 “=“를 이용하여 제약 조건들을 표현합니다.스토리보드에서 많이 볼 수 있는 제약 조건들(Constraints)프로그램 상의 제약 조건들스토리보드에서만 제약 조건들을 설정할 수 있는 건 아닙니다. 프로그램 상에서도 제약 조건들을 설정할 수 있습니다. 스토리보드에서 뷰를 배치한 다음, 제약 조건들을 소스 파일과 연결해서 값을 지정할 수 있습니다. 주로 어떤 변화가 일어나면 제약 조건들을 다시 설정할 때, 프로그램 상에서 값을 다시 설정합니다. 예를 들어, 데이터가 있을 땐 해당 뷰를 보여줍니다. 만약 데이터가 없으면 그 뷰가 사라지면서 그 뷰와 관련되어 있는 다른 뷰의 제약 조건들을 다시 설정하여 화면에 재배치하는 것입니다.func hideTag(_ hide: Bool) {         if hide {             self.labelTag1.isHidden = true             self.labelTag2.isHidden = true             self.constLabelTag1Top.constant = 0.0             self.constLabelTag1Height.constant = 0.0         } else {             self.labelTag1.isHidden = false             self.labelTag2.isHidden = false             self.constLabelTag1Top.constant = 15.0             self.constLabelTag1Trailing.constant = 5.0             self.constLabelTag1Height.constant = 20.0         }     } 위 소스에서 hide 값에 따라 레이블의 숨김을 설정하고 레이블의 제약 조건의 값을 재설정하는 메소드가 있습니다. 데이터가 있으면 숨김을 해제하고 제약 조건들의 값을 설정하지만, 데이터가 없으면 레이블을 숨기고 제약 조건들의 값을 0으로 설정합니다.스토리보드에서 연결한 제약 조건들을 가지고 설정할 수 있는데, 프로그램 상에서 직접 제약 조건들을 생성하여 사용할 수 있습니다. 아래의 예시는 뷰의 높이를 60으로 설정하는 코드입니다.NSLayoutConstraint(item: self.testView, attribute: .height, relatedBy: .equal, toItem: nil, attribute: .notAnAttribute, multiplier: 1.0, constant: 60) Conclusion애플에서는 개발자가 다양한 해상도에 대응할 수 있게 오토 레이아웃이라는 시스템을 개발했습니다. 스토리보드에서 쉽게 화면에 뷰를 배치할 수 있고, 별다른 기능을 추가하지 않아도 다양한 아이폰 크기에 맞춰서 대응해줍니다. 오토 레이아웃을 이용하여 멋지게 모든 아이폰과 아이패드에 대응하는 앱을 개발해보세요! 곧 산호세로 떠나 설레는 마음으로 글을 마치겠습니다. 감사합니다. :)글김주희 사원 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발팀 #개발자 #개발환경 #업무환경 #인사이트 #경험공유

Overview주니어 개발자는 시스템 아키텍처(System Architecture) 또는 시스템 디자인(System Design)이라는 단어에 덜컥 겁부터 먹습니다. 지금 진행하고 있는 개발에만 집중하다 보니 큰 그림을 놓치고 있는 게 아닐까 란 생각이 들었죠. 조금 더 큰 그림을 보고자 공부를 시작했습니다. 문득 같은 생각을 하는 주니어 개발자 분들도 많을 것 같다고 생각했어요. 그래서 이번 글은 시스템 아키텍처에 ㅇ_ㅇ? 뀨? 하는 표정을 짓는 주니어 개발자들을 위해 썼습니다.상상의 나래: 가상의 패션 e커머스상상의 나래를 펼쳐봅시다. 패션 e커머스 서비스를 이용하는 김유저 씨가 구매한 옷이 마음에 들어 상품 리뷰를 남기고 싶어한다고요.김유저 씨는 본인의 착용 사진과 텍스트 리뷰를 작성하고 ‘리뷰 등록하기’ 버튼에 엔터를 탁! 누를 겁니다. 그런데 말이죠. 김유저 씨는 요청하고 싶은 웹서버의 IP 주소를 모르기 때문에 요청을 보낼 수가 없습니다.내 정체를 알려줘: DNS (Domain Name System)그래서, DNS(Domain Name System)에게 물어봅니다. 서버의 도메인 이름으로부터 해당 서버의 IP 주소를 알려주는 것이 바로 DNS입니다. 도메인 이름에 대한 질의를 하고, 만일 해당 도메인 이름이 DNS에 ‘A Record’ 형태로 등록이 되어 있다면 도메인 이름에 해당하는 IP 주소를 응답으로 돌려줍니다.서비스에서 자체 DNS 시스템을 가지고 있을 수 있습니다. 예를 들어 Route 53, Cloud Flare같은 서비스가 있습니다. 그렇다면 또 한 가지 의문이 생깁니다. 왜 서비스는 시스템적 부담을 안고서 자체 DNS 서버를 구축하고 있는 걸까요? 그 이유로 두 가지를 꼽을 수 있습니다.첫 번째로는 신뢰도가 높습니다. 직접 DNS Record를 관리 및 운영하기 때문입니다. 두 번째로는 보안이 우수합니다. 만약 공개하고 싶지 않은 IP 주소, 예를 들어 Database IP 주소 같은 건 공개하지 않습니다. 1)작업장소: Web Server이제 웹서버의 IP 주소를 알았으니 통신을 시도합니다. 웹서버는 웹서비스에서 필요로 하는 다양한 요청과 그에 대한 응답을 제공합니다. 클라이언트가 리뷰에 대한 사진과 텍스트를 등록하고 싶다면 웹서버에게 등록하라는 요청을 보내야 합니다.웹서버에서 요청을 받으면 사용자가 요구한 대로 사진과 텍스트를 등록하고, 그에 대한 결과 정보를 응답으로 보내줄 것입니다. 웹서버 내부에서는 그 과정에 필요한 연산을 수행합니다. 서버 개발자는 이 연산에 대한 코드를 작성하고요.센스가 없는 서버:API (Application Programing Interface)서버는 사람이 아닙니다. 센스나 재치가 없죠. 미리 정의되지 않은 요청은 대응하지 못합니다. (어버버버버 퉤! Error 404!) 그래서 약속한 요청을 보내면 약속한 방식으로 응답해줄게라고 명세를 제공합니다.약속한 요청으로 데이터를 보내면 원하는 요청에서 데이터를 정제해 잘 처리했는지, 또는 처리된 데이터를 약속한 방식(예를 들어, JSON 방식)으로 내보내죠. 웹서버는 정의된 API에 맞춰 요청과 응답을 합니다.그런데 웹서버가 수많은 요청을 받고 응답하면 과부하가 일어날 수도 있습니다. 사용자 수가 어마어마한 규모로 늘어나서 서버가 펑! 하고 터진다면, 김유저 씨는 서비스를 더 이상 이용할 수 없을 겁니다. 이용하고 싶지도 않을 겁니다!따라서, 서버가 감당하는 요청을 나누기 위해 같은 역할을 하는 서버 장비 수를 늘릴 수도 있습니다. 그러면 요청이 각기 다른 웹서버 장비에 분산되어 한 번에 감당할 수 있는 요청 수가 더욱 많아집니다.이 구역의 매니저는 나야: Load Balancer그림처럼 서버가 4대 존재하는 상황이라면, 서버 4대에 일을 적절히 분배해주는 역할이 필요합니다. 그것이 로드 밸런서(Load Balancer)입니다. 로드 밸런서가 서버에게 일을 나누는 방법론은 여러 가지가 있습니다.Random: 랜덤으로 분배하기Least loaded: 가장 적은 양의 작업을 처리하고 있는 서버에게 요청을 할당하기Round Robin: 순서를 정하여 돌아가며 작업 분배하기많이 쓰는 로드 밸런서의 종류는 Layer 4, Layer 7을 꼽을 수 있습니다.Layer 4 Load Balancer: 데이터의 내용을 보지 않고 IP주소 및 TCP/UDP 정보에 따라 단순히 분배를 해줍니다.Layer 7 Load Balancer: 서버가 하는 역할이 분리되어 있는 환경에서 데이터의 내용을 보고 각기 맞는 역할을 하는 서버에게 분배를 해줍니다.로드 밸런서는 클라이언트가 요청을 보내야 할 서버를 골라야 하는 부담을 덜어주며, 로드 밸런서에게 할당된 vIP (가상 IP)로 요청을 보내기만 하면 로드 밸런서에서 알아서 작업을 나눠줍니다. 서버에서는 적절한 로드 밸런서를 사용하면 들어오는 요청이 여러 장비에 분산되어 처리량이 늘어나고 응답 시간이 줄어드는 효과를 기대할 수 있습니다. 컨텐츠 저장소: CDN(Content Delivery Network)이제 웹서버가 클라이언트의 요청에 의해 웹페이지에 대한 응답 결과를 돌려줬습니다. 이때 클라이언트의 화면에 렌더링해야 하는 수많은 이미지가 필요합니다. 이 이미지들을 웹서버가 전부 주려면 데이터의 용량이 너무 크고, 무거워서 서버가 헥헥거리죠. (서버가 죽으면 어떻게 될까요? 클라이언트님이 경쟁사로 환승하겠죠.. 안 돼요..) 따라서 웹서버는 직접 이미지를 주는 대신 CDN(Content Delivery Network)에게 요청하라고 이야기합니다. CDN은 일반적으로 용량이 큰 컨텐츠 데이터(이미지, 비디오, 자바스크립트 라이브러리 등)를 빠른 속도로 제공하기 위해 사용자와 가까운 곳에 분산되어 있는 데이터 저장 서버입니다. 클라이언트는 용량이 큰 컨텐츠 데이터를 가까운 CDN에 요청해 멀리 있는 웹서버에서 직접 받는 것보다 빠르게 받을 수 있습니다. CDN이 동작하는 방식에는 크게 Push CDN, Pull CDN이 있습니다. Push CDN: 서버에서 컨텐츠가 업로드되거나, 변경되었을 때 모두 반영하는 방식 Pull CDN: 클라이언트가 요청할 때마다 컨텐츠가 CDN에 새로 저장되는 방식 두 방식 모두 장단점이 있습니다. Push CDN은 모든 컨텐츠를 갖고 있기에 웹서버에 요청할 일이 없지만 유지하는데 필요한 용량과 비용이 많이 필요하겠죠? Pull CDN은 클라이언트가 요청한 컨텐츠가 있으면 바로 응답하지만 그렇지 않을 땐 데이터를 웹서버로부터 가져와야 하기 때문에 서버에 요청하는 부담이 존재합니다. 컨텐츠명은 그대로인데 내용만 변경되었다면 인지하지 못하고 옛버전의 컨텐츠를 제공하죠. 그래서 Pull CDN에 들어가는 컨텐츠는 TTL(Time To Live)이 적용됩니다. TTL이란 유통기한이라고 생각하면 쉽습니다. 일정시간이 지나면 해당 데이터가 삭제되는 것이죠. 이런 방식이 적용된다면 Pull CDN의 최대 단점을 보완할 수 있습니다. 이렇게 보완이 되면 수정된 데이터에 대해서도 대응이 가능하며 서버의 용량 즉, 비용적 부담이 해소될 겁니다.소중한 내 데이터: Database서비스를 제공하다 보면 클라이언트의 소중한 정보, 이력, 상품 가격, 상품 정보 등 다양한 데이터를 저장하고, 또 제공합니다. 하지만 수많은 데이터를 웹서버에 전부 저장하고 사용하기엔 데이터의 양이 너무 많아 저장 공간도 부족하고, 데이터를 원하는 모양에 맞게 정제하기가 어렵습니다. 그래서 데이터를 저장하는 데이터베이스 서버가 따로 존재합니다.민감한 정보를 다루는 데이터베이스는 ACID라는 성질을 만족해야 하는데요.Atomicity(원자성): 데이터베이스에 적용되는 명령이 중간만 실행되지 않고 완전히 성공하거나 완전히 실패해야 한다는 것을 의미합니다. 반만 적용된 명령이 있다면 헷갈리겠죠.Consistency(일관성): 데이터베이스가 수행한 명령이 일관적으로 반영되어 있어야 한다는 의미입니다. 예를 들어 계좌에 돈을 입금했는데 잔고에 반영되지 않는다면 당황스러울 겁니다.Isolation(고립성): 데이터베이스가 수행하는 명령 도중 다른 명령이 끼어들지 못한다는 것을 의미합니다.Durability(지속성): 성공적으로 수행한 명령은 영원히 그 이후 상태로 남아있어야 한다는 걸 의미합니다. 갑자기 하루 뒤에 명령이 취소되거나 이전 상태로 롤백되면 안 됩니다. Replication (복제 / 이중화)큰 시스템에서는 똑같은 데이터베이스가 여럿 존재한다고 하는데요. 그렇다면 왜 비용적인 부담을 안으면서까지 복제 데이터베이스를 구축해놓는 걸까요? 만약에 데이터베이스가 정상적으로 동작하지 않는다면 클라이언트의 데이터를 변경하지 못하며, 클라이언트가 원하는 정보를 제공하지 못하는 불상사가 일어나게 됩니다. 글로만 써도 벌써 땀이 납니다. 그러므로 복제해놓은 데이터베이스를 얼른 마스터로 등업해 데이터 흐름에 차질이 없도록 대비해야 합니다.만약 하나의 데이터베이스가 어떤 일을 수행할 때 다른 요청들은 계속 기다려야 합니다. 그렇다면 데이터를 변경하는 데이터베이스는 하나, 읽기만 하는 데이터베이스는 여러 대가 존재해도 되지 않을까요? 바로 여기서 Master-Slave의 개념이 탄생합니다.master-slave-replicaMaster-Slave Replica (a.k.a 주인-노예)요청을 분산하기 위해서 데이터베이스를 늘리다 보면 master-slave 토픽이 등장합니다.Mater: CRUD(Create, Read, Update, Delete)가 모두 가능Slave: R(Read)만 가능Master가 데이터를 변경할 동안 읽기에 대한 요청은 Slave에게 보내집니다. 그렇게 하면 읽기 요청은 분산되어 훨씬 더 수월하고 빠른 속도로 데이터 처리가 가능할 것입니다. 만약 Master가 변경된다면 아래 계급인 Slave, Replica 데이터베이스에게도 이 정보를 전해야 합니다. 다시 말해, 자신에게 들어온 요청(Query)을 동일하게 보내 빠른 시간 안에 동기화를 시켜주죠. 하지만 동기화도 시간이 걸리는 작업이므로 무한대로 Slave Replica를 늘려 확장하기는 어렵습니다.Master-Master Replica의문이 하나 생길 겁니다. “여러 대의 Master를 두어서 변경도 가능하고, 읽기도 가능하게 하면 되지 않을까?”앞서 언급했듯이 같은 데이터의 변경 가능한 데이터베이스는 하나여야 할 것입니다. 동시에 같은 데이터를 변경했을 때 갈등을 해소하기 위한 방법론은 존재하지만, 그 방식이 복잡하고 오래 걸립니다. 안정성도 낮아지고, 효율도 떨어집니다. 그래서 Master-Slave 아키텍처를 선호하는 것이죠.Sharding그러면 같은 데이터베이스 테이블을 동시에 변경하는 건 불가능한 걸까요? 그것을 해소하기 위해 샤딩(Sharding)이라는 방법론을 사용합니다. 샤딩된 테이블은 개념적으론 하나의 테이블처럼 보이지만 사실 그 내용물이 쪼개져 있습니다. 쪼개는 방법은 여러 가지 선택할 수 있습니다만, 분명한 건 겹치는 데이터 없이 쪼갠다는 것입니다. 그래서 같은 테이블이어도 쪼개져 있다면 그 테이블에 동시에 접근해 데이터를 변경할 수 있는 것이죠.이외에 서비스별, 기능별로 쪼개어 데이터베이스를 관리하는 Federation 등 많은 데이터베이스 디자인 방법론이 존재합니다.시스템 아키텍처가 가지고 있어야 할 최소본 아키텍처요점: 시스템 아키텍쳐에서 고려해야 할 성질이렇게 간단한 시스템 아키텍처의 면면을 살펴봤습니다. 시스템 개발자라면 시스템을 디자인하면서 반드시 고려해야 할 성질들을 만날 텐데요. 위에서 소개한 내용들 역시 아래의 성질들을 충족하기 위해 탄생했다고 볼 수 있습니다.Scalability (확장성): 10만 명의 요청을 처리할 수 있는 시스템과 1000만 명의 요청을 처리할 수 있는 시스템은 다릅니다. 확장성을 고려한 시스템은 앞으로 클라이언트 수가 늘어났을 때 무리 없이 모든 요청을 처리할 수 있을 겁니다.Performance (성능): 속도와 정확성을 말합니다. 요청한 내용을 정확하고 빠르게 돌려주어야 합니다.Latency (응답 시간): 모든 요청은 클라이언트가 불편해하지 않을 정도로 빠른 시간 안에 돌려주어야 합니다.Throughput (처리량): 같은 시간 안에 더욱 많은 요청을 처리한다면 좋은 시스템입니다.Availability (접근성): 사용자가 언제든지 시스템에 요청을 보내서 응답을 받을 수 있어야 합니다. 비록 서버 장비 한두 대가 문제가 생겨 제 기능을 하지 못하더라도 사용자는 그 사실을 몰라야 합니다.Consistency (일관성): 사용자가 서버에 보낸 요청이 올바르게 반영되어야 하고, 일정한 결과를 돌려주어야 합니다. 요청을 보낼 때마다 불규칙한 결과를 돌려준다면 믿을 수 없는 서비스가 될 것입니다.결론발로 그렸나 싶을 정도의 그림과 기나긴 글을 마무리 지으며주니어 개발자로서 시스템 아키텍처를 공부하면서 느낀 점이 있다면 시스템에 대한 완벽한 대응은 없으며, 모두 장단점이 존재한다는 것입니다. (이것을 보통 trade-off라고 표현합니다.)하지만 설계하는 서비스를 잘 알고 서비스에서 무게를 둬야 할 부분을 파악한다면, 그에 맞는 시스템을 설계하고 디자인할 수 있을 겁니다. 김유저 씨도 만족시킬 수 있을 거고요. 꼬박 이틀을 밤새워서 쓴 글이 아직 시스템 아키텍처를 두려워하는 다른 주니어 개발자분들에게 도움이 되었으면 합니다. 이번에는 시스템에서 아주 기초적인 부분을 공부했으니 다음 글에선 MSA(MicroService Architecture)를 씹어봅시다! 겁이 나고 무서워도 외쳐보세요. “Hello, System Architecture!”이 세상 모든 주니어 개발자분들, 퐈잇팅입니다.참고1) 추가적인 이점에 대하여: 웹서버에서 요청을 보낼 때 database 도메인 네임으로 보낼 경우, 멀리 있는 공인 DNS 서버 (예를 들면 google public DNS server: 8.8.8.8)에 물어오는 것보다 자체 DNS 서버에 물어오는 것이 훨씬 더 빠른 속도로 응답을 받아올 수 있습니다.출처GitHub - donnemartin/system-design-primer: Learn how to design large-scale systems. Prep for the system design interview. Includes Anki flashcards.글오연주 사원 | R&D 개발2팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발자 #개발팀 #인사이트 #경험공유 #주니어개발자

마음챙김명상앱 '마보'의 콘텐츠들은 모두 Waves 플러그인으로 프로세싱된다.(처음과 마지막을 제외하면) Waves에 대해 간단한 생각을 정리하자면 다음과 같다.머큐리 구입시 UAD와도 고민을 많이 했지만 소프트웨어로만 비교를 한다면 waves가 훨씬 편하게 사용이 가능하다. 그 중에서도 CPU로 돌릴 수 있다는 점이 제온 CPU 에서 강력하게 작용한다.(Waves 하드웨어가 필요하다면 영국콘솔회사 DiGiCo와의 합작품인 DiGiGrid라는것도 있다.)근데 문제는... 맥에서는 더이상 CPU파워가 따라주지 않는다는 것이다.이런 상황에서 밖에서 작업하기에 딱 좋은 솔루션이 있었다. Soundgrid라는 waves의 DSP솔루션이다.이 사운드그리드에 대해 요약하면 waves의 플러그인만 따로 모아서 랜케이블로 Soundgrid 연결을 하면 CPU의 부담을 주지 않고 Daw에서 똑같은 프로세싱이 가능하다.이번에 BLS에서 데모로 받은 Waves Soundgrid IMPACT SERVER를 까페에 들고 나왔다.문제는 예상했던 사이즈가 아닌 맥북보다 훨씬 커서 카페에 가지고 다니기 부담스러운 크기... 휴대성이라는 측면에서는 역시 좀 무리가 있지 않나 싶다.(사진참조)어쨌든 카페에서 작업이 가능하게 되었다는 점. 다만, 카페에 가는데 차가 필요하다는 점이 있겠다.앞서 말했듯 마보 콘텐츠는 waves외에 플러그인의 시작과 끝을 Izotope 플러그인을 쓴다.마지막에는 라우드니스를 위해 오존을 사용한다. 오존은 너무 유명한 플러그인이니 설명도 생략.녹음이 끝나면 바로 첫단에 오디오스위트로 걸어주는 RX5라는 플러그인이 있다.이 플러그인은 보이스를 녹음한다면, 혹은 볼륨이 크지 않은 클래식 악기를 녹음한다면 정말 요긴하다.첫째로 입에서 발생하는 립노이즈들을 효과적으로 빠르게 제거해 준다. 콘덴서 마이크에서 타는 쩝쩝거리는 소리들을 손으로 하나씩 잡을 필요가 없다. 그저 한번 클릭으로 모든 파형의 클릭소리들을 제거해준다.Waves Mercury에도 X-Click이있지만 Izotope의 RX5가 훨씬 퀄리티가 좋다.두번째로 De-noise의 강력한 기능이다. 녹음시에 발생되는 팬소음들은 사실 EQ를 통해 어느정도 제거가 가능한 험의 형태로 발생한다면, 전기적 접지의 부재로 인한 핑크노이즈는 쉽게 제거가 불가능하다.하지만. 이 De-noise의 노이즈 LEARN기능으로 노이즈를 분석한 후 노이즈를 획기적으로 제거할 수 있다.칭찬일색으로 보이지만 RX5는 유튜브 믹싱채널을 운영하는 Alan JS Han님도 추천을 하실 만큼 유명하다.(근데 Izotope는 품질은 정말 유명하나 CPU를 정말 힘들게 한다.)자세한 이야기는 각 사진 속에보다시피 크기가 생각보다 크고 3kg에 육박하는 mini-itx PC이다.. 공연장비가 베이스이기 때문에 랜케이블로 연결한다.프로툴 유저라면 한번쯤 겪어본 창프로툴 유저라면 한번쯤 겪어본 창보이스가 없는 부분을 선택해 기본으로 깔리는 노이즈를 분석한다.전 구간에 분석한 노이즈 커브를 적용한 모습.깔끔하게 정리되었다.(SSL프리에서 오는 하모닉스들도 제거)#마보 #콘텐츠 #프레임워크 #스택 #인사이트 #일지

문화는 매일 우리가 보고 느끼는 것입니다. 우리는 국가, 학교, 회사, 가족, 심지어는 친한 친구들의 모임과 같은 많은 사회의 구성원으로서 문화를 경험합니다. 조직이 특정 방식으로 행동하고 회사 내부와 외부에서 탁월한 능력을 발휘할 수 있도록 확고한 정체성을 부여하는 것은 기업문화보다 강력한 것은 없습니다. 기업은 명확한 비전, 사명 선언문 및 핵심 가치를 확정하고 이를 모두가 공유하고 경험할 수 있도록 조직의 최 하위 부서까지도 전해 내려와야 합니다. 이를 달성하기 위해서는 인적 자원 및 자본, 그리고 변화 관리의 역할이 매우 중요합니다. 오늘날 인적 자본 관리 IT 솔루션 및 어플리케이션은 급속히 성장하고 있으며 많은 조직에서 이를 이용하여 직원 간의 커뮤니케이션과 참여를 돕고 기업의 가치와 정책들이 스며들어 모두가 공유할 수 있는 장이 되고 있습니다.이메일 메모를 통한 공지, 모든 불필요한 서류 작업을 통한 복리후생 처리, 중앙 집중식 프로젝트 관리 및 보고 시스템은 과거에서나 많이 찾아볼 수 있는 모습입니다. 스마트폰과 많은 클라우드 기술이 발전된 지금은 바로 클라우드 기반 그룹웨어, 협업툴의 춘추전국시대라고 할 수 있습니다. 기존 아날로그에서 디지털로 변화하는 지금의 인간은 집중력을 발휘할 수 있는 시간이 점차 줄어들고 있습니다. 뉴욕 타임즈의 티모시 이건 (Timothy Egan)은 ‘The Eight-Second Attention Span’에서 ‘마이크로소프트(Microsoft)가 진행한 캐나다 미디어 소비에 대한 설문조사에서 사람의 평균 관심 시간은 8 초로 줄어들었다’고 결론지었습니다. 요즘 우리는 기업의 이메일 메모를 읽을 시간도 없을 뿐더러 항상 다양한 종류의 정보와 알림에 노출되고 있습니다. 요즘 가장 선호되는 통신 수단과 업무 수단은 랩탑과 스마트폰입니다. 그리고 많은 직원들이 재택근무, 외근, 유연근무 등으로 기업의 체질이 변화하고 있습니다. 조직의 리더인 우리는 구성원의 행동과 취향을 반영하여 기존 시스템을 변화시켜 직원의 니즈를 충족, 훌륭한 문화를 조성하고 전사적으로 보급하려는 노력이 필요합니다.직원 개개인을 생각한 훌륭한 시스템은 조직 전체의 효율성을 극대화합니다.직원들이 업무외의 다른 요소에 방해받지 않고 더 집중할 수 있도록 활용될 수 있는 새로운 커뮤니케이션 툴은 무엇이 있을까요? 어떻게 직원들의 성과를 인정하고 그에 대한 보상과 감사표시를 할 수 있을까요? IT 서비스를 접목함으로써 제거될 수 있는 불필요한 업무 절차는 어떤 것들이 있을까요? 기업 내에서 조직의 효율성을 극대화하며 각 직원 개개인의 만족도와 성취감을 높여줄 수 있는 많은 방법이 있습니다.1. 조직 내에서 직원들이 소통할 수 있는 가장 좋은 방법을 선택하십시오.효과적인 커뮤니케이션은 구성원 간의 좋은 관계와 신속한 업무 진행으로 이어집니다. 조직과 그를 구성하는 직원들도 마찬가지입니다. 새로운 방향, 일정 발표, 또는 기타 공지 사항 등 어떤 종류의 커뮤니케이션이든 소통은 명확하고 목적이 뚜렸해야 합니다. 일주일 전에 받았던 공지를 찾느라 공지 메일을 검색하거나 채팅방 내에서 위 아래로 스크롤하는 작업은 직원의 많은 시간을 낭비하게 됩니다. 조직 내에서 사용할 기업용 커뮤니케이션 채널을 정하십시오. 직원이 이메일, SMS 또는 일반 메신저에 묻혀 있는 메시지들 중 업무관련 메시지들을 매번 골라내야 한다면 조직의 관점에서 굉장한 손실을 떠안게 될 수 있습니다.기업에서 사용할 수있는 SaaS 커뮤니케이션 및 협업 툴의 몇 가지 예:slack : 메시징 및 타서비스 연동JANDI : 메시징 및 서비스 연동collabee : 협업, 타임라인 및 프로젝트 칸 반BeeCanvas : 시각적 작업 공간 및 실시간 협업GRAP : 기업용 소셜 네트워크, 타임라인위의 모든 서비스들은 기업 데이터, 정보를 암호화하여 높은 보안 수준의 클라우드 저장소에 제공합니다. 이 같은 서비스를 사용하면 직원이 그룹, 부서 또는 프로젝트를 만들 수 있으며 관련 구성원만 참여하도록 초대하여 협업할 수 있습니다. 이러한 도구 중 일부는 업무 또는 프로젝트 승인/결재 체계을 갖추고 있으므로 누가 언제 어떤 작업을 승인하였는지 추적 할 수 있습니다.기업내에서 구성원들이 사용하는 커뮤니케이션 툴을 정하고 나면 보다 명확한 의사소통과 업무진행으로 인해 조직 전체의 효율성이 높아지게 됩니다. 또한 보안이 확실하지 않은 매개체를 통해 업무 관련 통지 및 소통할 시 데이터 손실의 위험이 있으며 해커가 정보 유출을 시도할 시 취약한 구조를 가지게 됩니다. 다시 말하지만, 안전한 통신 채널을 정하여 소통을 명확하게 유지하고 혼란을 최소화하십시오. 그렇다면 인간 상호 작용을 장려하는 것입니다.2. 직원들이 서로의 성과와 업적을 인정할 수 있도록 칭찬 및 보상 시스템 사용모든 직원은 기업의 스타입니다. 조직의 구성원은 자신의 업적과 성과에 대해 인정 받을 자격이 있으며 자신이 하는 일을 자랑스럽게 여길 수 있어야 합니다. 시간 안에 프로젝트를 끝내도록 동료가 도움을 주었거나 다음 번에 더 잘 할 수 있도록 매니저가 과거 프로젝트에 대한 귀중한 피드백을 주었다면 어떤 경우이든 상관없이 이를 인정해 주고 감사의 마음을 표하게 됩니다. 때로는 말로는 충분하지 않기도 하죠. 어떤 회사는 기업내에서 모든 사람이 서로를 인정할 수 있도록 칭찬 및 보상 시스템을 사용하기도 합니다. 칭찬을 많이 받은 직원의 경우 모인 칭찬을 백화점 기프트 카드와 같은 보상의 형태로 전환하여 사용할 수 있습니다. 귀사가 이미 오프라인에서 열심히 일하는 직원을 인정하며 보상 시스템을 운영하고 있다면, 이제는 동일한 작업을 수행 할 수 있는 더 나은 방법이 있습니다. 실질적인 효과를 볼 수 있는 직원 복지 시스템을 도입하여 직원들의 동기부여와 사기를 극대화하고 서로에게 용기를 북돋아줄 수 있는 문화를 만들어보세요.위에서 언급한 피어 투 피어 (peer to peer) 칭찬과 보상 플랫폼을 제공하는 많은 신생 스타트업과 기존 기업들의 서비스들이 있습니다:kudos : ‘직원 인정 시스템 및 기업 소셜 네트워크’Redii : ‘가장 큰 자산(팀)의 힘을 활용하여 훌륭한 비즈니스를 성장시키고자 하는 중소 기업을 위해 설계된 간단한 직원 성과 인정 소프트웨어’globoforce : ‘사회적 인정 : 감사의 힘’평범한 휴가나 보너스를 주는 전통적인 방법에 비해서 온라인으로 서로가 서로를 인정해주고 이에 대한 보상 시스템을 이용하면 누가 어떤 이유로 누구를 위해 고맙게 여기는가에 대한 투명성이 높아집니다. 동료가 성공을 달성할 수 있도록 서로 돕고 응원하는 문화를 만들어보세요. 보상 및 인식 시스템을 구현하여 모두가 윈-윈하는 문화를 육성할 수 있습니다.3. 기업의 직원 복지와 의료 혜택 또는 개인 지출 트래킹 프로세스가 더 우수하고 스마트해질 수 있습니다.당신의 기업은 사용자 경험(UX)을 극대화해야한다고 생각하십니까? 기업내 직원의 경험도 고려해 보세요.커뮤니케이션 도구와 마찬가지로 모든 HR 이나 재무 관련 서류 및 승인 절차는 복잡하고 지루하지 않아도 됩니다. 기업의 많은 직원들은 업무를 처리하기 위해. 불필요한 절차에 더 많은 시간을 할애합니다. 정확히 말하면 실제로 일을 끝내는 것보다 보고서 작성과 결재를 기다리는 데에 많은 시간을 보내고 있습니다. 이제는 대부분의 불필요한 절차 및 서류 작업은 IT 기술로 대체 될 수 있습니다. 이러한 지루한 서류 작업과 승인 사례를 들어 보겠습니다.휴가를 승인받기 위해 휴가신청서를 문서로 제출하여 서명 받거나 신청서를 스캔하여 이메일로 결재를 받는다.지출 보고서를 엑셀로 작성하여 영수증을 첨부하고 관리자의 결재를 받고 느린 업무 처리로 인해 늦게 환급 받는다.기업에서 제공하는 특별 직원 복지인 헬스장 비용 지원금을 이용하기 위해 신청서를 문서로 제출하고 결재를 받는다.위의 모든 결재된 문서는 서류함에 보관되어 공간을 많이 차지하며 접근성이 떨어진다.휴가 요청, 건강 및 복지 혜택 및 비용 보고와 같은 일상적인 재무와 HR 업무에 대해 기업내부에 명확하고 투명한 승인 체계를 클라우드 시스템으로 적용하면 직원과 관리자의 많은 시간을 절약하고 요청이 승인되었는지 이메일을 보내거나 개인적으로 물어봐야 하는 절차를 없애줍니다. 이러한 시스템은 많은 프로세스가 자동화되어 모든 관련 당사자가 열람 및 관리가 가능합니다. 모든 직원들이 편의를 느낄 수 있는 훌륭한 시스템을 도입해보세요.Workday Benefits : 기업의 복지 시스템 운영 툴.Expensify : ‘영수증 스캐닝에서 승인 및 환급까지, Expensify는 비용보고 프로세스의 모든 단계를 자동화합니다.’Gusto : 급여, 복리 후생 및 인사SaaS 클라우드 컴퓨팅 서비스를 사용한다는 것기업에서 업무 효율성을 위한 전통적인 소프트웨어들은 대부분 개별 컴퓨터에 설치된 독립형 소프트웨어로 제한되어 있었습니다. 예를 들어, Office 365가 출시되기 전의 Microsoft Office를 기억해 보십시오. 모든 Microsoft Office는 모든 직원들의 컴퓨터에 개별적으로 설치되어 오프라인으로만 작업할 수 있었습니다. 지금은 클라우드에서 모든 문서작업이 가능하며 동료 혹은 협력사의 담당자와도 협업이 가능하게 되었습니다. 이를 보면 우리의 일상에 클라우드 컴퓨팅은 그 어느 때보다도 널리 보급되어 있습니다. 이러한 솔루션의 대부분은 SaaS (Software as a Service)로 제공됩니다. Google 드라이브, Office 365, Salesforce CRM 및 Dropbox는 우리가 사용하는 주요 클라우드 기반 서비스의 예이며 많은 기업들이 클라우드 시스템으로 전환하고 있습니다. 왜 클라우드 서비스가 급성장하고 있을까요? 이유는 다음과 같습니다.1. 접근성. 조직의 데이터를 자체 서버에 저장하는 대신 클라우드 서비스 활용하여 데이터에 접근하고 원격으로 작업도 할 수 있습니다. 스마트폰과 노트북은 우리 일상과 업무처리를 하는 매개체로서 많은 비율을 차지하고 있으며 이제는 누구나 인터넷에 접속할 수 있습니다. 이제는 업무용 프로그램을 오프라인 상태로 제한할 이유가 없습니다.2. 비용 절감. 비즈니스 및 개인 간 클라우드 컴퓨팅의 출현은 우리의 상당한 비용을 절감케 했습니다. 기존의 무거운 프로그램과 데이터베이스를 운영하는 전통적인 방식은 서버 유지 관리, 데이터 저장, 백업, 개발 등의 상당한 비용을 발생시킨 데에 비해, 클라우드형 서비스는 앞의 비용이 발생하지 않습니다.3. 유연성. 클라우드 기반 서비스는 대역폭, 사용자수 등의 니즈가 증가하거나 변동하는 비즈니스를 위해 다양한 옵션을 제공합니다. 예를 들어, CRM 시스템을 이용해야 하는 직원이 많아졌다면 사용자를 추가한 만큼 요금이 변동됩니다. 간단하게 말하면, SaaS 서비스의 가장 큰 장점 중 하나는 기업의 니즈가 변화할 때마다 확장 및 축소가 쉽다는 점입니다.자유, 권한, 생산성한 명의 특별한 사람이 모든 문제를 결정하고 해결할 수 있을까요? 마이크로 매니징은 팀 운영에 있어 많은 악영향을 끼칩니다. 업무의 부담을 나누고 책임과 권한을 알맞은 담당자에게 위임하는 것은 기업의 관점에서 상당한 효율성을 발휘합니다. 조직 계층 구조의 각 직원이 스스로 결정할 수 있도록 하고, 자신이 내리는 의사 결정에 수반되는 책임을 느낄 수 있도록 한다면 직원들의 오너십을 키울 수 있습니다.당신의 비즈니스 운영에 맞도록 클라우드 시스템을 도입한다면 앞서 언급된 권한 위임과 의사결정을 내릴 수 있으며 부하직원의 프로젝트를 결재하는 기능은 필수라고 볼 수 있습니다. 그렇지 않으면 모든 승인 절차는 이메일이나 서류 절차 같이 시스템의 외부에서 이루어집니다. 새로운 시스템이 기업의 권한/승인 절차와 부합되는지, 조직의 운영적 니즈를 얼마나 수용하는지 확인해 보아야합니다.체크리스트 예:시스템에 여러 개의 액세스 레벨이 있습니까?특정 액세스 권한만 승인 할 수 있습니까?승인자의 이름과 시간을 기록해줍니까?직원에게 더 많은 자유를 부여하십시오. 직원들이 스스로 결정을 내리고 스스로의 동기부여와 생산성을 높일 수 있도록 알맞은 권한을 부여하세요. 우리는 리더로서 직원들의 자유와 권한을 허용하는 동시에 책임을 지어주고 합리적인 규칙과 지침, 그리고 성과 측정 방식을 이용하여 모두가 기업과 함께 성장할 수 있는 방향성을 제시할 수 있어야 합니다. 이렇듯 기업문화를 형성하고 그에 걸맞는 기술을 부합하여 기업과 구성원 모두의 이익을 극대화해보세요.#시프티 #기업문화 #혁신 #SaaS #조직문화 #기업소개 #시스템구축 #원격근무 #리모트 #디지털노마드

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