본문 바로가기

전체 글27

[카이젠저니] 07장 ~ 11장 나는 절대 오지 않을 구세주를 계속 기다리고만 있다는 것을 깨달았다. 그런 허울 좋은 일은 일어나지 않는다. 스스로 바꿀 수 밖에 없다. 제07장 둘이라면 더 바꿀 수 있다 XP(eXtreme Programming) is about social change. 지금까지 자신이 하던 행동을 바꾸고 다른 사람과 관계하는 방법을 바꾼다. 언제든 시작은 자신, 한사람. 하지만 언제까지나 혼자이면 안 된다. 소외 이론과 건설적 상호 작용 사람은 자신이 경험한 것을 바탕으로 사물을 생각하고 가족이나 타인과의 일상을 통해 배운 지혜를 조합해 경험을 강화해나간다. 이러한 지식들의 집합. (Lv.1) 직접 체험하지 않아도 학교나 서적을 통해 자연 현상이나 물리 원칙등을 배움 (Lv.3) 이해하기 쉽게 설명할 수 있는 방울.. 2022. 5. 8.
[카이젠저니] 01장 ~ 06장 당신은 어떤 일을 하는 분입니까? 아무것도 대답할 수 없었다. 한마디의 말도 나오지 않았다. 그리고 이해할 수 있었다. 난, 아무것도 하고 있지 않았다. 제 01장 회사를 떠나기 전에 꼭 해야 할 일 외부로부터 지식을 얻을 때 꼭 기억해야 할 중요한 점이 있습니다. 외부로부터 얻은 지식을 우리가 속한 현장이나 업무에 그대로 적용하려고 하면 대부분 잘되지 않습니다. 우리가 처해있는 '상황'에 맞춰 적용하는 것이 매우 중요합니다. 다른 사람들이 만들어 낸 프랙티스의 배경에 어떠한 상황 또는 제약이 있었는지 이해하고 우리가 처한 상황이나 제약하에서 어떤 프랙티스*를 적용할지를 반드시 다시 판단해야 합니다. 화려하게 설명돼 있는 각종 용어에 마음을 빼앗기지 않도록 주의하십시오. * 프랙티스 : 어떤 일을 함에 .. 2022. 4. 24.
[카이젠저니] Kaizen(改善, カイゼン) Journey 작게 시도하고, 실패하고, 학습하고, 개선함으로써 01 책 정보 (링크) 저자 : 이치타니 토시히로, 아라이 타케시 역자 : 김연수 출판사 : 제이펍 출판일 : 2019.09.19 목차 1부 개인 / 2부 팀 / 3부 팀외부 각 단위로 도입할 내용을 사례와 함께 서술 더보기 제1부 혼자 시작하다 1 제01장 회사를 떠나기 전에 꼭 해야 할 일 2 제02장 나부터 시작하다 7 제03장 혼자 시작하는 회고 15 제04장 혼자 시작하는 태스크 가시화 24 제05장 내일을 내 편으로 만들다 33 제06장 경계를 넘나들다 40 제07장 둘이라면 더 바꿀 수 있다 48 제08장 둘이서 경계를 넘다 54 제2부 팀으로 강해지다 63 제09장 혼자에서 팀으로 64 제10장 완료 기준을 팀에서 결정하다 72 제11장 팀.. 2022. 4. 24.
실용주의 프로그래머 Tip 100 " 결국 당신의 삶이다. " Tip 1 자신의 기예(craft)에 관심을 가져라 Tip 2 자기 일에 대해 생각하라. Tip 3 당신에게는 에이전시(agency)가 있다. Tip 4 어설픈 변명 말고 대안을 제시하라. Tip 5 깨진 창문을 내버려 두지 말라. Tip 6 변화의 촉매가 돼라. Tip 7 큰 그림을 기억하라. Tip 8 품질을 요구 사항으로 만들어라. Tip 9 지식 포트폴리오에 주기적으로 투자하라. Tip 10 읽고 듣는 것을 비판적으로 분석하라. Tip 11 한국어든 영어든 하나의 프로그래밍 언어일 뿐이다. Tip 12 무엇을 말하는가와 어떻게 말하는가 모두 중요하다. Tip 13 문서를 애초부터 포함하고, 나중에 집어넣으려고 하지 말라. Tip 14 좋은 설계는 나쁜 설계보다 바꾸기 .. 2022. 4. 6.
제 9장 실용주의 프로젝트 여러분의 직함이 명목상으로는 “소프트웨어 개발자”나 “소프트웨어 엔지니어” 비슷한 이름일지 몰라도 진정한 여러분의 직함은 “문제 해결사”다. 이것이 우리가 하는 일이고, 실용주의 프로그래머의 본질이다. " 우리는 문제를 해결한다. " TIL (Today I Learn) Assignment 15 2022-04-05 오늘 읽은 범위 9장 실용주의 프로젝트 Topic 49 실용주의 팀 Topic 50 코코넛만으로는 부족하다 Topic 51 실용주의 시작 도구 Topic 52 사용자를 기쁘게 하라 Topic 53 오만과 편견 3줄 요약 각 팀원이 자신의 방식대로 빛나게 하라. 유행하는 것이 아니라 실제로 잘 맞는 것을 사용하라. 사용자를 기쁘게 하라. " 프로그래머는 고양이 같은 면이 있다. 호기심 많고 제멋대.. 2022. 4. 5.
진정한 요구 사항 (연습문제 33) 다음 문장들이 진정한 요구 사항인가? 가능하다면 진정한 요구 사항이 아닌 것을 좀 더 유용하게 고쳐 써 보라. 응답시간은 500ms 이하여야 한다. 모달창(modal window)의 바탕색은 회색이다. 애플리케이션은 프론트엔드 프로세스 몇 개와 백엔드 서버로 구성된다. 사용자가 숫자가 아닌 글자를 숫자 필드에 입력하면 시스템은 입력 필드를 깜빡이고 입력을 거부한다. 이 임베디드 애플리케이션의 코드와 데이터 크기는 32Mb 이내여야 한다. [내 답변] 요구 사항인 것을 O 아닌 것을 X라고 한다면 X - 어느 환경에서 어떤 경로의 시간을 말하는 건지 모르겠다. - 실제 서비스 시 방화벽 등이 추가된다면 더 늘어날 수 있으니 조건을 더 명시적으로 적어야 할 것으로 보인다. - 이를 명확히 하기 위해선 왜 5.. 2022. 4. 4.
제 8장 프로젝트 전에 " 자신이 뭘 원하는지 정확히 아는 사람은 아무도 없다 " TIL (Today I Learn) Assignment 13 2022-04-03 오늘 읽은 범위 8장 프로젝트 전에 Topic 45 요구 사항의 구렁텅이 Topic 46 불가능한 퍼즐 풀기 Topic 47 함께 일하기 Topic 48 애자일의 핵심 3줄 요약 요구 사항은 피드백을 반복하며 알게 된다. 사용자는 여러분 팀의 일원이다. 애자일은 명사가 아니다. 애자일은 무언가를 하는 방식이다. " 프로그래머는 사람들이 자신이 원하는 바를 깨닫도록 돕는다. " 책에서 기억하고 싶은 내용을 써보세요 Topic 45 요구 사항의 구렁텅이 요구 사항이 땅 위에 놓여 있는 경우는 드물다. 보통은 가정과 오해, 정치의 지층 속 깊숙이 묻혀 있다. 심지어 아예 .. 2022. 4. 3.
제 7장 코딩하는 동안 " 모든 코드를 비판적인 시각으로 바라본다. 자기 자신의 코드도 예외가 아니다. " TIL (Today I Learn) Assignment 12 2022-04-01 ~ 2022-04-02 오늘 읽은 범위 7장 코딩하는 동안 Topic 37 파충류의 뇌에 귀 기울이기 Topic 38 우연에 맡기는 프로그래밍 Topic 39 알고리즘의 속도 Topic 40 리팩터링 Topic 41 테스트로 코딩하기 Topic 42 속성 기반 테스트 Topic 43 바깥에서는 안전에 주의하라 Topic 44 이름 짓기 3줄 요약 여러문의 내면의 파충류에게 귀 기울여라. 하던 일을 멈추고 그 느낌을 분석하라. 책에서 기억하고 싶은 내용을 써보세요 코딩할 때는 매 순간 결정을 내려야 하는데, 프로그램이 정확하게 생산적으로 작동하.. 2022. 4. 2.
제 6장 동시성 " 동시성은 필수다. 세상은 비동기적이기 때문이다. " TIL (Today I Learn) Assignment 10 2022-03-29 ~ 2022-03-30 오늘 읽은 범위 6장 동시성 Topic 33 시간적 결합 깨트리기 Topic 34 공유 상태는 틀린 상태 Topic 35 액터와 프로세스 Topic 36 칠판 3줄 요약 ‘동시성 concurrency’은 둘 이상의 코드 조각이 실행될 때 동시에 실행 중인 것처럼 행동하는 것이고, ‘병렬성 parallelism’이란 실제로 동시에 실행되는 것이다. 동시성은 소프트웨어 동작 방식이고, 병렬성은 하드웨어가 하는 것이다. 공유 상태는 틀린 상태다. " 동시성은 ‘병행성’이라고도 한다. (Concurrency) " 책에서 기억하고 싶은 내용을 써보세요 To.. 2022. 3. 29.
간단한 현실 점검 (연습문제 16) 다음 ‘불가능한’ 것들 중 무엇이 실제로 일어날 수 있는가? 한 달이 28일보다 적은 것. 시스템 콜의 오류 메시지: 현재 디렉터리에 접근할 수 없음. C++에서, a = 2; b = 3; 하지만 (a + b)는 5가 아님. 내각의 합이 180도가 아닌 삼각형. 1분이 60초가 아님. (a + 1) 2022. 3. 27.
제 5장 구부러지거나 부러지거나 " 삶은 멈추지 않는다. 우리가 작성하는 코드도 마찬가지다. " TIL (Today I Learn) Assignment 08 2022-03-26 오늘 읽은 범위 5장 구부러지거나 부러지거나 Topic 28 결합도 줄이기 Topic 29 실세계를 갖고 저글링하기 Topic 30 변환 프로그래밍 Topic 31 상속세 Topic 32 설정 3줄 요약 묻지 말고 말하라 Tell, Don’t Ask, TDA. 상태를 쌓아 놓지 말고 전달하라. 환경에 적응하지 못하는 생물은 멸종한다. 책에서 기억하고 싶은 내용을 써보세요 Topic 28 결합도 줄이기 높은 결합도는 변경의 적이다. 묻지 말고 말하라 Tell, Don’t Ask, TDA. 다른 객체의 내부 상태에 따라 판단을 내리고 그 객체를 갱신해 서는 안 된다.. 2022. 3. 26.
제 4장 실용주의 편집증 어느 누구도, 심지어는 자기 자신도 완벽한 코드를 작성할 수 없음을 알기 때문에 TIL (Today I Learn) Assignment 07 2022-03-25 오늘 읽은 범위 4장 실용주의 편집증 3줄 요약 계약에 의한 설계 Design By Contract, DBC. 단정문으로 불가능한 상황을 예방하라. 언제나 교체 가능한 코드를 작성하여 대비하면 된다. (결국은 ETC) 책에서 기억하고 싶은 내용을 써보세요 여러분은 완벽한 소프트웨어를 만들 수 없다. 삶의 공리로 인정하고 받아들여라. 실용주의 프로그래머는 자기 자신 역시 믿지 않는다. Topic 23 계약에 의한 설계 계약에 의한 설계 Design By Contract, DBC. DBC는 단순하지만 강력한 기법으로, 프로그램의 정확성을 보장하기 위.. 2022. 3. 26.
제 3장 기본 도구 " 아무리 흐린 먹물일지라도 가장 훌륭한 기억력보다 낫다 " TIL (Today I Learn) Assignment 05 2022-03-23 오늘 읽은 범위 3장 기본 도구 3줄 요약 도구들의 사용법을 배우는 데에 시간을 투자하라. 여러분은 IDE가 갖는 한계를 넘어설 수 있어야 한다. 근시안의 함정에 주의하라. 텍스트 처리 언어를 익혀라. 책에서 기억하고 싶은 내용을 써보세요 Topic 16 일반 텍스트의 힘 일반 텍스트는 인쇄 가능한 문자로 이루어지고, 정보를 전달하기에 적합한 형식을 갖추어야 한다. 우리가 만드는 일반 텍스트는 사람이 이해할 수 있어야 이해할 수 있어야 한다. 여러분은 모든 참가자가 하나의 공통 표준을 사용해서 소통하도록 해야 한다. Topic 17 셸 가지고 놀기 작업대는 목공소의.. 2022. 3. 24.
제 2장 실용주의 접근법 " 우리는 모두 시간과 자원이 제한된 세상에서 일한다. " TIL (Today I Learn) Assignment 03 2022-03-20 ~ 2022-03-21 오늘 읽은 범위 2장 실용주의 접근법 3줄 요약 바꾸기 더 쉽게 Easier to Change. ETC. 이게 전부다. 규칙이 아니라 가치. DRY: 반복하지 말라 Don’t Repeat Yourself 목표물에 맞을 때까지 조준을 옮겨야한다. 책에서 기억하고 싶은 내용을 써보세요 Topic 8 좋은 설계의 핵심 어떤 게 잘 설계되었다는 건 그 물건이 사용하는 사람에게 적응하여 맞춰진 다는 것이다. 바꾸기 더 쉽게 Easier to Change. ETC. 이게 전부다. 규칙이 아니라 가치. Topic 9 DRY: 중복의 해악 " 우리의 이해는 .. 2022. 3. 22.
제 1장 실용주의 철학 "이 책은 무엇을 ‘하는’ 것에 관한 책이다." TIL (Today I Learn) Assignment 01 2022-03-19 오늘 읽은 범위 추천사 2판 서문 1판 서문 1장 실용주의 철학 3줄 요약 우리는 자신의 능력에 자부심을 가질 수 있지만, 실수나 무지 같은 단점도 인정해야만 한다. 발견하자마자 바로 고쳐라. 멈춰야 할 때를 알라. 책에서 기억하고 싶은 내용을 써보세요 서문 어떤 특정 기술에 매이면 안 된다. 개별 상황마다 그 상황에서 좋은 해결 방안을 고를 수 있도록 충분한 배경지 식과 경험을 쌓아야 한다. 언제나 일하면서 동시에 생각하고, 자기 일을 비평하라 개개인의 기여가 프로젝트를 지탱한다는 것이 이들의 믿음이었다. ​Topic 1 당신의 인생이다 당신의, 당신이 사는, 당신이 만드는 .. 2022. 3. 19.
제 3장 함수 #작게_만들어라 - 80년대에는 한 함수가 한 화면을 넘어가면 안된다고 했다 - 당시 VT100 화면은 가로 80 세로 24줄이었는데 편집기가 4줄을 관리용으로 사용했기 때문 - 얼마나 짧아야하는가? - 20줄도 길다 - if/else/while 블록은 한줄 -> 대게 여기서 함수 호출 - 즉 중첩이 생길만큼 함수가 커선 안된다는 의미 (들여쓰기는 1,2에서 그치도록) "함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다" #한가지만_해라 - 한가지의 기준은? - 추상화 수준 : 지정된 함수 이름 아래 추상화 수준이 하나인 단계만 수행하면 작업 갯수는 하나인 것 - 의미 있는 이름으로 다른 함수를 추출할 수 있다면 여러 작업 - 여러 섹션으로 나눈다는건 여러 작업을 한.. 2021. 5. 16.
제 2장 의미 있는 이름 #의도를_분명히 - 고려 사항 - 존재 이유는? 수행 기능은? 사용 방법은? - 주석이 필요하다는건 의도 표현이 불충분했다는 것 #그릇된_정보_지양 - 다르게 해석할 여지가 많은 함축어나 단어는 쓰지 말 것 - 서로 비슷해서 헷갈릴 이름을 사용하지 않게 #의미있는_구분 - 연속된 숫자나 불용어 추가하지 말 것 - a1, a2, ..., aN - a, an, the, Info, Data, Manager, Process - 구분이 안되는 예시 - NameString / Name - moneyMount / money - accountData / account - theMessage / message #발음하기_쉽게, 검색하기 쉽게 - 마음대로 축약해서 넣지 말 것 - 여러 곳에서 사용한다면 검색하기 쉽게 상.. 2021. 4. 11.
제 1장 깨끗한 코드 #코드의_가치 - 코드를 자동으로 짜주는 기대가 오면 프로그래머는 필요가 없나? - 어느 수준에선 코드없이 요구사항을 상세히 표현하는건 불가능. 그럼 추상화도 불가능하게됨 - 앞으로 언어에서 추상화 수준은 점차 높아질 것 - 특정 분야에 적합한 domain-specific language 가 많아질 것으로 예상 (DSL) - 코드란 요구사항을 표현하는 언어 #르블랑의_법칙 - 급하게 짠 코드를 나중에 손보겠다? - 안돌아가는 프로그램보다 돌아가는 쓰레기가 낫다? - 나중은 결코 오지 얂는다. #깨끗한_코드? - 기한을 맞추고 빨리가는 유일한 방법은 코드를 최대한 깨끗하게 유지하는 습관뿐 - 깨끗한 코드를 작성할 땐 '청결'이라는 감각으로 기법을 적용하는 절제와 규율이 필요 == 코드 감각 - 비야네 스트.. 2021. 4. 3.
[golang] interface와 reflect, 그리고 OOP golang에는 type 문이 있다. 속성들의 집합을 표현하는 struct와 행위의 집합을 표현하는 interface를 정의할 때 주로 쓰인다. struct는 Custom Data Type을 정의하며 interface는 해당 type이 정의해야하는 함수 원형을 정의한다. #interface golang에는 전통적인 class, object, 상속 개념이 정의되어 있지 않은 대신 struct와 interface라는 기능으로 OOP를 지원한다. 기존 class는 사용자 정의 타입을 정의하는 struct로 표현되는데, 속성(==field)과 행위(==method)를 함께 표현하지 않는다. struct는 필드만을 가지게, method는 함수 이름 '앞'에 선언되는 매개 변수인 receiver 인수를 받는 fun.. 2021. 3. 28.
I/O Multiplexing 톺아보기 (2부) 이전 1부에서 Blocking/Non-Blocking, Synchronous/Asynchronous 기본 개념과 Linux 환경에서의 기법들을 살펴보았다. I/O 동작의 가장 기본 형태인 Synchronous Blocking 방식은 굉장히 직관적이긴 하지만 2개 이상의 파일을 처리할 때는 multi-process 또는 multi-thread 기법으로 동작해야했다. Non-Blocking이라 한들 지속적인 Context Switching이 일어나기도 한다. 즉 Synchronous 방식에서 성능을 고려하면 multi-processing 또는 multi-threading 을 구현하지 않을 수 없다는 것이다. 하지만 multi-processing 환경에선 IPC(프로세스간 통신)나 동기화(semaphore, .. 2021. 2. 16.
I/O Multiplexing 톺아보기 (1부) “Everything is a File” 이 말은 Linux/Unix에서는 socket도 하나의 파일(File), 더 정확히는 File Descriptor(FD, 파일 디스크립터)로 관리된다는 것에서 착안되었다. 이처럼 Low Level File Handling을 통해 socket 기반의 데이터 송수신이 가능하다. 즉 I/O 작업은 단순히 단일 server 내에서 일어나는 읽기/쓰기 뿐만 아니라 Server-Client 간 네트워크 통신에도 적용되는 개념인 셈이다. 이번 포스팅에서는 각종 I/O 모델 들을 이해하기 위한 선수 개념과 기본 동작 방식을 숙지하고 일련의 과정을 설명하기 위해 Linux 계열에 대한 Multiplexing 기법까지만 다루도록 한다. 그 외 Windows, Solaris, Ope.. 2020. 11. 25.
go map 초기화 Map in golang 키(Key)에 대응하는 값(Value)을 신속히 찾는 해시테이블(Hash table)을 구현한 자료구조 format : map[Key]Value # 선언 var results map[string]string map은 reference 타입이므로 nil 존재 이 상태의 map을 "Nil Map" 이라함 panic: assignment to entry in nil map goroutine 1 [running]: main.main() /Users/larva/go/src/go-study/main.go:8 +0x4f exit status 2 초기화 하지 않은 nil map을 사용하려고 하면 panic 발생 panic : 컴파일러가 찾아내지 못하는 error nil map에는 어떠한 값도 .. 2020. 10. 18.
gRPC 배경부터 활용까지 1. 등장 배경 1.1 Server-Client Model PC(Personal Computer)의 개념이 없던 시절, 프로그램은 하나의 메인 프레임에서 동작하는 Monolothic 구조로 설계되었다. 이때까지만 해도 모든 기능들이 한 공간에서 구동되다보니 지금처럼 네트워크 통신이 크게 중요하진 않았을 것이다. 기술 발전에 따라 소형 컴퓨터 장비들(PC, 워크스테이션 서버 등)이 등장하게 되고, 기업 입장에선 매우 고가인 메인 프레임워크를 비교적 저가의 워크스테이션 서버로 대체하고 싶어했지만! 메인 프레임워크의 초고사양 서비스를 워크스테이션 서버에서 그대로 제공하기엔 한계가 있었다. 때문에 메인 프레임워크의 기능을 워크스테이션 서버로 분산시키고, 네트워크 연결로 서비스하는 방식을 채택하게되었다. 흔히 말.. 2020. 7. 26.
core dump 분석을 위한 gdb 사용법 간단 정리 살다보면 기껏 키워놓은 프로그램이 어느 날 갑자기 죽었거나 hang 걸리며 뻗어버리는 반항하는 모습을 보게 됨. 내가 널 어떻게 키웠는데 일반적인 운영 로그/에러는 직접 logger를 만들어 따로 잘 저장해두겠지만 미처 고려하지 못한(생각보다 low한) 부분에선 바로 원인을 파악하기가 힘듦. 따라서 프로그램 실행 시, core dump를 남기게 설정한다면 프로그램이 돌연사했을때 특정 시점의 메모리 상태를 알 수 있어 이슈 파악에 매우 유용 unix 환경에서 이를 도와주는 디버깅 툴이 gdb (=gnu debugger) 1. core dump 구조 core 파일은 ELF 형식 [ ELF - Executable and Linkable Format ] 실행 파일, 오브젝트 파일, 공유 라이브러리 그리고 '코어.. 2020. 5. 15.
로드 밸런싱(SLB, Server Load Balancing) 기본 개념 패킷이 네트워크 장비에 의해 어디로 보내질지는 몇 계층 통신인가, 그래서 어떤 데이터를 보느냐에 따라 달라진다. 이 구분은 OSI 7 Layer model에 기반한다. Layer 2 : Ethernet Header의 MAC address 구분 Layer 3 : IP Header의 IP address 구분 Layer 4 : TCP,UDP Header의 Port 구분, packet 조작, Session 관리 Layer 7 : Application 별 Payload 구분 (HTTP, RTSP 등) 이 중 여러대의 서버로 부하를 분산하는 로드밸런싱(SLB, Server Load Balancing) 기법은 일반적으로 L4 통신에 해당한다. 보통 서비스 운영에 필요한 포트를 기준으로 분산시키기 때문이다. 그래서 L.. 2020. 5. 12.
CPS, TPS L4 용어 " L4에서는 CPS / L7에서는 TPS 용어 사용 " #CPS (Connection Per Second) 초당 TCP Connection을 생성할 수 있는 최대 개수 ex) 1 CPS : Client가 LB의 VIP로 접속하여 특정 서버로 분산된 후, 다시 세션을 끊는 하나의 과정 ex) 200,000 CPS를 지원하는 장비 = 1초당 200,000의 커넥션을 동시에 처리 Connection : 하나의 세션이 열고 닫히는 순간까지를 의미 200,000 CPS라 하면 X 7(열릴때(3-way) + 닫힐때(4way)) = 1,400,000 의 패킷이 오가는 것 #TPS (Transcation Per Second) 초당 최대 처리 건수 = 초당 교환되는 데이터의 수치 (L7 성능 지표) RPS(.. 2019. 4. 7.
[golang/err] import cycle not allowed #현상 Cross-refering packages -> 각 패키지들이 상호 참조 (순환 종속) package 간 종속성이 생겨버리면 단위 테스트 하기도 어려워지고 한 package가 변경 될 때마다 종속성을 가지는 package까지 같이 컴파일 돼야하므로 비용 증가함 각 개체가 다른 개체를 유지하기 때문에 memory leak의 위험성도 높아짐 (+) package는 compile의 단위가 되는데 go는 빠른 compile 좋아하는 성향 탓인지 import cycle을 아예 막아버림 뭐 애초에 좋은 모델도 아니니까 ... #예제코드 욕심이 과하면 화를 부르는 법 대애충 A에서도 B 출력하고 싶고 B에서도 A를 출력하고 싶어하는 상황이라고 가정해보자 [ pkg_a.go ] package A import (.. 2019. 4. 6.

티스토리툴바