<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
        <title>ssu_hyun.log</title>
        <link>https://velog.io/</link>
        <description></description>
        <lastBuildDate>Thu, 30 Nov 2023 04:28:17 GMT</lastBuildDate>
        <docs>https://validator.w3.org/feed/docs/rss2.html</docs>
        <generator>https://github.com/jpmonette/feed</generator>
        <image>
            <title>ssu_hyun.log</title>
            <url>https://images.velog.io/images/ssu_hyun/profile/162ec88b-de88-4b92-9fb0-27c56eaa209b/KakaoTalk_20220127_074846465.png</url>
            <link>https://velog.io/</link>
        </image>
        <copyright>Copyright (C) 2019. ssu_hyun.log. All rights reserved.</copyright>
        <atom:link href="https://v2.velog.io/rss/ssu_hyun" rel="self" type="application/rss+xml"/>
        <item>
            <title><![CDATA[물고기는 존재하지 않는다]]></title>
            <link>https://velog.io/@ssu_hyun/%EB%AC%BC%EA%B3%A0%EA%B8%B0%EB%8A%94-%EC%A1%B4%EC%9E%AC%ED%95%98%EC%A7%80-%EC%95%8A%EB%8A%94%EB%8B%A4</link>
            <guid>https://velog.io/@ssu_hyun/%EB%AC%BC%EA%B3%A0%EA%B8%B0%EB%8A%94-%EC%A1%B4%EC%9E%AC%ED%95%98%EC%A7%80-%EC%95%8A%EB%8A%94%EB%8B%A4</guid>
            <pubDate>Thu, 30 Nov 2023 04:28:17 GMT</pubDate>
            <description><![CDATA[<p><img src="blob:https://velog.io/ee324271-2586-4a47-b743-34d71b5d766a" alt="업로드중.."></p>
<ul>
<li><p>p.18
이 얘길 듣자마자 나는 그가 바보라고 생각했다. 바늘은 분명 지진에 맞서서는 효과가 있겠지만, 화재나 홍수, 녹, 그 밖에 그가 고려하지 못한 수천 가지 파괴 방식에 대해서는 어쩐단 말인가? 그가 바늘로 이뤄낸 혁신은 너무 허술하고 너무 근시안적이며, 자신을 지배하는 힘에 대한 어마어마한 무지를 보여주었다. 그는 내게 오만에 대한 교훈으로, 어류 수집계의 이카로스처럼 보였다.
그러나 나이가 들어가면서 내게 찾아온 혼돈에 뒤흔들리고, 내 손으로 직접 내 인생을 난파시킨 뒤 그 잔해를 다시 이어 붙여보려 시도하고 있을 때, 문득 나는 이 분류학자가 궁금해졌다. 어쩌면 그는 무언가를, 끈질김에 관한 것이든, 목적에 관한 것이든, 계속 나아가는 방법에 관한 것이든 내가 알아야 할 뭔가를 찾아낸 것인지도 몰랐다. 그리고 나 자신에 대해 가당치 않게 커다란 믿음을 가져보는 것도 괜찮을 것 같았다. 자기가 하는 일이 효과가 있을 거라는 확신이 전혀 없을 때에도 자신을 던지며 계속 나아가는 것은, (이렇게 생각하는 게 죄악 같은 느낌이 들긴 하지만)바보의 표지가 아니라 승리자의 표지가 아닐까 생각했다.</p>
</li>
<li><p>p.45
아가시는 신에 이르는 가장 좋은 방법은 해부용 메스를 쓰는 것이라고 설명했다. 껍질을 가르고 그 내부를 들여다보라는 것이다. 내부야말로 동물들의 &quot;진짜 관계&quot;를 발견할 수 있는 곳이며, 그들의 뼛속과 연골, 내장 속이야말로 신의 생각이 가장 잘 담겨 있는 곳이라고 했다.
...
어류는 인간이 자신의 저열한 충동들에 저항하지 못하면 어디까지 미끄러져 내려갈 수 있는지를 상기시키는 비늘 덮인 존재였다.</p>
</li>
<li><p>p.46
그는 가장 높은 위치에 있는 피조물들조차 조심하지 않으면 그 위치에서 떨어질 수 있으며, 나쁜 습관들이 어떻게든 한 종을 육체적으로도 지적으로도 쇠퇴하게 만들 수 있다고 우려했다.</p>
</li>
<li><p>p.55</p>
</li>
</ul>
]]></description>
        </item>
        <item>
            <title><![CDATA[11장. 시스템]]></title>
            <link>https://velog.io/@ssu_hyun/11%EC%9E%A5.%EC%8B%9C%EC%8A%A4%ED%85%9C</link>
            <guid>https://velog.io/@ssu_hyun/11%EC%9E%A5.%EC%8B%9C%EC%8A%A4%ED%85%9C</guid>
            <pubDate>Wed, 20 Sep 2023 00:05:57 GMT</pubDate>
            <description><![CDATA[<h2 id="관심사-분리">관심사 분리</h2>
<ul>
<li>시스템 제작(construction)과 사용(use)을 분리하라. (생성 로직과 사용 로직을 분리하면 모듈성이 높아진다.)</li>
</ul>
</br>

<h3 id="1-main-분리">1) Main 분리</h3>
<ul>
<li>생성과 사용의 분리
   <img src="https://velog.velcdn.com/images/ssu_hyun/post/dea8d78a-f10b-4e33-a514-0aa405c015db/image.png" alt=""><ul>
<li>Main에서 Application 호출 전 Builder에 생성 요청 &gt; Builder는 Configured Object 생성해 Main에 리턴 &gt; Main은 Application에 Builder에서 넘겨준 Configured Object를 넘겨주어 로직에서 사용하게 함</li>
<li>시스템에 필요한 객체 생성과 관련한 일은 Main에서 하고 Application은 그저 Main으로부터 생성된 객체를 사용하는 방식 (즉, Application은 Main이나 객체가 생성되는 과정을 전혀 모름)
</br></br></li>
</ul>
</li>
</ul>
<h3 id="2-팩토리">2) 팩토리</h3>
<ul>
<li><p>객체 생성 시점 Application이 제어
 <img src="https://velog.velcdn.com/images/ssu_hyun/post/035b2054-f9ec-4439-86ae-73a59c96c7b3/image.png" alt=""></p>
<ul>
<li><p>main에서 FactoryImpl 구현 &gt; Factory에서 Configured Object 제작 &gt; Main에서 이 생성 시점을 제어 (Item 제작과 생성의 분리)</p>
<ul>
<li>의존성 주입 (DI, Dependency Injection)</li>
</ul>
</li>
<li><p>분리시킨 의존성을 메서드/생성자/환경변수 등으로 주입해주는 형태</p>
</li>
<li><p>객체에 특정 변수/객체(의존성)를 매개변수로 주입한다는 의미
ex) saveData(Data data) : saveData는 Data라는 객체에 의존성이 강한 함수</p>
</li>
<li><p>디자인 패턴 중 하나로 객체 간의 의존성을 자신이 아닌 외부에서 받아 유연하고 느슨한 결합을 통해 종속성을 감소시켜 변경에 민감하지 않아 코드의 유연성, 재사용성, 테스트 용이성을 개선시킴</p>
<pre><code class="language-cs">// SpellChecker는 KoreanDictionary에 의존
public class SpellChecker
{
Dictionary dictionary = new Koreandictionary();
}

// DI 방식 1 : 생성자 주입 (Constructor Injection)
public class SpellChecker
{
private Dictionary dictionary;

public SpellChecker(Dictionary dictionary)
{
 this.dictionary = dictionary;
}
}

// DI 방식 2 : 세터 주입 (Setter Injection)
public class SpellChecker
{
private Dictionary dictionary;

// SpellChecker 객체 생성하는 곳에서 아래 메서드 실행
public void setDictionary(Dictionary dictionary)
{
 this.dictionary = dictionary;
}
}</code></pre>
<p></br></br></p>
</li>
</ul>
</li>
</ul>
<h3 id="3-확장">3) 확장</h3>
<ul>
<li>소프트웨어 시스템은 물리적인 시스템과 다르다. 관심사를 적절히 분리해 관리한다면 소프트웨어 아키텍처는 점진적으로 발전할 수 있다.</li>
</ul>
<p></br></br></p>
<h2 id="횡단-관심사cross-cutting-concern">횡단 관심사(cross-cutting concern)</h2>
<p><img src="https://velog.velcdn.com/images/ssu_hyun/post/efeeea91-b6c8-4fed-833c-a83527e72531/image.png" alt=""></p>
<ul>
<li>핵심적인 기능이 아닌 중간중간 삽입되어야 할 기능 관심들(기능/모듈들) </li>
<li>관심사들은 디자인과 구현 면에서 시스템의 나머지 부분으로부터 깨끗이 분해되지 못하는 경우가 있을 수 있으며 분산(코드 중복)되거나 얽히는(시스템 간의 상당한 의존성 존재) 일이 일어날 수 있다. <blockquote>
<p><em><strong>AOP (Aspect Oriented Programming)</strong></em></p>
</blockquote>
<ul>
<li>관점 지향 프로그래밍</li>
<li><U>횡단 관심사항의 기능을 모듈화하여 중복을 최소화</U>하면서, <U>핵심관심사항에 집중</U>하도록 하는 프로그래밍 기법</li>
<li>소스코드 상에서 핵심적인 관점과 부가적인 관점으로 나누어보고 이를 기준으로 각각 분리하는 것 의미
<img src="https://velog.velcdn.com/images/ssu_hyun/post/23f84da8-6adf-4517-8b18-ddf0a829c6c9/image.png" alt=""><img src="https://velog.velcdn.com/images/ssu_hyun/post/e66e3750-143c-45b8-ba92-16dbbe39dd49/image.png" alt=""></br></li>
<li>Aspect (관심 모듈) : 횡단 관심사를 모듈화한 것 (Advice + PointCut)</li>
<li>Target : Aspect를 적용하는 곳, 부가 기능을 적용할 대상</li>
<li>Advice : Aspect에서 수행해야 하는 작업 </li>
<li>JoinPoint : 코드 실행 중 Aspect가 적용될 수 있는 특정 지점 </li>
<li>PointCut : 어느 부분에 Advice를 적용할지를 정의. 메서드 호출, 필드 엑세스 등의 특정 지점 </li>
<li>Weaving : Aspect 코드를 어플리케이션 코드에 적용하는 프로세스 </li>
</ul>
</li>
</ul>
<p></br></br></p>
<h3 id="횡단-관심사-해결을-위한-자바에서-사용하는-aspect-or-aspect와-유사한-메커니즘-3가지">횡단 관심사 해결을 위한 자바에서 사용하는 Aspect or Aspect와 유사한 메커니즘 3가지</h3>
<ol>
<li>자바 프록시 <ul>
<li>단순한 상황에 적합</li>
<li>프록시를 사용하면 깨끗한 코드를 작성하기 어려우며 시스템 단위로 실행 지점을 명시하는 매커니즘도 제공하지 않는다.</li>
</ul>
</li>
</ol>
<pre><code>&gt; **_프록시 (Proxy)_**
- 어떤 다른 객체나 서비스에 대한 접근을 제어하거나 대리하는 객체
- 클라이언트와 실제 객체 사이에 &lt;U&gt;중간 역할&lt;/U&gt;을 수행하며, 클라이언트가 실제 객체에 직접 접근하지 않고 프록시를 통해 상호 작용하게 함
- 보안 및 권한 관리, 로깅 및 모니터링, 캐싱, 원격 호출, 지연 로딩 등의 용도로 사용
- 객체 간의 상호작용을 보다 유연하게 제어하고 확장성을 높이는데 도움
- 프록시의 단점 : 코드의 양과 크기 (프록시를 사용할 경우 깨끗한 코드를 작성하기 어렵다.) 

```cs
using System;

// 실제 서비스를 나타내는 인터페이스
public interface IService
{
    void DoSomething();
}

// 실제 서비스를 구현한 클래스
public class RealService : IService
{
    public void DoSomething()
    {
        Console.WriteLine(&quot;RealService is doing something.&quot;);
    }
}

// 프록시 클래스 (POJO)
public class ProxyService : IService
{
    private IService realService;

    public ProxyService()
    {
        // 실제 서비스 객체 생성
        realService = new RealService();
    }

    public void DoSomething()
    {
        // 프록시에서 추가적인 작업 수행 가능
        Console.WriteLine(&quot;ProxyService is doing something before calling the real service&quot;);

        // 실제 서비스 메서드 호출
        realService.DoSomething();

        // 프록시에서 추가적인 작업 수행 가능
        Console.WriteLine(&quot;ProxyService is doing something after calling the real service&quot;);
    }
}

class Program
{
    static void Main()
    {
        // 클라이언트 코드는 프록시를 사용해 서비스 호출
        IService service = new ProxyService();
        service.DoSomething();
    }
}
```</code></pre><ol start="2">
<li>순수 자바 AOP 프레임워크</li>
</ol>
<ul>
<li>AOP 언어인 AspectJ를 사용하지 않는 방법</li>
<li>다른 라이브러리나 프레임워크에 종속되지 않은 POJO(Plain Old Java Object) 객체만 남음</li>
<li>테스트 하기 쉬움</li>
</ul>
<ol start="3">
<li>AspectJ</li>
</ol>
<ul>
<li><p>AOP를 구현하는 방법을 담은 언어 (스프링AOP보다 많은 기능들을 제공함)</p>
<p></br></br></p>
<h2 id="테스트-주도-시스템-아키텍처-구축">테스트 주도 시스템 아키텍처 구축</h2>
<ul>
<li>코드 수준에서 아키텍처 관심사를 구분할 수 있다면, 진정한 테스트 주도 아키텍처 구축이 가능</li>
<li>좋은 API는 걸리적거리지 않아야 한다. </li>
<li>최선의 시스템 구조는 각기 POJO(또는 다른) 객체로 구현되는 모듈화된 관심사 영역(도메인)으로 구성된다. 이렇게 서로 다른 영역은 해당 영역 코드에 최소한의 영향을 미치는 관점이나 유사한 도구를 사용해 통합한다. </li>
</ul>
<h2 id="의사-결정을-최적화하라">의사 결정을 최적화하라</h2>
<p>모듈을 나누고 관심사를 분리하면 지엽적인 관리와 결정이 가능해진다.</p>
<h2 id="명백한-가치가-있을-때-표준을-현명하게-사용하라">명백한 가치가 있을 때 표준을 현명하게 사용하라.</h2>
<p>표준 을 사용하면 아이디어와 컴포넌트를 재사용하기 쉽고, 적절한 경험을 가진 사람을 구하기 쉬우며, 좋은 아이디어를 캡슐화하기 쉽고, 컴포넌트를 엮기 쉽다. 하지만 때로는 표준을 만드는 시간이 너무 오래 걸려 업계가 기다리지 못한다. 어떤 표준은 원래 표준을 제정한 목적을 잊어버리기도 한다.</p>
<h2 id="시스템은-도메인-특화-언어가-필요하다">시스템은 도메인 특화 언어가 필요하다.</h2>
<p>도메인 특화 언어(Domain-Specific Language, DSL)를 사용하면 고차원 정책에서 저차원 세부사항에 이르기까지 모든 추상화 수준과 모든 도메인을 POJO로 표현할 수 있다. </p>
<p></br></br></p>
<h2 id="결론">결론</h2>
<ul>
<li>시스템 역시 깨끗해야 함</li>
<li>모든 추상화 단계에서 의도는 명확히 표현해야 한다. 그러려면 POJO를 작성하고 관점 혹은 관점과 유사한 메커니즘을 사용해 각 구현 관심사를 분리해야 한다.</li>
<li>설계시 시스템이든 개별 모듈이든, 실제로 돌아가는 가장 단순한 수단을 사용해야 한다.</li>
</ul>
</li>
</ul>
<h2 id="brbr"> </br></br></h2>
<h2 id="reference">Reference</h2>
<p> <a href="https://effortguy.tistory.com/194">[클린 코드] 11장 - 시스템 (Systems)</a></p>
]]></description>
        </item>
        <item>
            <title><![CDATA[10장. 클래스]]></title>
            <link>https://velog.io/@ssu_hyun/10%EC%9E%A5.%ED%81%B4%EB%9E%98%EC%8A%A4</link>
            <guid>https://velog.io/@ssu_hyun/10%EC%9E%A5.%ED%81%B4%EB%9E%98%EC%8A%A4</guid>
            <pubDate>Wed, 20 Sep 2023 00:05:11 GMT</pubDate>
            <description><![CDATA[<ul>
<li>클래스 이름은 해당 클래스 책임을 기술해야 한다.</li>
<li>단일 책임 원칙(Single Responsibility Principle, SRP)<ul>
<li>클래스의 책임, 즉 변경할 이유는 단 하나뿐이어야 한다.</li>
<li>큰 클래스보다 작은 클래스 여럿으로 이루어진 시스템이 더 바람직하다. 작은 클래스는 각자 맡은 책임 즉, 변경할 이유가 하나며, 다른 작은 클래스와 협력해 시스템에 필요한 동작을 수행한다.</li>
</ul>
</li>
<li>응집도에 따라 함수를 작은 클래스 여럿으로 분리하게 되면 프로그램의 체계가 잡히고 구조가 더욱 투명해진다.</li>
<li>새 기능을 수정하거나 기존 기능을 변경할 때 건드릴 코드가 최소인 시스템 구조가 바람직하다. 이상적인 시스템이라면 새 기능을 추가할 때 시스템을 확장할 뿐 기존 코드를 변경하지는 않는다.<pre><code class="language-cs">// 아래 구조는 파생 클래스를 생성하는 방식으로 새 기능에 개방적인 동시에 다른 클래스를 닫아놓는 방식으로 수정에 폐쇄적이다.
public abstract class Sql()
{
  public void Sql(string table, Column[] columns);
  public abstract string Generate();
}
</code></pre>
</li>
</ul>
<p>public class CreateSql : Sql
{
    public void CreateSql(string table, Column[] columns);
    public override string Generate();
}</p>
<p>public class SelectSql : Sql
{
    public void SelectSql(string table, Column[] columns);
    public override string Generate();
}</p>
<p>public class InsertSql : Sql
{
    public void InsertSql(string table, Column[] columns, object[] fields);
    public override string Generate();
    private string valuesList(object[] fields, Column[] columns);
}</p>
<pre><code>- 낮은 시스템 결합도
  - 유연성과 재사용성 증가
  - 각 시스템 요소가 다른 요소로부터 그리고 변경으로부터 잘 격리되어있어 각 요소를 이해하기 쉬워진다. 
  - 자연스레 클래스 설계 원칙 DIP(Dependency Inversion Principle)를 따르게 됨
    - DIP : 클래스가 상세한 구현이 아닌 추상화에 의존해야 한다는 원칙
  - 인터페이스, 추상 클래스를 통해 구현 가능
  ```cs
  // 주식 기호를 받아 현재 주식 가격을 반환한다는 추상적인 개념 표현
  // 이와 같은 추상화로 실제로 주가를 얻어오는 출처나 알아오는 방식 등의 구체적인 사실들을 모두 숨김
  public interface IStockExchange
  {
    Money CurrentPrice(string symbol);
  }

  // Portfolio는 IStockExchange 인터페이스에 의존
  public class Portfolio
  {
    private IStockExchange exchange;

    public Portfolio(IStockExchange exchange)
    {
        this.exchange = exchange;
    }
    //...
  }</code></pre><pre><code class="language-cs">  // Test code
  public class PortfolioTest
  {
      private FixedStockExchangeStub exchange;
      private Porfolio portfolio;

      protected void SetUp() 
      {
        exchange = new FixedStockExchangeStub();
        exchange.fix(&quot;MSFT&quot;, 100);
        portfolio = new Portfolio(exchange);
      }

      // Test Method
      public void GivenFiveMSFTTotalShouldBe500()
     {
       try
       {
         portfolio.add(5, &quot;MSTF&quot;);
         Assert.assertEquals(500, portfolio.value());
       }
       catch
       {
         Assert.Fail($&quot;예외 발생: {ex.Message}&quot;);
       }
     }
  }
</code></pre>
]]></description>
        </item>
        <item>
            <title><![CDATA[9장. 단위 테스트]]></title>
            <link>https://velog.io/@ssu_hyun/9%EC%9E%A5.%EB%8B%A8%EC%9C%84-%ED%85%8C%EC%8A%A4%ED%8A%B8</link>
            <guid>https://velog.io/@ssu_hyun/9%EC%9E%A5.%EB%8B%A8%EC%9C%84-%ED%85%8C%EC%8A%A4%ED%8A%B8</guid>
            <pubDate>Wed, 20 Sep 2023 00:04:41 GMT</pubDate>
            <description><![CDATA[<ul>
<li><p>TEMPLATE METHOD 패턴 -&gt; 중복 코드 제거 가능</p>
<ul>
<li><p>부모 : given/when 부분 코드 </p>
</li>
<li><p>자식 : then 부분 코드</p>
<pre><code class="language-cs">public void testGetPageHierarchyAsXml() throws Exception{
  givenPages(&quot;PageOne&quot;, &quot;PageOne.ChildOne&quot;, &quot;PageTwo&quot;);

    whenRequestIsIssued(&quot;root&quot;, &quot;type:pages&quot;);

    thenResponseShouldbeXML();
}</code></pre>
</li>
</ul>
</li>
<li><p>테스트 함수 하나는 개념 하나만 테스트할 것</p>
</li>
<li><p>F.I.R.S.T</p>
<ul>
<li>Fast : 테스트는 빨라야 한다.</li>
<li>Independent : 각 테스트는 서로 의존하면 안 된다.</li>
<li>Repeatable : 테스트는 어떤 환경에서도 반복 및 실행이 가능해야한다.</li>
<li>Self-Validating : 테스트는 bool값(성공 or 실패)으로 결과를 내야 한다.</li>
<li>Timely : 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다.</li>
</ul>
</li>
<li><p>테스트 코드는 실제 코드의 유연성, 유지보수성, 재사용성을 보존하고 강화한다.</p>
</li>
<li><p>테스트 코드는 지속적으로 깨끗하게 관리하며 표현력을 높여 간결하게 정리해야만 한다. 특히 테스트 API를 구현해 도메인 특화 언어를 만들면 테스트 코드를 짜기가 쉬워진다.</p>
</li>
</ul>
]]></description>
        </item>
        <item>
            <title><![CDATA[8장. 경계]]></title>
            <link>https://velog.io/@ssu_hyun/8%EC%9E%A5.%EA%B2%BD%EA%B3%84</link>
            <guid>https://velog.io/@ssu_hyun/8%EC%9E%A5.%EA%B2%BD%EA%B3%84</guid>
            <pubDate>Wed, 20 Sep 2023 00:04:05 GMT</pubDate>
            <description><![CDATA[<ul>
<li>외부 패키지를 호출하는 코드를 가능한 줄여 경계를 관리하자. Map에서 봤듯이, 새로운 클래스로 경계를 감싸거나 아니면 ADAPTER 패턴을 사용해 <U>우리가 원하는 인터페이스를 패키지가 제공하는 인터페이스로 변환</U>하자. 어느 방법이든 코드 가독성이 높아지며, 경계 인터페이스를 사용하는 일관성도 높아지며, 외부 패키지가 변했을 때 변경할 코드도 줄어든다.</li>
</ul>
]]></description>
        </item>
        <item>
            <title><![CDATA[7장. 오류 처리]]></title>
            <link>https://velog.io/@ssu_hyun/7%EC%9E%A5.%EC%98%A4%EB%A5%98-%EC%B2%98%EB%A6%AC</link>
            <guid>https://velog.io/@ssu_hyun/7%EC%9E%A5.%EC%98%A4%EB%A5%98-%EC%B2%98%EB%A6%AC</guid>
            <pubDate>Wed, 20 Sep 2023 00:03:40 GMT</pubDate>
            <description><![CDATA[<ul>
<li>오류 발생보다 예외를 발생시킬 것<ul>
<li>발생시킬 때 보다 구체적이면 그 원인과 위치를 찾기가 쉽다.</li>
</ul>
</li>
<li>코드 상에서 null을 최대한 줄이는 것이 좋음 (반환, 전달, 발생 등등)</li>
</ul>
]]></description>
        </item>
        <item>
            <title><![CDATA[6장. 객체와 자료구조]]></title>
            <link>https://velog.io/@ssu_hyun/6%EC%9E%A5.%EA%B0%9D%EC%B2%B4%EC%99%80-%EC%9E%90%EB%A3%8C%EA%B5%AC%EC%A1%B0</link>
            <guid>https://velog.io/@ssu_hyun/6%EC%9E%A5.%EA%B0%9D%EC%B2%B4%EC%99%80-%EC%9E%90%EB%A3%8C%EA%B5%AC%EC%A1%B0</guid>
            <pubDate>Wed, 20 Sep 2023 00:03:16 GMT</pubDate>
            <description><![CDATA[<ul>
<li><p>자료 추상화</p>
<ul>
<li><p>자료를 세세하게 공개하기보다는 추상적인 개념으로 표현하는 것이 좋다.</p>
<pre><code class="language-cs">// 지양해야할 코드 : 구체적인 값의 자료
public class Point 
{
  public double x;
  public double y;
}

public interface Vehicle
{
  double getFuelTankCapacityInGallons();
  double getGallonsOfGasoline();
}

// 지향해야할 코드 : 추상적인 개념의 자료
public interface Point
 {
  double getX();
  double getY();
  void setCartesian(double x, double y);
  double getR();
  double getTheta();
  double setPolar(double r, double theta);
}

public interface Vehicle
{
  double getPercentFuelRemaining();
}</code></pre>
<ul>
<li>객체는 동작을 공개하고 자료를 숨기므로 기존 동작을 변경하지 않으면서 새 객체 타입을 추가하기는 쉽지만 새 동작을 추가하기는 어렵다.</li>
<li>자료 구조는 별다른 동작 없이 자료를 노출하므로 기존 자료 구조에 새 동작을 추가하기는 쉬우나, 기존 함수에 새 자료 구조를 추가하기는 어렵다.</li>
</ul>
</li>
</ul>
</li>
</ul>
]]></description>
        </item>
        <item>
            <title><![CDATA[5장. 형식 맞추기]]></title>
            <link>https://velog.io/@ssu_hyun/5%EC%9E%A5.%ED%98%95%EC%8B%9D-%EB%A7%9E%EC%B6%94%EA%B8%B0</link>
            <guid>https://velog.io/@ssu_hyun/5%EC%9E%A5.%ED%98%95%EC%8B%9D-%EB%A7%9E%EC%B6%94%EA%B8%B0</guid>
            <pubDate>Wed, 20 Sep 2023 00:02:32 GMT</pubDate>
            <description><![CDATA[<ul>
<li>종속 함수<ul>
<li>&#39;호출하는 함수 &gt; 호출되는 함수&#39; 순으로 작성 (호출되는 함수를 찾기가 쉬워지고 모듈 가독성 상승)</li>
</ul>
</li>
</ul>
]]></description>
        </item>
        <item>
            <title><![CDATA[4장. 주석]]></title>
            <link>https://velog.io/@ssu_hyun/4%EC%9E%A5.%EC%A3%BC%EC%84%9D</link>
            <guid>https://velog.io/@ssu_hyun/4%EC%9E%A5.%EC%A3%BC%EC%84%9D</guid>
            <pubDate>Wed, 20 Sep 2023 00:01:44 GMT</pubDate>
        </item>
        <item>
            <title><![CDATA[3장. 함수]]></title>
            <link>https://velog.io/@ssu_hyun/3%EC%9E%A5.%ED%95%A8%EC%88%98</link>
            <guid>https://velog.io/@ssu_hyun/3%EC%9E%A5.%ED%95%A8%EC%88%98</guid>
            <pubDate>Wed, 20 Sep 2023 00:00:51 GMT</pubDate>
            <description><![CDATA[<ul>
<li>함수를 만드는 규칙<ol>
<li>작게, 더 작게 만들기</li>
<li>확실히 &#39;한 가지&#39; 작업만 할 것</li>
<li>함수 당 추상화 수준은 하나로</li>
</ol>
</li>
<li>함수에서 상태를 변경해야 한다면 함수가 속한 객체 상태를 변경하는 방식을 택한다.</li>
</ul>
]]></description>
        </item>
        <item>
            <title><![CDATA[2장. 의미 있는 이름]]></title>
            <link>https://velog.io/@ssu_hyun/2%EC%9E%A5.%EC%9D%98%EB%AF%B8-%EC%9E%88%EB%8A%94-%EC%9D%B4%EB%A6%84</link>
            <guid>https://velog.io/@ssu_hyun/2%EC%9E%A5.%EC%9D%98%EB%AF%B8-%EC%9E%88%EB%8A%94-%EC%9D%B4%EB%A6%84</guid>
            <pubDate>Tue, 19 Sep 2023 23:59:38 GMT</pubDate>
            <description><![CDATA[<ul>
<li>의도를 분명히 밝힐 것<ul>
<li>따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다.</li>
<li>코드의 함축성 : 코드 맥락이 코드 자체에 명시적으로 드러나야함<pre><code class="language-cs">// Before
public List&lt;int[]&gt; GetThem()
{
List&lt;int[]&gt; list1 = new List&lt;int[]&gt;();
foreach (int[] x in theList)
{
    if (x[0] == 4)
        list1.Add(x);
}
return list1;
}</code></pre>
<pre><code class="language-cs">// After
public List&lt;int[]&gt; GetFlaggedCells()
{
List&lt;Cell&gt; flaggedCells = new List&lt;Cell&gt;();
foreach (Cell cell in gameBoard)
{
    if (cell.isFlagged())
        flaggedCells.Add(cell);
}
return flaggedCells;
}</code></pre>
</li>
</ul>
</li>
<li>그릇된 정보를 피할 것<ul>
<li>약어 사용도 주의할 것</li>
<li>일관성이 떨어지는 표기법은 그릇된 정보다.</li>
</ul>
</li>
<li>의미 있게 구분하라<ul>
<li>이름이 달라야 한다면 의미도 달라져야 한다. </li>
<li>읽는 사람이 차이를 알도록 이름을 지어라.<pre><code class="language-cs">// 불용어보다 source, destination이라는 명확한 인수 이름을 사용한다면 코드 읽기가 훨씬 더 쉬워진다.
public static void CopyChars(char[] a1, char[] a2)  
{
for (int i = 0; i &lt; a1.Length; i++)
{
    a2[i] = a1[i];
}
}</code></pre>
</li>
</ul>
</li>
<li>발음하기 쉬운 이름을 사용하라</li>
<li>검색하기 쉬운 이름을 사용하라                 </li>
</ul>
<ul>
<li>똑똑한 프로그래머와 전문가 프로그래머 사이에서 나타나는 차이점 하나만 들자면, 전문가 프로그래머는 명료함이 최고라는 사실을 이해한다. 전문가 프로그래머는 자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드를 내놓는다.</li>
<li>재미난 이름보다 명료한 이름을 선택하라. ... 의도를 분명하고 솔직하게 표현하라.</li>
<li>프로그래머는 코드를 최대한 이해하기 쉽게 짜야 한다. 집중적인 탐구가 필요한 코드가 아니라 대충 훑어봐도 이해할 코드 작성이 목표다. </li>
</ul>
]]></description>
        </item>
        <item>
            <title><![CDATA[1장. 깨끗한 코드]]></title>
            <link>https://velog.io/@ssu_hyun/1%EC%9E%A5.%EA%B9%A8%EB%81%97%ED%95%9C-%EC%BD%94%EB%93%9C</link>
            <guid>https://velog.io/@ssu_hyun/1%EC%9E%A5.%EA%B9%A8%EB%81%97%ED%95%9C-%EC%BD%94%EB%93%9C</guid>
            <pubDate>Tue, 19 Sep 2023 23:58:27 GMT</pubDate>
            <description><![CDATA[<ul>
<li>DSL(Domain Specific Language)
  : 도메인에 특화된 언어는 특정 문제 도메인, 특정 문제 표현 기법, 특정 문제 해결 기법에 사용할 목적으로 만든 프로그래밍 언어나 명세 언어를 의미한다. 해당 분야 전문가들의 의사 소통을 돕기 위해, 모호함을 없애며 표현력을 높인 특징이 있다.</li>
<li>궁극적으로 코드는 <U>요구사항을 표현하는 언어</U>라는 사실을 명심한다.</li>
<li>간단한 코드의 규칙<ul>
<li>중복을 피하라</li>
<li>한 기능만 수행하라</li>
<li>제대로 표현하라</li>
<li>작게 추상화하라</li>
</ul>
</li>
<li>이만큼 깨끗한 코드는 너무도 잘 짜놓은 코드라 읽는 이가 그 사실을 모르고 넘어간다. 모든 뛰어난 설계처럼 설계자가 코드를 어이 없을 정도로 단순하게 설계했기 때문이다.</li>
<li>기존 코드를 읽어야 새 코드를 짜므로 읽기 쉽게 만들면 사실을 짜기도 쉬워진다.                                               - Agile Software Development : Principles, Patterns, and Practices의 다섯 가지 원칙<ul>
<li>SRP(The Single Responsibility Principle) : 클래스에는 한 가지, 단 한 가지 변경 이유만 존재해야 한다.</li>
<li>OCP(The Open Closed Principle) : 클래스는 확장에 열려 있어야 하며 변경에 닫혀 있어야 한다.</li>
<li>LSP(The Liskov Substitution Principle) : 상속받은 클래스는 기초 클래스를 대체할 수 있어야 한다.</li>
<li>DIP(The Dependency Inversion Principle) : 추상화에 의존해야 하며, 구체화에 의존하면 안 된다.</li>
<li>ISP(the Interface Segregation Principle) : 클라이언트에 밀접하게 작게 쪼개진 인터페이스를 유지한다.</li>
</ul>
</li>
</ul>
]]></description>
        </item>
        <item>
            <title><![CDATA[Clean Code]]></title>
            <link>https://velog.io/@ssu_hyun/Clean-Code-n844xl6c</link>
            <guid>https://velog.io/@ssu_hyun/Clean-Code-n844xl6c</guid>
            <pubDate>Tue, 19 Sep 2023 23:56:36 GMT</pubDate>
            <description><![CDATA[<p><img src="https://velog.velcdn.com/images/ssu_hyun/post/9ac54ac0-29d6-4491-a757-c0deaf88d47d/image.png" alt=""></p>
<h2 id="brbr"> </br></br></h2>
<h2 id="reference">Reference</h2>
<p> <a href="https://github.com/Yooii-Studios/Clean-Code">Github - Clean Code</a>
 <a href="https://effortguy.tistory.com/184">https://effortguy.tistory.com/184</a></p>
]]></description>
        </item>
        <item>
            <title><![CDATA[승려와 수수께끼]]></title>
            <link>https://velog.io/@ssu_hyun/%EC%8A%B9%EB%A0%A4%EC%99%80-%EC%88%98%EC%88%98%EA%BB%98%EB%81%BC</link>
            <guid>https://velog.io/@ssu_hyun/%EC%8A%B9%EB%A0%A4%EC%99%80-%EC%88%98%EC%88%98%EA%BB%98%EB%81%BC</guid>
            <pubDate>Sat, 12 Aug 2023 10:44:55 GMT</pubDate>
            <description><![CDATA[<p><img src="https://velog.velcdn.com/images/ssu_hyun/post/bb6ef99f-475c-4da1-ac28-bed4d5569f49/image.png" alt=""></p>
<ul>
<li><p>p.0
다른 사람이 그린 지도, 다른 사람이 밟던 길을 따라가는 게 무슨 의미가 있을까? 이건 내 여행이고 내 인생이다. 내겐 더 이상 인생을 낭비할 시간이 없다.</p>
</li>
<li><p>p.5
매 순간 어떤 형태가 손이나 얼굴에서 완벽하게 그려지는가 하면, 자연의 언덕이나 바다에 표현되는 느낌이 다른 어떤 것보다 마음을 끌기도 한다. 한순간 열정이나 깨달음, 지적 환희가 거부하지 못할 만큼 생생하고 매력적으로 다가올 때도 있다. 중요한 건 경험의 결과가 아닌, 경험 그 자체이다.
우리에겐 이 다채롭고 극적인 삶에 대해 한정된 시간만이 허락되었다. 어떻게 하면 그 속에서 가장 정교한 감각의 눈을 통해 모든 걸 놓치지 않고 볼 수 있을 것인가. 어떻게 하면 매 순간 삶의 에너지가 절정으로 타오르는 지점에 항상 발을 딛은 채로 끊임없이 움직일 수 있을 것인가. 이 단단하고 보석 같은 불꽃으로 언제나 활활 타오르며 이 환희를 유지한다면 우리의 인생은 성공한 것이다.</p>
</li>
<li><p>p.8
파스칼은 &#39;고뇌에 지는 것은 수치가 아니다. 쾌락에 지는 것이야말로 수치이다. 고민하면서 길을 찾는 사람들, 그들이 참된 인간상이다&#39;라고 하였다.
그의 이 한마디는 &#39;파스칼의 삼각형&#39;보다 내게 더 귀했다. 무엇을 좋아하는지조차 몰라 방황하고 고민 속을 헤메던 내게 그럴 듯한 명분과 함께, 이것이 나의 끝이 아닌 참된 길을 찾아가는 과정일 뿐이라는 안도감을 줬기 때문이다.</p>
</li>
<li><p>p.10 
내가 배운 것 중 가장 잘한 것은 &#39;타인에게 무엇을 배울 것인가&#39;에 대한 준비가 항상 되어 있다는 점이다. 모순적이게도 누군가에게 무엇을 배운다는 것은 더욱 더 나를 독립적으로 만들어 줬다.</br>
&#39;하고 싶은 일을 하라. 해야만 하는 것보다... 그래야 진지해질 수 있고, 오래갈 수 있으며, 이를 지속함으로써 그 분야에서 뭔가를 이루고 마침내 성과를 낼 수 있다.&#39;</p>
</li>
<li><p>p.11
행복은 오로지 자신의 삶에 대한 진지한 목적의식과 내가 진정 원하는 것을 발견할 때 가능하다. 그리고 이것은 수많은 경험과 노력을 통해 발견되는 산물이다. 해보지도 않고 머릿속으로 그려서는 결코 발견하기 어렵다. 그래서 도전해야 한다. 해봐야 한다. </p>
</li>
<li><p>p.56
사업을 시작하려면 그 정도는 기본이다. 사업을 시작하는 사람들은 약간 비이성적이고 분석이 불가능할 만큼 열정적이어야 한다. 사업에 대해 의심이 들더라도 믿지 못한다면 성공할 수 없다.</p>
</li>
<li><p>p.63
틀을 벗어나 꿈을 좇는 사업가들과 이민자들에게는 공통점이 있다. 나는 믿음 하나에 모든 걸 거는 사람들을 존경한다. 이민자든 사업가든 이렇게 위험을 감수하는 사람들이 있어야 세상은 변할 수 있다. 그런 사람들은 실행이 불가능한 상황에도 미래에 베팅을 한다. 영웅이란 그런 사람들이 아닐까.</p>
</li>
<li><p>p.78
그들이 최선을 다해 이룬, 발전된 모습을 한 번 보십시오. 팀을 이탈하는 사람도 없고, 품질 역시 유지되고 있습니다. 사업을 진행시키면서 학습하려면 융통성이 있어야 하고, 늘 깨어 있어야 합니다. 경영진들은 유통을 맡은 파트너와 계약을 끝내고 대안을 모색하려고 노력 중입니다. 어떤 면으로 보나 그 팀은 업무를 훌륭히 수행하고 있습니다. 원칙적으로 계획은 초기단계에서만 필요한 겁니다. 즉, 창업자가 똑똑한지, 제대로 된 사업계획을 갖고 있는지, 미래에 대한 어떤 비전을 갖고 있는지를 때만 필요한 겁니다.</p>
</li>
<li><p>p.104
교훈을 얻으려면 실수를 딛고 일어설 줄 알아야 하며, 성공을 오랫동안 유지하려면 교훈을 통해 배울 수 있어야 한다.</p>
</li>
<li><p>p.106
레니는 사업가다운 면모를 가지고 있었다. 즉, 거대한 장애물을 과속방지턱으로 바꿀 꿋꿋한 의지력과 결단력을 지녔다.</p>
</li>
<li><p>p.108
나는 세월을 보내면서 사업이라는 게 돈을 버는 일이 아닌, 창의력을 펼치는 일이라고 생각하게 됐다. 마치 회화나 조각처럼 스프레드시트보다 캔버스를 더 좋아하는 사람들의 개성과 예술성을 보여 줄 분야라고 말이다. 왜냐고? 사업의 핵심은 변화이기 때문이다.</br>
기업은 변화에 대처하고 헤쳐 나가는 방법을 가르쳐 주는 몇 안되는 사회기관이다. </p>
</li>
<li><p>p.149
내가 &#39;평생을 바쳐도 좋을 만한....&#39;이라는 질문을 던졌을 때 레니는 그걸 명확한 인생계획을 세워야 한다는 의미로 받아들였다. 그건 정말 바보 같은 생각이다. 그가 이미 언급한 것처럼 세상은 끊임없이 변할 것이기 때문이다. 하지만 어떤 것에 평생을 기꺼이 바치려고 한다면 어떤 요소를 갖춰야 할지 고민하는 시간을 맞게 된다. 그제야 비로소 귀중한 자각이 가능해지는 것이다.</p>
</li>
<li><p>p.151
의욕(drive)과 열정(passion)에는 결정적 차이가 있다. ... drive는 인생에서 당장 해야 하는 것, 혹은 의무와 같은 걸 의미하며 passion은 진정 자신의 내면이 원하는 걸 의미함
열정이란, 어떤 것에 저항조차 할 수 없이 끌려드는 걸 말한다. 반면, 의욕이란 책임감 내지 해야만 한다고 생각되는 일에 떠밀려 가는 걸 말한다. 만약 스스로에 대해 아무것도 모른다면, 그 차이를 알 수 없을 것이다. 조금이나마 자기인식을 하고 있는 사람만이 어떤 분야에 스스로가 열정을 지녔는지 알 수 있다. 
&#39;미뤄진 인생계획&#39;을 놓고 생각해 보면 1단계에서 발휘되는 건 의욕이다. 즉, 잠시 보류시킨 2단계야 말로 열정의 본거지인 것이다.</p>
</li>
<li><p>p.163
오늘이 마지막 날이라고 한다면, 당신이 어떤 일을 하고 싶을지 생각해 보라는 뜻이었습니다. 의욕과 열정을 혼동하지 마십시오. 의욕은 앞으로 떠밀려 가는 걸 말합니다. 의무감과 책임감 때문에 말입니다. 열정은 당신을 끌어당기는 겁니다. 본래의 자신과 맞아떨어지는 일을 하고 있을 때 느끼는 유대감 같은 겁니다. 열정을 갖고 있어야 어려운 시기도 극복할 수 있게 됩니다. 가끔 MBA에서 강의를 할 때면 학생들에게 이런말을 들려주고는 합니다. 사업을 가치 있게 만드는 것은 재정이 아닌 애정이라고 말입니다. </p>
</li>
<li><p>p.207
사업이란 당연히 돈에 관한 일이다. 그건 사업을 만들어 내는 동기이기도 하다. 하지만 사업의 본질적 성공을 위해서는 사람에 관한 게 그 바탕에 자리해야 한다. </p>
</li>
<li><p>p.215
최우선으로 살펴야 할 건 서비스를 제공할 시장이다. 그 다음이 함께 일하는 팀원, 즉 직원들이다. 마지막이 사업 파트너와 협력업체들이다. &#39;리더들&#39;과 &#39;고객들을 위해 회사 전략을 제품과 서비스로 만들어 내는 사람들&#39; 사이에 가치 사슬이 끊긴다면 장기적 관점으로 볼 때 성공할 수 있는 기반이 파괴되는 것과 다름없다. 새롭게 일궈 내는 기업문화와 표방하려는 방침들은 직원들 상호간은 물론, 고객을 연결시키는 유일한 통로가 돼 줄 것이다. </p>
</li>
<li><p>p.247
그는 지금까지 외면하기만 했던 근본적인 문제들을 깊이 생각해 봐야 한다. 이 사업을 시작하는 이유가 뭔가? 자신이 중요하고 소중하게 생각하는 게 뭔가? 자신은 누구이며 사업을 통해 어떻게 본래의 자신을 표현할 건가?</p>
</li>
<li><p>p.250
그가 중요시했던 건 &#39;어떻게 하면 남들과 차별화 될 수 있을까&#39;가 아니라 &#39;어떻게 하면 돈을 벌기 위해 가장 위험하지 않는 길로 갈 수 있을까&#39; 하는 문제였다. 그 결과, 모순적이게도 그는 실리콘밸리에서 가장 위험한 방법인 평범함을 택했다.
레니는 실리콘밸리에서 사업상의 위험부담과 실패를 어떻게 생각하는지 잘 모르고 있다. 실리콘밸리에서는 실패의 가능성을 최소화하거나 없애기 위해 위험수위를 조절하기보다는 성공 가능성을 극대화하는 데 초점을 맞춘다. 실패는 성공을 위해 반드시 거쳐야 할 부분으로 생각하는 것이다.</p>
</li>
<li><p>p. 254
다음 봉우리 너머에는 무엇이 있는지, 다음 계곡 너머에는 무엇이 있는지를 모른 채 오랜 시간을 보내다 보면 인생에서 내가 통제할 수 있는 부분은 오직 나만의 장점밖에 없다는 것을 깨닫게 된다.
내가 창업 지망생들에게 사업상의 위험부담과 성공에 대해 이야기할 때면 해주는 말이 있다.
만약 당신이 똑똑하다면 위험부담이 15에서 20퍼센트 정도 감소한다. 하루에 24시간 일한다면 위험부담이 15에서 20퍼센트 정도 더 감소한다. 나머지 60에서 70퍼센트의 위험부담은 당신이 절대로 통제할 수 없는 부분이다. </p>
</li>
<li><p>p.255
성공의 척도를 행운과 함께 찾아오는 성과가 아닌, 실력이 얼만큼 발휘되는가로 삼아야 한다. 즉, 외부 여건을 통해서 만족감과 성취감을 느껴서는 안 된다. 또한 사업 그 자체의 성공이 아니라 자신이 어떤 일을 하는지, 자신이 어떤 사람인지에 그 토대를 둬야 한다. 세상에는 통제할 수 없는 부분도 있다는 걸 깨닫지 못한다면 심각한 실수를 저지르고 자원을 엉뚱하게 쓰며 시간을 낭비하는 일이 발생할 것이다.</p>
</li>
<li><p>p.256
가장 큰 위험부담은 미래의 행복을 위안으로 삼으며 원치 않는 일에 인생을 평생 낭비하게 되는 것이다.</p>
</li>
<li><p>p.258
개인의 위험부담을 생각하다 보면 자신이 생각하는 성공이 어떤건지를 규정해 볼 수 있다. ... 우리 대부분은 초등학교에서부터 대학교를 거쳐 직장 생활에 이르기까지, 끊임없는 방해 요소에 부딪치며 다른 사람들이 정의한 &#39;성공&#39;을 그대로 인식하게 된다. 또한 다른 사람들이 만든 기준으로 자신을 평가하고, 다른 사람들과 자신을 비교해 순위를 매기려 한다. 하지만 개인적인 목표는 오직 우리 스스로에게 놓여 있을 뿐, 쓸데없는 평가와 비교로부터 자유로운 것이다.</p>
</br>
열정을 다해 열심히 일해라. 단, 가장 소중한 재산인 시간을 가장 의미 있는 일에 써라. 남은 인생 동안 무엇을 하고 싶은가? 이 말은 앞으로 평생 무엇을 할 건지 묻는 게 아니다. 불가피한 변화를 생각한다면 이건 어리석은 질문인지도 모른다. 생각건대 내일 갑자기 삶이 끝나도 지금껏 진짜 하고 싶은 일을 하고 살았다며 자신 있게 말할 수 있는지를 묻고 싶던 건 아닐까? 당신은 앞으로 평생 어떤 일을 하고 싶은가? 지금 당장 그 일을 시작하려면 어떻게 해야 할까?
</li>
<li><p>안철수 교수 - KAIST 기업가 정신 수업 수강 노트</p>
<ul>
<li><p>창업 시 자신에게 던져야 할 본질적 질문은?</p>
<ul>
<li>기업가로서 위험부담을 이겨 내고, 미래에 닥칠 불확실성과 모호함, 흥망하는 시간들을 견뎌낼 만한 자질을 갖췄는지 물을 것</li>
</ul>
</li>
<li><p>창업 아이템을 정할 시 What과 When은 어떻게 판단하는가?</p>
<ul>
<li>&#39;What&#39;의 경우 기초검증 필요. 따라서 어떤 산업에 뛰어들지, 실제로 잘되기 위해 가상실험(Concept Test)을 거쳤는지 끊임없는 질문 던져야 함. <img src="https://velog.velcdn.com/images/ssu_hyun/post/9c16a3fb-32d0-41a6-88c5-e70360775de3/image.png" alt=""></li>
<li>&#39;When&#39;의 경우 일찍 시작하든 늦게 시작하든 그 시기가 중요치 않을 때가 많다. </li>
<li>먼저 나가는 것이 중요한 게 아니라, 제대로 된 제품과 서비스로 나가는 것이 더 중요하다. 따라서, 이를 통해 네트워크 효과를 얻어 내고, 자연스레 확장되게 하는 일이 가장 중요하다.</li>
</ul>
</li>
<li><p>마케팅의 핵심은?</p>
<ol>
<li>누가 타겟인가?</li>
<li>누가 경쟁자인가?</li>
<li>차별화 포인트는 무엇인가?</li>
</ol>
</li>
<li><p>협상의 핵심은?</p>
<ol>
<li>협상의 중요성을 파악한다. 예를 들어 무슨 수를 쓰더라도 성공해야 하는 것인지, 실패하더라도 상대방이 성공하지 못하게 하는 게 중요한지 등을 파악해야 한다.</li>
<li>상대방의 관심사를 생각하고, 그 해결책을 제시한다.</li>
<li>제안을 하되, 상대방이 받아들일 수 밖에 없는 대안 제시</li>
</ol>
</li>
<li><p>어떤 회사가 혁신적인 회사가 될 수 있는가?</p>
<ol>
<li>새로운 아이디어를 붇돋고, 시도해 보려는 기업문화가 있어야 함</li>
<li>올바르고 타당한 제도가 있어야 함</li>
<li>창의성을 받아들일 준비가 된 관리자가 있어야 함</li>
</ol>
</li>
<li><p>전략이란 무엇인가?</p>
<ul>
<li>목표달성을 위해 어떤 일을, 어떻게 할 건지 찾아내는 것</li>
</ul>
<ol>
<li>차별화가 돼야 함</li>
<li>가격경쟁력이 있어야 함</li>
</ol>
</li>
<li><p>벤처투자가는 어디에 투자하는가?</p>
<ul>
<li>사람, 시장규모, 시장경쟁력의 3요소가 뚜렷한 기업에 투자</li>
</ul>
</li>
<li><p>창업기업의 경영진들에게 필요한 준비 요건이 있다면?</p>
<ul>
<li>구성원 중, 한 명이라도 창업 경험이 있어야 한다.</li>
<li>해당 창업 분야의 전문성은 물론, 경험 역시 갖추고 있어야 한다.</li>
<li>전력을 통한 실행력이 중요하다.</li>
<li>윤리적이어야 한다.</li>
<li>구성원이 얼마나 자신의 인생을 비중 있게 투입하는가를 봐야 한다.</li>
<li>구성원은 서로 간에 상호보완적이 돼야 한다.</li>
<li>열정이 있어야 한다.</li>
<li>사업계획은 계속 변하므로 적응력을 갖춰야 한다.</li>
</ul>
</li>
<li><p>사업의 목적은 이윤창출인가?</p>
<ul>
<li>기업에게 있어 수익은 목적이 아닌 결과이다.</li>
<li>피터 드러커(Peter Drucker)는 &quot;기업의 첫번째 책임은 고객에게 서비스를 제공하는 것이다. 이윤은 최우선 목표가 아닌, 기업의 지속적 생존을 위해 필요한 본질적 조건이다.&quot;라고 설명했다. </li>
<li>기업은 주주의 이익을 위해 존재하기 이전에 사회의 모든 이해관계자의 기회창출을 도모한다.</li>
</ul>
</li>
<li><p>&#39;미뤄진 인생계획&#39;대로 살아가는 게 바람직하지 않은 이유는?</p>
<ul>
<li>돈을 버는 것만이 목적인 사람은 그런 종류의 성공을 위해 5년에서 7년의 힘겨운 시간을 견디지 못한다. 따라서 의미를 찾아야 하는 게 중요하다.</li>
<li>그럼, 무엇을 하고 싶은지 어떻게 알 수 있는가? 해보기 전에는 하고 싶은 일을 모르거나, 잘할지조차 모르는 경우도 많다. 강물만 쳐다봐서는 물의 빠르기를 알 수 없는 것처럼 말이다. 따라서 물에 뛰어들어야 한다. 그러고 나서 자신에게 맞는 일인지 아닌지를 판단하는 것이다. 이는 시간 낭비가 아닌, 경험의 자산이 된다. 그 경험은 결국 언젠가 자신의 삶에서 필요할 때가 반드시 오게 된다.</li>
<li>자신을 잘 알게 되는 순간은 무엇인가를 &#39;결정&#39;하거나 &#39;선택&#39;할 때이다. 말이나 생각이 아닌 행동만이 그 사람을 표현할 수 있다. 평생을 바쳐도 좋은 일이라는 것은 평생 그 일을 해야 한다는 의미가 아니다. 내일 당장 지구가 망하는 순간에도 하고 싶은 일을 해야 한다는 의미인 것이다.</li>
<li>많은 사람들이 가는 길이 반드시 안전한 길은 아니다. 자신의 적성에 맞는 일을 하며 오랫동안 적응하다 보면 성공할 수가 있다. 따라서 10,000시간을 견뎌 내려면 자신에게 맞는 일을 찾을 필요가 있다.</li>
</ul>
</li>
<li><p>리더십과 관리의 차이는?</p>
<ul>
<li>리더십이 사람을 중심으로 두고 타인의 협조를 이끌어 내며 공감을 얻는 것이라면, 관리는 일을 중심으로 두고 시간 내에 과업을 완수하는 것을 의미한다.</li>
<li>창업자는 관리자가 아닌, 리더가 돼야 한다.</li>
<li>리더십은 말이 아닌 행동이며, 대중으로부터 부여된다. 리더는 일관성과 전문성, 그리고 실행능력의 세 가지 요소를 모두 갖춰야 한다.</li>
<li>특히 일관성은 과거를 볼 때가 아니라 원래 생각했던 목표인 앞을 바라봐야 생긴다. 따라서 &#39;내가 왜 사업을 시작했는가, 사업의 원칙은 무엇인가&#39; 등의 질문은 초심을 유지하는 방법 중 하나일 것이다.</li>
</ul>
</li>
<li><p>성공이란?</p>
<ul>
<li>사람들은 어떤 일을 이루기 위한 대부분의 흐름이 과정임을 알아야 한다.</li>
<li>성공은 목적지가 아닌, 여정에서 맞닥뜨리는 행운일 뿐이다.</li>
<li>그렇기에, 인생에 무엇이 성공인지는 스스로 정의를 내려야 한다. 사람들의 생각을 바꾸고, 의미있는 생각을 남기며, 뭔가 변화되는 걸 남기는 것, 그게 바로 흔적을 남기는 일이다.</li>
</ul>
</li>
<li><p>창업 시 스스로에게 던져야 할 질문은?</p>
<ol>
<li>사업을 왜 시작하려 하는가?</li>
<li>창업이 자신의 인생에 어떤 영향을 미칠 것인가?</li>
<li>스스로를 사업할 만한 타입이라고 생각하는가?</li>
<li>자신을 편치 않게 만드는 사업의 모습이 있다면 무엇인가?</li>
</ol>
</li>
<li><p>창업 멤버들은 어떤 구성이 좋은가?</p>
<ul>
<li>가치관이 같은 구성원들이 오래간다. 공동 창업자들은 자신의 가치관을 솔직히 소통하는 일이 바람직하다.</li>
</ul>
</li>
<li><p>제품의 특성(Feature), 이익(Benefit), 가치(Value)</p>
<ul>
<li>특성 : 제품의 기능적인 특성 (제조자의 관점)</li>
<li>이익 : 제품으로 얻게 되는 이익 (소비자의 관점)</li>
<li>가치 : 제품의 특성이 있으면 소비자는 이익을 얻게 되는데 이 때 해당 이익을 가치로 느끼는지의 여부는 소비자가 결정</li>
<li>따라서 제품은 소비자에게 가치를 전달해야 한다는 명제를 잊지 않아야 함</li>
</ul>
</li>
<li><p>인생의 핵심적 시기는 언제인가?</p>
<ul>
<li>잘되고 있을 때가 아니라 어떤 장벽에 막혀 있는 순간, 어떤 방식으로 잘 대처하느냐가 인생 전체를 결정짓는다. </li>
<li>이 때 핵심은 편법이나 유혹에 빠지지 말 것, 좌절에 빠진 시기를 도리어 &#39;나의 문제를 고치는 시기&#39;로 생각할 것.</li>
</ul>
</li>
<li><p>어려운 시기를 헤쳐 나가려면?</p>
<ul>
<li>본질적으로 어려운 시기는 항상 생각보다 길게 느껴진다. 이럴 때, 근거 없는 희망과 낙관보다는 객관적인 현실 분석과 인식을 하는 사람이 더 오래 버틸 수 있다.</li>
<li>따라서 균형잡힌 시각을 가져야 한다. 즉, &#39;현실이 어렵다는 걸 알지만 자신은 이런 대안들을 통해서 결국 잘될 것&#39;이라는 판단에 근거한 믿음을 가질 필요가 있다.</li>
</ul>
</li>
<li><p>이 시대 청년들에게 전하는 조언은?</p>
<ul>
<li>시간을 엄수하라.</li>
<li>경청하라.</li>
<li>언제, 어느 곳이든 읽을거리를 갖고 다녀라.</li>
<li>무엇이든 잡지 하나를 구독하라.</li>
<li>아침마다 급한 일이 아닌, 중요한 일을 실행하라.</li>
<li>아이디어가 떠오르면 항상 메모하라.</li>
<li>어느 분야에 시간을 집중투자하라. 그만큼 즐길 수 있게 된다.</li>
<li>본디 계획 했던 일보다 항상 더 하라.</li>
<li>불평하지 마라. 이는 시간을 낭비하는 가장 좋은 방법이다.</li>
<li>생각의 틀을 깨라.</li>
<li>첫인상보다 더 중요한 건 마지막 인상이다.</li>
<li>실수는 모든 사람에게 자연스러운 것이니 두려워 마라.</li>
<li>스스로 인생의 주체가 돼서 살아라.</li>
</ul>
</li>
</ul>
</li>
</ul>
]]></description>
        </item>
        <item>
            <title><![CDATA[클린 소프트웨어]]></title>
            <link>https://velog.io/@ssu_hyun/%ED%81%B4%EB%A6%B0-%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-t7tzf5pp</link>
            <guid>https://velog.io/@ssu_hyun/%ED%81%B4%EB%A6%B0-%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-t7tzf5pp</guid>
            <pubDate>Mon, 10 Jul 2023 13:16:19 GMT</pubDate>
            <description><![CDATA[<p><img src="https://velog.velcdn.com/images/ssu_hyun/post/82ebd510-13ae-40a7-bb65-91bc81160acb/image.png" alt=""></p>
</br>

<h2 id="1-애자일-실천방법">1. 애자일 실천방법</h2>
<ul>
<li>애자일 소프트웨어 개발 선언문<ol>
<li>프로세스와 툴보다 개인과 상호작용이 우선이다.<ul>
<li>동료와의 커뮤니케이션, 상호작용 능력 &gt; 프로그래밍 실력<ul>
<li>툴은 간소하게 시작</li>
<li>팀 구성은 환경 구축보다 더 중요</li>
</ul>
</li>
</ul>
</li>
<li>포괄적인 문서보다 동작하는 소프트웨어가 우선이다.<ul>
<li>새로운 팀원에게 정보를 전할 수 있는 제일 좋은 기록은 코드(code)와 팀(team)이다.</li>
</ul>
</li>
<li>계약 협상보다 고객 협력이 우선이다.<ul>
<li>성공의 열쇠는 한정된 비용으로 일의 범위와 기한을 명시하는 것보다는 고객과의 협력과 이런 협력 과정을 관리하는 계약에 있었다.</li>
</ul>
</li>
<li>계획을 따르는 것보다 변화에 대한 반응이 우선이다.<ul>
<li>프로젝트의 성공과 실패를 좌우하는 것은 변화에 대한 반응 능력이다.</li>
</ul>
</li>
</ol>
</li>
</ul>
<p></br></br></p>
<h2 id="2-익스트림-프로그래밍xp--extreme-programming">2. 익스트림 프로그래밍(XP : Extreme Programming)</h2>
]]></description>
        </item>
        <item>
            <title><![CDATA[표현의 기술]]></title>
            <link>https://velog.io/@ssu_hyun/%ED%91%9C%ED%98%84%EC%9D%98-%EA%B8%B0%EC%88%A0</link>
            <guid>https://velog.io/@ssu_hyun/%ED%91%9C%ED%98%84%EC%9D%98-%EA%B8%B0%EC%88%A0</guid>
            <pubDate>Fri, 07 Jul 2023 04:00:08 GMT</pubDate>
            <description><![CDATA[<p><img src="https://velog.velcdn.com/images/ssu_hyun/post/a5fc3267-fb6c-401f-87d8-d5aaf7fdf252/image.png" alt=""></p>
<ul>
<li><p>p.4~5
표현의 기술은 마음에서 나옵니다.</br>
글쓰기는 결국 내면을 표현하는 일입니다.</p>
</li>
<li><p>p.30
누가 쓴 책이든, 무엇에 관한 책이든 비판적으로 읽는 게 기본입니다.</br>
책은 모두 사람이 쓴 겁니다. 가방끈이 얼마나 길든, 하는 일이 뭐든, 사람은 다 비슷한 결함을 지니고 있습니다. 잘 속이고, 쉽게 속아 넘어가고, 편견과 고정관념에 빠지고, 감정과 충동에 휘둘리고, 믿고 싶은 것만 믿으려고 하는 동물. 우리는 모두 그런 불완전한 존재로서 책을 읽고 글을 씁니다.그래서 누가 쓴 어떤 책이든 다 비판적으로 읽어야 한다는 겁니다.</p>
</li>
<li><p>p.32
훌륭한 생각과 감정을 아름답게 표현한 글은 저절로 정치적 영향력을 행사하게 됩니다. 정치적 목적을 잘 이루려면 아름답게 글을 써야 합니다.</p>
</li>
<li><p>p.39
우리는 내면에 지닌 생각과 감정을 글로 씁니다. 당연한 말이죠? 글쓰기는 이미 가지고 있는 것을 문자로 표현하는 작업입니다. 내게 없는 것을 만들어 쓰지는 못합니다. 이렇게 본다면 &#39;글짓기&#39;가 아니라 &#39;글쓰기&#39;가 더 적절한 표현이지요.</p>
</li>
<li><p>p.42
글 쓰는 사람은 자신이 누구인지 알아야 합니다. 그래야 자기답게 글을 쓸 수 있습니다.</br>
그래서 저는 늘 이렇게 생각하면서 글을 씁니다. &quot;내 생각과 감정을 나다운 시각과 색깔로 써야 한다. 내 목소리를 내야 한다. 진부하고 상투적인 생각과 표현에서 멀어져야 한다.&quot;</p>
</li>
<li><p>p.44
말과 글은 사람의 세계관과 철학을 드러냅니다.</br>
글을 쓰면 제 모습이 더 잘 보입니다. 일부러 들여다보지 않아도 저절로 그렇게 됩니다. 주된 효과인지 부작용인지는 모르겠지만, 어쨌든 글쓰기는 자기 성찰을 동반하는 것이죠.</br>
그러나 권력과 돈만 속박인 것은 아닙니다. 우리들 각자가 지닌 생각도 때로 속박이 됩니다. 살아가려면 세상을 이해해야 하고, 세상을 이해하려면 생각의 틀이 있어야 합니다.</p>
</li>
<li><p>p.46
어떤 &#39;주의&#39;를 받아들여 사용하면서도 거기 속박당하지 않으려면 어떻게 해야 할까요? 제가 찾은 방법은 직관을 믿는 것입니다. 어떤 &#39;주의&#39;의 원칙이나 교조보다 마음이 내는 소리에 먼저 귀를 기울이는 것이지요.</p>
</li>
<li><p>p.48~49
정언명령 1번은 &quot;스스로 세운 준칙에 따라 행동하되 그 준칙이 보편적 법칙이 될 수 있도록 하라&quot;는 것이고, 2번은 &quot;자기 자신이든 타인이든 사람을 수단으로 삼지 말고 언제나 목적으로 대하라&quot;는 것입니다. 이렇게 살아야 행복하게 살 자격을 얻는다는 주장입니다. 그저 욕망을 충족하는 데만 매달려 사는 사람은 중력에 끌려 바닥으로 떨어지는 당구공이나 마찬가지라고 했습니다. 행복을 누리려면 욕구의 노예가 되지 말고 삶의 주인이 되라는 조언이지요.</br>
정언명령은 &#39;이성을 사용하는 규칙&#39;입니다. 칸트는 이 규칙을 인식하는 것은 이성 그 자체의 기능이라고 주장했습니다. 특별히 배우거나 경험하지 않아도 누구나 도덕법을 알 수 있다는 뜻입니다.</p>
</li>
</ul>
<blockquote>
<p><strong><em>&#39;스스로 세운 준칙에 따라 행동하되 그 준칙이 보편적 법칙이 될 수 있도록 하라&#39;</em></strong></p>
</blockquote>
<ul>
<li>인간의 모든 행위는 의지의 표상이고, 모든 의지는 어떤 준칙에 따라 형성되는데 이 준칙이 바로 &#39;보편적 입법원리&#39;에 합당해야 한다는 것</li>
</ul>
<blockquote>
<p><strong><em>&#39;인간을 수단으로 대하지말고, 목적으로 대우하라&#39;</em></strong></p>
</blockquote>
<ul>
<li><p>각자는 자기 준칙의 입법자로서 자유롭고 동등한 자율적 인격체로 존중 받아야 한다는 의미.</p>
</li>
<li><p>인간관계에 있어 서로가 서로에게 갖는 수단/도구로서의 의미를 전적으로 배제할 수는 없으므로 이는 수단으로&#39;만&#39; 대하지말고, &#39;언제나 동시에&#39; 목적으로 대우하라는 의미. 수단일 수 밖에 없는 불가피한 상황에서도 항상/동시에 목적을 염두에 두고 있어야 한다는 의미.</p>
</li>
<li><p>인간 존재의 궁극성/목적 = 모든 인간은 동등한 가치와 동등한 존엄을 갖는 독립된 인격체이므로 각자는 자신의 의지와 준칙에 따른 행위능력을 갖고 그 행위는 존중받아 마땅하다는 사실</p>
</li>
<li><p>행위능력으로서의 자기결정권을 말하는 실천이성의 자율성에 대한 상호존중과 상호인정이 바로 위 문장이 뜻하는 바.</p>
</li>
<li><p>인간을 수단으로 대하는 경우 : 상대의 의지/판단/결정/행위 등에 대한 무시나 경멸이 내면에 존재하고 자율적 자기결정권을 갖는 동등한 인격체로서의 존중감이 없다는 것 의미</p>
</li>
<li><p>목적으로 대우받지 못한 자 보다는 목적을 망각한 자에게 더 치명적인 인간성 상실을 결과한다.</p>
</li>
<li><p>인간은 누구나 동등하고 자유로운 자기결정권을 갖는 존엄한 존재이므로, 이러한 사실에 대한 상호인정과 상호존중이 바로 &#39;목적으로서의 인간&#39;에 대한 예의</p>
</li>
<li><p>수단에 집중하면 추진력을 얻을 수 있고, 목적에 집중하면 방향성을 얻을 수 있다.</p>
<ul>
<li>수단은 속력에 도움을 주지만 그것이 속도를 의미하진 않는다. 눈을 감고 감각에 의존하며 전력 질주를 하는 것과 같은 이치다. 빠르게 달릴 수야 있겠지만 올바른 방향으로 가는지 알 수 없고, 중간에 장애물이 닥쳐도 피하기는 커녕 대체로는 인지조차 할 수 없으며, 나중에 다른 방향이라는 것을 직감적으로 알게 되어도 바로 방향을 틀 수 없다. 그렇기에 우리는 틈틈이 목적을 확인하며 본인이 바라는 방향대로 가고있는지 확인할 필요가 있다.</li>
</ul>
</li>
<li><p>p.50
이념은 세상을 바라보는 데 유용한 인식의 틀이지만, 사람의 생각을 속박하는 족쇄가 될 수 있습니다. 글 쓰는 사람이 미학적 열정을 자유롭게 발현하려면 어떤 도그마에도 예속되지 말아야 합니다. 그렇게 믿기 때문에 저는 어떤 &#39;주의&#39;가 아니라 &#39;옳은 것&#39;과 &#39;선한 것&#39; 그리고 &#39;아름다운 것&#39;을 알아볼 수 있는 직관의 힘에 의지합니다. 나쁜 감정과 고약한 충동에 휘둘리지 않으려고 애씁니다. 그래야만 &#39;우리 본성의 선한 천사&#39;와 도덕적 미학적 직관이 날개를 펼 수 있기 때문이죠.</p>
</li>
<li><p>p.54~56
정치인이든 평범한 시민이든 견해가 달라서 말과 글로 싸울 때는 창의적으로, 개성 있게, 예술적으로 싸워야 합니다.</br>
예술성이 완전히 꽝인 글로는 다른 사람의 생각을 움직이지 못한다는 이야기를 하는 겁니다. 막말로 감정을 배설하거나 거짓말로 남을 비방하지 않고 제대로 주장을 펼친다면 논쟁은 좋은 겁니다. 예술이 될 수도 있습니다.</br>
저는 진리가 아니라 &#39;관용&#39;이 우리를 자유롭게 한다고 믿습니다. 진리에 대한 집착과 확신은 오히려 자유를 파괴합니다.</br>
예술적인 글을 쓰려면 무엇보다 독창적으로 생각해야 합니다.</p>
</li>
<li><p>p.59
예술성은 문장의 아름다움과 아울러 독창적인 논리의 미학을 요구합니다. 그런 글을 쓰려면 생각과 감정에 자유의 날개를 달아 놓아야 해요.</br>
예술적으로 쓰고 싶다면 자유롭게 생각하고 스스로 판단하는 습관을 길러야 합니다. 정해진 도그마보다 자기 자신의 눈과 생각, 마음과 감정을 믿는 게 현명합니다.</br>
예술은 자유를 먹고 피어납니다.
고정관념과 이념의 교조에 생각과 감정이 묶이면 글이 진부해집니다.
진부냐 보수냐? 내 이념을 어떻게 글쓰기에 반영할까? 창의적인 글을 쓰고 싶다면 이런 헛된 질문을 털어 버리고 오로지 아름다운 것과 옳은 것만 생각하면서 글을 쓰시기 바랍니다. 저는 그렇게 씁니다.</p>
</li>
<li><p>p.76
더러운 것을 더러워서 피하면 이기는 것이지만 두려워서 피하면 지는 겁니다.</p>
</li>
<li><p>p.</p>
</li>
</ul>
]]></description>
        </item>
        <item>
            <title><![CDATA[모순]]></title>
            <link>https://velog.io/@ssu_hyun/%EB%AA%A8%EC%88%9C</link>
            <guid>https://velog.io/@ssu_hyun/%EB%AA%A8%EC%88%9C</guid>
            <pubDate>Mon, 05 Jun 2023 22:47:17 GMT</pubDate>
            <description><![CDATA[<p><img src="https://velog.velcdn.com/images/ssu_hyun/post/b1e58ef3-9f06-4f42-beb2-3cc318d21334/image.png" alt=""></p>
<ul>
<li><p>p.8
우리들은 남이 행복하지 않은 것은 당연하게 생각하고 자기 자신이 행복하지 않은 것에 대해서는 언제나 납득할 수 없어한다.</p>
</li>
<li><p>p.22
그랬다. 이렇게 살아서는 안 되는 것이었다. 내가 내 삶에 대해 졸렬했다는 것, 나는 이제 인정한다. 지금부터라도 나는 내 생을 유심히 관찰하면서 살아갈 것이다. 되어 가는 대로 놓아두지 않고 적절한 순간, 내 삶의 방향키를 과감하게 돌릴 것이다. 인생은 그냥 받아들이는 것이 아니라 전 생애를 걸고라도 탐구하면서 살아야하는 무엇이다. 그것이 인생이다.....</p>
</li>
<li><p>p.168
인생이란 때때로 우리로 하여금 기꺼이 악을 선택하게 만들고, 우리는 어쩔 수 없이 그 모순과 손잡으며 살아가야 한다는 사실을 주리는 정말 조금도 눈치채지 못하고 있는 것일까.</p>
</li>
<li><p>p.176
세상은 네가 해석하는 것처럼 옳거나 나쁜 것만 있는 게 아냐. 옳으면서도 나쁘고, 나쁘면서도 옳은 것이 더 많은 게 우리가 살아가는 세상이야. 네가 하는 박사 공부는 그렇게 단순한지 모르겠지만, 내가 살아보는 삶은 결코 단순하지 않았어. 나도 아직 잘 모르지만.</p>
</li>
<li><p>p.179
나는 이모를 위해 아무것도 모르는 척 했다. 주리 식으로 말한다면 이런 거짓말도 분명 &#39;옳지 못한 것&#39;이겠지만 나는 주리가 아니고 안진진이었으므로 얼마든지 그렇게 할 수 있었다.</p>
</li>
<li><p>p.182
나의 불행에 위로가 되는 것은 타인의 불행뿐이다. 그것이 인간이다. 억울하다는 생각만 줄일 수 있다면 불행의 극복은 의외로 쉽다. 상처는 상처로밖에 위로할 수 없다.</p>
</li>
<li><p>p.200
그러나 한없이 달릴 수는 없는 일이었다. 달리기만 할 줄 알고 멈출 줄은 모르는 자동차는 아무 쓸모도 없는 물건이듯이, 인생도 그런 것이었다. 언젠가는 멈추기도 해야 하는 것이었다. </p>
</li>
<li><p>p.296
삶의 어떤 교훈도 내 속에서 체험된 후가 아니면 절대 마음으로 들을 수 없다.</br>
인생은 탐구하면서 살아가는 것이 아니라, 살아가면서 탐구하는 것이다. 실수는 되풀이된다. 그것이 인생이다...</p>
</li>
<li><p>p.303
우리들 모두, 인간이란 이름의 일란성 쌍생아들이 아니었던가 하는 자각 </br>
새삼스런 강조일 수도 있겠지만, 인간이란 누구나 각자 해석한 만큼의 생을 살아낸다. 해석의 폭을 넓히기 위해서는 사전적 정의에 만족하지 말고 그 반대어도 함께 들여다볼 일이다. 행복의 이면에 불행이 있고, 불행의 이면에 행복이 있다. </p>
</li>
<li><p>p.306
우리들 삶의 내면을 들여다보면 모든 것이 모순투성이였다. 이론상의 진실과 마음속 진실은 언제나 한 방향만을 가리키는 것이 아니었다. ⌜모순⌟은 무엇을 따라도 모순의 벽과 맞닥뜨려지는 인간과 삶에 관한 진술이었다. 세상의 일들이란 모순으로 짜여있으며 그 모순을 이해할 때 조금 더 삶의 본질 가까이로 다가갈 수 있는 것이다. 그렇다면 이것 이상 구체성을 띤 제목은 없을 터였다.</p>
</li>
</ul>
]]></description>
        </item>
        <item>
            <title><![CDATA[말랑말랑 생각법]]></title>
            <link>https://velog.io/@ssu_hyun/%EB%A7%90%EB%9E%91%EB%A7%90%EB%9E%91-%EC%83%9D%EA%B0%81%EB%B2%95</link>
            <guid>https://velog.io/@ssu_hyun/%EB%A7%90%EB%9E%91%EB%A7%90%EB%9E%91-%EC%83%9D%EA%B0%81%EB%B2%95</guid>
            <pubDate>Sat, 27 May 2023 04:08:42 GMT</pubDate>
            <description><![CDATA[<p><img src="https://velog.velcdn.com/images/ssu_hyun/post/d426ca8a-4da8-4607-8362-51aced6e5afc/image.png" alt=""></p>
<ul>
<li><p>p.18
<img src="https://velog.velcdn.com/images/ssu_hyun/post/777cf6ec-5847-4fce-bbb0-126090176d31/image.png" alt="">신발을 벗고 테이블 위로 올라간 나 자신이 참 기특했어. 내가 좋아하는 것을 내 안에 숨겨두지 않고 직접 꺼냈으니까. 좋아하는 것이 아니라 좋아해서 하게 된 무엇이 내 진짜 모습이니까.</p>
</li>
<li><p>p.46
커뮤니케이션이란 비언어적인 대화가 더 많다. 의사소통에서 언어의 내용은 7퍼센트, 어조나 억양이 38퍼센트, 비언어적 몸짓이 55퍼센트의 비중을 차지한다. 머리와 가슴으로 들어라. 대화로 표현되지 않는 것을 파악해야 한다. </br>
믿음, 소망, 사랑, 그중 제일은 사랑이라.
의도, 생각, 감정, 그중 제일은 감정이라.</br>
진실하게 말하고 자연스럽게 행동하면 상대의 마음을 움직일 수 있다.</p>
</li>
<li><p>p.53
우리가 늘 사용하는 언어와 단어, 개념을 언어로 정리하는 과정을 거치면 인식이 깨어나는 즐거움이 생겨. 특히 반대말을 억지로 만드는 건 본질을 파고드는 귀한 삽질, 또는 곡괭이질과 같지.</p>
</li>
<li><p>p.57
크로노스란 흔히 우리가 알고 있는 객관적・정량적 시간, 카이로스란 자신이 가치를 창출하는 주관적・정성적 시간</p>
</li>
<li><p>p.62
우리가 알고 있는, 알고 있다고 생각하는 흔한 말들을 반대말로 정의하는 건 매우 힘들어. 그 뜻을 정확히 이해하고 있거나 해석을 해봤어야 반대말을 떠올릴 수 있기 때문이야.</p>
</li>
<li><p>p.67
문화의 속성 = 겉(형식/Style, Pattern, Mode) + 속(내용/Philosophy, Contents, Story, Why)</br>
겉과 속을 일치시키는 것이 디자인이다.</br>
형식의 껍데기를 벗기기 전까지 내용은 우리에게 말을 건네지 못해. 철학, 스토리, 이유들이 이 형식의 껍데기 안에 들어있지만 눈애 안 보여서 그러지 사람들은 그 내용에 관심이 크지 않아.</br>
형식은 곧 메시지야. 우리는 양식화된 행위를 되풀이하면서 그 힘에 압도당하지. 자연스럽게 인식된 형식과 양식들은 그 자체로 우리를 편안하게 해주는 동시에 알고 있는 세상이 안정된 세상이라고 느끼게 해줘. 압도된다는 느낌을 못 느낄 정도로, 우리는 스타일을 반복해 패턴화되니 그 무엇에 길들여 있지.</br>
스타일의 반복 = 패턴/모드
예측이 가능한 어떤 양식의 세계 안에 갇히게 되는 건데. 상당히 위력적이야. 편안해진다는 거지.</br>
시간이 지나면서 문화의 속은 점점 퇴색해. 고유의 생각과 이유가 잊히지. 반면, 문화의 겉은 굳건한 스타일로 명맥을 유지해. 인간은 겉에 매료되고 영향을 받고 따라 하는 존재거든. 그런데 가끔 껍데기를 깨고 본질을 찾아내는 사람들이 형식에 도전을 내밀며 우리를 놀라게 하지.</br>
본질적인 뜻과 메시지는 변함이 없는데, 형식이 바뀌니 생각이 열리고 그 안으로 빠져드는 것이 아닐까?</br>
&quot;처음에는 익숙하지 않아서 부자연스럽겠지만 좋은 뜻에 맞는 새 형식을 발견하고 반복해서 자연스럽게 느끼도록 노력하여, 누군가에게 &#39;이것 참 자연스럽네&#39;라는 칭찬을 받는 자연스러운 사람이 되어볼래요&quot;</br>
같은 일을 반복하는 건 숭고하지만 같은 방식을 되풀이하는 건 헛수고일 뿐이야.</p>
</li>
<li><p>p.96
창의성은 몰입을 통해 새로운 &quot;경험을 끊임없이 재구성 해가는 과정&quot;</p>
</li>
<li><p>p.101
존재하도록 만들어. 생각만으로 무언가를 움직일 수 없잖아.</p>
</li>
<li><p>p.110
[창의성 개발 방법 5가지]</p>
<ol>
<li>호기심을 갖고 질문해라.</li>
<li>좋아하는 일을 해라.</li>
<li>자신과 관련 없는 분야를 경험해라. (=우물 안 개구리가 되지 말것)</li>
<li>멍을 때릴 것. (= 억지로 무언가를 하려하지 말고 잘 놀고, 잘 쉬어야 함)</li>
<li>실패를 두려워하지 않고 위험을 감수해라.</br>
=&gt; &quot;호기심을 갖고 몰입해서 실행하라&quot;</br>
&quot;새로운 것을 만드는 능력은 지식이 아니라 인간의 내면적 필요성에 의한 유희적 본능에서 나온다. 창의적 마음은 그 마음이 좋아하는 일과 함께한다.&quot; -카를 구스타프 융-</br>
&quot;창의적인 사람은 각기 다르지만 한 가지는 모두 같다. 자신이 하는 일을 몹시 사랑한다는 점이다. 창의적인 결과는 지식이나 창조적인 사고에서 오지 않는다. 몰입과 열정이 뒤다를 때 놀라운 결과를 얻을 수 있다. 오롯이 몰입하는 순간에 효율적으로 사고하게 되고 창의성이 커지기 때문이다.&quot; -칙센트미하이-</br>
관심도 관찰도 관계도 사랑하는 마음에서 시작되더라.</li>
</ol>
</li>
<li><p>p.119
말은 글이 되어 눈으로 들어와 생각과 결심이 되고, 그것이 실천으로 뿜어져 나와 누군가를 변화시키는 게 대단히 신기해.</br>
멋진 말들은 세상에 가득하고 흔하지. 화장실에도, 건물 앞 현판에도, 아버지가 카톡으로 보내주는 이미지에도, 베스트셀러 띠지에도 그런 말들은 넘쳐흘러. 하지만 그런 말들은 피부에 와닿아 내 세포를 깨워 의지와 케미를 만든 후 행동으로 발현되지 않는 한, 공허한 텍스트일 뿐이야.</br>
멋진 말은 유려하게 빛나지만 행동을 이끌지 못하면 공허하기 짝이 없지. 허무한 형식미만 뽐낼 뿐인 거야.</br>
내가 하고 싶은 이야기가 아니라 그가 듣고 싶은 이야기를 해.</p>
</li>
<li><p>p.145
어쨌든 누가 시킨 일이 아니라 내가 좋아하고 선택한 일을 꾸려나가는 건 빛나는 생명의 특권이야. 나다움을 확인하고 꺼내 보고 개발하여 뭔가를 해내는 건 내가 누구인지, 무엇 때문에 이 땅에 태어났는지를 알아낼 수 있는 숭고한 여정일 수 있기 때문이지. </p>
</li>
<li><p>p.147
내가 하고 싶은 것과 상대가 원하는 것 사이에서 &#39;그동안 해왔던 관습을 깨고 기대 이상의 무언가&#39;를 해내보려는 실험과 도전을 시시때때로 해보지 않는다면 우리는 금세 나만의 숭고한 에너지를 다 잃어버리고 말 거야. 상대가 원하는 것만 척척 해내는 일도 대단하지만, 그것에 만족하지 못하는 사람이 꼭 있거든.</br>
처음부터 내가 하고 싶은 것을 이루지 못하더라도 욕먹을 각오하면서 해봐. 욕을 먹으면 기분이 상하고 낙심이 크잖아. 그러니까 욕을 적게 먹을 수 있는 아주 작은 일부터 차곡차곡 &#39;나만의 방식&#39;으로 욕을 앙증맞게 먹으면서 해보라는 거야.
&#39;좀 이상하겠지만 귀엽게 봐주세요&#39;라는 기특한 말이 있어. 이 솜사탕 같은 말은 내 앞뒤로 날아오는 핀잔과 욕을 누그러뜨리는 완충재야. 연차가 낮을 때 써야해. 연차가 쌓이면 이 말을 쓸 수가 없거든.언어에도 유효기간과 때가 있기 때문이야. 어리숙하고 멋모를 때 이 말을 서먹으면서 나만의 에너지를 소멸시키지 않으며 일하기를 바라. 솜사탕 같은 말을 한 덕에, 내 인생을 도울 요정 같은 누군가가 있었다는 사실을 알게 될지도 몰라. 요정은 초능력자가 아니라서 가만히 있으면 내 안에 숨은 빛을 알아보지 못하거든. 그리고 남들을 따라 해서 무난히 일하는 걸 안도하고 자랑스러워하면, 어느 순간 내가 가진 무언가를 모두 빼앗겼다는 느낌이 들어도 그 때는 대책이 없을 거야.</br>
머릿속에서 나의 모습을 형상화한들 &#39;내가 생각하는 나&#39;와 &#39;남이 보는 나&#39;사이에는 간극이 있잖아. 그 간극이 없어질 때가 비로소 나만의 무언가가 자연스레 자리 잡은 때라고 생각해. 그 때를 앞당기려면 뭔가를 해보고 확인하고 또 해보고 확인하는 수밖에 없지.</p>
</li>
<li><p>p.157
효율, 빠름, 안정을 원한다면 감히 창의적으로 일하면 안돼. 망하기 십상이니까.</p>
</li>
<li><p>p.162
무언가를 남다르게 하거나 새롭게 만드는 가장 쉬운 방법이 있어. 바로 그것을 그것이라고 부르지 않는 습관을 기르는 거야. </p>
</li>
<li><p>p.193
언어가 풍성하면 같은 세상을 훨씬 풍성하게 볼 수 있어. 소쉬르는 &quot;그 사람이 쓰는 언어의 틀에 의해서 그 사람의 세계를 파악할 수 있다&quot;라고 했어.
인간은 언어에 갇힌 존재라고 할 수 있어. 언어 체계가 세계를 인식하고 다르게 구성하고 규정하지.    </p>
</li>
<li><p>p.203
부끄러워해. 부끄러워야 해. 부끄러움이 없으면 앞으로 나아가지 못해.</p>
</li>
<li><p>p.207
본질을 깨달으면 인생의 어려운 부분이 쉽게 풀린다고 생각해요.</br>
이런 일을 결정한 뉴욕시의 공립도서관장 토니 막스는 이런 말을 했어요. &quot;우리는 벌금 걷는 사업을 하는 게 아니에요. 사람들이 읽고 배우도록 돕는 게 우리의 일이지요.&quot;</br>
쓸데없는 것에 에너지를 쓰지 않으면서 문제를 제대로 파악하고 해결하게 되지요. &#39;도서관은 왜 도서관이지?&#39; &#39;도서관은 애초에 왜 생겼지?&#39;라고 질문하는 것이 시작일 텐데요. 그 단순한 것이 어렵지요.</p>
</li>
<li><p>p.220
자기소개를 하는 순간마다 매번 똑같이 하지 않는다면, 더 작고 선명한 이야기를 눈치 보지 않고 할 수 있다면, 우리는 계속 큰 문을 열어젖힐 수 있는 사람이 되지 않을까?</p>
</li>
<li><p>p.250
당장 따먹을 수 있는 열매만 기르는 농사꾼들과 단기성과에 능한 이들의 공통점이 있어. 삶의 흔적이 앙상하다고 해야 할까. 그 흔적을 문화라고 하는데 멋이 없지. 먹고사는 문제에만 온통 인생의 초점이 모여 있으니 통장은 두둑한데 삶은 앙상하고 메마르지. 뒤늦게 앙상함을 덮으려 번쩍번쩍한 것들로 주변을 채우곤 하는데, 그게 자기 자신에서 나온 것이 아니라 여기저기서 흉내내어 붙인 것이라서 어색하고 품위 없고 일관성도 없어. 그들의 인생은 비싼 가격표만 달랑 달린 것 같아.</p>
</li>
<li><p>p.262
정해진 답을 거스를 때 더 좋은 답이 나와. 지키라고 만든 것이 아니라 깨트리라고 만든 것이 규칙이라면 세상은 넓고 깰 것은 많아.</br>
규칙을 지키는 것이 아니라 규칙을 깨는 것이 목표가 되기를 바라.</p>
</li>
</ul>
]]></description>
        </item>
        <item>
            <title><![CDATA[디자이너의 일상과 실천]]></title>
            <link>https://velog.io/@ssu_hyun/%EB%94%94%EC%9E%90%EC%9D%B4%EB%84%88%EC%9D%98-%EC%9D%BC%EC%83%81%EA%B3%BC-%EC%8B%A4%EC%B2%9C</link>
            <guid>https://velog.io/@ssu_hyun/%EB%94%94%EC%9E%90%EC%9D%B4%EB%84%88%EC%9D%98-%EC%9D%BC%EC%83%81%EA%B3%BC-%EC%8B%A4%EC%B2%9C</guid>
            <pubDate>Mon, 08 May 2023 04:01:07 GMT</pubDate>
            <description><![CDATA[<p><img src="https://velog.velcdn.com/images/ssu_hyun/post/56512136-5fb4-46fd-b12d-3a3aeb59c900/image.png" alt=""></p>
<ul>
<li>p.21
그는 자신이 할 수 있는 일과 할 수 없는 일, 해야만 하는 일과 해서는 안 되는 일에 대한 분명한 기준이 있고, 그렇기 때문에 자본의 압력에서 자유로운 디자인을 할 수 있다고 말했다. 그 말에는 그의 작업은 아무나 돈을 낸다고 얻을 수 있는 것이 아닌, 한 사회의 구성원으로서 최소한의 책임을 공유하는 사람과 함께 만들어가는 공동 작업이라는 의미가 담겨 있었다.</li>
</ul>
]]></description>
        </item>
        <item>
            <title><![CDATA[[Unity] NavMesh 더 크게 구워진 이유]]></title>
            <link>https://velog.io/@ssu_hyun/Unity-NavMesh-%EB%8D%94-%ED%81%AC%EA%B2%8C-%EA%B5%AC%EC%9B%8C%EC%A7%84-%EC%9D%B4%EC%9C%A0</link>
            <guid>https://velog.io/@ssu_hyun/Unity-NavMesh-%EB%8D%94-%ED%81%AC%EA%B2%8C-%EA%B5%AC%EC%9B%8C%EC%A7%84-%EC%9D%B4%EC%9C%A0</guid>
            <pubDate>Tue, 14 Mar 2023 01:11:12 GMT</pubDate>
            <description><![CDATA[<p>NavMesh Bake는 static 상태이므로 사이즈가 고정인데 내가 map의 크기를 런타임에 동적으로 조정해서 크게 구워져 보였던 것이었다. 즉 맵의 사이즈가 1일 때 Bake했는데 런타임에 동적으로 생성할 때는 0.6f로 사이즈를 바꿔서 static인 NavMesh는 반영하지 못했던 것...</p>
]]></description>
        </item>
    </channel>
</rss>