Blog.RedAge.NET

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. 결론적으로…

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

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

당신이 얼마나 소중한 존재인지 아시나요?

아..뭐 또 세상에 하나밖에 없는 Unique Key 어쩌구 저쩌구~ 그러면 뭐해요 나 없으면 그만 인걸…

아니요. 당신은 Unique Key가 아니라 Primary Key입니다. 당신의 존재 여부(Nullable)는 당신을 표현해주는 수 많은 말들 중 하나일 뿐이에요.

—-

언젠가 기억나는 시험문제 답안..

당첨된지도 모르고 있다가 어제 급히 신청했습니다.

잽싸게 신청해서 점심시간에 전 직원이! 정말 자알~ 먹었습니다.

인상적이였던 코멘트

CFO(라 쓰고 경영지원팀장님 이라 읽는다..)님께서 “IT쪽 책 출판사라구요? 그 회사 책 좀 사줘야겠네.”

디자이너분께서 “다음엔 (야식으로)교촌치킨 같은거 어때요?” (이건 저한테..이러셔 봐야..)

개발자 : “아 저는 책이 왔으면 했죠.” (어쩌라고!)

늘 좋은 책 출간해 주셔서(그리고 이벤트도 당첨시켜 주셔서) 감사합니다!

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

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

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