'2019/03/08'에 해당되는 글 3건

  1. 2019.03.08 REST API 디자인 가이드 적용기
  2. 2019.03.08 Tuckman의 팀 발달 모델
  3. 2019.03.08 자연어처리 - Bag of words, n-gram
아주 작은 시스템을 개발할 때는 API들이 약간 엉켜 있어도 
문제가 생겼을때 원인을 찾는데 어렵지 않을 것이다.
하지만 시스템이 커지고 복잡 하다면, 서로의 인터페이스를 잘 정돈하고 관리하는 것이 중요해진다.

구글이나 페이스북 등 큰 기업들은 잘 정돈하고자 그들만의 REST API 가이드라인을 가지고 있다.

나는 여러 개발자들과 함께 REST API 개발을 담당하게 되었다.
그래서, 구체적인 개발을 시작 하기 전에 사내 REST API 디자인 가이드를 만들어야겠다고 마음을 먹었다.

가이드라인을 만들고 이것을 참고해 반년 정도 개발-운영을 했다.
처음 가이드라인을 만들때 했던 고민과 챙겨야할 것들, 
그리고 가이드라인과 함께 개발하면서 느낀점들을 정리해보고자 한다.


REST API를 쓰는 이유

REST API 에 대한 설명은 인터넷에 많다보니 생략하려고 한다.

  REST

  API

핵심은 표현에 대한 약속

원하는 결과는 얻을 수 있는 "표현에 대한 약속"은 종류가 많을 것이다. 
하지만 이것들은 좋은 약속도 있고 안좋은 약속도 있다.
안좋은 약속은 당장에 동작에 문제가 없더라도, 
나중에 가면 유지보수가 힘들어지거나 구조를 더 꼬이게 만드는 것들을 말한다.
좋은 약속에 해당하는 "표현에 대한 약속"들을 모아.. RESTful API 라고 부르고 있다고, 나는 생각한다.
  


디자인가이드의 필요성


협업
여러 개발자들이 여러가지 각자의 자원에 대해 개발을 할 때 필요하다. 
개발자가 많고 자원이 많은 상황에서 일일이 해당 자원의 개발자를 찾아가 API를 이해하는것은 시간 낭비가 크지만, 가이드라인에 따라 개발 되었다면 이 낭비를 줄일 수 있다.


개발 효율
위의 협업과 비슷하다. 자원에 대한 통일된 접근 방식은 개발 효율 을 높인다.
API를 만드는 사람 입장에서 가이드라인에 맞게만 만들면 되기 때문에 고민할 필요가 적어진다.
API를 사용하는 사람 입장에서도 동일하게 효율적으로 API를 이해할 수 있게 되어 좋다.


기능 단순화
API에서 표현해야 하는 자원의 범위는 중요한 문제다. 가이드라인에는 자원의 범위에 대한 내용을 다루어야 하고, 개발자들도 이것에 맞추어 개발해야 효율성이 높아진다.

간혹 자원에 대한 범위나 접근 방법을 정하기 애매할 때가 있다. 
나도 모르게 여러가지 자원을 한번에 묶어서 처리하거나,
필요 이상으로 여러가지 기능을 한번에 묶어서 처리하는 식으로 개발하게 될 수 있다.
이렇게 되면 API(ex. 엔드포인트)는 기능에 의존도가 높아져서 다양한 용도로 활용이 어렵게 된다.

예를 들어 사용자정보, 사용자부가정보 라는 자원이 있다고 하자. 
이것을 1가지 자원으로 묶어서 표현을 하게되면, 사용자정보만 필요한 상황이 왔을때 이 자원은 사용자정보+사용자부가정보 로 묶여 있어서 필요하지 않은 자원도 가져가야 한다.

API 범위가 크면 사용할 필요 없는 자원도 가져가야 할 경우가 많아질 것이다. 
그렇다고 범위가 너무 작으면 API 호출이 많아 지게 된다.

MSA 구조 관련된 이슈로 볼 수도 있다. 
경험상 가급적 자원 범위를 작게 유지하는 편이 나중에 추가기능이 필요할 때 더 유연하게 대처할수 있다.
그래서 디자인가이드에 이런 내용을 담아 약속하면 좋다.

 

디자인가이드 필수요소

나는 구글의 가이드라인을 많이 참조했다. 

바퀴를 다시 발명하고 싶은게 아니라면..앞서간 개발자들의 지식을 누리는건 좋은일이다.
시작부터 잘못되면 나중에 이도저도 안되서 후회할 수도 있다.

구글의 가이드라인은 양이 방대하다. 때문에 그대로 적용 했다가는 구성원들에게 버림 받을 수 있다.
나는 적당한 선에서 타협을 하고 개발하면서 규칙을 추가해 나가기로 정하였다.

아래는 REST API 가이드라인을 만들면서 처음에 정했던 규칙들이다.
 

URL 규칙

URL을 만들때 아래 규칙에 따라 만든다.

https://[서버주소]/[버전]/[자원명]/[ID]

https://localhost/v1.0/articles/1
  • 자원명은 반드시 명사로 표시해야 한다. 
  • 자원명은 복수로 표시해야 한다.

게시판에 대한 자원명 이라면 "게시물들(articles)" 로 정해야한다.
자원명은 자원에 대한 복수 명사 가 되어야 한다.

아래 예시들처럼 어떠한 행동이나 조건을 포함하면 안된다.
"게시판조회하기(boardView)","게시판최근게시물(boardNewView)","게시판모아보기(boardAllView)"

  • 페이징 처리가 필요할 때는 offset 과 limit 을 사용한다
/articles?offset=0&limit=20

  • 계산, 변환 등 어쩔수 없이 URL 에 동사를 사용해야 하는 케이스는 자원명 뒤에 콜론(:)을 넣고 뒤에 동사를 붙인다.
/articles:backup


Http Method 기능 정의

주로 사용하는 Http Method 는 GET, POST, PUT, DELETE 4가지가 있다.
앞에서 정한 URL(자원명)에 이 4가지 행동의 조합으로 모든 요청을 받아서 처리해야 한다.

  • POST : 새로운 자원 생성
  • GET : 자원의 목록 혹은 단건 가져오기
  • PUT : 기존의 자원 업데이트
  • DELETE : 기존의 자원 삭제


버전 관리

버전은 v[메이저].[마이너] 로 구성한다.

  • 메이저 : API의 변경이 이전 버전과 호환이 되지 않는 수준의 변경
  • 마이너 : 호환 가능한 수준의 변경

이 규칙들과 함께 요청(request)의 표준 표현, 응답(response)의 표준 표현, 에러응답의 표준 표현을 정하고 추가해서 우리 조직만의 REST API 가이드라인을 만들어 사용하였다.



디자인 가이드 운영하며 느낀점

가이드라인을 처음 만드는 것은 그리 어려운 일은 아니었다.
제일 어려운점은 계속해서 가이드라인을 지키는것이다.

가이드라인이 처음 만들었을 때는 잘 지켜나갔다. 
하지만 시간이 지나고 일정이 바빠질 때가 위험한 순간이다. 
이럴때 가이드라인 만으로 해결할 수 없는 예외가 생기면, 
가이드라인을 조금 벗어나더라도 일단은 동작하는 방향으로 개발을 완료하는 경향이 생겨났다.
  
예외가 생겼다면 2가지 케이스중 하나일 것이다.
  • 가이드라인을 잘못 이해해서 생긴 예외
  • 기존 가이드라인에서 해결할수 없어서 추가 규칙이 필요한 예외

잘못 이해한것이라면 좀 더 고민해서 자원을 나누고 표현방법을 바꾸면 될것이다.
규칙의 추가나 변경이 필요하다면, 구성원들과 충분히 논의하고 결정하면 된다.
  
이 두가지 과정이 꼭 필요하다.

처음부터 완벽한 가이드라인은 있을 수 없다. 
또한 조직이나 업무에 따라 필요한 가이드라인은 다를 것이다.

그렇기 때문에..
계속해서 의문을 제기하고, 구성원간의 논의-결정들이 가이드라인에 쌓이는 것이 중요하다.
그래야 좋은 가이드라인을 만들수 있고, 시스템의 품질을 올리는데 도움이 될 거라고 생각한다.
  
제일 중요한것은 구성원 모두가 이해하고, 도움이 된다는 확신과 개선해 나가려고 하는 의지라고 생각한다.

하지만 역시 쉽지 않은 일이다. 
잊혀지지 않으려고 주기적으로 강조를 해야했고 앞으로도 계속 그래야 할 것으로 보인다.


Posted by panpid

댓글을 달아 주세요

지금까지 IT업계에 20년 가까이 일을 하면서, 많은 팀을 겪어 왔습니다. 


역할로는 팀원에서부터 파트장, 팀장까지 다양하게 경험을 해왔으며 현재도 진행중이지요.


팀과 프로젝트를 리딩한 경험도 다양한데, 팀의 규모로는 3명에서부터 20명이 넘는 팀을 리딩해 본 경험이 있습니다.


또한 경험해 온 환경도 무지 다양한데, 여러 회사의 다양한 팀 구조와 문화를 체험했습니다. 
인터넷 컨텐츠 회사에서 부터, 게임회사, 대기업 SI 등의 서로 다른 조직 문화에서 일을 해왔으며, 팀의 조직화 특성으로는 보통의 기능조직 성격의 팀에서부터 프로젝트에 특화되어 구성된 TFT(Task Force Team)까지 겪어 봤습니다.


지금까지 제가 겪어온 팀들은 제각각 다른 특성들이 있었지만, 결국 사람이 모여서 일을 하는 것입니다. 


그래서 팀이 결성되고 협업하고 때론 갈등에 직면하고 목표를 달성해 나가는 근본적인 원칙과 과정은 크게 다르지 않다고 봅니다.


오래전 팀리딩을 담당하게 되면서, 프로젝트 관리와 동기부여에 관련된 다양한 이론과 지식을 찾아서 학습해 왔습니다. 그전에는 관심 없었던 다양한 경영이론과, 심리학 이론 등이 존재하더군요.


이 글에서는 그 중 하나인, Tuckmana의 팀 발달 모델을 소개하고 개인적인 경험과 접목하여 글을 정리해 볼까 합니다.




Tuckman's Team Development Model


1965년, 심리학 교수인 Bruce Tuckman은 'Developmental Sequence in Small Groups'이라는 논문을 통해 Team Development Model이라는 경영이론을 발표했습니다.


팀이 형성되고 발달해 나가는 과정을 4단계로 나눈 이 모델은, 각 단계별로 팀이 겪게 되는 특징을 잘 설명합니다. 

첫 논문 발표시 4단계였던 것이 1977년에 Adjourning 단계가 추가되면서 현재는 총 5단계 모델로 알려져 있습니다.


국제적인 프로젝트관리 협회인 PMI에서 발행하는 PMBOK에서도 '인적자원관리'라는 지식영역에서 이 모델을 '프로젝트 팀 개발'이라는 항목으로 안내하고 있습니다.


팀 리더는 팀 운영과 프로젝트의 성공을 위해 이 모델을 참조할 수 있습니다. 팀이 발달하는 과정을 이해하고 각 단계별로 당면하는 팀의 상황과 각 상황별로 필요한 리더십 스타일을 이 모델의 이론에 근거하여 결정할 수 있습니다.


개인적으로도 이 모델은, 그간 제가 맡은 팀을 이해하고 문제를 해결하고 리딩 스타일을 결정하는데 많은 도움이 되었습니다.


Tuckman에 의하면 팀은 (아래 도식에서와 같이) 5단계의 과정을 거치게 됩니다. 처음에 혼돈과 불확실성으로 가득찬 상태에서 긴장과 대립, 갈등이 촉발되는 시기가 옵니다. 이후 각 단계를 거치면서 팀은 성장하고 프로젝트를 성공적으로 완수할 수 있게 됩니다. 물론 잘 운영되는 경우에 말이지요.



출처: https://www.lfhe.ac.uk/download.cfm/docid/3C6230CF-61E8-4C5E-9A0C1C81DCDEDCA2



Tuckman의 이론을 요약하여 다음과 같은 표로 정리해 봤습니다.



처음 이 모델을 봤을 때, 참으로 공감되는 내용이 많았습니다.


제가 맡은 여러 형태의 팀들 중에서 특히, SI 프로젝트를 수행할 당시의 팀이 이 모델의 이론과 매우 흡사 했습니다.





각 단계별 리더십 스타일


제가 이 글을 정리하고자 했던 동기는 바로 이 부분입니다. 팀리더가 어떻게 해야 팀을 원만하게 운영하고 프로젝트를 성공시키느냐 하는 것입니다.


팀리더는 프로젝트를 성공시키고 팀을 성장시키는데 책임이 있습니다. 그 책임을 다하기 위해서는 팀과 팀 구성원들을 정확히 이해하고 자신의 리더십 스타일을 적적히 변경할 수 있어야 합니다.


팀 리더는 Tuckman의 모델에 참고하여 자신의 리더십 스타일을 결정하거나 조정할 수 있습니다.

여기에 좋은 안내서가 있습니다.


https://kristalaace2014.wordpress.com/2014/02/26/w1_al_tuckman-analysis-assignment/comment-page-1/


위의 표는 각 단계별로 팀리더의 스타일을 안내하고 있습니다. 저도 이 표를 보면서 간과했던 부분을 다시금 깨닫는 계기가 되었습니다.



형성기(Forming)

모든것이 불명확하고 불확실한 상태입니다. 프로젝트의 목표와 과제에 대해 공감과 이해가 부족한 상태이며, 구성원들은 서로 어색하고 신뢰가 형성되지 않은 시기입니다.  


'우리가 여기에 왜 모였는가?'' 를 분명히 해야 합니다. 

즉 목표를 명확히 설정하고 작업 과제와 R&R을 분명히 해서 구성원들을 인지시켜야 합니다. 
요약하자면 이 시기에서 팀 리더는 프로젝트의 방향 설정과 공유에 집중하고 각 구성원들의 R&R과 수행과제를 명확히 전달하는 것이 필요합니다. 시형 리더십 스타일이 필요하다 하겠습니다.


격동기(Storming)

프로젝트의 목표와 개인의 역할을 인지하게 된 시기입니다. 

이제 본격적으로 각 구성원들이 프로젝트를 위해 일을 시작하게 되는 것이지요. 그러나 이제 막 모인 사람들은 각자의 업무 스타일과 개성이 표출됩니다. 이로 인해 잦은 의견충돌과 대립이 발생하면서 긴장상태로 접어 듭니다. 말 그대로 격동기 입니다.


팀 리더로써 가장 중요한 시기입니다. 다름과 틀림을 구분할 수 있도록 해야 합니다. 구성원들의 서로 다른 업무 스타일로 갈등이 고조되지 않도록 하는 조치가 필요합니다. 


팀이 일을 하는 방식에 대한 표준(기술표준, 프로세스 표준, 의사결정 방식 등)이 반드시 필요합니다. 각자의 스타일을 존중하되, 협업을 위한 표준으로 스타일을 조화시켜야 합니다.이 시기의 팀 리더는 구성원들의 개인적인 상호작용에 많은 관심을 가져야 합니다. 


구성원들의 의견 불일치, 갈등을 적극적으로 중재해야 합니다. 이때 팀의 표준이 많은 도움이 됩니다.

코치형 리더십 스타일이 필요하다 하겠습니다. 특히 개인적인 관계를 촉진하는 역할이 중요합니다.


규범기(Norming)

이제부터 팀의 정체성이 서서히 형성되기 시작합니다. 팀 구성원들은 공동의 목표 달성을 위해 모였다는 것을 자각하게 됩니다. 상호 조화를 위해 노력하기 시작하고 서로를 신뢰하기 시작합니다. 이제 각 구성원들은 자신의 작업을 원만히 수행하며 원만히 협업하기 시작합니다. 


이때 팀 리더는 작업 그 자체 보다는 작업과 작업간의 우선순위와 프로세스에 집중해야 합니다. 
즉 프로젝트의 진행을 촉진한느 참여형 리더십 스타일로 팀을 리딩하는 것이 좋습니다.


성과기(Performing)

이제 팀은 최고의 성과를 내기 시작합니다. 서로간의 신뢰가 매우 높아진 시기입니다. 프로젝트 목표 달성을 위해 구성원 스스로가 최적의 방안을 스스로 도출해 내기도 합니다. 


팀 리더는 구성원들에게 권한을 위임해도 큰 문가 없으며 오히려 권한 위임으로 인한 동기부여와 시너지가 높아지기도 합니다. 즉 위임형 리더십 스타일이 권장됩니다.


해지기(Adjourning)

프로젝트의 수행이 완료되고 팀이 해체하는 시기입니다. 보통 기능조직팀은 해체라는 것이 없지만 프로젝트에 특화된 팀은 해체하게 됩니다. 이 시기에는 특별한 리더십 스타일이 요구된다기 보다는, Lesson Learned를 통해 프로젝트를 수행하면서 겪었던 성공과 실패, 프로세스 지식 등을 정리하고 평가를 수행합니다. 이러한 경험이 쌓여 다음 프로젝트에 경험적 지식으로 활용됩니다.




'프로젝트 관리' 카테고리의 다른 글

아키텍처의 출발점  (0) 2019.04.04
Core/Context 모델  (0) 2019.03.22
Tuckman의 팀 발달 모델  (0) 2019.03.08
Posted by 사용자 박종명

댓글을 달아 주세요

자연어 처리(natural language processing)는 인간의 언어 현상을 기계적으로 분석해서 컴퓨터가 이해할 수 있는 형태로 만드는 자연 언어 이해 혹은 그러한 형태를 다시 인간이 이해할 수 있는 언어로 표현하는 제반 기술을 의미한다. (위키피디아)

간단하게 말하면, 자연어의 의미를 분석하여 컴퓨터가 처리할 수 있도록 하는 일 이라고 생각하면 될 것 같다.

텍스트

기계학습 모델을 만들기 위해서는 데이터를 모델에 맞게 변형시켜 주어야 한다. 알고리즘에서 텍스트를 그대로 받아들일수 없기 때문에 받아들일 수 있는 어떤 숫자값으로 변환을 해주어야 한다. 하지만 텍스트는 일단 언어가 제각기 다르기 떄문에 텍스트 자체를 어떻게 숫자화 할지 부터 시작해야한다.

그럼 어떤 방법들이 있는지 살펴보자.

BOW(bag of words)


BOW(Bag of words)는 텍스트 데이터를 표현하는 방법 중 하나로 가장 간단하지만 효과적이라 기계학습에서 널리 쓰이는 방법이다. BOW는 텍스트의 구조와 상관없이 단어들을 담는 가방(Bag)으로 생각하면 된다.

The game is fun
The game is interesting
The game is not funny

세 문장에서 나타나는 단아들을 모으고 세 문장을 각각 binary vector로 표현하는 것이 BOW이다. 각각의 문장을 binary vector로 표현하면 다음과 같다.


thegameisfuninterestingnotfunny
1111000

The game is fun : [1, 1, 1, 1, 0, 0, 0]

thegameisfuninterestingnotfunny
1110100

The game is interesting : [1, 1, 1, 0, 1, 0, 0]

thegameisfuninterestingnotfunny
1110011

The game is not funny : [1, 1, 1, 0, 0, 1, 1]

만약 이 가방에 들어있지 않는 단어가 포함된 문장이 있어도 BOW는 그 없는 단어는 제외하고 있는 단어만을 가지고 벡터로 만들 것이다.

그럼 이 수치로 표현된 값을 어떻게 활용할까?

머신러닝 모델에 입력값으로 사용할 수도 있디만 단순히 계산만으로 문장간의 유사도(Sentence similarity)를 알 수도 있다.

the game is fun 과 The game is interesting 문장의 유사도를 구해보자.


문장벡터값
the game is fun[111, 1, 0, 0, 0]
The game is interesting[111, 0, 1, 0, 0]

유사도 = (1x1) + (1x1) + (1x1) + (1x0) + (0x1) + (0x0) + (0x0) = 3

또한 수치로 표한된 값을 이용해 기계학습 모델에 입력값으로 사용할 수가 있다. 문장에 대한 감성분석을 해주는 모델이 있다면, 벡터화된 값을 모델에 입력값으로 사용할 수 있고 모델은 우리가 원하는 Good 또는 Bad의 결과를 출력해 줄 수 있다.



하지만 BOW는 몇 가지 단점이 있다.

  • Sparsity
    실제 사전에는 100만개가 넘는 단어들이 있을 수도 있다. 그렇게 되면 벡터의 차원이 100만개가 넘어가기 때문에 실제 문장하나를 표현할 때 대부분의 값이 0이고 그외의 값들은 상당히 적을 것이다. 결국 학습량이 많아지고 컴퓨터 자원도 상당히 많이 사용하게 된다.
    (the game is fun [1,1,1,1,0,0,0,0,0,0,0,,,,,,0,0,0,0,0])

  • 빈번한 단어는 더 많은 힘을 가진다.
    많이 출현한 단어는 힘이 세진다. 만약 의미없는 단어들이 많이 사용 되었다면 우리가 원하는 결과를 얻기는 어려울 것이다.

  • Out of vocabulary
    오타, 줄임말 등의 단어들이 포함되면 굉장히 난감해진다.^^;

  • 단어의 순서가 무시됨
    단어의 출현 횟수만 셀수 있고 단어의 순서는 완전히 무시 된다. 단어의 순서가 무시된다는 것은 다른 의미를 가진 문장이 동일한 결과로 해석될 수 있다는 것이다.

전혀 반대의 의미를 가진 두 문장을 보자.



두 문장은 의미가 전혀 반대이지만 BOW를 이용해 처리한다면, 동일한 결과를 반환하게 될 것이다. 이런 단점을 보완하기 위해 좀더 개선된 n-gram이란 것이 있다. BOW는 하나의 토큰을 사용하지만 n-gram은 n개의 토큰을 사용하여 어느정도 단어의 순서를 반영 결과에 반영해 준다.

N-Gram

BOW를 조금 더 개선하여 단어 하나만을 보는 것이 아니라 주변의 n개 단어를 뭉쳐서 보는 것이다. 뭉쳐진 n개의 단어들을 gram이라고 한다. 단어 개수에 따라 부르는 명칭이 다른데 2개의 단어를 묶어서 사용하면 bi-gram, 3개면 tri-gram이라고 부른다. (1-gram은 uni-gram이라고 한다.)


“home run” 과 “run home” 문장을 bow와 bi-gram으로 처리한 결과를 보자.

bag of words : [home, run] , [run, home]
bi-gram : [home run], [run home]

BOW를 사용한다면 두 문장은 같은 백터의 값을 갖게 되겠지만 bi-gram을 사용하면 2개를 뭉쳐서 사용하므로 어느정도의 순서가 보장되는 효과를 볼수 있게 되어 다른 결과 값을 가지게 될 것이다.

이런 특성을 이용해 n-gram은 다음 단어 예측하거나 어떤 단어를 입력 했을때 오타를 발견하고 다른 단어를 추천해 주는데 활용할 수 있다.

텍스트 전처리 (Preprocessing)


BOW나 n-gram이나 모두 많이 쓰이지만 가장 중요한 것은 단어의 전처리가 확실해야 한다는 것이다. 이 글에서는 설명을 위해 간단한 문장만을 사용하여 크게 신경을 쓸 필요는 없겠지만, 자연어 처리를 하다보면 다양한 케이스의 문장들을 접하게 될 것이며 이런 문장들을 토큰화하고 불필요한 단어들은 제거하고 같은 의미의 단어들은 치환하는 등의 고단한 작업 들을 해야 할 것이다. 하지만 다행인 것은 이런 전처리 작업들을 편하게 할 수 있도록 도와주는 좋은 라이브러리들이 있다.


다음 포스팅에서는 전처리에 대해 자세히 살펴보도록 하겠다…

Posted by @위너스

댓글을 달아 주세요