AI, VR 그리고 교육


결론부터 말하자! AI와 VR은 하루빨리 교육에 도입되어야 한다!


사회 혁명인가? 산업 혁명인가? 아니면…


이미 알 사람은 다 알겠지만 새로운 혁명이 다가오고 있다. 4차 산업 혁명이라는 말로는 부족한 혁명이…
이전의 혁명이 사회적이고 인간 존엄의 문제였다면 새로운 혁명은 개인에게 스며들며 인간 존재의 문제이다.
많은 사람들이 이미 이 혁명의 한 가운데 있으면서도 이 것이 혁명이라고 생각하지 못한다. 그저 전문가의
미래 예측 정도로 생각할 뿐. 이 혁명은 바로 AI(Artificial Intelligence)와 VR(Virtual Reality)이다.


이미 우리 생활 곳곳에 AI가 실용화되고 있지만 많은 사람들이 ‘과연 인공지능이 어떻게 쓰일까?’라고
말한다. 그에 비해 발전의 속도는 늦고 분야도 한정되어있지만 VR 역시 그 범위를 넓힌다면 상당히
많은 곳에서 접할 수 있는 기술이다.


AI와 VR은 인간의 두 가지 중요한 측면을 대체한다. 인간의 정신은 AI가 대체하고 인간의 육체는 VR이 
대체한다. 사람들의 많은 활동들이 AI와 VR로 대체될 것이다. 어떤 뉴스를 볼 것인지, 어떤 영화를 볼
것인지 어떤 물건을 살 것인지 선택과 판단의 문제는 AI를 통해 이루어질 것이다. 이는 ‘마스터 알고리즘’
에서 언급되 디지털 클론(Digital Clone)이다. 한 편 사람들은 서울의 어느 곳에서 프랑스 파리를 여행
하게 될 것이다. 자기 자신이 패션쇼의 주인공이 될 것이며 심지어는 어느 우주인보다 먼저 화성에 발을
디디게 될 것이다.


이러한 변화를 단지 산업혁명이라고만 부를 수 있을까? 아니면 인류의 활동 영역을 확장하는 인지혁명
이라고만 부를 수 있을까? 아니면 현실의 사회의 영역을 연장시키는 사회적 혁명이라고만 부를 수 
있을까? 새로운 혁명은 이전 어느 혁명과는 그 급이 다르다.


시민 혁명은 인간과 인간의 충돌이었으며 존엄성을 갖지 못했던 인간들의 존엄성 회복의 혁명이었다.
산업 혁명은 기계와 기술에 의한 혁명이었으며 인간 생존 문제에 있어서 모순된 영향을 주었다.
생산성을 향상시켰지만 많은 사람들의 생존을 위협하였다.


다가올 혁명은 이러한 이전의 혁명들과 많은 부분에서 다르다. AI와 VR은 (물질적, 육체적으로)결핍된 
인간들에게 새로운 기회를 줌으로써 그 존엄성을 찾아줄 것이다. 하지만 인간의 역할이 대폭 줄어들면서
인간의 그 존재에 대해 다시 한 번 생각을 해봐야 할 것이다. 산업혁명과 빗대어 봤을 때도 기술의 약진
이라는 점에서는 유사하나 생존의 측면에서는 사회적 제도에 의해 그 위험요소가 감소되는 반면
그러한 기술로 인한 생산성 향상은 기하급수적인 파급 효과를 가져올 것이다.


경제적으로 보았을 때 가장 흥미로운 것은 마르크스의 노동 가치설이다. 인간의 경제 활동에서 가치를
만들어낼 수 있는 것은 오직 노동 뿐이다. 하지만 만일 (이런 용어가 있는지 모르겠지만) 완전 비고용
상태가 온다면, 마치 터미네이터의 스카이넷이나 매트릭스의 인공지능 컴퓨터처럼 모든 생산에 인간이
개입하지 않고 100% 인공지능과 기계에 의한 생산이 가능해진다면 그러한 사회에서의 ‘가치’는
어디서 찾을 수 있을까? 아무도 고용되어있지 않고 아무도 임금을 받지 않는데 어떻게 소비가 발생하고
경제가 굴러갈 수 있을까?


이 혁명은 판도라의 상자와 같다. 무엇이 튀어나올지 예측하기 힘들다. 다만 그 안에 희망이 들어있길
바랄 뿐…


어떻게 적응할 것인가.


이 혁명이 이전의 산업 혁명과 또 다른 하나는 새로운 기술을 어떻게 사용하느냐에서 끝나는 것이 아니란
것이다. 그 기술들이 고스란히 삶의 일 부분이 되어버린다는 것이 핵심이다. 우리는 우리가 살고 있는
이 사회 이외에 또 다른 삶을 살아가게 될 새로운 세상을 만든 것이다. 매트릭스의 네오처럼 빨간 약과
파란 약 중 하나를 선택할 필요도 없이 원하는 때 원하는 현실을 마음것 선택해서 생활할 수 있다.


또 다른 사회가 만들어진다는 것은 그 새로운 사회에 필요한 질서가 같이 만들어져야 함을 의미한다.
얼마전 허핑턴포스트에 기사가 하나 실렸다. “지난주 저는 가상현실에서 성추행을 당했습니다”라는
다소 특이한 제목의 기사였다. 하지만 이 것은 실제 일어난 사건이고 피해자는 정말로 현실과 다름없는
수치심을 느꼈다. 내가 이 글을 쓰게 된 이유도 이러한 사건에 기인하고 있다. 오늘 퇴근길에 나는 VR에
관련된 소책자를 읽고 있었고 이러한 VR이 교육 현장에서 활용되면 좋겠다는 생각을 하면서 VR 상에서
선생님이 학생을 인솔하여 동굴이나 화산을 탐사하고 학생들은 그 뒤를 줄지어 따르는…그러다가 문득
이 기사가 생각난 것이다. 어떤 남학생이 가상현실 상에서 내 딸아이의 치마를 들췄다면 나는 이 상황을
어떻게 판단해야 하는가? 


조금은 현실성이 떨어지겠지만 다른 상상을 해보자. 별다른 연고가 없는 사람이 디지털 클론을 통해
여러 곳에서 소비생활을 하고 또 이 인공지능은 VR을 이용한 소셜 네트워크 상에서의 활동에도
이 사람의 역할을 곧잘 해오고 있다. 어느 날 이 사람은 돌연사를 하게 되고 디지털 클론은 그 사실과
무관하게 디지털 세상에서 열심히 활동을 하고 있다…


택시 기사가 소복입은 여인을 태워다 준 집에서 그 여인의 제사를 지내고 있었다는 이야기보다 더
섬뜩하게 느껴진다. 아니, 소복입은 여인을 만날 확률보다 주인 없는 디지털 클론을 만날 확률이
훨씬 더 높을 것이 분명하다.


내가 한 이야기는 그저 상상에 불과한 이야기일지는 모르겠지만 허핑턴포스트의 기사는 현실 그 자체이다. 

비단 이러한 문제 뿐만 아니라 기술 발전을 따라가지 못하는 제도로 인해 새로운 범죄가 생겨날 것은 분명해

보인다.


다시 한 번! AI와 VR은 하루빨리 교육에 도입되어야 한다!


AI와 VR이 갖는 교육적 유용함은 대단할 것 같다. 관찰과 실험에 있어서 VR과 AI가 주는 효과는 분명
기존의 어떤 교육 도구도 접근하지 못할만큼 대단하리라. 하지만 단지 교육의 도구로서만 도입을 
서두르자는 것은 아니다. 이미 가까이 와있는 생활의 일부분으로 그 안에서의 삶을 어떻게 이끌어가야
하는지에 대한 준비가 더 중요하다고 보여진다. 무엇을 할 수 있는지, 무엇을 해야 하는지, 무엇을 하지
말아야 하는지에 대한 상식적인 선에서의 교육이라도 시작되지 않으면 가상현실에서 발생하는 성추행은
비참한 일상이 되어버릴 것이다. 현실에서의 성추행조차도 가볍게 넘어가기 일쑤인데 가상 현설에서
벌어진 일이라면 더 말해 무엇하랴.


이제 그저 다가왔다고 말하기가 무색하게 우리의 삶의 깊은 부분에 걸쳐있는 이 새로운 기술들에 대한
교육은 지금부터 시작해도 많이 늦은 것으로 보인다.

저작자 표시
신고
TDD



TDD에 대한 단상


몇가지 전제


일단 TDD에 대해서는 책 한 권(테스트 주도 개발 TDD 실천법과 도구) 

읽은 것 외에는 아직 제대로 된 지식이 없다.


물론 설계도 내 경력에 비해 그리 잘한다고는 할 수 없고...


또한 TDD와 설계는 모두 구체적인 실체가 드러나기 전해 행해지는
작업이라는 부분에 초점을 맞추고 있다.


그리고 이 글은 초급 개발자들이 이러한 기술들을 습득하는 과정에 대한
이야기다.


무에서 유를 창조하다.


앞서 전제를 달았듯이 TDD나 설계가 어려운 이유는 일단 아무런 구체적
실체가 없는 상태에서 시작을 하기 때문이다.


조금 더 엄밀하게 표현을 하자면 현재는 아무것도 없지만 과거의 경험이 
밑바탕이 되어 수행이되는 작업으로 경험이 밑바탕이 된다는 점에서
역시나 고급 경력자들에게나 걸맞는 일이다.


하지만 설계는 그렇다 쳐도 TDD의 경우에는 팀 전체가 일관된 룰을 
따라야 할 필요가 있다. 이는 곧 팀에서 가장 경력이 짧은 팀원들도
TDD를 익히고 이 방법을 따라야 한다는 말이다(물론 프로젝트 상황에
따라 다를 수 있고 또 페어 프로그래밍 등으로 보완할 수는 있겠다).


하지만 적절한 경력이 쌓이지 않은 상태에서 이런 작업은 결코 쉽지 않다.
사실 ‘무’라고 표현을 했지만 ‘추상적’이라고 말하는 것이 조금 더 
적합할지도 모르겠다.


굳이 별다른 예를 들지 않더라도 우리는 일상 생활에서 보다 쉬운
이해를 돕기 위해 구체적인 예를 든다. 물론 내가 읽은 TDD 책에서도
은행에서의 금전출납을 예로들어 설명을 하고있다. 하지만 그럼에도
불구하고 쉽게 이해가 가지 않고 어렵게만 느껴지는 것이 TDD가
단순히 값의 옳고 그름만을 판단하는 기능을 하는 것이 아니기 때문일
것이다.


이러한 상황은 결국 학습 곡선을 길게 만들고 장기 프로젝트가
아닌 다음에는 쉽게 경험을 하기도 힘들고 다른 측면으로는 익숙하지
않은 기술을 실제로 적용함으로써 발생하는 비용 또한 고려를 하게 만들 것이다.



단계를 바꾸어보자.


누차 반복하지만 TDD나 설계를 쉽게 익힐 수 없는 것은 그 것이
추상으로부터 시작하는 작업이며, 결국 경험에 의존할 수 밖에
없기 때문이다.


거꾸로 이야기 하면 충분한 경험을 쌓기 전에는 TDD나 설계를 하기가
힘든 것이다. 하지만 여기서 중요한 것은 경험에 숨어있는 한 단어다.
바로 자~~알...좋은 경험을 해야 좋은 TDD와 설계가 나올 수 있는
것이다. 좋은 코드를 작성해본 적이 없는데 좋은 TDD나 좋은 설게를
할 수는 없는 법이다.


그럼 좋은 코드를 만드는 것은 어떻게 경험을 할 수 있을까?
바로 우리가 잘 알고있는 Refactoring이 그 답이 아닐까 한다.


자꾸 내 경험을 이야기해봐야 객관성은 떨어지지만(어차기 내 글 자체가
객관성하고는 거리가 멀다...ㅠ.ㅠ) 사실 TDD 책을 읽을 때에 비하면
리팩토링 책(Refactorting, 대청)을 읽을 때 더 이해가 쉬웠고 더불어
이해한 내용을 직접 실전 적용해볼 샘플들이 넘쳐났다.(그렇다고 해서
모든 내용을 다 이해한 것은 아니다!)


다시 강조하지만 지지고 볶을 실체를 놓고 그 것을 개선하는 Refactoring이
좀 더 초보자들에게는 쉬운 접근법이라고 판단된다.


그렇다고 실제 프로젝트에서 개판 오분전인 코드를 그냥 두지는 않을 것이고
하다못해 PMD를 돌려서라도 어느 정도 정적 분석정도는 거치고 난 경우가
많을 것이다. 최소한 그정도 수준이라면 Refactoring을 통해 어떻게 해야
보다 나은 코드를 만들 수 있는지에 대한 경험을 쌓기에는 충분하지 않을까 한다.


결국 일반적인 코딩 작업 -> Refactoring -> Unit Test -> TDD로 나가는
방향이 맞을 것으로 보인다.


이렇게 쓰고 보니 TDD는 말 그대로 테스트 주도, 테스트를 먼저하는 (먼저 실패하라!)
방법인데 이걸 어떻게 적절하게 써먹느냐는 딜레마가 생겨버린다.



무작정 좋은 것은 없다.


언제나 합리적인 이론, 좋은 방법, 훌륭한 도구들은 끊임없이 있어왔다.
하지만 누구나 만족할 수 있는 것은 아직 없었다.


누군가에게는 완벽한 솔루션이지만 누군가에게는 힘겨운 장애가 되는 수도
허다하다.


결국 얼마나 상황에 맞는 방법이나 도구를 알맞게 사용하느냐가 관건이리라


2개의 루프를 돌려도 좋으리라 고경력자들은 TDD를 위한 테스트케이스를 만들고
초급개발자들은 그 테스트케이스를 이해한 후 실제 코딩에 들어가고 
하지만 여전히 그에 앞서 보다 구체적으로 좋은 코드에 대한 경험을
쌓게 해주는 것이 더 좋지 않을까 하는 생각이다.


아마 나도 조금 더 TDD에 대해 깊이 이해하게 된다면 오늘의 이 글과는 
또 다른 글을 쓸지도 모르겠다...



여담


나쁜 코딩 습관 중 나는 중복 코딩 만큼은 충분히 용인해주고싶다.
불필요한 코드의 증가와 변경이 발생했을 때의 수정 범위가 넒어진다는
치명적인 단점이 있지만 속도면에서 C&P를 따라갈 만한 것이 없다.
더군다나 이러한 중복 코드들은 나중에 Refactoring을 할 때에도
큰 부담 없이 진행을 할 수 있으며 이 과정에서 코드를 다시 보는 과정이 생겨
더 나은 코드에 대한 고민을 가능하게 한다.


혹시라도 나중에 시간에 쫓기는 프로젝트를 할 기회가 있으면 한 번
중복 코드로 도배를 하면서 시작을 해봐야겠다...^^;;;

저작자 표시
신고




아파치 Kafka 따라잡기 : 확장성과 고가용성을 지닌 메시지 브로커


일단 결론부터 말하자면 매우 실망이다...ㅠ.ㅠ
페이지 수에서 짐작을 했어야 했지만 웬만한 인터넷 자료보다 부실하다고 느껴진다.
다만 국내에서 Kafka를 단독으로 다룬 유일한 번역서인 듯하여 선택의 여지는 없지만
역시 이 책을 사보기 보다는 인터넷을 통해 블로그를 검색하는 것이 더 양질의
자료를 모을 수 있을 것이다.


그런데 문제는 amazon에서 kafka 관련 서적을 검색해도 kafka만 단독으로
다룬 책이 별로 없을뿐더러 그나마 있는 책들도 평이 너무 않좋다.
평균 별점 3개 이하...


도대체 Kafka라는 기술은 전망이 어두운 것인지 아니면 책 따위는 없어도
할 수 있는 쉬운(?) 기술인 건지...-.-


암튼 결론은 Kafka를 공부하기 위해 책을 살 필요는 없다는 것이다.

저작자 표시
신고




1. 인공지능은 인류를 위협할 것인가, 인류에게 도움이 것인가?


일고의 가치도 없는 논쟁이다. 어쨌든 인공지능은 계속해서 발전을 나갈 것이고

때론 인류에게 도움을 것이고 때론 인류를 위협할 것이다.


?


인간 만들었고인간 만들어 것이기 때문이다.


그러면 인공지능 스스로가 스스로를 만들어가는 ?

터미네이터의 스카이넷?

매트릭스의 매트릭스?


오늘의 알파고를 보면 가능할 같다.

사실 터미네이터나 매트릭스나 영화니까 마지막에 인간이 승리하는거지

오늘의 알파고를 보니 그런 가능성 조차 여지없이 무너진다.


그러면 인공지능을 만들지 말까?

그것도 말이 안된다.


?


인간 일이니까

수십억의 인간들이인공지능 결사 반대 외쳐도

지구 어느 구석에선가의 ~ 명의 인간들은 들은 척도 하지 않고

결국 만들어 것이다.


결국 옳고 그름의 문제가 아니라 현실적으로 발생할 있은 문제들을 에측하고

이에 대비하는 것이 인공지능을 대하는 올바른 자세일 것이다.



2. 육체, 행동 그리고 아날로그


현재 인공지능에 제공되는 지식과 정보들은 모두 디지털화 데이터들이다.

게다가 정보들은 인공지능 스스로가 직접 경험한 것이 아니라 인간의 경험을

전해들은 것이다. , 간접 경험이다. 말하자면수영을 글로 배웠어요 셈이다.

이런 상황은 분명 인공지능의 한계가 되지 않을까 싶다.


원시시대로 거슬러 올라가 인간이 유인원에서 인간으로 발전해 과정을 살펴보자.

직립보행과 손의 사용.

인간들은 스스로 움직이며 미지의 세계에 부딪쳐가며 지식과 지혜를 쌓아왔다.

이렇듯 자유로운움직임’, 아날로그적인 지식까지 완벽하게 수집이 가능해야 

진정한 지식이 형성되는 것이 아닐까?


대부분의 인공지능 소재 영화에서 인간형 로봇이 등장하는 이유는 바로 이런 까닭이

아닐까?



3. 감정의 문제


인공지능을 소재로 영화들을 보면 거의 빠짐없이감정 가지고 있다.

때론 사랑을 하고 때론 그리워하고 때론 두려워하고

만일 인공지능이 감정을 가질 있다면 오히려 두려움은 반감될 것이다.

인간에게 있어 감정은 양날의 칼이다. 그런 감정을 인공지능도 갖게 된다면

사랑, 연민, 동정, 분노 등으로 인해 논리적이고 합리적인 판단을 수행할 없을 것이다.

만일 감정까지 갖고있는 인공지능을 만들어낸다면

인류는 결국 새로운 인류를 창조한 것이 되고 신의 영역에 올라서는 일이 것이다.


하지만 아무리 기술이 발전을 한다 할지라도감정 불어넣는 일은 불가능해보인다.


인공지능이 두려운 것은 일말의 감정도 없이 모든 선택을 논리에 의해 수행한다는

점일 것이다.


오늘 대국에서의 이세돌 9단도 바로 이러한 점에 적잖이 당황했다고 한다.


결국 1번에서 말한 인공지능을 대하는 올바른 자세 하나는 바로 인공지능은

감정이 없다라는 것을 명확히 인지하는 일이 것이다.



요약하자면

인공지능은 점점 발전해 것이라는

인공지능이완성되기 위해서는 인간과 같이 자유롭게 움직일 있는 육체가 필요하다는

하지만 지금의 수준에서도 인간을 위협하기에는 충분한 같다는

그렇기 때문에 인공지능으로 인해 생길 있는문제들을 미리 예측하고 대비해야 한다는 것이다

저작자 표시
신고

가만히 보니 생각보다 많은 인공지능 소재의 영화들을 봤다.

지금 기억나는 것들 몇가지, "A.I.", "I, Robot", "HER" 그리고 며칠 전 본 EX MACHINA...

물론 그 이전에도 인공지능에 대한 영화가 많았겠지만 내가 직접 본 것 중 기억에 남는것은 이정도네...


-- 가장 오래된 인공지능 로봇에 대한 기억은 아마도 커크 더글라스가 나왔던 새턴3라는 영화의 헥토르라는

로봇이 아닌가 싶다. 자신의 두뇌 소스였던 벤슨의 얼굴 가죽을 뒤집어쓰고 있던 그 그로테스크한 모습은... --

-- 터미네이터 시리즈가 있지만 뭔가 느낌이 조금 이질적 이라서 뺐다 --







소재가 소재인지라 다들 참 재미있게 봤다.

요즘 한창 인공지능에 대한 이야기가 화제거리이다.

특히나 인류 최고의 두뇌 게임인 바둑에, 그것도 세계 최강이라고 할 수 있는 이세돌 9단에게 도전을 하겠다고 나선

인공 지능이 있고 보니 관심이 안갈래야 안갈 수가 없다.


그런데 곰곰 생각해보니 왜 이전까지 이러한 인공지능 소재의 영화를 보면서도 그리 현실감을 느끼지 못한 것은 바로

'감정'의 문제가 아닐까 싶다.


심리학이나 그와 관련된 분야를 공부해본 적도 없고, 인간 뇌의 구조는 더더욱 모르고,

(그냥 내 두뇌는 휘발성 메모리와 유사하다는 것만 알 뿐이고...-.-)


그럼에도 "지능(지식)"과 "감정" 막연하게 뭔가 그 작용이나 발현이 서로 다를 것 같다는 생가...

말하자면 논리라는 것이 그 선후 관계 혹은 변수로 삼을 수 있는 다양한 객체들의 연관을 읽어 결과를 도출하는 것으로

이 것을 통한 지식의 확장은 충분히 이해를 하겠는데, 과연 감정 역시 그러한 과정을 거쳐 발생할 수 있는 것인지..


인공지능 로봇은 부모가 없다는 것에 슬픔을 느낄 것인지...

인공지능 로봇은 자신의 존재가 사라질지 모른다는 것에 두려움을 느낄 것인지...

인공지능 로봇은 자신에게 관심을 기울여주는 대상에게 사랑을 느낄 것인지, 그리고 그에게 아픔을 주었을 때 미안함을 느낄 것인지...

한 발 더 나아가 인공지능 로봇은 다른 인공지능 로봇과 유대감을 느낄 수 있을 것인지...


최근 ZDNET에 실린 우리가 알아야 인공지능 현주소 9가지라는 기사에서 보면 인공지능은 "악"이 될 수 없다고 한다.

인공지능은 단지 '논리연산을 바탕으로 그 연산의 옳고 그름을 따질 뿐 윤리나 가치의 기준을 가지고 판단을 하지는 못한다'라고 할 수 있겠다.


하지만 이 글에서 언급하는 인간보다 더 똑똑해질 수 있다는 말은 여전히 두려움의 대상이 된다.


앞으로 더 어떻게 달라질지 모르겠으나 아주 먼 과거에서부터 아주 먼 미래까지 인류와 인공지능은 "닭이 먼저냐 달걀이 먼저냐"와 같은

순환계 속에서 영원히 태어나고 사라지는 것을 반복해가는 것이 아닐까?


* 참고로 위의 영화 중에서는 가장 최근에 본 엑스 마키나가 가장 현실감 넘쳤다. 감정 보다는 지적 호기심(지적 확장)을 위해 행동하는

  모습이 진짜 인공지능이라면 저럴 수도 있겠구나 하는 생각이 들더라...

 

저작자 표시
신고

오늘도 열심히 구글링을 하려고 구글에 들어선 순간....

구글 두들이 케이크네...

어? 오늘이 내 생일인데...

아니나 다를까...

 

 

물론 내 계정으로 로그인 되어있으니 이런 서비스야 간단하게 할 수 있는 것이지만

하느냐 안하느냐의 차이는 상당히 큰 것이다.

 

암튼 구글에게 감사~

저작자 표시
신고

예전에도 삼성 전자의 SM업무를 약 4년 정도 하였고

현재는 모 은행의 SM 업무를 3년째 하고있다.

14년 정도의 경력 중 절만이 넘는 7년이 SM 업무였다니…

아무래도 나는 SM 체질인가보다.


하지만 안타깝게도 이제서야 SM 업무를 잘하려면 어떻게 해야 하는가의 문제에 눈을 돌리게 되었다.

흔히들 SM하면 늘 반복되는 업무, 긴장감 없는 생활, SI에 비해 여유있는 근무시간 등을 떠올리게 된다.


그렇다!

대부분의 사람들이 SM는 그저 '늘 하는 일을 하는 것' 정도로 생각하고 있는 것이다.

물론 규모에 따라 장애가 발생했을 경우에 대한 긴장감이 크고 작은 차이는 있을 것이다.

하지만 그 것도 그 때 뿐…


아마 내가 불현듯 이런 생각을 하게 된 것도

너무나 널널한 SM 업무를 하고 있기 때문인지도 모르겠다…^^;;;

게다가 이런 시간에 이런 글을 블로그에 쓸 수 있다는 건 더더욱…-.-


됐고!


도대체 이 SM 업무를 잘하려면 어떻게 해야 할까?

나름 몇가지 리스트를 정리해서 앞으로 업무에 지침으로 삼아야겠다.


1. 상시적/주기적 업무에 대한 체크리스트 마련과 주기적인 확인


앞서도 언급했지만 SM이란 것이 일상적인 업무이다.

늘 같은일을 반복하는 만큼 오랜 시간 하다보면 어느 순간 형식적으로 눈길 한번 주고는

확인을 끝내는 순간이 생긴다.

명확한 체크 리스트와 이에 대한 주기적인 확인만이 이러한 관성을 조금이나마 줄여줄 것이다.


2. 담당 업무에 대한 확실한 관 리


SM의 경우 대체로 정해진 업무를 수행하지만 불특정한 업무가 불규칙적으로 오는 경우가 많다.

직원조회 화면 열심히 수정하고 있는데 일정쪽에 뭐 안된다고 연락오고, 일정 수정이 끝나기도 전에

또 메일쪽 고쳐달라고 연락이 오고…자칫하면 스케쥴링은 커녕 자신이 뭘해야 하는지조차 누락시키는

경우가 발생을 하게된다.


정기적인 업무도 물론이거니와 이런 산발적인 업무에 대한 관리가 잘 이루어져야 할 것이다.


다행이 체계가 잡혀 컨택 포인트가 단일화 되어있고 여기에서 적절히 분배가 된다면 다행이겠으나

그렇지 않은 경우는 스스로가 최소한 목록만이라도 정리를 하고 있어야 한다.


더구나 3번 항목에서도 언급이 되겠지만 자칫 본인이 관리하지 못하는 본인의 업무가 동료에게 전가되어

민폐를 끼치는 상황이 발생할 수도 있기에 최소한 자신의 업무에 대한 관리는 확실하게 해 놓아야 할 것이다.


3. 업무에 대한 전방위적인 관심


SM업무 역시 효용의 법칙을 피해갈 수 없다. 최소의 재화로 최대의 효과를 얻어야 하는 것이다.

즉 최소의 인력으로 최대의 업무를 수행해야 한다…-.-;


그러다보면 본인의 주력 업무가 아닌 다른 업무도 병행해야 하는 경우가 많다.

즉, SM은 어찌보면 수직적 지식보다는 수평적 지식을 가진 사람이 더 적당한 업무라고도 할 수 있는 것이다.


본인의 업무만도 2개 이상의 상이한 업무인데다가 운영 인력이 적기 때문에 동료가 자리를 비웠을 경우(휴가 등)

그 백업의 역할도 해야 한다.


이게 가능하려면 늘 동료들의 업무에 관심을 가지고 있어야하는 것이다.


4. 적극적인 의사소통


사실 SI같은 경우 하나의 소통만으로도 웬만한 것은 다 해결된다…바로…구글신…-.-

사람이 필요하다고 한다면 PL, PM, 옆사람 정도?


하지만 SM의 경우는 좀 다르다.

앞서 언급했듯이 컨택 포인트가 단일화 되어있으면 좀 낫다(그냥 나은 정도?)

그렇지 않다면 사방에서 (뻥 좀 포함해서)벌떼같이 전화를 해댄다.

그 중에는 공손하게 요구사항을 말하는 사람도 있겠지만

지X지X 하면서 왜 이거 안맞느냐? 왜 이거 안되느냐고 어기는 사람

밑도 끝도 없이 '해줘!'로 끝나는 사람 등등

오만가지 사람들이 다 있다.


그리고 또다시 반복되지만 다양한 업무를 소수의 인력으로 운영하다보니 외부 지식통과의

연락도 빼놓을 수 없을 것이다.


맘에 안든다고, 귀찮다고, 부끄럽다고(?) 필요한 의사소통에 소극적이 된다면

SM은 힘들어질 것이다.


실제로 현재 있는 사이트에는 개발은 좀 별로인데 이 의사소통 능력만으로 잘 버티는

특급 개발자가 있다. 이 사람은 비록 자신의 생각을 전달하는데는 좀 서툴지만 암튼

필요하다면 어디든 전화를 돌리고 의견을 교환한다. 그점 하나는(마?) 정말 존경스럽다.


5. 철저한 자기관리


조금은 이기적인 발상일지는 모르겠지만 나는 혹시 SM을 하고자 하는 사람이 있다면

이 5번 항목을 염두에 두고 하라고 얘기해주고 싶다.


운영 업무는 SI에 비해 남는 시간을 어떻게 효율적으로 사용하는가가 그 업무를 하는 기간을

가치있게 만들어줄 것인가 쓸모없게 만들어줄 것인가를 결정한다고 본다.


막말로 코딩이나 개발을 병맛으로 한다고 해도 운영 시스템 말아먹는 경우는 별로 없다.

즉 업무에 지장을 주지 않는 선에서 최대한 자신의 목표를 설정하고 그 목표에 시간을 할애하는 것이

SM 업무에서 무언가를 얻어나갈 수 있는 제일 큰 것이다.


SM 업무를 하고자 한다면 개인적인 목표 한가지를 잡고 그 목표를 이룰 수 있는 정도의 기간을

하는 것이 좋을 것 같다.


SM업무의 가장 큰 적은 관성과 타성이다.

어느 순간부터 잠시 틈나면 하는 일이라고는 무의미한 웹서핑 아니면 달콤한 꿀잠이다.

(차라리 잠은 피로회복 측면에서 좋아보인다.)


만일 SM 업무를 마치고나서 셀렉트 박스 목록 수정과 네이버 검색어 입력의 달인으로 

남고 싶지 않다면 업무 관리 이상으로 자기 관리 계획을 세워야 할 것이다.


그나저나 난 애초에 여기에 내가 만든 앱 대박날 때까지만 있기로 했는데…

아마 짤릴 때까지 여기 있어야 할 것 같다…ㅠ.ㅠ


두서 없이 쓴 글이라 과장도 있고 놓친 부분도 있고 또 잘못 알고 있는 부분도 있을 것이다.

그리고 많은 내용이 SM/SI 구분 없이 필요한 내용이기도 하고 또 사업장마다 업무마다 다른 특수성들이

있을 것이다.


이 글은 어디까지나 나의 경험에 바탕한 글이므로 이점 양해 바라고

내가 뭘 잘 아나보다하고 나한테 뭔가 질문하려고 하지 말았으면 하는 바람이다…-.-


마지막으로 이 글을 쓰는데 영감을 주신 우리 회사 정모 이사님과

정말 인간적으로는 내 스타일 아니지만 업무만큼은 FM대로하는

김모 PM에게 감사드린다.(하지만 적어도 김모 PM은 감사를 받지 못할 것 같다…)


저작자 표시
신고
  1. 김병근 2014.02.13 14:02 신고

    평범한 사람과 비범한 사람의 큰 차이는 아는것과 아는 것을 계획을 세워 꾸준히 실천하고 반성하는 작은 차이에서 시작되는것 같습니다.

새로 매버릭스 설치하고 

OS X Server 설치하고

바로 Xcode 통합 작업에 들어갔다.


우선 bitbucket에 있는 repositary 하나 등록하고

Xcode 5에서 bot 생성하고 첫 통합을 시도했다.


떡하니 뜨는 fail 메시지...

그나마 처음 fail은 repositary 인증 설정을 잘못해서 발생한 것이었다.

쉽게 해결하고 다시 통합 작업 진행...


이번에는 통합은 진행되었으나 통합 과정중에 오류 발생...

Code Signing과 Provisioning에 관한 오류다...


요런거...




OS와 Xcode를 몽창 바꿨더니 인증서와 프로비저닝을 제대로 인식 못하나보다.

구글링을 해가면서 뻔하디 뻔한 답을 수차례 시도를 해보았으나 별무신통...

결국 개발 인증서는 새로 생성해서 해결을 하였으나 이번에는 Archive 진행하면서

배포용 인증서와 프로비저닝이 말썽...


아무래도 배포용이다보니 Revoke 버튼을 쉽게 누를 수가 없다...ㅠ.ㅠ

다시 build settings로 가서 애꿎은 Code Signing 설정만 만지작 만지작...


지루하니까 결론만 말하면 다음과 같은 세팅으로 해결 봤습니다.



심플하네요...


밸류를 선택하면 프로비저닝 선택 리스트가 뜨던것도 많이 줄어들어서 현재 사용 가능한 것만 딱 뜨네요.

Xcode 4.5까지는 너줄하게 뜨는게 보기 싫긴 했는데 이렇게 간소화 되니 또 뭔가 빠진듯 아쉽기도 하고...^^;;;


암튼 이 설정으로 해결 봤습니다~

저작자 표시
신고
  1. 2014.06.30 16:58

    비밀댓글입니다

한국시간으로 지난 10월 23일 새벽 2시에 애플의 새 OS인 Mavericks(OS X 10.9, 이하 매버릭스)가 정식 출시되었다.

다양한 기능 개선과 추가로 맥 사용자들은 오래전부터 매버릭스가 출시되기를 고대하고 있었다.


*자세한 기능은 … http://www.apple.com/kr/osx/whats-new/


그 기다림의 끝에서 아주 반가운 소식과 함께 매버릭스가 출시되었는데…

바로 '무료 배포'라는 것이다.


그런데 애플 개발자 사이트에 등록한 개발자들에게는 또 하나의 선물이 있었으니…

OS X Server가 그것이다.


원래 OS X Server는 라이언 버전까지는 OS에 통합되어 일반 데스크탑용 Lion과는 달리

OS X Lion Server라는 별도의 OS로 판매가 되었다. 마치 윈도우 Server와 같은 개념이다.

그러던 것이 Mountain Lion으로 오면서 아예 OS X Server라는 서버 모듈만을 별도로 분리하여

판매를 하게 되었다. 즉, Mountain Lion을 데스크탑에 쓰다가 별도로 OS X Server를 구매하여

설치하면 바로 서버 버전의 OS가 되는 것이다. 기존 OS X Server의 가격은 $19.99이다.





이 OS X Server를 개발자들에게 무료 배포한 것이다.


그런데 이상한 점이 있다.

일반적인 개발자들이라면, 특히 애플 기반의 개발자들이라면 특별히 서버 모듈같은 것은 사용할 일이

없을텐데…


어쨌든 공짜니까! 양잿물보단 훨씬 좋으니까! 일단 다운로드 받아 설치를 해보았다.

그리고 서버 관리 콘솔을 실행시켜 찬찬히 보다보니….그 전에 보지 못했던 것들 중 유독 하나가

눈에 띈다.


Xcode…




상세한 도움말도 지원한다.




그렇다! 이번 업그레이드를 통해 OS X Server에 맥 OS 기반의 개발 IDE인 Xcode가 통합된 것이다.

용도는 CI(Continuous Integration)이다.


프로세스는 이렇다.


서버 콘솔의 Xcode 항목에서 Repositary(SVN과  Git 지원)를 등록한다.

사용할 이름과 URL 그리고 인증 방식을 선택하여 입력하면 된다.







Xcode IDE에서 등록된 Repositary와 연동되는 BOT을 다음과 같이 생성한다.


1. Scheme(빌드 대상)과 이름 및 서버 선택



2. 빌드 스케쥴과 빌드시 수행할 액션 그리고 빌드 전에 clean 수행 여부를 설정



3. 빌드 성공 혹은 실패시 메일을 전달 받을 메일 주소 설정




이렇게 설정해 놓으면 BOT 생성시 등록한 스케쥴에 맞춰 프로젝트 환경에 따라 빌드, 분석, 테스트, Archive 및

최종 커밋까지 자동으로 수행이 된다.


이렇게 진행된 작업은 Xcode IDE 내에서나 웹을 통해 그 결과를 확인할 수 있다.


Xcode 화면





web 화면





사실 CI는 소스코드 무결성 유지와 테스트 및 빌드 그리고 최종 생산품 제출에 이르기까지

그야말로  개발 전과정에 대한 통합이 이루어지는 시스템이다.  이러한 과정에서 개발자들은 보다 신속하게

빌드를 진행할 수 있고 보다 빨리 소스 상의 오류를 감지할 수 있게 된다.


이러한 막강한 기능과 역할에 비해 다른 개발 시스템에 비해 관심도가 그리 높지 않은 형편이다.

꽤 역사가 오래된 Cruise Control부터 최근의 Travis까지 다양한 Tool들도 존재한다.

자세한 내용은 위키피디아 참조 : http://en.wikipedia.org/wiki/Continuous_integration


현재 일하고 있는 곳에서는 Jenkins(구 Hudson)를 사용하고 있는데 Jenkins도 MAC 환경하에서

Xcode 빌드를 지원하여 iOS 개발자로서는 매우 유용하게 사용을 하고 있다.

그런데 새로운 OS X Server와 Xcode5에 이러한 기능이 통합되어 MAC/iOS 개발자들은 최적화된 환경을

제공 받을 수 있게 된 것이다.

(다만 나는 아쉽게도 안드로이드도 함께 관리를 해야 하는 입장이어서 jenkins를 버릴 수는 없다)




(맥 OS X 상에서의 jenkins를 이용한 CI 시스템 구축은 다음 링크를 참조 : http://mazdah.tistory.com/519)


애플은 가장 앞서서 개발자-벤더-사용자가 통합되는 IT 생태계를 만들어왔다. 이 생태계를 통해 이익을 얻는

사람들이 많겠으나 그중 가장 이익을 얻고 있는 것은 개발자가 아닌가 한다. 그리고 그걸 증명이라도 하듯이

애플은 개발자들에게 더 나은 환경을 제공해주고 있다.


비록 국내에서 아이폰의 점유율이 높지 않아 OS X 기반의 개발자들의 입지가 좁아지고 있는 것은 사실이지만

이런 개선들이 지속적으로 이루어진다면 앞으로의 전망은 밝을 것으로 기대된다.

저작자 표시
신고

글 이전일 : 2013/05/03 15:50 


최초 작성일 : 2008.12.10

많은 소규모 SI업체들이 상황이 어려워질 때마다 입버릇 처럼 하는 말이 있다.

'솔루션 하나 만들어야지...'

사실 영업에 전적으로 의존을 하여 프로젝트를 수주하는 것으로 연명하는 소규모 SI업체에게 있어서
하루 하루가 불안한 연속이 아닐 수 없다. 그래서 안정적인 회사 운영의 기반으로 그럴 듯한
제품 하나 만들어서 팔아먹는 것은 마치 은행에 큰 돈을 예치하고 여유있게 이자를 타먹는
아주 여유로운 기분일 것이다.

하지만 모두 알고있거니와
SI업체로 시작해서 쓸만한 솔루션을 만든 회사는 아직 본 적이 없다.
얼핏 수많은 프로젝트를 거치면서 쌓이 Knowhow를 통해 무언가 그럴듯한 솔루션이 나올법도 한
SI업체에서 제대로 된 솔루션이 나오지 않는 다는 것은 역설적인 상황으로 보인다.

하지만 대기업 SI업체들이 시작을 독식하는 상황에서 중소 SI업체가 외도를 할 만한 여유를
갖는 것 또한 상상하기 힘든 현실이다. 아무리 기존 인력을 활용하여 최대한 비용을 줄인다
하더리도 솔루션 개발이 그리 싸고 빠르게 이루어지는 것이 아닌만큼 중소규모의 SI업체에서
자체적으로 솔루션을 개발한다는 것은 쉽지 않은 것이 사실이다.

그럼에도 불구하고 SI업체로서 솔루션 개발에 손을 대고 싶다고 한다면 자신들이 수행한
프로젝트의 Knowhow를 축적하고 이를 분석하여 명확한 타겟과 기술을 설정하고 이를 통해
외부적으로 투자를 받는 것이 가장 확실한 방법이 될 것이다.

가장 중요한 것은 'Knowhow를 축적하고 이를 분석'한다는 것이다.
'솔루션'이란 말 그대로 어떠한 '문제'에 대한 해결책인 것이다.
문제도 알지 못하는 데서 해결책이 나올 수는 없다. 이런 점에서 다양한 영역의
다양한 문제를 정리하고 분석한다는 것은
솔루션 개발의 출발점이자 가장 중요한 부분이라 아니할 수 없다.

이렇게 출발점이 정해졌다면 다음으로는 2가지 방향이 있다고 본다.
하나는 이미 출시된 제품을 벤치마킹하여 보다 나은 기능의 새 제품을 만들어 내는 일,
또 하나는 중장기 플랜을 설정하여 전혀 새롭고 혁신적인 기술의 제품을 만들어 내는 일이다.

첫 번째의 경우는 모델로 삼을 대상이 존재하고 기존의 시장 영역도 있기 때문에 기술적인 실패의
위험은 적겠지만 선발 업체와의 경쟁이 쉽지만은 않을 것이다.

두 번째의 경우는 전혀 새로운 제품을 만들어낸다는 점에서 기술적인 투자에 많은 부담이 생길
것이고 새로운 시장을 개척해야 하는 위험이 있으나 일단 성공을 하게 되면 선발업체로서의
입지를 굳건히 세울 수 있을 것이다.

정작 가장 중요한것은 경영진의 의사 결정이다.
이제까지 말한 준비 단계 및 방향성에 대해 숙고하고 결정을 내려야 하며
일단 결정을 내린 후에는 과감하게 추진을 할 수 있어야 한다.

어설프게 '솔루션이나 한 번 만들어 볼까?' 하는 안이한 생각으로는 시간과 돈의 낭비
그 이상도 이하도 아닌 것이다.

어플리케이션 개발이 그렇듯이 이러한 사업의 진행 또한 충분한 시간을 통해 분석을 하고
설계를 하여야 그 진행이 탄탄해 지고 결과 역시 만족스러울 것이다.

이제 SI 분야만 남은 우리 회사역시 끊임없이 솔루션 개발에 대한 문제제기는 있어왔지만
단 한번도 성공적인 결과를 남긴 적이 없다. 외부 그룹웨어를 인수하여 판매를 해보았으나
결과는 좋지 않았다. 그도 그럴 것이 아무리 개발팀을 함께 인수했다고 하나 단지 유지 보수를
위한 인력일 뿐 그 솔루션의 미래에 대한 고려는 전혀 없다시피 했기 때문이었다고 생각한다.

여기서 또 하나 추가할 수 있는 내용은 바로 '솔루션의 미래'다.
만들어놓기만 하고 관리를 하지 않은 솔루션이라면 그야말로 사생아일 뿐이다.
기술은 계속 변화하며 기술의 변화는 사회의 변화와 상호 작용하며 주변의 많은 것들을
변화시킨다.

이런 변화의 소용돌이에서 변화를 따라가지 못하는 솔루션이란 일회용 종이컵에 불과한 것이다.

두서 없이 이야기가 길어졌다.
세줄 요약으로 마무리를 짓겠다...^^;;;

1. '솔루션'의 정의를 명확히 하고
2. 문제 상황을 축적, 분석하여 방향성을 잡아서 개발하며
3. 끊임 없이 업그레이드 되는 솔루션을 만들어야 한다.

부디 성공적인 솔루션이 탄생하기를...

저작자 표시
신고

+ Recent posts

티스토리 툴바