brunch

매거진 말문을 트이게 만드는 IT 지식

라이킷 14 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 공대적 문과생 Jun 09. 2022

6. 서버와 클라이언트, 그 사이의 용어들

말문을 트이게 하는 IT지식

이번 글은 총 8개 중 6번째 글입니다. 원활한 이해를 위해 차례로 읽어보시는 것을 추천드려요. 글 하단에 모든 시리즈를 확인하실 수 있습니다.

“그거 API가 마련되어 있나요?”

“파라미터가 잘못되어서 에러가 났던 거였어요.”

“토큰이 만료되면 그 때 재발행해주면 돼요.

이번에는 더욱 본격적으로, 서버와 클라이언트 사이의 상호작용과 관련된 용어들을 알아보겠습니다. 이런 것들은 실무에서 자주 등장하는 표현이기에 더욱 확실히 알아두면 좋을 거예요.

API

API는 Application Programming Interface 의 약자로 보통 클라이언트 프로그램이 서버 프로그램에게 무언가를 요청할 때 사용됩니다. 예를 들면 특정 회원의 정보를 요청하는 API를 호출하면 서버 프로그램이 DB에서 해당 회원의 정보를 찾아 클라이언트 프로그램에게 응답으로써 제공하는 것이죠.

보통 API란 여러 서비스를 연결할 때 사용됩니다. 예를 들면 우리 쇼핑몰에 카카오톡 계정을 이용해서 로그인할 수 있게 하고 싶다 할 때 카카오톡의 API를 사용합니다. 간단히 말해 API란 다른 프로그램이 이용할 수 있도록 만들어놓은 기능이라고 보면 될 것 같네요!

파라미터 (Parameters)

이러한 API를 호출할 때는 ‘요청하는 기능’과 ‘추가 정보’를 함께 보내는데요. 예를 들어 ‘회원 정보 제공’이라는 기능을 가진 API를 호출한다고 할 때는 ‘어떤 회원의 정보를 원하는지’ 그 회원의 ID도 함께 적어서 보내야겠죠? 안 적어주면 누구 껄 보내라는 건지 서버 프로그램이 모를 것 아니에요? ‘새 회원 추가’라는 기능을 가진 API를 사용할 때는 이 회원이 어떤 ID를 사용하고 싶어하는지, 설정한 비밀번호는 무엇인지, 입력한 주소는 어떻게 되는지-와 같은 정보를 함께 보내야 할 겁니다. 이 추가 정보를 ‘파라미터’라고 합니다.

예를 들면 날씨가 어떤지 알려주는 기능을 만들면 무엇을 파라미터로 만들어야 할까요? 지역과 날짜 를 파라미터로 만들면, 기능을 요청할 때 파라미터인 날짜와 지역을 바꿔가면서 요청하면, 똑같은 기능(코드)을 사용하지만 사용할 때마다 지역과 날짜를 달리해서 유연하게 날씨를 알아볼 수 있겠죠? 이렇게 같은 기능이지만 매번 달라져야 하는 부분을 따로 떼서 매번 다르게 사용할 수 있게 만든 것이 바로 파라미터입니다.

JSON

API를 통해 서버에 어떤 정보를 요청하거나, 작업을 요청하면 서버는 요청한 작업을 수행한 뒤, 작업의 실패/성공 여부나 요청한 정보를 JSON 이라는 형식으로 클라이언트에게 보내줍니다. 아래처럼 생겼는데요.

{ "username": "gildong", "lastName": "길동", "firstName": "홍", "mbti": "infp" "married": false }

간단히 해석하면 ID가 gildong 이고, 성은 홍 씨에 이름은 길동인 사람의 정보가 담겨 있습니다. 하지만 이 정보는 이렇게 표현할 수도 있습니다.

성은 홍이고 이름은 길동인데, INFP야. 결혼은 안 했고, 아이디는 gildong임.

같은 내용이지만 위 문장은 컴퓨터가 이해하기는 어렵겠죠? 그래서 컴퓨터에서 이렇게 정제된 정보를 주고 받을 때 형식을 하나로 통일하는 게 좋은데, 이 때 가장 많이 쓰는 게 바로 위와 같은 JSON 형식입니다.

JSON은 JavaScript Object Notation 의 약자인데요. 인터넷과 웹이 유명해지고 대세가 되면서, 웹 브라우저가 사용하는 언어인 자바스크립트가 객체를 다루는 문법이 개발자들 사이에 많이 익숙해졌고, 따라서 자바스크립트가 아니더라도 데이터를 다룰 때는 그냥 자바스크립트 비슷한 문법으로 통일하자! 해서 나온 게 JSON입니다. 우리나라에선 [제이슨]이라고 많이 읽지만 영어에서는 [제이썬~] 에 가까운 발음이에요.

CRUD

CREATE, READ, UPDATE, DELETE 의 앞자를 따서 만든 CRUD는 DB(데이터베이스)와 관련돼서 수행하는 동작의 대표적인 4개 동작을 말해요. 만들고, 읽고 수정하고, 삭제하는 것이죠. 예를 들어 상품의 리뷰를 쓰거나 조회하는 사용자의 행동과 관련해서

회원이 어떤 상품에 새 리뷰를 쓸 때는 CREATE

작성한 상품의 리뷰를 확인할 때는 READ

그 리뷰에 맘에 안드는 점이 있어 수정할 때는 UPDATE

작성한 리뷰를 삭제할 때는 DELETE

…와 같은 동작을 하게 됩니다. 따라서 DB라는 것은 이 4개 동작을 하는 것이 거의 대부분이고, DB에 대해서 처음 공부할 때는 이 4개를 모두 수행하는 프로그램을 만들어보는 것이 튜토리얼처럼 여겨져요! 그러니까 간단한 게시판이나 메모 서비스를 만들면 CRUD를 모두 구현할 수 있어서, 백엔드 개발의 좋은 예제가 됩니다.

쿼리 (Query)

위에서 DB 역시 서버라는 얘기를 했는데요. 따라서 API처럼 명령어 비슷한 걸 작성해서 DB 서버와 통신하면서 DB 관련 작업을 하게 됩니다. 예를 들면

gildong 회원의 4월 1일 오전 0시부터 4월 30일 오후 23시 59분 59초 사이의 구매내역 중 환불된 건의 상품 ID와 상품명, 구매금액을 찾아서 최신순으로 정렬해줘

라는 문장을 DB 서버에게 요청하면, DB 서버가 마치 엑셀 파일과 비슷하게 생간 데이터베이스를 샅샅이 뒤져서 조건에 맞는 데이터만 뽑아서 돌려준다는 거죠. 이런 문장을 DB 서버가 이해하는 형식으로 적은 것이 바로 쿼리(Query, 질의문)입니다.

가장 대표적인 쿼리 문법인 SQL(Structured Query Language) 에서는 아마 이런 느낌으로 쓰여질 거에요.

SELECT item_id, item_name, cost
FROM purchases
WHERE refunded=TRUE AND date BETWEEN '20220401' AND '20220430' AND username='gildong'
ORDER BY date DESC

SQL은 데이터를 다루지만 프로그래밍보다는 문법이 영어와 비슷해서 기획자나 PM도 많이 배워서 유저 행동 분석에 사용하기도 합니다.

세션(Session)과 토큰(Token)

웹 사이트에 접속하는 건 서버와 클라이언트 간에 매번 새로운 연결입니다. 이 말은 즉 서버는 클라이언트가 수십~수백 번을 접속해도 누군지 매번 모른다는 거죠. 안면인식에 어려움을 겪는 웨이터가 손님을 대접한다고 생각해봅시다. 이 웨이터가 손님을 알아보기 위해 두 가지 방법을 생각해내요.

가게 메모장에 손님의 인상착의를 적어놓는다. (공개수배 방식)

손님에게 종이로 된 팔찌를 손님의 손목에 매어주고 가게 올 때 하고 오라고 한다. (에버랜드 방식)

둘 다 좋은 방법이지만, 1번은 가게가 바쁜 와중에 손님의 인상착의를 일일이 비교하기가 힘들 겁니다. 2번은 손님이 조금 귀찮겠고 팔찌를 잃어버리면 곤란하겠지만 가게 쪽이 조금 편해지겠죠.

이렇게 클라이언트의 정보를 서버에 저장해놓고 클라이언트가 올 때 서버가 알아보는 방식을 세션이라고 합니다. 반면 처음 로그인을 했을 때 서버가 클라이언트에 인증 정보를 남겨주고, 방문할 때마다 클라이언트 프로그램이 서버에 인증 정보를 제시해서 서버가 ‘나 왔던 사람이야~ 이거 니가 남겨놨잖아~’ 라고 서버가 알아보게 하는 방식이 바로 토큰 방식이죠. 우리가 웹사이트에 접속할 때 한번만 로그인하면 다음에 왔을 때도 로그인이 되어 있거나, 페이지를 이동해도 로그인이 유지되는 것은 바로 이 세션이나 토큰을 이용해서 이뤄집니다.

장단점도 명확합니다. 토큰 방식은 서버에 부담을 주지 않지만, 클라이언트가 기기를 포맷 했거나, 앱을 지웠거나 하면 인증정보가 날아가서 다시 인증을 해야 합니다. 세션 방식은 서버가 허락하는 한은 클라이언트를 알아보고 로그인이 유지되겠지만, 서버에 다소간 부담이 되겠죠.

세션과 토큰에는 꼭 유효기간을 적어놓습니다. 이 사람이 바로 그 사람이다. 라고 적어놓은 정보는 오래되면 바뀔 수 있거든요. 클라이언트에 맡겨놓은 토큰은 누군가에 의해 변조되거나 복제될 수 있고(그래서 에버랜드의 입장권을 의미하는 종이 팔찌는 매일 다르게 하지요?), 세션에 적어놓은 손님의 인상착의는 손님이 나이를 먹든다든지, 옷차림의 유행이 바뀌었다든지 하는 이유로 변할 수 있습니다. 혹은 누군가가 그 손님의 인상착의를 따라함으로써 우릴 속일 수도 있죠. 따라서 유효기간을 최대한 짧게 두어서, 일정 주기마다 인증을 다시 하도록 하는 것이 보안에 유리합니다.

아~ 세션이 뭔데?

은행 같은 서비스를 이용할 때 간혹 ‘세션이 만료되었습니다.’라는 오류를 보신 적이 있을 거예요. 은행이나 인증 같은 높은 보안성이 요구되는 서비스에서는 세션을 사용할 때 세션 유효기간을 아주 짧게(5분 ~ 30분) 만듭니다. 따라서 얼른 하려는 일을 하지 않고 딴짓을 하면 금세 재인증(로그인)을 하도록 요구하죠. 이것은, 네가 30분 전에 있던 그 사람인지 알 수 없어. 혹은 컴퓨터를 켜놓은 사이에 누군가 다른 사람이 앉았을 수도 있잖아? 라는 취지입니다.

하지만 ‘세션’이라는 단어가 일반적인 사람들에게 익숙한 단어가 아니기 때문에, UX Writing적 관점에서 세션 같은 단어를 사용자에게 노출하는 것은 지양해야 할 것입니다. 가뜩이나 에러 메시지가 떠서 짜증나는데, 세션은 도대체 뭐야? 라는 느낌으로 사용자를 더욱 화나게 만들 뿐이겠죠.