스크린과  영사대가 배송되어 왔습니다.

스크린은 일단 크기로 압도 해서  합격
영사대는 고급형이라고 해서 구매 하였지만.. 평탄도도 안나오고 좀 허접했습니다.
게다가 영사대 설치하고 앞으로 빔을 쏘니 회의 테이블 주변 앉아 있으면 머리 그림자가 생기고
프로젝터 쪽 빔 때문에 눈이 부셔서 사용하기가 좋지 않습니다.

프로젝터는 무조건 천정에 설치하는것이 진리인듯합니다. 

(2012.4.25 내용 추가 )
천정에 설치하고서 좋아했는데.. 머리 그림자가 안생기고 깔끔한것은 정말 좋았는데..
입사각과 반사각의 차이로 인해 화면 색감이 현저히 떨어지는 현상이 발생하여 
얼마뒤 다시 천장에서 내려서 영사대에  올려두는것으로 바꿨습니다. 걸리적 거리고 깔끔하지는 않지만
선명도와 화질이 최우선이기 때문에.. 어쩔수가 없네요.



아래 사진은 스크린 프레임을 조립하기 위해 펼쳐 놓은것입니다.
생각보다 훨씬 큰것 같아서 놀랐습니다. 순간 너무 커서 회의실 벽면에 설치가 안될것 같은 불안감이 살짝 들었지만
다행히 꽉차게 맞았습니다.



스크린 원단과 프레임을 스프링으로 고정하고 있는 장차장과 애량씨


스크린 장착용 지그를 벽에 장착하고 있는 곽대리



석고벽체라서 잘 빠져버려서 장차장이 다시 시도중.. 사다리가 부러질까 불안함..



설치후 윈도우 화면



FULL HD 영화도 한번 틀어보고 ( 스타워즈 )


FULL HD 영화도 한번 틀어보고 ( 스타워즈 ) 






Posted by ICT 이성열

댓글을 달아 주세요


코드리뷰를 열심히 하려고 작년에 47인치 LED TV를 구매했었습니다. (물론 일반 회의때도 사용 )
하지만 회사의 회의테이블이 그리 크지 않음에도 불구하고 먼쪽에 앉은 사람은 소스 코드를 볼때마다 잘 안보여서 인상을 찌푸려야 했죠. 그나마 소스 코드는 폰트조절이 됐지만, Redmine 웹 화면을 띄어놓을때는 조절도 잘 안되어서 힘들었습니다.

그래서 생각한것이 모니터 분배기를 이용한 화면 공유 입니다.



TV는 그대로두고 LCD 모니터 21인치 2개를 회의 테이블에 더 설치하고 모니터 분배기로  같은 화면을 공유하는 것이죠. 화면 보는것은 그럭저럭 쓸만 했습니다.
다만 . 회의실 테이블이 모니터와 모니터 케이블등으로 지저분해지고, 회의할때 모니터 때문에 서로 얼굴이 잘 안보이는 단점이 바로 나타났습니다.

그래서 심사숙고(1~2시간) 끝이 결정한 것이 FULL HD 프로젝터 시스템을 세팅하는 것이었습니다.
요즘 모든 구매는 충동 구매로 시작 되어 버리는군요. ^^;

[ 옵토마 H23 Full HD 프로젝터 ]



[ 윤씨네 고급 영사대 ]
1.2 미터 높이까지 높이 조절이 가능합니다.





[윤씨네 120인치 16:9 와이드 액자형 스크린 AV원단(gain:2.8) ]
아래 이미지는 우리 회사에 설치한 사진은 아닙니다. 아직 배송중.. ^^ 




이번에 세팅하는 시스템이 우리 회사 코드 리뷰 & 멀티미디어를 위한  최종 시스템이 되기를 바랍니다. 

설치 장면
http://ictlab.tistory.com/276 
Posted by ICT 이성열

댓글을 달아 주세요

개발이야기2009.12.02 04:17

SW개발에서 'Peer Review'의 중요성


김익환 SW컨설턴트 ik_kim@yahoo.com 의 글을 인용하였습니다.

소프트웨어 개발방법론이나 프로세스 개선모델을 보면 'Peer Review(동료검토)'라는 말이 예외없이 나온다.

Peer Review의 '검토'라는 의미에서 나오는 선입관때문에 많은 사람들이 거부감을 갖는다. 마치 내가 일을 잘못해서 조사받는다는 인상을 받기 때문이다.

물론 잘못된 것을 발견해서 고치는 것도 목적중의 하나이긴 하지만 근본적으로 Peer Review는 '어느 누구도 한 사람이 완벽할 수 없다'는 가정에서 출발한다.

소프트웨어는 근본적으로 완벽을 추구해야 한다. 시작부터 완벽을 추구하지 않고 대충 개발한 소프트웨어는 지뢰밭을 걸어가는 것이나 마찬가지다. 언젠가는 터지고 필연적으로 당도하는 'Fire Fighting' 모드에 들어가서 터지는 문제의 해결에 많은 노력을 허비하게 된다. 그로 인해 발목이 잡히고 장기적으로 성공하기는 무척이나 어렵게 된다.

이 시나리오는 어느 정도 규모있는 소프트웨어를 개발해 본 경험이 있는 사람이면 쉽게 이해할 것이다. 성숙하지 못한 회사의 소프트웨어에서 발생하는 대부분의 중요한 문제는 사소한 개인의 결정에서 시작된다. 미리 검토만 한번 했더라면 이같은 문제가 애초에 생기지 않았을 텐데 하는 경우를 많이 본다.

Peer Review를 검토의 세밀함과 강도에 따라 세분해서 'Inspection', 'Review', 'Desk Check' 등으로 두 종류나 세 종류로 구분하기도 한다. 이러한 분류에 따라 검토방식이 달라야 한다는 의미에서 세분화 했을지 모르나 검토의 목적을 명확히 이해하는 한 세분화하지 않더라도 얼마나 자세히 검토해야 하는 정도의 판단은 경험이 있는 사람이면 자율적으로 알아서 할 수 있다.

Peer Review는 부정적인 의미를 갖는 '검토'보다 사실은 '의논'이라고 하는 것이 더 가깝다. 의논없이 혼자의 능력을 과신하는 사람이 가장 위험하다. 그래서 혼자서 조용히 일하는 사람이 바로 요주의 인물이다. 천재라고 해도 소프트웨어에 관련한 방대하고 새로 생겨나는 모든 지식을 갖추기도 힘들고, 또 시간이 요구되는 직접경험을 소유하기도 힘들다. 그래서 다른 사람의 지식을 서로 빌리는 가장 좋은 방법이 Peer Review인 것이다.

Peer Review의 대상은 소프트웨어의 개발단계인 제품기획, 요구사양, 설계, 코딩, 빌드, 테스트 등에서 나오는 모든 산출물에 해당된다. Peer Review에서는 산출물의 내용만 검토하는 것이 아니라 어떤 산출물이 나와야 된다는 것도 토의되어야 한다.

개발방법론에서 명시한 수 많은 산출물 리스트는 가이드정도로 사용해야지 꼭 작성해야 한다고 생각하면 엄청난 비효율을 초래한다. 한 회사에서도 모든 프로젝트가 다 상이하다는 것을 고려하면 왜 산출물 리스트를 획일적으로 정하기 어려운 지 짐작할 수 있다. 많은 문서를 작성한다는 것은 그 만큼 미래에 변경이 필요할 때 많은 수정을 해야 한다는 것을 의미한다. 그리고 문서가 많다 보면 중복되는 정보가 여기저기 적히기 쉽다. 이런 것들을 여러 사람이 토의해서 가장 적절한 합의점을 끌어 내는 것이 중요하다.

Peer Review에서 여러 사람이 토의를 하게 되면 다양한 의견이 나오게 되는데 옳은 의견과 다수의 의견을 혼동하면 안 된다. 안건에 따라 어떤 방법이 적절한 지 선택해야 한다. 가장 쉬운 예로 코딩 방식 중에 괄호를 같은 줄에 적느냐 다음 줄에 적느냐 하는 것들은 많은 사람이 선호하는 다수결의 원칙을 따르는 것이 무난할 것이다.

하지만 대부분의 중요한 결정에서는 다수결의 방식이 부적절하다. 옳고 그르냐의 문제는 서로 의논을 해서 모두 이해시키고 설득해서 만장일치로 결정하는 것을 목표로 해야 한다. 모르는 사람을 적당히 설득해서 투표로 이기는 것은 좋은 결정이 될 수 없다는 것이다. 마지막 한 사람까지 진심으로 옳다고 생각하도록 노력해야 한다. 그래서 학습능력이 중요하다.

옳은 의견을 가지고 있다고 생각하는 사람이 다른 사람들을 확신시킬 수 있어야 하는데 다른 사람들을 확신시키지 못했다면 완전한 지식을 갖고 있지 못하거나, 안건이 너무 어렵거나 혹은 학습능력이 떨어지는 동료들일 수 있다. 어떠한 케이스이든 간에 이런 상황에 오게 된다는 것은 그리 바람직한 경우는 아니다. 서로 설득이 안 되는 경우 마지막 방법으로 투표를 하거나 '캐스팅 보트(Casting Vote)'를 가진 권위있는 사람이 결정할 수 밖에 없는데 투표를 하게 된다면 그 회사의 최고 전문가그룹에서 해야 한다.

많은 경우에 검토는 경험있고 지식있는 사람들이 이것 저것 물어도 보고 지적도 하면서 리드해 나가게 된다. 하지만 누구든지 완벽한 사람은 없기 때문에 여러 사람이 의견을 표출하고 그런 의견을 경청해 듣는 것도 중요하다. 이렇게 함으로써 치명적인 결함이 있을 수 있는 소수의 편견을 발견할 수 있게 된다.

아무리 완벽하게 작성했다고 생각하는 간단한 코드도 다른 사람이 보면 더 좋은 방법을 발견하는 것을 무수히 본다. Review를 받는 사람도 다른 사람이 Review를 한다고 생각하면 한번 더 쳐다보게 된다. 그럼으로써 생각하지 못했던 많은 부분이 수정되고 정리된다. 다시 볼 때 마다 더 좋은 방법이 끊임없이 생각나는 것이 필자의 경험이다.

효율적인 Review가 되기 위해서는 열등감을 없애야 한다. 어떠한 질문도 창피하다고 생각하지 않는 문화를 만들어야 한다. 어설프게 아는 사람이 열등감때문에 더 방어적이 되고 참여를 두려워 한다. 많이 아는 사람일수록 열등감이 없기 때문에 다른 사람의 의견을 스스럼없이 구하는 경우가 많다.

하지만 모두를 위해 긴장을 풀고 열린(Open) 분위기를 만들기 위해서는 모두가 바보 같은 질문을 하나씩 하는 것도 좋은 방법이다. 괜히 자존심 세우고 실수하지 않으려고 조용히 있는 것이 결국은 개인이나 회사나 경쟁에서 점점 더 뒤떨어지는 이유가 된다.

Peer Review에서는 항상 '왜 다른 방법을 사용하지 않는가' 하는 질문도 해야 한다. 개인의 한정된 지식으로는 제품을 만들어 내도 작동은 할 지 모르나 가장 좋은 방법은 아닐 수 있다. 기능을 구현하는 것은 어렵지 않다. 하지만 잘못된 경우에 대처하는 것은 어렵다. 워낙 경우의 수가 많기 때문이다. 이럴 때 여러 사람의 의견이 잘못된 경우를 발견하는데 많은 도움을 준다.
Peer Review를 많이 해본 사람이면 여러 의견의 다양성과 기발한 아이디어에 놀란 경험들을 갖고 있을 것이다.

Peer Review의 또 다른 목적은 배우는 것이다. Peer review 만큼 회사에서 지식을 공유하고 전파하는 좋은 방법은 없다. Peer Review를 주최하는 사람이 자기 한 일을 발표하게 되는데 후배는 후배대로, 동료는 동료대로 배울 것이 있다. 선배라고 하더라도 배울 점이 있다.

이런 식으로 진행됨으로써 서로 가장 좋은 방법을 은연중에 배우고 따라 하게 되고 몸에 익히게 되는 것이다. 얼마나 Peer Review가 중요한가는 계속해보면 나중에 깨닫게 된다. 서로 좋은 영향을 주고 자기가 한 일을 자랑하는 것이 Peer Review를 즐겁게 진행할 수 있는 방법이다. 조언을 구하는 것도 중요하다. 모르면 물어보는 것이 왕이다. 모르는 데도 열등감에서 혼자서 연구해 봐야 최적의 결론에 도달하기도 힘들고 시간만 낭비할 가능성이 높다.

제대로 된 Peer Review의 중요성은 많이 해 본 사람이면 알게 된다. 그런데 운동과 비슷한 점이 있어서 좋은 줄 알지만 귀찮아서 안 하는 경우가 많기 때문에 어느 정도의 강제성은 있어야 한다.

항상 깨달음은 나중에 오게 되는 게 인간이 겪는 시행착오다.
스스로 깨닫기 전 까지는 누군가 강제로 시키지 않으면 안 하는 것이 또 Peer Review의 본질이다.

출처는 2004년도 아이뉴스24 기사입니다.
http://www.inews24.com/php/news_view.php?g_serial=120492&g_menu=090334

'개발이야기' 카테고리의 다른 글

개밥 먹기(dog food)를 즐깁시다~  (2) 2009.12.12
모방 과 창조  (0) 2009.12.08
SW개발에서 'Peer Review'의 중요성  (0) 2009.12.02
사장들의 유형  (1) 2009.12.01
C++Builder2010 C++ Class Explorer  (0) 2009.11.25
Mensa(멘사)회원들보다 똑똑한 Waitress  (3) 2009.11.06
Posted by ICT 이성열

댓글을 달아 주세요