얀테의 법칙

친분이 있는 교수님께서 하나의 글을 공유해주셔서 내용을 봤다.

몇 몇 태도에 대해서는 나도 좀 익혀야 하는 태도인 거 같다. ㅠㅠ

특히 겸손에 대한 강조를 하는 부분이 여러모로 직관적인 하나 하나의 규칙으로 되어 있는 점이 요즘에는 맘에 든다. 직관적 이야기가 요즘은 엄청 먹히다보니 여러모로 느껴지는 바가 좀 많다.

근데 모든 것에 공감하는 건 아니다. 북유럽 특유의 문화 환경과도 엮여있는 것이 좀 많이 보인다. 특히 당신을 누가 도와줄 거라고 생각하지 말 것 자체가…  첨부터 도움을 기대하면 안되지만 그렇다고 아예 없다고 하기도 뭐하고…

읽어보고 공유해서 나쁜 글은 아닐 거 같다. 특히 난 내가 한국 회사 다닌다면 이걸 사무실 게시판에 붙이고 싶을 정도… (그리고 위에서 욕먹겠지..)

한명이 강의하듯 하는 스터디? 그게 강의지 스터디냐!

판교의 모 회사와 그와 비슷한 수많은 IT 회사들의 개발자 분들이 이거 보면 욕 좀 하겠지….?

하지만 좀 적으려고 한다.

애당초 스터디를 하는 목적이 뭐냐고 하면 다들 하는 소리는 똑같다. 혼자 하긴 힘들 거 같으니 여러 사람이 여러 파트를 나눠서 해당 파트만 깊게 공부한 뒤 공부한 내용을 다른 팀원들에게 공유하는 것이다.

라고 하면 좋은 취지인데….

정작 스터디 망하는 케이스를 엄청 본 거 같다. 결국 스터디 파 되고 돈은 돈대로 날리고 혼자 공부하게 되는 케이스… 대학에서도 그런 경우 수도 없이 보면서 회사 가면 될 거라고 생각하면 오산이다. 특히 더더욱 일에 집중해야 하는 상황에서 그 외의 기술들을 익혀야 하는 압박감에 스터디를 만들어서 많이들 하는데….

그 중에서 제일 큰 것이 바로 한 명이서 강의하는 형식의 스터디이다. 엄청나게 대단한 능력의 사람 한 명이 다른 사람들에게 강의하는 형식을 말한다. 이 경우에는 그걸 이끄는 사람이 정말 엄청난 기술력과 리딩 능력이 있어야 한다. 어느정도 좀 큰 회사에 거물들 몇 있는 곳에서 자주 일어나는 스터디 형식이다.

사실 개인적으로는 이런 방식의 혼자서 강의하는 형태의 스터디를 하려면 그에 맞는 조건이 있어야 된다고 본다.

  • 스터디 때 강의하는 개발자가 최소한 그 기술로 프로젝트 개발을 해봤어야 한다. 계약서 쓰고 하거나 상업적인 솔루션을 회사 내에서 개발해 봤다면 훨씬 좋다.
  • 질문에 능동적으로 답변할 수 있을 정도로 알아야 한다.
  • 예제 코드를 보고 생각을 하고 고민을 하더라도 이 예제 코드를 자기가 알고 있는 형식으로 설명할 수 있어야 한다.

종합적으로 보면 본인이 피 쏟고 시간 쏟고 한 만큼은 자연스럽게 대답할 수 있어야 한다. 해당되는 기술의 버전 업그레이드가 되더라도 저정도 해뒀으면 어느 정도 모체가 되는 이야기는 다 알아듣기 때문에 더더욱 쉽게 본인은 이해할 수 있고, 그를 적용시키는 법도 안다. 그렇다면 가르치는 것 또한 할 수 있다. 가르치는 것 자체가 또 다른 어려움을 가지고 있지만… 못하지는 않을 것이다. 사실 개발자 컨퍼런스에 나와서 이야기 하는 분들도 다 자기들이 해본 기술들과 버전들 기반으로 이야기 하는 경우가 태반이기도 하고…

근데 사내에서 이런 식으로 스터디의 경우에 대부분이 그냥 겉으로 쓱 햛고는 대충 가르쳐 주고 그대로 하다가 이해 안되면 다음 시간에 하면서 여러모로 시간 쏟고 그런 것이 몇 주 지나면 계속 누적되고….

좀 악순환이 자주 된다.

그러다 보면 정작 진짜 그냥 책으로 쭉 읽거나 튜토리얼 따라하기를 일주일 정도만 한 수준 가지고 몇 개월로 스터디를 끌려 다니는 케이스도 좀 있다.

준비하는 사람이야 자기가 말할 내용에 대해 어느정도 준비 좀 하고 그에 따른 예시 만들어서 돌려보고 준비하면 된다. (내 블로그도 그런 식으로 작성중이고..) 그리고 해당 예시 공유 좀 하고…

그러다 보면 그 사람들의 스킬은 참 잘 늘어나있다.

듣는 사람들의 이야기는 근데 좀 다르다.

이 사람들이 이걸 보고 어느 정도 참여 의식을 가져야 하는데…

하는데….!

학원 강의듣는 태도로 듣는다. (왜냐고? 몸에 베여있거든.)

이러다가 생기는 결론 또한 간단하게 진행된다.

  • 아, 저분 잘하는 사람이다.
  • 나 좀 배웠다.
  • 예제 따라 좀 하면 되겠지.
  • (하다가) 어? 뭐지? (검색) (루프)

……사람 수동적으로 변하는 건 한순간이다.

이러다가 만약에 저 스터디 이끄는 사람이 금나 해버리면 바로 그냥 파토다. 내용을 더 깊게 들어가기 위해 경험을 공유하고 토의하고 하는 시간도 있어야 하는데 그럴 시간따윈 없는 경우 허다하다. 회사 일 바쁜데 그런 시간까지..?

몇 대기업들은 개발자도 아닌 사람들이 개발 업무에 관여는 해야 하니 정말 학부 기초 수준의 내용을 스터디하는 데 시간 낭비하는 케이스를 엄청나게 듣는다. (SI 개발회사들) 그러면 진짜 더더욱 미친다.

그러면 결국 기다리는 건 퇴사 테크인 듯 하다. 그러면서 더더욱 실력 엄청난 기술자들이 모이는 곳으로 강사하던 사람은 떠날 것이고, 그렇지 않은 사람들은 여러 자괴감을 받을 것이고… 그런 거 없이 그냥 자기 일 하기 바쁜 사람도 있을 것이다.

그래서 스터디 분위기 잘 봐서 혼자서 다 독박으로 상의하듯 하는 스터디는 스터디라고 하지 말아야 한다. 그냥 강의다.

p.s. 갠적으로 스터디 엄청 싫어한다. 내가 첨부터 끝까지 다 공부하고 이해하지 못하면 안되는 스타일이기도 해서 솔직히 내가 다 혼자 공부하고 혼자 다 이용해 먹는 스타일인 것도 있는데, 저런 식의 강의도 진행을 당해보니 정작 그냥 학원 강사가 이런 기분이구나라고 생각했다.

윈도우 10 + 윈도우 스토어 우분투 + 루비 온 레일즈…

필자는 여러모로 리눅스를 많이 쓴다. 특히 우분투..

그렇지만 윈도우를 안쓰는 것도 아니고, 많은 개발자들이 여전히 윈도우 환경을 선호하기도 한다. (시계 옆에 스팀이 없으면 안되는 자들이 있다.)

뭐, 게다가 윈도우 10 환경에서는 대놓고 bash가 지원되고 리눅스들이 깔리고….

그러니 이젠 그냥 리눅스에서 이용하는 방법을 보여주려 한다.

설치법은 이전 블로그 글에 적었다. (괜히 적은 거 아니다. 다 이유가 있다.)

그럼 이제 설치 다 했으니 프로젝트를 만들거나 윈도우에서 만든 프로젝트나 받아온 프로젝트 폴더를 끌고 와야 하는데…

경로를 알아야 할 꺼 아냐! 근데 경로 쉽다.

  • 우분투에서 윈도우 경로로 가는 방법

/mnt/c <- 윈도우의 C 드라이브 경로다.

20180517_155117.png

그럼 이제 거기서부터 내 프로젝트가 있는 폴더까지 들어가서 실행을 하면 된다.

  • 윈도우 탐색기에서 우분투의 홈 폴더를 찾아가는 방법

될 수 있으면 하지 마라. 근데 어디 있는지는 알려주겠다.

C:\Users\[사용자 계정 폴더]\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\rootfs

들어가 보면 우분투의 / 가 보일 것이다. 거기서 home/[사용자 이름 폴더] 가 작업을 했던 경로다.

이렇게 하면 진행하는 데 무리 없이 할 수 있다. 단, 윈도우 환경에서 이용하던 것과는 다르므로 반드시 bundle install 작업과 rails db:migrate를 통해서 기존에 작업했던 gem들과 데이터 모델은 만들어 줘야 한다.

그 덕에 아까 작성했던 bcrypt 문제는 해결되었다.

 

cannot load such file — bcrypt_ext

레일즈에서 bcrypt를 이용하려고 하는데 터진 문제다.

지금 개발중인 레일즈 환경이 ruby 2.4.2, rails 5.1.6, windows OS 환경이다. 근데 사용자 관련 기능을 넣고 암호 저장으로 저걸 쓰려고 하는데 오류가 난다.

아마 검색해보면 죄다 윈도우 환경에서 안된다고 나온다. (ㅅㅂ…)

게다가 버전도 아예 정해져 있다. 3.1.11…. 아오 썅..!

이거 해결책이 골때린다. 그래서 내가 이건 아예 블로그로 남기려고 한다.

  • gem을 다시 설치한다.

신기하게도 이게 스택 오버플로우랑 레일즈 포럼에서 제일 인기 많은 방법이다.

윈도우의 루비와 레일즈 환경에서 동작시키면 이게 x64_mingw 환경에 맞춰서 바이너리가 생성된다. 루비와 레일즈의 devkit 설치가 msys, mingw 기반으로 되어 있기 때문에 몇몇 바이너리가 대놓고 이렇게 되어 있다. 이런 경우에는 루비 플랫폼 환경에서 쉽게 끌어다가 쓸 수 있도록 해주면 된다.

gem uninstall bcrypt 명령어로 지우는데, 여러 버전이 설치되어 있으면 그대로 전부 다 지워준다.

그 다음에 설치를 다시 하는데 다음과 같은 명령어로 설치를 한다.

gem install bcrypt –platform=ruby

이렇게 설치하면 설치된 gem 번들 뒤에 x64_mingw 가 붙어있지 않는 버전이 설치된다.

그 다음에 레일즈에서도 Gemfile에 추가한 번들이 있을 것이다. 그것 뒤에 플랫폼 지정을 적어준다.

gem ‘bcrypt’, ‘~> 3.1.7’, platforms: [:ruby]

혹시 모르니 x64_mingw를 그대로 쓰고 싶은 분들은 플랫폼을 이렇게 바꿔준다.

platforms: [:ruby, x64_mingw]

앞에 루비를 지워도 되는데 어차피 어느 환경이던 다 쓸 수 있도록 복수 환경을 지원한다고 해도 별 지장은 없다.

  • 환경을 옮긴다.

이래도 오류가 나는 사람들 많다. 진짜로… 다른 해결법이 있으면 좋겠는데, 정 방법이 없다면 아예 개발 환경을 옮겨봐라. 일단 규링이 해본 봐로는 리눅스 환경에서는 100% 문제 없이 된다.

윈도우 10을 이용하는 사용자라면 마이크로소프트 스토어에 있는 우분투를 설치 후 그곳에다가 환경을 만들어서 이용하는 것도 좋은 방법이다. 그 내부의 경로로 들어가는 방법은 별도의 블로그 글을 작성하도록 하겠다.

리눅스 서버를 자체 운영하거나 도커 환경에서 만들어서 이용하고자 한다면 그 방법도 좋은 방법일 수 있겠다. 단, 개발이 좀 번거롭긴 하겠다만… 일단 오류는 없다.

……

어이가 없다. 진짜….

또 다른 해결 방법이 있다면 꼭 블로그로 내용 남기도록 하겠다.

[개발자의 취향] 흐드미(HDMI) vs 에(DP) …..

모니터 이야기를 너무 지루하게 썼는데… 좀 이유가 있다.

좀 몇 가지 더 적어보려고 했는데 갑자기 모니터 취향뿐만 아니라 포트 가지고도 이리저리 말이 많더라….ㅡㅅㅡ;;;

큰 화면 + 큰 해상도를 지원하는 데 있어서 요즘은 hdmi랑 dp를 사용하는 것이 당연하게 되어 있다. 듀얼 링크 dvi로는 한계가 있기 때문이다. 그러다 보니 지원되는 포트를 어떻게 쓰느냐에 따라서의 취향 차이가 생겼다.

일단 둘 다 영상, 음성 다 지원된다. 게다가 이게 웃긴 것이 케이블 장난이 통하지도 않는 것이다 보니 그냥 진짜로 본체에 달린 그래픽카드나 노트북에 있는 포트 차이 정도로 이해하면 될 정도로 간단한 선택화가 되어있다.

여기에 그래픽카드 제조사들도 똑같은 칩셋인데도 불구하고 한 녀석은 흐드미만 잔뜩.. 다른 녀석은 dp만 잔뜩….

그러다보니 이것도 취향인가 싶어지는….ㅡㅅㅡ

어차피 그냥 이렇게 포트 잔뜩 연결하고 할 수많 있으면 좋은 규링이지만..ㅡㅅㅡ

p.s. 아, 참고로 흐드미를 잘 이용하는 회사랑 dp를 잘 이용하는 회사는 차이가 있다. dp를 잘 이용하는 회사는 정통적으로 컴퓨터를 주로 제조하던 회사들이 주로 dp를 잘 이용하고, 흐드미를 잘 이용하는 회사는 주로 가전 AV 기기를 엄청 만드는 회사들이 잘 이용한다. 흐드미는 사실 멀티미디어 기기에 최적화 되어 있는 데다가 그에 따른 기술과 라이센스가 들어간다. 그래서 그냥 그쪽으로 찍어내는 게 편하다. 반면 dp는 dvi의 확장 개념이라 컴퓨팅 환경에 맞춰져 있는 것도 있고, 라이센스 비용따윈 없다. 이걸 컴퓨터 제조회사들 입장에서는 쓸데없이 낼 필요가 없는 것도 있다. 그래봤자 일반 사용자들이 쓰는 기기들에서는 그런 차이 확 나는 그런 건 얼마 없지만…

[개발자의 취향] 모니터….

필자가 대학원 시절에 썼던 환경이다. 필자는 자잘(?) 한 모니터를 여럿 쓰는 걸 좋아한다. 집에서도 모니터는 트리플 이상으로 쓰고 있고, 노트북에도 아이패드로 듀엣(duet)을 이용하여 모니터로 쓰는 걸 좋아한다. 그래서 한 화면에는 소스코드, 한 화면에는 디버그 출력, 한 화면에는 실행 결과와 검색 화면, 한 화면에는 메신저(와 트위터)…

그런데 그냥 모니터 큰거 하나나 둘만 있어도 충분하다는 사람도 있다. 큰 모니터 + 큰 해상도로 많은 글자와 화면이 한번에 표현되는 걸 좋아하는 사람들이다.

그렇다.

모니터도 취향 탄다.

개발자들은 색감이니 뭐니 하는 거 그닥 잘 안따진다. 단, 글씨 잘 보이는 거에 대해서는 진짜 따진다. 사실 그게 직업상 제일 중요한 것이기도 하고 해서 뭐…

필자는 작은 글자를 잘 안보려고 한다. 그래서 폰트도 주로 14포인트로 맞춰서 쓰기도 한다. 그러면 스크롤 하고 할 일이 늘어나지만 애당초 코드 길이가 그렇게 길게 막 짜는 스타일도 아니라 알아서 잘 적응해서 쓰는 편이다. 반면에 그냥 있는 그대로의 폰트 크기만 해도 충분한 사람들은 그냥 잘, 그리고 많이 표현되는 걸 좋아한다. 그리고 그대로 실행 화면에서 바로바로 띄워지고 오류 나는 코드 줄이 바로 보이고 하는 그런 것을 좋아한다.

사실 이것도 진짜 정답은 없다. 필자처럼 그냥 코드랑 검색 결과랑 디버그 화면이 막 널부러져 있어야 하는 사람은 여러 모니터를 잘 쓰는 것이고, 널부러져 있어도 그냥 한 화면에서 열심히 뒤적거리면서 찾거나 배치 잘 해서 이용하는 사람도 있는 것이니깐…..ㅇㅂㅇ

[개발자의 취향] 키보드…

개발자의 취향으로 전에 에디터 화면에 대해서 잠깐 딴 소리를 적은 적이 있는데…

오늘은 그 2탄이다. ㅇㅂㅇ;;;

그 주제는 바로 키보드.

키보드는 사실 좀 여러모로 웃긴 환경이 지속적으로 발생하다 보니깐 적으면 안된다는 생각도 있었는데… 그래도 좀 적어보려 한다.

내가 미국을 가보면 거기선 또 어떤 환경을 볼 지는 모르겠지만 일단 지금의 한국 개발자들은 키보드를 한번 쯤은 꼭 갈고 시작했을 것이다.

그냥 일반적으로 쓰는 멤브레인 쓰다가 어느샌가 기계식 키보드가 확 유행하면서 다들 하나 둘 바꿔보고, 그리고 나서 사무실에서도 개인 용품으로 소소하게 행복함을 느끼려 하거나 뭣같은 상사의 엿소리를 듣지 않기 위해 일부러 키보드 소음을 만들기 위해 이용한다던가(?!) 하는 등 여러 이유로 인해서 기계식 키보드를 한번 거치고 했을 것이다.

근데 그것도 나중에 보면 그냥 취향이 되는 거 같다.

그대로 기계식 키보드 매니아가 되어서 여러모로 써보고 나한테 좋은 게 뭔지 찾아보는 사람도 있는 가 하는 반면 그냥 멤브레인보단 좀 더 좋은데 뭐 일단 샀으니 쓰자 하는 사람들도 있을 것이고, 기왕 가는 거 무접점까지 간다! 하는 사람도 있을 것이다. ㅇㅂㅇ;;;

그런 걸 보면서 “과거에는 키보드를 기계장치로 생각해서 만들었던 것을 기술이 발전해서 맴브레인으로 넘어왔더니 다시 과거 향수에 젖어서 기계식을 찾는 꼴”이라면서 비판하는 사람도 있다.

이것도 진짜 답은 없기는 매한가지는 하다…

실계 사례…..는 너무 많고, 모 유명한 애니에서도 잘 살펴보면 특정 개발자분의 키보드가 다른 사람들과 다르다는 걸 알 수 있다. (심지어 소리도 다르다.)

단, 매너는 있게 행동해야 한다는 걸 보여주는 것이 키보드 같다. 바로 키보드 소음 때문인데, 청축을 사무실에서 아무렇게나 쓰는 건 다들 안하려고 하는 분위기인데도 불구하고 멋대로 쓰고 하는 건 좋지 않다. 진짜 싫은 상사 엿먹이려고 소음 만드는 케이스가 아니라면…ㅇㅅㅇ;;;

마지막으로, 입력장치 명가나 컴퓨터 기계를 잘 만드는 특정 회사들의 맴브레인은 뭔가 다르긴 다르다. 델이나 HP 등에서 나오는 맴브레인은 각자의 특색이 있는 데다가 은근 오래 쓸 수 있게 나오기도 하고, 로지텍도 나름 입력장치로 유명한 곳이어서 그런지 잘 나온다. 마소는 인체공학 키보드를 한참 연구하고 했던 곳이어서 그런지 여기저기 입력 느낌이 다르게 해서 오래 타자를 쳐도 문제 없는 느낌으로 만들기도 하고…

…쓰고보니 또 잡소리네.

뭐, 이것도 취향이다.

소스코드 공개를 보안땜에 감시해야 한다고 떠드는 보안뉴스…

늬들은 개발에 대한 이야기를 쓸 자격이 없다라고 먼저 이야기하고 싶다.

아니, 좀 더 정확하게 이야기하면 보안에 대한 이해 자체가 낮은 것들이 보안뉴스를 한다고?

아침에 이 기사 내용 보고 진짜 어이없어서 멍때렸다. 깃허브에 보안 취약한 부분이 발견되어 공격당하나 하는 그런 소리인 줄 알고 클릭했는데 거기 올라가 있는 소스코드는 지적 재산권 올려놓은 거랑 같은 수준이라는 소리에 더불어서 회사 코드를 공개한다는 것에서 여러모로 취약점이 드러난다는 소리… 거기에 로그인 크리덴셜이 공개된다는 소리….

아 ㅆ….

그럼 리눅스도 커널 소스코드 공개 되어있으니깐 쓰면 안되겠네?

gcc 왜 씀?

오픈소스 프로젝트들은 그럼 전부 보안 취약한 거니깐 쓰면 안된다는 거냐?

…………………

늬들은 KISA 사건 수준으로 병신 레벨을 인증했다.

사실 기사에 보면 몇 가지 이유에 대해서 여러모로 적어놨는데 이 내용에 대해서 하나 하나 파해치기로 하자.

이유 1) 소스코드가 풍부하다. 말이 좋아 소스코드 공유 사이트지 사실은 지적재산이 공유된다고 표현해도 무리가 없다. 그 자체로도 해커들이 훔치기 좋아하는 아이템들인데, 다양한 소스코드를 빌려 멀웨어들을 빠르게 개발할 수도 있다. 시간이 절약되고, 공격 기획이나 사전 정찰과 같은 작업에 더 많은 자원을 투자할 수 있게 된다.

답변 1) ….. 오픈 소스를 이용한 개발은 요즘 다 이런 식이다. 그리고 요즘의 개발 트랜드도 전부 이런 식이다. 단순하게 이용할 수 있는 부분은 그냥 떠도는 수준까진 막 복붙으로 가도 문제 없다. 진짜 핵심적인 부분을 직접 개발해야 하기 때문에 개발이 어려워지는 것이다. 그리고 그에 대해서 “노하우”를 공개하기 위해 코드를 공개하는 거지 코드를 다 까는 게 아니다. 그리고 그거야 당연히 해커들이 아이템 만들어 쓰는 데도 마찬가지다. 그들 또한 밑바탕은 개발자다.

이걸 부정하는 건 아무것도 안통하는 곳에서 그냥 시디로 툴 깔고 쓰고 해야 했던 시절의 이야기이다. 아니, 시디도 없던 시절의 이야기일꺼다.

이유 2) 또 다른 공격 표면이 된다. 소스코드를 훔치거나 가져다 쓰지 않고도, 개발 과정을 주시하면서 해당 소프트웨어 혹은 애플리케이션에 대한 특징 및 취약점을 미리 간파할 수 있다. 그리고 나중에 프로젝트가 끝나고 정식 앱이 되었을 때, 남들이 모르는 공격 루트를 확보할 수 있게 된다. 코드를 중간중간 가져다가 남몰래 여러 공격 실험을 진행할 수도 있다.

답변 2) 그 정보를 공유해서 보안을 강화하고자 하는 것이 보안 아닌가? 그러기 위해 공개하는 거다. 악용하는 건 그 자체로 사회적인 범죄가 되는 것이지 그걸 기술 테스트로 하여 모의로 해킹해서 그 정보를 공유하고 하면 보안 강화 아닌가? 그리고 그런 걸 위해서 소스 공개하는 수많은 프로젝트들은 그럼 전부 보안이 약하다고 하는거냐? 그럼 리눅스 왜 쓰냐? 리눅스 커널 기반의 운영체제들은 전부 보안 취약한 거네? 왜 써? 니들 안드로이드 다 갖다 버려라?

이건 진짜로 오픈소스 운동 초~~~창기에 나오던 보안 취약에 대한 이야기 그대로를 가져온 병신 의견이다. 이걸 말했다는 거 자체는 진짜로 IT랑 개발 아무것도 모른다고 인증한 것이다.

이유 3) 로그인 크리덴셜도 많다. 실제로 자주 일어나는 일인데, 깃허브에서 개발되는 코드와 파일들 내에는 로그인 정보가 담겨 있기도 하다. 아마존의 AWS와 연계된 앱을 만들 때 개발자가 실수로 자기 계정 로그인을 코드에 그대로 넣어놓는 일이 왕왕 발생한다. 해커들도 이를 알고, 코드에 접근해 로그인 크리덴셜이 있을만한 부분을 검색한다. 또한 훔쳐낸 크리덴셜을 가지고 추가 범죄를 저지르기도 한다.

답변 3) 내가 화 덜 내는 이유다. 로그인 크리덴셜의 경우에는 개발자들이 스스로 밖으로 새지 않도록 관리하는 것이다. 근데 이들은 소스코드를 공개하는 입장에서도 중요하게 이용되는 내용이다. 대부분의 오픈소스 코드에 보면 DB, 클라우드에 접속하는 부분에 대해서는 별도의 설정 코드 파일을 만들고,  그곳에서 별도의 입력을 관리하도록 되어 있다. 그렇지 않은 코드들은 그런 부분에 소홀한 부분이다. 조금이나마 신경쓰고 하는 사람들이라면 당연하게 대처하고 있는 부분인데 그 부분을 놓치고 있는 사람들은 보안에 대해서 알려야 한다. (깔 곳 없는 내용이다.)

이유 4) 인증되지 않은 접근이 가능하다. 개발자들은 많은 경우 회사 내 주요 서버나 데이터로 무제한 접근이 가능하다. 자기 개인 메일 계정을 가지고 회사에 접속하기도 하는데, 이러한 메일 주소만 해커가 획득하게 되어도, 회사 전체가 크게 취약해지는 것이나 다름없다. 심지어 개발자에게는 지나치게 많은 데이터로의 접근을 허용하는 회사가 대다수인데, 그 개발자가 깃허브를 즐겨 사용한다면 다시 생각해볼 필요가 있다.

답변 4) …….그냥 그 사람 대신 해커가 들어가서 그 사람인 척 하면서 살면 회사의 모든 걸 전부 다 해킹할 수 있는데…?  회사 단위로 오픈소스를 하게 되면 당연히 그 회사의 전용 이메일이나 어카운트를 이용하겠지 그걸 개인껄 이용하게 한다고? 얼마나 허접한 보안 레벨의 회사냐? 최소한 업무 메일이랑 개인 메일 구별 정도도 못한다고? 후………….

이유 5) 내부자 위협을 감추기에 편리하다. 깃허브가 제대로 된 모니터링을 받고 있지 않아서 생기는 문제인데, 깃허브에서는 얼마든지 개발자 혹은 악성 내부자가 활개를 칠 수 있다. 예를 들어 한 사람이 수십 개의 코드 리포지토리에 자꾸만 접속한다면, 수상하게 생각할 수 있어야 하는데, 애초에 회사가 깃허브를 모니터링하고 있지 않으니 이런 ‘명백히 수상한 행위’도 적발되지 않는다.

답변 5) 이건 진짜 깃허브 뿐만 아니라 오픈소스 프로젝트들을 참고하려고 하는 행위를 단 한번도 안해본 사람들의 이야기다….

달면서도 열이 받는다. 오픈소스 프로젝트들에 대한 이해 자체가 없으니 코드 공유 == 보안 취약성 이라고 이어지는 그런 수준으로 이어진다.

이렇게 내가 일일이 달았는데도… 기사 내용에 뒤에 보면 이에 대한 해결책이 있다고 하면서 내가 까는 걸 이상하게 여기는 분들이 있을 텐데…

그 내용도 보면 그냥 코드 꽁꽁 감싸라 이거다. 권한 제어 관리하고 아이디 관리하고 로그 수집하라 이거다…

그거 안하는 회사가 어딧냐 병신들아!!!!

그럴 꺼면 코딩도 전부 손으로 하고나서 나중에 타자로 치라고 하지 그러냐? 천공카드를 부활하자고 하지 그래?

….병신 지랄도 이정도면 쌈박한 수준이다.

레일즈구성 요소, 그리고 MVC

내가 레일즈로 논문 프로젝트를 할 때, 레일즈 구성 요소가 진짜 MVC 디자인에 정말 잘 부합하는 녀석 중 하나라고 확신이 들 정도로 레일즈는 MVC가 철저하게 이루어져 있다. 게다가 모델, 뷰, 컨트롤러의 이름 생성에도 규칙이 존재하고, 이 규칙만 일치하면 레일즈 프로젝트에서 알아서 변수나 파일, 내용 끌어다 쓰는 건 진짜 쉬운 일이다.

레일즈 프로젝트의 구성 요소를 간단한 예시를 들어서 그림으로 그려보면 이렇게 구성될 수 있다.

이 예시는 다음과 같이 동작을 한다.

  1. 브라우저에서 특정 사용자를 확인하기 위해 주소 창에 http://XXXXXXXX.XX/users 이라고 입력했다고 하자.
  2. 해당 주소를 읽어서 어떠한 컨트롤이 필요한 지를 rails의 router에 지정된 형식에 따라 주소 변환과 그에 따른 컨트롤러 프로젝트로 연결한다. 이 경우에는 index 에서 사용자를 보여주도록 되어 있어서 index 처리로 넘어간다.
  3. index에 연결되어 있는 user_controller.rb 컨트롤러에서는 해당 유저가 있는지 User 모델을 검색한다. 모든 사용자를 검색하는 것이기 때문에 검색으로 User.all로 하였다.
  4. 모델 컨트롤러에 있는 액티브 레코드에 연결된 데이터베이스에서 알아서 검색한다.
  5. 검색 결과를 컨트롤러에 반환한다.
  6. 검색 결과를 View에 넘겨서 보여주는 형태로 전환한다.
  7. 전황된 HTML 코드를 컨트롤러가 받아 완전한 형태의 HTML 페이지로 구성한다.
  8. 브라우저로 HTML을 전달하여 화면에 표시한다.

모델 에서는 진짜로 데이터 모델에 관련된 작업만 하도록 구성되어 있고, 뷰는 진짜로 말 그대로 화면 뷰이다. 특정 템플릿에 맞춰서 화면을 보여주는 html 및 레일즈 코드를 이용하여 화면을 구성한다. 마지막으로 컨트롤러는 해당 주소의 이벤트 혹은 API에 데이터를 받으면 어떠한 작업을 해야하는지를 구성하는 코드로 이루어져 있다.

그리고 이걸 확인할 수 있는 것이 바로 레일즈의 폴더이다. 예제로 만들었던 hello 폴더를 비주얼 스튜디오 코드로 열어보았다. 레일즈 어플리케이션 코드가 들어있는 app에 보면 controllers, views, models라고 별도의 폴더가 있는 것을 볼 수 있다. 레일즈에서는 이 각각의 폴더 안에 해당되는 코드를 만들어서 이용하면 알아서 MVC 모델의 디자인화 된 코드를 볼 수있다.

레일즈 관련된 책에도 보면 이런 내용에 대해서 칭찬을 많이 하는데, 내가 봐도 이 부분이 되게 깔끔학데 되어 있다. 사용자가 특정 URL에 접근하여 요청을 하면 컨트롤러가 이 요청을 받아 모델을 조회해서 데이터를 불러오고, 이 데이터를 바탕으로 뷰를 통해 시각적으로 표현한다. 그리고 시각적인 표현에 클릭을 하였을 때의 동작 또한 컨트롤러를 통한 후에 필요하면 데이터를 모델을 통해 호출하고 그걸 뷰가 표현하고…

그럼 이젠 이걸 어떻게 만드는 지 보여줄 수 있어야 하는데, 일단 그것은 다음 포스팅에서..!

Serverless Computing

아키텍트를 개발하고 연구하는 사람들한테는 몇 년 전부터 들려왔던 버즈워드이지만 서비스 개발하는 사람들한테는 이게 뭔 마법의 단어처럼 막 이용되고 있어서…..

뭔가 좀 제대로 떠들어 주는 사람이 진짜로 별로 없어지고 있다.

거기에 아직도 구식 마인드를 가진 사람들은 하드웨어가 눈에 보여야지만 되는 마인드를 가진 분들도 많은지라…

서버리스 컴퓨팅을 이해하기 위해서는 클라우드 컴퓨팅에서 주로 이야기하는 IaaS, PaaS, SaaS에 대한 이해가 어느 정도 있다는 전재 하에서 말하는 FaaS(Function as a Service)에 대한 개념도 제대로 잡혀있어야 한다. 이것은 이제 사용자가 기능을 코딩하고 빌드, 배포 및 실행 단위로 만들어 쓰는 그 과정 자체가 복잡하지 않는 상태에서 해당 기능에 대한 구현을 위주로 하는 작업을 말한다. 그러나 이를 위한 모든 아키텍트들이 전부 뒤에 숨어서 보이지 않는, 즉 서버가 보이지 않는 구조를 이루고 있는 것이 바로 서버리스(serverless) 구조인 것이다.

Raghuram Sirish씨의 교훈적인 말이 있는데, 원 글은 기억이 안나고 지금 번역된 이야기를 하도 떠들어서 번역된 이야기를 기억해서 그 이야기를 적어보겠습니다.

“90년대에는 응용 프로그램을 작성하고 하드웨어에허 실행했습니다. 그 다음 사용자가 동일한 하드웨어에서 여러 응용 프로그램을 실행할 수 있는 가상 시스템이 출시되었습니다. 그러나 각 응용 프로그램에 대해서 본격적인 운영체제들이 실행되고 있었습니다. 그러나 컨테이너의 도입으로 가볍고 민첩한 운영체제의 중복성직 기능 및 프로세스 수준으로 격리되었습니다.”

라고… (이건 제가 원문 좀 확실히 뒤져서 수정하겠습니다. 꼭!)

좀 사설이 길어졌는데, 그럼 서버리스가 정확하게 뭔데? 라고 하면 클라우드 네이티브 컴퓨팅 파운데이션에서 정의한 백서가 있습니다.

“서버리스 컴퓨팅은 서버 관리가 필요없는 응용 프로그램을 작성하고 실행하는 개념을 의미합니다. 하나 이상의 기능으로 번들 된 응용 프로그램을 플랫폼에 업로드 한 다음 즉시 필요한 요구에 따라 정확하게 실행, 확장 및 요금 부과가 이루어지는 보다 정교한 배포 모델을 말합니다.”

라고 되어 있습니다. 즉, 서버리스에서 중요하게 생각하는 것은 사용자가 프로비저닝, 관리, 확장 측면에서 서버의 비용과 복잡성에 대해서 걱정할 필요 없이 응용 프로그램을 구축, 실행할 수 있도록 하는 환경을 말합니다.

그럼 서버는 없는 것이냐고요?

아닙니다. 서버는 존재합니다. 단지 숨어 있습니다.

어디에? 클라우드 속에 숨어 있습니다.

…..말장난 아닙니다. 저 용어 자체에 속으면 안됩니다. 우리는 여전히 서버들이 연결되서 서비스화된 인터넷 속에 살고 있습니다.

진짜로 중요한 것은 개발자가 개발을 위해 생각하는 것 외에 가치에 대해서 별도로 생각하지 않아도 된다는 것이 중요한 것입니다. 사실 클라우드 환경에서 제공되는 컴퓨팅이나 API 등도 이런 내용들이 있지만, 서버리스에서는 이 점이 기존 비즈니스 레벨의 관점까지 꿰뚫고 있기 때문에 더더욱 강조되어 이야기를 합니다. 기능 관리에 대해서 주로 걱정을 하는, 즉 비즈니스적인 가치를 중요히사는 기능에 대해서 주로 생각하면서 개발을 진행합니다. 대신 그걸 구축하고 하는 데 시간 할애하는 것을 막는 겁니다. 또한 스케일링 등의 관리 작업에 대해서도 자동화 되어 있기 때문에 이를 걱정하지 않는 겁니다.

그럼 이에 대한 관리는? 플랫폼을 제공하는 측에서는 이 플랫폼을 제공하기 위해 구축해놓은 서버가 있겠죠? 바로 이걸 관리하는 것입니다. 구글 클라우드 플랫폼, 아마존 AWS, 마이크로소프트의 애저 등의 공용 클라우드 오퍼링의 경우에 이것들을 관리하고 고객이 해당 기능에 대한 실행을 확인하고 청구하면 됩니다. 개발자는 이러한 서버들과의 프로비저닝이나 상호 작용에 대해서 걱정할 필요가 없는 사설 클라우드나 데이터 센터의 경우에도 각자의 팀이 존재해서 관리를 진행할 것입니다.

이 녀석이 왜 중요할까요?

이녀석에 대해서 이야기를 주로 하는 가장 큰 이유가 바로 FaaS입니다. FaaS는 이벤트 또는 http 요청에 의해 기능이 트리거되는 이벤트 중심의 컴퓨팅 환경을 제공합니다. 개발자는 이 이벤트 또는 http 요청에 의해 트리거되는 기능을 사용하여 응용 프로그램 코드를 실행하고 관리합니다. 또한 개발자는 작은 단위의 코드를 FaaS에 배포합니다. 이 코드는 서버 또는 기타 기본 인프라를 관리할 필요 없이 확장된 개별의 작업으로 보고 필요에 따라 실행하는 실행 단위화가 됩니다.

하지만 이 FaaS가 지금은 완벽한 단계가 아닌 상황인지라…. 이 녀석을 이용하는 가장 좋은 환경이 바로 이벤트가 발생했을 때, 어플리케이션이 실행해야 하는 기능으로 동작하는 것이 좋은 사례이다. 그러나 이러한 종류의 작업들에 대해서는 여러 가지 고려 사항이 발생하게 된다.

  • 독립적인 작업 단위로 구성되었을 때 비동기식, 동시성, 병렬화가 용이한가?
  • 스케일링 요구 사항에 예측할 수 없는 큰 차이가 있는 산발적 수요에 대한 대처가 되는가?
  • 무방비, 이회성, 즉각적인 콜드 스타트 여부
  • 속도의 가속에 대한 요구와 요구에 변화하는 비즈니스가 역동적으로 발생하는가?

어려운 것이다…;ㅅ;

그렇지만 서버리스 자체는 새로운 형태의 기술이자 패러다임이다. VM과 컨테이너가 앱 개발 및 배포 모델을 변화시켰던 것과 마찬가지의 수준으로 다가올 것이다. 또한 FaaS도 극적인 변화를 가져오는 요소가 될 수 있다. 단, 이것들이 아직 초기 단계이기 때문에 정확하게 알아야 한다. 안그러면 기존의 영역들에 대해 애매모호하게 묻혀서 이용될 것이다.