Blog.RedAge.NET

백업 로그를 보다가 심심(?)해서 드디어(?) 시도 해 봅니다.

원본은 키시야스님의 바칼로레아 문제에 답해보기 제안 이고 개인적으로 바칼로레아 프로젝트라고 명명(?)하고 틈나는데로 하나씩 해보기로 키시야스님과 이야기를 주고 받은 적이 있지요. 그 약속(?)을 이제야 지킵니다.

5.9. 자유를 두려워 해야 하나? – 아니요.

주어지지 않았던 환경에 대한 두려움이라는 관점에서 보면 자유는 두려울 수 밖에 없는 것 입니다. 실제로 자유를 만끽할 수 있는 많은 공동체/사회체제에서도 자유란 힘들고 어려운 것으로 인식됩니다 적지않은 비용과 노력이 자유를 위해 희생(?)되고 있습니다. 이 비용에 대해 사회적으로 역사적으로 많은 논의가 있어왔습니다만(세종대왕의 독재아래서 살것인가, 민주주의 국가에서 살 것인가? 같은 주제의 논의들) 아직 인류는 자유를 두려워하고 있습니다.

허나, 이는 사회 공동체적 관점에서의 자유일때 이야기 입니다. 한 개인의 입장에서의 자유란 내가 어떠한 존재로 생명을 불태우며 살아갈 것인가? 에 대한 문제입니다. 남들의 유행에 따라 살 것인가?(공무원-공사-대기업 취업하기,취업공장이 되어버린 전공의 의미가 없어진 대학, 정치에 대한 무관심, 몇 살 땐 뭘 해야 한다는 생각 등등..) 스스로의 생각에 따라 살 것인가? 에 대한 문제라고 생각합니다. 물론 스스로의 선택으로 유행에 따르기로 결심 했다면 그에 대한 댓가 – 예를 들면 의미없어 보이는 혹은 무기력한 재미없는 하루하루 – 를 치를 계산(혹은 각오)이 되어 있어야 합니다. 물론 그 반대의 선택에 대한 댓가(예를 들면 고달픈 인생, 인정받지 못하는 삶) 또한 마찬가지지요.그런 인생의 선택들을 스스로 생각하고 정할수 있느냐, 스스로 정했느냐, 그리고 스스로의 선택에 대한 결과가 스스로에게 예속되느냐 되지 않느냐를 기준을 저는  ‘자유’라고 부르고 있습니다. 그 선택의 폭이 넓은 사회를 ‘우왕ㅋ굳ㅋ’ 하면서 부러워하고 그렇지 못한 곳을 보고 ‘뭐야 저거’ 하면서 비판합니다.

어느 사회나 기본 원리는 Give & Take, 작용-반작용입니다. 항상 자유로울 수 없고, 항상 얽메여 있는 것도 불가능(당신의 선택으로 노예가 된다고 치더라고 그건 당신의 선택이므로 당신이 누리는 자유입니다.) 합니다. 저는 지금 ‘상대적으로’ 많은 자유를 누리고 있다고 생각하며, 그 삶에 무척 만족하고 즐거워 하고 있습니다. 저를 보고 다른 친구들은 부러워하기도 하며, 저처럼 살기를 ‘두려워’ 하기도 하더군요.

자. 이제 자유란 ‘두려운’ 것일까요? 즐거운 것일까요? 당신의 잊어버렸던(혹은 잃어버렸던) ‘자유’는 찾으셨습니까?

짜장면과 개발자 란 글의 트랙백입니다.

마침 어제 점심(잠들기 전이니..)이 중국집이여서.. 생각나더군요.

사용자 입장에서 한번 풀어보겠습니다.

일단 오늘 점심은 중국집!! 으로 결정. 점심 시간이 되어 근처에 잘한다는 중국집에 룰루랄라 가서 자리를 잡습니다.

중국요리가 어떤건지는 알고 있습니다. 국민 요리 자장면도 있고 사천 요리는 맵고, 삼선이란 단어가 들어 있으면 해물이 많이 들어 있겠죠. 그러다가 요즘 개발 되었다는 짬짜면, 탕볶밥.. 너무도 다양한 메뉴에 눈이 휘둥글해집니다.

결국 이런 저런 메뉴를 고르다가 번뇌에 빠집니다. 번뇌에 빠지는 순간… ‘중국 요리는 느끼하던데..’ , ‘몇인분 이상 시키면 군만두도 서비스로 준다던데…’ 등의 생각에 다다르게 되고 처음에 ‘룰루랄라’하는 마음은 온데간데 없습니다.

그러다가 결국 아무 요리나 시킵니다. 그리고 먹으면서.. ‘나 이런거 원한게 아니였는데…’ 라며 후회합니다.

IT도 마찬가집니다. 사용자는 홈페이지가 필요하다, ERP가 필요하다, CRM이 뭐다.. 무슨 솔루션인가가 필요하다더라 라는 것을 잘 알고 기꺼운 마음으로 업체에 컨택하고 프로젝트를 진행하게 됩니다. 프로젝트를 진행하다 보면.. ‘이게 아닌데..’하는 생각들로 가득차게 되고 먼가 물어 보면 알기 쉽게 대답이 나오지도 않습니다.(사용자 입장에선 다형성이나, 라조육과 라조기의 차이나 머리에 안들어오긴 마찬가집니다..)

요리는 상도의(?)상 뒤집지 못하지만, 이물질(아~~주 심각한 버그?)이 나오거나 하면 강하게 클레임을 걸 수 있습니다. IT의 경우 그 이물질의 기준이 사용자에게 있기 때문에..(OTL) 원활한 진행이 더 어려워 지기도 합니다.

결국 어떻게든 만들어지지만 갑(사용자,고객)이나 을(회사,개발자)이나 모두 만족스럽지 못합니다. 차라리 홍x반점 04xx 처럼 ‘짬뽕’만을 전문으로 하던지(우린 이거만 해요~), 노다메 칸타빌레의 중국집 ‘우라켄’ 처럼 ‘클럽 하우스 샌드위치와 에스프레소’라도 주문하면 만들어 줄 정도의 준비(…)가 되어 있어야 서로 만족스러운(?) 결과를 낼 수 있습니다.

물론 현재는 IT산업 자체는 세계적으로 안정화 되어 가고 있습니다만.. 국내에서의 이 산업 자체가 더 성숙하기 위해선 이런 일들에 대해서 커뮤니케이션하는 프로토콜들이 정해질 필요가 있습니다.(사회/문화적 합의를 통하는게 제일 무난하겠죠) ‘을’의 입장에서는 갑측에서 깔끔하게 ‘클럽 하우스 샌드위치와 에스프레소’라고 주문해주고, 우린 그게 힘들겠다. 다른 곳을 찾아보시지요~ 라고 하는 편이 속 편할 수도 있고, ‘갑’의 입장에서는 홍x반점 처럼 ‘우린 이 분야에선 확실해요.’라고 하는 곳을 쉽게 찾을 수 있도록 ‘뭘 먹고 싶은지 제대로 정하는 일’이 선행되어야 하지 않을까?

이러나 저러나 아직 우리의 인식수준은… 포병이나 상근이나 해병대나 특전사나 모두 같은 군인이듯이.. 당신이 서버 관리자건 HTML 코더건 C 프로그래머건 웹 프로그래머건… ‘IT회사에서 근무하는 컴퓨터 잘 하는 사람’(좀 심하게는 오덕후?)일 뿐 입니다. IT 산업 전반이 성숙해져서.. 프로그래밍 언어나 연차로 구분 되지 말고 의사들 처럼 전문분야로 구분되어질 때 즈음 되면 자연스레 줄어들 것만 같습니다~

횡설수설 했습니다. 긴 글 읽어주셔서 감사합니다.

2줄 요약.

1. 중국집 자주 가지 말자(응?..)

2. 대세는 클럽 샌드위치와  에스프레소(응??….)

오늘도 나는 교회에 가지 않을 것이다 란 제목의 글을 읽고 무척 마음과 생각을 움직이는 바가 있고 마침 문득 생각나는 바가 있어 트랙백 합니다.

현직 대통령이신 분과 대한민국 기독교(카톨릭 제외)의 공통점이 몇가지 있습니다.

1. 상대방에게 무자비한 폭력을 가하며, 이를 폭력이라고 생각하지 않는다.
2. 나는 틀리지 않았다. 옳다.
3. 행위에 대한 논리적 정당성이 결여되어 있다.
4. 욕을 먹어도 변하지 않는다.

떠올려 보면 살아가는 가운데 저런 이야기 나열하면서 아~ 그사람~ 하면서 끄덕끄덕 하시는 분들도 계시겠지요? 참 여러가지로 주변을 피곤하게 하는 유형인 듯 합니다.

저도 조금 높은 자리나 성과를 내서 목소리 낼 권력을 손에 쥐게되면 저리 행동했던 기억이 있습니다. 어쩌면 누구나 그럴 수 있는 것 이겠지요. 저야  지금은 그러지 않기 위해 반성하며 지내지만…(그간 주변에 폐 끼쳤던 분들 죄송합니다.)

개인인 저야 하루하루 스스로를 돌아보며 삼가한다고 하지만… 대체 이 사태를 어떻게 해야 할까요?(그래..대통령은 임기라도 있지..)

Hani님의 일과 학습 에서 트랙백 합니다.

1. 수박 겉핥기 식 학습 마인드를 가진 스스로에 대한 반성

수박 겉핥기 식 학습마인드는 말하자면 “단기적인 성과와 장기적인 발전의 Trade Off” 입니다. 급하게 수정해야 할 부분을 고치고나니 알수 없는 문제가 터졌다. 그렇게되면 정말 그로기 상태. 어떻게 해야 할지 모르는 것입니다. 그런 요구사항을 맞추는데 급급했을 뿐이고 눈에 보이는 진도에만 메달렸지 실제 뒷단(설계적인 부분이나 경험적인 부분이 적용되어야 하는 부분에 있어)에 문제점들에 대해서는 생각하지 않습니다.(당장 눈에 돌아가는 것 처럼만 보이면 되니까요..)

그렇게 운영되다가 몇 개월 혹은 몇 달뒤에 문제가 뻥~ 터지면 악의 축이신 해결사(^^)분들을 모셔서 비싼 댓가(돈의 문제뿐 아니라 시간 및 여러가지..)를 치르고 문제를 해결합니다.

물론 한국 사회의 구조적 병폐(?)로 인하여 깊이 있는 학습(혹은 자기계발) 자체가 힘든 경우도 많고 이를 토로하시는 분들을 주변에 많이 계십니다. 학교로 돌아가서 공부에도 매진해보시고 여러 교육과정을 찾아듣기는 하지만 어느 것 하나  충족시켜 딱 이것이다 하고 맘에 드는 것은 없다고들 하십니다. 그렇게 몇년을 시름시름 앓고(?) 계시다가  이런저런 나쁜 일로 일에 대한 열정을 잃고 다른 일로 떠나시는 분들의 이야기도 들어보았습니다.

그렇다고 그런 학습법이 무조건 나쁘다고만은 할 수 없습니다.

2. 수박 겉핥기 식의 학습을 긍정적으로 이용해보자.

서론이 길었습니다. 오늘의 진정한 주제가 되겠습니다. 이런 문제가 많은 수박 겉핥기 식의 학습을 어떻게 긍정적으로 이용해 볼 수 있을까요? Hani님의 글을 인용해 봅니다.

수박 겉핥기 식 학습 마인드로 수행했던 프로젝트 몇 건에서 제가 얻은 건 무엇일까요? 하나는 ‘일 잘한다는 칭찬’과 ‘속이 빈 중국호떡을 먹은 뒤 생기는 공복감 비슷한 지적인 배고픔’이었습니다.

수박 겉핥기 식 학습으로 생긴 저 ‘공복감’이야 말로 우리가 잊지말아야 할 부분 아닌가 합니다. 수박 겉핥기 식 학습으로 새로운 분야를 Start up 했고 경험도 쌓았습니다. 그 분야에 대해서 체계적으로 제대로 공부할 기회(!!)를 얻은 건 아닐까요?

요즘 회사의 Was를 Resin 최신버젼(회사의 기존것이 너무 구버젼 이였습니다.)으로 교체중이였습니다. 예전에 한번 만져본 경험(만 있습니다..)이 있는 녀석이라 최신버젼에 테스트로 당장 눈에 보이게끔 회사 서비스를 올리는 것에는 아무 문제가 없었습니다. 하지만 실제 서비스 가능한 녀석은 아니라 내부적인 구조와 자세한 세팅(SSL부터 Session등등..)은 또 몇일 끙끙거리며 작업을 해야 했습니다. 아마 다음번에 다른 서비스에 Resin을 이용하라고 하면 자신있게 할 수 있을 겁니다.

처음에는 그냥 설정만 조금 만져본 Resin에 대한 경험(수박 겉핥기식 학습)을 지속적인 학습으로 승화(??)되면 Resin이라는 WAS의 전문가가 아니더라도 회사 서비스의 WAS 변경 정도는 할 수 있게 되었습니다.(이건 그냥 하나의 예를 든 것입니다…)

3. 결론적으로…

수박 겉핥기 학습하는 것은 배움의 기회를 만들어 내는 것이고 여기서 만들어진 기회를 노력하여 스스로 학습하도록 이어지면 우리가 해온 수 많은 수박 겉핥기 학습들(어쩐지 찔립니다만..)이 그리 헛 것많은 되지 않을 것 같습니다. 물론 이를 위한 적지 않은 노력이 필요하겠지만 말이죠.

한 줄 요약 : 열심히 공부하자. 예습이 안되면 복습이라도 잘하자.

겸손한 개발자가 만든 거만한 소프트웨어

‘개발업무’이외에도 업무와 관련된 커뮤니케이션 자체 대한 절실함이 느껴지는 하루 하루 입니다. 마침 좋은 기회(?)를 맞이하여 현재 칼퇴근의 신화(?)를 창조한 현 개발팀 이야기를 잠깐 해 볼까 합니다.

1. 조직과 조직간의 의사소통

- 회사내에 Feedback을 주는 사람(or 부서)이 거의 없습니다. 일정확인도 거의 없습니다.

- 업무 연락 및 관리 업무를 담당한 분들은 다들 자기 일에 바빠서 개발업무에 신경을 거의 쓰지 않으십니다.

이런 경우 겪어보셨는지요?(저..저도 처음입니다만) 사실 기획 업무를 맡으신 분과의 원활한 의사 소통이 프로젝트 성공의 상당히 중요한 요소라고 생각하는데 무척 안타까운 점이였습니다.

이런 회사 분위기를 바꿔보기 위해서 개발팀이 나서서 메일을 보내고 일을 진행하고 외부와 연락하는 모든 메일에 참조로 붙이고, 외주업체와의 협업시에는 반드시 기획팀을 통하여 연락을 하도록 건의하여 프로세스를 변경하였습니다. 기획팀은 귀찮아(???) 할 수도 있는 문제지만 예전에 0건이던 FeedBack이나 일정에 대해 물어보는 횟수가 1-2회씩이라도 늘어나고 서로 이야기 할 시간이 조금씩 이라도 늘어나고 있다는 것은 고무적인 일입니다.

아직은 서로가 부족하지만 시간이 지나면 서로간의 업무에 대한 범위, 장기적으로 프로세스에서 진행 방법등을 더 이야기 해 볼 수 있을 것 같습니다.( 다른 곳에서는 기획팀이나 영업/마케팅 하시는 분이 너무 괴롭혀서 힘들어 하시는 분들이 많으시던데… ^^ ) 서로간의 기본적인 상식선에서 이 문제는 해결을 본 것 같습니다.

2. 개발팀 내부의 의사소통 문제

- 버젼 관리/보안/구조화 같은 것은 찾아 볼 수 없는 JSP+Model1 Code 들로 된 사이트가 있습니다.

- 거기에 JSP 코드를 PHP 수준으로 사용하고 있습니다.(으악!)

사실 위에 나열한 기술적인 문제는 팀 내부의 소통의 문제는 아닙니다. 기존 개발팀들이 서서히 해체되고 현재의 팀이 꾸려지는 기나긴(자세한 내용은 생략해도 누구나 알수 있을 법한?) 과정중에 발생한 기술적인 화두들일 뿐입니다. 하지만 팀원(PM까지 전부 합쳐야 단 둘. ^^) 들이 저런 문제에 대하여 서로 다른 생각을 가지고 있다거나, 한사람만 인지하고 다른 사람이 인지하지 못하고 있다면 함께 일 해내가긴 참 힘들 것 같습니다.

다행히 개발자분은 기술적인 지식은 약간 부족하지만 문제 해결 능력이나 실제 업무 처리에 있어서(시간이 좀 걸리는 점 빼고는) 문제 될 점은 없습니다. 하지만 이 상태(1번에 내용을 포함하여..)로만 계속 간다면 회사 전체적인 관점에서 큰 문제다라는 인식을 서로 공유하게 되었습니다. 하여 어찌할까 고민하다. 입사 초에 개발자분과 이런저런 대화 나누던 중 ‘저는 질질 끄는 회의 말고 짧고 깔끔하게 하는 회의가 너무 좋아요. 뭔가 일하는 것 처럼 보이자나요? 여기선 아무도 그런걸 안하려고 해요.’ 라는 말이 기억이 나서. 그래. 그럼 우리 매일 회의하자!

기술적인 지식도 좀 쌓고, 원활한 의사소통을 위하여 매일 10-30분 정도 회의를 가집니다. 추후 일정, 오늘의 남은 업무,현재 작업의 진행사항이나 문제점, 개발과 관련된 전반적인 지식이나 새로운 기술들에 대한 것들로 회의를 가집니다. 회사 회의실의 화이트보드는 사실상 개발팀이 독점해서 사용할 만큼 빈번히 회의를 합니다. 많게는 6-7번씩 가질 때도 있고 적을 때는 1-2번으로 끝나는 날도 있습니다.

회의에서 주로 거론되는 내용이라고 해봐야 ‘오늘 뭐했나?’, ‘지금 어디까지 진행되었나?’, ‘이제 해야 할 것은 무엇인가?’, ‘이런이런식으로 문제를 해결하려는데 어떠냐?’, ‘이런이런거 있는데 한번 해볼까?’, ‘오늘 야근 할껀가?’, ‘점심(or 저녁)은 뭘 먹을 것인가?’, ‘아 우리회사 누구누구~’, ‘아 어제 어디 갔었는데 정말 좋더라’, ‘다음에 뽑을 개발자는 꼭 여직원으로!!’ 같은 것들뿐이지만 이 회의에는 독서와 경험에서 나온 몇가지 나름의 원칙이 있습니다.

- 형식을 갖춘 브리핑/보고서 같은건 일절 하지 않고 가볍고 편안한 분위기로 칠판에 쓱쓱~ 쉽게 그리고 간단하게만 메모하고 특별한 이슈가 발생하면 그때그때 보고하고 처리합니다.(귀찮으면 핸드폰 카메라로 찍어서 대충 메모 할 때도 있습니다..)

- 아무리 뛰어난 개발자라도 놓치는 부분이 있을 수 있습니다. 한 사람보다는 두 사람의 생각이 (대체로) 더 뛰어나다는 확신을 가져야 합니다.

- 아무리 바보같은 생각이나 이야기라도 서로 이야기 할 수 있어야 합니다. 그렇지 않으면 서로 배워나가기 힘듭니다.

- 회의시간은 절대 30분을 넘지 않아야 합니다.(넘을 것 같으면 잠시 쉬었다가 다른 일을 하다 다시 모입니다.)

사실 위의 몇가지 원칙은 코끼리를 춤추게 하라, 맥킨지는 일하는 방식이 다르다. 등의 책을 참고하여 나름 정한 원칙입니다. 지금까지는 아주 효과적이고 또 효율적으로 진행되고 있습니다.(서로 충분히 만족할 만한 성과를 보이고 있다는 의미입니다.) 일정보고도 꼬박꼬박 메일을 통해 공유되고 일이 터지면 스스로 야근(?)하는 개발팀인지라 타 부서에서의 압박이 거의 없긴 합니다.(사실 아무도 관심이 없는 걸지도 모릅니다.)

이제 회의 하는 문화(?)는 확실히 자리 잡았습니다. 여기에 버젼관리와 Wiki/BBS류의 도구를 도입하여 문서화만 적절하게 하면 개발팀 안에서의 의사소통(+정보 공유)에는 큰 문제가 없을 것 같습니다.(이건 순전히 제 생각일뿐..)

이제  1번의 문제가 점진적으로 해결되면 칼퇴근의 신화도 옛 말이 될 수도 있습니다. 새로운 개발팀원이 합류하면(부디 회사가 커져서 내년에는 여자 개발자분을 당당(?)하게 뽑을 수 있기를!!) 또 다른 방법의 의사소통을 고민해야 될 수도 있습니다. 그러나 입사초기에 급작스럽게 떨어진 사이트 런칭, 사이트 및 업무 파악, 새로운 체계 정립 등 짧은 시간에 많은 일들을 ‘함께’ 처리하고 개발팀이 자리잡는데 있어서 가장 큰 원동력은 개발팀 내부의 원할한 의사소통 이 아니였을까요?

ps. 두서없이 긴 글 읽어주셔서 감사합니다.

ps2. 사실상 의사소통이 없어서 정체되어 있던 곳에 와서 이렇게 우리는 의사소통 하자 라고 정한 것이기 때문에 주제에 맞는지는 모르겠지만 의사소통과 관련된 이야기는 한번 해보고 싶어서 이렇게 트랙백을 남깁니다.