스토리 홈

인터뷰

피드

뉴스

조회수 1950

푸른밤의 스프린트 정의와 리뷰/킥오프

오늘은 저희 팀에서 스프린트 진행하는 방법에 대한 포스팅을 올립니다. 다루고자 하는 주제는 다음과 같고요. 하나의 글로 적기에는 호흡이 길 것 같아서 몇 개의 글로 쪼갤 생각입니다.스프린트에 대한 정의(@푸른밤)스프린트 리뷰와 킥오프에서 하는 일스프린트 기간 동안 PM이 하는 일스프린트의 일정 관리 툴: 트렐로스프린트 기간 동안 하는 일들스프린트 정의스프린트라는 용어는 다소 광범위하고 모호하게 사용됩니다. 특히나 이터레이션과 스프린트의 구분은 애매한 감이 있습니다. 제가 링크해 놓은 XP 모임의 Kay Kim(김기웅)님의 대답이 가장 사전적으로 정확한 구분이라고 생각됩니다.스프린트는 스크럼에서 개발주기(iteration)을 일컫는 용어입니다. 스프린트라는 표현을 사용하는 이유는 스크럼 자체가 럭비의 은유법을 사용하고 있기 때문입니다. (짧은 거리의)”전력 질주”. 보통은 그 와중에 상대편(예: 변화)에서 태클 당하고, 공이 바깥으로 나갈 경우, 스크럼을 다시 짜고 경기를 다시 시작합니다. 그리고 다시 전력 질주를 하겠죠.이제 푸른밤의 제약 조건 몇가지를 설명하고 제가 어떤 식으로 스프린트를 정의하고 사용하는지 적겠습니다.본격 성장 중인 회사: 가장 큰 조건입니다.-_-;; 본격적으로 성장 가도의 초입을 지나고 있습니다. 이 얘기는 long-term, mid-term의 Goal이 자주 바뀐다는 의미를 가지기도 합니다.Paid SaaS(Sofrware as a Service) 서비스 알밤: 일단 가장 기본은 돈을 받고 서비스를 제공하는 SaaS를 하고 있습니다. 이 얘기는 Paid Customer와 연결되어서 핫픽스로 처리해야 하는 일이 무조건 발생한다는 뜻입니다.3개의 모바일 프로덕트(양 OS 다 제공함), 2개의 PC웹 프로덕트(IE 9.0부터 지원), 1개의 백오피스로 구성된 제품 라인업: 각 제품별 업데이트가 일치하는 것이 꽤 중요한 조건입니다. 그러면 개발 주기 설정 자체가 상당히 어렵습니다.B2B, B2C 고객의 공존: 정확한 용어가 될 수 있을지 모르겠지만 제품 판매 단위가 1인 고객과 100+인 고객이 공존합니다. 그리고 각 고객의 특성도 굉장히 다릅니다.이런 제약 조건 속에서 제품 개발을 진행하는데요. 싱글 프로덕 구조에서는 발생하지 않는 이슈가 멀티 프로덕 구조에서는 굉장히 많다는 것을 푸른밤에서 PM 역할을 하면서 점점 알게 됩니다.-_-;이러다보니까 저는 사업상 필요한 mid-term Goal을 달성하기 위한 기간을 iteration으로 먼저 잡습니다. 그래서 제품 개발 담당자들(기획/디자인/엔지니어링)에게 mid-term Goal을 공유한 다음, 그것의 Due date에 대해서 공유합니다. 이 때는 이 부분을 명확하게 말합니다.X까지 이 일들을 다 끝내야 합니다. 이건 양보할 수 없는 것이며, 이 일을 달성하기 위한 자원들을 확보할 예정입니다.그 다음에 각 mid-term Goal의 달성을 위한 short-term Goal을 다시 설정합니다. 그래서 각 short-term Goal 달성을 목표로 전력질주하는 스프린트를 만듭니다. 하지만 단순히 short-term Goal만으로 스프린트를 만드는 것은 아닙니다. 조직 구조, 개발 방법, 각 구성원의 R&R, 업무 프로토콜 등도 스프린트 정의의 변수이기도 합니다.우사인볼트의 스프린트통상적으로는 2주 정도의 기간으로 스프린트를 설정합니다. 그리고 스프린트를 처음 시작할 때, short-term Goal들을 공유합니다. 또한 필요하다면 mid-term 단위의 변화 가능성들에 대해서도 공유합니다.결국 이런 모든 것들을 요약해서 내린 푸른밤의 스프린트 정의는 다음과 같습니다.“mid-term 단위의 사업적 목표 달성을 위한 제품 목표를 달성하기 위한 제품 개발 단위 중 가장 작은 unit으로 하나의 합의된 업무 프로토콜을 가진다.”스프린트 리뷰와 킥오프에서 하는 일저희의 스프린트는 통상적으로 리뷰와 킥오프를 겹쳐서 진행합니다. 그러다보니 다음과 같은 일이 각 스프린트의 끝과 시작의 겹치는 시점에서 진행됩니다.현재 스프린트에서 목표했던 Goal들과 달성된 Goal 사이의 갭을 측정합니다. 보통 이 작업은 저 혼자서 진행합니다. 그렇게 하는 이유는 제가 스프린트의 Goal 리스트업의 초안을 만들기 때문이며, 팀원들이 충분히 노력했음에도 스프린트 goal 달성이 부족했다면 그건 전적으로 제 책임이기 때문입니다. 저 역시 팀원들에 대한 현실적인 판단을 해야 하기 때문에 이런 일들이 필요합니다. 단 이것과 관련해서 팀원들에게 문제가 있다면 이 부분은 정리했다가 다시 개별로 논의를 진행합니다.지난 스프린트의 문제들에 대해서 논의합니다. 전 대안 없는 비판/blame 모두 허용해야 한다는 입장인데요. 문제를 같이 해결하는 것이 팀으로 일하는 이유 중 하나라고 생각하기에, 그냥 뭐든 불만을 다 얘기하라고 합니다.자주 하진 않지만 스프린트 시작 시점에 현재 회사의 사업적인 상황을 공유하고 이를 제품 단위의 과업과 연결해서 설명합니다. 단 기존 스프린트 킥오프 때의 상황과 동일하다면 그냥 스킵합니다.이런 키노트를 합니다이번 스프린트의 목표와 지켜야 할 프로토콜에 대해서 공유합니다. 주니어급들은 그나마 습관이 좀 적어서 보통 프로토콜에 빨리 적응합니다. 하지만 시니어들은 이미 고착화 된 습관을 고치면서 프로토콜에 적응해야 합니다. 그래서 프로토콜 적응을 잘 못 하는 분들에겐 한 번 더 강조합니다.장문의 업무 프로토콜정리하며확실히 글이 길어질 수 밖에 없는 주제입니다. 사실 각 사안에 대해서도 많은 고민을 거친 것이라 별도의 글이 나올 수 있습니다.-_-;; 일단 이 정도로만 정리하고, 다음 글에서 다음 사항들을 적어볼까 합니다.푸른밤의 스프린트 프로토콜과 이런 프로토콜이 도입된 이유스프린트 기간 동안 PM이 하는 일스프린트의 일정 관리 툴: 트렐로이 정도의 주제를 정리해도 꽤 긴 글이 될 것 같네요. 꼭 다음 글에서 봤으면 좋겠습니다.네. 제가 글을 꼭 쓰길 바랍니다.ㅜㅠ#푸른밤 #프로토콜 #업무환경 #업무프로세스 #사내문화 #조직문화 #시스템구축 #인사이트 #경험공유 #일지
조회수 1815

LG전자 직무를 알면 합격이 보인다

많은 취준생들이 대기업에 입사하려고 하는 이유는 수백 개의 작은 회사들을 모아 놓은 것처럼 다양한 부서가 존재하고 그 많은 부서들이 하나의 지붕 아래에 있기 때문에 서로 협업을 하면서 경력의 폭을 넓힐 수 있다는 점을 손꼽을 수 있을 텐데요.10월은 많은 기업들이 하반기 공채 신입 사원 면접을 보는 시기입니다. 성공적인 면접을 위해서는 기본적으로 취업하고자 하는 회사 안에 어떤 부서들이 있는지 사전 학습을 하고, 각 부서의 특성을 잘 이해하는 것이 매우 중요하답니다. 면접관들 앞에서 지원 부서와 자신의 경력을 자연스럽게 연결시켜 답변한다면, 적임자로 인식해 뽑힐 확률이 높아질 것입니다.오늘은 LG전자 입사를 희망하는 후배들을 위해 자신의 평생 커리어의 첫걸음이 되는 부서 선택 방법에 대한 이야기를 해보고자 합니다. 특히, 부서 선택은 ‘순간의 선택이 평생을 좌우한다’라는 말처럼 첫 부서의 선택이 평생 커리어를 좌우한다고 해도 과언이 아닙니다.LG전자 직무 부서LG전자의 직군을 크게 나누면 R&D SW, R&D HW, R&D 기구개발, Marketing, Sales, Production 등으로 구성되어 있습니다. 각 직군들은 유기적으로 연계되어 있으며, 소비자들에게 완성품이 최종 전달될 때까지 전 과정에 걸쳐 다양한 전략, 기획, 관리 조직들이 존재하고 있습니다.오늘은 전략, 기획, R&D 조직을 좀 더 자세하게 설명드리고자 합니다. 모든 일이란 사람의 몸처럼 유기적으로 엮여 함께 고민해 만들어 가는 것이지만, 피라미드 방식으로 크게 3 단계로 구분해 볼 수 있습니다.상위에는 회사가 무엇(포트폴리오)을 하고, 어느 방향으로 나가야 할지에 대해 고민하는 ‘전략’과 중간에는 실행단의 R&D가 전략에 맞춰 올바른 방향으로 잘 나아갈 수 있도록 지원하고 가능하게 하는 ‘기획’, 하단에는 연구를 기초로 하여 상품을 개발하는 ‘R&D’ 분야로 나눌 수 있습니다.1. 회사의 브레인 집합소, 전략기획 부서 전략기획 부서는 경영전략, 기술전략, 마케팅전략, 생산전략, 구매전략, CS전략 등 기능별로 세분화되어 있습니다.‘전략기획’이 회사의 포지셔닝과 어떤 방향으로 나아갈지를 고민한다면, ‘경영전략’은 회사 내부의 예산/배분 등 살림살이를 책임지는 전략을 말합니다.또한, LG전자와 같은 IT기업은 중장기적인 관점에서 원천 기술 및 신기술을 발굴하기 위해 어떤 분야에 어떻게 체계적으로 준비를 해나갈지 고민하는 ‘기술전략’ 부서도 있습니다.이 외에도 전략 직무에는 특정 휴대폰, 가전 등 사업별로 구체적인 방향을 제시하는 ‘사업전략’, 소비자들에게 제품 홍보 외에 제품들이 어떻게 회사 고유의 아이덴티티를 유지하며 서로 간에 시너지를 낼 수 있을지 고민하는 ‘마케팅전략’, 전 세계 소비자들에게 제품을 원활하게 공급하기 위해 생산 및 거점을 고민하는 ‘생산전략’, 부품 조달과 협력사 간의 협업이 차질 없이 진행되도록 긴밀한 파트너십을 형성하는 ‘구매전략’, 제품 출시 후 소비자들의 불편한 점을 신속하게 받아들이고, 제품 개선에 대해 고민하는 ‘CS전략’ 등이 있습니다. 참 많은 전략 부서가 있죠? ^^* LG전자 직무 전체 보기 2. 폭넓은 업무 경험을 쌓을 수 있는 기획 부서참고로 전략과 기획 부서는 칼로 무 자르듯이 명확하게 나눠져 있지 않습니다. 기획부서는 실제 수행 주체들의 현황과 진척 사항을 파악하고, 올바른 전략 방향에 맞춰 운영될 수 있도록 구체적인 계획을 세우는 것이라고 보면 됩니다.기획팀은 실제 실행 주체가 존재하는 조직에서 조직 전반에 대해 대표 창구가 되다 보니 수많은 부서들과 업무 협의를 진행하게 됩니다. 그로 인해 기획팀은 기술, 재경, 인사, 생산, 마케팅 등 폭넓은 업무 경험과 인맥을 형성할 수 있다는 장점을 갖고 있습니다.3. 시장을 선도하는 R&D 부서마지막으로 실행 주체라고 불리는 곳이 바로 R&D(Research& Development) 부서입니다. R&D 부서는 회사 내 매우 중추적인 역할을 하는 곳으로 기획과 R&D가 묘하게 섞여 있습니다. R&D에는 실제 개발을 하는 부서도 있지만, 기술을 발굴해 제품에 적용하는 기획 부서도 있어 R&D의 전 프로세스를 경험할 수 있는 장점이 있는 곳입니다.최근에는 프로젝트를 총괄하는 ‘프로젝트 매니저(PM)’의 역할이 점점 중요해지고 있는데요. 그 이유로는 PM이 기술의 단순 진행을 관리하기보다는 비즈니스 관점에서 해당 기술의 가치와 출시 시기를 지속적으로 고민하는 역할을 하기 때문입니다.l LG전자 연구소 현황지금까지 부서를 크게 세 곳으로 나눠서 설명드렸는데요. 이해가 되시나요?^^간단히 요약하면, 기획은 전략, 운영(기획), 실행 관점에서 나뉘고 부서는 업무 기능별로 굉장히 세분화되어 존재한다는 것을 항상 기억하세요. 자신의 첫 출발점을 어디로 삼아 나의 미래의 모습을 만들어갈지 사전에 충분히 고민한 후 면접에 임하면 좋은 결과가 있을 것 같습니다.이 글을 읽고 도움이 조금이나마 보탬이 되어 후배 사원으로 다시 만나 뵙기를 바라며, 합격을 기원하도록 하겠습니다. 감사합니다.#LG #LG그룹 #LG전자 #2016채용 #LG전자_직무 #직무정보 #직무소개 #면접 #면접_팁 #채용 #LG채용정보 #LG공채
조회수 3140

Attention is all you need paper 뽀개기

이번 포스팅에서는 포자랩스에서 핵심적으로 쓰고 있는 모델인 transformer의 논문을 요약하면서 추가적인 기법들도 설명드리겠습니다.Why?Long-term dependency problemsequence data를 처리하기 위해 이전까지 많이 쓰이던 model은 recurrent model이었습니다. recurrent model은 t번째에 대한 output을 만들기 위해, t번째 input과 t-1번째 hidden state를 이용했습니다. 이렇게 한다면 자연스럽게 문장의 순차적인 특성이 유지됩니다. 문장을 쓸 때 뒤의 단어부터 쓰지 않고 처음부터 차례차례 쓰는 것과 마찬가지인것입니다.하지만 recurrent model의 경우 많은 개선점이 있었음에도 long-term dependency에 취약하다는 단점이 있었습니다. 예를 들어, “저는 언어학을 좋아하고, 인공지능중에서도 딥러닝을 배우고 있고 자연어 처리에 관심이 많습니다.”라는 문장을 만드는 게 model의 task라고 해봅시다. 이때 ‘자연어’라는 단어를 만드는데 ‘언어학’이라는 단어는 중요한 단서입니다.그러나, 두 단어 사이의 거리가 가깝지 않으므로 model은 앞의 ‘언어학’이라는 단어를 이용해 자연어’라는 단어를 만들지 못하고, 언어학 보다 가까운 단어인 ‘딥러닝’을 보고 ‘이미지’를 만들 수도 있는 거죠. 이처럼, 어떤 정보와 다른 정보 사이의 거리가 멀 때 해당 정보를 이용하지 못하는 것이 long-term dependency problem입니다.recurrent model은 순차적인 특성이 유지되는 뛰어난 장점이 있었음에도, long-term dependency problem이라는 단점을 가지고 있었습니다.이와 달리 transformer는 recurrence를 사용하지 않고 대신 attention mechanism만을 사용해 input과 output의 dependency를 포착해냈습니다.Parallelizationrecurrent model은 학습 시, t번째 hidden state를 얻기 위해서 t-1번째 hidden state가 필요했습니다. 즉, 순서대로 계산될 필요가 있었습니다. 그래서 병렬 처리를 할 수 없었고 계산 속도가 느렸습니다.하지만 transformer에서는 학습 시 encoder에서는 각각의 position에 대해, 즉 각각의 단어에 대해 attention을 해주기만 하고, decoder에서는 masking 기법을 이용해 병렬 처리가 가능하게 됩니다. (masking이 어떤 것인지는 이후에 설명해 드리겠습니다)Model ArchitectureEncoder and Decoder structureencoder는 input sequence (x1,...,xn)<math>(x1,...,xn)</math>에 대해 다른 representation인 z=(z1,...,zn)<math>z=(z1,...,zn)</math>으로 바꿔줍니다.decoder는 z를 받아, output sequence (y1,...,yn)<math>(y1,...,yn)</math>를 하나씩 만들어냅니다.각각의 step에서 다음 symbol을 만들 때 이전에 만들어진 output(symbol)을 이용합니다. 예를 들어, “저는 사람입니다.”라는 문장에서 ‘사람입니다’를 만들 때, ‘저는’이라는 symbol을 이용하는 거죠. 이런 특성을 auto-regressive 하다고 합니다.Encoder and Decoder stacksEncoderN개의 동일한 layer로 구성돼 있습니다. input $x$가 첫 번째 layer에 들어가게 되고, layer(x)<math>layer(x)</math>가 다시 layer에 들어가는 식입니다.그리고 각각의 layer는 두 개의 sub-layer, multi-head self-attention mechanism과 position-wise fully connected feed-forward network를 가지고 있습니다.이때 두 개의 sub-layer에 residual connection을 이용합니다. residual connection은 input을 output으로 그대로 전달하는 것을 말합니다. 이때 sub-layer의 output dimension을 embedding dimension과 맞춰줍니다. x+Sublayer(x)<math>x+Sublayer(x)</math>를 하기 위해서, 즉 residual connection을 하기 위해서는 두 값의 차원을 맞춰줄 필요가 있습니다. 그 후에 layer normalization을 적용합니다.Decoder역시 N개의 동일한 layer로 이루어져 있습니다.encoder와 달리 encoder의 결과에 multi-head attention을 수행할 sub-layer를 추가합니다.마찬가지로 sub-layer에 residual connection을 사용한 뒤, layer normalization을 해줍니다.decoder에서는 encoder와 달리 순차적으로 결과를 만들어내야 하기 때문에, self-attention을 변형합니다. 바로 masking을 해주는 것이죠. masking을 통해, position i<math>i</math> 보다 이후에 있는 position에 attention을 주지 못하게 합니다. 즉, position i<math>i</math>에 대한 예측은 미리 알고 있는 output들에만 의존을 하는 것입니다.위의 예시를 보면, a를 예측할 때는 a이후에 있는 b,c에는 attention이 주어지지 않는 것입니다. 그리고 b를 예측할 때는 b이전에 있는 a만 attention이 주어질 수 있고 이후에 있는 c는 attention이 주어지지 않는 것이죠.Embeddings and Softmaxembedding 값을 고정시키지 않고, 학습을 하면서 embedding값이 변경되는 learned embedding을 사용했습니다. 이때 input과 output은 같은 embedding layer를 사용합니다.또한 decoder output을 다음 token의 확률로 바꾸기 위해 learned linear transformation과 softmax function을 사용했습니다. learned linear transformation을 사용했다는 것은 decoder output에 weight matrix W<math>W</math>를 곱해주는데, 이때 W<math>W</math>가 학습된다는 것입니다.Attentionattention은 단어의 의미처럼 특정 정보에 좀 더 주의를 기울이는 것입니다.예를 들어 model이 수행해야 하는 task가 번역이라고 해봅시다. source는 영어이고 target은 한국어입니다. “Hi, my name is poza.”라는 문장과 대응되는 “안녕, 내 이름은 포자야.”라는 문장이 있습니다. model이 이름은이라는 token을 decode할 때, source에서 가장 중요한 것은 name입니다.그렇다면, source의 모든 token이 비슷한 중요도를 갖기 보다는 name이 더 큰 중요도를 가지면 되겠죠. 이때, 더 큰 중요도를 갖게 만드는 방법이 바로 attention입니다.Scaled Dot-Product Attention해당 논문의 attention을 Scaled Dot-Product Attention이라고 부릅니다. 수식을 살펴보면 이렇게 부르는 이유를 알 수 있습니다.Attention(Q,K,V)=softmax(QKT√dk)V<math>Attention(Q,K,V)=softmax(QKTdk)V</math>먼저 input은 dk<math>dk</math> dimension의 query와 key들, dv<math>dv</math> dimension의 value들로 이루어져 있습니다.이때 모든 query와 key에 대한 dot-product를 계산하고 각각을 √dk<math>dk</math>로 나누어줍니다. dot-product를 하고 √dk<math>dk</math>로 scaling을 해주기 때문에 Scaled Dot-Product Attention인 것입니다. 그리고 여기에 softmax를 적용해 value들에 대한 weights를 얻어냅니다.key와 value는 attention이 이루어지는 위치에 상관없이 같은 값을 갖게 됩니다. 이때 query와 key에 대한 dot-product를 계산하면 각각의 query와 key 사이의 유사도를 구할 수 있게 됩니다. 흔히 들어본 cosine similarity는 dot-product에서 vector의 magnitude로 나눈 것입니다. √dk<math>dk</math>로 scaling을 해주는 이유는 dot-products의 값이 커질수록 softmax 함수에서 기울기의 변화가 거의 없는 부분으로 가기 때문입니다.softmax를 거친 값을 value에 곱해준다면, query와 유사한 value일수록, 즉 중요한 value일수록 더 높은 값을 가지게 됩니다. 중요한 정보에 더 관심을 둔다는 attention의 원리에 알맞은 것입니다.Multi-Head Attention위의 그림을 수식으로 나타내면 다음과 같습니다.MultiHead(Q,K,V)=Concat(head1,...,headh)WO<math>MultiHead(Q,K,V)=Concat(head1,...,headh)WO</math>where headi=Attention(QWQi,KWKi,VWVi)dmodel<math>dmodel</math> dimension의 key, value, query들로 하나의 attention을 수행하는 대신 key, value, query들에 각각 다른 학습된 linear projection을 h번 수행하는 게 더 좋다고 합니다. 즉, 동일한 Q,K,V<math>Q,K,V</math>에 각각 다른 weight matrix W<math>W</math>를 곱해주는 것이죠. 이때 parameter matrix는 WQi∈Rdmodelxdk,WKi∈Rdmodelxdk,WVi∈Rdmodelxdv,WOi∈Rhdvxdmodel<math>WiQ∈Rdmodelxdk,WiK∈Rdmodelxdk,WiV∈Rdmodelxdv,WiO∈Rhdvxdmodel</math>입니다.순서대로 query, key, value, output에 대한 parameter matrix입니다. projection이라고 하는 이유는 각각의 값들이 parameter matrix와 곱해졌을 때 dk,dv,dmodel<math>dk,dv,dmodel</math>차원으로 project되기 때문입니다. 논문에서는 dk=dv=dmodel/h<math>dk=dv=dmodel/h</math>를 사용했는데 꼭 dk<math>dk</math>와 dv<math>dv</math>가 같을 필요는 없습니다.이렇게 project된 key, value, query들은 병렬적으로 attention function을 거쳐 dv<math>dv</math>dimension output 값으로 나오게 됩니다.그 다음 여러 개의 head<math>head</math>를 concatenate하고 다시 projection을 수행합니다. 그래서 최종적인 dmodel<math>dmodel</math> dimension output 값이 나오게 되는거죠.각각의 과정에서 dimension을 표현하면 아래와 같습니다.*dQ,dK,dV<math>dQ,dK,dV</math>는 각각 query, key, value 개수Self-Attentionencoder self-attention layerkey, value, query들은 모두 encoder의 이전 layer의 output에서 옵니다. 따라서 이전 layer의 모든 position에 attention을 줄 수 있습니다. 만약 첫번째 layer라면 positional encoding이 더해진 input embedding이 됩니다.decoder self-attention layerencoder와 비슷하게 decoder에서도 self-attention을 줄 수 있습니다. 하지만 i<math>i</math>번째 output을 다시 i+1<math>i+1</math>번째 input으로 사용하는 auto-regressive한 특성을 유지하기 위해 , masking out된 scaled dot-product attention을 적용했습니다.masking out이 됐다는 것은 i<math>i</math>번째 position에 대한 attention을 얻을 때, i<math>i</math>번째 이후에 있는 모든 position은 Attention(Q,K,V)=softmax(QKT√dk)V<math>Attention(Q,K,V)=softmax(QKTdk)V</math>에서 softmax의 input 값을 −∞<math>−∞</math>로 설정한 것입니다. 이렇게 한다면, i<math>i</math>번째 이후에 있는 position에 attention을 주는 경우가 없겠죠.Encoder-Decoder Attention Layerquery들은 이전 decoder layer에서 오고 key와 value들은 encoder의 output에서 오게 됩니다. 그래서 decoder의 모든 position에서 input sequence 즉, encoder output의 모든 position에 attention을 줄 수 있게 됩니다.query가 decoder layer의 output인 이유는 query라는 것이 조건에 해당하기 때문입니다. 좀 더 풀어서 설명하면, ‘지금 decoder에서 이런 값이 나왔는데 무엇이 output이 돼야 할까?’가 query인 것이죠.이때 query는 이미 이전 layer에서 masking out됐으므로, i번째 position까지만 attention을 얻게 됩니다.이 같은 과정은 sequence-to-sequence의 전형적인 encoder-decoder mechanisms를 따라한 것입니다.*모든 position에서 attention을 줄 수 있다는 게 이해가 안되면 링크를 참고하시기 바랍니다.Position-wise Feed-Forward Networksencoder와 decoder의 각각의 layer는 아래와 같은 fully connected feed-forward network를 포함하고 있습니다.position 마다, 즉 개별 단어마다 적용되기 때문에 position-wise입니다. network는 두 번의 linear transformation과 activation function ReLU로 이루어져 있습니다.FFN(x)=max(0,xW1+b1)W2+b2x<math>x</math>에 linear transformation을 적용한 뒤, ReLU(max(0,z))<math>ReLU(max(0,z))</math>를 거쳐 다시 한번 linear transformation을 적용합니다.이때 각각의 position마다 같은 parameter W,b<math>W,b</math>를 사용하지만, layer가 달라지면 다른 parameter를 사용합니다.kernel size가 1이고 channel이 layer인 convolution을 두 번 수행한 것으로도 위 과정을 이해할 수 있습니다.Positional Encodingtransfomer는 recurrence도 아니고 convolution도 아니기 때문에, 단어의sequence를 이용하기 위해서는 단어의 position에 대한 정보를 추가해줄 필요가 있었습니다.그래서 encoder와 decoder의 input embedding에 positional encoding을 더해줬습니다.positional encoding은 dmodel<math>dmodel</math>(embedding 차원)과 같은 차원을 갖기 때문에 positional encoding vector와 embedding vector는 더해질 수 있습니다.논문에서는 다른 *frequency를 가지는 sine과 cosine 함수를 이용했습니다.*주어진 구간내에서 완료되는 cycle의 개수PE(pos,2i)=sin(pos/100002i/dmodel)<math>PE(pos,2i)=sin(pos/100002i/dmodel)</math>PE(pos,2i+1)=cos(pos/100002i/dmodel)<math>PE(pos,2i+1)=cos(pos/100002i/dmodel)</math>pos<math>pos</math>는 position ,i<math>i</math>는 dimension 이고 주기가 100002i/dmodel⋅2π<math>100002i/dmodel⋅2π</math>인 삼각 함수입니다. 즉, pos<math>pos</math>는 sequence에서 단어의 위치이고 해당 단어는 i<math>i</math>에 0부터 dmodel2<math>dmodel2</math>까지를 대입해 dmodel<math>dmodel</math>차원의 positional encoding vector를 얻게 됩니다. k=2i+1<math>k=2i+1</math>일 때는 cosine 함수를, k=2i<math>k=2i</math>일 때는 sine 함수를 이용합니다. 이렇게 positional encoding vector를 pos<math>pos</math>마다 구한다면 비록 같은 column이라고 할지라도 pos<math>pos</math>가 다르다면 다른 값을 가지게 됩니다. 즉, pos<math>pos</math>마다 다른 pos<math>pos</math>와 구분되는 positional encoding 값을 얻게 되는 것입니다.PEpos=[cos(pos/1),sin(pos/100002/dmodel),cos(pos/10000)2/dmodel,...,sin(pos/10000)]<math>PEpos=[cos(pos/1),sin(pos/100002/dmodel),cos(pos/10000)2/dmodel,...,sin(pos/10000)]</math>이때 PEpos+k<math>PEpos+k</math>는 PEpos<math>PEpos</math>의 linear function으로 나타낼 수 있습니다. 표기를 간단히 하기 위해 c=100002idmodel<math>c=100002idmodel</math>라고 해봅시다. sin(a+b)=sin(a)cos(b)+cos(a)sin(b)<math>sin(a+b)=sin(a)cos(b)+cos(a)sin(b)</math>이고 cos(a+b)=cos(a)cos(b)−sin(a)sin(b)<math>cos(a+b)=cos(a)cos(b)−sin(a)sin(b)</math> 이므로 다음이 성립합니다.PE(pos,2i)=sin(posc)<math>PE(pos,2i)=sin(posc)</math>PE(pos,2i+1)=cos(posc)<math>PE(pos,2i+1)=cos(posc)</math>PE(pos+k,2i)=sin(pos+kc)=sin(posc)cos(kc)+cos(posc)sin(kc)=PE(pos,2i)cos(kc)+cos(posc)sin(kc)<math>PE(pos+k,2i)=sin(pos+kc)=sin(posc)cos(kc)+cos(posc)sin(kc)=PE(pos,2i)cos(kc)+cos(posc)sin(kc)</math>PE(pos+k,2i+1)=cos(pos+kc)=cos(posc)cos(kc)−sin(posc)sin(kc)=PE(pos,2i+1)cos(kc)−sin(posc)sin(kc)<math>PE(pos+k,2i+1)=cos(pos+kc)=cos(posc)cos(kc)−sin(posc)sin(kc)=PE(pos,2i+1)cos(kc)−sin(posc)sin(kc)</math>이런 성질 때문에 model이 relative position에 의해 attention하는 것을 더 쉽게 배울 수 있습니다.논문에서는 학습된 positional embedding 대신 sinusoidal version을 선택했습니다. 만약 학습된 positional embedding을 사용할 경우 training보다 더 긴 sequence가 inference시에 입력으로 들어온다면 문제가 되지만 sinusoidal의 경우 constant하기 때문에 문제가 되지 않습니다. 그냥 좀 더 많은 값을 계산하기만 하면 되는거죠.Trainingtraining에 사용된 기법들을 알아보겠습니다.Optimizer많이 쓰이는 Adam optimizer를 사용했습니다.특이한 점은 learning rate를 training동안 고정시키지 않고 다음 식에 따라 변화시켰다는 것입니다.lrate=d−0.5model⋅min(step_num−0.5,step_num⋅warmup_steps−1.5)warmup_step<math>warmup_step</math>까지는 linear하게 learning rate를 증가시키다가, warmup_step<math>warmup_step</math> 이후에는 step_num<math>step_num</math>의 inverse square root에 비례하도록 감소시킵니다.이렇게 하는 이유는 처음에는 학습이 잘 되지 않은 상태이므로 learning rate를 빠르게 증가시켜 변화를 크게 주다가, 학습이 꽤 됐을 시점에 learning rate를 천천히 감소시켜 변화를 작게 주기 위해서입니다.RegularizationResidual ConnectionIdentity Mappings in Deep Residual Networks라는 논문에서 제시된 방법이고, 아래의 수식이 residual connection을 나타낸 것입니다.yl=h(xl)+F(xl,Wl)<math>yl=h(xl)+F(xl,Wl)</math>xl+1=f(yl)<math>xl+1=f(yl)</math>이때 h(xl)=xl<math>h(xl)=xl</math>입니다. 논문 제목에서 나온 것처럼 identity mapping을 해주는 것이죠.특정한 위치에서의 xL<math>xL</math>을 다음과 같이 xl<math>xl</math>과 residual 함수의 합으로 표시할 수 있습니다.x2=x1+F(x1,W1)<math>x2=x1+F(x1,W1)</math>x3=x2+F(x2,W2)=x1+F(x1,W1)+F(x2,W2)<math>x3=x2+F(x2,W2)=x1+F(x1,W1)+F(x2,W2)</math>xL=xl+L−1∑i=1F(xi,Wi)<math>xL=xl+∑i=1L−1F(xi,Wi)</math>그리고 미분을 한다면 다음과 같이 됩니다.σϵσxl=σϵσxLσxLσxl=σϵσxL(1+σσxlL−1∑i=1F(xi,Wi))<math>σϵσxl=σϵσxLσxLσxl=σϵσxL(1+σσxl∑i=1L−1F(xi,Wi))</math>이때, σϵσxL<math>σϵσxL</math>은 상위 layer의 gradient 값이 변하지 않고 그대로 하위 layer에 전달되는 것을 보여줍니다. 즉, layer를 거칠수록 gradient가 사라지는 vanishing gradient 문제를 완화해주는 것입니다.또한 forward path나 backward path를 간단하게 표현할 수 있게 됩니다.Layer NormalizationLayer Normalization이라는 논문에서 제시된 방법입니다.μl=1HH∑i=1ali<math>μl=1H∑i=1Hail</math>σl= ⎷1HH∑i=1(ali−μl)2<math>σl=1H∑i=1H(ail−μl)2</math>같은 layer에 있는 모든 hidden unit은 동일한 μ<math>μ</math>와 σ<math>σ</math>를 공유합니다.그리고 현재 input xt<math>xt</math>, 이전의 hidden state ht−1<math>ht−1</math>, at=Whhht−1+Wxhxt<math>at=Whhht−1+Wxhxt</math>, parameter g,b<math>g,b</math>가 있을 때 다음과 같이 normalization을 해줍니다.ht=f[gσt⊙(at−μt)+b]<math>ht=f[gσt⊙(at−μt)+b]</math>이렇게 한다면, gradient가 exploding하거나 vanishing하는 문제를 완화시키고 gradient 값이 안정적인 값을 가짐로 더 빨리 학습을 시킬 수 있습니다.(논문에서 recurrent를 기준으로 설명했으므로 이에 따랐습니다.)DropoutDropout: a simple way to prevent neural networks from overfitting라는 논문에서 제시된 방법입니다.dropout이라는 용어는 neural network에서 unit들을 dropout하는 것을 가리킵니다. 즉, 해당 unit을 network에서 일시적으로 제거하는 것입니다. 그래서 다른 unit과의 모든 connection이 사라지게 됩니다. 어떤 unit을 dropout할지는 random하게 정합니다.dropout은 training data에 overfitting되는 문제를 어느정도 막아줍니다. dropout된 unit들은 training되지 않는 것이니 training data에 값이 조정되지 않기 때문입니다.Label SmoothingRethinking the inception architecture for computer vision라는 논문에서 제시된 방법입니다.training동안 실제 정답인 label의 logit은 다른 logit보다 훨씬 큰 값을 갖게 됩니다. 이렇게 해서 model이 주어진 input x<math>x</math>에 대한 label y<math>y</math>를 맞추는 것이죠.하지만 이렇게 된다면 문제가 발생합니다. overfitting될 수도 있고 가장 큰 logit을 가지는 것과 나머지 사이의 차이를 점점 크게 만들어버립니다. 결국 model이 다른 data에 적응하는 능력을 감소시킵니다.model이 덜 confident하게 만들기 위해, label distribution q(k∣x)=δk,y<math>q(k∣x)=δk,y</math>를 (k가 y일 경우 1, 나머지는 0) 다음과 같이 대체할 수 있습니다.q′(k|x)=(1−ϵ)δk,y+ϵu(k)<math>q′(k|x)=(1−ϵ)δk,y+ϵu(k)</math>각각 label에 대한 분포 u(k)<math>u(k)</math>, smooting parameter ϵ<math>ϵ</math>입니다. 위와 같다면, k=y인 경우에도 model은 p(y∣x)=1<math>p(y∣x)=1</math>이 아니라 p(y∣x)=(1−ϵ)<math>p(y∣x)=(1−ϵ)</math>이 되겠죠. 100%의 확신이 아닌 그보다 덜한 확신을 하게 되는 것입니다.Conclusiontransformer는 recurrence를 이용하지 않고도 빠르고 정확하게 sequential data를 처리할 수 있는 model로 제시되었습니다.여러가지 기법이 사용됐지만, 가장 핵심적인 것은 encoder와 decoder에서 attention을 통해 query와 가장 밀접한 연관성을 가지는 value를 강조할 수 있고 병렬화가 가능해진 것입니다.Referencehttp://www.whydsp.org/280http://mlexplained.com/2017/12/29/attention-is-all-you-need-explained/http://openresearch.ai/t/identity-mappings-in-deep-residual-networks/47https://m.blog.naver.com/PostView.nhn?blogId=laonple&logNo=220793640991&proxyReferer=https://www.google.co.kr/https://www.researchgate.net/figure/Sample-of-a-feed-forward-neural-network_fig1_234055177https://arxiv.org/abs/1603.05027https://arxiv.org/abs/1607.06450http://jmlr.org/papers/volume15/srivastava14a.old/srivastava14a.pdfhttps://arxiv.org/pdf/1512.00567.pdf
조회수 2416

스타트업이 CTO를 찾는 법?

스타트업이 CTO를 찾는 법? 을 알고 계신 분에게 드리는 "질문"입니다. 이 글을 읽으시는 분들에게 부탁드리고 싶은 것은.. 1. 어디에 만나볼 엔지니어(개발자) 분들이 있으니 거기에 포스팅을 해보세요2. 엔지니어 들은 job을 찾을 때, 이런저런 고민을 하니.. 이런 포인트에서 조금 더 고민해보세요. 3. job 포스팅에는 이런저런 구체적인 내용들이 더 필요하니, 구체적으로 XX를 더 작성해보세요4. 이분 한번 만나보시겠어요? (소개 등등) 5. 공유를 해주셔도 좋습니다... 이런 고민을 함께 하시는 분들을 위해~등등의 조언을 댓글로 주셔도 좋고, 메일로 주셔도 좋고.. 아무튼 이 글은 조언을 구하고자 쓰는 글입니다. ^^;개발을 잘 모르는 스타트업 대표가 CTO를 모시는 방법은 어떤 것이 있을까요? ㅜㅜ대부분의 경우 co-founder 중, 엔지니어(engineer) 분이 CTO의 역할을 담당해주시는 것이 일반적인 경우로 보입니다. 하지만 서비스에서 engineer의 비중이 상대적으로 낮은 스타트업의 경우는 회사가 성장해 나감에 따라 function을 더 크게 만들어 나가는 경우도 있겠지요? 파펨도 그러한 회사 중에 하나입니다.지금까지는 할 수 있는 한 효율성을 따져가면서 최소한의 개발을 진행해왔지만, 이제는 조금 더 적극적으로 서비스를 고도화시켜야 할 때! 이기에 이제 좋은 분을 내부에 모셔야 하는데.. 우선 대표 입장에서의 고민을 한번 늘어놔 본다면.. 1) 개발을 거의 모르기 때문에 (새로 모셔야 할) 그분이 실력자 인지 아닌지 알 수가 없다는 불안감2) Ruby on Rails로 개발이 되어 있어, 이 언어에 능한 분을 찾는다는 것이 어렵다는 소문을 이미 많이 들음3) 엔지니어 분들이 선호하는 job 에 대한 구체적인 정보가 없음  반대로 job을 찾고 있는 엔지니어 분의 입장에서 상상력을 발휘해 본다면.. A) 잘 될 회사인지 아닌지 정확히 모르겠음 : 투자 몇 번 받은 것으로 스타트업 평가가 가능?B) 개발팀이 구성되어 있지 않아.. 당분간 나 혼자 full stack으로 일해야 함 : 내가 하나하나 다해야 함? C) 개발이 중심이지 않은 회사에서 일을 하는 게 적합할지? : 나의 커리어 차원에서 도움이 되는가? 위의 내용을 고려한다면, 100년 만의 개기일식이 일어나는 것과 같은 우연이 없다면 정말 만나기 어려운 인연이 아닐까?라는 생각이 듭니다. ㅜㅜ 그래도 어쩌겠습니까... 그런 인연을 찾아 나서야죠. 예전에는 엔지니어 한 분을 만나면, 리쿠르팅과 관계없이 다른 한 분을 소개 요청드리고, 또 그분에게서 다른 분을 소개받아서 계속해서 아는 분들의 영역을 넓혀가고자 노력도 해보았습니다. 그렇다면 파펨 대표가 생각하는 CTO는 어떤 분일까요? 현재의 파펨 구성원들과 아래의 일들을 함께 해나가 주실 분입니다. 1. 자체 커머스로써의 서비스 업그레이드 : 전체 팀과 함께 논의할 일 2. 알고리즘의 upagrade 반영 : 알고리즘 설계자(대표)와 함께 할 일3. 파펨 DB에서 추출할 수 있는 data를 바탕으로 마케팅 insight 발굴 : marketer와 함께 할 일4. 새로운 tool(예, GA보다 amplitude를 한번 사용해보자 등)을 소개하고 도입 이렇게 쓰면 컴퓨터 공학을 전공한 사람에게 저렇게 많은 것을 요청하는 당신은 경영학과 출신이니.. 재무, 회계, HR, 생산관리 모두 잘할 수 있는 사람인가요?라는 질문을 받을 것 같은 느낌이 들지만... ㅜㅜ 아무튼 어려운 리쿠르팅의 길을 떠나기 전에 머릿속에 생각나는 것들을 한번 써보았습니다.파펨에서 engineer를 찾습니다!! 파펨은? a. Ruby on Rails / AWS에서 서비스되고 있고, 나름 github에 히스토리 정리가 잘 되어 있고, 이전에 프리랜서로 개발에 도움을 주신 분이 체계적으로 정리해주셔서 나중에 열어보시면 뜨악하실 정도는 아닙니다. (라고 합니다. ^^;) b. 구체적인 연봉, job title 등은 상황별로 합리적인 논의를 할 준비가 되어 있습니다. C. 퓨쳐플레이와 아모레퍼시픽에서 투자를 유치하였습니다. #파펨 #스타트업 #창업가 #창업자 #마인드셋 #인사이트 #채용 #CTO #팀빌딩 #팀원
조회수 1105

스타트업을 운영하며..

1. 심장이 "말린 무화과" 같다는 생각을 해본 적이 있는지? 심장이 쫄깃! 하다는 말로는 표현이 부족하다. 쫄깃하다는 것은 충분한 수분과 탄력이 있다는 것을 말하지만.. 요즘 내 심장은 쫄깃이 아니라 거의 수분을 잃어가는 말린 무화과 같은 느낌이다. 그런데 그런 것들이 이제 일상이 되는 것 같은 느낌이랄까?심장이 "말린 무화과가" 된다는 것은...최소한 아직 안쪽은 쫀득하다는 뜻이겠지.2. 작은 성공을 계속 만들어가는 것이 중요하다. 스타트업 선배 중에 한 분이 말씀해 주신 것이다. 파펨을 1년 반 이상 경험을 하면서 느끼는 것은... 정말 중요하다는 것이다. 실제로 작은 성공을 만들어 내는 것일 수도 있고, 아니면 정말 별것 아니지만 성공으로 생각하고 축하하는 것이다.그래야 지치지 않는다.갈길이 멀기에...3. 어디로 가야 할지 아는 것사실 파펨의 모델은 처음에 기획된 부분도 많이 있지만, 계속해서 진화해 가고 있다는 것이 맞다. 그 중심에는 향기(fragrance)라는 것이 있고, 우리가 가는 첫 번째 목적지는 PerfumeTeller의 성공이다. 퍼퓸텔러는 기존의 향수 시장에서 Game Changer가 되겠다는 생각을 가지고 실용적이며 합리적인 면을 강조하고 있는데, 향수라는 제품이 지금까지 가지고 있던 category의 이미지와는 맞지 않는 것이 사실이다.게다가 우리는 후각의 객관화라는 중간 목표를 가지고 있고.. 마지막으로는 냄새를 생성해내겠다는 생각까지 가지고 있다. 이건 향수 회사인지 아니면 tech 회사인지 혼동이 될 수도 있겠지만, 중심에는 후각이 존재한다. 어디로 가야 할지 안다는 것은 파펨에 올라탄 사람들이 무엇을 해야 할지에 대한 방향을 잡아줄 수 있고, 스스로 일할 수 있게 만들 수 있기에 상당히 중요하다.4. 누구와 일할 것인가?파펨에서 일하는 사람은...생각할 줄 알고 그것을 실행할 줄 아는 사람이기를 바란다. 바란다기보다는 그런 사람을 계속해서 받아들일 것이다.생각을 할 줄 안다는 것은... 우리가 어디로 가야 하는지를 아는 상황에서 자신이 무엇을 고민해야 하는지 알며, 발전을 만들어 낼 수 있는 능력이 있다는 것이다.게다가 그 생각을 실현하는 능력 또한 중요하다. 단지 고민만 하는 사람보다는, 구현해낼 줄 아는 사람이 필요하다. 그것이 디자인이던, 글이던, 혹은 operation이던 실행까지 마무리할 줄 알아야 한다. 그러기 위해서는 본인의 speciality가 필요하다는 생각이다. 요즘 열심히 찾고 있는 중이다.5. 어떤 성장을 그릴 것인가?처음부터 폭발적인 성장을 하게 된다면 얼마나 다행이겠냐만은...   그럴 가능성이 높지는 않기에, 차근차근 성장 전략을 세워야 한다. 성장 전략 중에 중요한 하나는 자원의 배분이다. 또한 많은 자원 중에 가지고 있는 자본금을 어떻게 배분할까의 고민이다.처음부터 빵! 터트릴 것(full 조직 setting, 공격적 마케팅 등) 인가? 아니면.. 계속해서 조금씩 조금씩 가지고 있는 자원을 사용해가며 성장의 기회를 찾아볼 것인가? 두 모델의 장단이 있다. (이 내용에 대해서 글을 작성 중) 파펨의 경우는.... 차근차근 준비를 해왔다. 최적의 타이밍을 잡고서 모아둔 자원(이런 건 사실 없다..)을 쏟아붓는 것이다.옛날 전쟁 영화에서 (활이던 총이던) 사정거리 안에 적이 들어올 때까지.... 기다리고 기다렸다가 가지고 있는 공격력을 쏟아붓는 것처럼. 자... 이제 파펨도 공격의 타이밍을 잡을 때다.이 글을 어제 쓸 때만 해도... 소식을 기다리고 있던 상황이었으나, 답이 오지 않고 있었는데드디어 오늘 아침 축하 소식이 날아들었다. ㅠㅠFuturePlay와 아모레퍼시픽(AP)의 TechUP+ 프로그램에 최종 합격하신 것을 축하드립니다.물론 이 소식이 회사에 당장 어떤 큰 변화를 줄 수 있을지 모르겠지만, 우리에겐 축하해야 할 작은 성공이고 또 이로 인해 좋은 사람들을 모을 수 있는 계기가 된 것도 사실! 심장이 이젠 조금 쫀뜩해진 기분이다!!자 이제 공격하러 GOGO#파펨 #스타트업 #창업가 #창업자 #마인드셋 #인사이트
조회수 319

깜짝! 서프라이즈 파티~ 지성과 미모를 겸비한 과장님 생일!

대한민국 대표배달대행바로고대한민국의새로운 배달문화를 이끌어가는바로고의 사람들삭막한 도시에서정신없는 일상그 안에서 서로서로챙겨주는훈훈한~ 바로고-바로고는팀원들의 생일까지꼼꼼하게 챙겨주며서로를 응원하며함께 일하고 성장하고 있습니다!지난 3월 24일은지성과 미모를 겸비한최지선 과장님의 생일이었어요.화려한 데코레이션으로동료들의 마음을 가득가득 담아서생일 축하 파티를 했어요~생일축하합니다~생일축하합니다~사랑하는 과장님!생일축하합니다!!!깜짝 서프라이즈 파티가 시작되었어요.모두 즐겁게 생일 축하송을 부르며과장님의 생일을 축하합니다~^^깜짝 서프라이즈 파티에기쁨을 감출 수 없는 과장님생일축하송 장면을 화면에 담으셨어요.지성과 미모를 겸비한바로고의 최지선 과장님앞으로도바로고를 잘 부탁드려요!후~ 하고 촛불을 끄고도깨비 소환도깨비는 나타나지 않았지만짧게나마 촛불을 끄며소원을 빌어봅니다.장미꽃 한 송이와 함께과장님께 마음을 전해봅니다.이럴때 정말팀웍이 넘 좋은바로고라는 점~바로고 파이팅 입니닷!마지막은 단체 사진으로역시 중요한 것은 인증샷!이렇게 좋은 회사바로고에 있습니다~^^감사합니다.
조회수 2993

현대엔지니어링의 베테랑을 만나다

이들은 어떤 노력으로 베테랑이 될 수 있었을까요?시행착오의 경험을 차곡차곡 쌓는 주체는 결국 사람입니다. 온몸으로 경험을 축적한 사람은 성장과 혁신의 밑그림을 창조적으로 그릴 수 있는 힘을 가집니다. 그들은 막다른 길에서의 실패조차 다름으로 이어지는 중요한 자산으로 생각합니다. 각자의 자리에서 오랜 시간 경험을 갈고 닦은 현대엔지니어링의 베테랑들을 만났습니다.한국 주행시험장설계 분야의 최정점자동차 주행시험장설계 분야 고수화공플랜트사업본부 김웅기 부장입사 30년차 김웅기 부장은 국내 주행시험장설계 분야에서 최정점에 서있습니다. 국내 최초의 주행시험장인 남양주행시험장 설계(1992)를 시작으로 중국 연태 현대차기술연구소 주행시험장(2016), 현대모비스 주행시험장(2017) 등에 이르기까지 국내외 주행시험장은 모두 그의 손을 거쳐 탄생했습니다. 현재 김웅기 부장은 ‘현대자동차 서산직선로 주행시험장 기본 및 실시설계’를 수행하며 군산에서 시공 중인 ‘전북 상용차부품 주행시험장 건설 사업관리용역’의 기술지원기술자를 겸하고 있습니다.김웅기 부장에게 ‘경험’이란, 일을 하면서 익힐 수 있는 새로운 정보나 지식과는 다른 개념입니다. 요즘 시대엔 모르면 인터넷에 검색해서 배우면 되지만, 도로설계와 같은 전문 분야는 검색만으로 알 수 없기 때문입니다. 남양주행시험장 프로젝트를 수행할 때의 일화입니다. 고속주회로 완화곡선을 설계하던 한 선배가 사람이 느끼는 지각한계치인 ‘롤적’이라는 상수를 잘못 적용했습니다. 작은 값을 적용해야 하는데 반대로 큰 값을 적용한 것입니다. 그 때의 경험으로 지금까지 모든 고속주회로 완화곡선 설계 시 롤적 값을 2 이하로 적용해 운전자로 하여금 쾌적한 주행이 되도록 합니다.김웅기 부장이 회사에 입사했을 때 사용하던 도로설계 프로그램은 현대엔지니어링이 자체 개발한 HDSP로, 상용화된 도로설계 프로그램이 존재하지 않았던 당시에는 획기적인 프로그램이었습니다. 당시 김웅기 부장은 프로그램을 개발한 선배들을 동경했습니다. 프로그램을 배우고 익혀 선배들이 닦아놓은 길을 자신도 잇겠다는 마음으로 밤낮없이 공부했습니다.독학 끝에 김웅기 부장이 업무에 반영한 최초의 프로그램은 기존 도로 확장 도로설계에 필요한 ‘기존도로 선형도출’ 프로그램입니다. 이후에도 김웅기 부장은 고속주회로 프로그램도 독학해 각 프로젝트별로 적합한 설계솔루션을 만들어내고 있습니다. 특히 ‘McConnell Curve’ 원리를 기반으로 개발한 프로그램은 현재 거의 모든 국내 자동차 주행시험장에서 적용되고 있습니다.김웅기 부장은 지난 2002년 현대건설이 주관한 ‘거금도 연도교 2단계 턴키설계’ 사업 때의 일화가 지금까지 열정을 잃지 않고 쉼 없이 전진할 수 있는 이유라고 전합니다. 이 사업은 전라남도 고흥군 소록도에서 거금도 금산면까지 연결하는 해상교량 및 교차로 4개소와 휴게소를 설치하는 익산지방국토관리청의 도로 프로젝트였습니다. 과업 10개월 동안 남부터미널 옆에 위치한 합동 사무실에서 보내고 마지막 한 달은 거의 밤을 새웠습니다. 이때 독일의 LEONHARDT, ANKRAUND PARTNER와 함께 기본 계획을 수행했는데, 머리 색이 하얗게 바랜 노령의 독일 토목기술자가 직접 계산기를 두드리며 구조계산을 하던 모습에 깊은 감명을 받았고 그 독일기술자처럼 늙고 싶다고 생각했습니다.도로설계에만 30년을 몸담은 김웅기 부장은 요즘 ‘기술지원기술자’에도 관심을 갖고 있습니다. 설계자로서 시공현장에서 발생하는 설계-시공간 문제점을 현장에서 적재적소에 효과적인 방법으로 해결하고 싶은 바람입니다. 김웅기 부장은 노력하는 사람에게는 그에 상응하는 보답이 존재하는 것이 회사생활이라고 전하며, 직원들이 자신의 일에 자부심과 책임을 느끼며 지낸다면 좋겠다는 당부도 잊지 않았습니다.건축에 생명을 불어넣는 명장기계설비 분야 고수건축사업본부 오흥기 부대현대엔지니어링 기계설비 분야 대표 베테랑으로 건축사업본부 오흥기 부대를 꼽습니다. 오흥기 부대가 기계설비 분야라는 한 우물을 판 지는 24년. 80년대 중반, 당시 미개척 분야였던 건축설비를 전공으로 택한 후 대학 졸업과 함께 현대건설에 입사했습니다.현대건설 재직 당시 참여했던 평양 류경 정주영체육관 건립 사업은 잊지 못할 프로젝트입니다. 최근 남북통일 농구경기가 개최됐던 곳으로, 오흥기 부대에겐 감회가 남다른 곳입니다. 이 사업은 워낙 극비리에 진행된 데다 북한의 설계기준 및 자료가 미비해 어려움이 많았습니다. 이런 녹록하지 않은 환경에서 난방 시 상하부 온도 차가 없도록 기류순환시스템을 고안하기 위해 몇 날 며칠을 고민했습니다. 오흥기 부대는 미국 NBA 경기장을 참고해 문제를 해결했다고 합니다.제주 해비치호텔도 좋은 경험이 됐습니다. 바로 8층 높이, 1,600평 규모의 대형 아트리움 로비 때문입니다. 많은 사람이 동시에 이용하는 만큼 항상 쾌적함을 유지하는 것이 관건인 가운데 원활한 냉·난방 운전은 물론 에너지 비용까지 고려해 설계해야 했습니다. 가장 완벽한 시스템을 설계하기 위해 오흥기 부대가 선택한 것은 끊임없이 새로운 방식을 시도하는 것입니다. 수차례 시뮬레이션 검토 끝에 적정한 공조 방식을 선정할 수 있었습니다. 오흥기 부대가 수많은 시행착오를 겪으면서도 끝까지 포기하지 않을 수 있었던 이유는 목표가 확실했기 때문입니다. 목표를 향하는 과정에 어려움이 있었지만 항상 긍정적인 자세와 규칙적인 생활로 자신을 컨트롤했습니다. 무엇보다 주변 사람에게서 많은 힘을 얻었다고 합니다. 동료 혹은 팀원들과 대화를 하면서 문제를 해결할 방법을 찾아나간 것입니다. 오흥기 부대는 이를 팀 스포츠인 축구에 빗대어 설명했습니다.축구를 하다 보면 뒤에 눈이 달린 것도 아닌데 서로 잘 피해서 움직입니다. 이는 주위 선수들이 각자 자신의 위치에서 역할을 훌륭히 수행해내며 서로의 상황을 끊임없이 소통하기에 가능한 일입니다. 오흥기 부대는 업무에서도 각각의 위치에서 서로의 역할을 다하고 끊임없이 소통하며 부족한 부분을 채워줘야 한다고 말합니다.최근 오흥기 부대의 가장 큰 관심사는 미세먼지입니다. 미세먼지 농도가 삶의 질을 넘어 생존을 위협하는 수준이 됐기 때문입니다. 이에 오흥기 부대는 깨끗한 실내공기를 위한 여러 시스템을 개발했습니다. 주방후드연동 하부급기 시스템과 현관 에어샤워 시스템은 각각 주방에서 요리할 때 발생하는 미세먼지와 외출 후 의류나 신체에 의해 유입되는 미세먼지를 방지합니다. 가장 최근에는 ‘H-SUPER 공기청정 환기시스템’을 개발했습니다. 0.3㎛ 미세먼지 제거 성능을 99.97%로 끌어올리고 환기량을 법적 기준 대비 2배 증가시켰습니다.오흥기 부대는 달인과 기술자, 그리고 기능공과 엔지니어의 차이를 얼마 전 사내에서 진행된 이정동 교수의 특강에서 찾습니다. 특강에 따르면, 매번 같은 일을 하는 생활의 달인은 매번 다른 일을 하는 40년 경력의 조다이회사 백발 엔지니어를 결코 넘어설 수 없습니다. 그리고 경력이 쌓인 엔지니어일수록 새로운 환경에서도 문제의 핵심을 재빨리 분석하고 유사경험을 더 폭넓게 활용해 보다 창의적이고 차별적으로 일할 수 있어야 합니다. 오흥기 부대는 회사 생활, 나아가 개인의 삶은 100m 단거리 달리기가 아닌 마라톤이라고 강조했습니다. 남들이 설계해놓은 길을 빠르게 효율적으로 달리는 것만으로는 한계가 있으며 긴 호흡으로 계속 도전하고, 경험을 축적해 길을 그려내는 고수가 되어야 한다고 설명했습니다.민자발전 사업개발의 선두자민자발전 사업 분야 고수전력플랜트사업본부 박상민 차장현대엔지니어링은 최근 민자발전(Independent Power Plant, 이하 IPP) 사업으로 사업영역을 확장해나가고 있습니다. 박상민 차장은 그 선두에서 민자 발전 사업개발을 이끌고 있습니다. 박상민 차장은 EPC 프로젝트를 수행할 당시 발주처와 협의를 하는 그 과정에서 지분 참여를 통해 사업을 개발, 운영하는 Developer에 대한 이해가 생겼고 EPC 도급만이 아닌 발주처 입장에서 발전소 운영 사업의 가능성을 발견했습니다. 투자리스크가 존재하지만 단순 도급 사업에 비해 매년 배당이익을 통한 안정적인 수입을 창출할 수 있다는 점에서 매력을 느낀 것입니다. 또 주력 발전 시장인 개도국과 신흥국들의 국가 재정 여력이 부족한 탓에 최근 들어 투자를 동반한 PPP나 Private IPP 형태의 사업이 많이 발주되고 있는 점에도 주목했습니다.처음 가는 길이기에 난관도 많았지만, 끊임없는 노력으로 하나하나 헤쳐나갔습니다. 먼저 관련 서적을 들여다보며 공부를 했습니다. 하지만 책 속의 이론은 현장 실무에 적용하기에 한계가 있었습니다. 이를 보완하기 위해 국내외 Developer들과 자주 면담하면서 현장업무의 고민을 파악했습니다. 또 팀원들과 해외연수나 세미나 등에도 적극 참여하는 등 IPP를 배울 수 있는 기회를 최대한 갖고자 노력했습니다. 회사 미래성장동력사업으로 IPP가 선정된 덕분에 지원을 받은 점과 기획실 주관으로 진행된 경영전략 PF 교육과정에 참여한 것도 많은 도움이 됐습니다.사내에 IPP 개발사업에 관한 규정도 만들었습니다. PRM팀 등 관련 실/본부와 상의해 절차를 새로 만들고 다듬으면서 업무를 추진했습니다. 전력플랜트사업본부 내부적으로도 팀 차원의 스터디그룹을 만들어 민자발전 표준 절차서를 개발, 사내 표준으로도 등록했습니다. 이렇게 만들어진 규정과 표준 등은 현재 현업에서 활용되고 있습니다.박상민 차장은 지난 2015년 첫 국내 IPP 사업으로 진행하고자 했던 통영 천연가스 발전사업에 참여했던 경험이 큰 도움이 됐다고 이야기합니다. LNG 직도입을 통해 사업성을 확보하는 전략을 세웠지만 안타깝게 당시 저유가의 영향으로 토지매입 협상이 지연되면서 결국 포기해야만 했습니다. 하지만 건설출자자의 사업개발 노하우와 LNG에 대한 이해를 높이는 계기가 됐습니다. 그때의 경험이 유사사업에 도전해 수주할 기회가 될 것이라 의심치 않습니다.현재는 산업통상자원부 국책개발과제로 선정된 전남 안마도 200MW 해상풍력사업을 진행하고 있습니다. 태양광, 풍력 같은 신재생에너지 분야가 확대됨에 따라 이 사업을 발판으로 해외풍력사업에 진출하겠다는 비전도 품고 있습니다.박상민 차장은 EPC뿐만 아니라 인허가, 금융, 운영 등 사업의 모든 분야를 다루는 IPP의 경우 긴 호흡과 안목을 갖춰야 한다고 이야기합니다. 그래서 그 어떤 분야보다 여러 사람이 모여 서로 협업하면서 각자 축적한 지식을 공유해야 한다는 것입니다. 하지만 축적이라는 것이 단번에 이루어지지 않기 때문에 모든 구성원이 매일의 업무를 체계화하고 설계노트/사업노트를 만들어 공유하는 것이 Lesson & Learned 측면에서 많은 도움이 될 것이라고 말했습니다.마지막으로 박상민 차장은 ‘이 또한 지나가리라’는 마음으로 끈기 있게 도전하는 자세가 필요하다고 말합니다. 성과가 눈에 보이지 않거나 지금 가는 길이 맞는지 걱정이 들 때도 있을 텐데 그럴 때마다 포기하지 않고 꾸준히 자신의 자리에서 노력하면 언젠가 결실을 거두게 된다고 덧붙였습니다.계약/클레임 분야 국내 최초 QS (PER) & Accredited Mediator계약/클레임 분야 고수화공플랜트사업본부 김지연 과장클레임 제기는 현대엔지니어링이 프로젝트를 수행하면서 발주처가 계약 역무 범위 외에 추가 요구를 하면서 발생할 수 있는 손해를 막기 위한 장치입니다. 하지만 클레임이든 컴플레인이든 발주처의 입장에서는 사실 달갑지 않은 일이기 때문에 최대한 공손하고 친절하며 무엇보다 정확하고 객관적이어야 합니다. 김지연 과장은 본인의 노하우를 최대한 발휘해 Complain Letter를 작성합니다. 어떠한 Complain Letter라도 김지연 과장의 손을 거치면 Love Letter로 바뀝니다.건설플랜트산업이 고도화되면서 계약과 클레임 관리의 중요성이 커지고 있지만 정작 계약당사자들은 계약내용을 제대로 파악하지 못하는 것이 현실입니다. 매우 어려운 데다 까다롭기 때문입니다. 이뿐만이 아닙니다. 실제로 역무를 진행하면서 발주처에서 계약 범위 외에 추가 요구를 해오는 상황이 종종 있습니다. 김지연 과장은 이러한 요구들로 인해 비용이 늘어나는 것은 물론 공사 기간이 지연되는 등 프로젝트 수행 중에 발생하는 여러 요인으로부터 현대엔지니어링이 스스로를 보호하고 계약서상의 조건 및 역무 범위 안에서 프로젝트를 수행할 수 있도록 가이드라인을 잡아주는 역할을 합니다. 지금은 UGTL 프로젝트를 담당하고 있습니다.김지연 과장이 처음부터 계약/클레임 업무를 했던 건 아닙니다. 지난 2005년 Vendor Document Control Manager로 입사 후 잘 할 수 있는 일, 재미를 느끼는 일을 찾다가 자재 운영팀에서 일하던 중 공급 계약 관리, Change Order, Vendor Claim, 비용 정산 업무를 진행하면서 관심을 가지게 됐습니다. Vendor에서 제기한 클레임에 공급 계약 업무 범위를 살펴보며 대처하고, 최종 비용 정산 업무를 하면서 상당히 흥미를 가지게 된 것입니다.열심히 하는 것으로는 김지연 과장의 성에 차지 않았습니다. 제대로 하고 싶다는 욕심이 생기면서 QS(Quantity Surveyor, 건설원가 관리자) 자격 취득에 도전했습니다. 김지연 과장은 2년간 주말을 반납하고 공부를 했고 3년째 되던 해에 RICS 홍콩사와 5단계에 거친 인터뷰를 진행하고 최종 자격인 MRICS를 취득했습니다. 이뿐만이 아닙니다. 클레임/계약 관리 업무를 진행하면서 분쟁이 발생할 수 있다는 것을 깨닫고 영국 중재인 협회(CIArb)로부터 Accredited Mediator 자격을 부여받았습니다. 이 역시 2년 동안 준비한 끝에 취득했습니다. 연이은 도전이 물론 쉽지는 않았습니다. 다른 나라의 기관에서 부여하는 자격이다 보니 관련 정보가 턱없이 부족해 맨땅에 헤딩하듯 처음부터 혼자 부딪혀야만 했던 것입니다. 하지만 김지연 과장은 차근차근 단계를 밟으며 정보를 취했고 아는 만큼 보인다고 그때마다 길을 발견했습니다.김지연 과장은 QS가 되어 전임 계약 관리자로 투입됐던 UKAN 프로젝트를 잊을 수 없다고 말했습니다. 중앙아시아 지역 업무 노하우가 부족한 상황이라 힘들기도 했지만 스스로 경험을 쌓을 수 있었고, 이때 쌓은 경험이 다음 UGTL 프로젝트에 더 몰입할 수 있는 기반이 됐다고 합니다.김지연 과장은 중요한 것은 몰입이라고 설명합니다. 스스로에게 하고 싶은 일이 무엇인지, 흥미를 느끼는 일이 무엇인지 물어보고 그 일에 푹 빠져들어야만 포기하지 않기 때문입니다. 목표를 한 곳에 두고 몰입감 있는 경험과 지식을 축적해야만 한 분야의 진정한 전문가가 될 수 있다고 전했습니다.묵묵히 최선을 다하는 3D 모델러플랜트회전기계 3D 모델링 분야 고수엔지니어링센터 이정은 대리이정은 대리는 어떤 분야의 전문가가 되기 위해서는 최소한 1만 시간 정도의 훈련이 필요하다는 ‘1만 시간의 법칙’을 믿습니다. 한 TV 프로그램에서 20년 경력의 아주머니께서 시선조차 따라갈 수 없는 빠른 속도로 불량을 찾아내는 모습을 보며 시간과 경험의 중요성을 느꼈습니다. 햇수로는 12년, 시간으로는 10만 5천 시간, 이정은 대리가 현대엔지니어링에서 3D 모델러로 일한 시간입니다.3D는 2D 설계의 한계를 뛰어넘어 전체적인 설계 검토를 가능하게 합니다. 2D 도면을 보고 다른 분야의 3D 모델러들이 각각 작업한 3D 모델링 결과물을 가지고 내부 리뷰를 거치며 간섭 및 오류 등을 확인 후 수정합니다. 이 과정을 통해 설계 오류를 최소화하고 시공 재작업을 방지합니다. 리뷰 작업은 최소 3번 이상 이뤄지는데, 30%(기계의 대략적인 형태 표현), 60%(Vendor GAD 반영), 90%(전체 설계 반영) 리뷰 단계를 거칠 때마다 오류가 줄어들고 점점 개선되는 결과물을 눈으로 확인할 수 있습니다.이정은 대리가 처음 입사했을 때는 스스로를 3D 모델러라 자부할 수 없었습니다. 시각디자인을 전공하고 관련 회사에 다녔지만 적성에 맞지않아 그만두고 진로를 고민하고 있을 때 지인에게 3D 분야를 추천받았습니다. 처음에는 잘 알지도 못하는 분야에다 하던 일이 아니라서 망설였습니다. 하지만 자세히 알아보니 관심이 생겼습니다. 교육을 받고 회사에 입사했지만 리뷰 룸에 있는 3D 모델링 샘플을 보고 기가 죽기도 했습니다.첫 프로젝트는 EGP3(Escravos Gas Project Phase 3)였습니다. 당시 겨우 프로그램 기본 사용법만 익힌 상태였는데 발주처에서 기기를 디테일하게 표현해달라고 요구하는 바람에 난관에 봉착했습니다. 더욱이 이전까지는 배관팀이 기계 모델링을 한 탓에 팀 내부에 관련 기술과 정보를 가진 사람도 없었습니다. 이정은 대리는 하루가 멀다고 야근을 하며 혼자 프로그램 툴을 이리저리 사용하면서 기술을 터득했습니다. 또 기계에 대한 이해가 없어 도면을 보기 힘들 때는 담당자를 찾아가 물어보며 배워나갔습니다. 길을 가다가도 기계만 보이면 모델링 할 때 도움이 되겠다 싶어 유심히 지켜봤을 정도였습니다.10만 5천 시간이 흐른 지금 이정은 대리는 현재 모든 플랜트회전기계 관련 프로젝트의 3D 모델링 전반을 관리하고 있습니다. 이제는 전문 3D 모델러라는 자부심도 생겼습니다. 리뷰를 거칠 때마다 점점 나아지는 모습을 보며 느끼는 성취감이 지금까지 그녀가 자신의 분야에 계속해서 도전하는 원동력이 되고 있습니다. 그리고 묵묵히 자신의 자리에서 최선을 다하며 현대엔지니어링 설계/시공의 품질을 높이는 데 일조하고 있습니다.3D 모델링 작업은 베테랑이 되는 과정과 비슷합니다. 시행착오를 두려워하지 않고 실패와 수정을 반복하며 결국 자신만의 경험을 축적해야 합니다. 이정은 대리는 시간과 노력은 배신하지 않는다는 것을 직접 경험했습니다. 설령 지금 가는 길이 잘못됐다고 느꼈을 때조차 그 노력이 또 다른 길을 열어주었다고 합니다.십 년을 넘게 일해도 덜렁거리는 성격 탓에 여전히 실수가 나오기도 하지만 그럴 때마다 초심으로 돌아간다는 이정은 대리. 중요한 것은 힘들어도 오뚜기처럼 다시 일어나 축적의 길을 가는 것입니다. 그리고 일과 인간관계에서 힘들 때 틈틈이 여행과 운동으로 자신만의 시간을 가지며 리프레시하고 다시 업무에 집중할 수 있는 활력과 힘을 충전하는 것이 많은 도움이 된다고 말합니다.▶ 현대엔지니어링 사내보 < HEC> 2018년 9월호에서 원문을 확인할 수 있습니다.#현대 #현대그룹 #현대엔지니어링 #베테랑 #자동차_주행시험장설계 #기계설비 #민자발전_사업 #계약 #클레임 #플랜트회전기계 #3D모델링 #직무소개 #직무정보 #HMG저널 #HMG_Journal #HMG #기업문화 #조직문화 #구성원인터뷰
조회수 661

플로우 마케팅팀 재택근무 시행기(인터뷰)

#재택근무  #재택근무후기 #인터뷰 #협업툴 #기업문화 #조직문화안녕하세요 협업툴 플로우입니다.코로나19 사태와 함께 재택근무를 시행하는 기업들이 늘어나고 있습니다. 이미 회사 내 협업 도구가 구축되어 있던 기업들은 비상 재택근무 체제에도 큰 업무 공백 없이 원활한 소통을 이어가지만, 임시방편으로 '단톡방'으로 업무를 공유하는 경우 명확한 업무 보고의 기준이 없어 소통이 마비되거나, 과도하게 업무를 감시하는 수준에 이르는 등의 혼선을 겪고 있다고 합니다. 이에 플로우 직원들의 재택근무 방법이 다른 기업들에게 작게 나마 도움이 되길바라며 '솔직한 재택근무 시행기'를 들려드립니다. 팀마다 업무 속성이 다른 점을 고려하여 마케팅팀 > 고객지원팀 > 개발팀 > 디자인팀의 이야기를 순차적으로 업로드 하겠습니다. 플로우 재택근무 시행기 첫번째팀은 마케팅 팀의 장아람 담당자의 인터뷰입니다.Q. 간단한 본인 / 팀 소개A. 플로우 마케팅 팀 장아람 주임입니다. 마케팅 팀은 업무 특성상 수 많은 업무량 + 타팀 협의 / 대행사 핸들링 / 대표님 최종 컨펌.. 등, 그 어떤 팀보다 커뮤니케이션이 많이 필요합니다. 또한 마케팅은 답이 정해져 있지 않기 때문에 업무가 시행되는 과정 속에서도 중간 피드백 + 수정도 빈번합니다. 퍼포먼스 성과가 좋은 전략을 빠르게 업그레이드하여 성과를 키우고, 성과가 부진한 전략은 중단 결정 or 보완 전략이 필요하기 때문이죠. 최대한 업무 시간을 효율적으로 활용하여 어제보다 더 많은 도전을 하려고 노력하는 플로우 마케팅 팀 입니다.Q. 본인의 재택근무 환경을 소개 해 주세요.A. 재택근무 기간동안 친동생 보물 1호인 게이밍 컴퓨터 사용을 허락을 맡았습니다. (회사 노트북을 가져오긴 했지만) 이번 주는 포토샵 작업이 많은 것을 고려하여, 좀 더 사양이 좋은 데스크탑과 듀얼 모니터 사용이 적합하다고 판단했습니다. 다소 PC방 같은 분위기지만 게이밍 의자가 편해서 업무 집중에 큰 도움이 됐습니다.Q. 출/퇴근은 어떻게 체크 하나요?A. 경영 지원 팀에서 매일 아침 플로우로 [오늘의 출근 일정]게시물을 등록하여 줍니다. 각자 본인의 재택 근무지 에서 업무 준비가 완료되면 '실시간 업무 준비 사진'을 찍어서 인증샷을 남기고 있습니다. 회사까지 출근하는 이동 시간이 줄어드니 30분 정도 아침 뉴스 (코로나19 사태 현황)를 보다가 다른 직원들의 출근 알림을 확인하고 저도 업무 시작을 함께 했습니다.Q. 하루 업무 계획은 어떻게 하나요?A. 플로우 에서는 모든 업무의 [담당자/마감일]이 명확하게 지정되어 있습니다. 출근과 동시에 오늘까지 내가 마무리 해야 하는 업무를 필터링 하여 우선순위를 파악합니다. 플로우는 개인의 업무 뿐만 아니라 모든 직원들의 업무를 투명하게 확인 할 수 있습니다. 즉, 대표님도 팀원들도 저의 업무를 확인 할 수 있습니다. 몇 년전 협업툴이 없는 회사에서 근무했을 때는, 본부장님의 출장 기간 동안 엑셀로 업무 일지 작성하여 오전 / 오후에 보고하는 절차가 필요했는데.. 번거로운 보고 절차 없이도 투명하게 업무를 관리 할 수 있어서 좋았습니다.Q. 여러명이 참여하는 회의는 어떻게?A. ZOOM이라는 화상 회의 채널을 활용하였습니다. 상황 상 평소보다 회의가 빠르게 진행 되었습니다. 모니터에 바로 자료를 띄우고 팩트 중심으로 간략하게 주요 이슈만 공유 하였습니다. 사실 화상회의가 처음 이였던 저는 모니터 연결의 실패하여 얼굴을 비추지는 못했습니다. 저를 제외한 다른 분들은 스마트 하게 적응하여 차질 없이 회의를 진행하였습니다. 잘 들린다는 사실을 알리고 싶어 무턱대고 헤드폰을 끼고 혼자 대답을 했습니다.Q. 오전시간 업무는?A. 오전에는 언제나 그러하듯 우선순위가 높은 업무 = (오늘까지 마감일을 절대 넘겨서는 안되는 업무)를 우선적으로 처리합니다. 내가 맡은 '업무에 대한 요건'들은 플로우에 명확하게 기록되어 있어서 혼선 없이 수월하게 업무를 진행 할 수 있었습니다. 업무를 진행하는 과정에서 질문이 있거나, 사소하게 업무 방향이 변경되는 경우가 있어 '실시간 채팅'으로 소통하였습니다. 재택근무 기간에는 가급적 더 빨리 회신을 하기로 약속을 했기 때문에 오전에 진행했던 간단한 업무 소통에는 전혀 문제가 없었습니다.Q. 점심시간은 어떻게 보냈나요?A. 전 날 저녁에 미리 점심을 준비 해 놨습니다.(원래도 저와 동생의 건강을 위해! 주 3일 이상 퇴근 후 요리를 해서 건강한 아침을 챙겨 먹고 있습니다.) 코로나19 사태에 대비하기 위해서는 개인의 위생/컨디션 관리가 가장 중요하다고 생각합니다.Q. 점심시간 후 오후 업무 복귀에 어려움은 없었는지?A. 원래 플로우는 점심시간이 자유롭습니다. 때문에 내가 정한 점심시간에 충분히 휴식을 취하고 오후 시간에 리스타트 하고 있습니다. 재택근무라고 해서 특별히 점심시간에 늘어지진 않았습니다. (각자의 점심시간이 다르기 때문에) 내가 점심 시간을 보내고 있는 틈틈이 실시간 업무 알람이 왔고, 느낌 상 다들 꽉 채운 점심시간을 보내는 것이 아니라 신속히 업무 마무리를 하고 싶어 빨리 복귀를 하는 듯 보였습니다. 오후 1시 30분 쯤에는 모두 열일하는 분위기가 시작되어 저도 평소와 같이 오후 업무를 시작했습니다.Q. 업무 소통에 어려움은 없었나?A. 상황에 따라 커뮤니케이션 방법을 달리했습니다. 글로 요건을 정리 할 수 있는 업무는 플로우로 업무 요청을 했습니다. 약속된 업무 요건 외 좀 더 다양한 의견이 필요한 경우에는 실시간으로 채팅을 주고 받았습니다. 중간에 좀 더 빠른 회신이 필요한 경우 전화를 했고, 전화는 거의 5분 내로 끊었습니다. 하루의 업무 소통의 방식의 비율을 표시한다면 아래와 같습니다.* 재택근무 중 업무 소통 비중- 플로우 : 업무 요청 (70%)- 플로우 : 실시간 채팅 (20%)- 전화 (10%)Q. 전화는 어떤 경우에 필요 했는가?A. 아무리 협업툴이 시/공간의 제약을 넘어 소통을 원활하게 도와주더라도 상황에 따라 분명 비 언어적 커뮤니케이션도 필요했습니다. 대표님께서 아주 중요하다고 강조했던 마케팅 콘텐츠를 기.깔.나.게. 살리지 못하여.. 대표님의 사랑을 독차지 하게 되었습니다. ( 어찌 보면 근무 시간이라 너무나 당연히 필요한 업무 피드백인데 집에서 전화로 피드백을 받으니 막 반갑거나 막 좋거나 그렇지 않았습니다. ㅎ )Q. 퇴근까지 업무 집중이 잘 되었는가?A. 평소와 비교 했을 때 업무 집중 오히려 더 잘 됐습니다. 개인마다 재택근무 환경이 다르겠지만 저는 동생이 출근을하고 완전히 혼자 집에서 일을 한 덕분에 타인 or 외부 영향을 받지 않고 온전히 개인 업무에 몰두 할 수 있었습니다. ( 평소에는 가끔 회사 분위기에 따라 집중이 흐려질 때도 있었던 것 같습니다. ) 재택근무 기간에 절대로 업무 공백이 없어야 한다는 심리적 책임감과 약간의 부담감이 있었기에 마감일에 맞춰 더 철저하게 업무를 진행 했습니다.Q. 짝짝! 모든 업무가 마무리 되었습니다.퇴근 후 업무 보고 절차는?A. 실시간으로 모든 업무 처리 상태가 알림으로 뜨기 때문에 평소에 플로우 마케팅팀은 퇴근 시간에 따로 업무 보고 절차가 없습니다. 다만 재택근무 기간에는 평소보다 좀 더 철저하게 업무 보고를 하고 싶어서 [ 할 일 ] 체크 리스트 기능을 활용하여 직관적으로 보고를 했습니다. 업무 계획 100% 수행. 이로써 퇴근 완료!Q. 플로우 활용 재택근무 (마케팅팀 장아람 마지막) 총평A."어디서 일하느냐" 보다 "어떻게 효율적으로 일하느냐"가 중요하다.Good (+) 내 스스로 업무 시간을 통제하지 못하고 업무에 집중하지 못하는 시간이 생기지 않을까? 고민과 달리 오히려 외부 환경에 영향을 받지 않으니 업무 집중이 더 잘 됐다. 또한 플로우를 활용한다면 담당자와 / 마감일이 명확하고 실시간 업무 처리 알림이 뜨기 때문에 장기간 재택근무를 하더라도 업무 리듬이 쉽게 깨지지 않을 것 같다. 팀 커뮤니케이션은 상황에 따라 다르겠지만 현재로서는 큰 무리가 없었다. 결과적으로 업무의 만족도는 평소와 비슷하게 잘 유지 될 수 있었다. 무엇보다 '코로나19'로 부터 나를 아주 안전하게 지킬 수 있었다는 점은 매우 높은 점수를 줄 수 있다.Bad (-) 사람과 사람의 관계가 중요한 나로써는 유대감(친밀감)이 거의 느껴지지 않아서 장기간 혼자 일을 해야 한다면 일의 흥미가 떨어지거나 외로울 수도 있을 거라는 생각이 들었다. 빨리 코로나가 종식되어 모두 한 공간에서 서로 에너지를 부딪히면서 일하고 싶다. 평소 같았으면 대표님과 피드백을 주고 받으며 일을 발전시키는 재미가 있었는데 집에서 전화로 피드백을 받으니 왠지 모르게 전혀 반갑지 않았다. 마지막까지 걸려온.. 대표님의 피드백 전화.. (내겐 너무 완벽한 당신...) 어쨌든 오늘 하루도 잘 마무리 됐다고 한다. 이상. 플로우 마케팅 팀 재택근무 시행기 끝!협업툴 플로우 바로가기
조회수 935

[Buzzvil People] Ben Yoo, Software Developer

 Buzzvil People에서는 다양한 배경과 성격 그리고 생각을 지닌 버즈빌리언들을 한 분 한 분 소개하는 시간을 갖습니다. 어떻게 버즈빌에 최고의 동료들이 모여 최고의 팀을 만들어가고 있는 지 궁금하시다면, 색색깔 다양한 버즈빌리언들 한분 한분의 이야기가 궁금하시다면, Buzzvil People을 주목해주세요.1. 간단한 자기 소개 부탁드립니다.  안녕하세요 저는 버즈빌에서 Server engineering 을 맡고 있는 유병우입니다. 회사에서는 Ben 이라는 닉네임을 쓰고 있고 저와 아내 사이에 아기가 하나 있는데 회사에서는 벤, 벤처, 미니벤이렇게 부르고 있습니다. 성격은 매우 Active 해서 웬만한 스포츠는 다 좋아하고 회사에서는 Rock band도 하고 있습니다. 프로그래머! 어린 시절 Basic 이라는 언어로 시작한 프로그래밍이 너무 재밌기도 했고 가능한 많은 사람들에게 유익을 끼치고 싶다는 생각에 Software Engineer 가 되었습니다. 10년 전 병역특례 시절 카카오톡 이전에 존재했던 m&Talk 이라는 무료 메신저 개발을 시작으로 삼성의 Chat@n, 그리고 Line, Naver 외 여러 앱에 들어가는 push notification platform 을 개발한 경험이 있습니다. 전 세계에서 억 단위가 넘는 유저들에게 서비스하고 그 유저들에게 좋은 경험을 선사하는 것이 저에게 더욱 Software 의 매력에 빠지게 만들었던 것 같습니다. 새로운 기능이나 개선사항을 배포하고 나면 유저들의 Feedback 을 보는 것이 아침에 눈을 뜨면 가장 먼저 하는 일이었습니다. (늘 즐겁기만 한 건 아니었습니다. 특히 버그를 배포한 다음 날엔.. -_-a)  2. 어떻게 버즈빌에 오시게 되셨나요?  Infobank 에서의 인연 Infobank 에서의 병역특례를 하면서 m&Talk이라는 메신저를 개발할 때 Product Team의 Jay 는 iPhone 쪽 개발을 주도하고 있었고 저는 Android 쪽 개발을 주도하고 있었습니다. 함께 하나의 Product 을 만들면서 여러 가지 의견을 주고받기도 했고 서로 부족한 부분을 잘 보완해주는 친구이자 동료라는 생각을 많이 했습니다.  창업을 결심 나중에 Jay가 미국에서 함께 잠금화면 서비스를 만들어보자고 절 찾아왔고 그렇게 해서 Slidejoy 라는 회사를 함께 공동창업하게 되었습니다. 당시 좋은 회사에서 만족하며 생활하고 있었고 한 가정의 가장으로서 불안정한 길을 선택하는 것에 대한 두려움이 있었지만 좋은 사람들과 함께 창업이라는 기회는 자주 오지 않는다는 것과 다음의 단순한 생각이 창업의 길로 저를 이끌었습니다.  “뭐, 굶어 죽지는 않겠지.” 버즈빌로 합병 많은 위기들을 헤쳐나가며 Slidejoy 는 계속 성장했고 좋은 기회에 한국에서 비슷한 서비스를 하고 있던 저희보다 규모가 큰 회사인 버즈빌로 합병을 하게 되었습니다.  3. 버즈빌에서 어떤 업무를 담당하고 계신가요?  신기술 & Refactoring  제가 Software 를 개발하면서 가장 중요하게 생각하는 것은 효율 / 훌륭한 Design 을 가지고 있는 프로젝트 설계인데요, 효율을 올리기 위해 Go 와 Kubernetes 등의 기술을 회사에 도입했고 MVP, MVC 와 같은 Design pattern 들을 도입해서 코드를 읽기 쉽고 서로 분리하고 재사용 가능한 구조로 만드는 것에 노력 중입니다.    Go server engineering 실제 업무는 BuzzScreen / HoneyScreen 에서 광고 및 콘텐츠 할당과 Slidejoy 라는 서비스의 API 서버 개발을 맡고 있으며 Slidejoy 클라이언트를 개발했어서 클라이언트 쪽도 조금씩 참여하고 있습니다. 새로운 기술에 관심이 많다 보니 BuzzScreen 과 HoneyScreen 할당 로직을 전부 Go 언어로 포팅했고 비약적인 성능 향상이 있었습니다. (Go 서버 개발하기)  4. 스타트업에서 혹은 광고업계에서 일하는 느낌이 어떠세요?  사람 > 회사 대기업에서의 경험과 다르게 스타트업에서는 한 사람 한 사람이 일당백인 경우가 많은 것 같습니다. 그리고 그런 한 사람에 의해서 회사가 좌지우지 할 수 있는 곳이 스타트업입니다. 회사가 겪는 크고 작은 성장과 위기 모두 그대로 직원들에게 전달 되다 보니 그만큼 Buzzvil 식구들 모두 함께 만들어가는 서비스의 성공에 초점을 맞출 수 있습니다.  모바일 광고 저는 사실 미디어에 큰 흥미가 없고 광고는 더더욱 관심이 없었습니다. 하지만 Mobile 이라는 Big wave 안에서 0에서 출발해서 수억 명이 사용하게 된 급속도로 성장하는 Messenger 를 개발을 몸으로 체험할 수 있었고 모바일 광고 역시 Buzzvil 을 성장시킨 Big wave 였다고 생각합니다. 이렇게 급속도로 변하고 성장하는 시장에서 스타트업에 분명히 가치를 계산할 수 없는 엄청난 기회가 있다고 생각합니다.  5. 이것만큼은 버즈빌이 참 좋다! 어떤 게 있으실까요?  밝고 명랑한 문화 회사 회식 중에서 저는 “친해지길 바래” 라는 테마를 정말 좋아하는데요. 그야말로 정해진 예산 안에서 소수의 사람들끼리 마음껏 놀 수 있습니다. 지난번 친해지길 바래 때는 간단히 막국수 먹고 그 외의 모든 예산을 사격 및 방탈출 등의 액티비티에 쏟아부었습니다. 회식 날 밤에 배가 고픈 건 태어나서 처음이었던 것 같아요. 올해 초에 다녀왔던 전 직원들과 함께 다녀온 Bali 에서의 워크숍도 빠질 수 없습니다. 워낙 서로 친하게 지내다 보니 밤잠을 아껴가며 놀았던 기억이 납니다. 휴양지를 다녀왔는데 한국 돌아와서 1~2주 체력적으로 정말 힘들었던 기억이 나네요. 어느 Slack 채널에서나 난무하는 아재개그와 어처구니없는 3행시, 직원들의 표정이 담긴 얼굴로 만든 이모티콘 등 직원들 사이에서 주고받는 대화에는 늘 위트가 넘칩니다. 다크할거야! 라고 생각할 틈을 주지 않습니다. 비록 웃기지 않더라도 응원해줍니다. 노력은 언젠가 결실을 맺을 것이라 기대하기 때문이죠. 같이 놀고 같이 공부하는 회사 마음껏 교육이나 운동을 할 수 있도록 지원해주는 프로그램이나 무제한 도서구매를 지원하고 다양한 주제의 동아리나 스터디 모임 등이 있고 이걸 회사 차원에서 장려하는 것이 빼놓을 수 없는 Buzzvil 의 특징인 것 같습니다. 머신러닝, 영어스터디, 통기타 등의 스터디 모임과 밴드, 축구, 배드민턴, 테니스, 필라테스 등의 동아리 모임 등 대부분 직원들이 하나 이상의 프로그램에 참여하고 있습니다.  6. 개인적인 목표나 꿈이 있으신가요? 있다면, 버즈빌에서의 경험이 어떻게 도움이 된다고 생각하시나요?  많은 사람들에게 편리함을 제공 잠금화면이라는 대부분 사람들이 기존에 크게 활용되지 않고 있던 공간에 Value 를 만드는 것이 버즈빌에서 더 열심히 프로그램을 개발하게 만드는 원동력입니다. 위에도 기술 했지만 저는 가능한 많은 사람들에게 유익을 끼치고 싶어서 Programming 을 하게 되었고 대부분의 다른 산업과 달리 제가 하는 개발 작업은 하나의 복제품을 생성하는데 Ctrl+C / Ctrl+V 만으로 충분하니까 좋은 제품을 만들면 더욱 발전돼서 긍정적인 영향을 더 널리 끼칠 수 있을 것 같습니다.  다른 개발자들이 읽기 쉬운 코드 실제 제가 일을 하면 할수록 기존의 코드를 구조화하고 모듈화하고 사용하지 않는 코드를 지우는 일에 열심을 가지고 있다는 사실을 알게 되었어요. 확장이나 활용이 가능한 Core 나 Library 쪽 개발을 주로 하면서 어떻게 짜면 제 코드를 사용하는 사람이 덜 혼란스럽고 잘 활용할 수 있는지와 어느 곳에 어떤 설계가 어울리는지도 많이 고민해왔던 것 같습니다 버즈빌에서 버즈스크린이라는 상품을 통해서 저의 이런 성향을 마음껏 발휘하고 있습니다. 여러 Publisher 가 쉽게 사용할 수 있어야 하고 SDK 등을 사용할 때 쉽게 Integration 되어야 하기 때문이죠. ‘내가 짠 코드를 인수인계 받을 사람이 연쇄살인범이고 그 사람은 너의 주소를 알고 있다고 생각하고 코딩하라.’ 라는 말이 있는데요. 누구에게도 부끄럽지 않은 코드를 짜려고 항상 노력합니다. 갈 길이 아직 멀지만 연쇄살인범이라도, 어떻게 이렇게 코드를 (잘?) 설계했는지 의논하러 오게 만드는 것이 저의 꿈입니다.     *고성장 스타트업 버즈빌의 채용공고(전문연구요원 포함)를 확인하고 싶으면 아래 버튼을 눌러주세요!
조회수 39

바로고에는 특별한 무언가가 있다~ 바로고의 비타민데이

[비타민데이]2017년이 시작된지 얼마 되지 않은 거 같은데벌써 1월이 끝나갑니다.요즘따라 날씨도 더 추웠어요.이럴때 우리는 챙겨주는 것은'바로고'뿐이다!바로고에는 특별한 무언가가 있어요.매월 1회임직원들의 건강까지 생각하는비타민데이를 진행합니다.센스있게 세팅까지 마무리한바로고의 비타민데이건조한 피부와 비타민 보충을 위해꼭! 챙겨 먹어야할 과일바로고에서는 사과, 배, 귤을 준비했어요.과일을 잘 챙겨드시면몸 안의 수분이 보충되고비타민까지 챙길 수 있어서꾸준히 잘 챙겨드시면피부도 좋아지는 효과가 있으니꼭! 챙겨 드세요^^MISURA 제품도 함께 준비했어요.아무래도 배고픔을 채우기에는탄수화물 섭취는 필수 입니다.다른 각도에서 인증샷을 찍으니좀 더 색다른 느낌.사무실이 아니라 카페에 온듯한 느낌이 드네요~인증샷 타임이 끝나자바쁘게 움직은 손들!기다렸다는 듯 비타민을 보충하기 시작 합니다.특히 아침을 잘 챙겨 먹지 못하시는 분들이제일 좋아하는 바로고 타임비타민데이 입니다.함께 비타민데이를 즐기는 모습입니다.바로고에만 있는 특별함바로고에는 특별한 무언가가 있다.임직원의 건강까지 생각하는바로고의 따뜻한 마음이 느껴지는사내 복지 중의 하나 입니다.바로고에는 임직원들을 위한다양한 복지들이 준비되어 있어요.모든 복지들이 호응도가 좋지만그 중에서도 비타민데이는임직원분들의 반응이 뜨거워요~역시 맛있는 것이 쵝오!어느새 비워져 가는 테이블든든하게 아침식사를 하고 업무를 위한 대화가 오고 갑니다.업무 외 이런 시간들이바로고 안에서 끈끈한 무언가를 만들고더 나은 바로고를 만들기 위해함께 노력하는 원천이 되는 것 같아요.앞으로도 바로고는 함께! 즐거운 마음으로 나아가겠습니다.다음에는 어떤 특별함을 찾아올지기대 많이해주세요!"바로고에는 특별한 무언가가 있다"바로고의 비타민데이 였습니다.감사합니다.
조회수 835

아마존 리스팅 최적화에 대한 고찰

인사말안녕하세요 대한민국 셀러들의 아마존 진출을 도와주는 컨설팅 회사이자 업무 대행사인 컨택틱의 이이삭 대표입니다.오늘 제가 여러분께 소개해드리고 싶은 주제는 '아마존 리스팅 최적화에 대한 고찰'입니다.INTRO. 리스팅 최적화의 중요성너무나도 많은 분들이 아마존 리스팅 최적화의 중요성을 간과하고 있습니다. 물론 그 어느 아마존 셀러라고 하더라도 본인의 리스팅을 최적화 시키고 싶어 할 것입니다. 하지만 여러분은 본인의 아마존 리스팅을 최적화 하는 것에 대해 어느 정도로 간절하신가요? 물론 가독성 높은 상품 설명글은 구매전환에 치명적인 요소 중에 하나로써 굉장히 중요합니다. 다들 아는 이야기죠. 하지만 상품 설명글은 고객이 여러분의 상품에 대한 더 깊은 이해를 할 수 있게 할 뿐만 아니라, 가장 중요할 수도 있는 '아마존 검색 결과 내에서의 노출'과 직접적인 연관을 가지고 있습니다.PROBLEM. 내 리스팅은 노출이 안되는 것 같습니다아마존은 전자상거래 시장입니다. 즉, 고객들이 쇼핑할 때 가장 먼저 하는 일이 바로 '검색'이라는 것을 절대로 간과해선 안됩니다. 백화점에 입점된 상품들이 1층 맨 앞에 전시되어 있어야 잘 팔리듯이, 아마존에서도 내 리스팅이 검색 결과 맨 앞 맨 상단에 노출되어야 그만큼 잘 팔릴 가능성이 높아집니다. 하지만 검색 결과에서 내 리스팅이 보이지 않았을 때 원인이 두 가지가 있을 수 있다는 것을 명심해야 합니다. (1) 아마존에서 해당 키워드 검색 결과와 내 리스팅에 대한 연관을 짓지 않기 때문에 아예 검색 결과에 안 나오는 경우 (이걸 보고 keyword indexing 키워드 인덱싱이라고 합니다). (2) 검색 결과 안에 내 리스팅이 존재하긴 하는데, 너무 뒤에 밀려 있어서 고객들의 눈에 안 띄는 경우. 분명히 해당 키워드에 대해 내 리스팅이 인덱싱은 되고 있지만 아무리 뒤 페이지까지 넘기더라도 보이지 않는다면 그것은 마치 백화점에 판매자로 입점했는데 상품은 창고에만 보관되어 있어서 매일매일 백화점을 방문하는 고객들이 내 상품을 보지도 못하는 상황과 동일한 것입니다.SOLUTION. 어떻게 하면 내 리스팅이 노출될까?여러분께서 이해하기 쉽도록 하나의 예시를 들겠습니다. 여러분께서 sunscreen을 판매한다고 가정하겠습니다. 여러분은 당연히 여러분의 리스팅 상품명 및 상세 설명에 sunscreen이라는 단어를 삽입하겠지만, sunscreen을 sun cream, sun gel, sun block 이라고 표현하는 미국 현지인들도 굉장히 많다는 것을 간과해선 안됩니다. 만약 여러분의 리스팅에 이러한 유의어/연관어들이 최적화되어 들어있지 않다면 여러분의 리스팅은 결국 sunscreen이라는 키워드로 검색해서 유입되는 고객들에게만 노출될 뿐 나머지 키워드를 타고 들어오는 고객들에게는 리스팅이 노출되지 않게 됩니다. 여러분의 상품이 sun cream, sun gel, sun block 등의 단어들과 연관성이 없어서요? 아닙니다. 아마존 시스템에서 그걸 알아차리지 못하기 때문입니다. 리스팅의 그 어디에도 표현하지 않았기 때문이죠. 그렇다면 답은 '올바른 키워드들을 찾고' '해당 키워드들을 자연스럽게 내 리스팅에 녹이게 만드는 것'이 핵심이라고 볼 수 있겠습니다.1. 올바른 키워드를 찾아라제 포스트를 한 번이라도 읽어보신 분들은 잘 아시겠지만, 저는 그 누구의 주관적인 생각도 믿지 않습니다. 항상 숫자와 데이터로 입증할 수 있는 결론이야말로 안심하고 진행하는 것이 제 성격인지라 자연스럽게 제 블로그 글들도 그런 위주로 작성이 되는 것 같습니다. 올바른 키워드를 찾는 것 또한 역시 주관적인 생각을 버려야 합니다. 앞서 언급했던 예시에서 sunscreen이라는 단어를 sun gel, sun block, sun cream 등등의 방법으로 표현할 수 있을 거라고 제가 얘기를 했지만, 이것 또한 지금 이 글을 쓰고 있는 현재 시점에서는 그저 제 주관적인 의견일 뿐입니다. 실제로 미국 현지 고객들이 해당 키워드들로 구글이든 아마존이든 검색을 하고 있으며 그 검색량이 많다는 것을 숫자로써 증빙하기 전까지는 저 자신도 쉽게 결단을 내리지 않을 것입니다. 오직 이러한 factual data에 대한 확신이 생긴 뒤에야 올바른 키워드를 찾았다고 결론 내릴 수 있습니다. 컨택틱은 아마존 고객들이 어떤 키워드에 대해 얼마나 많이 검색하고 있는지, 그리고 그 키워드와 연관된 키워드/키워드절 (keyword phrase)가 어떤 것들이 있는지도 명확히 알아낼 수 있는 노하우가 있습니다. '내 리스팅에 대한 올바른 키워드를 찾는 것에 대한 도움'이 필요하신 분은 컨택틱을 찾아주세요.2. 키워드를 자연스럽게 리스팅에 삽입하라올바른 키워드를 찾았다면 그다음으로 해야 할 일은 리스팅에 빠짐없이, 하지만 자연스럽게 삽입하는 것입니다. 이 부분은 유난히 어려운 것이 사실입니다. 상품명에는 200 byte가 최대 입력 제한이며, 강조 포인트에는 한 줄당 250 byte, 상품설명란에는 2000 byte가 최대입니다. 하지만 그 안에서도 아마존이 어느 정도의 글자까지는 indexing 시킬지는 미지수입니다. 저희가 할 수 있는 최선은 단지 최대한 많은 유의어들과 연관어들을 상품명, 강조 포인트, 그리고 상품설명란에 입력하는 것일 뿐입니다. 하지만 마구잡이로 키워드 또는 키워드절들을 도배하는 것은 아마존뿐만 아니라 고객들의 눈에도 당연히 이상해 보이고 오히려 부작용을 불러일으킬 확률이 높습니다. 따라서 올바른 키워드를 수집하고 목록화했다면 영어를 원어민급으로 구사할 수 있는 주변인에게 도움을 받아서 자연스럽고 매끄러운 copywriting을 요청하거나 전문 업체에게 의뢰해보시길 추천드립니다. 컨택틱의 '고급 상품 등록 대행' 서비스는 올바른 키워드를 찾는 단계에서부터 copywriting 단계까지도 해결해주는 서비스이다 보니, 도움이 필요하신 분들은 언제든지 컨택틱을 찾아주시기 바랍니다.3. 기타 조심해야 할 사항타사 브랜드명은 리스팅에 넣으면 안 됩니다. 타사 브랜드명을 내 상품의 PPC 광고할 때 타깃 할 키워드로 설정할 수는 있으나 리스팅 최적화 단계에서는 엄격히 금지사항입니다. 이런 부분을 간과하고 경쟁사들의 브랜드명을 리스팅에 포함한 어느 한 셀러는 리스팅도 강제로 내려갔으며 판매 권한도 박탈 당하게 되었습니다. 그 외에도 한 번 사용한 키워드/키워드절은 두 번 중복 입력할 필요가 없습니다. 아무래도 제한된 입력 가능 란들 안에서 최대한 자연스럽게 copywriting을 해야 하는데, 거기에 더해서 한 번 사용한 키워드는 가급적 두 번 사용하지 않으려는 것은 정말 머리 아프고 어려운 작업일 수밖에 없습니다. 하지만 글자 수가 제한된 만큼 최대한 중복 키워드는 사용하지 마시고, 주어진 칸들을 최대한 유리하고 노출이 많이 될 수 있는 방향으로 꾸며보시기 바랍니다.그럼 오늘도 즐거운 글로벌 셀링 되세요!컨택틱  서울특별시 강남구 강남대로 62길 11, 8층 (역삼동, 유타워)  대표 전화: 02-538-3939  해외 부서: 070-7771-1727  영업 부서: 070-7771-1728  이메일: [email protected]  유튜브: https://www.youtube.com/channel/UC8OxbQGAnMqWGpGj5weLcZA 홈페이지: https://www.kontactic.com
조회수 4725

실패한 프로젝트, 더 자세히 리뷰하라.

대부분의 프로젝트는 실패한다. 처음 세웠던 계획대로 진행되는 경우는 거의 본적 없다.원숭이도 나무에서 떨어지고, 아키텍트도 당연하게 실패를 자주 만나게 된다. 그리고, 프로젝트는 언제나 성공하지 않는다. 성공과 실패를 거듭할 뿐이다. 여기서, 실패를 어떻게 다루느냐에 따라서 아마추어와 프로의 차이는 극명하게 구분된다.아마추어는 실패를 변명하기에 급급하지만, 프로는 실패를 냉정하게 인정하고, 실패를 하게 된 이유를 찾고, 똑같은 실패를 반복하지 않기 위해서 실패의 원인에 대해서 분석하고 리뷰한다.많은 실패를 거듭할수록 전문가가 된다. 전문가는 실패를 반복하지 않기 위해서 언제나 실패에 대해서 필요한 리뷰 스킬을 높이게 된다. 이번 이야기에서는 필자가 지켜보았던 미니 프로젝트의 하나를 기준으로 실패에 대한 이야기를 해보도록 하겠다.여기서 이야기하는 프로젝트는 처음부터 실패가 될 것으로 예견되었다. 그리고, 그 예견된 결과대로 실패했다. 결론적으로 해당 팀이 해체되었고, 관련된 개발자들은 흥미를 잃고 해당 업체를 떠나게 되는 상황까지 진행되었다.문제가 더욱 심각한 것은 이러한 실패의 이유에 대해서 예견되었고, 그 문제를 지적하고, 향후 그 처리방안을 경영진에게 제시하였지만, 결론적으로 회사의 리더의 생각이 변화하지 않았기 때문에 ‘실패에서 주는 경험’이 제대로 전파되지 못했다. 하지만, 아키텍트는 이러한 실패에 대해서 분명하게 기록해두고, 다시 그러한 실패를 하지 않도록 준비를 하는 것이 전문가로 성장하는 가장 중요한 버릇 중의 하나라고 이야기하겠다. 아키텍트가 아니라고 해도 개발자는 자신만의 노트로 '실패'를 기록해야 한다."어떤 실패한 프로젝트에 대한 리뷰"실패에 대해서 정의할 수 있는가? 이 기준에 대해서 느슨하게 적용하게 되면 대부분의 프로젝트는 실패할 이유가 없어지며, 매우 엄격하게 적용하게 되면 대부분의 프로젝트는 실패라고 기록될 것이다.필자는 프로젝트의 성공과 실패의 요소에 있어 가장 중요한 것은 ‘비용’이 계획보다 많이 투자되었다면 그 프로젝트는 ‘실패’라고 평가를 한다. 가능하다면, 아키텍트를 목표로 하고 있는 개발자라면 모든 프로젝트의 기준과 투입인력, 시간과 하드웨어 리소스들을 모두 ‘비용’으로 환산하는 방법을 터득하는 것이 좋다.가능하다면, 필자는 이 기준으로 프로젝트를 평가한다.이 기준에 따라서 필자가 지켜본 미니 프로젝트를 평가해보자. 소프트웨어 개발자의 실제 일하는 것들이 모두 비용이고, 그들이 투입되고 생각하고, 무언가를 하는 행위들은 대부분 ‘비용’으로 모두 환산할 수 있다. 이러한 비용을 기준으로 프로젝트에 투입되게 되면 초기에 필자가 프로젝트의 기준을 세우는 원칙은 다음과 같다.소프트웨어 디자인과 기획에 30%, 실제 개발에 50%, 테스트에 20%를 투여하는 법칙이다. 다만, 이 수치에서의 약간의 차이는 투입되는 팀원이나 회사의 사정에 따라서 조금씩 달라지기는 하지만, 필자는 가능하면 저 수치를 지키려 한다.그동안의 필자의 경험으로 느껴지는 저 수치는 약간의 조정이 있을 수 있으나, 대부분의 국내의 프로젝트에서는 대부분 일치하거나 근사치로 정의될 것이다. 이번 이야기에서 언급하려는 프로젝트는 2013년도에 필자가 실패한 프로젝트의 사례에 해당한다.이 규칙에서 기획에 30%의 투자가 있었어야 했는데, 실제 초기 기획에 2%도 안 되는 투자 후에 실제 개발이 진행되면서, 프로젝트가 제대로 진행되지 않는 케이스가 발생하였다.물론, 이번의 케이스는 작은 스타트업에서 매우 작은 외주 프로젝트를 진행하는 일이었는데, 실제 프로젝트에 참여할 팀원의 구성이나 팀워크, 주된 목표치에 대한 설정 등이 제대로 서술되지 못하면서 기획이 제대로 진행되지 못한 케이스가 되었다.작은 모바일 프로젝트였고, 필자가 판단하기에 4주면 넉넉하게 해결될 프로젝트가, 필자의 계산착오로 4개월간 뒤틀린 프로젝트가 벌어지게 된 것이다. 필자는 왜 이런 실수를 하게 된 것일까?기본적은 린 개발 방법이나 에자일 방법과 같은 방법론의 문제가 아니라. ‘초기 기획’이 부정확한 상태에서, 팀워크도 갖추어지지 않고, 소통이 안 되는 팀원들이 보고체계가 붕괴된 상태에서 프로젝트가 지속되면서, 팀 자체가 와해되어 버린 아주 엉터리같이 진행된 프로젝트가 되어버렸다.필자도, 이러한 대대적인 실패에 대한 경험을 정말 오래간만에 한 셈이 되었는데, 결론적으로는 프로젝트를 수행할 제대로 된 팀원을 제대로 세팅하지 못한 ‘인사’에서 그 문제는 시작되었다고 프로젝트의 실패 원인 중에 가장 큰 원인을 지적하고 싶다.목표도 불확실한 상태에서 기획이 제대로 진행이 안되었고, 서버 개발자의 능력 부족에 아이폰과 안드로이드 앱 개발자의 자기 멋대로의 전횡과 서버 개발자가 이중으로 서버 인터페이스를 구현하면서 보고체계까지 제멋대로 진행된 아주 최악의 프로젝트가 진행되었다는 것을 거의 프로젝트 후반부에 가서야 알 수 있었다. 말 그대로 전형적닌 실패사례가 된 것이다.결론적으로 이야기하자면, 가장 먼저 이야기한 ‘기획’이란 팀 빌딩과 목표 수립과 같은 부분에 대해서 제대로 된 접근을 수행했어야 했는데, 이 부분에 대한 고려와 협의 없이 진행되면서 프로젝트가 일정에 떠밀려서 진행되면서 프로젝트가 상당히 누더기가 되어버렸다.어떻게든 중간에 올바른 방향으로 유도하려고 하였으나, 언제나 입버릇처럼 말하듯이 ‘한번 기본이 뒤틀린 경우에는 다시 바로 잡을 수 없다’가 정답이고, 그 여파로 인하여, 많은 비용과 시간적인 소모, 정력적인 소비까지 매우 불유쾌하게 진행된 프로젝트였다.결론적으로 이 프로젝트는 마무리는 되었지만, 이 프로젝트를 참여하게 된 팀원들은 모두 해산되고, 서버 개발자만 빼고는 모두 팀에서 해체가 되게 되었다. 물론, 이 프로젝트 이후에 해당 문제들을 보완한 상태에서 다시 프로젝트는 본래의 궤도로 올려놓기는 했지만, 이렇게 진행된 부분에 대해서는 명세 화가 절실하게 필요하고, 이를 리뷰해야 한다.이 프로젝트의 가장 큰 원인은 개발에 참여한 개발자나 디자이나, 기획자나 PM의 문제가 아니라, 전체적인 개발의 틀을 만들어 주어야 하는 ‘개발회사의 경영진’이 가장 큰 문제였다. 말 그대로 ‘인사’ 문제였다. 그중에 몇 가지의 문제들에 대해서 언급해보자."개발자의 의사소통의 문제"후반부에 개발과 관련된 보고체계의 문제점은 서버 개발자와 클라이언트 개발자 간의 의사소통과 의사결정에 대해서 개발자들 간에 ‘숨겨왔던 문제’가 드러났다. 가장 큰 원인은 ‘보고’를 제대로 하지 않았다는 것이다.안드로이드와 iOS의 앱 개발을 동시에 진행하였는데, PM이 인터페이스를 ‘동일’하게 추상화해서 구현하라는 방향성에 대해서 클라이언트 개발자들과 서버 개발자들이 서로 협의한 것이 아니라, 서버 개발자가 클라이언트 개발자들의 요구조건을 모두 받아들여, 인터페이스가 두배로 늘어나고, 테스트와 관련된 처리 방안들이 모두 증가하게 된 것이다.실제, 클라이언트에서 구현해야 하는 상당 부분의 기능들을 서버에서 구현하게 한 것은 향후 Web개발을 일부 처리하기 위한 방안이었는데, 이 부분들이 모두 무시된 채로, 클라이언트 개발자들 간에 자신이 하고 싶은 개발을 추진하면서, 서버 개발자가 의지 없이 끌려다닌 결과물이었다.당연하지만, 개발 일정이 늘어나고, 테스트도 진행되지 못하면서, 품질이 저하되는 것뿐만 아니라, 전체적인 프로젝트가 모두 붕괴되었다. 참으로 애통스러운 상황을 지켜보아야 하는 마음은 참으로 아픈 경험이다.그래도, 최악의 프로젝트였지만 ‘테스트’가 좀 더 명쾌했다면, 이 프로젝트는 초기에 문제를 잡을 수 있을 가능성이 있었다. 그래서, ‘테스트’에 대해서 몇 가지 더 정리해봤다."테스트, 그 계획과 실행의 전부"과연, ‘테스트의 적정선은 어느 정도 인가?’. 소프트웨어 개발에 있어서 테스트에 투입되는 비용이나 기간에 대해서 근접한 수치를 보여주거나 적절한 경험성을 부여하는 경우가 매우 드물다. 다만, 경험자의 직관에 의존하는 경우가 많거나, 각 개발사의 프로세스에 따라서 정형화되어 있는 경우가 많다.실제 자기 자신에게 다음의 화두들을 던져보자.정말로 테스트 커버리지 100%의 테스트란 존재하는가제품 개발 시간과 테스트 코드의 비율은 어느 정도가 적정한가?개발에 착수하기 전에 테스트를 얼마나 준비해야 하는가?통합 테스트는 매번 해야 하는가?테스트 전담자는 있어야 하는가?TDD는 비용 합리적인가?과도한 테스트란 어떤 것을 의미하는가?실제 개발환경에서 테스트란 무엇인가?현장 품질 커버리지란 무엇인가?테스트에 대해서 위의 질문에 대해서 독자들은 얼마나 명쾌하게 답변을 할 수 있을까? 아마도, 다음번 칼럼에는 테스트에 대해서 좀 더 자세한 이야기를 할 것으로 계획을 잡고 있다.테스트에 대한 유명한 Kent Beck의 말을 인용해보자.I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don’t typically make a kind of mistake (like setting the wrong variables in a constructor), I don’t test for it.나는 코드가 작동하는지에 대해 보수를 받지, 테스트를 위해서는 보수를 받지는 않는다. 그래서 나의 철학은 신뢰할 수 있는 수준에 도달하기 위해 가능한 한 테스트를 적게 한다는 것이다.(신뢰할 수 있는 수준이라는 것은 업계 표준에 비해 높다. 조금 거만한 들릴지 모르지만). 만약 전형적인 실수(생성자에서 다른 변수를 설정하는 것 같은)를 하지 않는다면, 나는 테스트하지 않는다.-Kent Beck의 말소프트웨어 개발자들에게 테스트 환경과 테스트 조직, 테스트 문화에 대해서 강요하는 것이 바람직한가?라는 물음에 필자는 이렇게 이야기하고 싶다. ‘개발자’에게 ‘테스트’를 강요하지 말고, ‘테스트한 경과’를 제시하고 ‘수정’과 ‘제대로 된 결과’를 강조하라.일반적인 소프트웨어 개발에 대해서 무지한 사람들의 반복적인 질문은 ‘소프트웨어 개발자들은 왜 테스트를 소홀하게 하는 가?’라는 질문을 버그가 발생할 때마다 이야기를 한다. 대부분의 소프트웨어 개발은 ‘목표’가 불명확하기 때문에 ‘버그’가 발생한다고 생각한다.아마도, ‘개발자’에게 사용자의 ‘제약사항’과 ‘하지 말아야 할 행위’에 대한 언급이 없었다면, 개발자는 문제 해결을 위하여 상당 부분 위험요소를 건너뛰거나 넘어서게 된다. 물론, 적절한 여유시간과 품부 한 리소스를 제공한다면, 당연하겠지만. 튼튼한 소프트웨어를 만들기 위해서 노력한다. 하지만, 일정이 정해지고, 목표가 명확한 SI성의 프로젝트의 경우에는 ‘목표’를 향해서 가장 빠른 코드를 만들기를 강요하기 때문에, 이때에 만들어지는 ‘버그’의 대부분은 개발자의 실수이기보다는, ‘요구사항’에 대한 부정확한 전달 때문이다.별 요구사항이 없는 것 같은 DataGrid를 만들어 달라고 이야기를 했지만, 사실, 고객은 Excel정도의 기능을 원하고 있다. 하지만, 일정과 비용상의 문제 때문에 단순 데이터의 표현을 위한 DataGrid인 것처럼 요구를 하는 경우가 대부분이다.이때에 개발자는 당연한 것처럼 최소한의 제약사항과 요구사항을 통해서, ‘숫자’만을 처리할 수 있는 DataGrid를 만들지만, 고객은 개발에 착수함과 동시에 다양한 요구사항들을 요구한다. 문자열을 처리해달라, 날짜, 함수 등등… 그리고, 종이 출력도 자연스럽게 되게 해달라고 한다.개발자는 중간에 발생한 요구사항과 제약사항에 최대한 맞추려고 기능들을 구현하다 보면, 당연한 것처럼 특정 이슈만 처리하는 기능으로 구현되고, 다른 프로세스에서는 당연한 듯이 버그와 같은 현상을 발생시킨다.그럴 때에 고객은 이야기하고, 개발회사의 사장도 이야기한다. ‘개발자가 테스트도 없이 소프트웨어를 만들고 있다’고. 이것이 현실이다.대부분 소프트웨어 개발에 대해서 무지하기 때문에, 이런 일이 반복된다. 필자도, 이러한 경험을 최소한으로 하려고 하였지만, 역시. 회사의 대표가 되어서 프로젝트의 계약부터 관여하기 전에는 이러한 문제들을 모두 해결할 수 없다는 것이 정답일 것이다.필자는 단언한다. ‘소프트웨어 개발자에게 넉넉한 일정과 풍부한 리소스를 제공하지 못한다면, 소프트웨어 개발자가 모든 것을 해결할 것으로 기대하지 말아라’. 다만, ‘소프트웨어 개발자들이 보다 원활하게 개발에 전념할 수 있도록 다음과 같은 필수조직이 따라붙어야 한다.하나. 요구사항에 대해서 고객과 꾸준하게 소통할 수 있는 담당자나 조직둘. 정해진 일정에 맞추어 기능이 동작할 수 있게 하는 테스트 담당자나 조직하지만, 보통의 스타트업이나 작은 SI를 전담하고 있는 기업의 경우에는 위의 가장 중요한 두 조직이나 담당자들이 대부분 부재중이거나 기능이 모호한 경우가 많으며, 위의 두 가지 기능을 모두 담당 개발자의 책임으로 귀속시킨다.만일 이러한 기능이나 리소스를 모두 담당 개발자에게 귀속시키고 있는 회사나 조직에 있다면, 조직을 다시 만들거나, 해당 기업을 빠른 시일에 빠져나가는 것이 가장 현명한 방법일 것이다. 대부분 소프트웨어 개발에 무지한 경우에 이 두 기능을 너무 소홀하게 하고, 개발자들이 대부분 야근과 휴일근무를 밥먹듯이 하게 되는 경우가 이에 해당된다.실제 필자 또한 경험이 풍부했지만, 실제 기업의 인사권과 경영권이 없었기 때문에 이에 대해서 해결할 수 없는 경우를 또 만났기 때문이다. 그래서, 또 실패했다. 아무리 경험 많은 사람이라고 하더라도, 이미 알고 있는 내용이라고 하더라도. 그것을 실제 바꾸지 못한다면, 필패한다는 것이 소프트웨어 개발의 현장이다.그래서, 필자도 크게 실패한 경험을 또 하나 기록에 남기게 되었다."체계적인 품질관리 지표"개발과정에서 발생되는 요구사항의 지표에 대해서 NIPA의 SW Visualization을 참조하면 요구사항 추적성, 요구사항 달성률, 요구사항 커버리지의 3가지 지표에 대해서 서술하고 있다. 여기서, 달성률과 커버리지는 100% 처리가 되는 것을 목표로 움직이는 정략적인 지표로 보면 되고, 실제 개발현장에서 주목할 부분은 요구사항 추적성을 주목해야 한다.개발 공정별로 요구사항의 일관성이 어떻게 유지되고 있는지 확인하면서, 형상관리가 등록된 내용의 변경률과 비교하면서 요구사항의 변화된 추이를 꾸준하게 주목해야 한다. 대부분, 이 부분 때문에 개발이 뒤틀리는 진입점을 제공하게 된다.품질검증에서 사용되는 정적인 테스트는 ‘코딩 표준 준수율’과 ‘메트릭 만족률’, ‘정적 분석 이행률’을 기반으로 진행된다. 대부분 이 정적인 테스트는 ‘자동화 도구’를 사용하여 코드의 룰과 만족 여부를 확인하기 때문에 결국은 ‘개발 비용’을 얼마나 투자하느냐에 달려있는 부분이라고 할 수 있다. 특히, ‘정적 분석 이행률’과 같은 SW 실행 전에 잠재적인 결함을 분석하는 것은 이러한 투자 없이는 대부분 이룰 수 없는 수치이다. 그래서, 보통 ‘정적 테스트’는 제대로 갖추어진 개발 조직이 아니라면 성립하기 어려운 지표가 된다.보통, 이 ‘정적 테스트’ 지표를 얼마나 진행하고 있느냐에 따라서, 소프트웨어 개발 조직의 성숙도를 체크할 수 있으며, 소프트웨어 개발 조직에 얼마나 투자를 하고 있느냐에 대해서 알 수 있는 지표이기도 하다.보통은 품질검증에서 동적 테스트로써 요구사항 검증방법과 구조 검증방법이 진행되는데, 마찬가지로 구조 검증인 구조적 커버리지 또한 Basic path, Statement, Branch, MD/DC Coverage 등을 선택해야 하므로, 이 또한 개발 조직의 투자 없이는 이루어지기 힘들다. 그래서, 대부분의 개발 조직 현장에 가보면 기능 검증, 비기능 검증, 정형 검증, 사용자 검증 중에 기능 검증과 사용자 검증만을 취해서 품질검증을 하는 경우가 대부분이다.소프트웨어 개발자에게 ‘품질검증’을 제대로 요구하기를 원하는 조직이라면, ‘정적 테스트’를 수행할 수 있는 투자나 일정, 준비 또는 품질 관련 조직이 세팅되어 있어야 한다. 이러한 단계 없이, 개발자에게 ‘테스트’를 제대로 하지 않는다고 강요하는 개발회 사는 정말 크게 잘못된 케이스라고 보면 된다. 그런 회사는 배울 것도 없으니 피하는 것이 최선이다.또한, 기능 검증이나 비기능 검증 또한 테스트 케이스에 대한 자동화된 방법들을 사용하지 않는 다면, 이 또한 개발자에게는 상당히 모호한 테스트들만이 존재하게 된다."좌우지간, 소프트웨어 개발의 시각화"소프트웨어 개발의 경험자라고 하더라도, 소프트웨어 개발 현장에서 일어나는 일들을 모두 파악할 수 있는 방법은 ‘지감’밖에 없을 것이다. 그래서, 소프트웨어 개발에 있어서 적정한 범위까지 개발의 과정을 ‘시각화’하는 기준이 필요하다.하지만, 이 ‘시각화’는 말 그대로 ‘과비용’으로 책정되거나, 소프트웨어 개발을 하기도 어려운 일정과 시간에 촉박한 경우에는 이 시각화의 최소 영역에 대해서 고민하고 결정해야 한다. 완전한 시각화를 이룰 경우에는 소프트웨어 개발 관리조직과 품질조직, 테스트 조직 등의 PM관리체계가 완비되어 있는 경우에만 이러한 과정을 수행하는 것이 최선이다.그리고, 중요한 케이스나 문서 등에 대해서 품질관리 조직과 PM조직이 해당 문서를 작성하는 것이 되어야지, 각 개발자에게 이러한 업무를 전가하는 방식으로 진행되어서는 문제가 해결되지 않는다. 언제나, 품질조직은 옥상옥이 되어서는 안된다.2/2페이지결론적으로 '능력 부족한 개발자'소리를 듣는 것이 대부분이다.대부분 급하다고 일을 의뢰하거나 서비스 론칭을 위해서 급하게 요구하는 경우가 있다. 개발자의 선택은 매우 명쾌하다. 정해진 기간과 인원 숫자로 만들어야 하는 서비스가 특정한 시간 내에 동작하게 하는 방법은 동작시에 제약사항과 커버하지 못하는 품질 이슈를 만드는 것뿐이다.말 그대로 기술적 부채를 만들어 낼 수밖에 없으며, 이 기술적 부채는 결론적으로 반복적인 유지보수 업무와 처리하지 못하는 기능들에 대한 하소연을 만들어 낸다.슬프지만 그렇게 반복되는 과정에서 경영진은 해당 개발자를 신뢰하지 못하게 된다. 그리고, 그렇게 반복적인 유지보수 업무를 만든 것은 개발자의 능력 부족이라고 생각하게 되고, 이 관계는 보고서가 늘어나거나 주간회의시에 디테일하게 보고하라는 식의 결론으로 귀결된다.물론, 이런 상황을 만든 '착한 개발자의 결정'이 문제이기는 하다.대부분 경험이 풍부한 개발자들은 이런 과정들을 반복해 보았기 때문에 처음부터 거부하거나 거절하거나, 적정한 선에서 타협하는 방안들을 제시한다. 물론, 그 과정에서 무지한 경영진과 트러블이 발생하는 것도 다반사이다.이 경우 중간관리자가 개입해서 타협하는 경우가 분명 있다.단언컨대 해당 중간관리자는 둘 중 하나이다. 무지하거나 난파하려는 개발 조직을 재빠르게 떠날 사람이다.소프트웨어 개발에서 '급한 일'이란 없다.정해진 규칙과 기본에 충실하게 하고, 빠진 것 없는지 체크하고 디자인, 설계 후에 미래의 변화에 대해서 적절하게 해당 조직의 규모와 형태에 따라서 반영한 후에 '개발'하는 것이다.지금 이상황에도...'급한 일'이라면서 일을 가져다주는 경영진을 만나고 있을 슬픈 개발자들을 위해서...끄적끄적...#와탭랩스 #와탭 #프로젝트 #인사이트 #경험공유 #조언

기업문화 엿볼 때, 더팀스

로그인

/