개발자와 협업을 시작한 분들을 위해 개발자들이 현업에서 사용하는 기초 개발용어들을 몇 가지 정리했어요!

먼저 1부에서는 개발자들이 작성하는 코드와 관련된 용어들을 담았고, 다음 2부에서는 개발자들의 개발방식, 환경과 관련된 용어들을 담았어요.

개발용어에 대해 찾아보면 단어만 열거되어 있어 이해가 어렵다는 피드백을 반영해서 조금 더 연관이 있는 용어들을 묶어서 연결되게 작성해봤어요.

이번 아티클에서 소개하는 개발용어들

• 서버와 클라우드 서비스

• 빌드(Build), 배포(Deploy), 컨테이너(Container)

• CI, CD

• Commit, PR, Merge, 브런치

• 오픈소스

• 라이브러리, 프레임워크, 아키텍처

• 레거시

서버와 클라우드 서비스

이용자가 많아서 서버를 분리해야겠어. 🏃🏃🏃
클라우드 비용이 너무 많이 나올 것 같아서 예산을 조정해야겠어. 💰

서버

서버는 쉽게 말해 컴퓨터 본체를 떠올리면 돼요! 본체에는 특정 OS(Operating System, 운영체제)가 설치되어 있어요. 윈도우, Mac OS, 리눅스와 같은 것들을 말해요. 푸른 들판과 하늘 하면 떠오르는게 바로 윈도우의 이미지이죠. Apple에서는 Mac OS라는 OS를 만들어서 맥북 노트북이 동작하게 하고 있어요.

서버는 Server라는 말 그래도 사용자의 요청에 대한 결과를 다시 제공해주는 역할을 해요. 예를 들어 사용자가 최근 맥북 가격이 얼마인지 조회한다면 가격 데이터를 전달해주는 것을 말해요.

클라우드 서비스

클라우드 서비스는 24시간 가동할 수 있는 서버가 없거나 자체 서버실이 없는 경우에 저렴한 비용으로 서비스를 운용할 수 있게 도와주는 서비스예요. 클라우드 서비스를 이용하면 무중단 서버를 구축하거나 사용자 급증에 따라 서버를 유동적으로 증가시키는 등의 작업을 제공해줘요. 그 외에도 `.com`과 같은 도메인을 연결하거나 데이터베이스 서버, AI 기능들을 사용한 만큼 비용을 지불하고 사용할 수 있어요.

아마존 웹서비스(AWS)인 클라우드 서비스는 아마존에 아마존 이커머스를 통한 수입보다도 더 큰 수익과 안정성을 가져다 준 서비스예요. 그 외에도 구글의 GCP(Google Cloud Platform), 마이크로소프트(Azure) 등이 있어요.

빌드(Build), 배포(Deploy), 컨테이너(Container)

빌드 에러 나서 확인중이야. 😨
배포때문에 야근했어. 🥲
컨테이너로 배포되어 있어. 🚛

빌드(Build)

빌드는 코드로 작성한 서비스를 배포할 수 있는 파일로 만드는 과정이예요.

여기서 배포할 수 있는 파일이라함은 즉 작동 가능한 소프트웨어 상태를 의미해요. 빌드는 단순히 다양한 개발언어로 작성한 코드를 기계가 인식할 수 있는 언어로 바꾸는 과정(컴파일)만 있는 것은 아니예요. 그 외에도 개발에 포함된 이미지 자료와 같은 자료를 컴파일하고 테스트를 거치는 과정 등을 포함하는 포괄적인 개념이예요.

이렇게 만들어진 파일의 종류는 .war, .jar, .ipa, .apk와 같은 확장자가 있는 파일로 생성돼요.

배포(Deploy)

개발자들은 로컬(자신의 컴퓨터) 환경에서 개발을 진행하고, 테스트 서버를 거쳐 실제 다른 사람들이 사용할 수 있는 서버인 운영서버에 배포하는 과정을 거쳐요. (실제로는 회사별로 차이가 있고 로컬이 아닌 환경에서 개발할 때도 있어요.)

실제 사용자들이 사용할 수 있는 운영서버로의 배포는 테스트 과정에서 생각치 못한 변수들과 사용자의 피드백을 받을 수 있는 순간이기 때문에 가장 설레고 떨리는 순간이예요. 🙌

컨테이너(Container)

배포는 빌드에서 얻은 파일이나 컨테이너로 실행시켜서 동작하게 할 수 있어요. 여기서 컨테이너는 화물 컨테이너처럼 실행환경을 포함하는 독립적인 유닛이예요.

이전에는 코드를 실행시키기 위해 작성에 사용된 언어, 라이브러리 등 다양한 도구들을 모두 버전에 맞게 설치해야 작동할 수 있었어요. 그래서 개발하던 작업을 다른 사람이 이어서 작업하기 위해서는 이런 실행환경들을 다 구축해야 하는 작업으로 하루가 필요했어요. 하지만 실행환경을 포함하는 컨테이너를 이용한 개발이 늘어나면서 개발 속도도 빨라지고 있어요.

CI, CD

우리도 이제 CI, CD 구축할 때가 된 것 같아. 🚀

뉴니커 분들은 요즘 웹이나 모바일 앱을 사용하면서 서비스 점검 이슈로 이용이 불가한 시간을 보여주는 팝업을 보신 적이 있나요? 이전에는 많았던 이런 문구들은 차츰 사라지고, 갑자기 새로운 기능들이 반영되어 있는 경우를 보신 적이 있을거예요.

이렇게 중단없는 서비스 사용을 위해 대부분의 서비스들은 흔히 무중단 배포를 위한 CI, CD를 구축하고 있어요.

CI(Continuous Integration)는 여러 개발자들이 만드는 소스 코드들을 지속적으로 통합하는 것을 말해요. 로그인, 계정 정보, 포스팅 등 서비스에서 제공하는 다양한 기능들을 개발한 코드를 통합해서 빌드하고 테스트하는 것을 말해요.

CD는 두 가지 의미를 가지고 있어요.
먼저 Continuous Delivery는 새로운 변경 사항을 사용자에게 안정적으로 빠르게 제공하는 것을 말해요. Continuous Deployment는 개발된 코드를 실제 운영 환경에 무중단 배포하는 것을 말해요.

소스코드를 하나로 관리하고 버전별 또는 일자별로 관리하기 위해 Git이라는 툴을 이용해서 코드를 관리하고 있어요. 코드를 올리는 순간 CI, CD가 될 수 있도록 작업하고 있어요.

Commit, PR(Pull Request), Merge

추가 기능 커밋(Commit)해놨어요. ✅
PR 올려놨어요. 확인부탁드립니다. ❗️
Merge했어요. 반영체크 부탁드려요. 🚀
Branch 추가해서 작업하시면 돼요. 🙏

이번 단락의 용어들은 모두 소스코드를 관리하는 Git 사용시 사용되는 용어들이예요. 비개발자들은 사용할 일이 없을 것 같지만 회의에서 개발자들끼리 이런 용어를 주고 받는 내용을 들을 수 있을거예요.

Commit

커밋은 Git에서 변경사항을 저장하는 것을 말해요. 변경사항마다 어떤 것이 변경됐는지 제목과 세부 내용을 작성해서 같이 저장해요.

PR(Pull Request)

풀 리퀘스트는 Commit 내역을 다른 브런치에 적용하도록 요청하는 것을 말해요. 여기서 브런치는 여러 사람이 동시에 작업하도록 분기를 만드는 것을 말해요. 각 분기에서 작업을 하고 배포를 위해 `main` 브런치에 통합할 때 PR로 요청을 만들어요. 이렇게 해야 반영 전에 다른 개발자들로부터 피드백을 받거나 다른 변경사항과 충돌이 없도록 적용할 수 있어요.

Merge

PR을 승인하게 되면 하나의 브런치에 통합하게 되는데 이 과정을 Merge라고 해요. PR을 통한 통합이 아니라도 개별 브런치의 통합 등 소스 코드의 통합도 의미하기 때문에 넓은 의미로 사용돼요.

위에 용어가 사용된 커밋내역을 사진에서 볼 수 있어요. 커밋 히스토리들에서 `main` 브런치에 해당하는 커밋 내역이라는 걸 알 수 있어요. 그 다음 `Merge branch '6.1x'`라는 커밋은 6.1x 브런치 변경사항을 main 브런치에 반영했다는 내용이예요. 그리고 아래 `Merge pull request`라는 용어를 통해 PR 반영사항이 main 브런치에 통합된 것을 알 수 있어요.

오픈소스

오픈소스로 만들어볼까? 🤩

오픈소스가 없다면 IT 발전은 없었을거예요.

많은 사람들의 노력으로 다양한 오픈된 소스들이 존재하고 저작권이 허용하는 범위 내에서 누구나 사용할 수 있도록 되어 있어요. 오픈소스는 미리 만들어진 기능이 있는 코드로 위에 사진처럼 GitHub이라는 사이트를 통해 오픈된 소스들을 볼 수 있어요.

힘들게 만든 걸 왜 오픈해? 라고 생각할 수 있지만 많은 사람들이 사용하면서 같이 이슈를 개발하고 더 발전된 기능으로 만들 수 있어요. 그리고 오픈소스 개발을 통해 만든 서비스를 이용하는 사람이 많다는 것은 그많은 안정된 소스개발이 가능하다는 반증으로 사용될 수 있어요.

• 오픈소스: 오픈된 코드를 말해요.

라이브러리, 프레임워크, 아키텍처

라이브러리 버전을 높여야 해. 🧱
프레임워크 이걸로 사용하면 되겠지? 🏠
아키텍처는 이걸로 하는게 좋겠어. 🏗️

집을 지을 때를 생각하고 비유를 해서 설명해볼게요.

라이브러리는 벽돌과 같은 자재, 프레임워크는 집의 틀을 만드는 철골, 아키텍처는 자재를 연결하는 구조물과 집의 동선이라고 생각하면 쉬울 것 같아요.

라이브러리

하나의 소프트웨어를 정말 바닥부터 만든다고 한다면 정말 어려울 거예요. 하지만 라이브러리는 미리 만들어진 코드를 이용한 개발이 가능하게 합니다. 라이브러리는 오픈소스로 제공되기도 하고 자체적으로 회사 내부에서 개발해서 사용하기도 해요.

프레임워크

일정 규칙과 구조, 그리고 제공되는 기능들을 통해 전체적인 프로그램이나 애플리케이션의 기본적인 틀을 제공해요.

점점 프레임워크에서 기본적인 기능을 제공하는 경우가 많아서 편리하지만 한 편으로는 무거워지는 경향이 있기도 해요. 어떤 서비스에 어떤 프레임워크를 사용할 것인지 비교를 통해서 정하는 것도 중요해요.

주로 개발언어마다 사용하는 대표적인 프레임워크가 있어요.

아키텍처

집을 지을 자재와 틀이 정해졌다면 가장 중요한 건 어떤 방식으로 집을 지을지에 대한 부분이예요. 벽돌을 어떻게 쌓을 것은지, 집안의 동선을 어떻게 유도할지에 따라 상이한 집이 완성될 수 있기 때문이예요.

이런 방식들을 결정하기 위한 일종의 방식이 바로 아키텍처예요. 아키텍처를 알면 코드 구조가 어떻게 되어 있는지 파악하는데 도움이 되고, 코드 설계시 핵심적인 부분을 결정해요.

레거시

레거시 코드 리펙토링 해야겠는걸 🤔

오래된 코드에서 많이 보이는데 불필요하거나 시간이 흘러서 변경이 필요한 것을 말해요. 잘못된 코드도 있지만 기술의 발전으로 변경 적용이 필요한 경우가 대부분이예요.

이 부분을 해결하기 위해 레거시 코드를 개선하는 리펙토링을 진행하기도 해요. 레거시 시스템을 변경하는 것은 시스템의 성능을 높이고, 유지보수를 용이하게 하는데 도움이 돼요.