스토리 홈

인터뷰

피드

뉴스

조회수 2587

웹 플러그인 개발기 - iframe의 재발견

채널 웹 플러그인을 개발하며 겪은 문제들과 우리 팀의 해결책을 소개합니다. 채널 웹 플러그인은 SDK의 형태로 고객사 웹사이트에 붙어서 고객이 매니저와 대화할 수 있는 인터페이스를 제공합니다. 이 글을 쓰고 있는 당시 약 2300개의 채널이 개설되었고, 하루 약 180만 명의 일반 유저가 웹사이트에 붙은 저희 플러그인을 보고 있습니다.플러그인은 고객사 웹사이트 (이하 호스트 웹사이트라고 함) 의 HTML 도큐멘트에 붙어서 실행됩니다. 이 말은 실행 환경 (자바스크립트, CSS, DOM 환경 등) 을 우리가 컨트롤하지 못한다는 것을 의미합니다. 이것이 일반적인 웹서비스와 플러그인 개발의 가장 큰 차이점이고 사실상 많은 이슈들은 이 차이로부터 기인합니다. 또 이것에 대응하기 위해 프레임워크의 선택부터 개발, 배포에 이르기까지 훨씬 신경 써야할 부분이 많았습니다. 이 글에서는 그 중 호스트 웹사이트와의 실행 환경 공유에 따른 문제들을 자바스크립트와 CSS로 나누어 나열하고 iframe 을 이용하여 해결한 과정에 대해 설명하겠습니다.채널 홈페이지에 웹 플러그인이 붙은 모습1. 자바스크립트와 관련된 이슈1-1. 네임스페이스 공유에 따른 충돌 문제브라우저에서 자바스크립트는 글로벌 네임스페이스를 공유합니다. 이 속성 때문에 플러그인에서 window 를 접근해서 수정한다던가 글로벌로 객체를 정의해서 사용하면 호스트 웹사이트에 영향을 미칠 수 있습니다. 이 문제는 코딩할 때 아래 항목을 주의하는 정도로 큰 비용 없이 방지할 수 있습니다.플러그인의 최상위 네임스페이스를 만든다.(ex. window.CHPlugin)플러그인에서 사용하는 모든 객체는 최상위 네임스페이스 아래에 정의되도록 한다.(ex. window.CHPlugin.outObject)window 객체에 접근할 때는 수정하거나 추가하는 부분이 없도록 주의한다.(ex. [removed] = function(){}와 같은 코드는 사용하면 안 됨. 기존에 [removed] 이벤트가 날아감)사용하는 라이브러리들 중에 window에 바인딩하는 것이 없는지 체크하고 있으면 직접 수정하여 모듈화한다. (ex. lodash는 기본적으로 window 에 _ 객체를 생성함)이건 사실 플러그인이 아니더라도 주의해야하는 거죠..1-2. 에러로 인한 오동작 가능성더 어려운 문제는 바로 예측하기 어려운 오동작의 가능성이 있다는 것입니다. 호스트 웹사이트에서 동작하는 자바스크립트에서 에러가 날 경우 플러그인의 동작에도 영향을 미칠 수 있으며, 반대로 플러그인에서 에러가 발생해서 호스트 웹사이트의 코드 실행을 멈출 수 있다는 것입니다. 양방향으로 영향을 미칠 수 있는 것이죠. 특히 후자의 경우는 우리의 실수로 고객사의 서비스에 피해를 끼칠 수 있으니 쉽게 넘길 문제는 아닙니다.아이디어 1: try/catch를 적절히 처리한다?이를 해결하기 위해 가장 쉽게 생각할 수 있는 방법으로는 호스트 웹사이트 쪽에서 try/catch를 적절하게 처리하도록 가이드를 하는 방법입니다. 예를 들어 플러그인 코드의 바깥 쪽에 try/catch처리를 하고 호스트 웹사이트의 자바스크립트에도 적당하게 처리를 하면 되지만 이 방법은 현실적으로 어려움이 있습니다. 우리의 타겟 고객사들은 일반 쇼핑몰들이고 이들은 대부분 개발자가 없거나 쇼핑몰 빌더를 이용해 만들어진 사이트들이기 때문에 개발력이 없는 경우가 많습니다. 또 설사 개발력이 있다 하더라도 플러그인을 붙이기 위해 가이드할 것이 너무 늘어나는 문제가 있죠.아이디어 2: 자바스크립트 실행 순서를 강제한다?생각해볼 수 있는 또 다른 방법은 호스트 웹사이트의 코드와 플러그인 코드의 실행 순서를 명확히 정해서 한 방향의 영향이라도 차단하는 것입니다. 예를 들어 플러그인 코드가 호스트 웹사이트의 코드보다 항상 먼저 실행되도록 고객사에게 가이드한다면 우리의 코드는 항상 문제 없이 실행될 것이고 호스트 웹사이트에서 에러가 발생하더라도 영향을 받지 않을 것입니다. 하지만 이 방법 역시 마음에 들지 않았는데요 양방향의 영향을 모두 차단하지는 못하기 때문입니다. 그리고 더욱 큰 문제는 플러그인은 한 번 실행되고 끝나는 단순한 스크립트가 아니라 계속해서 실행이 되는 애플리케이션이기 때문에 사실상 소용이 없습니다.2. CSS와 관련된 이슈채널 웹 플러그인은 UI도 포함합니다. 플러그인의 DOM이 호스트 웹사이트에 붙어있기 때문에 플러그인의 스타일을 정의하는 CSS도 호스트 웹사이트에 Inject 되어야합니다. 호스트 웹사이트의 CSS와 플러그인의 CSS가 같은 스코프에 존재하기 때문에 우리가 의도한 스타일이 제대로 표현되지 않을 가능성이 있습니다. 실제로 이 문제는 런칭 초기에 우리를 가장 괴롭혔던 문제입니다. 쉽게 생각해볼 수 있는 방법은 아래와 같습니다.플러그인의 CSS에 네임스페이스를 둔다.(플러그인 CSS가 호스트 웹사이트 CSS에 주는 영향을 차단함)CSS 의 우선순위를 이해하고 플러그인 CSS의 우선순위가 항상 높도록 처리한다. (CSS Specificity 링크 참조)하지만 위처럼 처리하더라도 모든 경우에 대해 해결이 되는 것은 아닙니다. 주된 이유는 우리가 개발을 할 때 모든 CSS 속성을 정의하지 않기 때문입니다. 플러그인에서 정의하지 않은 속성을 호스트 웹사이트에서 사용한다면 호스트 웹사이트의 스타일이 적용될 것입니다. 또 특수한 경우이긴 하지만 만약 호스트 웹사이트에 !important 가 적용되어 있다면 그 속성이 덮어씌워지게 됩니다.!important는 사용하지 맙시다..ㅜ아이디어: 스타일 Normalizing?여기에서 의미하는 Normalizing은 모든 DOM 엘리먼트에 가능한 모든 CSS 속성의 기본값을 정의하는 것을 의미합니다. 크로미움을 기준으로 모든 CSS 속성 목록은 이 곳을 참조하시면 됩니다. 이것을 바탕으로 normalize.css를 만들어 적용했습니다.이 방법을 적용한 이후로는 스타일이 오버라이딩되는 문제는 어느 정도 해결되었습니다. 물론 !important에 대한 대응은 여전히 되지 않지만요. 그런데 예상하지 못한 부작용이 발생했는데 첫번째는 디버깅할 때 크롬 인스펙터가 도저히 사용하지 못할 정도로 느리다는 것입니다. 두번째는 CSS가 inheritance 가 안 되고 기본 엘리먼트 셀렉터의 우선순위가 높아서 직접 코딩해야하는 CSS가 2~3배는 길어지는 불편함입니다. 위 두 이유로 개발 피로도가 상당히 높아져서 머지 않아 다른 방법을 알아보게 되었습니다.3. iframe 도입위에 나열한 문제들을 해결할 수 있는 아이디어로 iframe을 리서치하게 되었습니다. 사실 iframe은 최근 웹서비스에서는 잘 사용하지 않기도 하고, 보통은 사용하지 않는 것을 권장하기도 하죠. 따라서 저희 팀에서도 처음에는 고려사항이 아니었는데요 우리와 유사하게 채팅 인터페이스를 제공하는 인터콤에서 iframe 을 적용한 것으로부터 아이디어를 얻어왔습니다.원래 목적에 맞게 사용하지 않으면 독이 됩니다.iframe은 HTML 도큐멘트 안에서 또 다른 도큐멘트를 임베드합니다. iframe 내에 있는 도큐멘트는 호스트 도큐멘트와 자바스크립트 스코프가 분리되어 있고, CSS가 적용되는 스코프 역시 분리되어 있습니다.이런 속성 때문에 위에 나열한 문제들을 원천 차단할 수 있습니다. 자바스크립트 스코프가 분리되어 있기 때문에 글로벌 네임스페이스에 접근해도 호스트 웹사이트에는 전혀 영향이 없고, 자바스크립트의 에러로 인해 다른 쪽 자바스크립트까지 실행을 멈추는 오동작을 막을 수 있습니다. CSS 역시 Normalizing 을 하지 않더라도 호스트 웹사이트와 플러그인은 완벽히 분리가 됩니다.4. iframe 의 단점iframe을 도입하여 1, 2번에 나열한 문제들은 해결했지만 그에 따른 작은 문제들도 발생했습니다. 첫번째는 iframe도입 시 가장 먼저 고민해야할 부분인데 바로 3rd-party cookie 문제입니다. iframe 안에서 로드되는 도큐멘트는 3rd-party 컨텐츠로 인식합니다. IE에서는 기본 설정이 3rd-party cookie 허용을 하지 않기 때문에 쿠키를 사용해서 인증을 구현한 경우 문제가 될 수 있습니다.두번째는 도큐멘트가 분리됨에 따라 발생하는 코딩상의 여러 불편함들입니다. 여기에서는 범위를 벗어나 더 자세하게는 설명하지 않겠지만 도큐멘트가 분리되니 조금 더 신경써야할 것들이 있었습니다.저희 팀의 경우 쿠키 인증 방식이 아닌 토큰 형태의 인증도 지원을 하고 있었기 때문에 첫번째는 크게 문제되지 않았고 두번째 문제도 얻는 이득에 비하면 불편함을 감수하는 편이 훨씬 좋다는 판단이 들어서 도입을 결정했습니다.마무리플러그인 개발을 시작할 당시에 우리 팀은 웹 SDK 형태의 프로젝트 개발 경험이 없었습니다. 리서치를 해도 플러그인 개발과 관련된 아티클이나 리소스 그리고 보일러플레이트 프로젝트도 많지 않았습니다. 프레임워크, 아키텍쳐를 선택하는 것부터 프로젝트를 구성하는 것부터 개발, 배포 및 운영에 이르기까지 일반적인 웹서비스를 개발할 때와 조금 다른 고민들을 해왔던 것 같습니다. 앞으로 저희가 해 온 고민을 공유하려고 합니다. 저희와 같은 플러그인, SDK 형태의 제품을 개발하고 계신 분들에게 도움이 되었으면 좋겠습니다.#조이코퍼레이션 #개발자 #개발팀 #인사이트 #경험공유 #일지
조회수 1574

"코인원 중심에서 '보안'을 외치다." - 보안전략기획팀 정지원

‘보안팀'을 생각했을 때 어떤 단어들이 떠오르시나요? 조금은 무시무시하지만 우람한 팔뚝, 강력한 눈빛, 태평양같은 어깨를 소유한 영화배우 ‘마요미' 마동석님이 떠오르네요. 코인원에서도 무시무시한 매의 눈으로 코인원 크루가 자리를 비울때 화면잠금이 되었는지 확인하는 ‘정요미'가 있습니다. 바로 코인원 보안을 책임지는 보안전략기획팀의 지원님이에요. 코인원 크루의 보안뿐만 아니라 고객들의 소중한 자산을 지키는 코인원의 수문장, 지원님을 만나볼까요?Q. 안녕하세요, 코인원의 ‘프로 화면잠금러'를 만나뵙게되어 정말 영광입니다.네, 저 또한 영광입니다. 제가 이전에 자리를 잠깐 비울때 화면잠금을 하지 않았는데요, 이렇게 영혼까지 털릴줄 몰랐습니다. ‘화면잠금도 모르면서 보안을 어떻게 논하느냐’ 라고들 하셔서 사죄의 의미로 커피를 쏘게 되었습니다. 이후 다시 이런 일이 없도록 스스로에게 다짐했을 뿐만 아니라 화면잠금 안하신 크루가 있는지 없는지 열심히 찾고 있습니다. (걸리기만 해 아주…-_-)Q. ‘프로 화면잠금러’로 오해하실 수도 있는 독자분들을 위해 ‘진짜’ 지원님 소개 부탁드릴게요:)안녕하세요, 코인원 보안본부 내 보안전략기획팀에서 근무하고 있는 정지원입니다. 코인원의 보안본부는 대내외 각종 보안 위협으로부터 선제적으로 대응할 수 있도록 Action Plan을 수립하고 실행하여 코인원의 모든 서비스와 자산을 보호하는 역할을 하고 있어요. 크게 보안전략기획팀, 개인정보보호팀, 보안운영팀으로 나뉘어 집니다.이 중에서 보안전략기획팀은 주로 대/내외 보안 트렌드를 파악하며 거래소 보안전략을 수립하고, 우선순위를 설정하고 조정하여 실행하고 있습니다. 더불어 코인원의 기존 서비스와 앞으로 출시될 신규 서비스의 보안 위험을 식별할 수 있도록 분석하고 대응방안을 마련하죠. 철저한 보안으로 코인원이 고객들에게 신뢰받을 수 있는 거래소가 되기 위해 최선을 다하고 있습니다.Q. 코인원을 이용하는 고객분들이라면 정말 궁금할 것 같아요. 코인원에 보관되어 있는 제 자산, 정말 안전하게 보관되어 있나요?“코인원 고객들의 자산은 100% 안전합니다" 라는 말 대신 “코인원 보안팀은 단 1%의 취약점도 허용하지 않기 위해 정말 최선을 다하고 있습니다" 라고 말씀드리고 싶어요.개인적으로 “고객의 자산은 100% 안전합니다.” 또는 “100% 완벽한 보안” 이라는 말은 성립할 수 없다고 생각해요. 취약점이 발생할 가능성은 언제나 있다고 생각하고, 그것이 1%의 가능성이라고 할지라도 해결방안을 고민해서 현실적인 대책을 세우고 실행해나가야 한다고 생각합니다.현재 코인원에서는 *DID(Defense In-Depth)의 개념으로 계층화된 보안 시스템(Multi-Layered Security)을 구축하고 발생할 수 있는 보안 위협에 대비합니다. 성을 공략하는 게임을 예를 들어 볼게요. A라는 성은 10m의 성벽 1개가 있고 B라는 성은 1m의 성벽 10개가 있다고 가정할께요. 성벽을 우회해서 성에 도착하기까지 어디가 시간이 더 걸릴까요?코인원은 마치 여러 개의 성벽처럼 계층화된 보안 방안을 구현, 거래소에 적용하고 있어요. 적용했다고 끝난게 아닙니다. 계속해서 모니터링 하면서 좋은 점과 나쁜 점을 모아놓고 좋은 점은 더 좋게, 나쁜 점은 개선할 수 있도록 재기획하고 실행합니다. 보다 더 안전하게 고객의 자산을 보호할 수 있는 방법을 고민하고 적용하고 있어요. *여기서 잠깐 DID(Defense In-Depth, 심층방어)란? 여러 계층의 보안 제어가 정보 기술(IT) 시스템 전반에 걸쳐 배치되는 정보 보증 개념입니다. 보안 제어가 실패하거나 시스템의 수명주기 동안 인력, 절차적, 기술적 및 물리적 보안 측면을 포괄 할 수있는 취약점이 악용되는 경우를 대비하여 다수의 방어 중복성을 제공하기 위한 것입니다.Q. 현재 코인원에서 진행하고 있는 보안정책은 어떤것들이 있을까요? 간단하게 소개해주세요.코인원 보안정책 중 몇가지를 소개해 드리자면, 코인원은 콜드월렛 보관 비중을 85%로 유지하여 고객자산을 보다 안전하게 보호하려고 노력하고 있습니다. 이는 사단법인 한국블록체인협회 권고 사항인 70% 보다 높은 비중이죠.또한 IT전문 보안 기업 SK infosec의 체계적인 보안관제 서비스를 제공받고 있습니다. 사이버 침해 위협을 실시간으로 감시하고 SK infosec이 보유한 방대한 위험 정보 데이터 베이스에 기반하여 고도화된 위협에 대응하고 있습니다. 마지막으로 이번에 새로 사이버 보안 기업 티오리(THEORI)의 전문적인 보안 컨설팅을 받게 되었습니다. 티오리는 미국 오스틴에 본사를 둔 기업으로 카네기멜론대학 해커팀(PPP) 핵심 멤버들이 설립한 사이버 보안 R&D 기업인데요, 데프콘(DEFCON) 같은 유명한 국제해킹방어대회에서 항상 상위권에 랭크되고는 합니다. 이렇게 검증된 역량을 바탕으로 Pen-Test(모의해킹)을 통해 코인원의 보안 아키텍쳐를 점검하고, 발생 가능한 모든 침해 시나리오를 상정하여 이에 대비하기 위한 자문을 진행할거에요.이외 다수의 테크니컬한 부분은 영업비밀(?) 입니다. (와하하하)Q. 콜드월렛을 잘 모르실 수도 있는 독자분들을 위해서 자세한 설명 부탁드려요. 또한 85%까지 비중을 유지하는것이 왜 중요한가요?먼저 콜드월렛에 대한 설명을 드릴게요. 콜드월렛은 핫월렛과 달리 네트워크가 연결되지 않은 물리적으로 분리된 저장 공간을 말합니다. 콜드월렛에 보관한다는 의미는 고객의 암호화폐 자산을 침해 또는 해킹 위협으로부터 원천적으로 차단된 별도의 장소에 보관한다는 뜻입니다. 그런일이 있어서는 안되겠지만, 사이버 침해가 발생한다고 가정할 경우 고객의 피해를 최소화할 수 있는 안전 장치에요. 블록체인 협회에서는 70%이상을 콜드월렛에 보관하는 것을 권고하고 있는데요. 저희는 협회에서 권고하기 이전부터 자체적으로 월렛 관리 정책을 만들고 그에 따라 콜드월렛을 운영해왔습니다. 참고로, 85%로 유지하는 이유는 거래소 비즈니스적으로 병목현상이 일어날 수 있는 부분을 방지하기 위한 적정 수준이라고 답할 수 있겠네요.보안팀은 무시무시하지 않아요, 부드럽습니다! (그윽한 눈빛을 발사하는 지원님)Q. 거래소 보안 전문가로서 막중한 책임감을 갖고 계실 것 같아요. 코인원 입사 후에 가장 기억에 남았던 혹은 어려움을 겪었던 에피소드가 있을까요?코인원의 보안 수준을 어떻게 하면 제1금융권 수준까지 끌어올릴 수 있을까에 대한 고민이 매우 컸습니다. 블록체인과 암호화폐 업계가 굉장히 폭발적으로 성장해왔는데요. 폭발적으로 성장하는 속도를 따라잡을 수 있도록 보안 및 인프라팀에서 무수한 노력을 해왔어요. 짧은 시간내에 보안 인프라를 효율적으로 구축할 수 있을지 치열하게 진행했던 회의들이 생각나네요. 코인원의 많은 크루들이 노력해주시고 도와주신 덕분인지 현재까지 코인원에서는 단 한건의 해킹사고도 발생하지 않았습니다. 최근에 생각나는건 금번 NH농협은행과의 재계약에서 보안 요구사항과 점검에 대한 실사가 많았는데 다행이 보안요건을 충족하며 재계약한 것이 생각나네요.Q. 지원님은 앞으로 보안본부에서 어떤 꿈을 이뤄나가고 싶으세요?글로벌 회사를 보면 유명한 보안팀들이 있어요. 예를 들어 구글에는 ‘프로젝트 제로(Project Zero)’라는 팀이 있는데, 이 팀은 ‘제로데이(0-day)’ 공격을 대비하기 위한 팀이에요. 제로데이 공격은 알려지지 않은 취약점을 발견해서 이에 대처하기 전 무방비 상태인 점을 악용하는 사이버 공격 방법이에요. 프로젝트 제로는 제로데이 공격 위협을 사전에 해소하기 위해 자사 제품 뿐만 아니라 타사 제품까지 연구하고 취약점이 발견된다면 해당 회사에 전달해서 대처할 수 있게 합니다. 또 다른 예로 야후에 “패러노이즈(Paranoids)”를 들 수 있겠네요. 야후의 모든 제품은 패러노이즈의 승인 없이는 론칭되지 않습니다. 전문성이 뛰어나지 않다면 가능하지 않은 케이스죠.저는 보안을 위해서라면 편집증적인 집착도 용서가 된다고 생각하는데요, 암호화폐 거래소 뿐만 아니라 블록체인 전반적인 영역에 대해 전문성을 발전시켜 궁극의 편집증 환자가 되는게...(?) 아 이게 아니고, 글로벌 유수의 보안팀들과 어깨와 나란히 하고 싶습니다.Q. 마지막으로 묻겠습니다. 지원님에게 ‘화면잠금' 이란?(인터뷰에서까지 영혼이 털리네요...) 회사 메신저에 제 프로필을 보시면 “화면잠금 털린 보안어린이”라고 되어 있습니다. 슬프네요 흑. 농담이구요, 어떤 일이던지 기본부터 충실해야 한다는 초심을 찾을 수 있었던 계기도 되었고 또 의도하지 않았지만 코인원 크루들이 보안은 어려운게 아니구나 라는 인식으로 바뀌게 된 계기가 된 것 같습니다. 수많은 보안 캠페인을 기획하고 시행했지만 지금처럼 크루들에게 여운이 남아있던 적이 없던 것 같아요. 앞으로 쉽지만 누구나 할 수 있는 보안 캠페인을 고민해 볼께요. (좋은 아이디어 주시면 제가 커피를 쏩니다!)충성! 단결! 필승! 오늘도 보안은 안전합니다 :-)언제나 보안을 최우선으로 고려하고, 원칙을 지키며 건전한 암호화폐 시장을 만들기 위해 지원님은 오늘도 24시간 365일 보안에 대한 고민을 풀가동하고 있습니다. 코인원을 이용하는 고객들의 안전한 거래를 위해 끊임없이 노력하는 보안전략기획팀에 많은 응원 부탁드립니다!#코인원 #블록체인 #기술기업 #암호화폐 #스타트업인사이트 #기업문화 #조직문화 #팀원소개 #인터뷰
조회수 2798

100일 간의 챗봇 디자인 실패기-2편

본문은 100일간의 챗봇 디자인 실패기 - 1편 에서 이어집니다.각고 끝에 탄생한 린더봇의 실적은 화려했다. Microsoft에서 주최하는 기술경진대회인 ImagineCup에서 수상을 하기도 하고, 4차 산업혁명이라는 정치적(?), 시대적 흐름에 맞추어 여러 정부지원사업에서도 긍정적인 반응을 이끌어냈다. 이제 막 대학을 졸업하는 대학생들이 몇 달간 잠도 못 자고 밥도 못 먹고 로봇 인척 하며 개발 및 사용자 연구를 진행해왔다는 스토리텔링은 우리가 봐도 가히 감동적이기까지 했다. 하지만 베타 테스트를 시작한 지 한 달 만에 린더봇은 종료되었고 우리는 서비스 개발을 중단했다. 대체 무슨 일이 일어난 걸까.결론이 정해진 사용성 조사'현실왜곡장'이라는 말이 있다. 스티브잡스가 자주 사용한 기법으로 유명한데, 아무리 비현실적이거나 거짓된 내용도 그 왜곡장 안에만 있으면 가능할 것으로 생각되는 것을 말한다. 경우에 따라서는 불가능해 보인 일을 기어코 성공시키는 멋진 리더십으로 그려질 때도 있지만 대다수의 경우에는 현실을 직시하지 못하고 그들만의 망상에 빠져버리는 위험한 상태를 뜻한다.앞서 1편에서 린더봇을 통한 한 달간의 일정 입력률이 전체 캘린더 데이터 입력률에 대비하여 51%까지 나왔다는, 매우 희망적인 수치를 제시했다. 하지만 한 가지 빠뜨리고 언급하지 않은 것이 있다. 그 린더봇을 통한 입력의 80%가 서비스 사용 첫 3일 간 발생했다는 것이다. 나머지 3주 간 린더봇을 통한 일정 입력 횟수는 현저히 줄어들었다.우리가 회피하고 있었던 현실새로운 전자기기를 살때면 대부분 한번쯤은 경험해보았으리라 생각한다. 우리는 새로 만나게 된 제품에 호기심을 가지고 이리저리 만져보지만 이는 어디까지나 새로운 경험에 대한 일시적인 현상일 뿐, 대부분의 서비스는 특정 기능에 국한된 제품으로 전락하고 만다. 이러한 냉혹한 수치를 분명 인지하고 있었음에도 제품에 대한 간절한 희망 때문에 우리에게 유리한 방향으로만 수치를 읽어내는 실수를 저질렀다.준비되지 않았던 플랫폼우리는 린더봇을 제공하는 플랫폼으로 카카오톡 자동응답 API를 택했다. 비록 라인, 페이스북 메신저 등 타 메신저 플랫폼들이 챗봇을 위한 다양한 기능들을 선제적으로 제공하고 있었음에도 불구하고 카카오톡이 국내 메신저 점유율의 95%를 차지하는 시점에서 다른 메신저를 고려할 수가 없었다.카카오톡 자동응답 API결국 카톡을 선택하기는 했지만 카톡이 챗봇 써드파티 업체들을 위해 준비해놓았던 기능들을 매우 제한적이었다. 여러 아쉬운 점이 많았지만 그중에서도 ‘선톡’을 날릴 수 없다는 점과 ‘PC카톡’에서 대화를 할 수 없다는 점은 서비스 운영에 있어 매우 치명적인 문제들이었다.카카오에게 있어 '단체 선톡'은 매우 중요한 수익모델이다. 물론 지금도 수 만개의 기업고객에게 돈을 받고 ‘선톡을 날릴 수 있는 권리’를 팔고 있는 카카오 입장에서 굳이 소수의 개발사들을 위해 해당 기능을 무료로 제공할 이유는 없다고 생각한다. 또한 사용자들에게 무분별한 선톡이 발생할 경우 사용성이 저하될 여지도 충분히 있다. 하지만 다수의 해외 챗봇이 '무료 선톡'을 기반으로 한 섭스크립션, 큐레이션 서비스를 확장해나가고 있다는 점을 고려했을 때 매우 아쉬운 것은 사실이었다(특히 위챗은 매주, 또는 매일 특정 정보를 제공하는 섭스크립션/큐레이션 유형의 챗봇을 이미 하나의 카테고리로 규정하고 있다).'자동응답 API에서 선톡을 막는 것'이 사용자 편의성과 수익성을 고려한 어쩔 수 없는 선택이었다면, PC 카톡에서 자동응답 API를 통해 대화를 할 수 없었다는 점은 명백히 카톡 플랫폼 내 기술적 완성도의 부족이었다. 비록 카톡 트래픽의 대다수가 모바일에서 이루어진다고 할지언정 단순히 기술적인 이슈로 데스크탑 환경에서 자동응답 옐로아이디(현 플러스친구 통합)를 사용할 수 없었던 점은 카카오의 챗봇 환경에 대한 대응이 매우 늦었다고 밖에 볼 수 없었다.(지금도 PC에서는 자동응답 플러스친구 활용이 안되는듯하다)비록 국내 메신저 업체가 우리와 같은 작은 써드파티를 위해 조금 더 진보되고 오픈된 API를 제공해주지 않았다는 점은 아쉽지만 이 또한 업체 간의 이해관계와 시장의 속도를 현실적으로 고려하지 못한 우리의 잘못이었다.접근성, 인터페이스, 그리고 습관우리는 막연했다. 앞서 1편의 서두에서 언급했던 바와 같이 많은 사용자가 접근성 하나 때문에 메모장 대신 카톡을 선택한 것처럼, 린더봇 또한 접근성 하나로 많은 이들의 사랑을 받을 수 있을 것으로 기대했다. 우리의 챗봇을 통해 사람들이 놓치고 지나치던 많은 일정들을 캘린더로 입력시킬 수 있을 것이라 생각했다.우리가 그렸던 막연한 이상향새로운 기술을 좋아하는 IT업계 사람들이 더러 그러하듯 우리 팀 또한 ‘대화형 인터페이스(CI)’라고 하는 새로운 형태의 사용자 경험에 열광했다. 2016년 한 해 미국을 강타했던 다수의 챗봇 비즈니스를 검토하며 CI가 제시하는 미래에 매료되었다. 하지만, 우리의 기대와는 달리 베타 출시된 린더 봇의 실질적인 일정 입력률은 기존 캘린더 앱의 그것과 크게 다르지 않았다. 린더봇을 준비하며 설문을 실시한 결과 캘린더 앱을 활발히 사용하는 유저 중 주간 캘린더 입력률이 5회가 넘는 사용자가 20%가 채 되지 않았다. 우리는 린더봇을 통해 이 수치를 크게 바꿀 수 있을 것이라 생각했지만 그것은 단순히 새로운 인터페이스를 제공한다고 해서 해결될 수 있는 문제가 아니었다. 사용자들에게 필요했던 것은 ‘보다 편리한 캘린더’가 아니라 아예 ‘새로운 형태의 일정 도우미’였다. 그렇게, 지금의 일정 구독 서비스 - 린더가 탄생했다.자동응답 API를 통해 챗봇을 제공하기 전, 한 달 동안 수동으로 모든 일정 요청을 응답할 당시 한 사용자로부터 독특한 요청을 하나 받았다. 바로 재학 중인 대학원의 1년 일정을 자신의 캘린더로 넣어달라는 것이었다. 솔직히 요청을 받은 당시에는 이걸 정말 해줘야 하나 고민이 많았다. 단 한 사람을 위해 20개가 넘는 연간 대학원 일정을 캘린더로 담아줘야 한다니. 하지만 실험 당시 우리는 사용자들에게 분명 일정에 관련한 모든 입력을 도와주겠다고 약속했기에 대학원 웹사이트를 찾아 일일이 일정을 옮겨 담아주었다.실험이 끝난 후 해당 사용자는 설문에서 린더를 사용하며 가장 편리했던 기능으로 ‘연간 일정 한 번에 추가 기능’을 꼽았다. 30명의 사용자 중 단 한 명이 요청하고, 좋아했던 이 기능으로부터 지금의 ‘일정 구독 서비스 - 린더 ( https://linder.kr/ )’가 탄생했다. 챗봇의 성공 가능성이 희미해지고 있던 시점에서도 우리 팀은 ‘일정’이라는 요소를 손에서 놓지 않았다. ‘일정 데이터’가 앞으로 지니게 될 가치에 대해 고민한 결과 누군가는 80%의 비어있는 캘린더에 일정을 채워줄 수 있는 서비스를 만들어 낼 것이라는 결론을 도출하게 되었고, 그 ‘누군가’가 우리가 되지 못할 이유는 없다는 생각으로 린더를 만들기 시작했다.제품 개발 연혁- 17.01 ~ 17.02 휴먼(?) 린더봇 실험- 17.02 ~ 17.03 린더봇 베타 출시- 17.04 린더봇 중단- 17.03 ~ 17.05 일정 구독 서비스 - 린더 기획, 개발- 17.06 일정 구독 서비스 - 린더 출시2017년 11월 현재- 엔드유저(구독자): 10만 명- 파트너(기업): 삼성, SK, 현대 등 8개 사 스포츠, 교육 일정 등 협약- 누적 캘린더 181개 / 누적 등록 일정 12,000개- 평균 CTR(클릭률): 4~5%, 최대 7~8% ( 캘린더 내 일정 링크 클릭 수 / 구독자 )- 이탈률: 1% 내외 ( 구독 취소자 / 구독자 )- 제공 일정: 아이돌 스케줄, 화장품 세일, 대학교 학사일정, 스포츠 경기, 공연/축제 일정, 공채 일정 제공언론'국내 최초' 삼성, 캘린더 구독 서비스 실시…린더와 제휴 – 마이데일리(17.10.13)손 안에서 확인하는 경기일정, 현대캐피탈 배구단 캘린더 구독 서비스 실시 – 스포츠서울(17.10.18)스마트폰 달력 여니… 아이돌 스케줄이 주르륵 – 동아일보(17.11.01)#히든트랙 #챗봇 #기술기업 #개발자 #개발팀 #인사이트 #경험공유
조회수 1581

날짜 변환, 과연 그리 간단할까?

안드로이드에서는 입력한 날짜를 변환 및 검증하는 로직을 간단하게 구현하기 위해 SimpleDateFormat 클래스를 종종 활용하게 되는데 이 클래스는 규칙에 관대하다(lenient)는 재미난 특성이 있습니다. java.text.SimpleDateFormat 클래스의 근간이 되는 java.text.DateFormat 클래스의 다음 API 문서를 살펴봅시다.By default, parsing is lenient: If the input is not in the form used by this object’s format method but can still be parsed as a date, then the parse succeeds. Clients may insist on strict adherence to the format by calling setLenient(false).파싱 기본 동작은 관대합니다. 이 객체의 날짜 포맷과 일치하지 않는 입력이 주어지더라도 날짜 형태만 유지한다면 파싱이 성공합니다. 클라이언트 코드에서는 setLenient(false) 메소드를 호출해 파싱 규칙을 여전히 엄격하게 가져갈 수 있습니다.lenient 라는 흔하지 않은 단어 때문에 의미가 잘 와닿지 않습니다만, 캠브릿지 영영사전에 따르면 ‘관대하다’ 라는 뜻이 있다고 하네요.lenient /ˈliː.ni.ənt/ ▶ adjective ▶ Level C2(Mastery Proficiency)A lenient punishment is not severe.Thesaurus: allowing, forgiving, merciful, permissive, tolerant하지만 규칙에 관대하다는 말이 무슨 의미인지 여전히 와 닿지 않습니다. 잠시, 아래의 소스코드를 읽고 그 결과를 한번 예측해 볼까요? parse 메소드는 기본적으로 lenient 하다는 특성에 주의합시다./* * 2017년 13월 32일 이라는 입력에 대해 어떤 결과가 나타날까? * 1. 2017-13-32 * 2. 2018-02-04 * 3. 2017-01-01 * 4. 2018-01-01 * 5. ParseException 이 발생 */ val userDate = "2017-13-32" val date = SimpleDateFormat("yyyy-MM-dd").parse(userDate) val localDate = LocalDateTime.ofInstant(date.toInstant(), ZoneOffset.UTC) println ("사용자의 ISO-8601 Date 입력 결과는 ${localDate.year}년-${localDate.month}월-${localDate.dayOfMonth}일 입니다.") lenient 라는 사전 hint 없이 바로 문제를 낼 경우 사람들이 제일 많이 선택한 결과는 ParseException 이 발생한다 였습니다. 하지만 lenient 한 특성으로 인해 실행 결과는 의외로 두번째, 즉 2018년 2월 4일 입니다. 막상 글로 풀어 쓰려니 별 것 아닌 내용처럼 보입니다만, 필자가 담당하는 서비스에서 이 특성을 제대로 파악하지 못해 특정 사용자의 생년월일을 제대로 인식하지 못한 문제가 있었습니다.또한 우리가 흔히 아는 달력을 쓰지 않는 국가도 있다는 점 까지 고려한다면 날짜 변환이라는 것이 간단한 문제가 아니게 됩니다. 즉, 한국인의 관념 속의 ‘달력’ 이란 Gregorian calendar 를 기반으로 한 ISO-8601 달력 입니다. 그런데 이 달력을 쓰지 않는 문화권도 있습니다(한국도 흔하진 않지만 ‘단기’ 라는 별도의 달력을 쓰기도 합니다). 이런 문제 때문에, 글로벌 서비스를 준비하고 계신다면 날짜 변환 문제를 꼭 점검해 보셔야 합니다.Android 에는 이 문제를 해결해 주는 클래스가 있습니다만 불행히도 API Level 이 26이나 되어 2018년 현재에는 제대로 쓰긴 어렵습니다. 다행히도 이 문제를 보완한 joda-time 라이브러리의 안드로이드 포팅 버전도 있으니 이 라이브러리의 도입을 검토해 보는 것도 좋은 문제 해결 방법이 될 것입니다.#개발 #인사이트 #하이퍼커넥트 #개발자 #안드로이드 #개발후기
조회수 1283

개발팀의 유행어 제조기, Mark를 만나다

 * 2015년에 작성된 글입니다편집자 주: 잔디에는 현재 40명 가까운 구성원들이 일본, 대만, 한국 오피스에서 일하고 있습니다. 국적, 학력, 경험이 모두 다른 멤버들. 이들이 어떤 스토리를 갖고 잔디에 합류했는지, 잔디에서 무슨 일을 하고 있는지 궁금해하시는 분들이 많았습니다.  이에 잔디 블로그에서는 매 주 1회 ‘맛있는 인터뷰’라는 인터뷰 시리즈로 기업용 사내 메신저 ‘잔디’를 만드는 사람들의 이야기를 다루고자 합니다. 인터뷰는 매 주 선정된 인터뷰어와 인터뷰이가 1시간 동안 점심을 함께 하며 다양한 이야기를 나누며 진행됩니다. 인터뷰이에 대해 궁금한 점은 댓글 혹은 이메일([email protected])을 통해 문의 부탁드립니다.인터뷰 시작에 앞서 편집자 스스로 잔디의 개발팀에 궁금한 점이 있었다. 매 주 수요일 아침 8시, 오피스 근처 카페에서 스터디를 하는 그들의 문화가 바로 그 것이다. 회사의 강요가 아닌 공부를 하겠다는 자발적인 이유로 모인다는 그들. 그들 중 한 명인 Mark를 이번 주 맛있는 인터뷰에 어렵게 모시게 되었다.세렝게티의 한 마리 표범과 같은 그의 눈빛이 향한 곳은 가.츠.나.베반갑습니다. 우리 좀 걷지 않았나요? 회사에서 꽤나 멀리 떨어진 ‘오무라안’을 온 특별한 이유가 있다면?회사 바로 앞에 있는 ‘탄’보다는 조금 고급스러운 일식 레스토랑이에요. 우연히 알게 된 곳인데 맛이 딱 제 취향이라 즐겨 찾습니다. 항상 가츠나베를 먹는데요. 그 맛은.. 말로 형용하기 어렵네요.가츠나베성애자이시군요. 얼마나 있는지 모르겠으나 ‘맛있는 인터뷰’ 독자들을 위해 인사 부탁드립니다.안녕하세요, 부산 남자 Mark입니다. 잔디에 합류한 지 약 두 달 정도 되었어요. 잔디에서는 Front-end 개발 업무를 맡고 있습니다.주로 어떤 일을 하시나요?쉽게 말하자면 사용자들이 접하는 부분을 책임지는 역할이에요. 지금은 Jihoon, Young과 함께 일하고 있는데 궁합이 잘 맞는 것 같아요. 사람이 적으면 할 수 있는 일이 한정되어 있고 반면 사람이 많으면 커뮤니케이션이 힘든데 저희 세 명은 예외인 것 같습니다.왔노라, 보았노라, 달렸노라Mark님만의 유행어가 있더라고요?‘가자!’ 를 말씀하시는 것 같은데요. 맞나요? (웃음) 비글로벌 서울 2015 우승 후, 뒷풀이 회식에서 흥에 겨워 술과 함께 외친 ‘가자!’가 다른 분들에게 인상적으로 각인되었던 것 같아요.네, 저도 그 자리에 있었는데요. 굉장히 인상적이었어요. 술이 센 편이신 것 같은데요?아니에요. 사실 술을 잘 하는 편도, 자주 마시는 편도 아니에요. 주량이라면 소주 두 병 정도? 그 날은 저희 회사가 좋은 일도 있고 해서 평소보다 많이 마시긴 했지만 기분이 좋았던 게 그런 사태를 만든 주된 이유인 듯 합니다.잔디 비글로벌 서울 2015 우승!잔디의 개발자 채용 과정이 다른 곳에 비해 까다롭다고 들었어요. 직접 경험하신 분으로서 어땠는지 여쭤볼 수 있을까요?정말 까다로워요. 다른 곳도 코딩시험을 보기는 하는데 잔디는 인사부에서 1차 코딩 시험을 보고 2차 면접에서는 왜 그렇게 코딩을 했는지 설명을 해야 합니다. 그리고 나서 인성 면접을 봤습니다. (잔디에서는 이 면접을 Behavior Interview 라고 부르며, 여러 부서의 인원들이 참여해 해당 인터뷰이가 함께 일할 사람으로서 적합한지 판단하게 된다 – 편집자 주)마치 수험생 같다는 느낌이 들었어요. 면접 과정 중에는 ‘뭐 이리 깐깐하게 굴어?’ 라는 생각을 했었는데, 지금 돌이켜 보면 이런 과정을 거쳐 합류한 인재들이 모여 있어 잔디가 빠르게 성장할 수 있지 않을까 추측해 봅니다.잔디에서의 생활은 어떤가요?신기한 점이 참 많은 것 같아요. 좋은 점은 출중한 능력을 가진 분들이 많다는 점이에요. 그분들을 통해 배울 점도 많고, 개인적으로는 분발해야겠다는 생각을 하게 해요. 많은 자극을 받고 있어요.신기한 점이라면 어떤 부분일까요?예를 들면 아침에 출근하면 Dan(CEO)이 제게 다가와 영어로 말을 건네는 것이 가장 신기한 것 같아요. 당황스러우면서도 한편으로는 신기해요.이건 개인적으로 궁금한 건데요. 개발팀의 아침 스터디에 대해 어떻게 생각하시나요?사실 아직 참여해 보진 못했어요. 잔디 개발팀에서는 매주 아침 8시까지 나와서 자발적으로 스터디를 하고 있는데요. 강요가 아닌 자발적으로 업무 외에 스터디를 한다는 점이 참 인상 깊어요.그렇군요. 질문을 좀 바꿔볼게요. 쉬는 날엔 뭐 하시나요? 부산 사람이니 야구?보통 쉬는 날엔 서울에 있는 친구들을 만나거나 게임을 해요. 야구는 부산 사람이다 보니.. 삶의 일부 같은 느낌이죠. 우리가 공기를 좋아하거나 싫어할 수 없듯, 야구 역시 좋아하거나 싫어할 수 있는 대상이 아니에요.보통 ‘부산 사람=야구’라고 생각하는데 Mark도 여기에 해당하는 분이었군요. 게임은 어떤 걸 즐겨 하시나요?WOW(Wolrd of Warcraft)라고 아세요? 저는 게임에 있어서 저만의 철학이 있어요. 게임에도 레벨이 존재한다고 생각하는데요. 모바일 게임을 아주 안 하는 것은 아니지만 모바일 게임에 투자하는 시간은 아깝다고 느껴져요. 물론 개인적인 생각입니다.록타르.. 피바람을 몰고올 Mark여..그러면 Mark가 생각하기에 게임으로서 ‘와우’는 어느 정도 레벨인가요?제가 알고 있는 게임들 중 와우는 Top3에 듭니다. 물론 생각을 깊게 해 본 적은 없어서 나머지 2개에 뭘 넣어야 할지 고민해야겠지만 와우는 정말 잘 만든 수작이에요.이제 곧 휴가철이잖아요. 부산 여행 추천 장소 좀 해주세요.외지 사람들은 보통 해운대 많이 가는데, 사실 부산 사람들은 해운대를 잘 안가요. 사람이 너무 많잖아요? 부산 여행 장소를 찾으신다면 개인적으로 을숙도를 추천하고 싶어요. 여긴 가족 단위 여행객이 많은 곳인데요. 서울 사람들이 한강을 찾듯 부산 사람들은 을숙도를 찾아요.이번 여름 휴가는 을숙도로!을숙도? 섬인가요?네, 섬이긴 한데 엄청 큰 다리로 육지와 연결되어 있어서 차를 타고 들어갈 수 있는 곳이에요. 공원이 잘 조성되어 있어요. 자전거도 빌려 탈 수 있고 까페도 있어서 여행 장소로는 딱이에요.축구장도 엄청 많아서 축구 동호회 분들이 자주 찾으시는데요. 사람으로 북적거리지 않는 부산 여행지를 찾는다면 이번 여름 여행은 을숙도로 가보세요. 참고로 을숙도에는 음식점이 많지 않아요. 저 같은 경우, 을숙도 갈 때마다 도시락을 챙겨가곤 합니다.다음은 맛있는 인터뷰의 고정 코너 ‘어서 말을 해’입니다. Jinho가 남긴 질문 ‘잔디를 한문장으로 표현한다면?’에 대해 답을 주신다면?잔디란 ‘기회’ 입니다. IT 업에서 제가 어디까지 능력을 발휘할 수 있을지 확인해볼 수 있는 좋은 기회이기 때문이죠. 좀 진부한가요?전~혀 진부하지 않아요. 멋진 답변을 주셨으니 다음 인터뷰이를 위해 질문 하나 남겨주시겠어요?저는 이걸 꼭 물어보고 싶어요. ‘최근 3년 동안 당신에게 가장 행복했던 일은?’Mark와 개인적으로 얘기를 나눠보고 싶었는데 이렇게 소원이 이뤄졌네요. 개인적으로 뿌듯한 인터뷰였습니다.감사해요. 잘 좀 편집해 주세요.#토스랩 #잔디 #JANDI #개발팀 #개발자 #개발 #팀원소개 #팀원인터뷰 #팀원자랑 #기업문화 #사내문화 #조직문화
조회수 2308

[인공지능 in IT] 네가 내 마음을 알아?

지난 2018년 3월, 고용노동부는 10월부터 발효되는 '감정노동자 보호법 개정안'을 통과시켰다. 해당 개정안은 고객의 폭언이나 폭력으로부터 스트레스를 받는 감정노동자의 인권과 업무의 질을 개선시킬 사업주 조치를 의무화하는 내용을 담고 있다. 감정노동이란, 고객을 응대하며 자신의 본래 감정과는 상관없이, 업무상 정해진 감정 표현을 연기하는 것을 일상적으로 수행하는 노동을 말한다. 예로 콜센터, 백화점 안내, 텔레마케터 등이 있다.< 감정노동자 보호를 위한 5개 금융업법 개정안 주요 내용, 출처: 동아닷컴 >이제 정부는 감정노동자의 '적응 장애'와 '우울증' 등을 업무상 질병으로 인정한다. 세계보건기구(WHO)에서 정의한 건강은 '육체적, 정신적, 사회적, 영적으로 안녕한 상태'다. 즉, 감정노동자들은 육체뿐만 아니라 정신적, 사회적으로 고통받을 수 있다는 것이다. 그들은 자동으로 저장된 말을 내뱉는 음성 안내기가 아니고, 일반 사람들처럼 똑같이 울고 웃는 사람이다. 그렇지만, 아직까지 국내에서 심리상담에 대한 정서적인 장벽은 높고, 상담 받을 수 있는 인프라도 잘 갖춰지지 않다. 감정노동자들이 실질적인 상담 도움을 받기는 어렵다는 의미다.감정노동 소식 뒤, 국내 인공지능 기술 업체 중 한 곳이 심리상담 서비스를 출시했다는 기사를 접했다. 전문 심리 상담사들이 축적한 수많은 상담 시나리오 데이터를 수집하고 구축해, 개별적이고 정확한 서비스를 제공한다는 것이 취지다. 또한, 통화 목소리를 기반으로 이를 감정 데이터로 변환시켜 정신 건강에 대한 정보와 스트레스 관리 등을 위한 맞춤형 콘텐츠를 제공하는 것이 목적이다. 정확도는 알 수 없지만, 인공지능이 인간의 감정을 인지하고 생활에 도움을 줄 수 있다는 사실만으로도 큰 의미가 있다고 생각한다.사실 필자는 몇 년 전까지 매 순간 변하는 복잡한 인간의 감정은, 인간 고유의 것이라고 생각했다. 인간은 자신의 감정을 알지 못할 때도 있고, 긍정적인 감정과 부정적인 감정을 주체하지 못하기도 한다. 아직 우리 스스로 감정에 대해 확실하게 정의할 수 없고, 통제할 수 없다. 하지만, 그럼에도 불구하고, (앞서 언급한) 심리상담 서비스처럼 여러 분야에서 기계가 인간의 감정을 이해하고, 심지어 감정 표현을 돕는 연구는 거듭되고 있다.기계와 감정의 접목은 2000년대 이전부터 시작되었다. 1995년 MIT의 피카드(Rosalind Picard) 박사가 처음으로 감성컴퓨팅이라는 용어를 사용하며, 인간의 감성을 분석하고 해석하는 기술 개발을 시작했다. 감성 컴퓨팅은 인간이 느끼는 바를 인지, 해석, 처리할 수 있는 시스템을 설계하기 위한 인공지능 기술을 연구하고 개발하는 분야다. 감정 인식은 상상 이상으로 복잡하고, 아직까지 정확하게 구현하기 힘든 어려운 기술이지만, 조금씩 그 영역을 확장하며 다양한 분야에서 사용되고 있다.아무래도 사람의 감정을 드러내는 표면적인 수단 중 가장 눈에 띄는 것이 표정일 것이다. 얼굴에 드러나는 인간의 감정은 안면 근육의 움직임을 통해 여러 표정으로 나타나기 때문이다. 여기에 영상 처리 기술을 활용하면, 기계가 인간의 감정을 분류할 수 있다. 이를 기반으로 한 감정인식은 다음의 과정으로 이루어진다.먼저 영상이나 이미지 안에서 얼굴 영역을 찾는다. 일반적으로 스마트폰 카메라 앱에서 많이 볼 수 있듯, 네모 박스 형태로 얼굴을 인식한다. 그리고 해당 박스 안에서 눈, 코, 입 등 랜드마크라고 불리는 특징점들을 찾는다. 이어서 각 특징점을 바탕으로 각각의 위치나 배치를 파악하는 프로세스를 거친다. 마지막으로 학습을 거쳐 사람의 표정을 인식할 수 있다.일반적으로 감정 쪽을 연구하고 기술을 개발하는 업체 대다수는 이러한 딥러닝 방식을 적용한다. 그리고 미리 지정한 각각의 감정 메트릭에 사용자의 표정을 맵핑하는 식으로 결과값을 도출한다. 하나 주의해야 할 점은 표정과 비교하는 감정이라는 결과값을 '확률(%)'로 산출한다. 예를 들어, 눈썹을 찌푸리고 눈이 커지면서 입을 벌리고 있으면, 감정은 '화남 95%, 놀람 20%, 슬픔 5%...' 등으로 표현하는 방식이다.< EMOTION>이외에도 톤, 크기, 템포 등 감정 변화에 따라 변하는 목소리를 분석하는 음성 인식 기술이나 몸의 특정 움직임을 분석해 감정 상태를 인지하는 동작 인식 기술 등이 있다. 특히, 음성 인식은 CS(고객 응대) 영역에서 빛을 발할 수 있다. 실시간으로 고객의 감정을 분석해 소통방식을 바꾸거나, 그들의 구매 패턴을 예측하는 데 도움을 준다.최근에는 페퍼를 비롯한 가정용 휴머노이드 로봇이 여럿 출시되면서, 감정인식 기술의 적용사례를 쉽게 찾아볼 수 있다. 이들 로봇들은 인간과 대화할 때 억양이나 표정을 인식하며, 심지어 때로는 인간의 감정을 예측하고 묻기도 한다. 물론, 아직까지 우리의 머리 속에는 기계라는 생각 때문에 상호간 자연스러운 대화나 감정을 전달하기 어렵다. 하지만 문자, 음성, 시각 등 현재도 여러 영역에서 인공지능 기술은 발전을 거듭하고 있다.< 핸슨로보틱스(hansonrobotics)의 휴머노이드 로봇 소피아(Sopjia), 출처: 핸슨로보틱스 >인간의 감정이라는 것은 하나의 영적인 매개체가 아닌, 복합적인 것이다. 결국 각 영역별 인공지능 기술이 고도화될수록 감정 인식에 적용할 수 있는 기술 또한 정교해진다는 것을 의미한다. 언젠가는 기계가 인간의 말상대가 되어주고, 함께 어려운 문제에 대해 의논할 수 있는 단계까지 이르지 않을까? 감정 노동자의 마음을 어르고 달래는 로봇이 등장할지도 모를 일이다.이호진, 스켈터랩스 마케팅 매니저조원규 전 구글코리아 R&D총괄 사장을 주축으로 구글, 삼성, 카이스트 AI 랩 출신들로 구성된 인공지능 기술 기업 스켈터랩스에서 마케팅을 담당하고 있다#스켈터랩스 #기업문화 #인사이트 #경험공유 #조직문화 #인공지능기업 #기술기업
조회수 1679

비트윈의 스티커 시스템 구현 이야기 - VCNC Engineering Blog

 비트윈에는 커플들이 서로에게 감정을 더욱 잘 표현할 수 있도록 스티커를 전송할 수 있는 기능이 있습니다. 이를 위해 스티커 스토어에서 다양한 종류의 스티커를 제공하고 있으며 사용자들은 구매한 스티커를 메시지의 첨부파일 형태로 전송을 할 수 있습니다. 저희가 스티커 시스템을 구현하면서 맞딱드린 문제와 이를 해결한 방법, 그리고 프로젝트를 진행하면서 배운 것들에 대해 소개해 보고자 합니다.스티커 시스템 아키텍처비트윈에서 스티커 기능을 제공하기 위해 다양한 구성 요소들이 있습니다. 전체적인 구성은 다음과 같습니다.비트윈 서버: 이전에 소개드렸었던 비트윈의 서버입니다. 비트윈의 채팅, 사진, 기념일 공유 등 제품내의 핵심이 되는 기능을 위해 운영됩니다. 스티커 스토어에서 구매한 스티커는 비트윈 서버를 통해 상대방에게 전송할 수 있습니다.스티커 스토어 서버: 스티커를 구매할 수 있는 스토어를 서비스합니다. 스티커 스토어는 웹페이지로 작성되어 있고 아이폰, 안드로이드 클라이언트와 유기적으로 연동되어 구매 요청 등을 처리합니다. 처음에는 Python과 Flask를 이용하여 구현하려 하였으나 결국엔 서버 개발자들이 좀 더 익숙한 자바로 구현하기로 결정하였습니다. Jetty와 Jersey를 사용하였고, HTML을 랜더링하기 위한 템플릿 엔진으로는 Closure Template을 이용하였습니다. ORM으로는 Hibernate/JPA, 클라이언트와 웹페이지간 연동을 위해서 Cordova를 이용하였습니다. EC2에서 운영하고 있으며 데이터베이스로는 RDS에서 제공하는 MySQL을 사용합니다. 이미 존재하는 솔루션들을 잘 활용하여 최대한 빨리 개발 할 수 있도록 노력을 기울였습니다.스티커 다운로드 서버: 스티커는 비트윈에서 정의한 특수한 포맷의 파일 형태로 제공됩니다. 기본적으로 수 많은 사용자가 같은 스티커 파일을 다운로드 받습니다. 따라서 AWS에서 제공하는 CDN인 CloudFront을 이용하며, 실제 스티커 파일들은 S3에서 호스팅합니다. 그런데 스티커 파일들은 디바이스의 해상도(DPI)에 따라 최적화된 파일들을 내려줘야하는 이슈가 있었습니다. 이를 위해 CloudFront와 S3사이의 파일 전송에 GAE에서 운영중인 간단한 어플리케이션이 관여합니다. 이에 대해서는 뒷편에서 좀 더 자세히 설명하도록 하겠습니다.구현상 문제들과 해결 방법들적정 기술에 대해 고민하다스티커 스토어 서버를 처음 설계할때 Flask와 SQLAlchemy를 이용하여 구현하고자 하였습니다. 개발팀 내부적으로 웹서버를 만들때 앞으로 Python과 Flask를 이용해야겠다는 생각이 있었기 때문이며, 일반적으로 Java보다는 Python으로 짜는 것이 개발 효율이 더 좋다는 것은 잘 알려진 사실이기도 합니다. 하지만 Java에 익숙한 서버 개발자들이 Python의 일반적인 스타일에 익숙하지 않아 Python다운 코드를 짜기 어려웠고, 오히려 개발하는데 비용이 더 많이 들어갔습니다. 그래서 개발 중에 다시 웹 서버는 자바로 짜게 되었고, 여러가지 스크립트들만 Python으로 짜고 있습니다. 실제 개발에 있어서 적절한 기술의 선택은 실제 프로젝트에 참여하는 개발자들의 능력에 따라 달라져야한다는 것을 알게되었습니다.스티커 파일 용량과 변환 시간을 고려하다사용자는 스티커 스토어에서 여러개의 스티커가 하나로 묶인 스티커 묶음을 구매하게 됩니다. 구매 완료시 여러개의 스티커가 하나의 파일로 압축되어 있는 zip파일을 다운로드 받게 됩니다. zip파일내의 각 스티커 파일에는 스티커를 재생하기 위한 스티커의 이미지 프레임들과 메타데이터에 대한 정보들이 담겨 있습니다. 메타데이터는 Thrift를 이용하여 정의하였습니다.스티커 zip파일 안에는 여러개의 스티커 파일이 들어가 있으며, 스티커 파일은 다양한 정보를 포함합니다카카오톡의 스티커의 경우 애니메이션이 있는 것은 배경이 불투명하고 배경이 투명한 경우에는 애니메이션이 없습니다. 하지만 비트윈 스티커는 배경이 투명하고 고해상도의 애니메이션을 보여줄 수 있어야 했습니다. 배경이 투명한 여러 장의 고해상도 이미지를 움직이게 만드는 것은 비교적 어려운 점이 많습니다. 여러 프레임의 이미지들의 배경을 투명하게 하기 위해 PNG를 사용하면 JPEG에 비해 스티커 파일의 크기가 너무 커집니다. 파일 크기가 너무 커지면 당시 3G 환경에서 다운로드가 너무 오래 걸려 사용성이 크게 떨어지기 때문에 무작정 PNG를 사용할 수는 없었습니다. 이에 대한 해결책으로 투명 기능을 제공하면서도 파일 크기도 비교적 작은 WebP를 이용하였습니다. WebP는 구글이 공개한 이미지 포맷으로 화질 저하를 최소화 하면서도 이미지 파일 크기가 작다는 장점이 있습니다. 각 클라이언트에서 스티커를 다운 받을때는 WebP로 다운 받지만, 다운 받은 이후에는 이미지 로딩 속도를 위해 로컬에 PNG로 변환한 스티커 프레임들을 캐싱합니다.그런데 출시 된지 오래된 안드로이드나 iPhone 3Gs와 같이 CPU성능이 좋지 않은 단말에서 WebP 디코딩이 지나치게 오래 걸리는 문제가 있었습니다. 이런 단말들은 공통적으로 해상도가 낮은 디바이스였고, 이 경우에는 특별히 PNG로 스티커 파일을 만들어 내려줬습니다. 이미지의 해상도가 낮기 때문에 파일 크기가 크지 않았고, 다운로드 속도 문제가 없었기 때문입니다.좀 더 나은 주소 포맷을 위해 GAE를 활용하다기본적으로 스티커는 여러 사용자가 같은 스티커 파일을 다운받아 사용하기 때문에 CDN을 이용하여 배포하는 것이 좋습니다. CDN을 이용하면 스티커 파일이 전 세계 곳곳에 있는 엣지 서버에 캐싱되어 사용자들이 가장 최적의 경로로 파일을 다운로드 받을 수 있습니다. 그래서 AWS의 S3와 CloudFront를 사용하여 스티커 파일을 배포하려고 했습니다. 또한, 여러 해상도의 디바이스에서 최적의 스티커를 보여줘야 했습니다. 이 때문에 다양한 해상도로 만들어진 스티커 파일들을 S3에 올려야 했는데 클라이어트에서 스티커 파일을 다운로드시 주소 포맷을 어떻게 가져가야 할지가 어려웠습니다. S3에 올리는 경우 파일와 디렉터리 구조 형태로 저장되기 때문에 아래와 같은 방법으로 저장이 가능합니다.http://dl.sticker.vcnc.co.kr/[dpi_of_sticker]/[sticker_id].sticker하지만, 이렇게 주소를 가져가는 경우 클라이언트가 자신의 해상도에 맞는 적절한 스티커의 해상도를 계산하여 요청해야 합니다. 이것은 클라이언트에서 서버에서 제공하는 스티커 해상도 리스트를 알고 있어야 한다는 의미이며, 이러한 정보들은 최대한 클라이언트에 가려 놓는 것이 유지보수에 좋습니다. 클라이언트는 그냥 자신의 디스플레이 해상도를 전달하기만 하고, 서버에서 적절히 계산하여 알맞은 해상도의 스티커 파일을 내려주는 것이 가장 좋습니다. 이를 위해 스티커 다운로드 URL을 아래와 같은 형태로 디자인하고자 하였습니다.http://dl.sticker.vcnc.co.kr/[sticker_id].sticker?density=[dpi_of_device]하지만 S3와 CloudFront 조합으로만 위와 같은 URL 제공은 불가능하며 따로 다운로드 서버를 운영해야 합니다. 그렇다고 EC2에 따로 서버를 운영하는 것은 안정적인 서비스 운영을 위해 신경써야할 포인트들이 늘어나는 것이어서 부담이 너무 컸습니다. 그래서, 아래와 같이 GAE를 사용하기로 하였습니다.GAE는 구글에서 일종의 클라우드 서비스(PaaS)로 구글 인프라에서 웹 어플리케이션을 실행시켜 줍니다. GAE에 클라이언트에서 요청한 URL을 적절한 S3 URL로 변환해주는 어플리케이션을 만들어 올렸습니다. 일종의 Rewrite Engine 역할을 하는 것입니다. 서비스의 안정성은 GAE가 보장해주고, S3와 CloudFront의 안정성은 AWS에서 보장해주기 때문에 크게 신경쓰지 않아도 장애 없는 서비스 운영이 가능합니다. 또한 CloudFront에서 스티커 파일을 최대한 캐싱 하며 따라서 GAE를 통해 새로 요청을 하는 경우는 거의 없기 때문에 GAE 사용 비용은 거의 발생하지 않습니다. GAE에는 클라이언트에서 보내주는 해상도를 보고 적당한 해상도의 스티커 파일을 내려주는 아주 간단한 어플리케이션만 작성하면 되기 때문에 개발 비용도 거의 들지 않았습니다.토큰을 이용해 보안 문제를 해결하다실제 스티커를 구매한 사용자만 스티커를 사용할 수 있어야 합니다. 스티커 토큰을 이용해 실제 구매한 사용자만 스티커를 전송할 수 있도록 구현하였습니다. 사용자가 스티커 스토어에서 스티커를 구매하게 되면 각 스티커에 대한 토큰을 얻을 수 있습니다. 스티커 토큰은 다음과 같이 구성됩니다.토큰 버전, 스티커 아이디, 사용자 아이디, 유효기간, 서버의 서명서버의 서명은 앞의 네 가지 정보를 바탕으로 만들어지며 서버의 서명과 서명을 만드는 비밀키는 충분히 길어서 실제 비밀키를 알지 못하면 서명을 위조할 수 없습니다. 사용자가 자신이 가지고 있는 스티커 토큰과 그에 해당하는 스티커를 비트윈 서버로 보내게 되면, 비트윈 서버에서는 서명이 유효한지 아닌지를 검사합니다. 서명이 유효하다면 스티커를 전송이 성공하며, 만약 토큰이 유효하지 않다면 스티커의 전송을 허가하지 않습니다.못다 한 이야기비트윈 개발팀에게 스티커 기능은 개발하면서 우여곡절이 참 많았던 프로젝트 중에 하나 입니다. 여러 가지 시도를 하면서 실패도 많이 했었고 덕분에 배운 것도 참 많았습니다. 기술적으로 크게 틀리지 않다면, 빠른 개발을 위해서 가장 익숙한 것으로 개발하는 것이 가장 좋은 선택이라는 알게 되어 스티커 스토어를 Python 대신 Java로 구현하게 되었습니다. 현재 비트윈 개발팀에서 일부 웹사이트와 스크립트 작성 용도로 Python을 사용하고 있지만 Python을 잘하는 개발자가 있다면 다양한 프로젝트들를 Python으로 진행할 수 있다고 생각합니다. 팀내에 경험을 공유할 수 있는 사람이 있다면 피드백을 통해 좋은 코드를 빠른 시간안에 짤 수 있고 뛰어난 개발자는 언어와 상관없이 컴퓨터에 대한 깊이 있는 지식을 가지고 있을 것이기 때문입니다.네 그렇습니다. 결론은 Python 개발자를 모신다는 것입니다.
조회수 1206

“디자인과 기술을 이어주는 존재, 마크업 개발자를 함께 알아볼까요?” - 유저플로우셀 오혜진

'마크업 개발자', 아직은 우리들에게 다소 생소한 직군이죠. '마크업 개발자'는 디자이너와 개발자 사이에서 '오작교' 같은 역할을 하는 아주 중요한 포지션이에요. 오늘은 코인원의 마크업 개발자로 활약 중인 혜진님과 이야기를 나눠보려 해요. 자신의 위치에서 묵묵히 유저 친화적인 웹 환경을 만들어나가고 있는 혜진님을 만나러 가보시죠!사실 이미 혜진님은 지난 4월 13일(토), 테크 업계 여성들의 목소리에 집중하는 소중한 행사 ‘Women Techmakers Seoul 2019’에서 ‘스타트업에서 마크업 개발자로 살아남기’를 주제로 자신의 이야기를 널리 알리고 왔답니다. 스타트업 그리고 코인원에서 마크업 개발자로 살아남는 혜진님만의 방법은 무엇일까요? :-)Q. 혜진님 안녕하세요, 자기소개 부탁드립니다.안녕하세요, 코인원 유저플로우셀에서 마크업 개발자로 일하고 있는 오혜진입니다. 유저플로우셀은 암호화폐 거래와 프로차트와 같은 트레이딩 영역을 제외한 전반적인 서비스 영역을 담당하고 있어요. 특히 ‘셀'이라는 목적조직으로 개편된 이후 PM, 디자이너, 개발자가 한곳에 모여 누구나 코인원에서 거래를 하고 싶은 마음이 들도록 매력적인 곳으로 탄생시키고 있답니다. 저는 셀안에서 마크업 개발자로 일하며 디자이너와 프론트엔드 개발자를 이어주는 다리 역할을 하고 있습니다.Q. 지난 ‘Women Techmakers Seoul 2019’에서 마크업 개발자를 널리 알리는 발표를 했다고 들었어요. 어떤 내용인지 소개해주세요!감사하게도 ‘스타트업에서 마크업 개발자로 살아남기' 라는 주제로 300명이 넘는 관중들 앞에서 발표를 하고 왔습니다. (사실, 많은 분들이 와주셔서 땀이 좀 나기도 했고요;) 마크업 개발자는 스타트업에서 발견하기 힘든 직군이기도 해요. 보통은 웹 에이전시에 많이 속해 있거든요. 제가 마크업 개발자로 일한지 6년이라는 시간 동안 스타트업에서 어떤 방식으로 일해왔는지 알리고 싶었어요. 그래서 지금까지 이런 일들을 해왔고, 앞으로도 더 활발하게 할 것이라고 속시원하게 말하고 왔습니다.Q. 마크업 개발자는 구체적으로 어떤일들을 하나요?마크업 개발자는 한마디로 디자인(Design)과 기술(Tech)의 오작교 같은 존재입니다. 디자인의 의도가 개발과 충돌하는 부분은 없는지 파악하고, 개발에 잘 녹아들 수 있도록 프론트엔드의 앞단을 맡고 있어요. 코인원 웹 서비스에서 제공하는 신규 기능의 마크업 개발을 담당하고, 운영하면서 생긴 이슈들을 처리합니다. 또한 마크업 레거시에 대한 유지보수 작업도 병행하죠.예를 들어, 코인원의 회원가입 페이지를 제작할 때 디자인 작업을 먼저 들어갑니다. 그럼 디자인 작업을 바탕으로 개발자들이 기능을 만들어 넣게 돼요. 이 때, 기능적인 개발을 제외하고 UI(User Interface)적인 부분을 제가 담당합니다. 회원가입 페이지에는 이메일 인증, 휴대폰 인증 등 여러가지 개발요소들이 많아요. 그래서 개발하기 전에 기능이 들어가는 기본적인 레이아웃을 만들어 개발자에게 전달합니다. 마크업 작업이 바탕이 되어 그 위에 기능 개발이 이뤄진다고 보시면 돼요.디자이너가 레시피를 만드는 사람이라면, 마크업 개발자는 레시피 재료를 세팅해 주는 사람이에요. 개발자들은 세팅된 레시피를 끓이고 버무려 요리를 완성시키고요. 저는 좋은 요리가 탄생할 수 있도록 중간과정을 도와주는 역할인거죠. ▲ 'Women Tachmakers 2019'에서 발표에 열중한 혜진님!Q. 디자인과 기술의 중간 역할을 담당하고 계시군요, 사실 중간자의 역할이라고 하면 이어주는 과정에서 고충(?)이 생길 것 같아요.아무래도 디자이너와 개발자, 양쪽과 다 소통해야하는 부분입니다. 디자이너 입장에서는 ‘왜 프론트엔드에서 이 디자인이 안되는걸까?’ 라는 불만이 생길때도 있고, 프론트엔드에서는 ‘왜 디자인이 이렇게 들어가야 하는걸까?’ 라고 이해를 못할 때도 있어요. 서로의 이해관계를 잘 전달해야 한다는 점이 나름의 고충이죠. 코인원에서는 ‘디자이너 - 마크업 개발자 - 프론트 개발자’의 협업 프로세스를 정립해서 각자가 맡은 분야에 집중 할 수 있는 초석을 다졌어요. 무엇보다도 배경이 다른 세 개의 직군이 원활하게 소통할 수 있는 체계가 잡혀 고충이 해결되고 있습니다 :) Q. 그렇다면 마크업 개발자는 어떤 부분을 기여한다고 볼 수 있나요?코인원 메인 화면에 기능 개발을 추가하지 않고도 마크업단에서의 처리만으로도 쉽게 변화를 줄 수 있습니다. 메인화면의 배너 이미지는 유저들이 코인원에 접속해 제일 먼저 마주하는 부분이죠. 그래서 유저들이 코인원의 시각화된 정보를 빠르게 접할 수 있도록 이미지를 교체합니다. 웹 페이지의 운영 측면에서 비주얼 개편을 빠르게 할 수 있는 환경을 만들어 놓고 대응하는거에요.곧 코인원 마이페이지 화면이 개편될겁니다. 웹 페이지를 새로 만든다는 것은 무에서 유를 창조하는 과정과 같아요. 제가 마크업 개발을 잘 해놓으면 다른 직군에게도 도움이 됩니다. 개발 속도도 더 잘 붙고, 디자인에서도 빈공간이 없는 페이지가 탄생하는거죠. 최대한 밑바탕을 꼼꼼하게 만들어 모두가 일에 더 집중할 수 있는 환경을 만든다고 보시면 돼요.Q. 코인원 마이페이지에서 새롭게 바뀌는 부분은?기존의 마이페이지는 유저들이 보기에 정리가 잘 안되어있다는 느낌이 있었어요. 어떤 인증과정을 끝마쳐야 하는지 한눈에 들어오지 않는 부분이 있었거든요. 이번에 개편될 마이페이지는 좀 더 명확해졌습니다. 이전의 인증페이지가 도돌이표의 느낌이었다면, 이번에는 UX(User experience)를 생각해서 flow 개선도 많이 이뤄졌습니다. 편리한 암호화폐 거래 경험을 코인원에서 느낄 수 있어요. (새롭게 바뀔 마이페이지 많은 기대 부탁드립니다! 물론 편리한 암호화폐 거래도 언제나 코인원!)Q. 유저들에게 편리한 거래경험을 선사하기 위해 어떤 가치를 가장 중요시 여기나요? 저는 중간자이므로 유저들 뿐만 아니라 개발까지 두 가지 측면을 모두 고려합니다. 유저의 입장에서 사용성과 접근성이 용이한 마크업을 짜려고 하고, 개발측면에서는 유지보수가 편리한 마크업을 최대한 짜려고 해요. 개발하기 편한것과 사용하기 편한 것은 다른 맥락이거든요. 요새는 코인원 디자인시스템을 적용하고 있어요. 디자이너 분들이 정리해주신 디자인 시스템을 잘 적용시켜서 코드적으로도 재사용성이 용이하게 관리가 되도록 하고, UI도 정돈이 되어가는 과정을 진행 중입니다. 이런 과정을 계속 거치면 유저들에게 편리한 거래 경험을 선사하는 부분은 놓치지 않을 것 같아요.▲ 마크업에 열중하고 있는 혜진님 (약간의 설정샷 +_+)Q. 코인원 크루로 일하면서 장점을 뽑자면?유저플로우셀은 코인원이 셀이라는 목적조직으로 개편되고나서 만족도가 높은 셀이라고 알고 있어요. 업무도 많은 편인데, 톱니바퀴처럼 잘 맞물린다는 느낌이거든요. 특히 일에 대해서 선긋지 않고, 이슈가 발생했을 때 해결할 수 있는 부분들을 빠르게 파악해주는 부분들이 정말 좋아요. 속도랑 효율성 측면에서 이만큼 해낼 수 있는 팀은 앞으로 만나지 못할 것 같아요. 항상 원활한 업무 소통을 위해 힘써주시는 셀원들에게 감사 드립니다!Q. 앞으로 이루고 싶은 목표가 무엇인가요?회사 안 뿐만 아니라, 바깥에서의 활동도 꿈꾸고 있어요. 마크업 개발자들이 모두 모여 이야기할 수 있는 CSS 컨퍼런스를 열어 좀 더 커뮤니티를 활성화 시키고 영향력을 높이고 싶습니다. 아직 마크업 개발자들만이 모여서 이야기 할 수 있는 곳이 부족하거든요. 저의 이야기도 차곡차곡 쌓아서 여러 창구를 통해 들려드리고 싶고요.코인원에서는 지금 하는 것 이상으로 마크업 개발도 열심히 할거에요. 우선 단기적인 목표로, 프론트엔드에서 사용하고 있는 angular에 대한 이해력을 높일 겁니다. 마크업 컴포넌트 단위에 최적화 된 CSS로 개편해서 사용하지 않는 스타일 리소스가 최소화가 되도록 만들거에요.▲ 마크업 개발자에 많은 관심 부탁드려요 :)디자이너가 디자인에 집중할 수 있게, 개발자가 개발에 집중할 수 있게 ‘일잘러’로 통한다는 혜진님. 혜진님의 인터뷰를 통해 ‘마크업 개발자’에 좀 더 친해지는 시간이길 바라봅니다. 그리고 이렇게 멋진 코인원 크루와 함께 성장하고 싶지 않으세요?  현재 코인원은 멋진 크루들과 함께 크립토갤럭시를 헤쳐나갈 분들을 기다리고 있습니다 :-)
조회수 2678

리디북스 웹뷰어의 이어보기를 개발하며

최근 리디북스에서는 판타지 연재물을 웹에서 바로 볼 수 있는 기능을 새롭게 선보였습니다.기존에는 별도의 앱을 설치하고 다운로드하는 과정을 거쳐야 했기에 연재물을 보는 사용성이 좋지 않았습니다만, 브라우저에서 바로 볼 수 있는 “웹뷰어” 기능을 제공함으로써 사용성을 높일 수 있었습니다.그리고 여기에 사용성을 더하기 위해 추가된 것이 이어보기 기능입니다. 짧아도 100화 이상, 길게는 1000화가 넘는 연재물에서 다음 화로의 매끄러운 연결은 매우 중요합니다. 혹은 잠시 읽기를 중단했다가 다시 돌아왔을 때, 어디까지 보고 있었는지를 빠르게 알려준다면 호흡을 이어서 작품에 더욱 몰입할 수 있을 것입니다.이어보기가 구현된 모습리디북스에 로그인되어 있다면, 이곳에서 확인하실 수 있습니다.이번 글은 이어보기 기능에 대한 개발 후기입니다. 요구 사항에 따라 여러 저장소 솔루션을 비교해 보았으며 최종적으로 Couchbase를 선택한 이유와 간단한 벤치마크 결과, 그리고 겪었던 문제를 공유합니다.요구 사항기획된 내용을 요약하니 아래와 같습니다.연재물의 가장 마지막에 읽은 화를 알 수 있다.보았던 모든 연재물에서 가장 마지막에 읽은 연재물을 알 수 있다.사용자가 본 모든 연재물 목록을 확인할 수 있다.이를 개발자 용어로 다시 풀어보면 아래와 같습니다.연재물을 읽을 때마다 연재물 ID와 화(episode) 정보를 기록한다.보았던 연재물을 최신순으로 정렬하여 가져온다.선택된 연재물의 마지막으로 읽은 화를 가져온다.목록에서 특정 연재물을 삭제한다.이어보기는 가장 마지막에 읽은 연재물을 기억하기 위해 작품을 열 때마다 해당 정보를 기록해야 합니다. 그런데 수십 화를 연달아서 보는 연재물의 특성상 내가 어디까지 읽었는지를 조회하는 것(read)보다 내가 읽은 연재물을 기록하는 것(write)이 더 많을 것으로 판단했습니다. 즉, 읽기보다 쓰기가 더 많을 것으로 예상했습니다.NoSQL을 쓰자대부분의 연산이 쓰기(write)와 관련된 이상, 어떤 저장공간을 사용할 것인지가 주된 관심사였습니다.특히 RDBMS와 NoSQL 사이에서 어떤 것을 사용할지 많은 고민과 테스트를 했고, 결국 아래와 같은 이유로 NoSQL을 사용하는 것이 적합하다고 판단했습니다.현재 사용 중인 MariaDB를 그대로 사용한다면 마스터에 부담을 줄 수 있다.별도로 MariaDB를 구성하더라도 운영 및 쓰기 분산하기가 여전히 어렵다.반면 NoSQL은 RDBMS 대비 확장(Scale out)이 간편하므로 운영에 대한 부담이 적다.단순 Key-Value 보관 용도면 충분하다.이어보기 데이터는 독립적인 성격을 가지고 있어서 다른 사용자 데이터와 JOIN을 할 필요가 없다.이어보기 데이터는 크리티컬한 트랜잭션이 필요하지 않다.MongoDB vs. Couchbase데이터를 영속적으로 유지해야 한다는 요구 사항을 충족하기 위해, Redis 등의 메모리만 사용하는 NoSQL은 제외했습니다. 물론 디스크에 기록할 수 있지만, 성능이 급감하기 때문에 실용적이지 못 합니다. 또한, 메모리 사이즈에 기반을 두기 때문에 Scale up 비용이 크고, 서비스 확장시 Scale out 빈도가 높습니다.그래서 MongoDB와 Couchbase를 비교 대상으로 했습니다. 둘 다 도큐먼트 기반의 NoSQL이고 확장이 용이합니다. 과거에는 MongoDB가 Write lock 사용에 있어서 문제점이 있었지만, 최근 버전에서는 문제가 되지 않습니다.[1] 둘 다 기업용 서비스 및 충분한 부가 기능들을 제공하므로 선택하기 어려웠지만, 최종적으로 아래와 같은 이유로 Couchbase(CE)를 선택했습니다.1. 이미 사내에서 다른 서비스에 사용되고 있습니다.가장 중요한 요인이었습니다. 더 좋은 솔루션이 있더라도 어디까지나 서버 스택을 늘리는 것 이상의 효용이 있는지를 따져보아야 합니다. 이미 사용하고 있는 솔루션이 있다면, 검증이 되었을 뿐만 아니라 개발 및 운영 경험도 활용할 수 있습니다.2. 이어보기는 복잡한 쿼리(Query)가 필요 없습니다.이어보기에서 사용할 쿼리는 간단하기 때문에 Couchbase의 뷰(View)만으로 충분했습니다.Couchbase, 실제 성능은 어떨까?테스트를 하기 전 우리가 어떤 식으로 사용할 것인지 정리해야 합니다. 애플리케이션 액세스 패턴이나 동시성 문제, 데이터 구조화 등을 파악하고 그에 맞는 테스트를 진행해야 합니다. 이번 이어보기는 쓰기 연산이 보다 많기 때문에 이로 인한 뷰의 인덱싱(Indexing)에 초점을 맞추고 테스트를 진행했습니다.성능을 위협하는 요소들View IndexingCouchbase는 MapReduce를 이용하여 뷰를 제공합니다. MapReduce는 일반적으로 리소스를 많이 소모하는 동작입니다. 그래서 Couchbase는 버킷의 새로 갱신된 데이터만 인덱싱하는 Incremental MapReduce라는 기법을 적용해서 리소스 소모를 줄였다고 합니다.[2] 하지만 해당 작업으로 인한 부하는 여전히 발생합니다.Auto CompactionCouchbase는 데이터와 인덱스를 디스크에 데이터를 저장할 때 파일에 추가하기(Append) 모드로만 쓰기를 수행합니다.[3] 그리고 오래되고 불필요한 데이터들은 추후 한꺼번에 정리하는데, 이는 디스크 쓰기 성능을 최대화하기 위함입니다.그런데 이렇게 추가만 하게 되면 오래된 정보들은 파일의 앞에 쌓이게 됩니다. 그리고 사용하지 않게 된 데이터도 남아있습니다. 이를 주기적으로 정리해서 최적화하는 작업을 Auto Compaction이라고 합니다. 뷰의 인덱스는 디스크에 존재하기 때문에 디스크 작업이 있으면 인덱싱에 영향을 미치게 됩니다.성능 테스트Couchbase는 기본적으로 5,000ms마다 Index를 업데이트합니다.[2] 그리고 데이터를 비동기적으로 응답합니다. 비동기는 응답속도를 빠르게 하지만, 데이터 불일치가 발생할 수 있습니다. 데이터 불일치가 신경 쓰이고 이 시간이 길다고 생각되면, stale 옵션을 지정해서 뷰의 인덱스를 업데이트할 수 있습니다.이어보기는 뷰가 간단하기 때문에 응답시간에 큰 문제가 없을 것으로 예상하고 stale 옵션을 꺼두었습니다. 이 옵션은 뷰를 조회했을 때 버킷의 변경사항에 따라 뷰를 인덱싱하고 데이터를 응답합니다. 하지만 예상한 것과 같이 실제로도 응답시간이 짧은지 확인할 필요가 있습니다. 그래서 다음과 같이 테스트를 진행했습니다.테스트 환경은 아래와 같이 2-tier로 준비하고 요청을 늘려가면서 RPS를 측정했습니다.서버 구성OS: Ubuntu 14.04Application: Couchbase Server (CE) 3.1.3클라이언트 구성클라이언트 1개에서 50개의 세션으로 요청10만 사용자 가정책은 1만개의 책중 랜덤으로 선택됨요청의 70%는 책 읽기(Bucket Write)요청의 30%는 연재물의 마지막에 읽은 책 가져오기(View Read)그래프 분석성능 테스트 주요 지표RPS : Response Per SecondSP : Saturation PointBuckle zone : 시스템 과부하로 인해 내부 자원이 서로 경쟁상태나 적체 상태가 심해지기 때문에 최대 처리량보다 더 떨어지는 경우가 발생함성능테스트 결과그래프를 보면 요청이 늘어남에 따라 RPS가 선형으로 증가하지만, SP인 8,000 RPS에 도달하고 나서 Buckle zone에서 7,000 RPS로 수렴하고 있습니다. 물론 1개의 클라이언트에서 세션을 생성해서 테스트를 진행했기 때문에 서버의 성능 부족이 아닌 클라이언트의 병목 현상이 원인일 수 있습니다. 또한 JMeter나 다른 부하 테스트 툴을 사용하지 않고 간략하게 만든 테스트 툴을 사용하였기 때문에 수치가 부정확할 수 있습니다. 그러나 어디에서 병목이 있었든 현재 이 이상의 성능이 필요하지 않기 때문에 테스트 결과에 만족할 수 있었습니다.이어보기 배포 후모바일 브라우저 캐시 문제이어보기 기능을 배포하자마자 당일 저녁 이슈 하나를 접수했습니다. 아이패드와 PC를 번갈아 이용할 경우 이어보기 데이터가 맞지 않다는 것이었습니다.데이터를 쌓을 때 모든 이력을 기록하지는 않았지만, 다행히도 Couchbase에 이용기기와 시간은 기록하였기 때문에 이를 바탕으로 디버깅을 할 수 있었습니다. (서비스 초기라 할지라도 최대한 많은 이력을 남기는 것이 중요함을 다시 느꼈습니다)원인은 아이패드의 멀티태스킹으로 인한 캐시 소멸이었습니다. 아이패드 브라우저의 캐시가 소멸되면서 마지막으로 열어두었던 페이지가 강제적으로 리로딩되었고, 이때 의도치 않게 마지막 위치 정보가 덮어씌워진 것입니다.이 문제는 기술적으로 해결이 쉽지 않아 결국 기획을 수정하게 되었습니다. 사용자가 해당 책을 읽었다고 판단하는 기준이 “페이지를 열어본 즉시”였다면, 이를 “페이지를 열고 수 초 이상을 유지”하는 것으로 기준을 변경하였습니다. 물론 근본적인 해결책은 아니었지만, 실제 사용에는 지장이 없는 합리적인 해결책이라고 생각합니다.Key 구조의 변경 및 동시성 문제Couchbase는 높은 성능을 위해 메타데이터(Key + @)를 모두 메모리에 적재하는 특징이 있어서, Document 하나가 평균 350Byte를 차지하고 있었습니다. 따라서 현재 상태로 1000만개의 데이터를 저장할 경우 최소 3.5G의 메모리를, 2개의 사본(Replica)를 유지할 경우 약 10.5G의 메모리를 사용하게 될 것으로 예상되었고 이는 큰 부담으로 다가왔습니다.처음에는 단순히 “사용자ID_연재물ID” 형태의 Key를 사용하였지만, 보다 빠르게 증가할 것으로 예상되는 것은 사용자보다 연재물 이었으므로 아래와 같이 Key값을 변경하여 메모리 사용량을 크게 줄였습니다.// U_id : S_id 조합을 사용하면 Key가 엄청 많아진다. // 그래서 사용자당 Key를 100개로 제한하도록 한다. Count = 100 Key = '사용자ID' + ('연재물ID' % Count) 그런데 이렇게 Key 구조를 변경하였더니, 간단한 업데이트 동작임에도 불구하고 정상적으로 수행되지 않는 경우가 빈번하게 발생하였습니다. 이유는 낙관적 동시성(Optimistic concurrency) 모델의 특징 때문이었는데, Couchbase는 명시적인 잠금 이외에도 “Check and Set(CAS)”이라는 기능을 제공하고 있었습니다.공식 문서의 예제를 참고하여 아래와 같이 로직을 수정한 뒤로는 다행히도 동시성 문제가 아직까지 발생하지 않고 있습니다.boolean updateUsingCas(key, value) {  for (tryCount = 0; tryCount < MAX>    orgValue, cas = getValueAndCas(key)           // Update the original value.     // newValue = ... if setValueWithCas(key, newValue, cas)      return SUCCESS sleep(0.1) // 부하를 줄이기 위해  }  return FAIL } 맺으며동작하는 서비스에 새로운 기능을 추가한다는 것은 어려운 일입니다. 특히 새로운 데이터 스토리지를 필요로 하는 일이라면 더더욱 어렵다고 생각합니다. 그리고 그럴 때일수록 설계에 많은 시간을 들여야 한다는 것을 느꼈습니다. 설계 초기에는 RDBMS의 샤딩까지 고려하였지만, 요구 사항을 구체화할수록 단순 Key-Value로도 같은 문제를 해결할 수 있음을 깨달았기 때문입니다.또한, 서비스 개발에 있어서 어려운 문제를 마주했을 때 기술적으로만 접근할 것이 아니라 고객이 정말 원하는 것이 무엇인지를 고민하여 기획적으로 해결하는 능력도 중요하다는 것을 실감하였습니다.마지막으로 Couchbase는 현재로서도 꽤 좋고 앞으로도 많은 발전이 기대되는 NoSQL입니다. 도입을 고민하시던 분들께 조금이라도 도움이 되었기를 바랍니다.참고자료[1] MongoDB - Concurrency[2] Couchbase - Views Operations[3] Couchbase - File write#리디북스 #개발 #개발자 #서버개발 #서비스개발 #고객중심 #기능개발 #Couchbase #인사이트 #개발후기
조회수 1862

Circle CI에서 rbenv를 이용해서 Ruby 2.2와 CocoaPods 0.39 버전 사용하기

최근 Circle CI에서 Ruby 버전을 2.3으로, CocoaPods 버전을 1.0으로 업그레이드함에 따라 발생하는 빌드 문제를 rbenv를 이용해서 해결한 경험을 공유합니다. 최종적으로 완성된 Gemfile과 circle.yml 파일은 마지막 섹션에서 확인하실 수 있습니다.1. CocoaPods 1.0지난 2015년 12월에 CocoaPods 1.0.0 베타 버전이 처음 공개되었습니다. CocoaPods이 1.0 버전으로 업그레이드되면서 굉장히 많은 변화가 있었는데요. 가장 큰 변화는 DSL입니다. 추상 타겟Abstract Target과 타겟 상속Target Inheritance이 새롭게 소개되면서, 0.39 버전까지 자주 사용되던 link_with 및 :exclusive => true와 같은 구문이 제거되었습니다.이에 따라 기존에 사용하던 Podfile이 CocoaPods 1.0 버전과는 호환되지 않는 문제가 발생했습니다. 이를 해결하기 위한 가장 좋은 방법은 새로운 DSL을 사용하여 Podfile을 다시 작성하는 것이지만, 꽤 많은 서드파티 라이브러리를 사용하는 StyleShare의 경우 새로운 DSL을 적용하여 빌드하면 각종 문제로 인해 빌드가 정상적으로 이루어지지 않았습니다. 4년동안 유지되고 있는 프로젝트이다보니, 레거시 Objective-C 코드와 라이브러리, 그리고 새로운 Swift 코드와 라이브러리가 혼용되어 사용되는 것도 원인 중 하나일 것입니다.따라서 StyleShare에서는 CocoaPods 0.39 버전을 사용하기로 결정을 했습니다. 하지만 최근 Circle CI에서 CocoaPods 버전을 공식적으로 1.0 버전으로 업그레이드하면서 빌드가 깨지기 시작했습니다. Circle CI 환경에서 CocoaPods 0.39 버전을 사용하려면 어떻게 해야 할까요?▲ ㅠㅠ2. Bundler를 이용해서 Gem 관리하기Bundler는 Ruby로 작성된 라이브러리들의 버전을 관리해주는 강력한 도구입니다. CocoaPods에서 Podfile에 의존성을 기재하듯, Bundler에서는 Gemfile에 의존성을 기재합니다.source 'https://rubygems.org' gem 'cocoapods', '~> 0.39' $ gem install bundler 명령어를 사용하면 Gemfile에 기재된 의존성 라이브러리들을 설치해줍니다. 이렇게 설치된 CocoaPods을 사용할 때에는 $ pod COMMAND 대신 $ bundle exec pod COMMAND 명령어를 사용해야 합니다.$ gem install bundler $ bundle install --path vendor/bundle $ bundle exec pod --version 0.39.0 3. Ruby 2.3과 CocoaPods 0.39Bundler를 사용해서 CocoaPods 0.39 버전을 사용하기만 하면 모든 문제가 해결될 줄 알았습니다. 하지만 더 큰 삽질이 남아있었는데요. 바로 Ruby 2.3 버전이 CocoaPods 0.39 버전과 호환되지 않는 것이었습니다.$ bundle exec pod install Updating local specs repositories Analyzing dependencies 신나게 $ bundle exec pod install 명령어를 실행하니, 의존성을 분석하는 듯 싶다가 갑자기 에러를 주르륵 뱉습니다. 에러 로그의 #### Error 항목을 보면 에러 메시지가 나와있습니다.NoMethodError - undefined method `to_ary’ for #이 에러 메시지로 CocoaPods GitHub 저장소의 이슈를 검색해보면 꽤나 많은 이슈가 올라와 있습니다. 이 이슈들을 보면, 모두 Ruby 버전이 2.3이라는 공통점이 있습니다. Ruby 버전을 2.2로 내렸더니 문제가 해결됐다는 댓글들도 굉장히 많고요. Circle CI의 Ruby 버전을 2.2로 낮추면 문제가 해결될 것 같습니다.Circle CI 문서 내용에 따라 circle.yml에 Ruby 버전을 기재해봅시다.machine: ruby: version: 2.2.5 그러나 Circle CI의 OS X 컨테이너에서는 Ruby 버전 변경을 지원하지 않는다고 합니다.▲ ㅠㅠ (2)4. rbenv를 이용해서 Ruby 2.2 사용하기그러다가 알게된 것이 바로 rbenv입니다. rbenv를 사용하면 여러개의 Ruby 버전을 깔끔하게 관리할 수 있게 됩니다. rbenv는 Homebrew를 사용해서 쉽게 설치할 수 있습니다.$ brew install rbenv rbenv는 ~/.rbenv 디렉토리에 안에 여러 Ruby 버전을 설치하고 관리합니다. rbenv를 설치한 뒤 가장 먼저 할 일은 환경변수 $PATH를 설정해주는 것입니다. $PATH에는 $HOME/.rbenv/shims와 $HOME/.rbenv/bin 경로가 포함되어있어야 합니다.4.1 환경변수 설정하기Circle CI에서는 환경변수를 설정하는 편리한 인터페이스를 제공합니다. 하지만, Circle CI에서 실행되는 각 명령어는 별도의 쉘에서 실행됩니다. 그말인 즉슨, 각 명령어가 실행되기 직전에 새로운 쉘이 실행되고, $PATH 환경변수를 덮어쓰는 .bash_profile이 실행된 후 명령어가 실행된다는 뜻인데요. 이렇게 될 경우 $PATH 환경변수의 가장 우선순위는 항상 /usr/local/bin이 가지게 됩니다. 그리고 같은 이유로 $ export FOO=bar와 같은 명령어도 사용할 수 없게 됩니다.1고민을 하다가 생각해낸 방법은 바로 .bash_profile의 내용을 변경(!)하는 것입니다. 그렇게 되면 우리가 원하는 $PATH를 항상 우선순위로 둘 수 있게 됩니다. 아래와 같이 환경변수를 설정하는 명령어를 .bash_profile의 가장 아랫줄에 삽입하도록 설정했습니다.machine: pre: - echo "export PATH=\$HOME/.rbenv/shims:\$HOME/.rbenv/bin:\$PATH" >> .bash_profile - echo "export RBENV_SHELL=bash" >> .bash_profile 4.2 rbenv에 Ruby 2.2 설치하기그 다음으로 할 일은 원하는 Ruby 2.2 버전을 설치하는 것입니다. $ rbenv install -l을 사용해서 설치 가능한 모든 Ruby 버전을 조회할 수 있고, $ rbenv install 2.2.5 명령어를 사용해서 2.2.5 버전을 설치할 수 있습니다.$ rbenv install -l Available versions: 1.8.5-p113 1.8.5-p114 1.8.5-p115 1.8.5-p231 ... $ rbenv install 2.2.5 이렇게 설치된 버전은 두 가지 방법으로 사용될 수 있습니다. 한 가지 방법은 시스템 전체에서 사용하는 것이고, 다른 한 가지 방법은 프로젝트 단위로 사용하는 방법입니다. 시스템 전체에서 사용하려면 $ rbenv global 2.2.5 명령어를, 프로젝트 단위로 사용하려면 $ rbenv local 2.2.5명령어를 사용합니다.global 명령어를 사용해서 Ruby 버전을 선택하면 ~/.rbenv/version 파일에 선택된 버전이 기록됩니다.$ rbenv global 2.2.5 $ cat ~/.rbenv/version 2.2.5 local 명령어를 사용하면 현재 디렉토리의 .ruby-version 파일에 선택된 버전이 기록됩니다.$ rbenv local 2.2.5 $ cat .ruby-version 2.2.5 local 명령어로 선택된 Ruby 버전은 global 명령어로 선택된 Ruby 버전보다 우선순위가 높습니다. $ rbenv version 명령어를 사용하면 현재 선택된 버전을 확인할 수 있습니다.$ rbenv version 2.2.5 (set by /project/path/.ruby-version) Circle CI에서는 편의를 위해 global 명령어를 사용해서 Ruby 버전을 선택하도록 했습니다.dependencies: pre: - brew update - brew install rbenv - rbenv install 2.2.5 - rbenv global 2.2.5 4.3 Bundler 다시 설치하기rbenv를 사용해서 새로운 Ruby 버전을 설치했기 때문에, Circle CI 시스템에서 제공하는 Gem도 다시 설치해야 합니다. 우리는 Bundler로 Gem 의존성을 관리하기로 했으므로, Bundler만 재설치합니다.$ gem install bundler --no-ri --no-rdoc $ rbenv rehash $ gem install 명령어를 실행한 후에는 $ rbenv rehash 명령어를 실행해서 executable 경로들을 재설정해주어야 합니다.4.4 ~/.rbenv 경로 캐싱하기rbenv를 사용해서 Ruby를 설치하는 과정이 굉장히 오래 걸립니다. 이 경우, Circle CI에서 제공하는 캐싱 기능을 사용해서 이 과정을 한 번만 하고 건너뛸수 있게 됩니다.dependencies: cache_directories: - ~/.rbenv 위와 같이 circle.yml를 설정해주면 컨테이너 실행시 ~/.rbenv 디렉토리가 캐시로부터 설정됩니다. 캐싱된 디렉토리를 사용하는 경우 Ruby 버전이 미리 설치되어있기 때문에 $ rbenv install시에 --skip-existing 옵션을 추가해주어서 캐싱된 버전을 재설치하지 않도록 합니다.5. 마치며최종적으로 완성된 Gemfile과 circle.yml 파일은 다음과 같습니다.Gemfilesource 'https://rubygems.org' gem 'cocoapods', '~> 0.39' circle.ymlmachine: pre: - echo "export PATH=\$HOME/.rbenv/shims:\$HOME/.rbenv/bin:\$PATH" >> .bash_profile - echo "export RBENV_SHELL=bash" >> .bash_profile xcode: version: 7.3 dependencies: cache_directories: - ~/.rbenv pre: - brew update - brew install rbenv - rbenv install 2.2.5 --skip-existing - rbenv global 2.2.5 - gem install bundler --no-ri --no-rdoc - rbenv rehash - bundle install --path vendor/bundle override: - bundle exec pod --version - bundle exec pod install https://circleci.com/docs/environment-variables/#custom ↩#스타일쉐어 #개발 #개발자 #개발팀 #후기 #일지 #인사이트
조회수 1424

스타일쉐어 커머스 시스템 리빌딩 회고 1

스타일쉐어 스토어 소개스타일쉐어 스토어(이하 커머스)는 2016년 4월 출시되어 지금까지 나날이 성장하고 있습니다. 작년 초, 커머스 시스템을 리빌딩하기로 했고 현재까지 진행 중입니다. 어떤 이유로 리빌딩을 하는지, 어떤 고민을 했는지, 어떻게 진행하고 있는지 몇 자 적어보려 합니다. 이 글은 문제 인식, 목표, 계획에 대한 내용입니다.리빌딩을 결정한 이유커머스 프로젝트를 시작할 당시 커머스 시스템을 경험해본 개발자가 없었습니다. 이 상황에서 새로이 구현하기엔 위험 부담이 크다는 판단을 했습니다. 때문에 커머스 솔루션을 도입했고, 적은 비용으로 커머스 기능을 출시할 수 있었습니다. 거래량이 점점 늘어나면서 솔루션이 감당할 수 있는 한계치를 벗어나자, 예상치 못했던 기술적인 이슈가 발생했습니다. 사내 MD팀, CS팀은 물론, 입점사들과 유저들에게까지 불편한 경험을 주고 있었습니다. 개발팀은 솔루션 유지 보수와 운영 이슈에 집중했지만, 끝이 없는 문제들에 점점 지쳐갔습니다. 개발팀의 퍼포먼스는 저하되고 있었고, 새로운 기능 개발에 집중하지 못하는 상황까지 발생했습니다. 이 시점에서도 거래량과 매출은 꾸준히 늘어났으며, 더 늦기 전에 리빌딩을 진행해야겠다고 판단했습니다.리빌딩의 목표당장 눈앞에 생겨나는 문제들로, 서비스가 해결하고자 하는 본질적인 문제들에 집중하지 못하는 상황입니다. 궁극적으로 이 상황을 개선하고 싶었습니다. 그리고 선택의 기로에 섰을 때 좋은 기준을 제시하기 위해, 언제 끝날지 모르는 리빌딩이 산으로 가는 걸 막기 위해 목표를 몇 가지 세웠습니다.유지보수 및 운영 이슈에 소모되는 개발 리소스 최소화커머스 시스템과 연계되는 기능들을 공격적으로 개발할 수 있도록 함개발 리소스 대비 높은 퍼포먼스를 낼 수 있어야 함튼튼한 커머스 시스템목표 1. 유지보수 및 운영 이슈에 들이는 개발 리소스 최소화기존 솔루션의 큰 레거시는 소모될 개발 리소스의 양과 일정을 예측하기 어렵게 만들었고, 개발자에게도 큰 스트레스를 안겨줬습니다. 서비스의 성장을 방해하는 큰 걸림돌 중 하나이며, 개발팀의 움직임을 느리게 만드는 주된 원인이었습니다. 리빌딩을 완료하더라도 유지보수와 운영 이슈는 끝이 없을 테지만, 더 이상 같은 문제를 반복하고 싶지 않았습니다. 효율적인 개발 리소스 운용을 위해선 가장 신경 써야 하는 부분이라고 생각됩니다.목표 2. 커머스 시스템과 연계되는 기능들을 공격적으로 개발할 수 있도록 함기존 솔루션 레거시가 너무 복잡하여 기능을 추가하거나 개선하기 어려워 반려한 요구사항이 많았습니다. 매력적인 요구사항에도 조심스럽게 대응했습니다. 서비스 성장을 위해 다양한 시도를 해야 하는 상황인데, 기술적인 이유로 진행이 까다롭다고 말하는 게 항상 아쉬웠습니다. 개발팀에서도 좋은 기능을 공격적으로 구현하고 싶으나, 실제로도 작업하기 까다로워 항상 답답했습니다. 어떤 방법이던 괜찮으니 지금보다 훨씬 더 공격적인 기능 구현으로 서비스 성장에 좋은 영향을 주고 싶었습니다.목표 3. 개발 리소스 소모 대비 높은 퍼포먼스를 낼 수 있어야 함스타일쉐어 팀은 기존 서비스 운영과 동시에 항상 새로운 무언가를 찾으려 합니다. 개발팀은 이 움직임에 맞춰 개발 리소스를 효율적으로 운용해야 합니다. 하지만 개발 리소스는 한정적이며, 다양항 상황에 따라 유동적으로 변해 예측하기 어렵습니다. 이런 상황에서 커머스 관련 작업 시, 언제나 평균 이상의 높은 퍼포먼스를 내고 싶었습니다.목표 4. 튼튼한 커머스 시스템커머스 시스템의 장애는 매출에 직접적인 악영향을 줍니다. 어떤 작업을 하더라도 커머스 시스템은 잘 운영되어야 합니다. 높은 가용성은 개발팀의 숙명이며, 공격적인 기능 개발에도 높은 가용성을 유지하려면 더욱 신경 써야 합니다.모두 꿈에 가까운 목표들입니다. 이 목표들에 조금이라도 더 가까이 다가갈 수 있도록 노력한다면 보다 좋은 결과를 얻을 수 있을 거라 생각했습니다.현실 반영과 계획당연하게도 현실적인 부분을 생각해야 했습니다. 이미 예정된 작업들이 많아 리빌딩에 필요한 개발 리소스를 확보하기 어려웠고, 개발 성공 여부 또한 불확실해 팀원들을 설득하기 어려웠습니다. 유지보수와 운영 이슈는 끝이 없었고, 회사 방향에 따라 추가 기능 개발과 개선 작업을 진행해야 했습니다. 이 상황을 고려해 리빌딩을 성공적으로 진행할 수 있도록 계획을 세워나갔습니다.개발 리소스에 여유가 생길 때까지 서브 프로젝트로 진행기존 커머스 시스템과 리빌딩된 시스템을 동시에 운영할 수 있어야 함적절한 단위로 서비스를 나눠 안전하고 효율적으로 개발 진행계획 1. 개발 리소스에 여유가 생길 때까지 서브 프로젝트로 진행다들 리빌딩이 필요하다고 느꼈지만, 선뜻 진행하기엔 큰 부담이었습니다. 시간이 흘러 여유가 생길 때 리빌딩을 진행해도 되지만, 그땐 너무 늦을 것 같았습니다. 최대한 빨리 작업을 시작하고 싶었고, 그러기 위해선 서브 프로젝트 수준으로 진행하는 게 제일 빠른 방법이라 생각했습니다.계획 2. 기존 커머스 시스템과 연동되어 동시에 운영할 수 있도록 함리빌딩의 완료 시점을 예측하기 어려웠습니다. 때문에 기존 커머스 시스템을 운영하며 리빌딩을 진행해야만 했습니다. 그리고 리빌딩된 시스템은 점진적으로 기존 커머스 시스템을 교체해 나가야 하므로, 두 시스템이 서로 연동되어야 했습니다. 또한 리빌딩된 시스템이 잘 동작할지에 대한 확신이 없어, 언제나 후퇴 계획을 세워야 했습니다. 이런 이유로 기존 커머스 시스템의 DB와 스키마를 그대로 사용하고, 두 시스템의 로직이 서로에게 문제가 되지 않도록 조심스럽게 개발하기로 했습니다.계획 3. 적절한 단위로 서비스를 나눠 안전하고 효율적으로 개발 진행커져가는 개발팀과 복잡해져 가는 커머스 시스템을 생각하면 요즘 자주 들리는 마이크로 서비스 구조(이하 MSA)를 도입해도 되지 않을까 싶었습니다. 솔직히 이런저런 이유보다, 재미 때문에 도입해보고 싶었습니다. 처음 도입하는 구조라 조심스러웠지만, 적절한 단위로 서비스를 나눈다면 충분히 좋은 효율을 낼 수 있을 것이라 생각되었습니다. 재미와 만족은 덤이고요. 서비스를 나누는 기준은 2가지로 잡았습니다.개발 안정성/개발 속도 둘 중 어느 것에 집중해야 하는가?서비스를 사용하는 주체는 누구인가?—개발 안정성/개발 속도 둘 중 어느 것에 집중해야 하는가?개발 안정성과 개발 속도에 대해 생각한 이유는 시스템 안정성과 작업 퍼포먼스 모두 잡고 싶은 마음 때문이었습니다. MSA는 서비스 별로 다른 언어를 사용해도 괜찮다는 장점이 있습니다. 덕분에 상황 별로 각기 다른 언어를 사용할 수 있고, 이를 통해 개발 안정성 혹은 개발 속도에 잘 집중할 수 있을 것이라 기대했습니다. 나중에 기술 스택을 설명하면서 얘기를 하겠지만, 개발 안정성을 추구해야 하는 부분은 java8로, 개발 속도를 추구해야 하는 부분은 node나 python으로 구현됩니다.서비스를 사용하는 주체는 누구인가?서비스를 어떤 기준으로 나눌지 고민이 많았습니다. 처음엔 상품 관리, 주문 관리, 출고 관리 등 DB 테이블에 가까운 기준으로 나누려고 했으나, 서버 운영이 큰 부담으로 다가올 것 같다는 의견 때문에 다른 기준을 세워야 했습니다. 서비스를 사용하는 주체 별로 나누면 어떨까라는 말이 나왔고, 이 기준이라면 큰 부담이 없을 것 같았습니다. 서비스를 사용하는 주체는 유저, 관리자, 입점사, 다른 서비스 이 4가지라고 정의했고, 이에 따라 서비스를 구성했습니다.—앞서 말한 두 기준으로 나눴을 때에 대한 예시입니다.유저 커머스 서비스 (node 혹은 python)관리자 커머스 서비스 (node 혹은 python)입점사 커머스 서비스 (node 혹은 python)커머스 핵심 기능 서비스 (java8)위 두 기준 말고도 서비스 운영에 큰 부담이 없다면 상황에 맞춰 다른 기준을 세워 서비스를 나누기도 했습니다.이 고민이 끝난 후, 현실적으로 실행 가능한 계획이 나온 것 같아 만족스러웠습니다. 이 계획을 토대로 아키텍처를 구성하고 개발을 진행했습니다.마무리어떤 문제 때문에 리빌딩을 결정했고, 어떤 목표와 계획을 세웠는지 주저리주저리 적어봤습니다. 앞에서 말했듯이 리빌딩은 아직 진행 중입니다. 현재 정식 일감으로 진행되고 있고, 상황에 맞게 계획을 다시 세워 조금씩 목표에 다가가고 있습니다. 처음엔 3부로 계획했지만, 아직 리빌딩 중이란 걸 까먹고 있었나 봅니다. 이 프로젝트가 완료되기 전까진 회고록으로써 글을 계속 쓸 것 같습니다. 앞으로 풀어야 할 문제들이 많으니 하소연할 것들도 많을 거고요. 아무쪼록 다음 편에선 시스템 구성도와 기술 스택에 대해서 한번 이야기해보려 합니다.스타일쉐어 개발팀의 고민과 생각들이 부디 도움이 되었길 빕니다. :)#스타일쉐어 #개발팀 #리빌딩 #인사이트 #조언
조회수 5550

유용한 Javascript UI Component 라이브러리 소개

웹 애플리케이션을 개발할 때 기능적으로는 무관하지만, 사용자에게 인터렉티브하고 심미적으로 예쁜 디자인을 제공하고 싶은 경험이 있을 것입니다. 하지만 막상 직접 구현을 하는 것은 생각보다 시간이 오래 걸리고, 구현하더라도 양질의 UI가 나오지 않는 경우들이 있습니다. 그래서 이번 글에서는 쉽고 빠르게 양질의 UI를 제공해주는 라이브러리를 소개해 드리려고 합니다.Spin.js작업을 완료하거나 페이지가 넘어갈 때 아무런 말도 없이 그냥 기다리는 경우가 있습니다. 이럴 경우 사용자에게 현재 기다리는 중이라는 것을 표현하는 것이 좋습니다. 이러한 기능을 제공해주는 라이브러리가 바로 Spin.js입니다.Spin.js는 위의 그림과 같이 로딩 중이나 무언가를 진행 중이라는 것을 알려주는 사용하기 쉬운 Javascript 라이브러리입니다. 이미지 없이 사용되어 매우 가볍게 사용할 수 있습니다. 그리고 사용할 때 쉽게 설정하여 사용할 수 있으며 대다수 브라우저를 지원합니다.Spin.js / DownloadDatatables많은 양의 정보를 쉽게 볼 수 있도록 테이블로 정리해야되는 경우가 있습니다. 그러나 많은 양의 정보를 처리할 때 쉽게 원하는 정보를 찾을 수 있어야 하고 정보가 쉽게 정렬이 될 수 있어야 합니다. 이러한 기능을 제공해주는 라이브러리가 바로 Datatables입니다.Datatables는 위의 그림과 같이 테이블을 동적인 테이블을 만들어주는 JQuery Javascript 라이브러리입니다. 다양하게 정렬할 수 있도록 테이블을 만들수 있으며, 따로 정보를 찾아주는 기능을 만들어주지 않아도 검색을 할 수 있는 기능을 제공하고, 정보를 편하게 볼 수 있도록 구성을 제공합니다. 그리고 DOM, Ajax, Server-Side Processing으로 쉽게 정보를 Datatables로 만들 수 있습니다.DatatablesCurtain.js긴 내용으로 된 하나의 페이지를 섹션별로 효과적으로 내용을 전환해야 되는 경우가 있습니다. 그러나 사용자에게 혼란을 주지 않으면서 전환 효과를 만들어 내야 합니다. 이러한 기능을 제공해주는 라이브러리가 바로 Curtain.js입니다.Curtain.js는 위의 그림과 같이 마치 커튼이 걷히는 것처럼 내용 전환 효과를 주는 JQueryJavascript 라이브러리입니다. 각 내용을 화면에 고정하고 스크롤이나 키보드를 통해 화면을 전환하여 트렌디하면서 인터렉티브한 느낌을 쉽게 제공할 수 있습니다.Curtain.js / DownloadTurn.js위의 Curtain.js가 세로형태의 전환 효과를 내는 것이었다면 가로형태의 전환 효과를 내야 하는 경우가 있습니다. 이러한 기능을 제공해주는 라이브러리가 바로 Turn.js입니다.Turn.js는 위의 그림과 같이 책장을 넘기는 듯한 내용 전환 효과를 주는 JQuery Javascript 라이브러리입니다. 하나에 페이지를 섹션별로 나눠서 키보드를 통해 화면을 전환하여 책장을 넘기는 느낌을 제공해 스마트폰이나 태블릿에서 책을 읽는 듯한 느낌을 쉽게 제공할 수 있습니다.Turn.js / DownloadGlfx.js이미지를 따로 수정해서 올리는 것이 아니라 웹에서 바로 밝기를 조정하거나 다양한 효과를 주고 싶은 때도 있습니다. 이러한 기능을 제공해주는 라이브러리가 바로 Glfx.js입니다.Glfx.js는 위의 그림과 같이 다양한 효과를 주는 WebGL기반의 Javascript 라이브러리입니다. 이미지에 Blur 효과, 세피아, 밝기 조절, 모자이크처리 등 다양한 효과를 다양한 설정을 통해 쉽게 사용 할 수 있습니다. 그러나 WebGL 기반으로 되어 있어서 WebGL을 지원하는 브라우저만 가능합니다.Glfx.js / DownloadJQuery Tag-it태그를 넣을 때 쉽게 수정 가능하게 하고 자동완성기능을 넣고 싶은 때도 있습니다. 이러한 기능을 제공해주는 라이브러리가 바로 JQuery Tag-it입니다.JQuery Tag-it은 위의 그림과 같이 태그에 대한 JQuery Javascript 라이브러리입니다. 쉽게 태그를 넣고 지울 수 있으며 태그에 대해 자동완성 기능을 지원합니다. 그리고 각 태그에 대해 이벤트를 줄 수 있어서 매우 유용하게 사용하실 수 있습니다.JQuery Tag-it / DownloadTinycon새 글의 개수나 접속자 수에 대한 정보를 사용자에게 알리고 싶은 때도 있습니다. 이럴 경우 브라우저 탭에 정보를 제공하는 경우가 있습니다. 이러한 기능을 제공해주는 라이브러리가 바로 Tinycon입니다.Tinycon는 위의 그림과 같이 파비콘에 동적인 숫자를 통해 정보를 알리는 Javascript 라이브러리입니다. 매우 쉽게 사용할 수 있으며, 설정을 통해 어떤 내용을 숫자로 표현할 것인지를 쉽게 사용자화 할 수 있습니다. 파비콘에 경우 브라우저 탭에 항상 보이기 때문에 아주 유용하게 사용할 수 있을 것 같습니다. 그러나 현재 크롬, 파이어폭스, 오페라 브라우저만이 지원 가능합니다.Tinycon / Download3D GALLERY사진이나 슬라이드 탭을 보여주기 위해 갤러리 공간을 만듭니다. 그래서 좀 더 효과적으로 보여주기 위해 다양한 효과를 넣는 경우가 있습니다. 이러한 기능을 제공해주는 라이브러리가 바로 3D GALLERY입니다.3D GALLERY는 위의 그림과 같이 내용을 3D로 나열해 보여주는 JQuery Javascript 라이브러리입니다. 간단한 설정으로 3D로 배치하고 움직이도록 할 수 있습니다. 그리고 자동으로 내용을 넘어가게 할 수도 있고 다양하게 바뀌는 효과를 줄 수 있습니다.3D GALLERY / Demo글을 마치면서이번 글에서는 UI Component Javascript 라이브러리들에 대해 알아봤습니다. 위의 라이브러리로 좀 더 쉽고 빠르게 양질의 웹 애플리케이션을 개발할 수 있었으면 좋겠습니다.#스포카 #개발자 #디자이너 #협업 #Javascript #라이브러리 #꿀팁 #유용한정보

기업문화 엿볼 때, 더팀스

로그인

/