InFinity_Dev

Q : 기획자가 이런걸 왜 공부해요?

A : 기술에 대해서 알아야, 어디까지 되고 어디부터는 안되는지 알수 있습니다.
     기술에 대해서 알아야, 그 기술을 통해 사용자에게 가치를 전달 할 수 있는 최적의 UI/UX로 설계 할 수 있습니다.

쨋든 공부했으니 아까워서 정리해둡니다.
Pronto가 뭔지, NEC가 뭔지 적외선 신호 가지고 뭘 하라고 해서 머리 싸매고 있는 기획자든, 개발자든
또다른 그 누군가에게 제가 먼저 걸은 길이 도움이 되길 바랍니다.

IR 신호에서의 비트 인코딩 : Logical 0, Logical 1의 표현

IR 신호 프로토콜에서 논리 0과 1을 표현하는 방법에는 두가지 방법이 있다.

1. Variable Length Encoding (PWM / PDM 사용)

MARK(Hightime)상태와 SPACE(Lowtime)상태 둘중 하나의 시간을 고정한채로,
나머지 상태의 길이를 다르게 하여 논리 0과 논리 1을 표현한다.

본 포스팅에서 알아볼 NEC 프로토콜의경우 Carrier Frequency = 38Khz 일때를 기준, 약 21주기

즉, (1/ 38000 hz) * 21 ≈ 562.5 μs 를 Fixed time 길이로 고정하여

• 논리 0 : Fixed time 만큼의 "MARK" 이후 1배수 길이의 "SPACE" 가 따라오는 신호

• 논리 1 : Fixed time 만큼의 "MARK" 이후 3배수 길이의 "SPACE" 가 따라오는 신호

와 같이 정의한다.

즉, 신호가 있는 상태를 의미하는 "MARK"와 신호가 없는 상태를 의미하는 "SPACE" 상태를
하나의 쌍으로써 논리 정보비트를 결정하며, 논리 정보비트의 신호 길이는 달라질 수 있다.

또한, PWM 혹은 PDM 둘중 어떤 주파수 변조 방식을 사용하느냐에
따라 "MARK" 와 "SPACE" 둘중 어느 것을 Fixed time 으로 설정할지 다르다.

PDM 방식은 논리 정보 비트 표현을 위해 "MARK"를 Fixed time 길이로 고정하고,
"SPACE" 의 길이를 다르게 하는데에 반해

PWM 방식의 경우는 "SPACE"를 Fixed time 길이로 고정하고, "MARK"의 길이를 다르게 적용하여 논리 1,0을 표현한다.

NEC 프로토콜의 경우에는 PDM 주파수 변조 방식을 사용한다.

대부분의 IC 컨트롤러는 신호가 없는 "SPACE" 상태를 IR LED를 끔으로서 표현이 가능하지만,
특정 IC 컨트롤러에서는 "SPACE" 상태를 100% Duty Cycle (Fully illuminated) 로서 표현해야 하는 경우도 있다.

전자의 경우에는 PWM보다는 PDM 이나 Manchester Encoding을 사용하는 것이 전력효율에서 이득을 가지며
후자의 경우에는 Manchester Encoding을 사용하는 것이 전력효율에서 이득을 가질 것이다. 

2. Manchester Encoding

Variable Length Encoding과 마찬가지로 "MARK" 상태와 "SPACE" 상태를 가지지만
Manchester Encoding의 경우 "MARK" 와 "SPACE" 상태가 같은 Fixed time을 가진다.

즉, Manchester Encoding 에서의 논리 0과 1은 다음과 같이 표현된다.

NEC Protocol Message Frame Breakdown

NEC 프로토콜의 Carrier Frequency 라고 하는 기본 주파수는 38Khz이다. PDM(Pulse Density Modulation)을 사용한다.

NEC 프로토콜의경우 표준 Carrier Frequency = 38Khz 일때를 기준, 약 21주기
즉, (1/ 38000 hz) * 21 ≈ 562.5 μs 를 Fixed time 길이로 고정하여 "MARK" 상태의 단위 길이로 정한다.

Carrier Frequency의 경우 38Khz 가 표준이지만, 제조사에 따라 다른 경우가 있기에
캐리어 주파수에 따라 달라지는 "시간"으로 서술하기 보다는 Fixed time 의 길이를 가진 "MARK" 상태의
최소 단위길이를 1 Unit 이라고 설정하고 해당 단위 길이의 배수로 신호 길이를 서술하고자 한다.

0. 단위 신호 길이

Fixed time 만큼의 길이를 가진 "MARK" 의 단위 길이가 1 Unit 일때
38Khz를 기준으로 1 Unit 은 562.5 μs 의 신호 길이를 가진다.

논리 0

논리 0을 나타내는 신호의 길이는 1 Unit 길이의 "MARK"와 1 Unit 길이의 "SPACE" 신호로 이루어져 있으므로
총 2 Unit, 38Khz를 기준으로  562.5 μs  x 2 = 1.125ms 의 길이를 가진다.

논리 1

논리 1을 나타내는 신호의 길이는 1 Unit 길이의 "MARK"와 3 Unit 길이의 "SPACE" 신호로 이루어져 있으므로
총 4 Unit, 38Khz를 기준으로 562.5 μs x 4 = 2.25ms의 길이를 가진다.

이제 본격적으로 NEC 프로토콜에서 정의하는 메세지 구조에 대해 알아보자.

1. 데이터 메세지

1-1. Preamble (Header - Leading Pulse Burst)

송신시 메세지 첫 부분에 길게 보내는 신호.
수신측 장치를 깨우고, IR 수신 Gain 값을 캘리브레이션 할 수 있도록 하는 역할을 한다.

16 Unit 길이의 "MARK" 신호 + 8 Unit 길이의 "SPACE" 신호로 이루어져 있다.
38Khz를 기준으로 9ms의 "MARK" 이후 8 Unit 의 "SPACE" 로 인한 4.5ms 의 간격을 가진다.

1-2. Data (Payload) : 32bit (16bit Address + 8bit Command + 8bit Command in Reversed bit)

8 자리 HEX code 로 알려져 있는 데이터 영역이다.
대체로 NEC 코드값을 표현할때 이 부분만 8자리의 16진수 HEX Code로 기록한다.

ex) https://www.tastethecode.com/backing-up-ir-remote-codes-ir-receiver

Vol+ 키로 기록되어 있는 NEC 코드 : 0xF7087F80 을 4 자리씩 끊어서 보았을때

F708으로 기록된 Address 영역을 2진수로 표현하면
1111 0111 0000 1000 으로 앞 8 bit는 Address, 뒤 8 bit는 Address 의 Bit Inversed 를 표현한다.

7F80으로 기록된 Command 영역을 2진수로 표현하면
0111 1111 1000 0000 으로 앞 8 bit 는 볼륨 UP을 뜻하는 명령코드 | 뒤 8 bit는 Command 의 Bit Inversed 표현임을
알 수 있다.

이처럼 NEC 프로토콜에서 Data 영역은 총 32 bit.
8bit Address + 8bit Address in inversed bit + 8bit Command + 8bit Command in inversed bit 의 구조를 가진다.

이는 데이터 무결성을 확인하기 위함으로,
Address와 그 반전 비트, Command 와 그 반전 비트가 각각 쌍을 이루기에
Variable Length Encoding을 사용하는 NEC 프로토콜에서의 논리 1과 0의 길이는 다르나
비트 반전을 하여 한쌍씩 묶어두어 전체 Data 프레임에서 논리 1과 0의 개수는 동일해짐에 따라
데이터 메세지의 길이는 항상 일정하다.

38Khz를 기준으로

8bit Address 가 전부 논리 0일 경우 = 2 Unit x 8 = 16 Unit = 9ms
8bit Address Bit inverse 는 전부 논리 1 = 4 Unit x 8 = 32 Unit = 18ms

8bit Command 가 전부 논리 0일 경우 = 2 Unit x 8 = 16 Unit = 9ms
8bit Command Bit inverse 는 전부 논리 1 = 4 Unit x 8 = 32 Unit = 18ms

총합, (48 Unit + 48 Unit) = 96 Unit = (27ms + 27ms) = 54ms 의 길이를 가진다. 

단, 8bit Address, 즉 256개의 Address 영역이 모두 소진되어 고안된 NEC Extended 의 경우
8bit Address 의 비트반전 영역을 없애고 Address 영역에 통합하여 총 16bit Address 영역을 사용한다.

16 bit Address 영역의 길이는 제조사에게 부여된 Address 마다 다르고
Command 영역은 NEC Standard 와 마찬가지로 비트 반전을 통해 Data integrity를 체크 하기 때문에
Command 영역의 길이는 NEC Standard, NEC Extended 모두 27ms로 같다

이로 인해, NEC Extended 프로토콜에서 서로 다른 Address 정보를 가진 신호는 총 메세지 프레임 길이가 달라 질 수 있다.

1-3. End of Stream (Leadout Pulse Burst)

메세지 프레임의 끝에 스트림 종료를 알리는 신호.
"SPACE" 영역 없이 Fixed time 만큼의 "MARK" 신호만 Burst 한다.

즉, 1 Unit 길이로 38Khz를 기준으로 562.5 μs 길이의 신호이다

2. 반복 신호 (Repeat Codes)

리모컨의 키가 눌린 상태(Long Press)의 표현이나, 누른채로 반복 입력이 필요한 경우(ex) 음량조절)
Repeat Code를 통해 전체 메세지 프레임을 반복 전송하지 않고, 전력소모를 줄이면서 신호를 보낼 수 있도록 하는 신호

데이터 메세지 없이 단순히 Preamble + End of Stream 의 구조로 구성되어 있다.

2-1. Repeat Code's Preamble

Repeat Codes의 Preamable 프레임은 "MARK" 길이는 일반 메세지의 Preamble과 같지만
"SPACE" 길이는 일반 메세지의 Preamble 에서의 "SPACE"에 비해 절반의 길이를 가진다.

따라서 Repeat Codes의 Preamble 신호의 길이는
16 Unit 길이의 "MARK" 신호 + 4 Unit 길이의 "SPACE" 신호로 이루어져 있다.
38Khz를 기준으로 9ms의 "MARK" 이후 4 Unit 의 "SPACE" 로 인한 2.25ms 의 간격을 가진다.

2-2. End of Stream (Leadout Pulse Burst)

Repeat codes는 Preamble 신호 이후 데이터 메세지 없이 바로 1 Unit 길이의 EOS 신호를 보낸다.
마찬가지로, 38Khz를 기준으로 562.5 μs 길이의 신호이다.

즉, Repeat Codes는 38Khz를 기준으로
Preamble + EOS = 16 Unit "MARK" + 4 Unit "SPACE" + 1 Unit "MARK" = 21 Unit = 562.5 μs x 21 = 11.8125ms
의 신호길이를 가진다.

3. NEC 프로토콜 요약

각 신호 자체의 길이와 관계없이 NEC 프로토콜의 전체 시그널 길이는 38Khz 기준으로 108ms로 동일하게 유지된다.

이는 NEC 프로토콜에서 정의하는 Fixed time 의 정확히 192배이다. (1 Unit = 562.5 μs@38Khz, 192 x 562.5 μs = 108 ms)
NEC 프로토콜의 신호 길이는 192개 Unit이 들어갈 수 있도록 크기를 잡아둔 것이다.

IR Remote의 키를 계속 누르고 있을때 데이터 신호 이후 따라오는 반복신호들의 모양은 다음과 같을 것이다.

Repeat 신호는 단순히 이전에 받았던 Frame Data가 반복중이라는 신호이기때문에 수신 측에서 1st Frame Data를
제대로 수신 하지 못했다면, Repeat 신호 자체에는 그 어떤 Payload 정보도 들어있지 않기에 정보 해독이 불가능하다.

Pronto Edit Infrared HEX Format : 다양한 프로토콜의 IR 신호 기술 양식

IR 신호 전송을 위하여 가장 대중적으로 많이 쓰이는 프로토콜은 앞서 기술한 NEC 프로토콜과,
Philips 에서 개발한 RC-5 (Manchester Encoding 사용) 라는 프로토콜이 있으며
이 외에도 세상에는 IR 신호를 전송하는 다양한 프로토콜이 존재한다.

이렇게 각기 다른 IR 신호 전송 프로토콜과 그 신호 정보의 기술을 위하여 Pronto 라는 IR 신호 표현 양식이 있다.

Pronto는 기본적으로 4자리 16진수로 인코딩 된다.

1. Pronto Edit HEX Format의 Header (Preamble)

Pronto의 헤더는 4 Sets 의 HEX Code 를 담으며
각 Set 는 다음과 같은 정보를 담고 있다.

FLAG

• 서술하는 신호의 종류
• IR Raw 데이터의 경우 0x0000 으로 표기

Carrier 주파수 분할자

• 서술하는 신호 데이터가 사용하는 Carrier 주파수를 기술
• Pronto의 Internal Clock Frequency 는 4,145,146 Hz로서
  Internal Clock 주파수를 이 Carrier 주파수 분할자로 나눈값이 후술되는 신호의 주파수 값이 됨
• ex) NEC 프로토콜의 표준 주파수인 38Khz 를 기술할시
  IR 신호를 기술할 경우 Carrier 주파수 분할자의 값은 0x006D이 됨
  
  0x006D (HEX) = 109 (Decimal) 이므로
  4,145,146 Hz / 109 = 38,028.86 ≈ 38Khz 로 역산 가능

첫 Signal 길이

• Payload 가 담기는 첫 Signal 의 전체 길이에 대한 정보를 기술
• 신호의 "MARK(High)" - "SPACE(Low)" 쌍의 개수를 기록한다.
  • 즉, 신호의 Preamble 이나 EOS 등은 정보 비트가 아니지만 어쨌든 한쌍으로 기록하고
    데이터 프레임의 경우 논리 0, 논리 1 모두 "MARK"-"SPACE" 의 쌍으로 이루어진 신호이므로
    비트에 대응한다고 생각하면 된다.
• NEC 프로토콜의 경우 0x0022
• ex) NEC 프로토콜의 데이터 프레임 신호는
  1쌍(Preamble) + 16쌍 (Address 16 bit) + 16쌍(Command 16 bit) + 1쌍 (EOS) = 34 개
  "MARK" + "SAPCE" 쌍으로 이루어져 있다.
  따라서 34 (Decimal) = 0x0022 (HEX) 로 표현한다.

두번째 Signal 길이

• 첫 Signal 이후에 오는 Repeat Code 와 같은 신호의 정보를 기술
• 마찬가지로 신호의 "MARK(High)" - "SPACE(Low)" 쌍의 개수를 기록한다.
• NEC 프로토콜의 경우 0x0002
• ex) NEC 프로토콜의 Repeat Code 신호는
  1쌍 (Preamble) + 1쌍 (EOS) = 2개 의 쌍으로 이루어져있으므로
  2 (Decimal) = 0x0002 (HEX) 로 표현한다.

2. 신호 데이터 (첫 Signal + 두번째 Signal 정보)

Header 에서 기술된 각 신호 길이에 맞춰 각 신호의 "MARK" 와 "SPACE"의
Carrier 신호의 Cycle(주기) 배수를 각기 기술한다.

Pronto 에서의 NEC 프로토콜의 데이터 메세지 Preamble 신호 기술을 예를들면, 다음과 같이 기술된다.

NEC 프로토콜의 데이터 메세지 Preamble은 앞서 알아보았듯이 Carrier 주파수 38Khz 기준
16 Unit MARK (9ms) + 8 Unit SPACE(4.5ms) 로 구성된다.

1 Unit 의 신호 구성은 약 21주기 즉, (1/ 38000 hz) * 21 ≈ 562.5 μs 를 Fixed time 길이로 고정한다고 하였다.

1 Unit 는 21 Cycle 이므로 Pronto Edit HEX Format에서 NEC 프로토콜의 데이터 메세지 Preamble은

"MARK" 21 Cycle  x 16 Unit = 336 (Decimal) = 0x0150 (HEX)
"SPACE" 21 Cycle x 8 Unit =  168 (Decimal) = 0x00A8 (HEX) 이므로 다음과 같이 기록한다.

0150 00A8

이런 식으로 첫 Signal 과 두번째 Signal의 전체 신호를 HEX 로 기록하는 것이 Pronto HEX Format 이며

다음은 NEC 프로토콜을 사용하는 한 전자제품의 Volume Down 신호의 Pronto HEX 형식 데이터이다.
(출처 : https://www.remotecentral.com/cgi-bin/codes/rotel/rtc-970_1/page-2/)

0000 006d 0022 0002 0150 00ac 0014 0040 0014 0040 0013 0016 0013 0016 0013 0016 0013 0016 0013 0016 0014 0041 0014 0040 0013 0016 0014 0016 0013 0016 0014 0040 0013 0016 0013 0016 0013 0017 0013 0016 0013 0016 0014 0040 0014 0040 0014 0040 0013 0016 0013 0016 0013 0017 0014 0040 0014 0040 0013 0016 0013 0016 0013 0016 0014 0040 0015 0040 0014 003e 0013 0650 0150 0055 0013 0e0a

분석해보면 다음과 같다.

[Pronto HEX Format 헤더]
0000 : IR RAW Data
006d : 0x006d = 109 | 4,145,146 Hz / 109 = 38,028.86 ≈ 38Khz
0022 : 0x0022 = 22 | 첫시그널 길이 : 34 Pair
0002 : 0x0002 = 2 | 두번째 시그널 길이 : 2 Pair

첫시그널 길이(0x0022) : 34 Pair ( 1 + 16 + 8 + 8 + 1 )

[NEC Protocol 데이터 메세지 Preamble]
0150 00ac

[NEC Extended Protocol Address 16bit] 1100000110001000
[00] 0014 0040 : Logical 1
[01] 0014 0040 : Logical 1
[02] 0013 0016 : Logical 0
[03] 0013 0016 : Logical 0
[04] 0013 0016 : Logical 0
[05] 0013 0016 : Logical 0
[06] 0013 0016 : Logical 0
[07] 0014 0041 : Logical 1
[08] 0014 0040 : Logical 1
[09] 0013 0016 : Logical 0
[10] 0014 0016 : Logical 0
[11] 0013 0016 : Logical 0
[12] 0014 0040 : Logical 1
[13] 0013 0016 : Logical 0
[14] 0013 0016 : Logical 0
[15] 0013 0017 : Logical 0

[NEC Protocol Command 8bit] 00111000
0013 0016 : Logical 0
0013 0016 : Logical 0
0014 0040 : Logical 1
0014 0040 : Logical 1
0014 0040 : Logical 1
0013 0016 : Logical 0
0013 0016 : Logical 0
0013 0017 : Logical 0

[NEC Protocol Command in Inversed 8bit] 11000111
0014 0040 : Logical 1
0014 0040 : Logical 1
0013 0016 : Logical 0
0013 0016 : Logical 0
0013 0016 : Logical 0
0014 0040 : Logical 1
0015 0040 : Logical 1
0014 003e : Logical 1

[NEC Protocol 데이터 메세지 EOS]
0013

[남은 메세지 프레임 시간 채우는 공백]
0650

두번째 시그널 길이(0x0002) : 2 Pair ( 1 + 1 )

[NEC Protocol Repeat Code 메세지 Preamble]
0150 0055

[NEC Protocol Repeat Code 메세지 EOS]
0013

[남은 메세지 프레임 시간 채우는 공백]
0e0a

Pronto HEX 형식으로 기록된 주소 영역의 "MARK"-"SPACE" 길이를 통해
정보 비트로 변환하여 8bit 씩 나누어 보았을때 각 자리가 반전되어 있지 않다는 점을 통해
주소공간 16bit를 전부 사용하는 NEC Extended 프로토콜을 사용하는 것을 알 수 있으며,
Command 영역의 앞 8bit 와 뒤따라오는 8bit 영역이 비트 반전되어 있음으로 직접 확인 할 수 있다.

NEC 프로토콜을 따르는 IR 신호의 프레임 길이는 38Khz 기준으로 108ms 로 고정되어 있으므로
End of Signal 이후 남은 신호의 공백을 채우는 시간을 기록해두는 것을 알 수 있다.

End of Signal 자체는 한번의 "MARK" burst 이지만,
프레임 길이가 끝날때 까지 채워넣는 LOW time 만큼의 "SPACE" 영역과 합쳐서 한쌍의 Pair로 간주하는것이다.

출처 및 참고 링크)

IR 신호 프로토콜
https://book.hacktricks.xyz/todo/radio-hacking/infrared
https://www.sbprojects.net/knowledge/ir/nec.php
https://www.renesas.com/us/en/document/apn/1184-remote-control-ir-receiver-decoder
https://www.bestmodulescorp.com/amfile/file/download/file_id/1945/product_id/798/
https://blog.embeddedexpert.io/?p=1138
https://techdocs.altium.com/display/FPGA/NEC+Infrared+Transmission+Protocol
https://onlinedocs.microchip.com/pr/GUID-3A005322-7241-4A38-9889-70DEE3EF1259-en-US-3/index.html?GUID-717B7771-EAB8-42FF-B9B3-9F88A9897C7C

Pronto HEX Format
https://www.etcwiki.org/wiki/Pronto_Infrared_Format
https://www.scribd.com/document/275868502/Smartphone-IR-remote-control
https://www.codeproject.com/Articles/6786/C-Remote-Control-using-the-Audio-Port
https://www.remotecentral.com/features/irdisp2.htm
https://www.remotecentral.com/cgi-bin/codes/rotel/rtc-970_1/page-2/

많은 조직에서 관성에 의해, 습관에 의해 진행되는 미팅들이 있다.

최초에는 필요성이 대두되어 소집된 미팅이겠지만,

시간이 지남에 따라 해당 미팅의 필요성과 가치가 지속된다는 보장은 없다.

조직관리자 및 팀장들은 많은 회의를 주관하고 소집하며 자신이 주관한 미팅이 조직의

커뮤니케이션에 기여한다는 점을 자랑스럽게 여기고 성과로 여기기도 한다.

그러나 조직의 자원의 관점에서 미팅은 굉장히 비용이 많이 들어가는 행위이다.

미팅에 참여하는 인원의 직급이 높을 수록 더더욱 그러하다.

최대한 단순화 시켜 미팅에 참여하는 인원의 시간당 임금의 합만을 계산해보아도

해당 미팅의 "금전적인" 비용을 산출할 수 있을 것이다.

그렇다면 이러한 미팅이 해당 미팅에 소진되는 조직 자원 그 이상의 가치를 가지려면 어떻게 해야할까.

효과적인 미팅을 위해서는 미팅에 앞서 준비할 것이 있다.

PAO가 바로 그것이다.

1. Purpose : 미팅의 목적이 무엇인가?

2. Agenda : 미팅에서 구체적으로 이야기할 아이템들은 무엇인가?

3. Outcome : 미팅이 끝나고, 결과물로 나와야 할 결정사항들은 무엇인가?

이 세가지가 미리 준비되지 않은 미팅은, 시덥잖은 아이스브레이킹으로 시작되어

결국 그 어떠한 성과도 이루지 못한채 이러저리 흘러가다가 흐지부지 해산되기 마련일 것이다.

미팅의 PAO를 Prep 하면서 얻을 수 있는 장점은 다음과 같다.

1. 이 미팅이 정말로 필요한 것인지 (미팅으로 인해 소진되는 조직 자원 이상의 가치를 가지는지)

2. 누가 정말로 참석해야 하는 사람인지

다시한번 되짚어 볼 수 있다.

더불어 Agenda 에는 가능하다면 항목별로 시간 할당을 해 둘 수 있으면 좋다.

시간 할당이 중요한 이유는 그렇지 않으면 사람들은 별로 중요하지 않은 안건에

많은 시간을 쓰기 때문이다. 보통 어려운 문제에는 별로 말이 없지만, 누구나 의견을 내기 쉬운 문제는

누구나 한마디씩 의견을 내기 마련이기에 중요하지 않은, 혹은 상대적으로 결정이 쉬운 안건에 대해

지나치게 시간이 많이 낭비 될 수가 있다.

마지막으로, 효율적인 미팅의 끝은 미팅노트를 해당 미팅에 참여하지 않은

다른 조직의 구성원들과 공유하는 데에 있다.

조금만 생각해보면, 아무런 경계심 없이 진행되던 미팅이 알고보면

엄청난 조직 자원의 소모였다는 것을 알 수 있다.

PAO 를 지키는 미팅 Prep 과 미팅노트의 조직 공유만이

그러한 "고비용"의 미팅으로 부터 최대한의 효율을 끌어내는 방법이라고 할 수 있겠다.

https://youtu.be/tcrr2QiXt9M

들어가기에 앞서 생각해 볼 질문들

Carrying Capacity (한계 수용 능력)

프로덕트 관점에서 MAU(Monthly Active Users)가 프로덕트가 가지는 역량이라고 하였을때
Carrying Capacity는 이 MAU 즉, 호수의 물이 얼만큼 올라갈지를 알려주는 지표이다.

호수의 물의 양은, 땅의 지형(=시장)과 관계 없이

• 호수에 물을 채우는 비의 양
• 호수의 물의 양에 따라 점점 늘어나는 나가는 물의 양 (%)

두가지 요소만에 의해 정해진다.

마찬가지로, 프로덕트의 Total Customers 에 영향을 미치는 요소는

• Inflow ( = New User + Ressurection)
• Chrun Rate ( = 1 - Retention Rate)

이 두가지 요소만에 의해 정해진다.

Carrying Capacity = 제품의 본질적인 체력(마케팅, 광고가 제외된) = 내 서비스가 도달할 최종적인 유저수

CC를 결정하는 두개의 값을 바꾸지 않으면 프로덕트의 MAU는 늘어나거나 줄어들수 없다.
CC의 의의는 서비스를 운영하고 3-6개월 안에 알 수 있기 때문에, 제품의 성장을 미리 예측할 수 있다는 점에서 중요하다.

마케팅 관점에서의 CC 의 가치

전제 : 광고는 돈이 든다. 즉, 지속 가능한 Inflow 의 증가가 아닌 일시적인 Inflow Boosting에 불과.

Q. 현재 MAU가 10만, CC 는 75만 | 광고를 해야 할까?
-> YES : CC에 도달하기 까지의 시간을 단축 시킬 수 있다.

Q. 현재 MAU가 70만, CC 는 75만 | 광고를 해야 할까?
-> NO : 광고를 하지 않아도 MAU는 CC가 75만이기 때문에 75만에 도달할 것이다.

Q. 현재 MAU가 100만, CC 는 75만 | MAU는 떨어질까?
-> YES : 프로덕트의 CC가 변하지 않는 이상 MAU는 다시 75만으로 회귀한다.

R&D 관점에서의 CC의 가치

프로덕트가 CC에 도달하는 시점을 알게되면,
프로덕트를 성장시키기 위해 기능을 추가해야 하는 시점도 알 수 있다.

CC에 도달한 프로덕트를 성장시키는 방법에는 두가지가 있다.

• Inflow 를 개선 / Retention 개선을 통한 CC 자체를 높히는 방법
• 새로운 기능(프로덕트)를 추가하여 새로운 CC를 얹는 방법

프로덕트의 Carrying Capacity 를 측정하면 언제 프로덕트가 성장 한계에 도달하고, 언제 기능을 추가 해야 하는지를 알 수 있다.

주의점

1. 프로덕트의 정확한 Carrying Capacity 를 측정하기 위해서는 Organic 지표를 기준으로 삼아야 한다.
    즉, 광고를 끈 상태의 프로덕트 자체의 Organic 지표를 파악하는 것이 중요.

2. Customer 에 대한 정의가 중요하다. 사전에 해당 지표를 Fix 해두는 것이 중요.

• Active User 에 대한 정의
• Churned User 의 정의 : 얼마를 안써야 Churn 된 유저라고 정의하는지 | Loss 유저에 대한 정의.

3. Carrying Capacity를 결정하는 요소에 대한 Timeframe 에 대한 기준

Carrying Capacity = Number of New Customers per [Timeframe] / Percentage of Customers Lost Each [Timeframe]

[Timeframe] 이 너무 길어지면 이터레이션에 따른 측정에 걸리는 시간도 늘어난다.

https://ridibooks.com/books/950000024?_s=search&_q=1+page+proposal&_rdt_sid=search&_rdt_idx=0

"지나친 정보는 결정을 앞당기는 것이 아니라 지연시킨다."

1 Page 제안서란 무엇인가

• 추진하고자 하는 사업 혹은 프로젝트를 둘러싼 모든 객관적 사실, 추론, 상황을 간결하게 표현
• 동의를 얻어내기 위한 것이므로 설득력 있는 언어를 사용
• 구체적인 실행 과정을 설명
• 이 모든 것을 1 페이지 분량으로 압축할 것

기획(제안)서의 목적

특정한 사람으로 하여금 특정한 종류의 실행 과정을 수행하도록 하는 것. 즉, 실행을 유발하고 보조해야 한다.
기획서를 읽는 사람이 기안자의 시각을 통해 프로젝트를 볼수 있도록 해야 한다.
비단 읽는 사람을 위함 뿐만이 아니라, 1 페이지 분량으로 기획을 압축하는 것은 프로젝트에 대한 스스로의 이해에도 중요하다.
1 Page로 압축하는 과정은 명료하게 자신의 생각을 표현하도록 독려하고, 많은 정보를 가지고 있지만 날카롭게 선택된 언어로
표현하도록 만든다.

그렇다면 방대한 분량의 계획서는 무의미 한가? - NO

1 Page 제안서는 결정을 위한 것이다. 일의 진행을 위해서는 전통적인 방식의 사업계획서는 언젠가는 필요하게 되어 있다.
그러나, 결정을 위해서는 지나친 정보는 결정을 앞당기는 것이 아니라 지연시킨다.

준비과정

자료를 수집하라

• 제안하고자 하는 사업에 대한 모든 지식을 리스트 화 한다. 그 과정은 모르고 있는 지식이 무엇인지 알 수 있게 해준다.

목표는 완전한 이해다

• 리서치를 하는 목적은 완벽하게 주체를 파악하는 것이다.

누구에게 제출 할 것인가

• 기획서를 작성하기 시작하기에 앞서 꼭 가지고 있어야 할 중요한 정보이다.
  설득을 위해서 설득의 대상이 되는 사람이 누구인가를 아는 것은 매우 중요하다.

반대 세력 / 리스크 다루기

• 제안서의 성공에 걸림돌이 되는 요소들을 절대 과소평가 하지 말라.

사실을 반드시 확인하라.

• 특히나 인터넷은 단편적이고 부분적이며 잘못된 정보가 곳곳에 숨어있다. 팩트체크는 필수이다.
  더불어 불완전한 데이터는 잘못된 결론을 이끌어낸다. 1 Page 제안서의 데이터는 반박 할 수 없는 것이어야 한다.

질문을 예상하라. 회의적인 태도와 NO 라고 말할 기회를 사전에 차단해야 한다.

• 해당 프로젝트는 어떤 구조를 가지고 있는가.
• 그 책임자는 누구인가.
• 비용은 얼마나 드는가.
• 회수 자금의 예상 가능 액수는 얼마인가.
• 해당 기획서의 특별한 점은 무엇이며, 시기는 적절한가.
• 기획서를 제출한 사람에게 특별한 경력이 있는가.

1 Page 제안서의 8가지 항목

제목

제목은 기획서의 내용을 한줄로 집약하는 것이다. 다른 것은 읽지 않을지라도 제목만큼은 읽는 다는 것을 명심하라.

기획서의 주제를 간단하게 나타낸다. 간결하면서도 정확해야 한다.

부제목

제목을 좀더 세부적으로 설명하는 간결문으로서 2차적 정보와 설명을 덧붙여 흥미를 불러일으키는 역할을 한다.
계속하여 아래 내용을 읽을 수 있도록 관심을 사로잡아야 한다.

부제는 단어 선택이 중요하다. 묘사적인 단어와 구를 써서 좀더 표현력 있게 제목을 보강하라.
읽는 사람의 흥미를 유발시키기 위한 요소를 사용되도록 한다. 읽는 사람의 마음옷게 적절한 단어가 새겨지도록 공들여 다듬어야 한다.

목표

기획서의 목표는 곧 기획자의 의도와 같다. "무슨 일을 해보겠다는 겁니까" 에 대한 대답이 목표에 쓰여져야 한다.

목표는 기획서의 의도를 밝히는 부분이다. 하나의 중심적 목적지를 제안한다.

2차 목표

1차 목표를 보완하고 장점을 부각시켜 읽는 사람의 동의를 얻어낸다. 목적이나 장점을 나열하는 것은 축적된 효과를 가져온다.

2차 목표는 주목적의 연장선상에 있으므로 동떨어진 사항을 적어서는 안된다.
프로젝트에는 수십가지 2차 목표들이 있을 수 있겠지만 5~6개 정도로 줄이는 것이 좋다.
잠재적으로 가치 있는 목표이지만, 불핗요하게 보이는 시점까지 않도록 목표의 수위에 조절해야 한다.
읽는 사람이 2차 목표중 어느 하나라도 억지 해석한 것처럼 느끼게 해서는 안된다.

논리적 근거

제안서의 설득이 시작되는 부분이다. 2~3개의 짧은 문단으로 구성된 논리적 근거는 프로젝트가

• 할 수 있고
• 할 것 이며
• 앞으로 나아가야 하는 모든 이유를

논리적으로 설명한다. 1 Page 제안서 이전의 모든 리서치는 이것을 위함이다.

설정 - 매력포인트 - 설득의 단계로 진행되는 논리 전개를 따른다.

1. 설정

• 읽는 사람의 관심을 잡는다.
• 당신이 누구이며 어떤 지식을 갖추고 있는지 알게 한다.
• 기획서의 내용을 뒷받침 할 수 있는 적절한 근거와 상황을 요약한다.

2. 매력 포인트

리서치에서 얻어진 적절한 데이터를 이용해, 기획서를 실행시키면 목표와 2차 목표가 완수될 것이라는 주장을 보강하라.
현상들은 반박할 여지가 없고, 시기 적절한 것들이어야 하며, 현 상황에서 당신의 프로젝트가 최고의 해결책인 이유를
설명 할 수 있어야 한다.

3. 설득

논리적 근거의 마지막 부분인 이곳에 최대한의 증거와 논리를 가지고 주장을 뒷받침하면서, 당신의 제안이 승인된다면
어떤 일이 일어나는지, 왜 그런 결과가 일어나리라 확신하는자, 왜 이 제안서를 읽는 사람이 그것에 찬성해야 하는지 설명하라.
이 과정에서 프로젝트가 가지는 시의적절성(데드라인-왜 지금이어야만 하는지)을 포함시킨다.

재정

모든 프로젝트는 재정 문제가 관련되기 마련이다. 제안서의 바로 이 항목에서 거래의 금전적 행위의 양을 정하고 질을 정한다.

투자란 기회가 될 수도 있지만, 위험도 따른다. 제안서를 읽는 사람은 위험에 집중할 것이다.
재정적인 부분이 전혀 없는 기획이라면, 왜 아무 비용이 들지 않는지, 아니면 보이지 있는 비용이 있는지 설명한다.
비용은 들지 않지만, 제안을 실행함으로서 절약되는 비용이 생긴다면 얼마만큼의 비용이 절약되는지 밝힌다.
재정 문제에 관하여는 "부풀리기"의 유혹을 참아야한다. 있는 그대로 자신있게 쓰도록 한다.
이러한 특징은 종종 불황이나 심각한 재정상태에도 불구하고 거래를 이루어 내는 중요한 역할을 한다.

현재 상태

현재 상황은 어떠한지, 지금까지 어떤 상황이었는지, 거래의 어떤 요소들이 이미 자리를 잡았는지, 누구와 협업하는지, 이미 계약된 거래가 있는지 등과 같은 현재의 상황을 정확하게, "최신의 정보로", 읽는 사람 앞에 그려주어야 하며 프로젝트가 진행됨에 따라 지속적인 업데이트가 필요하다.

제안 사업의 어떤 요소들이 자리를 잡았고 어떤 요소들이 답보 상태인지 설명한다.
부정적인 면이나 논쟁의 대상이 될 부분을 무시하지 말라. 누군가 당신의 제안을 거절한 적이 있다면 그것도 밝혀라.
정말 좋은 아이디어라면 전에 거절당한 적이 있다고 해서 그것을 놓치는 사업가는 많지 않다.
현재 상태 부분은 사업에 대한 그림을 그릴 뿐 아니라 열정까지 보여주어야 한다.

실행

제안을 받는 사람이 "내가 어떻게 하면 됩니까?" 에 대한 대답이다. 위의 모든 것은 이 한 문장을 쓰기 위한 준비다.

아무것도 부탁하는 것이 없다면 그것은 기획서가 아니다. 지금까지의 내용을 다 읽었다고 해서 제안서를 읽는 사람이
어떤 역할을 담당해야 하는지 추론할 수 있으리라 생각하지 말라. 이 시점에서는 제안하는 바를 "정확하게" 표현 할 수 있어야 한다.

한가지 명심할 것은, 당신이 부탁하는 것이 행할 수 있는 것이어야 한다. 리서치를 통해 상대방이 무엇을 해줄 수 있는지 알아내야 한다.
제안서를 읽는 사람의 능력 안에 있는 것을 명확하게 부탁하라.

날짜와 서명

서류의 맨 밑에는 날짜와 서명을 기입한다.

기획(제안)에 있어서 기획자의 이름은 중요하다.
공을 자랑하거나 아이디어에 대한 생색이 아닌, 책임소재와 제안의 확신과 신뢰성을 결정짓는 요소이다.

지식을 1 Page 형식으로 바꾸기

리서치 자료와 생각을 정리해 분류하기

모든 리서치 자료를 한군데 모은뒤 1 Page 제안서의 8가지 항목 단위로 분류한다.

축소

분명하게 중요한 사항이 아닌 자료들을 걸러낸다.

우선 순위 정하기

각 항목 안의 자료들을 우선 순위 순으로 정리한다.

쓰기의 시작

목표 항목 부터 시작한다. 분류 항목의 자료들의 주요 정보 하나하나를 한 문단으로 쓴다.

검토

• 문장들 중 적어도 한 문장에 주요 리서치가 나타나 있는가?
• 문장들이 각 부분에서 논리적 사고 과정을 따르고 있는가?
• 파일마다 리서치에서 파생된 결론과 이해를 정확하게 반영하는가?

회고

1. 내가 성취하려는 것이 무엇인가?
2. 말하고자 하는 모든 것을 잘 포착했는가?
3. 명확한가?
4. 빠진 것은 없는가?
5. 논리에 허점은 없는가?
6. 설득력 없는 주장은 없는가?
7. 계산이 틀린 곳은 없는가?
8. 기획서의 원리가 설득적인가?

아직까지 1 Page 제안서는 완성된 것이 아니다. 빈곳이나 넘치는 부분이 있더라고 신경쓰지 말자. 이 과정은 원래 불완전한 과정이다.

교정 축소 압축

기획서가 한쪽 분량을 넘는다면 할일은 딱 한가지, 잘라 내는 것이다.

길이

• 흥미롭지만 불필요한 사실들을 잘라 내라 : 제안서의 중심 내용을 이해시키고 설득하는데 절대적으로 중요하지 않다면 지운다.
• 과다한 정보는 잘라 내라 : 여러번 반복되거나 중복된 정보는 지워라.
• 뻔한 사항은 잘라 내라 : 제안서를 읽는 대상이 이미 갖추고 있는 지식이라면 들어내도 좋다.

문체

• 같은 단어의 반복과 후술 문장을 피하라 : 두 문장을 한문장으로 압축할 수 있다면 압축한다.
• 형용사, 부사 및 꾸며주는 말들을 없애라.
• 지나치게 세부적인 것들은 제거하라 : 시적으로 표현하고 싶은 유혹을 피하라.
• 동의어의 반복을 피하라 : ex) "오늘날 현대 산업..." "다시 반복하자면..." "위쪽으로 올라가..." 

단어 선택

• 3인칭을 사용하라 : 제안서의 성공은 개인적 매력이 아닌 사업 자체의 가치에 달려있다.
• 긍정적인 단어로 긍정적인 자세를 보일것 : 절망적으로 보이지 않고 절박해 보이지 않는 단어를 선택하라.
• 지나친 선전을 피하라 : 근거 없는 최상급을 사용했는지 살펴라. ex) "가장 ~"
• 맞춤법과 오탈자를 점검하라.
• 구두점을 제대로 찍어야만 자연스럽게 읽히는 복잡한 문장 구조를 피하고 간결한 문장구조를 사용하라.
• 일반적으로 쓰이는 줄임말이 아니라면 철자를 모두 적어라.

물리적 상품 가치

• 좋은 품질의 인쇄
• 읽기 쉬운 표준 활자체와 폰트 크기
• 튀지 않게 만들기 : 기본 검은색 인쇄와 넉넉한 여백

램오버시 PBO 만 키면 AIDA 캐시/메모리 벤치마크중 꺼집니다

작성일자 : 2021-05-18

원본 글 주소 : https://quasarzone.com/bbs/qf_overclocking/views/205986?_method=post&_token=0TIOlXdzcPa131ULPD88qZBmfZyjLngOuHs2RzEY&category=&direction=DESC&keyword=InFinityGURU&kind=nick&page=1&popularity=&sort=num%2C%20reply&type=

아카이브 주소 : 아카이빙 Blocked

ASUS PBO Fmax Enhancer 옵션 활성화시 램오버 셧다운 증상

작성일자 : 2021-05-19

원본 글 주소 : https://quasarzone.com/bbs/qf_overclocking/views/206151?_method=post&_token=0TIOlXdzcPa131ULPD88qZBmfZyjLngOuHs2RzEY&category=&direction=DESC&keyword=InFinityGURU&kind=nick&page=1&popularity=&sort=num%2C%20reply&type= 

아카이빙 주소 : 아카이빙 Blocked

5950X + AIO 수냉쿨러를 사용하는 당신이 수동오버가 필요없는 이유

작성일자 : 2021-05-23

원본 글 주소 : https://quasarzone.com/bbs/qf_overclocking/views/208515?_method=post&_token=0TIOlXdzcPa131ULPD88qZBmfZyjLngOuHs2RzEY&category=&direction=DESC&keyword=InFinityGURU&kind=nick&page=1&popularity=&sort=num%2C%20reply&type= 

아카이빙 주소 : 아카이빙 Blocked

사용할 데이터 베이스 선택

use 데이터베이스이름

현재 사용중인 데이터 베이스 이름 확인

db

데이터 베이스 리스트 확인

show dbs

사용중인 데이터 베이스 DROP 하기

db.dropDatabase()

컬렉션 생성

db.createCollection("컬렉션이름",{옵션})

// 옵션에는 {capped : true / false, size : 10000, max : 1000}
// size 는 컬렉션의 크기(byte단위) 제한
// max 는 컬렉션의 개수 제한

컬렉션이 capped 인지 아닌지 확인

db.컬렉션이름.isCapped()

이미 생성된 컬렉션을 Capped 컬렉션으로 변경

db.runCommand({"convertToCapped":"컬렉션이름",size:10000})

도큐먼트 삽입 1

db.컬렉션이름.insert({필드명:"필드값"})

도큐먼트 삽입 2

db.컬렉션이름.insert(
    {
        필드명 1: "데이터" // 문자
        필드명 2: 17 // 숫자
        필드명 3: ["원소1", "원소2"] // 배열
    }
)

도큐먼트 삽입 3 - 임베이드 도큐먼트 : 도큐먼트 안에 배열 형태로 여러 도큐먼트를 또 넣을 수 있다.

db.컬렉션이름.insert(
    {
        필드명 1 : "필드값"
        필드명 2 : [ // 배열 형태로 삽입된다
                            {
                                필드명2-1-1 : "필드값",
                                필드명2-1-2 : "필드값"
                            },
                            {
                                필드명2-2-1 : "필드값",
                                필드명2-2-1 : "필드값"
                            }
        ]
    }
)

도큐먼트 삽입 4 - insertMany()

db.컬렉션이름.insertMany( // 배열형태로 한번에 여러 도큐먼트를 넣을 수 있다.
    [
        {_id1, 필드명: "필드값", 필드명2: "필드값", 필드명3: 13},
        {_id2, 필드명: "필드값", 필드명2: "필드값", 필드명3: 14},
        {_id3, 필드명: "필드값", 필드명2: "필드값", 필드명3: 15},
    ]
)

도큐먼트 입력 검증

db.createCollection("컬렉션이름",
    {
        validator: {
            필드명1: {$type: "string"}, // string, boolean, array, int 등 데이터형 옵션
            필드명2: {$in:["Seoul", "Cheongju"]} // 순서 상관 없음. 배열의 원소들안에서 데이터 제한.
        }
    }
)

도큐먼트 검색

db.컬렉션이름.find().pretty()

도큐먼트 검색 : Projection

db.컬렉션이름.find({필드명: "필드값", 필드명2: "필드값"}, {"필드명" : 1}) // 뒤에 0이면 해당 필드값을 숨기고 1이면 보여줌

*db.컬렉션이름.find({}),{필드명: 1, 필드명2 :0}) 다음과 같은 옵션을 불가능. 필드명 여러개 혼합 불가.
숨길것만 0 Flag. 플래그 없는건 무조건 표기.

도큐먼트 검색 :  Query Operator (쿼리 연산자)

db.컬렉션이름.find({필드명:{$쿼리연산자:조건값}})
//$eq = equal
//$gt = greater than
//$gte = greater equal
//$lt = less than
//$lte = less equal
//$ne = not equal

db.컬렉션이름.find({필드명:{$쿼리연산자["필드값", "필드값"]}) // 순서 Sensitive X
//$in = 배열에 해당 값이 있는지 (있으면 보여줌)
//$nin = 배열에 해당 값이 없는지 (없으면 보여줌)

ex) [1,2,3,4,5]를 조건으로 검색했을때
$in[1,2,6] 해도 나옴 즉, OR 검색이다.

도큐먼트 검색 : Logical Operator (논리 연산자)

db.컬렉션이름.find({$논리연산자: [{필드명: "필드값"}, {필드명2:"필드값"}]})
db.컬렉션이름.find({$논리연산자: [{필드명: "필드값"}, {필드명2: {$쿼리연산자: 조건값}}]})
//$and
//$not
//$nor
//$or

도큐먼트 검색 : 임베디드 도큐먼트 접근

db.컬렉션이름.find({필드명: {필드명1: "필드값", 필드명2: "필드값", 필드명3: "필드값"}})
db.컬렉션이름.find({"필드명.필드명1": "필드값", "필드명.필드명2": "필드값"})
//위와 같이 검색시 전체가 완전히 같은 결과만 보여줌 (AND 연산 검색)

db.컬렉션이름.find({필드명: {$elemMatch: {"임베디드필드명": "필드값"}}})
//위와 같이 검색시 도큐먼트 안에 해당값이 포함되는 결과값 보여줌 (OR 연산 검색)

도큐먼트 검색 : 배열 원소 접근

db.컬렉션이름.find({필드명: ["배열원소1", "배열원소2"]})
// 배열에 순서, 갯수 정확히 일치하는 결과만 보여줌

db.컬렉션이름.find({필드명: {$all: ["배열원소1", "배열원소2"]}})
// 배열에 포함만 되면 다 보여줌 (OR 연산 검색)
// *인덱스 값으로 접근시 0 베이스 인덱싱임으로 주의할것

db.컬렉션이름.find({필드명: {$elemMatch : {$gt:80, $lt:90}}})
// 임베디드 도큐먼트 뿐만 아니라 쿼리연산자를 활용하여 배열에도 사용 가능

도큐먼트 검색 : 배열 길이를 통한 접근

db.컬렉션이름.find({"필드명": {$size: n}}) //원소의 개수가 n 개인 배열 검색
db.컬렉션이름.find({"필드명": {$size {$쿼리연산자 : n}}}) //쿼리 연산자 또한 사용가능

db.컬렉션이름.find({$where: "this.필드명.length > n"}) //자바스크립트 조건문검색의 형태도 사용가능

도큐먼트 검색 : null 값

db.컬렉션이름.find({"필드명": null}) //null값을 갖는 필드 찾기
db.컬렉션이름.find({"필드명": {$ne:null}}) //null 값이 아닌 필드 찾기

도큐먼트 검색 : 존재 여부

db.컬렉션이름.find({"필드명": {$exists: true/false}}) // 해당 필드명이 있는 문서가 있는지 없는지 *exists "s" 안붙이는 실수 자주함

도큐먼트 검색 : regex

db.컬렉션이름.find({"필드명": {$regex: "XX"}}) //필드값에 XX 를 포함하는 문서를 검색. 대소문자 구분.
db.컬렉션이름.find({"필드명": {$regex: "XX", options: 'i'}}) //대소문자 구분 X

db.컬렉션이름.find({"필드명": {$regex: "^XX"}}) //첫자리가 XX 인것 찾기
db.컬렉션이름.find({"필드명": {$regex: "XX$"}}) //끝자리가 XX 인것 찾기

db.컬렉션이름.find({"필드명": {$regex: "^XX$"}}) //딱 XX인것 찾기

도큐먼트 수정 - update 수정 : 필드단위 수정

db.컬렉션이름.update({필드명: "필드값"}, {$set: {필드명: "수정할필드값"}}) //하나만 수정됨
db.컬렉션이름.update({필드명: "필드값"}, {$set: {필드명: "수정할필드값"}}, {multi: true}) //전부 수정됨

*주의 : update 할 필드명과, 수정될 필드명이 달라지면 set에 설정한 필드명과 필드값으로 새롭게 추가된다.

도큐먼트 수정 - save : 덮어쓰기 - 필드 갯수도 달라질때

db.컬렉션이름.save({필드명: "필드값", 필드명2: "필드값", 필드명3: "필드값"})

도큐먼트 삭제

db.컬렉션이름.remove({}) //전체 삭제
db.컬렉션이름.remove({필드명 : '필드값'}, 1) //해당 필드값을 가지는 레코드 하나만 삭제
db.컬렉션이름.remove({필드명 : '필드값'}) //해당 필드값을 가지는 레코드 전부 삭제

Aggregation Framework

db.컬렉션이름.aggregate(
    [
        {$match: {}},
        {$sort: {}},
        {$project: {}},
        {$limit: {}},
        {$skip: {}},
        {$group: {_id: "$그룹명으로 만들 필드명"}},
        {$count: {}},
        {$unwind {}},
        {$out: {}},
    ]
)

//다음과 같은 함수 연산자 사용 가능
//$max
//$min
//$avg
//$sum
//$addToSet
//$push
//$first
//$last

인덱싱 : 몽고디비는 기본적으로 _id 필드 인덱싱으로 한다 (_id 필드는 독립된 데이터 type을 가진다)

db.컬렉션이름.createindex({"필드명" : -1 or 1}) //1은 오름차순 인덱싱, -1은 내림차순 인덱싱
db.컬렉션이름.createinder({"필드명" : 1, "필드명2": -1}) //여러개의 필드에 대해 인덱싱도 가능

explain() :  쿼리문의 수행 내역을 출력

쿼리문 뒤에 .explain("executionStats")

https://youtu.be/lOebGm_jMLY

FPS 게임에서의 무기 밸런스에 관한 Insight를 담은 영상.

FPS 게임에서의 변칙적인 STAT을 가진 무기중 하나인 스나이퍼 무기 군에 대한 밸런스는 어떻게 할 것인가에 대한
인사이트를 주는 영상이다.

아래 내용은 요약 정리.

FPS 게임에서 총기 밸런스를 조절하는 스탯은 대표적으로 7가지가 있다.

[Balancing Tools]

• Damage - 기본 데미지
• Headshot - 헤드샷 데미지
• Firerate - 연사속도
• Range - 유효사거리 : 게임마다 다르지만 총기 탄착군의 스프레드, 거리에 따른 데미지 감소율로 조절
• Recoil - 총기 반동
• Mobility - 기동성
• Handling - 핸들링 속도 : ADS:Aiming Down Sight 속도, 재장전 속도 등 

FPS 게임에서 총기 분류에 따라 스탯이 디자인되는 과정은, 베이스가 되는 AR #1의 총기 스탯으로
해당 게임의 전반적인 TTK나 총기반동등 건플레이의 아이덴티티가 확정되고
AR #1의 스탯을 바탕으로 조금씩 바리에이션을 주어 다른 총기들의 스탯이 결정된다.

Assualt Rifle #1 - Core stat of entire game

대체로 M4 같은 무난한 반동과 데미지, 연사속도를 가진 스탯의 총기
AR #1의 데미지에 따라 게임 전반의 TTK가 결정되고 거기에 맞추어 다른 총기들의 데미지도 조정됨

Assualt Rifle #2 - Alternative AR

대체로 AK와 같은 고반동 고데미지, 낮은 연사속도의 스탯을 가진 총기

SMG #1 / SMG #2

AR과 비슷하거나 낮은 데미지, 비슷하거나 높은 연사속도
SMG 특성상 짧은 유효사거리를 갖는 대신 기동성과 핸들링 속도가 빠른 특징

DMR (aka. Marksman Rifle) #NaN

높은 데미지
낮은 연사속도
AR 대비 긴 유효사거리
낮은 기동성과 핸들링속도

Shotgun #NaN

높은 데미지
낮은 연사속도
극도로 낮은 유효사거리
SMG와 비슷한 CQB (Close Quarters Battle) 포지션이므로 높은 기동성과 핸들링 속도를 가짐

Bolt Action Sniper

높은 데미지
낮은 연사속도

Bolt Action Sniper 무엇이, 왜 문제인가?

샷건의 경우 CQB에서만 우위를 점하는데에 반해 Bolt Action Sniper는 높은 데미지를 모든 유효사거리에 걸쳐서 가지는
카테고리이기 때문이다.

각각의 총기가 가지는 아이덴티티에 근거해서, 대응은 다음과 같이 할 수 있다.

• 장거리에서의 Bolt Action Sniper -> Dont peek
• 근거리에서의 Shotgun -> Dont push

레벨디자인이나 맵구조, 플레이 모드에 따라 이견이 있을 수 있으나 무기 특성에 따른 납득 할수 있는 특성이지만
문제는 볼트 액션 스나이퍼 라이플의 중/근거리 교전에서 발생한다.

중거리/근거리에서의 Bolt Action Sniper 는

• 거리에서의 AR
• 근거리에서의 SMG / Shotgun

과 같이 명시적으로 우위를 점해야 하는 무기와 비교하였을때 중/근거리에서도 여전히 0ms라는 TTK를 가진다.

특히나 근거리 교전의 경우 샷건 특성상 팰릿별 데미지 계산이 들어가기 때문에 문제 상황이 생긴다.

바로 이런 경우

근거리 교전임에도 불구하고 Shotgun 대비 Bolt Action Sniper 의 특성상 실각을 먼저 잡고 있는 Bolt Action Sniper는
교전상 우위를 점한다.

그렇다면 FPS 게임에서의 Bolt Action Sniper의 등장은 언제부터일까?

• 1993년 DOOM
• 1996년 Quake
• 1998년 Tom Clancy's Rainbow Six

스코프가 달리는 Bolt Action Sniper의 특성상 먼 거리의 물체도 렌더링 해야하지만
당시 하드웨어의 제약으로 인해 게임내에서 렌더링 거리가 제한되었기 때문에
우리가 알고있는 FPS 게임에서의 Bolt Action Sniper의 첫 등장은 2000년 Counter Strike 에서 부터이다.

그리고 이때도 에땁 AWP라고 불리는 Bolt Action Sniper는 역시나 원샷 원킬의 무기였다.

그러면 왜 5:5 카스 경쟁에서 전부 AWP를 들지 않을까 (카스가 원샷 원킬 볼트액션 스나이퍼를 밸런싱한 방법)

그전에,  그렇다면 스나이퍼 라이플을 밸런싱 할수 있는 방법에는 무엇이 있을까.

Damage

일부 스나이퍼 라이플은 원샷 원킬을 보장하지 않는다.
카스나 서든의 스카우트와 같이 구매 비용이 낮은 AWP/TRG의 대용은 그렇지만 우리가 얘기하고자 하는
원샷 원킬의 스나이퍼 라이플의 밸런싱과는 논외이다.(가격대비 성능의 문제이지 무기 자체에 대한 밸런싱이 아님)

99/100 데미지를 모든 스나이퍼 라이플에 적용할경우, 원거리에서의 스나이퍼 라이플에 대한 아이덴티티도
무너질 뿐더러, 모든 샷을 랜딩한다고 가정했을때 궁극적으로 스나이퍼 라이플의 TTK 자체를 늘려버리는 것과 동일하다.

더불어 이미 해당 카테고리는 DMR (aka.Marksman Rifle) 이 가지고 있는 정체성이다.

따라서, Damage 밸런싱은 불가능

Headshot

헤드샷 데미지 스탯을 만진다고 해서, 크게 달라질수 있는 문제가 아니기에 논외

Firerate

이미 볼트 액션 스나이퍼는 한발 쏘고, 재장전을 해야 하는 무기이다.
재장전 시간을 길게 조정했을경우, 궁극적인 중/근거리에서의 스나이퍼 라이플의 밸런싱 문제는 해결되지 않음과 동시에
한명을 눕히고 나서 다른 적이 나타났을때 대응 방법이 없다는 점에서 문제가 생긴다.

물론, 근거리 교전에서 스나이퍼 라이플을 사용하는 게이머에게 핸디캡을 주는 방식으로 근거리 교전 밸런싱을
하는 방법이긴 하지만, 중장거리에서의 스나이퍼 라이플을 사용하는 게임의 재미성을 극심하게 떨어뜨린다.

게임에 있어서 재미와 밸런싱이라는 요소는 둘다 챙겨야 하는 요소이다.

가능한 밸런싱 방법이기는 하지만, 밸런싱과 재미라는 두가지 요소를 둘다 가져가야하는 게임의 특성상
득보다 실이 많다는 뜻이다.

Range

스나이퍼 라이플의 교전거리를 줄이는 방법은, 애초에 스나이퍼 라이플 자체의 정체성에 맞지 않거니와
중/근거리에서의 볼트 액션 스나이퍼 라이플을 밸런싱하기 위한 본래의 목적에도 맞지 않기 때문에 논외로 한다.

Recoil

반동 스탯을 조절하는 것은 한발씩 쏘는 볼트액션 스나이퍼 라이플의 특성상, 별로 의미없는 일이다.

Mobility

이미 대부분의 게임에서, 스나이퍼 라이플을 들고 있으면 이동속도에 불이익을 준다.
여기서 더 만지는 것은 3. Firerate의 항목에서와 마찬가지로 재미라는 요소에 영향을 미친다.
누가 스나이퍼 라이플을 들고 달팽이 처럼 기어다니는 게임을 하고 싶겠는가.

더불어, 밸런싱이라는 본래의 목적에도 크게 영향을 줄 수 있는 스탯이 아니다.

Handling

가능한 방법이기도 하고, COD(Call of Duty)나 일부 게임의 경우 ADS 속도를 느리게 하는 방법을 사용하기도 하나
그 스탯 밸런싱에는 한계가 있다. 지나치게 느린 ADS 속도는 플레이를 답답하게 만들고 이미 언급한바와 같이 게임의
재미 요소를 떨어뜨리는 방향이기 때문이다.

만약 이게 정말로 효과적인 방법이었다면, 모든 게임들이 그러한 방법으로 밸런싱을 하겠지만
서든, 카스, 발로란트 등 이외 많은 게임에서 스나이퍼 라이플의 스코프 줌인 속도는 빠르다.

더불어, 스코프 줌인을 한 이후부터는 결국 우리가 원래 밸런싱 하고자 했던 문제들을 그대로 가지게 된다.

FPS 게임에서 조절 할 수 있는 총기 스탯 7가지의 경우를 모두 알아봤지만, 굉장히 까다로운 문제이다.
스탯 조절로는 어느정도 문제를 해결 할 수 있지만, 플레이하기에 짜증나는(재미가 없는) 매력없는 총기가 되거나
완전히 Under Powered 가 되버린다.

대부분의 FPS 게임에서의 해당 문제를 해결하기 위한 전통적인 밸런싱 방식은 다음과 같다.

고배율 스코프 고정

- 카스의 AWP나 발로란트의 Operator 같은 경우 고배율 스코프를 고정시킨다

정확도 회복 시간 늘리기

- Mobility 나 Handling 관련 스탯을 직접적으로 조정하기 보다는, 카스나 발로란트의 경우 움직이다가 멈춘뒤(브레이킹)
정확도 회복 속도를 조정하는 방식을 쓴다. 단, 이경우 볼트 액션 스나이퍼를 들고 공격적인 플레이를 하는 경우에만
제약을 준다는 부분에서 한계가 있다.

높은 구매 비용 책정

- 카스와 같은 구매 방식이 아닌 루트 슈터같은 경우 드랍 확률, 혹은 획득하기 어려운 곳에 드랍되도록 하는 방식
- COD나 배틀필드 같이 총기 선택에 대한 경제 시스템이 없는 경우는 적용하기 불가능한 방법

영상에서 제시하는 해결방법

차징 시스템 + 거리가 멀수록 더 높은 데미지 책정 (샷건과는 반대로!)

흥미롭게도 이미 이러한 시도들은 몇가지 게임에서 있어왔다.

차징시스템의 경우 팀포트리스 2 / 오버워치의 위도우메이커 스나이퍼 라이플에서 찾아 볼 수 있다.

거리에 반비례 하는 데미지 구간 적용의 경우 완벽히 같다고는 할 수는 없지만,

배틀필드 1의 "Sweet Spot" 시스템은 스나이퍼 라이플에 상체를 맞춰 원샷 원킬을 낼 수 잇는 거리 범위가 있어
근거리에서의 저격소총의 원샷 원킬 문제를 해결하고,
스윗스팟을 넘어가는 원거리 구간에서는 거리비례 데미지 감소를 적용하여,
배틀필드의 컨퀘스트 모드와 같이 Team Objective Oriented Game 에서 거점 점령에 참여하지 않고
베이스 캠핑 스나이퍼들에 대한 페널티를 주는 방식으로 팀플레이를 유도하는 방식을 따르고 있다.

https://youtu.be/mdCTkibt_zE

이처럼 다양한 게임에서 볼트액션 스나이퍼 라이플의 밸런스 문제를 해결하기 위해 다양한 시스템을 고려한다는 것은
그만큼 밸런스와 총기의 재미 사이에서 스나이퍼 라이플의 적당한 자리를 찾는다는게 어렵다는 뜻이다.

개인적으로 영상에 언급된 요소들 외에도, 저지력, 흔히 말하는 에임 펀칭도 하나의 방법이 될 수 있다고 생각한다.

근거리에서 스나이퍼와 다른 총기를 든 유저가 조우했을때 밸런싱 문제가 대두되는 이유는,
다른 총기를 가진 플레이어가 먼저 한발을 박았음에도 불구하고 볼트액션 스나이퍼 라이플은 TTK가 0ms이기 때문이다.

에임펀칭이 적용되는 시스템의 경우 먼저 한발을 박으면 스나이퍼 라이플을 들고 있는 유저의 조준이 강제로 흔들리기
때문에 패널티가 적용된다. 이 또한 중/근거리에서의 볼트액션 스나이퍼 라이플과 - 여타 총기들간 밸런스를
맞추는 방법이라고 생각한다.

iOS 초기 시절 iOS의 UI 디자인 철학은 스큐어모피즘이었다.

iOS 7 이후 윈도우 8의 메트로 UI와 함께 미니멀리즘이 새로운 UI의 대세로 자리잡게 되었고

그당시, 그러니깐 2014 즈음, 의미있게 읽었었던 기사 하나있었는데 즐겨찾기 링크가 만료되어 찾을수 없었으나

우연한 기회에 다시 접하게 되어 아카이빙을 목적으로 글로 옮기게 되었다.

스큐어모피즘과 미니멀리즘, 그리고 플랫 디자인에 관한 사설 컬럼이다.

원본 링크 : https://www.bloter.net/news/articleView.html?idxno=19134

아카이빙 : https://archive.md/cIUKW

하지만 그린버그의 모더니즘 미학이 디지털 디자인의 사용성 극대화를 담보해주지는 않는다. 가장 회화적인 것이 가장 이용자 친화적이지는 않기 때문이다.

아마 이 기사가 기억에 남았던 가장 큰 이유는 기사 말미에 있던 위와 같은 문구 때문이었던것 같다.

작성 일자 : 2021-09-30

원본 글 주소 : https://www.clien.net/service/board/use/16547636

아카이브 주소 : https://archive.md/l64el

작성 일자 : 2021-02-27

원본 글 주소 : https://www.clien.net/service/board/park/15926607

아카이브 주소 : https://archive.md/AkEsg

작성 일자 : 2020-11-11

원본 글 주소 : https://www.clien.net/service/board/park/15574688

아카이브 주소 : https://archive.md/JBTdY

작성 일자 : 2020-10-21

원본 글 주소 : https://www.clien.net/service/board/park/15499630

아카이브 주소 : https://archive.md/bXLgw

작성 일자 : 2020-10-17

원본 글 주소 : https://www.clien.net/service/board/park/15485679

아카이브 주소 : https://archive.md/dUBuh

작성 일자 : 2020-09-16

원본 글 주소 : https://www.clien.net/service/board/park/15390411

아카이브 주소 : https://archive.md/PW9Hq

작성 일자 : 2020-08-24

원본 글 주소 : https://www.clien.net/service/board/park/15309074

아카이브 주소 : https://archive.md/Y7F8B

작성 일자 :  2020-08-19

원본 글 주소 : https://www.clien.net/service/board/park/15291954

아카이브 주소 : https://archive.md/Xvksi

작성 일자 : 2020-06-28

원본 글 주소 : https://www.clien.net/service/board/park/15115510

아카이브 주소 : https://archive.md/efrzA

작성 일자 : 2020-05-05

원본 글 주소 : https://www.clien.net/service/board/park/14932691

아카이브 주소 : https://archive.md/Cucvy

작성 일자 : 2019-09-30

원본 글 주소 : https://www.clien.net/service/board/cm_mac/14091473

아카이브 주소 : https://archive.md/mil8D

작성 일자 : 2019-05-14

원본 글 주소 : https://www.clien.net/service/board/cm_mac/13488352

아카이브 주소 : https://archive.md/cuXDv

작성 일자 : 2019-03-21

원본 글 주소 : https://www.clien.net/service/board/cm_mac/13292358

아카이브 주소 : https://archive.md/tv2l3

작성 일자 : 2019-02-01

원본 글 주소 : https://www.clien.net/service/board/cm_mac/13119616

아카이브 주소 : https://archive.md/CdAr9

*순서는 절대적 순위가 아닌 생각나는 순으로 작성합니다.

1. 토스 유튜브 채널 |  https://www.youtube.com/@TOSSservice

"프로덕트"를 어떤 관점으로 보아야 하는지 너무나도 명쾌하고 단순하게 "정의" 해주는 인사이트를 옅볼수 있었던 채널

Toss Insight 재생목록
https://youtube.com/playlist?list=PL1DJtS1Hv1Piv_MQIHgA_CdNsXyDM9UDM

위 재생목록 외에도 개발, 디자인, 팀 컬쳐, 동기부여 등 다양한 분야에서 자극을 줄 수 있는 정보들이 많은 채널이기에
꼭 구독하기를 추천한다.

토스의 브랜치 채널인 머니그래피 또한 추천한다
https://www.youtube.com/@Moneygraphy

2. 배달의 민족 유튜브 채널 | https://www.youtube.com/@baemin_official
    우아한테크 유튜브 채널 | https://www.youtube.com/@woowatech

토스와 마찬가지로 배달의 민족 팀 내부의 여러가지 기술과 프로덕트 관점의 노하우를 전하는 채널

배달의 민족 채널에서는 영상 제목에 "[우아한형제들]" 태그가 달려있는 영상 위주로 찾아보면 PM 직군이나
프로덕트에 대한 인사이트에 관한 세미나를 쉽게 찾아 볼 수 있다.

3. EO 이오 유튜브 채널 | https://www.youtube.com/@eo_studio

IT 업계와 기술 트렌드, 스타트업 전반에 대한 인사이트들과 양질의 컨텐츠가 있는 채널

4. 나는 PM이다 유투브 채널 | https://www.youtube.com/@khanpm

PM이라는 직무가 정확히 무엇인지, 어떤 업무를 하고 어떤 사고 프로세스를 갖추어야 하는지 현업자의 입장에서 들을 수 있는 채널.

이전에 "프로젝트 매니저" 라는 유튜브 채널(https://www.youtube.com/channel/UCau_NLP8Tw_IuJoOZh0EwTw)을
한번 시도했지만 시원치않았는지 아니면 "프로덕트 매니저" 라는 아이덴티티에 맞게 다시 시작하려는지 모르겠지만
예전 채널에도 프로젝트 관리에 대한 몇가지 인사이트들을 찾아볼수 있으니 참고하여도 좋을것 같다.

확실히 예전 유튜브 채널의 운영 경험을 살려, 새로운 채널은 쇼츠나 알고리즘을 노린 영상 제작덕에
채널 접근성이 많이 좋아져 빠르게 성장하는 채널로 보이나, 넛지 패턴의 제목이나 썸네일이 정보 선별에
조금 방해를 주는 편.

5. 기획자 데이먼 유투브 채널 | https://www.youtube.com/@DamonCho

실무적인 부분에서 프로덕트의 기획, 분석, 데이터 리터러시, 기타 툴에 대한 노하우와 인사이트를 제공하는 채널

6. OJ Tube 유투브 채널 | https://www.youtube.com/@OJTube

기획자라기 보다는 개발자로서의 마인드셋에 대한 인생론적인(?) 관점에서 토크하는 채널
임베디드 개발자이자 업체 대표의 입장에서 어떤 자세를 가져야 할지 슈카월드 같은 느낌으로 영상이 올라오는데
지속해서 성장하는 개발자, 기획자가 되기위해 새겨들을만한 이야기들이 많아서 추천한다.

7. 성장하는 직장인들 | https://www.youtube.com/@growingworkers

브런치 https://brunch.co.kr/@kellypoly를 운영하고 있는 UI 디자이너 출신 CPO Kelly 와
벨로그 https://velog.io/@xunwk를 운영하고 있는 개발자/마케터 출신 PM Poco 의 팟캐스트 형식 유투브 채널

8. 게임캔버스-게임기획개발아카데미 | https://www.youtube.com/@user-hu1nx2lw7z

게임 기획에 대한 정보를 얻을 수 있는 채널

9. NDC : Nexon Developers Conference | https://www.youtube.com/@NDCKR/videos

넥슨 개발자 컨퍼런스

계속 추가 예정

학부생 시절, HCI와 UI/UX에 대한 고민을 진지하게 해본 적이 있다.
한창 전공공부에 대한 회의와 뭔가 다른것에 목말라 있던 때였고 무언가 만들어 내고 싶었던 때였다.
단순히 컴퓨터 공학 지식과 프로그래밍 문법을 외우는 것이 아니라, 무형의 아이디어를 실체화 하여 세상에 적극적으로
내놓고 싶어 하는 마음이 앞서던 시기였고, 디자인학과 복수전공을 고민해보던 때 였을 것이다.

이제와서 깨달은 것이지만, 결국 그러한 아이디어의 실체화를 효과적으로 구현하기 위해서 필요로 하던 지식을
학교에서 가르치고 있었던 것이었고 그러한 사실을 조금만 더 일찍 깨달았다면...학교 성적부터 시작하여
많은 것이 달라졌을 것이나... 당시에는 깨우치지 못했던 진리였거니와,
개인적인 생각으로는 여전히, 학교는 본질적으로 학문을 가르치는 곳이긴 하나 가르침에 앞서 필요성을 먼저 느끼도록
해주었다면 나와 같이 전공공부에 대해 회의를 느껴 시간을 낭비하는 사람들이 많이 줄지 않았을까 하는 아쉬움 또한 있다.

아무튼 그때 당시 나는 HCI라는 학문과 UI/UX에 대하여 관심이 많았었고, HCI (Human - Computer Interaction)가
궁극적으로 이루고자 하는 목적이 무엇인지, UI와 UX는 무엇인지, 그 과정에서 프로그래머가 맡아야 할 역할은
무엇인지에 대하여 진지하게 고민해본 시간을 가졌고 내가 내린 결론은 기술은 결국 인간이 인간을 위해 만들어낸 것이고,
그"기술" 이라는 것의 궁극적인 목적은 인간을 이롭게 하는 것에 있다고 생각하였다.

그렇기에 프로그래머로서, 우리는 흔히 말하는 공돌이, 이과적인 마인드를 가지고 문제를 해결하려는 본능이 있긴 하지만
결국 그 끝에 궁극적으로 이뤄내고자 하는 것은 "사람을 위한 기술의 실현"이기에 인문학의 영역으로 향한다고 생각한다.

따라서 내가 당시 프로그래머란 무엇이고 어떠한 역할을 맡아야 하는가에 대한 결론은 다음과 같았다.

"기술의 구현으로 인문학을 실체화 하는 직업"

Krafton Jungle 1기 과정을 마치고, 취업에 앞서서 여러 회사들의 JD와 지향점을 찾아보면서 다시금 어떤 개발자가 되고
싶은가에 대해 진지하게 고민해볼 시간을 가졌고 그 과정중 많은 도움이 되었던 위대한 프로그래머들의 인터뷰 영상들과
그 내용을 추려 소개해보려고 한다.

• John Carmack : 무엇이 좋은 개발자를 만드는가
• James Gosling : 열심히 일하는 것의 가치 / Risk Taking / 개발자의 윤리 의식
• George Hotz : 코딩을 배우는 가장 좋은 방법
• Travis Oliphant : 좋은 프로그래머가 갖추어야 할 요소

출처 : https://www.youtube.com/@lexfridman

John Carmack : 무엇이 좋은 개발자를 만드는가 / 워라밸에 대하여

무엇이 좋은 개발자를 만드는가(33:00)

Q. Given that you are once again, one of the greatest programmer ever,
what do you think makes a good programmer?


특정 아키텍처, 기술, 코드 시퀀스에 대한 지식을 얻는 것은 개인적으로 도파민 넘치는 즐거운 일이겠지만
그보다 상위의 중요한 것은 가치 있는 것을 빌드 하는 것이다.
진부하게 들릴 수도 있겠지만, 이러한 행동들이야말로 더 좋은 세상을 만드는 노력들이라고 생각한다.
사람들이게 더 멋진 가치를 제공하는 것 말이다.
당신의 제품 덕분에 사람들의 삶이 개선되고 그 과정중에 해당 제품을 경제적으로 생산했다면 정말 멋진 일 일것이다.

워라밸에 대하여(50:52)

Q. Well, let me ask you about this, then. The mythical "Work life balance".
For engineer, its seems like thats one of the professions for programmer
where working hard does lead to greater productivity,
but it also raise the question of personal realationships all that kinda stuff, family and...
How are you able to find "Work life balance"?
Is there advice you can give, maybe even outside of yourself,
have you been able to arrive at any wisdom of this part in your years of life?

"일과 삶의 균형 (워라밸)" vs "일생의 업" 이라고 한다면, 적은 수의 숫자이지만 본인의 일에 몰두하고
집착하는 사람들이 존재한다.
그리고 이러한 집착에 가까운 몰입이 사실 진짜 일을 해내곤 한다. 

James Gosling : 열심히 일하는 것의 가치 / Risk Taking / 개발자의 윤리 의식

열심히 일하는 것의 가치(56:14)

사람들은 "힘들게 일하지" 말고 "똑똑하게 일하라"고 하는데 ("Work smarter, not harder"), 그것은 사실이 아니다.
그렇게 하다간 망하기 마련이지.

Risk Taking (1:48:37)

리스크를 두려워 하지 말아야 한다. 살다가 멍청한 일 한번쯤 해봐도 된다.

개발자의 윤리의식(1:49:08)

삶의 윤리적인 선택에 대해서 생각하곤 한다. 개인적으로 공상과학의 팬인데, 내가 내리는 기술적인 선택들이
과연 "블레이드 러너"를 만드는지 "스타트렉"을 만드는지 우리가 어떠한 미래를 만들고 있는지 생각해봐야 한다.

George Hotz : 코딩을 배우는 가장 좋은 방법

- 해결하고자 하는 문제를 갖는 것, 즉 문제를 해결하기 위해 배우는 것

코딩을 배우는 가장 좋은 방법(2:46:14)

Q. Do you have a noob friendly advice on how to get into programming?

"프로그래밍을 배우자" 영상으로는 절대 프로그래밍을 배울 수 없다.
내 생각에 프로그래밍을 배우는 유일한 방법은 - 내가 아는 프로그래밍 잘하는 사람은, 다들 "다들" 이렇게 배웠다.
그들이 하고 싶은 일이 있었고, 이걸 어떻게 하지..컴퓨터가 해주면 좋을텐데…하다가 계속 노력을 하면서 배우는것.

Travis Oliphant : 좋은 프로그래머가 갖추어야 할 요소

좋은 프로그래머가 갖추어야 할 요소(2:47:20)

Q.What are some from programmer perspective, what makes a good programmer?
What makes a productive programmer?
Is there advice you can give to be a great programmer?

그중 첫번째는 호기심이다. 호기심이 없는 프로그래머는 글쎄… 지루하지.
일에 관심도 없고, 잘 하지도 못할 것이고.

두번째로는, 모든걸 혼자 다 한번에 하려고 하지 말아라. 사람으로서 각자 한계가 있다는 것을 알아야 한다.

다른 사람의 코드 쓰는 것? 너무 두려워 하진 말아라. 혼자서 모두 다 써야 하는건 아니라고. 누구도 그렇게 안한다.
복사-붙여넣기는 할 수 있다. 하지만 이해는 하고 해야겠지. 아 이 코드는 이런걸 하는구나. 할 수 있는 만큼 이해는 해야겠지.
여기서 중요하게 작용 하는것이 호기심이다. 그냥 대충 눈감고 복사-붙여넣기 하는건 좋은 자세는 아니다.

About hiring (3:00:55)

사람을 볼 때, "배우고자 하는 의지" 가 있는지를 본다. 우리가 항상 하는 일은 결국 "배우는 것"이다.
본인이 이미 다 안다고 생각한다면 결국 문제가 생길 것이다.

E.O.F.

Situation: 일어난 상황을 설명
Task: 상황에서의 목표나 해결해야 할 문제를 정의
Action: 목표나 문제를 해결하기 위해 취한 행동을 서술
Result: 취한 행동으로 인해 얻은 결과를 서술

얻을 수 있는 효과

• 추후 문제 해결 능력과 성과를 객관적으로 평가 할 수 있는 기록이 됨
• 목표를 달성하기 위해 취한 행동을 자세히 서술함으로써, 향후 비슷한 상황에서도 적극적으로 대처할 수 있는 기록

넓은 시야를 가져야 한다.

    - 다른 직군들의 가동 범위를 파악.
    - 주어진 조건(기술적, 경제적, 시간적)들의 한계를 파악.

    그 안에서 최선의 결과를 뽑아내는 것이 기획.

커뮤니케이션 능력

    - 최선의 결과를 뽑아내기 위해 환경변수들을 잘 파악하고, 기획한 내용을 효과적으로 전달하기 위해서는 필수적인 요소.

문서화 능력

    - 아이디어는 추상적이고, 말은 왜곡되기 쉽다.
    - 체계화된 문서화를 통해 아이디어를 텍스트화 하고, 전달하기 쉬운 형태로 만드는 것이 곧 문서화.

플랫폼의 변화를 눈여겨 보아야 한다

    앞서 말한 조건들이 팀 내부에서 기획자로서의 역할을 위한 능력들이라면, 이것은 기획 자체로 좋은 기획을 이끌어 내기 위한 능력
    - 게임으로 예를 들면, MMORPG - 모바일 플랫폼 -> ??? 다음 대세는 무엇인가 라는 선구안을 가지기 위해서는
      이러한 플랫폼변화, 즉 시장의 니즈와 방향이 어떤 쪽으로 흘러가고 있는 가에 대한 기민한 통찰력이 필요.

Pose Estimation & Landmark Extraction

1. 영상 처리 : OpenCV
2. Landmark 추출 : Google MediaPipe (https://google.github.io/mediapipe/solutions/pose.html)
   

1 Frame 당 33개 Landmark Data에 대해

• X : Landmark의 X 축 좌표. [0:1] 의 값으로 Normalized

• Y : Landmark의 Y 축 좌표. [0:1] 의 값으로 Normalized

• Z : 카메라와 수직을 이루며 피사체의 left_hip - right_hip 사이의 원점을 통과하는 가상의 depth 좌표.
       카메라와 가까운 쪽으로 음수 값을 가지는 Experimental 한 값

• V (Visibility) Factor : [0:1]의 값을 가지며 Landmark에 대한 가시성을 나타내는 값.
                                     (가려져 표시되지 않는다면 0)

영상 전체를 Frame by Frame으로 순회하며 Landmark 추출 Pandas 파이썬 패키지 이용 Dataframe 으로 담아 csv파일로 저장

https://youtu.be/OjCwLatUff8

https://youtu.be/iZMHllJtqsI

Vectorization

요가 영상은 고정된 특정 포즈를 취하는 Posing 구간과 A포즈에서 B포즈로 포즈가 바뀌는 Transition 구간으로 나누어짐.
즉, Landmark의 “변화량”을 기준으로 정적인 구간을 구분해 낼 수 있다고 추론.

따라서, X,Y 축 랜드마크 데이터를 가지고 변화량 데이터를 생성.(Z축 데이터는 제외)

1. 가려서 보이지 않는 Landmark 값 = 신뢰도가 떨어진다고 판단 Vector 그래프의 Jitter의 요소를 줄이기 위해
    Visibility Factor를 데이터에 가중치로 활용하기로 함

변화량 값에 곱해줄 가중치로 사용하려고 하기에 벡터 연산에 쓰일 두 Landmark 값중 하나라도 신뢰성이 떨어지면 연산된 벡터 값도 신뢰성이 떨어질거라고 판단, 더 작은 V-factor로 가져와서 Dimension Matching

2. X 축 33개 Landmark Column ——— Concatenate——— Y 축 33개 Landmark Colum

• DataFrame 1칸 Shift하여 Diff값 구한뒤, Dimension Matching된 V-Factor DataFrame 참조하여 V-Factor값이 0.9 이하인 값에 대하여 Landmark Data 0으로 치환.

3. V값 가중치 적용된 Concatenated DataFrame에 대해 Euclidean vector 연산 통해 Vectorization 하여 X축, Y축 각 33개 Landmark에 대한 벡터요소를 하나의 벡터로 합산

4. 합산된 벡터 데이터를 표준편차(std) = 1 , 평균(mean) = 0을 갖도록 하는 Standard Normalization 으로 정규화

Smoothing

Smoothing Method

1. Savitzky-Golay aka.SAVGOL Filter (사비츠키-골레이) (scipy.signal) <- 해당 필터로 진행

 

2. Moving Average Method

    a. SMA : Simple Moving Average Method

b. CMA : Cumulative Moving Average Method

c. EMA : Exponential Moving Average Method

3. Gaussian Filter

Posing 구간 분리

1. Peak Find (scipy.signal)

전제1 : Peak 기준으로 나눠진 왼쪽, 오른쪽 구간은 서로 다른 포즈이다.

전제2 : Peak 사이 구간의 Status는 2가지로 구별된다.
    - Transition Only (Cluster에 앞서서 pre-processing 통해 제거)
    - Posing + Transition (Clustering 통해 구별 가능)

2. Pre-processing : Peak to Peak 구간의 분류

핵심 전제 : 운동 영상의 경우 Posing 을 유지하는 시간이 Pose가 전환되는 Transition 시간 보다 압도적으로 길다.

*Standard Normalization 을 거치면 전체 데이터의 mean = 0 , std = 1 로 정규화 된다.
→ Posing 구간에서는 변화량이 적기 때문에 Flatten 구간의 데이터는 -1 에 가깝게 분포되어 있다.

만약 Peak to Peak 구간에 Posing 구간이 포함되어 있다면 아래의 식을 만족한다.

(Peak to Peak 구간의 mean 값) - (Peak to Peak 구간 std) < -1

그렇지 않다면, 해당 구간은 Transition 상태만 있는 구간 일 것이다.

3. Clustering (K-means (scikit-learn)) :  Posing 과 Transition이 혼재되어 있는 구간에서의 분류

기본적으로 변화량 데이터를 다루고 있기에, Transition 구간의 데이터 값들의 군집은
Flatten 구간(Posing)의 군집보다 더 큰 값을 가진다.

핵심 전제에 의해, 구간의 mean 값에 대해 Posing 군집의 기여도가 훨씬 크므로, 분류된 두개의 군집에서
최대값을 가지는 데이터를 군집의 대표 데이터로 선택한뒤,
구간 mean값 과의 거리가 먼 군집을 Transition 군집으로, 가까운 군집을 Posing 군집으로 본다.

4. Posing 구간 추출

변화량 데이터 또한 시계열 데이터이므로 Posing 군집에서 x축 최소 값과, x 축 최대값 데이터가
곧 영상에서의 Posing 구간의 시작 프레임과 끝 프레임이다.

https://google.github.io/mediapipe/solutions/pose.html#static_image_mode

STATIC_IMAGE_MODE = True / False
기본값 = False
False 일 경우 솔루션은 입력 이미지를 비디오 스트림으로 취급합니다.
첫번째 이미지에서 가장 두드러진 사람을 기준으로 랜드마크 추출을 지역화하여
후속이미지에서 화면상에서 인물 탐지를 잃을때 까지 해당 랜드마크를 기준으로 트래킹하여 계산과 지연시간을 줄인다.
True일 경우 매 입력 프레임마다 화면상에서 사람이 어디있는지 탐지하며, 정적이고 서로 연관되지 않은 일련의 이미지를 처리하는데 적합

MODEL_COMPLEXITY  = 0 / 1 / 2
기본값 = 1
포즈랜드마크 모델의 복잡성
랜드마크의 정확도와 추론대기 시간은 모델 복잡도가 올라갈수록 증가

SMOOTH_LANDMARKS = True / False
기본값 = True
True 일 경우, 솔루션은 지터를 줄이기 위해 각각의 인풋 프레임에 대해 필터링
STATIC_IMAGE_MODE에서는 True로 설정되어 있더라도 무시됨.

MIN_DETECTION_CONFIDENCE = [0.0 ~ 1.0]
기본값 = 0.5
화면 상에서 사람을 탐지하는 모델의 최소 신뢰 정확도. (화면상에서 사람이 있다고 판단하는 Threshold 값)

MIN_TRACKING_CONFIDENCE
기본값 = 0.5
포즈 랜드마크를 추적하기 위한 랜드마크-추적 모델의 최소 신뢰 정확도. (랜드마크 추적에 대한 Threshold 값)
설정 값 이하로 떨어지면 랜드마크 추적을 놓쳤다고 간주하고 해당 화면에서 사람 탐지를 다시 함.
값이 높을 경우 레이턴시가 길어지는 대신 솔루션에 대한 Robust를 높게 가져갈 수 있다.
STATIC_IMAGE_MODE 가 True 일때는 연관되지 않은 일련의 이미지라는 가정하에 기본적으로 매 프레임에 대해
새롭게 화면상의 사람 위치를 탐지하기 때문에 무시된다.

Sample Code for Config Options

import cv2
import mediapipe as mp
mp_drawing = mp.solutions.drawing_utils
mp_drawing_styles = mp.solutions.drawing_styles
mp_pose = mp.solutions.pose

# For static images:
IMAGE_FILES = []
BG_COLOR = (192, 192, 192) # gray
with mp_pose.Pose(
    static_image_mode=True,
    model_complexity=2,
    enable_segmentation=True,
    min_detection_confidence=0.5) as pose:
  for idx, file in enumerate(IMAGE_FILES):
    image = cv2.imread(file)
    image_height, image_width, _ = image.shape
    # Convert the BGR image to RGB before processing.
    results = pose.process(cv2.cvtColor(image, cv2.COLOR_BGR2RGB))

    if not results.pose_landmarks:
      continue
    print(
        f'Nose coordinates: ('
        f'{results.pose_landmarks.landmark[mp_pose.PoseLandmark.NOSE].x * image_width}, '
        f'{results.pose_landmarks.landmark[mp_pose.PoseLandmark.NOSE].y * image_height})'
    )

    annotated_image = image.copy()
    # Draw segmentation on the image.
    # To improve segmentation around boundaries, consider applying a joint
    # bilateral filter to "results.segmentation_mask" with "image".
    condition = np.stack((results.segmentation_mask,) * 3, axis=-1) > 0.1
    bg_image = np.zeros(image.shape, dtype=np.uint8)
    bg_image[:] = BG_COLOR
    annotated_image = np.where(condition, annotated_image, bg_image)
    # Draw pose landmarks on the image.
    mp_drawing.draw_landmarks(
        annotated_image,
        results.pose_landmarks,
        mp_pose.POSE_CONNECTIONS,
        landmark_drawing_spec=mp_drawing_styles.get_default_pose_landmarks_style())
    cv2.imwrite('/tmp/annotated_image' + str(idx) + '.png', annotated_image)
    # Plot pose world landmarks.
    mp_drawing.plot_landmarks(
        results.pose_world_landmarks, mp_pose.POSE_CONNECTIONS)

# For webcam input:
cap = cv2.VideoCapture(0)
with mp_pose.Pose(
    min_detection_confidence=0.5,
    min_tracking_confidence=0.5) as pose:
  while cap.isOpened():
    success, image = cap.read()
    if not success:
      print("Ignoring empty camera frame.")
      # If loading a video, use 'break' instead of 'continue'.
      continue

    # To improve performance, optionally mark the image as not writeable to
    # pass by reference.
    image.flags.writeable = False
    image = cv2.cvtColor(image, cv2.COLOR_BGR2RGB)
    results = pose.process(image)

    # Draw the pose annotation on the image.
    image.flags.writeable = True
    image = cv2.cvtColor(image, cv2.COLOR_RGB2BGR)
    mp_drawing.draw_landmarks(
        image,
        results.pose_landmarks,
        mp_pose.POSE_CONNECTIONS,
        landmark_drawing_spec=mp_drawing_styles.get_default_pose_landmarks_style())
    # Flip the image horizontally for a selfie-view display.
    cv2.imshow('MediaPipe Pose', cv2.flip(image, 1))
    if cv2.waitKey(5) & 0xFF == 27:
      break
cap.release()

1. 강렬한 도입문구
2. 당신의 아이디어가 해결할 실존하는 문제들에 대한 공감되는 스토리텔링
3. 당신의 아이디어가 어떤식으로 문제를 해결 할 수 있을 것인가에 대한 설명. 아이디어에 대한 시각적인 설명을 포함 할 것.
4. 당신의 아이디어 만이 가지는 특별한 점을 설명. 사용자를 확보하고 이익을 창출 할 수 있는 견고한 계획을 설명.
5. 지금까지 성취한 점을 설명하고 앞으로 나아갈 비젼을 설명
6. 당신의 팀이 이 아이디어를 진행시키기에 왜 최고의 선택인지 설명
7. 아이디어 피칭의 궁극적인 목표(투자 유치, 고객 유치, 파트너쉽 채결 등)를 위한 요청
8. 전체 설명에 대한 요약 정리
9. 감사 표하기
   
   
• 확신있고 직접적인 어구를 사용하기.
• 연습하기. 대본있는 피칭은 확신이 없어 보인다.
• 효과적인 프레젠테이션 자료를 준비할것. Infographic 등은 효과적인 설명 자료이다.
  프레젠테이션 자료는 발표할 내용의 반복이 아닌, 발표 내용에 얹어질 내용을 준비할것.
• 자신감 있는 자세를 유지할것.
• 자연스러운 바디 랭귀지를 사용할것. 
  
  

sudo apt install nodejs

sudo apt install npm

쉬운 node 버전 변경을 위한 nvm (node version manager) 설치

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.3/install.sh | bash

source ~/.bashrc

node 버전 리스트

nvm list-remote

nvm install v16.19.0

설치된 노드 버전간 변경

nvm use v16.19.0

vue cli 설치

npm install -g @vue/cli

electron 설치

npm install electron --save-dev

만든 vue app electron으로 빌드하기

vue add electron-builder

electron으로 빌드한 앱 실행

npm run electron:serve