본문 바로가기

소프트웨어이야기

Mensa(멘사)회원들보다 똑똑한 Waitress Mensa Convention 멘사 회의 A few years ago, there was a Mensa convention in San Francisco, and several members lunched at a local cafe. 몇 해 전 샌프란시스코에서 멘사 회의가 열렸을 때 몇 명의 회원들이 동네 카페에서 점심을 했다. While dining, they discovered that their salt shaker contained pepper and their pepper shaker was full of salt. 이들은 식사하다가 소금통에 후추가 들어 있고, 후추통에는 소금이 가득 차 있다는 것을 발견했다. How could they swap the contents of the bottle.. 더보기
CEO 가장 자주 하는 거짓말은 뭘까? CEO 가장 자주 하는 거짓말 '회사 여러분 것' 직장인들이 뽑은 최고경영자(CEO)의 가장 흔한 거짓말은 ‘이 회사는 여러분의 것’이라는 조사결과가 나왔다. 취업포털 스카우트는 최근 직장인 1천26명을 대상으로 설문 조사한 결과 CEO들이 가장 자주 하는 거짓말은 ‘이 회사 다 여러분들 것입니다’가 25.2%(216명)로 가장 많았다고 27일 밝혔다. 이어 ‘내년 한 해만 더 고생하자’(21.1%), ‘연봉 못 올려줘서 늘 미안해’(13.9%), ‘우리 회사는 미래가 있다, 다른 생각하지 말게’(12.3%), ‘사람 하나 더 뽑아줘야 하는데’(8.9%) 등이 있었다. 후략... Copyrights ⓒ 연합뉴스. (출처:조선일보) 흥미 있는 기사가 있어서 소개도 하고 의견을 좀 올려볼려고 합니다. 아직도.. 더보기
변화하지 못하는 회사들의 공통점 회사가 변화하지 못한다는 것은 더 이상 발전이 없고 점점 쇠퇴해 간다는 것을 의미합니다. 변화하지 못하는 회사들은 항상 핑계를 대기 마련입니다. 어떠한 종류의 핑계들을 대며 변화하지 못하고 정체되어 있는 회사들의 공통점을 얘기해보죠. 첫째, 항상 바쁩니다. 주먹구구식으로 일을 하면서 항상 바쁘고, 또 바빠서 변화를 받아들일 수 없다고 합니다. 물론 핑계죠. 지금과 같이 일을 하면 계속 더 바빠지고 뒤죽박죽이 될 것이므로 혁신을 해나가야 하는데, 이를 핑계로 개발자들이 경영자에게 겁을 주면 대부분 잘 넘어갑니다. 둘째, 자기 회사는 매우 독특한 줄로 착각합니다. 1명짜리 소프트웨어 회사나 1,000명짜리 소프트웨어 회사나 소프트웨어를 개발하는 원리는 별반 다르지 않습니다. 그런데, 우리는 금융이라서 안전성.. 더보기
변화하는 회사들의 공통점 여러 소프트웨어 회사들을 컨설팅 하다 보니 빠르게 변화해서 성공적으로 변신하는 회사가 있는가 하면 조그만 변화도 어렵게 어렵게 시도를 하면서 아주 더디게 변화하는 회사들도 있습니다. A회사는 단 2개월 만에 목표한 바를 150% 달성하기도 하고 B회사는 1년 동안 처음에 계획하고 기대한 목표치의 50%밖에 달성하지 못하기도 합니다. 물론 회사에 있어서 변화는 어렵습니다. 기존의 습관을 버리는 것도 어렵고, 기존의 방법이 잘못되었다는 것을 알아차리기도 어렵습니다. 설령 안다고 하더라도 기존의 방법을 구축해 놓은 사람들이 변화를 가로막고 심지어는 기득권을 지키려고 방해를 하기도 합니다. 또 변화 후에 더 좋아진다는 확신을 얻기가 어렵기 때문에 변화 자체는 항상 불안한 것입니다. 하지만 변화하지 않으면 더 이.. 더보기
오늘의 잡담 - 개발자와 영어 이 소프트웨어라는 것이 미국에서 처음 만들어지다 보니 엄청나게 많은 자료들이 영어로 되어 있고, 대부분의 커뮤니케이션의 영어로 진행되고 영어가 마치 소프트웨어 업계에서는 표준어가 된 듯합니다. 나 자신도 영어를 지독히 싫어했고, 최근 2,3년간 영어 공부에 열을 올리고 있지만, 제가 처음 소프트웨어를 시작할 때부터 영어를 잘했다면은 지금 내 모습이 달라졌을 것을 생각합니다. 대부분의 프로그래밍 언어가 영어 기반이고, 메뉴얼 원본은 다 영어인데, 영어로 된 원서를 읽으려면 번역서보다 10배이상 속도도 느리고 이해가 잘 안되니 항상 번역서만 찾아 다녔었던 기억이 납니다. 이제와서 뛰어난 개발자가 되려면 영어도 잘해야 한다고 말하기도 쑥스럽지만, 영어를 유창하게 하지 못하는 개발자는 이미 기회를 반쯤 버리고 .. 더보기
모짜르트와 두 제자 모짜르트가 두 명의 제자에게 피아노 레슨을 한적이 있답니다. 한 명은 이제 막 피아노를 시작한 완전 초자이고 또 한 명은 이미 연주를 능숙하게 할 줄 아는 사람이었다고 합니다. 모짜르트는 누구에게서 더 많은 레슨비를 받았을까요? 바로 두 번째 사람이었습니다. 첫 번째 사람은 완전 초자이므로 모짜르트가 시키는 대로 그대로 따라와줘서 진도도 잘 나가고 강습에 문제가 없는 반면 두 번째 사람은 자기스타일을 고집하기도 하고 오랫동안 몸에 익은 습관을 버리기가 어려워서 먼저 그 습관을 다 없애고 다시 배워야 하기 때문에 배우는 시간도 몇 배 더 오래 걸리고, 가르치기도 더 어려웠다고 합니다. 그래서 레슨비를 더 많이 받아야 했습니다. 소프트웨어 컨설팅을 할 때도 아무것도 없는 회사는 맨땅에게 건물을 짓는 것과 같.. 더보기
레퍼런스 있어요? 컨설팅을 하다보면 종종 듣는 질문이 레퍼런스 있냐는 말입니다. 또 이걸 시행하면 시행전보다 몇%의 생산성의 향상을 가져오는지 수치로 알려달라고 하는 사람들도 있습니다. 히딩크가 한국에서 와서 기초 체력훈련에 집중할 때 반대 했던 많은 사람들처럼 소프트웨어를 개발하기에는 너무나 기초가 취약한 수많은 기업에서 아주 기초적인 것들을 도입할 때도 종종 이런 말을 듣게 됩니다. 레퍼런스는 Global 소프트웨어 회사 전부이고, 생산성 향상을 논할 수 없을 만큼 기초적인 것이다라고 말을 해야 하지만, 그렇게 얘기를 하면 기분이 나쁠 수 있으므로 애둘러서 말해야 합니다. 아직도 국내 소프트웨어 개발 환경 및 역량 수준이 Global 수준과 너무나 큰 차이가 나는 것이 현실입니다. 레퍼런스를 따질 때가 아니고 기초부터.. 더보기
개발자는 코딩만 해야 한다. 제목을 보시고 무슨 말도 안되는 얘기를 하느냐고 생각하시는 분이 대부분일 겁니다. 이러한 생각의 Gap은 소프트웨어를 개발하는데 있어서 개발자의 역할에 대한 인식의 차이에서 비롯합니다. 현실을 보면 개발자라는 이름으로 정의된 소프트웨어 엔지니어들은 대단히 많은 일을 합니다. 요구사항 분석도 하고, 설계도하고, 코딩도 하고, 테스트도 하고, 빌드도 하고, 팩키징도 하고, 고객지원도 하고, 전화도 받고, 영업도 지원하고, 서비스 회사인 경우에는 실제 운영서버 관리도하고, 장애 해결도 하고, 정말 여러가지 일을 합니다. 이것을 역할로 바꿔보면, Software Analyst, Software Architect, Coder, QA Engineer, Build Engineer, Release Engineer, T.. 더보기
살아남은 개발자들 소프트웨어 업계에서 주변을 둘러보면, 실력은 없으면서 탁월한 생존력으로 살아남은 개발자들을 볼 수 있습니다. 소프트웨어 개발 실력은 떨어지지만, 업무지식을 속속들이 알고 있는 개발자 회사의 개발정보를 꼭꼭 숨겨서 자신만 알고 있는 개발자 과거에 개발해 놓은 소스코드의 문서도 만들지 않고 뒤죽박죽으로 섞어놔서 자신이 아니면 유지보수를 못하게 만들어 놓은 개발자 탁월한 인화력으로 후배 개발자들과 똘똘 뭉쳐있는 개발자 미래에 경쟁이 될만한 새싹은 미리 밟아 버리는 개발자(관리자) 화려한 언변으로 경영자들에게 거짓된 신임을 얻고 있는 개발자 위와 같은 방법의 생존이 소프트웨어 업계에서 살아가는 한 방법이기도 하지만, 또 일부 기술은 부러운 기술이기도 하지만, 이는 결국 회사와 개발자 모두의 경쟁력을 갉아 먹고,.. 더보기
도대체 얼마나 자세히 적어 달라고?! 소프트웨어 개발자들에게 문서 작성은 고역이 아닐 수 없습니다. 그래서 문서는 소프트웨어를 개발한 후에 후배들에게 소프트웨어에의 스펙과 구조를 설명하기 위해서 작성하곤 합니다. 이런 경우에는 문서의 효용성도 별로 없을 뿐더러 문서가 제대로 작성되었는지 알기도 어렵습니다. 또 개발자들은 기억을 더듬어서 문서를 작성하기도 어려울 뿐더러 이러한 작업은 하기 싫은 고역이 될 수 밖에 없습니다. 소프트웨어를 개발하는데 있어서 필수적인 문서의 대부분은 개발한 내용을 정리하기 위해서 만드는 것이 아니고, 소프트웨어를 개발하는데 필요한 내용을 앞 단계에서 작성하는 것입니다. 즉, 설계를 하기 전에 스펙을 작성하고 구현을 하기 전에 설계서를 작성하고 테스트를 하기 전에 테스트 계획 및 TCL(Test Case List)를.. 더보기

티스토리툴바