본문 바로가기

분류 전체보기

오늘도 밤을 세워야 하는 개발자 (야근 탈출) 옛날부터 내려오는 경영자들이 믿고 있는 미신이 있습니다. "개발자의 Output은 근무시간의 양에 비례한다." 말은 아니라고 하면서도 밤에 사무실이 텅 비어 있으면 개발자들이 군기가 빠졌다고 생각하고 주말에 누가 나와서 일하나 확인하러 가끔 사무실에 들르는 사람들이 경영자입니다. 실제로 근무시간에 성과가 비례하는 개발자들이 있다면 공장에서 벽돌 찍어내는 것과 다를 바가 없겠지요. 이 미신은 믿기 싫지만 자꾸 저절로 손이 가는 새우깡처럼 믿게 되고, 회사 조직에서 위로 올라갈수록 더 맹신하게 되나 봅니다. 이러한 이유로 어쩔 수 없이 또는 습관적으로 야근을 하는 개발자가 있다면 십중팔구 미혼이거나 결혼을 했어도 아이가 없겠죠. 이런 정상적이지 않은 생활을 하며 10, 20, 30년간 소프트웨어 엔지니어 일.. 더보기
우리 개발자는 뭐든 뚝딱 잘 만들어요. 소프트웨어를 개발하기 위해서는 기본적으로 갖춰야 할 인프라스트럭쳐시스템(Infrastructure System, 기반시스템)에 대해서 이미 본 블로그에 글을 올린 적이 있습니다. 그런데 여러 회사를 만나보니 이러한 시스템 중에서 일부를 직접 만들어서 사용하려는 경우를 종종 접하게 됩니다. 이런 회사를 "Tool company"라고 부릅니다. 자신들의 주력 제품이 아니고 개발하기 위해서 필요한 툴들을 만들어서 사용하려는 회사를 말합니다. 물론 워낙 특수한 형태의 툴로서 세상에 존재하지 않거나 구할 수가 없는 예외적인 경우도 있습니다. 하지만 개발 프로세스에 일반적으로 필요한 시스템들은 직접 만들어서 사용한다는 것은 큰 문제입니다. 특히, 버그관리시스템이나 프로젝트관리시스템을 만들어서 사용하거나, 만들려고 .. 더보기
고객중심의 서비스 마인드가 소프트웨어 산업을 망친다. 부제 : Global mind를 가져라. 우리나라의 Customer Service(A/S) 정신은 정말로 환타스틱합니다. TV가 고장나서 전화하면 수리기사가 바로 달려와서 고쳐주고 갑니다. 핸드폰이 고장나서 서비스센터에 가면 바로 고쳐줍니다. 뭐든지 바로바로 해결이 되죠. 하지만 미국에서는 좀 다릅니다. 노트북이 고장나면 바로 해결이 안됩니다. 서비스센터에 맡겨도 서비스센터는 단순히 포장만해서 수리공장으로 보내는 경우가 대부분이고 오래 걸리면 한달이 걸리기도 하고 재수 좋으면 그보다는 빨리 받아 볼 수 있죠. 미국은 땅덩어리가 워낙 커서 가 도시마다 전문서비스기사를 둘 수도 없습니다. 부른다고 쪼르륵 달려갈 수도 없습니다. 비행기타고 몇시간 날아가서 차 랜트해서 또 한참 가야지만 고객을 만날 수 있거든요.. 더보기
우리나라에는 전지전능한 슈퍼 개발자가 있다. 여러 소프트웨어 회사를 컨설팅하다보면 아주 많은 개발자들을 만나게 됩니다. 그 중에는 전지전능한 슈퍼 개발자를 만나게 됩니다. 코딩, 설계, 분석, 테스트, 기획, 고객 전화응대, 고객 지원, 프로젝트 관리, 일반 관리, 아키텍처 등등 엄청나게 많은 일을 하는 개발자들을 보게 됩니다. 이들은 대부분 팀장 쯤 됩니다. 어떻게 생각하시나요? 바람직해 보입니까? "나도 그런 전지전능한 개발자야 돼야지"라는 생각이 드십니까? 혹시 지금 이렇게 모든 분야의 일을 다 하고 계시나요? 이것은 One man company 얘기가 아닙니다. 개발자가 100명이 넘는 회사도 이러한 경우를 여럿 봤습니다. 대부분은 회사가 성장과정에서 적당한 때에 조직을 변화시키지 못하고 그냥 달려온 경우입니다. 이런 경우 전지전능한 개발자.. 더보기
우리나라 소프트웨어 회사에는 Technical career path가 없다. 우리나라에서는 소프트웨어 개발자로 일을 하면서 부딪히는 큰 걸림돌이 있습니다. "Technical career path가 없다"는 겁니다. 이 말에 바로 무슨 뜻인지 팍 와 닺지 않는 사람은 우리나라의 소프트웨어 환경에 이미 익숙해지신 겁니다. 소프트웨어 개발자들은 일을 열심해도 위로 올라갈 데가 없는 경우가 대부분입니다. 그래서 팀장도 되고, 관리자도 되고 다른 직종으로 점점 옮겨가게 됩니다. 그러다 보면 기술과는 점점 멀어지게 됩니다. 뛰어난 기술자들의 보석과 같은 실력을 썩히는 거지요. 대부분의 소프트웨어 회사에서는 Technical Track과 Management Track를 구분해야 한다는 사실을 인식하지 못하고 있습니다. 두 Track은 완전히 다른 것이고 서로 잘 호환 되지도 않습니다. 지금.. 더보기
소프트웨어 아키텍처는 어디에서 오는 것일까? 오늘은 아키텍처와 비즈니스의 관계에 대해서 적어볼까 합니다. 아키텍처… 비즈니스… 둘간의 무슨 관계가 있을까요? 별 관계도 없어 보이고… 혹시 제품의 아키텍처를 구성하고 설계를 하시고 계시나요? 그렇다면 비즈니스에는 얼마나 관심을 가지고 계십니까? 기술은 기술, 비즈니스는 비즈니스, 별 관계없다고 생각하실 수도 있습니다. 결론은 말씀 드리면 "소프트웨어 아키텍처는 비즈니스에서 나온다."입니다. 이 글을 쓰게 된 주된 이유는 많은 선임, 고참 개발자들이 기술에만 관심을 가지고 비즈니스에 별 관심이 없는 경우를 많이 봐왔기 때문입니다. 개발자는 상위 개발자가 될 수록 비즈니스를 알아야 합니다. 아키텍처에 대한 대부분의 결정은 단순히 기술적인 결정이 아닙니다. 비즈니스를 제외하고 기술적인 결정만 있는 경우는 .. 더보기
객체지향... 필요한가? 써니님의 "절차지향도 훌륭한데, 왜 객체지향인가?"라는 글을 읽고 객체지향에 대한 견해를 적어봅니다. 먼저 글을 읽고 계신 분이 C언어로 프로그래밍을 하시나요? 그러면 질문이 있습니다. "static 함수를 사용하시나요? 또 static 함수의 용도를 아시나요?" "static 변수가 아닙니다." 사용하고 계시고 정확한 용도를 알고 계시면 C언어로도 객체지향 프로그래밍을 하고 계시는 것일 겁니다. 이 질문에 갸우뚱하시는 분이 계시나요? 그럼 이야기를 시작해보죠. 여기서 이슈를 다음 두 가지로 나눠야 할 것 같습니다. 객체지향 프로그래밍 객체지향 프로그래밍 언어사용 첫째, 객체지향 프로그래밍은 당연히 필요하다고 생각합니다. 우선 몇 만 라인 이하의 소규모 소프트웨어를 개발할 때와 혼자서 소프트웨어를 개발할.. 더보기
코더(Coder)의 비애 블로그에서 설계에 대한 몇몇 글들을 의견을 적어보려고 합니다. 안녕하세요. Ray입니다. 써니님이 지금 하시는 일을 코딩이라고 만 얘기할 수는 없는것 같습니다. 분석, 설계도 다 하고 계시는데, 문서화가 안되어 있거나 부족할 수는 있어도 분석, 설계는 하고 있는 거죠. 적은 인원이나 소규모 프로젝트에서는 설계가 별로 이슈가 되고 있지 않습니다. 이런 상황에서 인도에 외주를 줄만큼 설계를 하는것도 낭비죠. 하지만, 내가 설계를 해서 다른 사람이 내 설계서를 보고 약간만 물어보면서 구현(코딩)을 할 수 있느냐를 따져보면 설계 이슈는 전면으로 부각됩니다. 실제로 제대로 설계를 해서 산출물을 만들어 외부에 코딩(구현) 외주를 줄 수 있는 사람은 많지 않습니다. 하지만 이런 구현 외주는 미국과 인도에서는 흔한 일.. 더보기
책(소프트웨어개발의 모든것)을 미국에 있는 친구에게 보냈다. 며칠 전에 책(소프트웨어개발의 모든것)을 미국에 있는 친구부부에게 보냈습니다. 오늘 받았다고 연락이 와서 잠시 얘기를 했습니다. 그 친구들은 과거 나와 같이 일을 했었던 친구인데, 버클리(UC Berkeley)에서 Computer Science를 전공을 했고, 십여년간 실리콘 벨리에서 소프트웨어 개발자로 일을 하고 있는 친구입니다. 그 친구가 책을 본 소감은 다음과 같더군요. "책의 내용이 매우 친숙하다. 미국의 개발자들이 당연히 따른 것들이다." 사실 그렇습니다. "소프트웨어개발의 모든것"이라는 책은 소프트웨어 회사라면 당연히 갖춰야할 기초를 다루는 것으로 미국에서는 당연히 되는 것들이 우리나라에서는 너무나도 낯선 것이 많더군요. Peer Review, SCM, BugTrack, Technical Pa.. 더보기
Diff and Merge in SCM(Software Configuration Management) 헝그리맨님의 Subversion(TortoiseSVN)의 Diff에서 한글이 깨지는 문제... 에 관한 포스팅에 대하여 답변 겸 SCM에서의 Diff와 Merge에 대해서 글을 남겨 봅니다. 일단 헝그리맨님의 글에 대한 답변을 먼저 해야 겠군요. 사실 그동안 소스코드를 Diff하고 Merge하는데는 GUI Diff, Merge툴의 한글 깨지는 문제는 크게 신경을 쓰지 않았습니다. 대부분의 소스코드는 거의 영어로 되어 있고, 주석에 일부 한글이 들어 갔어도 이부분이 수정되서 Diff, Merge가 필요한 부분이 거의 없었고, 대부분의 머지는 줄단위로 이루어져서 줄 내에서 한글을 깨지게 표현하는 것은 사실 문제가 안되었습니다. 3-way merge를 할때는 오랫동안 Unified diff를 사용했기 때문에 .. 더보기

티스토리툴바