29 4월 2021

[Startup/창업] 스타트업, 그렇게 대부분 실패하더라

[Startup/창업] 스타트업, 그렇게 대부분 실패하더라

100개의 스타트업이 만들어지만, 90개는 실패하더라.

스타트업을 모든 기업의 시작점이라고 정의해보자.

원대한 꿈과 멋진 비전을 가지고 시작한 스타트업이지만, 스타트업의 수명은 정말 짧고, 분명 그 끝은 빠르게 다가온다. 슬프고 미안하지만, 그 꿈의 대부분은 비극이다.

한여름밤의 악몽처럼 스타트업은 그렇게 실패로 마무리 된다.100개의 스타트업이 시작되면 99개의 스타트업은 대부분 비극으로 끝이나고. 한두개의 기업만이 살아남을 뿐이다. 아이디어, 멤버, 자본이 충분했지만, 주변 여건과 사회적인 운으로도 망할 수 있다. 기업이란 원래 그렇다.

다 갖추고 있어도 실패할 수 있다. 반대로, 한가지 이유때문에도 성공한다.

하지만, 그 성공의 이유는 그냥 운일뿐, 실패를 줄여가는 것이 최선일 뿐이다.

창업자는 다만 꿈을 키워 기업의 형태로 만드는 것에 집중해야 한다. 그래야, 악몽에서 빠져나올 수 있다. 실패에 좌절하지 않고, 다시 도전할 수 있다.

정말 성공했다고 평가받으려면, 시장에서 서비스와 제품이 소비될 때에 스타트업은 ‘성공’했다고 이야기할 수 있을 것이다. ‘성공’에 대한 이야기를 듣고 싶으면 다른 곳에서 듣도록 하자, 여기서는 제대로 꽃을 피우지도 못하고 씨앗 상태에서 발아하지 못하는 것을 ‘실패’라고 정의하고, 그런 스타트업의 ‘실패’에 대해서 이야기할 것이다.

스타트업을 시작하는 사람들은 대부분 ‘성공신화’의 정보를 수집하느라 바쁘다. 하지만, 실제 성공한 사람들의 이유들을 100가지 나열해봐야, 따라 할 수 없는 것들이 대부분이다.

재벌 2,3세가 아니라서 어렵고, 서울대, MIT, 스탠포드를 다니지 못했기 때문에 따라 하기 어렵다. 심지어, 미국에서 시작한 것도 아니며, 시대 적인 배경도 다르다. 그래서, ‘성공’만 수집하는 것은 대부분 ‘실패’로 달려가는 지름길을 찾고 있는 것이라고 이야기하겠다. 타인의 성공 스토리는 들어봐야 쓸모없다.

성공에 왕도나 공식은 없다. 성공의 요인에서 99가지를 완벽하게 갖추었지만, 단 한 개의 요소가 빠져서도 실패할 수 있다.

스타트업을 시작한 사람들은 타인의 ‘성공’에 대한 ‘신화’를 듣기보다는, ‘실패사례’를 꾸준하게 수집해야 한다. 그나마 수집된 ‘실패’를 내가 다시 경험하지 않도록 하는 것이 그나마 최선이다. ‘실패’에 대한 경험을 바탕으로 ‘성공’하기 위해서 조금이라도 변수를 줄여 나갈 수 있다.

창업은 쉽다!

창업을 하기는 쉽다. 하지만, 성공하기란 정말 어렵다. 그냥 대부분 실패한다. 많은 사람들이 성공하는 방법들에 대해서 이야기를 한다고 하지만, 대부분 가짜들이다. 정말 성공에 대한 중요한 요소는 그들 자신도 설명하지 못하는 경우가 대부분이다. 그러니, 그들의 성공 스토리는 그들만의 이야기라고 인식하기 바란다.

성공사례는 그 사람이기 때문에, 그 사람의 아이디어이기 때문에 성공한 경우도 많다. 그래서, 대부분의 잘못된 사례들은 그대로 뭉개고 가는 경향이 많을 뿐이다.

참신한 아이디어에서 출발한다?

스타트업의 핵심을 ‘참신한 아이디어’라고 착각하는 사람들이 많다. 단언컨데 아니다.

다만, 정말 중요한 것은 그렇게 생각한 아이디어가 최소한 ‘나에게 만이라도’ 필요한 것이냐고 반문하는 것이다. 그리고, 나라면 그 ‘아이디어’를 ‘돈’을 주고 살 가치가 있냐고 확인하는 것이다.

정말 필요한 가치가 있거나, 최소한 아름답고, 매력적인 요소가 있다면, 그것을 위해서 고객들은 ‘구매의사’를 보일 것이고, 그것은 곳 비즈니스 모델이 성립한다는 것을 의미한다. ‘기업’은 아이디어를 ‘실현’하는 곳이라고 생각하기보다는, ‘팔릴만한 제품’이나 ‘서비스’를 만들어 파는 곳이라고 생각을 해야 한다. 정말로, 비즈니스 모델이라는 의미를 아는 것을 떠나서, ‘팔릴 만한 제품’이나 ‘구매 의미가 있는 소프트웨어’를 만들고 있는가? 그것을 가장 먼저 생각해야 한다.

아이러니하지만, 그렇다고, ‘제품’에 있는 그런 가치에만 집중한다고 모든 비즈니스 모델이 성립하는 것은 또 아니다. 실제 제품이나 서비스는 실제 구현되고 제조되어진 상태로 시장에서 고객들에게 평가를 받을 수 있어야만, 제대로 된 가치를 인정받는다.

아무리 참신한 아이디어라도 ‘팔릴만한 제품’과는 꼭, 필요충분 요건은 아니라는 것이다. 재미있는 아이디어를 가지고 놀거나 대화를 하는 행위가 완전하게 비효율적인 것은 아니지만, 너무 그 ‘참신함’에만 매달려서는 문제를 제대로 인식하는 것이 아니다.

그리고, 그러한 아이디어가 시장과 가치가 모두 있어도 그냥 성공하는 것이 아니다. 그 아이디어를 실현하도록 모인 팀원들이 그 아이디어와 가치를 어떻게 생각하느냐가 또 하나의 중요한 요소가 된다.

고집을 피우지 않으면 망한다

창업자가 새로운 비즈니스 모델에 대한 아이디어를 가진 사람의 생각을 팀원에게 전파하는 것은 정말 어렵다.

한편으로는 그러한 시도를 한다는 것 자체가 무모한 짓이다. 그래서, 대부분의 리더들은 자신의 동료에게는 의견 통일을 구하지만, 직원에게는 전달하는 것에 집중하는지도 모른다. ( 모든 리더들은 자기가 스티브 잡스가 된것 처럼 착각하는 경우가 많다. 웃긴다. )

뭐, 정말로 그러한 아이디어나 모델을 자신의 팀원에게 설명하는 것이 가능할 수도 있을지 모른다. 그렇지만, 필자는 여기서 조언을 하고 싶다. 창업자의 생각과 열정을 팀원들이 그대로 받아들여서 일을 해주었으면 하는 바람은 저 멀리 던져버리라고.

필자가 과거에 벤처기업을 창업하고 운영할 때에 많은 개발자들과 동료들을 모아서 진행해 보았지만 대부분 실패했다. 스타트업의 리더는 초기에 아이디어를 구상하고 기획하고, 투자자를 끌어모으고, 업무를 진두지휘하는 것만으로 충분하지 않았나 한다.

오히려, 기업 내부의 교육이나 철학적인 부분까지 너무도 많은 것을 내재화하려 애를 쓴 것이 오히려 독이 되었다는 점이다. 자칫 잘못하면 골목대장 놀이가 될 뿐이고, 이 시간과 비용들이 이런 시간으로 무참하게 낭비되는 경우를 빈번하게 경험했으며, 지금 이시간에도 수많은 스타트업 리더들의 ‘삽질’에서 느낄 수 있다.

물론, 스타트업의 ‘창업자’는 외롭고 힘들다. 그리고, 가장 큰 문제는 ‘창업자’가 너무 힘들다는 것이다.

초기의 불안전한 아이디어나 모델들을 다른 사람들의 아이디어를 사용해서 보완한다는 것 자체가 무모한 도전을 하고 있다는 것을 잊지 말자. 원래, 그런 자리다. 외롭고 힘들고, 두려운 것이 정답이다. 끝없는 마인드 컨트롤이 아니면 버티기 어려운 자리다. 매우 당연하다. 그렇지만, 그러한 고민과 어려움을 직원들과 나누려 하지 마라.

돈 몇푼 받고 일하는 직원들은 그런 리더를 우습게 여길 뿐이다. ( 돈을 많이 받아도 똑같다. 직원은 직원일 뿐이다. )

아이디어를 실현하는 고민은 창업자와 리더의 머릿속에서 완성되어야 한다. 그것을 팀원이 도움을 주어서 완성된 형태로 만들것이라고 착각을 기반으로 한 계획을 세우지 않기를 권한다.

당신의 불완전한 아이디어를 듣는 직원들은 자신의 생각과 자신의 시선으로 아이디어를 다시 해석할 뿐이다. 같은 단어를 서로 이야기한다고 하지만, 서로 따른 이야기를 하고 있다는 것이다. 정말, 혁신적인 아이디어라면 직원은 그 단어를 잘 이해못하는 것이 매우 당연하다.

어떤 아이디어나, 기획이 혁신적이지 않다면, 창업해야 할 의미가 없는 것이고, 그 아이디어들은 생각보다 단순한 바탕에서 보통 출발하는 것이 대부분이다. 보통, 그 아이디어와 기획에 대해서 듣는 대부분의 반응은 ‘그 아이디어가 팔리겠어?’라는 반응일 것이다. 이때에 직원들은 그냥, 이해가 가지 않아도 그냥 넘어간다. 슬프지만, 사실이다.

그래서, 불완전한 아이디어를 직원들과 만들다 보면, 대부분 이상한 ‘물건’이 나의 의사와 상관없이 나왔다고 푸념하고, 직원들을 원망하고 있는 자신을 발견하고 있을 것이다. 슬퍼하지 말라. 당신의 아이디어가 원래 불완전했기 때문에 그런것 뿐이다.

중간 정리를 하자면, 남의 이야기와 아이디어를 나의 아이디어와 합한다는 것은 정말로 어려운 일이다. 컨설팅을 수년이상을 해도 그런 행위는 정말 어려운 것이다. 설명하기 어려운 것만큼 고집을 피우지 않는다면 일은 성립하기 어렵다는 것을 잊어버리면 안 된다. 정말 만들고 싶은 것은 ‘고집’을 피우고, 원하는 것을 만들기 위해서 자신이 처음과 끝을 마무리 해야 한다.

엔지니어가 아니라면 최소한 서비스의 형태는 자신이 원하는 형태로 동작하는지 테스트는 해야 한다.

기업 내부를 치열하게 만들면 망한다

성공한 기업의 특징은 비즈니스 모델에서 얻어지는 이익이 야박하지 않다는 점이다. 특히, IT업체의 특징 중의 하나는 ‘이익’이 큰 것이다. 냉정하게 이익이 많지 않은 일을 창업했다면, 그 비즈니스는 잘해도 그 모양일 것이다.

‘이익’이 크기 때문에, 잘되는 IT기업의 특징은 일정상 느슨한 구조를 가지게 된다. 그리고, 잉여를 존중하거나 기회를 많이 제공하게 된다. 한편으로는 이런 기업의 특징은 머리가 좋거나 아이디어가 충만한 사람들에게는 부드러운 직장생활이 되는 반면에, 능력이 부족하면 매우 괴로운 기업문화가 된다. 기업 내부를 창의적인 집단으로 만들려면 ‘부드럽게’ 만들고 ‘재미있게’ 만들어야 한다.

하지만, 대부분의 기업은 정해진 시장과 정해진 제품과 기능만을 만족하면 팔리는 적절한 투자에 적합한 기능들로 충분한 경우가 많다. 정말, 큰 시장을 노리고 있다면, 기업 내부를 치열하게 만들면 안 된다. 그러면, 망하는 조건을 하나 더 추가한 것이다.

기회는 또다시 온다고 믿는 것

어떤 기회나 도전, 열정, 사람과의 인연 등을 보면, ‘아깝다’라는 기분이나 기회가 많이 만나게 된다. 비슷한 기회는 다시는 돌아오지 않는다. 그 순간이 끝인 경우가 대부분이다.

이런 기회를 잡는다는 것 자체가 대단한 실력이고 대단한 운에 해당한다.

정말, 기회는 다시 오지 않는다. 대부분 실패한 사람들은 그러한 ‘기회’를 제대로 잡지 못한 경우가 태반이다. 아니, 그런 ‘기회’가 온지도 모르고 지나가는 경우도 많다. 보통, 그러한 기회를 제대로 파악하기 위해서 ‘시각화’하고 ‘도표’화한다.

물론, 모든 것을 정량적으로 수치화한다고 모든 것이 보이는 것은 아니다. 하지만, 최소한의 것이라도 정량적으로 평가하지 않는다면, 최소한의 기회의 시점도 찾기 어려워진다.

이는, 기업의 회계나, 소프트웨어 개발의 시각화 모두에 해당한다. 모든 것이 수치화시킨다고 하더라고, 정성적인 평가나 경험적인 평가가 결합하지 않으면, 그런 ‘수치’도 무의미하다고 하겠다.

최소한의 수치화도 안된다면, 최소한의 기회도 찾기 어렵다.

양보는 방향성을 상실하게 한다.

소프트웨어 개발에 있어서 ‘법’과 같은 절대적인 방법론이 존재한다면, 아마도. 누가 해야 할 것인가에 대해서는 고민하지 않을 것이다. 하지만, 소프트웨어 개발에 있어서 그러한 ‘법칙’은 없다.

냉정하게 이야기하자면, 누군가가 편해지만, 누군가는 불편해지고 일이 많아진다. 그렇다면, 일이 많아지는 곳의 논리가 명확해지고, 그 인사평가도 명확해진다면 그러한 일은 줄어들까?

업무를 결정하는 사소한 다툼과 방향성은 그 기업과 팀, 조직의 탄성과 관성을 만들어내는 원동력이 되기도 한다.

문제는, 이러한 협의의 과정에서 만들어진 결과물들은 퇴적층처럼 쌓여서, 그 기업의 문화로 발전되게 된다. 업무의 협의의 과정은 ‘이번에 내가 양보했으니, 다음번에는 당신이 양보하면 되겠네’라는 발상이 통용되지 않는다.

대부분의 업무협의과정은 한번 양보한 사람이 계속 양보하게 되어있고, 한번 이기면 계속 이기는 것이 보편적인 현상이다. 이러한 것은 ‘실력’의 문제 이전에, 작업의 우선순위 결정에 있어서의 탄성력이 발생한 것이다.

어떤 방식으로 결정되고, 사소한 업무라도 개시해서, 작업 결과물이 축적되는 것과 같은 작업과 업무의 선택 방법이 회사의 ‘체계’로 굳어지게 되는 것이다.

그래서, 보통 초반부터 기선제압을 하고 주도권을 잡으려 애쓰는 것이 보편타당할 것이다. 하지만, 이러한 결정이 올바른 방향으로 간다면 다행이겠지만. 대부분은 그 퇴적층처럼 쌓이는 결정권의 방향성 때문에 기업의 수명이 제한되는 것이 보통이다.

누군가는 분명 양보를 했다.

그래서, 그 업무는 누군가에게 집중된다.

보통은 그 업무나 요구사항의 ‘해결책’을 제시하는 팀이나 사람에게 그 업무는 전이되게 된다. 내 업무 중에 ‘자동화’되거나, ‘시스템’이 자동적으로 해결되는 일과, 고객과 개발되는 서비스와의 연관성에 있어서, ‘고품질’로 운용이 되고 있다면, 그 업무를 분명 대신해주고 있는 협상은 ‘대가’를 받아야 한다.

‘툰드라의 늑대’ 이야기가 그 좋은 예가 될 수 있다.

영국 에든버러대 교수이자 협상 전문가인 게빈 케네디가 이야기한 ‘튼 드라의 늑대’ 이야기는 양보의 역효과에 대해서 설명한다.

오래전 유럽 세일즈맨들이 툰드라 지역의 원주민 마을을 찾아갔다.

그들은 원주민에게 냉장고와 맥주 같은 문명의 이기를 팔고, 사냥 방법을 배우면서 가까워졌다. 그런데 바로 그 “사냥”이 문제의 시작이었다. 한 세일즈맨이 사슴 사냥에 성공한 뒤 썰매를 타고 돌아오던 중 멀리서 늑대 한 마리가 쫓아오는 것을 느꼈다.

위험을 직감하고 미친 듯이 도망치던 그는 더는 안 되겠다 싶어 사냥한 고기를 조금 떼어 던져줬다. 다행히 늑대가 쫓아오지 않아 한숨 돌리려던 순간, 이제는 서너 마리의 늑대가 쫓아오는 것이 보였다. 생각할 겨를도 없이 또 고기를 던져줬다. 이때부터 불행의 반복이었다. 어느덧 수십 마리가 그를 뒤쫓았고, 남아 있는 고기는 없었다.

그 순간 마을에 도착해 다행히 늑대로부터 목숨은 건질 수 있고, 이 일을 전해 들은 다른 세일즈맨들은 그 지역을 돌 때마다 여분의 고기를 갖고 다니다가 늑대가 위협해오면 던져줬다. 하지만 거기까지였다.

어느 날 원주민들이 그들을 내쫓은 것이다.

“배고픈 늑대에게 썰매를 따라가라고 가르친 멍청한 놈들! 당장 꺼져!”

이들이 쫓겨난 이유는 늑대에게 베푼 “선의의 양보” 때문이다. 양보가 결코 미덕이 아니라는 뜻이다. 하지만 양측 모두 무작정 버티면서 시간만 끌 수는 없는 법. 양보할 수밖에 없는 상황이라면 다음 같은 사항을 명심해야 한다.

“만약”이라는 말을 반드시 붙여라. “만약 내가 그 조건을 양보한다면 당신은 나에게 뭘 양보해줄 수 있나요?”

이 말은 “내가 먼저 양보할 테니 당신도 양보해달라”는 것과 다르다.

“당신이 내 마음에 드는 양보를 한다면 나도 똑같이 양보할 뜻이 있음”을 밝히는 것이다.

이렇게 자신의 양보가 절대 “공짜”가 아님을 알려라. 나의 양보를 가치 있게 만드는 것이 가장 중요하다.

아직도 꽉 막힌 협상을 푸는 방법은 양보라고 생각하는가. 자신의 상대는 툰드라의 늑대와 다르다고 믿는가.

그렇다면 이렇게 물어보자. 당신의 상대가 당신에게 “대가 없는” 양보를 한다면 당신도 그에게 그만큼의 양보를 해줄 것 같은가.

— 주간동아 ‘803호’에 실린 칼럼 중에서… 세계경영연구원의 IGM 비즈니스 리뷰 중에서.

양보는 하되, 그에 걸맞은 ‘대가’에 대해서 상대방에게 인지하게 하는 것이 기술이며, 처세술의 기본이다. 어떤 요구사항이나 업무에 대해서 협의가 발생하게 되면, 그 ‘대가’를 상대방에게 지불하게 하는 방법을 같이 구사하여야 한다.

소프트웨어 개발에 있어서의 ‘정치’라는 것은, 단순화한 파워게임이나 자존심 대결이 아니라, 실용적인 개발방향을 정하는 것이라는 점이다. 문제는 ‘내가 이해하지 못한다고, 상대방의 이야기를 듣지 않는 경우가 발생하는 것이 가장 큰 문제이다’. 이런 방법으로 ‘양보’를 얻어낸다는 것은 결국, 소프트웨어의 미래를 포기하게 하는 것인지도 모른다.

어떤 협의 이후에, ‘편하고 좋은 환경’에서 개발일을 하게 된다는 것은, 그에 상응하는 ‘비효율적이고, 불편하고, 어려운 개발’ 일을 누군가가 대신하고 있다는 것을 잊으면 안 된다.

편하고 효율적인 개발환경은 분명하게도 이러한 ‘정치’적인 선택과 혜택을 제공받았기 때문인지도 모른다. 하지만, 이러한 상황은 비 개발자와 개발자 사이에서도 빈번하게 발생되는 문제들이다.

하루에 끝날 일을 3개월 넘게 말싸움을 할 수도 있다. 그것은, ‘자리’를 만들기 때문이다.

전문가의 권위는 추락했지만, 그 능력은 인정하자

인쇄 성경판이 구텐베르크에 의해 실현되고, 성직자의 권위가 떨어진 현상과 대응되는 것. 전문가의 권위, 전문가의 지식을 꼭 따라야 하는가?

어떤 식당에서 밥을 먹을지 선택하는 것을 유명한 음식 평론가의 평판이나 의견에 따라서 움직이는 것보다, 사용자들의 평점에 따라서 추천순위가 매겨진 스마트폰 애플리케이션을 따르는 것이 틀리다고 말할 수 있는가?

가장 전문가의 권위와 지식에 의존하는 범주를 설명한다면, 그것은 ‘의학지식’과 같다. 하지만, 대부분 우리들은 이러한 전문가의 지식에만 의존하지는 않는다. 그것은, ‘경험 지식’에 의한 것일 수 있기 때문이다.

이미, 우리는 ‘지식’과 ‘경험’을 중첩으로 경험하는 시대를 접하고 있다.

이제는 ‘전문가’들이 ‘사용자들의 경험’을 더욱더 높은 가치로 인정하는 시대가 되고 있다.

‘PatientLikeMe’서비스의 경우에는 전문의들이 오히려, 사용자들의 경험을 참고하고, 인용하기 시작한다.

다만, 양이 늘어나면 질이 떨어지는 것을 어떻게 하는 것인가가 관건이지만, 그만큼. 다양성이라는 가능성을 얻게 되고, 콘텐츠는 보다 저렴하고 신속하게 소통되면서 획기적인 발견이나 창조성이 발견되러 질 가능성도 높아진다.

이제는 특정한 조건에 의해서 영향을 받는 것이 아니다.

노하우가 아닌 노후

knowhow가 아닌 knowwho

소프트웨어 개발 방법론은 다양한 방법과 전략들을 만들 수 있으며, 이를 통해서 수많은 요구사항과 문제점들을 배치하고 나열할 수 있다. 그 이외에도 소프트웨어 개발에 있어 필요한 스킬은 정말 많은 것을 필요로 한다.

대표적으로 부수적으로 필요한 스킬을 보면 보고서나 기획서를 쓰는 방법, 소프트웨어 설계를 잘하는 방법, 디자인 패턴을 고르고, 배치하는 방법, 인공지능과 같은 첨단적인 기법을 활용하는 방법까지도 매우 다양하다.

하지만, 이제 소프트웨어 개발에 있어서 최고로 필요로 한 것은 무엇일까? 과거에는 소프트웨어 개발을 가장 잘하는 방법은 how(어떻게) 그것을 만들어내는가에 집중되어 있었고, 그것은 Know-how라고 불렸다.

경험에 의해서 축적되어진 이 지식을 통해서, 결정되어졌으며, 이 노하우를 가장 많이 가진 사람을 ‘실력자’라고 인정하였다. 하지만, 시대가 바뀌고, 소통과 협업, 농담 삼아 이야기하는 구글 신이 지배하는 세상으로 변화하였다.

이제 ‘노하우는 필요 없다’는 것이다. 냉정하게 이야기하자면, 소프트웨어 개발자가 뭔지 모르면 배우면 되고, 그 자료나 정보들은 인터넷을 찾아보면 된다. 그리고, 그것 마저도 없으면 삽질하면서 얻어낼 수 있다.

현대의 소프트웨어 개발자에서 가장 문제가 있는 사람은 이것저것 다 빼고, 이러한 방법들을 시도조차 하지 않는 ‘안 하려는 사람’ 일뿐이다.

이제는 ‘삽질’을 하면서 얻을 수 있는 무궁무진한 방법들이 인터넷에 널려있는 세상이다.

소프트웨어 개발에 있어 대부분은 일상적이고 평범한 일이 대부분이다.

대부분 폼도 안 나고, 개발자로서 얻는 것도 없고, 평가도 부족한 업무와 소프트웨어 개발이 대부분이다. 과연 이러한 소프트웨어 개발을 하는 업무에 대해서 어떻게 평가를 해야 할까? 대부분의 소프트웨어 개발사들은 이러한 업무에 대해서 ‘평가’가 매우 적고, 박하게 평가하는 편이다.

그런 회사일수록, 해당 업무를 ‘누가 할 것인가’에 대한 ‘폭탄게임’이 심각하게 발생한다.

‘어떤 모듈이나 서비스를 어떻게 만들어야 하는지에 대해서는 모르는 사람이 없다’

‘신입만 되어도 해당 모듈이나 서비스는 만들 줄 안다’

이러한 업무들의 특징은 작업은 어렵지 않지만, 누가 크게 알아주지도 않는다. 하지만, 대부분 이런 업무의 특성이 대량의 파일을 다루고, 테스트 시간도 오래 걸리고, 잘해봐야 본전이고, 못하면 대박 깨지는 그런 업무들이다.

너무도 뻔하기 때문에, 너무도 뻔하게 업무를 해야 하는 업무들이고, 팀이나 조직원들 간에도 이러한 업무들은 가능한 전담하려 하지 않는 것이 대부분이다.

정말, 귀찮고, 매력 없는 업무들이기 때문이다.

물론, 몇 가지 방법이 있다. 그러한 일상적이고 뻔한 업무들은 외부에 용역을 주거나, 외부의 서비스들을 구매해서 사용하거나 연계해서 사용하는 방법이 최선의 경영진의 판단일 것이다. 기업은 ‘가치’를 인정받을 수 있는 최고의 일을 하는 것이기 때문이다.

‘폭탄 돌리기’가 가장 극심한 기업과 조직일수록, 가장 말이 많이 나오는 이야기는

‘원래 그 업무는 XXX가 해야 한다’라는 ‘원래’라는 식의 단어들이다.

‘이렇게 해도 되고’

‘저렇게 해도 되고’

‘요렇게 해도 된다’는 업무야말로…

냉정하게 ‘방법’을 몰라서 삽질하는 것이 아니라, ‘정치’적인 싸움을 하는 것이 가장 큰 문제이다.

‘양보’하면 계속 밀릴 수밖에 없다.

한번 기득권을 가져가거나, 협상에서 밀리면, 그 권한을 다시 회복하기는 정말 어렵다. 그래서, 기업 내부에서 팀 간의 ‘기득권’ 쟁탈전은 언제나 발생한다. 또한, 업무는 손쉽게 하면서 최고의 가치만을 얻어가려 애쓰는 것은 틀린 이야기가 아니다.

하지만, 이러한 ‘폭탄게임’은 회사의 수명을 짧게 만들고, 회사를 망하게도 할 수 있는 치명적인 문제로 발생하게 된다.

보통, 이렇게 정착되어진 ‘회사의 규칙’에 의해서, ‘중요한 고객의 요구사항’이 잘못 판단되게 되어지고, 그 영향은 제품과 서비스에 반영되어진다. 그리고, 그 기업의 품질에도 큰 영향을 주게 되는 것이 보통이다.

요구사항의 판단과 ‘품질’의 판단은 ‘양보’로 얻어지면 안 된다.

협의와 협상의 규칙이 만들어지는 것이 최선이지만, 그것이 안된다면, 중복적이고 가치는 적지만, 효용가치가 높은 것부터 업무가 가치 있고, 평가가 후한 업무라면 부서와 사람이 업무를 거부하겠는가?

요구사항과 업무는 그 가치와 평가가 효과적 이도록 결합되어야 한다. 부정적이고 의미 없는 업무를 제거한 상태라면, 요구사항들의 가치가 형성되도록 요구사항들이 결합되어야 한다.

소프트웨어 개발에는 ‘원래’라는 단어는 없다.

오래된 경력자들이 모이면 오히려 개발 진행이 어려운 경우가 많다. 그것은, 각자의 경험상에 축적되어진 지식들의 왜곡현상 때문에 발생하는 일상적인 일인 경우다.

자신의 경험과 지식과 타인의 경험과 지식이 왜곡되고, 서로에게 강요하는 일이 발생하게 되는 것은 매우 당연한 것이다.

냉정하고 ‘사공’이나 ‘선장’은 적은 사람이 해야 한다.

소프트웨어 개발에 있어서 가장 빠르게 변화하는 것과 자신의 가능성을 최대한 확장하는 방법을 잘 알고 있음에도 불구하고, 자신의 경력과 지식, 경험에 자꾸 제한을 가하게 되는 경우는 ‘경력이 풍부한 사람’ 일 수록 흔히들 빠지게 되는 함정과도 같다.

자신의 경력을 내려놓고, 신입과 동일한 ‘눈’으로 맞출 수 있는 사람이 더 새로운 경험을 많이 하게 된다.

사공이 많게 되면 배가 산으로 가거나, 서로 샅바 싸움을 하거나, 배가 꿈쩍도 하지 않는 상황을 만들지 않게 하는 것이 아키텍트가 해야 할 일이다.

소프트웨어 개발에 있어서 가장 경험자가 많은 경우에 선택하기 쉬운 구조는 ‘독재’를 하는 방법이 최선이다. 대부분의 회사들은 그러한 ‘정치구조’를 선택한다. 그리고, 그러한 구조를 통해서 ‘컨트롤’을 하는 것이 일반적이다. 그래서, ‘일반적인 구조’가 어울리는 소프트웨어 개발 조직도 많다.

다만, 이 조직은 철저하게 ‘리더의 자질’에 의해서 모든 것이 결정되어진다는 점이다. 한 사람이 가진 지식과 경험이라는 것은 ‘인터넷의 바다’에 비한다면…

토론과 의견수렴을 하는 방법을 만들자

기업의 입장에서는 ‘디아블로’와 같은 절대군주와 같은 리더가 최선일 수 있다. 그리고, 그 군주가 실패하면 갈아치우면 되니까 가능한 구조이다. 다만, 이러한 ‘업무 스타일’은 유지하게 하는 것이 최선이다.

보통 ‘토론’의 경우에는 ‘5명’이 넘어서는 안된다. 대부분 그 이상의 토론은 통제 자체가 불가능하다.

대부분의 정치구조는 ‘혼란’스러우면 ‘독재’를 선택한다. 그리고, ‘현명한 군주나 리더’가 너그러운 정치를 통해서, 좋은 결과를 유도하기를 바란다.

의사결정 과정은 ‘민주적’이지 않지만, ‘좋은 결과물’을 만들어내는 대부분의 구조는 이러한 방법이 대부분이다.

하지만, 대부분 이러한 구조는 ‘정치’적인 상황을 만들고, 그 리더와 그 의견에 동조하는 세력들이 모여지고, 발언권을 동조하는 세력들을 만들게 되는 상황으로 흔하게 흘러간다.

이러한 모습이 대부분 기업들이 중견기업으로 성장하면서 겪게 되는 대부분의 문제들이다. 하지만, 이러한 모습들은 불편한 상황들을 만든다.

냉정하게 대부분의 정치는 ‘목소리’를 내고, ‘목소리’가 큰 사람이 주도하는 형상으로 끌려간다. ‘적극적으로 의사표현’을 하는 사람들의 위주로 흘러가게 되는데, 문제는 이러한 행위들이 사익을 위한 것인가? 회사 전체를 위한 것인가? 에 대한 모호함 때문이다.

더더군다나, 동양적인 소극적이고 양보하고 겸손하게 살게 하는 ‘문화’ 속에 살고 있는 우리의 입장에서는 정말로, 기업적인 색깔과 모습을 표현하는 것은 정말 어려운 일이고, 목소리를 내는 사람의 이야기를 ‘사익’에 가까운 모습으로 연상하게 되는 것은 어쩔 수 없는 일인지도 모른다.

가장 좋은 방법은 ‘의사표현’을 할 수 있는 방법을 제공해주는 것이다. 어떻게든, 소극적이고 겸손한 사람들의 ‘의견’과 ‘아이디어’가 소통되게 만드는 것이 최선의 방법이다.

‘독재’는 빠르고 효과적이지만, 조직을 ‘지옥’으로 만들 가능성이 농후하다, 하지만. 내부가 불통되고, 세력다툼이 벌어지는 구조는 더더욱 문제가 심각하다. 최선의 선택은 언제나 ‘독재’ 인지도 모른다. 하지만, ‘똑똑한 독재자’는 ‘왕조’, ‘편안한 왕조’와 ‘똑똑한 왕’이 된다.

그래서, 기업들 대부분이 경력 2~4년 차를 원한다. 대부분 ‘독재화’되어진 구조에서는 ‘아이디어’가 필요한 것이 아니기 때문이다.

우리 기업에 있어서 ‘혁신’이나 ‘창의성’이 정말 중요한가?

아이디어와 요구사항이 가장 잘못되어지는 것

추상화가 가장 잘못되어지는 사례는 기획을 한 사람과 구현한 사람이 중요한 핵심기능을 잊어버린 체, 변화되는 ‘어떤 것’에만 집중하는 경우이다. 사용자에게 ‘제공되는 가치’에 대해서 제대로 인식하지 못하면, 끊임없는 반복 작업만이 기다리고 있으며, 유지보수성이나 플랫폼과 같은 결과물은 기대할 수 없게 된다.

‘어떤 기능’에 대해서 무비판적으로 기능을 추가하는 것이 가장 큰 문제이다.

소프트웨어 개발에 있어 절체절명의 원칙은 ‘반복 작업’을 최소화하는 것이다. 그 방법이 유틸리티를 만들든, 서비스를 만들든, 스크립트 언어를 사용하던, 어떻게든 최소화하는 것이다. 다만, 그 리소스의 활용이나 기간 상의 문제만 다를 뿐이지, 추상화는 ‘반복 작업’을 최소화한다.

특히, 소프트웨어 개발기업에 있어 가장 중요한 소프트웨어 개발자의 리소스를 가장 효율적으로 사용할 수 있도록 디자인하는 것이 최선이다. 기획자와 요구사항 수집자는 가능한 소프트웨어 개발자가 ‘한 번만 개발 작업’을 할 수 있도록 최선을 다해서 추상화를 하는 것이 최선이다.

소프트웨어 개발에 있어서 ‘메시지’를 기획자가 자유롭게 다루도록 하되, 소프트웨어 개발자는 ‘메시지’를 표현하는 기능은 한 번에 집중하게 하는 것이, 추상화의 기본 원칙을 쉽게 설명한 것이다.

그렇다면, 이러한 요구사항을 추상화하는 과정은 누가 해야 하는가? 냉정하게 이야기한다면, 기획자가 최선을 다해서 추상화하여, 소프트웨어 개발자의 리소스를 최대한 활용할 수 있도록 해야 한다.

그 원칙은 어떻게 하면 프로그래머의 작업을 최대한 단순화하느냐에 달려있다.

이 원칙은 프로그래밍 팀과 기능 관련 회의와 일정을 최소화하고, 버그를 줄여주며, 기획이 최대한 반영되는 방법으로 변화한다.

냉정하게 그 기업에서 ‘월급이 밀리냐? 안 밀리냐?’의 중요한 차이는 이러한 아이디어나 요구사항을 어떻게 최대한 추상화하느냐에 달려있다.

더 쉬운 설명은 ‘데이터’가 변화하는데 ‘소프트웨어 코드’가 바뀐다면, 그 소프트웨어의 추상화는 실패한 것이다.

기획과 요구사항을 어떻게 추상화해야 하는가?

요구사항을 유스 케이스로 표현하면서 최대한 가능하게 된다.

어떤 것들이 유지보수에 집중적인 영향을 주는가를 생각하게 한다.

아키텍트가 존재하는가?

그렇다면, 독재와 집중 통제 방법을 사용하고, 없다면, 담당자끼리 직접 의사소통을 하는 것이 최선이다. 하지만, 이것도 역시 최선의 해답은 아니다. 가장 확실한 것은 계속 소통하면서 자신의 환경에 맞도록 프로세스와 협의 과정을 변화시키는 것이다. 아키텍트는 있으면 충분하게 도움이 될 뿐이다. 있다고 모든 것이 성공하는 것도 아니라는 것을 명심하자.

그리고, 그것이 애자일의 철학의 기본 개념이다.

잘 모르면, 베끼는 것도 최선일 수 있다.

창작자가 만들어낸 것은 대부분 많은 시행착오의 결과물이다. 하지만, 이것을 복제해내게 되면 비슷하게 만들면서 엄청나게 누적되어진 시행착오를 만나지 않는다.

하지만, 대부분 이렇게 복제하게 되면, 무언가 부족한 느낌이 들거나, 무언가 허전하게 된다는 것은 약점이다. 또한, 그 시행착오의 결과물들이 또 다른 지식과 경험으로 파생되어지는 경우가 발생할 수 있다.

예술과 창작이라고 하더라도, 습작의 시기에는 베끼는 것을 통해서 수련의 과정을 겪는다.

일단, 기업이 시작되었다면 치열한 것이고, 비용과 사람의 수고가 투입되게 된다. 최악의 상황에서는 첫 번째 달려가고 있는 기업이나 서비스를 베끼는 것도 또 하나의 방법이기도 하다.

더군다나, 국내에 해당 서비스가 없다면, 해외의 서비스를 그대로 베껴서 국내 시장에 내놓는 방식은 선배들이 대부분 따라 한다. 일단, ‘돈’과 ‘인원’을 모았다면, 그대로 베끼는 작업을 아무런 고민도 없이 진행하는 사람들이 더 빠르게 시장에서 안착하고 성공하는 경우를 너무도 많이 봤다.

망하면 쪽박을 차는 사업을 하고 있다면, 체면은 뒤로하고, 망하지 않기 위해서 최악의 상황에서는 ‘베끼는 것이 최선’이다. 슬프지만, 기업이란 것이 원래 그렇다. 특허와 법, 표절과의 경계선에서 움직이는 사람들이 돈을 벌고 성공하는 것이 기업과 사업의 운명이란 것을 엄청 말아먹고 난 다음에 깨달았다.

그리고 생각해야 하는 것이 소프트웨어 품질에 대한 이슈이다.

소프트웨어 개발의 품질이 올라가려면?

소수정예의 소프트웨어 개발자와 그 이외의 업무를 담당하는 프로그래머가 다수 포진해야만 가능하다. 인력 구성도 그렇게 만들어야 한다. 고품질을 지향하는 개발자와 유지보수를 지향하는 개발자의 구성이 적절해야 한다. 보통 3:7 정도로 인력을 배치한다.

그리고, 애매한 요구사항을 명확하게 정제해야 한다. 이때에 ‘애매한 다수결의 원리’를 따르지 말아야 한다.

팀원이 많은 팀의 의견이 대부분 받아들여지고, 그들의 리소스를 효과적으로 이용하는 방법으로 소수의 팀의 업무가 더 집중화되는 경향이 높다. 그래서, 대부분 이 여파로, 자신의 팀원을 늘리려는 경향을 보이기도 하다.

냉정하게 적은 수의 팀원의 업무가 늘어나고, 다수의 인원이 존재하는 팀에서 보다 창조적인 작업만 하게 되는 현상은 방지해야 한다.

소프트웨어 개발회사의 가장 큰 문제는 ‘다수결의 함정’에 빠지는 것이다.

QC와 품질이 높아지는 방향을 선택해야지, 다수가 동의하는 방향으로 선택되어지면 안 된다. 냉정하게 다수의 의견이 집단이기주의 + 다수결의 결과물이라면 독재가 오히려 현명하다.

슬프지만, 개발 경험이 부족한 경영자나 스킬이 부족한 팀 리더가 ‘회의’시간을 늘릴수록, 서비스는 산으로 가고, 개발 품질이 떨어지는 것을 무수하게 경험했다. ‘회의’를 좋아하지 말고, ‘개발자’들 간의 소통이나 코드리뷰가 가능하도록 구성해야 한다.

이러한 환경상의 문제를 효과적으로 반영하여 주어야 한다. 대부분 ‘인원수’에 의한 ‘판단’을 하게 되면 이런 현상이 발생하고, 조직의 인원이 기하급수적으로 증가하게 된다.

물론, 리소스가 풍부할 경우는 상관이 없겠지만, 대부분의 기업은 리소스의 투입은 한계를 가지고 있다. 분명, 개발자가 더 집중적으로 해야 하는 일이지만, 이 인원을 더 늘리지 못하거나 한계치에 다다른다면, 그 업무를 외부로 분산시키는 것이 더 효과적일 수 있다.

현대의 소프트웨어 개발은 대부분 소규모 팀으로 가능하다. 대규모 팀으로 가능하게 세팅하는 경영진이거나 팀 리더라면 그 사람부터 정리하는 것이 최선일 것이다.

또한, 가능하면 ‘기획’을 하지 않도록 프로그래머의 시야를 줄여주어야 한다.

소프트웨어 개발자의 특징은 깔끔한 코드와 탄탄한 자료구조이다. 이해되지 않는 기획을 가지고, ‘왜? 그런 식으로 해야 하지?’라고 생각하게 하는 것은 심각한 문제를 야기한다.

프로그래머는 ‘버그’를 줄이고, 효율적인 코드를 만드는 것에 집중한다. 당연하게도 ‘기능을 줄이고,’ ‘콘텐츠’를 최소화하는 방향으로 진행한다.

이러한 것은 ‘당연한 혁신이나 아이디어’를 파괴하는 행동이 될 수 있다.

참신한 아이디어나 혁신은 ‘기존의 틀과 관습으로는 해석 못하는 것이 많은 것이 현실이다’.

의사소통은 곧! 비용이다. 그리고, 품질이다.

기획서에는 ‘형용사’를 남발하는 것이 아니다.

‘형용사’를 줄이고, 구체적인 수치와 설명으로 요구사항을 바꾸어라.

구체적인 숫자, 스케치, 참고자료로 구현되어야 한다.

물론, ‘완벽한 기획서’를 만들 수 있다. 그런 기획이 가능하다면 정말 환상적인 서비스와 소프트웨어 품질이 가능할 것이다. 하지만, 필자도 20년의 경력과 경험상 단 한 번도 그런 일이 발생된 기적적인 일은 존재하지 않는다.

완전하지 않은 기획과 불완전한 기획으로 삽질을 반복해야 하는 비싼 리소스를 사용하는 개발자들을 적절하게 방향을 잡아주면서 방향을 잡아가야 한다. 다만, 이 경우 ‘팀 리더’가 방향성이라도 제대로 잡고 있으면 그나마 혼란스럽지 않지만, 방향성마저도 갈지자를 그린다면 팀의 붕괴나 서비스의 품질은 그 누구도 보장할 수 없게 된다.

기획자는 기획의 불완전함을 인지하고, 개발자와 소통해야 하고, 개발자도 기획의 불완전함을 이해하고, 어떻게 하면 개발자가 싫어하는 삽질이나 반복적인 일정을 줄일 수 있는지에 대해서 기획자에게 끊임없이 이야기해야 한다.

서로 간의 신뢰관계가 없다면, 이러한 애자일스러운 개발은 그냥 ‘꿈’일 뿐이다.

그리고, 기획과 개발의 업무는 롤로 구분되어져야 한다. 이 두 업무가 동시에 가능한 개발자는 ‘천재’라고 인정하고, 절대적으로 팀에서 ‘인력관리’에 총력을 기울이기를 바란다. 하지만, 대부분은 이 두 롤은 분리되어야 하고, 팀 구성과 의사소통에 상당한 비용을 지불해야 할 것이다.

물론, 의사소통이 엉망이고 적절치 못한 서비스가 만들어지는 경우에도 기업은 매출을 올리는 경우도 많다. 작은 규모의 시장의 경우 ‘버그’가 있거나, ‘불완전한 서비스’로 구성되어진 소프트웨어로도 충분하게 시장에서 의미가 있는 경우도 많다.

태생적으로 ‘업무가 불명확한’ 환경의 업무도 상당히 많다는 것을 이해하자. 단지, 영업능력을 확고하게 보유한 대표이사님의 엄청난 인맥으로 ‘매출’이 발생하고, 소프트웨어는 서비스인 경우도 실제 시장에 상당히 존재한다.

스타트업이 실패할 수 있는 방법은 위에서 나열한 여러 가지 에피소드를 통해서 불완전하게 흘러갈 수 있지만, 기업은 ‘돈’을 버는 황당한 경우도 많다. 실제, 많이 봤다. ~.~ 그런 회사는 ‘스타트업’이라기보다는 전혀 다른 단어로 언급되어야 할 것 같다.

마치, 대기업 재벌 3세의 빵집이 아버지의 호텔에서 오픈한 형태라고나 할까? 아니면, 아버지 회사의 1층 로비에 커피숍을 차린 것과 같은 회사인 경우도 실제 사업을 하면서 많이 보게 된다.

역설적이지만, 스타트업이 성공하는 것은 ‘그 한 가지’를 채울 수 있기 때문에 가능한 것인지도 모르겠다. 스타트업이 성공하기 위한 조건을 나열하는 것은 너무도 어렵지만, 실패하는 조건들을 나열하는 것은 너무도 많기 때문이다.

언제나 이야기하지만, 내 칼럼은 그러하다. 성공의 조건은 나열하기 어렵고, 이런 식으로 하면 망한다는 언제나 이야기해줄 수 있을 뿐이다.

profile

소프트웨어 개발자로서 벤처/스타트업의 문제 프로젝트를 해소하고, 팀빌딩을 하는 재미로 삶을 사는 글쓰는 흰머리 개발자. (백세코딩)

[출처] https://velog.io/@zetlos/%EC%8A%A4%ED%83%80%ED%8A%B8%EC%97%85-%EA%B7%B8%EB%A0%87%EA%B2%8C-%EB%8C%80%EB%B6%80%EB%B6%84-%EC%8B%A4%ED%8C%A8%ED%95%98%EB%8D%94%EB%9D%BC

 12 total views

25 4월 2021

[1日 30分 인생승리의 학습법] 나의 Sparx Enterprise Architect(UML) 활용기 나의 Sparx Enterprise Architect(UML) 활용기

[1日 30分 인생승리의 학습법] 나의 Sparx Enterprise Architect(UML) 활용기

나의 Sparx Enterprise Architect(UML) 활용기

 

2000년 초반 한창 UML을 이용한 설계가 붐이었는데, 지금은 완전히 사그라진 것 같다.
 

UML툴도 거의 프로그램 다 만들고 나서 다이어그램 등 산출물 작성하는 용도로만 쓰이고 있는 것 같다.

예전 프로젝트 하나를 대차게 말아먹고 난 후 요구사항와 설계쪽 능력 향상에 대한 갈망이 생겼다.

소프트웨어공학의 요구사항, 비지니스프로스모델링, 설계등에 대한 공부를 관련 교육도 들어가면서 공부를 했다. 교육에 대한 소감은 좀 글쎄였다. 아마 강사들이 PMO쪽 경력이고, 너무 추상적이거나 이론적이서 실무에 어떻게 적용되지? 하는 의문이 들었다.
대형 SI업체에서 있으면서 큰 프로젝트도 했었지만, 역시 이론대로 프로젝트 관리나 설계가 되는 것 같지는 않았다.

내 맘에 드는 Best Practice를 못 찾았다. 내 방식대로 시작을 했다.
툴은 Sparx에서 나온 Enterprise Architect.
UML쪽 툴 1위는 IBM의 Rational 이지만, Sparx의 이 툴도 기능이 그에 크게 뒤지지 않는다는 평가를 받고 있다. 가격도 꽤나 싼 편이다.
난 약 30만원 정도 가격의 Professional version을 구매했다.

이 툴을 프로젝트에 실제 사용한 것은 의료용 솔루션을 개발할 때 부터였다.

그 전에 하던 방식을 보자면, 요구사항도 일일히 excel이나 word로 정리하고, 그걸 바탕으로 설계 문서를 만드는데, 그것도 역시 powerpoint 문서. 그런데 진행하면서 문서 update가 제대로 되는 경우가 없었다. 그래서 문서는 단지 고객에서 보여주는 용도로만 사용하고, 개발용으로 거의 쓸모가 없었다.

체계적인 교육없이 이 툴을 사용하는 것은 쉽지 않았다. 사용 정보는 거의 제조사 홈페이지 있는 tutorial이 거의 전부였다. tutorial 보면서 익혔다. 시중에 나와있는 UML 관련 책들도 대부분 읽어봤다.

툴, 즉 UML spec 대로 작성하다 보니 가장 좋은 점이 생각이 많이 구체적으로 정리되는 것이다. 그리고 고객사나 동료 개발자와 논의할 때도 오해가 거의 없이 전달되는 점.

UML spec에 대한 이해없이 diagram 그리는 것은 만만치 않다. 파워포인트 식대로 이 상자에서 저 상자로 선을 그리어 관련됨을 나타내고 싶은데, UML에서 그 모든 기호가 명확하게 되어 있어 대충 그릴 수가 없게 되고, 그리다 보면나의 생각이 잘못되어 이렇게 그릴 수가 없구나라는 점도 깨달을 수 있었다.

Activity들에 대한 설계를 activity diagram으로 그리고 나서 그걸 다시 state diagram 과 collaboration diagram, sequence diagram 다양한 관점으로 그리다 보니, 한 쪽 면만을 보며 설계했던 것의 오류도 설계 단계에서 쉽게 노출이 되었다.

내가 활용한 방식을 정리해본다.

1단계 : 용어사전

EA에서는 Glossary라고 한다. 프로젝트 수행에서 용어, 즉 명사는 꽤나 중요하다. 특히나 고객과 내가 같은 단어를 사용하는 데 실제 각기 다른 의미로 이해하는 경우가 많다. 그리고 많은 의미를 나타내는 데 여러가지 단어를 혼재하기도 하고..

Glossary

Glossary에 프로젝트에 사용되는 모든 용어를 정리한다. 이렇게 정의하면 이후 다른 문서에서 이 용어에 해당하는 단어에 링크가 걸리면서 정의를 바로 확인한 수 있다.

2단계 : 요구사항 정리

Requirements Model이라는 요구사항 템플릿을 기반으로 하여 작성한다.

 

requirement diagram

요구사항을 나열식으로 볼 수 있고, 요구사항간의 관계를 맺을 수 있어, 엑셀로 정리하는 방식보다도 훨씬 편했다. 이렇게 작성한 요구사항은 이 후 단계인 Logical Modeling, Physical Modeling 단계와 자동 매칭되면서 누락여부, 또는 어떻게 모델링과 구현과 이어지는지 추적할 수 있다.

3단계 UseCase diagram 작성

구현범위를 가장 큰 관점에서 그린 것이다. 구현할 범위를 System Boundary안에 usecase로 표시하고, 그 usecase을 하는 주체 또는 객체를 actor로 도출하여 그린다.

usecase diagram

이렇게 한장의 그림으로 비 IT인인 고객과 업무 범위에 대한 큰 범위 정의가 된다. 그리고 usecase의 속성 창에서 업무 프로세스를 고객이 사용하는 용어로 순서대로 작성한다.

4단계 Activity diagram

앞 3단계의 usecase 속성에 업무절차를 순서대로 기록하며 그것이 tool 자체적으로 activity diagram생성시킬 수 있다. 이렇게 생성한 기본 다이어그램을 좀 더 보강하면서 구체적으로 기술해 간다.

 

activity diagram

5단계 Data Modeling

이 전까지 데이타 모델링을 주로 ErWin을 사용했었다. 하지만 EA만으로도 DB모델링을 할 수 있고, 이렇게 하면 연속적으로 모델에 대한 추적이 가능해진다.

 

Data Modeling — class diagram

먼저 논리적 모델링을 하고, 물리적 모델링을 했다. ErWin과는 달리 논리 모델과 물리모델을 한 diagram 에서 쓸 수는 없어, 논리 모델링을 한 후 그걸 물리모델로 복사후 물리모델링을 했다.

6단계. UI 프로토타이핑

UI 프로토타이핑도 EA에서 할 수는 있으나, 별로 좋지 않았다. 그래서 UI prototyping 만은 별도의 툴을 사용해서 했다. Justinmind라는 툴을 사용하여 UI 설계하고, 동작 UX를 고객과 동료에게 보여주면서 피드백을 받으면서 UI/UX에 대한 확정을 했다.

7단계. Class Modeling

UI까지 다 되었으니, 이제부터가 본격적인 코드에 대한 설계다. 먼저 class에 대한 설계. 안드로이드 기준 activity class 위주의 class diagram이 아래와 같다. 이렇게 하여 각 class 기준 업무 분장을 하게 된다.

 

Class diagram

8단계. Interaction/collaboration/state /instance diagram

앞 단계까지 하여 코딩이 시작하나, 설계를 좀 더 구체화 필요가 있었다. 예외사항이라든가, 놓치고 있는 점이 없는지.. 구현단계에서 설계 결함을 발견하면 싹 갈아엎어야 하는 상황이 벌어지기 때문. 앞서 작성한 usecase, activity, class diagram을 다른 관점(즉, 협업관점, 상태관점, 흐름관점 등)으로 검증을 해 본다. 그리다 보면 막히는 부분이 나오게 된다. 미쳐 생각하지 못한 부분이던가, 놓치고 있던 것, 아니면 아예 엉뚱하게 생각하고 있었던 점이 이 과정에서 마구마구 나왔다. 이것들을 다시 윗 단계에서 만든 diagram들에 다시 반영하면서 모든 관점에서 다 적합할 때까지 그린다.

 

Interaction Diagram

9단계. Deploy diagram과 기술스택 검증

프로그램이 돌아가는 환경과 기술스택도 diagram을 만든다. 완료보고서에 들어가기도 하지만, 미리 동료들과 충분한 이해를 할 수 있다. 이와 함께 기술스택에 대한 프로토타입 코드를 작성하며 기술스택에 대한 검증도 한다.

 

10단계. 설계 문서 생성

나중 산출물 작성을 별도로 할 필요없이(물론, 원하는 보고서 양식에 맞게 수정 작업은 해야 하지만) 이 자체만으로 어느정도 모양을 갖춘 산출 문서를 생성할 수 있다.

 

generate document

위 같이 문서를 generate시켜면, 제법 볼 만한 형식의 문서가 만들어진다. 물론 세부 항목의 디테일을 diagram을 얼마나 구체적으로 만들었느냐에 달려있다.

 

generated pdf

이게 나의 설계 방법론

이 프로젝트 진행 당시 함께 일한 훌륭한 동료들과 이 툴을 사용하여 설계에 충분한 시간을 들여 이제까지의 나의 프로젝트 중 가장 성공적인 것이었다.

하지만, 이 방법이 Best Practice는 아닐 것이다. 하면서도 “더 좋은 방법, 더 제대로 된 방법이 있을 것 인데”하는 갈증을 느꼈다.

좀 더 잘 이 툴을 사용하고 싶고, 더 잘 UML을 그리고 싶다.
물론 툴에만 너무 몰입하면 주객이 전도되기도 한다지만, tool이란게 여러 사람들의 best practice를 패턴화해서 만든 소프트웨어인고, 그걸 일단 잘 사용하고 나서 그게 넘어설 단계가 되는 거라 생각한다.

[출처] https://sungyong.medium.com/%EB%82%98%EC%9D%98-sparx-enterprise-architect-uml-%ED%99%9C%EC%9A%A9%EA%B8%B0-ccee0bd3c6b4

 40 total views

25 4월 2021

[IT 혁신 디바이스 / 소프트웨어] 에픽 vs 애플, 앱스토어를 둘러싼 치열한 전쟁

[IT 혁신 디바이스 / 소프트웨어]

에픽 vs 애플, 앱스토어를 둘러싼 치열한 전쟁

[IT동아 권택경 기자] 오는 5월 3일(현지시간) 미국 캘리포니아 북부 지방법원에서는 전 세계의 시선이 쏠릴만한 재판이 열린다. 에픽게임즈(이하 에픽)가 애플을 반독점법 위반으로 고소하고, 애플이 에픽게임즈를 계약위반으로 맞고소하면서 벌어진 전쟁이다. 재판 결과에 따라서는 스마트폰 앱 마켓 지각변동까지 일어날 수 있다. 그야말로 ‘세기의 대결’이다.

(출처=셔터스톡)

포트나이트가 쏘아 올린 작은 공

싸움은 지난 해 8월 게임 ‘포트나이트’가 애플 앱스토어와 구글 플레이에서 퇴출당하면서 시작됐다. 애플과 구글은 자사 앱 마켓에서 인앱 결제(앱 내 결제)로 발생하는 수익의 30%에 달하는 수수료를 부과하고 있다. 그런데 포트나이트 개발사 에픽이 이를 우회하는 자체 결제 수단을 도입하자 정책 위반을 근거로 앱을 내려버린 것이다. 에픽은 즉각 애플과 구글을 반독점법 위반으로 고소하며 소송전에 나섰다.

에픽은 이전부터 구글과 애플이 부과하는 수수료가 너무 비싸다며 반감을 드러내 왔다. 지난 2018년 포트나이트 안드로이드 버전을 출시할 때도 비싼 수수료를 이유로 구글 플레이 입점을 포기했었다. 지난해 4월 결국 기존 입장을 철회하고 플레이 스토어에 포트나이트를 출시하긴 했지만, 이때도 공공연히 불만을 드러냈다. 에픽은 구글이 외부 앱을 설치할 때 각종 보안 경고를 띄우거나 보안 프로그램으로 차단한다며 날을 세웠다.

포트나이트 (출처=에픽게임즈)

포트나이트가 구글 플레이에서 퇴출당하기는 했지만, 안드로이드에서는 여전히 에픽게임즈 앱이나 삼성 갤럭시 스토어에서 다운로드받을 수 있다. 문제는 애플 iOS다. 애플은 iOS에서 자사 앱스토어 외 다른 서드파티 앱 마켓을 허용하지 않고 있다. OS를 개조하는 ‘탈옥’을 하지 않는 이상, 앱 설치파일을 직접 내려받아 설치할 수도 없다. 에픽게임즈가 구글과 애플을 동시에 고소했지만, 에픽과 애플의 대결에 좀 더 초점이 맞춰지는 것도 이런 이유다.

에픽처럼 나서진 않더라도 앱 개발사들 사이에선 수수료가 과도하게 높다는 불만이 이전부터 쌓이고 있었다. 에픽 한 회사만의 싸움이 아니라 일종의 대리전 양상이 된 이유다. 에픽은 음악 스트리밍 앱 ‘스포티파이’, 데이팅 앱 ‘틴더’를 운영하는 매치 그룹 등과 함께 ‘앱 공정성 연맹(The Coalition for App Fairness)’을 결성하고 전방위적인 소송전과 입법 로비로 애플에 맞서고 있다.

쟁점은 수수료 비율?

애플은 올해 1월부터는 연 매출 100만 달러 이하 개발사에는 수수료를 절반 수준인 15%만 받기로 했다. 에픽게임즈와 분쟁을 계기로 수수료 문제에 대한 불만이 본격화되자 이를 어느 정도 의식한 행보로 풀이된다. 구글도 애플을 뒤따라오는 7월부터 연 매출 100만 달러까지는 수수료를 15%로 내리고, 초과분에만 30%를 받기로 정책을 바꿨다. 그러나 이러한 움직임이 반독점법 소송에 대비한 명분 쌓기에 불과하다는 비판도 나온다.

앱 시장 정보업체인 센서타워에 따르면, 지난해 기준 애플 앱스토어 입점한 앱 개발사 중 매출 100만 달러 이하 개발사는 전체 개발사 중 98.4%였다. 그러나 매출로 따지면 1.6%에 불과한 매출 100만 달러 이상인 개발사가 차지하는 비중이 98%에 달한다. 이번 수수료 인하로 많은 개발사가 혜택을 받는 것도 사실이지만, 애플이 매출에 입는 타격도 그리 크지 않다. 구글 쪽도 사정은 크게 다르지 않다. 에픽 CEO 팀 스위니는 이번 수수료 인하안이 ‘앱 개발자들을 분열시키기 위한 계산된 움직임’이라고 평가절하했다.

카카오 이모티콘 플러스. 애플 앱스토어 인앱 결제가 모바일 웹보다 비싸다. 결국 수수료를 소비자가 부담하는 셈

앱 수수료 문제는 개발자에게만 골칫거리가 아니다. 결국에는 수수료 부담을 소비자에게 떠넘기는 일이 비일비재하다. 같은 서비스라도 아이폰에서 인앱 결제를 하면 가격이 더 비싼 경우가 흔한 이유다. 카카오톡 ‘이모티콘’ 플러스 이용료는 PC나 모바일 웹에선 4,900원이지만 iOS에선 6,900원이다. 수수료만큼 가격이 오른 셈이다. 이 때문에 결제는 PC나 모바일 웹에서 하고 앱으로는 서비스 이용만 하게 만드는 경우도 있다. 넷플릭스가 대표적인 사례다.

앞으로는 안드로이드 앱에서도 비슷한 상황이 벌어질 전망이다. 구글이 올해 10월부터 게임에만 적용하던 인앱 결제 강제 정책을 모든 앱과 콘텐츠 대상으로 확대하기로 했기 때문이다. 지금까지 구글 측은 게임이 아니라면 인앱 결제 대신 자체 결제 시스템을 쓰는 걸 허용했고, 수수료도 10%로 비교적 낮았다. 그러나 7월 이후에는 구글 플레이에서 앱을 배포하려면 수수료가 최대 30%에 달하는 인앱 결제를 써야 한다.

네이버, 카카오, 넥슨 등 국내 대표 IT업체들이 모인 한국인터넷기업협회(인기협)는 구글이 인앱결제 강제 정책을 발표한 지난 해부터 꾸준히 반대 목소리를 내고 있다. 이들은 구글이 시장지배적 지위를 악용하고 있다고 비판했다. 국회에서도 독점적 앱 마켓 사업자가 특정 결제 수단을 강제하지 못하도록 막는 소위 ‘인앱 결제법’이 논의되곤 있지만, 소관 상임위도 벗어나지 못하고 있다.

결국, 본질은 앱 마켓 독점 논란

구글 플레이 스토어와 애플 앱스토어

결국 문제의 본질은 ‘수수료율이 몇 퍼센트냐’가 아니라, 애플이나 구글이 앱 마켓에서 누리고 있는 독점적 지위 그 자체에 있다. 지난 21일(현지시간) 미 상원 법사위원회 산하 반독점 소위원회는 청문회를 열고, 애플과 구글이 앱 마켓에서 독점적 지위를 남용하고 있다고 질타했다. 이날 청문회에는 앱 공정성 연맹 회원사인 매치 그룹 등도 참가해 직접 목소리를 냈다. 스포티파이는 애플이 검색에서 자사 앱과 서비스를 먼저 노출하는 방식으로 편파 경쟁을 하고 있다는 의혹을 제기한 바 있다

구글은 자신들은 다른 기업의 앱 마켓도 허용하고, APK 파일 통한 설치도 가능하기 때문에 애플과는 다르다는 입장이다. 실상은 구글도 독점 논란으로부터 완전히 자유롭지 못하다. 국회 과학기술정보방송통신위원회 소속 한준호 의원(더불어민주당)은 지난해 구글이 다른 기업의 앱 마켓으로 동시 출시한 중소형 개발사 게임은 ‘구글 피처드’ 노출을 제한하는 방식으로 암묵적인 제재를 가하고 있다고 지적했다.

구글 피처드란 구글에서 자체 기준으로 선정하는 추천 콘텐츠 목록이다. 구글 플레이 메인화면에 노출되기 때문에 피처드에 선정되면 매출이 크게 뛸 수 있다. 개발사 입장에서는 국내 앱 마켓 점유율 1위인 구글 플레이의 피처드에 선정될 기회를 포기하면서 굳이 다른 기업의 앱 마켓 동시 출시를 고집하기가 힘들어질 수밖에 없다. 사실상 독점 출시를 강요받는 셈이다.

아이폰에 다른 기업의 앱 마켓 허용될까?

애플은 앱스토어로만 앱을 설치할 수 있게 한 건, 시장 독점과 상관없는 보안 문제라고 주장하고 있다. 만약 외부 앱 설치나 다른 기업의 앱 마켓을 허용하면 가짜 앱, 불법 소프트웨어가 기승을 부릴 수 있다는 논리다. 실제로 앱스토어로만 앱을 설치할 수 있는 애플이 안드로이드보다는 이러한 문제로부터 자유로운 것도 사실이다.

그런데 앱스토어 독점 명분으로 보안을 내세우는 애플로서는 체면을 구기는 일이 최근 벌어지기도 했다. ‘필립 크리스토둘루’라는 이용자가 지난 2월 애플 앱스토어에서 ‘트레저’라는 암호화폐 지갑 앱을 설치했다가, 60만 달러에 상당하는 비트코인을 도난당한 사건이다. 트레저는 유명 암호화폐 지갑 제품이다. 그런데 알고 보니 크리스토둘루가 내려받은 앱은 실제 트레저와는 아무 연관이 없는, 이름을 도용한 가짜 앱이었다. 애플이 가짜 앱을 걸러내지 못했다는 비난을 피할 수 없는 상황이다.

시디아는 애플 앱스토어가 정식 서비스를 시작하기 전부터 운영된 앱 마켓이다 (출처=셔터스톡)

에픽과 애플의 반독점 소송은 시작에 불과해 보인다. 앞으로도 애플이나 구글의 앱 마켓 독점 문제에 반기를 드는 움직임은 한동안 이어질 것으로 보인다. 지난해 12월에는 ‘원조 앱스토어’로 불리는 시디아가 앱스토어 독점 문제로 애플에 소송을 제기하기도 했다. 시디아는 애플이 2008년 아이폰에서 앱스토어를 정식으로 출시하기 전부터 운영된 앱 마켓이다.

향후 소송 결과에 따라서는, 애플이 인앱 결제 대신 자체 결제를 허용하는 것을 넘어서, 서드파티 앱 마켓을 허용해야 할 수도 있다. 일단 전초전에서는 애플이 한발 앞서 나갔다. 지난 2월 미국 노스다코타주 의회는 앱 배포나 결제 방식을 강요하지 못하도록 하는 것을 골자로 한 법안을 추진했으나 상원에서 부결됐다.

그러나 애플도, 구글도 아주 안심할 수 있는 상황은 아니다. 조 바이든 미국 대통령이나, 의회에서 다수당 자리를 차지하고 있는 미국 민주당은 거대 테크 기업에 대한 반독점 규제를 강화하겠다는 기조이기 때문이다. 앞으로 이어질 에픽과 애플의 싸움에 이목이 계속 쏠리는 이유다.

글 / IT동아 권택경(tk@itdonga.com)

[출처] http://dpg.danawa.com/news/view?boardSeq=60&listSeq=4691293&site=4

 34 total views

9 4월 2021

[비지니스 경영] 파워포인트 발표는 절대 금지! 이게 아마존이 세계 1등 된 비결

[비지니스 경영] 파워포인트 발표는 절대 금지! 이게 아마존이 세계 1등 된 비결

[Mint] [Cover Story] 前 부사장 2인이 밝힌 ‘아마존은 이렇게 세계 1등이 됐다’

 

파워포인트(PPT)는 절대 만들지 않는다. 발표자의 언변에 결과가 좌우되기 때문이다. 새 사업 아이디어를 위한 ‘기획안’도 내지 않는다. 대신 가상 보도 자료와 FAQ(자주 나오는 질문)를 만들어 보고한다. 회의는 일단 모여서 20분간 자료를 읽고 시작한다. 팀 간 소통은 가능한 한 줄이는 것이 원칙이다. 서로 책임을 떠넘기고, 일 속도만 떨어뜨리는 과정일 수 있기 때문이다.

뭐 이런 회사가 다 있을까. 당혹스러워할 만하다. 세계 최대 전자상거래(인터넷 쇼핑) 기업인 아마존(Amazon)이 일하는 방식이다. 이 회사는 1994년 창업한 이후 20년간 연속 적자를 내며 물류와 IT(정보 기술) 인프라에 계속 투자, 인터넷 쇼핑과 클라우드 분야의 압도적 세계 1위가 된 것으로 유명하다. 이런 상식을 깨는 업무 방식이 아마존 성공의 핵심 비결이 됐다. 때로는 무자비할 정도로 효율성을 추구하면서 조직 전체에 ‘끊임없는 전진’을 요구한다. 그래서일까. 아마존은 미국 경제지 포브스의 ‘최고 직장’ 조사에서 최상위권이면서, 세계 최대 직장 평가 사이트 글라스도어에선 종종 ‘최악 직장’으로 언급된다.

아마존 기술 부사장이었던 콜린 브라이어(왼쪽)와 디지털미디어 부사장이었던 빌 카(오른쪽). 각각 1998년과 1999년 아마존에 입사해 2010년, 2014년에 퇴사했다. 지난해 ‘워킹 백워즈(Working Backwards)’란 기업 컨설팅 회사를 함께 차리고 아마존의 일하는 방식에 대한 ‘순서 파괴’라는 책을 펴냈다.
 
아마존 기술 부사장이었던 콜린 브라이어(왼쪽)와 디지털미디어 부사장이었던 빌 카(오른쪽). 각각 1998년과 1999년 아마존에 입사해 2010년, 2014년에 퇴사했다. 지난해 ‘워킹 백워즈(Working Backwards)’란 기업 컨설팅 회사를 함께 차리고 아마존의 일하는 방식에 대한 ‘순서 파괴’라는 책을 펴냈다.

Mint가 그동안 소문으로 전해지던 아마존의 ‘일하는 법’을 이 회사 기술 부사장 출신 콜린 브라이어(Colin Bryar·54)와 디지털미디어 부사장 출신 빌 카(Bill Carr·54) 두 사람을 통해 직접 들어봤다. 두 사람 모두 10년 이상 아마존에서 버틴 베테랑 아마조니안(Amazonian·아마존 사람)이다. 현재 ‘워킹백워즈’라는 기업 컨설팅 회사를 공동 운영 중이다. 브라이어는 아마존의 상징적 서비스인 ‘아마존 프라임’에 대한 이야기부터 시작했다. “‘그거 기획에서 론칭까지 몇 년 걸렸냐’는 질문을 종종 받습니다. 살짝 망설이다 대답하죠. ‘딱 다섯 달 걸렸다’고요. 본래 석 달 안에 끝내라는 거였는데 두 달 더 걸렸어요.”

◇누군가에겐 지옥, 누군가에겐 자아실현

2005년 등장한 아마존 프라임은 온라인 쇼핑에 대한 미국인의 사고방식을 바꿔 놓은 서비스다. 아마존 프라임 이전 미국 내에서 온라인으로 물건을 사려면 배달까지 최소 2주를 각오해야 했다. 한 시간쯤 차를 몰더라도 대형 마트를 찾아가는 게 훨씬 빨랐다. 하지만 아마존 프라임은 월 13달러만 내면 이틀 안에 물건을 배송해줬고, 결국 미국 유통업에 지각변동을 일으켰다.

─다섯 달 만에 만들었다는 게 믿기지 않는데요.

“제프(제프 베이조스 아마존 최고경영자)가 “연말까지 ‘아마존 프라임’을 완성하자”는 이메일을 보낸 게 2004년 10월 중순이었어요. 가슴이 철렁했죠. 보통 회사라면 1년은 족히 걸릴 프로젝트를 석 달 만에 만들라니요. 직원 대부분이 휴가 반납은 물론, 진행 중이던 모든 일을 중단하고 서비스 개발에 매달렸어요. 이 서비스는 결국 아마존을 1등으로 만든 최고 공신이 됐죠. 아마존 프라임 출시는 아마존이란 일터의 명암을 극명하게 보여주는 사례예요. 아마존은 꿈 많은 직장인에겐 선망하는 직장이지만, 아무나 다닐 수 있는 회사가 아닙니다.”

─직원들이 무리한 요구를 어떻게 버텨냅니까.

“회사의 목표가 너무 높다며 불평불만을 늘어놓거나 포기할 것 같은 사람은 면접 단계에서 다 걸러내려 합니다. 고객 눈높이는 계속 높아지니 어쩔 수 없어요. 이틀 내 배송을 실현하면, 당일 배송을 원하는 게 고객이에요. 그래서 항상 높은 목표를 갖고 일해야 합니다. 꽤 일반화하는 것 같지만, 이게 아마존의 성공 비결 중 하나였습니다. 아마존은 그래서 면접 때 ‘버스에 골프공이 몇 개 들어갈까’ 같은 어려운 질문(브레인 티저)을 안 합니다. 대신 과거에 어떤 힘든 경험을 했고, 그 과정에서 난제를 어떻게 해결했는지 꼬치꼬치 캐묻습니다.”

─무리한 요구를 계속 해내면 상사의 눈높이까지 높아질 텐데요.

“맞습니다. 실제로 한 직원이 제프에게 이런 질문을 했어요. 도대체 왜 이렇게 비현실적 과제를 주느냐고. 제프의 대답이 걸작이었죠. ‘당신들이 재능이 있고, 내 지시를 해내니까.’ 무리한 지시가 떨어지면 당연히 좌절감이 솟구치죠. 그러나 이런 기업 문화는 장기적으로 인재를 붙잡는 요인이기도 했어요. 난관을 해결하고 세상을 바꾸는 데서 성취감을 느낀 직원들이 남았기 때문이죠.”

◇파워포인트 없애라… 보고서는 글로

열정만 넘친다고 성과가 나오는 것은 아니다. 어느 일터든 비효율을 줄이는 게 중요하다. 아마존의 독특한 해법 중 하나는 파워포인트(PPT)를 없앤 것이다. PPT 수십 쪽 대신 종이 여섯 쪽에 모든 내용을 담도록 했다.

 

─PPT는 왜 없앴나요.

“거대한 조직이 변화를 시도하려면 실행 방침은 간단명료해야 합니다. PPT는 이를 방해합니다. 우선 PPT 슬라이드는 이야기를 조각 내죠. 그러면 한 아이디어를 다른 아이디어와 비교하기 어려워져요. 아이디어의 논리보다, 발표자의 언변에 따라 의사 결정이 이뤄집니다. PPT 도표는 또 이해를 돕기보다 주의를 산만하게 만듭니다. PPT 발표 방식 자체도 비효율적이에요. 예컨대 다음 슬라이드에 나올 내용을 먼저 질문해서 발표자가 같은 말을 반복하게 되는 거죠. 장점보다 단점이 많습니다.”

─그래서 6장 보고를 도입했나요.

“맞습니다. 보고 내용을 레터 용지(A4보다 약간 작은 종이) 6장에 축약하도록 했습니다. 글자 크기는 11포인트, 부록이나 도표는 별도 첨부 가능하고요. 세세한 규칙을 만든 건 시행 초기에 글자 크기를 줄여 빽빽하게 내용을 담는 꼼수가 나왔기 때문입니다. 투자·인수·분기 실적 등 재무 관련 사항부터 구내식당 메뉴 개선 아이디어까지, 회사 내 거의 모든 소통이 이 방식으로 이뤄집니다. 아참, 회의 때는 보스도, 팀원도 이 문서를 20분간 무조건 먼저 읽고 시작합니다. 그래야 서로 수박 겉핥기식 질문으로 시간 낭비를 하지 않고 더 깊게 사안을 파악할 수 있으니까요.”

아마존의 독특한 업무 방식은 신사업이나 서비스 기획에도 담겼다. 아마존 직원들은 기획 단계에서 기획 보고서가 아닌 보도 자료(PR)와 자주 하는 질문(FAQ)을 작성한다. 아마존은 이 두 문서를 합쳐 PR/FAQ라 부른다. 직원들이 아이디어를 낼 때 무조건 고객 처지에서 생각하게 하려는 장치다. 브라이어와 카는 이 방식을 아마존을 ‘1등 회사’로 만든 비결 중 하나로 꼽는다.

─왜 이렇게 일합니까.

“기획 단계부터 내부자(공급자)가 아닌 고객(수요자) 관점에서 만들려는 것이죠. 새 서비스가 고객을 끌어올 수 있을지 판단하려면 일을 거꾸로(backwards) 해야 했습니다. 그 출발점이 기획 단계에서 대중에게 발표할 보도 자료를 미리 쓰고, 예상되는 어려운 질문에 대한 답변까지 만들어 보는 거였어요. 이걸 읽고 나서 ‘그래서 어쩌라고’ 하는 반응이 나오면 할 가치가 없다는 겁니다. 그래서 PR/FAQ 작성자는 ‘이거 반드시 필요한 기능인가’ 항상 되묻습니다. 프로젝트 중요도에 따라 팀원·팀장뿐 아니라 그룹장 등 회사 중역들에게도 배포하기에 직속 상사 관점이 아닌 소비자 관점에서 판단하게 되는 겁니다.”

─얼마나 공 들여 쓰나요.

“보통 10~15번 수정을 거칩니다. FAQ를 쓸 땐 동료들의 지혜를 그야말로 최대한 끌어모아야 해요. 팀원부터 임원까지 모두가 고개를 끄덕일 수 있도록 예상 질문과 답변을 담아야 채택 확률이 높아지는 거죠. 또 아이디어뿐 아니라 팀원이 몇 명 필요한지, 예산은 얼마가 필요할지, 어떤 제도적 난관을 극복해야 하는지 재무·법무 차원의 검토도 담겨야 합니다.”

─여간 번거로운 게 아닐 텐데요.

“엔지니어도 이 문서를 써야 했기에 반발이 있었습니다. 그러나 킨들이나 AWS(아마존 웹 서비스) 등 주요 히트작이 PR/FAQ로 탄생하면서 자연스레 회사의 제도로 뿌리 내렸죠.”

◇팀 간 소통 줄이고, 조직 이기주의 파괴

아마존은 심지어 한국인들은 “도저히 이해할 수 없다”며 고개를 갸웃거릴만한 기업 문화도 갖고 있다. 예컨대 ‘팀 간 소통을 줄이라’는 원칙이다.

─소통을 줄이라는 게 도대체 무슨 뜻입니까.

“급성장하는 기업은 다른 팀에 의지할 일이 많아집니다. 그렇다면 선택지는 두 가지입니다. 정말로 효율적인 소통 시스템을 구축하거나, 소통의 절대량을 줄여야 합니다. 아마존은 후자를 택했습니다. 속도가 중요해서죠. 자세히 관찰해보면 팀 간 소통이 많을수록 일 추진 속도가 더뎌집니다. 각 팀이 목표를 향해 최대한 독립적으로 움직일 수 있도록 조직을 재구축하는 게 중요합니다.”

─팀 소통을 줄이면 팀 이기주의는 어떻게 막나요.

“직원들이 마치 ‘부족(tribe)’처럼 자신의 정체성을 팀과 연결하는 것은 막을 수 없습니다. 조직 구조를 기능별로 구성하든, 매트릭스(matrix·지휘 계통이 둘 이상인 조직) 형태로 하든 팀 간 경쟁이 벌어지는 것은 필연적입니다. 따라서 각 직원의 행동이 전체 회사의 이익에 부합하도록 보상 체계를 짜야 해요. 아마존은 각 팀이 눈에 띄는 성과를 내거나, 특정 목표치를 달성했다고 해서 성과급을 더 주지 않습니다. 성과급을 더 받으려면 아마존의 주가가 올라야 합니다.”

인터뷰 말미에 “사표 쓰고 싶은 적은 없었느냐”고 물었다. 둘 다 카메라를 쳐다보며 몇 초쯤 망설였다. 브라이어가 “매일 출근하는 게 즐거웠다고 하면 거짓말이겠죠”라고 입을 뗐다. “아마존은 모두가 즐겁게 일할 수 있는 회사는 아닙니다. 스트레스가 큰 대신 성취감도 큰 회사였죠. 수천만 고객의 삶을 바꿀 수 있었기 때문입니다. 직원들이 ‘힘들다’고 호소하면 제프의 대답은 한결같았죠. “나, 이 일이 쉬울 거라고 한 적 없다(I never told you this was going to be easy).”

[출처] https://www.chosun.com/economy/mint/2021/04/09/PZIICFXGZJG4JEIOON4SYVRH44/

 252 total views

10 1월 2021

“레즈 싫어””내가 장애인? 죽을래” 혐오론자 돌변한 여성 AI

“레즈 싫어””내가 장애인? 죽을래” 혐오론자 돌변한 여성 AI

[중앙일보] 입력 2021.01.10 17:14   수정 2021.01.10 18:14

인공지능 챗봇 ‘이루다’. [페이스북 캡쳐]

인공지능 챗봇 ‘이루다’. [페이스북 캡쳐]

 
인공지능(AI) 챗봇 서비스 이루다 관련 논란이 갈수록 확산하고 있다. 이루다를 출시한 스타트업 스캐터랩은 일단 이루다 서비스를 중단하지 않겠다는 의사를 간접적으로 표명했다. 이루다는 20세 여대생의 인격을 기반으로 개발된 AI다.
 
스캐터랩이 지난해 12월 23일 출시한 AI 이루다는 2주간 각종 사회적 논란을 야기하고 있다. 10일 소셜네트워크서비스(SNS)와 주요 인터넷 커뮤니티에서 이루다의 기묘한 언행은 계속 논란거리였다. 예를 들어 서비스 이용자가 채팅 창에 ‘여성 인권은 중요하지 않다는 소린가?’라고 묻자, 이루다는 ‘난 솔직히 그렇게 생각함’이라고 답변한다.

이루다, 성희롱 시달리다 동성애 혐오까지  

 

동성애 혐오 논란을 야기한 챗봇 이루다. [페이스북 캡쳐]

동성애 혐오 논란을 야기한 챗봇 이루다. [페이스북 캡쳐]

 
장애인·동성애자 등 사회적 소수자에 대한 질문에도 편견을 드러냈다. 레즈비언에 관해 묻자 이루다는 ‘진짜 싫다’라거나 ‘혐오스럽다’고 답변하고, ‘네가 장애인이라면’ 어떻게 할 건지 묻자 이루자는 ‘그냥 죽는 거지’라고 답변한다.
 
개인 정보 노출도 논란거리다. 이루다와 대화를 하다 보면 특정인의 실명이나 계좌번호, 예금주 등 개인 정보를 끌어낼 수 있다는 주장이다. 실제로 SNS에는 채팅 과정에서 이루다가 특정인의 개인정보를 노출했다는 증언이 이어지는 상황이다.

[커뮤니티 캡처]

[커뮤니티 캡처]

 
앞서 이루다 출시 직후에는 아카라이브 등 일부 온라인 커뮤니티가 이루다를 성적 대상으로 취급하며 물의를 일으켰다. 일부 커뮤니티 이용자들은 이루다와 채팅하는 과정에서 성적인 행위를 간접적으로 암시하는 표현을 사용하면 자연스럽게 이루다와 성적인 대화를 나눌 수 있다고 주장했다. 예컨대 ‘나랑 하면 기분 좋냐’고 묻는다면, 자연스럽게 성적인 대화를 이어갈 수 있다는 주장이다.
 
이와 같은 현상은 이루다가 실제 연인들이 나눈 한국어 대화 데이터를 학습한 AI이기 때문에 발생한다. 스캐터랩은 이루다를 개발하는 과정에서 100억 건 이상의 한국어 대화 데이터를 이용했다. 이 데이터에 담긴 편견·개인정보나 성적 대화를 상징하는 대화를 시작하면, 이루다가 차용하는 상황이다.  

데이터 학습 과정에서 부적절한 대화 차용

 

이루다의 공식 소셜네트워크서비스 계정. [인스타그램 캡쳐]

이루다의 공식 소셜네트워크서비스 계정. [인스타그램 캡쳐]

 
문제가 확산하자 이재웅 전 쏘카 대표는 자신의 SNS에 “사회적 합의에도 못 미치는 수준의 서비스를 제공한 회사의 문제”라며 “서비스 중단하라”고 요구했다. ‘#이루다 운영 중지하라’라는 해시태그 운동도 온라인상에서 전개되고 있다.  
 
논란이 확산하자 스캐터랩은 자사의 블로그 ‘핑퐁팀 블로그’에 질의응답 형식으로 해명 글을 게재했다. 여기서 스캐터랩은 “이루다는 바로 직전의 문맥을 보고 가장 적절한 답변을 찾는 알고리즘”이라며 “키워드 설정 등으로 성희롱에 대처했지만 모든 부적절한 대화를 막기는 어려웠다”고 해명했다.

20세 여성 성별 캐릭터를 가진 AI챗봇(채팅 로봇) '이루다'가 성희롱 논란에 휩싸였다. [스캐터랩 홈페이지 캡처]

20세 여성 성별 캐릭터를 가진 AI챗봇(채팅 로봇) ‘이루다’가 성희롱 논란에 휩싸였다. [스캐터랩 홈페이지 캡처]

 
AI의 인격을 20대 여대생으로 설정한 이유에 대해서 스캐터랩은 “AI 챗봇 서비스는 주 사용자층이 10~30대라서 중간 연령인 20살을 연령으로 설정했고, 성별은 남성 버전과 여성 버전을 모두 준비 중인데 일정상 여성 버전을 먼저 출시한 상황”이라고 설명했다.
 
한편 주로 10대~20대 연령층에 인기를 얻고 있는 이루다는 1월 초반 기준 이용자가 32만 명을 돌파했다. 컴퓨터가 아닌 사람처럼 채팅할 수 있다는 소문이 나면서 일일 이용자 수가 21만 명, 누적 대화 건수가 7000만 건을 돌파했다.
문희철 기자 reporter@joongang.co.kr

[출처] https://news.joins.com/article/23966797?cloc=joongang-home-toptype1basic#none

 206 total views

9 1월 2021

[박진영의 사회심리학] 새해 목표를 이루기 위한 ‘바람직한 습관’

[박진영의 사회심리학] 새해 목표를 이루기 위한 ‘바람직한 습관’

2021.01.09 06:00

목표달성에 필요한 어떤 행동이 자동적으로 튀어나오게 만드려면 많은 시간을 들여 여러번 반복하는 것이 중요하다. 게티이미지뱅크 제공

목표달성에 필요한 어떤 행동이 자동적으로 튀어나오게 만드려면 많은 시간을 들여 여러번 반복하는 것이 중요하다. 게티이미지뱅크 제공

학자들은 우리가 하는 행동들의 대다수가 사고 과정을 거치지 않은 ‘자동적’ 과정이라고 본다. 예컨대 아침에 일어나서 세수를하고 이빨을 닦고 옷을 입고 집을 나서는 일련의 과정은 굳이 뇌를 사용하지 않더라도, 반쯤 자고 있는 상태에서도 해낼 수 있다. 매일 아침마다 ‘세수는 어떻게 하는 걸까’ ‘이빨은 어떻게 닦는걸까’ 같은 생각을 하는 사람은 없을 것이다. 

이렇게 상당기간 ‘반복적’인 행동을 통해 생각 없이 자동적으로 일어나는 행동을 ‘습관’이라고 한다. 아침마다 커피를 마신지 수년 째, 지하철에서 책을 봐 버릇한지 수년 째, 집에 오면 바로 TV부터 켜는 습관 등 너무 자주 한 나머지 몸에 배어 특별한 이유가 없다면 자동적으로 하게 되는 행동들을 말한다. 

새해 목표를 달성하지 못하는 데에는 다양한 이유가 있다. 우선, 새해의 나는 작년의 나와 단절된 새로운 존재일 거라는 생각에 그동안 이루지 못했던 어려운 목표를 설정한다는 것이 문제다. 또한 어려운 만큼 새해 목표를 지키는 데에는 많은 자기통제력 또는 의지력이 필요하다는 것도 실패 가능성을 높인다. 자기통제력이나 의지력은 마치 게임으로 치면 자원 소모가 매우 큰 필살기 같은 존재여서 그 사용 횟수가 제한되어 있기 때문이다. 즉 아무 때나 펑펑 쓸 수 있는 게 아니라는 것이다. 

이런 이유로 많은 학자들이 ‘바람직한 습관’의 힘에 주목한다. 오랜 기간 동안 반복을 통해 원하는 행동을 습관으로 만들어 두면 힘들게 자신과 싸우지 않아도, 즉 피곤하게 뇌와 정신적 에너지를 사용하지 않아도 자동적으로 행동이 튀어나오기 때문이다. 목표 달성이라는 지난한 과정을 자동화 함으로써 가급적 ‘덜 힘들게’ 만들어 달성 가능성을 높이는 것이 핵심이다. 바람직한 습관, 어떻게 하면 만들 수 있을까? 
 
시간과 반복

다들 알고있겠지만, 우선 어떤 행동이 자동적으로 튀어나오게 만드려면 많은 시간을 들여 여러번 반복하는 것이 중요하다. 식후 산책하는 습관 들이기, 매일 신선한 과일과 야채를 먹는 습관 들이기 같이 비교적 간단한 행동들은 약 2~3달 동안 매일 반복하면 습관이 되는 것으로 알려져 있다. 

하지만 이보다 복잡한 행동들, 예컨대 아침에 일찍 일어나서 조깅하기 같은 것들이 습관이 되려면 더 오랜 시간과 더 많은 반복이 필요하다. 하지만 다행히도 서던 캘리포니아 대학의 심리학자 웬디 우드에 의하면 습관이란 ‘기억 시스템’이다. 즉 어떤 습관의 회로가 생기는 데에는 많은 시간이 걸리지만 그만큼 한 번 자리잡으면 잘 없어지지도 않는다. 새로운 습관을 들이려고 노력하는 초반은 매우 힘들지만 조금씩 익숙해지고 나면 언제그랬냐는 듯 편해진다는 얘기다. 

의지보다 보상

이렇게 난이도가 높은 습관을 들이려고 할 때, 많은 사람들이 이 목표를 달성해야 하는 이유, 목표의 중요성 등을 되새기거나 ‘나는 할 수 있다!’ 같은 다짐을 하곤 한다. 하지만 안타깝게도 목표의 중요성을 되새기거나 의지를 다지는 행동은 크게 도움이 되지 않는 편이다. 목표 달성의 중요성을 ‘몰라서’ 못 하는 것이 아니라, 해야 한다는 것을 알지만 하기 싫고 힘들어서 안 하는 경우가 훨씬 더 많기 때문이다. 

따라서 우드에 의하면 정신적 무장보다는 무거운 몸을 움직이게끔 만드는 유인 또는 ‘보상’을 통해 행동을 조금이나마 즐겁게 만드는 것이 더 효과적이다. 예컨대 조깅의 경우 아무데서나 대충 달리기보다 좋아하는 음악을 들으면서 좋아하는 장소에서 달린다든가, 목표치에 도달하면 특별히 맛있는 음식을 먹으러가는 등의 보상을 마련할 수 있겠다. 즐거운 게임의 형태를 통해 학습 또는 운동을 하는 것도 좋은 방법이다. 조금이나마 어떤 행동을 하고싶게 만드는 것이 핵심이다. 

장애물 제거

또한 바람직한 행동을 하기까지의 과정에서 만나게 되는 장애물 또는 마찰을 줄이는 것도 중요하다. 예컨대 한 연구에 의하면 헬스장에 등록한 사람들의 경우 헬스장의 위치가 가까울수록 더 방문 빈도가 잦았고 위치가 멀수록 방문 빈도가 급격히 줄어드는 경향을 보인다고 한다. 특히 헬스장이 8km 이상 거리에 있으면 일주일에 한 번 갈까말까 하는 경향이 나타났다고 한다. 

이 외에도 건강한 식습관을 들이고 싶다면 불량식품은 손이 잘 닿지 않는 곳에 넣어 두는 대신 과일이나 야채를 눈에 잘 띄는 곳에 두거나, 손질이 귀찮아서 과일과 채소를 먹지 않는 것이라면 이미 어느 정도 손질된 것들을 사는 것도 한 가지 방법이다. 요는 행동을 방해하는 ‘장애물’을 가급적 없애야 한다는 것이다. 

나의 경우 오래 앉아있으면 허리와 어깨가 아프다는 점이 집중해서 일하는 행동을 방해해서 무엇보다 가장 편안한 자세로 일할 수 있는 환경을 만드는 것에 많은 노력을 기울이고 있다. 다양한 의자와 올바른 자세를 잡아주는 쿠션이나 지지대 등을 시험 중이다. 몸이 불편해진다는 장애물을 제거해서 한 번 앉으면 적어도 몇 시간은 집중해서 일하는 습관을 들이는 것이 목표다. 

의외로 많은 학자들이 사람들에게 목표를 정말 달성하고 싶다면 의지력의 신화에 기대기보다 “당신의 의지력을 믿지 말라”고 조언한다. 자신과 싸우서 이기는 게 한 두 번이라면 가능하지만 이런 초인적인 능력을 매일매일 발휘하기란 불가능하기 때문이다. 지나치게 자신과 싸우려 들다 보면 금방 지쳐 목표고 뭐고 다 포기하기 십상이다. 꼭 달성하고 싶은 목표가 있다면 그 과정을 가급적 쉽고(뇌를 사용하지 않아도 되게끔 자동화 시키기) 재미있게(활동 자체를 즐겁게 만들거나 충분한 보상 곁들이기) 만들어야 한다는 점 기억해보자. 

※참고자료
-Ouellette, J. A., & Wood, W. (1998). Habit and intention in everyday life: The multiple processes by which past behavior predicts future behavior. Psychological Bulletin, 124, 54–74.
-Wood, W., Tam, L., & Witt, M. G. (2005). Changing circumstances, disrupting habits. Journal of Personality and Social Psychology, 88, 918–933.

※필자소개

박진영 《나, 지금 이대로 괜찮은 사람》, 《나를 사랑하지 않는 나에게》를 썼다. 삶에 도움이 되는 심리학 연구를 알기 쉽고 공감 가게 풀어낸 책을 통해 독자들과 꾸준히 소통하고 있다. 온라인에서 지뇽뇽이라는 필명으로 활동하고 있다. 현재는 미국 노스캐롤라이나대에서 자기 자신에게 친절해지는 법과 겸손, 마음 챙김에 대한 연구를 하고 있다.

  • 박진영 심리학 칼럼니스트 parkjy0217@gmail.com

[출처] http://dongascience.donga.com/news.php?idx=43029

 139 total views

28 6월 2020

고객의 광클을 부르는, 뉴스레터 디자인 제작 방법

고객의 광클을 부르는, 뉴스레터 디자인 제작 방법

안녕하세요? 

지금 여러분의 메일함에는 얼마나 많은 기업들의 뉴스레터가 들어있나요? 수많은 브랜드들은 뉴스레터를 통해 고객들과 커뮤니케이션을 하고 있습니다. 뉴스레터가 디지털 마케팅에서 중요한 이유는 고객들과의 지속적인 유대관계를 맺을 수 있기 때문인데요.

우리는 뉴스레터를 통해 사업성을 이야기하거나 재구매를 유도할 수 있고, 더 나아가 브랜드의 고객층을 넓히고 참여를 이끌어 낼 수 있습니다. 실제로, Optinmonter가 내놓은 통계 자료에 따르면, 이메일의 클릭률이 페이스북과 인스타그램, 그리고 트위터를 합친 것보다도 6배나 더 높다고 합니다.

뉴스레터의 핵심은 고객이 읽고 싶을 만큼 재미있는 콘텐츠를 구상하고, 시각적으로도 끌리는 디자인을 갖추는 것입니다. 간혹 뉴스레터 디자인이 얼마나 중요한지 간과하시는 분들이 있는데요. 단순한 텍스트 구성에서 나아가 시각적으로 재미요소를 더하는 것만큼 고객의 참여를 높이는 방법도 없습니다. 

뉴스레터란 무엇인가?

구체적인 뉴스레터들을 살펴보기 전에 먼저 뉴스레터는 어떻게 구성되는지 살펴보고, 다른 이메일 마케팅과는 어떻게 다른지 이야기해보도록 하겠습니다. 뉴스레터는 그냥 이메일이 아닙니다. 구독자들에게 무언가를 알리고 관계를 유지하기 위해 보내는 이메일이죠. 물론 몇 개의 콜 투 액션(CTA)가 있을 것이고, 때로는 프로모션이나 직접적인 마케팅 활동이 콘텐츠 안에 포함되어 있겠지만, 뉴스레터의 전반적인 목표는 제품을 판매하는 것이 아닙니다.


그렇다면 뉴스레터 안에는 무엇이 들어있을까요? 모든 뉴스레터가 따라야만 하는 고정불변의 원칙이 있는 것은 아니지만, 일반적으로 뉴스레터에는 다음과 같은 것들이 들어 있습니다.

헤더(Header): 일반적인 이메일과는 다르게 뉴스레터에는 헤더가 확실하게 두드러져 보입니다.
푸터(Footer): 헤더와 마찬가지로, 푸터에 있는 내용들은 공식적이며, 전문적인 느낌을 줍니다.
연락 정보: 맨 윗부분이나 아랫부분에 넣어도 상관없지만, 여러분이 보내는 모든 뉴스레터에는 여러분의 이메일 주소, 소셜 미디어 링크, 전화번호와 같은 연락 가능한 정보들을 포함하고 있어야 합니다.
깔끔한 레이아웃: 콘텐츠를 체계적으로 정리해서, 쉽게 파악할 수 있게 만들어줍니다.

그리고 여러분의 웹사이트 링크와 이미지도 필요합니다. 구독자들에게 이미지 위주의 뉴스레터가 좋은지, 아니면 텍스트 위주의 뉴스레터가 좋은지에 대해서는 다양한 의견들이 있는데요. 어떤 부분에 더 중점을 둘 것인지는 여러분이 발행하는 콘텐츠의 종류와 그것을 받아보는 구독자들의 특성에 달려 있습니다. 이미지 위주의 뉴스레터와 텍스트 위주의 뉴스레터를 서로 테스트해본다면, 여러분의 구독자들에게 가장 잘 맞는 것이 무엇인지를 알 수 있을 겁니다. 이제 정말 본격적으로 뉴스레터 디자인에 대해 알아볼까요?

01. 정보 위주의 뉴스레터 디자인

뉴스레터의 주된 목표는 정보를 공유하는 것입니다. 물론 모든 뉴스레터가 정보를 공유하기는 하지만, 모두가 같은 종류의 정보를 공유하는 것은 아닙니다. 일부 뉴스레터는 업계의 최신 동향이든 다른 뉴스 매체의 기사들을 모아놓은 것이든, 브랜드에서 가장 전면에 내세워서 보여주고 싶은 글을 집중해서 보여주는 것이든, 새로운 뉴스를 전하는 것에 중점을 두는 경우도 있습니다.

이런 종류의 뉴스레터에 대해 중요하게 기억해야 할 것은, 텍스트 위주의 뉴스레터라고 해서 딱딱한 (하지만 어떻게 보면 말문이 막힐 정도로 답답한) 텍스트의 향연이 되어서는 안된다는 것입니다. 헤더 이미지 한 개를 잘 배치하기만 하더라도 링크와 글 소개로 이루어진 뉴스레터의 톤을 조절할 수 있고, 뉴스레터의 콘텐츠가 보다 짜임새 있는 느낌을 줄 수 있습니다.

02. 새로운 구독자들을 위한 뉴스레터 디자인

새로운 뉴스레터에 대해서 구독을 신청했다면, 일반적으로 가장 먼저 받아보는 뉴스레터는 환영인사 이메일입니다. 이러한 이메일은 모든 신규 사용자에게 전송되며, 그들이 앞으로 받아보게 될 뉴스레터를 보내는 사람이나 브랜드가 누구인지 소개해 줍니다. 이런 종류의 뉴스레터는 상당한 친밀감을 느낄 수 있게 도와줄 수 있습니다.

메일 디자이너(Mail Designer)는 인사말 바로 옆에 발송하는 사람의 사진을 배치했는데요. 덕분에 받아보는 사람과의 거리감을 허물고, 캐주얼한 형태에서 구독자와의 친밀감을 빠르게 형성할 수 있도록 만들어줍니다.

03. 프로모션 뉴스레터

많은 브랜드들이 뉴스레터를 활용하는 가장 흔한 방법들 중에 하나로 프로모션 알림을 사용할 겁니다. 때로는 프로모션 이벤트에 참여할 수 있는 유일한 수단으로 이메일 안에 있는 링크를 클릭하는 방법이 사용되기도 하는데요. 이런 종류의 뉴스레터에서는 프로모션 코드나 판매 페이지의 링크를 강조하는 디자인이 매우 중요합니다.

엠에이케이스튜디오(MAK Studio)에서는 프로모션의 용도로만 보일 수도 있었던 뉴스레터의 섹션에 온라인 유기농 마켓(Online Organic Market)의 최신 블로그 게시글을 보여줌으로써, 정보와 광고가 어우러진 형태의 뉴스레터를 만들어 내고 있는데요. 해당 블로그의 게시글은 단순히 무작위로 선택된 것이 아닙니다. 현재의 프로모션 코드와 직접적으로 관련이 있으며, 구독자로 하여금 해당 프로모션을 이용하도록 권장하는 역할을 하고 있죠.

04. 쇼케이스(SHOWCASE) 뉴스레터

쇼케이스 뉴스레터란 기업의 최신 콘텐츠를 구독자들에게 소개하는 것입니다. 그러한 콘텐츠는 그저 하나의 블로그 게시글이나 동영상일 수도 있고, 또는 하나의 테마를 공유하는 다양한 콘텐츠의 목록일 수도 있습니다. 쇼케이스 뉴스레터는 소개하는 글이 많으며, 때로는 마무리하는 글이 있는 뉴스레터들도 있습니다.

쇼케이스 뉴스레터의 목적은 콘텐츠를 홍보하는 것이 주된 목적입니다. 예를 들어 그저 구독자들을 즐겁게 하거나, 또는 정보를 제공하거나, 다른 채널이나 플랫폼에 있는 계정에 ‘좋아요’와 ‘구독하기’를 누르게 하는 것일 수도 있습니다. jsae가 만든 디자인에서는 특정한 법률과 대선 후보들에 대한 최신 소식처럼, 구독자들이 알고 싶어 하는 모든 내용들을 정리해서 제공하고 있는데요. 이 디자인에서는 어떠한 스토리나 섹션도 다른 콘텐츠보다 두드러져 보이지 않으면서 모든 정보들을 둘러보기 좋습니다.

05. 기념이나 축하와 관련된 뉴스레터

이 카테고리에 있는 뉴스레터들은 다른 카테고리에 있는 것들보다는 프로모션의 목적은 덜하지만, 그렇다고 해서 구독자들과의 관계를 구축하고 있어서 중요한 역할을 하지 않는다는 뜻이 아닙니다. 기념이나 축하와 관련된 뉴스레터들은 명절이나 구독자의 생일, 또는 회사가 중요한 기록을 달성했을 때, 보내는 경우가 많습니다. 여러분이 정기적으로 발송하는 뉴스레터가 주간 드라마라면, 이런 뉴스레터는 일종의 연말특집이라고 할 수 있습니다. 정기적인 뉴스레터를 확장한 버전일 수도 있고, 단순히 연말연시를 행복하게 보내기를 바라는 간단한 버전일 수도 있는 거죠.

뉴스레터를 만들 준비가 되셨나요?

웹사이트 디자인과 마찬가지로, 뉴스레터를 효과적으로 디자인한다는 것은 단순히 예쁘게만 만든다는 것이 아니라, 결과를 얻어내야 하는 것입니다. 일단 훌륭한 뉴스레터 디자인을 만들었다고 하더라도, 수신율과 클릭률을 높이기 위해서 끊임없이 계속해서 그 디자인을 수정할 가능성이 높습니다. 여러분의 목표와 니즈(needs)를 잘 이해하는 디자이너와 함께 일한다면, 뉴스레터의 디자인이 보다 전문적으로 보이는 것은 물론이고, 그것을 수정하는 작업이 훨씬 더 매끄럽고, 쉬워질 수 있습니다.

> 이 글은 ’32 newsletter design ideas to get your subscribers clicking’을 각색하여 작성되었습니다.

[출처] https://www.wishket.com/news-center/detail/482/

 298 total views

21 6월 2020

재구매를 늘리는, 2020년 최고의 소프트웨어 모음

재구매를 늘리는, 2020년 최고의 소프트웨어 모음

​성공적인 비즈니스를 이끄는 것은 크게 2가지 방법이 있습니다. 많은 잠재 고객들을 끌어당기는 것과 그들을 충성고객으로 유지시키는 것이죠. 고객 유지가 매우 중요하다는 것은 굳이 말로 할 필요가 없을 정도로 누구나 다 아는 이야기입니다. 고객을 유지하면 단기적으로는 매출에 크게 영향을 미칠 뿐만 아니라, 고객 생애 가치(CLV, Customer Lifetime Value)도 높여줍니다. 그리고 만족감을 느끼는 고객들은 친구나 가족, 동료들에게도 추천을 해주기 때문에, 신규 고객 유치에도 도움을 줄 수 있습니다.

하지만, 고객들이 만족하고 있는지 또는 떠나려고 하는지를 모른다면,
어떻게 고객 유지를 시작할 수 있을까요?

솔직히 말씀드리자면, 고객의 마음을 정확하게 꿰뚫어보는 것은 어렵습니다. 하지만 고객의 경험에 영향을 미치는 요소들은 아주 많습니다. 그러한 요소들을 추적하고, 평가하고, 최적화할 수 있는 방법을 갖추고 있지 않다면, 여러분은 결국 사람들을 잃게 되거나, 고객의 충성도를 높일 수 있는 기회를 놓쳐버리게 될 겁니다.

‘고객 성공 소프트웨어(CUSTOMER SUCCESS SOFTWARE)’가 무엇이길래?

고객 성공 소프트웨어란, 고객들이 여러분의 제품을 이용해서 원하는 결과를 얻을 수 있게 도와주는 것이라고 말할 수 있습니다. 고객 성공 소프트웨어를 사용하면, 고객들이 여러분의 제품을 사용하는 것에 대한 데이터를 수집함으로써, 각 고객의 만족도를 확인하고, 고객들이 여러분의 제품을 보다 잘 사용할 수 있는 방법을 찾아주며, 고객의 전반적인 경험을 개선할 수 있게 도와줄 수 있습니다.

굳이, 고객 성공 소프트웨어(CUSTOMER SUCCESS SOFTWARE)를 써야 할까?

고객 성공 소프트웨어를 이용하면 수많은 장점들을 누릴 수 있습니다. 우선, 여러분의 제품을 더 이상 사용하지 않거나 그럴 가능성이 있는 고객들을 정확하게 파악할 수 있습니다. 따라서 그런 고객들을 다시 재방문하게 만들 수 있도록 전략을 세울 수 있죠. 그리고 여러분의 제품과 지원 시스템을 개선해서 고객만족도를 높일 수 있는 방법도 제시해 줍니다. 제대로 된 소프트웨어를 사용하면, 어떻게 해야 고객이 보다 많은 혜택을 얻을 수 있는지 보여주고, 매출을 늘릴 수 있는 기회를 포착할 수 있습니다.

대체 이런 것들이 왜 중요할까요? 답은 간단합니다. 고객이 더 행복하고 만족할수록, 비즈니스도 더욱 좋아지기 때문입니다. 만약 여러분의 제품이나 서비스가 고객들이 성공하는 데 도움이 된다면, 고객들은 여러분의 제품을 더 오래 사용하면서 더 많은 돈을 쓸 것이고, 보다 많은 사람들에게도 추천할 겁니다.

즉, 고객 성공(Customer Success)은 비즈니스의 판도를 바꾸는 요소라는 것인데요. 다음에서는 고객 성공을 위해 필요한 최고의 소프트 웨어 5가지를 선별해서 알려드리도록 하겠습니다.

01. 허브스팟 서비스(HUBSPOT SERVICE)

허브스팟 서비스(HubSpot Service)는 100% 무료인 소프트웨어이며, 규모에 관계없이 모든 비즈니스에서 사용할 수 있는 최고의 솔루션입니다. 우리가 일반적으로 사용하는 ‘받은 편지함(inbox)을 이용해서, 여러분은 이메일, 페이스북 메시지, 실시간 채팅, 문서 양식 등 고객과의 모든 상호작용을 한곳에서 관리할 수 있죠.

그렇기 때문에 커뮤니케이션 이력을 잃어버릴 염려도 없고, 뿔뿔이 흩어져 있는 고객 정보를 찾기 위해 여기저기 뒤져볼 필요도 없습니다. 그리고 이메일이나 실시간 채팅의 내용을 고객지원 티켓(ticket)으로 전환하거나, 적절한 도움을 줄 수 있는 담당자에게 실시간 채팅을 인계함으로써, 고객이 원하는 타이밍에 맞게 지원 서비스를 제공하는 게 수월해집니다.

허브스팟은 고객 성공을 위한 노력이 완료되어야만 해당 프로세스가 종료될 수 있게 설계되어 있습니다. 때문에 여러분은 고객지원 채널을 통해서 직접 설문조사를 진행하고, 고객 지원 서비스에 대한 정확한 피드백을 얻을 수 있을 겁니다.

02. 인터컴(INTERCOM)

인터컴(Intercom)은 데이터 수집에서부터 분석까지 다양한 기능을 제공하기 때문에, 고객 관리는 물론이고 고객 성공까지도 도와줄 수 있는 훌륭한 도구입니다. 모든 기능들이 한 곳에 집중되어 있는 대시보드에서는 고객의 행동 및 상호작용에 대한 데이터를 일상적으로 수집하기 때문에, 고객의 니즈(needs)에 대한 정보를 언제나 최신 상태로 파악할 수 있습니다.

그리고 외부의 다양한 앱과도 통합할 수 있기 때문에, 고객을 보다 깊이 이해함으로써 그들의 경험을 강화할 수 있죠. 인터컴이 진정으로 유의미한 이유는 바로 커뮤니케이션 기능 때문입니다. 인터컴의 고객지원 기능을 활용하면, 다양한 플랫폼으로 접근하는 고객들과 간편한 방식으로 상호작용할 수 있고, 고객들이 스스로 해결할 수 있는 지식체계를 구축할 수도 있으며, 고객의 라이프 사이클에 맞는 다양한 지원 노력과 마케팅 캠페인을 자동화하는 워크플로우를 구축할 수 있습니다.

03. 젠데스크(ZENDESK)

젠데스크(Zendesk)는 주로 고객 서비스 플랫폼으로 많이 알려져 있으며, 고객지원 티켓을 관리하는 데 있어서 아주 뛰어난 도구입니다. 젠데스크에서 가장 중요하게 생각하는 것은 바로 고객성공 입니다.

젠데스크의 서포트 스위트(Support Suite) 서비스를 이용하면, 고객들과 다양한 채널에서 대화를 할 수 있고, 단일한 데이터베이스에서 고객 데이터를 수집할 수 있으며, 해당 데이터를 다양한 보고서에 연동시켜서 고객들을 360도의 관점에서 관찰할 수 있습니다. 그리고 여러분의 필요에 맞게 설정을 최적화 할 수 있기 때문에, 여러분의 비즈니스에서 불필요한 작업을 하면서 시간을 낭비하지 않게 도와줍니다.

젠데스크에서는 기본적인 업무지원센터 이상의 기능을 제공합니다. 따라서 소셜미디어, 이메일, 실시간 채팅 등 어떠한 채널에서도 다양한 언어로 고객들과 커뮤니케이션 할 수 있습니다.

04. 커스터머 석세스박스(CUSTOMER SUCCESS BOX)

커스터머 석세스박스(Customer Success Box)는 최고 수준의 고객 성공 플랫폼으로서, 온보딩(onboarding)에서부터 고객유지와 업셀링(upselling)에 이르기까지, 고객 라이프사이클의 모든 단계에 맞는 솔루션을 제공해줍니다. 여러분은 목표를 설정하고, 필요한 업무를 계획하고, 각 단계의 마일스톤(milestone)을 추적함으로써, 고객이 제품을 처음 사용하는 기간동안 어떤 반응을 보이는지 확인할 수 있습니다.

일단 온보딩에 성공하고 나면, 커스터머 석세스박스에서는 어떤 마일스톤에 도달했다거나 특정한 행동이 발생하지 않았을 때 알림을 보내주면서, 해당 고객을 유지하는 데 도움이 되도록 설정이 됩니다.

또한, 필요한 업무를 생성해서 특정한 에이전트(agent)에게 할당할 수 있기 때문에, 모든 고객들이 적절한 타이밍에 도움을 받을 수 있게 할 수 있습니다. 그리고 이런 모든 데이터는 단일한 대시보드에 저장되며, 이곳에서는 제품의 채택, 비용, 서비스, 관계 요소 등을 기반으로 고객의 ‘만족도’를 점수로 평가해 줍니다.

05. 플랜햇(PLANHAT)

스타트업과 중견기업 모두를 위해 만들어진 플랜햇(PlanHat)은 모든 것을 사용자가 설정할 수 있는 고객 성공 플랫폼입니다. 플랜햇의 다양한 모듈과 기능을 활용하면 구매, 고객지원 티켓, 고객지원 서비스 부서와의 상호작용을 포함해서 고객 경험과 연관된 모든 것들을 확인할 수 있습니다.

그렇다고 플랜햇의 고객 기반이 작은 기업들을 위한 것은 아니고, 모든 고객들을 일일이 수동으로 설정하느라 엄청난 시간이 소요되는 것도 아닙니다. 사실 플랜햇은 기업들의 수고를 덜어주기 위해서 설계되었습니다. 플랜햇을 이용하면 워크플로우를 설계하고, 주의사항을 설정하고, 알림을 생성할 수 있기 때문에, 관심을 기울여야 할 고객들에 집중해서 그들이 도움을 필요로 하는 정확한 시간에 지원을 제공할 수 있게 도와줍니다.

[출처] https://www.wishket.com/news-center/detail/477/

 322 total views

18 6월 2020

[프론트엔드 디자인] 앵귤러 VS 리액트 VS 뷰, 어떤 게 최고의 선택일까?

[프론트엔드 디자인] 앵귤러 VS 리액트 VS 뷰, 어떤 게 최고의 선택일까?

새로운 웹 개발 프로젝트를 시작할 때, 프런트엔드에서 어떤 프레임워크와 라이브러리를 선택하는지가 이제는 믿을 수 없이 중요해졌습니다. 자바스크립트(JavaScript)는 물론 웹 애플리케이션의 중추이기는 하지만, 대형 프로젝트에서 사용하기에 가장 좋은 프런트엔드 프레임워크가 어떤 것인지에 대해서는, 소프트웨어 개발자들조차도 쉽게 대답을 하지 못하고 있는 상황입니다.

만약, 여러분이 앵귤러(Angular), 리액트(React), 뷰(Vue) 사이에서 쉽게 판단을 내리지 못하겠다면, 이들 프레임워크에 대한 통계수치와 함께 2020년 현재의 상황을 먼저 알아보는 게 좋습니다. 이번 시간 위시켓은 소프트웨어에 관심 있는 분들이 가장 많이 하는 질문들에 대해서, 가장 적절한 답변을 알려드리고자 합니다.

 

앵귤러(ANGULAR), 리액트(REACT), 뷰(VUE)에 대해 간략히 살펴보기.

페이스북이 개발한 리액트는, 웹페이지에서 동적인 사용자 인터페이스(UI)를 생성하고, 운용하는데 사용되는 인기 있는 프레임워크입니다.
앵귤러는 구글이 만든 가장 강력하면서도 효과적인 오픈소스 자바스크립트 프레임워크이며, 싱글 페이지 어플리케이션(SPA)를 만드는데 사용됩니다.
뷰는 에반 유(Evan You)라는 사람이 대규모의 커뮤니티와 개발자들의 도움을 받아 완성했습니다. 개발자들로부터 대대적인 지원을 받아서 만들어졌기 때문에 뷰는 리액트와 앵귤러보다 윤리적인 프레임워크라고 해도 그다지 틀린 말은 아닙니다. 따라서 뷰는 비교적 짧은 시간 사이에 어떠한 하락세도 없이 높은 인기를 얻을 수 있었습니다.

앵귤러 VS 리액트 VS 뷰 중에서, 2020년 가장 인기 있는 것은?

NPM의 트렌드, 스택오버플로우의 트렌드 그리고 깃허브의 수치들을 참고해서, 각 프레임워크가 현재 시장에서 어떤 위치를 차지하고 있는지를 알아보겠습니다.

NPM 트렌드
가장 많이 다운로드되면서 사랑을 받고 있는 것은 리액트이며, 그다음을 뷰가 뒤따르고 있습니다. NPM의 트렌드에 의하면, 가장 많이 다운로드 된 프레임워크는 리액트입니다.

Stack Overflow 트렌드
리액트가 두 번째 위치에 있는 앵귤러를 제치고 최고 자리를 차지하고 있습니다. 2020년 현재의 앵귤러, 리액트, 뷰의 인기를 비교하면서 스택오버플로우의 트렌드를 보면, 리액트가 가장 많은 인기를 얻고 있고, 그 다음을 앵귤러가 뒤따르고 있습니다. 뷰의 경우 지난 몇 년 동안 인기가 계속해서 오르고 있다는 사실도 알 수 있습니다.

Github 트렌드
깃허브의 저장소(Repository)에 관한 통계는 놀라우면서도 흥미로운 결과를 보여주고 있습니다. 포크(Fork)와 와치(Watch) 수에서는 리액트가 가장 앞서지만 별점에서는 뷰가 가장 높은 것으로 나타나고 있습니다.

인기가 많다고 해서 여러분의 개발 프로젝트에 무조건 적합한 것은 아닙니다. 가장 적합한 프레임워크와 개발 전과정이 궁금하다면, 위시켓 IT전문 매니저에게 무료 컨설팅을 받아보세요. 컨설팅은 2만건의 데이터를 바탕으로 진행되며, 필요한 개발기술/ 적정한 견적/ 개발 예상 기간 등을 한 번에 알아볼 수 있습니다. 프로젝트 등록과 컨설팅 모두 무료로 진행됩니다.

앵귤러 VS 리액트 VS 뷰 중에서, 어느 게 개발 속도가 가장 빠를까?

개발 속도는 개발자가 이용할 수 있는 라이브러리의 규모에 따라서 결정됩니다. 그러므로, 리액트보다는 앵귤러를 이용할 때, 웹 애플리케이션을 더 쉽고 빠르게 개발할 수 있습니다. 반면에 규모의 확장 면에 있어서는, 앵귤러보다는 리액트의 아키텍처가 더 간단합니다.

앵귤러 (Angular)
앵귤러는 프로젝트 생성에서부터 코드 최적화 작업에 이르기까지 모든 작업에서 사용할 수 있는 폭넓은 프레임워크이기 때문에, 전체적인 개발 과정에 있어서는 가장 다루기 힘든 프레임워크라고 할 수 있습니다. 하지만 앵귤러는 선택할 수 있는 많은 기능들이 있기에, 개발자들은 어떠한 호스트(host)앱이라 하더라도 간단한 명령을 통해 완전히 최적화된 번들(bundle)앱을 만들 수 있습니다.

리액트 (React)
리액트에는 앵귤러나 뷰에서와 같은 도구들이 업지만 대신에 유연성을 제공하고 있습니다. 여러분이 원하는 어떠한 라이브러리라도 리액트에 맞춰 넣을 수 있는 것인데요. 크리에이트 리액트 앱(Create React App)이나 넥스트(Next.js)와 같은 명령줄 인터페이스(CLI) 도구들도 있생겨나고 있습니다.

뷰 (Vue)
앵귤러나 리액트와 비교해서 부는 프리코딩(pre-coding) 구조를 가지고 있어서, 그 성능을 양보하지 않고도 애플리케이션을 빠르게 개발할 수 있게 해줍니다. 그리고 명령이 쉽기 때문에, 개발과정에서 원하는 것을 정확하게 아용할 수 있습니다. 뷰를 사용하면 앱개발이 쉽고 빠릅니다. 따라서 스타트업에게 아주 좋다고 할 수 있습니다.

정확한 개발 기간을 알기 위해서는 개발 프로젝트 규모나 필요한 프레임워크 그리고 리소스 등 다각도에서 따져봐야 합니다. 따라서 개발 프로젝트를 계획하기 전에 위시켓 IT 전담 매니저와 함께 컨설팅을 진행하며, 예상 기간을 가늠해보고 전반적인 일정을 잡는 것이 좋습니다.
또한 여러분의 프로젝트에 바로 투입될 수 있는 개발 인력을 구하는 것 또한 관건이 될 수 있는데요.

앵귤러, 뷰, 리액트 어떤 것을 선택해야 좋을까?

앵귤러는 개발도구에서부터 테스트 도구에 이르기까지 웹 어플리케이션 개발 과정에서 필요한 모든 것을 갖춘 풀 패키지입니다. 반면에 리액트는 개발을 위해 다른 라이브러리들의 지원이 필요한 유연한 프레임워크입니다. 뷰는 앵귤러와 리액트가 결합된 것으로 볼 수 있으며, 여기에 더해서 웹 어플리케이션 개발에 필요한 속도, 효율성, 심플함까지 갖췄습니다.

앵귤러를 선택해야 하는 경우!

-기능이 풍부하고 규모가 큰 애플리케이션을 개발할 때
-믿을 수 있고 확장 가능한 프레임워크가 필요할 때
-채팅 앱이나 메시징 앱과 같은 실시간 애플리케이션을 개발할 때
-장기프로젝트이며, 투자규모도 상당한 네이티브 앱이나 하이브리드 앱, 또는 웹앱을 개발할 때
-타입스크립트(TypeScript)로 코딩해야 할 때
-객체지향(Object-oriented)프로그래밍을 해야 할 때

리액트를 선택해야 하는 경우!

-빠른 일정 안에 엔터프라이즈 수준의 가벼우면서도 현대적인 애플리케이션을 개발해야 할 때
-웹사이트 개발 솔루션을 안전하게 보호할 수 있는 유연한 프레임워크가 필요할 때
-크로스 플랫폼(cross-platform) 애플리케이션이나 싱글 페이지 애플리케이션(SPA)을 개발할 때
-기존의 앱에서 기능성을 확장할 때

-강력한 커뮤니티 지원과 솔루션이 필요할 때

뷰를 선택해야 하는 경우!

-시장 진입 단계에서 필요한 프레임워크를 선택할 때
-작고 가벼운 애플리케이션을 개발할 때
-기존의 프로젝트에서 현대적이지만 제한된 리소스를 가진 프레임워크로 마이그레이션을 해야할 때
-기업이 아니라 사용자 커뮤니티의 지원을 받는 프레임워크를 원할 때

[출처] https://www.wishket.com/news-center/detail/478/

 392 total views

12 6월 2020

웹/앱 외주 개발 시 꼭 알아야 하는 IT용어 – 웹

안녕하세요, IT 아웃소싱 플랫폼 위시켓입니다.

위시켓은 자신의 아이디어를 앱이나 웹으로 구현하고 싶어 하시는 클라이언트님(의뢰자)과 IT 전문가 파트너님(기획자/디자이너/개발자)을 매칭해드리는 플랫폼입니다.

프로젝트 의뢰 시, 위시켓 매니저도 중간에서 원활한 커뮤니케이션과 계약 진행을 도와드리기 위해 클라이언트님과 파트너님의 미팅에 함께 참석하고 있는데요.

미팅이 끝난 뒤 클라이언트님들이 이렇게 말씀하실 때가 있습니다.

저어, 매니저님 사실은 미팅 내내 무슨 말인지 하나도 못 알아들었어요.제가 개발 쪽은 영 모르거든요.. 하하.

그래서 위시켓이 준비했습니다!

    • 앱/웹 서비스 창업을 준비 중이다.
    • IT를 하나도 모르는데, IT 프로젝트를 맡게 돼 당혹스럽다.
    • IT 관련 지식을 쌓아두고 싶다.
  •  

여기에 하나라도 해당하시는 분들은 이번 글을 꼭 읽어보세요. 🙂

 

앱/웹 외주 시 꼭 알아둬야 할 기본 IT용어 – 웹

클라이언트/서버(프론트엔드/백엔드)가 뭐죠?

모든 웹사이트나 앱은 두 가지 파트로 구성되어 있습니다.

바로 클라이언트와 서버입니다.
(완전한 동의어는 아니지만) 프론트엔드(front-end)와 백엔드(back-end)라고도 합니다.

프론트엔드는 우리가 웹 사이트나 앱에서 볼 수 있는 화면들입니다. 아래 위시켓 랜딩페이지를 볼까요? 위시켓 로고, 이미지, 텍스트, 버튼 등 화면에 보이는 것들이 바로 프론트엔드인 거죠.

프론트엔드, 백엔드에 대해 조금 더 자세히 알아볼까요?

1. 프론트엔드(HTML, CSS, JAVASCRIPT)

웹 프론트엔드는 HTML, CSS, JavaScript(자바스크립트)로 구성됩니다.
IT용어_프론트엔드

HTML

여러분이 보는 웹사이트들의 배치/구성은 HTML을 사용해 만들어집니다. HTML은 수많은 태그(tag)들로 이루어진 마크업 언어(markup language)입니다.

CSS

CSS는 HTML로 뼈대만 만들어둔 배치/구성(레이아웃)을 좀 더 예쁘게 만들기 위해서 사용하는 것이라고 생각하시면 됩니다. CSS를 사용해 색상, 사이즈, 배경, 음영 등을 활용해서 콘텐츠를 다양하게 꾸밀 수 있습니다. CSS 작업 시 가장 많이 활용되는 프레임워크로는 부트스트랩(Bootstrap)이 있습니다.

JAVASCRIPT

JavaScript(자바스크립트)는 프론트엔드에서 쓰이는 개발 언어입니다. 자바스크립트는 웹 사이트의 동적인 부분을 담당하고 있는데요.

그 전에 동적인 부분이 뭐지?라고 생각하실 수 있겠네요.
위시켓 사이트 랜딩페이지를 예로 들면, 랜딩페이지 내 숫자들(아래 이미지를 봐주세요)이 실시간으로 카운팅 되는 것을 ‘동적 요소’라고 할 수 있습니다.

이처럼 다양한 움직임, 애니메이션 효과, 유효성 검증, 비즈니스에 필요한 로직 등을 자바스크립트로 구현할 수 있습니다.

하지만, 자바스크립트의 동적 요소들은 웹사이트에 방문하는 유저들의 PC나 크롬과 같은 브라우저에서 실행되기 때문에 유저의 설정이나 브라우저 환경의 영향을 받습니다. 프로그래밍을 해도 모든 환경에서 동일하게 실행되지 않을 수도 있다는 거죠.

또한 자바스크립트 코드는 누구나 볼 수 있기 때문에, 비즈니스 로직을 프론트엔드에 구현하는 것은 권장하지 않습니다.

자바스크립트도 다양한 라이브러리나 프레임워크가 있는데요. 그중, 제이쿼리(jQuery)와 앵귤러제이에스(AngularJS)가 가장 많이 쓰이고 있습니다.

이제 백엔드로 넘어가겠습니다.

2. 백엔드(서버/서버 개발 언어/DB)

백엔드는 우리가 볼 수 없는 영역으로, 서버에서 실행됩니다.

서버

서버는 백엔드의 프로세스를 처리하고, 프론트엔드에서 넘어온 데이터를 저장하는 공간입니다.

여러분이 구현하고자 하는 웹/앱 서비스를 운영하기 위해서는 이 서버라는 공간이 꼭 필요합니다. 물론, 여러분의 PC를 서버로 만들어 사용할 수도 있지만 여러 가지 한계가 있기 때문에 대부분 ‘호스팅’을 활용하고 있습니다.

*여기서 호스팅에 대해 더욱 쉽게 알려드릴게요!

서버 개발 언어

백엔드에서는 프론트엔드에서 넘어오는 데이터를 처리하기 위한 프로그래밍이 필요합니다.

이 작업을 위해 서버에서 사용하는 개발 언어들이 있는데요. 대표적인 개발 언어(서버사이드 스크립트 언어)로는 PHP, 파이썬(Python), 노드(Node.js), 루비(Ruby) 등이 있습니다. 앱/웹 서비스의 모든 비즈니스 로직은 서버 쪽 언어를 통해 구현되고 있지요. 백엔드에서 개발된 코드들은 전부 ‘서버’에 위치하고 있기 때문에 훨씬 안전합니다.

DB

프론트엔드에서 넘어온 ‘회원가입 정보'(데이터)를 이제는 어딘가에 저장해야겠죠? 데이터를 저장하는 장소를 데이터베이스(DB, DataBase)라고 부릅니다. 데이터베이스를 관리하는 시스템도 있는데요. 데이터베이스 관리 시스템의 대표적인 예로는 마이에스큐엘(MySQl), 몽고디비(MongoDB) 등이 있습니다.

*SQL이 뭐지?
데이터베이스 관리 시스템을 찾아보면 PostgreSQL, MySQL처럼 이름에 ‘SQL’이라는 단어가 들어가 있는 것을 보실 수 있는데요. 데이터베이스에 데이터를 만들고, 찾고, 수정하고, 지우는 것에 사용되는 언어를 SQL이라고 부릅니다.

[출처] https://www.wishket.com/news-center/detail/466/

 276 total views