CS

CPU의 진화CPU 관점의 프로그램포토샵, 크롬, helloWorld 출력 등 cpu 입장에서는 기계 명령어일 뿐이다. 명령어의 양이 다를 뿐기계어는 실행 파일에 저장된다. 프로그램이 실행되면 실행 파일에 있는 명령어들을 메모리에 적재하고 CPU가 실행한다.프로그래머 관점에서 CPU의 역활은 아주 단순하다고 생각해볼 수 있습니다.CPU에게 명령어 집합이란?CPU에게 명령어 집합(ISA: Instruction Set Architecture)은 CPU가 이해하고 실행할 수 있는 모든 기본 명령어들의 목록입니다. 요리사에게 레시피북이 있듯이, CPU에게는 수행 가능한 모든 동작이 정의된 명령어 집합이 있습니다.예를 들어, CPU는 다음과 같은 기본 명령어들을 가지고 있습니다:ADD: 두 숫자를 더하기MOV: ..

프로그래밍의 기본 동기와 비동기프로그래밍을 시작하면서 가장 많이 듣는 개념 중 하나인 동기와 비동기에 대해 알아봅시다. 동기 개념은 일상 속에서도 쉽게 접할 수 있습니다. 여러분이 건강검진을 하면서 엑스레이와 의사와 상담을 받아야 된다고 가정해봅시다. 여러분은 엑스레이를 촬영 후 엑스레이 결과가 나올 때까지 기다릴 것입니다. 엑스레이 결과가 나오고 나서야 여러분은 의사에게 상담을 받으러 움직이게 될 것입니다. 이처럼 저희가 작업을 요청하고 완료할 때 까지 기다리는 시나리오를 동기라고 합니다.위의 그림은 비동기의 과정입니다. 여러분이 채혈 검사를 받고 검사지가 완성되는 것에 오래걸리기 때문에 따로 기다리지 않고 바로 시력검사를 받으러 갔습니다. 그 뒤에 검사지가 작성되어 전달 받았고 의사에게 상담을 받아 ..

링커란링커는 컴파일러가 생성한 여러 개의 오브젝트 파일과 라이브러리를 하나로 묶어주는 프로그램입니다. 마치 음식에서 여러 명의 쉐프들이 여러 개의 요리를 만들면 그걸 하나의 접시에 담아 확인하는 헤드쉐프라고 볼 수 있습니다. 링커의 동작 과정심벌 해석: 링커가 여러 개의 오브젝트 파일을 연결할 때 각 심벌의 참조를 정확히 하나의 심벌로 연결하는 과정입니다. 주요 대상은 전역 심벌과 외부 심벌입니다. 심벌 수집: 오브젝트 파일에 정의된 심벌 테이블에서 전역 변수와 외부 변수를 수집합니다.심벌 매칭: 각 심벌 참조(예: extern 변수, 다른 파일의 함수 호출)를 해당 정의와 연결합니다. 정의가 없는 참조는 링커 오류를 발생시킨다.중복 심벌 처리: 동일한 이름의 심벌이 여러 파일에 정의된 경우, 링커는 s..

1. 매우 빠른 스위치 CPU위의 사진은 삼체에 한장면 중 하나입니다. 장면에 대해 간단하게 설명드리자면 3개의 태양으로 인해 발생하는 운동 원칙을 계산하기 위해 사람들을 일렬로 쭉 세워놓고 수많은 사람들이 깃발을 오르락 내리락하면서 마치 하나의 회로판처럼 움직이는데 이건 마치 CPU가 동작하는 모습을 떠올리게 합니다. 삼체에 한 장면처럼 CPU는 매우 많은 스위치를 가지고 있고 전기 신호를 통해 동작하기 때문에 각각의 스위치는 사람이 깃발을 올리고 내리는 속도보다 훨씬 더 빠르게 동작합니다. 그 덕에 사람들은 주판, 계산기보다 훨씬 빠른 연산장치를 가질 수 있게 되었습니다. 하지만 초기의 컴퓨터는 CPU가 이해할 수 있는 언어가 0, 1 뿐이라 천공 카드(paunched card)에 하나하나 구멍을 ..

마이크로 서비스 아키텍처(MSA)가 대체 뭐길래? "마이크로 서비스 아키텍처를 구축해야 되요", "서버를 분리해야한다", "프로젝트 크기가 방대하여 개발이 오래 걸려요" 등 다양한 말로 같은 뜻을 개발자들은 말한다. "마이크로 서비스 아키텍처를 구축해야되요!" 라고 하지만 PO나 기획자에게는 쌓여있는 기획들이 있을 것이고 CS를 담당하고 있는 직원들에게는 운영하는데 필요한 기능들을 기다리고 있을 것이고 데이터 분석가들에게는 분석하는데에 필요한 이벤트나 로그들이 기다리고 있을 것이다. 그래도 이유없는 주장은 없을 것이라는 생각에 일정을 물어보면 생각외로 긴 일정들을 요구하고 안정적으로 운영되고 있는 서비스의 버그나 장애가 발생할 수 있을 것이라고 이야기를 한다. 그런 이야기를 듣다보면 점점 마이크로 서비스..

백엔드 개발자가 가장 자주 하는 업무 중 하나를 꼽으라고 한다면 바로 "API 개발"이라고 이야기할 수 있을 것이다. 우리는 API들을 만들면서 API를 구현하는 비지니스 로직은 많이 공부하고 익혔었지만 API 자체에 대해서 잘 설계하는 것은 고려하지 못한 부분이 종종 있을 것이 있을 것이다. 아래와 같은 상황을 겪어 본적이 있는가? 일부 API는 단 하나의 용도로만 사용할 수 있는 방면, 어떤 API는 검색, 필터 등 유연하게 활용할 수 있다. 그리고 과거에 만들어진 어떤 API는 오랫동안 계속 사용하고 있지만 어떤 API는 최근에 만들었음에도 불구하고 약간의 변경이나 기능이 추가될 때 수정이 어려워 새로운 API를 만들거나 기존 API의 버전을 올려야 하는 상황이 발생한다. 서론이 길었지만 이글은 A..