제1회 re:View 참석 후기

지난 3월 22일 수요일 오후 늦은 7시, 잠실에 있는 삼성SDS 지하에서는 동회사에 근무하시는 신상재님께서 주관하셨던 코드리뷰관련 Meetup, “제1회 re:View”가 열렸습니다. re:View의 공식사이트, Facebook, Slack, Twiter의 운영과 개인별 문자/메일 발송 등의 멀티채널을 통한 참가자들의 압박(…)은 그 많은 인원이 평일 오후에 참석할 수 있었던 큰 원동력이 된 것 같습니다. 이뿐만 아니라 컨트롤이 힘든 자녀를 둔 맞벌이 개발자와 취업에 고군분투하고 있는 취업준비생을 위한 배려는 그동안 제가 참석한 다양한 Meetup에서는 단 한번도 보지 못한 멋진 운영중 하나였습니다.

Read More

Jekyll Page에 기능 추가하기

Markdown 형태의 정적인 페이지가 너무 밋밋하고 피드백을 받을 수 있는 영역이 없을 뿐더러 나중에 글이 늘어나면 포스트 관리의 어려움도 걱정되는 터라 몇개의 기능을 추가해보려 합니다.

페이스북 소셜플러그인 – 댓글기능 추가

페이지 하단의 페이스북 댓글 창을 추가하기 위해서 해야할 작업은 그리 어렵지 않습니다. 우선 페이스북 개발자 소셜 플러그인 패아자내의 “댓글 플러그인 코드 생성 도구”를 통해 쉽게 코드를 얻어올 수 있습니다. url항목은 어차피 Liquid태그로 수정을 해야하니 대충 넣고, 너비는 Responsive한 웹을 위해 100%, 게시물 수는 입맛에 맞게 넣습니다. 저는 default로 되어 있는 ‘5’를 사용했습니다. 3개의 항목을 채우고 해당 서식 바로 아래 있는 코드받기를 통해 두개의 코드를 받아옵니다.

<div id="fb-root"></div>
<script>(function(d, s, id) {
  var js, fjs = d.getElementsByTagName(s)[0];
  if (d.getElementById(id)) return;
  js = d.createElement(s); js.id = id;
  js.src = "//connect.facebook.net/ko_KR/sdk.js#xfbml=1&version=v2.8";
  fjs.parentNode.insertBefore(js, fjs);
}(document, 'script', 'facebook-jssdk'));</script>

첫번째의 코드는 페이지내의 <body>태그 바로 뒤에 붙이라고 가이드가 되어 있습니다. 그렇다면 우리는 _layout/default.html<body>태그 뒤에 바로 붙여줍니다. 그리고 두번째로 주어지는 페이스북 댓글창으로 사용될 코드인데, 댓글은 각 페이지의 주소마다 다르게 보여집니다. 따라서 data-href의 값으로 고정주소를 선언하게 되면 블로그내의 모든 포스팅에서 모두 동일한 페이스북 댓글창을 사용하게 됩니다. 따라서 Liquid문법을 이용하여 현재 페이지의 url을 동적으로 생성하고 이렇게 만든 두번째 html코드를 _include/post.html에사용하도록 합니다.

<div class="fb-comments" 
     data-href={{ site.url | append: page.url }}
     width="100%" 
     data-numposts="5" ></div>

웹에서의 페이스북 소셜플러그인 댓글 기능의 사용은 별도의 App-id가 필요없이 현재 포스트에 대한 url을 해당 data-href에 어떻게 지정할지만 고민을 하면 아주 손쉽게 붙일 수 있습니다.


TAG 기능

TBD

Read More

제1회 re:View 참석 후기

행사 진행 관련

삼성SDS의 신상재님께서 사내 개발자 포탈을 통해 무언가 심상치 않은 이벤트가 될것이라고 예고하셨던 만큼 기대가 많이 되었으나, 이정도로 완벽하게 준비하실 줄을 상상도 못했습니다. 사내외 참석자들의 접수부터 아이를 동반한 개발자들의 참석유도, 다양한 간식, 스폰서 유치, 각종 경품마련 그리고 사외행사를 잠실사옥에 유치하기 위한 장소섭외 관련 내부 프로세스 진행 등 어느하나 준비가 쉬워보이는 게 없었는데 이걸 해내셨습니다. 저는 특히 re:View의 공식사이트, Facebook, Slack, Twiter의 운영과 개인별 문자/메일 발송 등의 멀티채널로 참가자들을 참가를 압박(…)하는 운영은 그 많은 인원이 평일 오후에 참석할 수 있었던 원동력이 된 것 같습니다. 이뿐만 아니라 컨트롤이 힘든 자녀를 둔 맞벌이 임직원을 위한 좌석, 취업 고군분투하고 있는 취준생을 위한 좌석 등 그간 제가 참석한 사내외 Meetup에서는 단 한번도 보지 못한 배려가 정말 돋보였습니다. 이 글을 통해 감사의 말씀을 드립니다.

행사는 1부 서지연님 발표, 2부 김헌기님 발표, 3부 QnA로 구성되어 있었으며 발표중 질문이나 요청은 Slack채널의 운영으로 현장에서 온라인을 통한 참석자들의 참여가 있었습니다.

Forest

1부 : 코드리뷰를 시작하려는 그대에게(서지연@카카오)

카카오 서지연님의 사외 발표는 지난 나프다 컨퍼런스를 포함 2번였고 저는 운좋게 그 두번의 발표를 모두 라이브로 들을 수 있었습니다. 나긋나긋하며 또박또박한 발음으로 발표하시는 서지연님의 발표는 내용이 재미있어서 다행이지 따분한 내용의 발표였다면 청중의 수면을 유도하기 참 좋은(…) 목소리인 것 같습니다. 각설하고, 서지연님은 사내에서 경험한 본인의 코드리뷰를 바탕으로 이야기를 풀어나가셨습니다.

왜 코드리뷰를 시작하려 하는가?

내 코드가 부끄럽습니다. 이는 주니어뿐만 아니라 시니어들도 가지고 있는 생각일 것입니다. 보잘것 없는 코드가 타인에 의해 드러나는 것도, 의견을 주고 싶은데 잔소리로 오해 받을까봐 걱정되는 것도, 코드리뷰를 경험해보지 않은 인력들에게는 모두 걱정입니다. 코드리뷰란 코드로 대화하는 팀원간의 커뮤니케이션입니다. 부끄러움은 짧고 코드의 히스토리를 길다는 점을 명심해주세요. 잘못된 코드는 누군가에게 레거시코드가 되어 영원한 고통을 안겨줄 수 있습니다. 덮어놓고 코드를 작성하다 보면 장애의 위협은 항상 우리를 괴롭힐 것입니다.

상처를 주거나 받거나하지 말자

자칫 잘못하면 꼰대가 될 수 있음에 주의해야지만, 내가 아는 것을 모르는 사람에게 알려주는 것은 잘못된 것이 아닙니다. 이런 상황에서 온라인으로 진행하는 코드리뷰가 가지는 장점이 여기서 드러납니다. 목소리가 아닌 글로 격려와 칭찬을 하면서 진행하면 이러한 오해를 줄이는데 큰 도움이 됩니다. 코드는 본인이 아닙니다. 나에 대한 평가가 아닌 나의 코드에 대한 리뷰를 받는 것임을 생각하며 진행하도록 합니다.

할 수 있는 만큼만

프로젝트 초반에는 모두 코드리뷰에 대한 열정에 어마어마한 리뷰 요청이 들어오게 됩니다. 하지만, 이를 다 받아주면 내가 해야할 일에 병목이 생기고 번아웃이 되기 쉽습니다. 팀원이 요청한 모든 리뷰에 피드백을 줄 필요는 없습니다. 본인의 업무와 조율하며 코드리뷰 실행을 조절하되 정말 하고 싶거나 또는 좋은 의견을 주고 싶은 리뷰라면 나중에 하기로 약속하는 것도 좋은 방법입니다.

나의 의견을 고수

코드를 통한 협업에서는 가이드라인(Code Fomatting, Naming Rule 등)이 필수이지만 개발자의 취향은 존중받아야함이 마땅합니다. 리뷰어가 해당 코드에 대한 반대의 의견이 있을때는 요청자를 위해 목소리를 내어줘야하고, 요청자 역시 반대의 의견을 듣는 것을 두려워하지 말아야 합니다. 하지만 타당한 이유로 반박해야할 내용이 있다면, 왜 내가 이렇게 작성을 했는지에 대한 설명을 해줘야합니다. 해당코드에 대한 고민은 내가 가장 많이 했으니까요.

도입초반이 중요

초기에는 코드리뷰리더 역할을 가진 멤버가 필요합니다. 코드리뷰 리더는 반드시 개발을 잘하거나 연차가 높은 사람일 필요가 없습니다. 가장 중요한 자질은 적극적으로 코드리뷰를 참여하고 멤버들을 독려할 수 있는 열정을 소유하는 것입니다. 그 후, 메일이나 Slack을 통한 Notification 환경을 구축하고, 칭찬할 내용에 대해서는 아낌없는 따봉을 팍팍 줌으로써 서로 격려하는 문화를 만들어 나갑니다. 정기적인 오프라인 미팅운영도 큰도움이 됩니다. 아낌없는 격려와 칭찬. 이것은 코드리뷰를 도입하는데 있어 큰 밑거름이 됨을 잊지마시길 바랍니다.

나는 무엇이 바뀌었는가?

이전에는 본인 개성을 베이스로 자유로운 코드가 가득했던 반면, 코드리뷰를 통해 타인이 볼 것이라는 압박때문이라도 코드를 한번 더 생각해보는 습관이 생깁니다. 이를 위해서는 적절한 협업도구의 사용이 성공유무를 가르게 될 수 있습니다. 다같이 즐겁게 코딩하는 것이 코드리뷰의 궁극적인 목표임을 다시 한번 상기합시다. 꾸준한 코드리뷰를 통해 팀원들과 협업하는 재미가 생기는 것을 자신을 발견할 수 있을 것입니다.

사내 코드리뷰 경험을 공유해 주신 서지연님의 발표에서 그녀가 대한민국에서 얼마나 행복한 개발자인가를 알 수 있었으며, 그와는 별개로 발표용 키노트에 기가 막힌 타이밍에 삽입한 탁월한 짤방이 청중에게 큰 공감을 가져오게한 능력이 돋보인 발표였습니다.

2부 : 코드품질 개선을 위한 GS SHOP 고군분투기(김헌기@GS SHOP)

행사를 준비하며 온라인에서 보여주신 신상재님과 김헌기님의 모습은 한때 시대를 풍미했던 서수남과 하청일, 서경석과 이윤석처럼 ‘이런 것이 Meetup을 준비하는 자들의 호흡이다!’를 온몸으로 외치는 듯 했습니다. 더불어, 40대 개발자는 이런 자세를 견지해야 팀내의 젊은 후배들과 활기찬 협업을 할 수 있다라는 것을 30대 후반의 미천한 능력을 지닌 저에게 알려주셨습니다. 김헌기님의 직장생활 기간의 희열차트로 시작한 발표는 깨알같은 아들 자랑을 은근 슬쩍하시더니 본인 회사의 자랑을 본격적으로 대놓고 하시는 모습을 보며, 무언가 심상치 않은 발표가 될 것이라 예상했습니다. 홈쇼핑을 통해 물건을 구매하지 않는 저로써는 GS SHOP이 어떤 회사인지, 어떤 비지니스 물밑에서 하고 있는지 몰랐는데, 이런 오프라인 모임을 통해 커머스 비지니스를 하는 IT회사들은 어떤 환경을 가지고 어떤일을 하고 있는지에 대해 조금이나마 알게 되었습니다. 김헌기님이 발표하신 내용을 좀 정리해보자면…

엔터프라이즈 영역에서의 개발

과거에는 회사가 위험요소가 있는 곳은 애당초 가지 않았는데 이제는 이런 위험요소를 탐지하는 것 자체가 어려워졌습니다. 그래서 민첩함을 키워야했고, 현재는 팀장이 직접 코딩도 하고 사내에서 개발관련 지식을 공유하는 세미나도 주관하는 상황에 이르렀습니다. 이는 변화에 적응하기 위해 현업들과 코드로 대화를 해야하는 것이 필요하다는 것을 몸소 깨달았기 때문입니다. 우리모두 변화에 적응하는 유연성을 기르도록 합시다.

레거시 코드와의 사투

GS eShop에서 사용하는 엔터프라이즈 시스템에는 어마어마한 레거시 코드들이 아직도 있습니다. 자바코드 44000줄, A4로 뽑을 경우 670장이나 되는 거대한 양의 코드입니다. 메소드에 파라메터가 20개 이상인 것도 부지기수이고 또한, 개발 기준없이 개발자들마다 본인의 개성에 맞는 스타일로 작업을 하다보니 상황은 점점 절망적이 되어갔습니다. 이런 절망적인 상황에서 이를 해결하기 위해 내부에서 자발적인 고민을 하기 시작합니다. 더러운 코드로 인해 악순환이 계속되는 구조를 클린코드를 유입시키고 이를 통해 테스트 오류를 감지할 수 있는 선순환구조로 바꾸기 위해…

무엇을 했는가?

측정가능한 투명한 품질활동을 위해 관리자와 테스트 전문가가 프레임 워크를 제작하기로 했습니다. Python과 django사용를 사용하여 제작을 했는데 어느 프로젝트나 마찬가지지만 새로운 언어로 개발을 한다는 것은 쉬운일이 아니였습니다. 우리는 방향을 잡을 수 있는 목표보여줄수 있는 가치를 현실화 하기 위해 리더/엔지니어/테스트전문가/보안전문가로 구성된 팀을 꾸렸고, 영어 닉네임을 사용했습니다. 꾸준한 리뷰를 통해 잘못된 코드의 작성자는 즉시 담당자에게 호출되었고, 모의해킹/기능테스트/해킹테스트와 같은 품질향상을 위한 작업 역시 꾸준히 이루어졌습니다. 이리하여 배포품질관리시스템 “de:light”가 탄생되었습니다. 하지만 프로세스와 플랫폼으로 살림살이가 바로 나아지지가 않았습니다. 코드리뷰 문화의 확산 필요해졌습니다. 우선 사내커뮤니티 활성화하고 목표는 유지보수 가능한 코딩 기술을 전수하자는 미명하에 다양한 행사나 사내 Meetup/Hackerthon 등을 진행하였습니다. 코드리뷰는 품질개선의 건전한 활동이자 개발문화입니다.

무엇이 변했는가?

애자일을 시도했지만 우리에게는 이 방식이 불가능 하다고 판단을 하였습니다. 하지만 애자일의 아이템중 취해야 할 것은 과감히 채택하여 적용하였습니다. 특히, 커뮤니케이션 방식의 변화를 위해 주기적으로 업무를 끊고 갈수 있는 스프린트 방식을 도입했습니다. 각자 본인이 한달에 할 수 있는 범위를 정하고 이는 수단과 방법을 가리지 않고 실행하며, 한주의 스프린트 결과를 별거 없거나 아주 작은 내용이라도 팀원들에게 공유해야하는 그라운드룰을 운영했습니다. 이것을 우리가 원하는 상황으로 가고 있지 않을때 플랜B를 갈지 판단할 수 있는 판단의 근거로 작용하게 되었습니다. 관리만 할 줄 아는 사람들이 직접 참여하며 느끼는 것이 있었습니다.

발표전 김헌기님께서는 서지연님과의 발표를 듣고 본인이 속았다라고 볼멘소리로 주최측에 항의하셨으나 발표의 내용을 모두 들어봤을때, 사내외행사를 통한 경험을 토대로 이번 Meetup의 발표을 위해 큰 그림을 그려오셨다는 생각만이 머리속에 맴돌았습니다.

3부 : 대담식 질의 응답

슬랙을 통한 질의가 행사진행중 계속되었는데 많은 분들의 질문, 특히 본인의 업과 관련된… 업무에서 많은 고민을 해왔고 이 자리를 빌어 조언을 구하고 싶은 듯한 날카로운 질문들에 대해 김현기님과 서지연님이 혼을 다해 답변을 해주셨습니다. 슬랙을 통해 올라온 많은 질문들을 시간관계상 답변을 해드리지 못한 것은 발표자나 참가자들에게 모두 아쉬운 점이였다고 생각합니다.

마치며

최근 1년간 사내에서 일어나는 몇가지 이벤트들은 그간 제가 회사를 다니면서 경험해온 모습과는 많이 달랐습니다. 그 동안 매번 국내언론에서 IT Big3이니, 삼성의 차세대 동력이니 뭐니 하며 회사를 지켜세울때, 내부에서 지켜본 모습은 그것과는 많이 달랐기 때문입니다. (사실, 회사가 상장한뒤에 어느정도 껍질이 벗겨진 느낌은 없지 않아 있습니다만…) 하지만 최근 내부에서 일어나고 있는 회사의 변화는 이전에 진행되었던 변화의 움직임과는 달랐습니다. 임직원들이 자발적으로 문화를 바꾸려 노력을 하고 있고, 이는 변화에 관심이 없던 다른 직원에게 큰 영향을 끼치게 됩니다. 이런 변화를 즐기려는 선순환의 움직임이 사측에게도 전달이 되었는지 예전에라면 상상도 하지 못했던 나는 프로그래머다 컨퍼런스, 이번 Meetup 그리고 조만간 있을 Spring Camp등의 사외 이벤트 유치에 성공하게 되었습니다. 저희에게는 즐거운 변화입니다. 많은 분들이 고통받을 이 시점에 조금이나마 갈증을 해소해줄 청량음료가 되길 기원하며, 다음 2회 행사도 기대해봅니다.

Read More

[기행문] AWSomeDay 다녀왔습니다.


어제(2017.03.18)는 저번달에 회사 동료가 소개해 줘서 아무 생각없이 신청했던, AWSomeDay행사에 다녀왔습니다. AWSomeDay는 아마존 웹서비스의 다양한 기능과 기본적인 서비스의 사용법을 익히는 수업인 “AWS 기술 에센셜” 과정과 동일한 내용이라는 설명으로 시작했습니다. 물론 참가 인원이 많아서 실습은 진행하지 않고, 강사분과 질의응답을 할 기회가 거의 없기 때문에 위 정규과정과는 차이가 있다고 합니다.

Read More