QG(Quality Gate) 우리말로 의역을 하면, “품질통과기준으로 이해 할 수 있을 것 같다. 위키백과에서는 다음과 같이 정의하고 있다.

QG(Quality Gate)

간단히 이야기 하면, 검수관이 출구에 서서 제품을 살펴보고 이 제품 또는 기능이 출구를 통과해도 될지 안될지를 결정하는 과정이다.

 

모든 개발자는 당연히 좋은 품질의 소프트웨어를 만들기 위해 노력한다. 말은 참 쉬운데, 왜 쉽지 않을까?

여기에 고려해야 할 네 가지 주요 요소가 있다.

 

Feature – Quality – Time – Resource(사람과 비용)

 

피처를 잘 구현하기 위해서는 많은 시간과 자원을 투입하면 된다. (많은 시간과 자원을 투입한다고 항상 좋은 결과가 나오는 건 아닌 것 같지만J)

그렇지만, 기업은 항상 시간과 자원이 부족하다. 결국 전체 제품에서도 가치(Value)에 따라 우선순위를 정하고 자원을 배분 할 것이다.

 

예전 제 매니저분과 이야기 중 자신에게 자원(비용과 사람)이 풍부하다면, 난 이 일을 당신에게 맡길 이유가 있을까? 라고 질문을 하셨다. 사람과 자원이 풍부하면, 당연히 모든 주도권을 기업이 가지게 될 것이다. 결국 자원이 너무 풍부한 상황은 개발자 자신에게도 그렇게 유리한 상황은 아니다. (부족해도 문제, 많아도 문제 J)

품질과 자원은 항상 트레이드 오프가 생기게 되어 있다. 결국 조절을 해야만 한다.

(이러한 조정은 보통 와이드밴드 델파이(Wideband Delphi) 기법을 많이 사용한다. 와이드밴드 델파이 기법은 향 후 꼭 다루게 될 것이다. 그때 자세히 이야기 하도록 하겠다.

품질 프로세스와 보안 프로세스는 절 때 개발 프로세스와 떨어져서 진행하면 안 된다. 항상 함께 고려해서 함께 진행을 해야 한다.

 

자 이제 QG를 통과하기 위한 항목으로 소프트웨어 개발에서는 어떤 것을 보는지 살펴보자.

 

1.      높은 수준의 경고를 사용해 컴파일

2.      정적 분석 도구를 이용한 코드 분석

3.      모든 코드에 대한 유닛 테스트

4.      코드 커버리지 비율

5.      모든 코드에 대한 리뷰

 

여기서 소스와 개발은 닷넷위주로 이야기 하도록 하겠다.

경고는 항상 버그라고 생각해서, 되도록 방어적 프로그램을 할 필요가 있다. 사실 매뉴얼 하게 하면, 일이 참 많은 부분인데 Visual Studio를 사용하면, 쉽게 적용이 가능한 부분이다.

 

정적 분석 도구를 이용하는 부분이 QG에서 상당히 비중이 높다.

 

소스 코드를 가이드에 맞게 작성을 했는지 그 규칙을 지정한다. 소스 코드의 스타일 지침은 소스 코드의 형식을 지정하는 방법에 대한 규칙이며, 들여쓰기나 순환문의 형식 등 아주 자세한 코딩 룰을 지정 할 수 있다. 이런 소스 코드에 대한 규칙은 StyleCop 이라는 툴을 많이 이용한다.

자세한 방법은 아래 사이트나 검색을 통해 관련 자료들을 찾을 수 있다. 저는 향 후 이 내용에 대해서도 아주 심도 있게 다룰 것이다.

StyleCop 사이트


그 다음이 소스 코드 보다는 좀 더 나아가 어셈블리 중간코드를 분석해줄 필요가 있다.

FxCop 이라는 툴을 사용해 컴파일된 .NET 어셈블리의 중간 코드를 분석하고 디자인, 보안 및 성능 개선을 위한 기능을 제공한다.

이 기능은 제가 아주 좋아하는 기능이라 뒤에서 아주 자세히 다루도록 하겠다.

FxCop 사이트

C/C++Prefast를 사용할 수 있다.

Visual Studio Team System을 사용한다면, 통합되어 있는 Code Analysis를 사용하는 것이 가장 편할 것이다.

 

다음은 분석된 결과를 기반으로 각 코드에 대한 Unit 테스트를 모두 실행해야 한다. 유닛 테스트가 TDD에서도 가장 비중 있게 논의되는 부분이다.

닷넷에서 가장 많이 사용하는 툴은 NUnit 이다. NUnit은 닷넷 기반의 단위 테스트 프레임워크(Unit-testing framework)이다. Visual Studio Team System Unit 테스트 프레임워크를 사용할 수도 있다.

이것 또한 제가 아주 좋아하는 툴로 단지 사용법뿐만 아니라 단위 테스트에 대해서는 아예 다른 코너를 만들어서 다룰까 한다.

NUnit 사이트

 

이외에도 좋은 단위 테스트 툴이 많이 있다.

csUnit, mbUnit, xUnit.net 등이 있는데, 그 중 최근 개발된 xUnit이 눈에 뛴다. xUnit의 개발자 중 한명인 James Newkirk NUnit 개발에도 참여한 사람으로 다년간의 노하우로 xUnit을 개발했다고 한다. 기대가 되는 툴이 될 것 같다.

xUnit 사이트

 

마지막으로 닷넷에서의 단위 테스팅 프레임웍크와 TDD를 하기 위해 꼭 참고할 사이트가 바로 테스트 드리븐 닷넷이 있다.

테스트 드리븐 닷넷

 

다음 과정은 코드 커버리지를 통해 테스트가 코드를 얼마나 잘 테스트하는지를 측정하는 방법이다. 테스트의 목적은 무조건 많은 코드를 테스트 하는 것이 목적이 아니라 소프트웨어의 품질을 향상시키는데 있다면, 코드 커버리지의 목적은 테스트의 품질을 향상시키는데 있다. 그 비율을 통해 신뢰의 정도를 결정 할 수 있을 것이다. 보통 70~80%로 결정 하는 것 같다. 이건 상황에 맞게 결정 하면 될 것 같다.

 

자 마지막으로 모든 코드에 대한 리뷰과정이 있다. 보통 코드 인스펙션(Code Inspection) 이라고 하는데, CODE COMPLETE 2 에서는 코드 읽기로 소개가 된 것 같다.

인스펙터 툴도 있는데, 이건 제가 보기에는 정적 분석 도구로 분류하는 것이 더 나을 것 같다.

이게 사람들이 모여서 하게 되면, 잘못하면 누가 멀 잘못했는지 감정이 많이 상할 수 있는 부분이 있다. 이론상 좋지만 쉽지 않은 부분인 것 같다.

마이크로소프트에서는 개발자는 자신의 코드를 빌드 서버에 올릴 수가 없고, 리뷰어만 등록을 할 수 있는데, 보통 테스터가 많이 한다고 한다. 등록된 코드의 문제점에 대한 책임은 개발자가 지는게 아니고 리뷰어가 지게 된다고 한다. 당연히 내가 잘못한 것도 아닌데, 책임을 져야 하니 눈에 불을 키고 문제를 찾게 될 것이다. 저 또한 이 부분에서는 경험이 부족해 아주 자세한 노하우는 전달이 힘들 것 같다.

 

이러한 과정을 다 거쳐야 QG를 통과하게 되는 것이다. 사실 간략히 넘어갔지만 중간 중간 나오는 과정 하나가 상당한 분량이고 거기에 있는 툴 하나에도 상당한 책들이 나와 있을 만큼 중요한 부분이기도 하다.

제가 좋아 하는 부분이기도 해서 많이 다루고 싶었지만, 지금은 그 과정을 이야기 하는 부분이라 대부분 소개만 하고, 뒤에 자세히 다루기로 하겠다.

특히 몇몇 툴은 분량이 너무 많아 아예 카테고리 하나 만들어서 이야기 하는 것이 나을 것 같다.

 

자 다음은 Scrum(스크럼)에 대해 이야기 해 보도록 하겠다.

스크럼 자체를 아주 자세히 설명하는 건 아니니 스크럼이 무엇인지는 검색을 통해 미리 알고 있으면 좋을 것 같다.

 

Posted by SF공장장

 


 

마이크로소프트 PLC(Product Life Cycle)에서는 Product – Project – Feature 로 나누어서 접근하고 있다.

 

아무래도 마이크로소프트는 서비스 보다는 패키지 소프트웨어를 개발해서 판매하는 것을 주 업으로 하고 있어서 패키지 소프트웨어 개발 라이프 사이클을 잘 표현해 주고 있다.

그렇다고 꼭 패키지 소프트웨어에서만 적용이 가능한 것은 아니다.

어느 정도 차이는 있지만 인터넷 서비스에 적용하기에도 무난할 것 같다. 그리고 SI개발에도 도움이 될 것이다.

 

앞의 글에서 언급한 것처럼 항상 시작은 무엇(What)을 만드냐에서 시작한다.

하나의 제품(인터넷 기업에게는 서비스가 제품이 될 것이다.)을 만들기 위해 무엇을 만드냐는 것은 회사 전체의 전략이나 비전에 따라 결정이 될 것이다.

자동차회사에서 세탁기를 만든다면, 아무래도 좀 이상할 것 같다.

 

그럼 제품이 회사의 방향과 전략에 다르지 않다면, 왜 만들어야 하는지 당위성이 있어야 할 것이다. 우리가 살아가면서 필요하다고 무조건 물건을 구입하지 않는 것처럼, 기업 또한 필요하다고 무조건 만들지는 않을 것이다. “필요는 하지만 우리가 지금 정말 만들어야 하나?”

분명 여기서 생각해야 하는 것이 ROI(Return Of Invest) 일 것이다. 지금 수익성은 떨어지더라도 향후 회사의 전략상 필요한 것이라면, 당연히 모험을 해서 투자를 해야 할 것이다. 이 외에도 고려 해야 할 것이 훨씬 만을 것이다.

 

자 이제 만들기로 결정을 했다면, 개발의 입장에서는 전체 개발 공정을 어떻게 할 것인지, 업그레이드를 위한 장기 계획도 있어야 할 것이지만, 만들 무엇(What)에 대해 몇 가지 원칙이 필요할 것 같다.

 

고객, 비전, 방향, 책임

 

고객에게 전달할 제품의 가치는 무엇인지, 다양한 각각의 고객에게 줄 수 있는 비전은 무엇인지, 제품의 발전 방향에 대한 일관되고 신뢰할 수 있는 로드맵제품으로 인한 책임은 무엇인지를 개발에 앞서 결정해야 할 것이다.

 

SI 개발자들은 이런 이야기에 대해 이건 영업이나 PM이 할 일이고, 내 일은 아닌 것 같다고 대부분 생각하는 것 같다. 지금 맡겨진 일만 해도 태산이고, 스트레스 많은데 머 이런 것까지 라고 이야기 할 것이다. 다른 건 다 필요 없고, 내가 만들어야 하는 모듈이나 프로그램에 대해서만 정확히 이야기 해 주고 뒤에 다른 말만 안 해줘도 정말 고마울 다름이다.

그런데, 이렇게 일을 하면, 재미가 없다. 옆에서 보기만 해도 참 재미 없을 것 같다.

 

제가 만난 분 중에 SI 개발만 15년 이상 하신 분도 더러 있다. 비슷한 경력을 일 했으면, 실력도 비슷할까? 그건 아닌 것 같다. 정말 천차만별이다. 정말 하기 싫은 일을 밥벌이로 15년을 해도 생각해도 실력이 5년 정도 개발한 개발자와 별 차이를 못 느낀다. 거기에 비해 10년 정도 했는데도 진짜 대단하다는 생각이 드는 분들 또한 많다.

왜 이런 차이가 생기는지 한번 생각해 보시고, 그게 무엇일지도 한번 생각해 보시면, 내가 어떤 개발자가 될지 모습이 보일 것이다.

 

이외에도 제품에서 고려 하고 계획 해야 할 것들은 더 많을 것이지만, 이제 Project를 보자.

Value Proposition에 대해서 프로젝트 계획을 시작하면, 먼저 프로젝트의 최종 목표가 있을 것이다. 이 목표를 달성하기 위해 마일스톤과 기능에 대한 일정 그리고 기능의 우선 순위 리스트를 정한 후 엔지니어링 표준을 정해야 한다. 이제 우리가 앞 글에서 이야기 했던 구현에 대한 방법론 적용부터 디자인 등 이제 개발자들이 본격적으로 해야 할 일들이 슬슬 늘어나기 시작한다.

 

Feature 에서는 각 피처 팀들이 혼자 개발을 하는 것이 아니라 다른 팀과 지속적으로 상호작용하면서 애자일 방법을 사용해 개발을 진행하게 된다. 물론 지속적인 반복을 통해 각 빌드마다 QG(Quality Gate)를 통과 해야만 외부에 자신들이 자신 있게 만든 기능들을 공개하고 평가 받을 수 있다.

 

이런 과정을 거치면서 개발자들은 자신이 만들고 있거나 만들고 있는 제품에 대해 그리고 그 프로젝트에 작게는 자신이 참여한 피처에 자부심을 가지게 되는 것 같다.

아무래도 패치지 소프트웨어나 큰(사용자가 많은) 웹사이트의 개발자들이 이런 부분에 있어서는 자부심을 가질 수 있는 여건이 되는 것 같다. 게임의 경우에는 게임 마지막이나 중간 인트로 부분에서 개발에 참여한 사람을 영화처럼 보여주는데 이것 또한 개발자들에게 동기 부여가 되는 것 같다.

마이크로소프트에서는 제품 개발에 참여한 개발자에게 제품 출시와 관련해 특별한 기념품이나 제품의 버전 별로 참여한 사람의 이름을 돌에(?) 새겨 주는 것도 한다.

 

개발자에 대한 대우는 단지 높은 급여뿐만 아니라, 자부심을 가지고 일을 할 수 있는 환경 또한 절 때 무시 할 수 없을 것이다.

 

이렇게 하고 PLC를 넘어가기에는 아쉬움이 남는 것 같다.

실제 개발 중 개발자에게 가장 많은 스트레스를 줄 QG(Quality Gate)에 대해 알아보고, 품질 프로세스에 대해 살펴보자.

 

 

Posted by SF공장장

소프트웨어 생명 주기를 이야기 하면, 항상 교과서처럼 나오는 것이 Waterfall, Iterative, Agile 이다.

사실 소프트웨어를 만드는 단계를 아주 간단히 하면무엇을 만들지 결정하고, 만드는 두 가지 일이 있다. 분명 이 두 가지 일 가운데, 정말 다양한 일을 하게 될 거다.


폭포수 모델 이제는 이름만으로도 진부한 느낌이 든다. 반대로 애자일 적용만 해도 내 개발 실력이 확 느는 듯한 느낌을 주는 것 같다.

학교 다닐 때부터 책에서 소프트웨어의 위기부터 소프트웨어공학 그리고 방법론과 개발 프로세스 등 보기는 많이 본 것 같다. 문제는 보고 배워서 익히면 먼가 실력이 늘어야 하는데참 막막한 분야 이기도 하다.(90년대 중 후반은 객체지향과 UML 참 인기가 좋았고, 그 후는 디자인 패턴과 애자일로 인기가 많이 넘어간 것 같고, 최근에는 개발 프레임워크 인 것 같다.)

지금 여기에서는 ISO/IEC 12207 소프트웨어 생명주기 프로세스 모델 표준을 이야기 하려고 하는 것이 아니다. 그리고 제가 마이크로소프트에 있으니 당연히 ALM(Application Lifecycle Management) 솔루션으로 VSTS TFS 툴 소개를 하려는 것도 아니다.

CMMI와 같은 공정 또한 대형 프로젝트에서는 아주 중요하다. 저는 전체 공정 관리적인 측면 보다 이 글의 대상인 신입 개발자를 위한 관점에서 풀어 나가도록 하겠다.


마이크로소프트에서 제품을 만드는 모델을 PLC(Product Life Cycle)이라고 한다. 이름만으로는 먼가 와~ 하는 느낌이 안 오고 너무 평이한 것 같은데, 실제 이걸 적용하자는 것이 아니라 내가 소프트웨어 개발자로서 소프트웨어를 만들면서 놓치는 것이 무엇인지, 정말 큰 소프트웨어를 만드는 사람들은 어떤 방식이나 방법으로 만드는지 함께 공부하고, 실제 자신의 일에 적용해 보면 좋을 것 같다.

 

소프트웨어 프로세스 모델

 

앞에서 소프트웨어를 만드는 가장 간단한 단계로 무엇을 만들지 결정하고, 만드는 두 가지 역할로 구분을 했다. 여기에서 하나 더 포함되어야 하는 것이 왜 만들어야 하느냐는 질문이 들어가야 할 것 같다.

이걸 좀 있어 보이게  표현하면

“What? – Why? – How?”

사실 국내에서는 개발자들이 Why?는 잘 생각하지 않는다. 이유는 대부분의 개발자들이 SI업무에 종사하는 현실에서 왜 만들어야 하는지는 개발자 자신이 결정할 문제가 아니기 때문이다.

그래도왜 이걸 만들어 달라고 하지. 이유가 멀까? 아니면 진짜 필요한 게 머지?”라는 질문을 한번 해 보고 어떻게 만들지를 결정하는 것도 좋은 습관이 될 것 같다.

결국 이건 몇 가지 중에서 하나를 선택해 정답을 찾는 것이 아니라 현재 상황에서 가장 적합하고 효율적인 방법을 선택하는 문제이지, “이게 진리다!”는 아닌 것 같다.

그럼, 폭포수 방식은 전통적인 방법으로 요구사항 분석(R, Requirements Analysis)에서 시작해서 소프트웨어를 디자인(D, Design)하고 그 산출물을 기반으로 코드를 작성(C, Code)하고 단위 테스팅 등을 수행한 뒤 마지막으로 시스템 테스팅(S, System Testing)을 통해 통합하는 과정을 거치게 된다.

문서 기반의 모델로 요구 분석부터, 통합까지 말 그대로 한큐에 끝내는 프로세스로 간결한 모델이지만, 각 단계를 너무 명확히 구분하고 있고, 결과를 마지막에 가서야 알 수 있다는 위험 관리적인 측면에서 문제가 있다.

위키백과에서는 아래와 같이 정의 하고 있다.
폭포수모델




이러한 문제를 해결하기 위해 나온 것이 반복 모델로 위의 RDCT 과정을 한번에 끝내는 폭포수 모델과 달리 위험 요소를 중간에 검증해 볼 수 있다는 장점이 있다.

이러한 모델은 90년대 후반까지 사용이 되어왔지만, 전통적인 방식은 여러 문제점을 가지고 있었지만 가장 큰 문제가 사람 중심이 아니라 계획에 근거를 둔 방법이라 참여하는 사람에게 너무 많은 고통을 주게 되었고, 보다 빠르고, 기민한 방법이 필요하게 되었다.

이러한 노력으로 익스트림 프로그래밍(Extreem Programing, XP)과 스크럼 같은 모델들이 나오게 되었다.

애자일 개발 프로세스 또한 위키백과에 잘 정의 되어 있다.

애자일 개발 프로세스


자 그럼, 이제 마이크로소프트에서 소프트웨어를 개발할 때 사용한다는 PLC(Product Life Cycle)에 대해 다음 글에서 알아 보도록 하자.

 

Posted by SF공장장

 소프트웨어 공장 신입 개발자를 위한 가이드 V1.0소개

 

현재 회사에서 일하고 있는 업무상 소프트웨어 개발자를 많이 만나게 된다.

현재 학생부터 정말 오랫동안 소프트웨어 개발에 종사하고 계신 사장님까지 아주 작은 회사에서 아주 큰 회사까지 정말 다양하게 만나서 그 이야기를 들어보면 사람만큼이나 정말 다양하다.

 

소프트웨어 개발자는 소프트웨어를 만드는 사람이다. 소프트웨어 디자인에 참여 하는 사람도 있고, 하루 종일 개발만 하는 사람도 있고, 테스팅을 하는 사람도 있다. 이건 아주 아주 간단히 축약을 한 것이고 실제 소프트웨어를 만드는데 참여하는 사람은 이것보다 상상이상으로 많다. 이건 팀 구성에서 자세히 알아 보도록 하겠다.

 

개발자들과 팀장 그리고 사장님을 만나다 보면, 소개를 요청 하는 경우가 간혹 있다. 개발자의 경우 이력서까지 보내주시는 분들이 있는데, 이력서를 보면 정말 천편일률적인 경우가 대부분인 것 같다.

대부분 언제부터 개발을 시작했는지부터 알고 있는 기술은 먼지 그리고 참여한 프로젝트를 아주 멋지게 나열한 이력서가 대부분이었던 것 같다.

특히 자신이 사용 가능하거나 사용해본 기술 목록은 환상적인 10단 콤보 수준인데, 재미있는 건 학생이나 현업 개발자나 차이가 별로 없다.

 

좋은 소프트웨어 개발자는 방어적 코딩으로 개발을 하고, 디자인과 코드를 리뷰하고, Unit이나 TDD, 리팩토링을 통해 지속적으로 수정, 테스팅하고 분석을 통해 지속적으로 개선해서 좋은 제품을 만드는 게 덕목일 것 같다.

그러기 위해서는 제품이 돌아갈 운영체제도 알아야 하고, 개발 환경과 런타임, 개발 언어 그리고 개발 도구는 기본이고 여기에 개발 방법론부터 모델링, 데이터베이스, 등 정말 알아야 할 게 많은 것 같다. 그러니 당연히 위의 10단 콤보는 이런 것들이 쭉 나열되어 있다.

 

저 또한 이런 기술들을 공부하고, 2000년부터 이런 것들을 꾸준히 강연해 왔다.

 

너무 궁금해서 마이크로소프트에서 제품을 직접 만드는 개발팀에서는 신입 개발자에게 무엇을 가장 중요하게 생각하는지 궁금해서 오랜 시간 동안 제품 개발에 참여하신 분에게 질문을 하니 아래 요소를 꼽았다.

 

협업(협력)

의사 결정

혁신

학습

시간 관리

의사 소통(듣기, 말하기, 쓰기, 협상, 미팅 등)

 

그리고, 몇 가지 문서 링크를 주셨는데, 보면서 공부하니 도움이 많이 된 것 같다.

제가 공부한 내용들과 주위에서 들은 것들 그리고 잡다한 것을 정리해서 소프트웨어 회사에 들어가는 신입급 개발자들에게 필요한 가이드를 시리즈로 블로깅 하면 어떨까 해서 이 시리즈를 생각하게 되었다.


제목은 소프트웨어 공장 신입 개발자를 위한 가이드 V1.0” 이다.


소프트웨어 생명 주기부터 경력 관리까지 총 10가지 주제로 구성할 계획이다.

목표는 매주 하나의 주제를 블로그로 적자 인데, 사실 분량이 꽤 많은 내용도 있어 매주 하나의 주제는 쉽지 않을 것 같다. 제 생각으로는 대략 16주 정도면 될 것 같다. 여기에는 C#이나 코딩 가이드, Visual Studio 사용법, 세부 빌드 프로세스 등은 직접적으로 설명하지 않는다.

대신 중간에, 박스 형태 내용으로 추가할까 한다.

준비 기간도 꽤 되었고, 많은 것을 보이려는 욕심도 있다 보니 16주짜리 주제라 부담 또한 만만찮은 것 같다.

자 그럼 첫 질문 들어 갑니다!

 

현재 내가 일하고 있는 개발환경에서 가장 방해가 되는 요소 세가지만 꼽아 보세요. 그리고 그걸 없애기 위해 난 무슨 노력을 하고 있는지그리고 그게 해결(또는 제거J)이 되었을 때, 바뀌게 되는 효과와 개발 생산성은 어떻게 될지 생각해 보세요? (아무래도 세가지 요소 중 PM이나 팀장 이런 단어가 꼭 들어갈 것 같아 해결이라고 했습니다. 제거는 좀J)

 

아래는 앞으로 진행할 목록 입니다.

 

1.     소프트웨어 생명 주기

A.     소프트웨어 프로세스 모델

B.     품질 프로세스

C.     스크럼

2.     팀 구성

3.     협력

A.     함께 일하기

B.      기대

4.     의사 소통

A.     대화 기술

B.      문서 기술

5.     좋은 제품 개발

A.     성능

B.      신뢰

C.      계측 및 국제화

D.     보안

E.      유지 보수

6.     디버깅

A.     버그란?

B.      버그를 피할 수 있는 코딩

C.      실패의 재현

D.     문제 파악

E.      에러 수정

7.     기능 구현

A.     측정

B.      디자인

1.      왜 디자인인가?

2.      디자인 프로세스와 원칙

3.      디자인 영향

4.      연습

5.      디자인 문서

C.      테스팅

1.      버그의 영향(효과)

2.      개발자 테스팅 연습

D.     코드 검사

1.      검사란 무엇이고 왜 해야 하나

2.      검사 프로세스

3.      프로세스 향상

8.     일정

9.     우선 순위와 시간 관리

A.     우선 순위

B.      결정

C.      시간 관리

D.     과유불급

10.   경력 관리

11.   결론

 

Posted by SF공장장