22 9월 2022

[IT] 개발자에게 물어봤습니다: ① 함께 일하고 싶은 개발자

[IT] 개발자에게 물어봤습니다: ① 함께 일하고 싶은 개발자

우리가 알고 있는 대부분의 기업이나 서비스는 한 명의 힘으로 운영되지 않습니다. 스티브 잡스 하면 가장 먼저 떠오르는 애플의 아이폰조차 스티브 잡스 혼자만의 힘으로 만들어진 것이 아닙니다. 지금 이 시각에도 다양한 직무의 사람들이 서로 협력하며 서비스를 발전시켜나가고 있으며, 특히 IT 기업의 경우 PM(혹은 기획자), 디자이너, 그리고 개발자가 함께 일하는 경우가 많습니다. 그렇다면 각 직무의 인재들이 원활하게 협력하기 위해서는 어떠한 역량이 필요할까요?

이번 시리즈에서는 다양한 직무와 협업하는 IT 기업 직장인 중에서 개발자가 함께 일하고 싶어 하는 동료에 대해 다루고자 합니다. 오늘은 그중에서 개발자가 생각하는 ‘함께 일하고 싶은 개발자’에 대해 살펴볼 예정입니다. 여러 의견을 듣기 위해 2년 차 개발자부터 10년 차 개발자까지 총 8명의 개발자와 인터뷰를 진행해 보았습니다. 과연 개발자는 어떤 개발자와 함께 일하고 싶어 할까요?

개발자 질문
<출처: Unsplash>
 

개발자 사이의 협업

프로그래밍의 범위가 넓은 만큼, 개발자의 종류도 매우 다양합니다. 흔히 생각하는 웹이나 앱 분야의 개발자를 비롯해서 서버, 게임, 인프라, AI, 머신 러닝, 블록체인 등 다양한 분야의 개발자가 존재합니다. 그래서 개발자 간에 협업하는 상황도 각양각색인데, 대표적으로 서버 개발자가 작성한 API 코드를 앱이나 웹 개발자가 사용하는 경우가 있습니다. 예를 들어 회원가입 요청 코드를 서버 개발자가 완성하면, 웹 개발자가 이를 활용하여 아이디와 비밀번호 등을 받아서 회원가입 절차를 수행할 수 있도록 웹페이지를 구성하는 것입니다.

사실 다른 분야보다 같은 분야의 개발자 간에 협업하는 경우가 더 많습니다. 하나의 기능을 나눠서 작업하거나, 같은 코드 베이스 내에서 서로 다른 기능을 개발하는 것처럼 말이죠. 코드를 작성하는 것 외에 라이브러리와 아키텍처를 결정하거나 규칙(컨벤션)을 설정하는 과정에서도 개발자 사이에 협업이 활발하게 이루어집니다.

가령 자바스크립트 개발자 중에서 어떤 사람은 세미콜론(;)을 붙이는 것을 선호하고, 어떤 사람은 아예 붙이지 않는 것을 선호합니다. 몇몇 개발자는 ‘서로 다른 방식이 섞여 있으면 작업하기 어려우니 하나를 결정해서 컨벤션으로 정하자’고 하고, 또 다른 개발자는 ‘컨벤션을 정하고 지키는 것도 리소스가 소비되니 개인이 편한 방식으로 작성하자’고 합니다. 단순한 예시를 들었지만, 이처럼 개발자는 수많은 결정 사항과 작업에 대해 다른 개발자들과 소통하고 협업합니다.

협업이 잦은 만큼 ‘함께 일하고 싶은 개발자’가 되는 것은 매우 중요한데, 개발자 사이에 소통의 어려움이 발생하는 상황은 다음과 같습니다.

1) 잘 모르는데 아는 척 넘어가는 사람

“다양한 캐릭터의 개발자가 있는데 보통 커뮤니케이션이 원활하지 않을 때 함께 일하기 어려운 것 같아요. 커뮤니케이션이 어려운 상황에는 여러 가지가 있는데, 제가 가장 크리티컬 하다고 생각하는 것은 ‘잘 모르는 데 아는 척 넘어가는 것’이에요. 몰라도 아는 척 어물쩍 넘어가는 동료와는 일을 분배할 수 없겠다는 생각이 들더라고요. 그런 분을 믿고 일을 부탁하거나 그분의 작업을 믿기 어렵게 되는 것이죠.”

함께 일하는 데 있어서 신뢰는 매우 중요한 것 같습니다. 모르는데 아는 척 넘어가는 동료가 있으면 그의 솔직함과 역량에 대해 신뢰할 수 없게 되고, 한 번 신뢰가 깨지면 어떤 일이든 함께 하기 어려워지게 됩니다. 결국 그 순간의 부끄러움을 벗어나기 위해 아는 척을 하는 것이 자신의 성장과 자신에 대한 동료의 신뢰를 모두 저버리는 행동이 될 수 있습니다.

2) 동료와 프로덕트를 고려하지 않는 사람

“개발하는 것을 좋아하고 잘하시는 분과 함께하면 좋은 영향을 많이 받는 것 같아요. 그러나 개발에만 너무 집중해서 다른 동료들은 안중에 없거나 프로덕트의 성공과 멀어지는 개발을 하는 분이면 함께 일하고 싶지 않더라고요. 개발을 통해 고객 가치를 만드는 것을 중요시하는 분과 함께하고 싶어요.”

아무리 개발을 잘해도 그 방향이 동료와 프로덕트에 맞지 않으면 함께하고 싶지 않다는 의미입니다. 개인적으로 저 역시 개발은 좋은 가치를 만들기 위한 수단이라고 생각합니다. 수단을 잘 활용하는 것은 매우 중요한 역량이지만, 수단을 목적보다 중요시하면 안 된다고 생각합니다.

함께 일하고 싶은 개발자

그렇다면 개발자들이 함께 일하고 싶어 하는 개발자는 어떤 유형이 있을까요? 이 질문에 개발자들은 아래와 같이 답변했습니다.

함께 일하고 싶은 개발자
<출처: Unsplash>

1) 병목을 줄일 수 있는 사람

“우선 대부분 제품 조직의 아웃풋에서 가장 시간이 오래 걸리는 직무는 개발자라고 생각해요. 기능 요구사항을 가장 마지막에 전달받으면서도 기술 구현 과정에서 맞닥뜨리는 문제에 따라서 구현이나 설계가 달라질 수 있기 때문이에요. 또 개발자는 기술 구현 상황에 따라 기획이나 디자인 변경을 역으로 요청해야 할 때도 많은데요. 이렇게 변경이 필요한 사항을 최대한 이전 단계에서 알아보고 커뮤니케이션을 시작하는 것이 아웃풋을 극대화할 수 있는 부분인 것 같아요. 결국 전달받을 내용이 도달하기 전에 미리 할 수 있는 작업을 쪼개서 준비해두고, 기획과 디자인에 대해 빠르게 피드백하는 것이 개발자의 중요한 역량이라고 생각해요.”

대부분의 제품 조직에서는 기획자, 디자이너, 개발자 순서로 작업이 이루어집니다. 기획자가 기획 문서를 작성하면 디자이너가 디자인 파일을 만들고, 마지막으로 개발자가 기획 문서와 디자인 파일을 보고 구현하는 방식입니다. 결국 프로세스의 마지막에 위치한 개발자가 제품 개발 타임라인에서 중요한 위치를 차지하게 됩니다. 이때 프로세스의 이전 단계들이 끝나는 것만 기다리지 않고 미리 준비해서 커뮤니케이션하면 팀의 생산성을 높이는 개발자가 될 수 있을 것입니다.

2) 팀플레이가 가능한 사람

“팀플레이가 가능한 사람과 함께 일하고 싶어요. 할 줄 아는 게 개발이고 잘하는 게 개발이라서 그냥 관성적으로 개발하는 사람이 아니라, 같은 목표를 갖고 그 목표에 공감하고 같이 즐기면서 성장하는 사람이면 좋을 것 같아요.”

결국 핵심은 함께한다는 사실입니다. 개발을 좋아하고 잘하는 것도 물론 중요하지만, 함께 소통하고 성장하며 공동의 목표를 위해 나아가는 사람이 팀에게 있어서 필요한 개발자라고 생각합니다.

3) 함께 성장하기 위해 노력하는 사람

“개발자라면 대부분 개인의 성장은 신경 쓴다고 생각해요. 그러나 팀과 팀원 모두의 성장까지 신경 쓰는 개발자는 상대적으로 적은 것 같아요. 좋은 팀원들과 이야기하고 논의하다 보면 나도 발전하게 되는데, 이런 선순환을 생각하며 팀 전체의 성장을 위해 노력하는 개발자와 함께하고 싶어요.”

함께 성장한다고 하면 거창하게 들리지만, 사실 함께 성장하는 방법은 매우 다양합니다. 내가 읽었던 좋은 개발 아티클을 팀원들에게 공유하고, 코드 리뷰를 하고, 열린 자세로 논의하는 등 이 모든 것이 나와 팀원의 성장에 도움이 되는 과정입니다. 어떻게 하면 이런 과정을 활성화하고 발전할 수 있는지 고민하는 동료가 있다면, 그 팀은 시너지를 내어 빠르게 성장할 것입니다.

성장하기 위해 노력하는 개발자
<출처: Unsplash>

4) 근거와 함께 의견을 설득하는 사람

“똑똑한 사람이면 좋겠어요. 사실 똑똑하다는 것이 많은 것을 담고 있는데, 문제 해결을 잘하는 것도 똑똑함이고 다른 사람의 제안을 열린 마음으로 받아들이는 것도 똑똑함이고, 자신의 의견을 근거와 함께 명확하게 설명하는 것도 똑똑함이라고 생각해요. 특히 근거와 함께 의견을 설득하는 것이 중요하다고 생각하는데, 가끔 보면 신기술을 무작정 좋아하는 개발자가 있는 것 같아요. 예를 들어 타입스크립트(Typescript)가 이제 막 나왔을 때 큰 이유를 설명해주지 않고 신기술이라는 이유만으로 도입했던 적이 있었어요. 당시에는 멀쩡한 코드가 에러로 표시되는 등의 버그가 많아서 불편했는데, 제대로 된 설득 과정이 없이 이러한 불편함을 겪게 되니 더욱 결정에 공감을 하지 못했던 것 같아요. 다행히 지금은 타입스크립트가 편하고 좋지만, 왜 도입하는지 저를 비롯한 다른 동료들에게 설명이 되었으면 좋았을 것 같다는 생각이 들어요.”

서로 다른 의견이 있을 때는 설득하는 과정이 필요합니다. 만약 설득의 과정 없이 결정을 통보받기만 하면, 실제로 작업을 하는 개발자는 금세 일에 의욕과 열정을 잃어버릴 수 있습니다. 반대로 적절한 근거와 함께 설득하는 과정을 거친다면, 설령 자신의 의견이 받아들여지지 않더라도 결과를 납득할 수 있게 됩니다. 최종 선택은 의사 결정권자가 하더라도, 결국 팀원들과 동일한 방향성을 유지하기 위해서 적절한 설득의 과정이 필요한 것입니다.

5) 본인의 생각이 있는 사람

“본인의 생각이 있는 개발자와 일하고 싶어요. 저는 면접에 들어갈 때마다 정답이 없는 질문을 준비해서 본인의 생각을 갖고 있는지 테스트를 해보는 편이에요. 인터넷이나 책에서 공부할 수 있는 것들은 사실 자기 생각이 아니더라도 얼마든지 말할 수 있어요. 그러나 정답이 없는 것들은 생각해보지 않으면 말하기 어려울 거예요. 가령 새로운 서비스를 시작할 때 MySQL이랑 NoSQL 중에서 어떤 선택이 좋을지 물어보는 것이죠. 이런 질문에는 정답이 없다고 생각하는데, 정답이 없는 질문에 납득이 가는 답변을 할 수 있는 개발자와 함께하고 싶어요.”

스택이 어느 정도 갖춰진 기업이나 환경에서 개발하다 보면 큰 고민 없이 개발하는 경우가 종종 있습니다. 그러나 본인의 생각 없이 단순히 개발만 하다 보면 급변하는 기술 생태계를 쫓아가지 못할 수 있습니다. 평소에 여러 기술과 스택에 대해 고민하지 않았던 사람은 새로운 기술을 어떻게 받아들여야 하는지 모르기 때문입니다. 당연하고 익숙한 기술이라도 가끔은 한 발짝 뒤에서 고민하고 판단한다면 더 깊은 생각을 가진 개발자로 성장하게 될 것입니다.

6) 말 잘하고 글 잘 쓰는 사람

“말 잘하고 글 잘 쓰는 개발자와 일하고 싶어요. 개발 실력이 좋은 것을 전제했을 때 이 사람이 얼마나 다른 사람에게 자신의 생각을 표현하고 설득할 수 있는지가 중요하다고 생각해요. 그런 능력을 갖추고 있는 사람과 함께 일하면 의견을 주고받기도 편하고 시너지도 잘 나는 것 같아요.”

위에서도 설득의 중요성에 대해서 언급한 적이 있습니다. 그러나 설득하겠다는 의지만 있고, 생각을 잘 전달할 수 없다면 설득의 과정이 매끄럽지 않을 것입니다. 원활하게 소통하고 싶다면 이야기를 듣는 다른 개발자가 얼마나 제대로 이해할 수 있는지 고려하는 자세가 필요합니다.

협업하는 동료를 원한다

개발자가 함께 일하고 싶어 하는 개발자에 대한 이야기를 쭉 들어봤는데, 사실 대부분의 이야기가 개발자에만 국한되는 내용은 아닌 것 같습니다. 개발적인 역량은 기본적이라고 생각해서인지 모르겠지만, 대부분의 개발자는 개발적인 역량보다는 함께 협업하는 측면을 더욱 고려하는 것으로 보입니다. 그런데 과연 다른 직군에 대해서도 개발자의 생각이 비슷할까요? 다음 편에는 개발자가 ‘함께 일하고 싶은 디자이너’에 대해 알아보도록 하겠습니다.

[출처] https://yozm.wishket.com/magazine/detail/1702/

[졸리운곰 曰] 소프트 스킬, 커뮤니케이션 어쩌고 자 집어 치구고 함께 일하고 싶은 개발자 나부랭이나 동료건 

분명한 것은 자신에게 이득이 얼마나 되는지, 자신이 얼마나 이용해먹을 수 있는지가 문제지

핑계거릴 찾다가 소통이 안되네, 팀워크가 안되네 소리한다.

자기에게 이득되고, 이용해먹을 수 있으면 다른 모든게 용서가 될껄….

 17 total views,  2 views today

12 9월 2022

[산업] 코딩이 그렇게 만만합니까?

[산업] 코딩이 그렇게 만만합니까?

김형준(컴퓨터공학부·18)
하나의 유령이 대한민국을 떠돌고 있다. 코딩이라는 유령이. 대학가 역시 예외는 아니다. 당장 지난 학기 수강한 컴퓨터공학부 전공과목들만 보더라도 주전공생보다 복·부전생의 수가 월등히 많았던 기억이 있다. 몇몇 전공의 경우 서울대 간판을 달고도 취업이 요원한 반면, 컴퓨터공학 전공자는 비싼 값에 날개 돋친 듯 팔려나가는 탓이다. 이와 같은 수요와 공급의 불균형으로 인해 심화된 편중 현상은 소프트웨어 분야의 인력난 해결에 기여하고 있다. 그럼에도 이를 마냥 긍정적으로 바라볼 수만은 없는데, 적잖은 수의 사람들이 ‘코딩을 위한 코딩’의 구렁텅이에 빠지고 있기 때문이다. 남들에게 뒤처질 수 없다는 불안은 평생 뒤처진 적 없이 살아온 명문대생의 영혼을 어렵지 않게 잠식한다.

이런 불안감은 코딩을 공부하는 주변인과 언론에 의해 촉발되기도 하나, 무엇보다도 코딩 학원에 의해 확대·재생산된다. 분명 코딩 교육 시장은 성장 일로를 걷고 있으며 앞으로도 그래야 마땅한 분야다. 그럼에도 불구하고 과대광고로 무장한 대다수 학원의 작태를 보고 있자면 헛웃음이 나온다. 이들은 소위 ‘네카라쿠배’(네이버, 카카오, 라인, 쿠팡, 배달의민족)에 입사한 수강생들을 전시하며 평균 연봉을 과시적으로 내세운다. 소수의 고액 연봉자들로 인해 부풀려진 수치는 대다수의 수강생이 만족스럽지 않은 연봉을 수령하고 있음을 애써 숨긴다.

한술 더 떠 ‘90일 속성 머신 러닝’, ‘6개월 AI 전문가 코스’ 등의 허무맹랑한 카피를 보고 있자면 정신이 아득해진다. 누군가는 코딩 학원이 단언한 기간 내에 전공생 이상의 실력을 갖출 것이다. 대학생 때 본격적으로 농구에 입문해 이후 NBA MVP를 수상한 선수가 있는 것 혹은 고졸 출신으로 사법고시 수석을 차지한 사람이 있는 것과 같은 이치다. 드문 일이기에 우리는 그들을 ‘아웃라이어’라 일컫는다. 실상 학부 4년은커녕 석박사 과정까지 끝마쳐도 이들이 홍보하는 분야에서 전문가가 되기는 역부족이다. 가령 ‘변호사 3개월 완성’ 내지는 ‘180일 외과 의사 코스’였다면 반응이 같았을 리 없다. 그러니 작금의 열풍은 다소간 개발 직군에 대한 무시 내지는 무지에 기반하는 듯 보일 따름이다. 아웃라이어가 아닌 이상 고작 수개월을 투자하는 것만으로 업계가 요구하는 고급 개발자가 되기란 불가능에 가깝다.

이쯤에서 이 글이 당연하게도 비전공자의 코딩에 대한 관심을 억누르기 위해 쓰이지 않았음을 짚고 넘어갈 필요가 있겠다. 오히려 그 반대에 가깝다. 정확히 말하면 모두가 코딩을 할 필요는 없지만 모두가 코딩을 알 필요는 있다. (다른 모든 분야가 그렇겠지만) 물론 소프트웨어 분야는 극소수의 천재가 지대한 영향력을 행사하는 분야다. 예컨대 (모두 컴퓨터공학을 전공한) 마크 저커버그, 세르게이 브린, 래리 페이지, 리드 헤이스팅스는 우리의 삶에 얼마나 큰 영향을 미쳤는가?

그럼에도 불구하고 모두가 코딩을, 컴퓨터공학을 이해해야 하는 이유는 자명하다. 추상화를 위시한 논리적 사고를 훈련하기에 최적의 방법일 뿐만 아니라 개발자와의 협업에서 큰 이점을 얻을 수 있기 때문이다. 또한 어떤 학문을 공부하든 코딩은 해당 분야와 세상을 잇는 가교로 기능한다. 다행히도 세상은 이에 발맞춰 변화하고 있다. 말하자면 컴퓨터공학은 제2의 수학이 돼가는 중이고, 이는 비단 대한민국만의 유행이 아니며 전 세계적인 추세에 해당한다. 따라서 초중고에서 교양으로서의 코딩을 교육하는 것이 가장 효율적일 텐데 이런 맥락에서 지금의 20대는 저주 받았다고 볼 수 있겠다. 응당 코딩을 알아야 하는 세상에 너무 일찍 도착했으니 말이다.

관련 학과의 정원을 확대하고 비전공자에게도 학습의 기회를 주는 편이 최선이겠으나 현실적인 어려움이 산재해 있다. 그러니 교양으로서의 코딩을 학습한 이들이 대거 사회에 진출할 때까지는 대학 외부의 교육에 얼마간 빚질 필요가 있다는 결론이 도출된다. 상술한 코딩 학원들의 행태가 대폭 개선되거나 문제의식을 지닌 양심적인 사업자의 진입을 기대해야만 하는 상황에 놓였다. 일말의 희망. 나는 이 자그마한 희망에 억지로라도 기대를 걸어보려 한다.

출처 : 대학신문(http://www.snunews.com)

 91 total views,  10 views today

25 8월 2022

[산업] ‘데이터센터’를 계속 운영해야 하는 10가지 이유 

[산업] ‘데이터센터’를 계속 운영해야 하는 10가지 이유  

점점 더 많은 기업이 워크로드의 대부분 또는 전부를 클라우드로 이동하면서 서버 랙을 직접 설치 및 운영해야 할 이유는 줄어들고 있지만 (이는) 여전히 중요하다. 

클라우드로 인해 데이터센터가 서서히 빛을 잃고 있다. IT의 핵심 구성요소인 데이터센터에서 멀어지는 실질적인 이유가 있다. 클라우드 업체가 놀라운 코드를 간단하게 작성할 수 있는 놀라운 제품과 시간을 절약하는 서비스를 계속해서 선보이고 있기 때문이다. 그 편의성은 경이롭다. 

하지만 클라우드로 전환해야 하는 명백한 이유에도 불구하고, 이 트렌드에 역행하여 자체 데이터센터를 계속 운영해야 하는 몇 가지 이유가 있다(아마도 모든 워크로드는 아니더라도 일부에 해당될 수 있다). 여기서는 자체 랙에서 온프레미스로 코드를 실행해야 하는 이유 10가지를 살펴본다.
 

ⓒGetty Images

로컬 속도(Local speed)
클라우드는 전 세계에 퍼져 있는 기업에 적합한 자산이다. 먼 곳 또는 집에서 근무하는 직원들을 지원할 때도 적합하다. 하지만 직원들이 같은 건물에 있고, 같은 서버를 사용한다면 서버를 멀리 떨어진 곳에 두는 것은 그다지 적합하지 않다. 기업의 자산이 (이를테면) 우편번호도 모르는 먼 곳의 클라우드 기반 기기까지 가로질러 이동할 수 있어서다. 로컬 서버는 다른 곳에 있는 서버보다 빠르다. 게다가 네트워크 홉이 적기 때문에 장애 지점도 적다. 데이터가 건물 밖으로 나갈 일이 없다면 작은 인터넷 파이프로도 충분하다. 이게 바로 서버를 가까이 둬야 하는 이유다. 직원들이 한 곳에 있다면 필요한 서버를 가까이 두는 게 낫다.

기술적 균형(Technical tradeoffs)
일각에서는 눈에 보이지 않는 클라우드가 서버 운영, 기기 구매, 소프트웨어 설치 등 모든 일을 처리하기 때문에 이를 선호한다. 분명 클라우드는 부담을 덜어줄 수 있다. 하지만 때로는 이 모든 책임을 스스로 지는 것이 더 편안할 수 있다. 진짜? 물론 때에 따라 다르다. 중요하지 않은 작업이고, 클라우드 업체의 접근을 허용할 수 있다면 클라우드 업체가 알아서 하도록 하고 (이에 따라) IT를 조정하는 것만으로 충분하다. 그러나 자체적인 방식이 있다면 클라우드로의 이동에 수반되는 마찰로 인해 절약되는 시간만큼의 가치가 없을 수 있다.

이전 버전의 파이썬을 기반으로 한 레거시 코드를 사용했던 프로젝트를 예로 들어보자. 하지만 클라우드 업체는 최신 버전의 우분투와 새로운 버전의 파이썬을 사용하고 있었다. 다른 버전과 씨름하거나 연구실의 컴퓨터에 쓰고 있는 버전의 파이썬을 설치할 수 있었지만 코드를 다시 작성하는 것보다 컴퓨터를 구매하는 것이 더 간단했다.

이웃(Neighbors)
클라우드 업체는 모든 고객을 만족시켜야 한다. 그리고 서비스를 구매하는 기업(혹은 사용자)은 수없이 많다. 따라서 클라우드 서비스 가입은 개인 소유의 섬에 사는 것과는 다르다. 이웃과 잘 지내야 한다. 클라우드의 이웃이 악의적일 수 있다는 게 가장 극단적인 사례다. 이를테면 로우해머(Rowhammer) 공격은 같은 하드웨어의 다른 사용자에게 침입할 수 있다. 심각한 문제가 될까? 해커가 다른 클라우드 인스턴스를 자주 공격하는가? 아마 그렇지는 않을 것이다. 하지만 자체 하드웨어를 구매하는 가장 큰 장점은 데이터센터의 이웃을 걱정하지 않아도 된다는 것이다.

통제(Control)
오늘날의 계약은 돌판 위에 새겨지지 않는다. 심지어 종이에도 작성되지 않는다. 문제가 발생하면 클라우드 업체는 서비스 약관에 명시되지 않은 일부 조항을 위반했다는 모호한 주장을 하면서 사용자를 차단하는 경우가 많다. 서비스 업체에게 이러한 이메일을 받게 된 개발자와 기업의 슬픈 사연이 많다. 심지어 때로는 클라우드 업체가 이메일조차 보내지 않는다. 그리곤 모든 것이 작동을 멈춘다.

어쩌면 (이러한 문제에 대응할) 믿을 만한 변호사가 있을 수 있다. 어쩌면 이 모든 이야기가 과장됐으며, 남의 일이라고 생각할 수도 있다. 허나 클라우드 업체가 비합리적으로 행동하고, 매출을 날려버릴 가능성은 높아 보인다. 그러나 하드웨어를 통제하면 법적 장애 지점이 줄어든다는 건 확실하다.

권력(Power)
때때로 클라우드 업체는 서비스가 엉망이라는 비난을 받는다. 일부는 의도적으로 전화번호를 공개하지 않는 것 같다. 일부는 이메일에 절대 답신하지 않는 것 같다. 게시판엔 고생하는 클라우드 업체 직원에 관한 이야기도 있지만 이름을 밝히지 않은 정체불명의 악당에 관한 불평불만도 있다. 데이터센터에서 보고한다면 훨씬 더 쉽게 답변을 받을 수 있다. 물론 사라진 IT 직원에 관해 분노하는 이야기가 많은 것도 사실이다. 내부 기술 지원 인력이 멸종위기종인 것처럼 잘 보이지 않는다는 농담도 있다. 하지만 기업이 (내부 기술 지원 인력에게) 급여를 지급한다는 점에서 이는 더 나은 서비스를 확보하는 방법 중 하나다.

비용(Price)
최신 하드웨어는 항상 비싸다. 만약 (작업에서) 성능이 중요하다면 클라우드를 활용하는 게 가장 합리적일 수 있다. 하지만 다소 반복적이고 예측 가능한 작업이라면 구형 서버를 사용하여 비용을 절약할 수 있다. 물론 잠재적으로 숨겨진 비용이 있다. 구형 기기는 더 자주 고장 난다. 워크로드가 예상치 못한 다운타임을 처리할 수 있는가? 직원들이 기기를 수리할 수 있는가? 그렇게 할 수 있다면 구식 하드웨어를 사용하는 게 훨씬 더 저렴하다. 

일정한 부하(Steady loads)
클라우드에 적합한 기업은 컴퓨팅 부하가 매우 가변적이면서도 일반적으로 예측할 수 있는 곳이다. 예를 들면 스트리밍 비디오 서비스는 금요일과 토요일 밤에 대부분의 연산을 수행한다. 다시 말해, 몇 시간 동안 사용한 후 모두가 잠자리에 드는 즉시 전원을 끈다. 하지만 이 반대라면 자체 데이터센터를 운영하는 게 더 합리적일 수 있다. 할인을 받더라도 클라우드 기기를 하루 24시간, 주 7일 동안 실행하면 비싸기 마련이다. 기기를 계속 가동한다면 비용 경쟁력이 있는 로컬 데이터센터 예산을 책정하는 것이 낫다.

여분의 부동산(Extra real estate)
팬데믹으로 인해 상업용 부동산 세계가 요동쳤지만 일부 기업에는 쉽게 없앨 수 없는 여분의 공간이 있을 것이다. 이를테면 몇 년 동안 임대료가 발생하지 않는 건물을 소유하고 있을 수 있다. 클라우드 비용의 일부는 하드웨어를 보관하는 건물이다. 부동산 비용으로 인한 수익이 낮거나 심지어 없다면 빈 공간에 몇 개의 랙을 설치하는 것이 예산 대비 효과가 있을 수 있다.

저렴한 지역 전기 요금(Cheaper local power)
전기 요금은 데이터센터 운영의 큰 부분을 차지하며, 대부분의 경우 전력 비용이 하드웨어 비용보다 크다. 일부 주 또는 지방자치단체에서 로컬 비즈니스를 유치하려고 할 때 일부는 세제 혜택을 활용하지만 지역 전기 요금을 할인하여 신규 기업에 간접적으로 보조금을 지급하는 곳도 있다. 이에 따라 기존의 전기 요금이 이미 매우 저렴할 수 있으며, 그렇다면 자체 데이터센터를 운영하는 게 더 합리적일 수 있다.

할인을 받을 필요 없이 전기가 저렴한 지역도 있다. 풍부한 바람 또는 끝없는 햇빛 때문에 신재생 에너지를 더 쉽게 생산하는 곳도 있다. 비용이 저렴한 이유는 중요하지 않다. 기업의 전기 요금이 합리적인 경우 자체 시스템을 호스팅하여 클라우드 컴퓨팅 비용을 크게 절약할 수 있다는 게 중요하다.

지역 인재(Local talent)
몇몇 기업은 데이터센터 관리 인력을 최소화하고 싶어 한다. 하지만 인적 자본을 중시하는 곳도 있다. 한 기업은 일반적으로 예측할 수 없는 시기에 필요한 데이터센터 관리 인력을 확보할 수 있도록 여유 있게 채용하는 것을 선호했다. 그리고 비상사태가 발생했을 때 이 회사는 준비가 돼 있었다. 

물론 자체 데이터센터 인력을 확보하는 일은 비용이 많이 들 수 있으며, 이는 CIO들이 정당화하기 가장 어려운 비용 가운데 하나다. 하지만 데이터센터를 운영하면서 효과적으로 수행할 수 있는 다른 역할이 있지 않을까? 지역 인재를 원하고 스마트한 인력을 채용하고 싶다면 컴퓨팅 예산의 일부를 투입해 (데이터센터) 인력을 유지하는 게 바람직하다. 몇몇 클라우드 업체는 휴게실에서 소통하거나 7월 4일(편집자 주: 미국 독립기념일) 소풍을 계획하거나 회사 소프트볼장을 청소하거나 인적 자본이 기업에 제공할 수 있는 다른 일을 하지 않을 것이다. ciokr@idg.co.kr

원문보기:
https://www.ciokorea.com/news/231169#csidx609d036e3dc76bc91a1d44d46762ecd 

 126 total views,  4 views today

21 8월 2022

나에게 맞는 웹 기술 스택을 고르는 방법

나에게 맞는 웹 기술 스택을 고르는 방법

본문은 요즘IT와 번역가 Mr.P가 함께 만든 해외 번역 콘텐츠입니다. 이 글을 작성한 The Educative Team은 직접 하면서 배우는 개발자 학습 플랫폼 Grokking의 콘텐츠 발행팀입니다. 이번 글은 웹 개발을 위한 여러 인기 기술 스택을 살펴보고, 어떤 장단점이 있는지 분석하는 내용입니다.

 
웹 기술 스택

세상에는 웹 개발을 하기 위한 많고도 다양한 기술 스택이 존재합니다. 그러나 어떤 스택을 채택해야 하는지, 언제 그것을 사용할 수 있는지를 아는 것은 특히 초보자에게 어려운 일입니다. 이 글을 통해서 우리는 웹 개발을 위한 여러 인기 있는 기술 스택들을 살펴본 뒤 그것들의 장단점을 분석할 것입니다. 그 후에 우리는 일반적인 소프트웨어 개발, 웹 개발, 모바일 웹 앱 개발 등의 목적에 따라서 웹 개발 기술 스택을 고르기 위한 몇 가지 팁을 제공할 것입니다.

이제 시작하겠습니다!

기술 스택이란?

우선, 기술 스택이란 무엇일까요?

기술 스택이란 웹사이트나 웹 앱을 만들기 위한 언어, 데이터베이스, 프레임워크의 집합입니다. 일반적인 웹 개발 스택은 다음을 포함한 프론트엔드, 백엔드 기술이 혼합되어 있습니다.

  • 프레임워크: 다른 개발자가 작성한 코드 라이브러리입니다. 이는 웹 애플리케이션을 제작할 때 처음부터 시작하지 않아도 되기 때문에 도움이 될 수 있습니다.
  • 웹 서버/HTTP 서버: HTTP(Hypertext Transfer Protocol) 서버는 이메일을 보내거나 받고, 파일을 다운로드하는 등의 요청을 다룹니다.
  • 데이터베이스: 데이터베이스는 데이터를 저장하고 구성합니다. 데이터는 다양한 방법으로 검색, 변경, 업데이트, 관리할 수 있습니다.
  • 프로그래밍 언어: 컴퓨터가 이해할 수 있는 방식으로 명령어(Instruction)를 전달하는 데 사용됩니다.
  • 운영체제 (OS): 하드웨어, 소프트웨어, 기타 응용 프로그램이나 리소스를 관리하는 소프트웨어입니다.

모든 개발 요구사항을 처리하기 위한 다양한 기술 스택이 존재하며, 프로젝트의 요구에 따라서 그에 맞는 기술 스택이 매번 달라집니다. 예를 들어 만일 여러분이 많은 트래픽과 데이터를 처리해야 하는 고성능의 웹 사이트나 웹 애플리케이션을 생각하고 있다면, 강력한 백엔드 지원을 포함한 기술 스택을 채택해야 합니다.

마찬가지로 만일 여러분이 제한된 기능과 자원 속에서 빠르게 시작하고 실행해야 하는 웹 사이트를 구축하기를 원한다면(간단한 랜딩 페이지같이), 가볍고 세팅이 간단한 기술 스택을 고르는 것이 좋습니다.

웹 개발을 위한 인기 있는 기술 스택

웹 개발을 위해 사용할 수 있는 다양한 기술 스택이 존재합니다. 그러나 이 글에서는 다음을 다룰 것입니다:

  • LAMP: Linux, Apache, MySQL, PHP/Perl/Python
  • WAMP: Windows, Apache, MySQL, PHP/Perl/Python
  • MAMP: macOS, Apache, MySQL, PHP/Perl/Python
  • MEAN: MongoDB, Express.js, AngularJS, Node.js
  • MERN: MongoDB, Express.js, ReactJS, Node.js
  • MEVN: MongoDB, Express.js, Vue.js, Node.js
  • Django: Django, Python

기술 스택을 고르기 위해 고려해야 할 포인트

  • 요구 사항 정의: 제품이 무엇을 하며, 여러분의 비전을 달성하기 위해 어떤 조건이 필요하나요?
  • 시장 조사: 잠재적인 경쟁자를 조사하고, 아직 충족되지 않은 요구사항을 기회로 만든 후 타깃으로 하는 고객을 분석합니다.
  • 제품의 실행 가능성: 프로토타입(최소 기능 제품 혹은 MVP라고도 불리는)을 만들고 타깃으로 하는 시장에서 테스트 후, 유의미하게 사용되는지 확인합니다.
  • 확장성 고려: 제품이 성장할 때 어떻게 하면 제품의 품질과 통제를 잃지 않고 유저를 더 많이 수용할 수 있을까요? 확장을 위한 해결책으로서 다른 기술 스택은 어떨까요?
  • 보안: 웹 애플리케이션과 사용자 데이터를 어떻게 보호해야 할까요?
  • 가격 비교: 몇몇 기술 스택은 다른 기술 스택에 비해서 호스팅이나 다른 자원에 대해 많은 비용을 요구합니다. 제품에 가장 경제적인 것을 선택해야 합니다.

LAMP

LAMP는 많은 트래픽을 요구하는 페이스북, 위키피디아, 텀블러에서 사용되는 전통적인 기술 스택입니다.

LAMP는 다음으로 이루어져 있습니다:

  • 리눅스(Linux) (운영체제)
  • 아파치(Apache) (서버)
  • MySQL(데이터베이스)
  • PHP/펄(Perl)/파이썬(Python) (프로그래밍 언어)

리눅스: 리눅스 OS는 LAMP의 기반을 다져줍니다. 이는 무료이며 쉽게 수정할 수 있기 때문에 개발자들에게 인기 있는 오픈소스 플랫폼입니다. 반면에 윈도우는 클로즈드 소스(closed-source)[1] 플랫폼입니다. 따라서 여러분은 작동 방식에 대한 제어 권한이 리눅스와 비교하면 그다지 많지 않습니다. 리눅스는 또한 대규모 개발자 커뮤니티와 많은 양의 문서를 제공합니다.

아파치: 아파치는 많은 양의 트래픽과 데이터를 처리할 수 있는 크로스 플랫폼이자 오픈소스 HTTP 서버입니다. 1996년부터 사용해온 아파치는, 빠르고, 안전하며, 신뢰할 수 있습니다. 아파치는 모듈화 되어 있으며 필요에 따라 성능을 최적화하도록 사용자가 설정할 수 있습니다.

MySQL: MySQL는 관계형 데이터베이스 관리 시스템으로 행과 열로 구성된 표 형식으로 데이터를 저장하고 보여줍니다. MySQL 또한 오픈소스이며, 사용하기 편리합니다. MySQL는 확장성을 지원하며 많은 양의 데이터를 처리할 수 있지만, 너무 거대한 데이터베이스를 처리할 때는 성능과 효율성이 저하될 수 있습니다.

PHP/펄/파이썬: PHP는 LAMP와 함께 사용되는 가장 인기 있는 프로그래밍 언어이며 대부분의 서버와 호환됩니다. 게다가 상대적으로 배우기 쉽고 다양한 라이브러리와 프레임워크를 제공합니다. 펄과 파이썬 또한 PHP를 대신하여 사용되고 있습니다.

  • 펄: 강력한 고급 객체 지향 언어지만 초보자가 배우기 어려운 복잡한 문법을 가졌습니다.
  • 파이썬: 확장성이 좋으며 여러 방면으로 사용할 수 있는 언어입니다. 가독성이 좋아 개발자들에게 인기 있는 언어이기도 합니다. 또한 파이썬은 머신러닝과 과학, 수학적 연산에서 널리 사용되는 언어이기도 합니다.
장점 단점
  • 소유권이 없으며, 오픈소스입니다.
  • 오랫동안 사용되어 왔습니다.
  • 스택의 구성요소는 필요에 따라 교체될 수 있습니다. 따라서 높은 유연함이 존재합니다.
  • 사용과 초기 설정이 쉽습니다. 특히 초보자에게 유용합니다.
  • MySQL과 PHP는 이미 많은 웹 호스팅에 사용되었습니다.
  • 경제적입니다.
  • 제한된 확장성으로 인해 대규모 애플리케이션에는 적합하지 않습니다.
  • MySQL은 상대적으로 배우기 쉽습니다. 그러나 고성능의 애플리케이션에 있어서 최선의 선택지는 아닙니다.
  • 공유 서버가 성능 이슈를 유발할 수 있습니다.

WAMP와 MAMP

WAMP와 MAMP는 각각 리눅스를 대신하여 마이크로소프트의 윈도우와 맥 OS(Mac OS)에서 사용할 수 있도록 설계된 LAMP의 변형된 버전입니다.

MEAN

MEAN은 유튜브(YouTube), 넷플릭스(Netflix), 페이팔(PayPal)과 같은 웹 사이트를 제작하는 데 사용된 자바스크립트(JavaScript) 웹 프레임워크입니다. MEAN은 이미 자바스크립트에 친숙하거나, 개발 진행 속도를 높이려는 사람들에게 훌륭한 기술 스택입니다.

MEAN은 다음으로 이루어져 있습니다:

  • 몽고디비(MongoDB) (데이터베이스)
  • Express.js (Node.js용 웹 프레임워크)
  • Angular.js (프론트엔드 프레임워크)
  • Node.js (서버)

몽고디비: 몽고디비는 프론트엔드 프레임워크(이 경우 Angular.js)에서 생성된 JSON 문서를 Express.js에서 처리한 후 저장하는 오픈소스 프레임워크입니다. 몽고디비는 많은 양의 데이터를 저장할 수 있고, 클라이언트-서버 간의 빠른 데이터 교환을 가능하게 하며, 클라우드 호환성을 지녔습니다.

Express.js: Express는 Node.js 서버에서 실행되는 가벼운 백엔드 웹 프레임워크입니다. Express.js는 URL 라우팅과 HTTP 요청 처리에 탁월한 성능을 가지고 있습니다. Express.js는 웹 프레임워크로부터 JSON 문서를 받고, 그것을 처리하며 몽고디비에 저장합니다.

Angular.js: Angular.js는 빠르고, 오픈 소스이며, 본격적인 프론트엔드 프레임워크입니다. Angular.js는 강력하게(그러나 너무 엄격하지 않게) MVC(Model-View-Controller) 구조를 따르고 있습니다.

Node.js: Node.js는 비동기 이벤트 기반 자바스크립트 런타임 환경입니다. 비동기 서버로서 Node.js는 메모리에 대해 매우 효율적입니다. 또한 Node.js는 오픈소스이며, 윈도우, 맥, 리눅스 등 어느 환경에서 실행될 수 있는 크로스 플랫폼입니다.

장점 단점
  • 빠른 개발 속도를 지녔습니다.
  • 오직 하나의 프로그래밍 언어(자바스크립트)를 사용합니다.
  • 오픈소스이며 무료입니다.
  • 새로운 기능을 추가하기 쉬운 거대한 라이브러리 모듈이 존재합니다.
  • MVC 구조입니다.
  • 클라우드 호환성을 지녔습니다.
  • 웹 애플리케이션이 서버로 바로 배포될 수 있습니다.
  • 자바스크립트는 완벽하게 숙달하기 어려울 수 있습니다.
  • 모바일 애플리케이션 지원을 위해 Native Script[2]가 필요합니다.
  • 테스트를 위한 프레임워크가 없습니다.

MERN과 MEVN

MERN과 MEVN은 앞서 다룬 MEAN과 유사하지만, Angular.js를 대신해 각각 리액트와 Vue.js를 사용합니다.

우리는 우선 MERN을 살펴본 후, MEVN과 어떤 차이점이 있는지 알아보겠습니다.

MERN

MERN은 MEAN, MEVN과 매우 비슷합니다. 그러나 프론트엔드 프레임워크로 Angular.js나 Vue.js 대신 리액트를 사용한다는 점에서 차이가 있습니다. MERN는 드롭박스(Dropbox), 페이스북(Facebook), 에어비엔비(Airbnb)와 같은 회사에서 사용되고 있습니다. MERN는 MEAN의 많은 이점을 함께 공유하고 있지만, 리액트의 Angular.js에 비해 완곡한 러닝 커브를 그리고 있습니다.

MERN은 다음으로 이루어져 있습니다:

  • 몽고디비 (데이터베이스)
  • Express.js (Node.js용 웹 프레임워크)
  • 리액트 (프론트엔드 프레임워크)
  • Node.js (서버)

몽고디비: 몽고디비는 프론트엔드 프레임워크(이 경우 리액트)에서 생성된 JSON 문서를 Express.js에서 처리한 후, 저장하는 오픈소스 프레임워크입니다. 몽고디비는 많은 양의 데이터를 저장할 수 있고, 클라이언트-서버 간의 빠른 데이터 교환을 가능하게 하며, 클라우드 호환성을 지녔습니다.

Express.js: Express는 Node.js 서버에서 실행되는 가벼운 백엔드 웹 프레임워크입니다. Express.js는 URL라우팅과 HTTP 요청 처리에 탁월한 성능을 가지고 있습니다. Express.js는 웹 프레임워크로부터 JSON문서를 받고, 그것을 처리하며 몽고디비에 저장합니다.

리액트: 빠르고, 확장이 용이한, 오픈 소스 자바스크립트 라이브러리로 MERN 스택의 프론트엔드 프레임워크로써 사용되었습니다. 리액트는 웹 페이지 조작을 쉽게 만들어주는 가상 DOM을 제공합니다. 그러나 네이티브 DOM을 사용하는 MEAN에 비해 약간 느립니다. 또한 리액트는 컴포넌트 기반의 라이브러리를 사용합니다. 이는 애플리케이션의 다른 파트에서 코드 재사용을 쉽게 해 줍니다. 게다가 여러분이 자바스크립트가 어떻게 작동하는지 알고 계신다면 리액트를 쉽게 배울 수 있습니다.

Node.js: Node.js는 비동기 이벤트 기반 자바스크립트 런타임 환경입니다. 비동기 서버로서, Node.js는 메모리에 대해 매우 효율적입니다. 또한 Node.js는 오픈소스이며, 윈도우, 맥, 리눅스 등 어느 환경에서 실행될 수 있는 크로스 플랫폼입니다.

MEVN

MEVN은 Angular.js나 리액트 대신에 Vue.js를 웹 프레임워크로 사용합니다. Vue.js 사용자 인터페이스(UI)를 구축하기 위한 가장 인기 있는 자바스크립트 프레임워크 중 하나입니다. MEVN는 알리바바(Alibaba), 비핸스(Behance), 깃 랩(GitLab)과 같은 웹 사이트를 구축하는 데 사용되었습니다. Vue.js는 미티어(Meteor)와 도커(Docker)와도 호환됩니다.

MEVN은 다음으로 이루어져 있습니다:

  • 몽고디비 (데이터베이스)
  • Express.js (Node.js용 웹 프레임워크)
  • Vue.js (프론트엔드 프레임워크)
  • Node.js (서버)

MongoDB: 몽고디비는 프론트엔드 프레임워크(이 경우 리액트)에서 생성된 JSON 문서를 Express.js에서 처리한 후, 저장하는 오픈소스 프레임워크입니다. 몽고디비는 많은 양의 데이터를 저장할 수 있고, 클라이언트-서버 간의 빠른 데이터 교환을 가능하게 하며, 클라우드 호환성을 지녔습니다.

Express.js: Express는 Node.js 서버에서 실행되는 가벼운 백엔드 웹 프레임워크입니다. Express.js는 URL 라우팅과 HTTP 요청 처리에 탁월한 성능을 가지고 있습니다. Express.js는 웹 프레임워크로부터 JSON문서를 받고, 그것을 처리하며 몽고디비에 저장합니다.

Vue.js: Vue.js는 MVVM[3] 아키텍처를 기반으로 만들어진 점진적인 프레임워크(Progressive Framework)입니다. 새로운 기능이나 함수를 추가하는 것은 간단한 과정이며, (단지 패키지를 추가하면 됩니다) 프로젝트에 점진적으로 통합할 수 있습니다. Vue.js는 직관적이고 읽기 쉬운 문법을 가지고 있어서 오픈소스 커뮤니티의 개발자들에게 인기 있는 언어입니다.

Node.js: Node.js는 비동기 이벤트 기반 자바스크립트 런타임 환경입니다. 비동기 서버로서, Node.js는 메모리에 대해 매우 효율적입니다. 또한 Node.js는 오픈소스이며, 윈도우, 맥, 리눅스 등 어느 환경에서 실행될 수 있는 크로스 플랫폼입니다.

장고(Django)

장고는 빠른 개발과 깨끗하고 잘 구성된 코드를 권장하는 고급(High-level) 파이썬 웹 개발 프레임워크입니다. 장고의 유연한 아키텍처와 손쉬운 사용으로 인해 웹 개발자 사이에서 인기 있지만 배우기가 다소 어려울 수 있습니다. 장고 기술 스택은 인스타그램(Instagram)과 핀터레스트(Pinterest) 개발에 사용되었지만 핀터레스트는 이후 Flask로 프레임워크를 변경했습니다.

장고 스택은 언제나 장고와 파이썬을 사용합니다. 그러나 서버와 데이터베이스는 선호에 따라 다르게 선택할 수 있습니다.

장고 기술 스택의 하나의 예시입니다:

  • 장고 (웹 프레임워크)
  • 파이썬 (프로그래밍 언어)
  • 아파치 (서버)
  • MySQL (데이터베이스)

장고: 다양하고 즉시 사용할 수 있는 기능을 갖춘 종합적이고 다목적의 웹 프레임워크입니다. 장고는 빠른 개발과 깔끔한 설계를 우선순위로 둡니다. 장고는 다양한 웹 호스팅 제공업체 및 데이터베이스와 호환되며 관리자 패널, ORM[4], 템플릿, 인증(패키지를 통해) 등을 제공합니다.

파이썬: 확장성이 좋으며 여러 방면으로 사용할 수 있는 언어입니다. 가독성이 좋아 개발자들에게 인기 있는 언어이기도 합니다. 또한 파이썬은 머신 러닝과 과학, 수학적 연산에서 널리 사용되는 언어이기도 합니다.

아파치: 아파치는 많은 양의 트래픽과 데이터를 처리할 수 있는 크로스 플랫폼이자 오픈소스 HTTP 서버입니다. 1996년부터 사용해온 아파치는, 빠르고, 안전하며, 신뢰할 수 있습니다. 아파치는 모듈화 되어 있으며 필요에 따라 성능을 최적화하도록 사용자가 설정할 수 있습니다.

MySQL: MySQL는 관계형 데이터베이스 관리 시스템으로, 행과 열로 구성된 표 형식으로 데이터를 저장하고 보여줍니다. MySQL 또한 오픈소스이며, 사용하기 편리합니다. MySQL는 확장성을 지원하며 많은 양의 데이터를 처리할 수 있지만, 너무 거대한 데이터베이스를 처리할 때는 성능과 효율성이 저하될 수 있습니다.

장점 단점
  • 빠른 개발 속도를 가졌습니다.
  • 국제화와 현지화를 지원합니다.
  • 대규모의 서드파티(Third-party) 라이브러리가 존재합니다.
  • MVC 아키텍처를 사용합니다.
  • 일반적인 코딩 컨벤션[5]이 부족합니다.
    역주: 현재는 장고 코딩 컨벤션공식문서가 존재합니다.
  • 이미 존재하는 변수와 파일, 규칙을 장고에 배포하기 전에 미리 공부해야 합니다.
  • 배우기가 어렵습니다.

어떤 기술 스택을 사용해야 하나요?

지금까지 우리는 여러 인기 있는 개발 스택에 대해 살펴보았습니다. 아마도 여러분은 어떤 기술 스택이 여러분에게 가장 좋은 선택지 일지 궁금해하실 수 있습니다. 정답은 여러분의 프로그래밍 경험과 여러분의 목적에 있습니다.

만약 여러분이 웹 개발이 처음이시라면, MEAN이나 MERN이 좋은 시작점이 될 수 있습니다. 이러한 스택은 상대적으로 배우기 쉽고 하나의 언어(자바스크립트)만을 사용하기에 일을 간편하게 할 수 있습니다.

만약 여러분이 조금 더 개발에 경험이 있거나, 좀 더 유연한 스택을 찾으신다면 LAMP나 MEVN과 같은 스택이 더 나은 선택지가 될 것입니다. 이 기술 스택들은 사용하려는 도구와 기술을 더 자유롭게 선택할 수 있습니다.

만일 자바스크립트를 프론트엔드와 백엔드 둘 다 사용하고 싶으시다면, 자바스크립트 기반 스택들(MEAN, MERN, MEVN)이 좋은 선택입니다. 만약 프론트엔드와 백엔드의 언어를 다르게 사용하고 싶으시다면 LAMP, WAMP, MAMP가 더 낫습니다.

또한 이러한 스택을 엄격히 준수할 필요는 없습니다. 원하는 경우에 다른 기술을 혼용해서 사용할 수 있습니다. 궁극적으로 가장 중요한 것은 목표를 달성하는 데 가장 도움이 되는 도구와 기술을 사용하는 것입니다.

스택을 선택하고, 통달하기까지의 팁

웹 개발이 처음이라면, 다양한 툴과 기술을 배울 때 하나를 깊게 하기보다 다양하게 넓게 배우고 싶다는 유혹에 빠질 수 있습니다. 그러나 일반적으로 하나의 스택에 집중하여 공부하는 것이, 스택에 포함된 구성요소를 마스터하는 데 도움이 될 수 있습니다.

이러한 관점에서 기술 스택을 고르고 통달하는 것에 대한 몇 가지 팁이 있습니다.

  • 흥미와 커리어 목표를 정의하기. 여러분의 필요와 가장 부합한 기술 스택을 선택할 수 있습니다.
  • 천리길도 한 걸음부터. 처음부터 기술 스택의 모든 것을 알려고 할 필요는 없습니다. 스택에 있는 구성요소의 기본적인 기능을 연습하는 것에서부터 시작하세요.
  • 끊임없이 시도하고 실험하기. 만일 지금 고른 스택이 여러분과 맞지 않는다고 생각된다면, 다른 스택을 적용해보고 가장 적합한 스택을 확인하세요.
  • 시간을 쏟아 선택한 스택의 기술을 마스터하기. 스택에 있는 도구를 더 잘 아는 것이, 개발자의 생산성을 높여주는 길입니다.

여러분이 어떤 스택을 선택하였던, 가장 중요한 것은 끊임없이 학습하고 기술의 폭을 넓혀가는 것임을 잊지 마세요. 그렇게 할 수만 있다면, 머지않아 여러분들은 멋진 웹 애플리케이션을 만들 수 있을 것입니다.

글을 마치며

평생의 개발자 커리어 동안 하나의 기술 스택을 고수해야 한다는 생각하는 실수를 저지르지 마세요. 웹 개발의 아름다움은 문제를 해결하기 위한 기술과 방법이 언제나 새롭게 생겨난다는 점에 있습니다. 따라서 마음을 열고, 새로운 스택의 도입을 실험해보세요. 그리고 업계의 발전에 적응하세요.


[1] 사유화되어 소스코드가 외부에 공개되지 않은 프로젝트
[2] 자바스크립트 기반의 모바일 애플리케이션 지원을 위한 프레임워크
[3] Model, View, ViewModel로 이루어진 코드 디자인 패턴.
[4] 객체와 관계형 데이터베이스의 데이터를 자동으로 매핑해주는 것
[5] 코드의 가독성을 높이기 위해 코드를 작성할 때 모두가 지키자고 약속한 일종의 규칙

<원문>

How to choose the right tech stack for web development

[출처] https://yozm.wishket.com/magazine/detail/1645/

 221 total views,  10 views today

22 11월 2021

현명한 사람과 어리석은 사람의 차이는? 

현명한 사람과 어리석은 사람의 차이는?  

현명한 사람과 어리석은 사람의 차이

그들에겐 7가지 특징이 있다.

1.현명한 사람은 자기보다 지혜로운 사람 앞에서는 말하지 않는다.

2.현명한 사람은 다른 사람이 이야기하고 있는 동안에는 그의 말을 가로채어 끼어 들지 않는다.

3.현명한 사람은 다른 사람의 말에 귀를 기울여 한 마디도 흘려 보내지 않는다.

4.현명한 사람은 적절한 질문을 하고 적절한 대답을 한다.

5.현명한 사람은 조리있게 말한다.

6.현명한 사람은 자기가 알지 못하는 문제에 대해서는 ‘저는 그것에 대해서는 아는 바가 없습니다’라고 말한다.

7.현명한 사람은 자기와 반대 입장에 서 있는 사람이 말하는 것이 진리라고 인정되면 주저하지않고 그의 말을 인정한다.

어리석은 사람은 현명한 사람의 이런 특징과 반대되는 특징을 가진 사람이다.

<탈무드 황금률 방법>(이희영 지음, 동서문화사 펴냄)      

원문보기:
https://www.hani.co.kr/arti/well/well_writing/939308.html#csidxf2aaee10d8a5e5da9ead463e529de1a 

 390 total views,  4 views today

21 9월 2021

[時事][시사] ‘오징어잡이배’ 탈출했다더니, 게임업계 직원 절반 연휴에도 근무

[時事][시사] ‘오징어잡이배’ 탈출했다더니, 게임업계 직원 절반 연휴에도 근무

신은진 기자

입력 2021.09.21 17:19

경기 성남 판교테크노밸리 야경./조선일보DB
 
경기 성남 판교테크노밸리 야경./조선일보DB

밤늦게까지 사무실 불이 꺼지지 않아 한때 ‘오징어잡이배’, ‘구로·판교의 등대’로 불렸던 게임업계. 최근 근로환경이 개선되긴 했지만, 게임업계 직장인 절반 이상은 올 추석 연휴에도 정상 근무하는 것으로 나타났다.

게임 취업플랫폼 게임잡(대표이사 윤병준)이 게임업계 직장인 130명을 대상으로 ‘추석연휴 근무 현황’ 조사를 실시한 결과, 전체 응답자의 절반 이상인 52.3%가 추석 연휴에 정상 근무하는 것으로 나타났다.

이들 게임업계 직장인들이 추석 연휴에 근무하는 가장 큰 이유는(복수응답) ‘코로나19로 귀향 또는 친척집에 가기 어려워서’(쉬느니 일하자는 마음으로) (48.5%) 였다. 이어 ‘추석에도 회사가 정상 운영해서(42.6%)’, ‘대체 인력이 없어서(일손 부족)(27.9%)’, ‘추가 수입을 올리기 위해서(20.6%)’, ‘연휴 기간 당직·특근 일정이 잡혀서(17.6%)’ 등이 있었다.

추석 연휴 기간 중 게임업계 직장인들이 가장 많이 근무하는 날은 연휴 시작일인 ‘9월 20일 월요일(39.7%)’이었다. 이어 ‘9월 22일 수요일(30.9%)’, ‘추석 당일 9월 21일 화요일(20.6%)’, ‘3일 전부(8.8%)’ 순이었다.

한편, 이들 직장인 10명 중 3명은 추석 근무에 추가 수당없이 일하는 것으로 조사됐다. ‘근무 중인 회사는 추석 근무에 따른 추가수당이 있는지’에 대한 질문에, 36.8%가 “없다. 평소와 같은 급여가 지급된다”고 답했다.

[출처] https://www.chosun.com/economy/industry-company/2021/09/21/4D3B6XSONJHM3PQPHKSGAOX74I/

 610 total views,  4 views today

17 9월 2021

[時事][시사] 스타벅스 고객예치금 2.3조원, 일반은행 2배… 이제 모두가 경쟁자

[時事][시사] 스타벅스 고객예치금 2.3조원, 일반은행 2배… 이제 모두가 경쟁자

[Cover Story] 산업융합 ‘빅블러 시대’… 이젠 모든 기업이 서로 경쟁자

빅블러시대 이젠 모든기업이 서로 경쟁자/일러스트=안병현
 
빅블러시대 이젠 모든기업이 서로 경쟁자/일러스트=안병현

전 세계 유료 가입자 수 2억900만명(올 2분기 기준)을 자랑하는 세계 최대 OTT(온라인 동영상 서비스) 업체 넷플릭스가 지난 7월 게임 시장 진출을 선언했다. 이 회사는 주주에게 보낸 편지에서 “게임을 오리지널 시리즈(자체 제작한 영화·드라마) 같은 새로운 콘텐츠의 하나로 보고 있다”고 밝혔다. 영화 제작을 넘어 게임까지 직접 개발하겠다는 얘기다. 넷플릭스는 이미 미국 게임사 EA에서 게임 개발을 진두지휘했던 마이크 버듀를 게임 개발 부문 부사장으로 영입했고, 내년 서비스 출시를 목표로 개발팀을 구성 중이다.

넷플릭스의 게임 산업 진출은 요즘 세계 산업계를 휩쓰는 ‘빅블러(Big Blur)’의 최신 사례 중 하나다. 발전한 기술을 매개로, 이종(異種) 산업 간 경계가 무너지며 융합하는 현상이다. 미래학자 스탠 데이비스가 1999년 “ICT(정보통신기술)의 발전 아래 모든 산업은 소프트웨어 산업이 되고, 여러 산업이 한데 섞일 것”이라고 예측하면서 처음 쓴 말이다.

게임 시장 진출을 선언한 글로벌 OTT(온라인 동영상 서비스) 기업 넷플릭스의 로고에 게임 패드를 합성한 사진. / 긱크레이즈
 
게임 시장 진출을 선언한 글로벌 OTT(온라인 동영상 서비스) 기업 넷플릭스의 로고에 게임 패드를 합성한 사진. / 긱크레이즈

다소 설익어 보였던 그 예언이 20여 년이 지난 지금 현실이 되고 있다. 이른바 4차 산업혁명과 신종 코로나 대유행(팬데믹)으로 급격히 진행된 디지털 전환이 글로벌 산업의 거의 전 영역에서 경계의 파괴와 융합을 가속하고 있다. 이로 인해 예전에는 서로 상관이 없거나 협력 관계였던 기업들이 갑자기 경쟁자가 되는 일이 흔해지고 있다. 글로벌 회계 컨설팅 기업 프라이스워터하우스쿠퍼스(PwC)는 “산업 융합(빅블러) 현상으로 모든 산업 분야에서 (타 분야에서 넘어온) 신규 기업 진입이 기하급수적으로 늘고 있다”고 했다.

◇全산업으로 확산하는 빅블러

빅블러가 가장 두드러지는 곳은 빅테크의 타(他)산업 진출이다. 애플과 구글이 단적인 예다. 이 두 회사는 본래 각각 컴퓨터 기업, 검색 엔진 기업이었다. 하지만 스마트폰 분야에 잇달아 진출, 서로 경쟁자가 됐다. 최근에는 반도체 분야에도 진출하면서 인텔·엔비디아와 같이 경쟁하게 됐다. 애플은 작년 11월 PC용 CPU(중앙처리장치)에도 자체 개발한 반도체(M1칩)를 쓰기 시작했고, 구글은 모바일 반도체 ‘텐서(Tensor)’를 자체 개발해 10월 출시될 픽셀6 스마트폰부터 탑재할 계획이다. 두 회사는 모빌리티(이동 서비스) 산업에도 진출했다. 구글의 관계사 웨이모는 지난달 말 미국 샌프란시스코에서 자율주행 택시 시범 운행에 나섰고, 애플 역시 2014년부터 개발해온 자율주행 전기차 기술을 바탕으로 ‘애플카’ 사업을 시작할 것으로 전망되고 있다.

역으로 유통·제조 분야 전통 기업이 IT(정보기술)를 이용해 타 산업으로 진출하기도 한다. 커피 프랜차이즈 스타벅스는 지난해 하나금융과 KB금융그룹, 우리금융 등 국내 대표 금융회사 수장들이 “가장 신경 쓰이는 경쟁자”로 꼽은 회사다. 스타벅스코리아가 전용 앱과 카드 등을 통해 예치한 선불 충전금이 1801억원에 달한다. 이는 국내 주요 핀테크 기업인 토스(1214억원)와 네이버파이낸셜(689억원)보다 많다. 스타벅스가 이런 식으로 전 세계 고객들에게서 유치한 돈은 약 20억 달러(약 2조3380억원)로 추산된다. 미국 FDIC(연방예금보험공사)에 따르면, 미국 내 4500여 은행 중 3900개(87%) 은행의 총 자산이 10억달러가 안 된다. 커피 프랜차이즈가 웬만한 은행보다 2배 이상 많은 돈을 보유한 것이다.

B2B(기업 간 거래)와 B2C(기업과 소비자 간 거래)로 구분되던 기업 간 비즈니스 모델의 경계도 무너지고 있다. 미국 아마존과 한국 네이버는 과거 전형적인 B2C 기업이었다. 개인 소비자의 상품 주문과 검색 서비스 이용에 기반해 수익을 냈기 때문이다. 하지만 이 두 회사는 인터넷 쇼핑몰과 포털 서비스를 만들던 기술로 각각 AWS(아마존웹서비스)와 네이버클라우드라는 클라우드 서비스에 진출, 기업 대상(B2B) 사업을 펼쳐 큰 성공을 거뒀다. 반대로 LG CNS처럼 기업의 IT 서비스를 공급하는 B2B 기업이 개인 정보를 모아 관리해주는 마이데이터(본인신용정보관리업) 사업으로 B2C에 나서는 사례도 나온다.

/그래픽=최하은
 
/그래픽=최하은

◇모두가 경쟁자… 超경쟁 시대 열린다

이러한 빅블러 현상은 예상치 못했던 경쟁자들이 지속적으로 등장하는 초(超)경쟁 시대를 초래하고 있다. 최근 경쟁 기업 수가 급격하게 늘고 있는 전기차 시장이 대표적이다. 테슬라와 BYD 등 초기 전기차 기업에 이어 도요타⋅폴크스바겐⋅현대기아차 등 세계적 자동차 기업들이 전기차 생산 본격화를 선언했고, 수많은 스타트업이 등장한 것도 모자라 애플과 소니, 화웨이와 샤오미 같은 IT 기업들도 뛰어들었다.

심지어 푸드테크(식음료 기술)의 발전과 채식주의 소비자의 증가로 대체육 시장이 커지면서, 수입 쇠고기·돼지고기와 경쟁해왔던 국내 축산 농가들이 이제는 비욘드미트와 임파서블푸드 등 해외 첨단 식품 기업과도 경쟁해야 하는 상황이다. 콩과 버섯, 미생물 등에서 단백질을 추출해 만드는 대체육은 버거킹과 KFC 같은 유명 패스트푸드에도 납품되며 육류 시장을 잠식하고 있다. 시장조사기관 유로모니터는 전 세계 대체육 시장 가치가 작년 기준 207억달러(약 24조2190억원)로 오는 2024년에는 232억달러까지 성장할 것이라고 전망했다.

전통적으로 기업 경영에서 완전히 새로운 분야에 대한 진출은 금기(禁忌)처럼 여겨져 왔다. 베인앤드컴퍼니 등 많은 경영 컨설팅 회사가 “핵심 사업과 관련 있는 분야가 아니면 진출하지 말라”는 조언을 해왔다. 사업 기반과 경험이 전혀 없는 분야는 더 많은 투자를 요구하면서, 동시에 시행착오와 실패 가능성은 크기 때문이다.

이런 상식을 뒤바꿔 놓은 것이 전 산업 영역에 걸친 디지털 전환, 이른바 ‘4차 산업혁명’이다. 판매와 영업, 인사 관리는 물론 이제는 생산과 공급망 관리, 기술 개발에 이르는 거의 모든 기업 활동이 디지털화·자동화되면서 기업의 핵심 인프라이자, 범용 기술로서 IT에 대한 투자를 늘리게 됐다. 시장조사기관 가트너에 따르면, 전 세계 IT(정보기술) 투자는 작년 기준 3조8650억달러(약 4517조4120억원)로 전년 대비 3.4% 증가했다.

기업들은 이렇게 확보한 IT 인프라와 기술 상당 부분을 다른 산업에 진출하는 데 적극적으로 활용하고 있다. 모바일 기기에 쓰던 반도체와 소프트웨어 기술을 전기 자동차의 파워트레인과 기능 제어에 응용하는 것과 마찬가지다. 완성차 기업 역시 차량의 성능과 상품성을 높이기 위해 IT를 적극 도입, 자동차의 모든 기능에 반도체와 소프트웨어를 적극 활용하고 있고, 이를 기반으로 로봇 산업 등에도 진출하고 있다. IT가 신사업 진출의 다리 역할을 하게 된 것이다.

◇신기술 등장과 산업 패러다임 변화

2012년 네덜란드 암스테르담 시내 은행 건물에 들어선 스타벅스 매장(위)과 보스턴다이내믹스의 로봇 제품과 함께 있는 현대차의 수소차 넥쏘(아래). 스타벅스는 선불충전금을 기반으로 예금 산업에, 현대차는 미국 로봇기업 보스턴다이내믹스를 인수하며 로봇 산업에 진출했다. / 트립닷컴·현대자동차
 
2012년 네덜란드 암스테르담 시내 은행 건물에 들어선 스타벅스 매장(위)과 보스턴다이내믹스의 로봇 제품과 함께 있는 현대차의 수소차 넥쏘(아래). 스타벅스는 선불충전금을 기반으로 예금 산업에, 현대차는 미국 로봇기업 보스턴다이내믹스를 인수하며 로봇 산업에 진출했다. / 트립닷컴·현대자동차
 

전문가들은 이처럼 IT에 대한 적극적 투자 외에도, 산업 패러다임의 변화와 신기술의 등장이 빅블러를 가속했다고 본다. 전기차 산업은 산업 패러다임의 등장으로 인한 빅블러의 사례이기도 하다. 기후변화에 따른 탄소 중립 정책이 내연기관 자동차에서 배터리와 전자 장비 기반의 전기차로 산업 패러다임을 전환하면서 전기차 시장이 열렸고, 이를 통해 기존 완성차 업체 외에 IT 분야 기업들이 전기차 시장에 뛰어들 기회가 열렸다.

넷플릭스의 게임 산업 진출은 IT 진보에 따른 빅블러의 사례로 언급된다. 넷플릭스의 OTT 서비스는 세계 어디서나 초고속으로 대용량의 영상 파일을 전송할 수 있는 클라우드 기술의 발전으로 가능해졌다. 여기에 데이터 전송 지연 시간이 극도로 짧은 5G(5세대 이동통신) 기술이 더해지면서, 내용이 미리 정해진 영화뿐만 아니라 사용자(게이머)의 조작에 따라 상황이 바뀌는 게임 영상도 실시간으로 보내 줄 수 있다. 이른바 ‘클라우드 게임’이다. 멀리 떨어진 클라우드에서 실행된 게임을 내 PC나 스마트폰에 영상으로 보여주는 것이지만, 시간 지연이 없기 때문에 마치 내 PC나 스마트폰에서 게임이 돌아가는 것처럼 느껴진다. 그동안 클라우드로 영화 서비스를 해온 넷플릭스 입장에서는 영화를 저장해 놓은 클라우드 서버(대형컴퓨터)를 게임용으로 바꾸면 된다.

스타벅스는 디지털 결제 기술의 발전 덕분에 은행의 경쟁자가 됐다. 모바일 앱으로 커피 주문과 결제를 할 수 있게 되면서 상품권 구매 및 충전 기능을 통해 스타벅스에 ‘돈을 맡겨 놓고 쓰는’ 것이 가능해졌다. 스타벅스는 지난 3월부터 미국 일부 지역에서 가상화폐 결제 앱을 시범 운영하는 등 핀테크 기능을 계속 강화하고 있다.

◇빅테크의 ‘독과점 강화’ 부작용도

빅블러 시대는 그러나 짙은 그림자도 드리우고 있다. 애플과 구글 등 막강한 IT 역량을 갖춘 기업들이 문어발식 사업 확장을 하며 몸집을 불리고 있기 때문이다. 특히 이들이 특정 분야의 독점적 시장 점유율을 바탕으로 사업 확장을 하면서 산업 전체와 국민 경제에 대한 영향력을 키우고, 더 나아가 여러 분야에 걸친 독과점 기업으로 부상하고 있다. 모바일 메신저 시장에서 100%에 가까운 시장점유율을 가진 카카오가 택시 호출과 간편 결제, 콘텐츠 분야로 업종을 확대하면서 소상공인과 중소기업의 비판을 받는 것이 대표적이다.

이 때문에 미국 등 세계 각국 정부가 빅테크에 대한 규제 고삐를 바짝 조이기 시작했다. 미국 의회는 지난 6월 11일 빅테크 반(反)독점 규제 법안을 발의했다. 여기에는 경쟁자를 인수⋅합병해 없애는 ‘킬러 합병(Killer Acquisitions)’에 대해 허가 심사를 강화하는 내용이 포함됐다. 예컨대 페이스북 같은 시장 지배적 플랫폼 사업자가 인스타그램같이 시장에 진입한 지 얼마 안 된 잠재적 경쟁자를 인수할 경우, 시장지배력 확대로 연결되지 않음을 스스로 증명해야 한다.

일각에선 이러한 현상이 빅테크의 해체로 이어질 것으로 본다. 경영컨설팅 기업 지몬-쿠허 앤드 파트너스의 헤르만 지몬 명예회장은 Mint에 “각국 경쟁 당국이 빅테크에 대한 반(反)독점 규제를 강화할 것이 뻔하다”면서 “결국 사업부별로 분사(Spin-off)하거나 해체될 수 있다”고 했다.

◇빅블러 생존 비결은 ‘원천기술’

빅블러가 산업 간의 경계를 무너뜨리고 있다고 해도, 수십년간 쌓은 기업의 핵심 경쟁력이 한순간에 무의미해지는 것은 아니다. 김선재 한국과학기술기획평가원(KISTEP) 연구위원은 “역설적이게도 산업과 기술 경계가 모호해질수록 원천기술의 가치는 더욱 분명해진다”며 “결국 (산업 간 장벽을 넘는) 융합은 핵심기술에서 파생되기 때문”이라고 말했다. 원천기술의 중요성은 애플의 CEO 팀 쿡의 발언에서도 확인할 수 있다. 쿡 CEO는 지난 4월 미국 뉴욕타임스와의 팟캐스트 인터뷰에서 애플카 관련 질문에 “애플은 사업이 통합되는 지점을 찾아내고 그 주변의 핵심 기술을 직접 보유하는 걸 아주 좋아한다”고 했다.

전문가들은 빅블러 시대에 살아남는 기업의 좋은 사례로 일본의 조미료(MSG) 제조업체 아지노모토를 든다. 아지노모토는 세계 최초로 MSG를 개발한 100년 역사의 식품 기업이면서 동시에 현재 반도체 핵심 소재인 ‘마이크로 절연 필름(ABF)’도 독점적으로 공급하고 있다. MSG를 만드는 데 쓰이는 아미노산 화학을 특화시켜 ABF라는 원천기술 개발에 성공한 덕분이다. 아지노모토의 ABF는 현재 인텔·AMD·엔비디아·ARM 등 오늘날 생산되는 대다수의 반도체 제품 회로에 탑재되고 있다. 100년 전 조미료 기술이 오늘날 빅블러를 주도하는 첨단 반도체 산업 기술이 된 것이다.

[출처] https://www.chosun.com/economy/mint/2021/09/17/VQC7WIILLND5ZNE5VNDX46O3YM/

 524 total views,  2 views today

17 9월 2021

스프레드시트를 생산성 도구로…’구글 테이블’ A to Z

스프레드시트를 생산성 도구로…’구글 테이블’ A to Z

Computerworld
아직도 구글의 ‘테이블(Tables)’ 도구를 살펴보지 않았다면 지금 당장 시도해볼 것을 추천한다. 

데이터를 다루는 게 확실히 예전 같지 않다. 현대 컴퓨팅의 선사시대로 거슬러 올라가 보자(대략 2012년 정도를 말하는 것이다). 당시 비즈니스를 체계화하려면 지저분한 스프레드시트와 온갖 복잡한 공식을 관리해야 했다. 그리고 이를 처리하기 위해 ‘공식(formulae)’과 같은 단어를 사용하는 그런 사람이 돼야 했다. 

ⓒJR Raphael/IDG

요즘에는 보통 사람이라면 누구나 코드 없이 정보를 다룰 수 있는 도구가 많아졌다. 이를테면 에어테이블(Airtable)부터 마이크로소프트 리스트(Microsoft Lists), 다른 여러 종류의 고급 데이터 관리 앱까지 최소한의 노력으로 정보를 정리하고 체계화할 수 있도록 해주는 프로그램이 아주 많다. 

당연히 구글도 이 분야에 뛰어들었다. 지난 2020년 9월 구글은 흔히 해왔던 ‘실험(Experiments)’의 일환으로 작업 추적 도구인 테이블(Tables)을 출시했다. 그리고 현재 이 테이블을 본격적인 구글 클라우드 생산성 제품으로 전환하고 있는 중이다. 

다만 최종 버전은 가까운 시일 내에 제공되긴 어려울 전망이다. 하지만 완전히 무료인 베타 버전을 테스트해 구글이 내놓은 요리를 맛볼 순 있다(구글은 내년 중에 출시를 계획하고 있다고 밝혔다).

경쟁 제품과 비교해 테이블의 가장 큰 장점은 단순하다는 것 그리고 구글 생태계와 원활하게 통합된다는 것이다. 여기서는 테이블의 기능과 이것이 어떻게 비즈니스 효율성을 향상시킬 수 있는지 살펴본다. 

기본 사항
구글 테이블을 시작하는 가장 쉬운 방법은 웹 사이트를 열고, 사이트의 왼쪽 사이드바 메뉴에서 ‘템플릿(Templates)’ 탭을 클릭하는 것이다. 그러면 시작 지점으로 사용할 수 있도록 미리 만들어진 테이블 목록이 표시된다. 이를 사용자의 니즈에 맞게 수정할 수 있다.

템플릿은 ‘관리 및 IT(Admin & IT)’, ‘고객 서비스(Customer Service)’, ‘프로젝트 관리(Project Management)’, ‘팀 관리(Team Management)’ 등의 카테고리로 분류돼 있다. 

여기에 프로젝트 추적기, 팀 디렉토리, 회의 참석 관리 시스템과 같이 널리 쓰이는 기능부터 입사 지원자 추적기, 신입 온보딩 조직 센터, 제품 로드맵, 사용자 조사 데이터베이스 등 구체적인 기능까지 찾을 수 있다(심지어는 영업 관련 업무를 위한 기본적인 CRM 설정도 포함돼 있다). 

구글 테이블은 다양한 용도에 적합한 템플릿을 제공한다 ⓒJR Raphael/IDG

비교적 간단하고 그러면서도 널리 사용되는 ‘프로젝트 추적기’를 예로 들어 보겠다. 버튼을 클릭해 템플릿을 워크스페이스로 가져오면 다음과 같은 화면이 나타난다. 

구글 테이블에서 프로젝트 트래커 템플릿을 클릭했을 때 보이는 화면 ⓒJR Raphael/IDG

볼 게 많아 보이는가? 하지만 여기서 유념해야 할 것은 (에어테이블이나 이와 유사한 대부분의 다른 도구와 마찬가지로) 사용자가 실제로 보고 있는 게 결국 스프레드시트에 불과하다는 점이다. 구체적으로 말하자면 추가 서식과 고급 요소가 추가된 더 현대적인 스프레드시트다. 하지만 이를 제외하면 대부분은 열과 행 그리고 셀로 구성된 스프레드시트일 뿐이다.

테이블의 화면 오른쪽 상단에 있는 열(Columns) 버튼을 클릭하면 정확히 어떻게 작동하는지 알 수 있다. 여기에서 기존 열을 편집, 삭제하거나 새 열을 추가할 수 있다. 또 테이블의 모든 열에서 다양한 정보 형식 중 하나를 선택할 수 있다. 

구글 테이블의 열 관련 옵션을 사용하면 데이터가 표시되는 방식을 제어할 수 있다 ⓒJR Raphael/IDG 

‘퍼슨(Person)’ 옵션이 아주 중요하다. 이는 팀 기반 구글 워크스페이스 계정을 사용한다면 특정 동료에게, 개인 구글 계정을 이용한다면 연락처의 특정 지인에게 관련된 행을 할당할 수 있는 기능이다. 어느 쪽이든 기존 설정에 자동으로 연결되고, 누군가를 선택하고 할당할 때 (테이블에) 전체 이름과 프로필 사진이 즉시 표시된다.

구글 테이블을 사용하면 연락처 또는 조직의 사람들과 손쉽게 상호작용할 수 있다 ⓒJR Raphael/IDG

다른 구글 생산성 도구처럼 테이블 내에서 협업이 가능하다. 화면 오른쪽 상단의 공유(Share) 버튼을 클릭해 구글 계정을 가진 다른 사람을 초대할 수 있다. 그런 다음 테이블을 볼 수만 있는지 아니면 코멘트 추가나 편집을 할 수 있도록 할지 결정할 수 있다. 다른 사람과 동시에 테이블에서 작업할 때는 상대방의 작업 내용이 실시간 표시된다. 

구글 생태계 통합에 관해 말하자면 구글 문서와 스프레드시트 문서 등을 포함해 구글 드라이브 스토리지에 있는 파일과 연결할 수 있는 열 유형을 실제 업로드 없이 클릭 몇 번으로 추가할 수 있다. 그러면 테이블을 보고 있는 다른 사람이 브라우저를 종료하지 않고 바로 그 자리에서 해당 파일을 열 수 있다. 

맨 오른쪽 열의 원형 아이콘이 보이는가? 이는 연결된 스프레드시트, PDF, 이미지 파일을 나타내며 모두 구글 드라이브에서 가져온 것이다 ⓒJR Raphael/IDG

테이블을 전통적인 스프레드시트로 사용하는 방법도 간단하다. 화면 왼쪽 상단에 테이블 제목 옆에 있는 점 3개 메뉴를 클릭해서 전체를 구글 스프레드시트로 내보내는 옵션을 찾는다.

그다지 인상적이지 않은가? 걱정할 필요 없다. 테이블 자체에는 필요한 거의 모든 것을 처리할 수 있는 꽤 유용한 보기 옵션이 있다. 

구글 테이블의 보기 옵션(view)
모든 테이블의 맨 위에는 현재 보기 유형을 보여주는 버튼이 있다. 방금 전에 언급했던 작업 추적 예시에서 사용했던 보기는 ‘그리드(Grid)’였다. 하지만 테이블에서 기본적으로 제공하는 보기를 고수할 필요는 없다. 표시되는 버튼이 무엇이든 이를 클릭, 사용할 수 있는 테이블 레이아웃 옵션을 바꿔 선택할 수 있다.

• 그리드 레이아웃(Grid Layout): 지금까지 살펴본 표준 스프레드시트 및 보기다. 가장 기본적인 테이블 보기이며, 아마 가장 자주 사용하게 될 것이다.

• 칸반 레이아웃(Kanban Layout): 데이터를 트렐로(Trello)와 유사한 일련의 카드와 보드로 정리한다. 다양한 범주의 항목을 효과적으로 시각화해주는 보기다. 한 열에서 다른 열로 정보를 끌어다 놓을 수 있으며, 열을 상태 표시기, 타이밍 알림 또는 다양한 작업과 프로젝트에 각기 다른 유형의 범주로 사용하든 상관없이 쉽게 추적할 수 있다. 

테이블의 칸반 보기를 통해 구글 생산성 제품군에서 트렐로를 느낄 수 있다 ⓒJR Raphael/IDG

• 달력 레이아웃(Calendar Layout): 한 달 달력에서 날짜와 관련된 모든 데이터를 유용하게 표시할 수 있다. 언제 무슨 일이 있는지 정확히 확인할 수 있다.

몇 번의 클릭으로 익숙한 달력 그리드에서 모든 날짜 관련 정보를 볼 수 있다  ⓒJR Raphael/IDG

• 대기열 레이아웃(Queue Layout): 모든 열을 요약 목록으로 바꾼다. 더 광범위한 개요를 보고 개별 항목을 클릭해 자세한 정보를 확인할 수 있다. 

데이터를 간단한 목록으로 본 다음 개별 행으로 드릴다운하여 해당 내용을 확인할 수 있다 ⓒJR Raphael/IDG 

• 지도 레이아웃(Map Layout): 테이블 웹 사이트의 오른쪽에 있는 실제 구글 지도 내에서 특정 ‘위치(Location)’ 필드가 포함된 항목을 볼 수 있다. 

이러한 옵션은 사용자가 정보를 구성하고 조작하는 데 있어 다양한 선택지를 제공한다. 이제 테이블에서 가장 인상적인, 시간을 절약해주는 기능을 소개할 차례다. 사용하는 데이터나 테이블 보기의 종류와 관계없이 사용할 수 있다. 

테이블 자동화 방정식
테이블의 가장 큰 장점은 구글 생태계와의 통합과 단순성이라고 말했다. 그리고 그다음으로 큰 장점이 바로 자동화다. 

테이블은 상상할 수 있는 모든 유형의 데이터를 관리할 수 있는 프레임워크를 제공할 뿐만 아니라 정보 관리 체계를 한 단계 높일 수 있는 자동화 시스템을 지원한다. 단 이와 유사한 다른 많은 시스템과 달리 사용 방법이 아주 간단하고, 배우는 데 시간이 거의 필요하지 않다. 

생성한 테이블의 오른쪽 상단에 있는 봇(Bots) 버튼을 클릭하면 된다. 그런 다음 표시되는 패널에서 새 봇(New Bot) 버튼을 클릭한다. 봇의 이름을 지정하고 트리거 선택(Select Trigger) 버튼을 눌러서 자동화를 실행할 시기를 정한다. 현재 5가지 선택지가 있다.

1. 열 값 변경(Column value changes): 선택한 특정 열 내에서 데이터가 업데이트될 때마다 자동화 기능이 실행된다.

2. 시간 기반(Time-based): 매주 월요일 오전 9시 등 특정 시간에 반복적으로 지속적인 작업을 할 때 자동화를 실행할 수 있는 옵션이다.

3. 행 추가(Row added): 첫 번째와 비슷한 트리거다. 그렇지만 특정 데이터가 변경될 때 실행되는 게 아니라 새 행이 테이블에 추가될 때마다 실행된다.

4. 행 제거(Row removed): 명칭에서 무슨 일을 하는지 알 수 있을 것이다.

5. 코멘트 추가(Comment added): 누군가 선택한 열에 코멘트를 남길 때 선택한 작업이 트리거된다.

트리거를 선택하면 테이블의 특정 행으로 자동화를 제한할 수 있는 필터 추가(Add Filter) 버튼이 표시된다. 이 버튼을 클릭하지 않고 행을 선택하면 기본적으로 테이블의 모든 행에 자동화가 적용된다. 

한 단계 더 나아가 특정 열의 데이터가 특정 방식으로 바뀔 때 자동화가 실행되도록 만들 수도 있다. 그리고서 트리거 조건이 충족될 때 실행될 작업을 선택하면 된다. 

구글 테이블의 봇 시스템은 자동화 생성 프로세스를 안내하고 모든 종류의 고급 인텔리전스를 작업 공간에 쉽게 추가할 수 있도록 한다 ⓒJR Raphael/IDG

이를테면 테이블에서 사전에 지정한 주소나 테이블의 주소로 사용자 지정 이메일을 보내게 만들 수 있다. 특정 방식으로 행을 업데이트하거나, 행을 삭제 또는 추가하도록 할 수 있다. 데이터를 다른 앱에 데이터를 보낼 수도 있다. 

20초가량이면 작업이 완료될 때마다 업데이트를 모든 팀 구성원에게 이메일로 보내도록 테이블에서 설정할 수 있다 ⓒJR Raphael/IDG

그렇다. 아주 쉽게 이런 일을 할 수 있다.

결론
현재 구글 테이블은 무료로 사용할 수 있다. 사용량 및 기능 제한을 없앤 유료 서비스가 있긴 하지만 지금은 웹사이트 내의 버튼을 클릭하기만 하면 별도의 수수료 없이 유료 서비스로 업그레이드할 수 있다. 테이블 실험 초기에는 사용자당 10달러의 비용을 받았다. 이는 베타 서비스가 끝날 때 해당 도구가 어떤 방향으로 나아갈지 알려준다. 

물론 구글이 장기적으로 테이블에 투자할지에 관한 의문을 제기할 수 있다. 그동안 구글이 중요하지 않은 서비스(특히 기존 서비스와 어떤 방식으로든 중복되는 서비스)를 포기했던 역사를 감안한다면 타당한 우려다. 

하지만 현재까지 테이블은 생산성을 향상시킬 수 있는 잠재력이 무궁무진한 유망 서비스로 판단된다. 따라서 이미 구글 생태계를 사용하고 있고 효과적으로 작업을 추적 및 자동화하길 원한다면 테이블은 시험해볼 가치가 있는 도구다. 

JR Raphael은 컴퓨터월드 객원 편집자다. 기술의 인간적 측면에 큰 관심을 가지고 있다. ciokr@idg.co.kr

[출처] MS, 기업용 오피스 영구 버전 ‘오피스 LTSC’ 프리뷰 출시 – CIO Korea

 398 total views,  2 views today

17 9월 2021

칼럼 | 하둡의 실패 넘어선다··· 오픈 데이터 분야를 견인하는 4가지 기술 동향

칼럼 | 하둡의 실패 넘어선다··· 오픈 데이터 분야를 견인하는 4가지 기술 동향

IDG Connect
기업들이 방대한 양의 데이터를 수집하고 있다. 이를 제대로 활용하기 위해서는 수십, 수천 개의 서로 다른 데이터 소스와 여러 다른 데이터 형식으로부터 통찰을 추출해낼 수 있어야 한다. 이러한 가운데 오픈 데이터 생태계와 관련된 빅데이터 기술이 눈길을 끌고 있다. 오픈 데이터 생태계가 부상하는 이유가 뭘까? 그리고 이 기술 트렌드가 기업의 미래 경쟁력으로 어떻게 이어질 수 있을까?

수준 높은 애널리틱스와 AI 이니셔티브를 추진함으로써 대량의 데이터를 분석해 우수한 고객 통찰을 도출하고 가치 있는 질문들을 해결할 수 있기를 수많은 기업들이 바라고 있다. 이러나 이러한 결과를 실현하려면 기업은 우선 구조적 및 비구조적이고, 다양한 형식인 이질적 데이터 출처와 씨름하면서 통찰을 도출해야 한다. 그리고 이는 간단한 일이 아니다. 

지난 20년 동안 여러 기술이 이 문제를 해결할 수 있다고 약속했고 실패했다. 대표적인 것이 2000년대 중반의 하둡(Hadoop)이다. 

하둡 이전의 유일한 선택지는 거대한 리소스를 가진 온-프레미스 데이터베이스였다. 이는 데이터를 신중하게 모델링하고, 스토리지를 관리하고, 가치를 평가하고, 이들을 연결하는 방법을 파악하는 일을 요구했다. 

이와 달리 하둡은 데이터 레이크, 오픈 데이터 표준, 모듈식 첨단 소프트웨어 스택, 그리고 고객을 위해 가치를 견인하는 경쟁적인 데이터 관리 벤더로 이루어진 오픈 데이터 생태계를 주창했다. 

하둡 운동과 아파치 유형의 프로젝트는 오픈 데이터 생태계라는 발상을 진전시켰지만 아래의 3가지 이유 때문에 궁극적으로 실패했다. 

• 하드웨어를 구입하고 확장하고 관리하는 비용이 지나치게 비쌈
• 애플리케이션과 데이터 레이크 간의 공통 데이터 포맷의 결여로 인한 데이터 관리 및 이용의 난해함 
• 데이터 관리에 이용할 수 있는 툴 및 스킬의 부족 

하둡의 성과는 실망스러웠지만 그럼에도 불구하고 오픈 데이터는 다시 부상하고 있다. 그리고 이번에는 새로운 오픈 데이터 생태계 기술이 하둡의 단점을 해소하며 기업 내의 모든 데이터 범위를 아우르고 있다. 

그렇다면 왜 지금 이런 일이 일어나는가? 4가지 핵심적인 기술 동향이 오픈 데이터 생태계의 부활을 이끌고 있기 때문이다. 

Image Credit : Getty Images Bank

1. 클라우드 스토리지의 성장 
클라우드 데이터 스토리지, 다시 말해 아마존 S3, 애저 데이터 레이크 스토리지(ADLS), 구글 클라우드 스토리지(GCS)의 급속한 성장은 구조적 및 비구조적 데이터 레이크를 대량으로 수용할 수 있음을 의미한다. 

1세대 시스템은 온프레미스 연산 및 스토리지 시스템을 구축하는 데 큰 자본을 요구했다. 유지 관리가 값비쌌고 확장하는 데에는 훨씬 더 많은 비용이 들었다. 

그러나 클라우드 스토리지는 데이터 스토리지 문제로부터 값비싼 온프레미스 하드웨어를 제거했다. 대신 리소스 기준 과금이 도입되면서 기업들은 사용한 스토리지에 대해서만 비용을 지불하면 된다. 그리고 가격이 하락하면서 클라우드 스토리지 서비스는 데이터의 기본 정착지가 되었다. 범용적인 기록 시스템(System of Record, SoR)이 되는 것이다.

오늘날의 기업에게 클라우드의 예측 가능한 성능 및 유연성은 가속 쿼리 이행 등의 데이터 역량을 현실화하고, 복제를 회피하고, 데이터 레이크의 감독 및 관리를 개선하는 데 있어서 핵심적이다. 

2. 대세화된 오픈소스 데이터 포맷 
프로그래밍 언어 및 구현물 전반을 아우르는 데이터 호환성을 위해 오픈 데이터 포맷을 채택하는 기업이 많아지고 있다. 

오픈 스토리지 데이터 포맷, 예를 들어 아파치 파케이(Apache Parquet: 컬럼 지향 데이터 스토리지), 아파치 애로우(Apache Arrow: 애널리틱스, 인공지능, 머신러닝을 위한 메모리 포맷), 아파치 아이스버그(Apache Iceberg: 표 포맷/트랜잭션 레이어) 등은 현재 및 미래의 모든 툴에서 데이터를 이용할 수 있음을 의미하고, 비호환성으로 인한 벤더 속박을 해소한다. 

기업들은 즉시 이용할 수 있는 오픈 포맷으로 데이터를 대량으로 저장할 수 있고, 이와 연관된 비즈니스 애널리틱스와 AI 워크로드를 직접 실행할 수 있다. 데이터 변환을 요하는 길고도 값비싼 소프트웨어 구현이 필요하지 않다. 

이는 오늘날의 기업에게 특히 매력적이다. 왜냐하면 API ‘플러그 앤 플레이’ 데이터 분석 및 AI 툴, 예를 들어 H20데이터로봇(DataRobot) 등은 구현하고 결과를 보는 것이 빠르고 쉽기 때문이다. 

3. 클라우드 네이티브 벤더 지원의 성장 
2000년대 중반 하둡은 데이터 스키마, 소비, 및 관리에 구애받지 않고 데이터를 레이크에 무차별적으로 투척할 수 있게 해주었다. 

기업들은 아키텍처 설계, 액세스, 애널리틱스, 지속가능성을 고려하지 않은 채 더 많은 데이터를 수집하는 데에만 열중했다. 이들은 데이터 레이크 안에 무엇이 있는지 알지 못했고, 이들을 관리하거나 가치를 추출하는 법도 알지 못했다. 이런 문제를 해결할 툴이 나오지 않은 상황에서 데이터 레이크는 데이터 늪으로 변했다. 

그러나 오늘날 특정한 데이터 관리 문제를 처리하는 데 도움을 주는 벤더와 툴이 수없이 생겨났다. 데이터 관리 분야는 급속히 성장 중이고, 데이터 스트리밍, 변환, 가시성, 품질, 거버넌스, 최종 이용자의 소비에 걸쳐 솔루션이 속속 가세하고 있다. 

드레미오(Dremio), 트리노(Trino) 같은 회사는 클라우드 데이터 레이크에서 SQL 쿼리를 직접 운영한다. 세그먼트(Segment), 마틸리온(Matillion) 등의 회사가 가진 기술은 데이터를 흡수해 오픈 포맷으로 작성한다. 그리고 에어플로우(Airflow), 퍼펙트(Perfect), 대그스터(Dagster) 등의 플랫폼은 데이터 오케스트레이션을 취급한다. 이들 벤더들이 경쟁하면서 오픈 데이터 생태계에서의 운영은 갈수록 쉬워지고 있다. 

기업들이 어떤 기술로 자신의 데이터 인프라를 운영할 것인지를 결정함에 있어 기성 벤더와 전문 스타트업은 각각 장점과 단점을 가지고 있다. 올바른 진로를 선택하는 데에는 아래와 같은 차이를 고려하는 것이 좋다. 

• 통상적으로 기성 벤더는 한층 우수한 온-프레미스 호환성을 제공한다. 그러나 최고 수준의 전문 스타트업 툴이 가진 기능성이 부족하다. 
• 통상적으로 최고 수준의 전문 스타트업 솔루션은 한 분야에서 차원 높은 기능성을 가지고 있지만 보안, 거버넌스 등 기업 요구사항을 충족하는 면에서 성숙도가 떨어진다. 

4. 애플리케이션이 적정 고도에서 이용자와 만나고 있다
데이터 애널리스트, 과학자 및 현업 이용자는 수작업 스키마 변경, 리소스 프로비저닝, 여타 데이터베이스 관리의 하부에서 이루어지는 데이터 작용에 별로 관심이 없다. 그러나 이러한 작업은 1세대 오픈 데이터 생태계에서 필수적이었다. 

오늘날에는 수직적으로 통합된 툴에 추상화가 매립되어 있고, 이는 최종 이용자가 자신이 원하는 통찰 수준에서 작업을 할 수 있도록 도움을 준다.  

애플리케이션이 계속 진화하고, 기업들의 데이터 역량이 다각화되면서, 한층 정교해진 이용자들은 수준 높은 유연성과 깊이를 추구할 것이다. 

오픈 데이터 생태계는 기나긴 여정
이들 4가지 동향이 오픈 데이터 생태계의 부활을 견인하는 가운데, 이들은 스노우플레이크(Snowflake) 등 소유권적 클라우드 데이터 웨어하우스의 성장을 촉진하기도 했다. 

모든 워크로드를 아우르는 단일 데이터 웨어하우스라는 스노우플레이크의 접근법이 유일한 미래의 길이라고 주장하는 사람들이 있다. 그러나 시간이 지나면서 애플리케이션 개발이 단일 아키텍처로부터 API 기반의 마이크로서비스 아키텍처로 변화하고 있는 것처럼 데이터 애널리틱스 워크로드는 소유권적 데이터 웨어하우스로부터 오픈 데이터 아키텍처로 점진적으로 이동할 것으로 예상된다. 

요약 : 오픈 데이터가 어느 때보다 기업들에게 한층 접근 가능해짐에 따라 그야말로 흥미로운 시기에 접어들고 있다. 클라우드 데이터 레이크, 데이터 관리, 오픈 데이터 포맷 등 하둡의 단점에 대처하는 기술을 바탕으로 기업들이 마침내 조직 내에서 데이터를 완벽히 포착하고 이용할 수 있는 환경이 조성되면서 빅 데이터의 비전이 다시 활기를 찾고 있다.

*캐스버 왕은 사파이어 벤처의 부사장이다. ciokr@idg.co.kr

[출처] 칼럼 | 하둡의 실패 넘어선다··· 오픈 데이터 분야를 견인하는 4가지 기술 동향 – CIO Korea

 363 total views,  2 views today

22 8월 2021

KT의 프로젝트 [KT MY KT 엡] 마이 케이티 앱 프로젝트 2021-06 : 비정상, 접속오류, 고객센터

KT의 프로젝트 [KT MY KT 엡] 마이 케이티 앱 프로젝트 2021-06 : 비정상, 접속오류, 고객센터

 : 오늘의 유머 : 일간베스트(일베) 

아래 자료문서 

2021-06 [KT 온라인채널 고객경험 혁신 my kt앱 고도화 프로젝트] 결론 자료파일 다운

2021-06 [KT 온라인채널 고객경험 혁신 my kt앱 고도화 프로젝트] 결론
 
  1. 우선 예상하는 KT 에서 기획한 내용을 나름 분석하면
    1. 기존 MY KT 앱의 analytics를 분석하여, 사용자가 가장 많이 사용하는 기능(통신 사용량조회, 영화예메, 포인트 활용, 쿠폰 사용: 혜택)만들 남기고 최대한 사용성 (UX)를 이끈다는 기획이였던것으로 여겨지나.
    2. 문제는 미래지향적인 사용자 통계 분석(analytics에 기반한) 에 비해
    3. 아마추어적인 UX 기획으로 풀다운 메뉴에 길들여진 사용자들에게 하단 에니메이션 메뉴바를 도입
    4. 메뉴바에서 사용자들이 가장 궁금해하고 많이 사용하는 “사용량 조회”의 기능을 보여주는 메뉴를 “마이”라는 개발이나 IT 전문가에게 예상할 수 있는 이름을 붙여 일반사용자에게 “사용량조회”를 찾지못하는 설계가 되었고
    5. 한페이지에 고정된 것이 아닌, 세로방향 무한스크롤 같은 모바일 앱 에서 하단 메뉴에 사용자들이 익숙지도 않으며 ,
      1. 하단에 네이게이션 메뉴가 나오며 , 메뉴가 좌우 상으로 펼쳐지며
      2. 좌우 메뉴을 터치시 화면 전환이 되며,
      3. 좌 또는 우 메뉴로 갔다가 메인으로 돌아오려면 다시 하단에 x 표시로 된 메뉴로  화면을 닫는다는
      4. 방식은 개발자가 아니면 알기 쉽지 않는 네비게이션이며
      5. 사용자들이 가장 보고싶어하는 “사용량”조회시
      6. 무리한 정준기의 카드시스템 도입으로, 화면이 껌뻑이는 플리킹 발생 및 표출되는 데이터가 맞지 않는 앱이됨
      7.  
    6. 화면설계도 KT의 매출액 증대가 목적인지 대부분 카드광고로 이루어져, 사용자는 사용량 및 계약관계 정보를 얻으려 MY KT app을 구동하지, 마케팅 광고 구독 목적이 아닌데도 80%이상을 마케팅 광고로 도배된 앱을 기획했으며
    7. 게다가 기존 기능을 디자인만 바꾼다는 명목으로 개발하면서, 기존 기능과 호환되지 않는
    8. 사용량조회 내역을 도입, 표출되는 정보가 정확하지도 않고, (데이터 함께 쓰기 회선에 통화량출력)
    9. LTE 에그 사용량이 모바일 웹에서는 나오는데, 모바일 앱 화면에서는 나오지 않으며
    10. 사용자가 사용량조회에서 원하는 것은 결국 사용량 조회가 아니라 남!은! 가용한 사용량 조회에 더 관심이 있는데도, 사용량 조회에 초점을 맞추며
    11. 기획에도 없고 설계에도 없는 카드 시스템을 정준기가 꿋꿋이 요구하면서
    12. 개발된 기능에 막대한 장애와 정준기 지가 스스로 개발해도 퍼블에 맞지않고
    13. 로그인 기능을 IMUI(아이엠 유아이) 에서 기능 변경(개선)으로 작업을 했으나 로그인 불안정을 초래하여 사용자가 로그인 할 수 없는 결과(네이티브 모바일 앱과 부정합)를 초래하고
    14. 네이티브 모바일 앱 개발자들의 개발 실수(오류)로 앱이 불안정하여 비정상 종료를 반복하며
    15. 새로 KT에서 투입한 개발진(고급,특급) 을 몰아내려는 기존 유지보수 개발자의 욕심으로 투입된 개발진이 개발 정보를 얻지못하여 개발 진행이 공전되고
    16. 급기야는 투입된 고급 개발자들 몰아내고 유지보수개발진이  자신있게 개발하려다, 유지보수 개발진 (에이엔티 솔루션 (주))의 역량을 검토한 결과 저비용을 위해서 초급, 하급 개발진으로 (서울공고_조형예술대출신, 전남대 재료공학, 신학대학_방통대)의 역량 미숙의 유지보수 개발진이 나서서 개발하여 시스템과 앱의 완성도가 형편없이 되었으며
    17. PM을 맡은 정인섭(서울공고, 계원 조형예술대학출신)이 몰엽치한, 비양심적 거짓말 행각으로 추진하는 사업이니, 결과야 안봐도 뻔하다.
    18. 앱에 게임처럼 게이미피케이션인지 이리저리 터치구동해보고 기능을 깨닫은 앱을 기획한 어처구니 없는 실수로 게이머가 대부분이 아닌 모바일 앱 사용에 사용자들은 원하는게 메뉴에 있고 메뉴를 클릭하여 해당정보를 얻는다는 게시판 식 문회의 게이머 이외의 사용자에겐 어처구니 없는 앱이 되버림
    19. 개발 중에서도 로컬 개발 노트북과 테스트를 위한 개발 서버를 교차 할 때, ctrl H 로 기존 로그인 캐쉬 비워야 로그인 되더니, 업데이트 하니까. 기존 로그인 정보가 새 로그인 정보와 맞지 않고, 업데이트로 되지 않아 로그인 불안정 생김
    20. 2021-07-26 아직 저속 저용량의 3G 사용자와 블루투스 테더링 사용자도 존재하는데 마케팅 광고 대용량의 이미지 베너 도배로 50mb에 달하는 트래픽 유발로  느린 최악의 앱으로 사용자들에게 윈성을 삼

 483 total views,  6 views today