MZ세대 개발 입문자에게 API를 설명해보자
개발자를 지망하는 2002년생 사촌동생에게 API를 설명해 보자
인트로
개발자가 되고자 준비하며 CS 지식(Computer Science knowledge)을 학습하는 분들이 많습니다.
CS는 정말 많고 다양한 세부 분야가 있는 깊고 넓은 지식 분야인데, 이 중 개발자에게 기본이라고 여겨지면서도 동시에 면접 질문에 단골로 나오는 키워드가 몇 가지 있습니다. ‘기본이면서 단골 질문이다’는 것은 제대로 답변하지 못하는 경우가 있다는 걸 알 수 있기도 합니다.
이번 글은 그중 하나인 API(Application Programming Interface)에 대해 얘기를 해보려 합니다.
이미 좋은 개발자이자 멘토이신 분들이 예비 개발자들을 위하여 유튜브와 글로 자신의 지식을 설명해 주셨습니다. 저도 덕분에 정말 도움을 많이 받았고, 지금 다시 봐도 역시 좋은 내용입니다. (감사합니다!)
하지만 마음속 한 곳에 ‘현 세대에 맞게끔 좀 더 쉽게 설명할 수 있지 않을까?’라는 과감한 포부가 생겼습니다. 그래서 과감하게 제목을 ‘MZ 세대 개발 입문자에게 API를 설명해 보자’로 지어보았는데..
'프로그래머를 희망하는 2002년생 사촌 동생에게 API를 어떻게 설명하면 좋을까?'란 상황을 상상하며, 이 친구가 익숙한 것과 익숙하지 않은 것을 떠올리며 설명을 도전해 보겠습니다.
이 친구가 익숙한 것
기본적인 코딩(스크래치, 파이썬 등)과 함수 개념
간단한 텍스트 프로그램 구현 경험
자동 연동(블루투스, 와이파이 등)
이 친구가 익숙하지 않은 것
하드웨어 간의 유선 통신(Serial, I2C, Ethernet 등)
프로그램(프로세스) 간의 데이터 공유 또는 통신 (IPC 등)
푸리에 변환을 통한 전파 통신 기술 구현
어디선가 본 듯한 ‘네트워크’하면 나오는 그림
요즘의 교과서나 다큐멘터리에서 한 번쯤은 볼 법한 그림입니다. 그리고 대체로 이런 느낌의 설명이 붙습니다.
왼쪽 : '각 나라와 지역마다 연결이 되어있다'는 느낌의 설명. 뒤이어 지구와 위성사진이 나오기도 한다.
오른쪽 : '일상에 흔히 보는 기기들은 전부 네트워크에 연결되고 소통하고 있다'는 느낌의 설명. 높은 확률로 IoT, 클라우드 등의 키워드 함께 들어간다.
결국 두 개의 그림이 표현하고 싶은 것은 자연스럽게 문장으로 표현해 본다면,
"물리적 거리로 떨어져 있더라도 네트워크로 연결되어서 각 전자 기기는 연결되어 있다. 때문에 우리는 스마트폰 하나로 메신저도 하고, 비행기 예매도 하고, 집에 보일러도 끄고, 다른 나라의 인터넷 방송도 볼 수 있다."
거리가 떨어져도 통신만 된다면 소통이 되는 걸까?
실제로 전화 건 사람은 몇이나 될까?이전에 일론 머스크가 트위터에 전화번호를 공개한 실수가 있었습니다. 그 사건을 떠올리며 아래 상황을 읽어봅시다.
우리가 무슨무슨 경위로 테슬라의 일론 머스크의 연락처를 습득했습니다. 그러면 곧장 우리는 원활하게 소통할 수 있을까요? 일단 일론 머스크는 한국어를 모를 확률이 높을 것입니다.
→ “일단 소통할 수 있는 영어 실력이 필요해!”
전화를 빨리하고 싶은 마음에 족집게 영어 강의와 엄청난 열정으로 금방 영어에 능숙해졌습니다. 그런데 전화를 걸어서 무슨 얘기를 해야 될까요? 어느 정도 이야기할 것들을 생각해두면 좋을 것 같아요.
→ “대화를 할 수 있을 공통된 주제(업계 동향 지식 등)가 필요해”
그래서 그분들이 관심사나 회사 관련 기사를 열심히 알아봤습니다. 준비는 마친 것 같습니다. 이제 전화번호를 눌러봅시다. 모르는 번호라 안 받을 수도 있겠지만.. 오! 받았습니다. 나에 대해서도 소개하고 친목을 다지는 이런저런 얘기를 하면 좋겠지만, 굉장히 바쁜 분이라 느긋하게 통화할 시간 여유가 없으신 것 같습니다. 그렇다면 인사 겉치레는 넘어가고 알고 싶었던 것! 전화를 한 목적이자 핵심을 필요한 내용만 깔끔하게 말해봅시다. 질문할 내용이 길다면 요지를 정확하게 파악하기 위해 육하원칙(5W1H)같은 특정 틀(형태)을 적용해볼 수도 있겠습니다.
→ “화성에 직접 가실 건가요? (Are you going to Mars yourself?)”
1. 일단 말이 서로 통해야 되고
2. 유의미한 소통을 위한 주제. 즉 오고 가는 내용이 있어야 하고
3. 효율적인 소통을 위하여 내용을 간소화하거나 고정된 틀(형식)을 정해볼 수 있다.
효율적인 소통을 위한 표준안 또는 규칙 가이드가 필요
영어가 ‘글로벌 언어’라고 봐도 무방하겠지만 만능은 아닙니다. 또 굳이 따라야 하는 법은 없습니다. 그럼에도 우리는 해외여행을 갈 때 영어를 잘하면 왠지 든든합니다. 그렇지만 한국어를 잘하는 외국인이 한국에 방문했을 때 굳이 영어를 사용할 필요는 없어 보입니다. 어쩌면 진정한 글로벌 언어는 바디랭귀지일 수도 있겠으나, 구체적인 상황 설명은 힘들고 잘못된 소통이 될 확률도 높으며 소요되는 시간도 다른 방법보다 많은 편입니다.
일상생활에서 필요한 내용만 주고받는다면 ‘정 없네!’란 소리를 들을 수도 있지만, IT기기의 소통에서는 이런 눈치를 볼 필요가 없습니다. 우리는 빠른 IT 통신을 원하고 이를 위해 효율적인 통신 방법을 고민합니다.
이를 위해 기술 개발/개선을 먼저 떠올릴 수 있겠지만, 가장 먼저 그리고 쉽게 개선할 수 있는 것은 위처럼 소통의 형식(form, format)을 표준화/간소화/최적화하는 것입니다.
원활하게 서로 필요한 내용을 주고받을 수 있는 것은 유지하면서
필요한 내용만 주고받아 내용(데이터)이 간결하고
본래라면 3~4번 주고받을 것을 1~2번 주고받을 수 있도록 횟수를 줄여 시간 단축하기
API : 프로그램끼리 어떤 방법과 형태로 주고받을지 정의
위의 내용을 프로그램 또는 애플리케이션 관점에 적용한 것이 API(Application Programming Interface)라고 봅시다.
여러 프로그램들이 서로 얘기를 나누기 위해선 이를 위한 API가 정의(존재)되어야 한다.
우리 인간이 서로 소통하려면 ‘언어’ 외에도 ‘화법(또는 문법)’이 존재해야 한다.
즉, API는 프로그램끼리 주고받기 위해 서로 약속한 도구이자 규칙이다.
동등 또는 상하관계가 있습니다. 인간도.. 프로그램도..
그런데 위의 문단에서 정정이 필요한 내용이 있습니다.
'API는 프로그램끼리 주고받기 위해 서로 약속한 규칙이자 도구.'
이는 동등한 관계일 때만 그렇습니다. 개발을 접하다 보면 동등하지 못한 경우를 더 많이 접하게 됩니다.
사람 관계라면 ‘나이’라는 값으로 친구라는 동등 관계가 쉽게 맺어집니다.
하지만 회사 & IT 상황은 좀 다릅니다. ‘다른 두 분야의 프로그램이 적용되는 시장 규모의 차이’ ‘해당 분야의 현실 상황과 여건’ 등 여러 요인들이 상하관계를 만들고 있습니다.
PC ↔ PC로 동등한 관계에서 메일을 보내는 것 같아 보여도
사실은 PC ↔ Mail Server ↔ PC라는 상하관계 2개가 연결되어 있습니다.
사람 간에도.. 회사 간에도.. 프로그램 간에도 상하관계에 놓인 경우가 있습니다.
하지만 소통의 관점으로 봤을 때 그리 나쁜 것만은 아닙니다.
예로 일상에서 전자 문서 양식이나 가입 신청서처럼 ‘서로’가 아닌 ‘한쪽에서 일방적으로 소통할 규칙을 정하는 경우’ 오히려 편할 때도 있습니다.
갑이 일방적으로 소통할 규칙을 정하거나
→ 왠지 나쁜 표현처럼 보이는데, 기존 방식을 개선하고 편의성을 추구하는 경우가 대부분
또는 이미 고착된 시스템으로 인해 소통할 규칙을 새로 진입하는 갑이 맞춰줘야 하거나
→ 기존 시스템의 시장 규모가 커서 API 설계 측이 새로운 걸 시도하기엔 무리인 경우가 해당
API를 한국인 상황으로 역 비유
어떠한 개념을 설명할 때 현실 세계에 있는 걸 비유하는 경우가 많은데,
반대로 지금까지 API에 대해 나눈 얘기를 토대로 일상 상황에 적용하여 역으로 비유를 해봅시다.
들어가기에 앞서 ‘한글’과 ‘한국어’, ‘알파벳’과 ‘영어’의 차이점을 생각해 보고 진행하면 좋겠습니다. [링크]
고마워요! 스피드 온라인 가나다!상황 1. 한국인 1과 한국인 2가 만났다.
2명의 언어(한글)와 화법(한국어)이 동일한 상태이다.
이때 이 2명의 API는 '한글'+'한국어'
상황 2. 한국인 1(표준)과 한국인 2(사투리)가 만났다.
2명의 언어(한글)는 동일하나 화법(한국어 표준, 사투리)이 다른 상태
이 경우 상하관계를 판단해 본다.
세부 상황 1. 사투리를 쓰는 사람이 서울에 상경한 경우
한국인 1과 같은 분이 많으므로 한국인 2가 화법(한국어 표준)을 따르는 것이 유리해 보인다.
이때 이 2명의 API는 ‘한글’+’한국어(표준)’
세부 상황 2. 서울 사람이 사투리 사용하는 지방으로 이사한 경우
한국인 2와 같은 분이 많으므로 한국인 1이 화법(한국어 사투리)을 따르는 것이 유리해 보인다.
이때 이 2명의 API는 ‘한글’+’한국어(사투리)’
이러한 시나리오를 전개하며 ‘한국인과 외국인이 만났다’와 같은 예시 상황을 생각해 보고, 해답을 내보시면 좋겠습니다. (댓글로 남겨서 공유해 주시는 분께 미리 감사합니다.)
‘What is API?’ 배울 때 헷갈리는 이유
x가 무리수임을 증명하라. n=1일 때 OO임을 증명하라. 같은 수학 이야기를 조금 빌려오겠습니다.‘삼단논법’이나 ‘수학 증명 방법’(직접 증명, 귀납법, 간접 증명 등)을 떠올려봅시다.
해당 것에는 자체적인 개념과 정의도 있으나, 이를 통해 특정 분야의 새로운 법칙, 공식, 규칙, 개념 등을 새로이 정의하거나 또는 특정 기술로 활용하는 데 사용합니다.
이와 같이 API도 자체적인 개념과 정의가 있으며, 새롭게 특정 개념 정의를 할 때 사용되기도 하며, 또는 웹, 소프트웨어, 하드웨어 등의 분야에 적용되어 새로운 결과물을 표현할 때 붙여 사용됩니다.
API 활용의 결과가 개념인 경우
Web API : 웹 브라우저, 웹 서버가 데이터를 주고받기 위한 설계가 제시된 API 개념
→ 브라우저마다 이 설계의 특정 부분이 지원되지 않는 경우가 있는데 ‘브라우저 호환성’으로 확인할 수 있습니다. [링크]
RESTful API : HTTP Method 중 4가지(Get, Post, Put, Delete)를 사용하고 REST의 특정 규칙을 지향하며 설계한 API
Open API : 우리 회사가 구현한 기술(기능)을 제3자가(누구나) 사용할 수 있도록 공개하는 API
API 활용의 결과가 구현된 기술인 경우
Twitter API : 트위터의 트윗, 쪽지, 목록, 사용자 등과 같은 기능을 개발자가 프로그래밍할 때 활용할 수 있도록 구현된 API의 가이드
Clova Speech-To-Text API : CLOVA 인공지능의 음성인식 기능을 개발자가 프로그래밍할 때 활용할 수 있도록 Restful API 개념을 지키며 구현한 API의 가이드
Youtube API : 유튜브와 관련된 기능을 개발자가 프로그래밍할 때 활용할 수 있도록 구현한 API 가이드
‘API가 무엇인가?’를 알아보기 이전에 대부분 결과물인 ‘구현된 API’를 접해보거나 예시로 듣게 되다 보니, 본래의 API에 대해 들었을 때 헷갈리는 경우를 본 것 같습니다. 또한 API란 용어가 개념과 특정 구현된 기술에 혼용해서 사용되는 것도 이유라 생각되는데, 이런 상황처럼 CS 관련 용어를 배울 때 우리가 느끼는 ‘용어의 애매모호함’은 다른 사례에서도 볼 수 있습니다.
가장 먼저 떠오르는 것은 '자료구조(Data Structure)'입니다. 이는 마치 '아치형'과 같이 형태에 대한 자체적인 개념이면서 동시에 다리, 건물, 묘 등 서로 다른 곳에도 활용될 수 있는 기술입니다. 그런데 자료구조를 배울 때 조금 높은 입문 난이도와 코드로 구현 과제를 받다 보니 간혹 잘못 이해하고 있는 경우를 보았습니다.
자료구조 구현 방법을 알면 어떤 프로그램을 만들 수 있을 것이다. (X)
→ 자료구조 몰라도 대부분 만들 수 있으나, 더 성능이 좋도록 만들 수 있다.
일단 모르겠지만 코드로 과제 제출하는 걸 보니, 자료구조는 큰 프로그램 구현에 사용되는 '코드 스킬'이다.(X)
→ 자료구조는 효율적인 관리를 위한 개념이고, 이를 코드로 구현하는 방법은 다양할 수 있습니다.
→ 웹 브라우저의 뒤로 가기 버튼과 같은 간단한 기능에도 '스택(Stack)' 자료구조가 쓰입니다.
→ 흔히 떠올릴 수 있는 애플리케이션이 결과물이 아닌 곳에서도 자료구조 개념이 활용됩니다. (파일 시스템, 프로세스 관리, 컴퓨터 부팅 등)
다른 비슷한 상황으로는 프로그래밍 문법 학습에서 만나는 객체, 클래스, 인스턴스의 차이를 떠올려봅시다.
- 객체 : 현실의 물체(붕어빵) + 내 머릿속에 떠올리는 무언가나 물체(가상의 게임 몬스터)
- 클래스 : 객체를 분석하여 코드로 변수와 함수로 정의하는 것
- 인스턴스 : 클래스를 이용해 코드 상에 객체에 1:1 대응하는 데이터를 생산 (팥 붕어빵 1, 2. 슈크림 붕어빵 1, 2)
여기서 객체를 설명하며 예시로 붕어빵을 떠올릴 때
(실물) 현실에 있는 붕어빵이 될 수도 있고
(가상) 내가 머릿속으로 상상하는 지구 크기의 대왕 붕어빵일 수도 있고
이런 점에서 객체는 실존하는 무언가를 표현할 때 또는 허상의 개념을 표현할 때 사용할 수 있습니다. 2가지는 서로 상반되거나 많이 다른 것 같은데 말이죠.
그럼 구현된 API의 가이드에는 무엇이 작성되어있을까?
직접 문서들을 확인하는 방법이 빠르겠지만, 그전에 앞서 지금까지 다뤄진 내용을 토대로 유추부터 해봅시다.
구현된 API의 기능 및 개요
구현된 API의 가이드
준비 환경 : 사용할 수 있는 환경 또는 갖춰져야 할 준비 조건
화법
→ 통신 방법(Web이라면 대체로 HTTP) 또는 이용 방법(주고받을 데이터의 형태)
→ 주고받게 될 데이터가 필요한 이유 또는 값의 의미
언어 : 통신 또는 이용 과정에서 사용할 언어 체계.
예시(샘플 코드) : 위의 내용을 종합하여 API를 실제로 사용할 경우에 대한 예시 샘플
위 항목을 인지하면서 아래의 API가 어떤 느낌인지 훑어봅시다.
네이버 파파고 API : 개요[링크] , API 레퍼런스[링크], 구현 예제[링크]
OpenWeatherMap API : Current Weather API 문서 [링크]
토스 코어 API [링크]
마무리하며
‘이 세상에 와이파이와 같은 웹 망이 세상에 당연하듯 존재한다고 인식하는 아이들이 태어난다!’
예전에 이런 의견을 들은 것이 생각나는데, 이미 어쩌면 스타링크 등으로 이에 해당하는 세대가 시작되지 않았나 싶습니다.
이렇게 말하니 왠지 ‘IT 기술의 시작’에 저희가 위치한 듯 얘기가 흘러가는 것 같지만, 전혀 그렇지 않습니다. 사실 저희도 비슷한 상황에서 시작했습니다.
어디서나 무선으로 전화가 되는 이유. 그리고 어떻게 전파에 목소리가 담기는가?
내비게이션에 내 위치가 파악되는 이유. GPS는 어떻게 위치를 측정하고 위성과 정보를 주고받는가?
에 대해 딱히 궁금증을 품지 않을 정도로 익숙하여 당연하다고 생각하는 사람도 있을 것이고, 당연하게 생각하지 않더라도 이에 대해 제대로 설명할 수 있는 사람이 얼마나 있을까요? 이런 점에서 우리도 ‘누적된 IT기술’ 위에 시작한 세대라 볼 수 있겠습니다.
시간이 갈수록 누적된 기술의 양이 늘어나고 발전하며, 그때의 세대마다 새로운 설명 방법들이 나오지 않을까요? 10년 뒤에는 API에 대해 어떻게 설명하고 있을까요? 어쩌면 API란 개념이 역사로 사라지며 이를 대체한 새로운 개념이나 기술이 나왔을 수도 있겠습니다.
미래에 어떨지 궁금하니 저는 가능한 건강하게 오래 살고 싶습니다.
읽어주셔서 감사합니다. 모두 건강하시길 바라요 :)
참고
https://developer.mozilla.org/ko/docs/Web/API
https://www.tutorialsteacher.com/webapi/what-is-web-api
https://en.wikipedia.org/wiki/Web_API
https://developer.mozilla.org/ko/docs/Web/API/Gamepad_API
https://developer.twitter.com/en/docs
https://api.ncloud-docs.com/docs/ai-naver-clovaspeechrecognition-stt
https://aws.amazon.com/ko/what-is/restful-api/
https://developers.google.com/youtube/documentation
Special Thanks
초안 첨삭을 도와주신 Lia 매니저님
