by
Oct 02. 2020
IT 회사의 '말'
판교에서 문과로 살아남기 2장
오늘은 내가 일하면서 자주 사용하게 된 용어를 정리해 보려고 한다.
IT 회사에서 처음 일을 시작하면 용어 지옥에 빠지기 시작한다. 개발에서 쓰는 외계어, 디자인에서 쓰는 외계어가 물밀 듯이 밀려온다. 처음에 업무를 시작하고 하루 중에 가장 많이 했던 작업이 구글링이었다. 한 문장에서도 모르는 단어가 너무 많아 이해가 안 되었기 때문이다.
이러한 과정을 그나마 줄여주기 위해 내가 자주 사용하는 용어를 위주로 정리해 보겠다.
그리고 설명은 철저히 나의 관점에서 할 것이다. ‘개발’, ‘디자인’을 모르는 사람의 관점에서 말이다.
정확한 정의를 말하려는 것이 아니다. 그냥 소화하기 쉽도록 하는 것이 목표이다. 쓰이는 방향성에 대해서 말할 것이다.
서버와 클라이언트
하루 평균 대략 ‘서버’ ‘클라이언트’ 각각 50번은 쓰는 단어인 것 같다. 솔직히 말하면 정확하게 뭐가 뭔지는 잘 모른다.
그러나 우리가 쓰는 뉘앙스는 대략 이런 그림이다.
우리가 서비스를 쓰는 바탕은 크게 4가지 정도로 구분될 것이다.
웹으로 서비스에 접속하거나, PC에서 앱을 다운로드해서 쓰거나, 애플이나 안드로이드의 스마트폰을 쓰거나. 각기 다른 이런 환경에서 송수신되는 정보는 한 곳에서 모아 종합하고 다시 각 환경으로 뿌려줘야 한다.
이때 이 정보를 한 곳으로 모아 처리하는 일종의 통로이자 저장소는 서버이다. 그리고 서비스를 쓰는 각 환경은 클라이언트라고 말한다. (우리 회사에서는)
어떤 식으로 이 용어가 쓰이냐 하면 보통 이런 식이다.
CS팀: 이 문제는 iOS에서도 WEB에서도 보고가 되었어요. 확인이 필요할 것 같아요.
기획자: 흠… 여러 ‘클라이언트’에서 공통으로 발생했군요. 그럼 '서버' 확인이 필요하겠어요.
서버 개발자: 네 저희 쪽에서 한 번 체크해 보겠습니다. 그래도 클라이언트 개발도 한 번 확인해 주세요.
WEB 개발자/iOS 개발자: 네 알겠습니다.
즉 어떤 문제가 발생했을 때 그것이 모든 환경 공통 발생이라면 서버의 원인이 있을 확률이 높다. 그것이 아니라 특정 디바이스에서만 발생했다면 보통 클라이언트에 확인이 필요하다.
아울러, 어떠한 기능을 기획했을 때 모든 클라이언트에 통합적으로 제공을 해야 한다면 서버의 확인이 필요하다. 클라이언트에서 기능을 그려 놓아도 서버에서 불가한 경우도 상당히 많기 때문.
클라이언트는 그 자체로는 마치 오프라인 속 서비스와 같다. 서버를 통해서 데이터를 전송하고 받아와야만 비로소 온라인 서비스로 나타날 수 있는 것이다. 일반적으로 앱을 각 클라이언트에서 만들면 그만인 줄 아는 사람이 많지만, 실상은 서버 없이는 아무것도 할 수 없다.
그냥 간단하게 이 정도로만 기억하자.
클라이언트: 서비스가 실행되는 각 환경들 (웹, 앱, PC, 스마트폰, OS)
서버: 클라이언트가 함께 모여 달리는 엄청 큰 터널.
API
난 개인적으로 처음에 이게 도저히 이해가 안 갔다. 아무리 사전을 찾아서 읽어도 모르겠고, 각종 그림 설명을 봐도 모르겠고 도통 애매한 그림으로만 남아 있던 단어였다.
이것도 대화로 한 번 말해주겠다.
개발자: 이 기능은 저희 기존 API로 해결이 안 될 것 같아요, 새 API가 필요해요.
기획자: 아 새로 제작이 필요하시군요. 기존에 비슷한 기능이 있는데 사용이 불가한가요?
개발자: 네 비슷한 것 같지만, 약간의 로직이 달라서요. 새로 제작이 필요해요.
기획자: 그럼 공수가 많이 들어갈 것 같은데요. 서버의 API로도 해결이 안 될까요?
개발자: 그건 확인이 필요할 것 같네요. 공수를 줄이기 위해서 저희 기존 API 조합으로 구현이 가능할지 한 번 더 볼게요.
감이 오는가? 전혀 모르겠지 않은가. 내가 그랬다.
여러 글을 읽고 결론 내린 나만의 api 정의는 ‘코드의 덩어리’이다. 더 쉽게 말하자면 ‘작은 기능’ 이라고도 할 수 있을 것 같다.
기능을 만들 때 개발자들은 매번 새로운 코드를 만들지 않는다. 그렇게 되면 너무도 오랜 시간이 걸리고 효율적이지도 않다. 그래서 하나의 덩어리 단위로 쪼개 만들어 놓는다.
기능은 이렇게 여러 가지의 API들의 정교한 조합이다. 즉 기능을 구성하는 세세한 단위를 코드로 구현하고 조합을 하여 기능이 탄생하게 된다는 것이다.
이런 API는 모두가 자유롭게 쓸 수 있도록 오픈된 것도 있고, 사내에서 자체적으로 만들어 쓰는 것들도 있다.
만약 개발자가 API를 새로 만들어야 한다고 말한다면, 아 처음부터 창조해야 하는구나…라고 이해해도 되겠다.
UI/UX와 버튼의 종류들
UI/UX 이 심오한 용어는 누구 한 명 통쾌하게 설명해주지 않더라.
나는 그냥 UI는 그림이고 UX는 느낌이다. 정도로만 이해한다. UI는 일종의 모양이다. 버튼이 여기 있고 닫기는 저기 있고 등. 그런 것들이 구성된 최종적인 그림이다. UX는 그것을 실제로 썼을 때 나의 느낌이다.
그림에서는 예뻤는데 실제로 쓰면 그렇지 않은 경우가 있다. 보기엔 예쁜데 쓰니까 불편한 앱 말이다. 이때 우리는 “아… UI는 예쁜데 UX가 영…”이라고 말한다. 예쁘다 안 예쁘다의 기준이 UI면 불편하다 편하다의 기준은 UX라고 말할 수 있을 것도 같다.
이러한 UI/UX를 구성하는 요소들이 있다. 버튼, 레이어, 뱃지 등등 이러한 용어를 알아두면 이해가 편하다. 그래서 대표적인 몇 가지를 말해보려고 한다.
라디오 버튼: 체크박스와 유사하지만, 하나만 선택할 수 있는 버튼
토글 버튼: 좌우 레버를 움직이듯 on/off를 할 수 있는 버튼
드롭다운: 버튼을 누르면 아래로 선택 가능한 항목이 주르륵 나오는 버튼
레이어: 웹 사이트 내에서 독립적이지 않은 하나의 창을 보여주는 것, 뭘 눌렀더니 자연스레 나타나는 창(like 브런치 페이지에서 우측 상단 '공유' 버튼을 누르면 나타나는 창)
팝업: 단독으로 웹페이지 URL을 가진 창. 브라우저 탭처럼 보통 최소화, 최대화, 닫기 버튼이 있음.
토스트 팝업: 하단에 잠깐 표시되었다가 사라지는 안내 박스.
뱃지: 실행을 하지 않은 기능에 대하여 빨간색으로 표시를 해주는 것.
일단 이 정도이다. 사실 빙산의 일각이지만, 정말 자주 쓰는 것들에 대해서만 말해주고 싶었다.
지금도 새로운 용어가 튀어나오고 매번 구글을 찾고 있지만 그저 나만의 이해로 그림을 그려가며 간간히 살아가고 있다. 우리는 이러한 용어들을 개발자, 디자이너처럼 완벽하게 정의하고 있을 필요는 없다.
그저 소통에 문제없도록 자신에게 맞는 이해를 그려놓으면 된다. 중요한 건 맥락이다. 이런 말들이 나온다고 겁먹지 말자. 다 대강 알아 놓으면 소통엔 문제없다. 뭐 우리 보고 버튼을 그리랬나, 코드를 쓰랬나.
문과답게 이해하자. 다 할 수 있다.
아래는 추가적으로 자주 쓰이는 몇 가지 용어들을 간략히 적어놓은 것이다. 참고해도 좋겠다.
CSS: 웹페이지의 디자인, 레이아웃 등의 스타일 역할.
Mark-up – 디자인 디스크립션이다. 해당 화면의 폰트 크기, 픽셀 등을 매우 자세하게 표현한 것
Proxy – 중개 서버 (서버와 클라이언트 사이에서 데이터 전달, 웹 캐시)
Refactoring – 결괏값에는 변동이 없으나 코드의 구조를 효율적으로 개선
Sign off – QA 쪽의 승인 절차
Binary File – 일종의 설치 실행 파일, 완전한 앱 하나 (like apk)
객체 지향: 연관된 메소드와 그 메소드가 사용하는 변수들을 분류하고 그룹핑하는 것. (관계 중심)
<-> 절차 지향은 반대로 순서대로 처리하는데 초점이 맞춰져 있다.
클래스: 설계도, 골격이 되는 코드
인스턴스: 객체에 포함되는 개념, 선언된 변수가 메모리를 차지할 때
하드코딩: 변수를 지정하지 않고, 고정값을 정해 일종의 테스트 형식으로 구현한 소스코드.
Batch: 한꺼번에 일괄적으로 대량 건을 처리하는 방식.
Migration: 기존 운영환경을 옮기는 과정
A tag: 하이퍼링크와 비슷하다. URL를 넣어주고 연결을 시켜주는 것이다.
IDC: 서버를 모아놓은 데이터 센터, 나라별로 센터가 있다. 즉, 나라별로 IDC를 설치한다.
글이 마음에 들었다면 라이킷, 꾸준히 읽고 싶다면 구독 부탁드립니다.
