Untitled

[likejazz]

저출산 문제

출산을 포기하는 이들을 볼때마다 안타까움을 느낌.

자식을 키운다는 게 얼마나 숭고하고 아름다운 일인데 인생에서 경험해보지 못한다면 정말 안타까운 일.

육아를 사회 문제와 결부시켜 비판만 하는 건 매우 한심. 기본적으로 육아는 부모가 책임지는 것이며 사회는 그 다음. 다들 눈 높이가 북유럽 기준으로 지나치게 높은게 문제. 우리 할머니는 전쟁통에도, 국가가 무너진 상황에서도 자식을 놓고 장성하게 키우셨음. 우리가 여기서 포기하지 않고 좀 더 노력한다면 다음 세대에는 훨씬 더 좋은 환경을 물려줄 수 있을 것.

시대가 변한 만큼 아빠도 육아에 참여해야 한다는 데는 적극 공감. 육아는 엄마만의 문제가 아니며 부모 모두의 공통된 문제이기 때문. 나 또한 자식에게 아빠로서 최선을 다하기 위해 끊임없이 노력 중.

자식을 키운다는건 인생의 많은 부분을 포기해야 하는 어려운 문제임은 분명. 하지만 포기한 부분을 능가하는 위대하고 숭고한 가치가 반드시 따라올 것 임.

아직도 출산을 포기하겠다면 다시 한 번 생각해보길. 육아의 숭고한 가치를 위해. 부모라는 위대한 인생의 가치를 위해. 나아가 국가의 발전과 인류의 존속을 위해.

[wonnyz]

평소 기술적으로 좋은 글을 많이 올려주는 분이긴 한데 뜬금없는 이 꼰대글은 대체 뭘까. 육아의 숭고한 가치, 부모라는 위대한 인생의 가치에 모든 이가 공감할 필요가 있을까. 국가의 발전과 인류의 존속을 왜 개인이 생각해야 하는가.

육아를 마치 게임으로 생각하는 모양인데, 이건 마치 군대 다녀온 사람들이 부조리와 고생을 아름다운 추억으로 미화해서 기억하면서 한번쯤 해볼만하다 하는 말을 보는 기분. 군대는 2년으로 끝나지, 육아는 아이가 성인으로 성장할 때까지 그 열배가 필요하며 관련된 사람들의 인생이 바뀌는 일인데 어쩜 저렇게 쉽게 말할까.

국가의 발전과 인류의 존속을 위해 반드시 해야 하는 것이라면서 육아는 기본적으로 부모가 책임지는 것이라니 과연 저 주장에 논리라는게 존재는 하는 것인지 의심스러움. 나이가 들면 저렇게 되나 싶어서 나도 두렵다.

[likejazz]

개인은 국가 발전과 인류 존속을 생각하지 않아도 되는 존재인가요? 어느 누가 육아를 게임과 비유하나요? 그런 내용이 어디에 있나요? 왜 제가 쉽게 얘기한다고 생각하죠?

기본적으로 육아는 개인의 가치와 책임이라고 얘기했고 “나아가” 국가 발전과 인류 존속을 위한다고 얘길 했는데 앞뒤 빼먹고 필요한 부분만 얘기하는군요. 그나마 제 얘길 인용한 게 이 정도고 나머진 본인이 마음대로 해석하고 생각하는 거 같아요. 저는 육아를 게임에도 군대에도 비유한적 없고 하고 싶지도 않아요. 스스로 규정한 꼰대, 나이 프레임에 가둬놓고 무턱댄 비난이 아쉽습니다.

[wonnyz]

개인은 국가 발전과 인류 존속을 생각하지 않아도 되는 존재인가요?

‘개인이 왜 그것을 생각해야 하느냐'는 ‘개인은 그것을 생각하지 마라'가 아님. 생각하고 싶으면 하면 됨. 하지 말라고 한 적 없음. 댁이랑 생각이 다르다고 어설프게 비난하지 말라는 말임.

어느 누가 육아를 게임과 비유하나요? 그런 내용이 어디에 있나요? 게임은 오버했다는 것을 인정하겠음.

왜 제가 쉽게 얘기한다고 생각하죠?

“안타까움을 느낌.”

“비판만 하는 건 매우 한심.”

“육아는 부모가 책임지는 것이며 사회는 그 다음.”

“우리가 여기서 포기하지 않고 좀 더 노력한다면”

“우리 할머니는 전쟁통에도, 국가가 무너진 상황에서도 자식을 놓고 장성하게 키우셨음.”

다른 사람이 왜 그런 선택을 했을까 조금 더 깊게 생각했다면 이런 말이 쉽게 나올 수 있을까? 하도 어이가 없어서 풀 텍스트가 기억이 안났는데, 역시나 “우리 할머니는 고생했는데 너희는 왜 그걸 못함?” 이야기 나왔었네…

기본적으로 육아는 개인의 가치와 책임이라고 얘기했고 “나아가” 국가 발전과 인류 존속을 위한다고 얘길 했는데

다시 한번, 그게 개인의 가치와 책임이라는 것을 아는 사람이, 육아로 인하여 포기해야 하는 것들 때문에 육아를 포기한다는 사람들의 선택을 저렇게 쉽게 비난할 수 있는지 궁금함.

저는 육아를 게임에도 군대에도 비유한적 없고 하고 싶지도 않아요.

군대 이야기가 왜 나왔는지 정말 몰라서 하는 말인지? “나 또한 자식에게 아빠로서 최선을 다하기 위해 끊임없이 노력 중” 이라고 했는데, 본인이 육아휴직 하고 몇 달 직접 키워보고서 육아의 숭고함이 얼마나 위대한데 그걸 포기하냐고 훈계질을 하는 것인지?

백일된 아이가 갑자기 밤에 울어서 응급실로 들쳐업고 가고, 새벽잠을 못자서 주말에 겨우 보충하는 바람에 주중에는 부시시하고, 멀쩡한 직장인이었다가 집에 하루종일 말 못하는 아이와 함께 있는 아내는 없던 우울증이 생기려고 하는 것이 지나가면 아름답고 숭고한 일이 된다는 식인데, 이게 마치 군생활처럼 지나가고 난 다음에는 추억만 남는 그런 것이냐는 뜻임. 못알아들었으면 어쩔 수 없음.

다른 사람의 결정을 “안타깝다, 한심하다” 라고 하면서 근거로 “더 고생한 사람도 있는데”, “이게 얼마나 숭고한 것인데"를 들고, 결국은 개인 탓으로 돌리면서 스스로는 꼰대가 아니라고 주장하는 글 잘 봤음. 꼰대가 스스로를 꼰대라고 인정하는 것을 별로 본 적이 없으니 놀랍지는 않음.

[likejazz]

언제 봤다고 갑자기 뜬금없는 반말부터 당황스럽네요. 이미 정상적인 토론은 어려워 보이고, 사회에 불만이 가득한 전형적인 모습을 보는듯 하여 참으로 안타깝습니다.

육아가 군생활처럼 지나고 나면 추억에 불과하다는 비유에 안타까울 뿐이고 손해보거나 고생할 수 없다는 만연한 이기주의는 아쉽습니다. 제 글은 어디까지나 개인의 생각을 제 공간에 적은 것일 뿐 훈계나 강요는 아니므로 오해 없길 바라며 '나'라는 존재를 위해 우리 부모님은 얼마나 헌신하셨을지 한 번쯤 생각해볼 기회가 있길 바래요. (마지막에 또 꼰대같은 얘길해서 미안하네요.)

[wonnyz]

서로 볼 일이 없을 것 같으니 마지막 글이 될 것 같은데, '뜬금없는 반말'에서 잠시 허탈하게 웃고 시작함. 이래서 차라리 한국어에 존댓말을 없애버려야 할텐데. 사회에 불만이 많지만 나름 성실하게 사회에 낼 거 다 내고 할 거 다 하고 살고 있다고 생각함. 적어도 내 다음 세대는 내 세대에서 한 고생을 똑같이 겪지 않았으면 좋겠음.

내가 한 고생이 나름 보람이 있었다고 해서 그걸 왜 다른 사람도 했으면 좋겠다고 생각하는지, 다른 사람이 선택한 것을 비난할 때는 자신의 글도 비난을 받을 수 있다는 것을 좀 고려하고 글을 쓰면 처음부터 그렇게 공격적인 글이 나올 수 없지 않았을까.

'나'라는 존재를 위해 우리 부모님이 얼마나 헌신하셨을까 한번쯤 생각해본다면, 내 자식이 나보다 더 나은 미래를 얻을 수 있다는 확신이 없다면 애초에 그런 길을 선택하지 않겠다는 다른 사람의 결심을 조금이라도 존중할 수 있게 되기를 바람. 다시 한번 말하지만, 다른 사람을 스스로의 어설픈 잣대로 쉽게 재지 않았으면 좋겠음. 댁이 꼰대같다는 생각을 그것 때문에 한 것이니까.

[likejazz]

저출산 문제

출산을 포기하는 이들을 볼때마다 안타까움을 느낌.

자식을 키운다는 게 얼마나 숭고하고 아름다운 일인데 인생에서 경험해보지 못한다면 정말 안타까운 일.

육아를 사회 문제와 결부시켜 비판만 하는 건 매우 한심. 기본적으로 육아는 부모가 책임지는 것이며 사회는 그 다음. 다들 눈 높이가 북유럽 기준으로 지나치게 높은게 문제. 우리 할머니는 전쟁통에도, 국가가 무너진 상황에서도 자식을 놓고 장성하게 키우셨음. 우리가 여기서 포기하지 않고 좀 더 노력한다면 다음 세대에는 훨씬 더 좋은 환경을 물려줄 수 있을 것.

시대가 변한 만큼 아빠도 육아에 참여해야 한다는 데는 적극 공감. 육아는 엄마만의 문제가 아니며 부모 모두의 공통된 문제이기 때문. 나 또한 자식에게 아빠로서 최선을 다하기 위해 끊임없이 노력 중.

자식을 키운다는건 인생의 많은 부분을 포기해야 하는 어려운 문제임은 분명. 하지만 포기한 부분을 능가하는 위대하고 숭고한 가치가 반드시 따라올 것 임.

아직도 출산을 포기하겠다면 다시 한 번 생각해보길. 육아의 숭고한 가치를 위해. 부모라는 위대한 인생의 가치를 위해. 나아가 국가의 발전과 인류의 존속을 위해.

[wonnyz]

평소 기술적으로 좋은 글을 많이 올려주는 분이긴 한데 뜬금없는 이 꼰대글은 대체 뭘까. 육아의 숭고한 가치, 부모라는 위대한 인생의 가치에 모든 이가 공감할 필요가 있을까. 국가의 발전과 인류의 존속을 왜 개인이 생각해야 하는가.

육아를 마치 게임으로 생각하는 모양인데, 이건 마치 군대 다녀온 사람들이 부조리와 고생을 아름다운 추억으로 미화해서 기억하면서 한번쯤 해볼만하다 하는 말을 보는 기분. 군대는 2년으로 끝나지, 육아는 아이가 성인으로 성장할 때까지 그 열배가 필요하며 관련된 사람들의 인생이 바뀌는 일인데 어쩜 저렇게 쉽게 말할까.

국가의 발전과 인류의 존속을 위해 반드시 해야 하는 것이라면서 육아는 기본적으로 부모가 책임지는 것이라니 과연 저 주장에 논리라는게 존재는 하는 것인지 의심스러움. 나이가 들면 저렇게 되나 싶어서 나도 두렵다.

[likejazz]

개인은 국가 발전과 인류 존속을 생각하지 않아도 되는 존재인가요? 어느 누가 육아를 게임과 비유하나요? 그런 내용이 어디에 있나요? 왜 제가 쉽게 얘기한다고 생각하죠?

기본적으로 육아는 개인의 가치와 책임이라고 얘기했고 “나아가” 국가 발전과 인류 존속을 위한다고 얘길 했는데 앞뒤 빼먹고 필요한 부분만 얘기하는군요. 그나마 제 얘길 인용한 게 이 정도고 나머진 본인이 마음대로 해석하고 생각하는 거 같아요. 저는 육아를 게임에도 군대에도 비유한적 없고 하고 싶지도 않아요. 스스로 규정한 꼰대, 나이 프레임에 가둬놓고 무턱댄 비난이 아쉽습니다.

[wonnyz]

개인은 국가 발전과 인류 존속을 생각하지 않아도 되는 존재인가요?

'개인이 왜 그것을 생각해야 하느냐'는 '개인은 그것을 생각하지 마라'가 아님. 생각하고 싶으면 하면 됨. 하지 말라고 한 적 없음. 댁이랑 생각이 다르다고 어설프게 비난하지 말라는 말임.

어느 누가 육아를 게임과 비유하나요? 그런 내용이 어디에 있나요? 게임은 오버했다는 것을 인정하겠음.

왜 제가 쉽게 얘기한다고 생각하죠?

"안타까움을 느낌."

"비판만 하는 건 매우 한심."

"육아는 부모가 책임지는 것이며 사회는 그 다음."

"우리가 여기서 포기하지 않고 좀 더 노력한다면"

"우리 할머니는 전쟁통에도, 국가가 무너진 상황에서도 자식을 놓고 장성하게 키우셨음."

다른 사람이 왜 그런 선택을 했을까 조금 더 깊게 생각했다면 이런 말이 쉽게 나올 수 있을까? 하도 어이가 없어서 풀 텍스트가 기억이 안났는데, 역시나 "우리 할머니는 고생했는데 너희는 왜 그걸 못함?" 이야기 나왔었네...

기본적으로 육아는 개인의 가치와 책임이라고 얘기했고 “나아가” 국가 발전과 인류 존속을 위한다고 얘길 했는데

다시 한번, 그게 개인의 가치와 책임이라는 것을 아는 사람이, 육아로 인하여 포기해야 하는 것들 때문에 육아를 포기한다는 사람들의 선택을 저렇게 쉽게 비난할 수 있는지 궁금함.

저는 육아를 게임에도 군대에도 비유한적 없고 하고 싶지도 않아요.

군대 이야기가 왜 나왔는지 정말 몰라서 하는 말인지? "나 또한 자식에게 아빠로서 최선을 다하기 위해 끊임없이 노력 중" 이라고 했는데, 본인이 육아휴직 하고 몇 달 직접 키워보고서 육아의 숭고함이 얼마나 위대한데 그걸 포기하냐고 훈계질을 하는 것인지?

백일된 아이가 갑자기 밤에 울어서 응급실로 들쳐업고 가고, 새벽잠을 못자서 주말에 겨우 보충하는 바람에 주중에는 부시시하고, 멀쩡한 직장인이었다가 집에 하루종일 말 못하는 아이와 함께 있는 아내는 없던 우울증이 생기려고 하는 것이 지나가면 아름답고 숭고한 일이 된다는 식인데, 이게 마치 군생활처럼 지나가고 난 다음에는 추억만 남는 그런 것이냐는 뜻임. 못알아들었으면 어쩔 수 없음.

다른 사람의 결정을 "안타깝다, 한심하다" 라고 하면서 근거로 "더 고생한 사람도 있는데", "이게 얼마나 숭고한 것인데"를 들고, 결국은 개인 탓으로 돌리면서 스스로는 꼰대가 아니라고 주장하는 글 잘 봤음. 꼰대가 스스로를 꼰대라고 인정하는 것을 별로 본 적이 없으니 놀랍지는 않음.

[likejazz]

저출산 문제

출산을 포기하는 이들을 볼때마다 안타까움을 느낌.

자식을 키운다는 게 얼마나 숭고하고 아름다운 일인데 인생에서 경험해보지 못한다면 정말 안타까운 일.

육아를 사회 문제와 결부시켜 비판만 하는 건 매우 한심. 기본적으로 육아는 부모가 책임지는 것이며 사회는 그 다음. 다들 눈 높이가 북유럽 기준으로 지나치게 높은게 문제. 우리 할머니는 전쟁통에도, 국가가 무너진 상황에서도 자식을 놓고 장성하게 키우셨음. 우리가 여기서 포기하지 않고 좀 더 노력한다면 다음 세대에는 훨씬 더 좋은 환경을 물려줄 수 있을 것.

시대가 변한 만큼 아빠도 육아에 참여해야 한다는 데는 적극 공감. 육아는 엄마만의 문제가 아니며 부모 모두의 공통된 문제이기 때문. 나 또한 자식에게 아빠로서 최선을 다하기 위해 끊임없이 노력 중.

자식을 키운다는건 인생의 많은 부분을 포기해야 하는 어려운 문제임은 분명. 하지만 포기한 부분을 능가하는 위대하고 숭고한 가치가 반드시 따라올 것 임.

아직도 출산을 포기하겠다면 다시 한 번 생각해보길. 육아의 숭고한 가치를 위해. 부모라는 위대한 인생의 가치를 위해. 나아가 국가의 발전과 인류의 존속을 위해.

[wonnyz]

평소 기술적으로 좋은 글을 많이 올려주는 분이긴 한데 뜬금없는 이 꼰대글은 대체 뭘까. 육아의 숭고한 가치, 부모라는 위대한 인생의 가치에 모든 이가 공감할 필요가 있을까. 국가의 발전과 인류의 존속을 왜 개인이 생각해야 하는가.

육아를 마치 게임으로 생각하는 모양인데, 이건 마치 군대 다녀온 사람들이 부조리와 고생을 아름다운 추억으로 미화해서 기억하면서 한번쯤 해볼만하다 하는 말을 보는 기분. 군대는 2년으로 끝나지, 육아는 아이가 성인으로 성장할 때까지 그 열배가 필요하며 관련된 사람들의 인생이 바뀌는 일인데 어쩜 저렇게 쉽게 말할까.

국가의 발전과 인류의 존속을 위해 반드시 해야 하는 것이라면서 육아는 기본적으로 부모가 책임지는 것이라니 과연 저 주장에 논리라는게 존재는 하는 것인지 의심스러움. 나이가 들면 저렇게 되나 싶어서 나도 두렵다.

[wonnyz]

집 공유기 설정

표

강조된 것은 공유기 기본 설정값과 다른 것이다.

2.4 GHz 5GHz 비고 General Wireless Mode Auto N/AC mixed +b/g protection General Channel bandwidth 40 MHz 80 MHz (2.4) 20은 호환성을 얻고 속도가 제한됨 General Control Channel - - WiFi Analyzer 로 주변상황을 확인할 것 General Extension Channel - - 자동 (Control Channel에 의해 제어) General Authentication Method WPA2-Personal WPA2-Personal 집이면 Personal General WPA Encryption AES AES TKIP 쓰지 말 것 General Protected Management Frames Disable Disable Less secure, More compatibility General Group Key rotation Interval 0 0 Less secure, More performance Professional Enable Radio Yes Yes 무선 사용 Professional Enable wireless scheduler No No 사용시간대 제한 Professional Set AP Isolated No No 내부 네트워크 연결 Professional Roaming assistant Disable Disable 집에 다른 라우터가 없음 Professional Enable IGMP Snooping Disable Disable Apple TV나 크롬캐스트 쓰지 않음 Professional Multicast Rate(Mbps) Auto Auto 기본값 Professional Preamble Type Short - 성능 >> 호환성 Professional Fragmentation Threshold - 2346 Professional AMPDU RTS Enable Enable Professional RTS Threshold 2347 2347 Professional DTIM Interval 3 3 Professional Beacon Interval 1000 1000 Professional Enable TX Bursting Disable Disable b/g 장치를 사용하지 않음 Professional Enable WMM - Enable Professional Enable WMM No-Acknowledgement - Enable Professional Enable WMM APSD Enable Enable Professional Reducing USB 3.0 Interference Enable - 2.4 성능우선이면 끌 것 Professional Optimize AMPDU aggregation Disable Disable 게임 성능을 위해서라면 끌 것 Professional Optimize ack suppression Disable Disable 통신 신뢰성 >> 약간의 성능 Professional Turbo QAM Enable 2.4 GHz Wireless Mode = Auto 필요 Professional Airtime Fairness Enable Enable 구형 무선장비가 없다면 켜자 Professional 802.11ac Beamforming Disable Disable 애플 장치와 Z3TC와 호환성 문제 있음 Professional Universal Beamforming Disable Disable 애플 장치와 Z3TC와 호환성 문제 있음 Professional Tx power adjustment Performance Performance 당신도 주파수 혼잡의 주역☆

이러쿵저러쿵 해도 호환성 문제를 해결한 후 (i.e. Beamforming Off) 5GHz 대역의 주파수를 쓸 수 있으면 성능 문제는 잘 발생하지 않는다.

참고 자료

(Wireless) How to do Professional settings?

Tuning the Asus Wireless Router to Best Performance

[wonnyz]

왜 "애자일", 특히 스크럼이 끔찍한가.

이 글은 Michael O. Church의 ‘Why “Agile” and especially Scrum are terrible’을 글쓴이의 허락을 받고 번역한 글이다. 퍼가는 것은 보는 사람 맘대로지만, 가끔 번역이 마음에 안든다 싶은 부분은 수정될 수도 있다.

프로그래밍을 감염시킨 “애자일”의 유행을 내가 싫어하는 것은 비밀도 아닐 것이다. 그 중 최악의 종류인 스크럼은 악몽과도 같은데, 나는 이것이 실제로 기업을 살해하는 것을 본 적이 있다. 여기서 “살해”란 “나중에 보니 별로 좋지 않은 문화였다” 정도가 아니라, 기업 주가가 실제로 85% 이상 폭락했다는 것이다. 이 잡것은 유독하며, 예전에 없어졌어야 했다. 여기에 익숙하지 않은 사람들을 위해, 우선 용어를 정의하자. 그리고 왜 이것이 끔찍한지, 그리고 진짜 '민첩함'(agility)을 해치는지를 다룰 것이다. 그리고 “애자일” 개발이 실제로 유용한 하나의, 임시적인 사용 사례(use case)를 논할 것이며 그 사례를 통해 왜 이것이 “영구적 합의” (permanent arrangement) 만큼 유해한지 설명하겠다.

그래서 “애자일”이란 무엇인가?

“애자일” 유행은 웹 컨설팅 업계가 키웠는데, 그 업계에서는 어느 정도 가치가 있었다. 스스로 뭘 원하는지도 모르는 까다로운 고객을 다룰 때, 두 가지 정도의 선택지가 있다. 하나는 고객을 관리하는 것이다. 기대치를 설정하고, 수정 요청에 적절한 비용을 부과하고, 고객에게 굴종하지 않고 동등한 관계를 유지하는 것이다. 두번째는 고객의 진상짓을 감수하고 (그러니까.. 많은 그래픽 디자이너들이 그래야 하는 것처럼) 작업 방향을 고객 입장에서 문제라고 생각하는 것을 해결하는 쪽으로 맞추는 것이다. 프로그래머들은 - 고객을 관리하는 - 첫번째 선택지에 능숙하지 못하다. 그런 것을 잘 하려면 사회적 감각이 엄청 요구되는데다가, 두번째 선택지가 이제 막 승진했고, 실제 업무를 처리하지 않아도 되는 의사결정권자에게 매력적이기 때문이다.

“컨설팅”이라는 이름을 가진 업무의 범위는 매우 다양하다. 훌륭한 컨설팅 회사도 있고, 가장 질 낮은 업무를 떠맡는 곳도 있다. 기업은 컨설팅 회사에 두 가지 종류의 업무를 주곤 한다. 내부에서 일을 맡을 사람이 없는 최고 수준의 업무이거나, 그런 업무에 1년 정도 사람을 투입하면 사기가 박살나는 종류의 쓰레기같은 질 낮은 업무이다. 스크럼은 그런 질 낮은 업무를 처리하는 곳을 위한 것이다. 프로그래머를 쥐어짜고, 고객과의 관계를 제대로 관리하지 못하고 있으며, 아무도 하고 싶어하지 않고 경력이 꼬이는 저질 업무를 떠맡는 그런 곳 말이다.

자 그래서 스크럼과 “애자일”이란 무엇인가? 여러 종류의 미팅이나 (“회고”, “백로그 다듬기”, “계획”) 이론을 들 수 있겠으나, 핵심적인 공통 특성은 보통 일방적인 지독한 투명성 이다. 프로그래머는 대부분의 경우 자신의 업무 내용과 시간에 대한 굴욕적일 정도의 가시성을 제공해야 한다. 즉 실제 업무량에 더해서 생산성을 보여주는 일방적인 게임을 해야만 한다는 것이다. 사람을 신나게 하는 실질적인 장기 프로젝트에서 일하는 대신, 그들은 세분화된, 기능 단위의 “유저 스토리” 작업으로 격하되고, 단기간의 (보통 윗선에서 떨어지는) 사업적 요구와는 관련없는 개선사항을 처리하는 것은 허락되지 않는다. 애자일은 오너십이라는 개념을 없애버리고, 프로그래머를 교체 가능한 일반적인 부품처럼 다룬다.

사람을 어린애 취급하고 역겨운데다가, 스크럼은 개인의 생산성이 미세하게 요동치는 것에 대해 쓸데없는 걱정을 하게 만든다. 폭력적인 투명성이란, 이론적으로 사람의 매 시의 생산성 변동이 모두에게, 아무런 이유 없이 보이게 된다는 것이다. 이런 종류의 가짜 만병통치약이 실제로 일을 빠르게 끝내게 하거나 결국엔 더 낫게 한다는 아무런 증거가 없는데도. 평균 장기 생산성을 측정했을 때 괜찮은 성과를 내고 프라이버시 침해에 굉장히 민감하며, 불안증이나 감정 장애가 있는 사람들에게는 이것은 노골적인 차별이다.

"애자일"과 스크럼의 구체적인 결함

1. 사업부 주도의 엔지니어링

“애자일”은 종종 “폭포수(Waterfall)”라는 소프트웨어 설계 방법과 비교하여 팔리곤 한다. 둘 다 똑같이 끔찍한 허수아비다. 애자일과 폭포수 모델이 공유하는 것은 (그리고 둘 모두의 장애 원인) 사업부 주도의 개발이라는 것이다. 폭포수 모델에서 프로젝트는 회사 경영진이 처음 정의하고 중간 관리자와 아키텍트들이 설계하며, 그 다음에야 여러 층의 말단 노동자들이 구현과 운영 및 테스트를 수행하는데, 각 기능은 하나가 끝나야 다음을 진행할 수 있는 여러 단계를 거쳐서 구현한다. 폭포수 모델이 제대로 동작하지 않는 것은 악명 높고, 애자일 진영의 아무도 여기에 이의를 달지 않는다. 폭포수 모델에서 엔지니어들은 어떤 설계를 구현하는 역할로 격하되는데, 이 설계의 모든 중요한 결정은 이미 끝났고 되돌릴 수 없다. 따라서 재능 있는 엔지니어라면 그러한 프로젝트를 맡고 싶어하지 않는다.

폭포수 모델은 명확한 계급구조가 있는 문제 조직의 사회적 모형을 복제한다. 가장 흥미로운 업무를 먼저 진행하고 작업 완료가 선언된 다음, 지저분한 나머지는 아래 사람들에게 넘긴다. “폭포수”라고 불리는 까닭은 의사 소통이 단방향이기 때문이다. 설계에 잘못이 있더라도 반드시 구현되어야 한다. (아마도 설계한 사람들은 이미 다른 프로젝트로 넘어갔을 것이다) 그리고 애자일은, 문제 조직의 사회적 모형을 복제하는데, 명확한 계급구조를 빼고 복제한다. 이것은 꽤 명백하게 다른 모든 이의 아래에 엔지니어를 두는데, “프로젝트 소유자”와 “스크럼 마스터”는 “팀 구성원”보다 계급이 높고, “팀 구성원”은 하위 계층에서도 가장 낮은 위치에 있다. 이러면 시니어급의 능력있는 엔지니어에게 주니어를 위한 보고 구조를 (나눠준 티켓을 처리할 것, 상태 보고 회의에 주당 5-10시간씩 참가할 것) 충실히 따르도록 하여 그들의 자존감을 박탈하는 효과가 있다. 빈곤을 전파하여 모두를 동등하게 만드는 실패한 공산주의 국가처럼, 가장 순수한 형태의 스크럼은 모든 엔지니어링을 동일한 가장 낮은 계층에 둔다. 잘 설명하지는 않지만, 분명히 ‘무슨 일을 먼저 해야 하는가’에 대한 완전한 결정권을 쥐고 있는 사업부 조직의 밑으로.

“애자일”은 엔지니어에게 아무런 권력을 주지 않으면서 업무보고의 빈도를 늘린다. 이것은 손해인데, 일정이 필요한 만큼보다 늘어지는 것처럼 “보이면” 엔지니어들이 곤란해지거나 처벌받을 수 있기 때문이다. 이러한 결정은 언제나 사업부 사람들이 내리는데, 그들은 기술적 난제나 개발 업무의 특성에 대한 깊은 통찰 대신 그들의 감정에 기반하여 상황을 지휘할 것이다.

실리콘 밸리에서 특히 지난 5년간 잘못 생각한 것도 많지만, 제대로 하고 있는 것중 하나는 '엔지니어가 주도하는 회사'라는 개념이다. 엔지니어가 모든 회사를 이끄는 것이 항상 최선은 아니지만, 엔지니어가 엔지니어링을 주도하고 우선 순위를 세우면 모두가 승리한다. 엔지니어는 자신에게 할당된 일에 (스스로 정한 것이면 더 좋고) 만족하고, 사업부는 훨씬 질이 높은 결과물을 얻는다.

2. 주니어로 끝남

“애자일”은 주니어로 끝나는 (terminal juniority) 문화이며, 프로그래밍은 “젊은 남성들의 게임”이라는 (엄청 잘못된) 생각에 신빙성을 더해준다. 대부분의 최고급 엔지니어들은 그렇게 젊지도 않고, 일부는 남자도 아닌데 말이다. 애자일에는 출구 전략이 없다. “이걸 했으니 이제 더이상 이렇게 할 필요가 없다”는게 없다. “유저 스토리”와 사업부가 주도하는 엔지니어링과 끝없는 상태 미팅은 사라지지 않으며, 그 자리에 항상 남아있게 되어 있다. 구조 잡기(아키텍쳐), 연구 개발, 제품 개발은 프로그래머가 할 일이 아닌데, 그런 것은 세분화된 “유저 스토리” 또는 2주 단위 스프린트에 맞지 않기 때문이다. 따라서 프로그래머들이 한 분야의 기초를 익힌 다음에 맡고 싶어하는 그런 프로젝트는 무시되는데, 세분화할 수 없거나 세분화하는 것이 그냥 하는 것보다 훨씬 더 어렵기 때문이다.

스크럼 팀에 실제 시니어 엔지니어의 역할은 없는데, 문제는 스크럼을 도입한 많은 회사에서 보통 전사적으로 시행한다는 것이다. 관리직으로 넘어가는 것 말고는, “스크럼 마스터”가 되어 이것을 말단에 도입하는 책임을 지는 선택지가 있다. 권한이 없는, 헛소리에 불과한 가짜 관리직 말이다. 스크럼 팀을 떠나서 해로운 마이크로매니지먼트를 받으면서 살지 않으려면 괴물 안으로 깊숙히 파고들어서 다른 사람에게 유해한 마이크로매니지먼트를 강요하는 수 밖에 없다. “애자일”과 스크럼이 나에게 말하는 것은 시니어 프로그래머는 반드시 필요하지 않다고 여겨지므로, 무시해도 좋으며, 마치 프로그래밍이란 35세 이전에 접어야 하는 유치한 것이라고 하는 것 같았다. 나는 그런 사고방식에 동의하지 않는다. 사실 해롭다고 생각한다. 나는 30대 초반이 되어서야 이제 프로그래밍 좀 하는 것 같다고 느끼기 시작했다. 이런 “애자일”/스크럼 쓰레기가 컴퓨터 과학과 아무런 상관이 없고, 아무런 가치가 없다는 것을 알게 된 경험 많은 연장자들을 내쫓는 것은 끔찍한 생각이다.

3. 어리석고, 위험할 정도의 짧은 주기

애자일은 한계에 달한 컨설팅 회사들을 위해, 그들에 의해 만들어졌다. 즉, 고객과 동등한 위치에서 협상할 수 있는 신뢰도를 갖추지 못하였으므로 빠듯한 데드라인에 맞춰야 하고, 각 고객 프로젝트가 실존의 위기인 회사들을 위한 것이다. 그러니까 “헝그리한” 약자(underdog)들을 위한 것이다. 자 여기서 문제: 흔히 큰 회사, 또는 펀딩받은 스타트업에서도 스크럼을 사용한다. 그런데 (고용자가 가져가도록 금전적 조건이 적힌 서류를 남기고) 이런 회사에 입사하는 사람들은 패배자(underdog)가 되고 싶지 않아서 입사하는 것이다. 아무도 타당한 개인적 보상이 없다면 뒤치닥거리를(play from behind) 하고 싶어하지 않는다. 기업 업무에서 “애자일”이란 보상이 없는 고통과 위험을 말한다.

각 개별 프로젝트가 실존 문제이거나 심각한 평판 위험에 해당할 때, 애자일은 괜찮은 선택지일 수도 있다. 회사가 위기에 처했을 때 반복적인 단기 목표에 집중하는 것은 유용하며 오랫동안 지속되지는 않을 것이기 때문이다. 비상 시에 공격적인 프로젝트 관리는 이치에 맞다. 영구적인 합의로써는 적절하지 않다. 적어도 스트레스를 덜 받고 더 즐거운 선택지가 있는 인재들에게는 말이다.

애자일 하에서, 기술적 부채는 쌓이기만 하지 처리되지 않는다. 명령권을 가진 사업부서 사람들은 너무 늦거나, 고치려니 너무 비용이 많이 드는 지경에 처하기 전까지는 문제를 보지 못할 것이기 때문이다. 게다가, 엔지니어 개인은 오로지 2주 단위의 현재 “스프린트”를 완료했는가 하지 못했는가에 따라 보상을 받거나 처벌을 받으므로, 아무도 한 다섯번 뒤의 “스프린트”를 내다보지 않는다. 애자일은 단지 아무 생각없는 근시안적인 “스프린트”의 연속일 뿐이다. 진척도 없고, 개선도 없고, 단지 티켓에 티켓이 이어질 뿐이다.

4. “경력 일관성”을 전혀 고려하지 않는다

세분화된 유저 스토리는 엔지니어의 경력에 좋지 못하다. 사람들은 당신이 30세가 되기 전에 프로젝트 전체를 담당할 수 있다는 것을 보여주길 기대한다. 또한 적어도 기반 인프라, 구조(아키텍쳐), 연구 또는 리더십 등의 분야에서 어느 단계를 뛰어넘을 준비가 되었기를 바란다. 애자일/스크럼 경험은 주니어 일자리를 잡을 때는 어느 정도 도움이 되지만, 중간 정도나 시니어 엔지니어에게 적합한 일자리를 구할 가능성을 없애버린다.

비상시에, 그러니까 컨설팅 회사가 중요한 고객을 달래려고 안간힘을 쓰고 있든 기업의 “위기 상황실”(War Room) 상황이든, 경력 일관성은 잠시 유보할 수 있다. 자신이 일하고 있는 회사에게 정말 필요한 일이라면, 몇 주 동안 불쾌하거나 경력이 꼬이는 업무를 못하겠다고 거부하는 사람은 거의 없을 것이다. 최소한 그 작업의 중요성이 경력에서 인정된다. 그러나 비상 상황이 아닐 때는, 프로그래머들은 자신의 경력 증진을 중요하게 여겨주길 바라고, 그렇지 않으면 떠날 것이다. 모두가 싫어하고, 누구의 경력에도 가치가 없는 밑바닥 작업을 “잡일(Fish Frying)”이라고 하자. 비상시 또는 모두의 주목을 받아서 누구도 개의치 않는 “잡일”이라면 (조직 안팎으로) 경력에 충분한 가치가 된다. “나는 상황실에 있었고, CEO랑 하루에 20분씩 같이 있었다”고 하면 잡일은 정당화된다. 이것은 당신은 귀중하고 중요한 인재라는 뜻이다. 자 “나는 스크럼 팀에 있었다”는 어떨까, “나 좀 잘라줘”이다. “유저 스토리”를 할당 받았기 때문에 잡일을 처리했다는 것은 당신이 패배자로 보였다는 것을 알려준다.

5. 저성과자를 가려내는 것이 목적이지만, 잘못 판단할 가능성이 높아서 써먹을 수가 없다

스크럼을 팔아먹는 쪽에서는 “장애물을 없애는” 과정이라고 하는데, 이 말은 “게으름뱅이 가려내기”를 좀 부드럽게 말한 것이다. 문제는 뿌리뽑는 것보다 더 많은 저성과자를 만든다는 것이다. 이는 각 엔지니어들이 자신의 업무와 생산성 척도를 세밀하게 관찰할 수 있도록 제공해야 하는 감시 상태이다. 이를 “꺼리는게 없으면 숨길 것도 없다”는 식의 주장으로 무마하려고 하는데, 조직의 대들보에 해당하는 고성과자들에게도 감시 상태는 불안감을 주는 상태인 것이 사실이다. 누가 나를 관찰한다는 사실에 사람들은 일하는 방법을 바꾼다. 특히 창의성이 필요한 분야에서는 상황을 악화시킨다.

여기서 떠오르는 첫번째 주제는 지위 민감성 (status sensitivity)이다. 프로그래머들은 자신들이 사회적 지위에 대해 영장류의 수백만년 진화를 초월했다고 믿고 싶어한다. 그러나 사실은: 사회적 지위는 중요하다. 그 사실을 인정하기 전까지는 당신은 “정치적”일 수 없다. 나이든 사람들, 여성, 소수 민족과 장애인들은 자신들의 지위에 민감한데, 생존의 문제이기 때문이다. 누군가의 업무를 지속적으로 감시한다는 것은 그 사람을 신뢰하지 못하고 사회적 지위가 낮다는 것을 나타내며, 대부분의 “지위에 민감한” 사람들이 (그들이 최고의 직원이라고 해도) 제일 먼저 위축될 것이다. 반면 스크럼과 “애자일”은 “지위에 민감하지 않은” 사람들이 대부분인 집단을 위해 만들어졌다. 즉 시험이나 도전을 받아보지 못했거나 아직 업무에 치여보지 않은 (burned) 젊은 특권층 남성들을 위한 것이다. HR과 관리 업무는 시간낭비이며 이 사람들은 모욕을 당하거나 비하를 당해도 그저 알랑거려야 한다고 생각하는 그런 사람들 말이다.

애자일/스크럼이 소개되면 최고의 직원들이 제일 심하게 추락하곤 하는데, 연구 개발이 사실상 제거되었기 때문이고, 단기간의 “반복” 또는 스프린트에 대한 강박이라는 것은 실패할지도 모를 작업을 시도할 틈이 없다는 것이기 때문이다.

저성과자에 대한 진실은 그들이 누구인지 찾아내기 위해 “애자일”을 도입할 필요는 없다는 것이다. 사람들은 스스로를 안다. 어떤 팀이 한가하거나, 무능하거나, 유해한 사람들로 가득 차는 것은 그들에게 아무런 조치를 하지 않기 때문이다. 사람에 대한 관리 문제이지, 작업 흐름과 절차에 대한 문제가 아니다.

6. 주정뱅이 효과 (The Whisky Goggles Effect)

(주: 술에 취하면 앞에 있는 사람이 더 멋있어 보이게 된다는 뜻임)

애자일과 스크럼이 살짝 무능한 사람을 간당간당하게 쓸만한 사람으로 만든다는 증거가 일부 있는 것처럼 보인다. 나는 이것을 주정뱅이 효과라고 부르는데, 3점이나 4점짜리를 5점으로 바꾸지만, 당신을 너절하게 보이게 하여 7점이나 9점짜리 사람은 당신이 별볼일 없다고 여길 것이다. 공격적인 마이크로매니지먼트 환경에서 그들의 흘러넘치는 창의력을 짜내는 것은 불가능하고, 최고의 프로그래머들은 떠나게 된다.

'관리자는 소프트웨어가 어떻게 동작하는지 알지 못한다'는 관점에서 보면 이것은 해볼만한 거래로 보인다. 7점 이상의 “프리마돈나”들은 '멋진 스크럼'을 받아들이지 못하고 떠날테지만, 3점이나 4점짜리 직원들은 딱 아슬아슬한 5점짜리 직원이 된다. 문제는 7점짜리 프로그래머와 5점짜리 프로그래머의 차이는 5점과 3점짜리의 차이와 비교하면 꽤 크다는 점이다. 최고의 직원들과 (조직도 상의 관리직으로는 올라가지 않은) 리드들을 잃는다면, 무능력자들을 살짝 업그레이드할 수 있다는 스크럼의 장점은 아무런 쓸모가 없다.

스크럼과 애자일은 내가 '상황 이득 편향' (Status Profit Bias) 이라 칭하는 것에 빠진다. 기본적으로 많은 사업부 사람들은 객관적으로 (in objective terms) 성공과 실패를 평가하는게 아니라, 성취한 상황 변화를 근거로 평가한다. "3"점 프로그래머의 시장 가치가 연 $50,000이라 하고, "5"점 프로그래머는 $80,000이라 하자. (실제 프로그래머 급여는 중구난방이다. 나는 3점짜리가 $200,000을 버는 사례도 알고, 7점이 $70,000 아래인 경우도 알고 있지만 무시하자) "5"점짜리 프로그래머에게 "3"점짜리의 급여를 주는 것을 납득시킨다면 심리적으로 와닿을 것이다. 겨우 $30,000 이득이 아니라 2점이나 이득이기 때문이다.

애자일/스크럼과 연령 차별 문화는 보통 실제 경제적 이득보다는 제일 인상적인 상황 이득을 얻는 방법에 대한 것이다. 젊은이들은 자신이 “실제로 대접 받아야 하는” 사회적 지위에 대해 거의 알지 못한다. 자신이 3점 정도라고 생각하는 22세 6점짜리를 찾아서 스크럼에 합류시킬 수 있겠지만, 50세 9점 프로그래머는 마지못해 8.5점 대우를 받아들일지도 모르지만 6점짜리 대접을 받으려고 하지는 않을 것이다. 그러나 상황 이득을 찾는 것은 매우 근시안적이다. 업계 전체적으로 5점 엔지니어를 데려와서 4점처럼 대접하려고 (급여도) 하겠지만, 현재 시장 상황에서는 8점 엔지니어를 데려와서 8점 대접을 해주는 것이 훨씬 이득이다.

7. 거짓으로 팔아먹고 있다

이 점을 다루기 전에, 나는 “스크럼”이라 알려진 특급 애자일 프로세스가 특정 상황 조건에서는 잘 작동한다는 점을 인정해야겠다. 거짓 약팔이들은 이것이 '영구적인 합의'처럼 모든 상황에 잘 맞는다고 말한다.

스크럼이 잘 맞는 경우

애자일이 유행하기 전에는 “스크럼”이란 말은 회사가 “적색 경보” 또는 “위기 상황”이라 부르는 상황에서 사용되곤 했다. 이것은 조직경계를 넘어 (cross-cutting) 대응팀을 빠르게 꾸려서 예상치 못한, 보통 빠르게 퍼져나가는 문제에 대처하는 것이다. 정해진 관리자를 두지는 않지만 리더를 (“스크럼 마스터”같은) 선출하고 권한을 부여하는데, 보통 공식적인 "관리직"이 아닌 사람이 제일 적합하다. (가능한 공정해야 하므로) 위기는 단기간이므로, 각 개인의 경력 목표는 잠깐 보류할 수 있다. 이것을 “전력질주”(sprint)라고 할 수 있는 까닭은 최대한 빠르게 일해서 문제를 해결해야 하기 때문이고, 상황이 종료된 다음에는 평상시의 작업으로 돌아갈 수 있기 때문이다.

두 가지 시나리오를 생각할 수 있다. 첫번째는 기업의 “위기 상황실”에 대한 것인데, 어떤 사람이 (경영진 말고) 1년에 6주 이상 '위기 상황'에 있었다면, 이것은 회사에 뭔가 문제가 있는 것이다. 위기가 그렇게 잦으면 안되기 때문이다. 두번째는 컨설팅 회사가 자리잡으려고 애쓰고 있는 상황이거나, 고객 관리나 독자적인 평판 구축에 실패하여 항시 비상 상황으로 운영해야 하는 경우이다.

두 가지 문제

스크럼과 애자일은 비상시에 리더를 "떠맡은" 사람에게, 빠르게 일을 처리하기 위해 그가 필요하다고 생각하는 모든 것을 할 수 있도록 우선 비상 지휘권을 부여해야 한다는 생각을 대변한다. 시시비비는 일단 나중에 따지더라도 말이다. 예로부터 비상 지휘권에 대한 문제는, 가끔 없어지지 않는다는 것이다. 대부분의 경우 지휘권을 가진 사람은 이것을 유지해야 한다고 생각한다. 그리고 틀림없이, 관리의 문제가 된다. 장애 상황, 비상 상황에는 평상시 잘 돌아가던 때보다 더 많은 경영상의 노력이 필요하다.

출세지향적인 선동가 (“스크럼 마스터”) 에게는 우선 마을에 드래곤이 꼬이지 않게 하는 것보다 “드래곤 슬레이어”가 되는 것이 더 멋져 보일 것이다. 스크럼의 사업부 주도 엔지니어링에 대한 공격적인 주장의 문제점은, (“요구사항”이라 하는) 용을 꾀어내어 처치하는 것을 (“고객의 협력”이라는) 미덕으로 삼는 것이다. 처음부터 동굴에서 용을 꾀어내지 않는 편이 더 사려깊었을 것이지만.

“애자일”과 스크럼은 비상시를 미화한다. 그게 첫 번째 문제이다. 그것은 비디오 게임 업계에서 “크런치”라고 하는 것의 재발명일 뿐이다. 지속 가능하지 않다. 공세적으로 개인의 성과에 집중하고, 업무 할당에서 개인의 경력 목표를 배제하고, 최우선 순위로 정해진 것만 작업하도록 강요하는 것은 단기간의 비상 상황에서나 가치가 있지, 장기간으로 보면 독이 된다. 사람들은 자신의 자율성을 돌려받게 될 명확한 목표가 눈앞에 있어야 그러한 변화를 감내할 것이다.

두 번째 문제는 이러한 사례가 거짓으로 팔리고 있다는 것이다. 회사들의 소프트웨어 개발 업무에 “애자일”을 도입하도록 교육하면서 성장한 가내 수공업 업계가 있다. 문제는 핵심 아이디어에 새로운 것이 없다는 것이다. 용어는 신선한데, 개념은 대부분 진부하고, 실패한 “과학적 관리법”이다. (과학적이지도 않았고, 잘 되지도 않았다)

“애자일”과 스크럼의 장단점이 모두 다뤄졌다면 나는 이러한 개념이 그렇게 문제라는 생각을 갖지 않았을 것이다. 주니어 개발자들 뿐인 회사에서 어떤 기능을 빠르게 제공해야 한다면, 이러한 기법을 잠시동안 사용해보고, 구성원들이 성장하고 납기일에 조금 여유가 생기면 이후에는 쓰지 않는 것을 생각해볼 수 있을 것이다. 그러나 스크럼이 '있는 그대로' - 생산성 향상을 위해 긴급히 써볼 수 있는 몇 가지 방법이지만 영구적으로 쓸 수는 없는 - 팔렸다면 이런 방법론을 도입하는 고객은 훨씬 적었을 것이고, “애자일” 컨설팅 업계는 없었을 것이다. 이러한 기법에 대한 거짓 약팔이 수법으로만 (항시 수정(permanent fixes)으로 포장된 "크런치"에 대한 미화) 팔아먹을 수 있는 것이다.

앞으로의 기대

이제 대부분의 “애자일”, 특히나 스크럼은 없어져야 한다. 이들은 그냥 나쁜 생각이기만 한게 아니다. 한 세대의 소프트웨어 엔지니어들이 이보다 더 나은 것을 알지 못하고 받아들이고 있기 때문이다. 너무나 많은 젊은 프로그래머들이 사업부 주도 엔지니어링과 “유저 스토리”를 마땅히 따라야 하는 것으로 받아들이고, 단지 평범한 회사원이 되어버릴 운명이다. 이것을 막아야 한다. 우리 업계가 앞으로도 얼마나 멀쩡하게 남아있을지가 여기에 달려있다. “애자일”은 양동이에 가득찬 헛소리에 불과하며, 프로그래밍 및 컴퓨터 과학과도 아무런 상관이 없고, 원래 튀어나왔던 똥덩어리 속으로 다시 던져넣어야 한다.

[wonnyz]

3.0 upgrade시의 edge case

AuthSchemaIncompatible

상황

3.0 instance를 새로 셋업하면서 auth disable

db.adminCommand({copydb:1}) 을 사용하여 2.4 인스턴스에서 3.0 인스턴스로 데이터를 복사

auth enable로 설정을 변경하여 3.0 재기동

'Old 2.4 style user index identified' 에러와 함께 서버가 종료됨

원인

3.0.4 소스코드에서 확인했을 때 데이터베이스에 system.users 컬렉션이 있으면 오류가 발생함. wiredTiger 엔진은 컬렉션 이름 대신 내부 번호로 데이터 파일 이름을 붙이므로 mmap 때처럼 오류가 있는 컬렉션 데이터 파일만 삭제하는 임시 방법을 쓸 수 없음. 서버를 띄우지 못하면 아무런 해결 방법이 없음.

workaround

다음과 같이 복사 후에 바로 system.users 컬렉션의 이름을 변경한다. system.users 컬렉션은 system namespace이므로 바로 삭제할 수 없음.

db.getMongo().getDBNames().forEach(function(n) { db.getSisterDB(n).getCollection('system.users').renameCollection('_users'); });

node-mongodb-native 인증 버그

상황

node.js version 0.8

mongoose 3.8.25 (node-mongodb-native 1.4.32)

mongodb 3.0.4 w/ SCRAM-SHA-1 enabled (authSchema v.5)

에서 DB 접속에 실패함.

원인

node-mongodb-native driver 버그. (NODE-382 & NODE-459) changelog에 따르면 버전 1.4.36에서 문제가 수정되었으며, 관련 커밋 로그는 여기에서 볼 수 있음.

mongoose 최신 버전(3.8.32)도 native driver 1.4.33을 쓰므로 영향을 받는다.

workaround

node.js 0.10.x에서는 문제가 발생하지 않는다

mongoose 4.0.x를 사용한다

mongodb 구 버전을 사용한다 (2.4 or 2.6)

SCRAM-SHA-1 대신 MONGODB-CR 인증을 사용한다

[wonnyz]

mongodb 3.0에서 구버전 클라 접속

TL;DR

admin.system.version 컬렉션의 authSchema를 3으로 낮춘다.

절차

인증 해제 후 재시작

다음과 같이 인증을 끄고 서버를 재시작. 인증 안끄면 system.version 컬렉션을 아예 건드릴 수 없다.

security: # keyFile: "/data/key/keyfile" authorization: "disabled"

스키마 버전 변경, 사용자 생성

admin.system.version 컬렉션의 authSchema 항목을 변경한 다음 사용자를 생성한다.

use admin; // Use MongoDB 2.6 auth schema (default auth mechanism: MONGODB-CR) db.system.version.save({ "_id" : "authSchema", "currentVersion" : 3 }); db.createUser( { user: "root2", pwd: "root2", roles: [ "root" ] } );

이렇게 생성된 유저는 다르게 보이게 된다.

db.system.users.find() { "_id" : "admin.root", "user" : "root", "db" : "admin", "credentials" : { "SCRAM-SHA-1" : { "iterationCount" : 10000, "salt" : "M5DcpS5ns+skpfY3zrssKA==", "storedKey" : "7Ekup4Ifxtnfi97OMR6cqov+35U=", "serverKey" : "5nIHY/RcdjTLu+4p84XLNjuRhkA=" } }, "roles" : [ { "role" : "root", "db" : "admin" } ] } { "_id" : "admin.root2", "user" : "root2", "db" : "admin", "credentials" : { "MONGODB-CR" : "359a1cb5090b2b65bc64c47ef5b38b24" }, "roles" : [ { "role" : "root", "db" : "admin" } ] }

원복

인증 안쓰고 살기는 좀 그러니까 위에서 수정한 config 변경을 원래대로 하고 인스턴스 재시작.

비고

ver 3으로 내려놓은 상태에서도 ver 5일때 생성한 사용자는 정상적으로 접속된다

샤드 클러스터 환경이라면 config db 세 대를 모두 고쳐야 적용될 것이다. 서비스를 아예 내리고 세 대를 동시에 고치지 않는다면 데이터 불일치 등이 발생할 수 있어서 작업이 좀 클 것 같은데.. 행운을 빈다

ver 5로 다시 올려보지는 않았다 (귀찮아서) createUser 명령 동작 방식에만 적용되는 거라면 상관 없겠거니..

적어도 보안 측면에서 SCRAM-SHA-1이 좋은 것은 맞다

출처

mongodb-user newsgroup, SERVER-17459

[wonnyz]

MongoDB 2.8 RC Release Notes 요약정리

큰 변경점

저장소 엔진: 탈착식 API, 향상된 동시성, 문서 수준 잠금

MySQL처럼 pluggable storage engine API가 도입됨. 그러나 아직 DB 단위로 저장소 엔진을 지정할 수는 없고, 2.8에서는 인스턴스 단위로 지정해야 함. 한 replica set 내에서 각 호스트별로 엔진을 따로 쓰는 것도 물론 가능함.

2.8에서도 기본은 MMAPv1 (원래 쓰던 것)이지만 WiredTiger 엔진을 사용할 수 있음. MMAPv1 엔진은 컬렉션 수준 잠금으로 개선됨. WT 엔진을 사용하면 모두가 바라던 문서 수준 잠금과 문서 압축을 사용할 수 있음. 그러나 사용하던 데이터베이스의 저장소 엔진을 바꾸려면 mongodump & mongorestore를 쓰거나 복제를 이용해야 함. 변환기 그런거 없음.

설정 파일에 storage.wiredTiger 관련 옵션이 추가되었고 커맨드라인 상에서 --storageEngine wiredTiger로 엔진을 지정해서 실행할 수 있음.

WT엔진은 기본적으로 snappy 압축을 사용함. 또한 인덱스에 prefix compression을 지원함. 또한 캐시로 사용할 메모리 크기를 지정할 수 있음.

Replica Set 구성원 수 증가

한 Replica set을 구성하는 최대 인스턴스 수가 50개로 늘어남. 단 투표에 참가할 수 있는 것은 최대 7개까지임. 또한 이를 사용하려면 최신 드라이버를 사용해야 함.

질의 성능 분석이 강력해짐

db.collection.explain() helper, explain 명령이 추가됨.

뭔소리냐면, 이제 db.collection.explain().<method>(..) 와 같이 실행하면 mysql처럼 명령을 실행하지 않고 plan만 볼 수 있게 되었다는 말임. 이 당연한게 2.8이 되어 드디어 실현되었음.

또한 explain()이 aggregate(), count(), find(), group(), remove(), update() 명령에도 적용할 수 있게 됐음. 이제 좀 DB같음.

보안 개선

SCRAM-SHA-1 패스워드 인증 지원

기존 패스워드 저장 방법인 mongodb-CR이 md5였나 sha1이었나 하여튼 salt도 안써서 별로 안전하진 않았는데 개선했나 봄. 주로 드라이버 쪽에서 접속하는 방법에 영향을 미칠 것 같음.

localhost exception의 변화

계정 인증을 사용하면서 사용자 계정을 생성하지 않았을 때 localhost로 인증 없이 접속할 수 있게 하는 localhost exception에 제한이 좀 더 걸림. 이제 admin database에 첫 계정을 생성하는 일만 할 수 있음.

추가 사항

기타 개선 사항

별도 문서에 정리되어 있음.

replica set의 step down 동작 방식 변화

initial sync 시에 index 생성을 좀 더 효율적으로 하게 됨

청크 이동 (migration) 시에 write concern 지정이 가능해짐

로깅 개선

MongoDB Tools 개선

유틸리티가 모두 golang으로 바뀜. 이전에는 C++로 작성되었으며, 엔진 코드를 가지고 있어서 --dbpath 등의 스위치를 지정하면 유틸리티가 직접 데이터 파일을 읽어서 작업했으나, 이젠 온라인 인스턴스에 붙어서 작업하게 되었다. mongorestore를 예로 들면 worker를 여러개 지정한다든지 batch size를 지정한다든지 하는 숨겨진 스위치가 있으며 전반적으로 성능이 좋아졌음.

호환성에 영향을 미치는 변화

별도 문서 참고. 중요한거 몇개만 들어보면

설정 파일 내용이 변경됨. storage 섹션 밑에 있던 것이 storage.mmapv1 로

지정한 스토리지 엔진과 데이터 파일 형식이 안맞으면 실행 안됨

wiredtiger 엔진에서 touch 명령을 내리면 오류를 반환함

paddingFactor 지원 안함. usePowerOf2Sizes가 기본 동작이며 빈공간을 없애려면 collMod 명령이나 createCollection 명령의 옵션으로 noPadding:true를 지정해야 함

releaseConnectionsAfterResponse가 기본 동작이 됨

더이상 2.4의 인증 모델을 지원하지 않음

http://docs.mongodb.org/v2.8/release-notes/2.8/을 바탕으로 임의 정리.

WT 엔진은 rc3으로 테스트했을 때 replica set에 restore 시에 성능이 떨어지는 모습을 보여줬는데, 이후 rc에서 좀 개선이 되었나 모르겠음.

mongodb 2.4를 포크하여 TokuMX를 만들던 TokuTek도 자사의 TokuFT 스토리지 엔진을 mongodb 2.8용으로 제공하겠다고 공식 발표함. 그런데 RocksDB 설치 방법 같은걸 보면 기존 바이너리에 so 모듈로 된 엔진을 붙여서 쓰는게 아니라 빌드부터 새로 해야 할 것 같은데.. 글쎄 모르겠음.

[wonnyz]

파워셸 Accelerator

미쳤다고 타입을 하나하나 다 치고 있어야 하나! 했는데 이런게 있었다니.

$acc = [PSObject].Assembly.GetType('System.Management.Automation.TypeAccelerators') $acc::Add("Regex", "System.Text.RegularExpressions.Regex") # check $acc::Get | more # add accelerator as accelerator $acc::Add("accel", $acc) # add tcpclient [accel]::Add("tcpclient","net.sockets.tcpclient") # get-member [tcpclient] | get-member -static # new $a = new-object regex "pattern" $b = new-object tcpclient

단 한번 등록한 액셀러레이터는 저장되는 모양. 겹치지 않게 조심해야 할지도 모르겠다.

ref: 여기

[wonnyz]

디지털데일리 SW법 바로알기 by 김경환 변호사 모음

SW법 바로알기

[SW법 바로알기 01] 오픈소스 소프트웨어의 개작물은 영업비밀인가?

[SW법 바로알기 02] 소프트웨어 개발보안(시큐어코딩) 의무화

[SW법 바로알기 03] 오픈소스 소프트웨어의 역사

[SW법 바로알기 04] 오픈소스 소프트웨어 라이선스의 유형

[SW법 바로알기 05] 오픈소스 소프트웨어의 법률적 문제 (上)

[SW법 바로알기 06] 오픈소스 소프트웨어의 법률적 문제 (下)

[SW법 바로알기 07] 소프트웨어 공유의 문제점

[SW법 바로알기 08] SW개발비를 손해배상 청구하는 경우 그 산정방법

[SW법 바로알기 09] 컴퓨터프로그램의 임치 제도

[SW법 바로알기 10] 소프트웨어 개발계약에서 저작권의 귀속과 책임소재

[SW법 바로알기 11] 프로그램을 베꼈는지 여부를 판단하는 방법

[SW법 바로알기 12] 프로그램 시리얼넘버의 무단 배포행위는 저작권법 위반인가?

[SW법 바로알기 13] 직원의 불법프로그램 사용에 대한 회사의 형사책임

[SW법 바로알기 14] 컴퓨터 프로그램 위탁개발의 경우 저작권의 귀속

[SW법 바로알기 15] 렌탈 라이선스(Rental Right License)

[SW법 바로알기 16] 컴퓨터프로그램 코드의 역분석(Reverse Engineering)

[SW법 바로알기 17] 컴퓨터프로그램의 특허법적 보호

[SW법 바로알기 18] CAL 라이선스

[SW법 바로알기 19] 소프트웨어에 대한 집행절차

[SW법 바로알기 20] 개발자가 꼭 알아야 할 법률지식 10가지(上)

[SW법 바로알기 21] 개발자가 꼭 알아야 할 법률지식 10가지(中)

[SW법 바로알기 22] 개발자가 꼭 알아야 할 법률지식 10가지(下)

[SW법 바로알기 23] 소프트웨어(SW)산업진흥법 해설①

[SW법 바로알기 24] 소프트웨어(SW)산업진흥법 해설②

[SW법 바로알기 25] 소프트웨어(SW)산업진흥법 해설③

[SW법 바로알기 26] 소프트웨어(SW)산업진흥법 해설④

[SW법 바로알기 27] 소프트웨어(SW)산업진흥법 해설⑤

[SW법 바로알기 28] 소프트웨어(SW)산업진흥법 해설⑥

[SW법 바로알기 29] 소프트웨어(SW)산업진흥법 해설⑦

[SW법 바로알기 30] 소프트웨어(SW)산업진흥법 해설⑧

[SW법 바로알기 31] 소프트웨어 라이선스 감사의 법적 이슈①

[SW법 바로알기 32] 소프트웨어 라이선스 감사의 법적 이슈②

[SW법 바로알기 33] 소프트웨어 라이선스 감사의 법적 이슈③

[SW법 바로알기 34] 소프트웨어 라이선스 감사의 법적 이슈④

[SW법 바로알기 35] 데이터베이스와 저작권(上)

[SW법 바로알기 36] 데이터베이스와 저작권(下)

[SW법 바로알기 37] 웹접근성 준수 의무 1

[SW법 바로알기 38] 웹접근성 준수 의무 2

[SW법 바로알기 39] 웹접근성 준수 의무 3

[SW법 바로알기 40] 게임 콘텐츠의 표절 판단기준 1

[SW법 바로알기 41] 게임 콘텐츠의 표절 판단기준 2

[SW법 바로알기 42] 게임 콘텐츠의 표절 판단기준 3

[SW법 바로알기 43] SW업 종사자의 전직시 유의할 점 1

[SW법 바로알기 44] SW업 종사자의 전직시 유의할 점 2

[SW법 바로알기 45] 프로그램의 IP주소 수집은 적법한가?①

[SW법 바로알기 46] 프로그램의 IP주소 수집은 적법한가?②

[SW법 바로알기 47] 오라클 vs. 구글 판결의 정리

[SW법 바로알기 48] 컴퓨터프로그램 특허 개정내용 정리

ICT법 바로알기

[ICT법 바로알기] 개정 정보통신망법의 내용①

[ICT법 바로알기] 개정 정보통신망법의 내용②

[ICT법 바로알기] 중고 소프트웨어 판매는 위법한가?

[ICT법 바로알기] 비트코인(Bitcoin)의 동작원리

[ICT법 바로알기] 진화하는 파밍, 후퇴하는 피해자구제

[ICT법 바로알기] 게임콘텐츠의 표절 판단기준(上)

[ICT법 바로알기] 게임콘텐츠의 표절 판단기준(下)

[ICT법 바로알기] 인터넷·SNS 타인명의 사칭의 법적 문제

[ICT법 바로알기] 이디스커버리(eDiscovery) 제도의 현재와 미래 1

[ICT법 바로알기] 이디스커버리(eDiscovery) 제도의 현재와 미래 2

[ICT법 바로알기] 이디스커버리(eDiscovery) 제도의 현재와 미래 3

[ICT법 바로알기] 이디스커버리(eDiscovery) 제도의 현재와 미래 4

[ICT법 바로알기] 이디스커버리(eDiscovery) 제도의 현재와 미래 5

[ICT법 바로알기] 소셜커머스 사업의 법적 이슈

[ICT법 바로알기] 총 없는 은행강도, 메모리 해킹 기법의 파밍 사기

[ICT법 바로알기] 하반기부터 달라지는 전자금융 관련 규정

[ICT법 바로알기] 주민번호 처리를 금지한 개정 개인정보보호법의 내용

[ICT법 바로알기] 개정 소프트웨어산업진흥법의 모호함과 해결방안

[ICT법 바로알기] 병행수입과 통관보류절차 (上)

[ICT법 바로알기] 병행수입과 통관보류절차 (下)

[ICT법 바로알기] 미국의 영업비밀·산업기술 보호강화 동향 (上)

[ICT법 바로알기] 미국의 영업비밀·산업기술 보호강화 동향 (下)

[ICT법 바로알기] 가왕(歌王) 조용필과 음악저작권 1

[ICT법 바로알기] 가왕(歌王) 조용필과 음악저작권 2

[ICT법 바로알기] 소프트웨어(SW) 산업진흥법상 대기업의 공공사업 참여제한

[ICT법 바로알기] 구글의 휴면 계정 관리자와 디지털 유산 상속

[ICT법 바로알기] 브루스 윌리스와 디지털 유산 상속

[ICT법 바로알기] 인터넷 광고의 바람직한 규제 방안

[ICT법 바로알기] 소프트웨어 보호방안 : 저작권, 특허, 영업비밀

[ICT법 바로알기] 전자금융거래의 위기 : 피싱, 파밍, 스미싱

[ICT법 바로알기] 영업비밀의 핵심 조건

[ICT법 바로알기] 선사용 상표 및 모방 등록상표의 법적 문제

[ICT법 바로알기] ICT 종사자의 전직시 유의할 점

[ICT법 바로알기] MVNO(알뜰폰)와 법적 문제

[ICT법 바로알기] 트레이드 드레스(trade-dress) 바로알기 1

[ICT법 바로보기] 트레이드 드레스(trade-dress) 바로알기 2

[ICT법 바로보기] 트레이드 드레스(trade-dress) 바로알기 3

[ICT법 바로보기] 미성년자의 저작권침해에 대한 부모의 법적 책임

[ICT법 바로보기] e디스커버리(e-Discovery)에 관해

[ICT법 바로알기] 아디다스(adidas) 삼선줄무늬 셔츠 판결 : 위치상표

[ICT법 바로알기] 특허괴물(Patent Troll)에 관해

[ICT법 바로알기] 불법저작물에 대해 OSP는 법적 책임을 지는가? 1

[ICT법 바로알기] 불법저작물에 대해 OSP는 법적 책임을 지는가? 2

[ICT법 바로알기] 사망자의 디지털 유품의 상속

[wonnyz]

mongodb journaling은 어떻게 동작하는가

개요

mongodb journaling은 시스템 이상이나 크래시 등으로 mongodb가 비정상 종료된 경우라도 데이터가 깨지지 않도록 하기 위한 기능이다. 메모리를 살짝 더 사용하고 쓰기 속도를 아주 약간 늦추지만 비정상 종료 시에도 자동 복구 작업이 동작하므로 데이터 무결성을 지켜준다.

아래 글은 How MongoDB's Journaling Works를 번역하고 Durability Internals (MongoDB Server Development Guidelines)의 일부 이미지를 사용한 것이다.

상세

디스크에 데이터 파일과 저널 파일이 있다고 하자. 이것을 다음과 같은 그림으로 그려볼 수 있다.

mongod를 실행하면 데이터 파일을 '공유 뷰' (shared view)에 매핑한다. 이것은 기본적으로 운영체제가 "디스크에 있는 데이터 파일의 크기가 2000 바이트니까.. 이걸 메모리 주소 1,000,000-1,002,000로 연결해줄게. 주소 1,000,042 지점의 메모리를 읽으면 파일의 42번째 바이트를 읽게 되는거야" 이런 작업을 해준다는 것이다. 또한 실제로 그 주소에 접근하기 전에는 메모리에 데이터가 올라가지 않는다.

  메모리에 올라온 데이터는 디스크에 있는 파일에 기반하고 있다. 메모리에 있는 값을 수정하면 운영체제는 그 내용을 디스크에 있는 파일에 기록(flush)한다. mongodb가 저널링을 사용하지 않는다면 기본적으로 이렇게 동작한다. mongodb는 60초마다 운영체제에 메모리 상의 변경점을 디스크에 기록해 달라고 요청한다.

그러나 저널링을 사용하면 mongod는 shared view에서 private view로 이어지는 두번째 연결(mapping, 사상)을 만든다. 이 때문에 저널링을 사용하면 mongod가 사용하는 가상 메모리가 두 배가 되는 것이다.

이 private view는 데이터 파일과 이어져 있지 않으므로, 운영체제는 이 private view 에서 변경한 내용을 디스크에 기록할 수 없다.

이제 db에 쓰기 작업을 하면, mongod는 이것을 private view에 기록한다.

그러고선 변경 내역을 저널 파일에 기록한다. 여기에는 어떤 파일의 어느 위치에 무엇을 기록했다는 설명이 들어 있다.

변경된 내용이 저널에 계속 추가된다.

이 시점에서 쓰기는 안전하다. mongod가 비정상 종료되었을 때 아직 데이터 파일에 기록되지 않았던 것이 있더라도 저널에 기록되었으므로 나중에 다시 실행할 수 있게 되었다.

저널에 기록된 내용을 shared view에 재생한다.

그리고 mongod는 shared view에서 private view로 이어지는 연결을 다시 설정한다. 이렇게 하면 private view가 '너무 더러워지는 것' (shared view에서 변경된 내용이 너무 많아지는 것) 을 막을 수 있다.

최종적으로 shared view의 변경 사항이 디스크로 잽싸게 반영된다. 기본적으로 mongod는 60초마다 OS에 변경점을 디스크로 기록하도록 요청한다.

저널링은 이렇게 동작한다.

다이어그램

다음은 개발자 페이지에 있는 저널링 프로세스에 대한 도표이다.

기본적으로 모든 읽기와 쓰기는 mmap: protected (위의 설명에서는 private view) 에만 접근한다. 위에서 설명했듯이 mmap: protected는 mmap: write only (위의 설명에서는 shared view) 에서 한번 더 매핑한 것이며, 이 때 Copy on Write를 사용하므로 딱 변경된 데이터 만큼의 메모리만 더 사용한다.

읽기는 READ_UNCOMITTED이므로 protected view (private view) 에서 직접 읽는다.

쓰기는 protected view를 사용한다. 어떤 intent의 어느 위치에 기록했는지를 기억한다

PREPLOGBUFFER (로그 버퍼 준비)

WRITETOJOURNAL (group commit) - (저널에 기록함: 그룹 커밋)

WRITETODATAFILES (데이터 파일에 기록) - 저널 버퍼의 내용을 가지고 기록할 수도 있고, protected map의 내용으로 write only map에 memcpy를 하든지 맵의 메모리 주소로 file io를 할 수 있다

REMAPPRIVATEVIEW (private view 재지정) - 정기적으로 copy-on-write 뷰를 다시 지정하여 private view의 변경된 내용이 메모리를 다 잡아먹는 일이 없도록 한다

다이어그램 대로 이해하자면 mongodb에서 저널링을 켜면 변경된 내용을 데이터 파일에 직접 기록하지 않고, 먼저 변경된 내용을 redo 로그로 기록한 다음 (WAL?) 정기적으로 데이터 파일에 변경점을 반영(동기화)하는 것으로 볼 수 있다.

참고

How MongoDB's Journaling Works

Durability Internals (MongodB Server Development Guidelines)

Journaling Mechanics

[wonnyz]

Ubuntu에서 CLI로 juniper vpn client 사용하기

ncLinuxApp.jar 파일은 다운로드 받아놔야 한다.

필요한 라이브러리 설치

# x64 버전이면 설치해야 한다. x86이면 안해도 됨 sudo apt-get install ia32-libs

# unzip, msjnc에서 필요한 라이브러리 설치 sudo apt-get install unzip libwww-perl libgtk2-perl

msjnc 설치

# from http://mad-scientist.us/juniper.html wget -q -O /tmp/msjnc https://raw.github.com/madscientist/msjnc/master/msjnc chmod 755 /tmp/msjnc sudo cp /tmp/msjnc /usr/bin

.msjnc-profiles.cfg

vpn 설정은 다음과 같이 가정한다

site: vpn-site.com (주소), port: https 접속시 포트

realm: secure_realm (realm 설정은 알고 있어야 함)

user: 발급받은 vpn 계정

passwd: RSA Secure ID 같은 OTP 토큰 사용시 비워두고 securid => 1

VPN_USERID=my_vpn_id VPN_HOST=my-vpn-site.com VPN_URL=https://my-vpn-site.com VPN_REALM=my_realm VPN_NAME=my_vpn echo "\$valstore = {'default' => 1,'list' => {'vpn' => {'script' => undef,'proxy_user' => '','name' => '$VPN_NAME','securid' => 1,'port' => 443,'pfid' => 1,'host' => '$VPN_HOST','retry' => '','passwd' => '','realm' => '$VPN_REALM','url' => '$VPN_URL', 'user' => '$VPN_USERID','proxy_domain' => '','proxy_passwd' => '','proxy' => ''}}};" > ~/.msjnc-profiles.cfg

vpn 패키지 설치와 설정

# msjnc를 이용해서 vpn 패키지 설치. gui를 쓸 수 없으므로 도중에 중단되는데, ncsvc의 권한 설정만 해주면 된다. # installNC.sh에서는 sudo install -m 6711 -o root $1/../tmp/ncsvc $1/ncsvc 과 같이 설치하는 부분임 msjnc --jarfile ncLinuxApp.jar sudo chown root:root ~/.juniper_networks/network_connect/ncsvc sudo chmod 6711 ~/.juniper_networks/network_connect/ncsvc

사용하기

# 접속하기 msjnc --connect --profile "my_vpn" # 접속끊기 msjnc --disconnect

[wonnyz]

.mongorc.js

prompt = function () { var r = db.runCommand("isMaster"); var rst = db.adminCommand("replSetGetStatus"); var p = { mgs: (r.msg === "isdbgrid"), pri: r.ismaster, adm: (rst.errmsg === "unauthorized" ? "$ " : "# "), db: function(o) { return db.getName(); }, name: function() { if (this.mgs) return "mongos"; if (r.setName !== undefined) return r.setName + (this.pri ? "|PRI":"|SEC"); if (rst.info !== undefined) return r.info; return (rst.errmsg !== "unauthorized" ? db.serverStatus() : db.getMongo()).host; } }; return "["+p.name()+"]:" + p.db() + p.adm; } aauth = function(id,pw,c) { if (c === undefined) c = db; c.getSisterDB("admin").auth(id, pw); }

[backup:31001]:test# 같은 프롬프트로 당신도 매드 사이언티스트가 된 기분.

[wonnyz]

LoL 서비스 상황 알아보기

알고보니 간단한거였음 _-_..

http://ll.kr.lol.riotgames.com/pages/launcher/kr 페이지는 jsonp인데,

refreshContent({"status":false,"serverStatus":1, ...})

여기서 serverStatus:[UNAVAILABLE,ONLINE,BUSY,BLOCKED,LIMITED] 였음 (0부터)

[wonnyz]

MongoDB 스키마 디자인의 함정

역주: http://d.hatena.ne.jp/hiroppon/20130326/1364265864 의 글을 번역. 위의 글은 다음 글을 일본어로 번역하면서 코멘트를 추가한 것임 http://blog.serverdensity.com/mongodb-schema-design-pitfalls/ 

MongoDB를 간단하게 시작할 수 있는 이유 중 하나는 "스키마 디자인을 생각하지 않아도 된다"는 것이다. 단순히 데이터를 넣고 나중에 쿼리하면 된다. 따라서 초기에 개발을 시작할 때 편리하며 나중에 문서의 구조를 변경할 때에도 이점이 된다. 그러나…

Schemaless가 스키마 설계를 하지 않아도 된다는 의미는 아니다!

따라서 다른 데이터베이스들처럼 성능 향상 및 확장 가능하게 하기 위해서는 역시 스키마 디자인을 고려해야 한다. 이러한 점은 다음의 기사에서도 언급되고 있다.

http://docs.mongodb.org/manual/core/data-modeling/

http://blog.mongodb.org/post/38467892360/mongodb-schema-design-insights-and-tradeoffs-from

http://www.slideshare.net/jrosoff/mongodb-advanced-schema-design-inboxes

본 글에서는 MongoDB의 스키마 설계의 함정에 대해 다룬다.

문서를 키우지 않는다

기존 문서에 새로운 필드를 추가하거나 크기를 크게 하거나 (필드 이름 + 값) 하면 원래의 영역에 맞지 않게 되어 문서를 데이터 파일의 빈 영역으로 이동해야 한다. 이 작업은 데이터가 다시 쓰이게 되므로 성능에 영향을 준다. 또한 이러한 일이 대량으로 발생하면 MongoDB는 문서에 대한 여백 비율 (padding factor)을 조정한다. 따라서 문서는 기본적으로 더 많은 공간을 소비하게 된다. 그러나 원 영역 내에서의 (in-place) 업데이트는 빠르다.

프로파일러를 사용해서 문서가 이동된 것을 감지 할 수 있다. 만약 moved 필드가 true인 경우 문서는 재작성 (이동) 된 것이다. 이것을 시정하면 성능 개선의 여지가 있다. (아래)

MongoDB 문서를 디스크에 저장할 때 어느 정도의 패딩을 한다. 따라서 추후 문서를 업데이트할 때 약간의 크기 증가가 있었다고 해도 in-place update가 가능하다. 패딩 양은 문서 크기에 대한 비율로, 예를 들면 1.001과 같이 설정되어 있다.

위와 같이 업데이트에 따른 문서 이동이 많으면 이 값이 커진다 (1.0 ~ 2.0, default : 1.0 = nopad). 만약 이 값이 2.0이라면 문서를 저장할 때는 그 2배의 공간이 필요하게 된다. 당연히 이렇게 되면 디스크나 메모리의 소비가 효율적이지 않고 성능이 떨어진다.

이전에는 이 값은 커지기만 하고 완전히 제어할 수 없었지만, 2.2에서 compact나 각종 tool 등으로 지정할 수 있도록 했다. 또한 2.4 소스에서 업데이트시 축소 방향으로도 조정이 들어가 있는 것으로 보인다. (별로 신경 쓰지 않아도 되게 바뀌었는지도 모른다 → 확인 필요)

프로필의 예

// 이 DB의 프로필 (레벨 2)를 활성화 PRIMARY> db.setProfilingLevel (2); // 필드 추가 PRIMARY> db.testcol.update ({_id : ObjectId ( "514ac4666bff1b5721ca1bc1")}, {$ set {value3 : "a"}}) // 프로파일 결과는 system.profile에 저장되어 있다 PRIMARY> db.system.profile.find ({op : 'update'}) { "op": "update" "ns": "testdb.testcol" "query": { "_id": ObjectId ( "514ac4666bff1b5721ca1bc1")} "updateobj": { "$ set": { "value3": "a"}} "idhack": true, "moved": true, "nmoved": 1, "nupdated": 1, "keyUpdates": 0, "numYield": 0, "lockStats": { "timeLockedMicros": { "r": NumberLong (0) "w": NumberLong (394)} "timeAcquiringMicros": { "r": NumberLong (0) "w": NumberLong (8 )}} "millis": 0, "ts": ISODate ( "2013-03-22T04 : 30:35.504 Z") "client": "192.168.159.142", "allUsers": [{ "user": "crumb", "userSource": "admin"}], "user": "crumb @ admin" }

paddingFactor의 증감 확인

매번 update마다 평가되어 적당한 값으로 조정되는 모양.

또한 compact로 지정할 수 있는 paddingFactor는 compact를 위한 일시적인 값이며, 위의 paddingFactor에 관계없이 padding한다. 또한 범위도 1.0 ~ 4.0이다. 머리가 좋아진 반면 예측이 어려워진 것일까?

필드 연산자를 사용

전체 문서를 업데이트하지 않고 필드 지정을 사용하여 필요한 필드만 업데이트할 수 있다. 새 문서 전체를 전송하는 대신 업데이트할 필드에 set 및 remove 연산자를 지정할 수있다. 또한 increment 와 같이 특정 작업을 수행하는 연산자도 몇 가지 있다. 이들은 데이터베이스 통신뿐만 아니라 데이터 파일 처리면에서도 매우 효율적이다.

BSON 데이터 형식에 유의

문서는 필드의 데이터 형식을 변경하기만 해도 이동될 수 있다. 데이터를 저장할 때 그 형식도 고려할 필요가 있다. 예를 들면 (float) 0.0 (int) 0으로 한 경우 BSON data type이 달라서 문서의 이동을 일으키는 경우가 있다.

문서를 사전 할당(preallocate)한다

나중에 문서의 필드가 추가될 것을 알고 있다면 임시 값으로 미리 할당해 두었다가 나중에 $set 연산자로 실제 값으로 업데이트하여 문서의 크기가 증가하는 것을 막을 수 있다. 이때 위와 같이 데이터 형식을 명심해야 한다. 특히 null은 다른 데이터 형식이다!

그러나 사전 할당은 랜덤하게 일으켜야 한다. 갑자기 대량의 문서 insert가 발생하면 시스템에 부담이 될 것이다. 한번에 모든 작업이 일어나게 하지 말고, 미리 적절한 시간대에 작업해두는 것이 좋을 것이다.

여기서는 한 문서의 필드를 미리 할당할 뿐만 아니라 앞으로 사용할 예정인 레코드도 어느 정도 사전 배분 해두라고 하는 것 같다. 확실히 피크 시간대에는 "쓰기 작업이 한계다"라거나 "데이터 파일 추가 (2GB)"와 같은 갑작스런 I/O가 문제다 라고는 생각할 수 있지만, 솔직히 별로 어려운 점은 없었다.

단지 (나의 환경에서도) 새 insert보다 (in-place) update 쪽이 (모든 필드를 업데이트했다고 해도) 배 가까이 빠르기 때문에 곤란한 사람은 해볼만한 가치가 있을 것 같다.

필드 이름도 공간을 차지한다

수백만개 정도의 레코드 수에서는 별로 중요하지 않다. 그러나 수십억의 레코드를 처리할 경우 인덱스 크기에도 꽤나 영향을 끼친다. 디스크 용량은 상관없다 해도 메모리는 다르다. 데이터가 가능한 메모리에 올라와 있기를 바랄 것이다.

_id를 활용할 것

모든 컬렉션은 _id 인덱스를 가지고 있다. 따라서 이것을 어플리케이션 용도의 고유 인덱스로 활용할 수 있다. 예를 들면 (자사의) Server Density 용 서버 모니터링 정보로 날짜, 계정 ID, 서버 ID와 같은 구조를 가진 컬렉션의 경우, 문서를 확인하기 위해 이러한 필드 복합 인덱스 (날짜, 계정 ID, 서버 ID) 대신 _id를 사용하여 쿼리 할 수​​ 있다.

당연하다면 당연한 것이지만 애플리케이션 차원에서 _id를 적극적으로 쓰세요- 라는 것이다. 귀가 아플 정도

covered index를 사용하고 있는가?

만약 쿼리를​​ 실행할 때 사용할 인덱스에 모든 반환 필드가 포함 된 경우 쿼리는 인덱스 참조로 끝나며 MongoDB는 데이터 파일을 읽을 필요가 없다. 따라서 성능을 최대한 높이기 위해 모든 데이터를 메모리에 올릴 필요성이 줄어든다. (역주: 인덱스만 메모리에 올려도 된다는 말) 이것을 covered query라고 한다. covered query를 사용하면 explain 결과가 indexOnly = true 로 나온다.

일반적인 RDBMS 에도 비슷한 기능이 있기 때문에 MongoDB가 특별한 것은 아니고 오히려 일반적인 방법. 적극적으로 사용할 것.

컬렉션이나 데이터베이스를 최대한 잘 사용한다

여러 컬렉션 및 데이터베이스에 데이터를 분할하는 것을 고려한다.

컬렉션의 drop은 모든 문서를 remove하는 것보다 훨씬 빠르다. 이것은 데이터 보존 기간을 다룰 때 도움이 된다. 예를 들어 일 단위로 컬렉션을 나누어 대량의 컬렉션을 다루더라도 일반적인 처리 방법과 크게 다르지 않다. 단지 네임스페이스의 제한 등 몇 가지 주의가 필요한 항목이다.

데이터베이스 수준 잠금이 있으므로, 데이터베이스를 분리하여 부하 집중을 피할 수 있다. 예를 들어 인증 DB에서 처리량이 높은 로그 DB를 분리할 수 있다.

전체적으로 약간 알기 어려워서 대강 설명

일마다 컬렉션을 나누어두면 보관 기간이 만료된 문서의 삭제 처리는 컬렉션 drop으로 끝이므로 빨라진다. 컬렉션이 늘어나고 복잡해지는 것은 별거 아니니까 앱으로 처리하라고..

네임스페이스의 제한

- nssize 옵션에서 네임스페이스 의 데이터 파일 크기를 지정할 수 있다. 이 크기는 데이터베이스에 저장할 수있는 컬렉션 수와 직결된다. 보통 초기 값 16M으로 충분하지만 (나는 4M에서 사용함) 수만의 컬렉션을 만들고 싶다면 튜닝이 필요

데이터베이스 수준 잠금

본문의 인증 DB의 예는 이해가 어렵다. 인증 DB (admin)가 잠기면 모든 쿼리가 멈추잖아! 라고 말하고 싶은가?

MongoDB 2.2부터 전역 잠금 (mongod 전체 잠금)에서 데이터베이스 수준 잠금 (특정 DB의 처리를 잠금)로 변경되었다. 알기 쉬운 예로, compact 명령이나 repairDatabase 등의 명령으로 디스크 공간의 청소를 하려면 게시된 데이터베이스는 청소가 끝날 때까지 잠기지만 다른 데이터베이스 작업은 잠금의 영향을 받지 않는다. 그 밖에도 데이터 파일이 추가될 때의 잠금 등 여러가지 고려해야 하는 것이 잠금 타이밍이다.

어? 그런데 compact 명령이 어느새 DB를 잠그지 않는 모양.

모든 것을 테스트하라

많은 사람들이 MongoDB의 확장성을 오해하고 있다. 그 자체가 간단한 것은 아니다. 잘 생각하고 이해하고 테스트하는 수밖에 없다. 프로파일러 및 explan을 활용하여 생각대로 동작하는지 시험하라. 그리고 라이브 코드에서도 일정 기간 동안은 벤치마크를 해볼 것. 이 글에서 다루지 못한 훌륭한 예제를 다룬 링크가 있다.

[wonnyz]

exists / apply를 이용한 쿼리 비교

일별로 데이터를 집계해 넣는 테이블이 있다. 원본 데이터가 제 날짜에 들어오지 않았다면 그 날의 데이터는 빈다. 일별 데이터 건수는 몇만에서 십만단위가 될 수도 있다. (더 많을 수도 있고)

목표는 데이터가 들어온 날만 찝어서 알려주는 쿼리 작성.

처음에는 위에 있는 exists를 이용한 서브쿼리를 짰는데, 나중에 비슷한 것을 다시 만들면서 2005부터 추가된 apply 구문을 사용했다. 이게 훨씬 빠른데..

위 exist 구문의 상관쿼리를 any 연산자를 사용하여 다음과 같이 변경할 수 있다.

select dt from dbo.bdt_Date d where d.dt between @monStart and @monend and d.dt = any ( select sDate from dbo.SomeLog ) order by 1

둘다 NL 조인으로 풀어내며, 양쪽 모두 (12월 1일~12월 31일) 31번 index seek 들어간다. 이렇게만 놓고 보면 큰 차이가 없어야 하는데.. 차이는 다른 곳에서 난다.

set statistics io on go dbcc freeproccache dbcc dropcleanbuffers ...쿼리1... go dbcc freeproccache dbcc dropcleanbuffers ...쿼리2...

했을 때 결과는 다음과 같다.

DBCC 실행이 완료되었습니다. DBCC에서 오류 메시지를 출력하면 시스템 관리자에게 문의하십시오. DBCC 실행이 완료되었습니다. DBCC에서 오류 메시지를 출력하면 시스템 관리자에게 문의하십시오. (29 row(s) affected) 테이블 'SomeLog'. 검색 수 31, 논리적 읽기 수 281, 물리적 읽기 수 3, 미리 읽기 수 693, LOB 논리적 읽기 수 0, LOB 물리적 읽기 수 0, LOB 미리 읽기 수 0. 테이블 'bdt_date'. 검색 수 1, 논리적 읽기 수 2, 물리적 읽기 수 2, 미리 읽기 수 0, LOB 논리적 읽기 수 0, LOB 물리적 읽기 수 0, LOB 미리 읽기 수 0. (1 row(s) affected) DBCC 실행이 완료되었습니다. DBCC에서 오류 메시지를 출력하면 시스템 관리자에게 문의하십시오. DBCC 실행이 완료되었습니다. DBCC에서 오류 메시지를 출력하면 시스템 관리자에게 문의하십시오. (29 row(s) affected) 테이블 'SomeLog'. 검색 수 31, 논리적 읽기 수 245, 물리적 읽기 수 2, 미리 읽기 수 36, LOB 논리적 읽기 수 0, LOB 물리적 읽기 수 0, LOB 미리 읽기 수 0. 테이블 'bdt_date'. 검색 수 1, 논리적 읽기 수 2, 물리적 읽기 수 2, 미리 읽기 수 0, LOB 논리적 읽기 수 0, LOB 물리적 읽기 수 0, LOB 미리 읽기 수 0. (1 row(s) affected)

이걸 연 수준 데이터로 확대하면 차이는 더 늘어난다.

(363 row(s) affected) 테이블 'SomeLog'. 검색 수 366, 논리적 읽기 수 3224, 물리적 읽기 수 8, 미리 읽기 수 6977 (363 row(s) affected) 테이블 'SomeLog'. 검색 수 366, 논리적 읽기 수 2784, 물리적 읽기 수 8, 미리 읽기 수 394

물리적 읽기 수는 큰 차이가 없는데.. 미리 읽기에서 작두를 잘못탄게 아닌가 하는 생각이 좀 들고, 논리적 읽기 (버퍼 캐시에서 읽어들이는) 차이가 좀 나는 것도 있고.. 하여튼 결론은 apply ( select top(1) ) 쓰는게 낫다는 것.

[wonnyz]

SQL Server Agent 작업 실행중인지 판단

필요해서 급조해봄 use msdb go -- 해당 작업이 현재 실행중인가? create function dbo.fn_JobIsRunning ( @job_id uniqueidentifier ) RETURNS TABLE AS RETURN select is_running = case when stop_execution_date is null then 1 else 0 end from msdb.dbo.sysjobactivity ja where ja.job_id = @job_id and ja.session_id = ( SELECT top 1 session_id from msdb.dbo.syssessions order by session_id desc ) go -- 낮은 권한에서도 실행할 수 있도록 함 grant select on fn_jobisrunning to SQLAgentUserRole go -- TEST execute as user='agentUser' select * from dbo.fn_jobisrunning ('48A9CAD5-41C2-4FD9-9B45-67B485122F09') revert