22 11월 2021

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 33 total views,  9 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/

 192 total views

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/

 152 total views,  4 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

 152 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

 174 total views

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에 달하는 트래픽 유발로  느린 최악의 앱으로 사용자들에게 윈성을 삼

 68 total views,  4 views today

23 5월 2021

[profit, 수익] 1100조원이 사라졌다, 가상화폐 시총 2주일새 42% 증발

[profit, 수익] 1100조원이 사라졌다, 가상화폐 시총 2주일새 42% 증발

 윤진호 기자

/그래픽=김성규
 
/그래픽=김성규

전 세계 가상 화폐 시가총액이 지난 2주 동안 1100조원 넘게 증발한 것으로 집계됐다. 중국, 미국 등 각국 정부가 규제 대책을 발표하고, 유럽중앙은행(ECB) 등이 가상 화폐 거품 우려를 내놓고, 테슬라의 비트코인 결제 중단 등이 이어진 데다 전문가들의 가상 화폐 시장 과열 경고가 꼬리를 물면서 단기간에 악재가 쏟아졌기 때문이다.

23일 가상 화폐 정보 사이트 트레이딩뷰에 따르면, 이날 오후 6시 기준 전 세계 가상 화폐 시장 시가총액은 1조3960억달러(약 1573조원)다. 역대 최고점을 찍었던 5월 8일(2714조원)보다 1141조원(42%) 줄었다.

국내 코스피 시총 1~10위 기업인 삼성전자(478조원), SK하이닉스(89조원), LG화학(63조원), 네이버(59조원), 삼성바이오로직스(56조원), 카카오(51조원), 현대차(48조원), 삼성SDI(44조원), 셀트리온(37조원), 기아(33조원)를 합친 958조원을 훌쩍 넘어서는 금액이다.

◇중국 “가상 화폐 타격하겠다”

가상 화폐 대표 격인 비트코인은 23일 국내 거래소에서 4000만원 중반대에 거래됐다. 역대 최고치였던 4월 14일(8199만원)의 절반 수준이다. 지난 12일 541만원까지 치솟았던 가상 화폐 시총 2위 이더리움 역시 280만원대까지 주저앉았다. 주요 가상 화폐 가격은 휴일인 22~23일 10% 안팎씩 급락했다.

이런 와중에 가상 화폐 신규 발행과 거래에 이어 일부 지역에서 채굴까지 금지한 중국 정부는 고강도 규제 방침을 이어갔다. 지난 21일 중국 국무원 금융안정발전위원회는 “가상 화폐 채굴과 거래 행위를 타격하겠다”고 밝혔다. 이 소식이 알려진 지 10분 만에 비트코인 가격은 5%(2000달러) 이상 급락했다. 투자자들 사이에선 중국이 전국 채굴장을 모두 문 닫게 만들 수도 있다는 우려까지 나왔다.

이처럼 가상 화폐 가격이 급락하는 중인데 세계 최대 전기차업체 테슬라 최고경영자(CEO) 일론 머스크는 연일 가상 화폐 옹호 발언을 하면서 시장을 혼란하게 만든다는 지적을 받고 있다. 머스크는 22일(현지 시각) “충분히 진보한 어떤 마법은 기술과 구별할 수 없다”는 글을 올렸는데, 투자자들은 “당신 때문에 돈을 잃고 인생을 망쳤다” 등 그를 성토하는 댓글을 달았다. 머스크는 이들에게 “진정한 전투는 법정 통화와 가상 화폐 사이에 있다. 나는 후자를 지지한다”면서 가상 화폐를 옹호하는 댓글을 달았지만, “너는 (우주 개발로 추진 중인) 화성에 가는 대신 감옥에 갈 것”이라는 등 댓글이 달렸다.

◇이 와중에 일부 김치코인 급등 기현상

글로벌 주요 가상 화폐인 비트코인, 이더리움 등이 일제히 추락하고 향후 전망도 불투명해지면서 일부 투매까지 벌어지는 등 가상 화폐 시장이 난장판으로 변해가고 있지만, 국내에서만 거래되는 ‘김치코인’ 가운데 일부는 급등하는 기현상이 벌어지고 있다. 업비트에 따르면, 센티넬프로토콜은 21일 574원까지 올라 신고가를 기록했다. 전 거래일 대비 무려 359.2% 치솟은 것이다. 디마켓이라는 코인도 23일 전 거래일 대비 154.5% 오른 2990원으로 최고가를 갈아치웠다.

◇2018년 폭락보다 하락률은 낮아

가상 화폐 전체 시총이 지난 2주간 42%나 추락했지만, 지난 2018년 대폭락 당시보다 하락률은 낮은 상태다. 2018년의 경우 1월 7일 780조원 수준이던 가상 화폐 시장 규모가 한 달 뒤인 2월 5일 325조원으로 58.2%(455조원) 감소했다. 2020년에도 2월 14일 340조원이던 가상 화폐 시총이 3월 12일 153조원으로 한 달 새 55% 줄어든 적이 있다. 이병태 카이스트 교수는 “가상 화폐 버블이 꺼지고 종말이 오는 것처럼 보이지만 사실 비트코인 가격 변동성은 언제나 널뛰듯 해왔다”며 “늘 있는 일이라고 봐야 한다”고 말했다. 반면, 이더리움 창시자인 비탈릭 부테린은 CNN 인터뷰에서 “가상 화폐에 거품이 있다고 생각한다”며 “거품은 이미 끝났을 수도 있고 지금부터 몇 달 후일 수도 있는데, 예측하기가 매우 어려운 상황”이라고 말했다.

[출처] https://www.chosun.com/economy/stock-finance/2021/05/23/OY4KFP6YYFGLLGWLTNXZHFLQDA/

 216 total views

19 5월 2021

[IT 혁신디바이스/소프트웨어] 인간보다 말 잘하는 AI 나왔다… 구글 새로워진 AI ‘람다’ 공개

[IT 혁신디바이스/소프트웨어] 인간보다 말 잘하는 AI 나왔다… 구글 새로워진 AI ‘람다’ 공개

[김성민의 실밸 레이더]
구글, 연례 개발자회의 개최
강화된 AI, 사용자 맞춤형 디자인, 삼성전자와의 동맹

18일(현지시각) 순다르 피차이 구글 CEO가 구글I/O(연례 개발자회의)에서 이야기하고 있다. /구글
 
18일(현지시각) 순다르 피차이 구글 CEO가 구글I/O(연례 개발자회의)에서 이야기하고 있다. /구글

“날 찾아오면 거대한 협곡과 약간의 빙산, 간헐천과 분화구를 볼 수 있어.”

18일(현지시각) 구글의 한 엔지니어가 인공지능 대화 모델 ‘람다(LaMDA)’를 적용한 행성 명왕성에게 “너를 찾아가면 뭘 볼 수 있니”라고 묻자 이렇게 답이 돌아왔다. 구글의 AI가 자신이 명왕성인것처럼 자연스럽게 답변한 것이다. 람다는 ‘대화 언어 모델(Language Model for Dialogue Applications)’의 약자로, 기능을 고도화해 답이 없는 질문에도 인간과 같은 자연스러운 대화가 가능한 AI 언어 모델이다. 순다르 피차이 구글 CEO는 “람다는 미리 정의된 답변을 학습하지 않아 자연스러운 대화를 할 수 있다”며 “어떤 대화도 수행할 수 있다”고 했다.

구글은 이날 미국 캘리포니아 마운틴뷰 본사에서 온라인으로 ‘구글 I/O(연례 개발자회의) 2021’을 가졌다. 구글 I/O는 매년 구글의 방향성과 새로운 제품, 기술을 발표하는 자리다. 이날 가장 눈길을 끈 것은 AI 언어모델 람다였다.

구글 람다 시연 모습
 
구글 람다 시연 모습

◇답 없는 질문에도 사람처럼 이야기하는 AI

구글은 올해 개발자회의에서 AI(인공지능) 기능을 크게 강화한 서비스를 대거 발표했다. 그중 하나인 람다는 사람의 대화 방식을 이해하고 정답이 없는 질문에도 알맞게 대화한다. 이날 람다가 적용된 행성 명왕성과 종이비행기가 인간의 질문에 답을 하는 모습이 시연됐다. AI 람다가 자신을 명왕성이나 종이비행기로 인식하고 인간의 추상적인 질문에 알맞게 대화한 것이다. 구글은 이 기술을 음성인식 비서인 구글 어시스턴트와 검색 기능 등에 도입할 계획이다.

구글의 강화된 AI 기능은 여러 분야에 적용되고 있다. 구글은 이날 피부 트러블이 있는 부분을 사진으로 찍으면 현재 사용자의 피부 상태와 증상, 치료법 등을 자동으로 분석해 소개하는 헬스케어 툴도 발표했다. 구글맵에서는 도로가 막혀 운전자가 여러 차례 급정거를 해야 되는 도로를 추정하고 분석해 새로운 길을 안내하는 기능도 도입한다.

사용자 맞춤형 디자인이 적용되는 안드로이드12 모습. /구글
 
사용자 맞춤형 디자인이 적용되는 안드로이드12 모습. /구글

◇사용자 맞춤형 화면 디자인 제공

구글은 이날 새로운 디자인의 스마트폰 OS(운영체제)인 ‘안드로이드12’도 발표했다. ‘머티리얼 유(Material You)’라 부르는 기능을 탑재해 사용자가 스마트폰 배경화면을 선택하면 안드로이드가 자동으로 그에 어울리는 화면 색조와 잠금화면, 위젯 디자인으로 설정을 바꿔준다. 사용자 맞춤형 화면 디자인을 제공하는 것이다.

개인정보 보호 기능도 크게 강화된다. 날씨 앱 등에서는 이용자의 대략적인 위치만 알려줘도 날씨가 표시된다. 또 어떤 앱이 사용자의 위치 정보나 사진 등을 수집하고 있는지 한 화면에서 확인하고 이를 통제할 수 있다.

스마트폰으로 자동차 문을 열 수 있는 디지털 자동차 키 기능도 도입된다. 구글 픽셀폰과 삼성 갤럭시폰 일부 모델에서 스마트폰으로 시동까지 걸 수 있게 지원한다는 계획이다. 구글은 이를 위해 현재 BMW와 다른 완성차 업체와 협업 중이라고 밝혔다.

18일 열린 구글I/O 모습. 소수의 구글 직원들만 미 캘리포니아 마운틴뷰 본사에서 오프라인으로 참석했고, 모든 행사는 온라인으로 진행됐다. /구글
 
18일 열린 구글I/O 모습. 소수의 구글 직원들만 미 캘리포니아 마운틴뷰 본사에서 오프라인으로 참석했고, 모든 행사는 온라인으로 진행됐다. /구글

◇웨어러블 OS에서 삼성전자와 손잡아

구글은 스마트워치에 탑재되는 자체 웨어OS와 삼성전자의 타이젠을 결합한 ‘웨어러블 통합 플랫폼’을 만들기로 했다고 밝혔다. 하나의 OS로 애플워치와 아이폰, 아이패드가 연동되는 애플처럼 구글과 삼성전자가 손을 잡고 구글 안드로이드 기반으로 스마트워치와 스마트폰 연동성을 확장하겠다는 것이다. 구글과 삼성전자가 손잡고 개발하는 통합 OS는 올 가을 출시되는 삼성전자의 갤럭시워치4에 탑재될 예정이다. 구글은 “통합 OS는 기존보다 앱을 최대 30% 빠르게 구동하고, 소비전력을 낮춰 배터리 수명을 늘릴 것으로 기대된다”고 밝혔다.

IT 업계에서는 삼성전자가 그동안 밀고 갔던 타이젠이라는 독자 OS를 접으며 과감히 결단했다고 평가한다. 미 IT 매체 씨넷은 “삼성전자와 구글의 협력은 웨어러블 분야의 ‘저스티스 리그’처럼 보인다”며 “애플워치에 정면으로 맞서기 위해 안드로이드 스마트워치가 큰 변화를 맞고 있다”고 했다.

프로젝트 스타라인. /구글
 
프로젝트 스타라인. /구글

◇효율적인 연결 추구

구글은 코로나 시대를 맞아 유용한 도구도 소개했다. 바로 ‘스마트 캔버스’다. 재택근무를 하는 사람들이 구글독스, 구글시트, 구글슬라이드를 사용하며 바로 구글 미트 화상 통화를 할 수 있게 해준다. 문서 하나에 여러 협업툴을 합친 것이다. 특히 여러 문서 창과 영상 통화 창을 사용자가 원하는 대로 크기와 위치를 조절할 수 있다.

구글은 실시간 3D 이미지 처리 기법 등을 통해 멀리 떨어진 사람과 영상통화를 하며 실제 얼굴을 마주보고 이야기하는 것과 같은 느낌을 주는 ‘프로젝트 스타라인’도 소개했다. 3D 심도 센서가 필요해 별도의 전용 기기가 있어야 하지만, 현실 재현감이 뛰어나다. 구글 포토에서는 2개의 사진을 연결해 움직이는 이미지를 만드는 기능도 추가된다.

[출처] https://www.chosun.com/economy/tech_it/2021/05/19/VGPQHTFUP5D35GZDTTA67N36XI/

 321 total views

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

 250 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

 240 total views,  2 views today