'프론트엔드'에 해당되는 글 2건

  1. 2016.09.19 스타일 가이드로 웹서비스 개발하기 (2)
  2. 2016.09.05 개발자와 대화하고 싶은 비개발자를 위한 참고서 (2)


들어가며


저는 슬로워크의 이메일마케팅 서비스 스티비의 프론트엔드 개발자입니다. 현재 스티비는 정식버전을 한창 개발하고 있는데요, 개편을 진행하면서 프론트엔드 개발 프로세스에 대해 많은 고민을 하게 되었습니다. 무엇보다 웹서비스는 유용하고 쓸만해야 합니다. 즉, 사용자에게 도움을 주면서 그 과정이 쉽고 편해야 합니다. 쓰기 편한 웹서비스는 명확한 UI를 제시하여 사용법의 학습이 쉽고, 한 번 학습하면 다시 익힐 필요 없도록 통일성있는 UI를 가져야 합니다. 


오류와 경고를 표현할 때, 보통 오류는 빨간색으로 경고는 노란색으로 표현합니다. 하지만 어떤 페이지에는 빨간색이 너무 많이 쓰여서 예외적으로 오류를 보라색으로 할 수도 있을 것입니다. 이런 결정을 내리는 경우는 드물겠지만 과거의 방식처럼 웹서비스를 페이지(화면) 단위로 디자인한다면 충분히 일어날 수 있는 일입니다. 실제로 같은 역할을 하는 상자의 윤곽선 색상이나 굵기, 여백이 화면마다 다른 경우가 많습니다. 


이런 혼란을 막기 위해 등장한 것이 ‘스타일 가이드(style guide)'입니다. 웹서비스 화면을 디자인할 때 참고하는 가이드 문서입니다. 스타일 가이드에 맞춰 개발하면 사용자에게 통일성 있는 UI를 제공할 수 있습니다. 


스매싱매거진의 ‘Designing Modular UI Systems Via Style Guide-Driven Development’에서는 스타일 가이드를 기반으로 한 디자인을 ‘스타일 가이드 주도 개발(Style Guide-Driven Development)라고 합니다. 스타일 가이드 주도 개발은 과거의 개발 방식과 어떤 점이 다른지 알아보고 좋은 스타일 가이드들을 살펴본 뒤, 실제로 스타일 가이드를 작성해보도록 하겠습니다.



무엇이 다를까




페이지(화면)을 그린다 vs. 컴포넌트를 만든다


스타일 가이드 주도 개발은 과거 화면 단위의 개발과 대조되는 개념입니다. 이전에는 웹서비스를 사용하면서 사용자가 마주하는 모든 페이지(화면)을 하나씩 디자인해 왔습니다.(이하 ‘페이지 주도 개발’) 주로 포토샵을 사용하여 웹서비스 화면을 그립니다. 자주 쓰는 컬러 스와치를 미리 구성하여 사용하고, 공통된 레이어나 그룹은 복사하여 사용하지만 기본적으로 화면의 모든 내용을 직접 그리고 위치시킵니다. 


스타일 가이드 주도 개발에서는 화면부터 디자인하지 않습니다. 어떤 화면이 필요하다면 필요한 구성을 작은 단위로 쪼갭니다. 그리고 그 쪼갠 단위들을 공통점을 기반으로 묶어 작은 단위로 기획하고 디자인합니다. 제목을 클릭하면 내용이 보이는 아코디언 UI는 보통 자주 묻는 질문(FAQ) 화면에서 볼 수 있는 UI입니다. 목록에는 제목이 먼저 보이고, 제목을 누르면 해당하는 내용이 보입니다. 여기서 FAQ 페이지를 직접 그리는 방식과 아코디언 UI의 한 부분을 먼저 그리는 방식의 차이가 드러납니다. 즉, 페이지 주도 개발은 빈 화면에 내용물을 더하면서 시작하고, 스타일 가이드 주도 개발은 내용물을 쪼개면서 시작합니다.


완성 vs. 조합


페이지 주도 개발은 화면의 완성을 목표로 합니다. 사용자에게 제시될 화면과 완벽히 유사한 화면을 그리고, 그대로 개발해야 합니다. 하지만 스타일 가이드 주도 방식의 목표는 부품(컴포넌트)의 제작과 조합입니다. 필요한 부품을 만들고, 이들을 각기 테스트한 뒤 전체를 조합하며 화면을 구성해 갑니다. 


변화와 역동 vs. 통일과 안정


페이지 주도 개발은 화면을 통째로 디자인하므로 각 화면마다 개성있는 표현을 넣을 수 있고, 역동적인 디자인을 제시할 수 있습니다. 반면, 스타일 가이드 주도 개발로는 통일성 있는 UI와 안정적인 동작을 보장할 수 있습니다. 한 번 사용할 때 잦은 조작이 필요하거나 오랫동안 사용해야 하는 웹서비스는 통일성과 안정성이 중요합니다. 하지만 남과 다른 브랜드 가치를 표현하거나 사용자에게 감성적인 소구가 필요한 경우는 안정보다는 역동성이 필요합니다. 웹서비스의 목적에 따라 개발 방식에 차이가 있을 수 있습니다. 



아코디언UI




부품의 조합으로 다양한 가구가 된다. IKEA




스타일 가이드 주도 개발은 왜 필요한가


스타일 가이드 주도 개발은 사용자와 개발팀(기획자, 디자이너, 개발자)에게 모두 이점을 가져다 줍니다. 통일, 확정, 효율입니다. 각 장점을 차례로 알아보겠습니다.


통일

사용자에게 통일성 있는 UI를 제공할 수 있습니다. 사용자가 웹서비스를 사용하면서 만나는 모든 UI는 기존에 학습되었거나, 새로이 학습해야 하는 것들입니다. 웹의 역사만큼 표준 UI의 학습이 진행되어 왔지만 여전히 사용자는 UI에 대한 학습이 필요하고, 더군다나 새로운 기능과 가치를 제공하는 서비스라면 반드시 거쳐야할 관문입니다. 너무 어렵거나 일관성이 없는 UI는 사용자에게 혼란을 주고, 이는 이탈을 야기합니다.


스타일 가이드를 만들고, 이에 따라 화면을 구성한다면 최소한 통일성은 보장됩니다. A 화면에서 배운 UI조작법을 B, C, D 화면에서 재사용할 수 있습니다. UI에 익숙해지면 사용자는 안정감을 갖게 되고 더 효율적으로 서비스를 사용할 수 있게 됩니다. 또한 스타일 가이드를 통해 미리 UI 부품들을 만들어 보면서 떨어져 있는 화면 간의 공통점을 찾아낼 수 있고, 각 화면의 조건에 따라 생길 수 있는 혼란을 미리 막을 수 있습니다.


확장


한 번 만든 UI 부품은 언제든 재사용할 수 있습니다. 여러가지 상황과 조건에 테스트가 된 부품이므로 어떤 화면에 넣어도 큰 문제 없이 작동할 것입니다. 최근의 웹서비스는 과거와 달리 매우 많은 화면을 담습니다. 과거의 ‘이전’, ‘다음' 버튼을 통해 화면의 전환으로 해결했던 것과 달리 최근에는 하나의 화면에서 다양한 콘텐츠가 유기적으로 등장하고 사라집니다. 사용자의 인터랙션도 다양해져 상황과 변수가 굉장히 다양해졌습니다. 이렇게 수많은 화면과 조건을 하나씩 그려서 대응할 수는 없습니다. 스타일 가이드를 작성하고서 이를 조합하면 그럴 필요 없이 화면들을 만들어 낼 수 있습니다. 

린스타트업의 관점에서도 스타일 가이드 주도 개발은 매우 가치가 있습니다. 빠른 시장 변화에 맞추어 아이디어를 서비스로 만들어 제공하려면 뛰어난 확장성이 꼭 필요합니다. X라는 기능을 테스트해보고 싶을 때, X화면을 기획하고 디자인하여 개발할 필요 없이 기존의 UI 부품들을 조합하여 빠르게 개발하여 테스트할 수 있습니다. 


효율


뛰어난 확장성은 효율로 이어집니다. 앞서 말했듯 시장의 변화에 맞춘 서비스의 개발 속도는 매우 중요합니다. 기존의 기능을 개선하거나 새로운 기능을 만들 때도 스타일 가이드 주도 개발은 이점이 많습니다. 새로운 UI를 만드는 작업은 스타일 가이드의 ‘업데이트'로 생각할 수 있습니다. 새로운 기능이 기획되면 우선 스타일 가이드화 시킵니다. 이 과정에서 다른 UI와의 통일성을 확인할 수 있고, 화면마다 다른 상황과 조건에 대입해 볼 수 있습니다. 스타일 가이드는 그 자체로 작은 프로토타입 역할을 하므로, 이를 업데이트하면 해당 UI에 대한 기본적인 개발과 테스트를 할 수 있습니다.


팀으로 협업하는 경우에도 스타일 가이드는 중요한 역할을 합니다. 미리 약속된 디자인 패턴을 서로 공유하여 작업자마다 같은 품질의 명확한 결과물을 만들어 낼 수 있습니다. 또한 정확한 커뮤니케이션을 위한 참고 지표가 될 수 있습니다. ‘제목을 누르면 내용이 나오는 상자'라는 모호한 말보다는 미리 정의된 아코디언UI를 함께 보면서 논의하는 편이 낫기 때문입니다. 





좋은 스타일 가이드 구경하기


스타일 가이드를 직접 만들기 앞서 좋은 스타일 가이드를 살펴보겠습니다. 수많은 웹서비스와 브랜드에서 자체적으로 개발한 스타일 가이드를 공개하고 있습니다. 이들을 참고하여 좋은 스타일 가이드의 특성에 대해 살펴보겠습니다.


먼저 Mailchimp의 Pattern Library를 살펴보겠습니다. 메일침프에 쓰이는 여러가지 UI 구성을 분류별로 정리해 두었습니다. Style Guide가 아닌 Pattern Library라는 이름을 쓰고 있는데, 이를 통해 UI 구성 하나 하나를 ‘패턴'이라고 정의하는 것을 알 수 있습니다. 즉, 메일침프가 생각하는 스타일 가이드는 반복될 수 있는 디자인 부품으로서의 UI입니다. 

각 화면의 레이아웃을 결정하는 그리드 시스템부터 타이포그래피, 폼, 내비게이션과 같은 자주 쓰이는 UI를 디자인과 용법, HTML 코드까지 상세하게 정의하고 있습니다. 메일침프는 이미 많은 기능을 갖춘 커다란 서비스이지만 계속해서 보완되고 확장하고 있습니다. 개발 결과물의 품질을 보증하고, 무리없는 확장을 위해 이러한 ‘패턴 라이브러리'는 반드시 필요한 존재입니다. 





다음은 스타벅스의 웹스타일 가이드입니다. 웹디자인에 관심있는 분은 한 번 쯤 봤을 수도 있습니다. 수년 전에 개발되어 스타일 가이드에 대한 개념도 희박하던 때, 많은 작업의 참고가 되었던 곳입니다. 아쉽게도 마지막 업데이트는 2014년이지만 웹/모바일 기반의 기업이 아님에도 웹스타일 가이드를 가지고 일관된 UI와 통일성 있는 사용자 경험을 주었다는데 큰 의의가 있다고 생각합니다. 




styleguide.io에서 더 많은 스타일 가이드를 찾아 볼 수 있습니다. 스타일 가이드 제작에 대한 많은 정보를 제공하고, 예시와 팟캐스트(!)까지 제공하고 있습니다. 




마치며

스타벅스와 메일침프의 공개된 스타일 가이드를 보면서 어떤 생각을 하셨나요? 개인적으로 스타벅스의 스타일 가이드에서는 웹사이트를 방문한 고객에 대한 세심한 배려를 느꼈고, 메일침프의 패턴 라이브러리에서는 메일침프의 UI 디자인에 대한 철학과 꼼꼼함을 느꼈습니다. 이처럼 스타일 가이드는 개발편의뿐 아니라 브랜드 경험을 향상시키고, 신뢰를 쌓게하는 도구가 될 수도 있습니다. 


사용자에게 편리하고 안정된 서비스 경험을 주고, 개발팀에게는 효율과 품질을 위한 강력한 도구가 되는 스타일 가이드는 단순히 웹서비스를 위한 기반작업을 넘어 그 자체로 ‘살아 있는' 서비스의 일부라고 생각해야 할 것입니다. 


다음에는 이런 스타일 가이드를 어떻게 구성하고 작성해야할지 알아보도록 하겠습니다. 



작성자: 스티비 개발 문윤기
Posted by slowalk


슬로워크 블로그에서는 얼마 전, 비디자이너의 얕은 지식 쌓기: 디자인 용어 20에 대해 포스팅했습니다. 그 글을 보고 저 또한 개발팀 내 유일한 비개발자이기에 많은 영감을 받아 이번 글을 작성하게 되었습니다. 저는 웹기획자로 프론트엔드개발자 두 명, 백엔드개발자 한 명과 함께 팀을 이뤄 작업하고 있습니다. 개발자와 함께 일하기 역시 기본적인 용어를 알지 못하면 혼란스러운 상황(나는 누구? 여긴 어디?..)에 처할 수 있습니다. 고객들도 웹사이트 의뢰를 하면서 익숙지 않은 여러 용어에 낯설어 합니다. 저 역시 아직도 갈 길이 멀지만, 개발자와 소통하기 위한 넓고 얕은 개발용어 몇 가지를 안내해 드립니다.



프론트엔드개발자와 백엔드개발자는 어떻게 다른 건가요?


프론트엔드개발자 - 사용자의 화면에 나타나는 웹 화면을 프론트엔드(Front-end) 영역이라고 합니다. 그리고 이 영역을 설계하는 사람을 프론트엔드개발자라고 합니다. 프론트엔드개발자는 사용자가 보는 화면을 주로 HTML과 CSS를 사용하여 보기 좋게 보이게 만들어주는 사람이라고 할 수 있습니다.


백엔드개발자 - 백엔드(Back-end) 영역은 일반적으로 사용자가 볼 수 없습니다. 예를 들어, 회원가입 정보를 입력하면 그 정보는 서버 데이터베이스에 저장되는데, 이러한 동작들이 처리되는 영역이 백엔드 입니다. 사용자가 보이지 않는 웹서버, 내부로직, 데이터베이스 설계, 데이터 처리를 주로 개발하는 사람입니다.

프론트엔드에서 사용자가 클릭, 드래그의 동작을 하면 이를 백엔드에서 처리한 데이터를 다시 프론트엔드로 돌려주어 사용자가 해당 작업을 수행할 수 있게 됩니다. 예를 들어, 페이스북에 사용자가 사진을 올리면 그 사진을 백엔드에서 데이터베이스에 저장하고 다시 프론트엔드로 돌려주어 내 사진을 다른 사용자가 볼 수 있게 되는 것입니다.

꼭 두 영역을 명확히 나눠서 개발하는 것은 아닙니다. 프론트엔드, 백엔드를 함께 진행하는 개발자도 있는 등 역할의 범위는 다양합니다.



자바, 파이썬, 루비, 펄, C++ .. 이게 다 무슨 이름인가요? 프로그래밍 언어는 다양하여 많은 선택지가 존재합니다. 유행을 타기도 하고 순위가 매겨지기도 합니다. 현재 사용되는 프로그래밍 언어는, 위키피디아에 따르면 698종이라고 합니다. 그 중 가장 많이 사용하는 언어는 C 계열 언어와 JAVA 계열의 언어이고, 최근에는 빅데이터 전문가가 뜨면서 R 프로그래밍이나 하둡에 관심을 두는 사람도 많아지는 추세라고 합니다. 각 언어는 저마다 장단점을 가지고 있고, 그렇기에 개발자들도 다룰 수 있는 언어들이 다양합니다.


출처: TIOBE



사용 가능한 프로그래밍 언어가 계속해서 늘고 점유율 순위가 바뀌고 사라지는 이유는 사용성 때문입니다. 요구사항이 변하고 시스템이 바뀔 때마다 손쉽게 바꿀 수 있어야 좋은 프로그래밍 언어가 됩니다.

비개발자이더라도 위 프로그래밍 언어들의 이름 정도만 알고 있으면 개발자들이 옆에서 이야기할 때 ‘아~ 프로그래밍 언어 얘기하는구나!’ 정도는 이해할 수 있습니다. 개발자와 가까워지는 방법은 그들의 언어를 한 번이라도 더 많이 들어보는 것입니다.



PHP, MySQL, Oracle 들어는 봤는데.. 서버? 백엔드개발자들이 사용하는 언어 맞나요?

PHP는 서버 쪽에서 동작되는 언어입니다. 자바스크립트나 HTML이 웹 브라우저에서 구동되는 것과는 구분됩니다. 사용자가 업로드한 파일을 서버에 저장하거나, 입력 데이터를 받아 데이터베이스나 파일에 저장하고, 저장된 정보를 불러와 HTML을 생성해서 웹브라우저로 전송하는 일을 처리합니다.

MySQL은 데이터를 보관하는 데이터베이스 관리 시스템의 한 종류입니다. 데이터베이스는 파일보다 정보 저장에 관해 더 많은 기능을 제공하기 때문에, 대부분의 데이터들이 데이터베이스에 저장됩니다. 그 중 MySQL은 오픈소스이기 때문에 많이 사용되고 있습니다.  


*서버 - 서버란 파일, 홈페이지, 동영상 등의 자료를 보관하고, 보관된 자료를 인터넷이 연결된 곳에서 언제든지 접근할 수 있도록 구성된 소프트웨어를 말합니다. 서버에는 메일서버, 웹 서버, 데이터베이스를 관리하는 DB서버, FTP프로토콜을 이용하여 파일전송을 가능케하는 FTP서버 등 다양한 서버가 있습니다.



서브라임텍스트3 사용하고 있고요, 깃으로 푸시해주세요~ 서브라임텍스트는 개발도구를 말합니다. 일반적으로 프로그래밍을 하는 데는 윈도우에서 메모장, 맥에서는 텍스트 에디터만 있어도 가능합니다. 그러나 규모가 크고, 오류가 없는 프로그램을 만들기 위해 작업을 도와주는 수 많은 개발도구들이 존재합니다. 좀 더 빠르고 효율적으로 개발하기 위해 도구를 사용하는 것이죠. 개발도구에는 비주얼스튜디오, 노트패트++, 빔, 이클립스 등이 있습니다. 그 중 서브라임텍스트는 개발자가 선호하는 도구 2위를 차지할 만큼 인기를 끌고 있습니다. 현재 슬로워크 1팀에서는 서브라임텍스트3을 사용하고 있습니다. 서브라임텍스트는 유료이지만 무료로도 사용할 수 있습니다. 장점으로는 개발자들이 많이 사용하기에 플러그인이 많아 원하는 대로 기능 확장이 가능합니다. 또한 가벼워서 좋다고 합니다.





기본적으로 이러한 까만 창이 서브라임텍스트3 입니다. 코딩을 위한 폰트도 개발자의 설정에 맞게 변경할 수 있습니다. 자세한 내용은 코딩 폰트 디자인기, Monoid를 참조해주세요.

깃(Git)은 버전관리 시스템으로 소스코드의 중요한 변화를 기록하는 것입니다. 어떠한 문제가 발생했을 때 문제의 전후 상황을 파악할 수 있도록 도와주고, 과거의 상태로 쉽게 돌아갈 수 있게 합니다. 특히 백업, 협업에 쉬워 많이 사용되고 있습니다. 물론 Git이 모든 걸 해결해주진 않지만 도움을 주기 때문에 많이 사용하게 됩니다.


CMS는 주로 워드프레스를 사용해요~


CMS-Collage2.png

출처: wooraky's Minority Report



CMS(Contents Management System)는 콘텐츠 관리 시스템으로 웹사이트를 구성하고 있는 다양한 콘텐츠를 효율적으로 관리할 수 있도록 도와주는 시스템입니다. 콘텐츠를 손쉽게 생성, 배포, 관리할 수 있는 http 기반의 프레임워크*라고 생각하시면 됩니다. 웹 서버상에서 운용이 되고 다양한 방식의 기술적 적용이 가능합니다. 우리나라는 XE(Xpress Engine)가 CMS를 표방하고 있습니다. 또한 요즘은 워드프레스(Wordpress)를 많이 사용하는 추세입니다. CMS는 전 세계적으로 워드프레스, 드루팔(Drupal), 줌라(Joomla) 이 세 가지 툴이 많이 쓰입니다. 특히 워드프레스는 쉬운 사용법과 기능들을 통해  CMS 시장을 거의 장악하고 있습니다. 프로그래밍 언어와 같이 다양한 장단점이 있고 어떤 툴이 가장 좋다고는 할 수 없습니다. 다만 대표적으로 많이 쓰이는 CMS 세 가지 정도를 알고만 있어도 개발자의 이야기를 훨씬 많이 이해할 수 있습니다.


*프레임워크 - 소프트웨어 제작을 편리하게 할 수 있도록 뼈대인 클래스와 인터페이스를 제작한 것들을 미리 모아둔 것입니다. 개발자는 이 뼈대에 살을 붙이는 방식으로 어플리케이션을 완성 시킵니다. 개발 생산성이 증대되고, 유지보수가 비교적 편리하다는 장점이 있습니다.

단점은 익숙해지는 데에 시간이 소요되고 모든 상황을 커버할 수는 없다는 한계가 있다는 점입니다. 그렇기에 개발 프레임워크를 얼마나 쉽게 커스터마이징 할 수 있는지가 프레임워크의 우수성을 평가하는 기준이 되기도 합니다.



HTML / CSS / jQuery / JavaScript 를 사용해서 만들었고요~


HTML - HTML은 웹 브라우저를 통해 사용자에게 보이는 프론트 영역을 작성하기 위한 언어로 웹 문서 내용 작성에 집중 합니다. 웹 사이트의 뼈대가 되는 구조라고 볼 수 있습니다.

CSS - CSS는 HTML로 잡아놓은 뼈대에 다양한 스타일을 추가, 변경하여 웹사이트에 디자인을 부여하고 글자의 크기 모양 줄 간격 등을 제어할 수 있게 만들어주는 언어입니다. HTML로 만들어진 뼈대에 CSS로 디자인을 입힌다는 개념입니다.


14066284_10208305726855618_3819602411510392924_o.jpg

출처: 조성도 페이스북


JavaScript - 자바스크립트는 웹사이트에서 팝업창을 열거나 전화번호 또는 이메일 주소의 유효성을 체크하는 등의 기능적인 요소를 위해 사용되는 언어로 액션에 용이합니다. 즉 HTML로 만들어진 뼈대에 CSS로 디자인을 입히고 JavaScript로 움직임을 넣는 개념입니다.

jQuery - jQuery는 자주 사용되는 기능들을 쉽게 사용할 수 있도록 모아놓은 자바스크립트 라이브러리입니다. 쉽게 말해 자주 사용하는 자바스크립트의 복잡한 코드를 간소화해주는 모듈을 말합니다. 크로스 브라우징(웹브라우저의 종류에 상관없이 웹사이트의 레이아웃 위치나 모양이 동일하게 보여지도록 서비스 접근성을 향상시키는 기술)이 쉽게 해결됩니다.



반응형 웹으로 할까요, 적응형 웹으로 할까요?


반응형 웹과 적응형 웹도 웹 사이트 구축 시 빠질 수 없는 알아두어야 할 개념입니다. 해당 내용은 더 자세히 설명된 슬로워크 포스팅 글로 이동합니다.

반응형 웹, 정말 효과적일까?



구글지도API를 사용해서 찾아오시는 길에 넣을게요! API?


API - Application Programming Interface의 약자입니다.

각 단어를 나눠서 생각해보시면,

어플리케이션 : 응용프로그램, 즉 흔히 알고 계시는 앱(app)입니다.

프로그래밍 인터페이스 : 기계가 이해하기 쉽게 입출력이 데이터로 이루어지는 인터페이스 입니다.

즉, 웹 어플리케이션 개발에서 다른 서비스에 요청을 보내고 응답을 받기 위해 정의된 명세를 말합니다.


startup_img3.jpg

출처: 공공데이터포털



이렇게 프로그램 간 서로의 커뮤니케이션을 담당하는 기능이라고 이해하시면 됩니다.

최근 우체국의 우편번호 API, 구글과 네이버 다음지도 API등 유용한 API가 많아 홈페이지 구축 시 따로 추가 개발 대신 이러한 *오픈 API를 많이 사용하고 있습니다. 특히 하이브리드 앱이나 워드프레스로 웹사이트를 만들 때 더욱 유용하게 쓰이곤 합니다.


*오픈API - 말 그대로 오픈되어 있는 API, 즉 자사의 API를 개방하여 외부에서 쉽게 쓸 수 있도록 만든 것입니다. 오픈API는 포털의 개방성을 높이기 위한 기술적 기반/개방 응용프로그램 인터페이스입니다.


대표 오픈 API사이트 몇 가지를 소개해드립니다. 아래 사이트에 가보시면API가 어떤 용도로 쓰이시는지 조금 감이 오실 겁니다. 한 번쯤 구경해 보기에도 좋습니다.


서울시공공 오픈API

구글 디벨로퍼

페이스북 개발자

카카오 디벨로퍼



구글api.png

출처: 구글 디벨로퍼

기본적이지만 모르면 외계어처럼 들리는 개발 용어들에 대해 간단히 알아보았습니다. 사실 정말 많은 개발 용어가 존재하고 있고, 개발자마다 사용언어나 사용법이 조금씩 다릅니다. 그렇기에 가장 중요한 것은 내가 함께 일할 동료들의 대화에 귀 기울이며 많은 대화를 하는 것입니다. 이 글을 작성하면서 저 또한 같은 팀 개발자 동료들께 많은 검수를 받고, 조언을 얻었습니다. 그 과정에서 어떤 도구를 사용해 어떤 식으로 일을 하고 있는지도 더욱 자세히 알게 되었고, 커뮤니케이션의 중요성을 다시 한 번 깨닫게 되었습니다.


참조

공공데이터포털 테크엠






Posted by slowalk