칸반이란? 


애자일 소프트웨어 개발 시 많이 사용되는 툴의 한 종류입니다.

작업의 진행 상황이 모두에게 공유됨으로서 팀원/조직간 작업 상태를 실시간으로 확인할 수 있다는 점에서, 


빠르게 테스트와 개발, 수정이 이어지는 애자일 소프트웨어 개발 방식에 잘 맞는 방법인데요,

 많은 소프트웨어 회사에서 이 방식을 차용하고 있고, 특히 Jira 솔루션에서 이 기능을 직접적으로 제공함에 따라서

점점 더 많은 회사와 조직에서 사용될 것으로 생각됩니다.



칸반 보드를 그림으로 간단히 표현하면 이렇게 표현될 수 있습니다. 


칸반의 가장 큰 특징은 "작업의 시각화" 라고 할 수 있습니다.


우선 칸반은, 각 업무를 포스트잇 1개로, 사내의 모든 업무를 게시판으로 생각하는 것에서 시작합니다.


업무를 관리하는 이 게시판은, Swimline 이라는 틀로 나누어지며(파란색 점선) 각 부서가 이 틀을 하나씩 나누어 갖는 형태로 구성됩니다.

이렇게 함으로서, 각 부서별로 독립적으로 작업을 시행할 수 있고, 진행 내역을 한눈에 확인할 수 있게 됩니다.


이러한 작업을 통해, 업무 진행에서 발생하는 혼란을 줄이고, 프로젝트에 존재하는 병목을 확인하고 관리할 수 있게 됩니다.


특히, In Progress 항목(개발부서) 의 내용은 최대로 들어갈 수 있는 카드의 개수를 제한함으로서 각 개발자 혹은 작업자가

가져온 업무에 집중하고, 일정한 속도를 낼 수 있도록 도와줄 수 있습니다.



칸반의 장점

  • 생산성과 품질을 향상시킬수 있는 방법론.
  • 한번에 여러 업무를 진행하는데서 오는 혼란을 감소시키고, 확정된 업무의 목록을 누구나 간편하게 확인할 수 있습니다.
  • 병목 현상이 발생하는 업무를 바로 확인하여 인력을 충원할 수 있으므로, 프로젝트 관리에 대한 오버헤드를 감소시킬 수 있습니다.

칸반의 단점

  • 지원하는 소프트웨어가 아직 한정적이다.
  • 데드라인이 직접적으로 존재하지 않는 시스템이므로 일정에 대한 관리가 미흡해질 수 있습니다.


RPC vs 리플리케이션

원격 프로시저 호출(RPC)

리플리케이션  

위키백과 문서

언리얼 문서 

http://api.unrealengine.com/KOR/Gameplay/Networking/Actors/RPCs/

위키백과 문서

언리얼 예제

http://api.unrealengine.com/KOR/Gameplay/Networking/Example/

원격 프로시저 호출(영어remote procedure call, 리모트 프로시저 콜, RPC)은 별도의 원격 제어를 위한 코딩 없이 다른 주소 공간에서 함수나 프로시저를 실행할 수 있게하는 프로세스 간 통신 기술이다. 다시 말해, 원격 프로시저 호출을 이용하면 프로그래머는 함수가 실행 프로그램에 로컬 위치에 있든 원격 위치에 있든 동일한 코드를 이용할 수 있다.

객체 지향의 원칙을 사용하는 소프트웨어의 경우 원격 프로시저 호출을 원격 호출(remote invocation) 또는 원격 메소드 호출(remote method invocation)이라고 일컫는다.

가끔 ONC RPC와 DCE/RPC와 같은 비호환 대상을 수행하기 위해 쓰이는 다른 수많은 기술이 있다.

레플리케이션(Replication)은 데이터 저장과 백업하는 방법과 관련이 있는 데이터를 호스트 컴퓨터에서 다른 컴퓨터로 복사하는 것인데 이때 다른 컴퓨터가 반드시 떨어진 지역에 있어야 하는 것은 아니다. 컴퓨터 네트워크 상태에서는 데이터 저장을 할 수 있게 하는데 로컬 데이터 물리적 기억 장치와는 완전하게 구분된다. 레플리케이션은 유명한 데이터베이스 관리 시스템 (RDBMS, Relational DataBase Management Systems)에서 추가적으로 제공하거나 여러 대의 데이터베이스 서버의 부하를 맞추어 줄 용도로 제공한다.

레플리케이션은 남아 있는 리소스와 관련이 있는데 소프트웨어 요소나 하드웨어 부품이 말해 주며, 이는 신뢰성, 허용 오차, 그리고 성능을 개선한다. 전형적으로 '레플리케이션 인 스페이스'(replication in space)와 관련이 있는데 이것은 동일한 데이터를 다수의 저장 장치에 저장하거나 동일한 계산 업무를 다수 장치에서 수행하는 것이다. 또한 '레플리케이션 인 타임'(replication in time)는 컴퓨터 계산 수행이 반복적으로 한 개의 장치에서 일어나는 것이다.

    간단히 말하면, 클라이언트가 어떤 작업을 요청했을 때 (ex: 이동)
    • 서버에서 데이터의 유효성을
      검사해서 완전한 값을 확인한다.
    • 서버에서 결론을 내려 해당
      내용을 클라에게 전송해 준다(위치)
    • 클라이언트는 이 결과를
      기반으로 프로세스를 계속 진행한다
  • 클라이언트가 서버에게 어떤 "값"을 받는다. (ex: 이동 시 현재 위치)
    • 이것을 토대로 클라이언트에서 바로 유효성 검사를 하여 서버 기준으로 맞춘다거나 하는 작업을 진행한다.
  • 서버에 부하를 주거나, 작업 속도가 느리다.
  • 같은 값을 조금씩 다르게 유지할 수 있고 이를 맞춰주는 과정이 필요할 수 있다.


https://colorscripter.com/


코드를 써놓고 복붙해서 예시용으로 사용하기 좋다.


대충 이런식으로 쓸 수 있는 듯 하다.


"OOP" : //객체 지향 프로그래밍을 말합니다.
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ


약 1년 반쯤 프로그래머로 일을 하면서, 

가장 힘들었던 것을 손에 꼽으라고 한다면, 프로그래밍 언어나 논리 자체보다도


"사람들이 자연스럽게 사용하고 있는 단어들" 을 잘 몰라서 대화에 어려움을 겪는 것이었습니다.


OOP? RDB? 이런 단어들을 처음 접할때 무슨 뜻인지 몰라 고개를 갸웃하다가도


아! 객체 지향 프로그래밍 이야기구나!

아! 관계형 데이터베이스를 말하는 거구나!


라는 걸 깨달을 때마다,  이미 어느정도 잘 아는 개념인데도 단어를 몰라서 버벅이는 경우가 많이 생기는 것처럼 느껴졌습니다.


그래서 이런 단어들을 잘 정리해서 틈틈히 보고, 공부하기로 마음먹어 페이지를 만들고 지속적으로 업데이트 해 볼까 합니다.



"OOP" : //객체 지향 프로그래밍을 말합니다.
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
"관계형 데이터베이스"(RDB : "Relational DataBase" 라고도 부름.) :
// 키(key)와 값(value)들의 간단한 관계를 테이블화 시킨 매우 간단한 원칙의 전산정보 데이터베이스이다.
- 1970년 에드거 F. 커드가 제안한 데이터 관계형 모델에 기초하는 디지털 데이터베이스입니다.
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
"데이터 관계형 모델"
- 데이터를 컬럼(column)과 로우(row)를 이루는 하나 이상의 테이블(또는 관계)로 정리하며, 고유 키(Primary key)가 각 로우를 식별한다.
- 로우는 "레코드나 튜플"로 부른다.
- 일반적으로 각 테이블 관계는 하나의 엔티티 타입(고객이나 제품과 같은)을 대표한다.
//로우는 그 엔티티 종류의 인스턴스(예: "Lee" 등)를 대표하며 컬럼은 그 인스턴스의 속성이 되는 값들(예: 주소나 가격)을 대표한다.
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
"관계 (Relationships)"
관계는 테이블 간에 둘 다 존재한다. 이 관계들은 일대일, 일대다, 다대다, 이렇게 세 가지 형태로 이루어진다.
대부분의 관계형 데이터베이스들은 각 로우의 각 컬럼이 하나의 값만을 보유할 수 있도록 설계되어 있다. (값은 원자적이다)
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
"ACID"
ACID(원자성, 일관성, 고립성, 지속성)는 데이터베이스 트랜잭션이 안전하게 수행된다는 것을 보장하기 위한 성질을 가리키는 약어이다.
"트랜잭션"
데이터베이스 트랜잭션(Database Transaction)은 데이터베이스 관리 시스템또는 유사한 시스템에서 상호작용의 단위이다.
여기서 유사한 시스템이란 트랜잭션이 성공과 실패가 분명하고 상호 독립적이며, 일관되고 믿을 수 있는 시스템을 의미한다.
예를 들어, 은행에서의 계좌이체를 "트랜잭션"이라고 할 수 있는데,
계좌이체 자체의 구현은 내부적으로 여러 단계로 이루어질 수 있지만
전체적으로는 '송신자 계좌의 금액 감소', '수신자 계좌의 금액 증가'가 한 동작으로 이루어져야 하는 것을 의미한다.
"원자성(Atomicity)" 은 트랜잭션과 관련된 작업들이 부분적으로 실행되다가 중단되지 않는 것을 보장하는 능력이다.
예를 들어, 자금 이체는 성공할 수도 실패할 수도 있지만 보내는 쪽에서 돈을 빼 오는 작업만 성공하고 받는 쪽에 돈을 넣는 작업을 실패해서는 안된다.
원자성은 //중간 단계까지 실행되고 실패하는 일이 없도록 하는 것이다.
"일관성(Consistency)"은 트랜잭션이 실행을 성공적으로 완료하면 언제나 일관성 있는 데이터베이스 상태로 유지하는 것을 의미한다.
무결성 제약이 모든 계좌는 잔고가 있어야 한다면 이를 위반하는 트랜잭션은 중단된다.
"고립성(Isolation)"은 트랜잭션을 수행 시 다른 트랜잭션의 연산 작업이 끼어들지 못하도록 보장하는 것을 의미한다.
이것은 트랜잭션 밖에 있는 어떤 연산도 중간 단계의 데이터를 볼 수 없음을 의미한다. 은행 관리자는 이체 작업을 하는 도중에 쿼리를 실행하더라도 특정 계좌간 이체하는 양 쪽을 볼 수 없다.
공식적으로 고립성은 트랜잭션 실행내역은 연속적이어야 함을 의미한다. 성능관련 이유로 인해 이 특성은 가장 유연성 있는 제약 조건이다. 자세한 내용은 관련 문서를 참조해야 한다.
"지속성(Durability)"은 성공적으로 수행된 트랜잭션은 영원히 반영되어야 함을 의미한다.
시스템 문제, DB 일관성 체크 등을 하더라도 유지되어야 함을 의미한다.
전형적으로 모든 트랜잭션은 로그로 남고 시스템 장애 발생 전 상태로 되돌릴 수 있다.
트랜잭션은 로그에 모든 것이 저장된 후에만 commit 상태로 간주될 수 있다.
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ


전방선언:

클래스/ 스트럭처/ 함수 등등을 구현하기 전에 미리 선언하는 방식이라고 생각하면 된다.


함수와 데이터 구조의 전방 선언 사용방식이 약간 다르다. 

주석의 번호를 따라가며 설명을 읽어보면 어느정도 그 기능의 차이에 대해 이해할 수 있을거라고 생각한다.


  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37
  38. 38
  39. 39
  40. 40
  41. 41
  42. 42
  43. 43
  44. 44
  45. 45
  46. 46
  47. 47
  48. 48
  49. 49
  50. 50
  51. 51
  52. 52
  53. 53
  54. 54
  55. 55
  56. 56
  57. 57
  58. 58
  59. 59
  60. 60
  61. 61
  62. 62
  63. 63
  64. 64
//.1.
//.선언만 되고 정의는 되지 않은 클래스 형식.
//.선언만 된 클래스는 포인터로는 사용 가능하지만 실제 구현부의 정의가 먼저 나올때까지 기능은 사용할 수 없다.
class ForwardDec;

//.2-ⓐ
//.함수는 미리 선언만 해 두면 기능을 사용한다고 선언할 수 있다.
//.선언부가 존재한다면, 함수를 적재할 주소를 미리 지정해 둔다고 생각하면 된다.
void excution(ForwardDec * dec);
void excution2(ForwardDec * dec);
int main()
{
ForwardDec * dec;
//.2-ⓑ
//,소스코드 순서상에서 아직 정의가 없는 상태라고 볼 수 있지만,
//.함수는 런타임에서 실행되고, 런타임 상에서는 미리 정해진 메모리의 주소에 함수를 실행하는 코드부분이 적재되어 있기 때문에
//.함수의 실행 자체는 큰 문제가 없다.
excution(dec);
}

void excution(ForwardDec * dec)
{
//. 3
//. 이 시점에서, PrintLove함수는 존재하지 않는다.
//. 컴파일러는 단지 FowardDec 클래스가 존재한다는 사실,
//. 그리고 그 포인터가 존재한다는 사실만을 알고 있기 때문에, 실제 구현부에 있는 함수는 사용할 수 없다.
//. 3-ⓐ
//.따라서 다음과 같은 시행은 문제가 발생한다. (함수에 부여할 메모리 주소가 정해지지 않았는데 먼저 사용함.)
dec->PrintLove();//->(오류 발생)
//. 3-ⓑ
//. 로컬 변수로도 선언할 수 없다. (어떤 형태를 가지는 클래스인지 알수 없음.)
ForwardDec dec2;//->(오류 발생)
//. 3-ⓒ
//. 단, 전방선언 이후 클래스 정의 이후에 다시 정의되는 함수의 경우에는 정상적으로 작동한다.
excution2(dec);//-> (정상 작동)
}
//. 4
//. 헤더파일에는 클래스의 정의가 들어있다. 아래 주석의 내용이 이자리에서 선언되었다고 생각하면 된다.
#include "forwardDec.h"
/*
// #include <iostream>
//
// class ForwardDec
// {
// public:
// void PrintLove()
// {
// std::cout << "LOVE";
// }
// };
*/
void excution2(ForwardDec * dec)
{
//. ⑤
//. 이제 정의가 등장했으니 컴파일러는 FowardDec 이 어떤 클래스인지 잘 알고있다.
//. 로컬 변수와 함수를 시행 가능하므로 포인터를 넘겨받아 사용 가능해졌다.
dec->PrintLove();//-> (정상 작동)
ForwardDec dec2;//-> (정상 작동)
}




간단히 요약.


클래스의 전방 선언은 해당 클래스의 포인터를 통해 자료형에 맞는 데이터를 미리 적재할 수 있게 도와준다.

단, 내용 자체가 모두 선언된것이 아니고 이러한 자료형이 있다~ 정도만 알려주는 것이므로 포인터만 활용 가능하고,

 포인터를 통해 함수 시행, 변수 값 변경 등은 불가능하다.

하지만 클래스를 사용하겟답시고 클래스를 사용하는 모든 소스파일에 해당 클래스의 정의문을 헤더 파일 include를 강제하는 현상을 억제하여

결과적으로 소스의 컴파일 타임을 줄여준다.("include"로 집어넣는 것들은.. 그 파일에 해당하는 텍스트를 복붙해 준다고 이해하면 편하다)


함수의 전방 선언은 함수를 부를 수 있는 주소를 미리 지정해 두고 필요한 곳에서 선언할 수 있게 도와준다.

부르는 주소만 지정해 두기 때문에 구현부의 위치는 큰 상관이 없다.

+ Recent posts