나는 어쩌다 제주에 가게 되었나

슬로워크 생산성 엔지니어로 들어온 지 넉 달. 그동안 일을 하며 끊임없이 고민되던 것이 있었다. 바로 같은 팀에 시니어 엔지니어가 없다는 점. 내가 속한 오렌지랩에는 개발자가 나 혼자다. 시니어 엔지니어가 없더라도 업무를 공유할 수 있는 동료 개발자가 있다면 서로 실패와 성공의 경험도 나누고 노하우도 전수받으며 더 빨리 성장할 수 있을 텐데, 아쉽게도 우리 팀의 상황은 그렇지 않았다. 물론 다른 팀에 이런 이야기를 나눌 개발자가 많긴 하지만, 겹치는 업무가 별로 없는 데다 각자 맡은 업무에 집중하고 있어 피드백을 요청하기가 조심스러웠다.


이런 상황에 대한 고민이 깊어갈 때쯤, 오렌지랩의 리더인 펭도님이 슬로워크의 대표이자 개발자 선배이기도 한 시스님과의 면담을 제안해주셨다. 내가 원하는 개발자의 모습은 어떤지, 좋은 개발자는 무엇인지 등 다양한 이야기를 나누다 시스님이 외부 개발자를 많이 만나볼 것을 추천해주셨다. 슬로워크와 한 가족인 빠띠의 달리님이 그중 한 명이었는데, 마침 빠띠에서 진행 중인 3주짜리 코딩캠프의 마지막 주차를 함께 해보는 게 어떻겠냐는 제안을 하셨다. 아니, 다른 개발자들과 코딩캠프를 한다는 것만으로도 좋은데 무려 제주도라니! 고민할 필요가 뭐 있겠나. 바로 가겠다고 했다.


(용눈이 오름)


코딩캠프는 월요일부터 시작이었지만, 나는 이틀 전인 토요일에 비행기를 탔다. 제주도에 가는데, 우선 놀아야지! 토요일엔 김영갑 갤러리를 갔다. 용눈이오름과 제주의 바람을 담은 사진을 한참 바라보다 왔다. 얼마나 아름답던지. 일요일엔 일어나자마자 서핑을 했다. 태풍의 영향 때문에 파도가 높아서 서핑할 맛이 났다. 덕분에 팔과 얼굴에 화상을 입어서 코딩캠프 내내 화상약과 수딩젤을 바르며 지내야 했지만, 그래도 좋았다.


(창문 너머 보이는 푸른 바다가 일품!)


신입개발자, 제주에서 코딩하다

드디어 시작된 월요일, 코딩캠프의 시작이다. 오전에는 각자 회사 업무를 했다. 슬로워크는 워낙 원격근무가 활발하기 때문에, 같은 팀 동료들과 떨어져 일해도 별다른 불편함이 없었다. 점심을 먹고 오후가 되어서야 본격적인 코딩캠프가 시작됐다. 주로 표선해수욕장 근처 카페에서 진행되었는데, 공간도 아늑하고 전경도 멋졌다. 코딩캠프에 참여한 다른 빠띠 개발자들과 처음 만나는 거라, 처음엔 거의 한시간 반 정도를 자기소개와 기대하는 것을 말하는 데 썼다.


내가 기대했던 건, 1) 슬로워크에 적용할만한 디지털 보안규정 사례 듣기, 2) 다른 개발자와 페어 프로그래밍 하기, 3) 빠띠 개발자와 친해지기 이 세 가지였다. 개발자들만 모인 자리라 “우리 전처리기만 돌리다가 끝나는 것 아니냐", “이거 끝나고 컴파일도 하는 거냐"하는 개발자 전용 농담이 난무했고 그게 무척 즐거웠다. 


(자주 갔던 카페의 주인님이 노트북으로 찜질 중)


물론 농담이나 하며 놀기만 했던 건 아니다. 현재 빠띠와 슬로워크에서 사용하고 있는 인프라에 대해 이야기를 나눴는데, 왜 직접 만들지 않고 돈을 주고 서비스를 쓰는지에 대한 설명을 들을 수 있었다. 좋은 서비스를 이용하면 보다 저렴한 가격으로 시스템에 대한 이해가 높은 엔지니어가 할 만한 일을 대신 할 수 있기 때문이었다. 


특히 이날 가장 신났던 것은, 빠띠 동료들이 내 개인 프로젝트를 보고, 괜찮은 프로젝트라며 깃허브(Github)에 별을 달아주고 기능제안까지 한 일이다. (슬로워크에서는 서로의 개인 프로젝트를 지지하고 발전시키기 위한 ‘주작러'라는 소모임을 하는데, 그곳에서 개인 프로젝트를 공유하고 있다.) 나는 평소에 일의 효율성을 높이기 위해 타이머를 설정해두고 일을 하는데, 작업을 작은 시간 단위로 쪼개서 작업하고 강제로 회고를 하도록 하는 타이머를 직접 만들어서 쓰고 있다. 더 추가하고 싶은 기능도 있지만, 최근에 작업을 진행하지 못하고 있었는데 이렇게 피드백을 받고 나니 더 힘이 났다.

(깨알 홍보: https://github.com/ErickRyu/Powerdoro)


(코딩캠프를 함께한 빠띠 개발자 초록머리님과 켄타님)


둘째 날엔 모놀리딕(monolithic)과 마이크로서비스에 대해 이야기하고 켄타님이 커리큘럼을 구성해 온 ‘dapp 101’을 진행했다. 블록체인은 나와 거리가 먼 주제라고 생각하고 있었는데 dapp을 만들게 되다니. 프레임워크도 있는 데다, 켄타님이 커리큘럼을 잘 정리해주셔서 하루 만에 간단한 투표 프로그램을 만들어볼 수 있었다. 여전히 이게 어떻게 작동하는 것인지, 이 프로그램에 적절한 기술인지 이해는 잘 안 갔지만, 블록체인 세계에 한 발 쓱 담가본 것만으로 만족스러웠다. 머리를 썼으니 저녁은 맛있는 음식으로. 제주에 왔으니 회를 먹었다.


(달리님 댁으로 가는 길에 찍은 구름)


광복절이었던 셋째 날, 빠띠팀은 다른 날 대체휴일로 쉬기로 하고 평소처럼 일을 하고 나는 주로 개인 작업을 했다. 저녁에는 달리님 댁에서 바베큐 파티가 열렸다! 매일 그랬지만, 달리님 댁으로 가는 이날 따라 특히 구름이 너무 예뻐서 한참 동안 하늘을 바라봤다. 드디어 도착한 달리님 댁에서 맛있는 고기를 먹었는데, 달리님 아내분께서 우리의 어색함 때문에 숨이 막힌다는 피드백을 하셨다...하핳… 


(우리 친해요?)


넷째 날엔 거버넌스와 컨센서스에 대한 글을 읽고 대화를 나눴다. 빠띠팀과 있으면서 재밌었던 건, 이분들의 모든 대화의 끝이 민주주의였던 것. 정말 회사의 방향성과 일치된 분들이구나 싶었다.

(깨알 홍보: 빠띠의 슬로건은 “민주적인 삶과 문화를 만듭니다.”)


대망의 마지막 날. 크로스 페어 프로그래밍을 했다. 나와 달리님, 달리님과 초록머리님, 초록머리님과 켄타님, 마지막으로 켄타님과 나. 이렇게 돌아가면서 두 명이 페어프로그래밍을 하고 나머지 두 명은 관찰을 했다. 내가 만들고 있는 프로그램으로 대상을 정했고, 목표는 개발모드와 프로덕트모드 분리하기였다. 나는 package.json에 설정을 주는 것을 생각했는데 달리님이 간단하게 파라미터로 dev를 전달하는 것이 어떻겠냐고 제안을 했고 그게 더 쉬울 것 같아 동의했다. 1분도 안 걸려 첫 번째 개발모드가 분리됐다. 예전에 살리고살리고 패턴*을 배운 적이 있는데, 이렇게 같이 프로그래밍을 하다 보니까 내가 최근엔 그렇게 하지 못하고 있는 것이 더 느껴졌다. 돌아가는 것을 빠르게 보니 에너지가 생겨서 다른 부분에도 재밌게 적용을 시작했다. 


*살리고살리고 패턴: 

애자일 코치인 김창준님이 크리스토퍼 알렉산더의 NOO의 원리와 애자일의 원리, TDD의 원리 등을 융합해 만든 것으로, 돌아가는 상태(Working)를 빨리 보는 것이다. 어떤 작업을 시작하면 프로그램이 돌아가지 않는 상태(Not working)가 되는데, 거기서 돌아가는 상태(Working)로 빨리 넘기는 것이다. 단순하고 핵심이 되는 것을 만들고 살을 붙여나가는 방식 등을 함축한 패턴이다.


(회고시간 붙여놓은 포스트잇들)


제주 코딩캠프가 내게 남긴 것

코딩캠프 첫날, 달리님이 “짧은 1주 동안 문제를 해결하기는 힘들 것 같다. 하지만 돌아가서 무엇을 해봐야겠다는 단서들을 가지고 가면 좋겠다.” 뭐 이런 비슷한 말을 했던 것으로 기억한다. 물론 여전히 고민은 그대로다. 하지만 그 고민을 함께해볼 동료들이 생긴 것 같아 기분이 좋다. 빠띠 분들도 슬로워크 사무실에 올 때마다 약간 어색하기도 하고, 괜히 눈치가 보이기도 했는데 이제 내가 있어서 편하게 올 수 있다고 얘기해주셨다. 


개발자가 일을 할 조직을 고를 때 고민하는 것 중에 학습하기 좋은 조직에 들어가는가, 또 조직에 들어가서 학습하기 좋은 문화에 기여하는가, 이 두 가지가 있다는 이야기를 들은 적이 있다. 솔직히 아직 슬로워크가 학습하기 좋은 조직인지는 잘 모르겠다. 하지만 변화를 지지해주고 ‘학습할 의지가 있는 사람을 적극적으로 도와주려는 조직’이라는 것은 항상 느끼고 있다. 이번 코딩캠프에 참가할 수 있도록 자리를 제공해준 게 그렇듯이. 더불어 나도 슬로워크가 학습하기 좋은 문화를 만들어나가는데 기여하는 개발자가 되어야겠다는 다짐으로 즐거웠던 일주일간의 제주 코딩캠프를 마무리한다.



개발자의 학습을 적극적으로 도와주는 슬로워크, 지금 프론트엔드 개발자 채용중!


 

빠띠 초록머리의 ‘제주에서 3주일의 코딩캠프’ 구경가기

빠띠 켄타의 ‘제주에서 일주일’ 보러가기





글, 사진 | 슬로워크 오렌지랩 생산성엔지니어 류성진

편집 | 슬로워크 오렌지랩 마케팅라이터 누들

Posted by slowalk

지난 포스팅에서 개발자와 대화하고 싶은 비 개발자를 위한 참고서에 대한 글을 작성했습니다. 이번 포스팅에서는 개발자와 기획자 간 원활한 커뮤니케이션을 위해 저희 팀 내에서 초기 사용했던 방법이 현재는 어떻게 바뀌었는지 사례를 통해 보여드리겠습니다.

주의! 이 방법은 주로 슬로워크 1팀 기획자인 저와 개발자들이 사용하는 방식으로, 회사별로 팀별로 방법이 다를 수 있습니다. 가장 좋은 방법은 팀 내에서 서로 많은 대화를 해보는 것입니다.




1. 기획자와 개발자의 시간은 다르게 간다.

“이거 금방 되죠?” vs “이거 오래 걸려요”



초기에 기획자로서 흔히 했던 실수는, 개발자에게 정확한 기간이나 요건을 설명하지 않고 금방 될 것이라 추측한 것입니다. ‘금방’, ‘오래'와 같은 단어는 주관적입니다. 내가 생각하는 금방은 하루지만 상대방이 생각하는 금방은 3일일 수 있습니다. “이거 금방 되죠?"와 같은 질문을 받은 개발자는 당연히 금방 되지 않으니 오래 걸린다고 답할 수밖에 없습니다. 그러다 보니 서로 갈등과 오해가 생기게 됩니다. 기획자는 ‘분명 이전 프로젝트에서는 금방 해주었던 것 같은데, 왜 오래 걸린다는 거지’ 혼자 생각하고, 개발자는 ‘지금 요건에서 그 기능은 금방 추가할 수가 없는데 왜 금방 된다는 거지’ 하며 답답해 합니다.


시간에 대해 설명할 때는 구체적인 언급이 필요합니다. 모호하고 주관적 단어 대신 구체적인 단어를 선택해야 합니다.


“이런 기능 요건이 추가되었는데, 3일 안에 가능할까요?”

“이 기능은 지난 프로젝트에서 사용했지만, 이번 프로젝트 개발 구조와 달라 수정이 필요할 것 같아서 3일은 어렵고 5일이 소요될 것 같아요.”


위와 같이 서로 구체적인 기간을 언급하고, 그 이유를 설명해야 불필요한 오해의 소지를 줄일 수 있습니다. 또한, 고객에게 일정을 설명할 때도 정확한 기간을 언급해주는 것이 신뢰의 기본입니다.




2. 개발자와 기획자의 서로 다른 언어

이해관계자와 수많은 커뮤니케이션 vs 프로그래밍 언어로 컴퓨터와 커뮤니케이션




기획자는 여러 이해관계자와 다양한 수준의 커뮤니케이션을 합니다. 이를 통해 일을 정리하고 상대방을 설득하며, 개발자에게도 설명합니다. 즉 기획자가 하는 모든 일은 다른 사람들에게 상대방의 생각을 올바르게 커뮤니케이션해주는 과정에 있습니다. 개발자는 해당 내용을 결과물로 보여주기 위해 일반인이 이해하기 힘든 프로그래밍 코드를 작성하고, 컴퓨터와 대화를 주고 받습니다. 기획안을 오랫동안 설명하였는데 나의 기획과 다른 개발 결과물이 나오는 일도 있고, 반대로 기획자가 가져온 그대로 개발하였는데 번복하는 상황이 생기기도 합니다.


서로가 대화하는 대상이 다름을 인지하는 것이 가장 중요합니다.

기획자는 자신뿐만 아니라 상대방의 생각도, 고객의 요구도 반영해야 합니다. 개발자는 그러한 결과물을 구현해주기 위해 컴퓨터와 끊임없이 대화하고 수정합니다. 그렇기 때문에 서로의 커뮤니케이션 대상자가 다름을 이해할 때 서로 불필요한 오해를 줄일 수 있습니다. 특히 개발언어는 정량적 측정이 어렵기 때문에 정확한 기간을 말하기 힘들 때가 있습니다.


커뮤니케이션 대상자는 다르지만 하나의 결과물을 위해 함께 협업해야 한다는 점을 기억하세요.



3. 개발자와 기획자의 논리적인 대화를 위한 3단계

“이 기능 간단하죠? 전에 한 거랑 같은데.” vs “이거 달라요, 여기엔 안 돼요.”




기획과 개발은 서로 함께 하나의 목표를 위해 달려가는 협업과정입니다. 그 과정에서 서로가 생각하는 바가 다르기도 하고 머릿속에 있는 것을 말로만 설명해서는 이해하기가 어렵습니다. 막바지에 이르러 서로 다른 결과물을 가지고 볼 수도 있습니다. 따라서 대화 전에 아래와 같은 사전 기획서 혹은 간단한 문서를 통해 대화하면 조금 더 논리적이고 오해가 적은  커뮤니케이션을 할 수 있습니다.


1) 자신의 생각을 정리한다

2) 생각을 구체적으로 손으로 그리거나 툴을 이용해 누구나 이해할 수 있게 그린다

3) 1:1로 직접 보고 대화한다


<실제 1팀에서 기획자와 개발자 간에 대화를 위해 작성한 페이퍼프로토타입, ppt 문서>



슬로워크 1팀에서 기획자는 주로 moqups.com과 ppt를 사용합니다. 와이어프레임을 그려 디자이너와 개발자에게 전달하고 내부 세미나를 합니다. 또 역으로 개발자가 기획자에게 관리자 화면이나 기획안 수정 및 요청을 할 때가 있습니다. 주로 직접 그려서 주거나 엑셀 표에 작성해서 전달합니다. 또 가까운 공간에 서로 함께 일하기 때문에 끊임없이 이야기하면서 커뮤니케이션 능력을 서로 업그레이드시키고 있습니다. 특히 제가 개인적으로 선호하는 방식은, 개발자에게 먼저 묻고 일정과 협의를 진행하는 것입니다. 그렇게 되면 일정이나 서로 개발범위에 따른 오해의 소지가 반 이상 줄어들고, 서로 존중하는 프로젝트가 진행됩니다. 개인적으로 짐작하거나 말을 걸기 두려워 지레짐작하다 보면 프로젝트는 산으로 가기 십상입니다. 최근 1팀의 대화는 이렇습니다.


“ A와 B를 통해서 C가 나오도록 해주세요, 10일간의 일정에 가능할까요? “

“네, A와 B를 OO코드로 C가 나오도록 구현할게요. 일정은 10일이면 가능할 것 같아요. ”



4. 마무리

‘우리는 모두 한 배를 타고 있다.’ 서로의 언어에 관심을 가지는 것이 시작입니다.



사실 커뮤니케이션 방법에 정답은 없습니다. 우리 팀에서 잘 맞고, 우리 팀원들과 적합한 커뮤니케이션 방식을 찾아가는 것 또한 업무의 일환이라고 생각합니다. 다만 서로에 대한 배려와 이해하고자 하는 마음 그리고 조금 더 구체적으로 서로의 업무를 설명하는 것이 신뢰를 위한 첫 걸음입니다.



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