인터페이스, 장난감, 유연함

어릴 때 레고를 굉장히 좋아했었다. 목욕할 때에도 들고 가서 작은 블럭들을 조물조물거리며 이것저것 만들었다. 하나도 매뉴얼대로 만든 것은 없었다. 다만 그때 그때 떠오르는 생각들을 붙여나갈 수 있었고, 이는 충분히 재미있었다.

프로그래밍에 가까운 무언가를 하면서 ‘인터페이스’라는 단어를 자주 듣는다. 데이터를 가져올 때. 화면에 컴포넌트를 얹고 데이터를 제어할 때. 팀 안팎으로 무언가를 주고 받을 때. 만드는 사람의 입장에서는 틈이 없이 꼭 맞아떨어지는 접점을 만들려고 하게 된다.

보통의 인터페이스들은 바깥으로 알려질 일이 없다. 이건 어떤 원리와 과정을 거쳐 무엇을 모종의 형태로 가져온다는 이야기를 굳이 할 필요가 없기 때문이다. 컴포넌트를 만들건, API를 만들건, 우리는 우리 안에서만 인터페이스를 쓴다고 생각한다.

그런데 가끔은 재밌는 일이 일어난다. 안에서만 쓰던 이러한 인터페이스를 바깥으로 열어야 하는 일이 생긴다. 예를 들면, 고객사에서 우리 API를 사용해서 무언가를 보내줘야 하는 상황. 만약 나라면 부끄러운 감정을 숨길 수가 없을 것 같다.

잠깐 이야기를 틀어서, 나는 개발자에게 흥미를 준 서비스들이 크게 성장하며 성공했다고 생각한다. 흥미라는 표현이 적합한지 모르겠다. 어떠한 인터페이스가 열려있고, 그것을 사용해서 무언가를 만들 수 있다는 생각을 들게 만드는 것으로 풀어볼 수 있겠다.

Slack은 자체 제공하는 여러 API를 활용해 Slack App을 만들 수 있다. 간단하게 어떤 주소로 쏘면 그대로 채널에 올려주는 ‘Incoming Webhook’은 어떻게 쓰이는가. 개발 빌드 혹은 장애를 알려주고, 누군가가 지원한 사실 등을 알려준다. 형식과 사용처에 제한은 없기에 상상의 나래를 펼치면 된다.

Figma는 디자이너들이 자유롭게 사용할 수 있는 플러그인을 직접 만들어 배포할 수 있다. 어떤 모양을 비틀거나, Mock UI에 사용할 사람 얼굴을 가져오거나(이런건 요새 딥러닝으로 저작권 문제 없는 가상의 얼굴을 만들어준다), 가변형 폰트를 적용할 수 있게 해주거나.

Notion은 API는 없지만 리치 콘텐츠를 만드는 데 도움이 되는 블록을 많이 지원한다. 이러한 블록을 쌓아올려 템플릿을 만들 수 있다. 만들어진 템플릿에 사람들을 의미를 부여하며 적합한 용도로 사용하고 쉽게 바꿀 수 있다. 작성한 내용을 웹으로 공개하여 누구나 보고 활용할 수도 있다.

인터페이스의 예라고 보기에는 애매함이 있지만, 이는 모두 형식과 사용처에 큰 제한은 없다. 열려진 인터페이스들은 우리에게(특히 개발자들에게) 무언가를 만들 수 있다는 자극을 준다. 실제로 만들어서 괜찮으면 다른 사람들과 나눌 수 있고, 각자가 각자의 의미를 부여하며 도구를 사용한다. 그렇게 도구에 애착을 갖게 된다.

나는 인터페이스를 제대로 만들었는가. 우리 안에서만 쓰니까. 그 한마디가 나를 물렁하게 만드는 것은 아닐까. 돌아보면 이런 일은 없을테니까… 안에서만 쓸 테니 이건 대충 이렇게 합시다… 기록은 다음에 합시다… 같은 이야기를 많이 하지 않았나.

물론, 결과물을 완벽하게 만드는 생각은 하고 싶지 않다. 아무리 완벽에 매달려도 실제로 내놓았을 때 닥치는 상황은 내가 예상하지 못한 것들이니까. 다만, 이러한 생각이 도구를 무뎌지게 하고, 기능을 찾아 쓰기 어렵게 만들고, 그로 인해 상상의 나래를 펼치지 못하게 만들었다면 큰 문제일 것이다.

인터페이스를 만들 때, 어떤 때가 오면 활짝 열어둘 수 있도록 준비를 해두고 싶다. 한 번 만들 때 한정된 자원 안에서 잘 만들고, 꾸준히 가꿔나갈 생각을 해야겠다. 어느 시점이 가면(보통 서비스가 성공하면), 그때는 새로 짤 수 없을지도 모르니까.

p.s.
여담으로 제프 베조스는 2002년에 이런 이야기를 한 적이 있다.

모든 팀들은 서비스 인터페이스로 데이터와 기능을 공개해야 한다. 팀들은 이 인터페이스로 통신해야한다. 오직 네트워크를 통한 서비스 인터페이스 호출만 허용하며, 어떠한 방식을 쓰던 괜찮다(HTTP, Corba 등…).

모든 서비스 인터페이스는 예외없이 기초부터 모두 외부에서 사용 가능하도록 설계되어야한다. 외부 개발자가 이용가능하도록 계획하고 설계해야 하며 예외는 없다.

이를 지키지 않으면 해고다.

물론 AWS의 문서는 읽고 쓰기가 좋지 않지만(…) 인터페이스가 갖는 중요성을 설명한 글이라는 점에서 이야기를 하고 싶었다.