어플리케이션 개발의 흐름

요건파악

1. 요건파악이란

• 어플리케이션의 존재 이유는 유저의 고통점(니즈)를 해결하는 것에 있습니다. 어플리케이션이 어떤 니즈를 충족해 줄 수 있는지 요건을 파악하고 그 요건에 맞는 어플리케이션 개발은 개발 시 가장 먼저 이루어지는 액션이자 가장 중요한 액션입니다.

2. 요건파악에서 주의할점

• 유저의 요건 충족은 보통 프론트를 통해서 시각적으로 이루어질 시에 효과적입니다. 때문에 유저의 요건을 만족하는 프론트를 먼저 구상하여 요건을 만족하고, 그 프론트를 베이스로 큰 단위의 설계를 시행해 나갑니다.

요건에 맞는 설계

1. 설계란

• _기본 설계가 중요한 이유는 세부적인 알고리즘은 몇 번이고 리팩토링을 통해 수정해 나갈 수 있지만, 전체를 구성하는 설계는 변경하기가 쉽지 않기 때문입니다. _나무는 평생 몇 번이고 잎을 떨궈내고, 잔가지를 키워내며(리팩토링) 성장해 나가지만, 그 기둥이나 뿌리의 위치를 바꾸거나 모양새를 바꾸지는 않습니다. 어플리케이션도 이와 마찬가지 입니다.

• 설계란 요건을 실제 시스템에 녹이는 작업입니다. 설계에는 기본설계, 세부설계, 알고리즘설계로 이루어지는데, 하는 일은 같습니다. 다만 粒度(레벨감)가 다를 뿐입니다.
  설계를 하는 방법자체는 기본설계든, 구체설계든, 알고리즘설계든 모두 동일합니다. 중요한 것은, 기본->구체->알고리즘으로 粒度을 점점 좁혀나가며 세부적인 설계의 모양세를 갖추어나가는 것입니다.

기본설계

• 시스템의 가장 기본적인 흐름을 만들어 나가는 과정입니다. 가령, 「 DB - 어플 - UI 」와 같은 형태가 되겠군요. 이를 조금 더 구체화할 수도 있는데, 이는 플로우차트를 통해 구현할 수 있습니다. DB여도 여러개의 DB가 있다면, 혹은 클라우드내에서 여러 서비스를 거치게 된다면 복잡할 수 있으므로, 플로우차트를 통해 구현하면 이해하기 쉽습니다.
• 어플리케이션을 개발할 때는 요건과 사용언어 환경에 맞는 다양한 가이드라인이 필요합니다. 가이드라인은 결정하면 되는 문제지만, 한번 정한 가이드라인은 설계상 쉽게 바꾸기가 어려움으로 경험이 축적된 가이드라인은 중요합니다. 예를 들어 API를 개발 한다고 할때, API의 URI설계는 어떻게 할지, GET/POST의 메소드 활용은 어떻게 할지, request/response 포맷은 어떻게 할지 모두 일일이 정해야 합니다.
   이때, 기존의 가이드라인을 사용하면 매우 유용합니다. 위에서 예로든 API의 경우에는 [api guideline]이라는 키워드로 검색하면 많은 경험이 축적된 가이드라인들을 조사할 수 있습니다.

구체설계

• 파일단위의 설계 혹은 시스템보다는 조금더 구체적인 粒度를 통한 설계를 의미합니다. 시켄스도를 통해 구현할 수 있습니다.

알고리즘설계

• 알고리즘 설계는 매우 구체적인 행단위의 설계입니다. 알고리즘의 불완전성, 알고리즘의 성능・속도(bigO를 고려)하는 것이 알고리즘 설계에 해당하게 되겠네요.

2. 설계시 주의점

• 설계시에는 시스템단위(디비, 어플, 인터페이스와 같은 큰단위의 기본설계: 플로우차트) -> 파일단위(세부설계 : 시켄스도) 레벨로 점점 좁혀나가며, 각 시스템과 파일의 인풋 아웃풋 정도로만 고려합니다. 행단위의 매우 세부적인 알고리즘의 설계는 일단 고려하지 않고, 파일단위의 세부설계가 끝난 후 탑다운으로 粒度를 구체화시켜가며 고려합니다.
• 설계의 흐름을 보며 각 부분에서의 리스크를 미리 판단 후, 그 부분에 주의를 기울입니다.

프로토타입 개발

1. 프로토타입개발

• 프로토타입이란 완전체가 아닌 1. 데이터가 일단 흐르기는 하는, 2. 유저의 최저한의 요건을 만족한 매우 초기 형태를 의미합니다. 무엇이든 처음부터 완전할 수 없습니다. 특히 어플과 같은 경우는 모든 경우의 수를 고려하기가 사실상 불가능하기 때문에 더더욱 그렇습니다. 처음에는 프로토타입으로 일단은 움직이는 것을 만들어내고, 피드백을 통해 점점 진화시켜 나갑니다.

2. 프로토타입 개발 시 주의점

• 요건은 보통 프론트에서 나오기때문에 설계를 그릴때는 프론트에서 역으로 시작하고 , 실제 개발 시에는 디비부터 실장합니다. DB는 어플리케이션 전체에 영향을 미치는 가장 안쪽의 요소이니까요.
• 처음부터 완전한 어플을 만들지 않습니다. 아니 그렇게 못합니다 절대. 프로토타입이란 최소한의 요건을 만족한 최저로 움직일수 있는 것입니다. 처음에는 볼품없게라도 라도 움직이는 실체를 만들고 이후에 점점 피드백을 통해 고도화합니다.

V설계에 맞는 도큐먼트의 준비

요건정의

• 요건시나리오
  • 정상 패턴
  • 비정상패턴
• 비기능요건 : 성능, 레이턴시 등

기본설계

• wireframe
• mock(bootstrap studio)
• 시스템 구성도
• 네트워크 구성도
• 기능일람서
• 화면 사양서
• DB정의서
• swagger
• Redis KVS
• API일람
• 시켄스도
• ER도

세부설계

• 세부설계서
  • 함수의 인풋, 아웃풋

単体테스트

• jest같은 프레임워크를 이용한 자동화스크립트

結合테스트

• 결합테스트시나리오
• 성능테스트
• 세큐리티테스트
• 리리즈 판정서
• 유저빌리티 UX

노래부르는 감

1. 자세를 곧추세우기

2. 턱을 당기기

3. 배에 힘줘서 공기를 내밀기

4. 턱밑에 힘이들어가면 오래못부름. 턱밑에 힘이들어가면 안됨

- 소리를 내기위해 턱을 내리면 턱밑에 힘이 들어가므로, 턱을 내리는 대신 입 윗부분인 광대를 들어올려 입을 벌린다.

분할정복 알고리즘

한번에 정복하기 힘든 문제가 있을때, 이를 세부적인 부분까지 나누어서 분할한뒤 각 문제를 해결후, 분할된 요소를 합병하는 것

인수분해

의미있는 축을 기준으로 대상을 나누어 각 부분에서 해결 방법을 찾는것.
예] 맥도날드의 매출 증가를 찾기 위해, 연령대/시간대로 나누어 특정 시간대의 연령 대릉 공략하는 전략을 세운다

분할 정복 알고리즘 == 인수분해

파이를 한입에 먹을 수 없다면, 먹을만한 크기로 나누어 먹어라!

각개격파!

분할 정복 알고리즘은 컴퓨터 공학과 수학에서 주로 쓰이는 개념이고, 인수분해는 비즈니스에서 주로 쓰이는 개념이다. 하지만 본질은 결국 같다.

분할 정복 알고리즘,인수분해와 What 트리의 관계

What 트리는 하나의 대상을 분해해 나가는 과정을 트리로써 나타낸 것이다. 분해해 나가는 과정자체는 위에서 언급하는 분할정복 알고리즘, 인수분해와 동일하다. 즉, What 트리에서 대상을 분해하기 위해서 사용하는 방법이 분할정복 알고리즘, 인수분해이다.

분할정복 알고리즘과 인수분해의 공통점과 차이점

• 공통점 : 양쪽 모두 덩어리째 생각하기 어려운 과제에 대해, 그것을 구성하는 구성요소로 잘게 나누어 생각하는 것이다. 이때 구성요소를 나누는 기준으로는 축이 사용될 수 있는데, 의미 있는 축으로 분할하여 그 분할된 부분에서 해결책을 마련한 후 합병하는 것이다.

• 차이점 : 프로그래밍 경우 시스템을 구성하는 구성요소를 물리적/논리적 기준으로 명확하게 구분할 수 있지만, 비즈니스의 경우 축의 기준에 따라 인수분해의 결과가 달라지기 때문에, 의미 있는 축(기준)을 잘 선정하여 그 기준에 맞는 구성요소를 분해해야 한다는 차이점이 있다.

\*프로그래밍의 예: 네트워크의 구성-> ec2, elb, subnet, vpc...  
\*비즈니스의 예: 회사의 구성-> (부서를 기준으로) 인사부, 법무부, 개발부, 영업부.. (자본을 기준으로) 부채, 누적 자본...

인수분해는 문제해결프로세스에서 어떻게 활용될 수 있는가?

탐색형 문제/발생형 문제의 정의를 명확히 한다.(구글 도큐먼트에선 paraphrasing이라고 표현함.. 정말 적절한 표현 같음)

• 정의의 구체적인 방법
  • 문제란 목표와 현상의 GAP이므로, 목표와 현상을 명확히 할 것
  • 문제를 명확히 하기 위해 주어진 과제를 목적형으로 바꾸어 목적을 명확히 할것
    • 특히 실전에서는 다듬어지지 않은 워딩이 등장하여 문제를 해결하는데에 혼란을 주므로 목적을 명확히 한 후 목적을 띈 워딩으로 수정한다.
  • why 트리를 통해 상위의 배경을 고려
  • 구체화(5 W1 H)
    • 명확하게 정의되지 않아 이후 혼선이 발생할 수 있는 키워드들을 명확하게 정의한다. 예를 들어, 「볼빅의 매출을 높이기 위해서는」이라는 문제가 주어진다면, 볼빅들 중에서 몇 ml의 볼빅을 의미하는지 명확히 할 수 있겠다.
  • (optional)탐색형 문제를 발생형 문제로 바꾸어 생각해 볼 것
    • 가령, 「영어를 말할 수 있기 위해서는」이라는 문제는 「영어를 말할 수 없는 이유는」이라고 생각해서 그 원인을 해결하는 해결책을 입안하는 것이 어프로치하기 쉽다.

탐색형 문제/발생형 문제의 정의를 근거로, 과제형 문제/발생형 문제에서 주어진 키워드가 어떠한 구성요소로 이루어져 있는지 파악한다.

• 과제형 문제

  • 위에서 언급한대로 비즈니스 사이드는 인수분해가 축의 설정에 따라 달라지므로, 축설정이 중요하다. 그런데 문제를 접하고 어떤 축으로 나누면 의미있을지 곧바로 생각해내는 것은 그 문제에 대한 배경지식의 풀이 있지 않는한 쉽지 않다. 이를 돕기 위한 것이 축설정의 프레임워크이다.

    프레임워크는 MESE의 논리를 이미 가지고 있는 검증된 축이므로 문제의 인수분해에 있어 큰 도움이 된다. ppt자료를 만들때 레퍼런스가 있고 없고의 차이를 크게 경험해봤을 것이다. 레퍼런스는 요건에 따라 완벽하지는 않지만 사고에 큰 도움이 된다. 축의 프레임워크는 이러한 레퍼런스와 같다.  
    예를 들어, 긍정적/부정적, 내부/외부, 온/오프, 개인/환경, 물리적/정신적, 의식적/무의식적, 공급/수요/, 사람/물건/돈/정보, 연령/성별, 사회인/학생, 시각/청각/미각/촉각/후각, 개인/법인, 신규/기존, 프로덕트/서비스, 가상/실제, 사적/공적, 질/양, 4p(product, price,place,promotion).

• 발생형 문제

  • 발생형 문제 해결의 핵심은 원인 분석이다. 피상적인 원인 분석부터 시작하여 근본적인 원인 분석으로 이어나간다. 근본적인 원인의 분석은 원인에 대한 원인의 규명을 반복하여 접근한다. 이렇게 나뉘어진 원인의 계층에서 각 층의 원인은 피상적이든 근본적이든 해결책 마련의 근거가 된다. 이때 원인 분석은 MESE의 의해서 종류가 나뉘어지면 좋지만(생각이 누출을 막기위해), 이러한 구분보다 중요한 것은 근본적 원인을 밝혀내는 것이라는 방향성을 유지하는 것이다.

  • 발생형 문제의 원인을 파악해 나갈 때, 인과관계의 粒度가 충분히 구체적인지 고려해야한다. 예를 들어, 「꽃가루 알레르기 환자를 줄이기 위해서는」이라는 문제에서, 「꽃가루 -> 알레르기 발생」 이라는 인과관계는 중간의 세부적 인과관계가 생략되어 수많은 정보를 놓치고 있다. 이를 더욱 구체적인 인과관계로 분석하면 다음과같다. 「꽃가루 -> 꽃가루가 공기로 전달 -> 공기를 흡입 -> 기관지에 쌓임 -> 기관지에서의 방위작용 -> 기침,눈물 등의 알레르기 발생」 어떠한가? 이처럼 인과관계를 세부적으로 나타내면 그만큼 더욱 세부적인 원인을 분석할 수 있고, 세부적으로 발전한 원인에 대해 더 많은 해결책을 마련할 수 도 있다.

  • 공통

    • 축의 설정에 어려움을 겪는 문제라면, 귀납적 인수분해를 사용한다. 귀납적 인수분해란, 개별적 해결책을 생각하기는 비교적 쉬우므로 개별적 해결책을 우선적으로 생각한 후 각 해결책에 맞추어 역으로 축을 재구성해 나가는 것이다. -> 개별적
    • 인수분해를 시행할 시 그 구성요소는 stock혹은 flow(시간적 flow, ... )로 나뉘게 된다.
      stock적 구성요소 : 어플리케이션(DB- 클라우드 -어플 - 인터페이스), 신체(머리-팔-다리-몸통)
      flow적 구성요소 : 승진(퍼포먼스 - 평가 - 승진결정)

생각하기 좋게 나뉜 각 구성요소에서 해결책을 마련한다.

우선순위에 따라 해결책의 순서를 구체적으로 정한다.

-   우선순위를 메기는 기준은 다음과 같다 : 1. 해당 작업은 다른 작업에 영향을 미치는가? 2. 데드라인이 존재하는가?

bottom up/top down의 방법으로 검증한다.

예

• 과제 : 면접을 잘 보기 위해서는 어떻게 해야 할까?

1. 과제/문제

   과제형 문제/발생형 문제의 정의를 명확히 한다.

   • 면접이란 무엇일까? 면접은 무엇을 위한 것일까?(why so/so how로 상위의 배경을 고려)
   • 면접이란 「회사, 회사 사람들, 직무와 어울리는 지원자를 판단하는 것」이라고 정의(구체화)
   • 판단이란 객관적 기준과 주관적 기준에 의해 나뉜다.
   • 객관적 기준 :「명시된 기준을 통해서 in/out을 결정하는 것」
   • 주관적 기준 :「함께 일하고 싶은 사람인가?같이 맥주한잔 마시면 재밌을까?」*여기에선 객관적 기준만 생각하도록 한다.

2. 과제/문제

   과제형 문제/발생형 문제의 정의를 근거로,

   대상의 정의가

   과제/문제~

   과제형 문제/발생형 문제에서 주어진 키워드가 어떠한 구성요소로 이루어져 있는지 파악한다.

   • 면접의 정의 : 회사,회사 사람들,직무와 어울리는 지원자를 명시된 기준을 통해서 in/out을 결정하는 것
   • 키워드 : 회사, 회사사람들, 직무, 지원자, 기준
   • 회사가 요구하는 기준, 직무가 요구하는 기준
   • 지원자의 구성요소 : 경력, 성품
   • 지원자의 경력,성품이 회사가 요구하는 기준, 직무가 요구하는 기준과 맞는지?

3. 생각하기 좋게 나뉘어진 각 구성요소에서 해결책을 마련한다.

   • 회사가 요구하는 기준 조사
   • 직무가 요구하는 기준 조사 : 무엇을 하는지를 통해
   • 지원자의 경력 중 회사가 요구하는 기준과 직무가 요구하는 기준을 매칭시키면서 준비하기

4. 해결책의 순서를 구체적으로 정한다.

   1. input조사

      • 이메일, 면담할때 이야기해준 정보들,공유석
      • 회사가 요구하는 것, 직무가 요구하는 것을 나누어서

   2. input에서 기준을 추출

   3. 나의 경력사항 중 기준에 맞는 것들을 찾아서 스토리 만들기

      • 스토리를 만들때의 주의사항도 input에 나와있음
      • 예를 들어, try fail finally의 구조로 말하기

5. bottom up/top down의 방법으로 검증한다.

• [] 일본에서 한국카드로 원화송금 : 환율에 따른 계산필수
• [] 엔화를 스미신 은행 계좌에 넣기
• [] 스미신 계좌에서 비트뱅크로 송금
  • ****이때 계좌 송금명 BSGP98218キムダスル
• [] 비트뱅크에서 코인구매 후 송금
• [] 업비트에서 송금 확인후 매도
  • ****기존에 있는 리플 같이 팔지않도록 주의

https://www.youtube.com/watch?v=dudfGFb47mc&t=210s

이미지가 너무 많아서 구글 클라우드에 업로드

• 디자인 씽킹으로 할 수 있는 것

  1. 문제의 원인 파악
  2. 과제/문제자체의 선정

• 전제
  디자인 씽킹의 첫번째 단계는 공감하기이다. 공감하기는 유저가 존재한다는 것이 기본 전제이므로, 디자인씽킹의 사전 작업으로써 구체적 유저를 선정한다.

• 프로토타입 만들시 주의사항
  1. 프로토타입을 만들기 전에 유저에게 필수적인 최소한의 조건만을 조사하여 시제품을 만든다.
  2. 싸고 빠르게 만들어서 진화가 가능하도록 만든다.
  3. 프로토타입과 사랑에 빠지지말고 언제든지 전부 부숴버릴 수 있어야한다.

왜 갑자기 스케치?

내가 무엇인가를 만들어냈다는 느낌이 무척이나 좋다.
노트랑 연필만 지니고, 스케치를 하는 사람을 볼때면 무척이나 부러웠다. ' 나도 그려보고 싶다' 라고.

스케치를 가볍게 하는 팁

• 선에 대하여

  • 그림은 눈으로 그리는 것. 보인 만큼 우물쭈물 선 긋지말고 시원하게 길게 그어라
    • 선을 짧게 짧게 나누어 그리면 시야가 그만큼 밖에 보이지 않는 것
  • 그림을 그리기 위해서는 관찰한 사물의 잔상이 흰 종이위에 표시될 만큼의 관찰이 필요하다.
  • 끊어진 선은 이쁘게 이어 나가라
  • 선은 한 종류가 아니다. 쭉 이어지는 선도 있고, 빛에 의해 명확하지 않은 떨리는 선과 같은 선도 있다.(떨리는 선은 펜을 길게 잡고 힘을 완전히 빼고 그리면 그리기 쉽다)
    - 일반적인선(강시강끝)
    - 약시강끝(약하게 시작해서 강하게 끝남)
    - 강시약끝
    - 약시약긑
    - 파선(선이 점선처럼 중간중간 잘려있는 선)
    - 요선(선이 묘하게 흔들리며 그어지는 선)
  • 빛에 의해 선이 묻힌 경우 떨리는 선으로 그리면 매우 자연스럽다.
  • 선을 쭉 그렸을 때 선의 끝 꼭지점이 튕기지 않게 그린다.
  • 선은 꼭 매우 일자가 아니여도 된다. 살짝 울퉁불퉁 하지만 길게 이어 나가는 맛이 어반 스케치의 묘미다
  • 선을 빠르게 쭉그을 건지, 천천히 그을 건지.
  • 크로키를 그릴땐 명암도 선으로 간단히처리, 옷의 주름도 선으로 간단히 처리 이게 또 묘미. 크로키 하나당 10분안에 그린다고 생각할 것. 멋진 크로키는 이연의 그림 참고

• 명암에 대하여

  • 명암이 너무 다양한 방향으로 그리면 볼 때 산만하다.
  • 선으로 그릴 수 있는 부분과 명암으로 그릴 수 있는 부분을 잘 나누어라.
  • 화이트벨런스를 맞추기(내가 그리는 그림 내에서 가장 어두운 포인트와 가장 밝은 포인트를 발견 후, 어두운 부분은 얼마만큼 어둡게 그릴건지 밝은 부분은 얼마만큼 밝게 그릴건지)
  • 명암을 모든 그림에 적용해 그리기는 어렵다. 때문에 서로 독립적인 부분은 화이트밸런스가 다르더라도 다른 명암을 적용한다.
    예를 들어, 배경과 배경 위의 레이어에 있는 사람 얼굴을 그릴 때, 절대적 화이트 밸런스라면 흑백사진을 찍은 것처럼 얼굴에 대한 화이트기준과 배경에 대한 화이트 기준이 절대적으로 동일해야하지만, 스케치를 할때는 상대적 화이트밸런스를 적용하도록한다.
    상대적인 화이트 밸런스란 그림 내에 독립된 오브제라면, 각 오브제의 화이트 밸런스르 상대적으로 다르게 가져가는 것이다. 가령 얼굴의 화이트 밸런스가 100이라면, 배경의 화이트 밸런스는 50으로 가져갈 수 있다.

• 구도에 대하여

  • 가장 상위 레벨의 구도는 정확하게 그려준다.
  • 하위 레벨의 구도들은 상위 구도에 영향을 미칠만큼 중요하면 정확하게 그려주고 아니라면 어림짐작한다.
  • 익숙해 지면 상관 없지만, 기초 구도는 그리는 게 좋다.(사람의 실루엣이라던지)

• 얼굴그리기

• 몸그리키
• 기타
  • 펜을 잡을 때 힘을 주어 잡으면 잘 그려지지 않는다. 농구할 때와 마찬가지로 손 근육에 힘빼고 뼈를 움직여 그린다고 생각하라.
    • 드로잉은 머리가 아니라 몸으로 하는 것
      • 완성했을 때 몸이 그것을 기억하도록 틀리면 틀리는 대로 그려나가기
  • 마음에 안들어도 그리기로 한만큼은 꼭 완성하기
  • 필요한 만큼만 그린다 : 복잡함을 지양하고 심플하게 알아볼 수 있을만큼만 그려서 부담을 줄이자는 의미
  • 주변의 사물을 많이 그려본다.

하고 싶은 일에 대해 구체적으로 조건을 나누어 본적이 없다.

다음글의 작가의 글을 보고 현재의 나의 처지나 아직 닿지못한 미래의 나의 처지도 이와 비슷할 것 같다는 생각이 들었고, 그의 고민은 나의 고민이 될 수 있겠다는 생각이 들었다,(https://brunch.co.kr/@jaihie/13)

・많은 돈은 아니더라도 최종적으로는 달에 2~3천정도는 벌고싶다.

・명예는 그리 신경쓰지 않는다.

・나를 지속적으로 발전시킬 수 있는 직업이면 좋겠다.

・년에 3~4번 정도는 해외를 나갈 수 있는 직업이면 좋겠다.

・경제적으로나 시간적으로 수연이와 잘 살 수 있는 직업이면 좋겠다.

・일주일에 2번정도만 잔업하는 직업이면 좋겠다.

・하루를 돌아볼 수 있는 여유가 있는 직업이면 좋겠다.

・피는 꽃을 보고 무엇인가 느낄 수 있는 여유가 있는 직업이면 좋겠다

・개인에게 주어진 아웃풋이 명확하여 정치가 빈번하지 않은 곳

・일이 너무 루틴화 되어 있지 않고, 어느 정도 창의적으로 일 할 수 있는 환경이면 좋겠다 => 글을 쓰는 것, 문제의 원인을 파악하고 문제를 해결하는 것 이 모두 무언가를 계획하는 것으로 무언가를 계획하는 것은 마치 소설을 읽고 쓰는 것과 비슷하다는 생각이다. 인과관계에 따라 가설을 만들어나가고, 가설을 검증하는 프로세스가 재미있다.

어떤 역에서의 우리아게 : 손님수 * 손님당 평균 단가

손님수 : 우메다역의 유동인구 * 편의점선택률