개발자 인터뷰에 나올법한 용어 정리 - 1

github 자료와 메모 자료들을 정리하던 도중, CS 관련 지식들을 정리해놓은 자료들을 발견했다.

아주 기초적이고 쉬운 내용들이지만, 복습 겸 블로그에 다시 정리하고자 한다.

 

이번 블로깅은 IT 인터뷰에 나옴직한 용어들을 정리한 것이다. 이전에 개발직군 취업을 준비하면서 (물론 현재 하는 일과 직접적인 관련은 없지만) IT 관련 용어들을 정리한 적이 있는데, 그것을 바탕으로 쓴 글이다. 실제로 취업이나 인터뷰에 매우 큰 도움이 되었던 것으로 기억하며, 현재 하는 일에서도 꽤나 자주 접하는 용어들이니 한 번 익혀두면 피와 살이 될 용어들이다. 더 많은 내용들이 있지만, 개인적으로 중요하다고 생각하는 내용들만 정리해보았다.

 

 

---

 

 

1. OS 관점에서의 동기와 비동기 

동기적 방식은 무언가의 완료 사인을 받은 뒤, 그러고 나서 다음 동작을 시행하는 것을 말한다. 비동기적 방식은 완료가 되든 말든 나는 시작한다라는 마인드다. 즉, 자원공유가 일어나는 스레드에서는 동기적 방식을 채택해야 하는 것이다. 동기적 방식의 구현으로 뮤텍스와 세마포어가 있다.

 

---

2. TDD 

Test Driven Development. 애자일 프로세스의 일환으로, 현재 가장 메인 스트림에 속하는 개발 방법론이다. 개발을 하기 전에 테스트 코드를 먼저 짜본다는 아이디어에서 시작한 개념. 기존의 방법이 [디자인 -> 코드작성 -> 테스트] 였다면, TDD는 [디자인 -> 테스트 -> 코드작성] 의 과정이다. 무엇을 테스트할지 디자인하는 과정에서 프로그램의 전체 목적이 명확해지고, 후 수정의 불필요하게 돌아가는 과정을 방지하게 된다. 또한 테스트 코드를 작성하다보면 객체 지향적이고 모듈화가 잘 된 코드를 생산하게 된다. 모든 코드가 재사용을 가정으로 만들어지기 때문이다. 또한 보통 테스트는 하나의 기능 단위로 테스트를 하기 때문에, OOP 원칙에 따라 코딩이 잘 될 것이고 자연스럽게 디버깅 시간도 단축될 것이다. 그리고 무엇보다도, 테스트 시나리오를 정의하는 과정에서 예외 상황들을 잘 고려하게 된다는 장점이 있다. 프로그램에서 예외처리의 중요성은 아무리 강조해도 지나치지 않다.

 

하지만 단점으로, 코드 생산성이 낮아지고 시간이 오래 걸린다는 단점이 있다. TDD는 능숙하지 못한 경우 애자일 방법론을 위배하는 상황이 되기 쉽다.

 

---

3. BDD 

Behavior Driven Development. 행위나 행동 중심적인 방법으로 개발을 진행하는 방법론. TDD 보다는 조금 상위의 개념이라고 볼 수 있으며 TDD와 같이 사용할 경우 시너지가 발생할 것이다.

 

---

4. DevOPs 

Development, Operation의 약자의 합성어로 개발 조직과 운영 조직의 시스템을 통합하는 것. 운영의 입장에서는 사용자의 니즈에 발빠르게 대응하는 것, 개발의 입장에서는 deploy의 속도를 높이는 것이다. 개발 뿐 아니라 시스템의 모든 조직을 통합하여 collaboration과 optimization을 지향함. 좁은 의미에서는 Dev, Ops에 집중함. 페이스북의 경우 디플로이 주기를 점점 줄여가고 있음.

 

요약하자면, 디플로이 파이프라인을 Operation의 관점, 여러 부서의 관점에서 결합하여 사용자의 요구를 빠르게 적용하는 것이다. 개발과 운영의 관점을 통합하는 하나의 문화이며, 배포 주기를 단축시키며 사용자와의 끊임없는 인터렉션을 추구하는 방식이라고 할 수 있다. 이 역시 TDD와 결합하여 시너지를 낸다. 또한 데브옵스는 애자일 프로세스와 함께 설명될 수 밖에 없는 용어이다.

 

애자일 : 개발 프로세스 방법론이다. 전통적인 개발 프로세스는 폭포수 모델과 계획 기반 개발 방식을 따르는 반면, 애자일 프로세스는 이와 반하는 방식이다. 전통적인 개발 프로세스의 경우 차례와 계획이 탄탄하지만, 여러 부작용이 따른다. 다른 공학 분야와는 달리 소프트웨어 분야는 계획이나 차례에 대해 매우 유동적이다. 이로 인해 계획을 타이트하게 잡거나 기한을 못지키는 것에 대한 비난 등의 스트레스가 따른다. 따라서 소프트웨어 개발 프로세스는 불확실성을 포용하고 수반하고 있어야 한다.

 

애자일 프로세스는 계획형에 반하지만, 철저히 무계획적인 프로세스는 아니다. 타협점을 찾은 것에 더 가까운 형태다. 그 내용으로는, 앞을 예측하며 개발하지 않고 문서 지향적이지 않은 프로세스라는 것이 메인이다. 하지만 일정한 주기를 가지고 끊임없이 프로토 타입을 만들어내는 과정을 가진다. 기민하게 좋은것을 빠르고 낭비없이 만들어내는 것이 목표이다. 쉽게 요약하여, 실질적인 코딩을 통한 방법론이며 철저한 계획 없이 일정한 주기로 계속 수정하며 만들어내는 작업을 한다는 것.

 

---

5. 운영체제의 비트 

자료구조나 운영체제 시간에 한 번쯤 봤을법한 비트 개념이다. 전공자가 아니더라도 32비트와 64비트의 차이는 안다. CPU가 한번에 처리할수 있는 bit가 32이면 32비트 체제, 64면 64비트 체제라고 하는것이다.

---

 

6. 병렬처리 VS 분산처리 시스템 

병렬처리 시스템은 프로세서를 늘려서 여러 일을 동시에, 더 빨리 처리 할 수 있게 해주는 시스템 방식이고, 분산처리 시스템은 처리할 수 있는 장비(컴퓨터 등)을 네트워크로 상호 연결하여 전체적인 일의 부분 부분을 나누어 더 빨리 처리 할 수 있게 하는 시스템 방식이다. 이 둘은 단일에서 여럿으로, 일을 동시에 처리한다는 점이 유사하지만 전체적인 틀에서 보면 일을 처리하는 방식이 매우 다르다. 병렬처리는 “동시에 여러 일”을 처리하는 것이고, 분산처리는 “하나의 일을 동시에 여럿이서” 처리하는 것이다.

 

분산처리 시스템의 대표적인 예로 맵 리듀스 플랫폼이 있다. 기존의 프로그래밍은 데이터를 가져와서 중앙에서 처리하고 다시 저장하는 구조였다면, 데이터를 가져오지 않고 저장된 곳에서 바로 처리하게 하는 기술이 맵 리듀스이다.

 

하둡의 맵 리듀스 약식 기술 설명 예시 : 하둡은 입력된 데이터를 고정된 크기의 조각으로 나눈다.(64MB 로 나눔) 각 조각마다 하나의 맵 태스크를 생성하여 맵 함수를 처리한다. 전체 시스템에서 분산되어있는 각 노드마다 조각에 대한 맵 함수 처리를 시행하는 것이다. 이런식으로 분산처리가 진행되며 맵 리듀스의 전체 과정은 다음과 같다. input을 조각내어 조각마다 맵 함수를 시행. 조각마다의 결과값을 모아 정렬 및 그룹핑 해줌. 리듀스 과정을 통해 원하는 결과를 출력하여 완료함.

 

만약, 맵 리듀스와 같은 분산처리 환경에서 감성분류를 위해 텍스트에서 특정 단어의 출현 빈도를 센다고 해보자. 데이터가 작을땐 개인용 노트북에서 해도 되지만, 오바마 선거예측처럼 데이터가 무지막지한 경우는? 이처럼 극도로 작은 단위의 작업을 엄청나게 많이 해야 할 때 큰 플랫폼 환경에서 사용하면 좋은 기술이 맵 리듀스를 위시한 분산처리 기술이다. 맵 리듀스의 개념은 매우 간단. 쪼개고, 계산하고, 다시 합치고. 계산하는 것은 맵 함수이고, 합치는 것은 리듀스 과정이다. 즉 문서를 여러개의 조각으로 나누면, 각 클러스터 노드에서 각 조각을 맵함수로 계산하고, 만약 사용자가 hi 라는 단어의 카운트를 세고자 한다면 각 노드에서 hi라는 단어가 카운트 된것을 리듀스 과정을 통하여 더해서 출력하면 되는것이다. 스파크에서는 이를 시스템의 RAM 연산으로 처리하기 때문에 속도가 훨씬 빠르고, 계산하는 과정도 다르다. 스파크, 하둡과 분산처리 등에 대한 자세한 개념과 설명은 다른 포스팅에서.

 

 

---

7. 콜백함수 

일반적인 함수는 파라미터를 받아 무언가를 리턴하거나, call by reference로 들어온 값을 변경하고 무언가를 리턴하지 않을 수 있는 형식을 가지지만, 콜백함수는 파라미터를 통해 다음 실행지점을 지시하는 함수를 전달하는 것이다. 콜백함수를 전달받은 함수는 특정 상황에서 이 콜백함수로 진입한다. 마치 재귀함수처럼 동작하는 것. 함수가 일급객체로 표현되는 언어에서는 함수 그 자체를 파라미터로 쓰고, 그렇지 않은 언어에서는 함수의 포인터를 넘긴다. 쉽게 말하면 일반 함수는 필요할 때 쓰는 것이고, 콜백 함수는 특정한 이벤트가 발생하면 알아서 호출되는 것이다.

 

콜백은 보통 즉각적인 응답을 기대하기 어려울 때 사용한다. 예를 들어 네트워크에 요청을 날렸을 때, 지속적으로 요청이 도착했는지 확인하는 것 보다 콜백함수를 통해 요청이 도착했을 때만 그것을 인지하게 하는 것이 효율적인 경우이다.

 

아주 쉬운 예로, 자바스크립트의 요런 놈들이 콜백함수이다.

 

$("#btn_1").click(function() {

    alert("Btn 1 Clicked");

});

 

function getInput(options, callback) {

    allUserData.push(options);

    if (typeof callback === "function") {  // 콜백함수가 실행되기 전에 함수임을 명확하게 하는 원칙.

        callback(options);

    }

}

 

정리하자면, 콜백은 함수이며, 이는 “이 작업이 완료되면, 이 함수를 실행시켜줘”라는 의미이다.

다음 포스팅에 이어서