스토리 홈

인터뷰

피드

뉴스

조회수 1205

CodeStar + Lambda + SAM으로 테스트 환경 구축하기

들어가기 전: 실제로 프로젝트와 팀원들과의 작업 환경을 구축한 경험을 바탕으로 작성했습니다. 한마디로 실화. 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]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유
조회수 938

HyperCut으로 인물사진 필터를 만들었습니다

얼마전 하이퍼커넥트의 아이디어 제안 채널에서 나온 이야기입니다.mel 은 사업그룹의 터키지역 담당 팀에 있는 친구인데, 꾸준히 좋은 제안과 아이디어를 주는 훌륭한 동료입니다. 이번에는 최근 여러 스마트폰이나 사진 앱들에서 나타나기 시작한 인물사진 모드 를 아자르에서도 지원하는게 좋겠다는 제안이었습니다.스마트폰이 자체 기능으로 인물사진 필터를 제공하는 경우는 보통 듀얼 카메라를 사용해 인물 외의 배경을 흐릿하게 만들어 심도를 표현합니다. 하지만 모두가 듀얼 카메라를 탑재한 스마트폰을 쓰는 것은 아니기 때문에, 이런 인물사진 모드를 소프트웨어적으로 구현하는 앱들도 존재합니다. mel 이 보여준 링크의 인스타그램도 그렇게 구현했네요.인물사진 모드를 소프트웨어적으로 구현하려면, 영상에서 얼굴을 포함한 사람을 배경으로부터 정확히 분리해 내는 기술이 필요합니다. 그리고 사진을 찍을 때에 실시간으로 프리뷰를 보아야 할테니까 이것을 실시간으로 처리할 수 있을 정도의 성능도 필요하구요.하이퍼커넥트에서는 머신러닝, 특히 영상과 이미지를 다루는 분야에 대해 지속적으로 투자와 연구를 해 왔습니다. 영상에서 인물을 분리해내는 문제는 크게 Image Segmentation 의 범주에 속합니다. 좀 더 직접적으로 Portrait segmentation 이라고 부를 수도 있습니다. 이를 잘 하기 위해서 하이퍼커넥트에서는 자체적인 학습 데이터를 만드는 것부터 시작하여 기술 개발을 지속적으로 추진해 왔고, 그 결과 Machine Learning 팀에서 이미 실시간으로 얼굴과 배경을 분리해내는 - HyperCut - 이라는 기술을 확보한 상태입니다. 아직 실제 서비스에 탑재되진 않았지만 이미 하이퍼커넥트의 주요 서비스인 아자르의 개발 버전에서는 HyperCut을 응용한 여러가지 이펙트를 사용할 수가 있습니다. 그리고, 그 중에 인물사진 모드 필터도 이미 있습니다.mel 의 제안이 있던 날 오후 아이디어 제안 채널에 이런 답이 달렸습니다.모델이 되어 주신 분은 하이퍼커넥트의 CTO 인 ken 이네요. 아자르 개발 버전에서 HyperCut 을 응용한 인물사진모드 필터를 사용하고 찍은 사진입니다. 아자르의 저장하기 기능을 사용했더니 UI 없이 오른쪽 아래에 아자르 로고만 남게 되었네요. 아직 실서비스에는 포함되지 않았지만, 최적화와 튜닝 과정을 거쳐 조만간 많은 사용자들이 HyperCut 을 사용한 이펙트를 쓸 수 있게 될 예정입니다.#하이퍼커넥트 #개발 #개발자 #아이디어 #아이디에이션 #구체화 #협업 #팀워크 #팀플레이
조회수 444

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

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

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

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

단일 TABLE을 SELECT하자!

OverviewDB를 다뤄봤다면 SELECT문도 아실 겁니다. 가장 먼저 접하는 명령어 중에 하나이기도 하죠. 보통은 아래처럼 사용합니다. SELECT문SELECT     * FROM 테이블명  ; 명령을 주면 지정한 테이블에 저장된 모든 내용을 검색합니다. 이번 글에서는 테이블을 만들고 SELECT하는 과정을 다뤄보겠습니다. DB는 MySQL 5.6을 기준으로 하고, Tool은 MySQLWorkbench를 사용하겠습니다.Query, 너란 녀석테이블은 위와 같이 생성할 수 있습니다. 위의 내용은 MySQLWorkbench를 이용해 Model을 표시하면 아래와 같습니다. 구성원의 정보를 저장하도록 했고, 컬럼마다 의미를 갖게 됩니다. MBR_ID (구성원 아이디) : DB에서 구성원을 식별하는 아이디MBR_INDFY_NO (구성원 식별 번호) : 구성원을 실제 구별하는 번호로 과거에는 주민등록번호가 많이 사용되었고, 요즘은 e-mail 이 많이 사용됩니다.MBR_NM (구성원 명) : 구성원의 이름 테스트 데이터를 입력해 실행하면 어떤 결과가 나오는지 보겠습니다.가장 기본적인 SELECT문 실행계획을 보면 아래와 같이 나옵니다.실행 계획은 DB가 어떻게 Query를 수행할 건지 보여줍니다. Query가 복잡해지면 실행 계획을 보면서 Query가 올바르게 작성됐는지 확인하고 필요하다면 Query를 수정해야 합니다. DB를 시작할 때부터 실행 계획을 보는 습관을 기르는 게 중요한 이유입니다. 각 항목에 대한 설명id : SELECT 문에 있는 순차 식별자로 Query 를 구분하는 아이디select_type : SELECT의 유형SIMPLE : Subquery나 union 이 없는 단순한 SELECTtable : 참조되는 테이블의 명칭TB_MBR_BAS : 참조되는 테이블명type : 검색하는 방식ALL : TABLE의 모든 ROW를 스캔 위의 이미지는 임의로 만든 자료를 이용해 Query를 실행한 결과입니다. 실행 계획은 TABLE : TB_MBR_BAS 를 TYPE : ALL 전체 검색한다고 나옵니다. 실행한 내용도 같습니다. 여기서 MBR_NM 이 “나서영”인 자료를 검색해볼까요. WHERE 조건이 들어가자 실행 계획도 내용이 변경되었습니다. rows와 Extra에도 값이 있는데요. 두 항목을 잠시 짚고 넘어가겠습니다. rows : Query를 수행하기 위해 접근해야 하는 열의 수Extra : MySQL 이 Query 를 수행할때의 추가 정보Using where : Query 수행시 TABLE에서 값을 가져와 조건을 필터링 함 위의 결과처럼 전체를 검색해 필요한 자료만 추출하는 것을 FULL TABLE SCAN or FULL SCAN 이라고 합니다. 그러나 FULL SCAN은 성능이 좋지 않기 때문에 우선 꼭 필요한 Query인지 검토해야 합니다. 보통 MBR_NM에 INDEX를 추가해서 해결하는데요. INDEX를 추가해서 같은 Query를 수행하면 실행 계획은 어떻게 달라질까요. 분명 같은 Query였는데 INDEX에 따라 실행 계획이 변경된 걸 알 수 있습니다. INDEX를 추가해도 수행한 결과는 같지만 검색 속도에 많은 차이가 있습니다. 각 항목에 대한 설명type - ref : 인덱스로 자료를 검색하는 것으로 현재는 매칭(=) 자료 검색을 나타냄possible_keys : 현재 조건에 사용가능한 INDEX를 나타냄(인덱스가 N개일 수 있음) IX_MBR_BAS_02 : 현재 조건에 사용 가능한 INDEXkey : Query 수행시 사용될 INDEX (possible_keys 가 N 개일 경우 USE INDEX, FORCE INDEX, IGNORE INDEX 로 원하는 INDEX 로 바꾸어 수행할수 있음)key_len : 수행되는 INDEX 컬럼의 최대 BYTE 수를 나타냄152 : 수행되는 INDEX 컬럼의 BYTE 수가 152ref : INDEX 컬럼과 비교되는 상수 여부 or JOIN 시 선행 컬럼 constant : 상수 조건으로 INDEX 수행rows : 678 : 678 rows 접근하여 값을 찾음Extra : using index condition : INDEX 조건에 대하여 스토리지 엔진이 처리(MySQL의 구성에서 스토리지 엔진과 MySQL 엔진이 통신을 주고 받는데 스토리지 엔진에서 처리 하여 속도가 향상됨) ConclusionINDEX가 없으면 결과가 나오기까지 5초 정도 걸리지만, 반대로 INDEX가 있으면 1초 안에 결과가 나옵니다. 별거 아닌 것 같아 보이지만 실무에서는 엄청난 차이입니다. Query를 작성할 때 실행 계획을 확인하고 조금이라도 빨리 결과가 나올 수 있도록 하는 것이 중요하기 때문이죠. 다음 글에서는 단일 TABLE 을 SELECT하는 것을 주제로 이야기를 나눠보겠습니다. 무사히 SELECT하길 바라며.글한석종 부장 | R&D 데이터팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유
조회수 880

프로그래밍에는 왜 창의성이 필요하다고 할까요?

왜 프로그래밍에는 창의성이 필요하다고 할까요? 실제로 프로그래밍을 하다 보면 복잡한 문법을 이해하고, 암호 같은 에러를 차분히 해결해야 하니, 오히려 수학적이며 논리적인 사고가 더 필요해 보입니다. 그런데도 프로그래밍이 창의적이어야 하는 이유는 하나의 프로그램을 만드는 답이 여럿이기 때문입니다.답이 하나여도 가르치기 어려운데, 다양한 방법을 어떻게 가르쳐야 하는 걸까요? 또, 기상천외한 학생들의 코드를 보며 이해하고 교육하는 것이 얼마나 긴 시간이 필요하며 어려운 일인가요? 어디서부터 해결해나가야 할지 막막합니다.Elice 리서치 팀에서 하는 일 중 하나는 학생들의 수많은 코드 중 비슷한 타입들을 추려내는 것입니다. 코드를 몇 가지 타입으로 추려내고 나면, 선생님은 학생 하나하나의 코드를 보고 교육하는 것이 아니라, 비슷한 형태의 코드를 작성한 학생 그룹 전체에게 적절한 피드백을 줄 수 있습니다. 이렇게 그룹 전체에게 피드백을 준다면 선생님은 같은 시간에 더 많은 학생을 교육할 수 있을 것입니다.그럼 이제, 비슷한 코드를 어떻게 찾아내서 분류할지 이전 연구를 보며 알아봅시다. (현기증이 날 수 있으며, 다 이해할 수 없어도 괜찮으니 걱정하지 마세요!)지프의 법칙과 숙제 제출 패턴자연어 처리(Natural Language Processing;NLP)를 배울 때 자주 거론되는 사람이 있습니다. 바로 미국의 언어학자인 조지 킹슬리 지프George Kingsley Zipf인데, 이 사람이 만든 지프의 법칙은 자연적으로 일어나거나 생성되는 특정 정보들이 일정하게 나타내는 경향을 나타낸 것입니다. 지프는 영어로 된 텍스트를 분석하던 도중, 자주 쓰이는 단어를 순서대로 나열하면 각 단어의 빈도는 그 단어의 출현 순위에 반비례함을 찾아냈습니다. 영어에서 가장 많이 사용되는 단어 1~3위가 “the”, “of”, “and” 인데, “the”는 “of”의 약 두 배, “and”의 약 세 배의 빈도를 보입니다.이것을 수학적으로 표현하면, 일정 크기 이상의 영어 말뭉치(corpus)에 들어 있는 단어들의 개수를 전부 세서 그 단어들을 가장 많이 쓰이는 것부터 순위를 1위부터 나열했을 때, 특정 단어의 순위가 k 라면 (즉 전체에서 k번째로 많이 쓰인 단어라면) 그 단어가 말뭉치에서 쓰인 개수는 1/k에 비례한다는 것입니다. 이것을 그래프로 그려보면 다음과 같습니다. 재미있는 사실은, 여기에서 x축과 y축에 log를 씌워 보면 (이것을 log-log scale로 변환한다고 합니다.) 다음과 같은 직선 형태로 변환된다는 것입니다.이것이 도대체 숙제 제출과 무슨 관계가 있길래 이렇게 장황한 설명을 한 것일까요? 위에서 나온 지프의 법칙을 기억하시나요? 학생이 낸 숙제를 채점하다 보면 꽤 많은 학생이 비슷한 방식으로 숙제를 푸는데, 제출된 풀이 방식들을 비슷한 것끼리 묶어 분석해 보니, 이것 또한 지프의 법칙을 따른다는 것이 발견되었습니다. 예를 들어 가장 인기 있었던 풀이 방식으로 100명이 숙제를 제출했다면, 두 번째로 인기 있는 풀이 방식으로는 약 50명이 숙제를 제출했다는 뜻입니다.여기서 우리가 찾아낼 수 있는 인사이트는 무엇일까요? 첫째, 학생들의 숙제들을 비슷한 것끼리 묶을 수 있다면, 그리고 이 분류를 컴퓨터로 자동으로 할 수 있다면 조교가 채점하거나 코멘트를 할 때 써야 할 시간이 상당히 줄어들 것입니다. 둘째, 방법 서너 개에 대해서만 어떻게 채점할지 혹은 어떻게 코멘트할지에 대해 준비를 해놓으면, 그걸로 숙제 대부분을 채점/코멘트할 수 있을 것입니다. 대다수의 숙제는 몇 가지 인기 있는 풀이방식으로 만들어졌을 것이기 때문입니다.그러면 이제 다음 문제는, ‘비슷한 풀이 방식으로 푼 프로그램 코드’를 어떻게 찾아낼 것인가? 를 고민해봅니다. MIT의 Elena Glassman은 이에 대한 해법으로 Overcode를 제시했습니다.Overcode뉴스 기사나 책, 블로그 글 등 자연어로 이루어진 텍스트 데이터를 분석하고, 여기에 어떤 주제가 들어있는지 밝혀내는 연구는 많이 진행 됐습니다. 이를 위한 머신러닝 알고리즘 중 하나가 토픽 모델, Topic model 입니다(토픽 모델에 대해서는 다른 글에서 자세히 다룰 예정입니다). 그러나 토픽 모델링을 프로그래밍 문제에 실제로 적용하기는 쉽지 않습니다. 코드에 사용되는 문법이나 키워드가 자연어와 1:1로 매칭되지 않기 때문에, 기존에 자연어에서 사용되던 모델을 그대로 사용할 수 없기 때문입니다. 가령, 슬쩍 보면 무척 달라 보이는 아래 두 파이썬 코드는 사실 완전히 같게 동작합니다. 이 두 코드를 (사람들이 일상생활에서 사용하는) 자연어를 분석하는 모델로 분석한다면 제대로 된 결과를 낼 수 없는 건 당연합니다.def fibonacci(): parents, babies = (1, 1) while babies < 100 xss=removed>fibonacci()def fib(parents, babies): ‘’’ parents = 1 babies = 1 ‘’’ while True: print ‘This generation has {0} babies’.format(babies) parents = babies # set parents as babies babies = parents + babies # recursively add number of babies if babies >= 100: break fib(1, 1)Elena Glassman이 제시한 Overcode의 목적은 비슷한 로직으로 만들어진 프로그래밍 코드들을 모으는 것입니다. 이제 Overode가 어떻게 작동하는지 간단하게 소개하도록 하겠습니다. 가장 먼저 수행되어야 하는 것은 서로 다른 형식으로 쓰인 소스 코드들을 정리하는 것입니다. 소스코드 정리에는 주석 제거, 줄 및 공백/들여쓰기를 일정하게 맞추는 작업 등이 포함됩니다.Image from Overcode하지만 이 작업만으로는 충분하지 않습니다. 거의 같아 보이는 코드도 실제로 프로그램을 실행하기 전까지는 같은지 알 수 없고, 꽤 달라 보이는 코드도 실제로는 완전히 같게 동작할 수 있기 때문입니다 (여기서 같게 동작한다 함은, 결과를 같게 내는 것 이상으로 결과를 내는 중간과정이 완전히 같다는 것을 의미합니다). 다시 위로 돌아가, fibonacci() 함수와 fib(parents, babies) 함수를 살펴봅시다. 위 두 코드는 기존의 자연어 처리 기법에 따르면 완전히 다른 프로그램일 것입니다. 변수명이 달라서가 가장 큰 이유일 텐데, 사실 컴퓨터의 입장에서 변수는 어떤 값을 할당하는 공간에 불과하며, 그 공간에 어떤 이름을 붙이느냐는 중요하지 않습니다. 코드를 작성하는 것이 사람이기 때문에 공간에 편하게 이름을 붙이는 것뿐입니다. 서로 다른 프로그램에서 어떤 변수가 서로 같은 역할을 하는지, 컴퓨터가 알아내려면 어떻게 해야 할까요? (컴퓨터는 창의적이지 않습니다!)Image from OvercodeElena가 제시한 방법은 프로그램을 실행하면서 변수의 값이 어떻게 바뀌는지를 추적한 것입니다. 아래 두 코드를 보고, 한번 머릿속으로 프로그램을 실행해 봅시다. 학생 B의 코드는 for문으로 5의 3승을 계산했고, 학생 C의 코드는 while문으로 5의 3승을 계산한 것입니다. 학생 B의 코드가 실행됨에 따라 r이라는 변수가 어떻게 변하는지, 학생 C의 코드에서 result가 어떻게 변하는지 확인해보면 둘 다 1 → 5 → 25 → 125 의 값을 가지게 됩니다. 그렇다면 컴퓨터는 이렇게 판단할 수 있습니다. “B의 코드에서의 변수 r과 C의 코드에서의 result가 완전히 같은 방식으로 변하니, 같은 의미로 사용된 것이다.”Image from Overcode이제 같은 의미를 가지는 변수들을 알아냈다면, 컴퓨터는 쉽게 가장 “흔한” 이름으로 변수의 이름을 바꿔치기 합니다. 그러면 처음에 서로 다르게 보였던 코드들도 이제 같아질 것입니다.물론 이것이 다는 아닙니다. 예를 들어, 간단한 테스트 케이스들을 통해 결과를 비교함으로써 변수를 분석하기 전에 먼저 거르는 방법, 너무 흔한 변수들을 처리하는 방법 (예를 들어 완전히 다르게 동작하는 코드들에서도 반복문에서 사용되는 인덱싱 변수들은 같이 변화할 것입니다), 한 변수가 다른 의미론적으로 두 번 사용되는 경우 처리하는 방법… 등이 논문에는 더욱 자세히 적혀있습니다. 궁금한 독자들은 한번 논문을 읽어보도록 합시다.남은 문제들Elena가 제시한 방법은 위에서 보여준 예제와 같은 간단한 코드에서 꽤 잘 동작합니다. 예를 들어, 다음과 같은 문제들이 있습니다.a의 b승을 구해서 리턴하는 프로그램N번째 피보나치 숫자를 리턴하는 프로그램다항식의 미분 결과를 리턴하는 프로그램하지만 대학교에서 1학년만 넘어가더라도 이런 간단한 프로그램 과제는 내지 않습니다. 예를 들어 Elice에서 교육 중인 기초 프로그래밍/ 프로그래밍 유치원 수업을 듣는 학생들은 매우 많은 실습문제를 풉니다. 여기에서 푸는 과제들은 초반 몇 주가 지나면 이 정도의 간단한 프로그래밍 수준을 뛰어넘기 때문에, 코드가 꽤 길어지고 다양성이 생기게 되는데 이런 경우 이 방법은 잘 동작하지 않습니다.또 다른 문제는, 이 방법이 “동작하는” 코드에서만 작동한다는 것입니다. 예를 들어, 수강생들이 아직 기초 문법을 배우고 있다면? 제대로 실행도 되지 않는 코드를 만들었을 때, 비슷한 실수를 한 사람들끼리 묶어주고 싶다면? 아쉽게도 Elena가 제시한 방법은 이렇게 에러가 나는 코드에서는 동작하지 않습니다. 코드가 실행되지 않는다면 변수의 값의 변화를 추적할 수 없기 때문입니다.마치며이번 포스트에서는 학생의 제출 코드를 비슷한 것끼리 묶는(Clustering하는) 방법에 대해 간단하게 살펴 보았습니다. 학생이 낸 비슷한 답안을 모아주는 솔루션은 수학 문제 같은 단답식 문제, 혹은 영어 에세이같은 자연어에 대해서는 이미 상용화가 되어 있습니다. 영어 에세이의 경우 여러분들이 가장 친숙할 만한 상용화된 솔루션은 아마 copy detector일 것입니다.하지만 프로그래밍 코드의 클러스터링은 연구가 계속 진행되고 있습니다. 앞서 말했듯 코드에서 한 글자 한 글자가 가지는 의미가 자연어에서 가지는 알파벳과는 완전히 다르기 때문이기도 하고, 정말 실행을 해 보기 전까지는 어떻게 동작하는지 예측하는 것이 매우 어렵기 때문이기도 합니다. Elice 리서치 팀에서도 프로그래밍 코드에 대한 분석을 자동으로 수행하는 머신러닝 연구를 수행하고 있습니다. 이러한 기술을 통해 선생님이나 조교가 학생을 더욱 효율적으로 지도하고, 컴퓨터의 도움으로 지도에 아낀 시간을 한 단계 더 개인화된 도움을 주도록 하는 것이 Elice의 목표 중 하나 입니다.글쓴이김수인: KAIST 전산학부 박사과정 / Research Lead, Elice김재원: KAIST 전산학부 박사과정 / The Lead, Elice배휘동: KAIST 전산학부 박사과정 / Frontend Lead, Elice#엘리스 #코딩교육 #교육기업 #기업문화 #조직문화 #서비스소개
조회수 977

맛있는 인터뷰: 잔디 그로스 팀 개발자, Hugo

 역삼 맛집▲ 금강산도 식후경이라 했던가? 맛있는 인터뷰가 맛있는 이유는 늘 음식과 함께 하기 때문이다오늘 온 맛집. 분위기가 심상치 않다. 어떤 곳인지 소개해달라. Hugo(이하 ‘휴’): 역삼역 근방에 있는 ‘산촌’이란 곳이다. 얼마 전 버디런치 장소 물색을 위해 ‘다이닝코드’로 역삼역 주변 한식집을 찾던 중 발견했다. 예로부터 어르신들이 찾는 곳은 맛집이라는 얘기가 있다. 보면 알겠지만 어르신들이 많다. 괜찮은 가격에 건강한 음식을 섭취할 수 있는 곳이라 많은 듯 하다. 그리고.. 우리도 건강을 챙겨야 하는 나이다. 몸에 좋은 곤드레밥, 메밀 전병을 먹으며 함께 하는 건강한 인터뷰가 되었으면 하는 바람에 이 곳을 선택했다.깔끔한 답변 고맙다. 이제 본인 소개를 부탁한다. 휴: 반갑다. 개발자 Hugo다. 잔디 그로스 팀(Growth Team)에서 로우 데이터(Raw data) 가공, 분석을 통해 유의미한 지표를 보여주는 데이터 분석 툴 ‘스프링클러’를 개발하고 있다. 잔디 멤버들 사이에서 유독 명성이 자자하다 휴: 여러분의 관심을 먹고 자라는 임무를 수행하다 보니 그런 듯 하다. Hannah, Jihoon, Jane 등과 함께 GWP 팀으로 활동해서 많이들 알아봐 주시고 격려해주시는 것 같다. * GWP 팀? GWP는 Great Working Place의 줄임 말이다. 단어 그대로 물리적+비물리적 최고의 업무 공간을 만들기 위해 TF팀 형태로 구성된 그룹이 다양한 활동을 한다. 예를 들면, 할로윈 파티 개최부터 탕비실 냉장고 음식 채우기 등 업무 환경 개선을 위해 크고 작은 일을 수행한다. ‘비선실세’라는 얘기도 돌던데? 휴: 천부당 만부당한 말씀이다. 그저 잔디를 사랑하는 멤버 중 한 명이다.스프링클러? 휴: 잔디 그로스 팀에서 자체적으로 만든 분석 툴이다. 쉽게 말하면 잔디 데이터 분석과 가공에 최적화된 잔디 전용 구글 어널리틱스(Google Analytics)로 보면 된다. 스프링클러를 통해 잔디 DAU(Daily Active User) 파악, 마케팅 채널 별 효율 측정, 유저 별 사용량 측정 등을 할 수 있다.  스프링쿨러▲ 잔디의 모든 데이터를 가공, 분석해 보여주는 스프링클러잠깐! 유저 별 사용량 측정도 스프링클러를 통해 가능하다고 했는데 잔디 팀이 유저의 모든 정보를 열람하는 건가? 휴: 많은 분들이 오해할 수 있을 것 같은데 그렇지 않다. 스프링클러에서 열람할 수 있는 유저 별 사용량 확인은 특정 채널을 통해 유입된 유저가 메시지를 몇 건 보내고, 파일 업로드를 얼마나 하는지 정도다. 유저가 어떤 메시지를 주고 받는지, 어떤 파일을 올리는지 등 개인 정보는 원칙적으로 잔디 팀이 접근할 수 없다.   스타트업은 시간과 리소스 관리가 생명이다. 구글 어널리틱스와 같은 훌륭한 툴이 있는데 굳이 자체 데이터 분석 툴을 만든 이유가 무엇인지? 휴: 날카로운 질문이다. 나도 처음에 왜 스타트업에서 데이터 관련 팀을 꾸려 분석 툴을 만들려고 하는지 이해가 가지 않았다. 하지만 좀 더 생각해보니 잔디에서 발생한 데이터에 특화된 분석 툴이 있어야 정확한 결과를 얻을 수 있고, 이를 통해 스타트업 특유의 린(Lean)한 개발이 가능할거란 결론에 도달하였다.   듣기엔 스프링클러의 사용성과 분석 능력이 뛰어나 독자 서비스로 나오는 것 아니냔 루머가 있었다. 사실인가? 휴: 하하. 루머일 뿐이다. 다만 그런 생각을 갖고 그로스 팀과 최선을 다해 스프링클러 개발을 하고 있다. 어쨌든 좋게 봐주셔서 이런 루머가 나온 것 같아 담당자로서 기쁘다.   스프링클러에 애정이 많을 것 같다 휴: 내게 잔디도 소중하지만 스프링클러도 무척 중요하다. 소박한 꿈이 있다면 스프링쿨러가 내가 없어도 100% 완벽히 잘 돌아가게 만들고 싶다. 물론, 분석 툴로서 멤버들이 원하는 결과를 보여줄 수 있도록 정교하게 만드는 것도 중요하다.   그로스 팀은 과거 ‘맛있는 인터뷰’의 Kevin을 통해 소개한 바 있다. 당시 개발자 중 몇 명을 차출해 그로스 팀에 합류시킨 걸로 알고 있는데 여러 개발자 중 Hugo가 차출된 이유가 있다면? 휴: 평소 데이터 마이닝 분야에 관심이 많아 대학원에서 관련 공부를 하기도 했고, 그로스 팀 초창기 모든 업무를 책임지던 팀장 겸 팀원 Kevin이 추천해 팀에 합류하게 되었다. 아, 그로스 팀 오기 전엔 백엔드(Back-end) 개발자 포지션으로 있었다. 팀을 옮길 땐 백엔드 개발자들로부터 ‘배신자’란 오명과 함께 모진 고문과 학대를 받았다. 하하.. 농담이다.   다른 얘기를 해보자. 잔디에 어떤 이유로 조인했는지 궁금하다 휴: 건방진 말일 수 있지만 내 의지대로 무언가 만들고 싶었다. 대한민국 수 많은 개발자들이 그렇겠지만 회사에서 내가 할 수 있는 건 생각보다 한정돼 있다. 아이디어를 내도 예산 때문에 혹은 기타 다른 이슈 때문에 반려되기 일쑤였다. 어떻게 보면 그런 현실에 대한 반발심으로 잔디를 선택한 게 가장 크다고 볼 수 있다.   잔디에서는 생활은 만족스러운가? 휴: 70% 정도?   왜 70%인가? 휴: 장-단점이 있지만 장점이 조금 더 크기 때문에?   그럼 장점부터 말해보자 휴: 합당한 이유가 있다면 내가 하고 싶은 일을 진행할 수 있다는 점이 큰 장점이다. 그 일을 실행하기까지 절차도 이전까지 다녔던 회사 대비 상당히 간소화되어 있어 부담감도 적다. 각 분야에서 두각을 드러낸 사람들과 함께 일하고 있다는 점도 매력적이다. 다들 자부심을 갖고 일하고 있어 자극을 받는다.   단점은? 휴: 장점이 때에 따라 단점으로 보일 때도 있다. 논리적인 어프로치가 필요할 때도 있지만 분명 전쟁터로 돌진하는 돌격병 같은 저돌성이 필요할 때도 있다. 그럴 땐 일부터 치고 보는 자세가 필요한데 그 때를 놓치는 경우가 눈에 보여 개인적으로 아쉽다.   스트레스는 어떻게 푸는지? 휴: 주말에 13시간 이상 잔다. 밤에 10시간, 낮에 3시간. 남는 시간엔 수영이나 등산을 한다.   등산? 휴: 집 바로 뒤에 나지막한 산이 있다. 평소 자연을 좋아하는데 등산을 하다 보면 산의 나무나 풀, 바람을 보고 즐길 수 있어 좋다.   생각보다 감성적인 남자라 당황스럽다 휴: ^^ ▲ 감성적인 남자로 보이는 그는 한 때 해병대 전우였다.수영은 시작한지 얼마 안됐다고 들었다 휴: 작년 10월부터 시작했다. 이제 갓 1년이 넘었다. 작년 초부터 체력적으로 처진 것 같은 느낌이 들어 이대론 안되겠다 싶어 수영을 시작했다. 등산과 함께 꾸준히 하는 운동 중 하나다.   꾸준히 운동하고 있는데 달라진 점이 있다면? 휴: 몸도 몸이지만 정신적으로 건강해졌다. 확실히 체력이 떨어지면 부정적인 생각을 하는 경향이 있는 것 같다. 운동을 시작하기 전과 후의 마음 상태가 정말 많이 다르다. 앞으로도 꾸준히 운동을 할 생각이다.   곤드레밥과 함께 한지 벌써 1시간 가까이 됐다. 인터뷰 질문도 다 소진되어 이전 맛있는 인터뷰 주인공이었던 David이 남긴 질문을 묻고 싶다 휴: 준비됐다.   잔디 멤버 중 전생에 공주나 왕자였을 것 같은 사람은? 휴: 왕자는 디자인 팀의 Ben. 도도하고 말수도 적고. 공주는 디자인 팀의 Yujin (A.K.A Summer)? 얘기는 많이 안 해봤지만 말도 고급스럽게 하는 것 같다. 두 사람 모두 괜찮은 사람들이라 이번 인터뷰를 통해 점수를 따보고 싶다.   전략적인 답변 감사하다 휴: ^^   마지막 질문이다. ‘맛있는 인터뷰’의 백미는 다음 인터뷰이에게 현재 인터뷰이가 질문을 남기는 것이다. 다음 사람에게 묻고 싶은 질문이 있다면? 휴: 잔디 멤버 중 내 주변 괜찮은 남자 사람이나 여자 사람을 소개시켜주고 싶은 사람은?   오늘 맛있는 곤드레밥 덕분에 잘 먹었다. 계산은 인터뷰이가 한다는 거 다시 한번 더 상기시켜 드리며 인터뷰 마무리하겠다 휴: …^^#토스랩 #잔디 #JANDI #개발 #개발자 #개발팀 #인터뷰 #팀원 #팀원소개 #팀원인터뷰 #기업문화 #조직문화
조회수 1198

jekyll의 메커니즘을 이해하고 커스터마이징하기

편집자 주-PHP 기반의 서비스를 기준으로 설명했다.-서버의 프로그램은 ‘서버 스크립트’로 표기했다.-HTML/html: 약어로 사용할 경우엔 대문자, 파일명으로 사용할 경우엔 소문자로 표기했다.목차jekyll이 어렵게 느껴지는 이유 jekyll은 모든 화면을 미리 만들어둔다.서버 스크립트 없이 검색 기능을 어떻게 만들까?이미지 캡션 추가이미지 사이즈 대응부록: 글 반영 과정, 도메인 연결 방법, 추가 옵션에 대하여Overview기술 블로그인 브랜디 랩스를 관리하기에 jekyll은 안성맞춤인 도구입니다. 1년 넘게 탈 없이 잘 사용하고 있죠. 물론 커스터마이징을 하려면 고생이 이만저만이 아닙니다. 그 과정은 jekyll을 이용한 Github 블로그 만들기에도 잘 나와있습니다. 도대체, jekyll은 왜 이리도 어려운 걸까요? 브랜디 랩스를 사례로 설명하겠습니다.jekyll이 어렵게 느껴지는 이유일반적인 웹서비스는 정적 리소스와 동적 스크립트의 조합으로 이뤄집니다. 예를 들어 PHP 서비스에서는 정적인 부분을 아파치 웹서버로, 동적인 부분을 PHP 스크립트로 작동합니다.하나의 게시글이 생기면 PHP 스크립트가 데이터베이스에 row 생성을 요청합니다. 게시글 등록 요청을 마치고, 글 목록 화면 요청을 한다면 데이터베이스에서 등록된 글목록을 정리해 HTML 양식으로 응답값을 만들어줄 것입니다.PHP 기반의 블로그 프로그램하지만 jekyll은 컨셉부터 다릅니다. 아주 생소한 메커니즘을 갖고 있습니다. 파일 기반의 데이터를 정적인 리소스로 빌드해서 서비스하죠. 게시글마다 md 파일이나 html 파일을 생성합니다. 글을 작성하고 배포하기 위한 빌드를 진행하면 응답할 html 화면을 만들고, 파일로 저장해 준비합니다. 이 상태에서 유저가 특정 화면을 요청하면 미리 생성한 html 파일을 찾아 꺼내주기만 하면 되죠. 다시 말해, 데이터베이스를 조회하고 HTML 양식으로 응답값을 만드는 과정이 생략되는 것입니다.실제로 Github page가 아파치 서버를 쓰는지는 알 수 없지만 개념 설명을 위해 동일하게 그렸다.jekyll은 모든 화면을 미리 만들어둔다.jekyll은 유저가 요청할 수 있는 모든 화면을 미리 빌드하는 방식을 씁니다. 앞서 다뤘던 브랜디 랩스의 gnav 영역의 회사소개, 채용 화면도 미리 빌드해둬야 합니다. 저자를 소개하는 프로필 페이지도 마찬가지죠. 글이 많아지면서 점점 길어지는 글 목록 화면도 예외는 아닙니다. 글 목록을 보여주는 화면이 많아지만 페이지 수만큼 미리 만들어야 합니다.위의 이미지는 jekyll이 동작하는 메커니즘을 간단히 정리한 것입니다. jekyll을 커스터마이징하려면 완전히 새로운 관점으로 접근해야 합니다. 지금부터는 브랜디 랩스의 검색 기능 구현 과정을 살펴보면서 커스터마이징을 자세히 알아보겠습니다.서버 스크립트 없이 검색 기능을 어떻게 만들까?검색을 하려면 작성된 모든 글의 제목과 내용에 원하는 키워드가 있는지 찾아야 합니다. 하지만 검색어는 변동값이므로 미리 빌드하는 방식으로는 커버할 수 없습니다. 검색어마다 화면을 미리 만들 수 없기 때문입니다.이럴 때는 클라이언트 스크립트는 활용해야 합니다. 서버 스크립트를 쓸 수 없기 때문에 어쩔 수 없는 선택이기도 합니다. 검색에 필요한 정보를 json 파일로 빌드시키고 자바 스크립트를 이용해서 검색하도록 했습니다.먼저 최상위 경로에 search.json을 만듭니다. 파일 시작점에 아래와 같은 패턴이 있다면 빌드 대상으로 인식됩니다.--- --- 이전에 쓴 jekyll 문서를 PDF로 배포하기에서 pdf.html 파일을 만들 때도 비슷한 방법을 사용했습니다.--- --- [ {% for post in site.posts %} { "title" : "{{ post.title | escape }}", "category" : "{{ post.category }}", "tags" : "{{ post.tags | join: ‘, ’ }}", "url" : "{{ site.baseurl }}{{ post.url }}", {% if post.author %}{% for author in site.data.authors %}{% if post.author == author.name %} "author" : "{{author.koname}}", "email" : "{{author.email}}", {% endif %}{% endfor %}{% endif %} "date" : "{{ post.date }}", "content" : "{{ post.content | strip_html | replace: "\", ‘’ | replace: ‘"’, ‘\"’ | replace: ' ‘,’ ' | replace: ' ‘, ’ ' }}" } {% unless forloop.last %},{% endunless %} {% endfor %} ] ▲서머리 데이터를 만드는 json 파일search.json은 모든 페이지의 제목과 내용을 정리해 json으로 만들어야 하기 때문에 site.posts변수를 이용해 만들었습니다. post내용에는 글의 저자, 작성일, 제목, 내용 등 필요한 정보가 있으니 출력하면 됩니다. json을 만드는 것이므로 내용에 “가 들어가면 안되 "으로 치환시켰습니다. 마지막으로 HTML 태그는 검색에 필요하지 않기 때문에 luqid strip_html 함수를 이용해 제거했습니다.http://labs.brandi.co.kr/search.json위의 URL을 클릭하면 브랜디 랩스에서 검색에 사용하는 json을 볼 수 있습니다. 빌드하면 search.json이 만들어지는 것을 확인할 수 있습니다. 이제 json을 로딩하고 해당 키워드를 가진 글을 찾아내기만 하면 됩니다. json 내에 제목과 내용에 입력한 키워드가 있을 때 아래와 같은 UI로 표현했습니다. 기능 구현은 Simple-Jekyll-Search를 이용했습니다. 1)이미지 캡션 추가블로그는 이미지를 많이 사용하고, 상황에 맞게 노출도 해야 합니다. 아래 이미지는 최종적으로 적용한 이미지와 캡션의 결과 화면입니다. {% include figure.html file="/assets/20190415/05.png" alt="05" caption="커스터마이징한 gnav 영역" width="fitcontent" border="true" %} 위와 같이 구성하려고 html과 css를 다음과 같이 구성했습니다. 커스터마이징한 Gnav영역 ▲캡션 html 소스figure { margin: 1em auto; } figcaption { text-align: center; font-weight: bold; color:#999; } ▲캡션에 관련된 css 소스이미지는 가운데 정렬했고, 캡션 텍스트도 옅은 회색으로 가운데 정렬했습니다. 하지만 편집을 담당하는 장근우 대리는 개발자가 아니므로 태그를 입력해달라고 하기엔 무리가 있었습니다. 좀 더 편리한 방식이 없을지 고민하다가 liquid 템플릿의 include 기능을 쓰면 되겠다는 생각이 들었죠. 아래는 브랜디 랩스 원고에 이미지를 넣을 때 쓰는 liquid 문법입니다.{% include figure.html file="/assets/easydebug/5.png" alt="07" caption="커스터마이징한 Gnav영역" %} liquid 템플릿 엔진에서 include할 때 추가 파라미터를 전달할 수 있습니다. file, alt, caption은 파라미터로 전달하고, include되는 파일에서 전달할 내용을 바탕으로 프로그램을 구현할 수 있습니다. {{include.caption}} ▲ /_includes/figure.html이미지 사이즈 대응작은 이미지를 확대하면 이렇게 된다.대부분은 이미지는 화면에 꽉 차지만, 어떤 이미지는 사이즈가 너무 작아 원래의 사이즈로 보여줘야 했습니다.{% include figure.html width="fitcontent" border="true" file="/assets/easydebug/5.png" alt="07" caption="커스터마이징한 Gnav영역" %} ▲사이즈와 외곽 테두리 선에 스펙을 추가했다.추가 전달 인자를 넣고, figure.html 파일에서도 사이즈 대응을 했습니다. {{include.caption}} ▲완성된 /_includes/figure.html 파일figure { margin: 1em auto; } figure.percent100 { width: 100%; } figure.percent90 { width: 90%;} figure.percent80 { width: 80%;} figure.percent70 { width: 70%;} figure.percent60 { width: 60%;} figure.percent50 { width: 50%;} figure.percent40 { width: 40%;} figure.percent30 { width: 30%;} figure.percent20 { width: 20%;} figure.percent15 { width: 15%;} figure.percent10 { width: 10%;} figure.percent5 { width: 5%;} figure.fitcontent { width: fit-content;} figcaption { text-align: center; font-weight: bold; color:#999; } ▲완성된 css이제 원하는 사이즈를 지정해 이미지 상황별 적절한 대응을 할 수 있게 되었습니다.Conclusionjekyll은 브랜디 랩스를 운영하기에 아주 유용한 도구입니다. 기본 템플릿도 훌륭하지만 상황과 편의에 맞게 변경하면 개성 있는 기술 블로그를 만들 수 있을 겁니다. 물론 커스터마이징이 어려울 수 있지만 jekyll의 메커니즘을 이해한다면 금방 적응할 수 있을 겁니다. 이제 블로그를 만들 모든 준비가 끝났습니다. 자, 도전해봅시다!부록1.글 반영 과정jekyll을 이용해서 글을 작성했나요? 이제 Github 저장소에 push하면 글이 반영될 겁니다. push하는 과정을 보면 빌드된 파일을 push하는 게 아니라, 원본에 해당하는 md파일 또는 html 파일을 push하는 걸 알 수 있습니다. push하면 Github page에 바로 반영되지 않고, 몇 분 정도 걸립니다. 이것을 통해 작성한 글이 저장소에 push되면 스케줄러나 트리거에 의해 빌드된다는 걸 유추할 수 있습니다. 아마도 빌드 결과를 위한 저장소가 따로 있고, 빌드된 결과가 저장되는 것이라 예상합니다.2.도메인 연결 방법jekyll 서비스에서는 구매한 도메인을 간편하게 연결할 수 있습니다. 프로젝트의 가장 위쪽에 CNAME 파일을 만들고 push하면 금방 적용됩니다.CNAME 파일3.추가 옵션에 대하여자료를 조사하던 중에 공식 사이트의 빌드 추가 옵션을 찾았지만 0.2초 정도로 큰 차이가 없었습니다. 만약 별도의 옵션이 없다면 빌드 결과는 _site 폴더로 모일 겁니다.공식 사이트 빌드 옵션옵션을 넣어 빌드옵션을 넣지 않고 빌드참고1) GitHub - christian-fei/Simple-Jekyll-Search: A JavaScript library to add search functionality to any Jekyll blog.글천보성 팀장 | R&D 개발2팀[email protected]브랜디, 오직 예쁜 옷만
조회수 1199

Humans of TODAIT : CTO 유병한을 만나다

어느 화창했던 3월, ‘Humans of TODAIT’ 의 첫 주인공인 투데잇 CTO 유병한을 만나봤습니다. 투데잇 핵심엔진인 그의 이야길 함께 들어볼까요?Q. 자기소개 부탁드려요.안녕하세요! 투데잇에서 CTO를 맡고 있는 유병한입니다. ‘SW 마에스트로’라는 과정에서 대표님과 좋은 인연이 되어 투데잇의 전신인 투데잇브레이커부터 지금까지 열심히 개발중입니다. 안드로이드분야에 관심이 많아서 시작하게 되었는데, 차츰 기술 스펙을 확장해 나가면서 서버개발부터 최근엔 iOS 개발까지 맡고 있습니다.Q. ‘꿈을 향한 오늘, 투데잇’ 이라는 슬로건처럼 CTO님의 꿈에 대해 들을 수 있을까요?제겐 두가지 꿈이 있는데요, 먼저 투데잇이라는 서비스 자체에 대해선 전국민 앱으로 거듭나고 싶어요. 기존 교육관련 산업에서 우뚝 솟을 수 있는 서비스가 되고 싶은데요, 공부하는 사람의 입장에서 처음부터 끝까지 도움을 줄 수 있는 서비스를 제공하고 싶어요. 그래서 ‘저 사람이 일하는 투데잇은 일하기 좋은 회사다!’ 라던가 ‘성장하기 좋은 회사!’라는 인식을 주고 싶어요! 여러사람들을 심쿵!하게 만들고 싶습니다(웃음)음.. 그리고 제 개인적인 꿈으론 진짜 언젠간 해보고 싶은건데, 다큐멘터리 내셔널 지오그래픽급의 사진작가가 되고 싶어요.이래저래 심쿵하는 사람이 되고, 심쿵하게 만드는 서비스를 제공하고 싶습니다.Q. ‘개발자’로서의 시작은 어땠나요?음 제가 처음부터 개발자가 되고 싶단 생각은 안했어요. ‘개발’과 인연의 끈이라고 되짚어본다면, 아마 어릴 적에 접했던 나모웹에디터로 홈페이지 만들기?였던 것 같아요.그리고 수시를 과감하게 버리고 제가 즐겁게 할 수 있었던 컴공이나 관련 학과로 찾다보니 지금의 과에 입학하게 되었어요. 대학교와서도 다양한 학교 수업 중 개발 관련 수업을 맛보면서 ‘아 이게 나한테 맞겠구나!’ 싶어서 본격적으로 공부했어요.(Q. 앗, 그럼 ‘개발자’라는건 갑작스러운 전환이었나요? )그렇다고 해서 아주 갑작스럽진 않았어요. 학생때 사진찍는걸 즐겨서 색감에 대한 거라던가 화면에서의 구도에 대한 이해같은게 높았거든요. 학과에서 배웠던 다양한 편집툴들이 지금의 UI 센스에 발판이 되지않았나 생각해요.어느 순간 하나가 쓸데없던 적은 없었던 것 같아요. 자그마한 순간순간들이 지금의 저로 만든 것 같아요.Q. 본인이 맡은 업무에 대해 어떻게 접근하나요?일단 맡은 분야에 대해서도 그렇고 제가 욕심이 좀 많아요(웃음) 내가 잘하고 싶은 욕심, 가지고 싶은 욕심이 여러 힘든 과정을 이겨낸 원동력이 아닐까 생각해요.Q. 예를 들면 어떤 경험이 있나요? 조금 더 자세하게 듣고 싶어요!음.. 아 이건 좀 비밀인데 중학교때 사진을 찍게 되었는데 보통 그냥 똑딱이카메라쓰던 시절이었거든요. 그런데 DSLR이 너무 가지고 싶어서 조르기도하고 한푼두푼 모으기도해서 결국엔 DSLR을 손에 넣었어요. 되게 사소한것 같지만 나름 원하는걸 얻어낸 뜻깊은 추억이죠. 뭐든 전문가처럼 해야겠단 욕심이 강한 것 같아요.(Q. 오.. 그런데 책상에 책이 되게 많이 쌓여있네요? )책을 쌓아두는게 사실 좀 최근 관심이 가진 프로그래밍 언어라던지 관심이 가는거 위주로 가져다 놓긴 했어요. 아이폰 관련 서적이 몇개 있는데, (이제 세달 정도) 레퍼런스로 많이 찾아보기 위해서 책들이 상시대기하고 있어요. 2–3권. 스위프트라는 언어를 배우면서 기존의 코틀린 자바 스크립트 등 다양한 관심이 생겨서 , 언어들에 대한 욕구가 좀 큰 요즘입니다~(웃음)Q. 일을 하다보면 힘든 순간도 많았을 것 같아요.힘든 순간은 매순간인것 같아요(하하) 그래도 진짜 엄청 힘든 순간이 있었는데 제겐 ‘아버지’가 되게 큰 힘이 되주셨어요. 아버지께서 목사님이시거든요. 평생 부산에서만 사셨던 분이 산골 깊숙히 들어와서 농촌교회를 준비하시면서 힘든 부분이 분명 클텐데도, 지금은 사회복지기관까지 운영하시는 걸 보면 정말 대단하신 것같아요. 홀로 타지에서 모든걸 감내하셨던 부분이, 그리고 하고자 하는 일에 대한 끊임없는 열정을 많이 배워요.그런 아버지를 보고 감명받아서인지 저도 모르는 사이에 창업가 마인드가 생겼던 것 같아요. “ ‘내’가 능동적으로, ‘내’회사를, ‘내’회사에서, ‘내’회사를 위해 일하는, ‘내’일을 한다. ”라는 생각 자체가 아버지의 영향을 많이 받지 않았나싶네요.음 그리고 역시나 빼놓을 수 없는! 우리 투데잇을 사랑해주시는 유저분들이 정말 큰 힘이되요. 실은 투데잇브레이커 당시에 제가 이일을 시작하게 된 이유자체가 ‘이 서비스를 사용하는 유저들이 있다’란 거였거든요. 제겐 그분들이 제 모든 이유인것 같아요. 제 스스로가 성장할 수 있는 이유, 투데잇이 인정받을 수 있는 이유, 그 모든 이유의 근간이라고 생각해요.Q. 항상 좋은 리뷰만 있진 않았을 것 같아요. 혹시 가장 기억에 남는 리뷰 있나요?되게 오래전 리뷰인데, 많이 부족했던 투데잇을 보고 ‘대체 언제쯤 기능 업데이트 되냐, 3D게임 만드냐’라고 하셨던 리뷰가 가장 기억에 남아요. 순간은 되게 기분이 상하면서도 점점 더 잘해내고 싶단 의지가 생기더라구요. ‘내가 3D게임 개발하는 것도 아닌데, 이정도라니. 더 개발 좀 열심히 해야겠다.’하구요. 지금은 그분께 감사하죠.그때 당시만해도 투데잇이란 서비스가 되게 부족했을텐데도 끊임없이 애정해주시면서 기다려주신 유저분 중 한 분이니까요.좋았던 리뷰들은 정말로 셀 수 없이 많아요. 저희가 매주 리뷰를 함께 공유하는 자리가 있는데, ‘성적이 올랐다는 리뷰’부터, ‘투데잇 덕분에 공부 스타일이 또는 생활 습관이 바뀌었어요’, ‘지금 수험생활을 하고 있는데 힘을 얻고 있어요.’ 그리고 ‘합격소식’까지. 진짜 큰 힘이 되죠. 제가 어떤 무형의 무언가를 하고 있단게 현실에서 드러난다는게. 그게 정말 큰 힘이 되요.Q. 나에게 ‘기술’ 이란?저는 아까 말씀드렸던 것처럼 욕심이 좀 많은 편인데, 그 중 제일 욕심 많은게 바로 ‘기술’이예요. 이 분야에서 전문가가 되기 위해서 하나하나 하면 하나를 깊게 파는 스타일이예요.그래서 다양한 분야의 기술을 심도있게 잘하고 싶은 욕심이 있었는데, 투데잇을 개발하면서 그런 욕심을 부릴 수 있는 기회가 주어졌어요. 당시만 해도 당장 없는 개발팀원 자릴 메우기 위해 열심히 욕심부렸던게 지금의 이 자리에 앉게되지 않았나 생각됩니다.제게 기술이란건, 기술 자체가 가지고 싶은 그 무언가예요. 끊임없이 욕심을 내서 계속해서 닿고싶은 그런 존재?(웃음)Q. 오픈소스활동에서 핫하다는 이야기가 있는데요~오픈소스 활동이 아주 거창하진 않아요. 아직은 걸음마단계 수준이죠. 음 처음엔 제가 필요한 오픈 소스를 사용하면서 발견한 에러나 버그 부분에 대해 피드백을 드렸어요. 되게 간단한 부분이었는데 그쪽에서 긍정적으로 받아들여주셨어요. 그런 상호 피드백이 오가면서 관심을 갖게되었습니다.제트브레인스라는 회사에서 근무하시는 분의 피드백을 받는 과정이 오픈 소스활동을 통해 서로 교류할 수 있단 점이 매력적이었어요.활동을 하게된 결정적인 계기는, 다른 회사에 다니는 친구와 함께 깃허브에 올리고 IOS 개발 커뮤니티에 올렸더니 반응이 핫하더라구요. 큰 이슈는 아니지만, 사람들이 긍정적인 피드백을 해줘서 즐거운 순간이었죠.앞으로도 작은것부터 하나씩 해나갈 예정이에요. 큰 규모의 기술은 아니더라도, 투데잇의 ANDROID/IOS에 필요한, 하지만 불편함을 해소해줄 수 있는 라이브러리나 툴들을 만들어나가려고 생각을 하고 있구요. 기존에 투데잇 안에서만 쓰던 걸, 조금씩 정리해서 공유해나갈 생각입니다.Q. 안드로이드 앱 개발을 하면서 소프트웨어 아키텍쳐에 관한 고민이 있다던데, 어떤 고민을 하고계신지 들어볼 수 있을까요?지금 저희 나름대로, 기존에 있던 MVVM, VIPER라든지 그런 아키텍쳐들을 많이 보고 차용을 해서, 투데잇에도 적용을 해나가고 있는 중이에요. 직접 해보니 학교에서 책으로 배운 “프로그래밍 구조가~” 나 “아키텍쳐 구조가~” 에 대해 필요성을 뼈저리게! 몸소 부딪혀가면서 느끼는 중입니다.개발을 하다보면, 사소한 버그나 문제점을 많이 발견하게 되는데, 이를 어떻게 미리 테스트할지 또 어떻게 검증할지에 대해 고민을 하고 있어요. 그런데 기존 소스코드는 각각 다른 기능을 하는 코드가 한데 뭉쳐있어서, 이걸 분리해서 테스트하기에 용이한 아키텍쳐에 대해 개선 및 적용해나가고 있습니다.또 안드로이드와 아이폰 버전을 개발 중인데, 각각 플랫폼에 종속적인 부분을 빼놓고 두 버전 모두 동일한 구조를 가지고 갈 수없을까에 대한 고민 중인데요, 이러한 고민을 함께 하실 분들이 오셨으면 좋겠어요. 이상적인 구조를 향해서 말이죠. (웃음)Q. 현재 일하고 있는 팀원이 7명이나 된다고!네! 대표님과 단둘이 끌어왔던게 엊그제같은데, 벌써 7명의 투데잇팀으로 구성되었네요. (웃음) 사실 제게 투데잇팀은 그냥 공기같은 존재예요. 같이 있을 땐 중요성을 모르다가도, 누구하나 자릴 비우게 되면 그 느낌이 진짜 오묘해요. 서로가 서로를 너무 당연하게 자리하고 있다고 느끼고 있어서요.언젠가 한번 기호형님(COO)이 자릴 비운적이 있었어요. 아직 일한지 1년도 채 안되는데도, 옛날 옛적부터 알고 있던 사람처럼 그때 그 공허감이 되게 크더라구요.사실 좋을 땐 다 좋죠. 중요한건 일하면서 분명 좋지 않은 순간이 올텐데, 이때 서로 어떻게 커뮤니케이션을 하느냐 인것 같아요. 부정적 피드백에 대해 받아들이는 자세가 우리 팀의 가장 메리트라고 생각해요.지금 팀원들은 일에 있어서 피드백이 오갈 땐, 감정적인 건 잠깐 내려놓고, 객관적으로 앞으로 더 발전 방향에 있어서 뭘 어떻게 해야할지를 생각하는 태도를 보이거든요. 이 부분에 대해 ‘서로 핏이 잘 맞는다’라는 문장이 딱 맞는 표현 같아요.그래서 전 “같이 있으면서 어색하지 않은 그런 사이”가 좋아요. 물론 시간이 지나면서 서로 맞춰가는거겠지만, 왜 그런거 있잖아요. 함께 일을 해도 계속해서 어색한 사람이 있고 조금 풀리는 사람이 있는거. 그런 점이 저희 팀의 메리트라고 생각합니다.Q. CTO의 입장에서, 같이 일하고 싶은 개발자는 어떤 사람인가요?당연한 거겠지만, 일단 서로 존중해줄 수 있는 사람이면 좋겠어요. 아무리 비즈니스라지만 서로가 서로에게 예의와 매너가 갖춰진 사람을 원합니다.업무적으론, 뭔가 새롭게 배우는거에 대해 두려움이 없는게 좋은 개발자의 기본 자세라고 생각해요. 그래서 바로바로 과감한 도전 정신이 있는 사람! 그리고 제게 없는 재능을 가져서 서로가 상호 보완해나갈 수 있는 파트너면 좋겠어요.Q. 지원하고 싶은, 지원을 생각하는, 이 글을 보고있는 사람에게 한마디 부탁드려요!“만약에 지원을 하신다면, 마음을 단단히 먹어야할겁니다.”초반만 하더라도, 스타트업에 대한 환상이 있었어요. 이상적인 모습, 장밋빛 회사생활만을 꿈꿨거든요. 언론에서 소위 말하는 ‘젊은 창업가!’의 그 이면엔, 장밋빛을 현실화 하기위해 매일매일이 고난의 길이란걸 잊지 않으셨음 해요. 스타트업이란게 자신의 한계를 확인하는 과정이기 때문에, 같은 출발선에서 함께 발전하기 위해 달릴 준비가 되신 분을 환영합니다.또 자기 나름의 미션이 있고, 그걸 회사의 가치 성장에 일치시켜 나가면서 함께 실현해나가실 분을 모십니다!우리의 이상을 위해 함께 이 현실을 헤쳐나가실 분을 찾습니다!#투데잇 #팀원소개 #팀원인터뷰 #팀원자랑 #기업문화 #조직문화 #개발자 #개발팀 #CTO
조회수 3610

jekyll을 이용한 Github 블로그 만들기

Overview“githubPage로 기술 블로그를 만들자!” “jekyll로 만들면 한두 시간이면 가능할 거야!” 지난 1월, 브랜디 기술 블로그 제작 작업을 시작했습니다. 다양한 삽질과 험난한 여정의 결과물인 기술 블로그의 제작 및 커스터마이징 과정을 소개하겠습니다.GithubPage는 Github에서 공식적으로 운영하는 블로그 서비스입니다. 이곳엔 개발자들의 경험이나, 코드가 업로드되어 있습니다. 저장 공간도 무료로 제공되고, 도메인 연결도 편리하게 할 수 있지만, 무엇보다 GithubPage 혹은 GithubIO라고 하면 개발자 스멜이 풀풀 나기 때문에 선택의 이유가 되는거 같습니다.GitgubPage 제작 프로그램은 jekyll, HEXO가 가장 많이 쓰입니다. 브랜디의 기술 블로그는 템플릿의 종류도 많고, 더 어울리는 jekyll을 선택했습니다. jekyll 공식 사이트는 여기를 클릭하세요. 한국어도 지원하니 아주 멋집니다. 변역된 문서가 2015년 11월 23일 문서인 게 함정이지만 기능의 거의 유사하기 때문에 문제될 것은 없습니다. 1. 준비물을 챙기자!$ gem install jekyll $ jekyll new my-awesome-site $ cd my-awesome-site /my-awesome-site $ jekyll serve ▲ jekyll 설치 스크립트이제 브라우저로 http://localhost:4000 에 접속합니다.메인에 내거는 것처럼 설치와 실행이 쉽지만 몇 초 만에 되진 않습니다. 설치가 몇 분 정도 걸리고 ruby나 bundler같은 선행 조건이 갖춰져야 하기 때문입니다.ruby는 있는데 bundler가 없다면 아래와 같이 설치하면 됩니다.gem install bundler 설치가 잘 되고, 사이트 생성 후 실행을 했다면 브라우저와 함께 기본 페이지가 뜹니다. 설치가 성공했다!2. 1차 멘붕, 이제 무엇을?설치는 제법 쉽게 했지만 ‘이제 무엇을 해야 하나’ 막막하기만 합니다. 블로그 작성에 대한 아무런 가이드도 없고, 페이지나 이미지 추가 확인 등의 작업을 커멘드로만 하려니 힘들고 아찔하기만 합니다.커멘드 지옥..jekyll admin을 검색했더니 이런저런 아이들이 나옵니다. 그중에 jekyll 공식 플로그인을 선택했습니다. jekyll-admin 공식 사이트 이미지그런데 사이트 메뉴얼만 보고 설치하기 쉽지 않습니다. 이제 막 jekyll 띄웠을 뿐인데 플로그인은 어떻게 추가하는지 알 길이 없습니다. 이런저런 삽질을 거듭하고 안 되는 영어를 해석하다 보니 얼떨결에 성공했습니다.추가한 프로젝트 root에 보시면 Gemfile이 존재합니다.아마도 사이트 제너레이트 시 실행되는 스크립트인 것 같습니다. 파일을 열고 아래와 같이 추가합니다.# 아래와 같이 한줄 추가해주세요 gem 'jekyll-admin', group: :jekyll_plugins 프로젝트 root로 이동해 설치를 요청합시다.bundle install 달라진 게 없어 보여도 http://localhost:4000/admin 으로 접속하니 아뉫! 관리자가 설치되었습니다. 이제 한시름 놓입니다.3. 마크다운, 넌 누구?마크다운을 잘 안다면 넘어가도 됩니다.관리자를 설치하고 나면 그나마 좀 할만하지만 막상 글을 쓰려고 보니 무언가 다릅니다. HTML이나 위지윅 에디터도 아니고 Textarea만 덩그러니 있기 때문입니다....마크다운은 위키나 Github페이지 설명 작성 등에 쓰이는 언어입니다.1) HTML을 어느정도 한다면 문법만 읽어도 금방 이해할 수 있습니다. 생각보다 어렵지 않아서 간단한 문서 작성은 수월하게 가능합니다. 무엇보다 코드를 붙여넣을 때 아주 좋습니다. ``` PHP 코드 내용 ```위의 그림처럼 작성하면 자동적으로 신텍스 하이트라이트가 적용되니 개발 코드를 전달하기 편리합니다.4. Posts? Pages? Static Files? Data Files?확실히 jekyll은 그동안 봤던 블로그나 워드프레스 등 유명한 블로그와는 많이 다릅니다. 일단 개념부터 짚어보겠습니다. PostsPost는 한 개의 글을 지칭합니다. 블로그의 글 하나입니다. 어느 정도 구축이 되면 Post에서 글만 작성해도 쉽게 운영할 수 있습니다.PagesPost처럼 계속 추가되는 형태가 아닌 고정 페이지를 작성할 때 씁니다. About이나, 채용, 회사소개 등 Post와 분리가 필요한 글을 작성할 때 유용합니다.Static Files정적 리소스를 올리는 기능입니다. 생각보다 버그가 많아서 사용하기 쉽지 않습니다. 저는 이 기능을 커스터마이징해서 약간 쓰기 쉽게 바꾸었지만 쉽지는 않았습니다. 자세한 관리자 커스터마이징은 나중에 다루겠습니다.Data Files정적 데이터를 다루는 기능입니다. 저자 관리나 공통 변수를 담아두면 편리하게 쓸 수 있는 기능입니다. 역시나 버그가 넘쳐납니다. 당분간은 그냥 파일을 직접 수정하는 게 나을 겁니다.5. 블로그 제목 등 설정을 바꾸고 싶다면관리자의 configuration 메뉴를 이용하거나, 프로젝트 루트에서 _config.yml 을 열고 수정해도 됩니다. 사이트에서 사용할 전역 변수나, 플로그인, 기본값 등을 관리해주기 때문에 자주 수정하는 파일입니다. 제목을 변경하려면 title을 찾아서 변경하면 됩니다. 그외의 하단 문구는 buttomtitle을 변경하면 됩니다. 아래 보이는 각종 정보들은 맞게 수정하면 되고, social: 밑에 있는 정보들은 나중에 페이스북 공유나, 트위터 공유 등으로 사용할 수 있습니다. 해당 정보가 없거나 공유를 원치 않는다면 share를 false로 변경합니다. _config.yml은 수정 후 재시작을 해야만 반영되므로 jekyll를 다시 실행하면 됩니다.6. 테마를 적용하자테마 기능은 jekyll를 선택한 가장 중요한 이유였습니다. 멋진 디자인과 추가로 구현된 특수한 기능들은 jekyll이 가지고 있는 큰 메리트입니다. 테마를 사용하려면 소스를 다운로드 받고 압축을 해제해 사용하거나 git checkout 하면 됩니다. 해당 폴더로 이동해 실행하면 테마를 쉽게 사용할 수 있습니다.jekyll serve jekyll은 테마가 완성된 프로젝트 개념이기 때문에 바로 사용이 가능하지만 마이그레이션 이슈가 있습니다. 마이그레이션은 _post의 있는 파일과 _page에 있는 파일을 그저 테마 프로젝트 폴더에 덮어쓰기하면 됩니다.아쉽게도 _config.yml파일은 다시 세팅하는 게 빠릅니다. 어드민 설정 부분도 다시 하면 됩니다. 테마마다 약간씩 기능이 달라 마이그레이션이 안 되는 경우도 있으니 테마는 초기에 선택하는 게 좋습니다. 브랜디 랩스는 Centrarium 테마를 적용했습니다.테마가 적용된 화면7. 글에 이미지를 어떻게 넣을까?글을 쓰면 참고자료로 쓸 이미지도 필요합니다. static file에 업로드 기능이 있지만 업로드를 하면 프로젝트 루트 폴더에 업로드되어 관리상 좋지 않습니다. 앞서 공유한 것처럼 해당 기능 개선에 대해서는 다루지 않을 것이기 때문에 수기로 이미지를 관리하는 방법을 소개하겠습니다.로컬 프로젝트 기준에서 _site는 제너레이트된 최종결과라고 할 수 있습니다. 그래서 _site 폴더에 assets와 같은 폴더가 있으나 그 폴더에 올리면 덮어쓰기와 동시에 초기화 되므로 반드시 프로젝트 루트의 assets에 파일을 올려주시면 됩니다. 폴더를 생성하는 것도 문제 없으므로 포스팅마다 이미지를 나누길 권장합니다. 이미지가 폴더에 복사가 되었다면 이제 글에 넣어봅시다.마크다운 위지윅을 이용해도 좋고 이미지 부분을 HTML코드롤 사용해도 좋습니다. 마크다운으로 이미지를 추가할려면 아래처럼 사용하면 됩니다. ![이내용은 alt속성으로 치환됨](/assest/20180118/test.jpg "이 내용은 타이틀로 치환 됨") assets/test.jpg적용된 이미지이미지의 사이즈나 정렬을 변경하는 건 다음에 다루겠습니다.8. Gnav 변경은 어떻게 할까?커스터마이징한 Gnav영역테마도 적용했고, 글도 쓸 수 있지만 안 쓰는 기능 삭제를 비롯해 손볼 곳은 아직 많습니다. (분명 한두 시간이면 된다고 했던 일이 2주째 수정 중입니다…) 화면 구성을 고치려면 프로젝트에 포함되어 있는 템플릿 파일을 고쳐야 합니다.템플릿은 Liquid 라는 언어로 구성되어 있으며, 문법이 좀 난해하지만 충분히 헤쳐 나갈 수 있습니다. 다만 어디서부터 어떻게 고쳐야 하는지를 파악하는 게 어렵죠. 문법은 공식 사이트를 참고하고, 사용 가능한 변수는 여기를 참고하면 됩니다.사용 가능한 변수는 site와 page로 나눌 수 있습니다. site는 _config.yml 설정한 내용과 jekyll이 지원하는 전역 변수들입니다. page는 해당 페이지에 지정된 세부 변수들입니다. 글의 제목이나 경로 내용들은 기본적으로 세팅되어 있습니다. 추가적인 값을 다루려면 post를 작성하면서 meta정보를 추가하면 됩니다.템플릿의 시작파일은 index.html이고, 페이지에 layout이 지정되었다면 _layouts 안에 있는 [layout].html이 됩니다. 기본적 틀은 _layout/default.html에서 파생됩니다. 그외 파츠로 사용되는 HTML파일은 _includes에 넣고 `{% include header.html %} 같은 방식으로 추가하면 됩니다. 우리 변경하려는 파츠는 header.html에 있습니다. site.pages에는 모든 페이지가 들어있기 때문에 그중에 gnav가 지정된 글만 상단에 노출되게 했습니다. 그리고 상단 글에 대한 정렬이 없기 때문에 좋은 방식은 아니지만 1~10까지 숫자를 기입하면 순서대로 나오게 코드를 구성했습니다. (site.pages에는 posts와 pages가 같이 나옵니다.){% for i in (1..10) %}   {% for page in site.pages %}     {% if page.title and page.gnav == i %}     {{ page.title }}     {% endif %}   {% endfor %}  {% endfor %} 글에 옵션을 지정한 화면이제 pages에서 상단에 노출하고 싶은 글만 gnav를 숫자로 부여해 노출할 수 있게 변경했습니다.9. 스타일 변경은 어떻게 할까?sass로 구성된 스타일의 변경은 심도있게 다루지 않으려고 합니다. sass를 처음 사용한 것도 있지만 내용이 너무 깊어지기 때문입니다. 스타일변경은 _sass 밑에있는 scss 파일을 변경하면 되고, 템플릿마다 구조가 다르기 때문에 열심히 찾는 수밖에 없습니다.10. 저자 기능을 추가해보자 (1)최고의 난이도를 자랑하는 신규 기능 추가입니다. 브랜디의 기술 블로그에서는 작성자를 클릭하면 작성자의 글만 따로 모아서 볼 수있습니다. 하지만 이 기능은 공식적으로 지원되는 것이 아니기 때문에 처음부터 만들어야 했습니다. 완성된 작성자 기능위의 이미지와 같은 기능을 구축하려고 collection을 사용했습니다. collection은 posts나 pages와 같이 그룹핑된 글 목록을 이야기 합니다. posts나 pages는 기본 세팅되어 있고, 약간(?)의 설정 변경으로 collection을 추가할 수 있습니다. 작성자의 메인 페이지가 필요하니 authors라는 collection을 추가해보겠습니다.# _config.yml collections:   authors:     title: Authors     output: true jekyll을 재시작하면 아래와 같이 Authors가 관리자에 추가된 것을 볼 수 있습니다.authors는 작성자 메인 페이지만 생성하면 되므로, 내용에는 작성자에 대한 소개글만 간략히 쓰면 됩니다. jekyll admin에 한글 버그가 있기 때문에 우선 영어로 작성하고, 제목을 다시 한글로 수정하면 됩니다.포스팅마다 저자의 정보가 공통적으로 나와야 하기 때문애 위의 전역변수에 authors를 추가해 따로 관리하게 했습니다.# data/authors.yml # authors 공용 변수   - name: chunbs     koname: 천보성 팀장     email: [email protected]     position: R&D 개발2팀     img: /assets/profile/chunbs.jpg   - name: kangww     koname: 강원우 과장     email: [email protected]     position: R&D 개발2팀     img: /assets/profile/kangww.jpg 그리고 작성자의 포스팅을 엮어주려고 작성자의 아이디가 같을 때, 포스팅으로 나오게 구성합니다.{% if post.author %} {% for author in site.data.authors %}   {% if post.author == author.name %}   {{author.koname}}   {% endif %}  {% endfor %}  {% endif %} 11. 저자 기능을 추가해보자 (2)데이터가 준비되었다면 저자 레이아웃을 추가해야 합니다.(이거 도대체 언제 끝날까요) 저자가 작성한 글만 노출되어야 하는 게 어려울 수도 있지만 jekyll의 구동 원리를 이해하면 손쉽게 할 수 있습니다.jekyll은 내용 수정이 발생되면 전체를 다시 컴파일하는 구조입니다. 다시 말해 일부 파일이 변경되면 노출되는 모든 html파일을 다시 랜더링해서 write하는 것입니다. author의 각 작성자 페이지는 컬렉션에 포함되어 있기 때문에 랜더링이 발생하고 site.posts엔 작성된 모든 페이지 정보가 있습니다. site.posts를 foreach를 돌리고, 저자가 일치하는 페이지만 리스트로 보여줍시다.{% for post in site.posts %} <!-- author 정보가 저자와 같은 경우만 리스트로 출력한다. --> {% if post.author == page.author %}       {{ post.title }}         {{ post.content | strip_html | truncatewords: 25 }}         {{ post.date | date: "%Y-%m-%d" }}           {% if post.author %}         {% for author in site.data.authors %}           {% if post.author == author.name %}           {{author.koname}}           {% endif %}         {% endfor %}       {% endif %}       {% if forloop.last == false %} {% endif %}   {% endif %} {% endfor %} Conclusionjekyll admin은 은근히 버그가 많습니다. 그래도 ‘md파일을 메모장으로 작성하세요’라고 하는 것보단 편하죠. 다양한 기술을 사용하기 때문에 어려울 수도 있겠습니다. 글에서 소개할 수 없거나, 너무 깊어지는 내용은 소개에서 제외했습니다. 양해를 부탁드립니다. 대신에 브랜디 랩스는 저의 피땀 눈물로 만들어졌다는 걸 기억해주세요… 기타jekyll의 기본값 설정을 이용하면 layout과 같은 공통적인 부분을 쉽게 설정할 수 있다.# _config.yml defaults:  - scope:     path: ''     type: posts   values:     #permalink: "/blog/:title/"     layout: post     cover: /assets/default.jpg     author:  - scope:     path: ''     type: authors   values:     layout: author     cover: /assets/author.jpg     subtitle: ~담당하고 있습니다.     author: 영문이름 jekyll admin이 버그가 많아서 업로드 기능은 커스터마이징 했다. 루비와 UI코드를 고쳐서 다시 빌드하는 어지러운 작업을 했다.만약 버그를 고치기 어렵다면 IDE로 파일을 직접 수정하는 게 안전하다. 참고 1)마크다운 작성법은 여기를 참고하세요.글천보성 팀장 | R&D 개발2팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유
조회수 2034

칸반(Kanban) 5개월 사용 후기

사실 개발 방법론이라는 것을 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) 시스템을 적용해보는 것입니다. 우리 팀이 어떻게 바뀔지 정말 기대가 됩니다.#비주얼캠프 #인사이트 #경험공유 #조언 #개발자 #개발팀
조회수 1618

[앵커리어랩]연구보고서 개발자 '노선빈'

오늘 만나본 앵커리어의 팀원은!바로 앵커리어의 숨겨진 하드캐리어 개발자 노선빈(a.k.a 메-쓰:수학)군 입니당!컴퓨터와 대화하는 것을 가장 좋아하는 줄 알았던 그와인터뷰를 빌미로 오랜시간 이야기를 나누었습니다!그 결과... 의외로 수다떨기를 좋아하는 타입의 선빈씨!(나 촉 되게 좋아~~~ 선빈씨 다 들켰어~~~)그럼 앵커리어랩 네번째 인터뷰 시작합니다!(ps. 내일(10월 13일)이면 예비군을 떠나시는 선빈씨에게 이 포스팅을 바칩니다! 예비군 화이팅!)INTRO. 인사밍케터) 간단한 자기소개 부탁드려요^^메-쓰) 자기소개? 이럴 수가.어려워요. 아무렇게나 하면 되나요? 양식이..? 음….팀에서 개발을 하고 있으며, Front-end를 맡고 있고, 아주 약간의 Back-end를 맡고 있습니다.밍케터) 임하는 각오는요?메-쓰) 각오는… 각오라기보다는 지금의 마음 상태가 무섭네요.밍케터)) 마케팅팀이 무서우신 건가요?!메-쓰) 아니 아니 아닙니다.인터뷰가 무서운 거죠.아시다시피 저는 말을 많이 하는 사람이 아니라서. 이런 자리가 익숙하지 않죠. 제1장. 안경_★po코딩wer★밍케터) 하시는 일 소개 부탁드려요.메-쓰) 앵커리어에서의 저의 업무!위에서 한 것 같지만, 다시 하죠. 조금 더 구체적으로.웹 사이트를 만들고, 페이지를 구성하는 일을 합니다.디자이너께서 결과물을 만들어 냈을 때,실제로 웹 사이트를 그렇게 보이게 만드는 일을 하고 있습니다. 밍케터) 선빈 씨는 코딩 언제부터 시작하셨나요?메-쓰) 음. 그게 초 6 때죠.대표께서 초 5 때부터 혼자 코딩을 했었어서, 근데 제가 친구 였어서, 저를 꼬셔서,'같이 해보지 않을래?' 해서 하게 됐죠?(선빈씨 음성지원 中)6학년 때 정보 올림피아드 나가고 하면서 컴공과에 가서 프로그래머를 해야겠다라고 생각했었는데, 고등학생때 수학이 재미있어서 물리학과로 진학했습니다.그런데 올해 초에 새해를 맞아 오랜 친구인 대표께 전화를 했는데, ‘새해 복 많이 받아라’라는 말씀과 함께 '개발자 필요한데 같이할래?' 이러셨죠.그래서 올해부터 갑자기 다시 직업으로 삼게 되었습니다.   밍케터) 공백기가 길었는데 감을 잃지는 않으셨나요?메-쓰) 예전이랑 컴퓨터 언어도 다르고 분야도 달라서 “완전 능숙해” 이 정도는 아닙니다.밍케터) 코딩이 가장 즐거운 순간은 언제인가요?메-쓰) 1. 버그 없이 잘 돌아갈 때.2. 어떻게 해야 할지 바로 떠올랐을 때.3. 알 수 없는 버그가 날 괴롭히지 않을 때.밍케터) 물리 vs 코딩. 어떤 것이 더 재미있나요?메-쓰) 물리가 재밌습니다…아 각각의 재미가 다르죠(다급).물리는…..네이쳐를 알아가는 것은 흥미롭잖아요? 안 그렇습니까?밍케터) (.....전 아닌 것 같습니다만….)메-쓰) 개발은 문제를 해결해 나가는 재미가 있습니다. 이런 방식으로 하고 싶은데 이럴 때는 어떻게 해야 할까 같은 문제들이요. 둘 다 재미있습니다. 흥미롭죠. 밍케터) 게임 좋아하신다고 하던데, 인생게임 있나요?메-쓰) 인생게임이라…. 도타라는 게임이 있는데, warcraft3 라는 게임의 mod 같은 건데…밍케터) 그럼 이 인터뷰는 어떠세요? 핵심을 찔러서 평가해주세요.메-쓰) 분위기는 좋습니다. 굉장히 자유롭네요. 자유분방. 편한 분위기. 밍케터) 모드요? 모드…???메-쓰) 스타크래프트를 해봤으면 유즈맵이라고 하면 딱 아실텐데… 뭐 어쨌든.DOTA(‘디-오-티-에이’라고 친절하게 풀어서 읽어주는 선빈 씨)라는 게임이 있습니다. 지금 롤과 같은 장르의 AOS의 시초가 된 게임입니다. 밍케터) 가장 자랑하고 싶은 코딩 결과물 알려주세요.메-쓰) 없으면 안 되는 거죠?밍케터) 웬만하면 있으시면 좋겠습니다.메-쓰) 제가 솔로로 만든 것 중에 ‘오 굉장해. 오 훌륭해’ 이런 것은 없고, 참여한 것 중에 훌륭한 것은 지금 만든 자소설닷컴이죠?개인 작업물 중에 생각나는 것은…예-엣날에 코딩 처음할 때. 야구게임이라고 아시나요?야구게임 프로그램 예시(feat.다른 개발자).jpg고1 때 굉장히 유행했는데 옛날에 하던 코딩이 생각나 심심할 때 만들어서 학교에서 풀었죠.사실 코딩하는 사람들이 보면 굉장히 별거 아닌데 학생들이 “오 신기해. 쩔어. 있어보여” 이랬던 기억이 나네요. 밍케터) 대표님과 친구인지 얼마나 되셨죠?메-쓰) 18년 이죠.밍케터) 네 그리고 초, 중, 고 계속 같이 다니셨고 한 공간에서 코딩하시고...혹시 라이벌 의식…?메-쓰) 아, 전혀 없습니다.저는 예전부터 라이벌 의식 뭐 이런 것을 가져본 적이 없어서. 좀 있었어야 할 것 같은데.밍케터) 근데 굳이 필요가 없어 보이네요. 다 잘하시니까…알아서 좋은 학교에 입학하시고...(...조용히 먼 산을 바라보며 반성하는 마케터들)제2장. 입_난 핵심만 찌른다밍케터) 팀원들이 선빈 씨에 대해 핵심을 찌른다는 평가를 했습니다. 혹시 본인만의 남다른 기준이 있으신가요?메-쓰) 팀에 합류했을 때, 대표님이 저에게 날카로운 평가를 많이 기대하는 것 같았는데... 합류하고 보니 이미 굉장히 잘하는 분이 있으셔서. (조용히 pm님을 쳐다본다.) 서로 뿌듯해하는 하드캐리어들.jpg메-쓰) 하드캐리어 이십니다. 굉장히 날카로운 분이세요.상위 호환이 가능합니다.밍케터) …...네? 상위호환이요? 그게 뭐죠?메-쓰) 음…..밍케터)(상위호환을 이해하지 못하는 것은 나의 잘못일까, 선빈씨의 잘못일까, 고급언어를 사용할 줄 아는 능력의 차이인가….또 다시 먼 산을 바라보는 밍케터...)메-쓰) 여기저기서 쓸 수 있는 성격이라는 말입니다. 더 나으신 분이죠.상위 호환이 가능한 pm님) 선빈씨 시사잡지도 계속 주기적으로 사서 보시잖아요?메-쓰) 주기적이진 않지만 내킬 때…?상위 호환이 가능한 pm님) 주변에 보면 시사 잡지를 구독하는 이공계생을 본 적이 별로 없어요.시사에 관심이 많으신가요? 나아가서 정치 사회적인 부분까지 관심이 많으신가요?메-쓰) 음, 관심이 없진 않죠. ...왜 관심이 생겼을까요?시사주간지는 딱히 주기적으로 사진 않지만 내킬 때 사는데...지하철 편의점 지나다니다 보면 ‘이번 주는 저런 이슈가 있군.. 사볼까?’ 이럴 때 삽니다.뭔가 인생, 삶에 있어서 충실함이 떨어지거나 나태함이 차오를 때?열심히 사는 사람의 느낌을 낼 때 사는 것 같네요.밍케터) 그럼 이 인터뷰는 어떠세요? 핵심을 찔러서 평가해주세요.메-쓰) 분위기는 좋습니다. 굉장히 자유롭네요. 자유분방. 편한 분위기.제3장. 피카츄_개발팀의 핵심멤버밍케터) 선빈 씨 방에는 피카츄 친구들이 많잖아요? 혹시 피카츄가 최.애.캐(최강 애정 캐릭터)인가요?메-쓰)  캐릭터로 말할 것 같으면... 딱히 딱 떠오르는 것은 없습니다.밍케터) (당황… 최.애.캐인줄 알고 질문을 준비했는데…!)메-쓰) 피카츄는 포켓몬에서 상품 제작이 많이 되고 프로모션이 많잖아요?그래서 가보니까 귀여워서 사온거죠.밍케터)그럼 질문을 좀 바꿔서 드립니다.만약 살아있는 피카츄를 얻을 수 있다면 대표님과 피카츄 중 누구를 선택하시겠어요?세상에 단 하나 뿐이고, 100만 볼트도 쓸 줄 아는 피카츄라면?그런데 살아있는 피카츄를 얻으려면 대표님과 연을 끊어야 한다면?메-쓰) 이게 직장이 걸린 문제라서 다른 직장을 찾을 수 있는가가 문제인데요.밍케터) 그럼.. 대표님 자리에 앉아서 일하다가 퇴근할 때면 고개를 돌려 “피카!!!”하고 인사를 해주는 피카츄라면요?퇴근하는 직원들에게 인사하는 대표님_피카츄.jpg상위 호환이 가능한 pm님) 전 피카츄요.인터뷰 당일 대표님께 명품 벨트를 선물받은 문케터 ) 아 저도 피카츄로 하겠습니다. (대표님보다 피카츄)메-쓰) 음… 대표님이 양산에서 잘 살고 계시는 상태에서 연을 끊는 거라면…. 제4장. 마요 시리즈_에너지의 원천밍케터) 선빈 씨의 점심엔 항상 빠지지 않는 것이 있습니다. 한솥 마요네즈 시리즈.특별히 좋아하시는 이유가 있나요?메-쓰) 좋아해서가 아니라 싸서 먹고 있습니다.밍케터) (당황… 마요 시리즈를 좋아하는 줄 알고 질문을 준비했는데…이 인터뷰 호락호락하지 않다)그래도 가장 베스트 마요 하나만 말씀해주세요.인터뷰 당일 대표님께 명품 벨트를 선물받은 문케터 ) 그러지 마요.메-쓰) (무시) 제가 먹어본 것들이 치킨, 치킨샐러드, 닭가슴살 샐러드 등이 있는데 다 그놈이 그놈입니다.재료가 아니라 마요 맛이에요.싼 것을 먹어야 돈을 모을 수 있으니까 싼 걸 먹는 거죠.그래야 건물을 사서 임대를 줄 수 있고 ‘난 이렇게 돈이 많은 남자다’ 이러면서 사치도 부리는 거죠.빅치킨마요를 사 먹는다던가.밍케터) 그럼 우리 점심시간때 빅 치킨마요 사 먹는 분들은 선빈 씨 기준에서 사치 하는 사람이네요? ㅋㅋㅋㅋㅋ인터뷰 당일 대표님께 명품 벨트를 선물받은 문케터 ) 주연 씨? ㅋㅋㅋㅋㅋ상위 호환이 가능한 pm님) 선빈씨 “쟤는 건물 있나?”이러겠네요. ㅋㅋㅋㅋㅋ메-쓰) 최신게임도 풀 옵션으로 돌리고, 뭐 농담이고 돈 많으면 좋잖아요?   밍케터) 평소 과자 간식, 마요 시리즈, 콜라 등등 고칼로리를 즐겨 드시는데 날씬한 몸매 유지 비결이 무엇이죠?메-쓰) 마요가 고칼로리인가요? 먹을 때 칼로리 생각 안 하는데, 왜 살이 안 찔까...많이 안 먹어서 그런 것 아닐까요?저는 사실 먹을 만큼 먹는데 옆에서는 잘 안 먹는다 이런 평이 있긴 하더라고요.메-쓰) 그리고 저는 신체와 관련해서 그런 것을 해보고 싶긴 해요. 마사지? 교정? 교정이겠네요.요가라던가. 필라테스?이것들을 하면 나의 오랜 신체 불균형이 좀 개선되지 않을까 이런 생각이 있습니다.어멋_뒷사람을 못가렸네.jpg  제5장. 키. 손. 팔. 속눈썹… 메이비 전신_가장 자신 있는 부위밍케터) 마지막으로 가장 자신 있는 부위 알려주세요.메-쓰) 부위? 신체? 허….글쎄요.저는 막 몸이 이렇게 자신있는 스타일은 아닌데…그런데 살면서 들어본 신체에 대한 칭찬이 몇 가지가 있는데.밍케터) 몇 가지? (분명 몸이 자신 있는 스타일은 아니라 해놓고 천역덕스러우시군) 메-쓰) 네 몇가지는 누구나 있죠.우선, 키가 크다. 근데 이건 부위라고 하기엔 뭐하네요.왠지 전신을 이야기하는 것 같아서. "너는 손이 이쁘네. 손가락이 이쁘네. 손톱이 이쁘네."이런 이야기도 좀 들어 봤구요. 팔이… 이건 칭찬인지 모르겠지만, "여자들이 원하는 팔 형태네." 아니면 "속눈썹이 기네."  상위 호환이 가능한 pm님) 맞아요. 선빈씨 속눈썹 꼭 찍어야 해. 진짜 길어요. 장난 아니죠.메-쓰) 중학교 때 부터 여자애들이 “어우 속눈썹 굉장하다.” 이런 이야기를 몇 번 들었습니다. 메-쓰) 추가로 다리가 길다 정도?결론. 앵커리어 공식질문 1. 나에게 앵커리어란?뭐. 직장이죠.2. 자소설닷컴을 한 마디로 표현하자면?뭐. 우리 회사 서비스죠.#앵커리어 #팀원소개 #인터뷰 #팀원자랑 #기업문화 #조직문화

기업문화 엿볼 때, 더팀스

로그인

/