스토리 홈

인터뷰

피드

뉴스

조회수 1538

이노버즈미디어의 대표 미남, '박충선 디자이너'

안녕하세요, Y입니다! 지난 옐로피플 스토리에서 뷰신 나나가 첫 번째 인터뷰로 소개되면서 엄청난 화제를 몰고 왔는데요. 이번 두 번째 타자는 바로바로 YDM 소속의 디지털 마케팅 에이전시 이노버즈미디어의 대표 꽃미남 박충선 디자이너 입니다!Y: 안녕하세요! 옐블 독자들을 위한 자기소개 부탁 드려요! 박충선: 안녕하세요, 이노버즈미디어에서 브랜드 콘텐츠를 만들고 있는 디자이너 박충선입니다! 반갑습니다! Y: 브랜드 콘텐츠라! 정확히 어떤 일인지 궁금합니다박충선: 쉽게 말해서 각 기업 브랜드들이 페이스북, 인스타그램 등 소셜미디어에 발행하는 이미지를 제작하는 거죠. 현재는 롯데카드랑 글로벌 스포츠 의류 브랜드인 스파이더 코리아를 맡고 있어요. 아래와 같은 식으로 각 브랜드의 소셜미디어 콘텐츠를 제작하고 있습니다.Y: 본인이 느끼는 이노버즈만의 특별한 점이나 자랑할만한 사내문화가 있나요? 박충선: 사실 이노버즈가 제 첫 직장이라 다른 회사들과 비교하긴 어렵지만, 여기서 1년 4개월동안 몸담으면서 느낀 것은 정말 수평적이라는 거예요. 서로 눈치보지 않고 말할 수 있는 분위기다 보니 정말 다양하게 싱크빅 돋는 아이디어가 많이 나오죠 :) 또 매월 두 명씩 뽑아서 전 직원 앞에서 다양한 주제로 스피치를 해요. 업무에서 벗어나 본인이 흥미를 느끼는 분야 등 개인적인 이야기로 진행하기 때문에 서로를 알아가는데 큰 도움이 되는 것 같아요. 또 인턴과 신입사원은 물론 임직원들을 위한 다양한 교육과 지원을 해주는 것도 이노버즈만의 특별한 점인 것 같아요.출처 : 이노버즈 페이스북Y: 박충선님의 주제는 뭐였나요? 박충선: 저는 아직 안 했어요!ㅋㅋㅋㅋ 샤이가이라서.. Y: 샤이가이셨구나ㅋㅋㅋㅋ 네 다음질문 드릴게요! 기억나는 재미있는 에피소드가 있나요?박충선: 인턴기간에 업무와는 별개로 동료들에 대한 콘텐츠를 만들었어요. 이노버즈 가족 한 명 한 명에 대해 웹툰형식으로 만들었는데 친해질수록 디스(?)내용을 조금씩 넣어봤거든요. 그러다 보니 반응도 좋았고 다들 다음 편은 어떤 디스가 나올지 기대해줘서 재미있었어요ㅋㅋㅋ 역시 까야 제맛이라고……Y: 드라이플라워 고문이라니ㅋㅋㅋㅋ앞으로 드라이플라워 볼 때마다 죄책감들것 같아요ㅋㅋㅋ 그나저나 디자인 팀이라 남자가 많이 없을 것 같아요! 박충선: 이노버즈에 처음 입사했을 때 디자인 실에 저 포함 두 명 빼고 전부 여자분들이었어요. 처음엔 좀 걱정이 됐는데, 다들 좋으신 분들이고 형들처럼(!) 편하게 대해 주셔서 좋았어요ㅎㅎ Y: 다 여자분들이면 회식이 많이 없겠어요! 박충선: 왜 때문에 그런 생각을…… 저보다 잘 드세요 다들 (또르르)Y: 빨리 넘어갈게요!! 이노버즈/옐로모바일에 바라는 점이 있다면? 박충선: 일을 한다는 건 돈을 버는 것도 중요하지만 함께 일하는 사람들, 그리고 회사에서 임직원들을 대하는 자세가 엄청 중요한 것 같아요. 앞으로도 지금처럼 인간관계를 중요시 여기고 직원 한 사람 한 사람을 우선시하는 회사였음 좋겠어요. Y: 마지막 질문입니다! 앞으로는 어떤 일을 해보고 싶으신가요? 충선: 아주 먼 미래에는 디자인을 접목한 카페나 술집을 운영하고 싶어요. 당장은 원래 하고 싶었던 미술을 배워서 지금 하는 일에 적용시켜보고 싶습니다. 앞으로도 재미있는 컨텐츠로 브랜드에 좋은 영향을 미치는 디자이너가 되겠습니다! 저와 이노버즈 많이 응원해주세요! 
조회수 4517

RESTful API를 설계하기 위한 디자인 팁

올라왔었던 REST 아키텍처를 훌륭하게 적용하기 위한 몇 가지 디자인 팁의 글에서 언급되지 않았던 추가적인 내용에 대해서 좀 더 얘기해보고자 합니다. 혹시 이전 포스팅을 읽지 않으셨다면 이전 포스팅을 먼저 읽으신 후 이 포스팅을 읽어주시기 바랍니다.Document?컬렉션에 관해서는 앞서 소개한 이전 글에서 자세히 설명해놓았으니 읽어보시기 바랍니다. 지금 제가 언급할 것을 도큐먼트인데요. 도큐먼트는 컬렉션과는 달리 단수명사나 명사의 조합으로 표현되어 URI에 나타납니다.http://api.soccer.restapi.org/leagues/seattle/teams/trebuchet/players/claudio 위의 예제에서 leauges라는 컬렉션 리소스가 있는 것을 알 수 있습니다. 그 컬렉션의 자식 리소스 중 하나가 seattle이라는 리소스인데요, 바로 이 리소스가 도큐먼트입니다. 도큐먼트는 하위 계층으로 또 컬렉션을 가질 수 있습니다. 이 예제에서의 teams가 seattle의 자식 컬렉션 리소스가 되겠지요. 즉, 단수 리소스는 도큐먼트라 칭하고 복수 리소스는 컬렉션으로 칭한다고 알아두시면 됩니다.이 URI는 또한 문서의 계층 구조를 표현하고 있습니다. 즉 슬래시 기호(/) 다음으로 나타내는 명사가 그 앞에 나오는 명사의 자식 계층이 되는 것이지요. 이러한 도큐먼트의 응답으로써, 요청에서 명시된 Content-Type 헤더에 1:1대응하는 응답을 주는 것이 의미 있을 때가 있습니다. 가령,URI : dogs/1 1) Content-Type: application/json 2) Content-Type: application/xml 3) Content-Type: application/png 이와 같은 URI에 3개의 요청이 주어졌고, 각각 Content-Type이 다음과 같을 때 어떤 응답이 보내져야 할까요? 물론, 그것은 응답을 설계한 사람의 맘이지만 일반적인 기준을 적용해본다면 1번과 2번 요청에는 각각 json, xml 형식으로 구조화된 데이터가 그리고 3번 요청에 대해서는 해당 강아지의 사진이 담긴 png 파일을 보낼 수 있을 것입니다. 또한, Content-Type에 대해서 명시하여 원하는 리소스를 선택할 수 있으므로 URI 내에는 파일 확장자를 포함하지 않는 것이 좋습니다.dogs/1.xml 위와 같은 URI를 만드는 것보다, dogs/1 위의 URI에 Content-Type: application/xml헤더를 포함하여 요청을 보내는 것이 더 적절한 선택입니다. 어째서 파일에 확장자를 붙이지 않는 것이 더 나은 선택일까요? URI는 고유한 리소스를 나타내는 데 쓰여야 합니다. 그런데 URI에 확장자를 붙이는 순간 마치 다른 리소스인 것처럼 느껴집니다. 확장자를 달리하여 같은 리소스에 대한 다른 표현 양식을 주문하는 것이지 해당 리소스가 달라지는 것은 아닙니다. 또한, URI에 직접 확장자가 붙게 되면 해당 리소스 URI가 응답으로 지원하는 확장자만큼 새로운 URI들이 생기게 되겠지요. 결코, 이것은 좋은 디자인이 아닙니다.Controller?기본으로 GET, PUT, POST, DELETE 요청에 1:1매치 되는 개념인 CRUD가 있습니다. CRUD의 앞글자들을 풀어보면 Create, Read, Update, Delete가 될 텐데, 각각 POST, GET, PUT, DELETE에 대응되는 개념입니다. 그런데 사실 URI를 디자인 하다 보면 이러한 방식으로 나타내기 참 어려운 경우를 많이 만나게 됩니다. 그 중 가장 많은 경우가 어떤 특정한 행위를 요청하는 경우입니다. 많은 분이 이럴 때 동사를 쓰는데, 앞선 포스팅에서 밝혔듯이 동사를 써서 URI를 디자인하는 것은 대체로 옳지 않은 방식으로 여겨집니다.이럴 때 컨트롤러 리소스를 정의하여 이 문제를 해결할 수 있습니다. 컨트롤러 리소스는 URI 경로의 제일 마지막 부분에 동사의 형태로 표시되어 해당 URI를 통해 접근했을 때 일어날 행위를 생성합니다. (개념적으로는 이렇게 받아들이시면 됩니다.) 생성과 관련된 요청이 POST이기 때문에 컨트롤러 리소스에 접근하려면 POST 요청을 보내야 합니다. 예제를 살펴보시면 이해하기 빠르실 겁니다.http://api.college.restapi.org/students/morgan/register 리소스 morgan을 등록 http://api.ognom.restapi.org/dbs/reindex 리소스 dbs를 재색인 http://api.build.restapi.org/qa/nightly/runTestSuite 리소스 nightly에 테스트를 수행 그리고 마치 프로그램의 함수처럼 컨트롤러 리소스에는 입력값을 전달할 수 있습니다. 그것은 POST 요청의 엔티티 바디에 포함되어야 합니다. 그리고 역시 함수에서 반환값을 돌려주듯이 컨트롤러 리소스에서는 해당 입력 값에 대한 응답 값을 돌려주면 되겠습니다.URI 뒤에 붙는 쿼리의 용도흔히 GET 요청을 보낼 때 뒤에 추가로 쿼리 스트링(?,=,& 기호를 이용하여)을 전달하곤 합니다. 여기서는 그 쿼리 스트링을 어떻게 디자인 하는 게 좋은지에 대한 논의와 함께 실제 서비스에서 사용되는 사례를 살펴봅니다.가령 특정 컬렉션 리소스에 대하여 질의를 보낼 때 그 컬렉션의 집합이 너무 거대할 수 있으므로 필요한 정도의 정보만을 요구하기 위해서 페이징 값 혹은 구분 값을 쿼리 스트링에 포함할 수 있습니다. 예를 들어 보면/resources?pageSize=10&pageStartIndex=0 페이징을 위한 정보 전달 /dogs?color=red&state=running&location=park 구체적인 검색 제약사항 전달 이런 식으로 써서 페이징을 한다든가 혹은 다른 파라메터(color=red)따위를 던져서 검색 범위를 제한할 수 있습니다. 흔히 쿼리 스트링을 저런 용도로 많이 사용하기 때문에 아마 관찰력이 좋으신 분들은 저런 종류의 쿼리 파라메터를 네이버, 구글 같은 포털사이트의 검색 서비스를 이용하시면서 본 적이 있으실 것입니다.이와는 약간 다르게 실제 DB에서 사용하는 SQL의 select 문과 같은 결과를 낼 수 있도록 돕는 쿼리 스트링을 URI에 나타내려는 시도도 많은 편인데요. 물론 SQL에서 제공하는 구문의 모든 의미를 다 제공할 필요는 없겠지만, 기본적으로 서비스에서 필요한 정도의 인터페이스를 적절히 제공한다면 사용자가 선택할 수 있는 옵션이 많아진다는 측면에서 좋은 방법이겠죠. 이와 관련된 예제를 몇 개 소개하겠습니다. 이것은 실제 서비스에서 API로 제공되었던 URI들입니다. 구조나 의미가 SQL 문과 상당히 유사합니다.LinkedIn /people:(id,first-name,last-name,industry) 이 경우 people 리소스를 요청하되 마치 SQL 쿼리에서 가져올 필드를 제한하는 것처럼 필요한 필드에 대해서만 괄호로 묶어서 지정한 것을 볼 수 있습니다. Facebook /joe.smith/friends?fields=id,name,picture 이 경우 이름(혹은 계정이름)이 joe.smith인 사람의 정보를 가져오되 LinkedIn의 예와 같이 필드를 제한(id,name,picture)해서 가져오도록 한 예입니다. Google ?fields=title,media:group(media:thumbnail) 구글도 마찬가지네요. 이쯤 오면 대략 저 URI가 무엇을 의미하는지 알아채셨으리라 생각합니다. URI 설계시에 주의해야 할 점URI에는 소문자를 사용해야 합니다. 왜냐하면, RFC 3986은 URI 스키마와 호스트를 제외하고는 대소문자를 구별하도록 규정하기 때문이지요.http://api.example.restapi.org/my-folder/my-doc HTTP://API.EXAMPLE.RESTAPI.ORG/my-folder/my-doc 위의 두 URI는 같은 URI입니다. 호스트에서는 대소문자를 구별하지 않기 때문이지요. http://api.example.restapi.org/my-folder/my-doc http://api.example.restapi.org/My-Folder/my-doc 하지만 위의 두 URI는 다른 URI입니다. 뒤에 붙는 path가 대소문자로 구분되기 때문입니다. 물론 소문자가 아닌, 대소문자를 섞어 쓰거나 혹은 대문자만 쓰는 것도 가능하지 않으냐는 반론이 나올 수 있습니다. 하지만 대소문자를 섞어 쓰면 URI를 기억하기 어려울 뿐만 아니라 실제 사용 시 실수하기 쉽다는 단점이 있습니다. 만약 대문자만 쓴다면 상관은 없겠으나 일반적으로는 URI에 대문자를 잘 쓰지 않기 때문에 소문자로 쓰는 것을 권장합니다.HTTP HEADERHTTP 요청과 응답을 보낼 때 특정 헤더를 포함해 요청, 응답 그리고 리소스에 대한 메타 정보를 전달할 수 있습니다. 요청 헤더와 응답 헤더에 포함되면 좋을 만한 헤더 정보들에 대하여 알아보겠습니다.요청 헤더Accept응답으로 받고 싶은 미디어 타입을 명시하기 위하여 사용됩니다. 예제를 들어 설명하겠습니다.GET /magna-opus HTTP/1.1 Host: example.org Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 이 요청은 mangna-opus 리소스에 대해서 기본적으로는 html이나 xhtml의 형식으로 응답을 받고 싶되, 만약 상황이 여의치 않으면 xml을 만약 그것도 여의치 않다면 모든 응답(*/*)을 받아들이겠다는 것을 말합니다. 옆에 붙은 q가 선호도를 나타내게 되지요. (q 생략 시 1값을 가짐) 만약 앞의 예에서 모든 응답에 대한 표시가 없다고 가정하고 서버에서 앞의 세 가지 미디어 타입을 모두 지원할 수 없는 상황이라면 응답으로 406 상태코드를 내보내야 합니다.Accept-Charset응답으로 받고 싶은 캐릭터셋에 대하여 명시하는 헤더입니다.Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 가령 위의 예제는 일단 iso-8859-5를 선호하지만 unicode-1-1도 괜찮다는 메시지를 전달합니다.User-Agent현재 요청을 보낸 Agent의 정보를 표시하기 위해 사용됩니다.User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/21.0 파이어폭스 버전 21.0의 UA스트링, OS에 대한 정보도 담겨져있다. Referer해당 요청을 보내기 바로 직전에 참조하던 리소스 혹은 주소에 대한 정보를 나타내기 위해 사용합니다.Referer: http://en.wikipedia.org/wiki/Main_Page 응답 헤더Content-Length요청과 응답 메시지의 엔티티 바디가 얼마나 큰지에 대한 정보를 나타내기 위해 사용합니다. 단위는 바이트입니다.Content-Length: 348 Last-Modified해당 리소스가 마지막으로 갱신된 시간을 나타내기 위하여 사용됩니다. 캐싱 정책과 관련되어 중요한 헤더중 하나입니다.Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT 캐시나 쿠키정책과 관련된 헤더 정보는 글의 분량을 고려하여 생략하였지만, 매우 중요한 헤더 중 하나이므로 다른 관련 문서들을 검색하여 일독을 권합니다.HTTP 상태 코드의미에 잘 맞는 URI를 설계하는 것도 중요한 일이지만 그 리소스에 대한 응답을 잘 내어주는 것 또한 중요한 일입니다. 그런데 혹시 HTTP의 상태코드 중 200이나 404코드 정도만 알고 계시지 않으신가요? 그 코드의 정확한 의미를 얘기하실 수 있으신가요? 사실 저도 흔하게 볼 수 있는 상태코드 몇 개 정도만 알고 있고 나머지 상태코드의 정확한 의미라든지 쓰임새에는 관심이 별로 없었던 것이 사실이었습니다. 하지만 전문적으로 웹 개발의 길을 걸어갈 사람이라면 그보다는 좀 더 자세히, 많이 알고 있을 필요가 있겠지요. 사실 우리가 생각하는 것보다 훨씬 많은 상태코드가 존재하고 각각 그 쓰임이 다 다릅니다. 그 중 몇 개를 살펴보겠습니다.200 : OK일반적인 요청 성공을 나타내는 데 사용합니다. 단, 주의해야 할 점이 있다면 200코드를 에러 응답에 사용하면 안 된다는 것입니다. 가령 코드는 200인데 에러메시지를 포함한다든가 하면 의미에 맞지 않은 응답코드를 보낸 것이겠지요. 이런 적절치 못한 상황을 처리하는 경우에는 4XX대 코드를 사용하여야 합니다.201 : Created리소스 생성 성공에 대한 응답 코드입니다. CRUD 요청에서 Create 요청에 대한(즉, 컬렉션에 도큐먼트 추가 같은) 응답으로 내보낼 수 있는 응답코드입니다. 응답 헤더의 Location 필드에 생성된 리소스에 접근할 수 있는 URI를 포함할 수 있다면 브라우저에서 그 값을 참조하여 적절히 대응할 수 있겠습니다.202 : Accepted대체로 처리 시간이 오래 걸리는 비동기 요청에 대한 응답으로 사용됩니다. 즉, 이 요청에 대한 응답이 결과를 포함하지 않을 수 있다는 것이죠. 하지만 최소한 응답 헤더나 응답데이터에 해당 처리를 모니터링할 수 있는 리소스 페이지를 안내하거나 혹은 해당 리소스가 처리되기까지의 예상 경과 시간 따위를 안내하는 것이 더 좋은 설계라고 할 수 있겠습니다.301 : Moved Permanently리소스가 이동되었을 경우의 응답코드입니다. 새로 리소스가 이동된 URI를 응답 Location 헤더에 명시해야 합니다. 이 응답을 받은 클라이언트는 새 URI로 이동하든지 아니면 URI를 갱신하고 캐싱을 한다든지 하는 행위를 해야 되겠지요.400 : Bad Request일반적인 요청실패에 사용합니다. 대체로 서버가 이해할 수 없는 형식의 요청이 왔을 때 응답하기 위해 사용됩니다. 무턱대고 400에러를 응답으로 주지 말고, 다른 4XX대의 코드가 더 의미를 잘 설명할 수 있는지에 대하여 고민해야 합니다.401 : Unauthorized말 그대로 리소스 접근 권한을 가지고 있지 않다는 것을 의미하기 위한 응답코드입니다. 리소스를 획득하기 위하여 요청자는 인증에 필요한 헤더(가령 Authorization 헤더 같은)나 데이터를 첨부해야 할 것입니다. 필요한 헤더나 데이터는 서버 쪽에서 요구하는 스펙을 충실히 따라야겠지요.403 : Forbidden감춰진 리소스에 접근하려 할 때의 응답코드입니다. 401과 달리 인증의 여부와 관계없이 리소스를 보여주지 않습니다. 기본적으로 클라이언트 쪽에 정보를 공개하고 싶지 않은 리소스임을 나타내기 위해 사용합니다.404 : Not Found해당 URI와 매치되는 리소스가 없다는 의미를 전달합니다. 어지간한 사람들은 다 한 번씩(?) 마주치게 되는 응답코드이지요.405 : Method Not Allowed지원하지 않는 요청(예를 들어 POST 요청을 받는 컨트롤러 리소스에 GET 요청을 보낸다든가)을 하였을 때 사용합니다. 가능하다면 응답 메시지에 Allow 헤더를 추가하고 그곳에 지원하는 메서드를 명시하여 클라이언트 측에서 정확한 요청을 보낼 수 있도록 유도합니다.Allow: GET, POST 406 : Not Acceptable해당 미디어 타입(MIME 타입)에 대해서 지원하지 않을 때 사용합니다. 요청 Accept 헤더에 명기된 타입(가령 Application/xml)에 대해서 지원이 불가능할 경우에 돌려주면 되는 코드입니다.409 : Conflict요청의 형식에는 문제가 없지만 리소스 상태에 의하여 해당 요청 자체를 수행할 수 없는 경우의 응답코드입니다. 즉, 이미 삭제된 리소스를 또 삭제한다든가 비어있는 리스트에서 무언가를 요청한다든가 하는 모순된 상황을 생각해보면 되겠습니다. 응답으로는 그 방법을 어떻게 해결할 수 있을지에(혹은 문제가 무엇인지) 대한 힌트가 포함되면 좋을 것입니다.500 : Internal Server Error일반적인 서버 에러에 대한 응답코드입니다. 4XX대의 에러코드가 클라이언트 측 에러를 나타내기 위해 사용된다면, 5XX대의 에러코드는 서버 측 에러를 나타내기 위해 사용됩니다.503 : Service Unavailable가장 두려운(?) 응답코드 중 하나일 503입니다. 현재 서버에 과부하가 걸려있거나 유지보수를 위하여 잠시 접근이 거부될 때 필요한 응답코드입니다.그냥 맨 앞의 숫자별로 퉁쳐서 상태코드를 내보내지 않고, 이렇게 디테일한 의미까지 따져가면서 상태코드를 내보내는 것에 대해서 그 효용성에 의문을 제기하시는 분들이 있을 것 같습니다. 하지만 브라우저에서 혹은 서버 단에서 특정 상태코드에 대해서 내부 구현을 달리하거나 최적화를 통해 더 쾌적한 환경을 제공할 가능성이 있으므로 되도록 의미에 걸맞은 상태코드를 사용하는 것을 생활화하는 것이 중요합니다. 또한, 이렇게 디테일한 상황을 가정하고 만든 URI들이 다음에 서비스를 확장할 때 큰 도움이 될 것임은 의심할 여지가 없겠지요.위에서 소개한 응답 코드 말고 또 다른 응답 코드들에 대해서도 전부 소개해 놓은 링크를 밑에 달아두었으니 참고하시기 바랍니다.정리지금까지 소개한 내용이 조금은 두서없게 느껴졌을 수도 있겠다는 생각이 들어 한 번 전체 내용 정리를 해보려 합니다.컨트롤러의 정확한 쓰임을 알고 적절한 컨트롤러 URI를 구현하자.URI에 추가로 붙게 되는 쿼리 스트링의 형식을 잘 디자인하여 사용자로 하여금 적재적소에 쓸 수 있도록 하자.가능하다면 이용 가능한 HTTP 헤더를 적절하게 첨가하자.HTTP 상태코드의 의미에 대해서 생각해보고 상황에 맞는 적절한 상태 코드를 응답으로 보내줄 수 있도록 하자.이 글을 쓰면서 한빛 미디어의 일관성 있는 웹 서비스 인터페이스 설계를 위한 REST API 디자인 규칙과 apigee사의 web API design eBook을 참고하였습니다. 둘 다 내용이 좋은 서적이고 이 글에서 다루지 않은 심층 내용을 다루니 기회가 되시면 읽어보세요.referencesUniform resource identifierapigee api design best practicesrestful uri designHTTP status codesList of HTTP status codesURI schemeMIME typesMIMEfun and unusual http response headers#스포카 #디자인 #디자이너 #디자인팀 #개발 #개발자 #개발팀 #협업 #코워킹 #Co-working #업무프로세스 #꿀팁 #인사이트
조회수 1030

브랜딩은 틀린 말이다?!

일단 명백하게 짚고 넘어가야 할 것이 있습니다. 브랜딩이라는 단어가 남발하는 요즘, 사실 이 단어자체가 올바른 표현인지 다시 생각해 볼 필요가 있다는 것이죠. 당초 Brand라는 어휘는 피부에 새긴 화상과 같은 낙인이나 흔적을 의하는 burn의 어원과 그 맥을 함께합니다. 브랜드라는 뜻이 라틴어로는 '불태우다' 라는 뜻이기 때문이죠.이는 당연히 무언가를 구별/식별하기 위한 '표식' 의 의미로 쓰인 것입니다. 그러니까 그냥 로고를 의미했던 것이었죠. 하지만, 요즘엔 그 의미가 많이 확장/변형되었습니다. 이유는 단순해요. 너무 많은 표식들이 생겨났기 때문입니다. 게다가 오래전엔 죄수나 사형수, 범죄자, 이상한애들에게 부여했던 것이 '낙인' 이었기에 사람들에게 매력을 어필할 필요가 없었어요. 그냥 그런 표식을 지닌 애들을 피하면 그만이었죠. 그러나 요즘의 브랜드는 비지니스자체이니 사람들의 마음과 지갑을 열게 해야합니다. '낙인'의 역할이 완전히 바뀌게 된 것이죠. 예전엔 낙인을 '구별' 하기만 하면 되었지만요즘엔 낙인을 '선택' 해야하는 시대가 되었습니다.구별과 선택은 다른 개념이예요. 구별은 인식의 개념이기 때문에 '아 그렇구나' 하고 끄덕이기만 하면 됩니다. 하지만 선택은 행동의 개념이라서 '하나를 선택하고 나머지를 포기하게끔' 해야 하죠. 이 때 기회비용이 발생하면서(심리적이든, 실물적이든) 브랜드는 그것 이상의 가치를 제공해야 하는 입장이 되었습니다. 그래서 수많은 눈요기와 정책, 장점, 특징들을 내세우며 "우린 가치가 있어!!" 라고 소리지르고 있는 상태가 바로 요즘입니다.자, 하지만 여기서 함정이 발생합니다. 위에서 말했듯 고객은 무언가를 선택할 때 얻는 이득과 기회비용 사이의 가치를 저울질합니다. 그리고 더 합리적인 선택을 하겠죠. 적어도 이론적으론 말입니다. 그러나 현실은 엉망진창입니다. 사람은 그리 합리적인 존재도 아니고 이득과 기회비용 사이의 가치를 정확히 판단하지도 못합니다. 게다가 그 판단의 기준은 지극히 개인적인 성향과 가치관에 좌우되기도 하고, 심지어 그 성향과 가치관이란 것은 트렌드와 다수의 압박 등 예상치 못한 변수들에 의해 기묘하게 변질되기도 합니다.상황이 이렇다보니, 일관적인 기묘하게 이상한 포인트에서 대박치는 회사가 있는가 하면, 정석대로 해도 영 반응이 시원찮은 경우도 많습니다. 때문에 브랜드를 하는 사람들이나 그걸 원하는 회사나 도무지 갈피를 잡기가 힘들어졌죠.  물론 데이터가 쌓이면서 일정 패턴이 발생했던 것은 사실입니다. 인지/사회심리학의 도움으로 인간 행동의 불특정성을 어느정도 규명해나가고 있는 것이죠. 그러나 그것이 규명되는 속도보다 사람과 시대의 변화속도가 훨씬 빠르다는 것입니다.사람의 행동이 이렇게 가변적이니 전략을 짜는 사람 입장에선 그것에 일일이 맞추다가 늙어죽을 것 같았을 겁니다. 그러다 누군가가 이런생각을 했겠죠. 사실 생각을 했다기보단 천성적인 마이웨이가 있던 사람이었을 겁니다. 그냥 하던거나 계속 해야겠다...라고. 그리곤 그냥 해오던 걸 꾸준히 계속 묵묵히 했더니. 생각지도 못했던 평가들이 등장하기 시작합니다. 부정적이든 긍정적이든 꾸준한 일관성은 캐릭터를 만들어냈고, 그들은 예측가능한 존재가 되었습니다. 보통 이러면 매력이 사라져야 맞는데, 오히려 그 일관성에 열광하는 팬층이 발생하기 시작했습니다. 그리고 그 팬층을 동경하던 어중간한 포지션에 있던 사람들이 그들을 따라서 유입되기도 했죠. 굳이 어디라고 얘기하지 않아도 익히 알려진 대부분의 성공사례의 기업들의 브랜딩 전략을 떠올려볼 수 있을 것 같습니다.이런 프로세스가 성공사례로 속속 등장하기 시작하면서 브랜딩은 더이상 '우리가 그들에게 무언가를 하는 것' 의 개념이 아니게 되었습니다. 나는 그냥 하던걸 잘하는 것이고, 브랜딩은 그것을 통해 "되어지는 것" 이죠. 그래서 브랜딩은 그 자체가 목적이 아니라 일종의 부수효과라고 하는 편이 오히려 맞을 것 같습니다.그러니 "Branding" ..브랜딩을 한다! 라는 능동적표현보단 "Branded" 브랜딩 되어진다.라는 수동적표현이 오히려 적절하지 않을까 싶네요.물론 반론의 여지가 있긴 합니다. 예를 들어 키엘의 경우 Lab느낌의 화장품매장을 컨셉화했고, 직원들에게 기본적인 의학적지식을 교육시키는 등 어떤 전략에 의해서 움직이고 있습니다. 또한 이것이 키엘의 브랜드를 명확하게 만들었으니, 이것은 화장품전문가를 원하던 고객들의 니즈를 파악해서 그에 응답한 것이 아니냐?! 라는 의견이 나올 수 있겠죠.Kiehl's : 약국에서 화장품을 판다!..라는 컨셉으로 직원들은 약사복을 입고있습니다. 맞는 말입니다. 물론 키엘은 수많은 서칭과 서베이, 내부회의를 거쳐서 최초컨셉을 기획하고 확장시켰을 것입니다. 그러나, 애플도 그랬고 다이슨도 그랬고 키엘이나 이니스프리, 에뛰드하우스도 그렇듯 고객이 이걸 원하니까 이걸하자! 라고 시작하진 않았습니다. 오히려 그렇게 색깔이 분명한 곳들은 최초의 리스크가 엄청났을 텐데 그런 관점에서 본다면 합리적이거나 효율적인 선택은 아니었겠죠. 그걸 원하지 않는 대다수의 사람들을 포기해야 했을 테니까요.  대신 그들이 선택한 것은 이게 시장이 원하든 원치 않든 내가 옳다고 생각되는 색깔을 일관성있게 밀어붙이고 유지하는 것이었습니다.  "너희가 원하니까 이걸 하겠습니다.." 가 아니고 "우린 이런 기업입니다." 라고 무심하고 담담하게 걸어가는 편을 택한 것이죠"너희가 원하니까 이걸 하겠습니다.." 가 아니고"우린 이런 기업입니다." 라고 무심하고 담담하게 걸어가는 편을 택한 것이죠.그러니, 브랜드라는 것은 이제 한 순간의 낙인과 표식의 의미가 아닙니다. 그것은 꾸준한 행동과 신념의 일관성을 의미하는 단어가 되었습니다. 그들은 모두가 아닌, 우리를 사랑하고 지지해주는 고객들을 위해 최선을 다했습니다. 사회적책임을 다하고 제품이면 제품, 서비스면 서비스 그 자체에 충실했습니다. 브랜드는 이런 일련의 과정과 시간을 통해 자연스럽게 축적되어가는 것이 아닐까 싶습니다.그러니 우리가 지금부터 알아볼 것은, 고객의 마음을 사로잡기 위해 안간힘을 쓰는 그런 종류의 것이 아니라 우리가 하던 일을 어떻게 꾸준히 지속시키고 깊이 있게 만들것인가를 고민해보도록 하겠습니다.#애프터모멘트크리에이티브랩 #마케팅 #마케터 #마케팅팀 #브랜드 #브랜드마케팅 #브랜딩 #인사이트 #조언
조회수 1509

'회사소개서 만드는데 얼마에요?'

오더의 정석: 무엇을 알려주어야 할까? 우리가 병원에 가면 일단 접수를 하고, 기다렸다가 의사샘을 만나서 증상을 얘기하잖아요. 사실 모든 일은 이런 순서라는 게 있어요. 다짜고짜 원장실로 직행한 후 멱살을 잡고 주사를 내놓으라고 할 수 없어요. 증상도 얘기 안하고 얼마냐고 물어볼 수도 없어요. 어딜 어떻게 하고 싶은지 말을 해줘야 해요.얼마여!! 얼마냐고!!!!!디자이너에게 의뢰를 할 때도 비슷해요. 뭔가 접수가 있고, 미팅을 하고 협의를 하고 증상을 얘기한 후 거기에 맞는 솔루션의 비용을 책정하는 것이 기본이예요. 자, 이제 한 번 의뢰를 해볼께요.우리는 회사소개서를 만들고싶으니, 일단 회사소개서를 잘 만드는 사람을 수소문 해볼거예요. 소개건이나 포트폴리오 사이트를 뒤져서 괜찮은 컨셉의 디자이너를 컨택하겠죠. 컨택 후엔 유비의 심정으로 메시지를 보낼 거예요. 보통 페이스북이나 SNS에서 디자이너를 소개받은 경우엔 이 메시지의 간결성이 더욱 강렬해집니다.   “회사소개서 만들려고 하는데, 견적 요청드립니다.” “회사소개서 만들려고 하는데 가능하신가요.” “회사소개서 제작하는데 얼마정도 하시나요.” 회사소개서 얼마임? 이라고 하지 않은 것이 다행일정도로 간결한 의뢰예요.조만간 초성만 쓸지도 몰라요.  ㅅㄱㅅ ㅇㅁ?대다수의 이러한 메시지를 받은 디자이너는 머리위에 600개 정도의 물음표가 생기기 마련이죠.???????????????????무슨 종류의 어떤 제작건이며, 컨셉은 무엇이고, 가로인지, 세로인지, 페이지는, 기한은, 용도는, 인쇄는, 디자인범위는 아트웍이나 사진, 자료제공은 어떻게, 담당자는, 지불방식은, 계약여부는?등등 엄청난 궁금증을 뒤로 한 채 다시 물어보곤 해요.“언제까지인가요?” “다음주 수요일까지 해주시면 됩니다.” "몇 장이예요?""20장 정도됩니다."보통은 이런 식의 대화가 수십 번 오고 가는데 이러한 소통에는 디자이너의 책임도 있을 거예요. 아예 의뢰서양식을 만들어서 기입해 달라고 메일로 보내면 차라리 간편할 일일 수도 있겠네요. 하지만, 우리는 대화끝에 ‘^^’도 붙여야 하고 ’ㅜㅜ’도 붙여야 하는 등 힘들고도 답답한 대화를 이어가는 것이 보통이예요. 의뢰는 하는 방법을 스크립트로 말하면 대략 아래와 같을 거예요. ‘이번에 저희 회사 회사소개서를 만들려고 합니다. OO사이트의 포트폴리오를 보고 연락드립니다. 해당 회사소개서는 아래 내용과 함께 제작을 진행하려고 하오니, 확인하시고 관련된 견적과 추가적인 포트폴리오가 있으시다면 유첨하여 회신주시면 감사드리겠습니다.1. 제작기한 : 20XX년 9월30일(18:00까지)2. 제작목적 : 대외발송용 회사소개서 제작3. 제작방식 : 30페이지의 가로좌철 중철제본 표지4p+내지26p 구성 / A4사이즈4. 자료제공 : 디자인에 필요한 사진자료 및 텍스트는 제공해드립니다.5. 제공시점 : 견적확인 후 구두계약상 확정이 되면 당일 중으로 전달해드릴 예정입니다.6. 제작컨셉 : 하기첨부한 레퍼런스 양식을 확인해주시면 되겠습니다.(이미지첨부)7. 작업범위 : 인쇄는 저희측에서 진행합니다, 디자이너님께는 제작된 디자인파일의 PDF본과 ai원본파일을 요청드립니다. 원본제공에 대한 추가옵션도 견적에 포함시켜주시면 감사하겠습니다.8. 업체특성 : 저희는 비즈니스솔루션을 제공하는 IT업체로서 B2B를 전문으로 하는 터라 전문적이고 레퍼런스가 눈에 띄는 형식이면 좋겠습니다. 상세한 회사소개는 회사소개서를 첨부하여 드립니다.9. 계약방식 : 견적 조율 후 계약은 서면으로 작성합니다.10. 기정예산 : 추후 협의가능합니다.11. 지불방식 : 견적 조율 후 계약금30%와 잔금70%형식으로 지불되며 일정은 추후 계약서에 상세기재하도록 하겠습니다.12. 담당자명 : OOO / 연락처 : 010-0000-0000이러한 방식으로 의뢰를 해준다면 엄청나게 감사하고 황공해요.  감사!!!!!!!!!!!!!!!!!하지만, 굳이 이정도 까지가 아니더라도 적어도 기본적인 기한, 비용, 작업범위 등 정도만이라도 알려주는 것은 일종의 예의라고 할 수 있죠. 디자이너는 미륵보살이 아니기에 관심법을 쓸 수 없어요.그러나 무작정 이렇게 적으라고 강요하는 것은 실무자입장에서 다소 억울할 수 있으니, 잠시 디자이너는 어떤 방식으로 작업을 하는 지 살펴볼 필요가 있어요.  디자이너는 우선 백지에서 작업을 시작하지 않아요. 적어도 저는 그래요. 전 백지가 꽤나 무섭거든요. 기본적으로 클라이언트가 요청한 내용과 컨셉에 대한 다양한 레퍼런스를 검토하고 찾아보는 작업이 먼저예요. 핀터레스트를 뒤지고 비핸스를 뒤지고 뒤지다가 구경하고 계속 보다가..하루가 가고.........(이러면 안됨)핀터레스트를 보는 눈빛....우리 회사가 원하는 방향과 색깔을 얘기해주지 않으면 애당초 컨셉 설정 자체가 어려워질 거예요. 핀터레스트에는 오만가지 예쁘고 다양한 시안들이 가득하거든요.   이 작업을 좀 더 빠르게 할 수 있는 방법이 담당자가 직접 레퍼런스 이미지를 찾아서 첨부해주는 방법인데, 귀찮다면 디자이너에게 직접 요청하도록 해요.  물론 홈페이지 주소만 덜렁 던져주고 ‘당신이 알아서 찾아보세요.’ 라는 식의 행동은 자칫 오해를 불러일으킬 수 있으니, 상세한 회사설명을 직접 언급해주는 편이 좋아요. 이런 식으로 말이죠.우리 회사는 이런이런 일을 하고 있는데 타겟층은 이러하고 이런 서비스를 통해 이런 가치를 주려고 합니다. 현재 이런이런 정도까지 브랜드작업이 진행되있는데 이것때문에 주춤하고 있고, 이 소개서를 통해 넥스트 이런것들을 달성해보려고 해요!~ 지금까지 저희가 해왔던 대략적인 시안컨셉이 이러했습니다. 하지만 꼭 이렇게 가지 않아도 돼요. 조금 가벼운 느낌을 주면서 아기자기한 컨셉으로 재구성해보려고 하는데, 어울리는 컨셉 2,3가지를 제안해주시면 감사하겠습니다. 위에서 컨셉이 잡히고 나면 레이아웃과 스타일 설정을 한다고 했는데, 이 레이아웃이란 것은 백지에 선을 긋는 작업이므로 일단 작업사이즈를 정확하게 알아야하죠. 주로 mm단위나 픽셀단위로 알려주어야 해요! 그리고 책자라면 제본위치와 방식두요!(기껏 작업해놓고 타공으로 글자 다 뚫리면 개난감) 이 후 본격적인 작업을 진행하는데 디자이너는 하루에 얼마나 작업을 해야 하고, 수정시기는 언제쯤이 좋을 지 시간분배를 해요.  디자이너는 도깨비방망이로 작업하지 않아요.(물론 그런게 있으면 좋겠지만) 나오라면 뚝딱 나오는 것이 아니며, 폰트 자간 수정하는 데에만 몇 시간이 걸리기도 하죠. 물론 이게 좋은 건 아니지만, 확실히 물리적 시간이 걸리는 노가다가 많거든요. PPT디자인도 그러해요. 물리적으로도 1페이지당 1시간씩만 잡아도 30페이지면 30시간이예요. 대부분 디자인은 중간에 갈아엎거나 컨셉 전체가 바뀌는 경우도 있기 때문에 물리적계산보다 훨씬 오랜 시간이 걸리기 마련이겠죠. 물론 저 30시간은 밥도 안 먹고, 잠도 안 자고, 화장실도 안 간다는 전제로 가능하다는 얘기예요.참으면 건강에 안좋음..하지만 디자이너도 사람이니 카톡 볼 시간은 있어야 하지 않겠습니까. 작업기한은 명확하게 알려주도록 해요. 단, 기한은 1주일뒤인데, 자료를 주는 시점이 3일 뒤라면 그것 또한 문제가 되겠죠... 제작기한은 자료를 제공하는 시점으로부터 몇 일로 책정하여 알려주는 것이 온당해요! 그리고 가장 중요한 비용문제는 직접 제안해도, 역제안을 요청해도 상관은 없는 것 같아요. 다만, ‘일단 그것은 협의중이니 디자인부터 해주세요.’ 라는 것은 좋지 않아요. 아직 반찬은 사오지 않았지만 물부터 올려놔라..하는 것과 같달까요. 세상 어느 법도에도 얼마 줄 지도 얘기하지 않고 무작정 일부터 시키는 경우는 없어요. 이러한 깜깜이 계약를 진행하다가 추후에 도저히 맞지 않는 견적으로 서로 문제가 생기게 되면 디자이너도 클라이언트도 서로 피곤해지기 마련이죠. 그러니 비용문제는 세상 무엇보다 정확하고 딱딱 떨어지게 얘기하는 것이 좋아요.  그렇지 않으면 이런 미션을 수행하게 됨 물론 위의 내용은 제작물을 외주로 진행할 때의 경우이지만 인하우스 디자이너에게 요청할 때도 거의 비슷해요! 내부 디자이너에겐 위 내용의 1~7번까지를 서면으로 제공해주는 것이 좋으며, 추가적으로 결재라인과 1,2차 시안제출일도 함께 적어주는 거예요. 다른 업무와의 균형도 맞추어야 하고 작업시간도 책정해야 해요. 이 때 ‘당연히 우리의 놀라우신 디자이너님은 새벽2시에 퇴근하시겠지?’ 라는 생각의 업무시간 책정은 싫어요. 디자이너도 밤에 잠을 청하는 생명체예요.  -.- 내부 제작물이든, 외주건이든 결국 가장 중요한 것은 ‘소통의 정확성’ 이예요. 사실 1번, 2번, 3번으로 항목별 나열을 한 것은 줄글로 쓸 때보다 정보누락의 확률이 줄어들기 때문이죠. 대부분 줄글이나 구두지시는 추후에 오더상의 문제를 야기할 가능성이 커요. 읽다가 놓치는 것들이 많아지거든요. 넘버링은 신비한 힘을 지니고 있으니 숫자의 힘을 믿어보아요. 
조회수 24975

면접관으로서의 스타트업 면접 후기

어느덧 학창시절 지원자로서 면접 본 횟수보다, 면접관으로서 면접을 치르게 된 횟수가 3배 4배는 더 많아진 것 같습니다.  어렸을 땐, 면접관이 무얼 물어볼지 구글링하고 선배들에게 조언을 구하거나 서점에서 면접대비 책을 구매해가면서까지, 예상질문과 예답을 만들어가며 심지어 기숙사 벽장에 포스트잇까지 붙여가며 말하는 톤 하나하나 엄청 연습을 했었는데, 직접 사업을 운영해보니 그때 내가 지원자로서 받았던 질문들, 도무지 이런 질문까지도 준비를 해가야 하는거야? 라는 생각이 들 수 밖에 없던 질문들을 회사는 왜 물어볼 수 밖에 없는지 아니, 물어야만 하는지,  이젠 너무 훤히 알아서 실웃음이 나옵니다.  그만큼, 구인자와 구직자의 시각과 입장 차이가 다르다는 거겠죠. 도대체 우리나라 이력서는 왜 얼굴 사진을 박으라고 하고, 도대체 엄마 아빠 나이랑 직업은 왜 쓰라고 하는거야 심지어 몸무게, 키는 왜 써? 어이가 없네? 이런 생각을 저도 했었어요 하하. 팀원들끼리는 우스개 소리로,  지원자의 조부모님은 안녕하신지 한번 물어볼까? 라고 얘기합니다.  이 말을 알아들으신다면, 아마 여러분도 저만큼 또는 저보다 더 많은 사업 경험을 하신 분일지 모르겠습니다. 최근 우리 회사도, 다양한 직군의 신규 인력을 채용 중에 있어,  제 주간 스케줄 다이어리에 매주 4~5타임이 넘게 면접 일정이 채워지고 있습니다.  이번 포스팅에서는, 회사가 어떻게 인재상을 만들어가는지에 대한 내용을 다루려고 합니다.  CJ나 삼성과 같은 대기업 홈페이지를 들어가보면, 뭐 애플이나 구글 등 외국계 careers 사이트도 마찬가지겠고요. 회사소개나 비전, 인재상 등이 나와있는 페이지를 클릭하면 우리 회사는 어떠어떠한 인재를 원한다고 언급되어 있습니다.   열정, 도전정신, 끈기, 긍정 뭐 이런 말 많이 들어봤을 거에요.  어렸을 땐, 에이 으레 하는 말이겠거니 하고 그렇게 중요하게 살펴보지 않았어요.   그런데, 실제 회사를 운영해보니, 이게 웬걸, 그게 제일 중요하더라고요. 왜 중요할까요?▷인재상을 찾아가는 계기초기 스타트업의 경우, 함께 같이 일할 멤버를 찾습니다.  가족이나 친척이 될 수도 있고, 친구가 될 수도 있고 또는 건너 건너 소개를 받거나, 온라인에서 알게 되는 경우 등 다양한 경로로 멤버를 구합니다.  시간이 흐르면 흐를수록, 해치우는 일 보다, 해야할 일이 더 많아지게 되고, 운영진은 추가 인력 채용을 고민하게 됩니다.  그런데, 경험이 부족하다 보니, 정말 딱 맞는 친구가 들어오게 되면 너무 좋겠지만, 세팅을 해나가는 중인 회사는 회사 나름대로 안 따라줘서 답답하고, 직원은 직원 나름대로 고생하는 입장이 있겠고 거기서 빚어지는 자잘한 마찰이나 서투름 등을 이유로 결별하는 경우가 잦습니다.  이직이 빈번한 요즘 시대에, 스타트업은 인력변동이 더 심하죠. 처음엔, 직원과의 결별은 씁쓰름하고 여운이 며칠 갈 때도 있지만, 시간이 흐르면, 오히려 서로 개운할 때도 있습니다. 직원으로선 실력과 본인의 커리어를 한줄씩 차곡차곡 쌓아가고, 회사는 어떤 사람이 우리가 하는 일과 우리의 분위기와 우리의 업무 스타일에 맞는 사람인지 형상을 구체화하기 시작합니다. ▷회사와 직원 간의 호흡우리 회사는, 지원자 중에서 창업 경험이 있거나 창업 멤버로 일한 경험이 있는 친구를 좋아합니다.  설령 짧게 몸담았을지라도,  운영했던 회사가 비록 문을 닫았을지라도 그 경험을 저는 굉장히 가치 있게 여깁니다. 회사를 운영한다는 것이 여간 힘든 게 아니라는 것을 아는 친구,  운영진으로서 직원들에게는 말 못하는 고민들이 무언지 잘 아는 친구는, 회사의 방향성을 잘 이해합니다.  여기서 실력이나 역량은 그 다음입니다.  설령 능력이 뛰어나지 않더라도,  함께 의논하고 각자 맡은 바 일을 매일매일 조금씩 해내는 직원이 회사가 원하는 인재입니다. 빅딜을 계속 연이어 따거나,  거액 투자 유치를 하면 분명 회사는 비약적으로 성장하겠지만,  직원과 회사의 호흡이 따라주지 않으면 회사의 기반이 약할 수 밖에 없습니다. 지휘자가 스파르타식으로 단원들 연습을 단행한다던가 자기 맘대로 지휘하고, 오케스트라 단원들은 지휘자 손깃 한번 쳐다보지 않고 알아서 연주한다면, 심지어, 다른 단원의 악기 소리는 듣지도 않고 연주한다면 과연 그 소리는 아름다울까요?  그 합주를 듣고 관객은 어떤 반응을 할까요?회사라는 조직도 마찬가지입니다.  회사는 직원을 존중하고 나아가는 방향대로 따라올 수 있도록, 기다려줘야 합니다.  직원도 운영진의 입장과 회사가 나아고자 하는 방향을 정확히 알고 있어야 합니다.  쪽팔림 이런 거 개의치 않고 모르면 물어봐야 할 정도로 중요한 부분입니다.  마케팅, 영업, 개발, 디자인, 고객센터 등 업무는 다르지만, 내가 하는 일이 유기적으로 다른 파트와 어떻게 연결되어 있는지 알고 있어야 합니다.  초등학교 운동회를 하면, 청팀 백팀 대항 중 단골 게임인, 발목을 묶는 공동달리기 시합이 있습니다.  한 사람이 넘어지면, 같이 일으켜 세우고 격려해주고, 탓하지 않아야 합니다.   물론, 한 사람이 넘어지면, 어깨동무하던 옆사람도 넘어지는 점도 알아야 합니다.  성숙한 조직 생활이라는 건, 일이란 나 혼자 잘 한다고 되는 일이 아니라는 것을 인지하는 것에서부터 시작한다고 봅니다.  체계적인 조직 생활이라는 건, 직원들의 감정을 무시하지 않고 또 직원들의 역량과 성격 성향을 잘 이해하는 것에서부터 시작합니다. 실력이 아무리 좋아도, 회사 입장이 아닌 내 입장으로만 생각하는 사람은 원치 않습니다.   하찮은 주제를 가지고 얘기하거나 잡담을 하더라도, 말 한마디 말 한마디를 들어보면, 이 사람이 회사를 평소에 어떻게 생각하고 있는지 훤히 보입니다.   ▷스타트업이 지원자를 보는 관점규모와 서비스 업종에 상관 없이 기업이라면, 인재 채용을 정말 중요하게 여깁니다.  아무나 들어와도 상관없어- 하는 경영진은 아마 없을 거에요.  누가 들어오느냐에 따라 회사의 방향과 속도가 달라지는 만큼, 인재 한명이 회사를 일으켜 세우고, 한 명 때문에 망할 수 있는 게 회사입니다.  심지어 스타트업은, 1인 다인 역할은 물론 자기 일은 알아서 잘 해내야 하는 곳입니다. 면접을 진행할 때 회사가 보는 부분은 해당 업무에 대한 관심의 무게와 이해력, 적응력이 빠른지, 이전 회사에서 무엇을 성취해 왔는지, 그 경력이 우리 회사에선 어떤 식으로 역량 발휘가 되는지를 살펴봅니다. 어떤 서비스를 제공하는지, 서비스에 대한 이해, 열정과 배움의 자세, 인성과 성격 등 다양한 관점으로도 지원자의 합격여부를 고려하구요.  전공은 뭐고, 이전 경력은 뭐고, 어떤 역량이 있고 이런 것들도 물론 중요하지만, 스타트업은 특히 이 사람이 과연 스타트업에서 일할 수 있는 사람인지를 염려합니다.  예를 들면 이런거죠.  어떤 사람의 이력서를 보니, 줄곧 큰 기업에서만 일해왔는데,  과연 부서가 곧 직원 한 명,  회사가 팀인 작은 회사에서 일할 수 있을까 라는 의구심이 드는거죠. 그간 채용을 진행하며 깨달은 건, 전공과 직장 경력을 떠나서 역량에 대한 자기계발 및 자기반성이 부족할 경우, 회사로서는 아무리 그 사람의 성향에 맞는 일을 주거나 다른 보직으로 변경해도 답이 안 나온다-라는 겁니다. 결과물에 대한 스스로의 기준이 낮은 사람은, 장기적으로 회사에 도움이 되는 인재가 아닙니다.  이는 비단 실력의 문제가 아닙니다.  아무리 실력이 뛰어나도 대충대충 일하면 결과물이 나올까요? 학교 시험성적이 70점 나왔다고 탓하는 게 아니라 아쉽지만, 본인 스스로 70점을 받으면 속상해서 더 열심히 공부를 할 수 있는 계기만 된다면 그건 속상한 일이 아닌데, 70점 맞고도 속상은 커녕 너울너울 지낸다면, 과연 그 학생은 평생 만년 70점에 만족하는 사람이 되겠죠.  그래서 경력이 많은 사람이 채용 되는 게 아니라, 직장 경력과 연수는 적을지라도 잠재 역량이 높은 사람, 상황 별 대처 능력과 판단 능력이 있는 사람, 해결 능력이 있는 사람을 회사는 채용해야 합니다. 스타트업은 복지나 근무 환경이 열악할 수 있습니다.  구글, 페이스북과 같은 멋 드러진 회사 오피스에서 자유분방한 분위기 만을 생각한다면, 얼른 환상에서 벗어 나와야 합니다.   물론, 시키는 일보다 스스로 해야 하는 일이 스타트업에서 많을 수 잇습니다.  마냥 좋아할 일은 아니지요.  그만큼 본인에게 책임감이 주어지는 거니깐요.  물론, 일 못한다고 시말서까지 쓰진 않지만, 무조건적인 비판 보다는 문제의식을 가지고, 본인의 능력 안에 개선할 수 있는 것 작은 것부터 해치우려는 태도가 정말 중요합니다.  이 태도가 지원자에겐 보이지 않는다면, 합격 카드를 주기가 힘들 것이고,  이 태도가 지금 함께 일하는 직원에게서 보이지 않는다면, 그 회사는 고심이 클 수 밖에 없습니다. 그래서 이런 기본 자세가 없으면 스타트업에서는, 직원 스스로도 만족스러운 성과를 내기 힘들고, 회사에 나오는 게 점점 힘들어질 수 밖에 없습니다.  회사 또한, 안 그래도 의기투합해도 모자랄 판에, 엔진 동력에 한 부분이 모자르니 성장이 더딜 수 밖에 없습니다.  ▷면접 절차면접에 정해진 방식은 없지만, 넷뱅은 기본적으로 서류 전형을 통과한 지원자를 대상으로 전화면접, 사전과제 순으로 진행하며 대면 면접은 실무면접, CEO면접으로 구성되어 있습니다.  사전과제는 직군에 따라, 문제가 다릅니다.  때론 실기, 때로는 필기 과제가 주어집니다.   여기서 진짜로 걸러지는 건, 서류전형이 아니라 사전과제입니다. 경력이나 전공이 직무에 적합하면 서류전형 통과는 비교적 관대합니다.  어디 가서 우리 회사 면접 쉬웠다고 말하고 다니는 사람은 아마 최종문턱에도 못간 분들일거에요.  사전과제 제출여부에 따라, 회사 차원에서는 이 지원자가 진심으로 회사에 관심이 있는지의 의지를 확인할 수 있습니다.  사전과제 질문에 어떤 답변을 썼는지는 그 다음 중요도인거죠.  넷뱅의 경우, 오픈북 형태이더라도 생각의 로직을 묻는 질문이 많기 때문에 지원자의 실제 업무 지식이 어느 정도인지를 파악할 수 있습니다.  말만 거창하게 쓰고, 속 알맹이는 없을 수도 있고, 비록 전문용어는 없더라도 문액에 생각의 흐름이 읽혀지는 답변도 있으니까요. 직군에 따라 실무면접 시 팀 및 그룹면접을 진행하는 경우도 간혹 있습니다. 면접 결과는 보통 3에서 7일 이내, 최대 2주일 이내에 알려드립니다.  최종합격자에 한해 결과를 통보해드리고 있습니다. 넷뱅이란 회사에 관심을 갖고 계신 분들께 힌트를 드리자면,  홍보마케팅 분야는 계속 수시채용을 진행하고 있으니 비록, 채용이 마감됐더라도, 이력서를 보내면 즉시 채용담당자가 확인합니다. 늦어도 1주일 이내로 회신을 드리니 주저 마시고 지원하는 것을 장려하고 싶네요. #넷뱅 #스타트업 #스타트업취업 #스타트업채용 #면접후기 #후기 #경험공유
조회수 2068

1 Personality Trait Steve Jobs Always Looked for When Hiring for Apple

애플의 초창기 시절부터, 스티브 잡스는 회사를 성공적으로 만들고 싶어했다. 한 때 애플은 회사 외부로부터 “전문적인” 경영자들을 데려왔었지만, 잡스는 곧바로 그들을 해고해 버렸다.“그들의 방식은 전혀 먹히지 않았습니다.” 유튜브에서 볼 수 있는 젊은 시절의 스티브 잡스가 한 말이다. “그들 중 대부분은 멍청이에요. 관리만 할 줄 알지 다른 건 아무것도 할 줄 모르죠.”잡스의 경영 방식을 다룬 이 비디오는 최근 Quartz at Work라는 웹사이트에 의해 재조명되었다. 비록 이 영상의 잡스는 아직 그의 상징인 검은 터틀넥을 입기 전이지만, 애플 창립자로써 그의 인사이트는 세월이 지났음에도 가치가 있는 것이다.전문 경영인들을 쓰지 않기로 선언한 이후, 잡스는 그간 경영자들에게 요구되지 않던 색다른 자질을 가진 사람을 찾기 시작했다. 그 자질은 바로 열정이었다.“우리가 바라는 사람들은 자신의 분야에서 미친듯이 뛰어난 사람입니다. 꼭 그들이 경험 많은 전문가들일 필요는 없죠. 다만 자기 분야에 대해 열정이 있고 최신기술에 대한 이해력, 그리고 그 기술들로 뭘 할 수 있을지를 알고만 있으면 되는 겁니다.”잡스는 화려한 이력서나 경력 같은 것들을 신경 쓰지 않았다. 열정 있고 문제를 해결할 능력만 있으면 됐던 것이었다. 전문 경영인을 해고한 그 자리에, 잡스는 경영과는 관계 없는 부서에서 일하던 Debi Coleman을 그 자리에 앉혔다. 그녀는 영문학을 전공한 32살의 경험 없는 직원이었다(우연히도, 영문학은 마크 큐번이 예상한 앞으로 가장 가치 있을 전공 중에 하나이다). 그리고 이러한 채용 방식은 통했다. 애플의 제조 담당자로 일하고 난 다음, Coleman은 불과 35살의 나이에 애플의 CFO가 되었다.잡스가 계속해서 설명하길, 뛰어난 직원일수록 ‘관리’ 해 줄 필요가 없다고 한다. 만약 그들이 열정 넘치고, 똑똑하고 동기가 충분하다면, 그들은 스스로를 ‘관리’ 할 수 있다는 것이다. 물론 그러기 위해선 직원들이 회사의 비전에 대해 완벽하게 이해하는 것이 필요하다.그때야말로, “관리” 라는 것이 역할을 할 때인 것이다. 직원들에게 일일이 할 일을 지시하는 대신에, 모두에게 비전을 명확하게 보여줘서 그들이 같은 목표를 향해 일할 수 있도록 만드는 것이야말로 진정한 리더십이라고 잡스는 믿고 있다.비디오의 후반부를 보면, 초기 애플의 직원들이 신입사원 면접을 맡아볼 때 지원자들의 열정을 확인하는 방법이 나온다. Andy Hertzfeld는, 애플 초창기부터 함께해 온 소프트웨어 엔지니어인데, 그가 말하길 그들 면접팀은 일부러 지원자들에게 매킨토시 프로토타입을 보여 준다고 한다. 그리고 그들이 어떻게 반응하는 지를 지켜본다는 것이다. 만약 지원자가 별다른 반응이 없다면, 그는 아마 채용될 가능성이 적을 것이다.“우리는 그들의 눈이 반짝반짝 빛나며 흥분하는 모습을 보고 싶은 거에요. 그제서야 ‘이 사람도 우리랑 같구나’ 라는 것을 알게 되니까요.”원문 : https://www.inc.com/betsy-mikel/to-hire-all-star-employees-steve-jobs-looked-for-1-non-negotiable-quality.html#더팀스 #THETEAMS #애플 #스티브잡스 #인사이트
조회수 1217

어제의 실수는 오늘의 노하우!

Overview서비스되는 프로젝트에 첫 커밋(Commit)했던 순간이 아직도 생생합니다. 직원이 10명 남짓이던 시절, 특정 데이터를 삭제할 때나 쓰던 관리자 페이지였는데요. 당시엔 MVC Pattern, Transaction 등 아무것도 몰랐기 때문에 실수를 반복했습니다. (팀장님으로부터 피드백도 많이 받았죠.) 어떤 실수였는지 궁금하시죠? 오늘은 두 번 다시 겪고 싶지 않은 실수들과 깨달은 몇 가지 이야기와 개발자가 꼭 지켜야할 것을 소개하겠습니다. 사용자를 생각하는 마음예전에는 로직을 짤 때 실패하는 케이스를 깊게 생각하지 않았습니다. 왜냐하면 “나는 기능을 만들고, 사용자는 내가 만든 기능을 쓴다.”고 생각했기 때문입니다. 요구 사항대로 동작하게 만들고, 예외 케이스는 사용자의 책임으로 돌렸습니다. 하지만 이런 태도로 개발하면 UI/UX는 발전할 수 없고, 서비스도 개선될 수 없으며, 사용자의 불만만 생긴다는 걸 곧 알게 되었죠. 작년 이맘때쯤 브랜디 앱에 진열될 상품 관리 페이지를 개발했습니다. 요건에 기재된 내용을 요약하면 아래와 같았습니다.제시된 요건등록 가능한 상품의 개수는 ‘무제한’이다.하나의 페이지에 여러 구좌를 관리하는 영역이 들어갔으면 좋겠다.상품 조회 화면에는 ‘누적 판매량’과 ‘7일 판매량’ 항목이 추가되어야 한다.우선 ‘무제한’이라는 단어에 각 관리 영역마다 max-height를 지정했는데요. 여러 관리 영역이 하나의 페이지에 들어가더라도 스크롤을 많이 하지 않아도 되게 작업했습니다. 이뿐만이 아닙니다. 중복된 상품을 등록할 수도 있기 때문에 그것에 대한 유효성도 추가했죠. 하지만 막상 프로덕션(production)에 배포되니 직원들의 피드백이 쏟아졌습니다.“상품을 등록하고 다시 관리 페이지에 진입하려니 시간이 오래 걸려요.”“상품이 중복됐다고 alert이 뜨는데 어떤 상품이 겹치는지 알 수는 없나요? 혹시… 일일이 찾아야 해요?” 2)“상품 setting 후에 등록을 했는데 다시 보니 안 되어있어요!”“아뿔싸, ’무제한’이라는 단어를 보고 max-height 값만 떠올리다니!” 드러난 이슈들을 수정하면서 반성하고 또 반성했습니다. 등록된 상품들을 가져와서 페이지에 렌더링(rendering)할 때, 상품 수가 많을수록 뷰 페이지의 로딩 속도는 느려진다는 걸 예측하지 않았습니다. 심지어 하나의 페이지에 여러 구좌를 관리할 수 있도록 개발했으니, 불러와야 할 상품은 수백, 수천 개였을 겁니다. 직원들은 하염없이 페이지만 바라보며 불만을 터트릴 수밖에 없었고요. 이후엔 페이지에 진입하자마자 상품 목록을 가져오지 않고, 특정 버튼을 눌렀을 때 ajax로 상품을 로딩하는 방식으로 개선했습니다.당시 개발했던 진열 관리 화면상품 등록이 잘 안 된다는 이슈는 로컬(local) 및 스테이징(staging) 서버에서 재현되지 않아 고개를 갸웃거렸는데요. 프로덕션(production) 정보를 보고 나서야 원인을 잡을 수 있었습니다. ajax를 이용해 POST로 전송할 수 있는 array의 최대 사이즈가 정해져 있다는 걸 알게 된 것이죠.1) 결국 JSON 형태로 바꾸어 데이터를 전송하고, 서버사이드에서 배열을 다시 변환해 로직을 수행하도록 개선했습니다. 팀장님의 질문도 기억에 남습니다. 팀장님은 단호하게 물었죠.“쿼리 돌아가는 건 확인했어?”일정이 급급하다는 이유로 쿼리를 확인하는 과정을 간과했습니다. 데이터는 당연히 0건으로 나왔지만 조건에 부합하는 데이터가 없어서인지, 잘못된 질의 때문인지는 의심하지 않았던 것이죠. 팀장님은 말했습니다.“네가 자꾸 실수하면 사용자는 우리 시스템을 신뢰할 수 없을 거야.”PRODUCT_REGIST_DATETIME BETWEEN NOW() AND NOW() - 7 나 : 7일동안 등록된 상품 데이터를 가져와주세요.데이터베이스 : …???주위를 관심 있게 둘러보는 눈지난 번에 쓴 신입개발자를 위한 코드의 정석을 보면 ‘모든 개발조직은 좋은 품질의 소프트웨어를 개발할 수 있는 개발자를 원한다’는 문장이 있습니다. 좋은 품질과 가치 있는 서비스를 만드는 건 개발자가 당연히 가져야 할 책임과 소신입니다. 서비스에 대한 이해도 어느 정도 필요하고요. 그렇지 않으면 엉뚱한 서비스가 나옵니다.재작년, 브랜디 커머스 웹 1.0 버전을 개발했을 땐 e-commerce에 대한 이해도가 거의 없었습니다. 유사한 서비스들의 레퍼런스를 진행하고 개발을 시작해야 했는데 그저 상상력에 의존한 채 UI/UX 개발을 진행했었습니다. 그때 느꼈던 걸 몇 가지 정리해보겠습니다. 유사한 서비스를 적극적으로 사용하자!사람들은 많이 쓰는 서비스의 UI/UX에 익숙합니다. 그러므로 유명하면서도 비슷한 목적을 수행하는 다른 서비스들을 사용해보세요. 그 분야에 대한 센스가 무럭무럭 커질 겁니다. 더 나아가서는 사람들이 익숙하다고 느끼는 것보다 훨씬 더 편한 UI/UX를 떠올릴 수도 있겠지요!다른 개발자의 생각도 물어보자!같은 문장을 보고도 다르게 해석하듯, 같은 서비스를 개발하는 개발자들도 저마다 솔루션은 다릅니다. 자신은 괜찮다고 생각하더라도 다른 개발자에게 꼭 물어보세요. 미처 생각하지 못했던 의견들이 나올 수 있습니다. 즉, 많은 커뮤니케이션이 더 좋은 개발을 돕는 것이죠.개발하기 쉬운 서비스 말고, 사용자가 쓰기 편한 서비스로 만들자!일정에 쫓기면 당장 개발하기 편한 방법을 선호할 수도 있습니다. 개발자의 주관적인 판단이 UI/UX를 망칠 수 있는데도 말이죠. 실수는 자신이 만회해야 합니다. 눈앞의 것을 생각하지 말고, 사용자를 생각하며 개발합시다. 사용자가 기분 좋게 서비스를 이용하는 게 훨씬 뿌듯하잖아요. Conclusion무수한 실패담 중에 기억나는 몇 가지만 추렸습니다. 과거의 코드나 실수의 이력들을 글로 써 보니 ‘전부 내 경험이 되었구나’라는 생각이 듭니다. 지금 이 글을 읽고 있는 당신은 어떤 실수를 해보셨나요? 손해 보는 경험은 없습니다. 분명 언젠가는 도움이 될 거예요. 주석1)이 때문에 상품을 등록할 때, 스크립트에서 array로 담아 전송하면 데이터가 누락되어 제대로 등록되지 않거나 에러가 발생할 수 있는 결함이 있었다.2)중복된 상품을 화면에 표시해주는 기능은 여러 상황으로 인해 개선하지 못했다. 이후에는 발생하는 문제의 사유를 사용자에게 친절히 알려주어서 원하는 결과를 얻도록 힘쓰고 있다. 참고개발자는 개발만 잘하면 된다?사용자는 결코 실수하지 않는다글김우경 대리 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유
조회수 1377

데일리호텔에 리뷰 노출하기

Background현재 데일리호텔의 업장(호텔 또는 레스토랑) 상세화면에서 실제 이용자 중 몇퍼센트가 이용에 만족하였는지를 보여줍니다. 이는 사용자들이 구매를 결정하는데에 중요한 요소가 됩니다.AS-IS 만족도 표시사용자들이 실제로 작성한 리뷰를 볼 수는 없습니다.이는 데일리호텔의 쉽고 간단한 예약서비스의 컨셉에서 비롯된 정책이었습니다. 사용자가 리뷰 내용을 하나하나 보는 수고를 덜고, 확실한 측정 결과(만족도)를 제시하여 고민하는 시간을 줄여주고자 했습니다.서비스 규모가 커짐에 따라, 리뷰를 꼭 읽어보고싶어하는 적극적인 유저가 많아지고, 비교적 고가의 지출에 대한 근거를 제시해야 하는 니즈가 커지고 있습니다. 이를 최대한 만족시킬 수 있도록, 점진적으로 리뷰시스템을 구축하여 리뷰를 앱에 노출시키고 고도화할 예정입니다.Insights1. 63% 유저는 리뷰를 읽고 제품을 구매 한다.2. 50개의 리뷰는 CVR을 4.6% 상승시킬수 있다.3. 구매자는 공급자의 상품 설명보다 리뷰 내용을 더 신뢰한다.4. 평가 점수 보다는 리뷰의 텍스트 내용이 중요하다.5. 나쁜 리뷰가 나쁜 것만은 아니다. — 서비스 개선의 기회가 될 수 있다.출처:https://conversionxl.com/user-generated-reviews/https://www.groovehq.com/support/deal-with-bad-online-reviewsPurpose & Mission우리는 리뷰 노출에 앞서, 리뷰 작성 화면을 정비하기로 하였습니다. ‘리뷰의 질과 양 늘리기’라는 목표를 가지고 아래 세가지 기준에 맞추어 개선하기로 하였습니다.Before 리뷰 작성 화면리뷰 항목을 정량 분석할 수 있도록 구조를 변경하여, 리뷰 결과를 데이터화 할 수 있도록 함텍스트 리뷰 입력을 지금보다 많이 받을 수 있도록 함유저가 리뷰를 입력할 수 있는 기회를 보다 많이 부여함리뷰의 질을 높이고자 하니 리뷰 항목이 많아졌고, 필수 입력 처리로 리뷰 완료까지의 조건이 까다로워졌습니다. 이에 따라 최대한 많은 양의 리뷰(텍스트 리뷰 포함)를 받는 것이 중요한 과제가 되었습니다. 이 과제의 포인트는 유저가 리뷰 작성팝업을 접했을 때의 거부감을 줄이고, 리뷰를 끝까지 작성하도록 encourage하는 것이었습니다.Action Items먼저, flow에 대해 많은 고민을 하였습니다. 매 항목 선택 후 화면이동을 할 것인가, 한 화면에서 스크롤하여 모든 항목을 선택하게 할 것인가를 두고 프로토타입을 만들어 사내 유저 테스트를 진행하기도 하였습니다.Flow AB Test그리고 유저의 감성을 자극하는 컴포넌트로 유저의 참여를 유도하였습니다. 귀여운 이모티콘 디자인에 애니메이션과 인터랙션까지 더하여 재미요소를 부여했습니다.<meta charset="utf-8">GUI & Animation+Interaction리뷰 입력 시에는 상황에 맞는 피드백을 제공하여, ‘리뷰가 곧 끝나겠지’하는 막연한 기대와 실망을 최소화하고자 했습니다.FeedbacksResults아직 확실한 결과를 보기에는 기간이 충분히 지나지 않았지만, 텍스트 리뷰까지 입력하는 유저의 비율이 어느정도 늘어나고 있는 것 같습니다. 강제 업데이트를 하지 않았고, 아직은 구/신 버전의 UI가 동시에 노출되고 있습니다.텍스트 입력까지 모두 완료한 유저 비율 변화 (만족도 입력 대비/전체 리뷰 입력 대상 대비)기대했던 결과가 나오는 것도 중요하지만, 그 결과를 기반으로 또 다른 개선을 이끌어내고 조금씩(그리고 계속) 이전보다 나아지는 것이 더욱 중요할 것입니다.끝. 디자인 관점에서 계속...#데일리 #데일리호텔 #기획 #기획자 #개발 #개발자 #인사이트 #후기 #일지
조회수 1148

[어반테이스트] 와인과 함께한 곱창싸롱!

"지그므은~~~~ 곱.창.시.대!"(출처) MBC '나 혼자 산다'2018년 동시대를 살고 있는 분이라면 요즘 이 음식을 빼놓을 수가 없죠.바로바로 '곱창'먹어도 먹어도 질리지 않고,생각할수록 설레이는 음식이에요 ><어반테이스트라는 맛집탐방 복지문화가 시작되고 '왜 곱창 먹고 오신 분이 없을까....'의문이 들던 찰나에!드.디.어. 곱창 테이스트를 즐긴 팀이 생겼어요! 곱창 맛집 썰을 풀기 전에 잠깐! 곱창 지식 좀 풀고 가실게요 <알면 쓸데 있는 곱창지식>(출처) doopedia.co.kr곱창은 소의 작은 창자 즉 소창을 말하는데 보통 소의 내장을 통틀어 이야기 한대요!왼쪽에서부터 순서대로 양깃머리, 벌양, 간/처녑, 막창(홍창)왼쪽부터 곱창, 대창첫 번째 위가 양, 두 번째 위가 벌양, 세 번째 위가 처녑, 마지막 위를 막창이라고 하고, 위 다음에 연결된 소장과 대장을 각각 소창, 대창이라고 해요!식당에서 양곱창이라고 하는 것은 양(羊)의 곱창이 아니라 첫 번째 위인 양을 의미합니다. [양깃머리]양깃머리(특양)는 양에서도 두툼한 부위로 여러 내장들 중 가장 비싸고 주로 구이용으로 사용합니다. 소 한마리에서 나오는 특양 부위의 양이 많지 않아서 가격이 비싸다는....기름기가 없는 담백한 맛이고 기름진 대창과 잘 어울려서 양대창으로 묶어 부르기도 한대요. [벌양]벌양은 벌집양이라고 불리고 모양이 벌집(honey comb)을 닮아서 그렇게 이름을 붙였대요. [처녑]세 번째 위인 처녑은 1000장의 잎사위가 붙어있는 모습이라 천엽(千葉)이라고 부르기도 한대요. 구이용으로 거의 사용하지 않고 주로 간과 함께 생으로 먹는다고 합니다.저희도 애피타이져로 모둠 구이가 익는 동안 간과 처녑을 먹었지용~[막창]막창은 소의 마지막 위로 홍창이라고도 불리고 대구지역에서 유명합니다. [대창]소창 다음에 연결된 것으 좀 더 굵은 대창입니다. 원래 모습이 바깟쪽에 기름이 달려 있는데 그것을 뒤집어 안쪽으로 넣은 것입니다. 대창의 기름은 콜레스테롤 수치를 올리므로 많이 먹으면 건강에 좋지 않습니다만, 너무 고소하고 부드럽고 맛 있어서 일단 고민하지 말고 먹읍..시다![염통]염통은 심장을 말하고  가장 빨리 익기 때문에 먼저 먹어야 합니다!★ 먹는 순서 ★간, 천엽 -> 염통 -> 벌양, 양 -> 대창 -> 막창, 소창(참고) http://egloos.zum.com/hsong/v/3163122)그럼 어느정도 지식을 습득했으니이제 곱창 먹방 후기를 풀도록 하겠습니다 :) "와인과 함께한 곱창싸롱!"- 영업시간: 00시~24시 - 주소: 서울 강남구 언주로93길 31 (지번: 역삼동 677-1)  곱창싸롱 <지도보기>이번 테이스트는 역삼역 곱창 맛집 '곱창싸롱'이에요 !곱창 테이스트 멤버는 개발팀의 현목님, 종훈님과 CRO 강록님입니다!팀 결성 후 퇴근시간에 맞춰회사에서 5분거리에 있는 곱창싸롱을 갔습니다!"아 신난다~ 이 지역 곱창 몬스터는 내가 다 잡아야지~""우리 저기를 향해 갈꺼에요~"드디어 입성! 할렐루야!이것은 곱창싸롱의 메뉴입니다!모둠구이 200g (곱창+대창+막창+염통) --- 1.6만곱창 200g 1.8만막창 200g 1.6만대창 200g 1.6만특양 150g 1.9만염통 200g 1.2만깍양밥 1인분 1.2만(깍두기+특양+비빔양념+계란크러스트)이외에도곱창전골 1.2만올치다다 1.0만등의 메뉴가 있어요!저희 어반 테이스트 4기가 공략한 메뉴는 모듬구이와 깍양밥!모둠구이 3인분가운데 돌돌 말린 것부터 반시계방향으로 곱창, 대창, 염통, 막창이여요 :)물론 오발탄, 연타발 등 비싼 곱창집에 비해선 퀄리티가 좋진 않지만 그래도 저렴한 가격치곤 제법 맛있었어요 ㅎㅎ간과 천엽! 기름장에 찍어먹으면~~ 츄릅!곱창집에서 올리브를??여기는 그린, 블랙 올리브를 허브와 오일에 살짝 볶아서 나오는 것 같아요! 독특한 향이 납니다~~~~~기본으로 세팅할 때 한번 주시고 원하면 추가로 주문해야 할 것 같아요. 따로 메뉴가 있네요. 강록님이 대파 양념을 첨가하여 요리를 하신 맛나보이는 곱창 대파구이~깍양밥 1인분 /  12,000원 볶음밥류 치고는 비싼편이지만 요거요거 맛있었어요!곱창싸롱은와인을 가져가면 인당 5천원의 와인콜키지로 맛있는 곱창과 와인을 즐길 수 있습니다!테이블에 앉아서 먹을 수도 있고, 양철통 위의 스텐리스 테이블에서도 스툴에 앉아 먹을 수 있어요~그래서 현목님이 이날 와인을 준비해 오셨다는.. ㅋㅋㅋ"이거슨 스페인산 마트표 맛난 와인입니다. 3병에 2만원정도로 할인할 때 (집더하기에서) 사왔는데 맛있어요." - 문믈리에Campo Lindo Chrianza 스페인 Rioja 지역 와인. Cabernet Sauvignon, Tempranillo 품종 블랜딩. 2014년 빈티지. 와인과 곱창의 만남! 제법 신선하죠?와인과 곱창의 조합은 처음이었지만 제법 신선하면서 감동적이였습니다 ㅋㅋㅋ우리의 곱창싸롱 점수는?(5점 만점에)곱창싸롱은역삼역 인근 저렴하면서 이색적인 곱창을 즐기고 싶은분에게 추천합니다 :)곱창먹고 행복지수 120%취한거 아닙니다.....다음 '어반 테이스트'도 기대해 주세요 :) 출처: https://blog.naver.com/urbanbaseinc 
조회수 12543

개발자가 이직에 대해 생각할 때...

‘이직’이라는 화두는 샐러리맨에게는 매우 무섭게 다가온다. 평생직장이라는 의미가 사라진 현대 시대에 있어서 직장생활 중에 많이 만나게 되는 단어이다. 더군다나, 소프트웨어 개발자들에게는 매우 일상적으로 발생한다. 그러니, 이직을 너무  두려워하지 말자. 오히려 평소에 이직에 필요한 스킬과 준비를 매우 당연하게 해야 한다.개인적으로 소프트웨어 관련 학과에서는 '이직'과 관련된 커리큘럼을 하나 만들어 두거나. 아니면, 교양과목이라도 있어야 하나 가르쳐야 한다고 생각한다.필자도 여러 기업에 입사하고 이직을 고민하는 과정을 똑같이 경험했다. 더 큰 경험으로는 기업을 창업하고 직원을 채용하고, 퇴사하는 과정도 같이 경험했다. 돌이켜 생각해 보면 직원의 입장과 중간관리자의 입장, 경영진과 최고 경영진의 입장에서의 ‘이직’을 바라보는 관점이 정말 매우 다르다.이번 이야기에서는 이런 ‘이직’의 관점을 ‘소프트웨어 개발자’의 입장에서  이야기해보자.이직이란 단어는 언제 만나게 될까? 이직이라는 단어를 머릿속에 떠올리게 되면서 당연하게 고민할 것이다. 더 좋은 조건을 제시하는 회사로 자리를 옮기거나, 또는. 현재 있는 직장에서 하는 일이 마음에 들지 않거나, 특정한 사람이나 환경 때문에도 이직이라는 단어는 언제나 떠올릴 수 있다.소프트웨어 개발자들이 이직을 고민하고  생각할 때에 어떤 부분들을 고민하고 생각해야 하는지 알아보자. 물론, 이번 이야가의 내용은 전적으로 필자의 주관적인 경험을 바탕으로 만들어진 내용들이기 때문에 매우 주관적이라는 것을 먼저 이야기해야겠다.다만, 작지 않은 경험을 적은 기업의 신입직원이었을 때부터, 벤처기업의 CEO, 중견기업의 CIO의 역할을 해보고 느낀 점 들을 몇 가지 정리하여 본 것이다.자, 이 글을 읽는 독자들은 ‘이직’을 고민하는가?혹은 이직이라는 단어에 대해서 어떻게 생각하는가?일단, 직장은 너무 쉽게 바꾸거나, 특정한 이유에 너무 집착하여, 너무 쉽게 결정하지 않기를 바란다. 일반적으로 한 회사에서 정년퇴직한다는 전설을 만난다는 것은 이제 거의 불가능에 가깝다. ( 필자역시, 딱 한사람 만났다. )소프트웨어 개발자들은 한 회사에 오래 근무할 수 있는 여건이 되는 사람들은 매우 극소수에 해당된다고 생각해야 한다. 대부분은 프로젝트가 종료되거나 의미가 없어지면서 이직에 대해서 고민을 시작 하게 된다.너무도 자주 만나게 되는 이 단어에 대해서 사람들마다 각자의 의미와 나름대로의 기준점을 잡아두는 것이 매우 좋다고 설명하겠다. 각자 자신이 걸어가야 할 로드맵이나 기본적인 원칙을 한, 두 가지쯤은 정해 두는 것이 좋다. 이 기준은 정말, 개인적인 기준들이다. 이 기준을 각자 가져야 한다.필자의 경우에는 초보때에 세웠던 원칙이 몇 가지 있었고, 나름 경험이 많아지면서  이러한 원칙들은 조금씩 그 기준을  추가하게 된다. 필자의 사례를 들어보자필자는 가장 먼저 사회생활 초년병의 시작을 병역특례로 시작하였다. 그래도. 나름 기준은 있었다. 그것은 앞으로 소프트웨어 개발일을 계속하기 위해서 내가 어떤 기준으로 회사를 찾아야 하는가에 대한 것이었다. 내가 세운 대원칙은 딱 하나였다. 하드웨어 작업을 병행하는 일을 한다는 것을 원칙으로 했다.그래서, 선택한 기업에서 처음 내게 할당된 일은 Z80으로 음성보드를 만들고, 적외선 센서로 터치스크린을 만드는 파트에서 Z80과 i8051의 크로스 어셈블리로 프로그래밍하는 일이었다. 내가 세운 큰 대원칙에는 맞는 일이었고, 일 자체에 대해서도 매우 큰 매력을 가졌다.하지만, 그 업체에서 병역특례 일을 하다가 부당한 노동현장(?)의 부조리를 맞이 하게 되면서 회사를 그만두게 됐다. 그 당시 얻은 경험 중의 하나는 ‘부조리한 노동현장’은 빨리 떠나라는 개인적인 원칙도 세웠다. 그 기준은 나중에 기업을 운영하면서도 가장 부끄러워할 경영진의 몫이라는 것을 인지하게 된 것도 가장 큰 경험이었다고 하겠다. ( 이런 경험은 차라리 초보나 신입 때에 경험하는 것이 그나마 불행 중 다행이며, 사회의 쓴맛을 제대로 보았다고 하겠다. 무료 법률상 담도 해보았고, 노무담당 문의도 해봤다. )그 후에 경력직 프로그래머로써 제대로 된 취업을 할 때에도 나름대로 원칙을 세웠다.병역특례 일을 하다가 그만두고 군대를 다녀왔을 당시에는 윈도우즈 애플리케이션의 개발이 매우 어렵던 시절이었기 때문에 나름 몸값을 요구할 수 있었다. 그래서, 프로그래밍을 하는 데 있어서 조금은 특이한 솔루션을 활용하는 경험을 하고 싶었고 그것을 중요한 원칙으로 삼았다.당시에 선택할 수 있는 기업은 3곳이었다. 하나는 용산 근처의 게임 개발사. 건대 부근의 한국전력에 소프트웨어를 개발해서 판매하던 회사, 그리고. 하나는 건축 소프트웨어 개발을 하는데 Auto-Cad의 ARX아키텍처 기반의 프로그래밍과 윈도즈 개발을 하는 일이었다.3군데의 회사에 면접이 다 통과된 이후에 고민하였다. 가장 적극적이었던 회사는 게임회사였다. 지금 기억으로도 90년대 중반에 팔레트 애니메이션을 능숙하게 조작하는 내 스킬을 보고 매우 탐을 내었던 게임업체의 사장이 기억난다. 그 먼 거리에서 인천의 집까지 나를 태워다 주면서, 같이 일하자고 차를 타고 오는 도중에 많은 이야기를 나누면서, 같이 일하자고 설득했다.하지만, 결정적으로 그 당시에 결혼을 한 필자의 입장에서는 ‘급여’가 가장 큰 걸림돌이었다. 전혀 엉뚱하게도 ‘급여’를 가장 많이 준다는 ‘회사’를 선택했다. 바로, 건축 소프트웨어 개발회사였다. ( 당연하지만, ‘급여’는 언제나 샐러리맨에게는 최고의 선택 기준이 될 것이다. )아마도, 필자가 그 당시에 급여는 매우 적지만, 그 게임업체에 들어갔다면 운명이 매우 많이 바뀌었을 것으로 생각한다. 당시, 병역특례를 하다가 군대를 다녀오면서 네트워크 프로그래밍에 대한 스킬까지 겸비한 필자가 게임업계로 들어갔으면 나름 재미있는 미래가  진행되지 않았을까 한다.하지만, 그래도 그 당시에 급여도 나름 가장 많았지만. 최고의 선택 기준은 ‘독특한 기술’에 대한 호기심이었다. 더군다나, 윈도즈 개발자로서 나름 이름을 알리기 시작하던 시기였기 때문에 필자의 선택은 옳았다고 생각한다.이때 중요한 화두는 ‘급여’와 ‘윈도즈 개발환경’, ‘독특한 콘셉트’이었다. 당시, 그 회사는 AutoCad에서 동작되는 한글 소프트웨어와 설계용 지원 유틸리티를 개발하는 업체였기 때문에, 선배 개발자들과의 경험이 매우 좋았다. 선배 개발자와 개발실장으로 계시는 분들이 20대 중반이었던 필자를 매우 아껴주었던 기억이 난다.최소한 그 계통에서 5년 이상 일을 했던 선배들이 몇 분 계셨고,  그분들에게 생각보다 많은 것을 얻을 수 있었다. 정말, 훌륭한 선배들은 언제나 초보와 신입들에게는 큰 도움이 된다.필자가 신입시절에 크게 결정한 것은 ‘장래성’도 아니고, 오히려 찾은 것은 ‘독특한 개발’을 경험할 수 있는 환경을 찾았고. 그것은 또 하나, 새로운 개발환경을 초기서부터 세팅하는 것도 포함되어 있었다.‘개발자가 이직을 결정해야 할 때’는 언제 인가하고 후배들이 가끔 질문을 해오거나 자문을 구해올 때가 있다. 그렇다면, 소프트웨어 개발자가 이직을 생각하는 때에 대해서 어떤 것을 고민해야 하고, 이직을 결정하기 위하여 중요한 사항은 어떤 것이 있을까?물론, 이직은 모든 분야에서 공통적으로 발생하는 요소이기 때문에 전부를 이야기할 수 없겠지만, 가장 좋은 이직이란 무엇인지 필자의 경험을 중심으로 이야기해보자. 다음에 나열하는 요소들은 ‘이직’을 고민하게 될 가장 큰 가능성을 가지고 있다.첫째. 자신의 전문성에 대해서 고민하기 시작할 때...보통은 자기계발에 충실한 사람의 경우에 자신이 제대로 된 전문성을 확보하고 있는지에 대해서 의문점이 생기는 시점에 '이직'을 고민하게 된다. 이 일을  계속하는 것이 미래에 ‘전문성’을 가질 수 있느냐에 대해서 의문을 가지기 시작할  때부터이다.둘째. 조직원들 간에 트러블이 발생하거나, 말도 안 되는 상사의 권위에 질렸을 때이 부분은 일반 직장과 동일하다. 아무리 전문성이 보장되고, 일이 괜찮다고 하더라도. 동료들과의 문제가 발생되는 부분은 어느 직종이나 동일하다.필자는 소프트웨어 개발일을 하면서도 벤처기업의 경영진 역할과, 중견병원그룹의 CIO생활을 하면서 다양한 직종의 사람들과 일을 해보고 인사권을 가지고 있었지만. 모두 동일하게 문제가 발생하는 것은 ‘직원들’ 간의 문제나, 중간 관리자의 전횡 등이 가장 큰 이유가 되었다.셋째. 프로젝트가 종료되었을 때에생각보다 하나의 프로젝트가 종료되면서, 소프트웨어 품질이나 개발에 대한 연속성이 제대로 이어지지 않는 경우에는 이직을 생각하게 된다.재미있고 즐거운 개발을 필자가 주창하는 이유 중의 하나가 이러한 ‘프로젝트 종료’ 시의 이직에 대한 고민을 하지 않기 위해서이다. 하지만, 대부분의 프로젝트들은 실패하거나 어려움을 겪는 경우가 다반사이기 때문에, 프로젝트가 종료될 때에 이런 충동을 느끼게 된다.이상 3가지의 기본적인 이슈들은 직장생활을 하면서 매번 만나게 되는 고민이고. 3가지의 고민이 모두 발생한다면, 당연하게 ‘이직’을 오히려 권해야 할 사항이 될 것이다.자, 이직에 대해서 고민하고, ‘이직’을 결정하였다면, ‘미련’없이 ‘이직’을 준비하자.‘이직’을 준비하는 것에 있어서 가장 중요한 것은 옮겨갈 회사를 잘 고르는 것이 가장 큰 것이다. 그리고. 퇴사를 하는 회사의 경우에는 최소한 1개월 정도의 업무 인수인계 작업은 당연하게 고려하자. 물론, 제대로 된 체계가 있는 회사는 당연하지만, 직원들의 이직 프로세스가 잘 잡혀있기 때문에 너무 걱정할 필요 없다.대부분의 조직은 누구 한 사람이 나간다고 하더라도, 그 프로젝트가 잘못되는 경우는 거의 없다. 그냥, 본인의 마음이 떠난다면 ‘이직’을 진행하는 것이 맞을 것이다.너무 걱정하지 말고 이직을 결심하고 진행하라고 조언하고 싶다.다만, 필자는 ‘이직 시에 적합한 회사’를 찾기보다는, ‘이직 시에 안 좋은 회사’를 피하는 방법을 먼저 터득하라고 조언하고 싶다.이직 시에 안 좋은 회사를 피하는 방법개발자들이 이직을 고려하고, 이직을 결심하게 되었을 때에는 신입의 입장과는 매우 다르다. 어느 정도 경력도 생겼고, 일에 대한 경험도 풍부해지고, 나이도 한두 살 더 먹었으며, 사람들과의 스킨십이나 커뮤니케이션 능력도 좋아지기 시작하는 시기가 된다.또한, 과거에는 ‘취업’과 ‘작은 목표’가 중요하였지만, 이제는 같이 일할 동료들에 대해서도 생각하게 되고, 일하는 회사의 비전이나 다른 부분들도 같이 고님할 것이다. 이런 어느 정도의 경험과 시야가 생겼을 때에 ‘이직 시에 좋지 않은 회사’를 골라내는 방법은 어떤 것들이 있을까?필자의 경험으로는  다음의 사항들을 고려하여 ‘이직’하려는 회사들을 평가했다.하나. 고급 개발자가 있는가?회사의 CTO나 개발실장이 고급 개발자이며, 그 분야의 '구루'급에 해당되는 사람인가? 존재한다면,  그분들이 회사 내부에서 '존경'받으며, '대우'를 받고 있는지 확인해보라. 그 회사에서 꾸준하게 엔지니어로 성장한다면..  그분들과 같은 대우를 받을 수 있는 인사 환경을 갖추고 있는지 확인하면 된다.대부분 허접한 회사이거나 일반 기업체에서 전산실의 역할이 부실한 경우라면 IT기술을 최고로 습득해도 계장 이상 올라갈 수 없는 곳이라면, IT기술을 중요시하는 기업이 아니라는 것이다. 이런 경우에는 '직장인'으로써의 비전만을 따지면 된다. ( 정치적인 것이 아니면, 급여, 복지일 것이다. )'개발자'로써의 삶이나 목표, 비전과는 전혀 상관없는 기업이기 때문에 일반적인 '직장생활'에 충실한 것이 좋을 것이다. 이와 관련된 처세술이나 비교자료는 인터넷에 많으니 검색해서 참조하자.둘. 개발자들이 오랫동안 근무한 사람들이 있는가?회사가 성장하고 발전하는 과정에서 사람들이 들어오고 나가는 것을 반복한다. 이런 경우에 회사에 오랫동안 근무한 개발자나 엔지니어가 존재하는지 확인해보는 것이 좋다. 대부분 경력이 올라가면 '급여'가 오르게 되고, 이렇게 경험이 풍부한 사람들이 많이 존재하는 개발 조직이나 회사가 발전 가능성이나 시장을 가지고 있는 경우가 많다.하지만, 회사는 충분하게 돈을 벌고 있지만, 회사 경력에 비해서 적은 경력의 개발자들이 2~3년 차들로 대부분 도배되어 있다면, 특정 시점에 직원들이 물갈이가 되거나, 개발자들이 죄다 못 버티고 나간 경우라는 뜻이다.'소프트웨어 개발자'들도 대부분 '직장인'에 가깝다. 이 회사가 정말 좋은 곳이고, 계속 다닐만한 가치가 있는 회사라면. 오래된 개발자들이 많이 있을 것이다. 이런 오래된 개발자가 없는 곳이라면 분명, 인사 문제나 처우에 문제가 있는 회사이다.셋. 사무실의 환경을 살펴라.큰 사무실이건 작은 사무실이건 '실제 일하는 사람들'이 사용하는 '책상'이라면 사용하는 흔적들이 있다. 공간은 있지만, 빈 책상에 사용되지 않는 물품들만 있다면. 인력파견업체가 대부분일 것이고, 처우나 사무실의 환경은 그다지 좋지 않을 것이다.대부분 팀장이고 이사이고 아웃소싱 일을 대부분 하고 있는 사람들일 것이고, 당연하지만, 근로환경도 최악이고, 월급이 때인다던 지, 프로젝트 진행이 개판이 되는 경우가 많다.넷. 신입직원 연수나 트레이닝 프로그램이 있는지 확인하라대부분, 이직 시에 이러한 것들을 고려하지 않는다. 하지만, 대부분의 중소기업이나 대기업들의 경우에 자체적인 솔루션이 있거나 나름 시장 지배력이 있는 회사의 경우에는 ‘사전에 교육’ 해야 할 내용들이 많아진다.당연하지만, 신입직원들에게 짧으면 2주, 길면 4주 이상의 트레이닝 코스가 존재하게 된다. 나름 시장 지배력이 있는 회사라면 이러한 코스가 당연하게 있다. 만일 이러한 코스가 없다면, 해당 기업은 의미 있는 솔루션을 만들거나, 의미 있는 서비스를 하고 있는 회사라고 보기 어렵다.그것은 중소기업들은 대부분 적당한 인력을 구인해서 적당하게 사용한다고 보면 된다.이처럼 소프트웨어 개발자가 이직을 생각할 때에 이러한 조건들도 있지만, 오히려 개발 경력이 3~4년 차를 넘기는 개발자에게 필자가 가장 중요하게 질문하는 것이 있다. ‘소프트웨어 개발이 적성에 맞는가?’라고 묻는다.굳이, 소프트웨어 개발이 아니더라도 자신의 자아실현이나 사회생활이 충분하게 실현되는 경우도 많다. 억지로, 소프트웨어 개발자의 길을  걸어가면서 주변을 괴롭히거나, 오히려. 안 좋은 중간 관리자가 되면서 IT업계의 원흉이 되는 것도 이 시기에 잘못 결정한 선배들이나 후배들도 많다.필자가 만난 여러 후배 개발자 중에는 소프트웨어를 설계하고 만드는 일이 그다지 적성에 맞지 않는 경우도 상당수 있었다. 또는, 저 사람은 아예 소프트웨어 개발을 하지 않았으며 좋겠다는 생각을 하게 된 사람도 있었다. 그래서, 오히려 조언을 하거나 유도를 해서 다른 일을 선택하고 그 길을 잘 걸어가는 후배들도 여럿 있다.하지만, 대한민국의 SI개발에만 있었다면 다른 직종도 가능할까?라는 질문에는 사실, 정답이 없다고  이야기한다. 갑을병정 이무기라고 불리는 먹이사슬의 과정 속에서 SI현장에서 다른 분야로 진출하는 것은 정말 어려운 일이다.대기업이나 중소기업의 SI에 입사해서, 프로젝트 관리자의 길을 걸어가는 사람이 아니라면, 매우 어려운 자리가 될 것이다. 하지만, SI나 SM의 이직 시에도 제대로 된 선택을 하면 매우 수월하고 편안한 자리로 이직을 할 수 있다.실제 후배들 중에는 많은 급여보다는 안정적인 자리를 원하는 도메인이 특화된 SM자리를 잘 차지하고 편안하게 일하는 개발자들도 간혹 발견할 수 있다. 하지만, 그런 환경이 아니라면 필사적으로 이직 시의 조건을 따져봐야 한다.최소한 ‘피해야 할 회사의 조건’을 따져봤다면, 이제는 가장 현실적인 ‘조건’을 나열하여 회사와 조직의 환경을 살펴보자. 다음의 조건들을 살펴봐라.야근수당을 받는가?2015년을 기준으로 나이 30세 초반에 연봉 3000~4000이라면 소프트웨어 개발자로서 만족하는 삶을 살 수 있을까? 하지만, 사회생활에 있어서 야근수당을 받거나 주말에 근무하면 추가 페이를 계산받는가? 냉정하게 계산하고 매일 야근과 주말근무를 하고 있다면, 실질적인 연봉은 무려 5~6000만 원을 받아야 정상이다.필자가 중견그룹의 CIO 역할을 하던 시절에 인사팀에서 가장 많은 경고와 안내를 받았던 것 중의 하나가 '야근'근무를 가능한 하지 않도록 유도하는 안내였다. 야근을 하게 되면 자연스럽게 지출되는 야근을 위한 식사와 연장근로수당, 그리고. 주말까지 일하게 되면 2배를 넘어가는 수당의 지급은 상당히 부담스러웠던 것이기 때문에, 인사팀에서는 이러한 근무를 하지 않도록 유도하는 것이 최선의 방법이었을 것이다.대부분 괜찮은 기업들은 '야근'근무를 유도하지 않는다.단지, 근무조건이 탐나는가?냉정하게 SI는 전문성이 매우 높은 분야인데, 대한민국에서는 그러하지 않고, 거의 막장에 가까운 환경을 가지고 있다. 매우 슬픈 일이다. 일본이나 미국과 같은 선진국에서 근무하는 SI 개발자들의 처우나 근무조건은 매우 좋은 조건들이고, 연봉 또한 매우 높다.제대로 된 SI분야의 경우에는 대체인원이 그렇게 많지 않고, 어느 정도 경력을 가진 개발자로 성장하기 매우 어려운 분야이기 때문에 경력자와 경험자를 매우 우대한다. 하지만, 대한민국의 SI현장은 정말 열악한 환경으로 변화하였고, 그 현장은 매우 절망스러운 곳들도 많다.대한민국의 SI가 이렇게 된 이유에 대해서는 여러 가지 이유와 근거와 설이 존재하는데, 필자가 생각하는 몇 가지 이유는 다음과 같다.하나. 대기업의 전산실에서 분리된 IT조직의 태생적 한계둘. 전산/IT를 제대로 전공으로 한 '선배'들이 실제 부재하다.셋. 대정부의 SI 관련 프로젝트가 갑을병정 프로세스만으로 진행되면서 만들어진 흑역사넷. 소프트웨어 품질을 모르는 PM/PL들이 아직 수두룩하다. ( 이론만 아는 방법론자들 투성이다. )다섯. 책임지는 소프트웨어 개발 조직과 개발인력이 그다지 SI현장에 없다.여섯. 소프트웨어 개발은 '자격증'과 아무 상관없고, 개발 경력과도 그다지 연관성이 없다.그래서, 대한민국의 SI현장은 주변에 잘 수소문하여 ‘괜찮은 곳’을 찾아가는 센스를 발휘하지 못하면, 암흙의 이직을 경험할 수 있다.물론, 이렇게 이야기하는 ‘이직’의 대부분은 ‘스타트업’이나 ‘도전적인’ 기업을 선택하는 것과는 다른 기준들이다. 대부분은 ‘조직’이라는 틀에서 움직이는 ‘작업자’들을 구인하고 그 공간이 나에게 맞는지에 대해서 잘 따져야 하는 것이다.결국, '조직'의 틀로 생각한다면, 일반 샐러리맨의 회사 선택의 기준과 그다지 차이가 없을 것이다.하지만, 소프트웨어 개발자의 세계에서 '이직'을 제대로 할 수 있는 방법은 말 그대로 '스카우트'을 받고 이동하는 것이다. 그런 대우를 받으려면, 제대로 평가된 ‘나의 인식’과 ‘나의 브랜드’가 있어야 가능하다는 것을 염두에 두자.결론적으로 '이직'을 제대로 하려면, 자신의 '브랜드'를 만들 수 있어야 한다. 그것이 핵심이다.그렇다면, 성공적인 이직을 하려면 무엇을 갖추어야 하는가? 그것은 다음의 6가지로 정리할 수 있다.하나. 자기만의 장점을 가져야 한다.둘. 자신만의 전문성을 가져야 한다.셋. 절대다수는 하지 못하는 희소성을 가져야 한다.넷. 내 경력과 전문성을 증명할 프로젝트를 가져야 한다.다섯. 포트폴리오를 구성하라여섯. 외부활동과 내 브랜드를 만들어라이 6가지 중에 2~3가지만 충족한다고 하여도, 소프트웨어 개발자는 제대로 된 대우나 평가를 받으면서 즐거운 이직을 경험할 것이다. 말 그대로 헤드헌팅이나 개발자 커뮤니티에서 당신에 대한 평가가 좋을 것이다.매우 당연한 것이지만, 준비된 사람에게는 언제나 기회가 만들어진다. 기회가 만들어지지  않는다는 것은 ‘준비가 부족하기 때문이다’라고 이야기할 수 있다.직업 이직을 권유받았는가? 아니면. 이직을 꿈꾸는가?그렇지만, 그렇게 브랜드나 명성을 얻기 전에 권유를 받았건, 상사가 괴롭혀서 떠나건, 이직에 대해서 고민하고 결심했다면 다음의 몇 가지를 고민하자.후배들에게 이야기하는 몇 가지 충고의 이야기가 있다. 이것은 정말 최소한의 기준이다.최소, 이 기준에 대해서는 고민하고 '이직'을 결심했으면 좋겠다.하나. 소프트웨어 개발자들이거나 SI현장에 있는 개발자라면 최소한 하나의 도메인이나 전문분야를 택했다면 최소 5년은 버텨야 한다.둘. 프로젝트나 포트폴리오는 5년 이하 경력은 세상이 제대로 인지하거나 인식하지 않는다.셋. 직장이 중요한 것이 아니라, 직업과 도메인이 중요하다.넷. 경력과 브랜드는 ㅇㅇ회사의 누구가 아니라. 누가 다니는 ㅇㅇ회사가 더 좋다는 평가를 받아야 한다.SI현장에 있건, SM현장에 있건, 대기업이나 중견기업은 파견 나온 개발자를 좋아한다. 어떤 분야이건 어떤 특수하거나 일반적인 분야이건 대부분은 교육이 필요하고, 경험이 필요하다. 그리고, 그 조직과 회사에 적응하는 기간이 필수적이다. 대부분 이러한 '비용'은 기업을 운영하는 입장에서는 어떻게든 최소화하기를 원한다.대부분 이런 신입 비용을 어떻게 줄이느냐가 관건이기 때문에, 대부분의 회사들은 가능한 '경험'자와 '경력자'를 선호하는 것이 매우 당연하다. 특히나, 관련된 일과 조직에 익숙한 사람이라면 회사 입장에서는 신입의 교육비용이 들어가지 않는 파견된 개발자들을 선호하게 된다.바로 업무에 투입하고 결과물을 얻을 수 있기 때문에, 이러한 파견된 개발자들을 선호할  수밖에 없다. 그래서, 보통 갑, 을의 조직들은 자신의 일을 위해서 파견 나온 SI, SM개발자들을 참 매력적으로 인식한다.특히나, 이렇게 일하는 SI, SM 개발자들은 함께 일하고, 같은 조직에서 일하는 사람들이기 때문에 눈으로 확인한 이러한 사람들을 좋아할  수밖에 없다. 당연한 것이지만, '면접'을 통해서 사람을 뽑는 것보다 직접 함께 일한 사람을 뽑는 것이기 때문에 해당 기회비용과 교육을 위한 시간 비용들이 모두 절약된다.그래서, 대부분은 고객 회사에서 이런 개발자들에게 먼저 이직을 권유하게 된다. 고객의 입장에서는 바로 실전에 투입할 수 있는 개발자를 얻을 수 있고, 권유를 받은 개발자 역시 중소기업이나 파견직에서 일하다가 더 높은 연봉과 복지제도를 제공하는 기업으로 옮겨갈 수 있는 기회를 얻는다.다만, 이러한 권유를 받는 것은 '인력파견'업체를 통해서 SI현장에 나가서 일하는 경우에는 이러한 '기회'를 얻기 어렵다. 실제, 이러한 '제의'를 받는 경우는 '고객'의 기업에 직접 나가서 일하는 경우를 의미한다고 봐야 한다.물론, 이러한 것을 중소기업 입장에서는 인력 빼가기?라고 볼 수 있다. 필자도 중소기업을 운영해봤지만, 중소기업에서 4~5년 이상 일을 하고 있는 직원이 아니라면, 이러한 이야기도 하기 힘들것이고, 실제, 중소기업의 일이라는 것이 '일을 배우고 가르치는 이유가 어느 정도 업무에 필요한 수준'까지만 가르치기 때문에, 이를 중소기업의 인력 빼가기라고 이야기하기 어렵다. 가르친 것도 없이 일만 시켰는데 무슨 ‘인력 빼가기’인가?다만, 가장 최악의 이직 회사를 피하는 방법은 정말 고려하다. 하지만, 이직을 할 때에 순간적인 선택에 의해서 정말 좋지 않은 선택을 하는 경우가 종종 있다. 하지만, 아래와 같은 회사로 이직을 하였다면, 재빠르게 '사표'를 내는 것이 가장 현명하다. 필자의 경험을 기반으로 이런 회사는 빨리 떠나야 한다고 생각한다.하나. 회사의 사무실의 인테리어가 영 허접하다현재의 소프트웨어 개발자들의 인테리어는 대부분 훌륭하다. 특히, 이제 막 시작한 스타트업의 경우라면 직원이 아니라, '동료'의 입장으로 참여하는 것이기 때문에 이 조건은 해당이 안될 것이다. 하지만, '직원'의 입장에서 그 회사에서 일을 하는 경우라면 '회사 인테리어'는 매우 중요하다.그것은 초라한 사무실에 초라한 책상에 기본적으로 제공되는 도구도 깔끔하지 않다면, 정말 간단하다. 그 회사에서 직원들에 대한 처우나 근로환경은 최악이라고 보면 된다. 아마도, 입사를 한지 한 달 후에 바로 급여나 근로형태에 대해서 불만이 생길 것이다.대부분 이런 회사의 특징은 인력파견 회사일 확률이 높다. 당연한 것이지만, 내부에 축적된 지식도, 솔루션도 없는 조직이다. 그냥, 싼 개발자를 구하고, 파견을 보낼 개발자를 구했을 것이고, 그것에 당신이 걸려들은  것뿐이다. 빨리 탈출하는 것이 현명하다.둘. 직원들의 얼굴 표정이 매일 야근한 것 같다.근무조건과 처우에 대해서는 그 회사에서 근무하는 직원들의 모습을 보면 된다, 깔끔한 복장에 자유롭고, 자신에 찬 얼굴을 하고 있는 경우라면 상관없다. 하지만, 세탁한지 며칠 된 복장에 연일 야근에 찌든 듯한 얼굴, 사무실에 난로도 제대로 안 때워서 매번 감기에 걸려있는 상태인듯한 모습이라면, 그 회사도 빨리 탈출하는 것이 현명하다.필자는 개인적으로 소프트웨어 개발자들을 제대로 처우하는 곳이라면 키보드와 마우스, 그리고. 의자는 최대한 자신이 원하는 도구를 구해주는 곳이라고 생각한다. 그리고, 최소한의 근무환경을 구성해줄 수 있어야 한다. 다만, 같이 고생하고 같이 나눌 동료가 아니라면 이런 회사는 빨리 탈출하다.셋. 오래된 선배 개발자의 경력이 얼마나 되는가?좋은 조직과 좋은 회사. 그런 곳은 좋은 회사다. 고로, 당연하게 좋은 회사는 계속 다닐만한 가치가 있기 때문에 오래된 개발자들이 존재한다. 회사 업력이 10년이 넘었다면, 10년을 다닌 개발자가 있을 것이고, 5~6년 차 개발자들이 여러 명 존재해야 한다.하지만, 회사 경력이 10년을 넘었는데도 그 회사 경력 2년 차가 팀장이고, 병특들로 모두 구성되어 있는 회사라면, '결코 좋은 회사는 아니다'.분명하게 회사의 사장에게 문제가 있거나, 똘아이 같은 개발이사가 있거나, 막 나가는 팀장이 있을 수 있다. 또는, 처우나 급여문제 등등 문제가 분명 존재할 것이다.넷. 가족과 같다는 이야기를 반복하는 사장의 이야기회사는 '이익'을 위하여 존재하는 곳이고, '돈'을 벌어야 급여가 나오는 회사이다. 회사는 '가족'이 아니다. 그리고, '사장'처럼 일하라고 반복하는 '사장'들이 가끔 있다. 그럼, 이렇게 반문해보자, '사장'같이 일하면, '그 회사'를 물려줄 것인가?아니다. 처우는 '노예'처럼 하면서 일은 '사장'처럼 하기를 원하는 것이다. 이런 회사도 떠나라. 또 이런 회사의 특징은 이렇다.'회사 사정이 어려워서...', '요즘 경기가 안 좋아서...', '다음에...', '이거 끝나면 뭔가 있을 거야...'부끄럽지만 필자도 이런 이야기들을 20대 후반 사장 시절에 반복했었다. 결론적으로 '지키지 못할 약속'을 그냥 반복할 뿐이다. 이런 이야기의 99%는 뻥이고, 그냥.  '립서비스'일뿐이다. 포상은 합리적이어야 하는 것이다. 또한, 엄청난 투자를 받는다고 해서  밀어붙인 일일 경우도 많다. 하지만, 언제나 '과실'중에 '이익'은 경영진만이 가지고 간다는 것을 잊지 말자.다섯. 인건비는 무조건 싼 개발자만 찾는 회사.간단하다. 경력 10년 차 개발, 고급 개발자가 할 수 있는 일을 하거나, 품질이 높은 일이 필요 없는 일이 대부분이다. 임금이 비싸고 경력이 풍부한 사람이 비싼 이유는 당연하게 있다. 하지만, 단지 급여가 싼 사람을 찾는 이유는 간단하다.'일'에 대한 가치를 알지도 못하고, '개발자'에게만 탓을 돌리는 사장이나 경영진일 경우에 대부분 이렇다. 경력 1년 차가 할 수 있는 일이라고만 생각하기 때문에, 경력 4~5년 차도 그에 합당한 급여를 줄 수 없는 것이다.당연한 것이지만, 실제 일은 단순 SM이기 때문에 그런 경력을 가진 개발자가 필요 없다고 인지하기 때문이다. 이런 회사들이야말로 정말 비전이 없다.여섯. 급하게 뽑는데 면접도 제대로 안보는 회사정말 엉터리 같은 인력파견업체의 경우가 이렇다. 자신들이 면접을 보는 것이 아니라, 고객사로 보내서 면접을 본다.만일 위에 언급한 6가지 내용 중에 한 개 이상으로 해당되는 회사나 조직에 있다면, ‘이직’을 고려하는 것이 정말 당연하다 하겠다. 하지만, 자신의 능력과 이직에 대한 준비가 되어 있지 않다면, 어쩔 수 없다. ‘샐러리맨’의 기본자세로 돌아가서, 내 능력에 합당한 현재의 자리에 만족하는 법을 배워야 할 것이고, 처세술이나 그 조직에서 버티기 위한 정치력을 발휘해야 할 것이다. 이러한 글들은 주변 서점에 널려있으니, 그런 책 한두권 읽어보기를 권장한다.‘이직’은 소프트웨어 개발자 생활을 하면서 계속 유혹과 한계를 경험하게 할 때마다 머릿속에 떠오를 것이다. 그때에 실수하지 않고, 좋은 판단을 하기 바라며. 가장 중요한 것은 ‘후회’ 하지 않고, 이미 결정한 것은 잊어버리는 것이 속 시원하다는 것이다.마지막으로 좋은 스타트업을 골라달라고 조언하는 경우에는 다음과 같이 답한다.스타트업은 좋은 동료가 될 생각이 있을 때에 들어가라는 것이다. 스타트업은 초기 멤버로서 합류하면서 고생도 같이 하고, 이익도 같이 나누는 동업자가 되는 것이다. 샐러리맨으로써 직장을 택하는 것과는 정말 다른 것이다.물론, 스타트업이 투자를 받고, 초기 멤버가 아닌 경우에는 위에서 언급한 내용과 별로 차이가 없다고 설명할 수 있다. 어느 규모나 별로 차이가 없었다.'이직'은 소프트웨어 개발자들에게는 매번 경험하게 된다. 그리고, 그 경험을 좋은 결과로 얻기를 바란다. 그리고, 언제나 좋은 선택이  필수이며, 인생 선배나 동료에게 좋은 조언을 구해보자.

기업문화 엿볼 때, 더팀스

로그인

/