1. Tomoyuki arima

    • 회사의 얼굴을 만드는 브랜딩을 메인으로 하는 회 사
    • 디자인은 어떤것? 이란것보다 디자인을 해야할 필요성을 느끼는 요소에 커밋을 하는걸 좋아함.
    • 에니메이션 커버디자인은 당연히 보고 만드는 거지 ?*
    • 일하면서 터득한, 모야모야 하는 이미지(감각)를 구체적인 디자인으로 커밑해나가는 과정이 있냐? *
  2. Yu tae han

    • 엑센츄어의 디자인은 정확히 하는일이 뭐야? #비쥬얼 디자인에 관한 일을 한다네
    • 인정받기 위해서 공모전같은 경력을 존나쌓았구나…
    • 디자인은 보통 b2c 라고 생각하는데, 소비자입장에서 이게 먹힐지 어캐암?*
      • 요건을 정의한 뒤 -> 설계한 뒤 -> 실장?*
      • 디자인에서는 요건을 어떻게 정의함?*
      • v모델은 예술에도 적용이 될 수 있게구만
    • 창조력은 어디서 오는가?*
    • 난 아무래도.. B2C랑 맞는 거같아. B2C기획/ 개발/디자인 등
    • 브랜딩 : 광고의 이미지 -> 기업이 제공하는 전체적인 체험
    • 비쥬얼 디자인 : 기업의 유니크를 비쥬얼로 구체화하는 것
    • 사진적/구체적 -> 추상화/상징화 (예를 들어 인스타그램 아이콘)
    • 유쵸의 비쥬얼 적인 특징을 추출 : 그린, 글자에서의 커브
    • 기업의 상징적인 비주얼 이미지는 어떤 요소에서 찾음? 로고? 폰트?*
  3. 패널 디스커션

    • 비즈네스에서 디자인은 어덯게 가치를 낼 수 있을까?
      • 아리마 : 디자인 바꾼다고 매출이 바로 는다고 많은 질문을 받는데, 그건 아니라고 답한다. 브랜딩을 하면서, 오히려 회사쪽에서 '아 우리 이런 가치를 가지고 잇구나' 하고 재정의하는 경우도 생김
    • 좋은 디자인이란 무엇인가?
      • 아리마 : 이질문은 좋은 디자이너란 누구인가 로 대신할 수 있겠다. 내가 존경하는 디자이너 000 마커스* 본 애플 디자이너가 있다. 그가 존경받는 이유는 디지털 세대의 인터페이스를 새롭게 창조한 인물이기 때문이다. 유 : 전하고 싶은 게 전해지는 게 좋은 디자인이라고 생각함
  1. 질문

    • 디자인을 할때 어디까지 완벽성을 추구할지 타협은 어떻게 하나?:

    • 모야모야를 어떻게 구체화해나가는지

      • : 싸이클을 빠르게 하기 위해서 종이로 스케치하지 않는다. 프로토타입 제작 도중 파일은 남기지 않고 다 없애버림. 빠르게 완성형을 만들어야 한다면 설계를  거치지 않고 바로 실장을 시작한다. 가설을 빠르게 진행해서 안좋은 가설을 빨리버려버림
    • 고객한테 먹힐지 어떻게암?

      • : 사실 모름. 경험치로 밖에 알수없음
      • : 영화와 같다. 실제 겪어서 결과가 나오지 않으면 모름. 가장 믿음직한건 나마데이터. 예상 타겟에게 물어보고 결과를 추론한다.
    • 이미지는 어디서찾음?

      • : 보통 창립자에게 기업의 이야기를 듣는다. 기업의 정신성을 참조한다던가, 눈에 보이지 않는 추상적인 것으로부터 요건을 정의하는 경우가 많음.

 

 

글의 구조파악 하는 법

  1. 글의 구조를 파악하는데 있어서 가장 중요한 마인드 ; 인과관계의 파악
    독해 뿐만 아니라 말하기, 듣기, 쓰기에 있어서도 가장 중요한 기본 생각은 내용 전체의 인과 관계를 파악해 나가는 것이다. 어떤 사건은 다른 사건의 원인이기도 하며 결과이기도 하다. 그 인과관계의 고리를 잘 이어나가는 것이 독해의 핵심이다.
사건1의 원인    →    사건1    →    사건1의 결과
(사건1의 결과 = )사건2의 원인    →    사건2    →    사건2의 결과
(사건2의 결과 = )사건3의 원인    →    사건3    →    사건3의 결과
(사건3의 결과 = )사건4의 원인    →    사건4    →    사건4의 결과

예,

마이너스 기준금리    →    마이너스 예금금리    →    은행 예금 감소
은행 예금 감소    →    은행 대출 감소    →     투자감소
투자감소    →    기업실적 악화    →    고용감소
고용감소    →    소비심리위축    →    소비감소

소비감소    →    기업도산    →    경제파탄

경제학적으로 정확한 인과 관계인지는 모르겠지만, 위와 같은 예에서 두 가지 중요한 사실을 알아 낼 수 있다.

하나, 어떤 사건은 다른 사건의 원인의 되기도하고 다른 사건에 의한 결과이기도 하다.
둘, 경제파탄이라는 최종결과의 최종원인은 마이너스 기준금리다. 인과관계의 최종목적은 지속적인 원인을 파해쳐 가장 핵심적인 원인을 알아내는 것이다.

  1. 5W1H : Who When Where What How + Why(인과관계)
    위에서 언급한 바와 같이 인과관계는 사건의 핵심을 알아내고 사건의 의미를 파악해 볼 수 있다는 점에서 가장 강력한 무기이다. 하지만, Who When Where What How + Why(인과관계)에 의해 사건을 구체적으로 파악하는 것도 글의 정보를 캐치해내는 중요한 능력이다.

지문 유형별 구조 파악법

ⅰ. 소설

  1. 등장인물 간의 갈등관계 파악 : 소설의 핵심은 등장인물. 등장인물 간의 갈등(사이가 나쁨)・비갈등(사이가 좋음)・등장인물의 자기갈등・자기 비갈등의 심리적 원인을 파악하는 것이 중요하다.
  2. 갈등의 인과관계 파악 : 등장인물 간의 갈등・비갈등 관계가 어떠한 원인으로 발생하게 되었는지 파악한다.
  3. 사건의 파악 : 인물간의 갈등・비갈등 관계는 정적이지 않다. 사건을 통해서 그러한 갈등・비갈등 관계가 끊임없이 변화한다. 어떠한 사건이 어떠한 의미를 가지고 인물간의 관계를 변화시켜는지 파악한다.

ⅱ. 신문

신문에서 중심이 되는 사건이 제목으로 나타난다. 글의 내용을 통해서, 중심 사건의 원인이 무엇인지, 또 그 사건으로 인해 어떠한 결과가 나타나는지 인과관계를 파악한다.

ⅲ. 논문, 인문학서 등

인과관계를 파악하는 것은 다른 유형과 마찬가지 이지만 두 가지 이유로 독해의 난이도가 가장 높은 유형이다.

  1. 신문이나 잡지처럼 글이 짧지도 않고
  2. 필자가 비교적 독자의 독해력을 높게 기대하고 글을 쓰기 때문에 글을 친절하게 정리해놓지 않기 때문이다. 즉, 복잡하게 얽힌 글에서 키워드를 파악하고 그 키워드 간의 인과관계를 파악하여 필자가 하고싶은 말과 잘 연결 시켜야 한다. 각 장의 큰 제목은 필자가 말하고자 하는 바를 찾는데 큰 도움이 된다.
  • 이해가 어려운 문장의 확실한 이해를 증명하는 방법은, 어려운 문장을 자기만의 이해하기 쉬운 문장으로 바꾸어보는 것이다.
  • 전공 서적 등의 한 번 읽어서 독해가 어려운 글은 연반추 독해를 통해 학습한다. 효과적으로 학습(독해)하는 감

미팅 사전 준비

-미팅의 아젠다가 무엇인지, 목적이 무엇인지, 참가자는 누구인지 알아두고 참가할 것
-자신의 발화가 미팅에 포함되어 있을 경우, 청자를 고려하여 무엇을 언급할지 준비할 것
-외부 미팅의 경우, 내부미팅을 우선 진행하여 무엇에 대해 이야기를 나누고, 어떤식으로 대응할지 미리 정할 것

미팅시

기지록의 종류

Full기지록

Full 기지록은 말한토시 틀리지 않고 있는 그대로 모두 기재하는 것임. 보통은 이러한 기지록을 기재할 필요는 없지만, 계약 교섭과 같이 누가 언급했는지, 무엇을 언급했는지가 중요한 회의에서는 Full기지록을 써야함

  • 기지록은 rawdata라고 되도록 있는 그대로 적음
  • 기지록은 가능한 누가 언급했는지, 무엇을 언급했는지 세부적으로 적을 것

요약 기지록

요약기지록은 요점을 중심으로 그 앞뒤 배경을 파악할 수 있도록 어느 정도 요약해서 기재하는 것. Full 기지록처럼 다적을 필요는 없고, 흐름에 맞추어 정리가 필요하다고 판단되는 부분을 중심으로 적어나가면 됨.

  • 누가 언급했는지는 되도록 적는 것이 좋다.
  • 회의는 화제를 중심으로 이야기가 왔다 갔다 하는 것이므로, 화제 중심으로 기재할 것
  • 참가자가 말한 문장을 그대로 적을 필요없고, 자신이 이해한대로 요약해서 적으면 됨(요약기지록에서)

요점 기지록

회의의 고수들만이 활용할 수 있는 기지록으로, 결정사항TODO만 적는 것. 장기적으로 프로젝트에 어사인 되어 앞뒤배경을 모두 아는 상황에서는 요점 기지록을 활용해도 문제 없다. 보통 파트너급의 높은 이해능력과 전반적인 상황을 알고 있는 레벨에서 사용하는 방법.

기지록 작성시 유의점

  • 기지록을 적고 있을 때, 다른 사람이 real time으로 언급하는 부분을 놓치는 경향이 있으므로 기지록을 적는 와중에도 청중의 발언에 집중할 것
  • 주요 항목에 대해서는 회의 시간 중 실시간으로 빠르게 적고, 이후에 양식에 맞춰 정리할 것
  • 시계열로 기록할 것
  • 복잡한 복문이 아닌, 단문으로 적을 것
  • TODO 항목에 대해서는 #으로 표시, 이해 못한 항목에 대해서는 * 로 표시, 결정사항에 대해서는 ※로 표시하여 기지록 작성후 한눈에 알아볼 수 있도록 할 것

미팅 후

기지록 정리

  • 회의시 작성한 rawdata를 근거로, 아래의 템플릿을 채워나감
【Agenda】 
【참가자】 
【요약】
【TODO】 
【결정사항】
【미해결사항】
【議事】-> rawdata, 내부 증거용으로만 남기고 공유는 하지 않을 수도 있음 
  • TODO 작성법
  1. Role And Responsibility
    키워드 담당자 액션내용을 명확하고 심플하게 적을 것
  2. Due Date를 명시할 것
  3. 상대방의 입장에서 읽어보기
    TODO를 받은 담당자가 TODO만 읽고 자신의 일을 바로 커밑해나갈 수 있을지를 기준으로 TODO내용 자가레뷰하기
- 1차사업 견적서 수정 후 발송: 담당자A(~2/5)
- 경쟁사 벤치마킹 자료 작성: 담당자B(~2/7)
- 기존 사업 차별성 정리자료 작성: 담당자C(~2/4)
  • 회의록 공유는 가급적 빠른 시간 안에!

회의록은 회의가 끝나고 가능한 빠른 시간 내에 작성하고 공유하는 것이 좋습니다. 이를 통해 회의 참석자는 물론 참석하지 않은 업무 관련자들이 회의를 통해 도출된 내용을 이해할 수 있게 해야 합니다. 또한 빠른 시간 내에 공유가 이뤄져야 혹시라도 잘못된 사항이 있을 경우 누락되거나 수정해야 할 사항에 대해 확인할 수 있습니다.

  • 참석하지 않은 업무 관련자에게도 공유할 것

다른 일정으로 참석하지 못한 업무 관련자에게도 회의록을 빠짐없이 공유하는 것이 좋습니다. 그래야 회의를 통해 어떤 내용이 논의되었고 결론이 도출되었는지를 확인하고 관련 프로젝트를 완수할 때 혼선이 빚어지지 않습니다.

  • 회의 내용은 회의 시간 중 실시간으로 작성할 것

많은 내용이 오가는 회의 시간이 끝난 다음 회의록을 처음부터 작성하는 것은 거의 불가능에 가깝습니다.

  • 분량은 1매 이내로

지나치게 방대하게 회의록을 작성하면 읽는 사람들로 하여금 피곤함을 불러일으키고 명확성이 떨어지는 단점이 있습니다. 빠지는 내용이 없도록 꼼꼼하게 작성하되 잘 요약해 1매 이내로 작성하는 것이 좋습니다.

  • 회의록 작성이 처음이라면 전체 공유 전 1차 검토 받기

회의록을 공유하기 전, 회의에 참석한 동료 또는 상사를 통해 1차로 회의록을 검토 받는 것도 좋습니다. 특히 처음 회의록을 작성할 경우 회의의 핵심 사안이 무엇인지 파악하기 어려울 수 있고 누락된 사항이 생기기 쉽기 때문에 사전 검토가 필요할 수 있습니다.

참고

'지혜 > ' 카테고리의 다른 글

결정하는 감  (0) 2019.10.02
글의 구조를 파악하는 감  (0) 2019.09.01
질문하는 감  (0) 2019.08.29
자가 검진의 감  (0) 2019.08.29
정리되지 않는 복잡한 마음을 정리하는 감  (0) 2019.08.29
  1. 배경

【AIPSCM】LIVING_SYSTEM画面討議_20200622_議事メモ.txt
0.00MB
【AIPSCM】画面討議_20200617_議事メモ.txt
0.00MB
【AIPSCM】画面討議_20200612議事メモ.txt
0.00MB

  1. 좋은 질문을 해야하는 이유
    • 상대와 나의 시간 코스트 절감
    • 내가 원하는 질문을 얻을 수 있음
  1. 좋은 질문
    • 먼저 자신이 모르는 것이 무엇인지 정확히 파악할 것
    • 알고 싶은 것이 무엇인지 정확히 파악할 것
    • 어떠한 답이 나올지 예상하고 질문할 것
    • 상대의 답에 따라 어떠한 질문을 이어갈지 예상할 것
    • 어디까지는 알고 어디부터 모르는지 상대가 이해할 수 있도록 배경 을 설명할 것
    • 최대한 구체적으로 질문할 것
    • 예를 들어 가며 상대가 이해하기 쉽게 질문할 것

'지혜 > ' 카테고리의 다른 글

글의 구조를 파악하는 감  (0) 2019.09.01
미팅하는 감/회의록 작성하는 감  (0) 2019.08.29
자가 검진의 감  (0) 2019.08.29
정리되지 않는 복잡한 마음을 정리하는 감  (0) 2019.08.29
글을 쓰는 감  (0) 2019.08.29
  1. 자가 검사란?
    컴퓨터가 스스로를 분석해서, 하드웨어인 cpu, 메인보드, 메모리, 소프트웨어의 문제점을 검진하는 것처럼, 인간도 스스로의 상태를 파악하고 문제점을 집어내는 것이다.

    컴퓨터가 cpu, 메인보드, 메모리 등의 하드웨어 + 각종 소프트 웨어로 구성되어 있기에 한 요소 한 요소의 문제점을 검진해 볼 수 있는 것처럼, 인간도 인간을 구성하는 요소를 알고 있어야 자가 검진이 가능하다. (인간이라는 존재를 분할 알고리즘으로 분석: 인간 = 신체+이성+감정+욕구)

    인간의 하드웨어에 해당하는 것은 신체이다. 인간의 소프트웨어에 해당하는 구성물들은 다소 복잡한다. 첫째, 논리적인 옳고 그름을 밝혀내는 이성의 흐름안에 있는 생각이다. 둘째, 긍/부정과 각성의 흐름 안에 있는 감정이다. 셋째, 어떤 것을 원하는 생각도 감정도 아닌 욕구이다. 정리하면, 인간의 구성요소는 신체, 생각, 감정, 욕구이다.

    우리는 스스로의 신체, 생각, 감정, 욕구의 상태를 들여다보고 어떤 상태에 있는지, 무엇이 문제인지 스스로 검진할 수 있다.

감정 감성 이성

감성(pathos)은 이성(logos)의 상대어로 '자극에 대하여 느낌이 일어나는 능력. 감수성(感受性)' 또는 '대상으로부터 감각되고 지각되어 표상(表象)을 얻게 되는 수동적인 능력'을 뜻하는 철학적인 용어입니다.  
감정(emotion)은 '느끼어 일어나는 심정. 마음. 기분' 또는 '슬픔·기쁨·좋음· 싫음 따위의 심리 상태나 직감' 즉 '희노애락애오욕'과 같은 것을 말하는데 심리학적인 용어라고 볼 수 있습니다.  
따라서 감성은 '느낌을 받아 들이는 능력'이라고 할 수 있고, 감정은 느낌에 대한 심정, 심리 상태'라고 할 수 있습니다.  
직감은 곧바로 느껴 아는 것으로 설명·증명 등을 거치지 않고 곧 사물의 진상을 마음으로 느껴 알거나 그 감각을 말합니다. 직감은 감성의 일부라고 볼 수 있습니다.
  1. 자가검사의 방법
    • step1
      • 신체,생각,감정,욕구의 상태를 스스로 검진해본다.
      • 신체 : 목이 조금 당긴다. 발가락이 간지럽다. 위가 쓰리다. 배가고프다. 눈이 뻑벅하다. 머리가 상쾌하다. 몸이 가볍다
      • 생각 : 내가 지금 무엇을 해야할지 생각. 점심은 무엇을 먹어야할지 생각. 여자친구는 잘 있는지 생각. 부모님은 잘 계신지 생각. 다른 친구들은 뭘 하고 있을지 생각.
      • 감정 : 불안한 감정. 초조한 감정.
      • 욕구 : 자위를 하고 싶은 욕구. 게임을 하고 싶은 욕구. 맛있는 걸 먹고 싶은 욕구. 여자친구를 보고싶은 욕구. 아무것도 안하고 싶은 욕구

*감정의 분류법 ; 각성과 긍부정

'지혜 > ' 카테고리의 다른 글

미팅하는 감/회의록 작성하는 감  (0) 2019.08.29
질문하는 감  (0) 2019.08.29
정리되지 않는 복잡한 마음을 정리하는 감  (0) 2019.08.29
글을 쓰는 감  (0) 2019.08.29
어플리케이션을 개발하는 감  (0) 2019.07.28
  1. 머리속에 생각나는 모든 키워드들을 우선 적어내기
    마인드맵 그리기는 머리를 복잡하게 했던 키워드들을 종이 위에 하나하나 적어봄으로써 머리 속을 정리할 수 있는 효과를 지닌다. 이는 글을 쓰는 프로세스를 포함하여 모든 작업에 적용할 수 있는 일의 처리 프로세스이다.
  1. 각 키워드를 분류화하기
    • 키워드들을 粒度(level)에 맞게 정리해 나가기
    • 가지를 쳐 나가면서 MESE에 따라 누락되는 부분이 없는지 주의
    • 분할 알고리즘을 적용해 더욱 구체화 될 수 없는지 확인하기
    • 일정한 인과관계를 갖도록 한다.
  1. 우선 처리해야할 것이 무엇인지 일의 순서 매기기

    • 인과관계에 따라 분류된 키워드에 일의 순서를 매긴다.
    • 일의 순서를 매기는 기준 : 1. 다른 태스크에 영향을 미치는 일 2. 데드라인이 긴박한 일 3. 금새끝내버릴 수 있는 일
  2. 마인드 맵과 순서 매기기에 따라 ;하나하나 차분하게' 진행하기

'지혜 > ' 카테고리의 다른 글

질문하는 감  (0) 2019.08.29
자가 검진의 감  (0) 2019.08.29
글을 쓰는 감  (0) 2019.08.29
어플리케이션을 개발하는 감  (0) 2019.07.28
노래부르는 감  (0) 2019.06.24

글이 중요한 이유

글 외에도 유투브니 영화니 드라마니 소설이니 웹툰이니 PPT장표니 미친 듯이 다양한 컨텐츠와 미디어가 공존하는 와중에도 글이 중요한 이유는 모든 컨텐츠는 간단한 줄글로부터 시작하기 때문이다. 유투브, 영화, 드라마, 소설, 웹툰, PPT장표는 줄글을 보기 좋게 시각화하고 흥미를 더한 것에 불과하다.

글 설계하기

학생 때 지겹게 듣던 논리적 글쓰기니 뭔 복잡한 개소리 다 집어치우고, 논리적인 글은 주장 + 근거 간단하게 딱 이 2개로 이루어진 글이다. 필요하다면 근거 + Sub근거 + Sub근거 + ... 구조로 더욱 논리성을 더할 수 있다. 이게 논리적 글쓰기의 모든 방법이다.

주장
    > 주장에 대한 근거(why) 
        > 근거에 대한 Sub근거(why)  + what how so

주장: 가장 하고 싶은 말을 한마디로 하면?

논맂거 글을 쓰기 위해선 먼저 주장하고자 하는바 (글 전체에서 말하고자 하는바)가 단 한 줄로 간단명료하게 나와야한다. 주장은 가설적일 것이다. 가설적이지 않은 주장은 당연해서 주장이라고 받아들여지지 않을 것이기 때문이다. 시내 한복판에가서 사람은 죽는다! 라고 외쳐봐야 어느 누구도 주목하지 않을 것이다. 그러나 사람은 결국 신이 만든 장난감이다! 라고 외친다면 증명되지 않은 가설에 대해 이유라도 들어보려고 누군가는 주목할 것이다.

근거Why: 왜 주장이 합당하다고 생각되는가?

근거는 주장에 대해 그 이유를 제시하는 것이다. 근거는 Fact일 수도 있고 가설적일 수도 있다. 단, 가설적 근거는 데이터로 Back-up되어야 한다. 어떠한 객관적, 정량적 데이터로 가설에 머물고 있는 근거를 Fact로 만들 수 있는지 고민하고, 그러한 데이터를 활용하자.

What How So로 근거를 명확히 하기

근거를 제시하는 것만으로는 글이 명확하지 않을 수 있다. 이럴 때는 What How So 가 부족하지 않은지 생각해봐야 한다.

주장: 한국 반도체 시장은 앞으로 매우 힘들어 질 것이다

근거1: 일본, 대만, 미국이 한국 왕따시키고 지네끼리만 짝짝쿵하고 있다.(이하는 What에 대한 세부 설명)
   - 대만 TSMC가 일본 쿠마모토에 대규모 Fab을 세우고, 일본은 엄청난 정부적 혜택을 주고 있다.
      > 일본 정부의 세혜택에 관한 Data로 주장 Back-up
   - 미국 애플이 TSMC에게 발주하는 물량을 크게 늘이고 있다.
      > 애플의 TSMC向 발주 액 추이 데이터로 Back-up

근거2: 한국 반도체 시장 인력이 부족하다.

주장 - WHY의 구조로 설계된 글을 객관적으로 바라보면서 반론해보기

글의 기본적 설계가 완성되면 논리적 결함이 없는지 제3자의 입장에서 바라보면서 반론해보자. 반론을 무마시킬 수 있는 논리 구조를 만들 수록 글은 더 탄탄해진다.

논리적 글쓰기 설계 예

주장: 부동산 가격은 떨어질 것

이유1: 수요는 이미 하방인 상태로 관망할 것이고 ...
   - 수요 하방이라는 근거: 서울 매매 건수가 역대 최저. 공급 곡선이 그대로 였다고 했을때 수요곡선 하락 외 설명 불가
      - 수요 곡선 하락한 이유: 높은 대출 금리 및 갭 투자 불가
   -  관망할 것이라는 근거: 1억 버는 사람이 서울에 최대로 살수 있는 집값 7억. 또 부동산 시장 하락이 뻔한 상황에서 갭투자 불가. 이에 수요는 자기 소득으로 부동산 구매 가능한 7억선까지 내려오지 않는 이상 수요자체가 불가
      - 1억벌면 7억집살수 잇다는 근거: DSR LTV 모델링 결과 그러함

이유2: 공급은 늘어날 것
   - 집주인들이 버티고 있으면 모르겟지만, 어쩔 수 없이 집을 내놓을 수밖에 없는 상황이 존재
   - 어쩔 수 없이 집을 내놓을 수밖에 없는 이유: 갭투자, 갭투자자들은 전세값이 내려가면 그만큼이 자기 손해분이 되기 때문에 손절하기 위해 어쩔 수 없이 부동산 매매
   - 전세값이 내려가는 이유: 전세 시장에서 전세 수요는 낮고, 전세 공급은 높음
      - 전세 수요 낮은 이유: 높은 금리
      - 전세 공급 높은 이유: 전세로 집을 내놓는 사람들 중 대부분은 갭투자가이기 때문에 세입자가 없는 상태로 가만히 집비워두고 버틸재간 있는 사람 없음
         > (반론) 진짜 갭투자자 많은가요? 실제 갭투자 데이터 or 갭투자 없이 대출로 살수 잇는 서울 집값이 마지노선 데이타

그외 글 설계 할때의 Tip

  • 글쓰기 주제에 대해 생각나는 것 생각나는대로 모조리 적어 마인드맵 완성하기
  • 마인드 맵을 통해 얻은 정보를 바탕으로, 因果関係에 따라 논리 구조를 짜맞추기
    • 꼭 필요한 핵심단어들을 의식하며 논증과 전체 셀계에 녹여내기
  • 글의 큰 흐름을 어떻게 적어 나갈 것인지, 또 각 단락별로 말하고 싶은 바와 어떤 내용을 집어넣을 것인지 세세한 구조를 잡기★
    • 각 단락별로 주제를 잡고 그대로 글을 구성해 나가기

글 쓰기 중

  • 연구배경
  • 문제 제기(주제 정하기)
  • 가설 기술(주장 정하기)
  • 검증 방법 기술
  • 증거 제시(주장에 대한 이유를 제시하기)
  • 증거에 대한 논리적 해석(이유에 대한 증거를 제시하기)
  • 가능한 반대 주장에 대한 재반박
  • 결론과 제언

글 쓰기 후

  • 최소 세번이상 글의 성격 독자의 입장을 고려하여 글을 읽고 다듬는다.
  • 읽었을 때 이해하기 쉬운 글이 좋은 글이다 : 소리내어 읽어봄으로써 못난글을 알아보는 것은 단순한 원리에 바탕을 두고 있다. 언어는 말과 글이다.언어에 한정해서 보면 글이 아니라 말이 먼저고, 말보다 생각이 감정이 먼저다. 말과 글중에는 말이 먼저도. 말로해서 좋아야 잘 쓴 글이다. 글을 쓸때는 이 원리를 잊지 말아야한다.

글쓰기의 어드바이스

글쓰기의 테크닉에 대해

  • 글은 단문으로 쓴다.
    • 단문이 좋다. 문학작품도 그렇지만 논리글도 마찬가지다. 단문은 그냥 짧은 문장을 가르키는 것이 아니다. 길어도 주어와 술어가 하나씩만 있으면 단문이다. 문장에 하나의 뜻을 하나만 담으면 자연스레 단문이 된다.
    • 단문은 주술관계가 하나뿐이여서 문장이 꼬일 위험이 없다. 복문을 쓰는 사람 대부분은 멋지다고 생각해서 그렇게 쓴다.
    • 글을 압축하려면 단문을 기본으로하고 특별한 경우에 복문을 쓴다는 원칙을 견지해야한다. 뜻과 느낌을 강하고 확실하고 깊게 전하려면 복문을 서야 한다는 판단이 들때만 복문을 쓰는 것이다
  • 글의 군더더기를 없앤다 : 문법적인 군더더기 삭제 + 전체 문장에서 굳이 없어도 흐름이 이어지는 문장 삭제
    • 다음은 군더더기를 없애는 것이다. 문장의 군더더기란 무엇일까? 간단하다. 없애버려도 뜻을 전하는데 큰 지장이 없으면 군더더기다. 문장의 군더더기는 크게 세 가지다. 첫째는 접속사, 둘째는 형용사와 부사, 셋째는 여러 단어로 이루어져있지만 형용사나 부사와 비슷한 역할을 하는 문장 요소다.
    • 굳이 없어도 좋은 접속사는 과감하게 없애야한다. 단문으로 글을 이어나갈 때 문장 사이에 매번 '그러나' '그리고' '그러므로' '그런데' 같은 접속사를 넣는 것은 나쁜 습관이다. 문장은 뜻을 담고 있다. 그 뜻이 자연스럽게 이어지면 접속사가 없어도 된다. 단문을 기본으로 쓰고 불필요한 접속사를 생략하기만 해도 글을 압축할 수 있다.
  • 읽었을 때 이해하기 쉬운 글이 좋은 글이다 : 소리내어 읽어봄으로써 못난글을 알아보는 것은 단순한 원리에 바탕을 두고 있다. 언어는 말과 글이다.언어에 한정해서 보면 글이 아니라 말이 먼저고, 말보다 생각이 감정이 먼저다. 말과 글중에는 말이 먼저도. 말로해서 좋아야 잘 쓴 글이다. 글을 쓸때는 이 원리를 잊지 말아야한다.
  • 한자어는 대체될 우리말이 있는지 따져보아야 한다. 사용한다 -> 쓴다. 삭제한다 -> 없앤다. 인식한다 -> 안다.
  • 피동형 문장도 심각한 문제를 일으킨다. 우리말에는 피동문이 드물다. 반드시 피동문을 써야 의미가 전달될때만 예외로 사용한다. 그런데도 일본말이나 영어같이 피동문을 표준문장처럼 쓰거나 뜬금없이 피동형 동사를 가져다 붙이는 사람이 많다. 보여지다 되어지도 키워지도 디뤄지도 모여지도 두어지다 보아지다 와 같은 것을 글뿐만아니라 방송에서도 출몰한다. 타동사를 피동형으로 쓰는 것만으로 모자라는지 자동사까지 억지로 피동형으로 만든다.
  • 서양말의 완료시제와 복수형 어미의 오남용도 심각하다. 우리말은 완료시제가 없다. '어제 어머니를 만났었다'는 틀린말이다. '어제 어머니를 만났다'가 올바른 우리말이다. 서양말은 복수와 단수에 따라 동사의 형태가 바뀌므로 복단수를 인식하는 것이 중요하다. 그러나 우리말은 명사 그자체를 복수라고 분명하게 드러내야할 때가 아니면 복수형을 스지 않는다. 그런데도 '방법들을 찾아야 한다'는 식으로 추상명사에까지 복수형인 '들'을 붙여 사용하곤 한다.
  • 하나의 문단을 쓸 때, 처음으로 오는 문장은 가능한 문단 전체를 대표하는 주제로 한다. 이것은 독자에게 친절한 글이다.

글쓰기의 마인드에 대해

  • 독자의 입장을 고려해서 이해가 안되는 부분 풀어쓰기(친절한 글쓰기) : 다른 정보가 없어도 이해할 수 있도록 독자를 존중해야 한다. 사람들이 잘 모르는 전문용어나 이론을 끌어올 때는 문맥에 비추어 이해할 수 있도록 적당한 방법으로 설명을 붙여야한다. 이렇게 핮 ㅣ않고 무작정 하고 싶은 이야기를 우겨 넣으면 텍스트 밀도가 너무 높아진다. 틀린게 쓴 것도 흉하게 쓴 것도 아니지만 그런 글은 독자를 괴롭힌다. 읽기가 힘들고 이해하기 어려우면 아무리 좋은 책이라 해도 독자가 공감할 수 없다.
  • 글 쓰는 사람의 작업실에 대해 환상을 가진 사람이 있을 것이다. 고즈넉한 실내, 은은하게 흐르는 클래식, 커피향, 원고 청탁전화. 그 저도 환상이 나쁠건 없다. 하지만 그런 분위기를 만든 다음에 글을 쓰려고 한다면 좋지않다. 그런 작업실은 베스트셀러를 내는 전업작가라야 가질 수 있다. 전업작가라 해서 누구나 다 그런 작업실에서 글을 쓰는 것도 아니다.
  • 취향 고백과 주장을 구분하여, 주장이라면 반드시 논증하기
  • 주장을 논증하기 위한 근거는 주장이 아닌 사실을 언급하기 : 공리만이 타당한 주장의 근거가 될 수 있다. 논증의 근거로 주장이 오게 되면, 또 그 논증에 대한 논등을 해야하는 논증지옥에 빠진다.
  • 허영심은 위선의 감정에 에워쌓여 난해한 글을 쓰게 한다
  • 객관적인 글 쓰기 : 감정을 억제하고 최대한 객관적으로. 판단은 독자에게
  • 모든 논증은, 1차적, 2차적, 3차적.... 이유를 생각해보고 설명해야 하는 차원의 이유만 글을 통해 전달한다. 너무 심오한 이유는 당연한 것을 반복하는 실수를 범하고, 이는 글이 쓸데 없이 길어지고 지루해지며, 요점을 흐린다.★
  • 개인적인 경험이나 유머의 사용을 겁내지마라(개인적 경험의 언급은, 독자에게 하여금 일반적인 내용도 더욱 설득력 있게 만든다)
  • 스스로에게 굉장히 엄격한 비판가가 되라. 자기 스스로보다 자신의 글을 더 잘 평가할 수 있는 사람은 없다.

1-160429031445.pdf
1.04MB

어플리케이션 개발의 흐름

요건파악

  1. 요건파악이란
  • 어플리케이션의 존재 이유는 유저의 고통점(니즈)를 해결하는 것에 있습니다. 어플리케이션이 어떤 니즈를 충족해 줄 수 있는지 요건을 파악하고 그 요건에 맞는 어플리케이션 개발은 개발 시 가장 먼저 이루어지는 액션이자 가장 중요한 액션입니다.
  1. 요건파악에서 주의할점
  • 유저의 요건 충족은 보통 프론트를 통해서 시각적으로 이루어질 시에 효과적입니다. 때문에 유저의 요건을 만족하는 프론트를 먼저 구상하여 요건을 만족하고, 그 프론트를 베이스로 큰 단위의 설계를 시행해 나갑니다.

요건에 맞는 설계

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

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

기본설계

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

구체설계

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

알고리즘설계

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

프로토타입 개발

  1. 프로토타입개발
  • 프로토타입이란 완전체가 아닌 1. 데이터가 일단 흐르기는 하는, 2. 유저의 최저한의 요건을 만족한 매우 초기 형태를 의미합니다. 무엇이든 처음부터 완전할 수 없습니다. 특히 어플과 같은 경우는 모든 경우의 수를 고려하기가 사실상 불가능하기 때문에 더더욱 그렇습니다. 처음에는 프로토타입으로 일단은 움직이는 것을 만들어내고, 피드백을 통해 점점 진화시켜 나갑니다.
  1. 프로토타입 개발 시 주의점
  • 요건은 보통 프론트에서 나오기때문에 설계를 그릴때는 프론트에서 역으로 시작하고 , 실제 개발 시에는 디비부터 실장합니다. DB는 어플리케이션 전체에 영향을 미치는 가장 안쪽의 요소이니까요.
  • 처음부터 완전한 어플을 만들지 않습니다. 아니 그렇게 못합니다 절대. 프로토타입이란 최소한의 요건을 만족한 최저로 움직일수 있는 것입니다. 처음에는 볼품없게라도 라도 움직이는 실체를 만들고 이후에 점점 피드백을 통해 고도화합니다.

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

요건정의

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

기본설계

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

세부설계

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

単体테스트

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

結合테스트

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

'지혜 > ' 카테고리의 다른 글

정리되지 않는 복잡한 마음을 정리하는 감  (0) 2019.08.29
글을 쓰는 감  (0) 2019.08.29
노래부르는 감  (0) 2019.06.24
What 트리 그리기, 분할정복 알고리즘과 인수분해  (0) 2019.06.18
차액거래 메뉴얼  (0) 2019.05.14

+ Recent posts