'Essay/Software'에 해당되는 글 51건

  1. 2017.03.08 SW refactoring시 가장 주의해야 할 점.
  2. 2016.06.03 Builder pattern의 유용한 용법 - Constructor overroding 줄이기.
  3. 2015.06.24 새로운 업무를 할당 받을때 혹은 할당해 줄때 업무 목적/내용 공유/확인 하는 방법.
  4. 2014.12.15 인사평가를 대비한, 인사고과 분배를 위해 필요한 선조치.
  5. 2014.12.11 인사평가의 한계 - 조직 성과의 측정의 한계에 따른, 개인성과 측정의 한계
  6. 2014.08.11 MVC Pattern 시험...
  7. 2014.03.18 [Essay] HDL(High Level Design)의 형식 및 완료 시점?
  8. 2013.10.21 지난 한 주간, 새삼스레... 새롭게 느낀 것들...
  9. 2013.07.19 휴계공간의 접근성과 업무효율의 관계에 대한 단상.
  10. 2013.01.21 "Programming skill"의 정의와 거기에서 파생되는 문제점...

SW refactoring시 가장 주의해야 할 점.

Essay/Software 2017.03.08 21:58

Code refactoring의 어려운 점은 이미 잘 알려진 바와 같다.
하지만, 그 문제의 복잡성 측면에서 보면, 작은 규모의 refactoring - file 혹은 class 단위 변경 - 은, 대규모 - 특히 코드의 구조 혹은 설계를 바꾸는 정도 - refactoring 에 비할 바가 못된다.

legacy 코드의 구조가 한계에 부딫혀, 재설계->재구현 을 고민할 정도의 상황을 가정해 보자.
이때, 가장 많이 고민하는 것은 아마도 "SW 재작성" vs "대규모 refactoring"일 것이다.
그리고, 어떠한 이유에서든, "refactoring"을 하기로 결정한 상황이라면 어떨까?
(실제, SW를 처음부터 새로 작성하는 것에 대한 Risk는 많이 언급되어 지고 있다.)

필자의 경험에 따르면, 이때 가장 중요한 것은
- refactoring의 단위를 적당히 작은 단계(step)로 분류하고,
- 각 step에서는 그 목적에 해당하는 refactoring만 수행
하는 것이다.

정말로 간단하고, 쉬워보이지 않는가?
하지만, 이게 정말 쉽지 않다.

Refactoring을 주제로 하는 많은 이야기들은, '좋은 구조', 'refactoring 시점' 등등 기술적인 측면을 다루고 있다.
그런데, 막상 필자가 실제로 heavy하게 사용되고 있는 SW를 refactoring하는 경험을 해보니, 정작 문제는 앞서 언급했던 두 가지에 있었다.

보통, 대규모 refactoring은 아래의 단계를 거쳐서 진행될 것이다.
- 현재 SW의 문제점 논의
- Refactoring의 범위 결정
- 새로운 SW구조에 대한 설계 철학 공유
- SW의 최종 형태 공유.
- 각 주제별로 refactring 시작.

하지만, 이런식의 진행은 'legacy SW의 상태'와 '최종 SW의 상태' 사이에 큰 차이가 있기 때문에, 그 끝이 좋지 못한 경우가 많다.
많은 양의 변화를 한꺼번에 진행하면, refactoring과정에서 발생한 오류를 찾아내기 너무 힘들어서, 결국 refactoring 코드를 버리거나, 아니면 SW 재작성에 버금가는(혹은 그 이상의) 노력이 들어가게 된다.
이론적으로는 이런 내용들을 대부분의 개발자들이 잘 알고 있지만, 실제로는 어떨까?

예를 들어, class간의 관계를 재 설정하는 refactoring진행 중, code의 context와 맞지 않는 변수 이름을 발견했다면? 혹은 code style이 잘못된 곳을 발견했다면?
대부분의 경우, 아주 작은 수정이므로, 겸사겸사 같이 수정하면서 진행할 것이다.
이것은, 마치 "거실 바닥 정리"라는 과정 중 "벽에 작은 얼룩을 발견"한 경우, 그냥 지나치지 못하고, 잠깐 시간내어서 얼룩을 지우는 것과 같다.
혹은, SW의 "Feature creep"과도 일맥상통해 보인다.
이런 식의 작은 side-refactoring들이 모여서, 한 step의 복잡성을 증가시키고, 결국 해당 step을 포기하고 처음부터 다시 진행하도록 만든다.

따라서, refactroing을 계획할 때는 앞서 언급한 것처럼, 그 단계를 잘게 나누어야 한다.
물론, 각 단계별로, "새로운 구조" + "legacy 구조" 의 형태를 지켜 내기 위한 overhead가 필요하므로, 너무 잘게 분리할 경우, 이 overhead 비용이 너무 커질 수 있으므로 주의해야 한다.


신고
Trackback 0 : Comment 0

Builder pattern의 유용한 용법 - Constructor overroding 줄이기.

Essay/Software 2016.06.03 21:48

외부에 service를 제공하는 모듈 (예를 들면, library)일 경우, 잘못된 사용을 원천적으로 막는 것은 상당히 어려우면서도 중요하다.(모듈의 사용성과도 밀접한 관계가 있다.)

그런데, module의 instance가 생성되고 나서, 초기화 작업 이후에는 다시 setting될 필요가 없는 값들의 경우, 되도록이면, final (혹은 const)로 선언하는 것이, 코드의 이해도를 높이기도 좋고, 잘못된 사용을 막기도 좋다.


이때, default argument 값을 사용할 수 있는 언어의 경우(C++, Python 등)는 별 문제 없는데, 그렇지 않는 경우(ex, Java)는 사용성을 위해서 module constructor를 overloading해야 한다.(대부분의 경우, default 변수가 사용될 경우, 굳이 매번 이 값들을 argument로 전달해야 하는 것은 상당히 번거롭다.)


예를 들면,  'name', 'numArms'와 'numLegs' 세개의 final 변수를 가지는 'Person' module의 경우


class Person {
    private final String mName;
    private final int mNumArms;
    private final int mNumLegs;

    public Person(String name, int numArms, int numLegs) {
        mName = name;
        mNumArms = numArms;
        mNumLegs = numLegs;
    }
    public Person(String name, int numArms) {
        this(name, numArms, 2);
    }
    public Person(String name) {
        this(name, 2, 2); // 2를 default value로 사용. 대부분의 사람은 팔 다리가 2개... 
    }
}

와 같이 작성된다.

그나마 argument가 3개인 경우가 저정도고, argument가 많아지면, 사용성을 높이기 위해서 overloading되는 생성자도 많아진다.

이 문제를 builder pattern으로 해결할 수 있다.

예를 들면.

class PersonBuilder <T extends PersonBuilder > { // Generic type T 를 사용하는 이유는, 이 Builder를 상속받는 builder를 위함이다.
    private final String mName;  // name은 default가 없으므로 생성시 외부에서 반드시 argument로 받아야 한다.
    private int mNumArms = 2;  // 대부분의 사람은 팔, 다리가 2개...
    private int mNumLegs = 2;

    public PersonBuilder(String name) {
        mName = name;
    }
    public T
    setNumArms(int numArms) {
        mNumArms = numArms;
        return (T)this;
    }
    public T
    setNumLegs(int numLegs) {
        mNumLegs = numLegs;
        return (T)this;
    }

    public Person
    create() {
        return new Person(mName, mNumArms, mNumLegs);
    }
}


그렇지만, 역시 해당 class를 상속받는 경우, 긴 argument를 가진 생성자를 상속해야 하는 불편함은 여전하지만, 이 문제 역시, builder를 상속받는 방법으로 해결할 수 있다.


class OldPerson extends Person { ...}

class OldPersonBuilder<T extends OldPersonBuilder> extends PersonBuilder<T> {
    public OldPersonBuilder
    create() { ...}
}


Generic을 사용했기 때문에, 아래와 같은 용법이 가능하다.

OldPersonBuilder<OldPersonBuilder> bldr = new OldPersonBuilder<OldPersonBuilder>("MyName");
bldr.setNumArms(2).setNumLegs(2);

대략 정리해 보면, 이와 같은 pattern을 사용할때는


Module에서 final. Default값 존재 X => Builder에서도 final

Module에서 final. Default값 존재 O => Builder에서 NOT final.


이정도일려나?


신고
Trackback 0 : Comment 0

새로운 업무를 할당 받을때 혹은 할당해 줄때 업무 목적/내용 공유/확인 하는 방법.

Essay/Software 2015.06.24 21:31

* 가장 중요한 것은, 내가 맡은 업무가 무슨 업무인지 이해하는 것이다. 따라서 업무를 할당할때, 그리고 할당해 줄때 모두 내가/타인이 주어진 Project와 그에 따른 할일을 제대로 이해하고 있는지 확인하는게 중요하다.


* 그렇다면 위의 내용을 확인하는 가장 좋은 방법은 무엇인가?

Project에 대한 내용을 말로 설명하고 말로 확인하는거? 당연히 그렇게 해야 한다. 그렇지만 단순히 여기에 그칠 경우 한계가 명확하고, mis-communication도 종종 생긴다.

따라서 좀더 확실한 방법은, "난/넌 어떻게 내/니 일이 완료되었다는 것을 확인할래?"라는 질문을 던지는 것이다.

여기서 '어떻게'를 좀더 기술적인 용어로 변환해 보면, 'Test/Verification'이 될 수 있다.

즉, '어떤 Test/Verification을 통과하면, 이 일을 완료되었다고 확신할 수 있나?'가 된다.
(Project Management 쪽에서는 이것을 'Definition of done' 이라고 표현하고 있다.)


* 위의 과정의 핵심은 '어떤 Test/Verification'이다. 즉 Test design이다.


정리하면, 해당 업무를 '완료'했다고 말할 수 있는 'Test'를 design할 수 있다면, 그 업무를 완전히 이해했다고 볼 수 있다.


따라서, 업무를 받을때/할때 모두, 다음과 같은 질문/확인 을 통해서 업무에 대한 이해도를 확인할 필요가 있다.

업무를 할당 받았을때: "제가 <이런이런>시험을 했을때 문제가 없으면 되는거죠?"

업무를 할당할때:

(저급)1. <이런이런>시험을 했을때 문제가 없으면 됩니다.

- 문제의 본질을 이해하지 못하고, 단순히 시험에 통과하기위한 업무만을 진행할 가능성이 있음.

(고급)2. 업무는 <이러이러>합니다. 자, 당신은 어떻게 이 업무가 완료되었다는 것을 확인할 예정입니까?

- 제대로 된 답을 한다면, 이 사람은 업무를 완전히 이해하고 있다고 볼 수 있다.


신고
Trackback 0 : Comment 0

인사평가를 대비한, 인사고과 분배를 위해 필요한 선조치.

Essay/Software 2014.12.15 14:27

익히 알려진 바와 같이, 인사평가가 100% 공정 - 공정이라는 단어의 정의를 어떻게 하느냐에 따라 달라질 수도 있겠지만 - 할 수는 없다.

일례로, 기왕이면 진급 대상자에게 상위고과를 주는 것이 어찌보면 '인지상정'이라고 할 수도 있을 것이다.

이런 것이 '좋다' 혹은 '바르다'라고 이야기 하는 것이 아니다. 평가는 100% 공정한 것이 좋다. 그렇지만, '공정'이라는 것이 그 속성상 100% 객과적일 수가 없기 때문에, 주관적인 판단이 반드시 개입된다는 것을 인정해야 한다.

그리고, 이런 '주관적인 판단'에는 주변의 환경적인 요소가 포함되기 마련이다.

예를 들면, "같은 성과라면, 기왕이면 진급이 절실한 사람에게 손을 들어 준다던가."라는 것들 말이다.

비슷한 이유로, 상위고과가 다른 이들보다 절실한 사람이 있기 마련이다.

그렇다고 해서, 인사평가 시즌에 무턱대로, 이런 사람에게 아무런 이유없이 상위고과를 줄 수는 없는 일이다.

이런 경우, 어떻게 해야 합리적인 방법으로 무리없이 이런 문제를 처리할 수 있을까?


내가 보기에, 인사평가는 "일을 얼마나 잘 하였느냐?"보다는, "어떤 일을 하였느냐?"가 더 많은 부분을 차지하는것 같다.

SW의 분야의 경우 예를 들어보면, 기존일을 '유지/보수'하는 일은 정말 압도적인 '실력/성과'를 보이지 않고서는 최상위 평가를 받기는 거의 볼가능하다.

그렇지만, 회사가 주요하게 추진하는 새로운 제품을 개발한다던가, 새로운 기능을 추가 구현하는 일은 일단 무사히 업무를 마치기만 해도 상위 평가를 받을 가능성이 높다.

이 두가지 업무 중 어느 쪽이 더 힘들고, 덜 힘든지는 경우에 따라 다를 것이지만, 일을 마쳤을 때 받을 수 있는 평가의 차이는 상당하다.


다시, 앞의 이야기로 돌아가 보자.

어떤 사람에게 '기왕이면' 상위고과를 주고 싶은 경우는 위에서 언급한 내용을 응용하는 것이 좋다.

그 사람에게, '상위고과를 받을 수 있는 일'을 할 수 있는 기회를 주는 것이다.

'좋은'일이 생겼을 때, 소위 '챙겨줘야'할 사람에게, 먼저 "이 일을 할 것인지?"에 대한 의사를 물어보는 것이다. 그리고, 이 일을 잘 해내었을때 좋은 평가를 받을 수 있다는 것도 같이 언급하는 것이 좋다.

이렇게 먼저 기회를 주고, 무사히 일을 잘 해내었을 경우 큰 물의를 일으키지 않고 필요한 사람에게 '상위고과'를 줄 수 있게 된다.

한편, 이런 기회에도 불구하고, 일처리가 미숙했다면, 그 사람은 거기까지가 한계인 것으로 볼 수 있다.


지금까지 어찌보면 굉장히 '부당'하다고 생각할 수도 있는 이야기를 했다.

읽는 사람에 따라서 상당히 불편하게 받아들일 수도 있을 것이다.

그렇지만, 사람이 사는 곳이라면 이런 문제가 반드시 발생하고, 실제 많은 조직에서 이런 문제가 심심치 않게 보인다는 것에 이견을 가진 사람은 없으리라 생각한다.

따라서, 이런 일을 피할 수 없다면, 최대한 합리적인 방법으로 처리할 필요가 있고, 내 개인적인 생각으로는 위과 같은 방법이 무난하다고 여겨진다.


여기서 다시 한번 강조하고 싶은 내용은, 상당히 많은 경우 "그 사람이 얼마나 일을 잘 했느냐?"가 아니라, "그 사람이 어떤 일을 했느냐?"가 평가에 더 많은 비중을 차지한다는 것이다.


신고
Trackback 0 : Comment 0

인사평가의 한계 - 조직 성과의 측정의 한계에 따른, 개인성과 측정의 한계

Essay/Software 2014.12.11 10:29

Software분야에서 소위 '성과 평가'에 대한 문제는 아주 오래되고, 또 진부한 문제다.

여러가지 한계를 이야기 하고 있고, 그럼에도 불구하고, "평가를 하지 않는 것 보다는 하는게 낫다."라는 이론(?)을 근거로, 여전히 다양한 형태의 '평가'가 행하여 진다.

이 글은 '대안'을 제시 - 가장 어려운 부분 - 하는 것이 아니고, 기존 '평가' 방식이 가지는 여러가지 문제 중 하나를 언급하기 위해 작성된 것이다.


Software분야의 여러가지 연구 중 아래와 같은 것이 있었던 것으로 기억한다. (출처는 기억이 잘...)

"Software engineer에 개인의 기술적인 역량은, '어떤 group에 속해 있느냐'에 따라 상당히 많이 좌우된다."

즉, 좋은 group에서 좋은 경험을 쌓은 engineer가 기술적으로 뛰어난 engineer가 될 확률이 높다는 뜻이다.

그리고 또 재미있는 연구 중 하나는 (이것도 출처가 잘...)

"Software engineer 개인의 성과 차이는 100배까지도 발생하지만, 조직의 성과 차이는 10배 정도까지 밖에 차이가 나지 않는다."

관점에 따라서, 80:20 법칙을 생각나게 하기도 한다.

개인의 역량차는 심하게 나지만, 조직의 역량차는 그렇게까지 크지 않다는 뜻이다.

아마, [역량이 '1'인 엔지니어들의 group] vs. [역량이 '100'인 엔지니어들의 group] 과 같은 극단적인 조건에서가 아니라, 현실세계에 존재하는 일반적인 group을 대상으로 한 조사였을 것이라 생각된다. 

그리고 또, 일반적인 '회사'에서 똑같은 일을 두 곳 이상에서 하는 경우는 거의 없다.


내가 하고 싶은 말은, 

"조직의 역량 차는 각 개인의 역량차에 비해 크지도 않고, 또 같은 일을 하는 조직이 없기 때문에 SW조직의 역량을 비교 평가하는 것은 상당히 어려운 일이다."

라는 것이다.

특히, 같은 일을 하는 조직이 없다는 뜻은, 그 조직의 역량과 무관하게, 해당 분야의 history / 경험/ domain knowledge 등에 따라 진입장벽이 만들어 진다는 말이다. 그리고, 이 진입장벽으로 인해, 조직간 역량 평가는 결국 무의미해 진다."

즉, 개인의 성과 평가보다도 SW 조직(개발 조직)의 평가가 더 어렵다.


SW조직의 평가가 어렵다는 것을 받아 들인다면, 독립된 두 조직이 있을때 어느 조직이 더 나은 조직인지 알지 못한다는 뜻이다.

A, B 두 조직 중 실제 A 조직이 더 우수하지만, 조직 평가의 어려움 때문에 A, B 조직의 평가가 같게 나온 상황을 가정하자.

이 상황에서, 우수한 조직에서는 우수한 engineer가 배출될 확률이 높고(앞서 언급했다.) A 조직과 B조직의 역량차는 계속해서 커진다.

그렇지만, 여전히 조직간 평가의 문제점/어려움 때문에 이 부분이 보여질 가능성은 극히 낮다.


이런 상황에서, 일반적인 '회사'에서는 '상대평가'를 수행한다.

각 조직에서 상위 성과자와 하위 성과자를 구분하는 것이다.

개인의 역량평가를 정확히 실시하는 것도 사실 거의 불가능 하지만, 개인간 정확한 성과 평가가 가능하다는 것을 가정하더라도, 이미 조직의 평가에서 정확성을 잃어 버렸으므로, 개인간 평가의 정확성은 상당부분 희석될 수 밖에 없다.

뛰어난 조직의 하위 성과자가, 다른 조직의 상위 성과자 보다 더 나은 성과를 보였을 가능성도 무시하기 힘들다.


별다른 통일성이 없는 글이였는데... 정리하면...

SW분야에서 개인의 역량 평가에 대한 연구도 중요하지만, 조직의 역량 평가에 대한 연구도 동등 혹은 그 이상으로 중요하다.




신고
Trackback 0 : Comment 0

MVC Pattern 시험...

Essay/Software 2014.08.11 14:54

MVC Pattern에 대한 다양한 종류의 해석/적용이 있긴 한데... 일단, 내가 생각하기에, 일반적인 SW에서 좋다고 생각하는 구조는 아래와 같다 (Web SW나 기타 여러 case가 존재하고, 각각에 맞는 다양한 해석이 존재할 수 있으니, 정답은 없다.) 물론, 아직 나 자신이 MVC Pattern에 대해 미숙하기 때문에 확신할 수는 없으나...


+-----------+ Query(write/read) +------------+

| | <-------------------------- | |

| Model | | Control |

| | ---------------------------> | |

+-----------+ Response/Data for query +------------+

| | ^

| | |

| Feedback to user(ex. select view) | | User interaction event

| v |

| +------------+

| | |

+--------------------------------------> | View |

Read data / (Observe changes - optional) | |

+------------+


Pros : MVC간 연결이 최소화 되어 있어 각각에 대한 독립성이 잘 보장되어 있다.

Model부분이 최소화 되므로, Data 부분에 대한 안정성을 높이기 유리하다.

Cons : Control부분의 역할이 Model, View에 비해 압도적으로 복잡할 가능성이 높다.

따라서, 복잡한 UX를 가질 경우, Control 부분의 통제가 상당히 어려워질 수 있다.

일단 가장 좋은 점은, Model에 대한 update가 Control로 제한되어 있기 때문에

(View -> Model로 write path가 없다.), Data에 대한 관리가 일원화 되어 있다.

또한, Control이 Model의 data를 update하므로, View는 Model의 Data가 바뀌는지 아닌지 굳이 Observing할 필요가 없다.

(필요에 따라 Observing하는 것도 괜찮다.)



. .


신고
Trackback 0 : Comment 0

[Essay] HDL(High Level Design)의 형식 및 완료 시점?

Essay/Software 2014.03.18 15:49

[ 내 개인적인 생각임을 미리 밝힌다. ]


HLD이든 LLD(Low Level Design)이든 결국 block diagram의 형태 (Component 단위든, Class단위의 UML이든...)일 수 밖에 없고, 얼마나 작은 단위의 block까지 명세하느냐에 따라 구분되어 질 것이다.

그럼 이런 block diagram에서 가장 중요한 요소는 무엇인가?

결국 'Design'이라는 측면에서 본다면, 각 block의 input과 ouput을 정의하는 것이다.

그리고, input/output(IO)를 정의한다는 것은, "이 모듈의 역할을 명확히 정의"하는 것과 같다.

더 나아가, block diagram이라는 것 역시 결국,이런 block간 IO의 연결일 뿐이다.


IO를 명확히 하는 것이 왜 SW design에 중요한가?

SW design은 결국 block 간 IO 연결의 형태로 표현되게 된다. 예를 들면,

"A block은 B block의 output을 input으로 받아서 C block과 D block에서 사용할 값들을 만들어 낸다"

같은 형태가 될 것이다.

이때, 내부 구현의 문제는 해당 block하나에만 영향을 끼친다. 즉 A block의 내부 구현이 문제라고 한다면, A block 만 열심히 다시 구현/설계하면 되는 것이다.

그런데, A block의 IO로 정의된 내용이 틀리다면, 예를 들면, "이 input으로는 기대하는 output을 만드는 것이 불가능 혹은 현실적이지 않다."하다면?

그렇다면, A와 연결된 이후 모든 block의 설계다 전부 연쇄적으로 변경되어야 한다.

즉, 소위 "설계 변경"이 일어날 수 밖에 없게 된다.


일반적으로, 내부 구현 문제는 논란의 여지도 많고, 개선의 여지도 많지만, "A라는 input으로, B라는 output을 만들어 낼 수 있느냐?"의 문제는 내부 구현에 대한 고민과 관계없이 판단 가능한 경우가 많다. 혹은 '불가능'하다는 판단은 못하더라도, '가능하다'라는 판단은 명확히 할 수 있다.

따라서, HLD는 이런 block의 IO정의에 대한 잘못된 판단 요소를 조기에 찾아서, 나중에 설계전체에 영향을 주게되는 일을 미리 방지하는게 목적이 된다.


비단 HLD뿐만 아니라, LLD 및 기타 모든 SW 설계역시 마찬가지일 것이다.

얼마나 큰 단위의 block으로 IO를 설계하느냐의 문제이지 block의 IO를 명확히 하는 것이 무엇보다 중요하다.


그럼, 여기서 좋은 설계자는 어떤 차이를 만들어 내는가?

좋은 설계자는, block간 R&R을 명확히 하고, block의 내부 구현에 대한 어느 정도 '감' 을 가지고 있어서, performance및 resource 사용을 최소화 할 수 있는 형태로 block을 나눌 수 있다.

특히, 여기서, '내부 구현에 대한 감'역시 상당히 중요한데, 때로는 이론적으로 상당히 뛰어난 설계를 했음에도 불구하도, 특정 block이 설계에 정의된 IO를 만족하기 위해 너무 많은 비용 - performance, memory 등 - 이 들어가는 경우가 발생할 수도 있다. 불가능 하다는 말이 아니다, 단지 현실적이지 않다는 뜻이다.

이럴 경우, HLD에서는 IO가 타당하다고 Review되었겠지만, 실제 구현단계에서 설계변경이 필요해지는 경우가 발생하게 되는 경우이다.

이때, 경험이 많은 설계자라면, HLD시점에서, 이런 구현단계의 구체적인 문제를 알지는 못하겠지만, "이런 식의 IO로 module을 설계하면, 뭔가 문제가 발생할 여지가 많아 보이는데... 찝찝하다..."라는 소위 '감'을 가질 수도 있고, 이 '감'에 따라서, 이런 '문제 발생 가능성이 높은 설계'를 피할 수 있을 것이다.



project전체에 대한 개괄적인 schedule이 "주 단위 (혹은 2 주 단위), 아주 큰 project라면 한달 단위"로 나올 수 있다면 HLD가 끝났다고 볼 수 있을 것이다. "schedule이 나왔다."는 말은, "어떤 식으로 개발 할 것이다." 라는 것이 정했졌다는 말이고, 그 말은, "전체적인 Design(큰 그림)이 그려졌다."라는 뜻이기 때문이다.

뭐, 이런 식의 기준이 틀렸을 수도 있지만... 일단 난 이 기준으로 판단하고자 한다.




LLDR은 아마도, 2~3일 단위 정도로 schedule이 나왔을 때 끝났다고 이야기 할 수 있지 않을까?


물론, 이 모든 것은 project 의 규모에 따라, flexible할 것이다....

신고
Trackback 0 : Comment 0

지난 한 주간, 새삼스레... 새롭게 느낀 것들...

Essay/Software 2013.10.21 14:41

* 서로 잘 모르는 관계에서 어떤 토의를 하거나, 요구사항 등을 받아들일 때, - 예를 들면, 해외 지사에서, 업무에 불편한 점이 없는지, 도와줄 일은 없는 지 등을 조사할 경우 - 는 반드시 아래의 사항들을 먼저 언급하고 시작해야, 서로간 잘못된 의사소통에 따른 비용을 최소화 할 수 있다.

- 이번 토의/회의 의 명확한 목적

ex: 제안을 받아 들여 달라, xxx를 해 달라 등등

- (제안/요구 를 듣는 입장의 경우) 나의 R&R, 할 수 있는 일과 한계 등.


* Software 업계에서 자주 나오는 이야기 중 "Software중에 '보안'을 이야기할 정도로 정말 가치있는 부분은 얼마 되지 않는다"라는 말이 있다. 수많은 좋은 Opensource software가 넘쳐나는데, 회사의 software중 보안이라는 이름으로 권한을 정밀하게 할 가치가 있는 부분은 얼마나 있을까? 너무 넓은 범위, 정밀한 permission체계는 실무자들에게 쓸데없는 Overhead 및 불편함을 만들 가능성이 굉장히 높다.


* 내가 그 사람의 일(작업)을 control할 수 있는 위치가 아니라면, 가능하면, feedback은 긍정적으로 하자.

ex)

Proposal : '이런 이런' 아이디어가 있고, 이렇게 하면 '이런 이런'게 좋아집니다. 어떤가요?

+ 내가 그 사람의 상관(관리자)라면 : 좋으면 -> OK, 나쁘면 -> NO. 만약 idea가 받아 들이기 힘들다면 NO.. etc.

왜냐하면, 그 사람이 하는 일 및 시간을 관리해야 하는 위치이기 때문에, 필요없는 일을 하는 것들 두고 보는 것은 업무에 도움이 되지 않는다.

+ 만약 내가 3자의 입장이라면 : '이런 이런' 점들이 걱정되지만(뭔가 feedback을 원하는 경우이므로, 내가 관심이 있다는 것을 알려 주기위해 feedback은 해 주어야 한다.), 그렇게만 되면 정말 좋겠군요. 꼭 성공하세요.(마지막 feedback은 항상 긍정적이여야 한다. 나는 불가능하다고 생각하지만, 그 사람은 그것을 정말로 해 낼 수 있을지도 모르기 때문이다.)

나랑 관계없는 사람/일 에 굳이 부정적인 feedback을 주어서, 미움을 살 필요는 없다.


* Project에 대한 발표(Presentation)시, Risk에 대한 언급을 포함하고 있지 않다면 그 발표는 문제가 있는 것이다!

무엇이 문제인지도 모르는(고려해 보지 않은) Project description이 제대로 된 것일리 만무하다.


* Project Schedule이 "꼭 해야만 하는 일"로 꽉 차 있다면, Risk에 대해 전혀 고려되어 있지 않다는 것이다!

Project Schedule에 "꼭 해야하지는 않으나, Risk 완화를 위해 필요한 일"을 위한 시간이 포함되어 있어야 한다.


* Project 완료 시간이 너무 촉박하다면, 그 Project는 너무 늦게 시작된 것이다.(해당 사업계획을 잘못 세웠다는 말이다.)

기획/계획 쪽에서도 책임을 져야한다.







신고
Trackback 0 : Comment 0

휴계공간의 접근성과 업무효율의 관계에 대한 단상.

Essay/Software 2013.07.19 12:33

많은 기업들이, 직원들이 업무시간 중에 소위 '잡담'하는 것을 굉장히 싫어 - 일을 안하고 '논다'고 생각하는 듯 하다. - 하는 것 같다.

그래서, 직원들이 휴식할 수 있는 공간을 별로 만들지 않거나, 눈치를 보며 만들더라도 접근성이 어려운 곳에 위치한 경우가 많다.

비록 그것이 '고의적'인 조치는 아니라 할지라도, 직원들의 휴식공간이 회사의 업무공간 배치에 우선순위를 가지가 어렵기 때문에, 결국 접근성이 좋지 않은 곳으로 결정나는 경향도 있을 것이다.


그 원인이 어찌되었던 간에, 휴식공간에 대한 직원들의 접근성에 문제가 있는 경우 어떠한 문제가 발생할까?

직원들의 복지, 만족도 같은 당연하고 일차원적인 영향은, 너무나 당연한 것이므로 따로 이야기 하지 않겠다.

문제는, 직원들이 소위 '잡담'을 하고자 할때, 혹은 짧고, 간단한 업무회의를 하고자 할때 발생한다.

간단한 업무회의라, '회의실'을 따로 잡기에는 좀 무리가  - 회의실은 대부분 항상 부족하기 때문에 막상 예약하려고 해도 사용할 수 있는 곳이 없는 경우가 다반사다. -  - 있으므로, 그냥 업무하는 공간 - 큐비클 - 안에서 이야기 하는 경우가 종종 발생하게 된다.

'잡담'역시, 휴게공간에 가는 것이 귀찮으므로 - 접근성이 떨어진다 - 그냥 큐비클 안에서 이루어지는 경우가 많게 된다.

문제는, '회의'나 '잡담'을 하는 당사자가 아니라, 그 주변 사람들이다.


소프트웨어 회사의 경우를 생각해 보자.

소프트웨어는 엄청난 집중력을 요구하는 업무가 많다. 그런데, 이때 주변에서 '회의'를 하거나, '잡담'을 하는 소리때문에 집중하기 어려운 환경이 조성되게 되면, 업무에 차질을 빚게 된다.

100여명이 일하는 공간을 가정해 보면, 그 중 한 곳의 2~3명이라도  이러한 '큐비클 안 회의/잡담'을 하게 되면, 다른 97~98 명은 집중을 요구하는 일을 하기에 대단히 어려운 환경에 처하게 되는 것이다.

그렇다고 해서, '업무 큐비클에서 회의하거나 잡담하지 말라'라는 공문/지시를 하는 방법으로 해결하려고 한다면, 이 또한 흐지부지 될 가능성이 높다.

처음 며칠은 지켜질 수도 있겠지만, 약간만 시간이 지나게 되면, 또 다시 이러한 문제들이 발생하게 된다. 왜냐하면, 근본적으로 이 문제를 '처벌의 대상'으로 보기에 상당한 무리가 따르고, 객관적인 '측정기준' - 처벌을 위한 - 을 만들 수가 없으므로, 지켜지지 않을 것이다.

결국, 직원들의 휴게 공간이 부족 + 접근성의 문제는 전체적으로 보면, 직원들의 업무 효율성과도 직접적인 연관성이 있다.


소위 '직원들이 노는 꼴을 못 본다.'는 회사가, 직원들의 휴게 공간에 대한 접근성을 심하게 떨어뜨리게 되면, 역설적으로 '직원들이 일을 제대로 할 수 없는' 환경을 만들게 되는 것임을 깨달을 필요가 있다.


신고
Trackback 0 : Comment 0

"Programming skill"의 정의와 거기에서 파생되는 문제점...

Essay/Software 2013.01.21 18:10

Software업계에서 Programming skill 이라는 단어가 많이 사용되고 있는데 비해, 그 정의가 명확하지 않은 것 같다.

아니, 정의가 명확하지 않은게 아니라, 정의를 실체화 하는 방법이 명확치 않다고 해야 하나?


일단 "좋은 코드/소프트웨어"라는 말에 대한 정의는 어느 정도 합의된 실체가 있는 것 같다.

그럼에도 불구하고, 정량적인 측정 기준이 없기 때문에 여전히 관념적인 형태에 머물러 있긴 하지만...

그런데, "좋은 소프트웨어"를 만드는 것 => Programming skill 이 뛰어난 것"이 되지 못하는 이유는 현실적으로, 보통 '시간'으로 대표되는 '비용'이라는 요소가 들어가기 때문이다.

그래서 결국, Programming skill은 "적은 비용으로 좋은 소프트웨어를 만드는 기술"이라고 정의되어 질 수 밖에 없다.


문제는 앞서 이야기한 것처럼, "좋은 소프트웨어"라는 요소는 정량적인 기준이 없고, 측정방법 또한 모호하다. 그렇지만, '비용'은 객관적이고 명확한 측정 방법을 가진다. 그러다보니, 두 요소 중 '비용'이라는 요소에 더 집중하게 되고, 그것을 기준으로 Programming skill 을 말하는 경우가 많다.

그러다 보니, 극단적으로, "적인 비용으로 소프트웨어를 만드는 기술"이 Programming skill 로 왜곡되어 정의되어 버리게 된다.

(이 경우, 소프트웨어의 품질은 전혀 고려 대상이 아니다.)


실제, 계약에서도, 측정할 수 없는 "좋은 소프트웨어"라는 항목을 계약서에 기술할 수 없으므로, "비용"에 초점이 맞추어 질 수 밖에 없게되고, "적은 비용"이라는 기준을 만족시키는 쪽이 "기술력이 있는 곳"이라는 평가를 받게 되는 기이한 현상이 벌어지게 된다.

이는 계약에서 뿐만아니라, 국내 기업의 업무 형태에서도 쉽게 찾아볼 수 있다 - 물론 모든 기업이 그렇다는 이야기는 아니지만, 대부분(특히 소프트웨어가 주 제품이 아닌 곳들)의 경우 해당될 것이다.

소프트웨어를 만드는데, 연봉이 높은 우수 인력을 사용하는 것은 '과다 비용'으로 받아들이고, 경력이 짧은 미숙한 엔지니어에게 일을 맞겨 소위 "돌아가는 소프트웨어"를 만들어 내는 것을 "잘 했다"고 평가한다. 즉, 소프트웨어의 "품질"은 무시되고, "비용"부분만 고려된 "평가"인 것이다.


이와 같은 현상은 계속 반복된다.

위와 같은 방식으로 만든 소프트웨어는 필연적으로 수많은 문제점(버그)를 내포하게 된다. 이제 이 문제점들을 수정해야 하는데, 이 역시 '비용'만을 고려해서, 미숙한 엔지니어가 처리하게 되고, 수많은 fix-on-fix를 양산하는 악순환을 반복한다.

그러면서, "소프트웨어는 당연히 많은 버그를 내포할 수 밖에 없고, 약간의 수정도 많은 문제점을 동반할 수 밖에 없다."라는 이상한 결론을 내려 버린다.


위의 이야기는 좀 극단적인 측면이 있지만, 국내 현실을 상당히 잘 반영한다고 생각한다.

"소프트웨어의 비용 감소"라는 측면에서 시작된 것이 아니라, 순수하게 "소프트웨어 품질의 정량화"라는 측면에서 시작된, 소프트웨어 관련 연구가 활발하게 이루어 졌다는 이야기는 들어 본적이 없다. 물론, 내가 잘못 알고 있는 것일 수도 있지만...

각설하고... 슬프지만... Programming skill에 대한 가장 현실적인 정의는 "적은 비용으로 소프트웨어를 만들어 내는 기술"이라고 할 수 밖에....


주저리 주저리... 문맥도 안맞고... 내용도 정리가 안되어 있고.. 쩝..

신고
Trackback 0 : Comment 0