* 이 글은 Next.js의 공식 튜토리얼을 번역한 글입니다.** 오역 및 오탈자가 있을 수 있습니다. 발견하시면 제보해주세요!목차1편: 시작하기 2편: 페이지 이동 3편: 공유 컴포넌트4편: 동적 페이지 5편: 라우트 마스킹6편: 서버 사이드 7편: 데이터 가져오기 8편: 컴포넌트 스타일링 - 현재 글9편: 배포하기개요지금까지 컴포넌트를 스타일링 하는 것을 미뤄왔습니다. 그러나 이제는 몇 가지 스타일을 적용해볼만 합니다.React 애플리케이션에는 컴포넌트를 스타일링 할 수 있는 여러가지 기술들이 있습니다. 크게 두 가지 방법으로 분류할 수 있습니다:1. 전통적인 CSS 파일 기반의 스타일링 (SASS, PostCSS 등)2. CSS in Js 스타일링 결과적으로 전통적인 CSS 파일 기반의 스타일링(특히 SSR)은 실용적인 문제가 많아 Next.js에서 스타일을 지정할 때는 이 방법을 사용하지 않는 것이 좋습니다. 대신 CSS in JS 방법을 추천합니다. 이 방법은 CSS 파일들을 불러오는 것보다 개별적인 컴포넌트 스타일링 할 때 사용 할 수 있습니다.Next.js는 styled-jsx라는 CSS in JS 프레임워크를 미리 설치해두었습니다. 컴포넌트에 이미 익숙한 CSS를 작성할 수 있습니다. 이 CSS는 해당 컴포넌트에만 적용되며 심지어 하위 컴포넌트에도 적용되지 않습니다.이는 CSS가 범위가 있음을 뜻합니다.styled-jsx를 어떻게 사용할 수 있는지 살펴봅시다.설치이번 장에서는 간단한 Next.js 애플리케이션이 필요합니다. 다음의 샘플 애플리케이션을 다운받아주세요:아래의 명령어로 실행시킬 수 있습니다:이제 http://localhost:3000로 이동하여 애플리케이션에 접근할 수 있습니다.home 페이지 스타일링하기home 페이지(pages/index.js)에 스타일을 추가해봅시다.간단히 pages/index.js를 다음과 같이 변경해주세요:   <style jsx> 엘리먼트를 살펴봅시다. 이것은 CSS를 작성하는 곳입니다.코드를 바꾼 후 블로그 home 페이지는 다음과 같이 보일 것입니다:위의 코드에서 스타일 태그 안에 직접 스타일을 작성하지 않고 템플릿 문자열 안에 작성하였습니다.템플릿 문자열({``}) 없이 직접 CSS를 작성해봅시다:어떤 일이 일어날까요?- 아무 일도 일어나지 않는다.- 새로운 스타일이 적용된다.- "문법 에러: 기대되지 않는 토큰"이라는 에러가 발생한다.- "허용되지 않는 스타일 제공자"라는 에러가 발생한다.스타일은 템플릿 문자열 안에 위치해야 합니다styled-jsx는 babel 플러그인을 통해 동작합니다. babel 플러그인은 빌드 과정에서 모든 CSS를 분해하고 적용합니다. (스타일이 추가 시간 없이 적용됩니다)styled-jsx 내에 제약 조건을 제공합니다. 나중에 styled-jsx 안에 동적 변수를 사용할 수 있습니다. 이것이 스타일을 템플릿 문자열 ({``}) 안에 작성해야하는 이유입니다.스타일과 중첩된 컴포넌트home 페이지에 작은 변화를 만들어봅시다. 다음과 같이 링크 컴포넌트를 분리시켰습니다:    import Layout from '../components/MyLayout.js'   pages/index.js 안의 내용을 위와 같이 수정해봅시다.무슨 일이 일어나나요?- 아무런 일도 일어나지 않는다.- 링크가 아닌 h1만 스타일이 적용된다.- 페이지에 에러가 발생한다.- 콘솔에 에러가 발생한다.중첩된 컴포넌트에는 적용되지 않습니다위의 코드를 실행하면 다음과 같이 보입니다:보다시피 CSS는 하위 컴포넌트 내부의 엘리멘트에는 적용되지 않습니다.styled-jsx의 특징은 더 큰 애플리케이션에서 스타일들을 관리할 때 도움이 됩니다.이 경우에는 하위 컴포넌트에 직접 스타일을 적용해야 합니다. 지금 상황에서는 링크 컴포넌트에 직접 스타일을 적용해야 합니다:다른 방법로는 global selectors을 사용할 수 있습니다.전역 스타일때때로 하위 컴포넌트 안의 스타일을 바꿔야 합니다. 일례로 React에서 마크다운을 사용하는 경우가 있습니다. post 페이지(pages/post.js)에서 볼 수 있습니다.post 페이지는 전역 스타일이 유용하게 쓰일 수 있는 곳입니다. styled-jsx를 사용하여 몇 가지 전역 스타일을 추가해봅시다. pages/post.js에 다음과 같은 내용을 적용해주세요.다음 내용을 적용하기 전에 npm install --save react-markdown 명령어를 통해 react-markdown 컴포넌트를 설치해주세요. 무슨 일이 일어나나요?- 아무런 일도 일어나지 않는다.- 마크다운 컨텐츠에 스타일이 적용된다.- 페이지에 에러가 발생한다.- 콘솔에 에러가 발생한다.전역 스타일이 동작합니다전역적으로 스타일이 적용되므로 잘 동작합니다.이 기능은 매우 유용할 수 있지만 항상 전역 prop 없이 스타일을 작성하길 추천합니다.여전히 일반적인 스타일 태그보다 좋은 방법입니다. styled-jsx를 사용하면 필요한 모든 접두사와 CSS 유효성 검사가 babel 플러그인 내부에서 수행되어 추가적인 런타임 오버헤드가 없습니다.다음엔 무엇을 해야할까요이 편에서는 styled-jsx의 표면만 다루었습니다. 더 많은 것들을 할 수 있습니다. styled-jsx Github 저장소에서 더 많은 내용을 참고하세요.Next.js에서 꽤나 괜찮은 다른 스타일링 방법들이 있습니다. 이 부분도 같이 참고해주세요.#트레바리 #개발자 #안드로이드 #앱개발 #Next.js #백엔드 #인사이트 #경험공유

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

애플리케이션의 성능 개선은 웹 트랜잭션의 응답시간을 분석을 통해 이뤄집니다. 와탭의 응답시간 분포도는 대규모 트랜잭션 분석이 가능한 Heatmap 형태로 제공되고 있습니다. 와탭을 사용하는 사용자는 응답시간 분포도를 통해 웹 서비스의 응답시간이 느려지는 것을 알 수 있을 뿐만 아니라 패턴 분석을 통해 느려진 원인을 예측할 수도 있습니다. 와탭의 응답시간 분포도Y 축: 트랜잭션 응답시간을 의미합니다. 10s는 트랜잭션이 시작에서 종료까지의 시간이 10초가 걸렸다는 것을 의미합니다.X 축: 트랜잭션이 종료된 시간을 의미합니다.■: 트랜잭션이 발생한 위치에 색이 칠해집니다. 청색 계열은 정상적인 트랜잭션을 의미합니다. 노랑색과 붉은 색 계열은 에러가 발생한 트랜잭션을 의미합니다. 색상의 농도는 해당 영역에 발생한 트랜잭션의 밀도를 상대적으로 표시합니다.  와탭의 응답시간 분포도는 트랜잭션의 응답시간을 시각화하는 것입니다. 웹 서비스의 트랜잭션을 시각화 할 뿐만 아니라 추적하고자 하는 영역을 드래그하여 트랜잭션의 진행상황을 추적하는 것도 가능합니다.  추적하고 싶은 트랜잭션을 드래그 하는 모습와탭의 응답시간 분포도에서 트랜잭션을 선택하면 분석 화면으로 넘어갑니다. 해당 애플리케이션 서버 정보를 통해 선택된 트랜잭션이 어느 애플리케이션 서버에서 발생했는지 알 수 있습니다.애플리케이션과 선택된 트랜잭션 정보 화면분석하고 싶은 애플리케이션 서버를 클릭하면 해당 애플리케이션 서버에서 발생한 트랜잭션 목록을 확인 할 수 있습니다. 최종적으로 APM을 통해 확인하고 싶은 내용이 트랜잭션의 디테일한 정보일 것입니다. 와탭의 APM은 트랜잭션을 시각화하고 시각화된 트랜잭션을 선택하면 선택된 트랜잭션의 목록을 애플리케이션 서버 별로 분류하여 선택할 수 있는 구조를 가지고 있습니다. 이것은 능동적으로 웹 애플리케이션을 분석할 수 있는 최적화된 흐름이라고 생각할 수 있습니다. 사용자가 응답속도 분포도를 통해 선택한 트랜잭션 목록#와탭랩스 #개발자 #개발팀 #인사이트 #경험공유 #일지

들어가기 전: 실제로 프로젝트와 팀원들과의 작업 환경을 구축한 경험을 바탕으로 작성했습니다. 한마디로 실화. Overview소스를 수정할 때마다 지속적인 테스트를 하기 위해 AWS lambda 로컬 테스트 환경, SAM을 결합해서 환경을 구축했습니다. 이번 글에서는 팀원을 추가하고 CodeCommit을 리포지토리로 사용하는 것도 소개하겠습니다. 예상 구성도테스트 환경 구축, 도저언!1. 팀원 추가하기 IAM 서비스를 이용해서 프로젝트를 같이 사용할 유저를 추가합니다. IAM에 유저를 추가하면 AWS 콘솔을 같이 사용할 수 있습니다. 사용자 추가를 클릭해 유저를 추가합니다. 팀원마다 한 개의 계정을 추가해야 합니다. 사용자 세부 정보 설정 > 엑서스 유형에서 ‘프로그램 방식 엑서스’와 ‘AWS Managrment Console 엑서스’를 체크합니다. 여기에서는 개발2팀 팀원인 강원우 과장의 계정을 생성했습니다.1) 비번은 귀찮으니 미리 세팅해둡시다. 유저 계정은 그룹을 생성해서 관리하면 편합니다. 그룹을 사용하면 보다 편리하게 계정 권한을 제어할 수 있기 때문입니다. 이번 예제에서는 그룹 이름을 codeStarGroup으로 만들었습니다. AWSCodeStarFullAcess를 정책으로 설정하고 ‘그룹생성’을 클릭해 그룹을 추가합니다. 2) codeStarGroup에 체크한 후, ‘다음: 검토’를 클릭해 진행합니다.‘사용자 만들기’를 클릭해 생성을 마무리합니다.계정 추가를 완료했습니다.사용자 이름(위의 예시에서는 kanggw)을 클릭하고, 뒤이어 ‘보안자격 증명’ 탭을 클릭합니다.콘솔 로그인 링크를 공유합시다. 링크를 입력하고 들어가면 그룹 로그인이 활성화가 되어있다는 걸 볼 수 있습니다.2. CodeStar 설정하기 프로젝트 인원을 무사히 추가했습니다. 이제 프로젝트를 만들어 봅시다. CodeStar 프로젝트 세팅 방법은 R&D본부 윤석호 이사님이 쓴 ‘애플리케이션 개발부터 배포까지, AWS CodeStar’를 참고해주세요.새 프로젝트를 생성합니다.python AWS Lambda를 선택합니다.프로젝트 이름은 ‘admin-lambda-API’로 입력하겠습니다. 그 후에 ‘다음’을 클릭합니다.‘프로젝트 생성’을 클릭합니다.우리는 Git을 이용해 로컬에서 직접 관리할 것이므로 ‘명령행 도구’를 선택한 후, ‘건너뛰기’를 클릭합니다.3분 만에 프로젝트가 생성되었습니다. 참 쉽죠?3. 프로젝트에 팀원 추가하기프로젝트를 같이 하려면 팀원을 추가해야겠죠. 팀원 추가는 codeStar 대시보드 좌측의 ‘팀’ 탭을 클릭하면 됩니다.‘팀원 추가’ 클릭IAM에서 등록한 팀원의 정보를 불러옵니다. ‘추가’를 클릭해 팀원을 추가합니다. 여기에서 중요한 사실 하나! 프로젝트의 소유자로 지정해야 소스 접근 및 코드 변경이 가능합니다.4. 코드 체크 아웃앞서 설명한 것처럼 직접 Git으로 소스를 받아야 하기 때문에 codeCommit으로 이동합니다. codeStar 대시보드 왼쪽 ‘코드’ 탭을 클릭하면 코드 내역들을 확인할 수 있습니다.‘URL 복제 > HTTPS’를 클릭해 경로를 복사합니다. 소스를 클론하기 전에 계정에 깃허용을 먼저 해주세요. IAM 돌아와서는 계정 설정을 변경해야 합니다.사용자 > kangww > 보안 자격 증명 탭 클릭 > HTTPS Git 자격 증명 > 생성Git에서 사용할 ID와 비밀번호를 받았습니다. 해당 정보를 팀원에게 전달합니다. 이제 workspace로 이동해 체크아웃을 시작합니다.git clone [복사한 경로] [id 입력] [pw 입력] clone이 완료 되었습니다. 이제 기본 프로젝트가 들어있기 때문에 바로 실행할 수 있습니다. 미리 설치된 SAM으로 실행해보겠습니다.이제 해당 경로에 이동해 SAM을 돌려서 정상적으로 구동되는지 확인해봅시다. (SAM설치 방식은 부록에서 소개합니다.) sam local start-api -p 3333 성공적으로 SAM이 구동되었습니다. (짝짝) http://localhost:3333 으로 접근해 결과를 확인할 수 있습니다. 이제 로컬에서 작업을 진행하면서 바로 바로 확인이 가능해졌습니다. 만약 동료와 함께 개발한다면 아래처럼 구동해야 자신의 IP에 접근할 수 있습니다.sam local start-api -p 3333 -host [자신의아이피] 글을 마치며CodeStar의 관리와 배포 기능은 강력합니다. 많은 부분을 알아서 해주니 고마울 뿐입니다.3) 이제 Lambda의 local 테스트 환경인 SAM을 이용해서 배포 전 과정까지 간편하게 테스트를 해보세요. 배포의 복잡함을 codeStar에서 해결하고 테스트를 하거나 개발을 할 때는 SAM을 이용해 효율적으로 업무를 진행합시다.글 쓰면서 발견한 다섯 가지1) codeDeploy > executeChangeSet 에 구동될 때 cloundFormation 이 자동 세팅 됩니다. 엄청 편합니다. API 배포가 진행되면 lambda에서 바로 수정하는 게 편합니다.2) codeCommit은 https 보다 ssh방식을 권장하며, https방식으로 하다가 꼬이면 여기를 클릭해 해결하세요.3) codeStar는 다음과 같은 추가 구성을 자동 세팅합니다.codeStar 용 S3 버킷codePipeLine용 S3 버킷cloundFormation 세팅lambda 세팅4) IDE를 cloud9을 사용하면 EC2 및 EBS가 생성되니 주의하세요. 그리고 생각보다 느립니다.5) 로컬에서 Git push를 하면 약 5분 정도 뒤에 최종적으로 배포됩니다.부록1)SAM을 설치하기 전, 여기를 클릭해 docker를 미리 설치하세요.2)SAM 설치 안내는 여기를 클릭하세요. ( npm install -g aws-sam-local )참고1)강원우 과장은 귀여운 두 달팽이, 이토와 준지의 주인이기도 하다. 2)AWSCodeStarFullAcess는 codestar 접근에 대한 권한을 부여한다.3)자동 배포까지 2~5분 정도 걸리는 게 어렵게 느껴질 수 있다.글천보성 팀장 | R&D 개발2팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유

사실 개발 방법론이라는 것을 7개월 전만 해도 귓등으로 듣고 그게 왜 필요한지도 알지 못했던 것이 사실입니다. 부끄럽지만 애자일이 수많은 프로그래밍 언어중 하나인줄 알았죠.10개월 전만해도 우리 팀은 저를 포함해서 3명에 불과했고 모든 것은 메신저와 구글 드라이브로 일을 처리했습니다. 기억력이 좋지않지만 머릿속에서 각 팀원들이 언제까지 뭘하고 다음엔 무엇을 언제까지 해야겠다라는 것이 그려질 정도로 적은 숫자였죠. 개발방법론이 필요한 이유가 없으니 무관심한 것은 당연했습니다. 이 글을 읽으시는 분들 중에 아마 7개월 전의 저와 같은 생각을 하신 분이 있을지도 모르겠네요.지금 우리 팀은 11명으로 늘어났고(그중에 소프트웨어 개발팀만 7명) 그들 하나하나를 마이크로 매니징하기에는 저라는 인간이 너무나 머리가 아팠습니다. 그래서 도입한 것이 애자일 개발방법론이었는데 애자일은 비록 실패로 끝났지만 거기서 많은 교훈을 얻고 칸반으로 전환하는 원동력이 되었습니다.우리 팀은 애자일 개발선언 중에서도 "계획을 따르기보단 변화에 대응하기"라는 선언을 굉장히 맘에 들어했는데, 그 이유는 애자일 도입이전 우리의 상황이 그랬기 때문이었습니다. 매일매일 고객의 요구는 들어오고 경영진과의 대화에서 매일매일 우선순위가 바뀌고, 그에 따라 하던 작업이 마무리되지 않으면 브랜치를 새로 파서 다른 작업을 하고 미완성된 코드는 늘어났으며 그에 따라 불평불만도 늘어났습니다.여러 애자일 개발방법론 중에서도 우리가 선택했던 것은 eXtreme Programming(XP)이었는데, 우리에게 스크럼과 같은 1달간의 스프린트는 너무 길다, 2주간의 이터레이션(Iteration)으로 구성된 XP가 좋다라는 것이었습니다.우리는 스크럼 보드를 준비했고 거기에 포스트잇을 붙여가면서 아침마다 스크럼 회의를 했으며, 기록을 남기기위해 레드마인을 사용하였습니다.eXtreme Programming Flow Chart간단하게 왜 실패했는지 이유를 들어볼게요.1. 배포 계획(Release Plan)을 수립하기 힘들다물론 계획자체를 만들기 힘들다는 것이 아닙니다. 배포 계획을 만들어도 그대로 지켜지지 않았습니다. 큰 틀로 배포 계획을 만들고 작은 틀로 반복 계획(Iteration Plan)을 세우는 것이 목표였는데, 수립을 해봤자 절대 지켜지지 않았습니다. 우리와 같은 작은 스타트업의 작은 팀은 시장의 요구사항이라는 급류에 이리저리 쓸려 매일매일 계획과는 다른 일을 하고 있었거든요. 리팩토링할 시간은 커녕 테스트 코드를 짤 시간조차 없었습니다.(핑계일수도 있지만요)거짓말이 아니고 단 한번도 계획대로 되지 않았습니다.2. 팀원들의 시간 예측 능력 부족애자일은 팀원들이 시간 예측을 굉장히 잘한다는 가정하에 잘 돌아가는 방법론입니다. 모두가 함께 한자리에 모여 복잡도를 논의하고 그에 따른 프로젝트의 시간 예측을 하고 함께 번다운 차트(Burn-down chart)를 그리며 하하호호 잘 나아가야 하는데, 우리 팀은 그렇지 않았습니다. 물론 실력부족이라고 탓할 수도 있겠지만 실제로 스크럼 보드에 예측시간 8시간이라고 적어놓고 4시간정도만 지나면 다른 문제가 터지거나 다른 기능을 개발해야하는 둥 제대로 지켜지지 않았을 뿐더러 그런 방해요소가 없다고 하더라고 8시간보다 더 많이 걸리거나 더 적게 걸리기도 했습니다.예측시간을 측정하기 힘든 마이너한 이유중에 하나는, 스파이크 솔루션(Spike solution)를 개발하는데 얼마나 걸리는지 예측하지 못한 탓도 있었는데 이 세상에 없는 솔루션을 개발하는데 있어 이전의 경험만으로는 턱없이 부족했습니다.이런 이유들 때문에 우리는 XP를 버릴 수 밖에 없었습니다. 계획보다는 변화에 적응하자!라는 원대한 목표가 있었지만 애자일 개발방법론은 우리가 닥친 미친듯한 변화를 감당하기에는 벅찼습니다. 우리는 스크럼 보드를 점점 멀리하기 시작했고 다시 구글 드라이브로 돌아갔습니다.저는 구글 문서(Google Docs)에 우리가 해야할 요구사항을 적었습니다. 우선순위가 높은 일일 수록 상단에 두었습니다. 그 오른쪽에는 일을 해야할 사람의 이름을 적었습니다. 그렇게 적고 문서를 공유하면 팀원들은 그 문서를 보고 그 순서대로 일을 진행하였습니다. 일을 진행하다가 생기는 의문점은 급한 일일 경우 구두로 전달하고 급하지 않을 경우에는 메신저 또는 문서의 빈공간을 활용하여 적었습니다.완료된 요구사항은 취소선을 긋고 옅은 글씨로 처리하여 해야 할일과 완벽히 구분되도록 하였으며 한 사람당 해당 시간에 하나의 일만 처리하도록 규칙을 세웠습니다. 보류되는 일은 보류 섹션으로 할일을 옮기고 보류가 되는 이유를 적도록 했습니다. 혼자 해결하기 힘들경우 회의를 통하여 함께 해결할 수 있는 자리를 마련했구요.그런식으로 우리는 배포 시기를 최대한 맞추려고 노력했고 이상하게도 XP를 버리고 구글 문서로 갈아타니 일이 더욱 수월해져서 이제는 생각보다 일이 빨리 끝나는 것이었습니다. 그리고 더욱 놀라운 일은 지금까지 우리가 했던 방식이 칸반과 유사하다는 것이었습니다.저는 바로 칸반 보드를 도입했고 이에따라 애자일에서 배운 규칙/정신과 칸반의 장점을 혼합하여 우리 팀만의 칸반보드를 완성하였습니다. 현재 우리가 쓰고 있는 칸반 보드는 Kanboard의 오픈소스를 그대로 사용하고 있습니다.1. 활발한 커뮤니케이션을 토대로 개발한다. 절대 혼자 일하지 않는다- 지속적으로 팀의 동의(Team agreement)를 구한다.- Knoledge island를 탈출하라(자신이 알고있는 지식이 전부가 아니다).- 코드 병목현상(Code bottleneck)을 탈출하라. Collective ownership을 발동하라.2. 한 번에 한개의 일만 처리하라. 보류하는 일은 최소로 하라칸반의 핵심으로 한 번에 한개의 일만 처리하도록 합니다. 개발자의 뇌는 하나도 손은 두개이고 손가락은 열개이므로 한 번에 하나의 일만 처리해야 합니다. 한 개의 일이 끝나지 않으면 다음 일을 진행하지 않는 것을 규칙으로 합니다.3. 가능하다면 예측시간을 적는 습관을 들인다개발완료시간을 정확히 예측하는 것은 개발자들에게 정말 중요한 능력중에 하나입니다. 신제품을 시장에 빨리 내놓을 수록 피드백을 빨리 받을 수 있으며, 고객으로부터의 소중한 피드백은 개선된 다음 버전을 위한 초석이 되기 때문입니다. 사업적으로 성공하고 싶다면 예측시간을 꼭 적는 습관을 들여 자신이 정해진 시간 동안 얼마만큼의 일을 할 수 있는지 예측하는 일이 큰 도움이 됩니다.4. 더 좋은 방법이 있다면 기존의 방법을 과감히 버린다저의 철학과도 일치하는 이야기인데요, 우리 팀과 회사가 함께 좋아질 수 있는 방법을 발견한다면 과감히 현재의 방법을 버리고 새로운 방법을 시도한다라는 우리 팀만의 맹세입니다. 앞으로 항상 발전하겠다는 의지를 가지고 잠시 손을 놓고 한발짝 물러서서 비판적인 자세로 모든 것을 바라보는 시간을 가지는 것도 혁신의 첫발짝이라고 생각합니다.지금까지 우리 팀이 꾀한 겉으로 보기에 가장 큰 혁신은 기존의 속도가 느리고 사용하기 불편했던 솔루션을 과감히 버리고 새로운 서버와 새로운 언어로 전환하면서 마이그레이션 및 새로운 형태의 최적화된 솔루션을 구축했다는 것입니다.(물론 내부적으로 가장 큰 혁신은 기존의 방법을 버릴 수도 있다라는 생각을 가졌다는 것이지요)현재 저는 팀 매니저로서 User story(요구사항정의서) 관리, Release plan(배포 계획서), 와이어프레임을 포함한 기획서 등 최소한의 문서만 관리하고 있으며, 팀원들 또한 이 시스템에 만족하며 아직까지는 판단하기 이르지만 굉장히 좋은 방법인것 같습니다.5개월간 칸반을 사용하면서 팀원들로부터 받은 피드백은 다음과 같습니다.1. 매일 아침 15분씩 하는 스크럼 회의는 새로운 기능 또는 새로운 프로젝트를 진행할 때는 굉장히 유용하지만, 디버깅 또는 테스팅 기간에는 시간낭비다.이 말을 한 팀원의 말에 따르면, 우리 팀은 데이터베이스를 관리하는 사람, API를 만드는 사람 등등 각자의 역할이 확실히 나누어져 있는데 새로운 기능을 개발할때는 여러사람과 소통해야하는 경우가 많고 개발 스펙이 달라지거나(작게는 함수이름 변경 등) 여러 변수들이 작용할 수 있으므로 짧게 자주만나는 것이 좋다고 말했습니다.2. 회의도 시간낭비다- 회의는 가급적 개최하지 않고 가능하다면 1:1 구두로 해결한다.- 급한일이 아닐경우에는 이메일/메신저를 활용하도록 한다.3. 칸반 보드에 보류 칼럼, 테스팅 칼럼을 나눈다보류 칼럼과 테스팅 칼럼을 나누어 적어 어떤 할일이 보류되었으며 어떤 할일이 테스팅 중인이 확실히 하도록 했습니다. 이는 테스팅을 하는데 오래걸리는 기능들이 있으며 테스팅을 하는 동안 다른 기능을 개발할 수도 있다는 것이 큰 이유였습니다.우선 순위가 바뀌었을 때 할 일을 잠시동안 놓아둘 칼럼이 없다는 것이 보류 칼럼이 존재하는 가장 큰 이유였습니다. 그러나 보류 칼럼에 놓을 수 있는 할 일의 수는 개인당 1개로 제한하여 2개 이상의 보류하는 일이 없도록하여 경각심을 갖도록 하였습니다.앞으로의 계획은 전에 언급했던 와비파커(Warby Parker)의 기술팀이 도입한 와블스(Warbles) 시스템을 적용해보는 것입니다. 우리 팀이 어떻게 바뀔지 정말 기대가 됩니다.#비주얼캠프 #인사이트 #경험공유 #조언 #개발자 #개발팀

네이버랩스의 인재상은 passionate self-motivated team player입니다. 어쩌면 '자기주도적 팀플레이어'라는 말은 형용모순(形容矛盾)일 지도 모릅니다. 하지만 우린 계속 시도했고, 문화는 계속 쌓여갑니다. 다양한 분야의 전문가들이 경계없이 협력하고 스스로 결정하며 함께 도전하는 곳의 이야기를 전합니다. How to work at NAVER LABSH2W@NL 시리즈 전체보기지난해 11월, 네이버랩스는 국내 기업 중 최초로 도로 HD맵 데이터셋을 무상 배포했습니다. 수많은 국내 자율주행 연구자들을 위해서입니다. 그렇다면, 왜 자율주행 연구에 HD맵은 중요할까요? 안전하고 효과적인 자율주행을 위해서입니다. 센서 데이터와 HD맵을 연동하면 고층 빌딩이 즐비한 도심에서도 현재 위치를 끊김없이 정확하게 인식할 수 있도록 해주고, 복잡하게 얽혀있는 도로 구조를 광범위하게 파악해 효과적인 경로 계획을 세울 수 있으며, 신호등/횡단보도 등의 위치를 HD맵을 통해 미리 확인해 실시간 인지 정확도를 높일 수도 있습니다. 그래서 네이버랩스는 자율주행 연구 시작 시점부터 HD맵 솔루션을 함께 연구해 왔습니다. 그 결과가 하이브리드 HD 매핑입니다. 항공사진과 MMS 데이터를 융합해 고정밀 지도를 만드는 기술입니다. 다른 어디에서도 시도하지 못했던, 가장 독창적인 방식의 매핑 솔루션은 어떻게 개발되었을까요? 그 주역들의 이야기를 들어보았습니다.Q. 왜 HD맵 기술을 개발하나요?HD맵은 도로 자율주행을 위한 시작(김형준|시스템 소프트웨어 개발) 자율주행 시대가 온다고 합니다. 그렇다면, 반드시 그보다 먼저 필요한 것은 HD맵입니다. 자율주행 차량이 도로를 안전하게 주행하려면, 차선 단위의 아주 정밀한 정보가 필요하기 때문입니다. 보통은 MMS (Mobile Mapping System) 차량이 일일이 돌아다니며 수집한 도로 데이터로 HD맵을 제작하는 것이 일반적이지만, 이 방식은 소요되는 시간과 비용이 많습니다. 지역이 광범위해지면 더 많은 리소스가 필요하고요. 우리는 그걸 획기적으로 줄일 수 있는 방법을 찾고 싶었습니다. 정확도는 유지하되, 도시 단위의 넓은 지역을 더 빠르고 효율적으로 제작하는 솔루션을 찾았습니다. 그 결과가 네이버랩스의 하이브리드 HD 매핑 기술입니다. 항공 사진을 통해 대규모 지역의 도로의 레이아웃과 건물 정보 등을 얻고, 이 위에 자체 MMS 차량인 R1으로 취득한 데이터를 정합해서 HD맵을 만듭니다. R1이 최소한만 주행해도 HD맵을 제작할 수 있기 때문에, 소요되는 시간과 비용을 획기적으로 줄일 수 있습니다.(전준호|비주얼 피처맵 개발) 이렇게 완성된 HD맵에는 도로 자율주행에 필수적인 고정밀 정보들이 담겨 있습니다. 도로의 구조 정보인 로드 레이아웃 맵(Road Layout Map), 기하 정보를 가진 포인트 클라우드 맵(Point Cloud Map), 시각 정보를 가진 비주얼 피처 맵(Visual Feature Map) 등이죠.(신용호|센서 캘리브레이션) 우리가 하이브리드 HD 매핑이란 새로운 방식을 고안하고 완성할 수 있었던 건, 그 동안 지속적으로 개발해 온 자율주행 기술과 항공 사진 기반의 지도 생성 기술을 모두 내재화하고 있었기 때문이죠.도시 규모의 HD맵을 효율적으로 제작할 수 있는 독자 솔루션(이진한|PM/소프트웨어 개발) 사실 자율주행 기술을 연구하는 회사들은 많습니다. 그런데 독자적인 HD 매핑 기술까지 보유한 회사는 의외로 많지 않아요. 네이버랩스도 처음엔 그랬어요. 자율주행 프로젝트가 시작된 2016년 무렵엔 자체 HD 매핑 기술이 없다는 점이 아쉬웠어요. 센서만으로는 얻기 힘든 정보들을 미리 담아둘 수 있는 그릇이 HD맵인데, 바로 그 정보들이 자율주행의 성능을 높이는데 큰 역할을 하거든요. 결국 이 그릇을 만드는 방법을 내재화했죠. 이제는 도시 규모의 HD맵을 효율적으로 제작할 수 있는 독자 솔루션을 갖췄습니다. 실제로 이 결과물을 Localization에 바로 활용하여 자율주행 기술도 함께 고도화하고 있습니다.Q. 어떤 협업을 통해 개발되었나요?아웃풋이 바로 새로운 인풋이 되는(이진한|PM/소프트웨어 개발) 하이브리드 HD 매핑은 여러 분야의 전문가들이 함께 했습니다. 한 프로젝트의 결과물이 다른 프로젝트의 입력으로 연결되는 구조라고 할 수 있겠네요. 예를 들어 R1 하드웨어 장비 개발 프로젝트는 Sensor Calibration 프로젝트로 이어지고, 항공 매핑을 통해 만들어진 로드 레이아웃 데이터에 MMS 데이터를 연결하고… 이렇게 유기적인 의존 관계로 진행되었습니다.(이웅희|센서 데이터 툴 개발) 자체 개발한 MMS 차량인 R1에는 다수의 카메라, 라이다, GPS, 자이로센서 등 많은 센서들이 탑재되어 있어요. 이러한 개별 센서들에 대한 드라이버 개발은 물론 전체 센서 데이터가 동시에 들어왔을 때 유실 없이 저장할 수 있는 시스템 개발, 그리고 운용 소프트웨어 개발이 필요했습니다.(신용호|센서 캘리브레이션) R1이 수집된 데이터를 융합하기 위해서 반드시 필요한 과정이 있습니다. 캘리브레이션입니다. 각 센서간에는 상대적인 위치와 방향 등의 차이가 발생하는데, 캘리브레이션을 통해 정확하게 매칭을 시켜야 하죠. 그렇지 않으면 수집한 데이터들을 제대로 사용할 수가 없습니다.하늘과 도로에서 획득한 데이터를 융합하여 도시 규모의 HD맵 생성(김진석|항공 매핑) R1이 지상을 담당한다면, 저희는 하늘에서 찍은 정보를 활용합니다. 항공 사진을 통해 정확도를 획기적으로 높이는 방식을 개발했습니다. 항공 사진에서 8cm 해상도로 왜곡이 제거된 연직 정사영상(TrueOrtho)을 생성한 후, 도로 영역의 2D/3D 로드 레이아웃을 생성합니다. 여기에 R1이 수집한 포인트 클라우드 데이터를 정합하면, 대규모 지역의 HD맵을 빠르고 효율적으로 만들 수 있게 됩니다.(임준택|라이다 피처맵 개발) 이처럼 R1이 도로의 포인트 클라우드를, 항공기가 대규모 지역의 로드 레이아웃을 스캔해 결합하는 방식은 아주 새로운 솔루션입니다. 물론 그냥 붙인다고 HD맵이 바로 나오는 것은 아닙니다. 스캔 데이터에서 자동차나 사람같이 불필요한 부분을 지우는 딥러닝 모델을 만들고, HD맵을 사용할 차량이나 로봇을 위한 특징점을 추출하는 과정도 필수적입니다.서로 다른 분야의 전문가, 하나의 팀(전준호|비주얼 피처맵 개발) HD맵을 이루는 요소들, 즉 Road Layout Map/Point Cloud Map/Visual Feature Map 등의 구축 알고리즘을 각기 개발해, 이 데이터들을 잘 포함하고 있는 HD맵을 제작하는 거죠. 이렇듯 많은 팀의 협력으로 완성한 매핑 솔루션입니다. 항공 사진의 정합과 인식, MMS 차량의 데이터 수집을 위한 장비와 센서 시스템 구축, GPS와 LiDAR 데이터를 이용한 위치 인식 기술, 시각 정보 추출을 위한 딥러닝 기술 등 서로 다른 전문가가 하나의 팀으로 모여있어요. 같은 목적을 갖고 밀접하게 협업하기에 더 높은 수준의 연구와 개발이 가능한 것 같습니다.“결과도 중요하죠. 하지만 문제를 같이 정의하고, 함께 해법을 찾아가는 과정은 더 중요한 것 같아요. 그래야 좋은 결과가 이어질 수 있으니까요.”(김형준|시스템 소프트웨어 개발) 다양한 분야의 전문가들이 모여 유기적인 협업이 언제든 가능하다는 것은 프로젝트에서 난항을 겪을 때 큰 힘을 발휘합니다. 예전에, 데이터 취득 시스템의 안정성에 문제가 생긴 적이 있어요. 그때 하드웨어 엔지니어와 소프트웨어 엔지니어들이 모두 모여 동시에 검토를 했습니다. 필드를 돌며 문제 발생 시점의 상황을 함께 체크하고, 그 중 기구 엔지니어 분들이 원인을 찾아 문제를 해결했습니다.(김상진|하드웨어 설계) 저도 그때가 기억나요. 차량 진동으로 인한 간헐적인 회로 단락이 원인이었죠. 짧은 시간에 가장 정확한 답을 찾기 위해 필요한 것은, 역시 유기적인 팀웍인 것 같아요.(신용호|센서 캘리브레이션) 팀이 없는 것처럼 협업이 잘 된다는 점도 자랑하고 싶어요. 함께 잘하기 위해서라는 목표만으로 일에 몰입할 수 있다는 건 정말 좋은 경험이죠.Q. 경과, 그리고 목표는?서울시 2,000km 로드 레이아웃 지도 구축(김진석|항공 매핑) 서울시 4차선 이상 도로 2,000km에 대한 로드 레이아웃 구축을 완료했습니다. 자율주행에 필요한 도로 구조 정보(차선, 중앙선, 정지선, 좌회전 등의 노면표시)를 정밀한 벡터 데이터 형식으로 변환했습니다. 서울시만큼 큰 대도시 규모의 매핑이란 관점에서 보자면, 국내에서 유일한 기술입니다.(김형준|시스템 소프트웨어 개발) 하이브리드 HD 매핑의 자체 프로세스가 정립되면서, 예전과 비교해 최소한의 작업으로 원하는 지역의 HD맵을 생성할 수 있게 되었습니다. 무상 공개한 판교 및 상암 지역 HD맵도 이 결과물 중 하나죠.(이진한|PM/소프트웨어 개발) 상암/판교 지역의 HD맵 무상 배포를 DEVIEW에서 발표했을 때가 정말 보람되었던 것 같아요. 국내에서 자율주행을 연구하고 있는 많은 기관에서 데이터셋 신청을 해주셨어요. 저희의 솔루션으로 만든 HD맵이 국내 자율주행 기술 고도화에 도움이 될 수 있었으면 좋겠습니다.(전준호|비주얼 피처맵 개발) 네이버랩스의 HD맵은 도로 위의 정밀 위치 인식을 최종 목표로 하고 있습니다. 예를 들어 Visual Feature Map의 경우 위치 인식에 필요한 최소한의 시각 정보와 기하 정보를 Descriptor 형태로 경량화 했기 때문에, 대규모 도심 지역의 데이터도 용량이 아주 작습니다. 이러한 최적화를 계속할 계획이고요.미래 모빌리티 세상으로 한 걸음 더(김상진|하드웨어 설계) 매핑 시스템 고도화의 목표는 결국 신뢰성 높은 지도를 만드는 것에 있습니다. 하드웨어 시스템의 신뢰성/유연성/운용성을 빠르게 개선하고, 이를 더욱 저비용으로 구현할 수 있도록 개발을 지속하고 있어요. 이런 연구들의 결과가 모이고, 이러한 고정밀 데이터가 쌓이면, 우리가 상상하고 있는 미래 모빌리티 세상을 더욱 앞당길 수 있다고 생각합니다.

세상에 나쁜 개발자는 없다. 나쁜 개발 습관만 있을 뿐나쁜 개발자란 누구를 지칭하는 것일까? 코드가 별로인 개발자? 커뮤니케이션이 안되는 개발자? 나쁜 개발자로 지칭될 수 있는 사람들은 굉장히 많다. 하지만, 세상에는 나쁜 개발자는 없다고 생각한다. 단지, 나쁜 개발 습관만 존재할 뿐. 즉, 누구든지 나쁜 습관을 버리고 좋은 습관을 갖는다면 언제든지 좋은 개발자가 될 수 있다는 것이다. 좋은 개발자, 나쁜 개발자. 이것은 칭호가 아니라 속성일 뿐이다. 언제든지 바뀔 수 있는 속성 말이다.이것이 속성인 이유는 누구든지 좋은 개발자와 나쁜 개발자의 속성들을 가지고 있기 때문이다. 단지 그 속성의 비율의 차이가 그 사람이 어떤 개발자인지 결정할 뿐이다. 흔히, 좋은 개발자라고 불리는 사람도 나쁜 개발 습관이 있을 수 있다. 또, 나쁜 개발자라고 욕을 먹는 사람도 좋은 개발 습관이 있을 수 있다.우리는 이 글에서 나쁜 개발 습관(혹은 속성)들을 알아보고 왜 그것이 나쁜지 그리고 그것을 어떻게 피하는지에 대해 이야기할 것이다. 좋은 습관이 아니라 나쁜 습관들을 이야기하는 이유가 있다. 좋은 습관은 습득하기 어렵다. 하지만, 나쁜 습관을 버리는 것은 더더욱 어렵다. 나쁜 습관을 피하는 것이 때로는 좋은 개발자가 되기 위한 요건일 수도 있다. 아래의 습관들을 보면서 자신을 진단해 보자.(아래의 습관들 중 습관인 것들도 있고 단순히 사고방식이나 경향인 것들이 있다. 여기서 습관은 사고방식이나 행동의 양식 등 총체적인 행동 방식 등을 의미한다.)습관 1: 코드 리뷰가 없다.지난번에 같이 해보니까 험악만 말만 나오고, 분위기만 안 좋아졌다. 후배들에게 코드 지적받는 것도 자존심 상하고... 그리고 대부분 시니어들이 지적하고 주니어들은 고개만 끄덕이는 자리 아닌가? 코드 리뷰 할 시간에 코드 한 줄이라도 더 짜서 프로젝트 마감일이나 지키는 게 낫지. 솔직히, 프로라면 자기 코드는 자기가 책임져야 하는 거 아닌가?습관 2: 문서화를 하지 않는다.아니 개발할 시간도 부족한데 무슨 문서화인가. 개발자가 개발하는 사람이지 문서 만드는 사람인가? 인수인계받을 사람 오면 직접 알려주면서 일주일이면 끝날 텐데 말이다. 그리고 이때까지 만든 문서들 만들고 나서 본적이나 있나? 그냥 보여주기식 파일이지 뭐.습관 3: 커뮤니케이션 향상에 관심이 없다.지금도 말 잘하고 대화 잘 통하는데 더 향상시킬게 있나? 그리고 개발자의 핵심은 커뮤니케이션이 아니라 코딩인데 말이야. 컴퓨터랑만 잘 소통하면 되지. 어차피 다른 부서에 있는 사람들은 개발 기술에 대해서 잘 알지도 못하고... 커뮤니케이션 스킬은 그런 사람들이 향상시켜야 한다고 생각한다.습관 4: 업무 공유가 되지 않는다. 자신의 일에 대해 알고 있는 사람이 없다. 데드라인 잘 지키고, 주어진 일을 잘 해내면 된다고 생각한다. 보고를 하기 전까지 굳이 보고하지 않고, 동료나 후배들과 업무 공유를 잘 하지 않는다. 어차피 내가 하는 일에 별로 관심도 없는데 공유해봤자 무슨 소용인가?습관 5: 코드의 복붙(복사 후 붙여넣기)가 '일상화'되어 있다.직접 만드는 것보다 이미 만들어진 코드들을 찾아서 Ctrl +c,v하는게 더 빠르고 생산성 있다고 생각한다. 동료 개발자랑 공통 모듈을 만들어 사용할 수 있겠지만 그렇게 하기에는 너무 많은 리소스가 낭비된다고 생각한다. 잘 돌아가기만 하면 되지 않나?습관 6: 자신의 부족한 점을 드러내지 않는다.부족한 점에 대해 동료들과 터놓고 얘기하지 않는다. 괜히 부끄럽고 껄끄럽기도 하고 자신의 부족한 점이 드러나는 것이 두렵다. 동료들이 조언을 해주려고 해도 방어적으로 나오거나 피한다. 동료의 진솔한 피드백이 없으니 한 번 단점을 만들면 끝까지 내 것으로 가져간다.습관 7: 새로운 기술을 익히는데 시간을 투자하지 않는다.세상은 정말 빠르게 변하고 있다. 그리고 그 변화의 중심은 기술이고 기술 중에서도 IT 기술이 정점에 있다고 봐도 무방하다. 새로운 기술은 새로운 기술자들이 익히는 것이라 생각한다. 지금 하고 있는 일만으로도 벅차다. 그리고 지금 쓰는 기술이 시대의 주류인데 쉽게 바뀔까?습관 8: 자신의 개발 환경에서 벗어나지 않는다.개발자 모임이나 개발 커뮤니티에 시간을 쓰는 것은 낭비라고 생각한다. 개발에 대해 새로운 시도를 하지 않는다. 새로운 프레임워크나 협업 툴들이 나와도 기존의 환경을 고집한다. 왜냐하면 지금 개발 환경이 너무 편하고 익숙하니까.습관 9: 자신이 맡은 개발과 관련된 비즈니스를 이해하지 않는다.개발자는 개발에만 신경 쓰면 된다고 생각한다. 지금 개발하고 있는 서비스의 비즈니스적 관점은 생각해 본 적 없다. 어차피 기획자나 마케터, 프로덕트 매니저가 신경 써야 할 일이라고 생각한다. 개발만으로도 바쁜데 그것까지 신경 쓰면 정말 골치 아파진다.습관 10: 개발에 대한 지신만의 장기적인 목표가 없다.어떤 개발자가 되어야 하는지에 대한 목표가 없다. 주어진 프로젝트 외에 자신이 하고 싶은 프로젝트를 하면서 개발을 발전시키지 않는다. 그냥 개발의 메인 스트림을 따라만 간다. 커리어나 다른 생활에 대한 걱정은 종종 하지만, 개발 자체에 대한 고민은 하지 않는다.습관 11: 자신의 나쁜 개발 습관에 관심이 없다.(습관은 아니지만....)내가 나쁜 개발자라고...? 내가 하고 있는 것들이 나쁜 습관들이라고??? 글쎄..... 그냥저냥 잘 하고 있는 거 같은데.... 라고 생각하는 당신! 아무리 좋은 개발자라도 나쁜 습관은 존재하기 마련이다. 좋은 개발자는 좋은 습관들을 가지고 있는 개발자기도 하지만, 나쁜 습관들이 많지 않은 개발자이기도 하다.나쁜 환경은 나쁜 개발자를 만든다.당신이 만약 스스로를 나쁜 개발자라고 생각한다면 아마 '나쁜' 환경에서 개발을 했을 가능성이 크다. 혹은 선배가 나쁜 개발자여서 그 습관을 그대로 보고 배웠다든지, 아니면 좋은 개발자에 대한 고민 없이 흘러가듯 개발을 배웠을 것이다. 예를 들어, 코드 리뷰를 하지 않았던 것은 회사에서 코드 리뷰를 안 했을 가능성이 크다. 혹은 문서화를 안 하는 경우, 그 회사에서 그것에 대해 크게 신경 쓰기 있지 않을 가능성이 크다.Bad developers are not born, but created.위에서도 언급했듯이 나쁜 개발자는 없다. 나쁜 습관들이 있을 뿐. 당신이 지금 위의 습관에서 많은 부분들이 해당된다 하더라도, 그 습관들을 바꾸면 된다. 다른 개발자들에게 있는 좋은 습관들을 보고 배우면서 자신에게 해당되는 나쁜 습관들을 하나씩 바꿔나가는 것이다.환경이 바뀐다고 자신이 바뀌지는 않겠지만, 나쁜 환경이 나쁜 개발자를 만드는 것처럼, 좋은 환경은 좋은 개발자를 만든다. 좋은 환경을 찾아가라! 직장이 그걸 주지 못한다면 다른 곳에서라도 찾아라. 좋은 개발자는 나쁜 습관들을 하나씩 바꿔나갈 때 될 수 있을 것이다. 다음 포스팅에서는 좋은 개발자가 되기 위해 필요한 정보들을 압축적으로 모아 포스팅할 것이다.

올라왔었던 REST 아키텍처를 훌륭하게 적용하기 위한 몇 가지 디자인 팁의 글에서 언급되지 않았던 추가적인 내용에 대해서 좀 더 얘기해보고자 합니다. 혹시 이전 포스팅을 읽지 않으셨다면 이전 포스팅을 먼저 읽으신 후 이 포스팅을 읽어주시기 바랍니다.Document?컬렉션에 관해서는 앞서 소개한 이전 글에서 자세히 설명해놓았으니 읽어보시기 바랍니다. 지금 제가 언급할 것을 도큐먼트인데요. 도큐먼트는 컬렉션과는 달리 단수명사나 명사의 조합으로 표현되어 URI에 나타납니다.http://api.soccer.restapi.org/leagues/seattle/teams/trebuchet/players/claudio 위의 예제에서 leauges라는 컬렉션 리소스가 있는 것을 알 수 있습니다. 그 컬렉션의 자식 리소스 중 하나가 seattle이라는 리소스인데요, 바로 이 리소스가 도큐먼트입니다. 도큐먼트는 하위 계층으로 또 컬렉션을 가질 수 있습니다. 이 예제에서의 teams가 seattle의 자식 컬렉션 리소스가 되겠지요. 즉, 단수 리소스는 도큐먼트라 칭하고 복수 리소스는 컬렉션으로 칭한다고 알아두시면 됩니다.이 URI는 또한 문서의 계층 구조를 표현하고 있습니다. 즉 슬래시 기호(/) 다음으로 나타내는 명사가 그 앞에 나오는 명사의 자식 계층이 되는 것이지요. 이러한 도큐먼트의 응답으로써, 요청에서 명시된 Content-Type 헤더에 1:1대응하는 응답을 주는 것이 의미 있을 때가 있습니다. 가령,URI : dogs/1 1) Content-Type: application/json 2) Content-Type: application/xml 3) Content-Type: application/png 이와 같은 URI에 3개의 요청이 주어졌고, 각각 Content-Type이 다음과 같을 때 어떤 응답이 보내져야 할까요? 물론, 그것은 응답을 설계한 사람의 맘이지만 일반적인 기준을 적용해본다면 1번과 2번 요청에는 각각 json, xml 형식으로 구조화된 데이터가 그리고 3번 요청에 대해서는 해당 강아지의 사진이 담긴 png 파일을 보낼 수 있을 것입니다. 또한, Content-Type에 대해서 명시하여 원하는 리소스를 선택할 수 있으므로 URI 내에는 파일 확장자를 포함하지 않는 것이 좋습니다.dogs/1.xml 위와 같은 URI를 만드는 것보다, dogs/1 위의 URI에 Content-Type: application/xml헤더를 포함하여 요청을 보내는 것이 더 적절한 선택입니다. 어째서 파일에 확장자를 붙이지 않는 것이 더 나은 선택일까요? URI는 고유한 리소스를 나타내는 데 쓰여야 합니다. 그런데 URI에 확장자를 붙이는 순간 마치 다른 리소스인 것처럼 느껴집니다. 확장자를 달리하여 같은 리소스에 대한 다른 표현 양식을 주문하는 것이지 해당 리소스가 달라지는 것은 아닙니다. 또한, URI에 직접 확장자가 붙게 되면 해당 리소스 URI가 응답으로 지원하는 확장자만큼 새로운 URI들이 생기게 되겠지요. 결코, 이것은 좋은 디자인이 아닙니다.Controller?기본으로 GET, PUT, POST, DELETE 요청에 1:1매치 되는 개념인 CRUD가 있습니다. CRUD의 앞글자들을 풀어보면 Create, Read, Update, Delete가 될 텐데, 각각 POST, GET, PUT, DELETE에 대응되는 개념입니다. 그런데 사실 URI를 디자인 하다 보면 이러한 방식으로 나타내기 참 어려운 경우를 많이 만나게 됩니다. 그 중 가장 많은 경우가 어떤 특정한 행위를 요청하는 경우입니다. 많은 분이 이럴 때 동사를 쓰는데, 앞선 포스팅에서 밝혔듯이 동사를 써서 URI를 디자인하는 것은 대체로 옳지 않은 방식으로 여겨집니다.이럴 때 컨트롤러 리소스를 정의하여 이 문제를 해결할 수 있습니다. 컨트롤러 리소스는 URI 경로의 제일 마지막 부분에 동사의 형태로 표시되어 해당 URI를 통해 접근했을 때 일어날 행위를 생성합니다. (개념적으로는 이렇게 받아들이시면 됩니다.) 생성과 관련된 요청이 POST이기 때문에 컨트롤러 리소스에 접근하려면 POST 요청을 보내야 합니다. 예제를 살펴보시면 이해하기 빠르실 겁니다.http://api.college.restapi.org/students/morgan/register 리소스 morgan을 등록 http://api.ognom.restapi.org/dbs/reindex 리소스 dbs를 재색인 http://api.build.restapi.org/qa/nightly/runTestSuite 리소스 nightly에 테스트를 수행 그리고 마치 프로그램의 함수처럼 컨트롤러 리소스에는 입력값을 전달할 수 있습니다. 그것은 POST 요청의 엔티티 바디에 포함되어야 합니다. 그리고 역시 함수에서 반환값을 돌려주듯이 컨트롤러 리소스에서는 해당 입력 값에 대한 응답 값을 돌려주면 되겠습니다.URI 뒤에 붙는 쿼리의 용도흔히 GET 요청을 보낼 때 뒤에 추가로 쿼리 스트링(?,=,& 기호를 이용하여)을 전달하곤 합니다. 여기서는 그 쿼리 스트링을 어떻게 디자인 하는 게 좋은지에 대한 논의와 함께 실제 서비스에서 사용되는 사례를 살펴봅니다.가령 특정 컬렉션 리소스에 대하여 질의를 보낼 때 그 컬렉션의 집합이 너무 거대할 수 있으므로 필요한 정도의 정보만을 요구하기 위해서 페이징 값 혹은 구분 값을 쿼리 스트링에 포함할 수 있습니다. 예를 들어 보면/resources?pageSize=10&pageStartIndex=0 페이징을 위한 정보 전달 /dogs?color=red&state=running&location=park 구체적인 검색 제약사항 전달 이런 식으로 써서 페이징을 한다든가 혹은 다른 파라메터(color=red)따위를 던져서 검색 범위를 제한할 수 있습니다. 흔히 쿼리 스트링을 저런 용도로 많이 사용하기 때문에 아마 관찰력이 좋으신 분들은 저런 종류의 쿼리 파라메터를 네이버, 구글 같은 포털사이트의 검색 서비스를 이용하시면서 본 적이 있으실 것입니다.이와는 약간 다르게 실제 DB에서 사용하는 SQL의 select 문과 같은 결과를 낼 수 있도록 돕는 쿼리 스트링을 URI에 나타내려는 시도도 많은 편인데요. 물론 SQL에서 제공하는 구문의 모든 의미를 다 제공할 필요는 없겠지만, 기본적으로 서비스에서 필요한 정도의 인터페이스를 적절히 제공한다면 사용자가 선택할 수 있는 옵션이 많아진다는 측면에서 좋은 방법이겠죠. 이와 관련된 예제를 몇 개 소개하겠습니다. 이것은 실제 서비스에서 API로 제공되었던 URI들입니다. 구조나 의미가 SQL 문과 상당히 유사합니다.LinkedIn /people:(id,first-name,last-name,industry) 이 경우 people 리소스를 요청하되 마치 SQL 쿼리에서 가져올 필드를 제한하는 것처럼 필요한 필드에 대해서만 괄호로 묶어서 지정한 것을 볼 수 있습니다. Facebook /joe.smith/friends?fields=id,name,picture 이 경우 이름(혹은 계정이름)이 joe.smith인 사람의 정보를 가져오되 LinkedIn의 예와 같이 필드를 제한(id,name,picture)해서 가져오도록 한 예입니다. Google ?fields=title,media:group(media:thumbnail) 구글도 마찬가지네요. 이쯤 오면 대략 저 URI가 무엇을 의미하는지 알아채셨으리라 생각합니다. URI 설계시에 주의해야 할 점URI에는 소문자를 사용해야 합니다. 왜냐하면, RFC 3986은 URI 스키마와 호스트를 제외하고는 대소문자를 구별하도록 규정하기 때문이지요.http://api.example.restapi.org/my-folder/my-doc HTTP://API.EXAMPLE.RESTAPI.ORG/my-folder/my-doc 위의 두 URI는 같은 URI입니다. 호스트에서는 대소문자를 구별하지 않기 때문이지요. http://api.example.restapi.org/my-folder/my-doc http://api.example.restapi.org/My-Folder/my-doc 하지만 위의 두 URI는 다른 URI입니다. 뒤에 붙는 path가 대소문자로 구분되기 때문입니다. 물론 소문자가 아닌, 대소문자를 섞어 쓰거나 혹은 대문자만 쓰는 것도 가능하지 않으냐는 반론이 나올 수 있습니다. 하지만 대소문자를 섞어 쓰면 URI를 기억하기 어려울 뿐만 아니라 실제 사용 시 실수하기 쉽다는 단점이 있습니다. 만약 대문자만 쓴다면 상관은 없겠으나 일반적으로는 URI에 대문자를 잘 쓰지 않기 때문에 소문자로 쓰는 것을 권장합니다.HTTP HEADERHTTP 요청과 응답을 보낼 때 특정 헤더를 포함해 요청, 응답 그리고 리소스에 대한 메타 정보를 전달할 수 있습니다. 요청 헤더와 응답 헤더에 포함되면 좋을 만한 헤더 정보들에 대하여 알아보겠습니다.요청 헤더Accept응답으로 받고 싶은 미디어 타입을 명시하기 위하여 사용됩니다. 예제를 들어 설명하겠습니다.GET /magna-opus HTTP/1.1 Host: example.org Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 이 요청은 mangna-opus 리소스에 대해서 기본적으로는 html이나 xhtml의 형식으로 응답을 받고 싶되, 만약 상황이 여의치 않으면 xml을 만약 그것도 여의치 않다면 모든 응답(*/*)을 받아들이겠다는 것을 말합니다. 옆에 붙은 q가 선호도를 나타내게 되지요. (q 생략 시 1값을 가짐) 만약 앞의 예에서 모든 응답에 대한 표시가 없다고 가정하고 서버에서 앞의 세 가지 미디어 타입을 모두 지원할 수 없는 상황이라면 응답으로 406 상태코드를 내보내야 합니다.Accept-Charset응답으로 받고 싶은 캐릭터셋에 대하여 명시하는 헤더입니다.Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 가령 위의 예제는 일단 iso-8859-5를 선호하지만 unicode-1-1도 괜찮다는 메시지를 전달합니다.User-Agent현재 요청을 보낸 Agent의 정보를 표시하기 위해 사용됩니다.User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/21.0 파이어폭스 버전 21.0의 UA스트링, OS에 대한 정보도 담겨져있다. Referer해당 요청을 보내기 바로 직전에 참조하던 리소스 혹은 주소에 대한 정보를 나타내기 위해 사용합니다.Referer: http://en.wikipedia.org/wiki/Main_Page 응답 헤더Content-Length요청과 응답 메시지의 엔티티 바디가 얼마나 큰지에 대한 정보를 나타내기 위해 사용합니다. 단위는 바이트입니다.Content-Length: 348 Last-Modified해당 리소스가 마지막으로 갱신된 시간을 나타내기 위하여 사용됩니다. 캐싱 정책과 관련되어 중요한 헤더중 하나입니다.Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT 캐시나 쿠키정책과 관련된 헤더 정보는 글의 분량을 고려하여 생략하였지만, 매우 중요한 헤더 중 하나이므로 다른 관련 문서들을 검색하여 일독을 권합니다.HTTP 상태 코드의미에 잘 맞는 URI를 설계하는 것도 중요한 일이지만 그 리소스에 대한 응답을 잘 내어주는 것 또한 중요한 일입니다. 그런데 혹시 HTTP의 상태코드 중 200이나 404코드 정도만 알고 계시지 않으신가요? 그 코드의 정확한 의미를 얘기하실 수 있으신가요? 사실 저도 흔하게 볼 수 있는 상태코드 몇 개 정도만 알고 있고 나머지 상태코드의 정확한 의미라든지 쓰임새에는 관심이 별로 없었던 것이 사실이었습니다. 하지만 전문적으로 웹 개발의 길을 걸어갈 사람이라면 그보다는 좀 더 자세히, 많이 알고 있을 필요가 있겠지요. 사실 우리가 생각하는 것보다 훨씬 많은 상태코드가 존재하고 각각 그 쓰임이 다 다릅니다. 그 중 몇 개를 살펴보겠습니다.200 : OK일반적인 요청 성공을 나타내는 데 사용합니다. 단, 주의해야 할 점이 있다면 200코드를 에러 응답에 사용하면 안 된다는 것입니다. 가령 코드는 200인데 에러메시지를 포함한다든가 하면 의미에 맞지 않은 응답코드를 보낸 것이겠지요. 이런 적절치 못한 상황을 처리하는 경우에는 4XX대 코드를 사용하여야 합니다.201 : Created리소스 생성 성공에 대한 응답 코드입니다. CRUD 요청에서 Create 요청에 대한(즉, 컬렉션에 도큐먼트 추가 같은) 응답으로 내보낼 수 있는 응답코드입니다. 응답 헤더의 Location 필드에 생성된 리소스에 접근할 수 있는 URI를 포함할 수 있다면 브라우저에서 그 값을 참조하여 적절히 대응할 수 있겠습니다.202 : Accepted대체로 처리 시간이 오래 걸리는 비동기 요청에 대한 응답으로 사용됩니다. 즉, 이 요청에 대한 응답이 결과를 포함하지 않을 수 있다는 것이죠. 하지만 최소한 응답 헤더나 응답데이터에 해당 처리를 모니터링할 수 있는 리소스 페이지를 안내하거나 혹은 해당 리소스가 처리되기까지의 예상 경과 시간 따위를 안내하는 것이 더 좋은 설계라고 할 수 있겠습니다.301 : Moved Permanently리소스가 이동되었을 경우의 응답코드입니다. 새로 리소스가 이동된 URI를 응답 Location 헤더에 명시해야 합니다. 이 응답을 받은 클라이언트는 새 URI로 이동하든지 아니면 URI를 갱신하고 캐싱을 한다든지 하는 행위를 해야 되겠지요.400 : Bad Request일반적인 요청실패에 사용합니다. 대체로 서버가 이해할 수 없는 형식의 요청이 왔을 때 응답하기 위해 사용됩니다. 무턱대고 400에러를 응답으로 주지 말고, 다른 4XX대의 코드가 더 의미를 잘 설명할 수 있는지에 대하여 고민해야 합니다.401 : Unauthorized말 그대로 리소스 접근 권한을 가지고 있지 않다는 것을 의미하기 위한 응답코드입니다. 리소스를 획득하기 위하여 요청자는 인증에 필요한 헤더(가령 Authorization 헤더 같은)나 데이터를 첨부해야 할 것입니다. 필요한 헤더나 데이터는 서버 쪽에서 요구하는 스펙을 충실히 따라야겠지요.403 : Forbidden감춰진 리소스에 접근하려 할 때의 응답코드입니다. 401과 달리 인증의 여부와 관계없이 리소스를 보여주지 않습니다. 기본적으로 클라이언트 쪽에 정보를 공개하고 싶지 않은 리소스임을 나타내기 위해 사용합니다.404 : Not Found해당 URI와 매치되는 리소스가 없다는 의미를 전달합니다. 어지간한 사람들은 다 한 번씩(?) 마주치게 되는 응답코드이지요.405 : Method Not Allowed지원하지 않는 요청(예를 들어 POST 요청을 받는 컨트롤러 리소스에 GET 요청을 보낸다든가)을 하였을 때 사용합니다. 가능하다면 응답 메시지에 Allow 헤더를 추가하고 그곳에 지원하는 메서드를 명시하여 클라이언트 측에서 정확한 요청을 보낼 수 있도록 유도합니다.Allow: GET, POST 406 : Not Acceptable해당 미디어 타입(MIME 타입)에 대해서 지원하지 않을 때 사용합니다. 요청 Accept 헤더에 명기된 타입(가령 Application/xml)에 대해서 지원이 불가능할 경우에 돌려주면 되는 코드입니다.409 : Conflict요청의 형식에는 문제가 없지만 리소스 상태에 의하여 해당 요청 자체를 수행할 수 없는 경우의 응답코드입니다. 즉, 이미 삭제된 리소스를 또 삭제한다든가 비어있는 리스트에서 무언가를 요청한다든가 하는 모순된 상황을 생각해보면 되겠습니다. 응답으로는 그 방법을 어떻게 해결할 수 있을지에(혹은 문제가 무엇인지) 대한 힌트가 포함되면 좋을 것입니다.500 : Internal Server Error일반적인 서버 에러에 대한 응답코드입니다. 4XX대의 에러코드가 클라이언트 측 에러를 나타내기 위해 사용된다면, 5XX대의 에러코드는 서버 측 에러를 나타내기 위해 사용됩니다.503 : Service Unavailable가장 두려운(?) 응답코드 중 하나일 503입니다. 현재 서버에 과부하가 걸려있거나 유지보수를 위하여 잠시 접근이 거부될 때 필요한 응답코드입니다.그냥 맨 앞의 숫자별로 퉁쳐서 상태코드를 내보내지 않고, 이렇게 디테일한 의미까지 따져가면서 상태코드를 내보내는 것에 대해서 그 효용성에 의문을 제기하시는 분들이 있을 것 같습니다. 하지만 브라우저에서 혹은 서버 단에서 특정 상태코드에 대해서 내부 구현을 달리하거나 최적화를 통해 더 쾌적한 환경을 제공할 가능성이 있으므로 되도록 의미에 걸맞은 상태코드를 사용하는 것을 생활화하는 것이 중요합니다. 또한, 이렇게 디테일한 상황을 가정하고 만든 URI들이 다음에 서비스를 확장할 때 큰 도움이 될 것임은 의심할 여지가 없겠지요.위에서 소개한 응답 코드 말고 또 다른 응답 코드들에 대해서도 전부 소개해 놓은 링크를 밑에 달아두었으니 참고하시기 바랍니다.정리지금까지 소개한 내용이 조금은 두서없게 느껴졌을 수도 있겠다는 생각이 들어 한 번 전체 내용 정리를 해보려 합니다.컨트롤러의 정확한 쓰임을 알고 적절한 컨트롤러 URI를 구현하자.URI에 추가로 붙게 되는 쿼리 스트링의 형식을 잘 디자인하여 사용자로 하여금 적재적소에 쓸 수 있도록 하자.가능하다면 이용 가능한 HTTP 헤더를 적절하게 첨가하자.HTTP 상태코드의 의미에 대해서 생각해보고 상황에 맞는 적절한 상태 코드를 응답으로 보내줄 수 있도록 하자.이 글을 쓰면서 한빛 미디어의 일관성 있는 웹 서비스 인터페이스 설계를 위한 REST API 디자인 규칙과 apigee사의 web API design eBook을 참고하였습니다. 둘 다 내용이 좋은 서적이고 이 글에서 다루지 않은 심층 내용을 다루니 기회가 되시면 읽어보세요.referencesUniform resource identifierapigee api design best practicesrestful uri designHTTP status codesList of HTTP status codesURI schemeMIME typesMIMEfun and unusual http response headers#스포카 #디자인 #디자이너 #디자인팀 #개발 #개발자 #개발팀 #협업 #코워킹 #Co-working #업무프로세스 #꿀팁 #인사이트

'마크업 개발자', 아직은 우리들에게 다소 생소한 직군이죠. '마크업 개발자'는 디자이너와 개발자 사이에서 '오작교' 같은 역할을 하는 아주 중요한 포지션이에요. 오늘은 코인원의 마크업 개발자로 활약 중인 혜진님과 이야기를 나눠보려 해요. 자신의 위치에서 묵묵히 유저 친화적인 웹 환경을 만들어나가고 있는 혜진님을 만나러 가보시죠!사실 이미 혜진님은 지난 4월 13일(토), 테크 업계 여성들의 목소리에 집중하는 소중한 행사 ‘Women Techmakers Seoul 2019’에서 ‘스타트업에서 마크업 개발자로 살아남기’를 주제로 자신의 이야기를 널리 알리고 왔답니다. 스타트업 그리고 코인원에서 마크업 개발자로 살아남는 혜진님만의 방법은 무엇일까요? :-)Q. 혜진님 안녕하세요, 자기소개 부탁드립니다.안녕하세요, 코인원 유저플로우셀에서 마크업 개발자로 일하고 있는 오혜진입니다. 유저플로우셀은 암호화폐 거래와 프로차트와 같은 트레이딩 영역을 제외한 전반적인 서비스 영역을 담당하고 있어요. 특히 ‘셀'이라는 목적조직으로 개편된 이후 PM, 디자이너, 개발자가 한곳에 모여 누구나 코인원에서 거래를 하고 싶은 마음이 들도록 매력적인 곳으로 탄생시키고 있답니다. 저는 셀안에서 마크업 개발자로 일하며 디자이너와 프론트엔드 개발자를 이어주는 다리 역할을 하고 있습니다.Q. 지난 ‘Women Techmakers Seoul 2019’에서 마크업 개발자를 널리 알리는 발표를 했다고 들었어요. 어떤 내용인지 소개해주세요!감사하게도 ‘스타트업에서 마크업 개발자로 살아남기' 라는 주제로 300명이 넘는 관중들 앞에서 발표를 하고 왔습니다. (사실, 많은 분들이 와주셔서 땀이 좀 나기도 했고요;) 마크업 개발자는 스타트업에서 발견하기 힘든 직군이기도 해요. 보통은 웹 에이전시에 많이 속해 있거든요. 제가 마크업 개발자로 일한지 6년이라는 시간 동안 스타트업에서 어떤 방식으로 일해왔는지 알리고 싶었어요. 그래서 지금까지 이런 일들을 해왔고, 앞으로도 더 활발하게 할 것이라고 속시원하게 말하고 왔습니다.Q. 마크업 개발자는 구체적으로 어떤일들을 하나요?마크업 개발자는 한마디로 디자인(Design)과 기술(Tech)의 오작교 같은 존재입니다. 디자인의 의도가 개발과 충돌하는 부분은 없는지 파악하고, 개발에 잘 녹아들 수 있도록 프론트엔드의 앞단을 맡고 있어요. 코인원 웹 서비스에서 제공하는 신규 기능의 마크업 개발을 담당하고, 운영하면서 생긴 이슈들을 처리합니다. 또한 마크업 레거시에 대한 유지보수 작업도 병행하죠.예를 들어, 코인원의 회원가입 페이지를 제작할 때 디자인 작업을 먼저 들어갑니다. 그럼 디자인 작업을 바탕으로 개발자들이 기능을 만들어 넣게 돼요. 이 때, 기능적인 개발을 제외하고 UI(User Interface)적인 부분을 제가 담당합니다. 회원가입 페이지에는 이메일 인증, 휴대폰 인증 등 여러가지 개발요소들이 많아요. 그래서 개발하기 전에 기능이 들어가는 기본적인 레이아웃을 만들어 개발자에게 전달합니다. 마크업 작업이 바탕이 되어 그 위에 기능 개발이 이뤄진다고 보시면 돼요.디자이너가 레시피를 만드는 사람이라면, 마크업 개발자는 레시피 재료를 세팅해 주는 사람이에요. 개발자들은 세팅된 레시피를 끓이고 버무려 요리를 완성시키고요. 저는 좋은 요리가 탄생할 수 있도록 중간과정을 도와주는 역할인거죠. ▲ 'Women Tachmakers 2019'에서 발표에 열중한 혜진님!Q. 디자인과 기술의 중간 역할을 담당하고 계시군요, 사실 중간자의 역할이라고 하면 이어주는 과정에서 고충(?)이 생길 것 같아요.아무래도 디자이너와 개발자, 양쪽과 다 소통해야하는 부분입니다. 디자이너 입장에서는 ‘왜 프론트엔드에서 이 디자인이 안되는걸까?’ 라는 불만이 생길때도 있고, 프론트엔드에서는 ‘왜 디자인이 이렇게 들어가야 하는걸까?’ 라고 이해를 못할 때도 있어요. 서로의 이해관계를 잘 전달해야 한다는 점이 나름의 고충이죠. 코인원에서는 ‘디자이너 - 마크업 개발자 - 프론트 개발자’의 협업 프로세스를 정립해서 각자가 맡은 분야에 집중 할 수 있는 초석을 다졌어요. 무엇보다도 배경이 다른 세 개의 직군이 원활하게 소통할 수 있는 체계가 잡혀 고충이 해결되고 있습니다 :) Q. 그렇다면 마크업 개발자는 어떤 부분을 기여한다고 볼 수 있나요?코인원 메인 화면에 기능 개발을 추가하지 않고도 마크업단에서의 처리만으로도 쉽게 변화를 줄 수 있습니다. 메인화면의 배너 이미지는 유저들이 코인원에 접속해 제일 먼저 마주하는 부분이죠. 그래서 유저들이 코인원의 시각화된 정보를 빠르게 접할 수 있도록 이미지를 교체합니다. 웹 페이지의 운영 측면에서 비주얼 개편을 빠르게 할 수 있는 환경을 만들어 놓고 대응하는거에요.곧 코인원 마이페이지 화면이 개편될겁니다. 웹 페이지를 새로 만든다는 것은 무에서 유를 창조하는 과정과 같아요. 제가 마크업 개발을 잘 해놓으면 다른 직군에게도 도움이 됩니다. 개발 속도도 더 잘 붙고, 디자인에서도 빈공간이 없는 페이지가 탄생하는거죠. 최대한 밑바탕을 꼼꼼하게 만들어 모두가 일에 더 집중할 수 있는 환경을 만든다고 보시면 돼요.Q. 코인원 마이페이지에서 새롭게 바뀌는 부분은?기존의 마이페이지는 유저들이 보기에 정리가 잘 안되어있다는 느낌이 있었어요. 어떤 인증과정을 끝마쳐야 하는지 한눈에 들어오지 않는 부분이 있었거든요. 이번에 개편될 마이페이지는 좀 더 명확해졌습니다. 이전의 인증페이지가 도돌이표의 느낌이었다면, 이번에는 UX(User experience)를 생각해서 flow 개선도 많이 이뤄졌습니다. 편리한 암호화폐 거래 경험을 코인원에서 느낄 수 있어요. (새롭게 바뀔 마이페이지 많은 기대 부탁드립니다! 물론 편리한 암호화폐 거래도 언제나 코인원!)Q. 유저들에게 편리한 거래경험을 선사하기 위해 어떤 가치를 가장 중요시 여기나요? 저는 중간자이므로 유저들 뿐만 아니라 개발까지 두 가지 측면을 모두 고려합니다. 유저의 입장에서 사용성과 접근성이 용이한 마크업을 짜려고 하고, 개발측면에서는 유지보수가 편리한 마크업을 최대한 짜려고 해요. 개발하기 편한것과 사용하기 편한 것은 다른 맥락이거든요. 요새는 코인원 디자인시스템을 적용하고 있어요. 디자이너 분들이 정리해주신 디자인 시스템을 잘 적용시켜서 코드적으로도 재사용성이 용이하게 관리가 되도록 하고, UI도 정돈이 되어가는 과정을 진행 중입니다. 이런 과정을 계속 거치면 유저들에게 편리한 거래 경험을 선사하는 부분은 놓치지 않을 것 같아요.▲ 마크업에 열중하고 있는 혜진님 (약간의 설정샷 +_+)Q. 코인원 크루로 일하면서 장점을 뽑자면?유저플로우셀은 코인원이 셀이라는 목적조직으로 개편되고나서 만족도가 높은 셀이라고 알고 있어요. 업무도 많은 편인데, 톱니바퀴처럼 잘 맞물린다는 느낌이거든요. 특히 일에 대해서 선긋지 않고, 이슈가 발생했을 때 해결할 수 있는 부분들을 빠르게 파악해주는 부분들이 정말 좋아요. 속도랑 효율성 측면에서 이만큼 해낼 수 있는 팀은 앞으로 만나지 못할 것 같아요. 항상 원활한 업무 소통을 위해 힘써주시는 셀원들에게 감사 드립니다!Q. 앞으로 이루고 싶은 목표가 무엇인가요?회사 안 뿐만 아니라, 바깥에서의 활동도 꿈꾸고 있어요. 마크업 개발자들이 모두 모여 이야기할 수 있는 CSS 컨퍼런스를 열어 좀 더 커뮤니티를 활성화 시키고 영향력을 높이고 싶습니다. 아직 마크업 개발자들만이 모여서 이야기 할 수 있는 곳이 부족하거든요. 저의 이야기도 차곡차곡 쌓아서 여러 창구를 통해 들려드리고 싶고요.코인원에서는 지금 하는 것 이상으로 마크업 개발도 열심히 할거에요. 우선 단기적인 목표로, 프론트엔드에서 사용하고 있는 angular에 대한 이해력을 높일 겁니다. 마크업 컴포넌트 단위에 최적화 된 CSS로 개편해서 사용하지 않는 스타일 리소스가 최소화가 되도록 만들거에요.▲ 마크업 개발자에 많은 관심 부탁드려요 :)디자이너가 디자인에 집중할 수 있게, 개발자가 개발에 집중할 수 있게 ‘일잘러’로 통한다는 혜진님. 혜진님의 인터뷰를 통해 ‘마크업 개발자’에 좀 더 친해지는 시간이길 바라봅니다. 그리고 이렇게 멋진 코인원 크루와 함께 성장하고 싶지 않으세요?  현재 코인원은 멋진 크루들과 함께 크립토갤럭시를 헤쳐나갈 분들을 기다리고 있습니다 :-)

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]브랜디, 오직 예쁜 옷만#브랜디 #개발자 #개발팀 #인사이트 #경험공유 #주니어개발자

웹서비스에서 나만의 서비스 이용내역과 개인정보를 확인할 수 있는 공간을 ‘마이페이지'라고 하죠. 유저들은 마이페이지를 통해 나의 상태를 체크하며 해당 서비스에 좀 더 애착을 갖기도 합니다. 이번에 코인원 마이페이지도 더욱 더 새로워지면서 애정이 가득해졌다는 유저들의 제보가 속속 들어오고 있어요!오늘은 코인원 마이페이지를 새롭게 탄생시킨 유저플로우셀 예은님, 정유님, 현진님, 종헌님과 함께 마이페이지의 모든 것을 파헤쳐보겠습니다.코인원 유저플로우셀은 트레이딩 영역을 제외한 전반적인 서비스 영역을 담당하고 있습니다. 각 서비스에 대한 유저 경로 동선을 만들고 서비스를 제공하며, 누구나 거래를 하고 싶은 코인원을 만들고 있답니다. :-)Q. 안녕하세요, 유저플로우셀 여러분. 자기소개와 함께 현재 업무를 소개해주세요!예은 : 유저플로우셀에서 서비스 기획자로 일하고 있는 지예은입니다. 저는 코인원 유저들이 겪는 문제상황과 UX트렌드 분석을 통해 기존의 서비스를 개선하고 고도화하고 있어요.정유 : 프로덕트 디자이너로 일하고 있는 이정유입니다. 유저플로우셀은 유저와 거래소를 이어주는 모든 페이지를 담당하고 있어요. 저는 기획자들과 함께 유저의 니즈를 페이지에 UI(User Interface)적으로 어떻게 반영할지 고민하고, 이를 디자인 시스템에 녹여 시각적 일관성을 전달합니다.  현진 : 프론트엔드 개발자로 불철주야 개발 중인 박현진입니다. 프론트엔드는 한마디로 코인원 프로덕트에서 실제로 유저들에게 보여지는 웹화면이에요. 저는 유저들에게 보이는 영역을 책임지며 프로그래밍하고 있습니다.종헌 : 웹 API를 담당하고 있는 백엔드 개발자 김종헌입니다. 프론트엔드가 유저에게 보이는 영역을 담당한다면, 저는 보이지 않는 곳인 백엔드에서 입출금 서비스, 거래기록, 개인정보 등 코인원의 다양한 서비스와 유저를 연결하고 있어요.Q. 이번에 마이페이지 개선이 대대적으로 진행되었습니다. 어떤 계기와 방향성으로 개선하게 되었나요?예은 :  마이페이지 개선은 유저의 고충을 파악하기 위한 코인원 고객센터 인터뷰에서 시작되었습니다. 거래소 이용에 필요한 인증, 계정 보안에 대한 관리가 익숙하지 않은 유저들의 ‘페인 포인트(Pain Point)’를 발견했거든요. 서비스 기획자, 디자이너, 개발자가 함께 모여 UI나 정보로 사용자에게 도움을 주고 CS비용을 최소화 할 수 있는 방법을 고민하기 시작했습니다. 우선, ‘마이페이지'는 코인원 서비스를 이용하는 유저 개개인을 챙겨주는 공간이라고 생각합니다. 이번 개선 과정에서 가장 중점을 둔 부분도 ‘고객을 챙겨주는 마이페이지' 경험을 전달하는 것이었어요. 이렇게 설정된 방향성에 따라 유저들의 상태별로 필요한 상황을 안내하도록 구성했습니다. 한마디로 ‘유저 맞춤형 마이페이지’로 진화한겁니다!▲ 더욱 더 새로워진 코인원 마이페이지정유 : 이전의 마이페이지는 엉켜있는 플로우로 인해, 유저가 어떤 상태인지, 어떤 인증과정을 거치고 있는지 인지하기가 힘들었습니다. 목적을 달성하기 위해 마이페이지에 접속했지만 목적 달성을 끝마칠 수 없었죠. 먼저 흩어져 있는 기능, 정보, 구조들을 그룹핑하며 플로우를 개선하는 작업을 시작했어요. 아이데이션 과정을 거치면서 마이페이지를 ‘내 서랍, 내 방' 등 나만의 정체성을 확인할 수 있는 키워드로 정의했습니다. 그리고 키워드를 확장시켜 ‘나의 데이터'를 한 눈에 관리할 수 있는 대시보드 형태의 디자인을 지향하게 되었어요. 결과적으로 현재 마이페이지에는 나의활동, 개인정보관리, 인증단계 총 3 개의 탭으로 위계를 설정했습니다. :D▲ 코인원 거래소 인증단계가 훨씬 간편해졌습니다!Q. 기술적으로는 어떤 변화가 있었을까요?현진 : 마이페이지를 포함해서 코인원 웹 프로덕트에 기술부채(Technical Debt)가 조금씩 쌓여 있었어요. 이 부분을 덜어내기 위해 마이페이지를 개선하면서 ‘기획/디자인/개발’ 삼박자로 변화를 주는 리빌딩(Re-building)을 진행했습니다. 덕분에 기술적으로 관리 포인트가 많이 줄었어요. 이제는 웹 유지/보수가 좀 더 용이하게 되었답니다.종헌 : 그 동안 코인원 웹은 하나의 비대한 서비스로 운영되었습니다. 하나의 서비스가 덩치가 점점 커지다 보니 개발자가 서비스 로직을 온전히 이해하기 어려웠어요. 웹을 유지하고 보수하거나, 새로운 기능을 추가하는 것도 쉽지 않았습니다. 그래서 하나의 비대한 서비스를 여러 개의 작은 서비스로 나누는 작업인 리빌딩을 진행했어요. 여러 작은 서비스로 분리하고 책임 영역을 나누면서 서비스 로직에 대해 제대로 이해하고 체계적으로 코드를 작성할 수 있게 되었습니다.    Q. 마이페이지 개선 전과 후, 달라진 점을 말씀해주세요.예은 : 코인원 마이페이지는 이전보다 유저들에게 더욱 친근하게 다가가고 있습니다. 마이페이지의 콘텐츠가 유저의 상태에 맞춰 변화하며, 유저마다 다음 인증 과정이나 활동 내역을 다르게 안내합니다. 유저가 기능을 먼저 찾지 않아도, 마이페이지가 길을 찾아주는 가이드의 형태를 띄고 있어요.또한 인증단계 별로 수수료나 회원등급이 달라지는데, 유저들이 하나하나 가이드를 보며 찾아볼 수는 없다고 생각해요. 한눈에 자신의 상태를 파악할 수 있도록 UI를 활용하는 것이 중요한 부분이죠. 마이페이지의 개선된 UI로 유저가 코인원의 서비스 정책을 한층 더 깊게 이해하는데 도움이 되었으면 해요.정유 : 유저가 코인원 프로덕트와의 관계성을 인지할 수 있는 디테일들이 추가되었습니다. 가장 대표적인 예시로는 ‘코인원과 함께한 지 000일째 입니다.’라는 문구가 있겠네요. 코인원 유저들에게 ‘챙겨준다'라는 느낌을 전달하기 위해 정말 많은 회의와 아이데이션을 거쳤습니다. 그 과정 중 나왔던 아이디어인데 이번에 반영하게 되었어요. ‘제품’보다는 ‘서비스'로서 느껴질 수 있도록, 대화하는 느낌을 잘 살려주는 포인트이기에 매우 뿌듯했죠.▲ 심...심쿵....!!!!!현진 : 개발자 입장에서 바라봤을 때, 페이지 애니메이션이 가장 좋았어요. 페이지 애니메이션은 웹페이지가 다른 웹페이지로 이동할 때 발생하는 애니메이션을 말합니다. ‘툭' 하고 넘어가는 것이 아니라 ‘sha~(?)’ 하게 넘어가는 느낌이라고 할까요. 페이지와 페이지 사이가 하나의 관계성을 가지고 넘어가게 됩니다. 유저들은 ‘암호화폐 거래소에서 마이페이지에 이런 디테일한 부분까지 신경쓰고 있구나’를 느낄 수 있을거에요. 또한 에러메시지, 경고메시지와 같은 피드백 인터랙션도 정교해졌어요. 사용자와 교감할 수 있는 쪽에 코인원만의 감성이 잘 버무려졌습니다.종헌 : 이전의 코인원 프로필 서비스는 사용빈도가 높지는 않았어요. 그라바타(Gravatar)라는 외부서비스를 사용했는데, 이것을 사용하지 않는 유저들에게 친숙하지 않았거든요. 이제는 코인원에서 프로필 이미지를 정해두고 원하는 이미지로 클릭해서 쉽게 변경할 수 있게 설정했어요. 참고로 프로필 이미지를 설정하는 것이 보안측면에서도 좋습니다. 예를 들어, 은행에서는 프로필 이미지를 설정하면 바로 내가 사용하는 계정인지 아닌지를 알 수 있어요. 코인원에서도 프로필 이미지를 설정하면 내가 가입한 계정인지 아닌지 식별이 가능합니다.▲ 프로필 사진 설정 기능도 많이 이용해주세요 :)Q. 마이페이지의 개선 작업 과정에서 많은 고민이 있으셨을 것 같아요. 가장 중점적으로 생각했던 부분이 있었나요?정유 : 가장 중점이 되었던 부분은 서비스를 이용하는 유저 개개인의 상태를 반영하는거였어요. 유저별로 동일한 정보가 아닌 맞춤형 정보를 제공하기 때문에 한 페이지 안에 들어가는 정보의 위계가 상태값에 따라 계속 변하는 것이 관건이었습니다. 예를 들어, 마이페이지에는 나의 정보를 업데이트하기 위한 많은 버튼들이 들어갑니다. 그럼 유저 케이스별로 중요한 정보를 바꿔보면서 어떤 버튼이 가장 위계가 높은지 고민하고 계산해요. 이러한 과정을 거치면서 유저의 상태값을 쉽게 알려주고 변경할 수 있는 디자인이 완성되었습니다. 예은 : 기존부터 유저 인터뷰를 진행하며 ①신규 유저 ②타사 이용 유저 ③거래소 이용에 문제를 겪고 있는 유저 ④코인원을 오래 이용해준 고마운 유저 케이스까지 다양한 상황에 놓여있는 유저들에게 만족스러운 UX 경험을 드리기 위해 고민해왔습니다. 특히 운영지원셀과 코인원 고객센터 CS로 인입되는 주요 인터뷰들을 중점적으로 수집하여 인증과정에 문제가 되는 것들을 모아서 개선회의를 해왔어요. 이외에 마케팅, 프로덕트쪽도 함께 서비스를 제공하는 공급자 입장에서의 니즈도 취합해 마이페이지에 반영할 수 있었습니다.▲ (절대 설정샷 아니에요) 훈훈하게 회의중인 유저플로우셀!Q. 혹시 개선된 마이페이지를 이용한 코인원 고객들의 후기도 있었나요?예은 : 개선된 마이페이지로 바뀐 지 얼마되지 않아, 유저의 피드백을 직접적으로 접하지는 못했어요. 대신 정량적인 부분에서 여러 수치들이 올라간 것을 확인할 수 있었습니다. 대략적으로 재방문자의 UV(Unique Visitor)수가 개선 전과 대비해서 약 70%정도 크게 증가했습니다. 이전에는 회원가입을 끝마치고 인증과정 중에 페이지를 이탈한 유저도 보였지만, 개선된 후에는 마이페이지 탭 이용빈도가 크게 올라갔습니다. 마이페이지가 좀 더 원활한 거래소 서비스 이용을 위한 가이드 역할을 해주길 기대하면서, 지속적으로 니즈를 관찰하고 개선해 나갈 예정입니다.Q. 마이페이지 이외에도 기억에 남는 유저플로우셀의 프로젝트가 있나요?예은 : 코인원의 수익현황을 한 눈에 볼 수 있는 자산탭이 기억에 남아요. 그 동안 코인원 유저들이 수익률을 확인할 수 있는 기능을 많이 요청했었는데, 팀원들이 함께 고민하여 새로 개편한 기능이라서 그 의미가 컸어요.정유 : 저는 실질적으로 프로젝트에 돌입하기 전에 진행했던 코인원 유저 인터뷰가 가장 기억에 남아요. 인터뷰 내용이 개선점으로 가득찰 줄 알았는데, 응원의 목소리를 전달해주셨거든요. 더 열심히 UI 디자인을 해야겠다는 의욕을 불타오르게 해주었어요!현진 : 코인원 웹프로덕트를 사용하시는 분들이 눈치 채셨는지 모르겠지만, 마이페이지 이전부터 진행해왔던 리빌딩 프로젝트(랜딩, 거래소, 프로차트, 코인원 톡 등)들이 기억에 남아요. 사실 마이페이지 이전 리빌딩 프로젝트들은 기술적으로만 접근하다보니 우여곡절이 많았어요. 그래도 마이페이지 리빌딩은 업무적으로도 많이 배우고, 기술 뿐만 아니라 전체적으로 변화한 것이 보여 저 또한 성장하는 시간이었습니다.종헌 : 이외에도 유저플로우셀은 UX개선을 여러 프로젝트와 함께 진행하고 있습니다. 정신없긴 하지만 개발요소도 새롭고 다이나믹한 것이 많아서 즐겁게 하고 있습니다!▲ 화기애애하게 UI 시안을 보고 있는(?) 유저플로우셀Q. 코인원에서 디자이너 그리고 개발자로 일하는 큰 장점은 무엇인가요?예은 : 코인원에선 셀마다 다른 직무의 인원들이 빠르게 소통하여 의사결정하는 목적조직 형태로 일합니다. 중간중간 기획리뷰, 디자인리뷰 과정을 거치면서 더 꼼꼼하게 일하고, 다른 직무에 계신 분들의 작업도 공유하고 있어요. 거래소에서 일어날 수 있는 다양한 문제 상황을 긴밀하게 대응하고 있죠.정유 : 현재 코인원은 ‘셀(Cell)’이라는 목적조직 형태입니다. PM, 개발자, 디자이너가 한 조직에 속하다보니 Output 나오는 속도가 매우 좋아졌습니다. 또한 여러 직군이 함께 팀웍을 맞추다보니 서비스를 다양한 각도에서 바라볼 수 있고, 이는 디자이너로서 서비스 이해도를 높이는데 굉장히 좋은 환경이라고 생각해요.  종헌 : 코인원은 개발자도 기획 단계부터 적극적으로 참여하여 프로젝트를 설계하고 있습니다. 이로 인해 개발을 하다 예기치 않은 변수가 생기는 일이 거의 발생하지 않아요. 또한 정기적으로 회고를 하며 프로세스의 문제점을 도출해내고, 개선을 위해 다양한 시도를 해볼 수 있다는 것도 장점입니다. 현진 : 현재 코인원 기술본부는 트렌디한 기술을 곳곳에 사용하고 있어요. 기술에 민감하게 반응하는 프론트엔드 개발자분이 코인원에 온다면 기술적으로 매우 만족하실거에요. Q. 앞으로 이루고 싶은 목표는 무엇인가요?예은 : 암호화폐 거래소는 UX를 기획하기에 매우 도전적인 분야입니다. 블록체인 기술이 곳곳에서 화제가 되고 있지만, 아직 업계의 워딩이나 사용에서의 유저 친화적 성숙도가 높지 않은것 같아요. 앞으로의 목표는 누구나 쉽게 거래할 수 있는 암호화폐 거래소를 만드는 것입니다. 점점 더 발전하는 코인원의 모습을 많이 기대해주세요!정유 : 코인원 UI에는 아직 블록체인 공급자적 시선이 많이 담겨있어요. 예를들어, 개발자가 아니면 이해하기 어려운 용어나 UI가 남아있는 부분이 있거든요. 이를 디자인적으로 해소하고 싶습니다. 유저가 갖고 있는 암호화폐 거래 장벽을 낮추고, 코인원의 가치가 잘 반영된 프로덕트를 만드는 것이 목표에요. 종헌 : 코인원에서는 트레이딩 이외에도 여러가지 서비스들을 유저에게 제공하는 다양한 시도를 하고 있어요. 저는 다양한 서비스들을 연결하면서 서비스의 안전장치를 견고하게 쌓아올리고 싶네요. 장애 발생에도 끄떡없는 안정적인 코인원을 유저에게 선보이고 싶습니다.현진 : 대한민국에서 적어도 사용성 1위 암호화폐 거래소를 만들거에요. 유저플로우셀에서 마이페이지 이후에도 많은 프로젝트를 준비하고 있거든요. 매주(?) UX가 점차적으로 개선되는 코인원 거래소의 모습을 확인할 수 있을 거에요. 마지막으로 꼭 하고싶은 말이 있는데, 코인원에 많은 개발자분들이 지원해주셨으면 좋겠어요. 아직 업계에 부정적인 인식이 강하지만, 블록체인이 발전하는 과정을 보며 점차 해소될거라고 믿어요. 기술적으로 발전할 가능성이 무궁무진한 곳이니 기술적인 욕심을 채우고 싶은 분들, 함께 성장하고 싶으신 분들 코인원으로 오세요!▲ 코인원 유저플로우셀 많이 기대해주세요!무엇보다도 긍정적인 에너지로 가득찼던 유저플로우셀의 인터뷰를 들어봤어요.코인원 마이페이지에 큰 변화를 가져온 활기찬 에너지, 다들 느끼셨나요?마이페이지 이후에도 다양한 프로젝트를 준비하고 있는 유저플로우셀. 곧 코인원 웹 거래소를 사용하면서 UX적으로 편리한 사용성을 경험할 수 있을겁니다.끝으로, 특별한 문화를 경험할 기회! 코인원 채용에 함께하는 것도 잊지 마세요 :-)

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