Rookie Data Analyst's Mistakes

[커리어] SAP로 빡셌던 시간을 보내주며

진대현 — Sun, 5 Feb 2023 19:25:03 +0900

정식 입사가 2022년 03월이니, 아직 채 1년도 되지 않았지만 지난 몇달은 참···.

걱정과 불안의 힘이 컸던 것일지, 참으로 "빡셌다."

하지만, 그럼에도 값졌다.

그 시간들이 내게 주는 울림이 다양하고 독특해서, 나는 이 글을 쓴다.

이 글을 쓰는 이유는, 오직 훗날의 나를 위해 - 이 모든 것을 일지화/경험화 하기 위하여.

언젠가의 내가 이 글을 다시 읽기에 앞서 객관적인 서사를 작성하면, 독해에 도움이 될 것 같다.

우선 내가 다니고 있는 회사는 :

- 대형 유통 그룹의 법인들을 유기적으로 연결하는 쇼핑몰 또는 플랫폼 또는 서비스 또는 etc.

- 태생적으로 브릿지 역할을 하게 되므로 이 법인을 어떤 개인에 비유하자면, 참담할 정도로 주변인의 영향을 많이 받는 자.

- e-commerce 도메인에 속하므로 작년 말부터 이어진 경제 불황에 있어 직/간접적으로 부정적 영향을 많이 받는 기업.

지난 몇 달, 내가 한 일은 ··· 와!... 놀랍게도 내 머릿속에 문장으로 정리가 되어있지 않네? 사유는, '내가 이 상황과 과정들을 온전히 이해하고 있지 못하기 때문에 - 또한 개별 역량의 부재로 상급자의 가이드 없이는 방향성을 정의하지 못했기 때문에. ' 인 듯 하다.

머릿속을 살펴보건대 지난 몇 달간의 업무 목표는 "모기업의 차세대 정보시스템 전환(사내에서 혼용하는 표현들이 많지만, 그 어떤 것이 가장 올바른 표현일지 모르겠다. SAP 전환이라던지, 차세대 SAP라던지... SAP는 그냥 회사이름 아닌가? 솔루션을 지칭하는건지 ···)에 따라 발생한 마이그레이션(마이그레이션 이라는 단어의 정확한 뜻은 뭘까? 내 업무에 비추어 볼 땐, 신규 시스템이 요구하는 테이블 스키마가 변경되는 경우에 그에 맞추어 레거시를 요구사항에 맞추는 작업인데... 마이그레이션과 인터페이스라는 용어 간의 관계는 뭘까?)에 대비하여, 종래 레거시의 demand forecasting 기능에 문제가 없도록 하는 것." 정도로 정리가 되는 듯 하고.

이 상황을 정리해 내가 몰랐던 것과 여전히 모르는 것들을 정리해보면 :

- (중요)내가 참여한 프로젝트를 한 문장 또는 한 단어로 표현하면 뭐지? 이 프로젝트의 정확한 이름이 뭐야?
▶ 머릿속의 이름은, '이마트 SAP 전환 대응' 이긴 하다.

- 마이그레이션이라는 게 정확히 뭐야? 또, 마이그레이션을 원활히 하기 위한 전략을 짜는 룰은 정형화 되어있는 지식이야?

- (중요) 선배는 대체 어떻게 이 프로젝트 과정을 구체적인 워크플로우로 작성할 수 있었을까?

- 인터페이스라는 단어의 정확한 뜻은 뭐야? 나는 추상적으로만 이해하고 있는 용어가 많네..

- 다른 회사의 나와 같은 직무(일단 사내에서는 머신러닝 엔지니어 - 추구하는 바는 데이터 사이언티스트)를 가진 사람들에게 똑같은 상황이 닥친다면, 그들은 어떻게 일할까?

정도로 정리될 것 같다.

그리고 스스로에게 부족했던 능력 또는 스킬셋을 생각해보면 :

- 데이터 사이언티스트 실무자로서 나는 손이 굉장히 느린 편에 속한다.

- 원인을 꼽아보자면 몇가지 예상되는 것이 있는데, 첫번째로 업무가 어떤 순서로 해결되어야 할지에 대한 감이 없기 때문.

- 두 번째로 데이터 조회에 필요한 쿼리 작성의 숙달도가 떨어지기 때문.

첫번째 원인은, 시간이 흐름에 따라 해결될 부분이 있으리라 기대하며 큰 대응이 필요하지 않다(고 자기위로 해본다).

그러나, 두 번째 원인은 그간 미루고 또 미뤄왔던 SQL에 대한 조금 더 심화된 학습이 필요한 것으로 보인다. Spark를 쓰건, Hadoop을 쓰건, 결국 질의문이 필요한데 나는 왜 그걸 계속 외면해왔을까..? 학습 플랜이 필요한데, 여자친구의 조언에 따라 프로그래머스와 문제집을 병행해보려 한다.

프로젝트가 막바지에 이르렀을 무렵에, 마이그레이션 또는 학습 배치가 종료되는대로 이관 또는 생성 데이터를 빠르게 기존 데이터와 확인해야하는 업무가 있었다. 그런데, 이 과정에서 나의 대응 속도가 많이 아쉬웠고, 선배가 지나가는 소리로 '대현님은 SQL이 약간 어색하시구나.' 라고 혼잣말로 말씀하셨다. 부족한 부분을 따끔히 혼내신 것도 아니고, 지적을 하신 것도 아니지만, 나는 분명한 위기의식을 느꼈다. 초기에 대응(보완)하지 않으면, 언젠가 이것이 상사가 나를 바라보는 '평가'가 될 것이 자명하기 때문이다.

회사에서의 나에게는 복합적인 역할이 있다. 후배, 실무자, 프로젝트원, 파트의 막내 ···. 내가 위와 같은 위기 의식을 느끼는 까닭 또한 복합적이겠지만, (1) '손이 느린 실무자'가 나에 대한 제 3자의 만성적인 평가가 되어서는 안되기 때문, (2) 앞으로 내가 추가적인 학업을 병행하고자 한다면 '실무자로서의 역할'을 완벽히 한 뒤에 진행해야만 스스로의 평판에 마이너스 요인이 없을 것이기 때문 등이 그 이유이다(Ex - 저 인간은 '자기 할일 = 기본'도 제대로 못하면서 밖으로만 도네).

이제, 잘 모르는 것과 해내야만 하는 일들을 찾아두었으니 액션 플랜을 짜보면, 거창할 것 없이 첫번째로, 용어나 프로젝트명을 잘 모르는 부분들에 대해서는 팀원들에게 의견을 한번 구해보는 것으로 한다. 두번째로, 업무간 발생한 산출물을 다음주 출근하여 하나씩 정리해보아야겠다. 이건 분명히 지금 정리해둬야 다음에 내가 됐건 팀원이 됐건 써먹을 만한 문서가 될 수 있을것이다. 미뤄둬봐야 좋을 게 없다.

그리고 스킬셋에 있어서는 SQL도 SQL이지만, 내가 이 직업을 영위하는 데 있어서 필요한 실무적 스킬들을 상반기에 지속적으로 검토, 반성, 학습계획화, 실행하는 것으로 한다. 그 첫번째가 SQL일 뿐. 이번 프로젝트를 통해 내게 필요하다고 느꼈던 또 다른 분야는 데이터 엔지니어링 이었다는 점을 잊지 말도록 하자. 특히, 파이프라인 구축 등에 있어서 비용 효율적인 분석, 학습 등에 대한 준비를 위하여.

[Data Science 도서리뷰/Clean Code] 4. 주석

진대현 — Mon, 2 Jan 2023 21:45:10 +0900

클린코드, 로버트 C. 마틴, 2013

이 책은 세 부분으로 나뉜다.: (1) 깨끗한 코드를 작성하는 원칙, 패턴, 실기의 설명, (2) 사례 연구 : 더러운 코드를 깨끗한 코드로 고치기, (3) 사례 연구를 만들며 수집한 '냄새'와 '휴리스틱'의 열거. 본 게시글은 (1)의 네 번째 장인 4. 주석에 대한 정리와 리뷰이다.

4. 주석

우리는 코드로 의도를 표현하지 못했을 때에, 그러니깐 실패를 만회하기 위해 주석을 사용한다. 주석은, 그렇기 때문에 그 자체로도 실패의 증명이다.

주석이 좋지 않은 이유

주석은 오래될수록 코드에서 '필연적으로' 멀어진다. 오래될수록 완전히 그릇될 가능성도 커진다. 프로그래머들이 주석을 유지하고 보수하기란 현실적으로 불가능하기 때문이다. 코드가 태생적으로 변화하고 진화하는 것이라면, 주석은 결국 어느 시점에 머무르는 존재이다.

주석은 나쁜 코드를 보완하지 못한다

앞서 말했듯, 주석을 추가하는 가장 일반적인 이유는 코드로 의도를 명확히 표현하는 데에 실패했기 때문이다. 자신이 저지른 난장판을 주석으로 설명하려 애쓰기 보다는, 그 난장판을 깨끗이 치우는 데 시간을 보내는 것이 바람직하다.

코드로 의도를 표현하라

▶ 개선 전 코드

// employee가 복지혜택을 받을 자격이 있는지 검사
if((employee.flags & HOURLY_FLAG) && employee.age > 65)

▶개선 후 코드

if(employee.isEligibleForFullBenefits())

앞선 세 장에서 다뤘듯, '깨끗한 코드'는 그 자체로도 읽는 이가 이해하기 쉽다. 많은 경우에, 주석을 달아 설명하는 것보다 해당 설명을 표현하는 함수를 만들어 표현하는 것이 더욱 바람직하다.

좋은 주석(또는 필요한 주석)

경우에 따라 어떤 주석은 필요하거나 유익하다. 물론, 가장 좋은 방법은 역시나 주석을 달지 않는 것이다.

법적인 주석

소스 코드 첫머리에서 해당 코드의 저작권 정보 및 소유권 정보를 다루는 주석의 경우 법적으로 필요하여 사용된다.

정보를 제공하는 주석

때로는 기본적인 정보를 주석으로 제공하면 편리하다. 예를 들어, 추상 메서드가 반환할 값을 설명하는 다음과 같은 주석은 편리한 주석이다.

// 테스트중인 Responder Instance를 반환한다.
protected abstract Responder responderInstance();

하지만, 이와 같은 주석이 유용할지라도 해당 함수명을 "responderBeingTested" 로 바꾼다면, 해당 주석이 필요 없어진다.

의도를 설명하는 주석

때때로 주석은 구현을 이해하게 도와주는 선을 넘어 결정에 깔린 의도(그러한 코드가 작성된 의도)까지도 설명한다.

// 스레드를 대량 생성하는 방법으로 어떻게든 경쟁 조건을 만들려 시도한다. 
for (int i = 0; i < 25000; i++){
  스레드 생성
}

의미를 명료하게 밝히는 주석

때때로 모호한 인수나 반환값은 그 의미를 읽기 좋게 표현하면 이해하기 쉬워진다. 인수나 반환값 자체를 명확하게 만들면 더 좋겠지만, 인수나 반환값이 표준 라이브러리나 변경하지 못하는 코드에 속한다면 의미를 명료하게 밝히는 주석이 유용하다.

assertTrue(a.compareTo(a) == 0);  // a == a
assertTrue(a.compareTo(b) != 0);  // a != b
assertTrue(ab.compareTo(ab) == 0);  // ab == ab
assertTrue(a.compareTo(b) == -1);  // a < a
assertTrue(b.compareTo(a) == -1);  // b > a
assertTrue(aa.compareTo(aa) == -1);  // aa < aa

결과를 경고하는 주석

다른 프로그래머에게 결과를 경고할 목적으로 주석을 사용하는 경우 유용하다. 특히 아래 예시처럼 연산 시간이 오래 걸려 시스템에 부하를 줄 수 있는 경우에는 이를 경고할 목적으로 주석을 작성하는 것이 효율적인 결과를 낳을 것이다.

public static SimpleDateFormat makeStandarHttpDateFormat(){
	// SimpleDateFormat은 스레드에 안전하지 못하다.
	// 따라서 각 인스턴스를 독립적으로 생성해야 한다. 
	SimpleDateFormat df = new SimpleDateFormat("EEE, dd MMM  yyyy HH:mm:ss z");
	df.setTimeZone(TimeZone.getTimeZone("GMT"));
	return df; 
}

TODO 주석

'앞으로 할 일' 을 //TODO 주석으로 남겨두는 것은 편의성이 좋다. 프로그래머가 필요하다 여기지만 당장 구현하기 어려운 업무를 기술한다면, 잊지 않고 점검을 할 수 있다. 하지만 반드시 주기적으로 TODO 주석을 점검해 없애도 괜찮은 주석은 없애야 한다. 다른 프로그래머에게 혼동을 줄 수 있다. 만약, IntelliJ나 Pycharm과 같은 IDE를 사용한다면 요즘의 IDE는 TODO 기능을 제공하기 때문에 주석으로 작성할 필요가 없다.

[Data Science 도서리뷰/Clean Code] 3. 함수

진대현 — Tue, 27 Dec 2022 20:30:39 +0900

클린코드, 로버트   C. 마틴, 2013

이 책은 세 부분으로 나뉜다.: (1) 깨끗한 코드를 작성하는 원칙, 패턴, 실기의 설명, (2) 사례 연구 : 더러운 코드를 깨끗한 코드로 고치기, (3) 사례 연구를 만들며 수집한 '냄새'와 '휴리스틱'의 열거. 본 게시글은 (1)의 세 번째 장인 3. 함수에 대한 정리와 리뷰이다.

3. 함수

3장은 함수에서의 Clean Code를 소개하는 장이며, 앞선 두 장에 비해 정말 여러번을 정독해야만 했다. 이 장은 "함수의 추상화 수준"과 "메서드는 한 가지 일만 해야한다"는 두 개의 개념을 이해해야만 소화가 가능하다.

함수의 추상화 수준

그렇다면, "함수의 추상화 수준"이란 뭘까? 우선, 책의 내용을 찬찬히 살펴보면 다음과 같다. :

(1) 추상화 수준이 높다는 건 ... → 근본 개념에 가까운 것이다.

(2) 추상화 수준이 낮다는 건 ... → 세부 사항에 가까운 것이다.

이러한 설명은 그 설명조차도 너무 추상적으로 느껴진다. 높고 낮음은 구체적으로 어떤 예시가 있을까? :

(1) 추상화 수준이 높다는 건 ... → java에서 getHtml() 같은 것이다.

(2) 추상화 수준이 중간이라는 건 ... → String pagePathName = PathParser.render(pagepath); 같은 것이다.

(3) 추상화 수준이 낮다는 건 ... → .append("\n") 같은 것이다.

아, 어떤 느낌인지는 알겠는데, 뭔가 조금 부족하다. 책은 그에 대한 보충 설명으로, 함수를 만드는 이유를 짚는다. :

"지정된 함수 이름 아래에서 추상화 수준이 하나인 단계만 수행한다면 그 함수는 한 가지 작업만 한다(고 볼 수 있다는 내용임. 문맥 없이 잘라와서 오해가 가능하므로 정리). 우리가 함수를 만드는 이유는 큰 개념을 (다시 말해, 함수 이름을) 다음 추상화 수준에서 여러 단계로 나눠 수행하기 위해서가 아니던가."

메서드(함수)는 한 가지 일만 해야한다

함수의 추상화 수준에 대해 이해해보며, 함수들 만드는 이유에 대해 되짚어 보면 "메서드(함수)는 한 가지만 한다."는 말은 결국 위에서 정리한 바와 같이 "함수는 추상화 수준이 하나인 단계만 수행해야한다."는 말로 정리할 수 있다. 그렇게 정의되는 까닭은? 추상화 수준을 섞어 코딩을 하는 경우, 읽는 사람에게 개념적 혼동을 줄 수 있기 때문이다.

예시야 많겠으나 나는 다음으로 "함수의 추상화 수준이 하나"라는 말을 정리해보았다. :

"아메리카, 아프리카, 중앙아시아" 순으로 이야기 하는 것과 "남한, 북아메리카, 뉴욕시" 순으로 이야기하는 것 중 어느 것이 개념적인 통일성이 있겠는가?에 대한 질문과 그 답변으로.

개인적으로 한 블로거님이 정리해두신 내용을 보충자료로 사용했더니 이해가 좀 더 손쉬웠다. 추후에도 개념적인 혼동이 온다면 참고하는 것이 좋을 것 같다.:
https://onestone-dev.tistory.com/3

[CleanCode] 함수의 추상화 수준이란?

오랜만에 CleanCode를 다시 읽어보고 있는데 함수의 추상화 수준에서 책 읽기를 멈추고 3번 다시 읽었다. 아무래도 책의 추상화 수준이 높은 단계 였던 것 같다. "메서드는 한 가지만 해라!"라는 말

onestone-dev.tistory.com

그 외 깨끗한 함수에 대한 규칙들

(1) 첫째 규칙은 "작게!"다. : 둘째 규칙은 "더 작게!"다.

→ 가능하면, 최대한 간결하게 쓰라는 말.

(2) 중첩 구조가 생길만큼 함수가 커져서는 안된다.

→ 첫째 규칙이 뭐라고?

(3) 추상화 수준에 대한 내려가기 규칙을 지키자.

→ 코드는 위에서 아래로 이야기처럼 읽혀야 좋다. 한 함수 다음에는 추상화 수준이 한 단계 낮은 함수가 온다.

(4) 본질적으로 N가지를 처리하는 Switch문은 지양하되, 꼭 써야만 한다면 저차원 클래스에 숨겨라.

→ 해당 내용을 이해하기 위해서는 객체지향 5원칙을 이해하는 것이 좋다. 다음 블로그를 참고. https://blog.itcode.dev/posts/2021/08/13/single-responsibility-principle

[OOP] 객체지향 5원칙(SOLID) - 단일 책임 원칙 (Single Responsibility Principle) - 번째 알파카의 개발 낙

올바른 객체지향 설계를 위해 수립한 원칙이 있으며, 이 다섯 가지 원칙을 통틀어 객체지향 5원칙(SOLID)이라 명명한다. 필수로 적용하지는 않지만, 적어도 이 규칙을 준수하면 준수할 수록 올바

blog.itcode.dev

(5) 서술적인 이름을 사용하라.

→ 짐작가능한 이름을 쓰자.

(6) 함수 인수

→ 이상적인 인수의 수는 0개, 적으면 적을수록 좋고 3개 넘어가는 것은 피하자. 테스트 관점에서 보면 인수가 많을수록 인수마다 유효한 값으로 모든 조합을 구성해 테스트하기가 어려워진다.

→ 해당 내용은 다음 블로그에서 정리를 잘 해두었다. https://rebro.kr/199

[Clean Code] 클린 코드 3장 정리

1. 작게 만들어라 함수를 만드는 첫 번째 규칙은 최대한 작게 만드는 것이다. if문/else문/while문 등에 들어가는 블록은 한 줄이어야 하고, 주로 거기서 함수를 호출한다. 즉, 중첩 구조가 생길 만큼

rebro.kr

음, 사실 이 부분은 근래 데이터 사이언스에서 다루는 모수 튜닝 관점에서는 과연 가능한가? 에 대한 의문이 남는다. 데이터 사이언스 영역에서 해당 개념을 적용함에 대한 논의가 있는지 추가적으로 살펴보아야 할 것 같다.

이상으로 3장에 대한 정리를 마친다.

[Data Science 도서리뷰/Clean Code] 2. 의미 있는 이름

진대현 — Tue, 20 Dec 2022 00:46:18 +0900

클린코드, 로버트 C. 마틴, 2013

이 책은 세 부분으로 나뉜다.: (1) 깨끗한 코드를 작성하는 원칙, 패턴, 실기의 설명, (2) 사례 연구 : 더러운 코드를 깨끗한 코드로 고치기, (3) 사례 연구를 만들며 수집한 '냄새'와 '휴리스틱'의 열거. 본 게시글은 (1)의 두번째 장인 2. 의미 있는 이름에 대한 정리와 리뷰이다.

2. 의미 있는 이름

데이터 분석가(또는 사이언티스트) 또한 여느 개발자들과 마찬가지로 하루에도 여러번씩 '좋은 이름'에 대해 고민하게 되곤 한다. 핑계에 가깝지만 실제 업무에서는 아쉽게도, (1) 요구되는 수준이 매우 간단하거나, (2) 대응 자체를 빨리 해야만 하는 데이터 분석 업무의 경우에는 변수 또는 함수의 '좋은 이름'이 등한시되기 마련이다.

데이터 분석을 통해 추출된 인사이트를 전달하는 방식은 일반적으로 코드가 아니므로, 분석가의 산출물은 개발 언어로 작성된 '구조' 라기 보다는 가설로부터 시작된 어떤 '서사'에 가깝기 때문이기도 하다(라고 변명을 해본다).

하지만, 인사이트 추출을 위한 데이터 분석이 아니라 예측 또는 분류 성능이 목적인 ML/DL 프로덕트의 개발이 업무 목표인 경우엔 이야기가 조금 다르다. 나는 하루에도 여러번씩 옛 성현들이 남긴 레거시 코드들의 '배려심 없이 명명된 이름들' 때문에 분통이 터지곤 한다.

구조적으로 데이터 파이프라인을 파악하고, 각각의 컬럼들이 어떤 특성을 갖는지를 고려해야만 레거시 프로덕트들을 이해할 수 있고, 그 이해가 가능해야만 버릴 건 버리고 새로 만들어야 될 것은 새로 만들 수 있을텐데, 하루에도 여러번씩 이 '나쁜 이름'으로 명명된 값과 함수들 때문에 능률이 매우 떨어지곤 한다.

본 장에서는 이러한 '나쁜 이름'들을 '좋은 이름'으로 명명하기 위한 체크 리스트를 제공한다. 이 중 적절한 것들을 모아, 업무에도 적용해보려 한다. 프로덕트 개발에 필요한 작명도 그러하지만, 분석 인사이트 전달을 위한 컬럼명의 명명에도 도움이 될 것으로 생각한다.

의도를 분명히 밝혀라

좋은 이름이 절약해주는 시간은, 적어도 그 이름을 짓는 데에 드는 시간보다는 훨씬 많다. 내가 레거시 코드를 리팩토링 하면서 겪는 가장 '열받는' 유형의 나쁜 이름의 예시는 다음과 같다.

val mainPath = "./PATH/PATH"
val A1 = (...) // 주석 조차 없음.
val D = (...) read.parquet(s"$mainPath/.../TABLE") // 물론 여기도 없음.
val A2 = A1.join(D) // 마찬가지로 당연히 없음.

휴.. 이런 유형의 코드들을 리팩토링 과정에서 만나다보면, 정말 한숨부터 나온다. 물론, 이해는 한다. 많이 바빠서 그랬을 것이고, 데이터 파이프라인을 짜나가다 보면 대체 이걸 뭐라고 불러야할지 모를 - 덕지 덕지 JOIN을 붙여 만든 - 테이블들이 속출하기도 하니까. 한국말로도 설명하기 어려워서, 주석을 달기도 어려울 때가 있었을 것이다.

어쨌거나 분명한 건, 이 값의 이름은 능률을 땅바닥으로 추락시킨다. 레거시의 저 "A1" 같은 이름을 이해하려면, 데이터 파이프라인 전체를 UML로 그려본다던지, 그마저도 시간이 안되면 개별 파이프라인의 최종 테이블들을 기준으로 역공학을 해나가는 수밖에 없다.

그런 반면에 다음의 이름은 어떤가? :

val mainPath = "./PATH/PATH"
val ExpctPricInfo = 
	read.parquet(s"$mainPath/.../EXPC_PRIC_INFO").
	where("...").
	select("ID", "EXPC_PRICE", "REAL_PRICE")

적어도 단순히 알파벳 한 개로 명명된 이름보다는 테이블을 호출해오는 목적이 명료해진다. 정 고민하기 싫으면, 예시처럼 사내 데이터 표준 명명법을 따라 이름지어진 raw data의 이름을 그대로 쓰는 것도 나쁘지 않은 전략이라고 생각한다. 몇 번을 테이블을 붙여쓰건, UNION을 하건간에 최소한 어떤 테이블로부터 수정된 데이터인지 정도는 파악이 용이하지 않은가?

1장에서 이야기했듯이, 코드는 짐작 가능해야한다. 이는 데이터 분석을 위한 코드이건, 프로덕트 개발을 위한 코드이건간에 동일한 원칙이라고 생각한다. 짐작 가능한 코드를 위해, 좋은 이름을 고민하자.

이 부분을 책은 '변수나 함수 그리고 클래스 이름은 다음의 질문에 모두 답해야 한다. 존재 이유는? 수행 기능은? 사용 방법은? 따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다.' 라고 정리한다.

그릇된 정보를 피하라

이 파트의 내용은 다음과 같이 간단히 요약된다. :

(1) 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용하면 안된다. (Ex : RMSE와 같이 널리 쓰이는 metric 이름을 다른 의미로 사용.)

(2) val, var, list, array, def 등 특별한 단어를 작명에 사용하면 안된다. (Ex : val varNameDef 라던지.. 다양할 것이다.)

(3) 서로 흡사한 이름을 사용하지 않도록 주의한다.

(4) 유사 개념은 유사 표기법을 사용한다. 자동 완성 기능 상에서 유사한 정보가 순서대로 나오도록 하면 능률에 도움된다.

(5) 소문자 L과 대문자 O와 같은 끔찍한 혼동을 피한다. (Ex : 소문자 L과 대문자 I의 혼용이라던지, 알파벳 O와 0의 혼용 등)

의미 있게 구분하라

이 파트에서는, '코드를 오직 구현만을 위해 작성하지 말자.' 고 이야기한다. 가장 안좋은 예시로, 연속된 숫자를 덧붙이거나 불용어를 추가하는 방식은 적절하지 못하다는 점을 지적한다. 이름이 달라야 한다면, 의미도 달라야만 하는 것이다.

클래스의 경우 불용어를 추가하는 방식은 특히나 부적절하다. Product라는 클래스가 있다고 할 때, 다른 클래스를 ProductInfo 혹은 ProductData라 부른다면, 개념이 구분되지 않은 채 이름만 달리한 꼴이 된다. 이 경우 Info나 Data 라는 단어 역시 겉으로는 멀쩡해보이지만 기능적으로는 불용어와 다를 바 없는 기능을 수행하는 형태가 된다.

잘 이해가 안된다면, 다음의 예시만 한 가지 기억하고 유사한 경우를 피하자 : Name과 NameString.

발음하기 쉬운 이름을 사용하라

간단하다. 사람들은 단어에 능숙하며, 발음하기 쉬울수록 좋다.

책에서는 'genymdhms(generate date, year, month, day, hour, miunute, second)'라는 단어를 예시로 들었다. 이러한 단어 사용은 회의를 진행하는 데에도 단점이 있다. 비슷한 예로 내가 직접 겪어본 단어로는 'mksplprc(make supply price)'라는 단어가 있다.

물론, 저자가 예시한 genymdhms보다는 덜하지만, 이 경우도 발음이 참 난처한 경우가 많다. 이 단어는 공급가 함수의 이름인데, 사전 지식이 없는 사람이 회의에 있는 경우, '메이크 서플라이 프라이스 함수' 라고 읽어도 될지 안될지 고민하다가 결국 '엠-케이-에스-피-엘-피-알-씨' 라고 읽을 때가 많다.

검색하기 쉬운 이름을 사용하라

문자 하나를 사용하는 이름과 상수는 눈에 쉽게 띄지 않는다. 검색의 관점에서는 긴 이름이 짧은 이름보다 낫다. 이름의 길이는 범위 크기에 비례해야 한다.

자신의 기억력을 자랑하지 마라

루프에서 반복 횟수를 나타내는 변수명으로서의 i, j, k 등을 제외하곤, 문자 하나만 사용하는 변수 이름은 문제가 있다. 독자가 코드를 읽으면서 변수 이름을 자신이 아는 이름으로 변환해야 한다면, 그 변수 이름은 '절대로' 바람직하지 못하다. 진정한 전문가 프로그래머는 명료함이 최고라는 사실을 이해한다.

클래스 이름

클래스, 객체 이름은 명사나 명사구가 적합하다 : Customer, WikiPage, Account 등이 좋은 예 / 단, Manager, Processor, Data, Info 등은 피하고, 동사는 사용하지 않는다.

메서드 이름

메서드 이름은 동사나 동사구가 적합하다. postPayment, deletePage, save 등이 좋은 예 / 단, 접근자, 변경자, 조건자는 javabean 표준에 따라 각각 get, set, is를 붙임.

기발한 이름은 피하라 / 말장난을 피하라

코드 이름에 농담이나 장난을 치지 마라.

한 개념에 한 단어를 사용하라

추상적인 개념 하나에 단어 하나를 선택해 이를 일관되게 사용하는 것이 좋다. fetch, retrieve, get을 혼용해서 쓴다면, 추후 혼동으 불러일으킬 가능성이 높다. 나의 경우, 이러한 실수를 피할 방법으로 사내에서 지정된 데이터 표준어 사전을 활용한다.

해법 영역에서 가져온 이름을 사용하라

당신의 코드를 읽을, 읽는 사람도 당신과 같은 데이터 사이언티스트이다. 특히, 팀원이 같은 백그라운드를 공유하고 있다면 알고리즘, 패턴, 수학 용어 등을 사용해도 괜찮다. 모든 이름을 domain(문제 영역)에서만 갖고 오기보다는 동료들이 친숙한 개념을 사용하는 것이 현명한 경우도 있다.

의미 있는 맥락을 추가하라

책에서 예시한 내용 : firstName, lastName, street, houseNumber, city, state, zipcode라는 변수가 있다면, "읽다보면" 주소임을 알아챌 수 있겠으나 이보다는 각 변수명 앞에 "addr"이라는 접두어를 추가할 것을 추천한다. 알고리즘 또는 코드 전체를 읽어보지 않더라도, 아주 간단한 방법으로 코드를 읽는 사람에게 맥락을 알려줄 수 있는 방법이다.

불필요한 맥락을 피하라

공급사슬관리(SCM ; Supply Chain Management)를 위한 예측 모델을 개발한다고 치자. 이 경우, 모든 클래스나 함수명의 접두어를 SCM으로 고정하는 것은 바람직하지 않다. 코드 내 검색을 활용할 때에도 좋지 못하고, 일반적으로 긴 이름보다는 짧은 이름을 사용하는 것이 바람직하기 때문이다. 의미가 명확하다면, 길이가 큰 상관이 없겠으나 쓸데없는 접두어 등을 활용하여 불필요한 맥락을 만드는 것은 이름의 명료함을 떨어트린다.

요약

의미 있는 이름을 위한 규칙

의도를 분명히 밝혀라

그릇된 정보를 피하라

의미 있게 구분하라

발음하기 쉬운 이름을 사용하라

검색하기 쉬운 이름을 사용하라

인코딩을 피하라

자신의 기억력을 자랑하지 마라

클래스 이름

메서드 이름

기발한 이름은 피하라

한 개념에 한 단어를 사용하라

말장난을 하지 마라

해법 영역에서 가져온 이름을 사용하라

문제 영역에서 가져온 이름을 사용하라

의미 있는 맥락을 추가하라

불필요한 맥락을 없애라

[자기계발/자격증] 빅데이터분석기사 필기 독학 2주, 전공자 후기

진대현 — Wed, 14 Dec 2022 21:07:45 +0900

2022 빅데이터 분석기사 필기 문제집 800

기초 스펙

이런 자격 시험을 준비하시는 분이라면, 보통 본인의 스펙과 합격 후기를 남긴 사람의 스펙을 비교해보기 마련이라 본인의 이력을 아래와 같이 남깁니다.

- 시험응시 당시 최종학력 : 통계학과 석사과정생 + 학부 산업시스템공학, 통계학 복수전공 졸업
- 시험응시전 유관 시험(ADsP, SQLD, DAsP 등) 응시 경험 : ADsP 취득, ADP 시험 응시 경험(불합격)한 상태로 응시.

그렇습니다. 이 게시글은 순전히 전공자를 위해 전공자가 작성한 게시글입니다. 혹시 비전공자시라면 본 게시글 보다는 좀더 양질의 후기 포스트들이 있을 것이니, 검색에 조금만 더 힘내주시길 바랍니다.

합격 인증

필기, 실기 모두 합격하여 자격증 취득한 상태

응시 동기

아직은 빅데이터분석 관련 기술사 자격증이 존재하지 않지만, 일반적으로 기술사 시험의 경우 응시 요건으로 기사 자격증 취득 후부터 일정 기간의 경력을 요구합니다. 중요한 것은 내가 이미 몇 년을 일했던지간에, 자격증 취득이 전제조건이기 때문에 취득 시점이 빠를수록 유리합니다. 저는 추후 기술사 자격증이 생길 것을 고려해서(기술사가 몇년 내로 신규 개설될 가능성은 낮지만) 기사 자격증을 취득했습니다.

2022년 하반기를 기준으로, 여러 금융 공기업에서 해당 자격증에 가산점을 부여하고 있습니다. 이 때문에, 금융 공기업을 준비하는 분들께는 약간의 메리트(서류 가산점)가 있을 것으로 생각합니다.

시험 난이도

ADsP < 빅분기 < ADP 로 정리할 수 있습니다. 아직 빅분기가 좀 더 기사 자격증 다운 자격증이 되기에는 저변 확대가 될 시간이 필요한 듯 합니다. IT 관련 자격증으로 치면, 정보처리기사 수준의 변별력을 갖추려면 시간이 필요해보입니다.

공부 기간 및 방법

본 게시글은 전공자(통계학, 산업공학 등)를 대상으로 하기 때문에, 학부 4학년으로써 최소한의 백그라운드를 갖고 있는 상태라고 가정하겠습니다. 전공자의 경우 필기 시험은 2주면 충분한 수준입니다. 특히, 빅분기 필기 응시 직전에 ADsP를 응시한 분이라면 필요 공부 기간이 더욱 줄어듭니다. 두 시험의 시험범위가 유사한 과목이 있기 때문입니다. 하지만, 그래도 기사 자격증인만큼 2주 정도의 공부 기간을 예상하고 학습 계획을 짜는 것이 안전할 듯 합니다.

아래 사용된 책을 기준으로, 2주 이내의 학습계획을 미리 짜되 어느정도 여유가 있는 수준에서 학습 범위를 가져가시길 추천합니다. 특히, 직장인 응시자의 경우에 하루 2시간 이내로는 학습 기간 대비 총 학습시간의 절대적인 양이 부족할 것이기 때문에 최소 하루 3~4시간의 학습 기간을 확보하는 것이 경험적으로 올바릅니다.

어떤 책을 보면 좋을까요?

저의 경우 책은 2권을 사용했습니다. : 썸내일로 사용된 "NCS 정보화기술연구회, 빅데이터 분석기사 필기 문제집 800", 그리고 "데이터에듀, 빅데이터 분석기사 필기".

데이터에듀 2022 빅데이터 분석기사 필기

석사 전공자로서의 개인적인 의견이지만, 여러 종류의 문제집 중에 데이터에듀의 책이 '그나마' 이론 정리 및 구성이 다른 책들 보다는 나은 것 같습니다. 물론, 이러한 시험을 위한 교재답게 몇몇 부분들은 명쾌한 설명 없이 단순 암기해야할 부분들도 분명 있습니다. 저는 이러한 교재 구성을 보아도, 아직 본 자격시험이 변별력을 갖추기 위해서는 다소간의 시간을 더 필요로 한다는 증거라고 생각합니다.

아쉽게도 해당 문제집의 예상 문제들이 적중률이 높은가? 하는 부분에 있어서는 아직은 아쉬운 수준이라고 생각합니다. 그래서, 데이터에듀 책은 이론 정리를 위해서만 사용하고 문제 풀이를 위해서 "NCS 정보화기술연구회, 빅데이터 분석기사 필기 문제집 800" 를 이용하는 것을 추천합니다.

어떻게 공부할까요?

이론 정리와 문제 풀이 비율을 1:1로 가져가길 추천합니다. 본 시험은 문제은행 방식으로 출제되는 편이나, 신설된지 얼마되지 않은 자격증이기 때문에 신규 문제의 비율도 높은 편입니다. 개정된 문제집들 중 '필기 문제집 800'의 경우 실제 시험 문제들을 복원하여 문제집이 구성되어있기 때문에, 최대한 이미 기출된 문제를 또 틀리는 일을 최소화해야 합니다.

다만, 전공자의 경우 이론 정리 과정에서 노트 필기 등을 하느라 쓸데없이 많은 시간을 할애하지 않았으면 좋겠습니다. 통계 문제의 경우에도 최소한의 통계학 개념을 요구하는 편이라, 학부에서 전공 과목에 충실했다면 그리 많은 시간을 투입할 이유가 없습니다. 특정 본인이 잘 모르는 내용이 많더라도, 이론 학습 기간에는 특별히 어떤 한 과목에 시간을 많이 할애할 필요 없습니다. 오답문제의 과목 및 유형을 점검하여 약점이 있는 파트만 재학습하길 권고합니다.

ADsP와 마찬가지로, 데이터 전문가 포럼이 매우 유용합니다. 기출 문제를 점검해보고 빈출된 용어 및 개념이 어떤 것이 있는지 한번 숙지해보고, 해당 개념 및 용어들을 한번 정리해보는 수준으로만 학습 시간을 이론 공부에 할애하길 바랍니다.

https://cafe.naver.com/sqlpd

데이터 전문가 포럼 (빅데이터분석기사... : 네이버 카페

빅데이터분석기사, ADP, ADsP, SQLP, SQLD, DAP, DAsP, 자격증 취득 등 데이터 전문가 커뮤니티입니다.

아래는 주관적인 빈출 개념들입니다.

1. 통계 관련 개념으로는 최우추정, mean과 median의 용법차이, Bayes 정리, 정규분포의 확률 계산, 신뢰수준/구간 계산, 단측/양측 검정 방법 및 p-value의 개념과 계산 방법, 1종 오류와 2종 오류의 구분 등이 빈출되고 있습니다.

2. 모델 성능 평가 지표와 관련하여서는 RMSE, MAE, MSE 등의 metric에 대해 혼동을 주는 지문이 자주 출제되는 것으로 생각되고, Confusion matrix의 개념 및 계산 방법, ROC AUC Curve 등에 대한 개념 및 해석 방법 등 또한 그렇습니다.

결론

필기 시험 난이도 : ADsP < 빅분기 필기 < ADP

공부 기간 : 전공자의 경우, 2주면 충분

공부 방법 :

(1) 문제집 2종을 활용하여 이론 공부와 문제 풀이 기간을 1주씩 가져가기

(2) 빈출 개념에 어떤 것이 있는지 데이터 전문가 포럼의 게시글 참고하기

(3) 오답정리하기

[시시콜콜] 주차 물피도주(주차 뺑소니) 피해 발생시 처리방법, 신고 방법에 대한 경험담

진대현 — Sat, 10 Dec 2022 09:13:18 +0900

목이 달랑달랑한 닉... 아니 번호판이 달랑달랑한 K5

본 게시글은 주차중 물피도주 피해 경험을 기준으로 동일 피해를 겪으신 분들의 당혹감을 조금이라도 줄여드리고자, 피해 사실 인지 후부터 신고, 보험사 접수, 처리, 진술서 작성, 수사 과정 등에 대해 오직 일반인의 입장에서 전달하는 글입니다. 일반인 입장에서 2022년 11월 경 일어난 경험담에 근거하여 작성된 내용이므로 "전문가의 지식이 아니기에" 참고사항으로만 활용해주시길 바랍니다.

1. 사고에 대해 인지

"빌어먹을 XX."

많이 순화한 말이지만, 주차중 물피도주(뺑소니) 피해를 처음으로 인지하고 내가 내뱉은 말은 역시나 욕지꺼리였다. 사실, 멀리서 보았을 때 현실감을 느끼지 못했다. '어? 내 차 번호판이 왜 저래' → '뭐야 스크래치도 났네?' → '도대체 어떤 빌어먹을 자식이 이런짓을 한거지?' → '혹시 방금 막 나간 차들 중 하난가?' → '어라? 전화번호 남기고 간 것도 없네?' → '혹시 내가 전화를 못받았나?' → '부재중 없는데..?' → '아, 뺑소니구나 ···.'

지난 11월 27일, 나는 주차중 물피도주 피해를 입었다. 장소는 서울의 한 유료주차장. 면허 취득 10년차, 장롱 면허 탈출한지 고작 4년, 인생 최초의 뺑소니 피해에 대한 감상은? '황망했다.'

피해를 당해 이 글을 찾으신 분께서는 이제부터 아래 내용의 밑줄 친 부분을 따라하세요.

2. 사진 촬영 & 블랙박스 확인(블랙박스가 꺼져있는 경우)

사고 인지 후 가장 먼저 하셔야 할 일은 피해 사실을 증빙하기 위해 사진을 찍어두는 것입니다. 많이 당황스럽고 화가 나시겠지만 차량을 이동하지 마시고, 반드시 사진 촬영을 해두세요. 해당 사진은 이후 (1) 보험사 사고 접수, (2) 경찰 조사 접수 과정 등에 참고자료로 사용됩니다.

그 뒤에 곧바로 블랙박스를 확인합니다. 녹화 영상이 남아있다면, 112 신고 후 출동한 경찰관에게 사고 내용을 전달하기에 용이합니다. 또한, 영상에서 가해자가 특정된다면 후술할 '주·정차 사고 관련 스캐치' 서류 작성과 사고 접수 과정에도 도움이 됩니다.

저의 경우 안타깝게도 블랙박스 기능이 꺼져있었습니다. 하지만, 우선 저와 같이 '블랙박스가 꺼져있는 상태로 물피도주 피해를 입은 경우'에는 주변에 주차되어 있는 차량들의 차주들에게 연락해보는 것이 좋습니다. 혹시, 다른 차의 블랙박스에 가해자의 영상이 녹화되어 있을 수도 있기 때문입니다. 아, 아쉽지만 저의 경우 주변의 여러 차주분들이 도와주셔서 확인은 해보았지만 녹화된 영상은 없었습니다.

3. 경찰 신고 & 도착 후

사고 장소의 주소지를 확인하고, 카톡 등에 저장해둡니다. 가능하면, 지도 앱을 켜서 해당 장소를 캡쳐해둡니다. 확인되셨다면 고민하지 마시고, 블랙박스 내용을 확인해본 뒤(주변 차주들에게 전화하는 것보단 경찰 신고를 선행하세요) 112에 신고합니다. 신고 접수만 받는 곳에서 전화를 받습니다. 다음과 같이 말합니다.

'주차중 물피도주 피해를 입었습니다. 사고 장소는 (주소지) 입니다.'

신고 접수와 경찰관 출동

접수되었다는 문자가 올 것입니다. 10여분 뒤, 가까운 지구대 경찰관 2명이 출동했습니다. 경찰관에게 신고 접수 사실을 알립니다. 경찰관 한 분은 나의 피해 사실을 듣고, 다른 한 분은 피해 현장을 촬영합니다. 피해 사실을 알리는 과정에서 블랙박스가 촬영되어 있는지 경찰관이 물어봅니다. 그 질문에, 블랙박스가 꺼져있었음을 알립니다(혹은 녹화본의 존재에 대해 알립니다).

여러분, 하지만 이렇게 출동한 경찰관은 사실 해줄 것이 딱히 없을 것입니다. 이들은 사고 장소를 살펴보고, 그저 가능하면 빨리 가까운 경찰서 교통계에 방문해 사고 접수를 하라는 조언을 하고 떠날 가능성이 높습니다. 물론, 그렇다고 해도 신고는 반드시 하셔야 합니다. 대신 그냥 보내지 마시고, 어떤 경찰서가 가까운 지 출동 경찰관에게 물어봐 두세요.

여기에 제가 드릴 수 있는 추가적인 조언은 다음과 같습니다. :

(1) 블랙박스가 꺼져있었다면, 주변 차주분들께 전화를 해 협조를 구해보세요

→ 대체로 차주분들의 공감대가 높아 도와주실 것입니다

(2) 유료 주차장이라면, 주차장 관리자를 찾아 연락처를 받아 저장해두세요

→ 불행하게도 가해자를 찾지 못한다면, 보험사를 통해 유료 주차장 관리자에게 보상을 요구하는 최후의 수단이 있습니다

(3) 관리자를 찾기 어렵다면, 주차장 차단 장비 등에 부착된 관리업체의 연락처를 저장해두세요

→ 유료 주차장의 경우, 출입구 차단 장비에서 번호판을 인식하기 위한 카메라가 녹화중이므로 경찰 수사에 참고자료로 활용될 수 있습니다. 해당 연락처를 저장해두었다가, 수사관에게 전달하세요

(4) 주차장 내 CCTV 위치를 기억해두거나 촬영해두세요
→ 블랙박스가 녹화가 잘 되었건, 꺼져있었건 간에 CCTV 위치를 반드시 확보해두세요. 사고 장소의 지도를 캡쳐하여 스케치를 해두는 것도 좋은 방법입니다. 저의 경우 블박이 비록 꺼져있었으나, 이 CCTV 덕분에 수사를 통해 가해자를 특정할 수 있었습니다.

(5) 추가로, 혹시 주변에 정부, 도, 시, 군에서 운영하는 다목적, 치안 CCTV가 있는지 살펴보시고, CCTV 기둥에 부착된 관리번호를 '우선은' 촬영해두길 바랍니다. 왜 '우선은' 이라는 단서를 달았냐면요.

→ 검색을 해보다보면, 개인이 이 CCTV 관리주체(일반적으로 구청)를 대상으로 정보공개청구 포탈을 통해 정보공개청구를 하라는 글들이 있는데요. 하지만, 해당 CCTV에 대해 직접적으로 정보공개청구를 진행하는 데에는 실질적으로 제약이 많습니다.

저도 직접 정보공개청구를 사고가 난 구의 구청을 대상으로 진행을 했는데, 다음날 구청 직원에게 연락이 왔습니다. 해당 직원에게 피해 사실을 알리고 용도와 목적을 전달했으나, 돌아오는 대답은 'Sorry'. 개인정보보호법 18조, 35조, 그리고 정보공개에 관한 법률 9조 때문이랍니다. 그래서, 개인이 직접 영상을 취득하는 것은 어렵다고 해요. 몇몇 글들에서는 이 영상에 대해 구청에 모자이크 처리를 요청하여 취득하면 된다는 글들이 있긴 합니다만, 그다지 협조적이지 않아 포기했습니다.

다만, 수사과정에 참고자료로 쓰일 순 있으니 우선 (4)에서와 마찬가지로 CCTV에 대한 위치 및 상세 정보를 확보하는 차원에서 확인해두시길 바랍니다.

(6) 여기까지 완료했다면, 차량 대차 또는 렉카가 필요한 상황인지, 보험사 직원의 현장조사가 필요한 경우인지 판단한 상태로 보험사 사고 접수를 진행하세요

→ 경찰 신고도 접수했으니, 이제 긴장을 잠깐 푸시고 본인의 보험사에 전화해 사고 접수를 진행하길 바랍니다. 이건 사고 경위에 따라 + 보험사 직원에 따라 케바케일 것이므로, 정답이 뭐라고 말씀드리긴 어렵네요.

저의 경우, 장기 렌터카였기 때문에 우선 전국렌터카공제조합에 전화(1661-7977)하여 사고 접수를 진행했습니다. 사고 접수의 경우, 상담원이 매뉴얼에 따라 진행해주는데 이 과정에서 대차가 필요한 상황인지, 렉카가 필요한 상황인지, 사고 현장의 보험사 현장조사가 필요한지 등을 물어봅니다.

일반적으로 주차중 물피도주 피해는 경미한 수준일 것이며 저의 경우에도 사고 피해 때문에 운행에 문제가 되지는 않았으므로, 대차 또는 렉카는 요청하지 않았습니다(번호판이 완전히 떨어진 것이 아니라 나사만 조이면 되어서 다행히 운행이 가능한 상태였습니다).

한편으로 사고 현장 조사의 경우 신청해보긴 했습니다. 다만, 일요일이었던 탓일지 현장 조사 직원이 전화가 와 지금 가서 확인해보더라도 피해 복구를 진행해줄 공업사가 주변에 없으니 현장조사를 취소해달란 연락이 왔습니다.

(6) 유료 주차장이라면, 출차 시 요금에 대한 영수증을 출력, 보관하세요.
→ (3)과 동일한 이유입니다.

(7) 이후 주말이건 평일이건, 가능한 빨리 가까운 경찰서 교통계에 방문해 사고 접수를 하세요

→ 저의 경우, 사고가 일요일 12시 ~ 13시경 발생했고 경찰서에는 14시에 도착했으나 당직 경찰관이 근무중이었기 때문에 사고 접수가 곧바로 가능했습니다. 일요일이라고 해서 사고 접수를 미루지 마시고 가까운 경찰서에 방문해 사고 접수를 진행하세요.

4. 경찰서 교통계 방문 및 신고

가까운 경찰서에 찾아갑니다. 교통계는 어디로 가야하는지 문의하여 교통계로 갑니다. 교통계 수사관에게 접수를 문의합니다. 작성하라고 하는 서류를 작성합니다. '주 · 정차 사고 관련 스캐치' 양식 작성을 요구할거에요. 해당 양식을 작성합니다.

여기에 필요한 정보는 다음과 같습니다.

(1) 본인 인적사항 :

성명, 주민번호, 전화번호, 가입보험회사, 차량번호, 차종

(2) 사고발생 상황 :

주차일시, 사고발생 일시, 발견일시, 블랙박스 유무, 용의차량번호, 목격자 연락처, 파손부위, CCTV 유무, 발생주소

(3) 사고차량이 주차한 장소 약도

→ 이것 때문에 사고 장소의 지도를 캡쳐해두고, CCTV 위치를 그려두시라고 한 것입니다. 최대한 상세히 스캐치합니다.

해당 양식은 진술서가 아니므로, 사고 내용에 대해 진술할 필요까진 없습니다. 어차피 작성 완료 후 제출하면, 담당 수사관과 면담이 진행됩니다.

담당 조사관과 면담에서 아래 내용은 반드시 전달하세요. :

(1) 피해 사실과 사고 인지 과정을 상세히 설명

(2) 블랙박스 녹화본이 있다면 제출

(3) CCTV 위치(공공 CCTV 포함)에 대해 명확히 전달

(4) 사고 장소의 관리주체에 대한 정보 전달(유료주차장인지, 연락처는 무엇인지 등)

(5) 주차 장소 지도 앱을 켜 장소를 재확인, 지상 주차장의 경우 가능하다면 '주차 위치'까지 상세히 전달

자, 이제 수사관의 명함을 받아들고 나오시고 전화를 꼭 받아야 하므로 연락처를 바로 저장해두세요. 피해 확인 후 당장 해야할 일들은 끝났습니다. 고생 많으셨습니다.

5. 신고 이후

(1) 보험사로부터 카카오톡, 웹 URL 등을 통해 사고처리를 위한 기본 사항, 사고 사진 등을 요구 받을 것입니다. 제출하세요. 곧 사고 담당자가 배정될 것이고, 담당자로부터 안내 전화가 올 것입니다. 다만, 수사가 종결될 때까지 해당 담당자가 해줄 수 있는 일은 딱히 없습니다.

(2) 어차피 이미 일어난 일입니다. 되돌릴 수 없으니 전전긍긍하지마시고, 수사관의 연락을 기다립니다. 짧으면 1주, 길면 2주 이내로 연락을 줄것입니다. 저의 경우 1주일 후 첫 전화가 와 중간 경과를 알려주었고, 2주일 후 가해자 특정 사실을 통지 받았습니다.

(3) 가해자가 특정되었다면, 축하합니다! 하지만 아쉽게도, 또다시 기다림의 시간입니다. 이제 가해자가 가해자의 보험사를 통해 해당 사고 내용을 접수 해주기를 기다립니다. 상대방 보험사로부터 연락이 올 것입니다. 어.. 그런데 안올수도 있다고요?

(4) 천년만년 기다릴 수 없는 노릇입니다. 피해 복구도 못하고 있고, 이럴거면 차라리 대차를 받아 사용할 걸 그랬습니다. 수사관이 미리 안내를 해주셨을 수도 있지만 아무리 기다려도 연락이 오지 않는다면? 구상권 청구를 통해 가해 차주의 보험사에 보험료 직접 청구 소송을 요청할 수 있습니다. 하지만, 여기까지는 경험해본 바가 없어 이 글에서는 그 이상 다룰 수 없네요. 미안합니다. 그러나 해당 내용을 알아두는 것 까진 도움이 될 것입니다.

P.S. 보험 처리 및 피해 복구 시점은 경우에 따라 다르니 본 글에서는 해당 내용을 생략합니다.

자, 이제 모든 처리가 끝났습니다. 여기까지 마음 고생 많으셨습니다. 반드시 가해 차주를 잡으셔서 피해를 복구하시길 바랍니다. 물론, '엥? 할 수 있는게 고작 보험료 청구야?' 라는 생각에 고구마 엔딩이라고 생각하실 순 있습니다.

하지만, 현실적으로 나한테 피해를 입힌 가해자를 특별히 좀 더 괴롭도록 조질 방법이 딱히 없습니다. 그에게 주어지는 형벌은 고작 20만원 남짓의 범칙금과 약간 인상된 보험료에 불과하거든요. 어쩌겠습니까? 법이 그런데요. 아쉽지만, 최소한 어떤 놈이 그랬는지 확인하고 피해 원복에 내 돈이 안들어가는 것에 만족합시다.

독자분꼐 본 글이 도움이 되길 바라며, 심심한 위로의 말씀 전하며 마무리하겠습니다.

[자기계발/자격증] 데이터 분석 준전문가(ADsP), 전공자 독학 후기..를 가장한 경험담

진대현 — Thu, 8 Dec 2022 23:18:40 +0900

2022 ADsP 데이터 분석 준전문가, 윤종식, 데이터에듀

글에 앞서 본인은 2020년 11월 22일 치러진 제 27회 시험 합격자임을 밝힙니다. 주관처인 한국데이터산업진흥원의 ADsP검정 시행에 관련하여, 2020년과 2022년 사이에 출제 범위가 변경 및 개정 되는 등의 공지는 존재하지 않음을 확인했으나, 본 게시글의 모든 내용은 2020년 기준으로 작성되었음을 참고하여 시험응시에 불이익이 없도록 하시길 바랍니다.

합격 인증 : 죄송합니다. 화질구지네요.

기초 스펙 : 학부 전공자, 통계학 석사 과정생.

- 시험응시 당시 최종학력 : 통계학과 석사과정 2학기 재학중 + 학부 산업시스템공학, 통계학 복수전공 졸업.
- 시험응시전 유관 시험(빅분기, SQLD, DAsP 등) 응시 경험 : 無.

응시 동기 : 남들 다 갖고 있던데요. 어쩌겠어요, 그냥 땁시다.

응시 학과의 제한이 없기 때문일지, 빅데이터 산업이 유행일지 몰라도, 근래 데이터 관련 자격증 3종+@(빅데이터분석기사, ADsP, SQLD, 여기에 DAsP 정도)의 인기가 뜨겁습니다.

하지만 이러한 사실과는 별개로, 저는 그냥 '전공자라면 취득하는 게 낫겠다.' 정도의 생각에 응시했습니다. 때문에 어떤 메리트를 바라고 취득을 준비하지는 않았습니다. 말 그대로, 전공자라면 '누구나 당연히 갖고 있는 자격증' 이라는 감상이 듭니다.

취준생들을 위해 좀 더 구체적으로 얘기해보겠습니다. 자격 취득 후 2년이 지나 현직자로서도 여전히 똑같은 생각을 갖고있는가 하면, '네, 우선 저와 비슷한 시기에 취업을 준비한 사람이라면, 대체로 갖고 있던데요? 전공자든, 비전공자든 데이터 분석가(또는 데이터사이언티스트)를 목표로 한다면요.' 라고 대답할 것 같습니다.

그러므로 이 자격 시험은 취업준비에 도움이 되나요? 라는 질문을 받는다면 현재로써는, '글쎄요. 당신을 뽑는 사람이 ADsP를 취득 했을까요? 이력서를 많이 보신 분 정도쯤이나 돼야, 취중생들 사이에서 유행인가 보다~ 싶으실 것 같은데요.' 하는 생각이 듭니다.

하지만, '고작 이거 없어서 불안한 것보단 낫잖아?' 하는 생각이 드네요. 덧붙여 만약 이런 자격증 유행 기조가 10년 뒤에도 유지 된다고 한다면, 그러니까 제가 이제는 누군가를 채용하는 관리자급이 되었을 땐 '아 뭐 전공자라는 애가 자격증이 이것도 없냐, 게으르네.' 라고 생각할 것 같습니다. 그 정도의 감상입니다. 더 이상의 응시 동기가 필요할까요?

(아참! 전공자/비전공자 상관없이, 공기업 또는 금융권을 준비하시는 분들께는 이만한 혜자 자격증이 없습니다. 시험 난이도에 비해 가산점이 제법 후한 편이기 때문입니다. 본인의 응시 목적이 가산점이고, 데이터 관련 자격증을 준비한다면 ADsP 또는 SQLD가 가장 탁월한 선택입니다. 목표를 잘 선택하셨어요! 열공하시길!)

공부 기간 : 2주 기준으로 학습 계획 짜기

우선, 전공자라할지라도 개개인의 백그라운드가 다를 것이기 때문에 이 게시글에서 제안하는 공부 기간은 절대적인 것은 아닙니다. 우선, 제 기준으로는 1주일 정도의 시간만 사용했고 총 20시간 이내로 공부했습니다. 응시 당시 주변 선후배들(학부, 대학원)의 이야기를 떠올려보면, 길어도 2주이내였던 기억이 납니다. 결론적으로는, 본인이 백그라운드가 부족하다면 2주 이상, 그렇지 않다면 이내로 학습 계획을 짜보는 것이 좋겠습니다.

참고로 필자가 뭐 대단한 학교를 졸업한 사람도 아닙니다. 혹시 이 사람 엄청 좋은 학교(예컨대 설포카연고서성한+@) 나온 게 아닐까? 생각하실 필요는 없습니다. 저는 동국대 나왔거든요. 이 또한 사람마다 기준을 달리 갖고 계실 수 있는데, 제 기준으로는 그냥 서울에 있는 학교를 졸업한 수준이니까 참고해보세요. 그냥 이 시험이 난이도가 그냥 그렇습니다. 전공자에게 그렇게 많은 학습량을 요구하지는 않는 편이라고 봅니다.

공부 방법 : 민트책, 카페 활용, 2-3-1과목 순, 2과목 과락주의보

네, 그러면 전공자는 공부 방법을 어떻게 가져가야 하는가? 여기서부터가 이 글의 가장 중요한 파트입니다.

교재 : 민트책을 추천합니다

우선 교재는 1권이면 충분합니다. 책을 고르는 방법? 우선 가장 유명한 책으로는 데이터에듀, 윤종식 저자의 '2022 ADsP 데이터 분석 준전문가'가 있습니다. 바로 이 게시글 최상단 이미지의 민트색 책이죠.

아래에서 설명드리겠지만 ADsP 자격 시험을 준비하는 사람들에게 가장 유명하고 유용한 네이버 카페로는 '데이터 전문가 포럼'이 있습니다. 이 카페에서 '민트책' 이라고 불리는 책이 바로 이 책입니다.

이 게시글은 책, 네이버 카페 홍보를 목적으로 하지 않습니다. 뒷 광고도 아닙니다! 그냥 주변을 둘러보니 이 책을 가장 많이 쓰더라는 경험에 근거한 추천입니다. 물론, 사람에 따라 이 책이 본인에게 잘 맞지 않을 수는 있습니다. 시간이 허락한다면, 꼭 서점에 한번 들러 여러 책들을 직접 확인해보는 게 물론 가장 좋겠습니다.

(덧붙여 아주 아주 개인적인 의견이지만, 본인이 만약 ADsP 취득 후 곧바로 ADP에 응시할 계획이 아니라면, 또는 단기 합격이 목표인 전공자라면 한국데이터산업진흥원이 직접 출판한 '데이터 분석 전문가 가이드'는 필요하지 않습니다. 이 책은 무겁고, 무려 50,000원!으로 비싸고, ADsP 응시가 목적이라면 지나치게 방대합니다.)

데이터 전문가 포럼 : 가입과 활용을 추천합니다

https://cafe.naver.com/sqlpd

데이터 전문가 포럼 (빅데이터분석기사... : 네이버 카페

빅데이터분석기사, ADP, ADsP, SQLP, SQLD, DAP, DAsP, 자격증 취득 등 데이터 전문가 커뮤니티입니다.

자, 민트책 구매 준비 전후로 이제 위에서 언급한 네이버 카페에 가입합니다. 이 곳은 생각보다도 훨씬 건강한 커뮤니티이며 여러 QnA를 진행할 수 있으며, 양질의 자료를 많이 보유하고 있습니다. 또, 스터디가 필요한 분은 카페에서 공식적으로 진행하는 스터디에 참여할 수도 있습니다. 그리고 독자께서 ADsP를 시작으로 데이터 관련 자격증을 지속해서 취득할 계획이라고 해도 이 카페는 언제나 도움이 될 것 같습니다. 경험적으로요.

인강을 고민한다면 : 글쎄요?

그 다음으로 인강을 고려해보시는 분들이 있을 것 같습니다...만, 이 글의 타겟 독자께서는 전공자잖아요? 위에서 언급했지만, 전공자에게는 그렇게 많은 양의 학습량을 요구하지 않는 자격시험입니다. 인강은 비추천합니다. 인강 결제할 돈으로 떡볶이, 돈까스나 한번 더 사먹으시길 바랍니다.

과목별 공부순서 : ★2과목 과락에 반드시 주의★

2과목(데이터 분석 기획) → 3과목(데이터 분석) → 1과목(데이터 이해) 순으로 학습하길 추천합니다. 전공자의 경우 이 중 과락을 조심해야하는 과목은 2과목이고, 가장 꼼꼼히 공부해야하는 것도 2과목이라고 생각합니다.

2과목의 경우, 3과목과 개념적으로 연결된 부분이 많기 때문입니다. 또한 제목이 '데이터 분석 기획'이라서 마치 전공자라면 어느정도 백그라운드를 갖고 있을 것만 같은 착각을 주는 제목인데, 그 내용을 살펴보면 상당히 데이터 분석 컨설팅 도메인의 지식을 요약한 것에 가까워서 기술경영 또는 컨설팅 관련 백그라운드가 없는 분이라면 생각보다 외워야 할 것이 많을 것으로 생각됩니다.

구글에 "ADsP 과락"이라고 검색해보면, 1과목의 경우도 과락을 제법 하는 편인 것 같습니다. 하지만, 1과목은 IT 상식에 가까운 문제가 출제되는 편이기도 하거니와 종종 문제 은행에 없는 문제를 출제하는 경우도 많아서, 만족스럽게 대비하려면 책의 부록에 있는 내용까지 꼼꼼히 볼 필요가 있습니다. 제 생각에는 기본적인 과목 공부는 진행하되, 이 시험을 준비하는 분이라면 데이터분석가 또는 데이터 사이언티스트가 목표인 분일 것이라 여겨지므로, 차라리 빅데이터 산업 내 이슈에는 무엇이 있는지 뉴스 기사들을 읽어보는 게 나을 수도 있겠습니다.

혹은, 정말 불안하다면 최근에 알게 된 유튜브 채널인데 https://www.youtube.com/c/EduAtoZPython 해당 채널을 참고해서 1, 2과목을 준비해보는 것이 좋겠습니다.

과목별 기초 공부가 가볍게 끝났다면, 아시죠? 이제 그냥 문제은행 열심히 푸시면 됩니다.

결론 :

● ADsP 자격증! 전공자고, 취준생이면 그냥 따자.
● 공기업/금융권 취준생에겐 메리트가 있긴 있더라.
● 요구되는 학습량 많지 않다.
● 2주 기준으로 학습계획 세우자.
● 교재는 민트책, 네이버카페(데이터 전문가 포럼) 활용하자.
● 2 → 3 → 1 과목 순으로 공부하자.
● 그러나, 2과목 과락에 주의하자. 방심 금물!

[Data Science 도서리뷰/Clean Code] 1. 깨끗한 코드 : 코딩이란? 그리고 깨끗한 코드란?

진대현 — Thu, 8 Dec 2022 20:52:35 +0900

클린코드, 로버트 C. 마틴, 2013

근래 내게 가장 도전적인 주제가 두 가지 있다면, 하나는 Scala라는 (나에게만큼은)새로운 언어이고 다른 하나는 Scala로 '더럽게' 쓰여진 레거시 코드들을 하나 하나 리팩토링 하는 것이다.

[데이터과학 도서/Clean Code] 카테고리는 이러한 도전을 성공적으로 실현하기 위해 컴퓨터공학과 학생들, 그리고 수많은 프로그래머들의 바이블이라고 불리는, 로버트 C. 마틴의 저서 '클린코드'를 최소한 1회독이라도 마치기 위해 작성하기 시작했다(그러므로, 이 카테고리는 연구/필기노트에 가깝다).

우선, 가능하면 이 '철학서'에 가까운 도서의 겉 껍질이라도 한번은 핥아봐야 하기 때문에 2023년 1월 말까지 1회독을 목표로 도서 리뷰 겸 공부 노트를 작성해나가도록 한다.

이 책은 세 부분으로 나뉜다.: (1) 깨끗한 코드를 작성하는 원칙, 패턴, 실기의 설명, (2) 사례 연구 : 더러운 코드를 깨끗한 코드로 고치기, (3) 사례 연구를 만들며 수집한 '냄새'와 '휴리스틱'의 열거. 본 게시글은 (1)의 첫 장인 1. 깨끗한 코드에 대한 정리와 리뷰이다.

1. 깨끗한 코드

코드가 존재하리라 : 코딩이란 뭘까?

내가 처음 프로그래밍 언어다운 언어를 접하게 된 것은 군복학 후 학부 교수님 연구실에 인턴으로 들어가게 되어, 연구실 일을 하려면 "Java를 알아야만 해서"였다. 그 전까지는 코딩 비슷한 것이라고는, 정보시스템 분석 및 설계와 같은 전공기초 과목에서 SQL을 다뤄본 것이 전부이다. 지금도 결코 잘 다루는 편은 아니었지만, 그 당시 SQL에 엄청난 젬병이었던 나는 프로그래밍 자체에 '어렵고 하기 싫다'는 편견이 있었다(SQL이 프로그래밍 언어인가 아닌가와 같은 영양가 없는 논의는 차치하자).

그렇다보니, Java를 공부하긴 했지만 → 연구실 최약체로서 교수님께 어떻게든 해내라는 압박만 엄청나게 받고 → 정작 실질적으로 뭔가를 직접 개발하는 바 없이 → 기껏 설계만, 그림만 그리다가 → 그렇게 내 연구실 인턴 생활은 쫑이 났다. 현재에 이르러, 정말 뜻밖에 온갖 개발 언어를 요구받는 나로서는 대단히 아쉬운 대목이다. 지금도 종종 그때 내게 부족했던 것은 뭘까? 하는 생각을 하던 차에 이 책의 서론은 내게 강한 어조로 말을 건다.

ㅡ "코드가 존재하리라." ㅡ

이 문장을 읽고, 나는 생각했다. '아, 나는 코딩이 뭔지 정의해본적 조차 없구나.' 라고.

이 책을 읽기 전까지의 나에게, 누군가 코딩이 대체 뭐하는거냐?고 묻는다면, 나는 그저 뭔가를 개발하는 데에 필요한 도구라고 밖에는 대답하지 못했을 것이다. 프로그래밍, 그러니까 개발자가 하는 개발이라는 행위에 대해 너무 추상적으로 정의하고 있었던 듯 하다. 코딩이란 행위가 무슨 지니의 요술램프를 문지르거나 요술봉을 휘두르는 행위도 아닌데 말이다.

이 책에서 코드는, '요구사항을 표현하는 언어' 임을 명심하라고 권한다. 그러니까, 코드는 추상적인 것을 정확히 명시하는 도구이고, 어느날 뚱딴지 같이 '비정형적인 수학'이 등장하는 세기말적, 디스토피아적 세계관이 찾아오지 않는 한 코드는 항상 존재할 것임을 말한다.

'요구사항을 표현하는 언어'라니. '뭔가를 개발하는 데에 쓰는 도구' 라는 내 조잡한 정의와 엇비슷해 보이지만, 이 두 정의는 '인간의 행위'가 내포되었는가, 그렇지 못한가에서 큰 차이를 보인다. 나는 코드를 도구로서만 인지하고 있었던 데 반하여, 이 책이 제안하는 코드의 정의는 '도구로서가 아니라 행위로서의 정의'에 가깝기 때문이다.

아마도, 내가 프로그래밍, 코딩을 어렵게만 생각해왔던 것은 이러한 차이를 알지 못했기 때문인 듯하다. 나는 이 도구를 들고 아무런 행위를 하지 않았다. 동적 정의가 아닌 정적 정의로 프로그래밍을 받아들였기 때문에.

나쁜 코드 : 그리고 그에 따른 댓가

이 책의 제목이 '클린 코드'임을 떠올려보았을 때, 그렇다면 깨끗한 코드란 뭘까? 하는 생각에 빠지게 된다. 음, 사실 난 깨끗한 코드까지는 몰라도 더러운 코드가 뭔지는 경험적으로 알고 있다. :

함수 이름을 용도를 알 수 없게 짓는다던가 / 혼자만 알아보게끔 짓는다던가 / 아무 뜻도 없이 A1, A2, C1, B4 처럼 짓는다던가 / 전에 만들어둔 코드가 분명 있는데 같은 거 중복으로 만들어둔다던가 / 아무리 쳐다봐도 이게 대체 무슨 용도로 개발한건지 못알아보게 짜놨다던가, 등등. 대체로, 이름 짓기만큼 어려운 일이 없는 듯 하다.

그래, 경험적으로 이 코드들은 더럽기도 더럽고, 나한테 만큼은 '나쁜 코드'이다. 이 나쁜 코드들은 왜 나쁜가? 그에 대한 답은 많겠지만, 이 책의 추천사에서 나온 용어인 TPM(Total Productive Management)의 관점에서 보았을 때엔 5S(정리, 정돈, 청소, 청결, 그리고 이 4가지의 생활화)가 잘 지켜지지 않아서이다.

그러니까 뭐, 코드가 더럽단 얘기다. "더럽고, 세세하게 관리되지 못했다" 그런 말이다.

품질경영을 공부해본 경험에 비추어 보았을 때, 이 책이 몇 십년이나 지난, 케케묵은 5S를 굳이 굳이 들고와 이 책을 시작한 이유에 대해 생각해보면, 아마도 깨끗함을 '습관적으로' 관리하라는 말을 하고 싶었기 때문이 아닐까 싶다. 5S 중에 가장 중요한 건, 4S를 유지하는 습관화니까. 책은 나쁜 코드를 정의하며 "르블랑의 법칙"을 인용한다 : 나중은 결코 오지 않는다. 그러니까, 지금부터 습관을 가져라.

이 장에서 저자가 나쁜 코드의 댓가로 예시한 시나리오는, 정말이지 내가 회사 생활을 하면서 피하고 싶은 결말을 갖는다. :

나쁜 코드가 쌓일수록 팀 생산성은 떨어진다!

나쁜 코드가 쌓일수록 팀 생산성은 떨어진다. 그러다가 마침내 0에 근접한다. 생산성이 떨어지면 관리층은 나름대로 복구를 시도한다. 어떻게? 생산성을 증가시키려는 희망을 품고 프로젝트에 인력을 추가로 투입한다. 하지만 새 인력은 시스템 설계에 대한 조예가 깊지 않다. (...) 결국은 나쁜 코드를 더 많이 양산한다.

물론, 아직까지 '나쁜 코드를 더 많이 양산'하는 단계에 이르는 배드 엔딩을 맞이해보지는 않았다. 하지만, 대체로 과거의 인력이 개발한 것에 가까운 레거시 코드를, 현재의 우리가 지속적으로 관리하기 좋게끔, '깨끗한 코드로 만드는 과정' 중에 이 배드 엔딩을 맞이 하지 않으려면 우리 팀이 지켜야할 것들이 많고, 새롭게 정해야할 규칙들이 많을 것이다.

예를 들어 거버넌스라던지, 코드 컨벤션이라던지, Git과 같은 형상관리도구를 어떻게 활용할 것인가 하는 브랜칭 전략이라던지 말이다(이 지면은 추후에 관련 내용을 포스팅하고 새로 작성될 포스트를 참조하기 위해 비워둔다).

하지만, 결국 이런 나쁜 코드의 댓가를 받게 되는 근본적인 원인은 개발자가 개발자로서의 태도를 지키지 못했기 때문임을 잊지 말자. "아니, 잠깐만요! 상사가 시키는 대로 하지 않으면 짤린다구요!" 책의 예시처럼 뭐, 나도 비슷한 생각을 잠깐 해보긴 했다. 물론 책에게 곧바로 반박당했지만. :

"니가 의사라고 치자. 환자가 본인 수술 전에 손 씻지 말아달라고 하면 안 씻고 수술할래?"

그래, 전문가로서의 태도와 품위를 지키자, 우리.

깨끗한 코드란? : 고수들의 대답

마지막으로, 이 책이 소개한 "깨끗한 코드"에 대한 고수들의 대답을 정리해보면서 이 게시글을 마친다. 사족은 달지 않으려 한다. :

저명 프로그래머 이름	'깨끗한 코드'에 대한 정의 요약
비야네 스트롭스트룹, C++의 창시자	● 우아할 것 → 보기에 즐거울 것 ● 효율적일 것 ● 유지 보수를 위해 의존성은 최소화할 것 ● 명백한 전략에 의거해 오류 처리를 철저히 할 것 ● 깨끗한 코드는 한 가지를 잘한다
그래디 부치	● 명쾌한 추상화 :설계자의 의도를 숨기지 않고, 단순하게, 가독성 있게 표현할 것
데이브 토마스, OTI 창립자	● 문학적일 것 : 작성자가 아니어도 읽기 쉽고 고치기 쉬운 것 ● (단위, 인수)테스트 케이스가 존재하는 코드일 것 ● 큰 코드보다 작은 코드에 가치를 둘 것(작을수록 좋다)
마이클 페더스	● '주의 깊게 짰다'는 느낌을 주는 것
론 제프리스	● 중복을 피할 것 ● 한 기능만 수행할 것 ● 제대로 표현할 것 ● 작게 추상화할 것(초반부터 간단한 추상화 고려하기)
워드 커닝햄	● 짐작 가능할 것

[도서리뷰 단편선] 기획의 정석 - 질문의 퀄리티를 높이는 자문자답

진대현 — Sun, 4 Dec 2022 20:31:50 +0900

기획의 정석, 박신영 지음

"기획의 정석(특별판), 박신영, 세종서적, 2022"을 읽고, 나를 중심으로 일어나는 안팎 모두의 질문들을 생각하며.

근래 들어, 나의 독서 습관은 매우 치우쳐져 있었다. 대체로 나의 '읽기' 대상은 관심 분야의 새로운 SOTA(State Of The Arts ; 최신기술) 또는 목적하는 문제의 정의가 유사한 논문이거나, 업무 중 직면한 문제 해결에 도움되는 기술철학, 기술서적들이었다.

이러한 치우침은 기술자로서의 내 모습에 조금 더 빨리 적응하기 위한 자구책이기도 했으나, 사실 그보다는 '잡생각이 많은' 스스로를 믿지 않았기 때문이다. 정확히는 '쓸데없는 감상에 젖는 내 모습이 싫어서'가 더욱 큰 이유였다. 하지만, 이 책을 통해 잡생각 컨트롤에 약간의 단서를 발견한 듯 하여 이 독서록을 남긴다.

독서의 동기 : 화담숲에서의 담화, 내 생각이 뻗어가는 방식에 대한 반성.

이성복의 시론 시리즈 중 하나인 '무한화서'

화담숲에 놀러간 얼마전 20대 전체를 함께한 여자친구가 내게 '자기는 가장 좋아하는 문장이 뭐야?' 라는 질문을 했다. 나를 가장 잘 아는 사람 중 하나인 그녀는 내게는 뜻밖의 질문을 종종 하는 편인데, 이러한 뜻밖의 질문들에서 나는 대체로 내가 정의하지 못했던 나를 발견하는 경우가 많았다. '가장 좋아하는 문장' 질문도 이러한 유형의 질문이었는데, 질문을 들은 후 곰곰이 고민한 내게 떠오른 문장은 이성복의 시론집 '무한화서'에서의 무한화서에 대한 정의였다. :

" '화서(花序)'란 꽃이 줄기에 달리는 방식을 가리켜요. 순우리말로 '꽃차례'라고 하는데, 여기에는 두 가지가 있어요. 성장에 제한이 없는 '무한화서'는 밑에서 위로, 밖에서 속으로 피는 구심점을 염두에 둔 표현으로, 구체에서 추상으로, 비천한 데서 거룩한 데로 나아가는 시는 '무한화서'가 아닐까 해요. 언어로 표현할 수 없는 것을 표현하려다 끝없이 실패하는 형식이니까요." - 이성복 시론 <무한화서> 중에서.

내가 이 문장을 떠올린 까닭은, 내가 한 때 문청(文靑)의 꿈을 갖고 글과 시의 이론을 탐했기 때문일 수도 있겠으나 그에 덧붙여 나의 생각이 뻗어나가는 방식이 이와 유사했기 때문으로부터 발견한 동질감 때문이기도 했다.

그러나, 동질한 것이라고 무작정 덮어두고 사랑할 순 없는 것이다. 이 문장을 나의 사고 방식으로 바라보면 사랑할 수 있는 것이지만, 직업인으로서 목표하는 이지적 삶의 관점에서는 나에게 큰 단점이 되는 경계의 대상이기도 하기 때문이다. 나는 그래서, 이 문장을 가장 좋아한다고 그녀에게 답했지만 속으로는 '동시에 미워하는 문장'이라고 생각했다. 애증하는 문장이라고 정리해본다.

좀 더 정리해보면, 나는 잡생각이 너무 많기 때문에 상념에 곧잘 잠기는 사람인지라 스스로를 잘 모른다. 잘 모르기 때문에, 정의되지 않기 때문에, 그 상념들을 경계하는 것이고 - 결과적으로는 '어떻게 하면 생각을 잘 정리해서 나에게 이롭게 쓸 수 있을까?' 에 대한 도구에 목말라있다. '뭔가 단서가 있지 않을까?' 이것이 이 책을 읽기 시작하게 된 동기였다. 내 생각을 정리해보고 싶어서, 더 나아가서 그게 나에게 실익이 될 수 있도록 기획하기 위하여.

책의 내용 : 기획은, 상대방의 입장을 이해하는 것으로부터.

이 책의 내용을 요약하면, "모든 기획의 시작은 상대방의 입장을 이해하는 것으로부터."라고 할 수 있다. 저자가 소개한 기획을 위한 좋은 습관 10가지 모두가, 기획의 상대방을 이해하고 그 니즈에 맞는 무언가를 제안하기 위한 도구이다.

상대방의 '구시렁'으로부터 WHY를 찾고 → 5 Why, Logic tree, SOM 등을 통해 숨겨진 WHY SO를 찾아본 뒤 → 상대방의 니즈를 충족할 나의 WHAT을 제시한 뒤 → WHAT ELSE 비교를 통해 내 것을 강조하여 협상력을 키우고 → '정말로 어떻게 해낼 것인가'에 해당하는 HOW TO를 제안 → 실질적인 기대효과는 무엇인가 WHAT IF 를 증명함으로써 성공적인 기획을 이끌어 낸다는 것이 이 책이 제안하는 기획 절차의 요약이다.

이 책의 제안으로부터, 1차적으로 얻은 직접적인 이익은 '쉽게 말하기에 공을 들이자'는 교훈과 반성이었다. 다음은 그러한 교훈과 반성의 배경이다. :

얼마전, 나는 회사에서 2023년도 사업계획서 작성을 맡았다. 계획서의 초안, 흔히 말하는 '꼭지'들은 우리팀의 차석님이 정리해주었고, 나의 역할은 이렇게 준비된 꼭지(초안)들을 좀 더 구체적으로, 좀 더 풍부하게 만들기 위해 케이스 스터디를 하고, 이를 토대로 계획서를 마무리하여 팀에 부임한지 얼마되지 않은 팀장님께 브리핑 후 의사결정을 얻어내는 것이었다.

나는 내년 한 해의 사업계획서를 나같은 초짜가 맡아도 되는가에 대해 잠시 부담스러웠으나, 대학원에서 지도교수님 지시를 받아 연구계획서에 필요한 케이스 스터디를 하던 때와 뭐 그렇게 다를 게 있겠냐는 생각으로 스터디에 임했다. 그러다 보니, 너무 대학원생스러운 - 너무 아카데믹한 - 보고서가 완성되었으며, 그 결과 계획서를 같이 작성한 팀원으로부터 너무 구체적이고 세밀하지 않냐는 평가(그러니까, 공수가 너무 많이 들어갔단 이야기)를 받게 되었다. 하지만, 이때에도 역시 관성에 몸을 맡긴 나는 다른 이의 평가를 통해 내용을 반성해보기 보다는, '조금 지엽적이더라도 최대한 자세히 써두어야 좋지 않겠냐'는 생각으로 해당 계획서를 팀장님에게 보고 했다.

결과적으로, 작성된 사업계획서는 팀장님께 좋은 평가("대현님은 너무 능숙해서 신입이 아니라 경력직인 줄 알았어요.")를 듣고 OK를 받긴 했으나, 그보다 윗 선의 상사분께 팀장님을 통해 보고 되었을 때엔 개별 내용에 대한, 조금 더 상세한 질문을 받게 되었다. 작성자인 나로써는, 내가 정리한 내용이 "이해하기 너무 어렵다."는 평가를 받았다고 생각했다.

'어디서부터 어디까지 말씀드려야 할것인가?, 어떤 방식으로, 어떤 레벨로 말씀드려야 할 것인가'를 좀 더 고민했어야 했다.

그래도 우선 잘 했던 점을 톺아보면, 부임한지 얼마 되지 않은 팀장님을 위해 백그라운드를 최대한 충분히 설명드린 것, 여러 선택지의 존재를 보이고 단순화를 위한 의사결정을 요청드린 것이 있긴 하다.

하지만, 우리팀의 최종 의사결정권자의 "한번에 이해하기 어렵다." 는 반응을 다시한번 씹어보면, "장황한데, 그래서 뭘 하겠다는 건지", "어떤 이득이 있는지", "결론이 뭔지" 잘 모르겠다는 말이 된다. 즉, 내가 쓴 사업계획서는 최대한 구체적으로 작성되어 있어 실무자 수준에서는 만족할 수 있겠으나, 의사결정권자의 입장에선 한 눈에 들어오는 계획서는 아니었던 것이다.

나는 이제 이 책도 읽었고, 이런 반성도 해봤으니, 만약 다시 사업계획서를 작성할 기회가 온다면 의사결정권자의 입장에서 어떻게 하면 '결론을 잘 보일 수 있는지'를 고민할 것이다. 더 나아가 우선, 실무 속에서 우리가 데이터로 해먹을 수 있는게 뭔지, 그리고 그걸 왜 해야하는지를 늘상 고민해볼 필요가 있다. 상대방의 Painpoint가 뭐고, 그에 따른 Solution과 Supplement가 뭔지를 추론해서 제안하는 것, 그것이 이 책에서 제시해주는 기획의 방향성이니.

이러한 '기획'의 절차는 데이터분석가에게 요구되는 '가설설정과 분석을 통한 증명'과 그 궤가 매우 닮아있기 때문에 나는 이 책에 아주 쉽게 동의하게 된 것일지도 모르겠다.

이 책을 통해 다른 독자분들도 방법론을 실제 본인의 삶에 적용해보고 자성해보면 어떨까싶다. 기획이 없이 발생하는 비즈니스는 없지 않을까? 괜히 한 분야의 베스트셀러가 된 것은 아니라고 생각한다.

후기 : '생각 가지치기' - 이 책을 읽음으로써 얻은 2차적 이익.

이 책이 1차적으로 내게 선사한 가르침을 지나서, 다시금 내가 이 책을 읽게 되었던 동기를 생각해보았다. :

'나는 내 생각을 통제하고 싶어. 어떨 땐 생각 자체를 멈추고 싶을때도 많으니까.

아니, 우선 일단 내가 어떤 생각을 하려고 하는건지, 결과적으론 내가 뭘 원하는지를 빨리 알아차리고 싶어.'

근본적으로, 나는 나의 삶이 그래왔듯, 내가 가장 좋아하는 문장이 그러하듯, 결국 태생적으로 끝없이 뻗어나가는 사람으로 살다 갈 것이다. 그간 나는 그러한 나의 천성을 견제하기 위해 감상에 빠지기보다는 실용적이고, 실천적인 것들을 읽으며 눈을 돌려왔다. 그런데, 이 책의 내용에서 '상대방'을 '나 자신'으로만 바꿔보면, 이러한 단순회피에 비하여 더 나은 결론을 얻을 수 있으리란 기회를 엿보게 됨을 깨달았다.

2018년 6월, '파란' 전시회에 걸었던 작품 중 '꽃차례', 자작시.

그러니까, 일단 나는 나를 모르는 데에서 시작하는 많은 문제를 갖고 있는 사람임을 확인했다. 되짚어보니, 내가 예전에 썼던 글만 보아도, 나의 이런 마음은 여지없이 드러난다. 다만, 나는 그저 회피하고 있었을 뿐, 그저 내버려둔 채 나 자신의 생각을 정리해본적이 없었다. 나는 생각의 가지를 '쓸데없이 많이' 뻗어가는 사람이고, 내 생각의 가지는 글을 씀으로써 정리되곤 했다. 해결 방법을 알면서도 나의 문제를 회피하고만 있었던 것을 발견한 것이다.

스스로를 이따금 타인으로 느끼면서도, 나는 이 타인과 그간 어떤 교섭도 협상도 하지 않았다. 그러한 문제점을 이 책이 제안한 '상대방 입장 이해하기'로부터 알게 된 것이고, 스스로에겐 이미 그에 대한 해결책이 있음을 발견했으므로 이제 이 기획을 성공시키는 일만 남았다.

이제는 내가 시인의 꿈을 꾸던 때의 나를 미워하지 않아도 될 것 같다. 삶의 경영에 있어 가장 효과적인 기획 방법론을 배웠기 때문이다. 이제는 '나'라는 사회적 타인들을 위해, 적절한 기획안을 쓸 수 있을 것 같다. 이 가설이 참이라면, 나는 곧 올바른 증명을 해낼 수 있을 것이다.

[자기계발/자격증] 유통관리사 2급 독학 2주완성, 공부량, 공부방법

진대현 — Sun, 4 Dec 2022 00:07:40 +0900

SD에듀 유통관리사 2급 단기완성

나는 지난 2022년 11월 19일에 유통관리사 2급 자격시험에 도전했고, 가채점 결과 꽤나 고득점(평균 80점대)으로 합격을 예상해볼 수 있었다. 물론 합격자 발표는 12월 20일 예정이므로 설레발일 수 있으나, 시간이 지나면 공부 노하우 등을 잊을 수 있으니 기록 차원에서 이 글을 작성한다.

기초 스펙

보통 이러한 자격시험을 준비하는 분들이 가장 궁금해하는 것은 합격 후기를 남긴 사람의 기초 스펙이 본인과 유사한 환경에 있는가를 궁금해하기 때문에 나의 이력을 남긴다.

우선, 나는 유통 또는 물류에 있어서는 전공자도 비전공자도 아니다. 학부에서 산업공학을 전공하면서, 애매하지만 겉핥기로 생산, 유통 관련 전공 수업을 듣기는 하였지만 심도있게 다룬 수준은 아니기 때문이다. 이건 아마도 산업공학을 전공한 사람이라면 공감할테지만 아무래도 산공 자체가 여러 분야를 찍먹해보는 경우가 많아서, 이번 경우에도 그런 경우에 해당한다고 생각한다. 유사하게 경영학 전공한 사람들도 이런 경우가 많은 것을 보았다.

추가로 순전히 '내 생각이지만' 내가 이미 취득한 자격증 중 유통관리사 2급과 관련된 자격사항으로는 품질경영기사, 사회조사분석사 2급, 빅데이터분석기사 정도를 꼽을 수 있을것 같다. 품질경영기사의 시험과목 중 생산시스템, 품질경영 등의 과목이 유관한 듯 하고 사회조사분석사에서 다루는 조사방법론 등이 유통관리사의 여러 과목에 골고루 흩뿌려져 있다는 감상을 받았다. 특히, 빅데이터분석기사의 경우 유통관리사 2급의 4과목에 매우 밀접했다.

그리고, 현재는 제법 규모가 있는 e-commerce 기업에 다니고 있고 갓 1년차이며, 데이터 분석가이며 머신러닝 엔지니어이다. 딱 뭐 시험 공부에 도움이 될 정도의 경력은 아니지만 귀동냥을 아주 야아아앝게 한 사람이라 생각해주면 좋겠다.

시험의 난이도

내가 응시한 2022년도 3회차 유통관리사 2급 시험은 연간 난이도 조정의 실패로 다소간 어렵게 출제되었다는 것이 시험을 준비하는 네이버 카페 등의 일반적인 반응이었다. 하지만, 개인적으로 이미 여러 유관 자격 공부를 진행한 백그라운드가 있기도 했고 순수하게 2주간 약 40여시간의 학습 시간을 가져간 나로서는 그렇게까지 고난도의 시험은 아니었다고 생각한다. 시험의 난이도 자체가 높았다기보다는, 주관처의 난이도 조절 실패로 '이의 제기를 할만한 문제들이 많은' 시험이었다고 생각한다. 실제로, 여러 사람들의 민원으로 무려 3문제나 중복 답안이 인정되었으니 더 이상 말을 할 필요가 있을까 싶다.

공부 방법, 공부 기간

우선 공부에 사용된 교재는 총 2권이다. 둘 다 SD에듀(시대고시)의 책인데 각각 "유통관리사 2급 단기완성", "유통관리사 2급 기출문제 해설"이다. 교재 값은 오늘자(2022년 12월 3일) 교보문고 기준으로 10% 할인되어 각각 22,500원과 21,600원이다. 개인적으로 시험문제 자체가 기존 문제은행에서 출제되지 않는 편으로 변화하고 있다고 생각하기 때문에(특히 4과목이 그러하고 원성이 높다), 교재는 중고 서적을 구매하는 것보다는 가장 최근의 것을 구매하는 것이 좋다고 생각한다.

시험공부 기간은 11월 6일부터 11월 18일까지 총 2주 가량을 사용했고 이 중 4일은 약 6시간을, 나머지 기간 동안은 퇴근하고 2시간 가량을 공부에 투자했으니 약 40여시간을 사용한 듯 하다.

(1) 첫째주 평일 : 11월 6일 ~ 11월 11일

첫 날엔 전체 과목이 어떤 내용을 다루는 지 마치 소설책읽듯 단기완성 책을 약 2시간 가량 살펴보기만 하고, 6일간 하루 2시간씩 어느 정도의 분량을 읽어야 전체 네 과목을 모두 살펴볼 수 있을지를 점검했다. 둘째날부터 마지막 날까지는 하루에 2시간씩 단기완성 책의 각 유형별 문제를 눈으로만 보며 어떤 유형의 문제가 출제되는지 확인하고, 기출된 문제에서 요구하는 유형별 개념만 읽었다.

2주는 매우 짧은 기간이며, 자격 시험의 특성상 모든 개념을 외우려고 하기 보다는 외워야만 하는 개념이 무엇인지 점검하는 게 효율적이므로 필기는 따로 하지 않았다. 그저 샤프를 들고 2시간 이내에 기출 문제를 살펴본 뒤 외워야만 하는 개념을 선별하여 줄을 긋고, 체크하는 작업과 대략적인 흐름을 읽어보는 것만 진행했다. 여기까지 각 과목의 회독수는 1회독이 되었다. 물론 개념이 머릿속에 정리된 상태는 아니었다.

(2) 첫째주 주말 : 11월 12일 ~ 11월 13일

하루 6시간을 공부시간으로 잡아두고, 줄을 긋던 샤프를 내려두고 빨간펜을 들었다. 평일에 줄을 그어둔 내용들 중에서 '잘 이해가 가지않거나, 나의 상식 선에서 외워지지 않는 것들' 위주로만 개념 유형을 체크했다. 필기는 역시 하지 않았다. 전체 과목 중 줄을 친 유형들이 2회독이 되었다.

(3) 둘째주 퇴근 후 평일 : 11월 14일 ~ 11월 16일

하루 2시간을 공부시간으로 잡아두고, 유통관리사 2급 기출문제 해설 책을 꺼냈다. 이 책은 2016년 1회차 ~ 2021년도 3회차의 기출문제와 문제 별 해설을 담은 책인데 시간 상 전체 문제를 다 풀 수는 없으리란 판단을 했다. 그래서 가장 최근 년도인 2021년은 시험 전날 풀기로 하고, 14일부터 16일까지 사흘 동안 2018년도 1회차부터 2020년 3회차까지를 과목별로 몰아서 풀기로 했다. 예를 들어 14일에는 2018년 1회차~2020년 3회차 까지의 각 1과목만을 풀고, 그 다음날은 2과목을, 그 다음날은 3과목을 푸는 방법이다.

기출 문제를 직접 푼 것은 처음이었기 때문에 예상보다는 시간이 더 들어 하루 3시간 가량 사용한 것 같고, 계획한 만큼의 공부량을 채우지는 못했다. 사흘간 1~3 과목의 2018년 1회차 ~ 2020년 1회차 문제까지 풀어볼 수 있었다. (참고로, 4과목을 뒤로 미룬 이유는 개인적으로 4과목이 다루는 내용들이 지금 하고 있는 일과 매우 밀접하기 때문에 자신있었기 때문이다.)

(4) 둘째주 연차를 낸 평일 : 11월 17일 ~ 11월 18일

남은 이틀은 연차를 내고 하루 6시간을 공부시간으로 잡아두었다. 우선 첫날엔 1~3과목과 마찬가지로 4과목의 기출문제를 풀기 시작했으나, 2개 회차를 풀어보니 약 2~3개 가량만 틀리길래 풀이를 멈추었다. 전체 과목 중 가장 많은 오답이 나온 과목은 1, 2과목이었고 상대적으로 3, 4과목은 내 배경지식과 부합되는 것이 많았기 때문에 과락이 될 정도로 위험한 점수가 나오지는 않을 것으로 판단했다.

오답이 어떤 유형에 해당하는 지 확인하는 작업

예상보다 시간이 절약되었기 때문에 각 과목에 해당하는 오답들이 "유통관리사 2급 단기완성" 책에서 과목 별 유형 중 어떤 것에 해당하는 지 일일이 찾아 문제 옆에 아래와 같이 기입했다. 시간 집약적인 작업이지만 필기를 하는 등의 시간을 아꼈기 때문에 사용해도 되는 시간이고, 시험 전날 본인이 어떤 유형에 약한가를 판단하기 좋은 자료가 되기 때문에 공을 들였다. 이 작업을 하면서 대략 어떤 과목, 어떤 유형에서 무슨 내용을 다루는지 다시 한번 쯤 점검을 했다. 이러한 점검을 하며, 오답에 해당하는 유형들은 3회독이 되었다.

오답 유형 정리

그 뒤에 각 과목 별로 어떤 유형을 틀리는 지를 엑셀로 정리한 뒤 중복 제거를 하여 실질적으로 어떤 유형에 약한지를 위와 같이 확인했다.

다음날은 이 엑셀 표를 기준으로 약 3시간 가량은 개념정리를 하면서 아직 완전히 외우지 못한 수식, 개념들을 마지막으로 점검하면서 시험 당일 보기 편하도록 플래그를 달아두었다. 나머지 3시간 가량은 아직 풀지 않았던 2021년도 기출문제 1개 회차를 골라 풀고, 마지막으로 https://www.kinz.kr/subject/145098 에 들어가 해설이 아예 없는 상태의 2022년도 1회차 기출문제를 풀어보았다. 평균 70점대로 안정권이었다.

시험 결과

유관사 2급은 시험 종료 후 당일 1시 쯤 기출문제와 가답안지를 공개한다. 때문에, 수험표를 출력해가서 본인의 가답안을 작성해오는 것이 좋다. 그래야 한달이나 기다릴 필요 없이 당일 나의 합격을 대략적으로 점쳐 볼 수 있다. 내 가채점 결과는 다음과 같았다.

1과목 21/25 -> 84점
2과목 17/20 -> 85점
3과목 21/25 -> 85점
4과목 18/20 -> 90점

1, 2과목에 공을 들인 보람이 있는 결과였고 3, 4과목이 받쳐주어 다행이란 생각이 들었다.

공부 방법과 결과에 대한 내용은 이상으로 마친다.

사실 이 자격증이 취업에 직접적으로 도움을 주는지는 잘 모르겠다. 개구리 올챙이 적 기억 못하는 것이 아니라, 이 자격증을 들고 내가 취업 준비를 해본바가 없기 때문이다.

하지만, 현직자의 입장에서 - 특히, 도메인 널리지가 부족한 초짜의 입장에서 이 자격증 공부는 내게 분명히 도움이 되었다. 특히 머천다이저, SCM 등 유관 부서 소속의 동료들이 갖고 있을 법한 백그라운드를 핥아라도 봤다는 것이 그렇다. 생소했던 용어들을 '한번이라도 들어본' 수준으로 끌어올린 것만으로도 도움이 되었다고 생각한다. 또 한번의 보람찬 결과였다. 자격증 취득에 대해서는 할 말이 많은데 우선 이 글에서는 유통관리사 2급에 대해서만 다루고, 다음은 나의 자격증 공부 일대기를 정리해볼까 한다.