Daily Layer

회사에 코드 리뷰 하는 문화 만들어보기, (2) 학습동아리의 한계

미국산곰고기 — Sun, 18 Feb 2024 14:10:16 +0900

회사 내에서 하는 프로젝트 외에 별도 공부를 한다는것. 아무래도 쉽지 않은 일이지만 이 쉽지 않은 일에 여러 사람을 섞어낸다는것은 더 쉽지 않은 일이었다.

결론부터 이야기 하자면 이 학습동아리는 22년 11월부터 약 3주간의 파일럿을 통해 실패라고 판단했다.

그 실패를 통해 얻은 결론은 학습동아리를 운영하기 위해서는 상황을 좀 더 냉정하게 돌아 보면서 적절한 전략이 필요하다는것이었다.

함께 하는 사람들이 불특정 다수인지, 소수 정예인지

같은 목적을 가진 사람들인지, 체험이 목적인지

마음이 맞는 사람이 한명이라도 있을지, 그렇지 않을지

함께 하는 사람들은 불특정 다수를 모았는데, 그러다보니 목적이 명확하지 않았다. 나는 그 문제를 해결하기 위해 학습의 방향성을 제시해야 했으나 당시에는 그런 판단을 하지 못했다.

같은 목적을 가진 사람들이었다면 별다른 계획이 없어도 되었었다. 하지만 그 판단을 하지 않고 별 다른 계획 없이 불특정 다수의 동아리 활동을 시작 했는데 이는 동아리의 방향성을 잊어버리게 했다. 사람들이 체험이 목적이라면, 하나하나 체험하면서 같은 목적을 가지도록 설득하는 과정이 필요했다.

마음 맞는 사람이 한명이라도 있다면, 그 사람과 함께하기 공부하기 위해서라도 동아리가 유지되었을것같다. 하지만 나 혼자서 진행하기에는 방향성조차 잡지 못했으니 내가 무얼 하고 있는가 라는 기반이 되는 사상마저도 없어져 버렸고 결국은 그 원동력을 잊어버렸다.

생각해보니 나는 대학생 때 비슷한 목적의 동아리를 유치하려 한 적 있다. 그때 실패를 돌아보지 않고 같은 실수를 반복했는데 이제는 조금 더 전략적으로 접근하려한다. 동아리와 같은 어떤 집단을 만드는데 내가 목적한 바를 이루기 위해 사람들이 원하는 요소를 찾아서 이끌어내보아야겠다.

소프트웨어 개발자에게 어떤게 요구사항일까

미국산곰고기 — Sun, 18 Feb 2024 12:57:38 +0900

소프트웨어 개발 중 만나는 여러 문제가 있다. 그 중 하나인 요구 사항을 제시하는 사람과 요구를 분석하는 사람, 두 사람도 모르는 문제. 미지의 영역에 대한 부분에 집중해본다.

개요

개발을 요청하는 사람이 정말 완벽한 체계를 설계 해온다면 개발자는 작업만 하면 된다. 하지만 대부분의 경우 요구 사항을 토대로 실제 요구를 채굴해내어야 한다. 요구 사항은 요구하는 기능 깊숙한 곳에 숨어있다.

그러면 어떡해야하죠..?

요구사항이 들어오면, 그 요구사항의 의도를 파악하고, 확장 가능한 설계로 나누고, 그 설계의 세부 동작을 설정 가능하도록 분석해내어 요구사항을 채굴해낼 수 있다.

요구사항 예시 다섯가지를 확인해보려 한다.

요구사항

기능의 응답시간은 500ms 이하여야 한다.
대화 상자의 배경은 회색이다.
애플리케이션은 몇 개의 프론트엔드 프로세스와 하나의 백엔드 서버로 구성한다.
사용자가 숫자가 아닌 글자를 숫자 필드에 입력하면, 시스템은 삐 소리를 내고 입력을 받아들이지 않는다.
애플리케이션 코드와 데이터의 크기는 256kb 이내로 작성한다.

첫번째 요구사항

응답시간을 500ms으로 제한하려 한다. 왜 500ms로 설정하였을까? 응답시간은 어디에서부터 어디까지인가? 최악인가 최선인가?

만약 이 값이 어떠한 이유로 변경될 수 있는지 파악한다면, 시스템의 전체적인 적용이 필요한 것인지, 하나의 기능에 필요한것인지도 알아낼 수 있다.

두번째 요구사항

대화 상자의 배경 색상을 정의하고 있다. 자 그런데, 회색이 무엇일까? css에서는 grey라고 명시하면 RGB 값으로 808080이 제공된다. 그런데 flutter에서는 grey 라고 하면 머테리얼 템플릿일때 9E9E9E 를 제공한다. 그러면 이제 회색이 무엇인지 물어보러 가야한다.

하지만 색상에 집중하지 않고 rgba 색상을 설정할 수 있도록 해서 결과물을 전달하면 어떨까? 요구사항에 색상을 그대로 적용하면 이 색상을 변경해달라는 요청을 끊임없이 받을 수 있다. 하지만 색상을 직접 결정할 수 있는 인터페이스를 제공한다면 요구사항도 만족하고 회색보다 도전적인 색상을 적용해보기도 좋을것이다.

세번째 요구사항

서버의 수량을 제한하는 요구다. 목적이 무엇일까? 정말 하나의 서버를 원하고 있을까? 여러개의 분산 시스템을 사용하지만 하나의 목적으로 동작하므로 마치 하나인것처럼 명시한게 아닐까. 정말 하나의 서버를 의도했다면 우리는 단일 장애 지점(Single Point Of Failure, SPOF) 를 극복하기 위해서는 하나처럼 동작하는 서버가 여럿 필요하다고 설득할 수 있다.

네번째 요구사항

'숫자 필드' 에서 소리를 내는 기능을 요청하고 있다. 이 요건을 설계 없이 코드에 구현한다면 텍스트필드는 실제로 소리를 내는 기능과 결합하게 된다. 즉, 기능의 경계가 무너지고 스파게티 코드가 될 가능성이 높아진다는 뜻이다. 그러면 소리를 내면 안될까? 그런 방법은 옳지 않다. 대신 설계 과정을 거쳐서 느슨한 결합을 만들어낼 필요가 있다.

숫자 필드에서 올바르지 않은 값을 무시할 때, 그 무시에 대한 이벤트를 발생한다. 소리를 내는 기능은 그 리스너를 통해 소리를 내도록 처리한다면 요구사항을 만족하며 결합도를 낮출 수 있다. 테스트도 간단해진다.

다섯번째 요구사항

애플리케이션의 코드와 데이터의 크기를 제약하는 경우는 정말 명확한 목적이 있는 경우다. 개발자가 먼저 나서서 제안할만한 내용이 요구사항으로 들어왔다면 그 의도를 꼭 찾아야 한다. 256kb는 대체 어디서 온걸까?

게임과 같이 큰 메모리를 사용하는 경우에 OS단에서 하드웨어 스펙을 제한하는 경우에도 발생한다. iBanana 라는 제품에서는 애플리케이션 크기를 256kb 미만으로 사용해야 한다 라는 매뉴얼을 보고서 요구사항이 왔다면, 그 배경에 따라 필요한 제안을 할 수 있다. 예를 들어 이 제품 대신 다른 제품을 사용했을 때의 이점이라던가, iBanana 제조사에서 제공하는 SDK를 통하면 요구를 만족하기 쉽다거나 하는 방식이다.

다시 분석한 요구사항

기능의 응답시간은 최대(최악) 응답 시간을 ms 단위로 설정할 수 있다.
대화 상자의 배경을 rgba 로 설정할 수 있다.
애플리케이션은 프론트엔드와 백엔드 서버로 구성한다.
숫자 필드에는 숫자만 입력받을 수 있고 올바르지 않은 입력은 무시하며 올바르지 않은 입력 이벤트를 발생한다.
애플리케이션 코드와 데이터의 크기는 사용 제품인 iBanana(가칭)의 메모리 제약인 256kb 이내여야 한다.

결론

소프트웨어의 요구사항을 찾아내는 과정은 험난한 과정이 맞다. 이 험난한 과정임을 받아들이고, 요구사항을 채굴하고 추출하는 과정을 통해 제품을 목적에 맞추어 나가보자.

유니티의 폭주? "Unity Runtime 요금" 의 등장과 계산기

미국산곰고기 — Mon, 18 Sep 2023 11:39:56 +0900

미국시간 23년 9월 12일에 유니티가 새로운 요금 체계를 공개했다.

간단하게 이야기하면, 유니티 엔진으로 제작한 영리 활동을 하는 애플리케이션에 대해 설치당 요금을 매기겠다는 뜻이 된다.

값을 매기는 계산식도 아주 간단하지는 않다. 이 런타임 요금을 매길지 말지에 대한 요소는 세가지이다.

1. 라이선스 타입 (유니티 퍼스널, 플러스, 프로, 엔터프라이즈와 같은)

2. 연간 매출

3. 설치 수

스프레드시트로 계산기를 만들었는데, 아래쪽에 링크를 제공한다.

공식 홈페이지의 표에 따르면, 개인 라이선스는 연간 2억 6천만원의 매출(원문 20만달러, 1달러/1300원 기준), 20만회의 설치 수량을 초과하면 요금이 발생한다. 프로와 엔터프라이즈 라이선스는 연간 13억원의 매출(원문 100만달러, 1달러/1300원 기준) 을 달성했을 때 요금이 발생한다고 한다.

대체 유니티가 주장하는 "설치" 는 무엇일까

The installation and initialization of a game or app on an end user’s device as well as distribution via streaming is considered an “install.” Games or apps with substantially similar content may be counted as one project, with installs then aggregated to calculate the Unity Runtime Fee.
Each game or app’s cumulative install amount cannot be reset or reduced even if it has been sold, transferred to a new party, changed its name, been republished as a new version, added expansion content, or had its unique identifier (e.g., BundleID) altered. Additionally, a change in publisher or distributor does not reset the cumulative install amount.

스트리밍은 논외로 두고 우리가 생각하는 "설치" 에 집중해보자. 최종 사용자 장치 즉 PC, 스마트폰 등의 장치에 애플리케이션을 "설치" 하고 초기화 하는것을 설치로 규정하고 있다. 만약 게임의 소유권을 다른 회사로 이전하더라도 이 판매량은 유지된다.

PC 시장에서의 게임을 "설치" 한다는것은 스팀과 같은 전자 소프트웨어 유통망(ESD)을 통하는 방법도 있지만 고전적인 방법으로 CD/DVD를 사용하거나, 설치 프로그램을 제공하는 방법이 있다.

모바일 플랫폼에서의 설치는 각 플랫폼에서 제공하는 애플리케이션 (플레이 스토어, 앱스토어 등) 에서 설치를 시도하거나 안드로이드의 APK와 같은 OS 별 설치 파일을 직접 사용하는 방법이 있다.

설치 수량을 요금에 포함시킬정도로 신뢰성 있는 방법이라면 OS나 플랫폼에 종속되지 않는 유니티 자체적인 기능이 되어야 한다. 불법 복제 소프트웨어, 악의적인 설치, 설치 수 대비 낮은 매출은 유니티로 개발했을때 굉장한 리스크가 된다.

이 요금에 대한 계산을 스프레드시트로 만들어봤다. 바로가기

연 매출과 설치 수량을 입력하면 라이선스 별 금액을 표시하도록 작성했다.

직접 이리저리 만져보려면, 사본 만들기로 드라이브에서 만져보면 된다.

방어적 프로그래밍 - 널 객체 패턴 사용해보기

미국산곰고기 — Mon, 18 Sep 2023 10:10:32 +0900

여러 언어에서 NULL(혹은 nil) 은 어떤 키에 값이 존재하지 않는다는 뜻으로 사용한다. 이 비어있는 키에 NULL 검사 외의 다른 방법으로 접근하려고 하면, 대부분 Null Pointer Exception 을 던진다.

NULL 을 포함한 객체를 생성하고 전달하면 항상 NULL을 참조하는 예외가 발생할 수 있다.

조심하면 된다. 쓰기전에 검사하면 된다 라고 할 수 있지만 설계에 조금만 신경쓰면 예방할 수 있는 방법이 있으니 이 방법을 활용해보자.

언어는 타입스크립트로 작성했다.

export class Inventory {
  ...
  getItemQuantity(itemNumber: number) {
    return this.getItem(itemNumber).getAmount();
  }
  ...
  protected getItem(itemNumber: number) {
    if (this.hasItem(itemCode)) return this.items[itemCode];
    else return new Item(itemCode);
  }
  ...
}


class Item {
  constructor(itemNumber: number) {
    this.itemCode = itemCode;
    this.amount = 0;
  }
  ...
}

인벤토리와, 그 안에 있는 아이템에 대한 객체다. 인벤토리에서 아이템 번호로 아이템을 찾아 그 수량을 얻어내는 코드이다. 인벤토리에서 아이템을 선택하는 getItem 이라는 메소드를 보면, 아이템 번호로 아이템 유무를 확인하고, 있으면 아이템을 반환하고 없으면 새 아이템을 생성해서 반환한다.

새 아이템을 생성하는 코드를 보면 수량이 0인 아이템을 반환하도록 하고 있다.

만약, 아이템이 없으면 null을 반환하고 null일때의 처리를 별도로 구성한다면, 널 포인터 예외는 당연히 발생할 수 있고 논리 구조가 복잡해진다. 두 논리 구조를 비교해보자.

1. NULL 객체 패턴을 적용한 논리구조

a. 아이템을 선택한다.

b. 선택한 아이템의 수량을 반환한다.

2. NULL을 반환하는 논리구조

a. 아이템을 선택한다.

b. 선택한 아이템의 반환이 null인지 확인한다.

c. null이면 0을 반환한다.

d. null이 아니라면 선택한 아이템의 수량을 반환한다.

단순한 수량 반환만 해도 논리가 간단해진다. 인벤토리에 아이템을 추가하기 같은 기능 확장을 위한 논리도 단순해질것이라는 상상을 해보자. 물론 항상 나오는 이야기인 은 총알은 세상에 존재하지 않는 만큼 이런 방법론은 예외나 에러를 발생해야 할 상황을 놓친다면, 추후에 찾아내기 어려워진다는 단점이 있다. 하지만, 우리에겐 테스트코드가 있지 않은가.

여기서, 인벤토리와 아이템이 아니면 적용하기 힘든 구조가 아닌가 라는 생각이 잠깐 들 수 있지만

게시판과 게시글, 회원 관리 시스템에서의 회원, IoT 시스템의 센서 등등.. 여러 체계가 인벤토리와 아이템과 굉장히 비슷하다는것을 알 수 있다. 널 객체 패턴의 여러 예시는 직원 관리 시스템을 예시로 들고 있는데 적절한 추상화를 해보면 인벤토리와 아이템과 크게 다르지 않다고도 볼 수 있지 않을까.

구조와 설계를 보는 통찰력 - 가상 면접 사례로 배우는 대규모 시스템 설계 기초

미국산곰고기 — Thu, 24 Nov 2022 14:55:37 +0900

당장 눈앞에 펜과 종이가 놓여지고 큰 시스템의 동작을 설계를 하자는 제안을 받는다고 하자.

질문을 받은 나는 적당히 알고 있는 내용을 얼버무리는 것이 아니라 어떤 부분을 고려해야하고, 어떤 방식으로 문제를 해결해야 하는지, 확장을 어떻게 고려할것인지를 하나하나 쪼개서 수행할 능력이 있다고 할수 있는 사람일까?

이 책은 위 질문의 대답이고 해결 "책" 이다. 무언가 공부할 때 알아가는 순서를 모르겠을 때, 내가 무얼 모르는지 모르는 상태일 때 출발선을 명확하게 그어줄 수 있는 내용을 담고 있다. 어떻게 보면 내용이 깊지 않다고 생각할 수 있지만 이 책의 역할을 모든것을 알 수 있는 능력이 아닌 내가 관심있는 내용을 공부를 시작할 수 있는 기반을 다지는 내용이라고 보면 명확하다고 생각한다.

이 책에는 단원마다 참고 문헌이 등장한다. 책은 총 320페이지에 불과하지만 참고 문헌 하나하나가 굉장히 튼튼한 내용을 담고 있기 때문에 관심있는 주제가 있다면, 그 링크를 들어가서 따로 시간을 들여 읽어보아야 할 만큼 내용이 방대하다. 제목은 면접 사례이지만 분명 설계에 필요한 능력이다. 이 책은 단 320페이지만에 이 넓은 통찰력을 제공하고 어떤 내용을 공부해야하는지에 대한 기반을 확실하게 제공한다. 나라면 어떻게 했을까? 라는 생각을 하면서 이 책의 질문에 먼저 답해보면서 책을 읽어나가고, 이 내용에 대해서 공부해야겠다 라고 생각이 드는 내용이 하나라도 있고, 그 URL을 접속해서 글을 읽는 순간 이 책의 내용이 거미줄처럼 얽혀 굉장히 복잡하다는 것을 알 수 있을것이다.

개인적으로는 정말 추천하는 책이다. 그 링크를 뻗어 책에서 위키질이 가능할만큼 내용이 방대하다

+ 훌륭한 기반이 될 수 있는 넓고 명확한 내용

+ 튼튼한 레퍼런스, 내용이 궁금하면 바로 확인할 수 있음

+ 면접 기반이지만 실무에서 필요한 설계를 예시로 듦

- 레퍼런스를 참조하지 않고 책만 본다면 내용이 얕다고 느껴질 수 있음

- 기술적인 내용을 아예 모른다면 접근하기 어려운 이야기일 수 있음

ISBN13 9788966263158

OpenSSL 프로젝트의 버전은 왜 1.x.x 다음이 3.x.x 일까

미국산곰고기 — Tue, 15 Nov 2022 19:40:15 +0900

오랫만에 Critical CVE가 나온다고 해서 긴장하며 기다리다가 3버전으로 한정되고 그 영향 범위도 똑똑한 컴퓨터 덕분에 축소된 CVE를 보다보니까 그냥 든 생각이다.

버전 체계는 프로젝트마다 다르지만, OpenSSL은 한가지 의문이 들만한 점이 있다.

MAJOR.MINOR.FIX[PATCH] 로 구분하는 메이저 1버전. 예시로 1.1.1q

MAJOR.MINOR.PATCH 로 구분하는 메이저 3버전. 예시로 3.0.7

1버전은 메이저 버전과 마이너 버전 조합이 같을 때 API(ABI) 호환성을 보증한다. 즉, 1.0.2에서 1.1.1로 버전을 변경할 때 API 호환은 보증하지 않는다. 3버전은 같은 메이저 버전의 API(ABI) 호환성을 보증한다. 즉, 3.0.0에서 3.0.7으로 버전 변경 시 API 호환을 보증한다.

1버전과 3버전의 버전 체계는 다르게 돌아간다. 그런데 여기서 한가지 의문이 생긴다.

OpenSSL 2 버전은 어디로 간걸까?

OpenSSL 공식 블로그의 안티오크의 신성한 수류탄(Matt Caswell) 이라는 글에서 밝히길, 미국의 정부나 계약기관에서 보편적으로 사용하는 연방 정보 처리 표준(Federal Information Processing Standards, 이하 FIPS) 를 구현한 모듈인 OpenSSL FIPS module 2 에서 2.0.0 이라는 버전을 사용하고 있기 때문에 메이저 2버전을 건너 뛴다(skip)고 한다. 굳이 진실을 따지는 이유보다는 API 버전이 2.0.0으로 표시하는 이 OpenSSL FIPS Module 2의 실체를 알아보기 위해 github에서 흔적을 쫓아가보자.

우선 Configure 파일과 macros.h 파일을 찾아보면 OpenSSL 자체를 빌드할 땐 메이저 버전 2 를 배제함을 확인할 수 있다.

Configure 파일 및 include/openssl/macros.h 파일

정확히 찾아야하는 녀석의 실체를 알기 위해 배경을 검색해보자.

우선 단서는 두개다. 미국 국립 표준 기술 연구소(National Institute of Standards and Technology, 이하 NIST)에서 암호 모듈을 검증하는 인증서와 OpenSSL 위키의 FIPS module 2.0 이다. 블로그의 글을 먼저 보고, 인증서의 내용을 유추해보면

This 2.0 FIPS module is compatible with OpenSSL releases 1.0.1 and 1.0.2, and not with any other releases.
FIPS 2.0 모듈은 OpenSSL 1.0.1과 1.0.2, 두 배포 버전과 호환됩니다. 그 외 배포 버전과는 호환되지 않습니다.

FIPS 표준 중 OpenSSL은 암호에 대한 FIPS 140을 구현한다. 그렇다면 OpenSSL의 FIPS module 이라는 녀석의 버전은 어떻게 되는걸까? 위키에서 FIPS 3.0에 대한 내용을 어렵지 않게 찾을 수 있었다. 하지만 내용 자체가 많지 않고 연관 링크로 걸려 있는 글은 2018년도에 FIPS 140-2 에 대한 내용이었다. 보통 개발에 대한 글이 이런 모양새라면, 보나마나 완성하지 못했다는 뜻이니 방법을 바꾸어 구글에서 OpenSSL의 FIPS 140-3 에 대한 내용을 찾아보았다.

운이 좋게도, 2022년 9월 30일에 작성된 FIPS 140-3 계획 이라는 글을 OpenSSL 공식 블로그에서 찾을 수 있었다. 글 내용은 대충 표준이 정해지고 요구사항이 정해지고 OpenSSL에 FIPS 140-3은 OpenSSL 3.1에 포함될것이고... 2024년까지는 완성할수 없단다!

FIPS Module 3.0은 없다고 봐도 되겠다. 지금 배포하고 있는 FIPS Modules은 OpenSSL 3 과 함께 배포하고 있다.

그렇다면 FIPS Module 2.0는 어디있는가.

브랜치를 뒤져보니 cvs로 버전관리하던 FIPS 브랜치도 있었는데 이걸 제쳐두고 깃허브에서 조금 더더 찾아보니 OpenSSL FIPS가 의존하는 openssl을 클론 한 저장소도 있었다. 윈도우 7 32비트 환경에서 빌드하는 방법도 설명하고 있는데, openssl-fips-2.0.16.tar.gz 파일을 홈페이지에서 내려받으라고 한다. 하지만 링크에선 더이상 그 파일을 제공하지 않았고, 그 파일 이름을 찾아보니 openssl ftp에 올라와 있는 파일을 발견했다.

openssl fips 2.0 을 빌드할 수 있는 형상을 찾은것같다. 하지만 나의 목적은 빌드가 아니고 버전을 대체 몇으로 명시하고 있느냐다. 소스를 뒤져본다.

FIPS 모듈의 버전을 명시하는 헤더를 찾았는데 아까 위에서 확인한 버전 체계와 그렇게 유사한지는 모르겠지만 0x2001000FL 이라는 버전을 명시하고 있다.

OpenSSL 재단 내에서는 저 버전을 메이저 2버전을 낸것과 비슷한 느낌으로 받아들이는 것 같다.

내 한계는 여기까지인가보다. 더 이상 무언가 쫓아갈 단서가 없어서 여기서 결론을 지으려고 한다.

OpenSSL 1버전과 3버전 사이에는 FIPS 인증하는 모듈이 있는데 그 내부의 버전이 2로 명시되어서 마치 OpenSSL 2 처럼 다루니 OpenSSL 2버전은 넘어간다!

회사에 코드 리뷰 하는 문화 만들어보기, (1) 학습동아리라면?

미국산곰고기 — Mon, 24 Oct 2022 23:46:22 +0900

클린 코드와 디자인 패턴 공부를 하고 나니 회사에 있는 소스코드에서 나는 악취를 맡을 수 있게 되었다.

"이 악취는 내가 치우고 만다" 라는 목표 하나를 가지로 코드를 리팩터링 하고 테스트를 작성하는데, 코드를 작성하다 보니 자연스럽게 의문이 떠오른다.

내가 잘 하고있는걸까?

책에 있는 내용을 내가 이해한 건지, 다른 사람이 보기에 이해하기 좋은 건지, 악취가 가시는 건지 도저히 알 수가 없다.

다만 나와 같은 생각을 하는 사람들이 지금은 없다. 나조차 다른 팀까지 가지 않아도 당장 옆으로 두 칸만 가도 무슨 일을 하는지 모르고 있고 각자의 프로젝트에 커밋하는 개발 문화? 뿐이다. 내 코드 리뷰 경험은 버그를 생산하고, QA를 통과해서 문제를 일으키는 소스를 커밋한 죄로 혼나러 가는 것뿐이었다.

코드 리뷰를 하려면 TDD와 클린 코드를 추구하는 것이 가장 쉽다고 생각한다. 테스트가 잘 동작해야 한다는 것과 그 코드에서 악취가 나지 않도록 한다는 굉장히 명확한 목표가 있으니까.

사실 처음에는 퇴사하고 다른 회사를 찾는다는 생각이 제일 먼저 들었다. 하지만 그 개발 문화는 개발자가 만들지 않는가? 누가 개발자인가? 내가 개발자가 아닌가? 문화를 만들면 되는 게 아닐까. 그렇다면 나는 회사에 클린 코드를 전파하려고 한다. 어떤 방법이 제일 좋을까? 사내 학습 동아리를 만들고 개발 사상을 사람들과 함께 학습하고 나눈다면 그 문화를 공유할 수 있다고 생각한다.

사내 학습 동아리를 만들어보자.

주니어급 개발자끼리 생산적인 피드백을 주고받을 수 있으면 좋겠다고 생각했다. 현재 개발자의 주니어급 인원을 추려보니 대략 5~6명은 동아리를 진행하면 참여할 것 같다. 학습 동아리를 만들어서 그 안에서 클린 코드를 전파하고 뭔가 상의가 필요한 소스코드를 서로 리뷰하면서 이야기를 할 수 있는 자리를 만들어봐야겠다.

동아리의 진행 순서는

1. 토픽 선정

2. 자료 작성 및 예습

3. 토픽에 대한 토론

4. 자료 보충

5. 지식 베이스로 남김

을 목표로 잡았다. 다음에 누군가가 이 동아리와 길을 함께 걷고자 할 때 모든 구성원이 같은 지식 출처로 무장하고, 보충한 자료를 언제든 활용할 수 있다면 지식을 전파하는데 아주 좋은 수단이 되지 않을까.

악취 나는 코드를 방치하는 죄를 청산하듯, 그 문화를 바꿔나갈 수 있는지 해보아야겠다. 혹 알까. 이 회사의 문화가 정말 바뀔지

개발자가 읽은 "오늘도 개발자가 안 된다고 말했다"

미국산곰고기 — Mon, 24 Oct 2022 23:24:55 +0900

책을 둘러보는데 개발자로써 그냥 지나칠 수 없는 책 제목을 만나버렸다. 오늘도 개발자가 안 된다고 말했다니. 심지어 오늘 말한 그대로다.

어쩌다보니 업무에 개발자가 나설일이 굉장히 많아졌는데 그러다보니 기획, 마케팅 여러 사람들이 개발자를 컴퓨터랑 떠드는데 익숙한 무언가로 보는 세상의 느낌이 그대로 제목에 드러난다고 할까.

책 내용은 반 이상이 기획자와 디자이너에게 맞추어져 있다.(비중은 개발자가 제일 많을지도 모른다) 개발자가 흥미롭게 읽을만한 부분은 1/3정도인데, 나머지 부분은 내용이 와닿지 않다보니(어렵다보니) 언급하기 어렵다. 그리고 결론을 말하자면 개발자로써 이 책을 마냥 좋게 볼 수 없었다.

이 책에서 묘사하는 "어려움" 은 다른 도메인을 가진 사람과의 협업이 어려움이지 "개발자" 여서 어려운 점은 아니라고 생각했다. 소통을 잘 하는 방법은 개발자나, 디자이너나, 마케터나 모두 공부해야 하는 것이라고 생각하기 때문이다. 개발자라고 자신의 도메인에서만 일을 하는 특권을 누릴것은 아니라고 생각하기도 하고.

내가 이 책을 고른 이유는 다른 도메인을 가진 사람이 "개발자" 를 어떻게 생각하는지 보고 싶었기 때문인데 이 생각 자체가 일반화였다. 어떤 개발자가 소통의 어려움을 호소하며 기획자나 디자이너에게 '개발 좀 공부해보면 안돼요(어때요 등)?' 라고 했다면 그건 그 개발자가 실례를 한게 아닐까. 다른 직종의 사람에게 자신의 도메인을 강요하는 발언을 했다는 것이 같은 개발자로써 부끄럽다. 차라리 그 개발자가 디자인을 함께 공부해서 소통하면 어떨까?

기술 업계의 독성 말투를 고치자는 글을 읽은 적이 있는데 어쩌면 이 독성 말투에 절여진 누군가가 기획자와 디자이너를 괴롭혔던게 아닐까 라는 생각을 한다. (참 좋지 않은 단어다. 비-개발직군이라니.)

+ 개발자가 어떤 도구를 가지고 협업하면 좋은지 정리가 굉장히 잘 되어있다

+ 여러 직군이 느끼기에 좋은 개발자가 어떤 개발자인지 알 수 있다

+ 각 역할이 나누어져서 본인의 일을 충실할때 업무의 장점을 이해할 수 있다

- 기획자와 디자이너가 취해야 하는 포지션과 과업을 설명하는 책이기 때문에 개발자가 이해하기 어렵다

- 어떤 용어 설명이 중간중간 나오기는 하나 부실한 편이고, 기획자나 디자이너가 알고있어야 하는가 의문이 드는 부분도 있다

개인적으로는 저자분들이 잘못 느낀것이 아니라 개발자들이 스스로 만든 이미지라고 생각한다. 소통을 열심히 하자.

오늘도 개발자가 안 된다고 말했다 김중철, 김수지 저 (디지털북스)

ISBN13 9788960883727

PART 01 가깝고도 먼 개발자
1. 어딘가 이상한 비전공자의 협업
2. 온몸으로 느낀 개발자
3. 협업을 위한 준비물

PART 02 기획자의 일
1. 서비스 기획 들여다보기
2. 협업을 위한 사전 준비
3. 협업을 돕는 화면 설계서

PART 03 디자이너의 일
1. 디자이너의 마인드셋
2. 정확한 시각화를 위한 개발 지식
3. 협업을 위한 개발 지식

PART 04 개발자의 일
1. 개발자 이해하기
2. 생산성 향상을 위한 협업 툴
3. 개발자가 말하는 협업

일 잘하는 사람은 단순하게 말합니다. 진짜로

미국산곰고기 — Mon, 24 Oct 2022 22:50:23 +0900

개발자로서 일을 할 때는 항상 "기술" 만이 문제가 아니다. 소프트웨어 개발의 5단계가 어떻게 이루어져 있던가

요구사항 분석, 설계, 구현, 테스트, 유지보수

요구사항을 파악하고 일정을 잡고 이슈를 캐치하고 수정하는 모든 과정이 소통인데 이 책은 그 소통을 어떻게 해야 하는가의 전체적인 밑그림을 그릴 수 있는 능력을 키워준다. 그림을 그릴 수 있다는 것은 무언가 잘못되었을 때 스스로 문제를 확인하고 개선할 수 있다는 것이다.

일하면서 생기는 여러 문제들. 왜 내 설명을 높으신 분들이 이해하지 못하고 고객이 이해하지 못하는지 이 책을 읽고 나면 남 탓을 하기 어려울 것이다. 내가 과연 이해할 수 있는 언어로 한 건지, 내 의도를 충분히 전달한 건지, 상대방이 말하고자 하는 것은 내가 캐치했는지 사후 강평을 해보도록 하자.

여담으로, 이 책의 내용을 일하면서 의식하다 보면 책에서 설명한 상황이 정말 찾아온다. 우리가 무얼 위해 책을 읽었던가. 마음껏 활용해보자

+ 야근을 줄일 수 있는 내용

+ 구성이 좋다. 정말 일에 필요한 여러 상황이 있다.

+ 예시가 명확하다. 책의 표현을 따르자면 상황의 그림이 그려진다.

+ 여러번 읽으면서 내용을 익혀두면 스스로를 구원해내는 순간이 온다.

- 각각의 내용은 밑그림을 그릴 정도다. 깊게 파고 싶다면, 내용마다 특화된 책이 필요

사회 초중년생에게 이만한 책이 있을까. 어서 밑그림을 그릴 수 있는 능력을 얻고 각 능력을 키울 수 있는 사람이 되자!

일 잘하는 사람은 단순하게 말합니다. 박소연 (더퀘스트)

ISBN13 9791165211387

프롤로그 _ 언어는 삶의 강력한 도구가 됩니다. 특히 일하는 사람에게.

Part Ⅰ_ 단순하게, 소통하다

Chapter 1 보고의 언어 _ 상대방의 머릿속에 그림을 그려주다

Chapter 2 지시의 언어 _ 원하는 목적지를 정확하게 보여주다

Chapter 3 마케팅의 언어 _ 단순한 메시지로 소비자 마음을 움직이다

Part Ⅱ_ 단순하게, 설득하다

Chapter 4 파토스의 언어 _ 언제나 상대방이 이야기의 주인공이 되게 하다

Chapter 5 로고스의 언어 _ 좌뇌와 우뇌를 움직일 근거를 찾다

Chapter 6 에토스의 언어 _ 말하는 사람의 매력을 보여주다

# Special Tips : 회의에서 명쾌하게 대화하는 기술

Part Ⅲ_ 단순하게, 마음을 얻다

Chapter 7 협력의 언어 _ 친절하지만, 선을 단호하게 지키다

Chapter 8 친밀의 언어 _ 다정한 언어로 마음을 얻다

Chapter 9 해결의 언어 _ 문제 상황을 매끄럽게 해결하다

Part Ⅳ_ 단순하게, 이끌다

Chapter 10 리더의 언어 _ 부서원을 존중하고 합리적으로 대화하다

에필로그_ 언어가 장벽이 아니라 가장 멋진 도구가 되기를

error: expected initializer before ‘namespace’ 해결일기

미국산곰고기 — Fri, 12 Aug 2022 13:45:42 +0900

꽤 작성하던 코드가 갑자기 빌드가 안된다.

In file included from include/log.h:3:0,
                 from src/main.cpp:13:
/usr/include/c++/4.8.2/sstream:41:1: error: expected initializer before ‘namespace’
 namespace std _GLIBCXX_VISIBILITY(default)

대체 무슨 문제인가 하고 찾다가 함수나 구조체 등 무언가 선언이 완료되지 않으면 주로 발생하다는 글을 보고 찾아보았다.

내 코드의 경우 main.cpp의 13번째 줄까지는 전부 include 선언이다.

13번 째 줄도 log.h를 include하는 내용이다.

그렇다는 것은, 13번째 이전 줄의 헤더 파일 어딘가에 선언이 완료되지 않은 함수가 있다는것.

다행히 바로 이전인 12번째 줄에 불러온 헤더 파일 내부에 새로 만든 함수의 선언부에 세미콜론이 달려있지 않은것을 확인했고 세미콜론을 달아주고 ~~그간 찾아내지 못한 몇가지 컴파일 에러를 고치고 난 후~~ 빌드를 성공했다.