스토리 홈

인터뷰

피드

뉴스

조회수 2528

시뮬레이션에서의 Process Mining(프로세스 마이닝) 활용

시뮬레이션은 실제로 실행하기 어려운 실험을 간단히 행하는 모의실험을 뜻하며, 특히 컴퓨터를 이용하여 모의실험을 할 때는 컴퓨터 시뮬레이션이라고 일컬어집니다.  시뮬레이션은 특수한 하드웨어를 사용하는 3D 가상현실이나 비행 시뮬레이션 등 다양한 분야에 사용되고 있으며, 이벤트 중심의 로그를 다루는 프로세스 마이닝에서는 이산 사건 시뮬레이션을 중심으로 연구가 이뤄지고 있습니다.이산사건(discrete event) 시뮬레이션은 시간이 경과함에 따라 시뮬레이션 이 진행되는 것이 아니라 시스템 외부 혹은 내부에서 사건이 발생했을 때만 모델을 실행시킵니다. 이산사건 시뮬레이션에서 사건이란 시스템의 외부 혹은 내부에서 발생하는 추상적인 신호를 말하며, 이산 사건이란 임의의 시각에 불규칙으로 일어나는 사건을 의미합니다.이산 사건 시뮬레이션 모델을 잘 만들기 위해서는 사건 시간과 사건에 대한 정확한 기술이 필요한 데, 이를 위해 프로세스 마이닝이 사용될 수 있습니다.[그림] 프로세스 마이닝 기반의 시뮬레이션 모델 도출 (Discovering Simulation Model, Rozinat et a l., 2009)이것은 기존에 시뮬레이션 모델링이 현실 세계에서의 관찰 및 수작업에 의해 이뤄졌다면, 좀 더 쉽고 정확한 모델링을 위해서는 데이터 기반의 AS-IS 프로세스 파악에 능한 프로세스 마이닝을 사용해 볼 수 있지 않을까 하는 의문에서 출발합니다.아래 표와 같이 프로세스 마이닝과 시뮬레이션은 AS-IS 모델과 TO-BE 모델 각각의 영역에서 서로 보완하는 역할을 담당하고 있습니다. [표] 프로세스 마이닝과 시뮬레이션 단계별 역할 비교단계프로세스 마이닝 (AS-IS)시뮬레이션 (TO-BE)프로세스 설계프로세스 마이닝을 통해 도출한 실제 프로세스 모델을 바탕으로 프로세스 (재)설계다양한 대안 모델에 대한 검증 수행구현 및 실행구현하고자 하는 프로세스 모델의 표준 모델 준수 여부 확인시뮬레이션을 통해 테스트 및 검증 완료된 프로세스 모델 구현모니터링 및 분석표준 모델 준수 모니터링 및 병목 지점, 재작업 구간 분석시뮬레이션을 통한 병목 개선 구간 및 자원 수요 예측, 작업 시간 효율화 효과 분석 이러한 연구들을 바탕으로 최근에는 생산 공정 내 작업 현황 파악 및 성과 측정을 위해 생산 시스템의 이벤트 로그를 저장하고 분석하여, 제조 공정에 대한 시뮬레이션 모델 요소를 도출하려는 연구가 진행되고 있습니다. 이를 통해 프로세스 마이닝에서 찾은 병목 구간 등 문제점을 바탕으로 어떻게 개선할 것인지, 프로세스 변경 혹은 개선이 어떤 결과로 이어질지 What-if 분석을 통해 의사 결정을 위한 예측 방법이 제공되고 있습니다. 시뮬레이션 수행의 결과로 많은 수행 결과가 출력되며, 좀 더 나아가 사건과 이벤트에 대한 상세 기록들이 로그 데이터 형태로 나올 수 있습니다. 시뮬레이션이 가상 현실이라는 관점에서 현실에 대한 프로세스 마이닝 분석은 가상 현실에 대해 마찬가지로 유효합니다. 실제로 시뮬레이션 모델링을 하고 나서 시뮬레이션 모델링이 현실을 반영할 수 있도록 잘 되었는지 검증할 필요가 있는데, 시뮬레이션 로그에 대한 프로세스 마이닝 분석을 통해 해당 프로세스 모델을 도출할 수 있습니다.  얻어진 모델을 현실 세계에서 얻어진 프로세스 모델과 동일한 기준에서 비교하고 이에 대한 차이를 다시 시뮬레이션 모델이 반영하는 순환적 구조를 통해 좀 더 정확한 시뮬레이션 모델을 얻게 됩니다.  [참고 문헌]https://en.wikipedia.org/wiki/Simulation#퍼즐데이터 #개발팀 #개발자 #개발후기 #인사이트
조회수 396

프로그래밍 수업의 모든 것 — 엘리스 코스 매니저 인터뷰.

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

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

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

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]브랜디, 오직 예쁜 옷만
조회수 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#엘리스 #코딩교육 #교육기업 #기업문화 #조직문화 #서비스소개
조회수 6950

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

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

[Buzzvil People] Alan Kim, Senior Software Engineer

 Buzzvil People에서는 다양한 배경과 성격 그리고 생각을 지닌 버즈빌리언들을 한 분 한 분 소개하는 시간을 갖습니다. 어떻게 버즈빌에 최고의 동료들이 모여 최고의 팀을 만들어가고 있는 지 궁금하시다면, 색색깔 다양한 버즈빌리언들 한분 한분의 이야기가 궁금하시다면, Buzzvil People을 주목해주세요.1. 간단한 자기 소개 부탁드립니다. 안녕하세요. 김진언입니다. 영어 이름은 Alan Kim 이고, 현재 버즈빌에서 클라이언트 팀의 리더를 맡고 있습니다. 저는 2002년에 병역 특례로 IT업계에서 근무를 시작했고, 첫 직장에서는 연구소 장비들에 들어가는 소프트웨어 개발을 하다가 그 뒤로 모바일 게임 포팅, 게임 서버 개발 등 지금까지 14년 동안 여러 회사에서 여러가지 업무를 해 왔습니다. 소프트웨어를 만드는 능력이 뛰어난 분들은 워낙 많기 때문에  A급 개발자라고 소개할 수는 없겠지만(^^) 컴파일러 관련 시스템 개발이나 게임, 네비게이션 시스템 등 꼭 APP개발에 국한되지 않은 다양한 경험을 해 왔기 때문에 그런 장점을 살릴 수 있는 부분에서는 나름대로 역할을 하고 있다고 생각합니다.  저는 예전부터 개발자로서 여러가지 경험을 하는 것을 중시해 왔는데요. 그러다보니 임베디드 시스템부터 게임, 게임 서버, PC 툴이나 스마트폰 관련 개발까지 다양한 분야의 경험을 쌓아올 수 있었습니다. 그런데 요즘에는 다양한 경험을 하는 것보다 어떤 개발을 하든지 간에 지켜나가야 하는 기준을 세우는 것이 중요하다는 생각을 많이 하고 있습니다. 그러다 보니 코드 자체 보다는 코드를 작성하는 방식에 대한 고민들을 많이 하게 되는 데요. 최근에는 ‘클린 코드’에 대해 많이 관심을 가지고 있습니다. 요즘에는 과거에 비해 Computing resource나 컴파일러 최적화 등이 눈에 띄게 발전해왔습니다. 따라서 무조건 효율좋은 코드를 짜기보다는 조금 효율은 부족하더라도 Readability가 잘 갖추어진 코드를 짜는게 중요하다는 생각을 하게 되었고 클린코드를 위해 고민해야 하는 모듈화 방법이나 디자인 패턴에 대해서 여러가지로 고민 중입니다. 실제로 저희 팀을 운영할때도 굉장히 강조하고 있는 부분이기도 합니다. 개발 이외의 성격적인 부분으로는 평소에 말수가 적어서 종종 과묵한 사람이라 오해받고는 하는데요. 표현력이 서툴러 말수가 적을 뿐, 다른 분들을 싫어하는 게 아니니 오해하지 않으셨으면 좋겠습니다. ^^  2. 어떻게 버즈빌에 오시게 되셨나요? 버즈빌과의 인연을 설명하려면 먼저 Jay와 슬라이드 조이라는 미국 회사를 말씀 드려야 하는데요. Jay는 인포뱅크라는 회사에서 처음 인연이 시작된 동료인데, Jay가 스타트업을 창업한 후 1년쯤 지난 시점에 저에게 연락이 와서, 같이 일해보자는 제안을 했고 그렇게 슬라이드 조이에 조인했습니다.  그 당시에 저는 인프라웨어라는 회사에서 게임 서버를 개발하고 있었는데요. Jay가 권유했던 그 시기가 마침  진행했던 프로젝트가 완료된 시점이었고, 개발자로서 이런 저런 고민을 하던 시기였습니다. 내가 개발하고 싶은 것, 배워보고 싶은 것, 도전해보고 싶은 것과 같은 부분을 현 회사에서 충족할 수 있느냐에 대한 갈등이 심했던 때 였죠. 원래 저는 직장을 선택함에 있어서 제가 정말 하고 싶은 일인지와 리스크가 크더라도 그 결과를 구성원이 함께 공유할 수 있는 구조를 가지고 있는지를 많이 고민했었는데요. 결혼을 하게 되면서 자연스레 조금 더 안정적인 직장을 찾고 싶어서 들어가게 된 곳이 인프라웨어라는 회사였습니다. 하지만 그곳에서 1년간 문제 없이 일하다보니 안정적인 점은 좋았지만 제 의견이 반영되기 힘들다는 점과 개발과정에서 소통이 중시되지 않는다는 점이 저와는 맞지 않는 부분이라고 생각하고 있었습니다. 그렇기 때문에 좋은 타이밍에 연락이 왔다 생각하여 큰 고민 없이 자연스럽게 합류하게 된 것 같습니다. 물론 미래가 불확실 할 수 있는 스타트업으로 가는 것에 대해서 가족들도 염려했지만 당시 슬라이드 조이를 이루고 있던 멤버들이 정말 훌륭하고 의견들도 잘 맞았기 때문에 슬라이드 조이로의 합류를 결정하게 되었던 것 같습니다. 그 후, 여러가지 우여곡절이 있었지만, 슬라이드 조이도 상당한 성장을 이루었고 마침 좋은 기회로 버즈빌과 합병이 되면서 지금은 버즈빌에서 클라이언트 개발팀의 리더로 근무하게 되었습니다. 3. 버즈빌에서 어떤 업무를 담당하고 계신가요? 현재 클라이언트 팀의 리더를 맡고 있지만, 슬라이드조이에서는 백엔드를 전담했었고 버즈빌에서 근무를 시작할 시점에는 광고 서버쪽을 다뤘기 때문에 아직도 약간의 서버쪽 업무를 병행해 가면서 일하고 있습니다. 차츰 앱 서버를 포함한 백엔드쪽 업무를 줄이고, 클라이언트 팀 리더로서의 업무에 주력하기 위해 일부 업무를 서버 팀 개발자에게 옮기고 있습니다. 버즈빌 클라이언트 팀의 업무가 일반적인 클라이언트 개발과 다른 점이 있다면 단순히 하나의 앱을 개발하는 것이 아니라 stable 한 SDK를 개발해야 한다는 점입니다. 여러 버즈스크린 파트너들의 다양한 개발환경에서 동작되어야 하고, 어떤 상황에서든 항상 동작되어야 하기 때문에 시스템 전반에 걸친 깊은 이해가  이 필요한 일입니다. 때문에 단순히 소프트웨어 개발자 보다는 깊이 연구하고 세밀하게 설계하는 능력을 가진 사람이 필요하고 현재 클라이언트 팀의 경우 그런 사람들로 구성이 되어있다고 생각합니다.   클라이언트 팀의 리더가 되면서 아무래도 개발 자체보다는 팀원들이 개발을 잘 할 수 있도록 하는 환경들에대해 더 많은 고민을 하고 관련 업무들을 하고 있습니다. CI(Continuous Integration)나 개발 프로세스 등 흔히 말하는 DevOps에 관련된 일들을 하고 있습니다. 뿐만 아니라 구현 방식에 대한 최종적인 방향을 결정하는 의사결정이나 개발 과제가 내려오는 과정과 개발이 완료된 과제들에 대해 외부의 팀과 커뮤니케이션이 필요한 사항들을 맡아서 관리하고 있습니다. 4. 스타트업에서 혹은 광고업계에서 일하는 느낌이 어떠세요? 스타트업은 한 사람, 한 사람의 목소리가 회사의 성장에 직접적으로 영향을 줄 수 있다는 점이 큰 매력이라고 생각합니다. 저의 경우에는 게임 서버 개발(수천명 규모), 자동차 관련 TF팀(수백명 규모), 스타트업 두 곳, 또 다른 게임회사(60명 규모) 등 많은 케이스의 회사에서 근무를 해 왔기 때문에 큰 차이를 직접적으로 느낄 수 있었는데요. 저에게 스타트업이란 “회사의 성장에 직접적으로 기여할 수 있는 곳” 입니다. 대부분의 회사는 규모가 커짐에 따라 어쩔 수 없이 여러가지 체계가 도입되고, 문화적으로도 경직화 되는것 같아요. 사원 개인이 회사의 의사 결정에 참여 하기는 정말 어렵고, 위로부터 내려온 결정 사항에 자신의 동의 여부와 관계 없이 일이 하는 경우가 대부분입니다. 개인의 개성은 최소화하고 회사라는 체계의 한 부품으로만 움직이게 되고요. 동기부여 없이 그에 따른 무의미한 업무가 반복되면 회사 생활이 정말 재미 없게 되는 거 같습니다. 예를 들어, 특정 Feature를 개발 함에 있어서도 왜 이 Feature에 대한 개발이 필요한지, 어떤 맥락에서 이 Feature의 구현이 중요한지에 대한 커뮤니케이션 없이 그저 과제만 주어지는 경우는 해당 업무에 대한 흥미를 떨어뜨린다고 생각합니다. 하지만 스타트업의 특성상 다른 팀과의 의사소통이 활발하게 진행될 수 있는 환경이다 보니 같은 일을 하더라도 좀 더 큰 맥락에서 파악하고 내가 하는 일에 대한 의미와 기대효과를 고민해보면서 일 할 수 있다는 것이 장점이라는 생각이 드네요. 5. 이것만큼은 버즈빌이 참 좋다! 어떤 게 있으실까요?  아마 많은 분들도 공감하시겠지만, 회사 일이란 게 혼자 하는 게 아니니만큼 같이 일하는 직원이 어떤 사람이냐에 따라서 자신의 업무에도 영향을 받게 되죠. 일에 대한 열정도 없고, 월급 생각하며 대충 일하는 직원과 같이 일하게 되면 다른 팀원들도 영향을 받게 됩니다. 안 좋은 케이스의 일을 몇 번 겪고 나니 일 할 때는 같이 일하는 사람이 어떤 사람인지에 대해 촉각을 많이 세우게 되었죠. 그런데 제가 지금 버즈빌에 근무한 지 1년 반이 넘은 것 같은데, 처음 입사할 때나 지금이나 여전히 느끼는 점은 버즈빌에는 ‘능력자들’이 정말 많다는 점입니다. 보통 회사에서는 10명 중 1명 있을까 말까 할 정도로 특출난 인재들이 한 곳에 모여있다는 그 부분이 정말 인상적이었어요. 스펙도 스펙이지만 보통 사회 초년생이라 일컫는 어린 나이 임에도 일에 대한 진지한 태도와 전문성, 빠른 일 처리 속도 등 대부분의 직원들이 ‘능력자’라 부르기에 손색이 없을 정도입니다. 그런 직원들과 매일 생활하니 저 또한 분발해야겠다는 생각과 함께 많은 의욕을 얻고 있어요.   또한 개발자로서 느끼는 버즈빌은 제가 일했었던 다른 회사들과 극명하게 차이가 있는 곳이라는 생각이 듭니다. 회사가 평등한 문화를 가지고 있다고 PR을 하는 경우가 많은데 버즈빌 만큼 실제로도 수평적인 문화를 가진 회사는 처음입니다. 개발에 관련된 여러가지 의사결정을 함에 있어서도 서로의 의견을 존중하고 워낙 뛰어난 사람들이 많다보니 서로에게 많은 것들을 배울 수 있는게 좋습니다. 저도 팀장이지만 팀원들에게 여러가지를 물어볼 때도 많고 팀원들 통해 새롭게 배우는 것들도 많구요. 이렇게 뛰어난 사람들도 많이 있고 이런 사람들 간에 서로에게 시너지를 줄 수 있는 좋은 문화를 가지고 있다는 점은 분명 다른 회사에서 찾아보기 힘든 장점이라고 생각합니다. 저는 합병을 통해 입사했기 때문에, 버즈빌이라는 회사에 기대를 많이 하고 합류하게 되었는데요. 그 점에 있어서는 200% 이상 충족되었다고 생각합니다. 구성원 한 사람 한 사람을 믿고 자신의 업무에 집중할 수 있다는 것은 저에게 있어 매우 중요한 의미이기 때문에, 현재 회사 생활이 무척 만족스럽네요. 6. 개인적인 목표나 꿈이 있으신가요? 있다면, 버즈빌에서의 경험이 어떻게 도움이 된다고 생각하시나요? 먼 미래에 대한 목표는 ‘돈 걱정 없는 편안한 노후’고요.(^^)  사실 이런 목표를 늘 생각하면서 살고 있진 않습니다. 미래보다는 현재가 중요하고 단기적인 목표에 최선을 다하는 것에 보람을 느끼는 편입니다. 당장 생각나는 목표는…혼자만의 여행일까요? 예전부터 같은 일상에 지치거나 슬럼프가 올때면 한번씩 여행을 가서 충분히 쉬고 생각도 정리하는 시간을 가졌었는데요. 버즈빌에는 다양한 국적의 직원들이 많다보니 그들의 성장환경과 문화 이야기를 들으면 저도 당장 떠나고 싶은 기분이 들 때가 있어요.  가정이 있다보니 혼자 여행을 가는게 쉽지만은 않고 지난 3월에 회사 워크샵으로 발리를 다녀 온 이후로 더욱 눈치가 보이기는 하지만, 몽골에 배낭여행을 가는게 너무 하고 싶네요. 그리고… 생각만 하고 실천을 잘 못하고 있는 부분이 있는데, ‘영어권 나라로의 이민’을 위해 기반을 마련하는 것 입니다. 영어권 나라들의 경우 대부분이 한국에 비해서 삶의 방식이 자유롭고 틀에 박힌 부분이 적다는 생각이 들더라구요. 제가 느끼기엔 아직까지 우리나라가 여유가 없고 바쁜 느낌이 강하게 들어서 좀더 여유로운 환경에서 생활해 보고 싶다는 꿈이 있습니다. 무엇보다 영어가 중요할텐데, 버즈빌에서는 많은 의사 소통을 영어로 하고 있다보니 생각해 보면 엄청 좋은 기회이지만, 아직까지 영어 사용을 적극적으로 하지 않고 있어서 다시 한번 마음을 다 잡고 시작해 봐야겠습니다.
조회수 1391

원하는 정보를 5초 안에 인지할 수 있게 하자

우리나라에서 웹 서비스가 아이디어에서 출발해 출시되기까지 여러 단계를 거치게 되는데 크게는 기획, 디자인, 개발의 3단계를 거치게 된다고 볼 수 있다. 각 단계별로 세분화된 역할들이 있어도 결국은 각각 기획자, 디자이너, 개발자로 분류된다. 어니스트펀드에서는 그들이 제품개발팀을 이루고 있다.어니스트펀드 제품개발팀나는 그중 개발자로 속하고 퍼블리싱 & 프론트 개발을 하고 있다. 퍼블리싱은 디자이너가 그린 디자인된 화면을 웹페이지용 프로그래밍 언어라고 할 수 있는 HTML과 CSS로 웹 문서화하는 것이고, 프론트 개발은 HTML과 CSS로 만들어진 웹문서를 사용자의 의도/목적에 따라 기능이 동작하도록(주로 데이터 입출력, 예를 들자면 네이버 검색창의 자동 완성이나, 네이버 메인의 다음 뉴스 보기 등) 기능을 개발하는 것이다.어니스트펀드에서는 팀원들이 자신의 지식/경험을 공유하는 브런치 글을 돌아가면서 쓰고 있고 나도 함께하기로 결정하였다. 내가 가치 있게 공유할 수 있는 내용이 무엇인지를 고민하면서 나의 과거 경험들을 생각해보았다.나는 2002년 웹 디자인을 시작으로 퍼블리싱 업무를 겸하다 2004년부터 퍼블리싱 업무를 본격적으로 했고 2011년부터 스타트업에 합류하면서 기획 및 프론트 개발까지 제품 개발에 있어서 서버 개발을 제외한 사용자와 접하는 모든 업무를 두루 경험하였다. 보통 디자인 전공자들은 기획파트로 전업하는 경우가 많지만 나는 프로그래밍 언어로 코드를 작성하는 것이 재미있어 기회가 닿을 때마다 업무 영역을 넓혀왔다.따라서 기획과 디자인, 퍼블리싱, 프론트 개발에 이르는 사용자와 접점이 많은 다양한 업무를 해오면서 경험한 것을 바탕으로, 서비스를 구성하고 화면을 개발하는 데 있어 도움이 되는 유용한 내용을 공유하고자 한다.1. 많을 땐 나눠서 해결하자정보가 많다는 것은 정리 정돈할 물건이 많다는 것과 비슷하게 생각할 수 있다. 물건이 목적에 맞게 정리되지 않으면 찾기 어렵고 정리해놓더라도 쉽게 어질러질 수 있다. 정보도 마찬가지로 목적에 맞게 정리가 안되어 있을 때 이해가 어렵게 되고, 이해가 어려워서 이해를 돕기 위한 불필요한 설명이 덧붙여지다보면 더욱 이해하기 어려운 결과를 낳게 된다. 그렇게 되면 결국 설명하는 말만 늘어나고 고객의 이해는 저편에 남게 된다.웹페이지가 뜨는데 1초, 훑어보는데 3초, 원하는 정보를 캐치하는데 5초로 충분해야 한다. 사용자가 원하는 정보를 5초 안에 캐치하지 못할 정보의 양이라면 정보를 나누는 것이 좋다. 2. 제목을 생략하지 말자목적으로 나누어진 정보를 사용자가 빠르게 캐치할 수 있도록 돕는 가장 중요한 요소는 바로 제목이다. 제목은 본문을 다 읽지 않아도 내용을 어느 정도 짐작할 수 있게 한다. 따라서 훒어보는데 3초라는 의미는 한 페이지의 메뉴와 제목을 훑어보는데 필요한 시간이다. 이런 제목의 중요성 때문에 제목은 직관적이어야 하고 되도록 생략하지 말아야 한다. 생략을 할 때는 제목이 없어도 이해가 가능하며, 생략된 제목을 누구나 유추할 수 있을 경우가 아니면 제목의 생략을 피하도록 한다. 위 캡쳐화면은 네이버 메인 콘텐츠의 일부를 캡처한 이미지다. 네이버 메인 중 제목이 생략된 예는 왼쪽 하단 영역인 '주제형 캐스트'뿐이다. 다른 영역들은 '뉴스스탠드', '쇼핑' 등 제목을 생략하지 않고 노출시키고 있다. 메인 페이지처럼 목적이 다양한 페이지일수록 콘텐츠의 성격을 분명히 알 수 있게 하는 제목은 짧은 시간 안에 원하는 정보를 찾는데 도움을 준다.3. 한눈에 중요 정보를 읽을 수 있게 하자그다음으로는 정보의 배치이다. 해당 정보가 발생한 원인, 결과 등 고객이 인지하는 과정에 기반한 그룹으로 나누는 것이 좋다. 정보를 배치할 때는 개별 정보의 중요도 순서와 왼쪽에서 오른쪽, 위에서 아래로 흘러가는 흐름대로 배치고 중간에 역행하는 구성이 없는 것이 좋다. 국내 대형 인터넷 쇼핑몰의 상품 목록을 보면서 위 설명을 이해할 수 있다.정보 배치에 정답이 있는 것은 아니지만 마치 정답이 있는 것처럼 상품, 제목, 할인율, 가격, 현재 판매현황에 이르는 순서대로 나열하고 있다. 이는 선두업체를 따라 흉내 낸 것이 아니라 이와 같은 구성이 인지하기에 용이하기 때문에 모두 이와 같이 구성했다고 생각한다.   4. 어렵지 않게 보이도록 하자서비스에 대한 정보를 전달하고 나서 우리가 기대하는 바는 고객이 서비스를 이해하고 우리 서비스를 이용하게 하는 것이다. 쇼핑몰에서는 주문을 받는 것일 것이고, 어니스트펀드의 경우는 대출이나 투자를 신청하는 경우이다. 서비스를 이용하게 하려면 고객의 정보를 필수적으로 입력을 받아야 한다. 어니스트펀드의 경우는 대출 및 투자에 대한 금융서비스이기 때문에 더욱 많은 정보를 고객에게 요청한다. 고객의 정보를 웹 상에서 입력을 받을 때는 "폼"이라는 일종의 정형화된 웹페이지 구성항목을 이용하게 되는데 이것은 정형화되어있기 때문에 남들과는 다른 개성적인 방식을 이용하기는 어렵다. 금융서비스의 입력 폼이 아주 쉽지는 않다는 것을 고객들은 여러 다른 서비스를 이용하면서 어느 정도 알고 있다. 그러나 고객이 중간에 포기하지 않고 제대로 서비스 이용을 완료할 수 있도록 어렵지 않게 만들어야 하고, 언제나 경쟁사의 서비스를 확인하고 경쟁사보다는 어려워 보이지 않도록 만들어야 한다.5. 순서는 반드시 지키자순서는 여러 가지가 있다. 입력해야 할 항목이 무엇인지를 알려주는 입력항목 및 입력하는 창(=입력 필드), 입력하는데 필요한 도움말, 입력해야 할 항목들을 나열하고 전송/입력완료 버튼까지의 순서가 곧 정보의 순서이다. 이 중 쉽게 놓치는 부분은 첫 입력 필드에서 입력완료 버튼까지의 여정 중에 연관이 없는 링크나 버튼을 추가하는 경우이다. 이 순서는 디자인상으로는 잘 구분되지 않을 수 있지만, 웹코드 상으로는 100% 지켜져야 하는 순서이고 디자인과 웹코드의 순서가 일치하면 가장 좋은 결과이다.'다음'과 '네이버'의 로그인 영역을 비교해보자면 두 포탈 서비스 모두 메인 검색창에서 탭키로 아이디 입력 칸까지 이동할 수 있지만, 아이디 입력 후 비밀번호를 입력하고 로그인 버튼을 누르기까지의 탭키 이동 경로가 다르다. 다음 로그인 화면네이버 로그인 화면다   음 : 아이디 입력 -> 비밀번호 입력 -> 로그인 버튼 -> 로그인 상태 유지 순서로 이동한다.네이버 : 아이디 입력 -> 비밀번호 입력 -> 로그인 상태 유지 -> IP보안 선택여부 -> 로그인이다.탭키로 입력필드를 이동하는 경우가 곧 웹코드상에서의 각 입력 필드의 순서가 되는데, '다음'과 같은 경우는 아이디/비밀번호 입력 후 로그인에 대한 옵션을 키보드로 선택하기 위해서는 로그인 버튼을 지나쳐야 선택할 수 있다. 로그인에 대한 옵션은 로그인 버튼을 선택하기 전에 나오는 것이 더 자연스럽지 않을까? 눈에 보이는 순서도 중요하지만 각 입력필드의 논리적 우선순위를 지키는 것 또한 중요하다.6. 틀린 부분을 즉시 명확하게 알려주자고객이 언제나 우리가 기대한 값을 입력해주지는 않는다. 이 경우 너무너무 명확하게도 오류가 발생한 시점에 오류가 발생한 지점을 알려주는 것이 필요하다. 10개의 입력필드가 있는데 입력완료 버튼을 누르자마자 10개 항목 구구절절이 맞고 틀리고를 알려주는 것보다는, 오류가 발생한 시점에 알려주는 것이 훨씬 인지가 빠르다. 따라서 오류 항목을 보여주어야 하는 곳은 해당 입력필드의 다음이고 전송 버튼이나 후속 작업 이전이 되는 것이다. 위 캡쳐화면은 어니스트펀드에서 대출을 받고자 할 때 이름과 생년월일을 입력하는 부분이다. 필자는 생년월일 부분에 5월 32일이라고 없는 날짜 정보를 넣었고, 이와 같은 입력 실수는 사용자가 실수를 했다는 것을 시스템이 "정확한 정보를 입력해 주세요"라고 즉시 알려주고 있어 사용자가 입력을 실수하지 않도록 돕고 있다. 웹 페이지를 보는 고객들은 아무런 도움 없이 해당 서비스를 이해하고 이용할 수 있어야 한다. 똑같은 정보라고 하더라도 어떤 순서로 어떻게 보여주느냐에 따라서 인지와 인식은 크게 개선될 수 있다. 하물며 정보까지 가공을 하게 되면 더욱 큰 개선을 이끌어 낼 수 있다. 각자가 맡고 있는 서비스에서 5초 안에 고객이 원하는 정보를 웹 페이지 내에서 바로 인지할 수 있는지를 생각해보고 아니다면 테스트해보고 개선해보자.#어니스트펀드 #개발자 #개발팀 #UX개발 #철학 #인사이트
조회수 2422

코드 커버리지 80% 넘긴 썰

첫번재 코드를 짜기까지2015년 1월이었던 것으로 기억해. 당시 전 회사에서 테스트를 정착시키기 위해서 노력을 하고 있었는데, 사실 잘 되지 않았어. 그래서 혼자 ‘Testing Goat’를 따르며 공부를 하고 있었어. 그때 8퍼센트 이효진 대표와 연락이 닿았고, 초기 개발을 좀 도와 달라는 요청을 받았어. 옳다구나! 실전에 적용해 볼 수 있겠다 생각이 들어서 도와주기로 했지이것이 8퍼센트의 첫번째 commit간단한 기능을 가지고 있어서, TDD를 하면서 unit test와 functional test를 붙여서 전달해줬지. 책에 있는 내용을 열심히 활용해서 코드를 짜긴 했지만, 테스트 코드와 함께 결과물을 전달해서 스스로 뿌듯해했어. 물론 그때까지만 해도 내가 8퍼센트 들어갈 거라고는 생각도 하지 못했지. (사람의 인생이란 참)2015년 PyCon에서 발표테스트 없이 코드를 짜다가, 테스트와 함께 개발을 하다 보니 이게 너무 좋은 거야. 그래서 발표를 해야겠다는 생각을 했어. 그래서 아래 꼭지들을 내용으로 발표를 했어. ㅇ 테스트가 왜 필요할까요? 어떤 테스트가 필요할까요?ㅇ 좋은 테스트란 무엇인가요?ㅇ unittest 소개 및 활용ㅇ 테스트 관련 툴 소개ㅇ 내가 하고 있는 테스팅 과정 소개발표를 준비하면서 팀 단위에서 이런 것들을 제대로 한번 해보면 좋겠다는 생각을 했어. 내가 돌아왔다2015년 11월에 8퍼센트에 CTO로 조인을 하게 되었어. 처음으로 CTO로 일을 하게 된 것이었으니까, 이런저런 꿈에 부풀었지. 그중 하나가 ‘테스팅을 제대로 한번 해보자’라는 생각이었어. 코드를 살펴보니까 뭔가 내가 처음에 작성해서 넘긴 후에도 테스트 코드가 추가된 흔적은 있는데 제대로 동작하고 있는 것 같진 않더라고. 일단 기존에 있던 테스트들을 정리했어. 동작해야 하는 것 들을 정리하고, 필요 없는 것들을 지웠지. 그리고는 git push hook 에 테스팅을 추가했어. unittest가 돌지 않으면 push를 하지 못하도록 해버렸어.당시에는 bitbucket을 쓰고 있기도 했고 특별히 CI툴을 붙이지 않은 상태였어서,  기록이 남아 있지 않더라. 하지만 당시의 코드 커버리지가 한 20% 정도였을 것 같아. 그 뒤로 PR을 통해 코드 리뷰를 할 때에는 테스트가 짜여 있지 않은 경우에는 관련된 테스트를 추가해 달라고 요청을 했어. 하지만 구성원들이 테스트를 편하게 짜게 될 때까지는 꽤 시간이 걸렸어. 특히 unittest.mock, freezegun , fixture 등을 사용해서 테스트 상황을 잘 구성하는 것에 익숙해지는 것에 시간이 걸렸던 것 같아. Travis 의 도입 2016년 1월에 github으로 갈아타면서 travis를 도입했어. 기존에는 push을 할 때마다 전체 테스트를 돌리도록 했었는데, 테스트의 양이 늘어나면서 push의 시간이 오래 걸리는 문제가 있었어. 그래서 travis에서 테스트를 돌리도록 했어. 이제는 테스트가 안 돌아도 push 까지는 할 수 있는데 PR merge는 할 수 없는 상태가 된 거지. 그 이후에는 flake8을 돌려서 스타일 체크를 시작했어. 그래 생각난다. 개발팀에서 하루 날 잡아서 PEP8에 맞춰서 코드들을 수정했어. 그렇게 한 이후에도 수정할 것들이 많이 남아 있어서 모듈 단위로 수정을 하면서 해당 모듈을 추가로 검사할 수 있도록 travis와 commit hook에 추가해 나갔어. 결국 다 정리되긴 하더라. 그리고는 주요 브랜치에 대한 빌드를 깨뜨린 사람이 음료수를 쏘는 규칙을 만들었어. (주요 브랜치가 깨진다는 것은 로컬 환경과 travis 모두에서 테스트를 생략했다는 이야기거든)지금은 github flow  라서 develop branch 는 없어FactoryBoy의 사용테스트가 점점 늘어나서 한 1500개 정도가 되었어. 점점 모델도 많아지게 되면서 fixture로 테스트 데이터를 관리하는데 한계가 왔어. 예를 들면 신용평가를 한번 하면 데이터가 200여개가 쌓이는데, 신용평가 모델에 대한 테스트를 하려면 그것들을 다 fixture로 만들어야 했어. 그래서 개발팀의 한 분(누군지 기억은 안나는데 고마워요)이 FactoryBoy를 추천해 주셨고, 쓰기로 했지. 지금까지 만들어졌던 fixture 들을 모두 factory 기반으로 옮기는 것도 간단하지는 않았어. 하지만 새롭게 만드는 것부터 적용하고 과거 테스트들을 고칠 때마다 조금씩 조금씩 수정을 했더니, 다 고쳐지긴 하더라고. 그 이후로는 새롭게 모델을 만들 때에는 항상 관련된 TestFactory를 함께 만들어 주게 되었어.테스트 커버리지 측정도구 도입이걸 처음에 왜 붙였는지는 잘 모르겠어. 사실 그전까지는 테스트 커버리지를 재미로 측정해 본 적은 있었지만 꾸준히 측정을 해야겠다는 생각을 해보진 못했었거든. 그런데 이 수치가 측정이 되기 시작되면서부터는 많은 것들이 바뀌었어. 처음 측정 했을 때가 63.59%바뀐 게 무엇이냐고 하면, PR에서 '공식적인 잔소리'가 가능해졌어. 이게 테스트를 작성하다 보면 자괴감이 들 때가 있거든. 내가 봤을 때 너무나 자명한 것에 대한 테스트를 작성할 때야. 그런데 이 테스트라는 것이 지금의 내 기준으로 보면 안 되고, 다른 누군가 그리고 혹은 미래의 나를 기준으로 바라봐야 하거든. 그래서 자괴감을 느낄 시간에 그냥 짜야해. 근데 우리가 사람인지라 가끔 나태해 지거든. 나태해 지면...뭐. 나라고 예외는 없지UI 테스트에 대한 좌절처음에 테스트를 시작했을 때에는 selenium을 이용해서 UI에 대한 functional test가 있었어. 그리고 꽤 오랫동안 유지가 되었었지. 그 이후에는 멀티플랫폼에 대한 테스트를 하기 위해서 sauce labs를 통해서 firefox, IE, mobile browser 에 대한 테스트도 자동으로 진행했었어. 그런데 이 테스트는 한번 동작시키는데 시간이 너무 오래 걸리다 보니 로컬 환경에서 테스트가 쉽지 않더라. 그래서 CI환경에서만 테스트를 돌리게 했어. 그랬더니 수정하고 다시 CI에서의 테스트를 위해 push 해야 하고 또 기다리게 되더라고. 이런 어려움 때문에 중단했다, 재개했다, 중단했다, 재개했다를 몇 번 반복한 이후에 지금은 작성하고 있지 않아. 우리 팀의 프런트엔드를 이전 작업이 어느정도 되고 나면, UI 테스트를 꼭 다시 시도해 볼 생각이야.80%의 공약70%가 넘고 나니까 전체 테스트 커버리지를 올리는 것이 쉽지 않았어. 그래서 개발팀에 공약을 하나 걸었지.그날이 금방 올것 같지는 않았어그랬더니 사람들이 코드를 지우기 시작하더라고... 물론 사용되지 않는 코드를 말이야. 그리고 아예 브랜치 이름을 "80percent"라고 만들더니 예전에 테스트 코드를 작성하지 않던 시절의 코드까지 테스트를 붙이기 시작했어. 보이니? 그래프 마지막, 사람들의 욕망이?사실 80%가 특별한 의미가 있는 숫자는 아니야. 그냥 100줄의 코드에서 80줄의 코드가 테스트가 되고 있다는 것이지. 그래도 우리가 2년 동안 테스트를 중요하게 생각하고, 열심히 노력해 온 결과라고 생각하면 좀 뿌듯해. 달성흠. 나는 약속을 중요하게 생각하는 사람이야. 그리고 우리 팀원들은 나보다 더 약속을 중요하게 생각한다는 것을 알게 되었어.  아. 그리고 위 사진에 디자이너 두 분이 있어. 디자이너 분들도 commit 한 코드가 있으니 점심을 먹을 자격이 충분하지. 암암. 그렇지.이렇게 해서 80%를 달성하기까지의 과정을 적어 봤어. 짧은 글에 적혔지만 사실 2년의 시간이 걸렸고 아마 팀원들의 몇천 시간이 들어간 일일 거야. 모두들 고마워~끝!사람들을 낚아 보기 위해서 글 제목을 "~썰"로 지었다가, 평소에 잘 쓰지 않는 스타일의 쓰기 글이 되어 버렸다. 글의 남은 부분에서는 80%를 달성하고 나니 어떤 점이 좋은지 앞으로는 어떤 부분을 잘 하고 싶은지를 추가로 적어 보겠다.테스트를 작성하니까 무엇이 좋은가?테스트를 작성하게 되면 코드리뷰가 더 쉬워진다. 코드를 읽다가 잘 이해가 되지 않으면 테스트 코드를 살펴본다. 작성된 코드는 어떻게 사용되는가? 작성된 코드는 어떤 기능인가? 작성된 코드에서 주의해야 하는 점은 무엇인가? 를 효과적으로 알 수 있다.코드 수정에 자신감이 생긴다. 내가 오래전에 짠 코드, 다른 팀원들이 짠 코드는 수정하기가 무섭다. 특히 우리 회사와 같이 대부분의 코드 수정이 실제 돈의 흐름에 영향을 주는 경우는 더욱 무섭다. 하지만 테스트가 있으면 자신감이 생긴다. (그렇다고 안 무서운 것은 아니다.) 특히 시스템이 복잡해질수록 정적 분석 혹은 QA로 특정 코드에 대한 수정의 영향을 파악하기가 어렵다. 자동화된 테스트 외의 답은 없다고 생각한다. 11월에는 작성한 코드 보다 삭제한 코드가 더 많다. 이렇게 리팩토링이 가능하다.이제 수정하지 못하는 코드는 오래된 코드, 작성자가 퇴사한 코드가 아니라 테스트가 없는 코드가 되었다.테스트가 정착되기까지 키가 된 것은 무엇이었나?자동화를 통한 강제였다고 생각한다. 첫 번째 시점은 git hook을 사용한 시점이었다. commit을 할 때 flake8 체크를 하고 push를 할 때 테스트를 돌려주었다. 사람들은 스타일을 맞추지 않으면 commit을 할 수 없게 되었고, 기존의 테스트를 깨뜨리게 되면 코드를 push 할 수 없게 되었다. 두 번째 시점은 CI툴의 도입이었다. 내가 작성한 코드는 테스트를 통과했지만 maste에 있는 코드와 merge가 된 것을 기준으로 테스팅을 할 수 있게 되었다. 세 번째 시점은 테스트 커버리지 측정이었다. 신규로 작성되는 코드들이 우리가 원하는 수준의 테스트 커버리지를 만족시키는지 확인할 수 있었다. 자동화되지 않은 상태에서 매번 개발자에게 "테스트가 깨졌어요", "테스트를 추가해 주세요.", "여기는 코딩 스타일이 맞지 않아요."라고 말하는 것은 피곤한 일이기도 하고, 장기적으로 보면 동작하지 않는다. 자동화 외의 방법은 없고, 이 자동화된 방법은 새롭게 입사한 사람들이 테스팅에 손쉽게 적응하도록 한다. 앞으로의 테스팅에 대해사실 커버리지가 테스팅의 전부는 아니다. 커버리지만 올리는 의미 없는 테스트도 작성할 수 있다. 하지만 기본적으로는 python이 런타임 시에 다양한 에러를 발생시키기 때문에 어느 정도 이상의 커버리지 테스트는 필수라고 생각한다. 앞으로 주요한 모듈에서는 커버리지를 90% 이상을 맞추고 나머지 영역에 대해서는 80% 이상을 유지할 생각이다. 그리고 테스트의 질은 코드 리뷰로 해결해야 하겠다. 지금 unittest 가 약 3500개 정도 작성되어 있는 상태이다. 이 테스트를 동작시키는데 로컬에서는 약 3분 정도 CI환경에서는 10분 정도가 걸린다. 이 테스트를 기다리는 시간 동안 생산적인 일을 크게 하지 못하는 경향이 있어서 이 시간을 줄이기 위한 노력을 해야 한다. 마지막으로는 프런트엔드에 대한 테스트를 추가해야겠다. 글을 마치며이 글은 나의 눈에서 바라본 것을 기준으로 적었기에 내가 다 한 것처럼 느껴진다. 하지만 전혀 그렇지 않다. 이 모든 작업은 나 혼자 한 것이 아니라 우리 팀이 한 것이다. 더 나은 개발을 목표로 함께 달리고 있는 팀원분들께 감사를 전한다. #8퍼센트 #에잇퍼센트 #개발 #개발팀 #삽질 #팀워크 #팀플레이 #성장 #성과
조회수 1094

클라우드와 운영자의 불안함.

2018년은 정말 클라우드가 일반화되는 해가 될듯 합니다. 클라우드 이전 사업 소식이 이곳저곳에서 들리는 요즘입니다. 스타트업 생태계는 이미 클라우드로 넘어갔지만 올해에는 엔터프라이즈 기업에서 대규모 IT 기업들까지 모두 클라우드로 넘어가고 있습니다. 와탭이 클라우드 최적화를 목표로 하는 모니터링 서비스이다보니 클라우드로 전환하는 시점에 있는 많은 기업들을 만나는데요. 클라우드를 적용하려고 준비중이거나 최근 클라우드로 이전한 기업의 운영팀들은 현업에서 사용하는 과정에서 클라우드 안정성에 대한 불안을 토로하기도 합니다. IT 운영자들이 느끼는 클라우드에 대한 불안감IT 운영의 핵심은 안정화입니다. 클라우드 이전까지 IT 인프라는 변화를 관리하는 대상이 아니였습니다. IT 인프라는 운영중에 변화하지 않으며 초기 설계에서도 최대 부하를 견디기에 충분한 여지를 남겨서 구성하였습니다. 하지만 클라우드에서는 IT 인프라가 운영중에도 변화 가능한 요소가 되면서 IT 인프라 규모 산정에서 부터 커다란 변화가 발생합니다. 최대 부하가 아닌 최소 부하가 규모 산정 기준이 되다. 여지껏 IT 인프라의 구성 기준은 언제나 최대 부하를 견딜수 있도록 설계되어왔습니다. 하지만 IT 인프라를 클라우드로 시작한 스타트업들이 IT 인프라를 구성하는 방법은 기존의 규칙을 무시하기 시작합니다. IT 인프라를 규모를 최소 부하에 맞춰서 구성하는 것입니다. 단지 실시간으로 확장 가능한 서비스 구조와 Auto Scailing을 통해 규모를 맞춰갑니다.IT 인프라 평균 부하의 기준이 높아지다. 클라우드 이전까지 우리는 IT 인프라의 CPU 부하율을 평소 20% 아래로 유지해 왔습니다. 하지만 이 또한 변화가 생깁니다. 제가 만나는 많은 클라우드 기반 서비스 기업들이 CPU 부하율을 50%에서 70%까지 유지하고 있었습니다. 일반적은 운영관점에서 IT 서비스 운영에 익숙하지 않은 기업의 운영 미숙이라 생각할 수 있습니다. 하지만 클라우드에 익숙한 운영팀은 서비스 성능에 문제가 발생하지 않는 범위에서 인프라의 규모를 실시간으로 조절합니다. 기존의 상식으로는 매우 위험해 보이지만 클라우드를 정말 잘 쓰는 기업들은 성능과 안정성을 해치지 않으면서 인프라 자원의 여유를 최대한 줄이는 방법들을 내재화하고 있습니다. IT 인프라 장애를 해결하지 않는다.  모든 IT 인프라는 장애가 발생합니다. 인프라의 장애는 이벤트성으로 발생하지만 운영팀은 장애를 반복 해결해 나가는 과정에서 패턴을 인지하고 대처해 나갑니다. 클라우드에서도 장애는 어쩔수 없이 발생하지만 운영팀은 장애를 인지할 뿐 장애를 물리적으로 해결하지는 않습니다. 대신 클라우드를 사용하는 IT 운영팀은 빠르게 서비스 구성과 환경을 전환하여 서비스를 원활하게 동작시킵니다. 운영자들이 갖는 불안감이 현실이 되다.다시 운영자들의 불안감에 대해서 이야기 해보죠. IT 인프라의 규모를 줄이고 자원 사용률이 평소에서 50%를 넘기는 급박한 사용 환경에서 클라우드 인프라에 장애가 발생해도 할 수 있는 일이 없다는 것은 정말 큰 스트레스를 주는 일입니다. 물론 위에서 설명한 것처럼 클라우드 네이티브한 서비스라면 문제없이 돌아갈 수 있겠지만 기존 레거시를 운영하면서 클라우드로 전환한다면 IT 운영자 입장에서는 앞에 이슈들이 불안감이 아닌 현실이 됩니다. 넷플릭스 7년만에 클라우드 이전을 완료하다.넷플릭스가 클라우드 이전을 결정한것은 2007년이지만 이전을 완료한것은 2016년이였습니다. 이렇게 긴 시간은 투자한 이유에 대해 넷플릭스는 "기존 IDC 기반의 인프라가 가진 문제들을 클라우드로 가져가지 않기 위해서"라고 했지만 다른 한편으로는 클라우드에서 발생하는 문제들을 해결할 수 있는 시스템 구조를 만들기 위해서였습니다. 그렇기 때문에 넷플릭스에서는 클라우드 네이티브 방식을 택하여 사실상 모든 기술을 재구축하고 운영 방식을 근본적으로 바꿨다. 아키텍처 면에서 넷플릭스는 거대한 앱을 수백 개의 마이크로 서비스로 마이그레이션하고 NoSQL 데이터베이스를 사용하여 데이터 모델을 반정규화했다. 예산 승인, 중앙화된 릴리스 관리, 몇 주에 걸친 하드웨어 프로비저닝 주기를 도입해 지속적인 콘텐츠 전달이 가능해졌으며, 느슨하게 결합된 개발운영(DevOps) 환경에서 엔지니어링 팀이 셀프서비스 툴로 독립적인 결정을 내릴 수 있게 되면서 혁신이 가속화되었다. 이 과정에서 새로운 시스템을 여럿 구축해야 했으며, 새로운 기술도 배워야 했다. 넷플릭스가 클라우드 네이티브 기업으로 변신하는 데는 많은 시간과 노력이 필요했지만, 클라우드 마이그레이션을 통해 글로벌 TV 네트워크로서 지속적인 성장을 이뤄나갈 밑거름을 마련할 수 있었다.https://media.netflix.com/ko/company-blog/completing-the-netflix-cloud-migration결론기존의 레거시를 바탕으로 클라우드 마이그레이션을 진행하는 기업들은 클라우드에서 발생하는 다양한 운영 이슈들을 겪을 수 밖에 없습니다. 대부분 클라우드 이전 사업을 진행하는 데 있어서 이전 서비스 성능을 맞추는 데만 집중하다보니 이전 후 운영과정에서 발생하는 많은 문제들은 운영팀이 짊어지게 됩니다. 하지만 이 문제들은 개발팀과 운영팀이 함께 지속적으로 개선해 나가야 합니다. 최종적으로 클라우드 네이티브 구조가 완성되기 위해서는 시스템과 조직 문화 모두가 변화해야 합니다. 클라우드 마이그레이션은 엄청 고난한 일입니다. 만일 클라우드를 도입했는데, 아직 불안함이 있다면 아직 클라우드 마이그레이션이 끝나지 않은것입니다. #와탭랩스 #개발자 #개발팀 #인사이트 #경험공유 #일지
조회수 517

오픈서베이 개발팀이 일하는 법, 개발자에게 직접 들어봤습니다

김경만님은 오픈서베이의 미들레벨 안드로이드 개발자이자 오베이 시스템 PM(이하 조셉)입니다. 지인 추천으로 2명의 개발자 채용을 도운 오픈서베이 전도사기도 하죠. 이런 조셉은 지원할 때만 해도 오픈서베이가 어떤 회사인지 잘 몰랐다고 합니다. 병특 중인데 TO가 있길래 지원한 게 크죠. 그렇게 덜컥 입사한 오픈서베이를 다니며 잘 갖춰진 업무 환경, 조직 문화, 좋은 구성원에 반해버렸다고 합니다. 병특 복무를 마친 뒤에도 오픈서베이의 훌륭한 구성원으로 5년 차 개발자의 커리어를 쌓아가고 있죠. 조셉에게 오픈서베이에 반한 이유와 개발팀의 업무 문화에 대한 이야기를 들어봤습니다.            오픈서베이 김경만(조셉) 안드로이드 개발자 겸 오베이 앱 PM   조셉, 안녕하세요! 안녕하세요(웃음). 오픈서베이의 미드레벨 안드로이드 개발자 조셉입니다. 올해부터는 오베이 앱 PM으로 역할이 확대됐어요. 오베이는 오픈서베이 패널로 활동할 수 있는 설문조사 앱입니다.   세부적으로는 안드로이드 오베이 앱 개발, 오베이 회원계 시스템, 타겟팅 설문을 위한 유저 세그멘테이션 시스템을 개발·운영하고 있어요. 5년 차 개발자로 오픈서베이에는 17년 12월에 입사해서 벌써 1년 반 정도 일하고 있네요.    입사 계기가 독특하더라고요. 고백하자면 그렇죠. 전 직장에서 병특 복무 중에 이직을 결심하고 원티드에서 오픈서베이를 처음 알게 됐어요. 사실 뭐하는 회사인지도 잘 몰랐고 병특 TO가 있으니까 그때부터 찾아본 거예요.  잡플래닛을 검색해보니 ‘리서치 업계의 게임 체인저’라는 리뷰가 뜨더라고요. 실은 그 말이 정확히 무슨 의미인지도 잘 몰랐어요. 그냥 리서치란 단어가 주는 스마트하고 긍정적인 느낌이 있었는데 “그런 리서치 시장의 게임 체인저라니!”라며 면접을 본 거에요.   그럼 오픈서베이를 다니면서 긍정적인 면을 발견하신 거군요. 일단, 개발 업무 환경이 수준급이라 놀랐어요. 규모가 좀 있는 기업에서나 볼 수 있는 인텔리제이(intellij)도 너무 당연하게 구비돼 있더라고요. 이게 꽤 비싼 툴이거든요. 그래서 스타트업은 개발자 채용 공고에 인텔리제이 구매해서 사용한다고 일부러 적어놓기도 할 정도예요.  그런데 오픈서베이는 입사 때 따로 이야기해 주지 않아서 몰랐는데 떡하니 있길래 놀랐죠. whatap, jenkins, graylog 등을 이용한 배포·운영·모니터링 환경도 체계적으로 갖춰져 있었고요.  사실 이런 개발 환경을 갖춘 스타트업은 정말 흔치 않아요. 그래서 많은 개발자 꿈나무들이 큰 기대를 갖고 스타트업에 입사했다가 좌절해요. 앞에선 기술 중심의 혁신을 외치는데 그만큼의 투자가 없거나 여건이 마련돼 있지 않아서요. 여전히 많은 스타트업 개발자가 수작업으로 일일이 버그 모니터링을 하거나 업데이트 배포를 하는 경우도 많아요.  그런데 구비된 툴을 보면서 오픈서베이 개발팀은 생산성을 위한 비용 투자를 아끼지 않고 구조적인 개발 시스템에 노력하는 회사라는 인상을 받았어요. 개발 입문서 같은 데서 정석이라는 시스템을 그대로 갖추고 있으니까 제가 배운 이론을 현장에 바로 적용할 수도 있는 것도 좋았고요.   무엇보다 일에 집중할 수 있는 환경이군요.  이건 좀 개인적이긴 한데, 입사 전에 업무용 랩탑 선택권을 주는 것도 좋았어요. 사실 랩탑은 일할 때 제일 자주 많이 쓰는 도구잖아요. 업무에 가장 중요한 요소라고도 말 할 수도 있는데, 각 랩탑 사양을 정말 세부적으로 알려주고 원하는 걸 직접 선택할 수 있게 해주는 부분도 인상적이었어요.   그런데 후보 중에 제가 꼭 사고 말겠다고 생각했던 꿈의 랩탑 ‘델 XPS 15’이 있더라고요. 벌써 1년 반이나 지났는데 아직도 이 랩탑으로 일할 때는 괜히 기분이 좋아요.    “업무용 랩탑 선택권을 주는 것도 좋았어요. 사실 랩탑은 일할 때 제일 자주 많이 쓰는 도구잖아요.”   세세한 부분에서도 감동을 받으셨군요(웃음). 이렇게 디테일한 요소까지 챙기는 회사의 모습에 감동하는 거죠. 저는 오픈서베이가 3번째 직장이라서, 회사가 업무 환경에 디테일하게 신경 쓰는 게 얼마나 힘든지를 몸소 경험해서 알고 있거든요. 그런 면에서 오픈서베이는 개발 환경도 잘 갖춰져 있고, 업무를 위한 투자도 많고, 배울 사람도 많아요.   원티드에는 오픈서베이가 어떻게 소개되고 있을까요?   여건만 좋다고 다 좋은 회사는 아닐 수 있잖아요. 물론이죠. 근데 오픈서베이는 여건뿐만 아니라 성장 기회가 많아요. 의욕만 있다면 아직 주인을 찾지 못한 일들을 자신의 것으로 만들 수 있죠. 저는 주도적으로 일할 의지가 있는 구성원이 마음껏 역할을 늘려 갈 수 있는 조직이 긍정적인 면이 많다고 생각해요. 하고 싶은 사람이 그 일을 맡는 거니까요.   이런 면은 주니어나 미들레벨 개발자에게는 좋은 성장 기회가 되는 것 같아요. 제가 오베이 안드로이드 개발자에서 PM으로 역할이 확대되는 과정도 그랬어요. 처음에는 진짜 딱 개발만 했거든요. 운영 장애가 생겨도 저는 제가 개발한 요소의 코드만 아니까 다른 분야는 해결법도 모르고 제 역할도 아니니까 어쩔 줄 몰라 하며 지켜만 봤어요.  그런데 매번 아무것도 할 수 없는 상황에 놓이니까 제가 직접 문제를 해결할 수 있는 사람이 되고 싶어졌어요. 그때부터 오베이 앱 관련 코드를 다 까보면서 시스템 흐름을 파악했고, 장애가 발생했을 때 제가 해결할 수 있는 범위를 차근차근 늘려갔어요. 나중에는 노후한 시스템을 제가 만든 시스템으로 교체까지 했고요. 그러다 오픈서베이 CTO인 폴의 제안으로 올해부터 PM을 맡게 됐습니다.    조셉이 오베이 PM이 된 배경에는 그런 성장 스토리가 있었군요! 주도적으로 일하는 경험은 다른 회사에선 쉽게 얻기 힘든 기회라는 점은 정말 동의해요. 맞아요. 빠른 성장을 원하는 분에게 지금 오픈서베이는 딱 좋은 규모의 회사인 것 같아요.  정말 개발 인력이 적고 여건이 좋지 않아서 어쩔 수 없이 역할을 확대한 게 아니라, 좋은 여건과 환경에서도 빠르게 역할을 확대할 수 있는 단계에 이른 것 같아서요. 더 규모가 크고 탄탄한 회사에서는 사실 주도적으로 일하고 싶어도 환경이 따라주지 않는 경우도 많으니까요.  물론, 역량과 성취에 따라 합당한 보상을 해줘야 구성원들이 적극적이고 주도적으로 일하고 싶은 의욕이 생긴다는 생각도 하는데요. 제 경험에 비춰보면 오픈서베이는 일이 늘어나는 만큼 보상도 확실한 것 같아요(웃음).    “주도적으로 일할 의지가 있는 구성원이 마음껏 역할을 늘려 갈 수 있는 조직이 좋아요. 하고 싶은 사람이 그 일을 맡는 거니까요”     그런 좋은 경험 덕에 병특 이후에도 오픈서베이를 지켜주시는 거군요. 잘 몰랐는데 병특 복무가 끝나면 곧장 이직하는 게 훨씬 흔하다면서요?  맞아요. 더이상 그 회사에 묶여 있을 필요가 없으니 더 처우 좋은 회사를 찾아 떠나는 거죠. 저는 일부러 남았다기보다는 딱히 이직할 이유가 없어서 이직을 고려하지 않았다는 게 맞는 말인 것 같아요. 개발 업무 환경도 잘 갖춰져 있고 회사도 성장하고 있고, 무엇보다 보상 기준도 체계적이라고 생각하니까요.   보상 기준이 체계적이라고 생각하는 이유가 있나요? 개발팀에서 상하반기를 나눠서 1년에 2번씩 이뤄지는 성장진단을 해요. 단순한 연봉 협상이 아니라 정말로 제가 한 일을 돌아보면서 얼마나 성장했고 성취를 이뤘는지 상급자와 점검해보는 시간이에요. 사실 전 제 개인 블로그에 매달 1번씩 업무 성과 회고를 하거든요. 아무래도 명확한 독자가 없으니까 좀 캐주얼하게 쓰는 편이에요. 근데 회사 성장진단 문서는 내용은 같아도 독자가 다르니까 자연스럽게 자기객관화를 하면서 성과와 시행착오를 정리할 수 있는 시간이라 좋더라고요. 특히, 폴(이건노 CTO)은 이스트소프트에서 개발 조직을 오래 리딩하셔서 확실히 조언의 깊이가 달라요. 저는 아무래도 시야가 아직 넓지 않아서 개발 업무를 성능과 기술 중심으로만 대해요. 그런데 폴은 방대한 시각으로 비즈니스나 운영 관점에서 서비스가 확장될 때를 미리 계산해서 조언을 해주셔서 좋았습니다.   오픈서베이와 스타트업 얼라이언스가 함께한 ‘2018 스타트업 트렌드 리포트’를 보면, 재직자들이 스타트업에 가장 만족하는 요인은 ‘빠르고 유연한 의사결정 구조’였어요. 조셉 생각에 오픈서베이는 어떤가요? 자의적으로 해석할 여지가 많은 요소네요. 빠르고 유연한 의사결정 구조를 개발자 맘대로 하는 거라고 생각할 수 있으니까요. 그렇게 생각한다면 오픈서베이는 전혀 그런 회사는 아닌 것 같아요. 모든 의사결정은 전후 사정이나 논리적인 타당성을 따져보고 함께 결정하니까요.  대신 결정할 사안에 대한 논의는 정말 빠르고 유연하게 이뤄져요. 최고 결정권자인 하이(황희영 대표이사)와 논의가 필요하다고 생각되면 물어봐서 일정만 잡으면 얼마든지 1:1 미팅을 할 수 있어요. 대표실이 따로 있는 게 아니라 한 공간에서 같이 일하니까 몇초 걸어가서 바로 물을 수도 있고요. 대표이사와 이렇게 쉽게 이야기 나눌 수 있다는 점도 오픈서베이의 장점이죠.    “빠르고 유연한 의사결정 구조를 개발자 맘대로 하는 거라고 생각한다면, 오픈서베이는 그런 회사는 아니예요. 모든 의사결정은 전후 사정이나 논리적인 타당성을 따져보고 함께 결정하니까요.”   업무 영역을 넓힐 기회뿐만 아니라 발언 기회도 열려있다는 의미일까요? 정확해요. 개발팀에 ‘세미나’라는 제도가 있어요. 주간 회의와 별도로 팀에 공유하고 싶은 내용이 있는 구성원이 자발적으로 발표를 하는 시간이에요. 특정 프로젝트를 하면서 깨달은 점이나 노하우를 공유하는 식이죠. 저는 이런 세미나가 특히 주니어에게는 아주 좋은 발언 기회라고 생각해요.  사실 작년에 제가 ReactiveX와 Reactive System을 좋아해서 공부하고 있었어요. 당연히 오픈서베이 개발팀에도 도입하고 싶었죠. 근데 팀에 리액티브X를 다루던 분이 없어서 도입 시 이득에 대한 공감대가 없었어요. 그래서 세미나를 활용해서 , <리액티브 시스템으로 설문 서비스 구축하기>라는 주제로 두 차례 발표했어요.  당시에는 발표한다고 진짜 리액티브 시스템을 도입할 수 있을까 생각했어요. ‘필요하니 돈 내고 사자!’라며 간단히 설득할 수 있는 사안이 아니었거든요. 리액티브 시스템은 말하자면 개발 패러다임, 업무 방법론이에요. 개발 업무를 아무도 하지 않았던 새로운 방법으로 바꾸자는 얘기니까 팀 차원에서는 훨씬 복잡하고 신중한 의사결정이 필요한 사안이었죠.    조셉에게 세미나는 그런 중요한 사안을 건의할 기회의 장이었군요. 결국 도입은 성공했나요? 네(웃음). 덕분에 오베이 앱은 RxJava를 활용해 개발했어요. 이후 설문 서비스 개발을 담당하는 테리(이한별 개발자)는 리액티브한 방식으로 내부 파일 관리 시스템을 만들었어요. 정말로 저 혼자만 아니라 팀에서도 활용 가능한 개발 방법론이 된 거죠. 생각해보면 입사한 지 1년도 안 된 개발자가 팀에 새로운 업무 방법론을 도입하자는 발언권을 가질 수 있다는 점 자체가 오픈서베이 개발팀의 업무 문화와 일하는 방법을 단적으로 보여주는 예시 아닐까 싶어요.    마지막으로 오픈서베이의 예비 구성원분들께 한마디 부탁드립니다.  저는 오픈서베이를 다니면서 좋은 구성원들에게 자극을 받고 더 성장하기 위해 노력하게 된 것 같아요. 사실 제가 학창시절 때 꿈이 프로게이머였을 정도로 게임을 좋아해요. 회사 다니면서도 다른 시간 다 줄여도 게임하는 시간은 못 줄였을 정도로요.  그런데 좋은 업무 환경과 동료들, 성장 기회, 그리고 확실한 보상까지 고루 갖춘 회사에 다녀보니 더 좋은 사람이 되고 싶다는 생각이 들더라고요. 다른 동료들처럼 훌륭한 사람이 되고 싶어서 말이죠. 그래서 요즘은 그 좋아하던 게임도 접어두고 자기 계발에 몰두하고 있어요.  단순히 높은 연봉이나 좋은 복지가 아니라 함께 성장하고 싶은 예비 구성원분들의 많은 지원을 기대합니다!      “조셉과 함께 일하고 싶으시다면 지금 바로 오픈서베이 입사 지원을 해보세요”  

기업문화 엿볼 때, 더팀스

로그인

/