안녕하세요. 저는 LINE Plus 서비스 엔지니어링 팀의 권용찬이라고 합니다. 올해로 LINE에 입사한 지 4년 차입니다. 모르는 것도 없지만 다 알지도 못하는 애매한 연차라고 할 수 있겠습니다. 글의 시작을 세기말 자기소개서처럼 시작하는 이유는 제가 IT 인력치고 노령(?)인 탓도 있겠지만 사람을 만나면 처음 하는 것이 인사일 것이고 인사를 할 때는 예의를 갖춰 간단한 자기소개로 시작하는 것이 일반적인 것 아닌가 생각하기 때문입니다. 회사에서 운영하는 기술 블로그라 개인 블로그처럼 블링 블링한 스티커를 쓰기는 어렵지만 그래도 나름대로 글을 쓰면서 상상으로나마 하트도 넣고 LINE 캐릭터 스티커도 넣어보고 있습니다.  (하 하얀 화면에 글만 쓰자니 왠지 바삭바삭하다)  누구나 인사를 한다 과거 얼굴 보고 하는 인사가 최고였고(덕분에 12월은 형님들 따라다니면서 인사하느라 한 달 내내 바빴습니다), 여의치 않으면 전화로 목소리라도 전달해야 인사로 인정받던 시절에는 삐삐 암호화 숫자나 부의 상징이었던 SMS 문자 인사는 예의상 전하는 지라시 취급을 받았죠. 당시 이미 메신저가 있었기에 젊은 사람들은 메신저로 축하 인사를 주고받곤 했습니다(삐삐 이야기는 건너 뛰겠습니다 도저히 라떼는 말입니다). 시간이 좀 흐른 뒤에는 휴대폰 MMS(Multimedia Messaging Service)를 이용한, 사진이나 이미지에 새해 복 많이 받으세요와 같은 문구를 추가한 메시지가 나름 핫했습니다. 꽃 사진에 좋은 말씀 붙여 넣은 메시지의 연말 버전 정도 되겠습니다. 새해 복 많이 받으세요 사람들이 잔뜩 모여 가뜩이나 모자란 통신망에 이미지 전송은 대역폭 부족을 가중시켰습니다. 사람이 많이 모이는 종로와 혜화동, 신촌, 홍대 등지에 모자란 통신 대역폭을 커버하기 위해 이동형 기지국이라고 부르는 안테나 달린 트럭들이 배치됐습니다. 왠지 트럭 곁에서 전화하면 더 전화가 잘 될 것 같은 느낌적인 느낌 때문에 기지국 차량 근처에는 사람들이 북적북적했습니다. 인터넷이 안 될 때 공유기 옆에서 노트북을 켜는 느낌이랄까요. 모든 공중전화기에는 엄마 나 오늘 늦어를 시전하기 위해 사람들이 모여 들었고, 나름 부자의 상징이었던 2G폰 사용자와 찬란하게 타올랐다 사라져 간 일명 시티폰 사용자들은 발을 동동 구르며 00시 00분에 누군가에게 메시지를 보내기 위해 노력했습니다. 당시 트래픽 문제는 인터넷 회선이 부족해서라기보다는 전신 교환기 병목과 무선 주파수의 대역폭이 부족해서 단말기 접속 자체가 불가능해지는 상황이었던 터라 지금과는 양상이 달랐는데요. 한 번에 쏟아지는 통화량에 매해 연말이면 통신사들이 비상이었다는 신문기사를 읽은 기억이 납니다. 30년 정도 지난 지금은 달라졌을까요? 개인적인 생각으로 주파수 대역폭이 부족하고 교환기가 밀리던 그때나, 인터넷 회선이 부족하고 서버 처리량이 부족해서 이에 대응하기 위해 IT 인력들이 고민하는 지금이나 넓게 보았을 때 큰 차이가 없어 보입니다. 차이라면 안테나를 등에 지고 산과 건물 꼭대기에 오르거나 이동형 기지국 차량을 끌고

1. 시작하며이슈(Issue)를 추적관리하는 업무는 QA 직군이 반드시 해야 하는 필수 업무 중 하나입니다. 탄생(생성)부터 죽음(완료)까지 이슈의 생애를 각종 정보들을 통해 지켜봄으로서 이들의 처리가 원활하도록 관리해야 합니다. 이슈는 또 일종의 일감으로, 전체 프로젝트 마일스톤(Milestone) 안에 있는 또 하나의 미시적 마일스톤으로도 볼 수 있습니다.활발하게 개발이 이루어지는 기간에는 이러한 일감들이 끊임없이 쏟아져 나옵니다. 그럼 수많은 일감을 어떻게 전달해야 효과적일까요? 귀로 듣는 것이 확실하니까 직접 말로 설명할까요? 아니면 담당자 모니터에 포스트잇으로 붙여둘까요? 그것도 아니면 메신저로 전달할까요?여러 가지가 있겠지만, 가장 보편적인 방법으로 대부분 'BTS(Bug Tracking System)'라는 도구를 사용하여 이슈와 일감들을 관리합니다. (요즘 방탄소년단 덕분에 BTS라는 단어가 국위선양의 콘텐츠로 자리매김했지만 어쨌든...) BTS를 사용하여 팀원들은 수많은 일감을 시각적으로 확인하고, 현재 상태를 직관적으로 알 수 있어서 업무 효율성이 비약적으로 상승합니다. 구두 또는 문서전달의 방식 보다 훨씬 더 효과적이죠.그러나 당장 'BTS를 사용하자!'라고 결정해도 한 가지가 논의가 더 필요합니다.그럼 어떤 BTS 서비스를 사용해야 할까?BTS로 사용할 수 있는 프로그램이나 서비스들은 매우 많지만, 아무렇게나 사용하면 원하는 만큼의 효율성을 이끌어내지 못할 확률이 큽니다. 이는 개발 프로세스, 팀 성향, 무료 / 유료 툴 여부, 원하는 기능을 제공하는지 등 세부적으로 커스터마이징이 필요한 부분들이 많기 때문이죠. 어떤 툴을 어떤 방식으로 사용하느냐는 역시나 사람에게 달려 있기 때문에, 우리는 좋은 툴을 효과적으로 사용하기 위한 방법을 마련해야 합니다. 그렇지 않다면 일감 관리 업무는 Bug Tracking System이 아닌 Burn The Stage(하얗게 불태웠어...)가 될 테니까요.2. JIRA 이전의 BTS이 포스트에서는 쿠키런 오븐브레이크 팀에서 JIRA를 도입하는 과정과, 이를 효과적으로 사용하기 위해 노력했던 것들에 대해 서술합니다. 그럼 우리가 왜 JIRA를 사용했는지를 알기 위해서는 그 이전에 사용했었던 BTS에 대해서 한번 되짚어보아야 할 것 같습니다.1) 구글 스프레드시트 (Feat. Excel)협업을 하는 회사라면 적어도 한 번씩 사용해보았을 구글 스프레드시트입니다. 구글 계정만 있다면 기본적으로 웹페이지에서 접근이 가능하기 때문에 따로 요금을 지불하거나 복잡하게 계정을 생성해야 하는 등의 프로세스는 필요하지 않습니다. 또한 Microsoft의 Excel과 유사하여 사용성 측면에서도 비교적 간단합니다. 구글 스프레드 시트는 쿠키런 for KAKAO 서비스 초반과 쿠키런 오븐브레이크 일부 이슈관리에 사용했습니다.구글 스프레드시트의 장단점은 다음과 같습니다.장점:접근성과 사용성이 좋습니다.다양한 양식으로 템플릿을 제작할 수 있습니다.메일이나 링크 전달만으로도 손쉽게 다른 사람에게 공유가 가능합니다.

언제나 그렇듯 글을 쓰는 건 가장 어려운 것 중에 하나다. 평소에 글을 쓸 기회가 있는 것도 아닌 데다, 재밌게 쓸 재주도 없기 때문이다. 게다가 원고 마감만 다가오면 개발자가 아닌데 기술 블로그에 무엇을 써야 하나 하는 정체성의 혼란도 겪는다. 그래도 마감은 지켜야 하는 법! 고민 끝에 PMBOK(Project Management Body of Knowledge, 프로젝트관리지식체계)를 기준으로 브랜디에서 프로젝트 매니징하는 방법을 이야기하고자 한다. 브랜디에서는 어떻게 할까? 브랜디에서 통합관리(Project Integration Management)는 트렐로(Trello)로 진행한다. 통합관리에 대한 자세한 설명은 이전 포스팅인 PM, 대충하면 큰일납니다(1)의 1번 항목을 참고하면 되므로 생략하겠다. 브랜디는 R&D본부를 제외하고 15개의 팀으로 구성되어 있다. 각 팀은 저마다의 KPI를 달성하기 위해, 개발을 요청하는데 생각해보라. 팀마다 하나씩만 요청해도 R&D본부는 15건의 개발 업무를 진행해야 한다. 아찔하다. 자칫 헷갈릴 수도 있다. 그렇기 때문에 각 팀의 요청은 무엇인지, 언제까지 진행해야 하는지 등 한눈에 보이도록 정리하는 건 당연한 일이다. 트렐로는 소리 없는 아우성으로 가득한 통합관리를 완벽히 정리해주는 도구다. 트렐로 화면 일부 우선 위의 이미지처럼 각 팀별로 중요한 개발 요건들을 카드로 만든다. 요청한 개발 내용과 건수를 한 번에 파악할 수 있다. 하지만 더 중요한 건 요청에 대한 우선순위를 지정하는 것이다. 빨리 요청한 업무가, 빨리 처리되는 건 아니다. 어느 회사나 개발 자원은 한정되어 있기 때문에 조직은 가장 효율적으로 운용할 수 있는 방법을 찾아야 한다. 그 방법 중에 하나가 우선순위를 지정하는 것이다. PM팀은 매주 월요일마다 팀별 개발 요건 카드들을 나열하고 우선순위를 정한다. 그리고 그 다음에 프로젝트 계획서를 만든다. [정리]효율적인 통합관리를 위하여 1) 요청한 개발 내용들을 카드로 만들자, 이쪽저쪽 옮기기 쉽게! 2) 가장 중요한 업무를 파악해 우선순위를 지정하자. 3) 프로젝트 계획서를 만들자. 정리, 정리, 또 정리 서두에서는 15건의 개발 요건만 예로 들었지만, 세상 일이 그리 호락호락하진 않다. 하루에도 수십 개의 요청카드가 쌓이는 걸 보면 이따금씩 타노스의 능력으로 삭제 버튼을 클릭하고 싶은 마음이 굴뚝같다. 그래도 어쩌랴. 이왕 하는 거 깔끔하게, 그리고 가능한 헷갈리지 않게 해야 한다. 여러 팀이 함께 쓰는 보드인 만큼 PM팀의 역할이 중요하다. 1. 프로세스를 잡자! 여러 팀과 미리 약속을 잡아두지 않으면 혼선이 생기기 마련이다. 개발 요건 카드는 이리저리 날아다닐지도 모른다. 트렐로를 세팅할 때, PM팀은 카드들이 날아다니지 않도록 List를 설정해야 한다. 브랜디에서 세팅했던 초기 List는 아래와 같다. 1) 팀별 요건 List 팀마다 List가 있다. 트렐로에 참여한 직원들은 각자가 속한 팀의 List 외에는 건들지 않아야 한다. R&D본부에서 요건을 처리할 때마다 카드

지난 1월 말, 새해를 맞아 잔디에 새로운 기능이 업데이트되었습니다. 바로 잔디 커넥트에 관한 내용인데요, 협업에서 많이 쓰이는 몇 가지 외부 서비스를 잔디와 쉽게 연동해서 더욱 효율적인 업무 커뮤니케이션을 할 수 있게 되었습니다. 많은 고객분들이 이번 업데이트를 기다려주신 만큼, 저희 개발팀 또한 기대에 보답하고자 지난 몇 주의 스프린트 동안 열심히 준비했습니다. 이번 글에서는 커넥트 동작 방식을 설명하고 그 개발 과정에서 저희가 겪은 시행착오를 비롯한 여러 값진 경험들을 공유하고자 합니다. Integration? Webhook! 연동: [기계] 기계나 장치 따위에서, 한 부분이 움직이면 다른 부분도 함께 잇따라 움직임. 앞서 말한 대로 잔디 커넥트는 여러 웹 서비스들과 잔디를 연동할 수 있는 기능입니다. 서로 다른 웹 서비스를 연동하기 위해선 한 서비스 내에서 특정 이벤트가 발생 했을 때 다른 서비스로 해당 이벤트를 알려주는 연결 고리가 필요합니다. 이때 해당 연결 고리 역할을 위해 대표적으로 사용되는 기법이 웹훅(WebHook) 입니다. 웹훅은 user-defined HTTP callbacks, reverse APIs 등으로 불리는데, 간단히 설명하자면 웹 서비스에서 공개한 API가 아닌 사용자가 직접 지정한 주소(URL)로 특정 이벤트가 발생 시 HTTP Request를 보내주는 기법입니다. 예를 들어, 새로운 일정이 등록된 경우(Google Calender) 요청한 Pull Request가 Merge된 경우(GitHub) 카드에 새로운 코멘트가 작성된 경우(Trello) 이러한 이벤트가 발생했을 때 사용자가 매번 이벤트가 발생했는지 확인하지 않아도 서비스가 먼저 알려줄 수 있도록 일종의 알림을 등록하는 것이죠. 잔디 커넥트는 이와 같은 특징을 이용해서 각각의 웹 서비스에서 제공하는 웹훅을 잔디의 메시지 형태로 전달하는 기능입니다. 일반적으로 웹훅은 이벤트에 대한 알림을 외부로 전달하는 것을 말합니다. 이 부분에서 중요한 것은 전달 방향인데, 서비스 내부에서 외부로 전달하기 때문에 이를 Outgoing Webhook으로 부르기도 합니다1. 같은 맥락에서 반대로 생각해보면 외부에서 서비스 내부로 특정 데이터를 전달하는 경우이니 Incoming Webhook이 됩니다. 앞서 웹훅을 reverse API라고 했는데 이를 다시 뒤집으니 결국 서비스 내부로 통신하는 제한적인 API와 같은 역할을 합니다. 굳이 용어를 구분한 이유는 API와 달리 접근하려는 서비스의 별도 인증 절차를 거치지 않고도 사용자가 생성한 웹훅의 URL을 인증 토큰으로 사용하며 약속된 Request Body 포맷만 알고 있다면 자유롭게 사용할 수 있기 때문입니다. 개념 설명이 다소 길어졌지만, 이번 잔디 커넥트 기능에 대해 용어나 개념이 낯설다는 피드백이 생각보다 많았기 때문에 이번 글을 통해 더 많은 분들이 웹훅을 이해하는 데 도움이 될 수 있으면 좋겠습니다. 구현에 앞서 서비스를 운영한지 1년 정도 지난 시점에서 저희 내부적으로는 백엔드의 기술 스택 변경 및 각