1 6월 2014

弘益人間 (홍익인간)

사용자의 삶의 만족도를 높이고 불쾌함과 짜증을 감소시키는 견고하고 에러없는 소프트웨어 개발을 목표로 세월이 지나도 혁신적인 활동을 “에스 테크 스타 닷컴”은 이어갑니다.  좋은 소프트웨어 창출로 정보기술의 弘益人間 (홍익인간)을 구현합니다.


 

 

 

 

 

혼자가 아닌 나!


 

 5,538 total views

1 6월 2014

comphy’s profile

2014년
대한민국 공군 사이버전실습 및 대응체계 개발:평택공군제7전대
에스테크스타닷컴 에스천사게임즈 오픈
ebook 출판 예정

2013년
KT BIT OSS 프로젝트

2012년
삼성전자 가전사업부 표준화파트너 시스템 개발 (Java,JSP,Oracle)
행안부 종합장애대응체계 / 복지부 행복e음 유지보수

2011년
삼성전자 스마트그리드 서버 및 스마트TV 앱 검증 서버
삼성bada 2.0 검증 어플리케이션 개발 (MWC2011출품)

2010년
[LGU+] 패킷관련 프로젝트
[수원,구미] 삼성전자 MMP 프로젝트 (터치모바일플랫폼) : 피쳐폰의 스마트화

2009년
[천안] 삼성코닝 정밀유리 : S-Contour 프로젝트

2008년
삼성전자 소프트웨어연구소 QMO과제 수행

 6,428 total views,  2 views today

19 4월 2012

네 시작은 미약하였으나 네 나중은 심히 창대하리라.

네 시작은 미약하였으나 네 나중은 심히 창대하리라.

Your beginnings will seem humble, so prosperous will your future be….

나라장터 조달업체 등록 : 2014-07-04

한국SW산업협회 소프트웨어사업자등록 : B14-87964

출판업 신고 : 수지구청 제 123호

통신판매업 신고 : 제2012-용인수지-0185호

사업자 신고 : 용인 142-07-27414

sjkim_cc

 

 

 6,931 total views,  2 views today

13 5월 2999

Web Cloud & mobile App Business working Link

Web Cloud & mobile App Business working Link

  1. Biz Design Workplace
  2. Biz marketing tools Workplace
  3. Biz reference datas
    1. 프리렌서 업무 [크몽] : https://kmong.com/
    2. 모바일 앱 시장조사 [와이즈앱] : https://www.wiseapp.co.kr/
    3. 프리렌서 업무 [위시켓] : https://www.wishket.com
    4. 프리랜서 업무 [프리모아] : http://www.freemoa.net/
    5. 프리렌서 업무 [이렌서] : http://www.elancer.co.kr/
  4. Biz online Developing tool
  5. cloud developer console
    1. microsoft azure : https://azure.microsoft.com/ko-kr
    2. google developer console : https://console.cloud.google.com/?hl=ko
    3. amazon AWS : https://aws.amazon.com/ko/console/
  6. Mobile App Biz market
    1. android developer console : https://play.google.com/apps/publish/?hl=ko
    2. onestore (T Store) : http://dev.onestore.co.kr/devpoc/index.omp
    3. apple app store : https://developer.apple.com/app-store/
  7. 지적재산권 등록
    1. 특허정보검색(KIPRIS) : http://www.kipris.or.kr/khome/main.jsp
    2. 특허로(특허출원) : http://www.patent.go.kr/portal/Main.do

 

 

 

 6,389 total views,  2 views today

13 5월 2999

매일 들르는 곳 : nooksurfer : ホームページの閲覧えつらん者しゃ

매일 들르는 곳 : nooksurfer : ホームページの閲覧えつらん者しゃ

 

 

자주 들르는 곳 : Frequent stop :

 

모바일 (게임)개발툴 사이트

 

 

 웹 (사이트) 개발

 

 

디지털 마켓

 

 

멀티미디어 리소스 (마켓)

 

인문학과 사회와 재경학에 관심을 가져보자

 

오프라인 교육 기관

 

 7,648 total views,  2 views today

3 5월 2021

[알아봅시다][물리학][사이언스N사피엔스] 아인슈타인의 생애 가장 행복했던 생각

[알아봅시다][물리학][사이언스N사피엔스] 아인슈타인의 생애 가장 행복했던 생각

[사이언스N사피엔스] 아인슈타인의 생애 가장 행복했던 생각

2021.04.29 18:09

등가원리의 이런 성질을 가장 잘 드러낸 영화가 ′인셉션′이다. 사람의 꿈을 조작한다는 내용의 이 영화에서는 꿈의 층위가 여러 단계로 나뉘어있다. 디스테이션/네이버영화 제공

등가원리의 성질을 가장 잘 드러낸 영화가 ‘인셉션’이다. 디스테이션/네이버영화 제공

1905년 특수상대성 이론을 완성한 알베르트 아인슈타인은 이후 이에 부합하는 중력이론을 고민하기 시작했다. 그때까지 알려진 중력이론은 당연히 뉴턴의 만유인력의 법칙이다. 아인슈타인은 만유인력의 법칙에 불만이 있었다. 자신의 특수상대성이론에 따르면 이 우주에서는 그 어떤 물리적 신호도 빛보다 빠를 수 없다. 만유인력의 법칙에서는 질량이 있는 두 물체가 즉각적으로 중력을 느낀다. 즉, 만유인력은 즉각적인 ‘원격작용(action at a distance)’ 이론으로 특수상대성이론과 잘 맞지 않는다. 아인슈타인은 자신의 새 이론에 대한 확신이 있었고, 이에 부합하는 새로운 중력이론이 필요하다고 느꼈다.

특수상대성이론을 발표한 지 2년이 지난 1907년 아인슈타인은 새 중력이론으로 향하는 중요한 돌파구를 찾았다. 바로 ‘등가원리(equivalence principle)’이다. 등가원리란 한마디로 관성력과 중력이 동등하다는 원리이다. 아인슈타인은 훗날 “생애 가장 행복했던 생각(the happiest thought of my life)이었다”고 회고했다.

관성력이란 가속 운동 때문에 생기는 가상의 힘이다. 버스가 갑자기 출발하면 몸이 뒤로 젖혀진다거나 모퉁이를 돌 때 바깥으로 쏠리는 것은 우리 몸이 원래 운동하던 관성을 유지하려는 성질 때문에 힘(관성력)을 받기 때문이다. 관성력은 정지좌표계에 있는 사람에게는 작용하지 않는다. 아무리 버스가 급출발하거나 모퉁이를 돌아도 정류장에 서 있는 사람에게는 (중력을 제외하고는) 아무런 힘이 작용하지 않는다. 버스가 일정한 속도로 움직일 때에는 버스 안에서도 관성력이 존재하지 않는다. 관성력은 오직 버스의 속도가 바뀌었기 때문에 생긴다. 

버스가 모퉁이를 도는 운동과 같은 원운동 또한 가속운동이다. 속도는 크기와 방향을 함께 갖는 양(벡터)이다. 원운동은 운동의 방향이 매순간 바뀌기 때문에 가속운동이다. 원운동은 고대 플라톤 이래로 이 우주의 가장 자연스러운 운동으로 간주되었다. 근대과학의 아버지라 불리는 갈릴레오조차도 행성의 궤도는 타원이라는 케플러의 법칙을 외면했고, 원운동은 관성의 법칙이 적용되는 등속운동으로 생각했다. 경험적으로 우리는 원운동을 할 때 바깥으로 쏠리는 힘, 즉 원심력을 느낀다. 원심력도 관성력의 일종이다. 세탁기의 탈수기능이나 실험실의 원심분리기도 모두 원심력을 이용한다.

사람의 꿈을 조작한다는 내용의 이 영화에서는 꿈의 층위가 여러 단계로 나뉘어있다. 디스테이션/네이버영화 제공

사람의 꿈을 조작한다는 내용의  영화 ‘인셉션’ 에서는 꿈의 층위가 여러 단계로 나뉘어있다. 디스테이션/네이버영화 제공

관성력이 중력과 등가라는 원리는 우리가 일상생활에서 매일 겪는 일이다. 엘리베이터를 타고 올라가면 엘리베이터가 위로 움직이는 순간 우리 몸이 무거워지는 것을 느낀다. 이는 엘리베이터가 위쪽 방향으로 순간적으로 가속운동(정지상태에서 움직이기 시작했으니 속도의 크기가 바뀌었다.)을 했기 때문이다. 그 결과 엘리베이터 안에 있는 사람은 가속운동의 반대방향, 즉 아래쪽으로 관성력을 받는다. 엘리베이터 안의 탑승객은 아래쪽으로 당기는 힘이 더해졌으므로 자신의 몸무게가 더 늘어난 것으로 느낀다.  

만약 엘리베이터는 정지해 있고 갑자기 탑승객의 몸무게나 지구의 질량이 늘어났다면 어떻게 될까? 만유인력의 법칙에 따르면 두 물체 사이에 작용하는 중력은 각 물체의 질량의 곱에 비례한다. 즉 각 물체의 질량이 늘어나면 그만큼 비례해서 중력이 커진다. 탑승객의 질량 또는 지구의 질량이 늘어나면 탑승객은 그만큼 아래쪽으로 당겨지는 힘을 더 크게 느낀다. 

등가원리란 탑승객의 입장에서 엘리베이터가 위로 가속하는지 중력이 강해졌는지를 구분할 길이 없다, 즉 그 두 효과는 동등하다는 원리이다. 

엘리베이터가 내려갈 때는 어떨까? 이때는 관성력이 위쪽을 향하므로 순간적으로 몸이 가벼워지는 느낌을 받는다. 이런 상황을 좀 극단으로 활용한 놀이기구가 자이로드롭이다. 자이로드롭은 사람들을 높은 곳까지 끌어올려 안전하게 자유낙하시키는 놀이기구이다. 물체가 자유낙하하면 지구를 향해 중력가속도의 크기로 가속된다. 이에 따른 관성력은 위쪽을 향한다. 이때 관성력의 크기는 가속도의 크기에 물체의 질량을 곱한 값과 같은데, 이는 정확하게 지구가 물체를 당기는 중력의 크기와 일치한다. 그 결과 자유낙하하는 물체에는 중력과 관성력이 상쇄돼 아무런 힘이 작용하지 않는다. 즉, 무중력상태가 된다. 자이로드롭이 높은 곳에서 떨어질 때 내장이 들리는 느낌을 받았을 것이다. 자유낙하를 하는 동안에는 우리 신체에 늘 작용하던 중력이 관성력에 의해 지워졌기 때문이다. 

등가원리란 탑승객의 입장에서 엘리베이터가 위로 가속하는지 중력이 강해졌는지를 구분할 길이 없다, 위키피디아 제공

등가원리란 탑승객의 입장에서 엘리베이터가 위로 가속하는지 중력이 강해졌는지를 구분할 길이 없다, 위키피디아 제공

자유낙하하는 사람의 관점에서는 자신은 아무런 힘도 작용하지 않는 무중력상태에 그저 가만히 있을 뿐이고, 엄청난 크기의 돌덩어리(지구)가 매초 초속 9.8m씩 속도를 증가시키며 자신에게 다가올 뿐이다. 반면 땅에 가만히 있는 사람에게는 관성력이 작용하지 않는다. 오직 중력만 작용할 뿐이어서 자유낙하하는 사람은 매초 초속 9.8m씩 속도가 커지면서 지면으로 돌진한다. 

자유낙하의 한 특이한 경우가 지구궤도를 도는 위성이다. 달이든 인공위성이든 우주정거장이든 일찍이 뉴턴이 지적했듯이 이 모두는 지구를 향해 끝없이 추락하는 사과와도 같다. 지구 주위를 도는 물체에게는 궤도 바깥을 향하는 원심력이 작용한다. 이 힘의 크기는 지구가 물체를 당기는 중력과 정확하게 똑같다. 그 때문에 위성의 궤도가 유지된다. 따라서 위성 자체에는 아무런 힘이 작용하지 않는다. 우주정거장이 무중력인 이유는 이 때문이다. 

등가원리의 이런 성질을 가장 잘 드러낸 영화가 ‘인셉션’이다. 사람의 꿈을 조작한다는 내용의 이 영화에서는 꿈의 층위가 여러 단계로 나뉘어있다. 영화 속 꿈의 1단계에서 픽업트럭이 강으로 자유낙하하는 장면이 있다. 그 순간 트럭 안에 모든 승객은 차량과 함께 무중력상태가 된다. 재미있게도 바로 이 순간 호텔에서 진행되는 꿈의 2단계에서도 모든 세상이 무중력상태로 변한다. 자유낙하하면서 무중력상태에 빠진 꿈의 1단계의 사람들이 다시 꿈을 꾸면 그 2단계 꿈속의 세상에서 중력이 지워진다는 기발한 발상이 영화적으로 아주 훌륭하게 구현되었다. 

영화 속에서 등가원리가 구현된 또 다른 사례가 우주선 속에서의 중력이다. 우주선이 지구 궤도를 돌고 있거나, 주변에 중력을 발휘할 무거운 천체가 하나도 없는 텅 빈 우주공간을 비행하고 있을 때는 우주선 안이 무중력상태이다. 잠시 몇 초, 몇 분 동안이라면 자이로드롭에서처럼 비싼 돈을 주고서라도 그런 상태를 즐겨보고 싶겠지만, 며칠을 무중력의 환경에서 생활한다는 것은 대단히 불편한 일이다. 어쨌든 우리는 한쪽 방향으로 일정한 힘이 작용하는 생태계에서 출현해 오랜 세월 진화하고 적응해 왔기 때문이다. 그렇다면 오랜 시간 우주선 안에서 보내야 할 우주비행사를 위해 인공의 중력을 만들어 지구 표면에서와 똑같은 환경을 만들어줄 필요가 있다. 

영화 ′인터스텔라(2014, 크리스토퍼 놀란)′의 인듀어런스 호. 네이버영화 제공

영화 속에서 등가원리가 구현된 또 다른 사례가 우주선 속에서의 중력이다. 영화 ‘인터스텔라(2014, 크리스토퍼 놀란)’의 인듀어런스 호. 네이버영화 제공

가장 간단하게 인공중력을 만드는 방법은 우주선을 빙빙 돌리는 것이다. 우주선에 원형의 구조물을 만들어 빙빙 돌리면 그 회전에 의한 원심 가속도가 중력가속도와 같게 만들 수 있다. 우주비행사가 그 구조물의 바깥쪽에 발을 디디면 지구 표면에서와 똑같은 중력환경을 느끼게 될 것이다. 우주비행사에게는 우주선의 일부 구조물이 회전하는지 지구 같이 무거운 천체가 중력으로 당기고 있는지를 구분할 능력도 없고 그럴 이유도 없다. 설령 신이 있다 하더라도, 신조차 이 둘을 구분할 수 없다는 것이 등가원리이다. 

이런 이유 때문에 영화 속의 수많은 우주선들은 빙빙 도는 구조물을 갖고 있다. 고색창연한 영화 ‘2001: 스페이스 오디세이’에서부터 ‘인터스텔라’의 인듀어런스호, ‘마션’의 헤르메스호, ‘엘리시움’의 우주구조물까지 똑같은 원리가 적용되었다. 물론 ‘스타워즈’나 ‘승리호’의 우주선과 우주구조물에서는 회전하는 장치가 보이지 않는다. 아마도 우리가 아직 잘 모르는 새로운 중력의 원리를 적용해 손쉽게 중력을 발생시켰기 때문이리라. 

등가원리가 왜 성립하는지에 대해서 아직 우리는 근본적인 이유를 잘 모른다. 엄밀하게 증명하거나 보다 근본적인 원리로부터 유도하지는 못해도 그냥 그러해야 할 것 같고 실제 실험적으로도 잘 성립할 뿐이다. 최근에는 등가원리가 어디까지 성립하는지를 확인하기 위해 인공위성에 시료를 담아 우주에서 실험을 진행하기도 했다. 그 결과는 약 100조 분의 1의 정밀도에서도 여전히 등가원리가 깨지지 않았다.

인공 중력 실험 준비모습. ESA 제공

인공 중력 실험 준비모습. ESA 제공

보통 사람들은 그게 뭐 그리 대단하다고 우주선까지 띄워서 그렇게 미세한 실험을 하려고 할까하고 생각할지도 모르겠다. 그러나 그게 과학자들이 하는 일이다. 그 어떤 위대한 법칙이라도 정말로 모든 상황에서 성립하는지, 얼마의 정밀도까지 확인할 수 있는지를 끝까지 파고든다. 만유인력의 법칙만 해도 태양계 정도의 규모에서는 그 정확성을 쉽게 확인할 수 있지만, 은하 이상의 거대규모나 분자 수준의 아주 미시적인 세계에까지 정확하게 작동하는지는 별개의 문제이다. 실제로 학계에서는 ‘수정 뉴턴 동역학(MOND)’이론을 도입해 우주에서의 각종 현상을 설명하려는 노력도 없지 않다. 

만약 1000조 분의 1의 정밀도에서 등가원리가 성립하지 않는다고 밝혀지면 어떻게 될까? 우선 그 사실을 입증한 연구진은 당연히 노벨상을 받을 것이다. 아마도 이점에 의견을 달리할 물리학자는 거의 없을 것이다. 그 다음 수순으로 등가원리에 기초한 일반상대성이론을 능가하는, 보다 포괄적이며 새로운 이론을 찾아 나설 것이다. 그렇다고 해서 아인슈타인이 완전히 틀린 것인가, 일반상대성이론은 포기해야 하는 것인가 라고 묻는다면 그 답은 부정적이다. 1천조 분의 1의 정밀도에서 성립하지 않는다면 뒤집어서 말해 등가원리가 그보다 낮은 정밀도에서 매우 잘 작동한다는 의미이다. 일반상대성이론도 그 정도까지의 정밀함을 요구하지 않는 수준에서는 매우 잘 작동한다는 뜻이다. 다만 일반상대성이론이 그보다 더 근본적인 어떤 새로운 이론의 근사적인 이론일 뿐임이 드러난 것이다. 새 이론은 보다 근본적이고 포괄적인 이론으로서 일반상대성이론을 자신의 한 극한적인 상황에서의 이론으로 포함하게 될 것이다. 물론 아직 이런 일이 벌어지지는 않았지만, 만약 현실이 된다면 이 얼마나 신나는 일인가. 그래서 과학자들은 확립된 법칙이라 하더라도 끊임없이 검증하고 확인하는 작업을 멈추지 않는다.

과학은 이런 식으로 발전해 나간다. 

1925년의 아인슈타인. 위키미디어 제공

1925년의 아인슈타인(오른쪽). 위키미디어 제공

※참고자료

-A. Einstein, The Collected Papers of Albert Einstein, Vol.7: The Berlin Years: Writings, 1918-1921 (English translation supplement) Page 136, Princeton University Press, 2002; https://einsteinpapers.press.princeton.edu/vol7-trans/152

-Pierre Touboul et al 2019 Class. Quantum Grav. 36 225006; DOI: 10.1088/1361-6382/ab4707.

※필자소개 

이종필 입자이론 물리학자. 건국대 상허교양대학에서 교양과학을 가르치고 있다. 《신의 입자를 찾아서》,《대통령을 위한 과학에세이》, 《물리학 클래식》, 《이종필 교수의 인터스텔라》,《아주 특별한 상대성이론 강의》, 《사이언스 브런치》,《빛의 속도로 이해하는 상대성이론》을 썼고 《최종이론의 꿈》, 《블랙홀 전쟁》, 《물리의 정석》 을 옮겼다. 한국일보에 《이종필의 제5원소》를 연재하고 있다.

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

 42 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

 14 total views,  2 views today

28 4월 2021

영화 Nobody 2021 의 삽입곡 Impossible Dream 의 원곡    Luther vandross의.. ‘impossible dream’ 이라는곡가사해석

영화 Nobody 2021 의 삽입곡 Impossible Dream 의 원곡   

Luther vandross의.. ‘impossible dream’ 이라는곡가사해석

To dream the impossible dream                      불가능의 꿈을 꾸고               
To fight the unbeatable foe                            무적의 적과 싸우고
To bear with unbearable sorrow                     참을 수 없는 슬픔을 참고
And to run where                                              
the brave dare not go                                       그리고 용사가 감히 가지 못하는 곳으로

                                                                              뛰어가기
To right the unrightable wrong                       제대로 바꿀 수 없는 잘못을 바로잡기
And to love pure and chaste from afar          멀리서 순수하고 순결한 사랑하기
To try when your arms are too weary            팔이 너무 힘이빠져있을 때 애쓰기
To reach the unreachable star                         다다를 수 없는 별에 가기
This is my quest                                                이게 나의 가야할 길이야(모험/탐험)
To follow that star                                             저 별을 따라
No matter how hopeless                                   얼마나 가망이 없을지라도
No matter how far                                              얼마나 멀더라도
To fight for the right                                         정의를 위해 싸우려고
Without question or pause                             의문이나 멈춤이 없이
To be willing to march,                                     행진할 마음을 가지고
march into hell                                                   지옥을 향하여 전진하네
For that heavenly cause                                  저 신성한 이유를 위해
And I know                                                       그리고 나는 아네
If I’ll only be true                                              나만이 유일한 진실이 된다면 
To this glorious quest                                    이 영광스러운 모험에 있어서
That my heart                                                   나의 마음을
Will lie peaceful and calm                               평안히 고요히 놓네

When I’m laid to my rest                                 내가 쉴 때
And the world will be                                      그리고 세상은 이것으로
better for this                                                    더 좋아지리
That one man, scorned                                    그 한 사람, 멸시당한
and covered with scars,                                   흉터투성이인
Still strove with his last                                    여전히 그의 마지막
ounce of courage                                              여력의 용기로 애쓰네
To reach the unreachable,                               다다를 수 없는 곳에 다다르기 위해
the unreachable,                                                다다를 수 없는 곳
The unreachable star                                        다다를 수 없는 별
And I’ll always dream                                        그리고 난 항상 꿈을  꿀거야
The impossible dream                                        불가능한 꿈을
Yes, and I’ll reach                                                그래 난 갈거야.
The unreachable star                                          다다를 수 없는 그 별애

문장이  너무 조각나 있어 앞에 붙여야 할지 뒤로 붙어야 할지 애매한 부분이

한두군데 있었는듯…^^;

 

[출처] https://blog.naver.com/hyotao/70082819112

 25 total views

28 4월 2021

[1日 30分 인생 승리의 학습법] 훌륭한 개발자가 되는 방법

[1日 30分 인생 승리의 학습법] 훌륭한 개발자가 되는 방법

첫째, 문제에서 나 자신을 배제하지 말자⚠️

Photo by Fares Hamouche on Unsplash

둘째, 에러의 원인을 파악하자????

 

Photo by Rob Schreckhise on Unsplash

셋째, 에러 메시지를 읽어보자 ????

 

Photo on Pixabay

[출처] https://hshine1226.medium.com/%ED%9B%8C%EB%A5%AD%ED%95%9C-%EA%B0%9C%EB%B0%9C%EC%9E%90%EA%B0%80-%EB%90%98%EB%8A%94-%EB%B0%A9%EB%B2%95-5843a048a458

 22 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 혁신 디바이스/ 소프트웨어] 콘솔 게임 시장 바꾸는 XBOX게임패스, 패키지 시대의 끝을 알리나

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

콘솔 게임 시장 바꾸는 XBOX게임패스, 패키지 시대의 끝을 알리나

XBOX 게임패스를 앞세운 MS의 공격적인 행보가 콘솔 게임 시장을 긴장시키고 있다.

소니의 대표적인 독점작이었던 MLB 더쇼 21마저도 출시 당일 XBOX 게임패스에 합류하는 등 부족했던 라인업까지 대폭 확대했으며, 그동안 LIVE 서비스를 가입해야만 즐길 수 있었던 무료 멀티플레이 게임들도 무료 서비스로 전환하는 등 이전과는 확연히 달라진 모습으로 게이머들의 시선을 끌고 있다.

이전 세대에서는 다수의 독점작을 앞세운 PS4와 닌텐도 스위치 때문에, XBOX가 계속 밀리는 모양새였으나, 게임계의 넷플릭스 위치를 노리는 게임패스가 콘솔 시장의 경쟁 구도를 바닥부터 완전히 바꾸는 분위기가 연출되고 있다.

라인업을 대폭 확대한 게임패스

MS는 올해 초 컨퍼런스를 통해 XBOX게임패스 가입자가 2020년 1000만명에서 2021년 초 1800만명으로 급상승했다고 밝힌 바 있으며, 업계에서는 지난 3월 EA PLAY PC의 게임패스 합류 등 공격적인 라인업 확대에 힘입어 현재 2300만명을 넘어선 것으로 추산하고 있다.

이런 게임패스의 급성장이 영향을 주는 것은 MS, 소니, 닌텐도의 시장 점유율만이 아니다. 과거 패미컴 시대부터 지금까지 계속 이어져오고 있는 패키지 중심의 유통 구조도 큰 폭의 변화가 예상된다. 즉, 패키지 시대의 종말이다.

콘솔 게임 시장에서 큰 비중을 차지하는 패키지

현재 콘솔 게임 시장은 기존부터 유지되고 있는 패키지 유통방식을 기본으로 하고, 콘솔 제조사들의 자체 스토어를 통한 다운로드 판매로 이를 보완하는 형태로 유지되고 있다.

일부 소규모 게임들은 패키지 판매없이 다운로드 판매만 선택하기도 하지만, 아직까지는 패키지 소장을 중요하게 여기는 마니아들이 시장을 주도하고 있으며, 중고 판매 이슈 때문에 패키지 구입을 선호하는 이들이 많기 때문이다.

다만, 구독형 서비스인 게임패스의 영향력이 커지면 커질수록 콘솔 게임 시장에서 패키지 판매의 비중이 계속 줄어들 것으로 예측된다. 구독 신청을 해두면 정기적으로 새로운 라인업이 추가되는 상황에서, 굳이 추가로 돈을 들여 패키지 게임을 구입할 필요가 없기 때문이다.

XBOX 게임패스로 즐길 수 있게 된 MLB 더쇼21

소비자 입장에서 패키지 게임은 자신이 선호하는 게임을 수집, 보관할 수 있는 콜렉션의 의미와 클리어한 이후 중고 판매를 통한 일부 자금 회수로 저렴하게 취미 생활을 유지하는데 의미가 있다. 수집의 의미가 아니라 단순히 중고 판매 목적이라면, 굳이 사고 팔고 할 필요없이 훨씬 저렴한 가격으로 다양한 게임을 즐길 수 있는 구독형 서비스가 완벽한 대안이 된다.

게임 플레이 측면에서도 이점이 많다. 과거에 비해 훨씬 다양한 게임이 출시되고 있고, 엔딩을 본 이후에도 멀티 플레이까지 지원하는 게임들이 많다보니, 동시에 여러개 게임을 즐기는 경우가 많아졌다. 패키지 게임의 경우 다른 게임을 플레이할 때마다 디스크를 찾아서 갈아 끼워야 하는 수고가 필요하지만, 다운로드가 기본인 구독형 서비스에서는 그럴 필요가 없다.

충분한 용량의 하드디스크만 있으면 친구들과 멀티플레이 게임으로 손 좀 풀고, 좀 여유로운 게임을 즐기고 싶으면 RPG를 켰다가, 좀 지루해지면 스포츠 게임으로 잠시 머리를 시키는 여유로운 취미 생활을 즐길 수 있게 된다. 실제로, 소장 목적으로 패키지를 구입하더라도, 자주 플레이하는 게임의 경우에는 편의성 때문에 다운로드 버전을 추가 구매하는 사람들도 적지 않다.

할인된 금액으로 구입할 수 있는 다운로드 버전

굳이, XBOX 게임패스가 아니라 다른 콘솔도 다운로드 구입의 이점이 많다. 앞서 언급한 디스크 교체의 불편함 뿐만 아니라, 신작을 출시 당일에 꼭 즐겨야만 하는 것이 아니라면 조금만 시간이 지나도 세일을 통해 더 저렴한 가격으로 구입할 수 있기 때문이다.

출시 초기에는 패키지 판매 때문에 다운로드 버전 가격을 동일하게 선보이고 있지만, 패키지 판매가 어느 정도 완료된 시점이 되면, 다운로드 버전을 할인된 가격으로 판매해 추가 수익을 기대할 수 있다. 소비자 입장에서는 구입할까 말까 고민되던 게임을 저렴한 가격으로 구입할 수 있으니 이득이고, 게임사 입장에서도 패키지 버전과 달리 제작 비용 부담이 코드만 발송하면 되니, 할인된 가격으로 판매해도 이득이 된다. 거의 떨이판매가 다름없는 70~80% 세일이라고 하더라도 게임사에게는 한푼의 수익도 돌아가지 않는 중고 판매보다 낫다.

마니아들을 노린 한정판

물론, 소장의 목적이 큰 소비자들이 여전히 많이 존재하고, 마치 레고 재테크처럼 고전 게임 패키지가 비싼 값으로 팔리는 경우도 있다보니, 패키지 판매가 완전히 사라질 확률은 낮은 편이다. 게다가 최근 소니가 PS3, PS VITA, PSP 다운로드 스토어를 폐쇄하기로 결정했다가, 이용자들의 반발로 철회한 것처럼, 다운로드만 믿고 있다가는 플랫폼사의 상황에 따라 다시 구입할 수 없게 되는 게임도 생겨날 수 있다.

다만, 넷플릭스 등 OTT 서비스에 밀려 마니아 위주로 간신히 명맥만 유지하고 있는 영화 블루레이 시장처럼, 게임 역시 패키지는 한정판 등 마니아 수요층만을 대상으로 명맥만 유지되고, 대부분의 판매는 다운로드 중심으로 완전히 바뀌게 될 것으로 보인다. 수집 목적을 제외하면 가격, 편의성 등 모든 부분에서 다운로드가 훨씬 유리하기 때문이다. 다운로드는 이미 거부할 수 없는 흐름이고, 게임패스는 그 흐름을 좀 더 빠르게 만드는 계기가 될 것이다.

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

 35 total views,  2 views today