[TIL] 기술 아티클 읽기

 

오늘부터 동료님들과 기술 아티클 읽기 소모임을 시작했습니다

좋은 발전이 있기를 바라며 ~.~ 🍻

 

소프트웨어를 배울 때 가장 빠른 길은, 작은 성취를 이루어가는 것이다.

 

• 기술 아티클 읽은 후 소감문을 주기적으로 업데이트할 예정입니다.

 

---

 

1.

소프트웨어를 배우는 방법 / 이민석 학장님 블로그

• 첫 시작으로 아주 좋은 글을 골랐다. Navy Seal Admiral Shares Reasons to Make Bed Everyday  왜 아침마다 침대를 깔끔하게 정리해야 하는지에 대한 영상을 소개하며 시작하는 글인데, 해야하는 일을 이만큼 쌓아놓고 못했다고 자괴했던 지난날의 내 모습을 생각하게 됐다. 아침에 일어나 침대를 정리하는 것이 별 것 아니지만 그 한 가지를 성취했다는 원동력이 도미노처럼 연결되어 큰 성취를 이룰 수 있다는 것을 지금은 너무나도 잘 알고 있다.
• 종종 머신러닝 공부 어떻게 하나요? 비전공자인데 CS 공부는 어떻게 해야하나요? 하는 질문을 블로그를 통해 받곤한다. 내가 조언해줄 처지는 못되지만 과거 똑같은 고민을 했던 입장으로써 여기서 제시한 소프트웨어를 배우는 방법이 너무나 공감된다.
• 책을 사기 전 만들고 싶은 것을 생각하고 최소한의 목표를 잡고 무조건 완료한다. 큰 것이 아니여도 된다. 조금씩이라도 꾸준히 코딩을 하고 익숙해지는 것이 중요한 것 같다.

 

 

 

2.

나는 프론트엔드를 안다고 말할 수 있을까?

• 위 에세이는 프론트엔드 개발자를 위한 주제가 아니다. '개발'에 대한 '철학적인 고민'을 담고 있는 듯하여 읽게 되었다.
• 필자는 6년동안 프론트엔드 개발 경력이 있는 개발자였는데, '개발을 잘한다.' WebGL을 사용한다고 했을 때 '그거 겁나 어렵지 않아요?'라는 등의 대답을 들으며 나는 잘하는 개발자다 라고 으쓱하던 시절을 회상한다. 단순히 러닝 커브가 높은 기술을 할 줄 알고, 그럴 듯한 결과물을 내서 칭찬을 들어본 개발자들은 많을 것이다. 하지만 그 속에 항상 내가 모르는 걸 물어보면 어쩌지? 하는 두려움이 있었다. 필자도 마찬가지로 10년 이상 실무 경력이 있는 시니어 개발자들이 있는 모임에 참여했다가 웹 개발자도 아닌, DA(Data Analyst) 분께 퍼포먼스 이슈, 렌더링 시 발생하는 메모리 문제 등의 질문을 받고 대답을 하지 못해 쥐구멍이라도 숨고 싶었다고 한다.
• "스스로 잘한다."라고 생각하는 것이 얼마나 위험한 일인지 갑자기 피부로 와닿았다. 내가 A와 B를 알고 있다고 "인식"할 뿐, 사실 "안다"라고 할 수는 없다는 것이다. 

 

Q: 프론트엔드 개발자는 어떤 사람인가?
A: 웹 클라이언트를 만드는데 필요한 지식을 알고, 웹 클라이언트를 실제로 구현할 수 있는 사람입니다.

Q: 그럼 퍼블리셔도 프론트엔드 개발자 아닌가?
A: 아닙니다.

Q: 그렇다면 프론트엔드와 퍼블리셔의 차이는 무엇인가?
A: 퍼블리셔는 프론트엔드보다 컴퓨터 공학 지식이 적다고 생각합니다.

Q: 그럼 퍼블리셔가 컴퓨터 공학 지식을 공부하기만 하면 프론트엔드 개발자가 되는 것인가?
A: 프론트엔드 개발자로 이직까지 해야 프론트엔드 개발자라고 할 수 있을 것 같습니다.

Q: 그렇다면 회사에서 정해주는 포지션이 영향을 준다는 것인가?
A: …그런 것 같습니다.

Q: 그럼 유명한 IT기업에서 일하던 프론트엔드 개발자가 웹 에이전시의 퍼블리셔로 이직하면 그 사람은 프론트엔드 개발자인가 퍼블리셔인가?
A: … (모순 발생)

 

 

 

3.

The Mathematics of Machine Learning

• 머신러닝에서 왜 수학이 중요하고 어떤 분야의 수학이 필요한지에 관한 글
• 머신러닝을 사용해서 숨겨진 통찰력을 찾아내는 데 있어 확률과 통계, 컴퓨터 과학, 알고리즘을 반드시 이해할 수 있어야 좋은 결과를 얻을 수 있다고 말하는 글이다. 그렇지 않다면 인간지능을 사용하지 않고 인공지능을 사용하는 것에 대한 의미가 없기 때문이라고 생각한다.
• 머신러닝으로 학습된 결과가 유효한지 입증하려면 올바른 신뢰 구간과 불확실성을 판별할 줄 알아야하며, 모델의 성능을 높이는데 매개 변수 설정에 대한 이해도 필요하다. 그리고 overfitting, unserfitting 문제도 다룰 수 있어야 하고 편중된 분산에 대해서도 식별할 수 있어야 한다.
• 엄청나게 어려운 수준의 수학이 필요하진 않은 것 같다. 어렵고 이해 안되는 수준의 머신러닝 알고리즘도 많지만 공과 수학을 들은 정도라면 어느정도의 원리와 동작 과정은 파악이 가능하다.
• 어떤 수학 분야에 대해서 공부해야 하냐면, Linear Algeba(선형 대수학), Probabillity Theory & Statistics(확률과 통계), Multivariate Calculus(다변량 미적분) 그리고 알고리즘 복잡도. 이도 이럴 것이 머신러닝 알고리즘의 대부분은 통계기반으로 동작하기 때문이다. 사용하기 쉬운 딥러닝 라이브러리와 패키지들이 많이 나와서 저 글이 작성된 2017보다 훨씬 러닝커브가 낮아진 것은 사실이다. 그래서 아무래도 수학에 대해 좀 안일해지는 경향이 있기는 하다. 시간날 때 이 글에서 추천한 MOOCs 강의를 들어야 겠따고 다짐해본다.

 

 

4.

프론트엔드 개발자는 왜 구하기 어렵나요?

• 프론트엔드와 JS개발자는 아니지만 카카오 프로젝트100에 있는 주제에 JS 개발자 관련 글이 많은 것 같다. 그래서 읽는 건 아니고 그냥 흥미로워서 스리슬쩍 읽게 되었다. 
• 이 글이 6년전 쯤인데 UX/UI, 프론트엔드 분야가 세분화 되어 있다는 것을 알게 된 것도 이쯤인 것 같다. 실제 서비스에서는 UI쪽 엔지니어링이 중요하다는 것을 인식하게 된 것도 이쯤이다. (앱의 로딩 화면이 버벅거리거나 규칙 없이 전환되는 앱의 경우 신경 안쓴 앱이네 하고 생각하게 된다)
• 프론트엔드 개발자를 구하기 어려운 까닭 첫째로 프론트엔드 분야를 오해하고 있다는 것 때문이라고 한다. 페이지와 프레임, 효과를 만드는 것 뿐 아니라 애니메이션의 부드러운 정도, 트렌지션, lazy loading, 인터렉션, 워크플로우, 하위 표준 호환성 등등을 고려해야하는 것 부터 코딩 영역 뿐 아니라 간혹 마케팅, UX까지 신경써야 한다는 것이다.
• 또 둘째로 나쁜 프론트엔드 엔지니어가 많아서라고 하는데, 나쁜 프론트엔드 엔지니어라고 하면 라이브러리 남용, 기능의 조금밖에 쓰지 못하는 프레임워크 붙이기, 반응형에 대해 말하면서 서버측 기법에 대해선 모르기, 성능 메모리 누수 걱정안하기 등등.. 이 있다고 한다.

 

 

5. 

JS스럽게 좋은 코드 쓰기 꿀팁

• 요즘 JS 쓰지도 않고 잘 쓰지도 못하면서, JS스럽게 좋은 코드 쓰기 꿀팁이라는 글을 그냥 한번 읽어봤다.. 클린 코드는 어떤 언어든 비슷한 것 같아서 그 지점을 한번 찾아보려고 한 것도 있다.
• String 관련 - $과 백틱 사용하기, 객체 관련 - 비구조화 할당을 통해서 반복되는 부분 없애기, 객체 병합 관련 - 하나씩 속성을 만들거나 Object.assign은 지저분하다. spread 연산자를 활용해서 깔끔하게 작성이 가능하다, Array를 사용할 때도 마찬가지로 spread 연산자를 적극 이용한다, Loop관련 - 한줄로 체이닝(?) => 화살표 함수 이용, Promise then 체이닝 대신 async/await 쓰기

 

 

 

 

7. 

도메인 지식이 결여된 인과 추정이 위험한 이유

• 사례1 사례2 
• 예측 모델을 만드는 경우가 아닌 인과 추정을 하는 경우라면 도메인 지식 없는 상태에서 데이터 분석을 진행하는 것은 위험하다는 글이다. 각각의 변수들이 모두 독립적인 경우 외에, 다양한 변수가 있을 경우, 또 교란 변수가 있을 경우 실제로 인과 관계가 없음에도 인과 관계가 높고 설명력이 높은 변수라고 추정하는 경우가 많다는 것이다. 또 충분히 관련 없는 변수들을 가지고 샘플링과 회귀 분석을 반복하여 엉터리 모델을 만들어 놓고 설명력까지 높은 모델을 만들었다고 데이터 분석가는 행복해 할 수 있다는 것이다.
• 따라서 현실 세계에서 도메인 지식을 가지고 변수끼리 영향력이 있는 변수를 누락하거나 분석 단계에서 모형을 잘못 설계하면 안된다는 것이다.
• 또한 통계적으로 잘못 추정한 경우를 구분해내기도 사실 어렵다. 통계 기법은 주어진 모델에 대한 유의성 검정을 할 수 있을 뿐이기 때문이다. 이런 오류를 피하기 위해서 현실적인 방안은 충분한 도메인 지식을 통해 최대한 논리적이고 합리적인 모델 및 실험 구조를 설계한 후 관측 데이터에 적용하고 구체적이고 정량적인 효과를 추정해야 한다.
• 그리고 결과에 대해 논의하거나 발표할 때는 결과에 대한 조건을 충분히 설명하며 그 경우에만 모델이 동작한다고 해석해야 한다.

 

 

 

9. 

누가 이름을 함부로 짓는가?

• 프로그래머에게 가장 어려운 일, '변수 짓기(네이밍)'에 관한 글이다. 변수명을 지을 때 피해아할 것들과 추천하는 기법(?)을 담고있다.
• Boolean Type의 변수는 부정형을 쓰는 것은 좋지 않다/ 다른 사람이 보고 바로 무슨 변수인지 알아볼 수 있도록 만든다 ex) relate_entry X related_entries O / 변수 이름 자체로 Type을 표현하는 방법도 있지만 잘 사용하진 않는다 ex) movieArray / 변수명을 줄여서 쓸 때 영어 모음 a, e, i, o, u를 생략하는 거지 개발자 좋을대로 줄이는 것이 아니다 ex) tits..... / 한글 로마자 표기식 X ex) maemul X apart, villa O 
• 개발자는 '그렇게까지' 영어를 잘 할 필요가 없다고 하는데 이 글에서는 '그렇게까지' 잘 해야한다고 말한다. '못해도 돼' 라는게 오히려 냉소주의이며 첨단 SW 개발자에게 필요한 역량이 아니라고 한다.

 

 

10. 

재능과 열정 없이도 프로그래밍을 하는 사람들

• '좋은 프로그래머'가 되기 위해서 '재능' 뿐 아니라 '열정'이 필수라고들 한다.  하지만 이러한 인식이 해로운 태도이며 깊게 뿌리박힌 고정관념이라고 이 글은 설명한다.
• Django 창시자 Jacob Kaplan-Moss는 "천재 프로그래머에 대한 고정관념은 정말 위험합니다. 프로그래밍 입문의 벽을 높이고 입문 프로그래머들에게 겁을 주기 때문입니다. 우리는 이러한 태도를 버려야 합니다. 프로그래밍은 배워야하는 많은 기술들이 있을 뿐입니다. 그렇기 때문에 재능을 필요로 하지 않으며 보통의 프로그래머가 된다고 해서 전혀 창피해하지 않아도 됩니다."라고 하였고 그의 트위터 프로필에는 "진짜 프로그래머가 아닙니다" 라고 쓰여있다고 한다.
• 또 Bootstrap 창시자 Jacob Thornton은 컴퓨터를 싫어하고 뉴스쿨에서 사회학 공부를 하려고 했다고 한다. "제가 고용된 직업에 제 자신은 조금의 자질도 없었고 매일 매일 해고 위기를 겪었습니다."라고 하며 .send()를 빼먹어서 애태우던 시절을 언급했다. 그리고 그의 트위터 프로필에는 "컴퓨터 루저"라고 써있다고 한다.(ㅋㅋ)
• 또 PHP 창시자 Rasmus Lerdorf는 "저는 프로그래밍을 싫어하고 프로그래밍을 좋아하는 사람들이 이해가 되지 않습니다."라고 했다.
• 프로그래머에 관한 몇 가지의 유머에 "SW와 대성당은 공통점이 있다. 먼저 만든 후에, 기도합니다" - Sam Redwine 라는 글을 보고 실소를 터트렸다. 대단한 걸 만든 사람도 나처럼 코딩하는 구나에 대한 안도감과 함께..
• 학창시절 나는 왜 이렇게 코딩을 못하지 하는 자괴감에 빠져있을 때가 있었는데 딱히 노력하지 않았지만 그런 자괴감은 사라졌다. 내가 생각했을 때 그런 자괴감이 극복된 것에는 '좋은 팀원이 되고자 하는 열정' 때문이었던 것 같다. 딱히 컴퓨터를 잘하거나 코딩을 잘하고 싶은 생각은 없었고 내가 맡은 임무에 무언가라도 도움이 되고 싶었고 꾸준히 무언가를 했던 것이 코딩에 익숙해지게 만들어준 것 같다. 이 글을 읽으면서 대단한 프로그래머들도 나와 비슷한 생각을 하며 살아가는 구나 천재가 아니어도 프로그래머라는 직책을 달고 살아도 되는구나하고 안도했다.

 

 

11. 

뱅크샐러드는 어떻게 레거시 서비스를 박살내는가

• 종종 거대한 서비스에서 저 로직들은 다 어떻게 관리하는 것이며 비즈니스 로직이 돌아가는 걸 전반적으로 파악할 수 있는 사람이 있을까 하는 생각을 하곤 했다. 있다고 하더라도 그 팀원이 그만두게 되거나 주먹구구식으로 기능을 추가하거나 덧대서 로직이 스파게티처럼 꼬였을 경우 그 서비스는 새로운 업데이트 같은 것에 빠르게 대응할 수 있을까 궁금했다.
• 누구하나 총대를 매지 않는 이상 기능 단위로 프로그램을 나눈다거나 코드를 리팩토링 한다던가 의존하는 패키지를 최신으로 업데이트 한다거나 하는 일은 끔찍할 것이라고 생각했고, 내가 그 서비스의 팀원이라면 총대를 맬 수 있을 것인가, 하는 생각까지 해봤다. 
• 그리고 이 글은 이러한 나의 궁금증을 해결해준 글이었다. 뱅크 샐러드의 경우 보기만 해도 갑갑하게 꼬여버린 레거시 코드들을 재정립하기 위해서 콘웨이의 법칙을 착안했다고 한다. “소프트웨어의 구조는 이 소프트웨어를 만들어낸 조직의 커뮤니케이션 구조를 따른다” 즉 뱅크 샐러드의 조직 단위로 기준을 정하고 어떻게 구조를 마이크로 서비스화 시킬지 고민했다고 한다. 이렇게 구조에 대한 고민을 해결하고 분해에 있어서 "문제를 단순화 시키고 레거시 서비스와 신규 서비스의 응답의 일치성을 확인하고 목표가 아닌 것은 배제한다"라는 원칙을 세웠다고 한다. 코드를 리팩토링하고 마이크로화 할 때 공학적인 규칙을 따르는 것이 아닌 문제 의식과 가지고 있는 방향 나아갈 방향에 대해 먼저 고민한 것이다.
• 기술적으로는 레거시 서비스와 신규 서비스의 응답 일치성을 확인하기 위해 statsd, kibana를 활용했고 응답에 대해 수치로 확인할 수 있는 대시보드를 크로노그래프(Chronograf)를 이용해 구축했다고 한다. 이로 인해 막연한 목표를 수치로 명확하게 확인하니 의사결정 속도도 빨라졌다고 한다.
• 듣기만 해도 막연한 '레거시' 라는 소용돌이와 결정의 막연함을 어떻게 해소할 수 있는지 훔쳐볼 수 있었다.

 

 

 

12. 

Why Python is Slow: Looking Under the Hood

• 동적 타입을 사용하는 언어들이 그렇듯 사용하기 쉬운(인터페이스가 단순한) 언어들은 내부에서 복잡한 과정이 일어나기 때문에 구현체로 사용되는 C같은 언어들보다 느리다는 것은 익히 알고 있는 사실이다.
• 예를 들어 a+b를 할 때, C는 정수 1과 정수 2를 a,b 변수에 할당해 binary_add<int, int>(a,b)를 호출하고 결과를 정의하면 된다. 하지만 파이썬에서는 1과 2가 object라는 것만 안다. 그래서 인터프리터는 PyObject_HEAD를 inspect 해야만 하는 등의 과정이 더 들어가는 것이다. 1을 a에 할당하는 것만해도 PyObject_HEAD를 거쳐 typecode로 변환된다음 정수로 할당하고 a를 변수로 정의한다. a와 b를 더할 때는 a를 PyObject_HEAD에서 찾고 a가 정수라는 것을 밝히고 b도 그런과정을 거치고 1+2의 결과를 낸다. 그리고 그 결과를 c에 할당하는 것도 a와 같은 과정을 거친다.
• 파이썬의 object model은 비효율적으로 메모리 접근을 하게된다. C에서는 버퍼 기반 배열을 사용한다.  반면 파이썬에서 배치 계산을 위한 무수히 많은 정수가 있다고 할 때 List Object로 이를 담게 된다. List Object는 포인터의 연속 버퍼에 대한 포인트가 있고 각 포인터는 데이터에 대한 참조를 갖는 Python 객체를 가리킨다.

 

 

 

13. 

Naver AI NOW

• 네이버와 라인의 AI기술을 연구하고 개발하는 조직인 CLOVA에서 최근까지 개발한 Hyper CLOVA에 대한 온라인 세미나를 들었다.
• 네이버에서 한정된 자원과 상황 속에서 다양한 서비스에 AI기술을 확산시키기 위해 속도와 스케일을 확보하려고 노력해왔다고 한다. 기존에는 하나의 AI 서비스를 만들기 위해서 각각 태스크별로 데이터를 확보하고, 정제하고, 각각 모델을 정제하고 이를 서비스로 만들었다고 한다. 예를 들어 OCR 모델을 위해 디지털 파일을 수집 정제하고 쇼핑 추천 모델을 위해 관련 데이터를 수집 정제하고 등등.. 이러한 방법으론 하나의 서비스를 개발하기 위해 긴 시간과 리소스가 필요하고 확장성이 떨어진다.
• 때문에 네이버가 개발하고 있는 분야는 Big Model로 이야기되는 Big AI라고 한다. 모든 유형의 데이터로 하나의 커다란 모델을 만들어 다양한 모델에 적용하는 방식이다.
• 반도체의 발전과정에서 반도체 집적도가 향상됨에 따라 새로 등장하는 기술이 많아지고 기술 발전의 속도가 매우 빨라졌다. 이 반도체 집적도 기술처럼 AI 분야의 근본적인 기술은 AI 모델의 파라미터 수라고 한다. 파라미터수가 증가함에 따라 AI가 풀수 있는 새로운 문제들이 많아진다. 그래서 네이버는 GPT보다 더 많은 양의 데이터를 구축했다고 한다. 부가 부를 낳듯 AI 기술 트렌드도 자원이 부를 낳는 양상이 계속 될 것같다.

 

 

14. 

집에서 일했을 뿐인데 생산성이 폭발했다

• 재택근무, 유연근무, 디지털 노마드 등 자유롭게 일할 수 있는 환경이 보편화되어 가고 있다. 일을 하려면 반드시 출근을 해야 한다는 인식도 사라지고 있고. 하지만 어떤 사람은 일정한 감시나 제제 없이 일하는 것이 어려울 수 있다. 또 출근하는 것보다 더 능률이 떨어질 수도 있는데 개개인의 리소스가 중요한 스타트업에서 재택근무를 시행했고, 효율이 더 올랐으며 그 과정을 담고 있는 글이다.
• 이 기업은 바로 뱅크샐러드이며 재택근무를 위해 PR 관련 데이터를 트래킹하거나, 재택근무 룰을 지정하거나(스탠드업 미팅, 출퇴근 시간 기록), 비동기적으로 일할 수 있는 시스템과 프로세스를 갖췄다고 한다. 특히 Jira ticket을 사용해 즉시 응답이 필요한 소통이 아니면 각자의 리듬을 존중할 수 있도록 비동기적으로 업무 시스템을 갖춘것이 인상적이었다. 개발을 할 때는 장시간의 집중이 필요한 업무가 많기 때문에 결정했다고 한다.
• 물론 이러한 룰들이 하루아침에 정해진 것은 아니고 오랜 시간 준비를 해왔기 때문에 가능했다고 한다. 유연 근무와 재택 근무가 효율적인 장점만 갖기 위해서는 기록과 문서작업, 소통을 위한 시스템 구축이 중요하다는 것을 엿볼 수 있는 글이었다.

 

 

 

15.

주소 인식을 위한 삽질의 기록

• 당근마켓을 이용하다보면 주소를 공유했을 경우 바로 주소를 공유했다는 알람이 온다. 꽤나 인식이 잘 된다. 이를 어떻게 구현했는지에 관한 글이다.
• 처음에는 정규식을 통해 주소를 인식하려고 해봤지만 '오픈기념으로 1', '말씀드린대로 12', '종류별로 15' 등 원하지 않는 텍스트까지 주소로 인식했다고 한다. 이를 개선하기 위해 당근마켓 디비에 실제로 쓰이고 있는 법정동/행정동 정보를 이용해 한번 더 체크했지만 문제는 도로명 주소였다고 한다. 정부 데이터에서 도로명 주소를 제공하는 데이터가 있었지만 API 형태도 아니고 딱 도로명 주소만 제공한다고 한다. 이 데이터를 일단 모두 다운로드 받은 후 중복 제거를 하고 CSV로 다운 받아 스크립트로 필요한 부분만 고르고 내부 저장소에 저장해 검증 데이터로 사용했다고 한다. 또, 새롭게 추가되는 도로명 주소에 대해서는 일정 주기로 동기화하는 Job을 실행하고 주기적으로 다운로드 하고 내부 저장소에 반영하였다고 한다. 
• 주소 인식이 필요할 것 같은 작업이 생각나서 살펴본 글이었는데, 주소 인식에는 특별한 방법이 존재하는 것은 아니고 모든 주소를 받아 내부적으로 검증하는 방법이 가장 효과적인 것 같다.

 

 

 

16. 

개발자 한달 리뷰

• 학원 출신 비전공자에 대한 부정적인 견해를 딛고 개발자가 되신 분의 회고록, 자신의 성향과 성취하고 싶은 목표를 위해 개발자가 되었고 아주 만족하고 계시다는 이야기.

 

 

 

17.

프로세스와 스레드의 차이

• 운영체제 시간에 지겹도록 듣던 프로그램, 프로세스, 스레드 개념적으론 이해가 되지만 말로 표현하려니 선뜻 나오지 않아서 한번 읽어보게 되었다.
• 프로그램은 저장 장치에 저장되어 있는 코드 뭉텅이들이 아직 메모리에 올라가 있지 않은 정적인 상태를 말한다.
• 그 프로그램을 실행, 즉 메모리에 올라가 있으며 실행가능한 동적 상태를 프로세스라고 한다.
• 과거 보다 프로그램이 복잡해지면서 프로세스 하나만으로 프로그램을 실행하기 버겁게 되었고, 때문에 프로세스를 나누어야 했다. 하지만 프로세스를 여러개로 나누는 것은 불가능하다. OS의 안정성을 위해 프로세스마다 할당된 접근 가능한 자원이 있기 때문. 그래서 프로세스보다 더 작은 실행 단위 개념이 필요하게 되었고 이것이 스레드다.
• 스레드는 프로세스 안에 포함되어 있고, 프로세스는 OS가 코드, 데이터, 스택, 힙 메모리영역을 할당해주고 최소 작업 단위로 삼는다. 반면 스레드는 프로세스 내에서 스택 메모리 영역을 제외한 다른 영역은 프로세스 내 다른 스레드와 공유한다.

 

 

18.

개발자를 위한 정보 검색 팁

검색을 잘한다는 건? - 코딩을 중단하고 검색을 하고 답을 찾아 다시 재개하기 까지 1분 미만, 검색을 통해 알게된 정보가 새로 알았다는 것보단 검색 힌트 덕분에 알았던 것이 떠올랐다, 검색을 하는 행위가 자연스러워서 코딩을 하다 막혔다는 느낌이 들지 않는다.

검색을 잘하는 법 - 구글 검색, 영문 검색, 검색 엔진 기능 활용, 정확한 키워드, 정보 가치가 낮은 사이트 파악, 정보의 시의성 따지기, 검색어 바꾸기, 문서 잘 읽기

 

 

 

19.

우리는 불편함을 어떻게 마주하고 있는가

• 우아한 형제들에서 불편한 점을 마주하고 컨테이너 환경을 도입하는 과정을 담은 글이다. 도입 배경, 구현 관리, 성과 까지 기술되어 있다.
• 처음 우아한 형제들 신사업부 띠잉셀에서 개발하고 배포하는 과정에서 영 꺼림칙했던 부분을 해결하기 위해 컨테이너 환경을 도입하자는 이야기가 나왔다고 한다. 그렇지만 개발할 시간 부족, 인프라에 대한 러닝 커브, 도입 후 장애 문제 등으로 부정적인 반응들과 마주했다고 한다. 이런 경우는 되게 흔하다. 무언가를 도입하려고 할 때 그것에 대한 리소스를 감당할 사람이 필요한데 현실적으로 그 커다란 짐이 부담스러워서 회피하는 경우가 더 많다.
• 하지만 우선 순위가 낮은 일이라고 방치할 수록 일은 커진다. 도전해야 경험할 수 있다는 것을 깨닫고 컨테이너 환경을 도입했으며 명확한 작업 기준을 잡았다고 한다. 1. 우선순위를 치열하게 조정하자. 2. 유연한 마음 가짐을 갖자.
• 그래서 새로 만든 배포 아키텍처의 구성은 이렇다고 한다. 먼저 1. SCM : GitFlow 전략 사용, 2. Jenkins Pipeline의 단계로 작업을 구분하고 작업별 수행시간을 측정, 튜닝을 위해 단계를 세분화 한다.(Prepare, Build, Build Image) 3. 쿠버네티스와 프로메테우스 AWS EKS로 관리형 서비스에서 얻을 수 있는 이점 이용, Prometheus를 사용해 쿠버네티스 metric 모니터링, Grafana 구축해 쿠버네티스의 상태(Pod, Container CPU, Memory, Networ, Count)를 대시보드를 통해 모니터링 4. Prometheus Alert 로 컨테이너 상태 관찰 및 알람
• 도입 후 배포 시간 7분에서 2분30초로 개선, 하나의 인스턴스에 여러 다른 애플리케이션 컨테이너 구동, 쿠버네티스 자가치유 기능을 통해 서비스 안정성 증가, 배포 시스템 최적화 등의 성과를 얻었다고 하고, 데브옵스는 결국 대화와 신뢰와 직결된다는 것을 느꼈다고 한다.

 

 

 

20.

문제를 찾아 해결하라

•  같은 요구 사항에 대해서 개발자들은 문제를 다르게 정의하기도 하고 문제를 똑같이 정의해도 결론과 해결하는 방법이 서로 다르기도 하다. 모두 각자 살아온 배경과 경험이 다르기 때문에 처음부터 하나로 통일하는 것이 쉽지가 않다.
• 문제 해결을 위해서 가장 먼저 해야하는 것은 '문제를 정확하게 파악'하는 일이다. 문제를 정확하게 찾은 후 필요한 지식 조각을 찾아 학습하고 연결해야 한다. SW 그 자체가 문제 해결을 도와주지는 않고 도구일 뿐이다. 

 

 

 

21.

데이터 분석으로 유저의 마음을 읽는 서비스가 되려면

• 콘텐츠 플랫폼인 '리디'에서 '데이터'를 어떻게 해석하고, 업무에 적용하는지 그리고 그것이 고객의 서비스 경험에 어떤 영향을 주는지에 관한 글이다. 
• 리디의 의사결정 원칙 : '데이터와 직관을 동시에 활용한다'
• 서비스 운영은 가설을 세우고 검증하는 일의 연속이며, 이때 데이터는 가설을 검증하는 도구이다. 이때 가설을 세우는 것이 '직관'의 영역이다. 데이터는 가설을 뒷받침 할 뿐이고 데이터 자체로는 침묵이며 그 침묵을 읽어내는 것이 직관이라는 것이다. 직관을 발달 시키고 활용하는 것이 그래서 중요하다.
• 고객은 서비스를 이용하면서 데이터분석이나 직관이 어디에 녹아들었는지 알 수 없고 알 필요도 없다. 대신 고객의 마음을 알아주는 '눈치 빠른' 서비스를 제공할 뿐이다.

 

 

 

References

 

[카카오 프로젝트100]기술 아티클 읽기