꼰대 개발자~

푸념! 요즘은 과거 "성문법", "맨투맨"식 영어 교육시대를 살아가는 느낌입니다. 영어를 배우는건지 영어를 가르치기 위한 용어를 배우기 위해 공부를 하는지 알 수 없는 시대! 용어 보다는 실제로 경험해온 개발방법에 최근 정리된 방법론들을 해석해 봅니다. 

나 같은 고대(?) 개발자들은 아직도 애자일에 대한 적응이 힘들다. 솔까말 개발리소스를 최대한 갈아 넣어서 최대한의 이익을 낸다라는 느낌도 버릴 수 없고 워터플에 익숙하지만 시대의 흐름이므로 고대(?) 개발자로써 애자일에 적응해 보자.

간단히 애자일은 짧은 주기로 설계 - 개발 - 테스트 - 리스크분석의 주기를 반복하는 개발방법이다. 1-2주 정도의 기간동안에 할일에 대해서만 생각하기 때문에 설계와 분석에 대한 코스트가 적게 들고 계속해서 Client/Owner의 feedback을 받기 때문에 방향성의 공유와 사업의 변경에 유연하게 대응 할 수 있다.

고대 시대에 프로토타입 개발 방법론에서 좀더 유연한 개발을 강조한 개발방식되겠다. 고대 시대 프로토타입 개발 방법론의 최대 단점이 고객의 무분별한 개입과 조급함을 초래한다는 단점이 언급되었었는데 이걸 장점으로 승화(?) 시킨 방법론이라 생각할수있을듯... 

애자일이 성공하려면?

• 경영진의 의지 / 마인드가 제일 중요합니다.
  • 경영진이 장/단기 비전제시나 단기 계획에 대한 방향성을 위한 경영 정보를 공개하지 않는 성향이면 포기하세요.
  • 스크럼은 빠른 의사결정과 실행력이 최고의 장점인데 경영진이 보고를 통한 의사결정을 하려 한다면 포기하세요.
• 관계자 모두가 같은 큰그림을 보는것이 중요합니다.
  • 짧은 주기로 분석하고 일을 진행하다보면 자연스럽게 방향성을 잃어 버릴수있습니다.
  • 내가 만든 백로그도 못찾는 사태가 벌어지고 서로 상반되는 task들도 만들어집니다.
  • 이번 주기에는 교실을 만듭시다, 이번주기는 교무실이요 어? 우리가 뭘 만들고 있는거지?
  • 우리는 학교를 만들고 있다는걸 이 학교는 어떻게 만들것이라는거 구조가 변경될때 마다 변경된 최종 그림을 공유할 필요가 있다.
• 기간과 목표물이 명확한 프로젝트에 애자일을 끼워넣지 말자

개발프로세스 측면에서 애자일? ( JIRA가 요즘 거의 표준이지요? )

• SPRINT
  
  • 절차
    • 각종 요구사항 / 개선사항 / 개발요건등을 백로그에 쌓아 둡니다.
    • 스프린트 시작시점에 백로그에서 우선순위에 따른 개발 요건들을 스프린트에 넣습니다.
    • 담당자들을 배정하고 스프린트들을 시작합니다.
    • 스프린트를 마칠 시점에 업무들에 대한 평가를 하고 마치지 못한 일들에 대한 전략을 수립합니다.
    • 반복합니다.
  • 특징
    
    • 스프린트 계획 수립시 현재 개발 리소스 / 기간을 확정 할수있으므로 업무 분배가 쉽습니다.
    • 짧은기간에 성과와 리스크를 시각화할 수 있습니다. 잠재된 리스크를 빨리 발견하여 제거 할 수 있습니다.
    • 리더에 입장에서 보면 팀원들의 잘하는거 / 작업처리량등이 자연스럽게 드러나서 코칭 포인트를 찾아낼수있습니다.
    • 짧은 기간이지만 나름 계획으므로 스프린트 기간에 새로운 일감니나 리스크가 발생하면 스프린트를 유기하기 힘들다.
      • 스프린트의 변경을 최소화 해야합니다. 그런데 PM이나 PO입장에서는 일정이 중요하므로 스프린트 변경이 발생할수밖에 없다 -  이런 형태의 업무 / 비지니스 형태면 스프린트 하지 마세요.
      • 칸반 / 스프린트를 프로젝트 / 운영 타스크의 유형에 따라 분리 적용하세요. - 칸반으로 통일하자 스프린트로 통일하자는 꼰대입니다.
• KANBAN
  • 일감이 생길때마다 지라를 생성하고 담당자를 배정합니다.
  • 의사결정과 업무가 수시로 생기고, 업무가 외부에서 생기는경우 적합합니다.
  • 현재의 일감들의 상태를 한눈에 볼수있어서 좋습니다.
  • 그러나 성과 측정 및 마일스톤 및 목표점 찾기가 힘듭니다.
  • 보안으로 OKR과 TDD가 있습니다

조직 관리 측에서서 애자일

• Daily Sync / Stand up
  • 필수적으로 진행하는것이 좋습니다.
  • 그날 그날 하는 일에 대한 상세한 공유가 필요합니다.
  • 짧게 공유하고 더 논의가 필요한 부분은 따로 시간을 잡는것이 좋습니다.
  • 업무 지시나 방향성의 변화는 없는 공유에 의미를 두어야 합니다.
• 1on1 Meeting
  • Daily Sync를 통하여 스크럼을 생성했다 하여도 리더와 팀원간의 합을 맞출 부분이 필요합니다.
  • 무조건 들어주는 기술이 필요합니다.
  • 개인적인 관심사 / 고민등의 공유는 리더쉽에 지대한 영향을 미칩니다.
• Pair Programming
  • 주기적으로 하는것도 좋지만 어느정도 스탈이 맞았다면 필요시에만 하는것도 좋습니다.
  • 새로운 아키텍처나 프락티스의 도입시에 유용합니다.
• Code Review
  • 간단한 변경이 아니고 로직의 변경이 많은 경우 PR을 나눠서 하도록 가이드하는것이 좋습니다.
  • 공통 Lint를 적용하는것이 좋습니다. Lint가 만들어내는 변경사항은 PR리뷰를 어렵게 합니다.
  • 코멘트는 최대한 드라이하게 리뷰내용이 개인적인 습관의 문제라면 pair programming이나 1on1을 통하여 교정합니다.
  • PR에서 싸우지 않습니다 - 논쟁 발생시 당사자들을 모아서 해결합니다.
• 회고
  • 팀의 성과 / 개인 성과를 명확히 구분하여 공유합니다.
  • KPT 를 통하여 에로사항을 간접적으로 인지합니다.
  • Problem이 관계에 문제가 있다면 바로 결정하지 말고 pending하고 당사자들을 모아서 해결합니다.
  • 회고 준비도 상당한 시간을 소모하므로 정리하는 부분도 팀원들과 나누기 위한 아이디어가 필요합니다.

고대 개발자들의 애자일 리더쉽 전략

• "너의 성과는 팀의 성과다, 팀이 잘되야 너도 잘된다."라는 생각은 꼰대입니다.
  • 애자일의 성공여부는 개인의 역량과 동기부여가 전부입니다.
  • 개인의 성과를 모아서 팀의 목표 달성 / 성과를 만들어 낸다는 느낌입니다.
• 스프린트 시작때 task들에 대해 성과점수와 성과인정 방법에 대한 적절한 공유가 필요합니다.
  • 내가낸 성과인데 같이 먹는건 장기적으로 스크럼을 깨뜨릴수있습니다.
  • task들에 대한 테스트 방법등에 대해 질문하고 인정점위를 정합니다.
  • 이때 자연스럽게 왜 해야하는가와 목표가 설정됩니다.
  • 이때 성과 측정방식으로 Unit Test의 형태로 진행합니다 - 자연스럽게 품질도 보장되고 성과 측정도 됩니다. 

푸념! 요즘은 과거 "성문법", "맨투맨"식 영어 교육시대를 살아가는 느낌입니다. 영어를 배우는건지 영어를 가르치기 위한 용어를 배우기 위해 공부를 하는지 알 수 없는 시대! 용어 보다는 실제로 경험해온 개발방법에 최근 정리된 방법론들을 해석해 봅니다. 

간단히 얘기하면 Test Case / Test Environment를 만들어 놓고 개발하자! 라는 개념인데 이상과 현실이 공존하는 개발 방법론이다.

현재 domain에서 구현되어야 할부분에 대한 test를 구성하고 test가 잘 돌아가도록 프로그램을 완성하는 방법이다.

application을 다 만들고 구현하게되면 다른 개발자의 변경사항에 의해 병목이 생기고 실행 환경도 갖춰야 하고 여러가지고 고녁이다.

사실 test code는 복작한 남의 코드를 이해하는 가장 쉬운 방법이다.

그런데 공통모듈이나 아키텍처의 변경이 있을때는 그동안 개발한 unit test들을 모두 사용할수없으므로 unit test 리팩토링 하는 코스트가 사실 더 많이 듭니다. (성능개선, 리펙토링등의 작업에는 어울리지 않습니다)

그래서 DDD, CQRS가 같이 따라 댕기나 봅니다.

적절한 Infra Mock ( DB, Queue 등등 )의 활용과 적절한 test case만 잘 정의하고 개발하면 심각하게 빠른 개발속도를 경험할수있습니다.

푸념! 요즘은 과거 "성문법", "맨투맨"식 영어 교육시대를 살아가는 느낌입니다. 영어를 배우는건지 영어를 가르치기 위한 용어를 배우기 위해 공부를 하는지 알 수 없는 시대! 용어 보다는 실제로 경험해온 개발방법에 최근 정리된 방법론들을 해석해 봅니다. 

C++ 부터 java를 거치면서 수 많은 시행 착오를 거치면서 나름데로 OOP 설계/구현 원칙을 강요(?)해왔다. 이런 설계 원칙을 누군가 외쿡사람이 정의해 해왔네 이걸 실무적으로 얘기해 보고자 한다.

• S - Single-Responsiblity Principle (SRP)
  • 하나의 클래스는 하나의 일만 해야한다는 얘긴데...
  • 이건 실무적으로도 중요한 개념이다.
  • 하나의 기능에 관한 data / method / error등을 모아 둠으로써 변경에 대한 응집성을 높여서 변경에 대한 실수를 줄이고 코드에 대한 가독성 또한 높여준다.
  • 필수사항
• O - Open-Closed Principle (OCP)
  • OOP의 지향점인 추상화와 다형성에 대한 원칙
  • 쉽게 확장가능해야하고 변경발생시 다른 확장들이 영향이 미치면 안된다? 요렇게 정의해 볼까한다.
  • 간단히 얘기하면 if{ } else if{ }  else if{ } else {} 이런거 하지 말라는 말이다.
  • 요건 좀 아키텍트로서는 고민되는 부분이다. 대부분의 도메인들이 extend할수있을 만큼 constant하지 않기 때문이다.
  • 동적 데이터에 대한 switch, if-else pattern을 벗어 나려면 "Adapter pattern"을 통해서 OCP 부족한 점을 채울 수 있을듯...
  • 어찌되었던 디자인 패턴이니까 최대한 OOP의 다형성을 활용하자
• L - Liskov Substitution Principle (LSP)
  • sub class는 base class로 언제든 변환될 수 있어야 한다는 얘긴데...
  • 대부분의 언어들이 제공하는 casting을 통해서 sub class의 type을 몰라도 base class의 public property나 method에 접근가능해야한다는 얘긴데.....
  • java같은 signature가 있는 언어는 간단한데 C++같은건 조금 커스텀한 테크닉이 필요하다. 기본적으로 heap를 사용해야해서 C++같은 언어에서는 조금 유연하게 적용해도 될듯하다.
• I - Interface Segregation Principle (ISP)
  • interface의 구현도 통합하지 말고 기능별로 분리해라 라는 얘기입니다.
  • 최신의 신규 언어들도 언어적으로 지향하는 원칙으로 지키는것이 좋습니다.
  • 너무 많이 나누면 interface관리 자체가 burden이 될것입니다. 
  • 기능을 잘 분리하여 적절히 나눕니다.
  • scale / rust는 이런 이유로 interface를 trait 이라는 특성으로 분리 합니다.
• D - Dependency Inversion Principle (DIP)
  • 이것 역시도 상속을 통한 Event 수신을 하던 아주 오래된 패턴이다.
  • 공통로직을 base class에 담고 하위 class의 method을 참조할 필요가 있을때 추상화된 overriable method을 사용하여 하위 class에 종속된 기능을 추상화 하자는 얘기다.
  • 일반적으로 사용하는 callback, handler등이 이것에 해당된다.
  • 공통로직을 base class에 모아두고 sub class 특성을 담은 method만 추상화하여 로직의 통합한경우 즉 abstract class pattern들이 여기에 해당된다.

푸념! 요즘은 과거 "성문법", "맨투맨"식 영어 교육시대를 살아가는 느낌입니다. 영어를 배우는건지 영어를 가르치기 위한 용어를 배우기 위해 공부를 하는지 알 수 없는 시대! 용어 보다는 실제로 경험해온 개발방법에 최근 정리된 방법론들을 해석해 봅니다. 

EDD역시도 MSA의 보편화로 인해 파생된 개발 방법론인듯한다. Kafka, RabbitMQ등의 clustered message broker를 적극 활용하여 고가용/고성능, 손쉬운 확장성을 구현해 내기 위한 방법론이다.

이 개념 역시도 새로운 개념은 아니다. 꼰대의 입장에서 보면 Kafka 그 자체이다.

누군가 데이터를 만들어내고 (producer), 누군가가 그 데이터를 소비하며 ( consumer ), 누군가가 데이터를 소비(consume)하여 새로운데이터를 만들어(produce)에 낸다 ( aggregation ), 관심사는 topic을 통하여 분리한다. 

message broker를 통한 business의 구현의 다음과 같은 장점을 가진다.

• fire & forget이 가능하다.
  • producer는 필요한 시기에 데이터를 소비하고 원하는 시점에 데이터를 생산한다. 
  • peer의 performance  수신여부등에는 관심이 없다.
• feature 마다 route를 설정 할 필요가 없다.
  • 어디서 생성된 데이터 인지는 모르겠지만 내가 필요한 데이터를 소비하여 내 비지니스를 간단히 완성한다.
  • 어디서 쓸지는 모르겠지만 내가 만들어낸 데이터를 버리지 않고 생상해 낸다.
• bussines 확장이 용이하다.
  • 필요한 / 필요할지도 모르는 데이터는 최대한 생성해 두고
  • feature / bussiness 가 필요한다. aggregation하고 소비하여 완성하면된다.
  • 계속된 data aggregation / transform을 통하여 data의 품질을 높이고 단순화해 나가면서 복잡한 비지니스를 완성한다.
  • 이러한 이유로 기계학습 (DNN)에 많이 추천되는듯한다.

단점이 없는것은 아니다.

• broker의 장애는 전면장애다.
• data schema의 변경이 어디로 전파될지 모른다 ( 변경이 어렵다 )
• data producing및 latency의 변경이 어디서 문제가 생길지 예측하기 어렵다.

단점을 극복하려면

• 모니터링 강화
  • 어떤 변경이 어떤 영향을 미치지 모르므로 전체 시스템에 대한 견고한 모니터링이 필요하다.
  • infra performance - 경험상 이부분에서 거의 모든 이슈가 시작된다.
  • service별 perofrmance 
  • topic / parition별 performance
  • 데이터 흐름에 대한 visualizing
• domain간 data schema의 철저한 분리
  • clean architecture
  • 관리부서 domain간의 data schema를 변환하여 사용한다.
  • domain간 schema 변경 및 로직의 변경이 consumer들의 data driven에 영향을 미치지 않아야한다.
• data schema versioning & registering
  • 아무리 data schema를 분리하여도 외부 schema 변경이 없을수는 없다.
  • data schema에 version을 두어 consumer가 분리하여 처리 할수있도록 한다.
  • data schema에 대한 registering을 통하여 consumer가 consumming schema를 검증할수있도록 한다.

Actually It is not easy to manage programmers. They have really strong color, self-respect and etc. because They work in creative part including me(^^). On the another hand, Organization like company wants them to be one, share the techniques, experiences and so on but it is a dream.

So Then, What is the middle point between organization and programmers?

One thing is that consultant involved like "System architectures". They do modeling and establish architecture and frameworks and then programmers develop the each modules which is liable for each programmers BUT Unfortunately in Korea, companies or customers usually do not admit expense of architecture or consultant.

Ok! Now, The optimal alternative solution for Korean development environment is "Prototyping". The merits of prototyping is below.

1. Easily understand the model of to implement system.
2. Easily communicate with customers, programmers.
3. Programmers does not need to admit that they could not understand the model of to implement system.
4. Can establish the model of to implement system in some sort
5. Can establish the architect or framework in some sort.
6. Consequently the cooperation goes well because everyone understand the system to implement

Of cause needs some more expense for the "Prototyping" but think of it! How many expense have we spent because We proceeded the project without understanding the system.

Nowadays computer software systems are getting bigger and complicated. So programming software is also getting harder and difficult. Software is not any more written by just one person because it is already big enough as much as impossible to write easily but writting a software with many people is not easy either. People should be accordance with each other perfectly. Unfortunately people have different colors, education status, skills and way to write.

So then, what is the solution?

One of the solutions is to limit people’s intensive freedom in above reason, frameworks can be a appropriate solution. Defines a liable frame for the certain system then, programmers write parts of software in the frames.

If we can use frameworks and communication tools such DFD ( Data Flow Diagram ), Functional chart, Entity diagram, Entity specification and so forth. Finally, we can make a system has highest quality productively.

한 스타트업에 근무할때 였다. 그회사는 수많은 프로젝트를 진행중이었으며 모든 인프라는 AWS에 존재하였다. 

모든 인프라에 대한 구조, 위치 계정 정보는 관리 되지 않았고 인프라 삭제/생성도 모두 개인 역량에 집중하여 AWS Consol에서 작업중이었다, 물론 인프라 모니터링 조차도 존재하지 않았다.

나는 플랫폼을 개발하기위해 입사하였지만 ... 첫번째 목표는 인프라 관리 였다.

인프라 관리를 자동화하고 관리 이력을 남기며 모니터링 또한 가능해야했다.

그래서 시작된 brand-new XXX infra project

먼저 terraform을 통한 code base infra management를 구축하기위해

https://www.terraform.io/

을 분석하기 시작했다.

너무 멋지게도 AWS INFRA를 생성/삭제 해주었지만 multi-stack, multi-environment에 너무 많은 코드가 중복되었다.

하여 도입하되 된것이 

https://terraspace.cloud/

이다.

terraspace는 terraform을 돕는 framework으로써 stack / environment간의 코드 공통화를 지원하고 있었고 공통 인프라 생성을 성공적으로 마쳤다.

서해대교 계측관제 (Visual C++, Direct3D)

3D로 관련 건축물을 모델링하고 각 부분에 설치된 관측 장비로 부터 수신된 데이타를 통합 표시하고 다리의 뒤틀림과 움직임을 보여준다.

서해대교의 전체를 모델링하고 형상관리, 각각의 센서의 위치와 각 데이타를 표시, 화면 확대/이동/회전을 통하여 자세한 형상관리가 가능

센서의 데이타값을 기반으로 형상의 뒤틀림등을 시각적으로 볼수 있다.

각각의 센서는 필요시 디테일한 내역을 볼수 있다.