대빵's Blog

예전의 맥킨지 업무방식 이라는 책을 읽은 적이 있다....다른 내용들은 다 가물가물한데 가장 인상 깊었고 지금도 일종의 신조 처럼 여기고 있는 개념은 MECE 라는 개념이다.MECE - Mutually Exclusive Collectively Exhaustive의 약자, 상호배제와 전체포괄 - https://ko.wikipedia.org/wiki/MECEMECE 관련 자세한 내용은 위키를 읽으면 알 수 있을 꺼고 이걸 소프트웨어 설계에 어떻게 활용한다는 건지 예를 들어 보자 당신은 버스표를 티켓팅하는 시스템을 설계하려고 한다. 통상적으로 모든 프로젝트는 업무전문가가 Key User 로 참여하게 되고 이들 Key User 들 중에서 가장 높은 직급 또는 업무권한이 높은 User의 인터뷰로 부터 프로젝트가 ..

프로젝트를 수행하면서 많은 것을 느끼지만 가장 어이없는 것 중에 하나가 프로젝트 팀원들에 대한 신뢰는 없으면서 개발된 결과물의 높은 신뢰성을 요구한다 는 것이다. 난 항상 입버릇처럼 개발은 사람이 하는 것 이라고 말한다.개발자를 신뢰하지 않는데 그 개발자가 개발하는 결과물이 높은 신뢰성을 가지지 않는다.즉, 높은 신뢰성의 소프트웨어를 원한다면 신뢰성 높은 개발자와 신뢰성 높은 업체를 선택해야 한다. 이것이 첫단추이다.

Redis 수정에 관계없이 정해진 시간에 expire 처리하기(cron 처럼)이번에 Redis를 사용하면서 느낀건 참 쉽게 사용가능한데 호불호가 극명하게 나뉘고 목적이 명확하게 사용되어야 한다는 점이다.Redis 는 저장된 데이터에 expired time 을 설정하여 해당 데이터가 일정시간 지나면 없어지게 해준다. 데이터가 생기면 모를까....없어지는데 왜 좋은건지 이해가 되지 않는다면 아직 개발을 좀 더 해봐야 된다. 개발시 가장 까다로운 요구사항 중 하나가 생성된 데이터를 특정시간 지나면 없애고 갱신해 달라는 요구사항이다. 데몬을 띄워서 해당 데이터를 모니터링 하는 경우가 많아서 여러가지로 귀찮아 진다. Redis 를 사용하면 데이터가 생성된 이후 일정시간 지나면 데이터를 없애 버리기 때문에 데이터 ..

거의 대부분의 소프트웨어 관련 의사결정자들이나 관리자들은 개발자들이 소프트웨어를 만들때 컴포넌트화 하여 만들기를 원한다.실제로 개발을 해본적이 거의 없고 컴포넌트화 하면 이곳저곳에 약간만(?) 변경하면 소프트웨어를 재사용할 수 있다는 원론적인 얘기와 컴포넌트 찬양들만 들었기 때문에 가끔 거의 맹신도처럼 컴포넌트를 신봉하는 사람들도 존재한다. 개발자들은 뭔가 이게 현실적으로 어렵다는 것을 몸으로 느끼고 알고 있지만 실제로 이론적인 공부를 하거나 체계적으로 정리한 적인 없으니 정확하게 설명하지 못하고 그냥 끌려다니는 경향이 있다. 소프트웨어 컴포넌트는 정말 좋은 것일까? 단점들과 고려사항들을 알아보자.컴포넌트 소프트웨어의 단점은 사실 단 하나이다. 비용이 많이 들어간다. 하지만 단순히 비용이라고 하면 다들 ..

최근 수행했던 프로젝트에서 있었던 일이다...기획과 디자인은 시도 때도 없이 요구사항과 디자인을 변경했다...그리고 이러한 것을 Agile 문화라고 표현했다.....그 얘기를 들으면서 아직도 소프트웨어 개발에 있어서 Agile은 멀었구나 ... 라는 것을 느꼈다... 그러면 진정한(?) 또는 올바른 Agile 이란 무엇을까? .... 여러가지 정의와 개념들이 난무하지만 단, 한가지 공통적인 내용은 "무조건 자주 변경하는 것이 Agile은 아니다" 라는 내용이다. 즉, 사람들이 Agile 이라는 변명하에서의 무조건적인 변경과 수정을 가장 경계하고 있다는 말이다.그러면 어떻게 해야 할까? 답은 아주 간단하다. 변경과 수정하려면 올바른 방법으로 수행하면 된다. 그러면 올바른 방법은 무엇일까? "분석-설계-구현..

현재 개발하는 Application 은 해외 사업자와 인터페이스 해야 되는 환경이다....데이터가 내부에 없으므로 거의 모든 데이터를 해외 서비스 사업자의 인터넷 회선에 의존해야 한다. 네트워크 지연시간을 최소화 하기 위해서 여러개의 요청을 멀티쓰레드로 동시 호출하여 사용자에게 응답 주기전에 정리/통합하여 보여준다. 사용자에게 응답줄때도 전체 요청에 대한 응답을 기다렸다가 리턴하지 않고 사용자가 지루해 하지 않게(?) 중간중간 응답값을 정리해서 리턴하고 최종적으로 모든 응답값을 정리해서 다시 리턴하는 구조를 가졌다.성능에 대한 이슈가 많이 발생할 수 밖에 없는 구조이기 때문에 부하테스트는 필수적인 요건이다.....하지만 여기서 jMeter를 사용하는데 대한 여러가지 문제가 발생한다. 여기서 가장 큰 문제..

소프트웨어 관련 업종에 종사하다 보면 많은 사람들을 만나게 된다.특히 일반적으로 소프트웨어와 관련 없는 사람들은 SW라고 하면 뭔가 코딩하고 영화에서 보는 검정색 화면에 하얀글자가 쉴새없이 지나가고(매트릭스 처럼) 커다란 전선과 장비 덩어리 기계 앞에서 뭔가 전선 몇개 곂쳐서 연결하면 통화내역이 해킹되는 그런 생각을 하겠지만 실제로 SW업계에는 거의 대부분 컴맹들이다......ㅡㅡ;물론 어디나 넘사벽인 사람들이 존재한다....실제로 영화에서 보는 듯한....가끔 윈도우나 맥북을 마우스 없이 키보드 단축키만으로 사용해서 화면지나가는게 다른사람 눈에 보이지도 않는 사람들도 있다.....헐....여하튼, SW업게 종사하다 어느정도 나이가 들면 30대중후반 부터 많은 사람들이 분석/설계 라는 업무를 하게 된다...

진격의 거인 애니를 보고 느낀건 생각보다 많은 사회분야에 대입해서 시사점이 있는 애니라고 생각했다.IT 개발 17년차로 가끔 신입직원이나 다른 업종 사람들에게 SI와 SM의 차이점을 설명하라고 한다면, 주저없이 진격의 거인 애니를 비유한다. 조사병단 - SI벽밖으로 항상 나간다. - 보통 다른 회사에 나가서 일한다. 나갈때 마다 항상 많이 죽는다. - 프로젝트 끝나면 거의 대부분 지병이 하나씩 생긴다. 죽을때 인류에 도움이 되었는지 물어본다. - 그 고생을 했어도 겉으로 보기에 대단하지는 않다. 넘사벽인 사람들이 가끔 존재한다. - 후덜덜 한 사람들이 가뭄에 콩나듯이 있다. 보통 학교에서 성적 낮은 애들이 간다. - 이건 뭐....새삼스럽게..... 주둔병단 - SM벽안에 있다. - 보통 본사나 해당 유..