객체지향 프로그래밍(Object-Oriented Programming, OOP)은 클래스(Class)를 통해 데이터와 행위를 묶어 관리하는 프로그래밍 패러다임입니다. 그렇지만 OOP의 사용에 대한 모호함에 대한 논의는 끊임없이 진행되고 있습니다. 이러한 배경 속에서 예호나단 샤르빗(Yehonathan Sharvit)이 데이터 지향 프로그래밍(Data Oriented Programming)이라는 새로운 개념을 제안했습니다. 전편 ‘개발자가 알아야 할 데이터 지향 설계란?’에 이어, 이번 글에서는 데이터 지향 프로그래밍은 어떤 내용인지 알아보겠습니다.

객체지향 프로그래밍은 클래스(Class)를 통해 데이터와 행위를 묶어 관리하는 프로그래밍 패러다임입니다. 그렇지만 OOP의 사용에 대한 모호함에 대한 논의는 여전히 진행되고 있으며, 최근에는 함수형 프로그래밍(Functional Programming, FP)을 통한 활용도 많은 관심을 받고 있습니다. 이러한 배경 속에서 예호나단 샤르빗(Yehonathan Sharvit)이 데이터 지향 프로그래밍(Data Oriented Programming)이라는 새로운 개념을 제안했습니다. 그래서 이번 글에서는 데이터 지향 설계와 데이터 지향 프로그래밍에 대해 간략히 알아보는 시간을 갖고자 합니다. 첫 번째로 데이터 지향 설계와 관련된 이야기입니다.

지금 돌이켜 생각하면 부끄러운 일이지만, 처음 테스트 코드를 마주했을 때 든 생각은 '왜 귀찮은 테스트 코드를 만들어야 하는 걸까?'였습니다. 물론 지금은 테스트 코드의 중요성을 깨달아 열렬한 팬이 되었고, 이를 제 사회 생존을 위한 필수 장치로 여기며 함께하고자 노력하고 있습니다. 요즘은 대부분의 개발 과정에서 테스트 코드 작성을 실천하며 더 나은 결과물을 만들고 있습니다. 이번 글에선 테스트 코드가 무엇이고, 왜 중요한지에 대해 소개하고자 합니다.

일반적으로 API는 사용자가 API 클라이언트 도구를 이용해서 직접 사용하는 일은 거의 없습니다. API 호출 테스트를 할 때를 제외하고는 대부분이 자동화된 프로세스에 연동하여 사용합니다. 그렇기에 자동화된 프로세스라는 사용자의 특성으로 인해 API 개발자들은 비밀성과 가용성 부분에서의 보안적인 요소나 사용량 제어 등의 목표를 위해서 API 게이트웨이(API Gateway)를 이용합니다. 이번 글에서는 API를 제공하는 시스템에서 꼭 고려해야 하는 API 게이트웨이와 기능 중 하나인 API 스로틀링(Throttling), 관련 알고리즘에 대해 살펴보고자 합니다.

요즘 웹 개발자라면 Restful API를 한 번쯤 다뤄본 경험이 있을 것입니다. HTTP 사양의 주요 저자 이자 REST를 세상에 처음 알린 ‘로이 필딩(Roy Fielding)이 주장하는 REST 아키텍처 구성요소는 잘 몰라도 HTTP를 이용해 원하는 데이터를 URI로 호출하여 JSON 등의 문서 포맷으로 데이터를 주고받는다는 내용은 알고 있을 정도니까요.

비즈니스는 ‘애자일(Agile)한 방식으로 점차 빠른 구현과 검증을 요구하는 형태로 변화하고 있다. 이에 따라 ‘애플리케이션(Application)’도 빠른 대응을 위한 유연한 구조를 원하고 있고, 데이터를 관리하는 인터페이스도 유연한 구조를 원하고 있다. 이번 글에서는 OLAP-Stars schema를 GraphQL을 통해서 구현하는 방법에 관해 다룰 계획이다. 기업의 의사결정을 돕는 데이터를 제공하며, 유연한 Application을 구축하는 방안을 생각해보고자 한다.

개발자는 소프트웨어의 설계에 다양한 표현 방식을 사용합니다. 한국어, 영어 등의 자연어를 사용하여 표현하기도 하고, 직접 그림을 그려서 표현하기도 합니다. 하지만 이런 방식은 작성자 외 다른 사람과의 표현방식에 대한 약속이나 규칙이 없기에 간혹 의사소통에 방해가 되기도 합니다. 따라서 소프트웨어의 모델을 표현하는 ‘UML(Unified Modeling Lanugage)’이나 비즈니스 프로세스를 표기하기 위한 ‘BPMN(Business Process Model and Notation)’ 등을 사용합니다.

최근 Non-Blocking I/O 모델을 채택한 Node.js의 사용이 많다. Node.js는 사용자가 직접 스레드를 제어하지 못하는 한계로 인해 클라이언트로부터 요청이 증가할수록 비례하여 처리 속도가 느려지는 한계가 있다. 이번 글에서는 PM2와 Docker를 이용해 클러스터링을 구현, 멀티코어를 구현한 후 부하테스트를 진행하여 HTTP Request의 처리량 증가, 대기시간 감소, 초당 데이터 송수신량 등의 개선을 확인했다.

요즘 ‘개발자’를 들어보지 않은 사람을 찾기 어려워졌습니다. 모든 산업군에서 IT가 담당하는 부분이 보조 및 지원에서 핵심 동력으로 변화하고 있기 때문입니다. 이러한 변화에 발맞춰 다양한 직무의 사람들 또한 변화해야 하는 세상이 되었습니다. 재밌는 점은 예전에는 기술의 변화에 따라서 다른 직군이 지금과 같은 움직임을 보이지는 않았습니다. 반면 언제부턴가 개발자에 관해서 알아야 하는 세상이 되어버렸습니다. 여기서 우리는 기술이 오늘날 모든 주요 활동에 걸쳐 있으면서 직접적으로 가치 창출에 기여하고 있는 점에 주목해야 합니다. 따라서 시대의 흐름과 경영의 방향이 기술과 밀접하게 접목되고 있는 요즘, 개발자와의 대화는 그리 생소한 일이 아닐 것입니다. 그래서 이번 글에서는 개발자와의 대화를 주제로 개발자와 협업 시 소통에 ‘필요한 것’들과 ‘방식’을 공유하는 내용을 전달하고자 합니다.

우리는 시스템이라는 용어를 경영, 사회, 생물, 자연과학, 사회과학 등 다양한 곳에서 사용합니다. 우리가 살고 있는 사회도 시스템이라고 공연히 말합니다. 우리 몸도 인체 시스템이라고 말할 때도 있습니다. 그렇다면 시스템은 무엇일까요? 오늘은 ‘콘웨이 법칙’을 이용해 시스템에 관해 설명해 보겠습니다.