함수형 프로그래밍을 배우면서 깨달은 것이 있습니다. 실제 함수형 프로그래밍의 본질은 그렇게 어려운 것이 아닌데 이걸 설명하기 위해서는 대단히 어려운 일이 많았습니다. 아마 함수형 프로그래밍에 쓰이는 용어들이 대부분 낯설기 때문일지도 모릅니다. 최근 함수형 프로그램을 더 깊이 공부하다가 실제로 알려주고 싶었던 것이 방법이나 용어가 아닌, 코드를 함수형으로 생각하는 ‘함수형 사고 패러다임’이라는 걸 깨달았습니다. 그래서 오늘은 함수형 사고 패러다임을 바탕으로 새롭게 함수형 프로그래밍에 관한 글을 써보려고 합니다.

AWS가 제공하는 서비스들은 대부분 모니터링 및 로깅을 제공합니다. 하지만 AWS 리소스에서 CloudWatch로 로그를 수집할 경우, 보관 주기를 CloudWatch의 AWS 콘솔이나 CLI를 사용하여 별도로 설정해줘야 하는 번거로움이 있습니다. 이러한 불편함을 해소하기 위한 업무 자동화 방법 중 하나로 EventBridge를 소개합니다. 이번 글에서는 EventBridge의 여러 역할 중 AWS 서비스 이벤트 데이터 전송에 대해서 다루려 합니다.

대나무숲 슬랙 앱 개발을 사이드 프로젝트로 진행했으며, 완료 후 좋은 반응을 얻고 있습니다. 그래서 이번 대나무숲 앱의 개발 과정 및 후기를 공유합니다. 이번 글을 통해 슬랙 앱 개발에 관심이 있으신 분들께 도움이 되었으면 좋겠습니다.

사실 원활한 업무를 위해서는 개발 환경이 구성된 PC가 꼭 필요하다. 그래서 보통 개발 환경 구성이 끝난 노트북을 들고 다니면서 업무를 하기 마련이다. 그러나 업무 특성상 근무 시간 외에 급하게 처리해야 할 업무가 생겼을 때 휴대성이 좋은 태블릿PC 혹은 항상 휴대하고 다니는 스마트폰으로 간단히 업무 진행이 가능한 방법이 있어 소개하려고 한다. 무엇보다 인터넷만 된다면 장소와 환경에 상관없이 업무를 진행할 수 있는 것이 장점이다.

리액트 네이티브는 리액트나 뷰(Vue)와 같은 다른 자바스크립트 라이브러리와 비교하면 커뮤니티가 크지 않으며, 개발 과정에서 마주치는 문제에 대한 해결책을 찾는데 종종 어려움을 겪게 됩니다. 지금부터 리액트 네이티브 개발에서 가장 빈번하게 부딪히는 난관을 어떻게 해결할 수 있는지 구체적인 예제를 통해 알아보도록 하겠습니다.

이번 인터뷰의 주인공은 종합 e스포츠 기업 빅픽처인터렉티브(이하 빅픽처)의 김병규 개발본부장입니다. 빅픽처는 '게이머의 삶을 가장 행복하게'라는 기치 아래 e스포츠 교육사업을 시작으로 게임미디어, e스포츠 플랫폼, 글로벌 대회 플랫폼 등 각종 e스포츠 사업을 진행하고 있습니다.

매우 협소한 저의 작업 환경은 WSL2로 부족함이 없으리라 생각했었습니다. 하지만 몹쓸 호기심이 발동해, 동일한 OS가 올라간 VM(Virtual Machine)이 여러 개 필요한 상황이 생겼습니다. 예전 글에서 말했던 것처럼, WSL에서 GUI 방식으로 편하게 클릭해서 설치하는 우분투는 같은 버전끼리 CLI로 익숙하지 않은 명령어를 학습해야만 쓸 수 있었습니다. 그러던 중, 우분투용으로 제공하는 멀티패스(Multipass)가 눈에 들어왔습니다.

개발자는 어떤 기업에서 일하는 것을 선호할까요? 개발자 취업 준비생에게 선호도 높은 기업으로 ‘네카라쿠배'가 자주 언급됩니다. 이는 네이버, 카카오, 라인, 쿠팡, 배달의민족(우아한형제들)을 묶어 부르는 용어로, 각 회사들은 모두 채용 공고를 비롯하여 블로그나 세미나 등을 통해 자신들의 문화를 적극적으로 알리고 있습니다. 그런데 네카라쿠배가 내세우는 개발 문화를 살펴보면 몇 가지 공통된 요소를 발견할 수 있습니다. 오늘은 이를 토대로 개발자가 선호하는 기업이 가지고 있는 문화 5가지에 대해 알아보겠습니다.

스타트업에 있다 보면 “우리 회사는 일하는 체계가 없다“라는 이야기를 심심치 않게 듣습니다. 일하는 방식이 정해져 있지 않고, 그때그때 구두로 내려온 일을 쳐내기 급급하다는 불만을 같이 토로하기도 합니다. 일을 잘하기 위해 글을 찾아보면 ‘개발을 잘하고 커뮤니케이션을 잘하자’라는 좋은 글이 많지만, 팀이 어떻게 움직이는지에 대한 글은 흔치 않습니다. 오늘은 하나의 로드맵을 향해서 모인 히어로들이 일하는 방법에 대한 이야기를 풀어볼까 합니다.

처음 AB180 백엔드 팀에 들어왔을 때 AWS 상의 거의 모든 권한을 가지고 개발할 수 있었습니다. 풍부한 권한으로 불편함 없이 지내던 중 외부 회사와 파트너십을 맺기 위해 보안 감사를 받아야 했습니다. 보안 감사를 진행하면서 몇몇 개선사항이 있었고 그중 한 가지 수정해야 할 사항이 ‘개발자에게 너무 많은 권한이 부여되고 있다.’였습니다. 그래서 팀 내에서도 AWS의 권장 사항처럼 최소 권한 정책으로 권한을 지급하기로 했습니다.