Hello world

프로그램의 시작이 main 함수에서 이뤄짐 C나 C++이 생각난다.

void main(List<String> arguments) {
  print(arguments);
}

Type System

Dart는 타입 언어로 다양한 Built in type들을 지원하고, 타입체크 기능과 타입추론 등 타입 사용을 위한 각종 feature를 제공한다. 그와 동시에 타입에서 자유로운 Variable도 제공하고 있는데 할당시에 타입추론을 통해 자동으로 타입이 결정된다.

Control Flow

if else-if else, for...in for while, switch break continue 등 제어 로직은 자바스크립트 문법과 유사하게 제공된다.

Function

파라미터와 반환값의 타입을 지정한 형태의 함수로도 사용가능하고, 자바스크립트와 유사 문법의 Arrow Function도 사용 가능하다.

int fibonacci(int n) {
  if (n == 0 || n == 1) return n;
  return fibonacci(n - 1) + fibonacci(n - 2);
}
...
(name) => name.contains('turn')

함수의 파라미터엔 세 종류가 있는데 Required positional parameters Named Parameters와 Optional positional parameters 이다 이 중 required positional parameters가 일반적으로 사용하는 함수 파라미터와 같은 개념이고, 그 뒤에 Named Parameters 나 Optional positional parameters가 올 수 있다. 둘 중 어떤 것을 붙여써도 상관없지만 둘 다 붙여쓸 수는 없다.

Required positional parameters

String say(string lastname);

Named parameters

Named Parameter는 {} 로 감싸서 정의 가능하다. 기본적으로 모든 Named parameter가 옵셔널하기 때문에 필수 인자로 하고싶으면 required 예약어를 사용해야한다.

String say({required string firstname});

dart에선 인자에 ?를 붙여 nullable을 표시할 수 있는데, required와 ?의 동시 사용도 가능하다.

// null 값으로 넣을 순 있지만 꼭 입력은 해줘야하는 middlename
String say({required string? middlename});

Optinal positional parameters

옵셔널 파라미터는 []로 감싸서 사용할 수 있다. 옵셔널 파라미터의 값에 defaultValue를 지정하지 않을 경우 필수적으로 nullable ? 선언해줘야 한다.

String say(String lastname, String firstname, [String? suffix]) 

Lexical Scope

자바스크립트와 같이 하위에서 상위의 변수를 참조할 수 있는 스코프를 제공한다. 자바스크립트와 유사하게 클로저 선언도 가능하다.

Tear-off

Function이나 Method 사용 시 인자를 직접 넣어 호출하지 않더라도 상위 환경에서 자동으로 떼어와 삽입해주는 Tear-off 기능이 제공된다.

// bad
charCodes.forEach((code) {
  print(code);
});

// good
charCodes.forEach(print);

Generator

Dart에선 연속된 값(배열같은)의 생성을 위해 두 종류의 generator를 제공한다.

Synchronous generator: Iterable 반환

Iterable<int> countdown(int start) sync* {
  for (var i = start; i > 0; i--) {
    yield i;
  }
}

void main() {
  for (var num in countdown(5)) {
    print(num);
  }
}

Asynchronous generator: Stream 반환

Stream<int> asyncCountdown(int start) async* {
  for (var i = start; i > 0; i--) {
    await Future.delayed(Duration(seconds: 1)); // 1초 대기
    yield i;
  }
}

void main() async {
  await for (var num in asyncCountdown(5)) {
    print(num);
  }
}

External

바깥에서 구현된 함수를 사용할 때 선언용으로 사용하는 예약어

external void someFunc(int i);

Comments

주석 사용법은 자바스크립트와 완전 동일하다.

라이브러리 비교

장단점

React-Native Flutter Lynx를 비교하여 Flutter를 적용하기로 했는데 비교당시 파악한 장단점은 아래와 같다.

React-Native

Pros

• React 개발자라면러닝커브가 거의 X
• 프로덕션에서 많이 사용되기 때문에 지원되는 서드파티가 많다
• 서드파티가 없을때 네이티브-브릿지를 이용한 커스텀 라이브러리 제작이 가능하다

Cons

• 성능이슈로 UI 화면이 부드럽게 넘어가지 않는다는 느낌이 크다.
• node 생태계를 이용하다보니 디펜던시 설정을 직접 다 해야한다. (Expo 사용시 부담이 적으나 추후 커스텀을 생각해 고려하지않음)
• 아직 1버전도 되지않았고 breaking change가 꽤 있어 지옥의 마이그레이션

Flutter

Pros

• 구글주도로 개발되어 관리가 잘 된다는 느낌을 준다.
• RN에 비해서 렌더링 성능 좋음
• (익숙해지면) 앱 개발 속도가 굉장히 빠르다고 함

Cons

• 프론트개발자에게 높은 러닝커브, 처음보는 언어와 아키텍처
• 프로덕션에서 사용되는 비율 낮다고 느낌
  • 이 부분은 레딧의견들을 봤을 때 react에 추가적으로 크로스플랫폼을 원하는 기업이 많기때문에 RN이 프로덕션에서 더 우세하다고 생각하는 것 같다.
• 설정부터 개발까지 뭘 해야할지 어떤걸 해야할지 어느정도 공수가 있을지 파악이 안됨
  • 지금 이 글을 쓰는 시점이 Dart 접근 1일차이기때문에 내 머리는 백지와 같다.
• Skia를 기반으로 개발되어있는데 IOS에서 버벅이는 고질적 이슈가 있다고함
  • 추후 Impella로 코어 엔진 변경 계획이 있다고 함

Lynx

Pros

• 틱톡 개발사인 Bytedance에서 내부적으로 사용하던 크로스플랫폼 라이브러리로 메인테이너가 명확하게 있다보니 디스커션 응답 속도가 빠르고 프로덕션 이슈가 빠르게 해결될 거라는 기대감이 있음

Cons

• 25년 3월에 오픈소스화 된 따끈따끈한 라이브러리라 자료가 너무 없음
• Bytedance가 중국회사다보니 discussion에 중국어가 들어가는 경우가 많음 (외국인을 배려해서 동일한 문장에 대해 중국어와 영어를 같이 써주시는 경우가 많긴 함)
• 따끈 라이브러리 특성상 써드파티가 많진 않음

결과

UX 효과를 다양하고 자연스럽게 넣고싶다는 팀 내 희망사항이 있어, 렌더링 성능이 좋다는 flutter로 결정하였다. 웹과 구조와 문법이 비슷해 러닝커브가 낮을거라 예상되는 RN이나 Lynx를 포기하고 디펜던시 설정이나 성능 등을 고려해서 결정한 사항이라 아무쪼록 우리가 훑어본 장점이 잘 드러나길 바라는중

좋았던 점

신규 서비스 런칭

12월에 정말 몸을 갈아넣는 기분으로 열심히 작업했는데 너무 무리한 공수산정이었을까? 인원을 둘 추가하고도 1월 중순정도로 런칭이 밀려버렸다. 그치만 어쨌든 (내 마음 속 기준에 여기까지 밀려도 된다의 마지노선에) 늦지않게 런칭이 그럭저럭 무사히 되어 뿌듯했다. 인원이 추가될 때 이미 너무 바쁜 상태여서, 커뮤니케이션이 부족한 상태로 진행해서 오히려 일이 더 많아진 느낌도 있지만 어쨌든 팀원들도 정말 열심히 노력해줘서 다같이 해냈다는 기분이라 더 뿌듯한 것 같기도. 또 오랜만에 여럿이 함께 작업했다보니 문제의식이 부족했던 스스로의 언어습관도 돌아볼 수 있었고, 다같이 회고하며 좋았던 점 아쉬웠던 점 나누며 상당히 마무리감 있게 되었다고 생각해 기분이 좋았다. 비록 회계처리 문제로 아직 실제 오픈은 못한 상태지만.. 시장조사 느낌의 가오픈 상태로는 생각보다 성과가 괜찮다고 느껴지고, 개발할 때도 상당히 마음에 드는 아이템이었기 때문에 얼른 정식으로 오픈했으면 좋겠다.

상반기 작업의 알찬 성과

상반기에 전력으로 개발했던 AI드로잉 기능이 마케팅쪽의 좋은 홍보영상 덕분에 원래의 목적이던 신규 사용자 유치에 상당한 성과를 거뒀다. 사실 그 소식을 들은지 그리 오래되지 않았는데, 작업과 성과 사이에 꽤 텀이 있었다보니 뒤늦게 파도처럼 밀려오는 감동이랄까? 기분좋고 뿌듯했다. 당시에 일정문제로 제품제작까지 연동하지 못했었는데 최근의 성과 덕분에 해당 기능을 국내스쿼드에 계신 팀원분께서 진행해주시게 되었다. 아무쪼록 매출까지 이어지는 더 큰 성과가 됐으면 좋겠다.

면접관 경험

처음으로 정식 면접관으로 면접에 참여하게 되었다. 진행은 주로 팀 리드께서 하셨기 때문에 참여보다는 참관같은 느낌도 강했지만, 지원자분들과 소통하는 과정에서 배울 점도 많아 귀중한 경험이었던 것 같다. 기술 트렌드도 생각지 못하던 내용을 들을 때가 있었고, 트러블 슈팅 경험을 들을 때는 이런 방식으로 문제에 접근하는 방법도 있구나 생각될 때도 있었다. 그리고 면접관으로 있어보니 어떤 지원자가 좋은 지원자인가를 생각해보며, 동시에 내가 어떻게 더 좋은 개발자가 될 수 있을지 생각해볼 수 있는 시간이 되었다. 개발자로 부족한 부분이나 더 살려야 할 강점 등도 생각해볼 수 있었고, 어떤 지원자분의 팀 경험을 듣고 파트리드로서 파트원들에게 도움이 될 수 있는 부분에 대해서도 더 생각하게 되었다. 그 결과로 파트 월간 커피챗 시간을 가지게 되었는데 다들 만족할 수 있는 시간이 되도록 대화소재를 잘 생각해가야겠다.

아쉬웠던 점

부족한 웹 베이스

사내 신규 서비스를 런칭하며 Nextjs를 처음 다루었다. RN개발을 오래해 웹 베이스가 약한 상태라 확실히 알지도 못하고 확실히 모르지도 않는 채로 애매하게 개발한 것이 많았다. Vercel+Next 셋팅같은 경우도 완료된 상태로 개발을 진행했다보니 살짝만 툭 건드려도 모르는게 계속 나오는데 공부를 해야한다 생각하고 딱히 공부를 뭔가 하진 않았다. 사내 엔터프라이즈 계정에 playground 생성이 가능할 것 같아서 뭔가 만들어보면서 공부하는게 좋을 것 같은데.. 어떤식으로 공부해나갈지 주제를 정하는 것과, 트러블슈팅하면서 캐치한 특성들을 딥다이브해보는 것이 부족했다고 생각된다. 그래도 SSR을 오랜만에 다뤄서 재밌었다. (마지막 SSR은 2016...?년에 react+express로 직접 구현했던 것)

실행력 부족

요새 진짜 내가 ADHD일까? 생각할 정도로 머리에선 몇십초마다 휙휙 이런저런 다양한 생각을 하고 있는데, 뭔가를 하자고 생각해놓고 정작 실천하거나 실행한건 10%도 안되는 것 같다. 공부를 한다거나 사이드 프로젝트를 한다거나, 건강 관리나 글을 꾸준히 쓴다거나 책을 읽는다거나, 아침에 일찍 출근한다거나, 술을 끊는다거나 각종 인생에 도움이 될 습관은 꾸준히 한 게 하나도 없는 것 같다. 특히 이제 근근히(?) 명맥을 유지하고 있는 사내 글쓰기 스터디 문장공장은 3,4분기엔 일정에 치여 반도 소화를 못했다. 휴... 올해 다행히 스터디가 유지되게 됐고 새로 사이드프로젝트도 진행하게 되었는데 또 한 해가 그냥 지나가버리지 않도록 노력해서 이런저런 습관들을 만들어 가야겠다.

언어습관

작년은 스스로의 언어습관에 대해 상당히 자주 돌아보게되는 한 해였다. 말을 못한다고 생각하지 않았는데 사실 난 말을 잘 못하는 것 같다. 작년에 스스로를 돌아보며 깨달은 내 언어습관의 단점들은 다음과 같다.

말을 불필요하게 늘여서 한다.

이건 스스로는 전혀 깨닫지 못하고 있던 단점인데, 나는 말을 너무 길게 하는 일명 '장문충' 이었다. 어느정도냐면 팀 리드께서 내 피드백을 듣다가 팀 내에 말을 간결하게 하는 방법에 관한 책을 필수도서로 지정하실 정도. 거기에 부족한 웹베이스에서 나오는 엉뚱한 질문까지 더해져서 가끔 상대를 조금 괴롭게 하고 있나..? 라는 자각이 생겼다. 필수도서 두 권을 읽고 반성하여 말을 짧게 하려는 노력을 하고 있는데, 1차로 글을 쓰고 다시 읽으며 내용을 줄여보면 불필요하게 길게 쓴 부분도 있고, 어떻게 줄여야할지 모르겠는 부분도 있고 아직 발전도중이다. 개인 SNS에서도 글이 굉장히 긴 편이라 항상 글자수 제한에 걸리는데 좀 더 짧고 담백하게 말하려는 노력이 지속적으로 필요할 것 같다.

타인의 말을 끊는다.

스스로 생각하기에 말하는 능력은 부족해도 이해하는 능력은 괜찮은 편이라 커뮤니케이션 중 타인 사이의 겉도는 대화를 번역(?)하는 경우도 종종 있는데 그러다 말하던 사람이 자신이 언어로 좀 더 설명하려고 해도 중간에서 강제 번역(?) 할 때가 있었다. 회의중에 의사소통이 잘 안되어 시간이 흐르는게 낭비같이 느껴져서 그러곤 했었는데 그런 일이 유독 한두명한테 반복되다보니 어느순간 문득 내가 상대의 말을 잡아먹고 있다는 느낌이 들었다. 본인의 언어로 정확히 표현하고 싶은 뜻이 있었을지도 모르는데 강제 생략시킨 느낌이라 반성했다.

애매한 표현

면접에서 좋은 리더는 피드백에 명확한 리더라고 말씀하신 분이 계셨다. 그 얘기를 들으니 파트원과 면담할 때 부정적 내용의 피드백은 굉장히 모호하게 말하게 된다고 생각해서 아..! 하고 부정적 내용을 정제해서 말하는 능력이 부족해서 모호하게 말하고 있구나 깨달았다. 또한 얼마 전 내 모호한 표현때문에 마음이 상하셨다는 피드백도 들었는데, 말 할 당시나 피드백을 들을 때도 내 표현이 딱히 잘못됐다고 생각하진 않았지만 좀 더 대화를 나눠보니 좀 더 풀어서 설명을 드렸다면 좋았을까 싶었다. 사실 해당 피드백을 할 때는 이미 같은 주제로 같은 논의를 4번째 할 때라 벽에 대고 얘기하는 기분이 들어 지쳐있었다. 그래서 마지막엔 반복논의에 대한 반발심도 있었는데 감정대로 부정적 말을 할 수도 없고, 그걸 잘 녹여서 말하지도 못했기에 모호한 피드백이 되었었나? 생각이 들어 말을 잘 정제하자고 반성했다.

부정적, 냉소적 피드백이 많다.

최근 2인 체제로 작업하면서 팀원께 피드백을 많이 드리다보니, 부정적 피드백은 당장 고쳐야할 필요를 느껴 바로바로 얘기하게 되는데, 좋은 피드백은 분기행사마냥 하고 있네? 이러면 같이 일하는 입장에서 스트레스받고 싫을 것 같다 생각이 들었다. 그래서 의식적으로 좋은 얘기도 더 많이 해야겠다고 다짐했다.

해야할 것

글쓰기

• 일상에서 생각나는 개발 주제를 리스트화하여 리스트의 주제들을 예제다루듯 구현 및 테스트해보고 개발블로그도 적자고 생각했다.
• 그리고 일상블로그도 꾸준히 적기.. 지금 파리 날린다.

사이드 프로젝트

• jumto A.K.A 점심 토이프로젝트는 순항인듯 하면서도 나의 건강이슈로 진행이 지지부진하다. 이제 내 마음속 마지노선으로 다음 모임 전에는 git respository 셋팅 및 flutter vs RN 구현 테스트를 꼭 해야만해.. 몸 좀 회복되고 기침 좀 멎으면 주말에 힘내봐야겠다.

주기적 집안일

• 집이 더러우니 이도저도 안된다는 생각이 들고 천식이 있는데 집에 먼지가 이렇게 많은게 말이 안된다는 생각도 들어서 올해는 어떻게든 집을 개간하여 갑작스런 누군가의 방문도 가능할 정도로 조금 정돈된 생활을 하자고 생각했다.

책 읽기

• 개발도서 읽은지 너무 오래됐는데 안 읽다보니까 개발도서는 커녕 웹 소설도 꾸준히 읽기 힘든 지경이다. 올해는 개발 트렌드 공부도 하고 개발 공부도 하고 부족한 웹 베이스와 신규 기술 공부를 열심히 해서 깊게 생각할 수 있는 개발자가 되자고 생각했다.

건강관리

• 더이상 미룰 수 없다. 친구의 웨딩사진을 보니 위기감이 느껴진다. 처음 살이 찔 때는 건강이 안 좋아 스테로이드 장기복용을 하며 찐 거지만, 이제와서는 건강 안좋음과 체력, 살찜 셋의 악순환이 되었고 미용적으로 이 상태로 웨딩사진을 찍을 순 없어 라고 생각했기 때문에... 3월에는 꼭 열심히 다이어트 하자고 생각했다. (독감이 낫고나면....
• 그리고 허리가 너무 자주 아파서 홈트라도 데드리프트 스쿼트 코어 운동을 좀 해야할 것 같다

새해를 시작하며

인생이라는게 결심하고 적당히 실행하고 기뻐하고 반성하는 일의 반복인거지만.. 내년에는 조금 덜 반성할 수 있도록, 좋은 리드와 함께할 때 열심히 살아보자고, 그리고 나도 좋은 리드 좋은 팀원이 되자고 생각했다. 일단 건강한 한 해가 되기를

WORK

프린트허브

3,4분기의 주요 에픽으로 자사 신규서비스 프린트허브를 개발하고 있는데 프린트허브의 난점으로는 기획 백엔드 프론트엔드가 거의 병렬진행되고 있어서 업무순서상 명확하지 않은 상태에서 작업을 해둬야하는 부분이 많았다는 것이다. 설계를 예상할 수 있는 지점부터 개발해나갈 수 있는 일이지만 개인적으로 명확하지 않은 상태에서 개발을 진행하는것을 좋아하지 않는 편이라 마음 속 미약한 거부감 때문인지 작업 속도가 생각한거보다는 나오지 않았다. 4분기부터는 프로젝트에 프론트엔드 개발자가 한명 더 붙으니까 열심히 서둘러서 당초 목표로 했던 날짜에 서비스를 출시할 수 있으면 좋겠다.

Nextjs

넥스트를 처음 사용하며 프론트엔드에 개념적으로 이해도가 낮은 부분이 있다는 생각이 많이 들었다. 일할 때야 배워가며 할 수 있다 생각은 하지만 그래도 그런 부분이 시니어라고 하기에는 부족하게 느껴지지 않을까 싶어서 아쉬운 느낌이 있었다. 팀원들이 믿고 의지할 수 있는 사람이 되고 싶다는 생각이 들었다. 그 방법에 대해선 아직 ? 이긴하다.

회의

3분기는 뭔가 유독 회의가 많았던 것 같다. 일단 프린트허브와 디자인시스템이 별개의 트랙으로 분리되면서 회의가 2개가 되었고 서브챕터 회의도 신설되었다. 또 분기마다 진행되는 팀 내 타임라인 점검 회의, 매주 진행되는 리더회의도 있고 팀에 신규채용을 진행하게 되면서 채용관련 회의도 생각보다 많이 있었다. 그리고 중간중간 공휴일이 많았기 때문에 비율적으로 회의에 쓴 시간이 다른 분기에 비해 유독 많게 느껴졌는데 되돌아보면 딱히 필요없는 회의는 없었기 때문에 어쩔 수 없는 부분이 있다. 다만 나는 원래 회의를 싫어하지 않는데 업무 중간에 있는 회의가 분위기 환기에 도움이 된다 생각해서 좋게 생각하는 편이었어서 이번 기회를 통해 사람들이 회의를 싫어하는 이유를 어렴풋이 느껴본 것 같아 나름 좋은 부분도 있었던 것 같다. 어쨌든 대화를 하루종일 해야한다는건 상당히 지치는 일이었다 😓

HOBBY

지난 10여년간 내 인생에 나름 큰 부분을 차지했던 데프트 김혁규님이 선발전을 끝으로 당분간 휴식기를 가지게 되었다. 군대다녀와서도 다시 선수로 복귀할 수 있을까? 본인은 선수가 안된다면 감독코치로라도 업계에 리턴할 마음이 있는 것 같지만 나는 어떻게든 선수로 다시 왔으면 하는 마음이 커서.. 가기전에 좋은모습 많이 보여주고 갔으면 했는데 그래도 선발전 경기들에 임팩트를 크게 남겨서 마음이 그나마 좋았고.. 그치만 잘해서 마지막 날에는 더 눈물이 났던 것 같다. 그래도 본인은 후련하다 하셨으니 치열했던 삶을 잠시 내려놓고 조금 여유도 즐기고 건강도 챙기고 그렇게 돌아오면 좋겠다. 그리고 혁규가 가자마자 세븐틴이 컴백을 해서 이번주는 콘서트엘 가고 다음주는 여름에 예매해뒀던 나토리 콘서트를 보러 일본에 가는데 그 중간에 세븐틴이 컴백을 하셔가지고 사녹보러갈 수 있는가 하는 걱정도 살짝 되고 그래도 인생에 뭐라도 즐길 수 있는게 있다니 좋은거지 하고 좋게좋게 생각하려 하는중이다.

LIFE

여름이 끝나고 날씨가 선선하니 너무 좋은데 추위 대신 건조함이 먼저 겨울인양 찾아와서 천식땜에 힘들어죽겠다. 딱히 감기는 아닌데 숨쉬기가 불편하니까 두통이 너무 심해가지구... 각 계절마다 좋은점 안좋은점이 있겠지만 온전히 즐기기는 어렵구나 싶어서 약간 아쉬운 마음..? 아프기 쉬운 계절이라 건강을 잘 챙겨야겠다는 생각이 부쩍 든다. 아무래도 일정도 이래저래 바쁘니까.. 그리고 뭔가 소비습관에 대해서 가계부를 들여다봤을 때 아쉬울 때가 많아서 11월부턴 소비내역도 줄여갈 수 있도록 노력해보려한다. 돈을 쓸 때 내가 그에 맞는 가치를 얻는다면 써도 상관없다고 생각하고 쓰는데 가끔 조금 지나고보면 버린 것 같이 되는 금액들이 있었던 것 같아서.. 귀찮음과 돈을 트레이드오프 하던 부분들에 있어서 조금 줄여볼 수 있지 않을까하고 생각해본다.

200의 계획을 세워서 반만해도 100이다가 내 인생의 모토지만, 올해 상반기가 유독 뭔가 아쉽게 느껴진다.

아쉬웠던 점

건강

상반기에 건강이 좋지않은 날이 많았다. 6월에 등록했던 배드민턴도 아킬레스건 윤활낭염 치료로 인해 2번밖에 나가지 못했다. (재밌었는데.. 너무 슬펐다..) 위장이 안좋은날들이 달에 보름은 있었다. 혈액순환장애도 있어서 몸이 자주 저렸고, 윤활낭염의 원인 중 하나로 지목되기도했다. 매트리스가 공간차지하는게 싫었고 이부자리 관리하기는 귀찮아서 반년정도 소파생활을 했었는데, 매일 좁은데서 자서 건강이 안좋아졌나 싶어서 최근 이부자리 생활로 전환했다. 아킬레스건 윤활낭염때문에 체외충격파 치료에 돈을 꽤 썼는데 크게 호전이 없었고 물리치료과정에서 혈액순환이 잘 안되어 그런것 같다는 얘기를 들어서 스트레칭도 의식적으로 더 자주한다. 커피와 술을 끊고 물을 많이 마시게 되었다. 물을 하루에 2.5-3L정도 마시는 것같다. 아무쪼록 생활습관 개선으로 컨디션이 나아지길

일

2분기는 AI드로잉 추가작업으로 훌렁 사라져버렸다. 그런것치고 AI드로잉 결과물 퀄리티가 썩 마음에 들진 않아서 아쉽다. 초반에 일정에 쫓기다보니 고려가 부족했던 점이 있어서, 오프하기 전 생성 인터랙션을 추가하고 오프하고싶었는데 추가하려고 리팩토링하고나니 이미지 모달 캐러셀쪽에서 레이아웃이 깨지는 문제가 재발했다. 애초에 캐러셀을 직접 구현한게 아니고 react-slider를 사용한거라 슬라이드 가로너비가 계속 1px로 초기화 되는 이유를 결국 끝까지 완벽하게 대응하진 못했다. 그렇다고 시간이 더 있었으면 더 좋게 구현됐을까해도 딱히 모르겠어서 많이 아쉬웠다. 1분기 회고에 모바일앱 테스트 자동화에 대한 의견과 모바일 썸네일 용량 관리에 대한 의견을 제시했다고 적었었는데, 해당 내용을 수행해야할 2분기를 온통 AI드로잉에 다 써버려서 정작 하고싶던 이슈도 진행이 덜됐다. (칸반에서 시간만 흐르는 이슈를 보며 애타는 마음...)

그래도 잘했던 점을 꼽자면 진행했던, 혹은 리뷰했던 각종 피처에서 기획상 수정이 필요한 부분을 잘 캐치하여 업무효율을 높였고 AI드로잉도 풀스펙은 아니지만 기간내에 출시되어 나름 많은 사랑을 받고있다. 3분기를 맞아 새 서비스르 초기단계를 작업중인데 일정이 생각보다 널널한 느낌은 아니라서 잘 구현해봐야겠다고 생각중이다. 열심히의 일환으로 7월엔 조식도 신청했는데 4일동안 단 한번도 수령하지 않았다.. (위장염이슈로..) 건강이 조금씩 나아지고 있으니 다음주에는 조식 꼬박꼬박 챙겨먹기를 시도해봐야다.

스터디

스터디가 2주1회로 바뀌니 텐션이 많이 늘어지기도 했고 페널티를 한번 받고나니 어차피 한번이나 두번이나 라는 느낌으로 마음이 많이 해이해져서 이번 분기에는 글을 너무 적게 쓴 것 같다. 그래서 3분기 참여를 조금 고민했는데 내가 시작한 스터디기도 하고 열심히 살자의 일환으로 계속하는게 낫겠다 싶어서 페널티 여부를 떠나서 열심히 살자의 일환인 글쓰기를 꾸준히 잘 해낼 방법이나 마음가짐을 고심해봐야겠다.

취미생활

마음이 해이한 와중에 케이티롤스터가 욕만 나오는 경기력으로 날 더 진빠지게 했었는데, 저번주 반등의 기미를 보여줘서 나도 좀 더 의욕이 생긴 것 같다. 특히 고양에서의 경기는 진짜 이겨도 기분 나쁠 것 같다는 생각으로 갔었고, 당일에 몸상태가 엄청나게 안좋은데 이상한 자동문에 제대로 맞아 팔에 피멍이 크게 드는 등 인생 액땜 제대로다 싶었는데 이기니까 좋더라. 역시 스포츠는 이겨야 좋아. 근데 잘하고 이기면 더 좋았을텐데.. 다음주엔 더 잘하시길

그리고 저번달에 있었던 캐럿랜드 티켓팅에서 요새 엘씨케이 대기열에서도 잘 못봤던 1800번대 진입을 한 덕분에 내 손으로 플로어를 잡았다. 이선좌도 없었던건 난생 처음.. 뭔가 다른구역 다 봤으면 좀 더 좋은 자리 있었을수도 있지만 지금 자리에 만족해야지. 자리갈아타기엔 플미가 너무 비싸다. 원가에 이틀 다 가게해주셔서 신님 너무 감사합니다 열심히 살겠습니다 라는 마음이 있었는데 이제 진짜 열심히 살아야한다 캐럿랜드갈때 굿즈도 또 사야되니까 ◜◡◝

Work

5월에 AI드로잉을 마무리하고 그로인해 뒤로 밀렸던 이슈들을 처리하고 싶었는데, 6월에는 또 새 프로젝트가 시작된다. 다음으로 미루면 평생 하지 못하는 리팩토링처럼 이슈들도 생성되는 시일에 너무 늦지않게 진행을 해야하는데 아쉬울 따름이다. 일주일정도 아주 작은 짬이 있어 앱 작업은 어렵더라도, 모바일 이미지 리사이징 작업은 호다닥 해봐야겠다.

Communication

AI드로잉 관련하여 JSON 구성 컨벤션을 정하는 과정에서 팀 내 소통이 약간 잘 되지 않았는데, 그 후에 팀 내 필수도서로 '한 장 보고서의 기술'과 '내 문장이 그렇게 이상한가요?' 라는 두 권의 책이 생겼다. 처음 소감은 정말 '제가 말하는게 그렇게 이상한가요?' 였긴 한데 읽다보니 도움이 되는 것 같다. 약간 불필요하게 꾸며말하는 언어습관이나 불필요하게 보충하는 말들이 많아서 문장이 상당히 장황한 편이었구나 깨닫는 부분도 있고, 근데 나는 이런 내용에선 길게 말하는게 더 낫다고 생각하는데? 하는 부분도 있어서 마저 읽고 문장 교정하는 연습을 해봐야겠다.

Life

6월에 배드민턴 강습을 신규 신청했다. 등록하러갔더니 사람이 너무 많아서(애초에 하루 4타임, 주2/주3으로 반이 나뉘어져있는데 남는 타임이 딱 한 타임이었으니 당연한거지만) 파워 I성향이 발현되어 조금.. 기가 빨렸다. 시간도 아침 6-9시여서 잘 갈 수 있을지 솔직히 걱정이 더 크긴하지만 그래도 초보의 열정으로 잘 나가봐야지. 배드민턴장에서의 자만추를 기대하며...

Interest

6월엔 개막이다. 살..려...줘..... 개막전부터 이 미친 팀은 벌써 날 화나게 하고있다. 정규시즌 한 경기를 상대팀 이벤트용으로 회장을 옮겨서 진행한다는데 자리도 6000석중에 500석만 확보가 되었고 나머지는 상대팀 선예매를 한단다. 미친 구단이 아니고서야 이거를 오케이 할 순 없다. 감코가 미쳤는지 프론트가 미쳤는지 둘 다 미쳤는지 일하는 모양새가 너네가 직장인이라고 할 수 있냐 그런 생각만 들어서 화가 무지로소이다이긴한데, 6월엔 위버스콘이 있다. 그 생각하면서 힘내야지요.

ㅇ<-<

하고싶은게 많으니까 체력이 너무 부족하다고 느끼는 요즘이다. 운동도 해야하고 영양제도 챙겨먹어야하는데, 나이들수록 자기관리의 필요성만 느끼고 실천이 안되어 큰일이다. 6월엔 조금이라도 더 건강한 삶을 위해 화이팅해야지.

일정 산정의 중요성

3월을 끝내고 2분기를 시작하면서 4월에 하고싶던 큰 이슈가 두가지 있었다. 그들을 제쳐두고 회사에서 중요하게 생각하는 새 에픽, 비즈하우스에 AI도구 서비스 추가를 우선적으로 진행하게 되었다.

처음 에픽을 시작할 때 공수산정을 3주로 잡고 진행했는데 소통문제로 난항을 겪었다. 3주째에 몰랐던 기능이 하루에 하나씩 나와서 배포가 일주일 미뤄졌는데, 그 다음주에 스테이징 배포 기간이 임박해서 데이터 구조의 근간이 약간 잘못 전달되었다는 것을 알게된 것이다. 덕분에 2주정도 하루에 최대 12시간씩 근무했는데 이제 진짜 야근을 할 수 있는 나이가 아니다, 몸과 마음이 힘들어서 되겠나 싶었으나 여튼 무사히(?) 1차 MVP를 배포했다.

일정산정을 할 때에 모든게 베스트케이스로 돌아가는 이상적 상황을 가정하고 짜면 안된다는걸 다년간의 경험을 통해 체득했으나, 그렇다고 너무 나이브한 일정을 짜게되면 한도끝도 없기 때문에 그 중간점을 찾는게 중요하다고 생각해서 처음에 3주라는 일정을 잡은게 나름 일주일의 여유기간을 두고 잡은 일정이었다.

그런데 첫주차엔 디자인이 나오지 않아 코어기능들만 개발했고, 2주차에 디자인 전달 후 생각보다 부속 작업이 많아서 약간 타이트한 일정이 되었고, 3-4주차에 소통문제로 정말 타이트한 일정이 되었는데, 제품 개발에 드는 일정이 기획 -> 디자인 -> 개발 이렇게 세가지로 구성되었다고 할 때 이미 MVP치고는 앞쪽에 들인 기간이 길어서 일정을 더 늦출 수 없을 것 같은 상황이 되었다.

되돌아보니 기획을 전달받는 과정에서 약간 수동적이었던 것 같아서 다음에는 좀 더 정확한 일정 산정을 위해 능동적으로 기획 체크를 해야겠다는 생각이 들었다.

그리고 일정이 밀리는 과정에서 같은 에픽을 진행하는 팀원들에게 힘든 티가 났던 것 같아서 반성했다. 소통미스가 나서 폭풍야근을 하게된 것에 대해서 내심 서운한 마음이 있었던 것 같은데 얘기를 더 하다보니 일이라는게 여러명이 엮여있다보니까 소통미스가 났던 이유가 각자 있다는 생각이 들었고, 나 또한 다른 직군 동료들에게 불필요한 일을 늘려드린 부분도 있었던 것이다. 그걸 알게 되니 내면의 감정적인 부분이 내비쳐진게 (그러지 않으려고 노력은 했으나 잘 되지않았음) 프로페셔널 하지 못했다는 생각이 들어 반성이 되었다.

결론적으로 능동적 소통의 중요성을 크게 깨달은 4월이었다.

건강관리의 중요성

이제 진짜 많이 늙었다.. 라는 생각이 1년마다 새로이 갱신되는 것도 몇년째.. 이제는 올해가 그래도 남은 살 날 중에 가장 건강할 수 있는 날이라는 생각이 들어서 조금이라도 더 건강하게 늙어야겠다는 의식은 많이 하게 되는데 실천은 잘 안되는 것 같다.

술먹은 다음날 순환이 잘 안되는게 느껴져서 혈액순환에 좋다는 영양제를 먹고 자고 일어나도 피로가 잘 안풀리는거 같아 오쏘몰도 먹고 몸에 염증이 많아지니 염증에 좋다는 오메가3랑 장건강에 좋다는 유산균도 챙겨먹고 지병때문에 매일 복용하는 약도 먹고 이렇게 먹어야될 약이 하루에 20알 가까이 되다보니 도리어 잘 안챙겨먹는 날도 많아지는 식으로.. 5월에는 약을 더 잘 챙겨먹을 수 있도록 노력해야겠다.

그리고 4월 중순부터 바빠지면서 PT를 한달간 킵해뒀는데 5월엔 운동도 다시 열심히 다녀야겠다.

취미(?)와 또 다른 취미

4,5월에 롤이스포츠 비시즌이라 경기를 안가니 몸이 더 살 것 같다 라고 생각해서 오공완 챌린지에 들어갔는데, 일이 바빠져서 퇴근을 11시 이렇게 하니까 챌린지를 잘 참여하기 힘들었다. 실제로 마감시간 임박해서 사진만 남긴 날도 있고.. 1차 배포 나가고나니 맥이 탁 풀려서 배포 나간 주엔 3일이나 참여를 못했다... 돈도 돈이지만 현실적으로 4,5월에 토이프로젝트를 해야만 된다 라는 생각으로 참여했던 챌린지였는데 코드를 단 한 줄도 수정하지 못했다. 5월에라도 꼭... 작업을 할 수 있도록 노력해야겠다.

그리고 지친 몸과 마음을 위로하는 새로운 취미를 찾았는데, 친구의 영업으로 별 생각없이 세븐틴 콘서트에 갔다가 라이브도 너무 잘하고 퍼포먼스도 좋고 무엇보다 신곡이 좋아가지고 입덕하고 왔다. 세븐틴 신곡 마에스트로도 좋지만 보컬팀 신곡 청춘찬가도 진짜 좋아요 여러분 많이 들어주세요.

!youtube[-XqdJCl5Eus?si=8jnII-hXJsN_ZXVS]

건강한 몸에선 정신이 덜 힘들고 건강한 정신에서는 몸이 덜 힘들다

삶에 열정첨가를 위해 일 / 생활 / 취미의 밸런스가 중요하다고 생각하는데 취미가 하나 늘어서 6월에 시즌 개막할 생각하니까 약간 막막한 부분도 있지만, 원래 몸과 정신의 피로는 서로 벌충가능한 부분이 있는거니까 KT롤스터가 여름엔 제발 부디 꼭 정신차리고 좀 볼만한 경기력을 보여주시길 바라며 응원하는 수밖에...

뭐라도 남는게 있었으면 좋겠다

예전부터 블로그 바이오에 사용한 글귀는 1개의 계획을 세워서 1개를 실패하면 100% 실패하게 되는거지만 100개의 계획을 세워서 10개를 하면 10%는 성공한다는 인생 가치관에서 온 내용이다. 4월엔 뭐가 남았을까? 어쨌든 중요 에픽이 배포되었고 새 취미도 찾았다. 5월에도 뭔가가 남을 수 있도록 (이왕이면 토이프로젝트 완성/4월에 못한 에픽 하나라도 하기) 열심히 살아야겠다는 생각을 하며 회고를 마친다.

작성글 돌아보기

스터디 첫 날에 각자의 목적과 글쓰기 주제를 공유했는데 내 목적과 주제는 아래와 같았다. 사실 뭔가 성실한 글쓰기라고 하면 개발블로그를 써야했겠지만.. 사실 꾸준한 루틴 만들기 외에 숨겨진 목적으로 남들에게 도움이 되는 글쓰기가 있었는데, 일단 남에게 도움이 될만한 퀄리티의 글을 주 1회 쓰기는 어려울 것 같았고 생활블로그에서 리뷰 등을 올리는 것도 사람들에게 도움이 되는 글이라고 생각이 들어 주제를 이렇게 잡았었다. 목적 자체가 약간 모호한 목적이었기 때문에 내 스스로 정한 '도움이 됨'의 기준이 조회수였는데 나름의 성과가 있었다.

좋았던 점

생활블로그에 올렸던 티켓팅 꿀팁 글이 죽어가던 블로그치고 상당히 높은 조회수를 얻었는데, 다른 블로그 글들과 비교하여 다른 글엔 잘 없는 꿀팁들을 많이 상세하게 올렸고 중간중간 포스트 통계에서 검색유입 키워드를 확인하여 내용을 수정 보강하기도 하였다. 이런 노력이 보람이 있게 블로그 포스트중에 제일 많은 조회수를 기록하기도 했고, 댓글로 감사인사를 남겨주신 분도 계셔서 꽤 뿌듯했다 😁

아쉬웠던 점

한가지 아쉬운 점은 위에 티켓팅 관련 글 외에는 조회수가 평균적으로 저조한 편이라.. 네이버 블로그의 블로그 지수는 알고리즘 상 양질의 컨텐츠로 분류되는 글을 꾸준히 자주 올려야 올라가는 것으로 알고 있는데, 1-2주에 한개 3개월 게시한 것으로는 약간 부족했나 생각되었다.

스터디 돌아보기

글을 꾸준히 쓴다는 것이 쉽지 않은 일이기에 서로 강제성을 가질 수 있도록 글작성 누락 / 스터디 미참여에 각각 페널티를 부과하여 밥사기를 하는 스터디였는데, 중간에 작성글이 너무 길어지며 시간내 완성을 못하며 페널티를 받고 말았다. 다들 잘 진행하셔서 1회 페널티만으로 밥을 사게 되었지만... 다같이 좋은 습관을 3개월이나 끌고 갔다는 점이 좋았고, 또 중간에 미완성 됐던 작성글이 티켓팅 글이었어서 양질의 글을 쓰는데에는 시간이 좀 필요하구나를 더 절실히 느낀 경험이 되기도 했다.

좋았던 점

좋았던 점을 꼽자면 이 글 전까지 벨로그에 4개, 네이버 블로그에 6개 총 10개나 되는 글을 어쨌든 한번빼고 꾸준히 작성을 잘 했다는 점과 네이버 블로그쪽 글이 마음에 드는게 많았다는 점? 사람들이 리뷰를 볼 때 궁금해할만한 점 위주로 작성하려 했는데 나쁘지 않게 썼던 것 같다. 글 작성한 부분에 대해서 서로 피드백 하는 시간도 가졌는데 그로 인해서 어떤 부분을 더 보강해야겠다거나 이번주 글은 괜찮게 마무리 되었다는 기준점을 어느정도 가질 수 있어서 좋았다.

아쉬웠던 점

네이버 블로그쪽과 반대로 벨로그 글은 별로 만족스러운게 없었는데, 특히 토이프로젝트 시리즈의 경우 토이프로젝트가 완성되면 짠- 하고 개발 비하인드를 올리고 싶었는데 일단 기간 내 완성을 못했고, 그러면서 기간을 여름으로 미뤗는데 한번 미루고 나니 또 그 이후로 작업을 안하고 있어서 연재가 되지 않고 있는 부분이 스스로 가장 아쉽다. 이러다가 이제 6월 직전에 또 아니 시간이 이렇게 별로 안남았다고?!하고 부랴부랴 만들다가 미완될까봐 걱정인데 아무래도 4월부터는 LCK가 비시즌인만큼 남는 시간에 토이프로젝트 개발을 더 열심히 하고, 관련 글도 더 조리있게 적을 수 있도록 해봐야겠다.

글을 마치며

글쓰기 스터디를 진행하며 내 자신의 글에 피드백을 받는 부분도 정말 좋았지만 팀원들의 글을 보며 요새 이런 내용을 다루고 계시는구나 하고 각자의 관심주제를 볼 수 있어서 즐거웠고, 또 다같이 으쌰으쌰하고 글 안쓰는 걸 단속(?)하는 분위기가 형성되어 이탈자가 거의 없는 상태로 1분기를 마치게 된 것이 참 좋았던 것 같다. 2분기에도 다같이 열심히 해볼 수 있으면 좋겠다 🥰

코드리뷰란 좋은 코드를 작성하기 위해 서로가 논의하는 과정이다.

시니어 개발자들 사이에서 코드리뷰에 대한 호불호는 상당히 극단적으로 나뉘는 편이다. 전 회사에서 같이 일하던 시니어는 코드리뷰를 상당히 좋지 않게 생각하였다. 오늘은 그가 코드리뷰를 싫어하던 이유와 그로 인해 코드리뷰 없는 n년을 보내며 느꼈던 단점을 되돌아보며, 내가 코드리뷰를 좋아하는 이유와 코드리뷰때 중요하게 생각하게 하는 부분들을 공유하는 글을 적어본다.

서론

코드리뷰가 싫었던 그의 얘기

1년 정도 혼자 꾸려가던 개발팀에 새 개발자를 구하면서 내가 원하던 부분은 '개발에 대해 열정이 있고' '함께 페어프로그래밍이나 코드리뷰를 할 흥미가 있는' 개발자로, 이런 부분이 충족된다면 주니어여도 상관없다고 생각했었다. 그러던 중 대표를 통해 새로 오게 된 시니어 개발자는 나와 경력차이가 5배 이상 났다. 원래 임베디드 개발자로 오랜기간 일하다가 개인적 사유로 스타트업으로 이직하며 풀스택을 하게 되신 분이었고 명목상 '면접'인 첫 미팅자리를 가지게 되었다. 첫 만남에서 내가 원하던 조건에 관해 은근슬쩍 얘기가 나오자 그는 바로 손사레를 쳤다. 그리고 아주 짧은 시간 그가 코드리뷰를 싫어하는 이유를 풀어놨다.

1. 실력차이가 나는 사람간의 코드리뷰는 일방적이다.

앞서 말했듯이 함께 일했던 시니어는 나와 상당히 경력차이가 많이났다. 그는 실력차이가 나는 사람간에 코드리뷰를 진행하게 되면 경력이 더 긴쪽에서 짧은 쪽에 일방적으로 피드백을 하는 구조가 될 수 밖에 없다고 말했다.

그러나 사람은 익숙해도 항상 새롭게 깨달을 수 있는 부분이 있는 것이다. 코드의 해석이나 언어의 개념에 대해 사람의 주관이 들어갈 수 밖에 없는 부분이 있기 때문에 나는 경력차이가 있는 경우에도 서로 배울 수 있는 부분이 있다고 생각한다. 필자는 C언어 기초강의를 각각 다른 사람에게 5번이나 들었음에도 들을 때마다 생각해볼만한 부분이 있었다. 코드리뷰 측면에서 낮은 연차의 개발자가 경력이 많은 개발자를 상대로 할 수 있는 리뷰 내용이나 피드백이 상대적으로 빈약할 수는 있어도 실수가 있는 부분이 필터링 될 수도 있고, 저연차가 고연차의 코드를 봄으로써 팀 전체의 개발 실력이 향상되는 효과도 있다.

2. 코드리뷰로 인해 구현시간을 빼앗긴다.

모든 기업이 그렇겠지만 특히 스타트업이란 개발 기한에 쫓기는 경우가 많다. 빠른 MVP로 소비자의 반응을 살펴 빠르게 변모하는게 스타트업의 주요 로직이기 때문이다.

단순히 당면한 이슈들을 쳐내는데에는 코드리뷰로 소모되는 시간이 아깝게 느껴질 수 있다. 그러나 코드리뷰를 통해 실수를 줄이고 코드의 퀄리티를 향상함으로써 유지보수가 더 용이해지고 장기적으로 봤을 때 코드에 들이는 시간이 줄어들 수 있다.

3. 코드리뷰 시 알아야하는 도메인이 많아진다.

얘기를 할 때 서로 백엔드와 프론트로 업무를 나누기로 얘기가 됐는데, 코드리뷰를 하게되면 서로 작업하지 않는 부분의 코드도 파악해야하는 부분이 있고 본인은 프론트엔드 업무를 하기 싫으셨기에 업무가 확실히 분리되었으면 한다고 하셨다.

그러나 전 회사는 퇴사할 때까지 개발자 수가 많이 늘진 않았다. 결과적으로 그도 백엔드와 프론트를 둘 다 하게되었고, 나도 백엔드와 프론트, 앱을 전부 관리하게 되었다. 그 와중에 업무가 분담되어 특정 서비스 특정 플랫폼에 장애가 생기면 휴가 중에도 담당자가 무조건 업무를 봐야했고, 그 와중에 백엔드도 Node, Python으로 다양화되고 프론트로 Vue, React로 나뉘어 관리의 피로도가 하늘을 찔렀다. 언어를 통일하고 평시에 코드리뷰를 진행했더라면 서로 관리하는 서비스에 유사시에 훨씬 도움이 되었으리라는 점은 자명하다.

코드리뷰가 없을때 느꼈던 단점

내가 코드리뷰를 좋아하는 이유

위에 코멘트로 이미 내가 느꼈던 단점과 코드리뷰의 장점을 일부 설명했지만 다시 한번 정리해봤다.

1. 반복되는 문제점

코드에는 개인의 스타일이 들어가기 마련이다. 코드의 품질과 무관한 스타일도 있지만, 다른 사람과 비교하여 나쁘다는 걸 알기 전까지 반복해서 쓰는 안 좋은 습관도 분명 있기 마련이다. 예를 들어 나는 ~ 이런 안좋은 습관이 있었는데 코드리뷰를 통해 고쳤다. < 여기 뭐쓰죠 코드리뷰에는 서로의 코드 습관을 돌아보고 더 좋은 코드를 위한 논의를 통해 좋은 코드를 쓸 수 있는 힘을 얻는 효과가 있다. 개인의 개발실력 향상에 도움이 된다는 것이다. 이는 개인에게만 이점으로 작용하지 않고 팀 차원에서도 유지보수 공수를 줄이는 효과가 있다.

2. 통일성 없는 코드

1에서 얘기했듯 코드에는 개인의 스타일이 들어가기 마련이다. 다수로 구성된 개발팀에서 각기 코드를 작성하다보면 한 서비스의 코드인데도 중구난방이 되는 경우가 부지기수다. 코드의 다양성은 변수 및 함수 네이밍 같은 사소한 것부터 디렉토리의 구조 및 디펜던시 사용기준처럼 프로젝트 구성 단위에서까지 보여질 수 있다. 일반적으로 이를 해소하기 위해 각 팀마다 코드 컨벤션이 존재하고, 코드 포맷팅 툴과 린터가 존재하지만 그러한 것들이 모든걸 마법처럼 다 해결해주는 것은 아니다. 프로젝트의 초기 구성에서 포맷팅과 린팅 룰이 모두 세부적으로 짜여져 있는 회사가 얼마나 있을까? 이 때 그러한 부분에서 협의점을 찾고 규칙을 세우는 과정도 코드리뷰를 통해 이뤄질 수 있다. 그렇게 팀 내 규칙을 세부화해가면서 전체적 코드에 통일성을 갖게되면 직접 작업한 코드가 아니더라도 팀 내 누군가가 손대기 더 쉬운 코드가 되는 것이다.

3. 너무 높은 개인의 책임

서론에서 '코드리뷰란 좋은 코드를 작성하기 위해 서로가 논의하는 과정이다'라고 얘기했다. 이 문장에서 중요한 점은 '서로' 코드에 관여한다는 점이다. 코드리뷰없이 단독으로 작성되어 배포되는 코드는 별다른 검수과정을 거치지 않기에 실수가 발생할 확률이 더 높고, 안티패턴으로 짜여진 코드더라도 문제의식 없이 사용될 수 있다. 이 때 그러한 실수나 안티패턴으로 인해 서비스에 오류나 장애가 발생한다면 그것은 코드를 작성한 혼자만의 책임이 된다. QA과정을 통해 프로덕션에서 장애가 발생하는 것을 막을 수는 있겠지만, 개발자 입장에선 오류 발생 제보 자체가 심리적 피로가 된다. 꼭 오류나 장애로 이어지지 않더라도, 리뷰를 거치지 않는 경우 잠깐 신경을 못쓰는 것만으로도 코드의 품질이 낮아지기 쉽다. 이는 곧 유지보수 공수의 증가로 이어지고 본인의 코드 혹은 팀 내 다른 개발자의 코드를 리팩토링 하게 될 때에 해야될 업무의 크기가 크게 늘어나게 된다.

코드리뷰할때 생각하는 것

코드리뷰를 약 반년간 진행하며 중요하게 생각했던 부분을 글로 정리해봤다. 어찌됐든 코드리뷰를 진행하며 아직 멱살잡는 일도 없었고 개인적으로 도움도 많이 받았다고 생각이 들어 개인의 관점을 공유해본다.

1. 누구라도 수정할 수 있는 코드, 코드의 가독성

누구라도 수정할 수 있는 코드란 어떤 것일까? 한마디로 정의하자면 나는 '가독성이 좋은 코드'라고 말하고 싶다. 그럼 코드의 가독성은 어떨 때 좋아질까?

• 디렉토리 구조가 팀 내에서 주로 사용하는 구조로 되어있다. (디렉토리 규칙)
• 함수와 변수의 이름에 이미 그 의미가 들어있고 이름을 구성하는 단어들이 팀 내에서 해당 의미를 위해 많이 쓰는 단어들로 구성되어있다. (네이밍 규칙)
• 내부 로직이 너무 복잡한 함수나 여러 단계로 구성된 함수는 서브 함수로 쪼갠다. (함수 쪼개기)

등등 다양한 포인트가 있을 것이다.

어떠한 절대적 기준이 있는게 아니라 주관적 느낌이기 때문에 팀원간에 합의가 필요한 부분이다. 가독성이 좋은 코드는 직접 작업한 코드가 아니더라도, 혹은 직접 작업한 코드더라도 다시 봤을 때 코드를 파악하기 쉽다. 이런 코드는 유지보수가 비교적 용이하고 코드에 오류가 있더라도 쉽게 찾아낼 수 있다. 복잡한 코드는 코드의 문제를 파악하기 어렵게 만들어 유지보수 공수를 늘리고 다른 개발자가 코드에 조인하기도 어렵게 만든다. 이러한 점을 의식하여 코드리뷰를 할 때에 내가 보기에 가독성이 떨어진다고 생각되는 부분들을 얘기해서 팀 안에서 합의를 도출하고 그러한 합의점에 따라 통일성 있는 코드가 되도록 하자.

2. 통일성 있는 코드, 통일성 있는 코드리뷰

사람마다 코드를 작성할 때 중요하다고 생각하는 부분이 다를 수 있다. 그러나 개인의 선호만 반영한다면 작업자마다 너무 다른 코드가 나올 수 있다. 개인의 개성이 담기는건 좋지만 한 프로젝트 내에서 스타일이 너무 다를 경우 위에서 말한 코드의 가독성이 저해될 수 밖에 없다. 그렇게 되지 않도록 다양한 면에서 어느정도 팀의 컨벤션을 정해서 코드를 작성하는 것을 권장한다. 코드뿐만 아니라 코드리뷰를 할 때에도 통일성이 필요하다. A라는 PR에서는 컴포넌트 렌더링 시 삼항연산자를 쓰도록 리뷰했다가 B라는 PR에서는 논리연산자(&&)를 통해 렌더링하도록 리뷰하면 리뷰를 받는 입장에서는 리뷰에 일관성이 없다고 느낄 수 있다. 리뷰하기 전 구현방식이 갈릴 수 있는 로직이라면 스스로의 마음 속에서 충분한 근거를 찾아 선호방식을 결정한 뒤 리뷰하도록 하자.

3. 리뷰는 대화이다

코드리뷰를 할 때 이런 코멘트를 달아도 될까? 하는 고민을 해본 적이 있는가? 필자는 있다. 특히 나보다 경력이 높거나 코딩실력이 뛰어나다고 생각되는 개발자의 코드에 리뷰를 달 때는 더 조심스러워 지는 부분이 있을거라고 생각한다. 하지만 코드리뷰는 그저 '논의' 과정이다. 이 말인 즉슨 하는 말의 모두가 진실일 필요는 없다는 것이다. 이러이러한 방향이 더 좋지 않나요? 하고 코멘트를 다는 행위는 코드 작성자에게 그 부분에 대해 한번 더 생각해볼 수 있는 환기점을 주는 효과를 가진다. 실제로 그 방향이 더 좋거나 좋지 않더라도 코드를 선택하는 이유를 더 명확하게 하는 계기가 될 것이다. 코드를 단 입장에서도 원 작성자의 답에 따라 깨달음을 얻는 부분이 있을 수 있다. 또한 방향 제시가 아닌 그저 궁금증을 해소하는 코멘트도 괜찮다. 팀원 전체적으로 의문이 없는 코드는 더 좋은 코드가 될 것이고, 당장 이 코드에 도움이 되는게 아니더라도 내 지식의 증가가 추후 팀 코드의 방향성 통일에 도움이 된다는 긍정적 효과가 있다는걸 기억하고 열심히 얘기를 나누도록 하자. 코드리뷰를 받는 입장에서도, 설령 고연차의 피드백 멘션이 있더라도 모두 그렇습니다 하고 받아들일 필요는 없다. 본인이 납득할 수 있는 선까지 충분히 얘기를 나눈 후 더 좋은 코드라는걸 납득할 때 수정하거나 수정하지 않거나 하면 되는 부분이다. 리뷰를 받고 더 나은 코드가 되었다고 느낀다면 감사하는 마음을 표현하도록 하자.

4. 코드엔 정답이 없다 - 평가 X

코드엔 맞는 코드, 틀린 코드가 없다. '정답에 가까운' 코드가 있을 뿐이다. 이 얘기를 하는 이유는 코드리뷰를 할 때 '당연히 이렇게 해야지'라는 마음으로 해서는 안된다는 것이다. 인터넷의 많은 코드리뷰 후일담에서 서로 감정이 상하고 멱살을 잡는다는 얘기는 99프로 리뷰어나 피리뷰어의 태도의 문제일 것이다. '이 로직을 어떻게 이런식으로 짜?'라는 생각을 하는 순간 당신은 이미 감정싸움 유발자가 된다. 모든 코드는 그 코드를 짤 때 해당 개발자의 생각이 들어가있다. 만약 코드가 좋지 않다고 생각이 되더라도 코드에 대한 평가는 내려두고, 코드에 대해 안 좋다고 생각한 이유를 얘기하며 피리뷰어가 해당 코드를 그렇게 구현한 이유를 묻도록 하자. 안 좋다고 생각한 코드도 나름의 근거가 있을 수 있고, 혹은 해당 작업을 진행할 때 피리뷰어가 생각하지 못한 상황이 있을 수도 있다. 코드리뷰는 더 좋은 코드를 만들기 위해 서로 의견을 모으는 과정이지 남의 코드를 평가하는 과정이 아님을 명심하자. 마인드셋을 갖췄더라도 언어습관도 되돌아볼 필요가 있다. 리뷰코멘트를 작성할 때의 말투가 너무 거침없지는 않은지, 근거를 설명하지 않고 얘기하지 않는지 코멘트를 전송하기 전 작성 내용을 제 3자의 입장에서 한번 돌아보고 달도록 하자. 공격적으로 비춰질 수 있는 언어습관은 본인의 선량한 의도를 곡해받게 만들 수 있다.

5. 코드가 잘못됐지 내가 잘못된건 아니다

코드리뷰 진행 시 리뷰받는 내용이 너무 많으면 내 코드가 이렇게 개선해야 될 부분이 많구나 하고 기분이 다운될 수 있다. 그러나 코드가 잘못됐지 내가 잘못된 건 아니다. 리뷰를 하는 입장에서는 리뷰할 내용이 많으면 상대의 기분에 영향이 있을 수 있다는 걸 감안하고 말투를 더 조심스럽게 하는 노력이 필요하고 리뷰를 받는 입장에서는 피드백이 많고 간혹 내가 정말 잘못 작업한 부분이 있더라도 같은 실수를 하지 않는 방향으로 긍정적 마음을 갖도록 하자.

마무리하며

코드리뷰를 할 때는 내가 이 코드에 관여함으로써 책임이 발생한다는 생각으로 코드리뷰를 받을 때는 코드 작성에 도움을 받아서 감사하지만 결국 책임은 내가 져야한다는 생각으로 그렇게 하고 있는데 사실 나도 코드리뷰는 저년차라 잘하고 있는지 모르겠지만 개인적으로 도움이 많이 되었다 생각이 들어서 처음 코드리뷰를 하는 사람들에게 조금 도움이 될까 하고 글을 적어봤다. 이 글을 우리팀 막내 주니어님에게 바친다 ^.^

토이프로젝트를 진행할때마다 항상 공통적으로 느끼는 소회가 있다

'모든 작업은 생각보다 오래걸린다'

사실 머리로는 알고 있는 사실이기에 분명 미리 준비하는게 좋다는 것을 알면서도 마감이 눈앞에 보이기전까지 일을 미루는것이 파워P의 숙명인 것이다.

원래 이번 토이프로젝트는 2월 19일까지 끝내야 했던 작업이다. 2월 19일에 기념일이 있기 때문에 이를 축하하는 작업이라면 사실 일주일이라도 전에 작업을 끝내고 주변에 QA를 부탁해 2월 19일에 올리는게 정상적인 배포과정이었을 것이다. 그러나 일단 기능의 1차 완성이 2월 20일, QA를 거치지않아 실제 사용환경에서의 경험이 너무 불편했고, 무엇보다 그래픽을 온라인 리소스를 활용해서 사용했더니 전반적으로 픽셀아트로 구성되었음에도 불구하고 리소스마다 픽셀규격이 다르다던가, 시점에 따른 음영이 다르다거나 하는 이유로 그래픽이 너!무! 어색했다. 결국 2월 19일 기념일 축하를 포기하고 여름에 출시를 하기로 결정했다. 2월 15일에 뭔가가 있을거처럼 공지까지 올려놓고.... 출시를 취소한다는게 너무 무책임해서 죽고싶어졌지만 죽기에는 세상엔 할 일이 너무 많다

핑계없는 무덤없다

일단 준비기간에 아픈날이 너무 많았다. 본격적으로 준비를 하자고 생각했던 1월 중순부터 아프지 않은 날이 반도 되지 않아 그로인해 일정에 차질이 상당했다. 그리고 생각보다 일정이 짧아 디자인 협력이나 외주를 구할 수 없어 그래픽 작업에도 시간이 많이 들었다. 아이디어 단계에서 실제 구현을 하면서 마감기한 문제나 여타 이유로 변경된 기획도 너무 많았다. 이러저러한 이유로 약 일주일반 정도의 개발 기간동안 회사일을 마친 후 따로 작업하느라 밤샌날도 부지기수였는데도 결국 마감기한안에 출시가 되지 못하였다 💦

여름에라도 출시해야지...

당장의 마감을 포기했지만 여름에 출시하기 위해서도 사실은 지금부터 지속적으로 준비를 해나가야 할 것이다. 이에 이번 일에 대한 반성 및 지속 작업에 대한 계획을 작성하기 위해 이 글을 적게되었다. 지난글에서 정리했던 내용은 기획이라기엔 내용적으로 갖춰지지 못한 일종의 아이데이션이었다. 이번 글도 대략적 아이데이션이 되겠지만 본격적으로 시작하기전에 토이프로젝트 기획하는 방법에 대해서도 글을 한번 써봐야겠다는 생각이 들긴한다.

준비해야할 것

내용적으로 정리된 기획

저번 글에선 대략적인 아이데이션과 검토되지 않은 개발항목, 아주 대략적인 일정을 적었었는데 기획을 하기엔 너무 짧은 준비기간이었기에 실제 작업의 진행상황을 체크하거나 구체적인 기획을 통해 필요항목을 체크하여 디자인을 맡긴다거나 하는 부분이 불가능했다. 이번에는 마감을 미룬 김에 구체적으로 기획을 정리하여 디자인을 여유있게 맡기도록 한다. 시간은 돈이다. 마감에 임박해 맡기는 디자인은 일단 받아주는 곳도 잘 없지만 매우 비싸다.

일의 우선순위 정하기

코어한 기능을 먼저 기획 / 구현해야하는 것도 맞지만 외부의 서포트가 필요한 작업 (예를 들어 리소스를 모은다거나 디자인을 맡긴다거나)들은 어느정도 이상의 시간이 필요하다. 해당 시간 확보를 위해 밑작업을 먼저 하여 외부에 작업을 맡기고, 이후 혼자 개발 가능한 부분을 작업해야 할 것 같다.

생각해야할 부분

게임 외 항목 정돈하기

멀티유저 기능이라든가 기본적인 싱글플레이 기능도 시간때문에 타협했던 부분이 많아 어느 선까지 넣어야할지 정리를 잘 해야할 것 같다.

게임항목 정리하기

미니게임 10여개를 넣자고 생각했었지만 기한의 문제로 대대적으로 규모를 줄였었다. 게임의 가짓수도 줄였었지만 장르같은 경우에도 모듈로 갖다붙일 수 있는 캐쥬얼 보드게임류가 전부였다. 기한이 늘어난 만큼 최소 2주에 1개 이상 작업하겠다는 각오로 종류를 정리해야할 거 같다. 여름에 출시라고 해도 6월에 여름이 시작되는 점을 감안하면 남은 개발 기간은 3개월도 채 안된다고 봐야할 것이다.

디자인 항목 정리하기

비용이나 기간 부분에 있어 항목이 정리되어 있지 않으면 디자인 쪽에서도 일을 받아줄 수가 없다. 또한 항목이 정리되어 있어야 디자인 작업을 외주를 맡길지 커미션을 맡길지 협력으로 갈지 정할 수도 있기에 디자인 항목 정리가 늦어도 3월 안에는 되어야 할 것 같다.

생각 정리하기

머리속에 다양한 구체적인 생각이 있더라도 글로 적는 것은 또 다른 효과가 있는 것 같다. 구체적이고 지속적인 토이프로젝트 작업 진행을 위해 앞으로도 주간 작업에 대한 소회 글을 적어봐야겠다.

프로젝트 목적

특별한 날을 기념하기 위해, 많은 사람이 함께 즐길 수 있는 온라인 공간을 만든다.

프로젝트 내용 및 우선순위 구체적으로 정리하기

꼭 구현해야할 내용

• 미니게임 10개 붙이기: 시간관계상 공개된 코드를 수정하는 방식으로 시간을 단축한다.
• 미니게임 후보들
  • 코드확인 완료된 게임들
    • 테트리스
    • 스네이크
    • 2048
    • 지뢰찾기
  • 기간 내 구현 가능여부 확인 필요한 게임들
    • Flappy Bird
    • 인피니트 러너
    • 점프킹
    • 사과게임
    • 다른 그림 찾기
    • 숨은 그림 찾기
    • 반응 속도 테스트
    • 퀴즈게임
• 시나리오
  • 게임 10개를 깨면 넥스트 스테이지에 대한 질문이..?

    구현하면 좋을 내용

• 광장 기능
  • 웹소켓으로 실시간 캐릭터 기반 광장이 되면 좋겠지만 멀티플레이를 실시간 지원 시 접속자수 부하가 심할 것 같다. -> 소켓이 아닌 firebase RDB로 할 수 있을까?
  • 안될거같으면 아바타 + 실시간 채팅 기능으로 대체하기
• 전시회 기능
  • 기억에 남는 순간을 사진 + 코멘트로 받으면 좋을 것 같다 -> 구글폼 만들기

    부가작업

• 디자인 협력 구하기 > 이쪽이 큰일이다.....
  • 인게임 캐릭터
  • 홍보포스터
  • 앱 표지
• 사진 협력 구하기..?

개발 일정 짜기

• 총 기간: 1월 31일 ~ 2월 18일 (총 19일)

배포플랫폼 정하기

멀티유저 기능 유무에 따라 정해야 할 것 같다 공부 겸 NextJS기반으로 붙이면 좋을 것 같은데 일단 미니게임은 모듈식으로 붙여야할듯...

구체화 되는 부분이 있으면 이 문서를 계속 업데이트 해야겠다.

글쓰기가 어려운 당신에게

해당 포스트에서는 글쓰기에 관해 다음과 같이 두개의 항목으로 나누어 경험을 공유해주셨다.

1. 글을 써야 하는 이유와 계속 쓰기 위한 마인드셋
2. 구체적인 글쓰기 방법

포스트를 읽고 해당 내용을 내 입장에서 정리해보는 것이 꾸준한 글쓰기에 도움이 될 수 있을 것 같아 내 얘기를 돌아보는 글을 작성하게 되었다.

목차

본 글에서는 원글을 참고하여 다음과 같은 항목으로 나누어 개인의 경험을 회고해보고자 한다.

글을 써야 하는 이유와 계속 쓰기 위한 마인드셋

• 내 글쓰기의 역사
• 왜 글쓰기가 이어지지 않았을까?

  구체적인 글쓰기 방법

• 어떻게 하면 꾸준히 쓸 수 있을까?

내 글쓰기의 역사

SNS로서의 블로그

개발이라는 것을 아주 최초에 시작하던 2004년에는 사실 국내에 ‘블로그’라는 개념조차 희박하던 시기로 인터넷을 검색했을 때 나오는 자료는 전혀 없었다해도 과언이 아니다. 네이버 블로그 서비스 출범이 2003년 10월이니 이 시기의 인터넷 자료수는 수는 말할 것도 없다. 그렇기에 이 시기에는 개발자로서의 글쓰기에는 전혀 생각도 없었고 블로그란 일상 얘기를 올리는 일종의 SNS였을 뿐이다.

(2004년 올렸던 글들을 돌아보니 어렸던 내 말투에 소름이 쫙 돋았다)

개발 블로그의 시작

시간이 아주 조금 흐른 후 특성화고에 진학하여 처음으로 '개발자의 글'을 작성하게되었다. 아주 처음 작성한 글은 데이터베이스 수업 내용을 정리한 글이었다.

(처음으로 배웠던 DB는 MSSQL)

2007년에도 고등학생이던 내가 작성한 네이버 블로그의 C언어, 자바 기초 요약글에 나름 조회수가 나올 정도로, 인터넷 상 특히 국내에는 아직 정보 자체가 많진않았다.

취미생활 기록 + SNS

대학에 입학하고는 음주가무(?)를 즐기느라 바빴다. 블로그는 주로 취미생활을 기록하는데 쓰여졌다. 당시에 취미로 하던 것은 밴드 합주와 라이브클럽 이용이었다. 당시 좋아하던 밴드들의 정보를 취합해서 올리고, 라이브 감상 후기를 올리는 등 내용을 올리곤 했었다.

게으른 개발 블로그

시간이 꽤 흘러, 내가 대학에 입학해 술먹고 노는동안 세상이 많이 바꼈다. 넷상엔 이제 너무 많은 기초정보들이 있었고 그렇기에 그저 그런 수준의 글들은 힘을 잃었다. 당시에는 신기술 소개 및 아키텍처 소개에 대한 글들이 인기가 있던 것으로 기억한다. 국내에 한창 신기술들이 많이 유행하기 시작하던 시기였다. 시간이 더 흐르고 이제 사람들은 신기술에도 익숙해졌고, 각종 개발언어 및 프레임워크의 문서들도 상당히 견고해졌다. 해당 시기에는 당시 하던 대외활동때문에 반기마다 프로젝트 진행을 했었는데 할때마다 신기술을 이용했기 때문에 뭔가를 정리할 틈 없이 새 언어, 새 프레임워크를 익히는 데에 집중했기에 취미 포스팅도 거의 하지 않고 드물게 의무적 포스팅을 작성하곤 했다.

연간 개발 블로그

그 후엔 개발자로서 실력에 도움이 된다 생각해서 꾸준히 글쓰기를 해보자 생각하고 티스토리도 개설했다가, Github 블로그도 개설했다가, 네이버 블로그를 개발용으로 따로 팠다가 하면서 글 몇 개 작성하고 그만두기의 반복이었다.

(그나마 가장 글을 많이 작성했던 개발용 네이버 블로그)

일상리뷰 + 개발 블로그...?

글쓰기 스터디를 시작하고, "일주일에 한개이상 꾸준히 뭐라도 글을 쓰자" 는 목표가 있었는데 목표에 턱걸이로 일주일에 단 하나, 맛집리뷰만 적었다 (아직은...?)

왜 글쓰기가 이어지지 않았을까?

그동안의 세월을 회상해봤을 때 꾸준히 글을 쓰지 못한 가장 큰 이유는 글을 쓰려는 이유와 목적이 불분명했다는 것 같다.

이유와 목적 부족으로 인한 유인 부족

취미생활 기록이나 리뷰 글은 "기록"이라는 명확한 이유와 목적이 있었으나, 개발블로그의 경우 단순히 '개발실력에 도움이 될 것 같은 느낌'으로 시작했던 부분이라 글을 쓸 유인이 부족했던 것 같다.

목적별 난이도 차이

시기별로 살펴봤을때 목적별로 글 작성의 난이도가 달랐다.

개인 SNS - 쉬움 수업 정리 - 쉬움 취미생활 기록 + SNS - 쉬움 (게으른) 개발블로그 - 어려움 (더 게으른) 개발블로그 - 어려움 리뷰블로그 + 개발블로그 (예정) - 쉬움 + 어려움

취미생활 기록이나 리뷰 글은 작성시 사진이 많이 들어가고 사진을 바탕으로 글을 붙이는 구조이기에 쉽게 작성 가능했으나, 개발블로그는 형식이 자유롭고 내용물의 자유도도 높아 쉽게 글을 완성하지 못했다.

우선순위 낮음

글을 적는 것이 다른 업무나 취미생활에 우선순위가 밀리다보니까 글 작성이 하루 이틀 한달 두달 미뤄지고 점점 안쓰게 되었던 것 같다.

어떻게 하면 꾸준히 쓸 수 있을까?

글 작성 이유와 목적 찾기

과거에 막연하게 생각했던 '개발실력에 도움이 될 것 같은 느낌'은 사실 기술설명 포스트를 작성하면 조사하는 과정에서 어느정도 도움이 되는 부분도 있다고 생각하지만, 생소하거나 신기술이 아닐 경우엔 수요가 떨어질 수 있다. 또한 '개발실력에 도움이 될 것 같은 느낌'은 너무 모호한 내용으로 이를 구체적으로 생각해보기로 했다.

글쓰기를 하는 목적

• 타인과의 의사소통 과정에서 상대방이 이해하기 쉽게 표현할 수 있게 된다.
• 많은 사람들에게 도움이 되고 영향을 주는 컨텐츠를 생산한다.
• 기록을 통해 나중에 스스로를 되돌아볼 기회를 갖는다.

목적 달성을 위한 구체적 글쓰기 주제 탐색

• 많은 사람들에게 도움이 되고 영향을 주는 컨텐츠를 생산한다.
  • 리뷰블로그
    • 타인에게 도움이 될만한 정보를 제공하여 선택에 도움을 준다.
  • 개발블로그
    • 개인의 아이데이션 및 경험 공유로 타인의 의사결정과 가치관 확립에 도움을 준다.
• 기록을 통해 나중에 스스로를 되돌아볼 기회를 갖는다.
  • 리뷰블로그
    • 이용한 것을 기록화하여 추후 재사용할지 선택하는데 스스로 도움이 된다.
    • 리뷰를 모아보면 일상의 추억이 남는다
  • 개발블로그
    • 좋은 개발자는 좋은 가치관에서 나온다 생각하기에 스스로의 가치관 정리에 도움이 될 것 같다.
• 타인과의 의사소통 과정에서 상대방이 이해하기 쉽게 표현할 수 있게 된다.
  • 블로그 공통
    • 사람들에게 보여지는 글은 혼자 끄적이는 것보다 정제될 수밖에 없다. 정제된 언어로 의사를 표현하는 연습을 한다.
    • 온라인 게시를 통해 타인에게 직간접적 피드백을 얻는다. 직접적으로는 코멘트를 받을 수 있고 간접적으로는 조회수나 공감수를 통해 타인에게 인상깊게 다가왔는지 여부를 측정 가능하다.

목적에 맞추어 구체적으로 실천하기

난이도별 작성시간 할당

리뷰블로그가 개발블로그에 비해 작성시간이 짧으므로, 주마다 글쓰기에 특정 시간을 할당할 경우 개발블로그를 쓰는데 집중하고, 리뷰블로그는 여가시간에 작성할 수 있도록 조정하려한다.

업무에서도 작성하기

왜 글쓰기가 계속 이어지지 않았을까? - 우선순위 낮음 에서 깨달았던 것 처럼, 글쓰기를 여가시간에 수행하는 여가활동의 일부로 여길 경우 우선순위를 계속 낮추게 되어 점점 미루게 된다. 이에 블로그 작성에 사내 글쓰기 스터디를 통해 확보한 업무시간을 사용하였다. 또한 사내 위키 문서 등을 꾸준히 작성 / 업데이트하며 글쓰는 습관을 강화하도록 한다. 원글의 "글쓰기도 일의 일부다"와도 일맥상통하는 얘기다.

게시 후 통계기능 적극 활용하기

원글에서는 "의도적으로 피드백을 만든다" 를 권장했다. 해당 부분은 이미 글쓰기 스터디를 통해 어느정도 충족되는 부분이 있다고 생각된다. 나는 나아가서 좋은 글은 많은 독자의 선택을 받는다고 생각하기에, 통계기능을 적극 활용하여 글의 주제나 짜임새와 통계를 결부지어 어느정도 자체 피드백을 얻으려고 한다.

마치며

원글을 보며 글을 꾸준히 쓰기 위한 자아성찰과 목표 설정을 해보았는데, 사실 목표를 세운다는게 항상 실천으로 이어지지는 않는 터라 올해도 꾸준한 글쓰기가 쉽지 않을 수 있다. 그렇지만 작심삼일도 3일마다 반복하면 3일에 한번은 실천하는 사람이 되지 않겠는가? 중꺾마로 올해 조금 더 발전된 스스로가 되도록 노력해야겠다.

처음엔 VSCode 셋팅 문제라고 생각해서

• VSCode > Typescript: Select Typescript Version으로 워크스페이스 TS 사용확인
• VSCode 재설치

등을 해봤으나 dev서버 띄울때나 빌드시에도 동일 오류가 발생하는걸 확인해 VSCode 문제가 아니라는걸 알게되었다.

그 후 워크스페이스 셋팅을 확인했으나

• 워크스페이스 내에 @types/react 버전 확인
• 워크스페이스 내에 resolution 확인
• 타 기기에서 dev서버 구동 및 빌드 확인 등을 진행했을때 타 기기에선 문제가 발생하지 않는 것을 확인하여 워크스페이스 셋팅 문제도 아니라는걸 알게되었다.

포맷이라는 만능솔루션이 생각났지만 모바일 작업에 키파일 셋팅이 상당해서 다시 진행하기가 너무 귀찮아서 멘붕하고 있던 중 워크스페이스 상위 디렉토리에서 node_modules를 우연히 발견하여 해당 디렉토리에 ts가 설치된 것을 확인, 삭제했더니 오류가 사라졌다.

완전 뻘짓이었지만.. node_modules를 언젠가 내가 옮겼으니까 거기 있었겠지...? 나중에 또 반복할 수 있는 실수라고 생각해서 짧게 메모를 남겨둔다.

시간이 지나면 잊어버릴 것 같아서 면접 본 직후에 작성하는 후기라 결과는 알 수 없지만 이렇게 긴장한 면접은 처음이었다 싶을 정도로 긴장하고 시작한 면접이었는데 면접관 분들이 너무 친절하셔서 나중엔 긴장은 많이 풀렸던 면접이었다.

너무 쉬고싶지만 놓지고싶지 않은 회사

회사 마지막 1년은 사실 한달만 쉬고싶다는 생각을 매일해가지고 퇴사 결정 후 실업급여 나오는 반년정도 좀 쉬어야겠다 생각했다. PT해서 체력도 키우고 지병치료도 좀 하고 개인프로젝트도 좀 하고 그래서 당장 재취업은 딱히 생각이 없었다.

근데 평소 선망하던 당근마켓에 프론트엔드 채용공고가 올라온 걸 보게돼서

당근마켓이라면 내 열정을 불사를 수 있을 거 같다.. 재지원 텀이 6개월..? 붙을 자신은 없지만 어차피 쉴 거 떨어져도 6개월 쉬면서 준비해서 다시 시도해보면 그만이니 시도나 해보자

하고 서류 하루이틀만에 노션으로 후딱 해서 제출했다.

근데 그게 붙어버렸다 띠용...!

쇠뿔도 단김에 빼라

성격도 급하고 미뤄봤자 좋은 부분도 없으니까 가능한 면접일정 선택하는 표에서 가능한 빠른 시점부터 있는대로 좍좍 선택했다 월요일에 서류합격 통보를 받았고 선택은 수요일부터 꽤 여러날을 했는데 바로 돌아오는 수요일에 면접이 잡혔다. 화요일에 일정이 있어서 수요일부터로 했던거라 면접 준비할 시간도 거의 없었고..

애초에 뭔가 자신감도 없고 가고싶단 마음 하나만으로 지원했던거라 '잘보여야겠다'거나 '붙을 수 있다!!' 이런 마음보다는 (물론 잘 보이고 싶다고 딱히 아는 거 이상으로 보여줄 수 없는 부분이긴함...)

어쩔 수 없다 그냥 면접경험 쌓고 지원해봤다는거에 의의나 갖자..

하고 가벼운 마음으로 임하려고 했지만 평소에 너무 가고싶던 회사다보니까 긴장이 엄청 됐다 🫠 (오랜시간 긴장하고 있는것보다 차라리 빨리 해치운게(?) 다행일지도...)

간략한 면접내용

화상면접으로 진행된 1차 면접은 주로 기술적인 질문이 주를 이뤘는데, 이력서 상 서비스에 구현해본 내용에 대해서 어떤 방식으로 구현했는가, 트러블 슈팅 경험이 어느정도가 있는가, 구현할 때 고려하는 부분이나 특정 이슈가 있으면 어떻게 처리할 것 같은가 이런 실무적 부분에 대한 대응 위주로 질문을 주셨다. 면접 전에도 나는 깊이가 얕은 사람이라고 생각은 했지만 뭔가 면접 진행하면서 나 너무 깊이가 얕아서 슬프다 😥 생각이 들었다.. 그래도 면접관께서 너무 상냥하시고 대화도 잘 나눠주셔서 약간 될대로 되라 마인드가 돼서 편하게 면접 마무리 했던 것 같다.

Qué será, será

3-5일내에 면접결과를 메일로 말씀해주신다고 하셨다. 면접 후기들을 읽어봐도 1차 화상면접에서 떨어지신 경우가 많이 보였고, 스스로한테 자신이 없다보니까 솔직히 큰 기대는 없다.. 그래도 6개월 후에 재지원 할 수도 있으니까 그 때 참고하고자 짧은 후기를 남긴다.

신께선 항상 내게 가장 간절히 원하는 것은 주지 않으시고 괘념치 않는 것들은 분에 넘치게 주시는 것 같다. 나는 당근을 정말 가고싶을까? 그럼 떨어질수도.. 정말 쉬고싶나? 그럼 붙을수도.. 어느쪽이 되든 인생은 흘러갈테지만 너무 늦지 않도록 6개월 단디 잘 살아야겠지 중요한 것은 꺾이지 않는 마음, 그래도 내 인생에 되새길 수 있는 교훈과 행복을 주는 사람이 있어 행복하다.

인수인계를 해야하긴하지만 현재 남은 인력중에 인수인계를 받을만한 인원이 거의 없어서 아마 문서 정리정도로 다음주 초에 마무리 되지 않을까 싶다. 시원섭섭한 마음을 품은채 갑자기 주어진 시간

솔직히 마지막 1년간 번아웃이 너무 심했고 내후년전엔 꼭 이직하고 싶다는 마음이 있었어서 막연하게는 1년 내내 생각은 했었지만 실제 퇴사할 수 있게 될 수 있을지 몰랐어서 일단 가볍게 할일을 정리하며 마음을 정리하려 글을 적는다.

12월에 꼭 해야할 일

1. 집 치우기 (3일내)

지난 7년간 생활청소만 하고 이제는 누덕해진 집을 치우고 마음을 깨끗하게 정돈하자.

• 가구 당근하기
• 필요없는 물건 버리기
• 쓰레기 버리기
• 베란다 청소 (여건이 된다면)

2. 개인프로젝트 환경설정 (12월내)

개인적으로 만들고 싶던 것이 있는데 다뤄본 장르가 아니라 조금 시간이 걸릴 것 같다.

3. 퇴사 관련 회고록 작성 (12월말)

사실 이 벨로그에 작년에도 회고록을 적다가 임시저장만 3개하고 출간을 못했다. 뭔가 말이 길어지며 진정성이 떨어지는 것을 해결하지 못했기 때문에 올해는 허심탄회하게 마음 정리용 회고록을 써보고싶다.

4. 운동 등록

건강 문제로 살이 쪘지만 어쨌든 살이 쪄서 더 힘든 부분들도 있고, 체력이나 정신력의 문제도 있어 이번 쉬는 기간 꼭 제대로 운동해서 나이에 맞는 체력을 갖고싶다.

오랜만에 만나 어색한 여유

올해 일하는 내내 한달만 쉬고싶다고 생각해놓고 정작 이렇게 쉬게되니 10년만이라 조금 어색하지만 없을 때 아쉬워하지 않고 있을 때 즐기면서 그러면서도 시간을 그냥 흘려보내진 않도록 글도 커밋도 내 생활도 열심히 돌보는 휴식기를 보내야겠다.

- 작업환경
ubuntu 20.04
python 3.8

1. 인스턴스 생성

인스턴스 생성시 SSD용량을 32로 설정했었는데 한번 용량초과로 서버가 멈춘적이 있다. 설정 완료 후 KOBERT 모델을 사용하는 현재 디스크 용량은 약 20정도로 32면 충분해보이지만 만약을 대비해 약간 더 여유를 잡는 것이 좋을 것 같다.

2. ssh를 이용해 원격 접속

> ssh -i "KEYFILE.pem" ubuntu@EC2-ADDRESS

3. venv를 이용해 가상환경 설정

> sudo apt update
> sudo apt install python3.8-venv
> python3 -m venv environment

4. 필요 패키지 설치

> sudo apt install build-essential
> sudo apt install python3.8-dev

5. CUDA 드라이버 설치

> sudo apt-get install linux-headers-$(uname -r)
> sudo apt-key del 7fa2af80
> wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-keyring_1.0-1_all.deb
> sudo dpkg -i cuda-keyring_1.0-1_all.deb
> sudo apt-get update
> sudo apt-get install cuda

// GDS 기능 활성화를 원할 경우에만
> sudo apt-get install nvidia-gds 

6. 환경변수 설정

> vim ~/.bash_profile
export PATH=/usr/local/cuda-11.7/bin${PATH:+:${PATH}}
export LD_LIBRARY_PATH=/usr/local/cuda-11.7/lib64\
                         ${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
> source ~/.bash_profile

7. POWER9 설정

> systemctl status nvidia-persistenced
● nvidia-persistenced.service - NVIDIA Persistence Daemon
     Loaded: loaded (/lib/systemd/system/nvidia-persistenced.service; enabled; vendor preset: enabled)
     Active: inactive (dead)
> sudo systemctl enable nvidia-persistenced (if not enabled)
> sudo cp /lib/udev/rules.d/40-vm-hotadd.rules /etc/udev/rules.d
> sudo sed -i '/SUBSYSTEM=="memory", ACTION=="add"/d' /etc/udev/rules.d/40-vm-hotadd.rules

> sudo reboot

8. Python 패키지 설치

> source environment/bin/activate
> pip install wheel
> pip install mxnet
> pip install gluonnlp pandas tqdm
> pip install sentencepiece
> pip install transformers
> pip install torch
> pip install git+https://git@github.com/SKTBrain/KoBERT.git@master

9. 설정 후

GPU 수에 변경이 있을 수 있으므로 num_workers 등 파라미터 조정이 일부 필요할 수 있다.

ORM을 사용하는 여러가지 이유가 있겠지만 나같은 경우에 ORM을 사용하는 가장 큰 이유는 별다른 노력을 들이지 않고도 개발자간에 스키마 구조를 공유할 수 있다는 점을 가장 좋아한다. 전통적 방식으로 코드 상에서 DB를 쓰게되면 다른 개발자가 참여하게 됐을 때 스키마 구조 파악을 위해 DB를 조회해보거나 따로 첨부된 ERD를 확인해야하고, 사용된 쿼리도 어떤 내용인지 읽어봐야한다. ORM을 사용하는 경우 대부분 ORM 자체의 모델 정의 코드만 봐도 DB 구조를 알 수 있고, 해당 DB의 SQL 문법을 몰라도 코드상 어떤 쿼리를 하는 것인지 파악하기 쉽다. SQLAlchemy는 Python에서 대표적으로 사용되는 ORM 패키지라 선택하게 되었다.

Flask에서 SQLAlchemy 사용하기

Flask에서 SQLAlchemy를 사용할 땐 보통 Flask-SQLAlchemy를 많이 사용하는 것 같았다. 실제로 Flask 공식 문서에서도 Flask-SQLAlchemy를 소개하고 있다. Flask-SQLAlchemy를 사용하면 편리하게 연동 설정을 할 수 있지만 SQLAlchemy 버전을 1.0.10까지만 지원하고 있다. 출시되어 있는 SQLAlchemy의 최신버전은 2.0이므로 최신 버전 사용을 원한다면 직접 설정할 것을 권하는 바이다.

Alembic

내가 써봤던 ORM 툴들은 보통 migration 기능을 포함했었는데 SQLAlchemy의 경우 Alembic이라는 별도 패키지를 함께 써야한다고 한다. 모델을 수정할 때마다 일일이 따로 migration을 하는 일은 매우 성가신 일이기에 Alembic도 사용하기로 결정했다. (migration 기능은 모델을 정의하거나 수정할 때 변경내역을 저장하고 그에 맞춰 실제 DB에 적용해주는 기능을 말한다.)

Flask-Migrate

관련해서 검색해보다 보니 Flask, SQLAlchemy, Alembic을 한번에 설정해 사용할 수 있는 Flask-Migrate라는 패키지가 있어 이를 사용하기로 했다.

Flask-Migrate 공식 깃헙 사이트

Flask-Migrate 설치하기

pip를 이용해 Flask-Migrate를 설치해준다. Flask, Flask-SQLAlchemy, Flask-Script가 함께 설치된다. (기존에 설치되지 않았을 경우) MySQL을 이용할 예정이므로, Mysql connector인 mysqlclient도 설치해준다.

$ pip install Flask-Migrate
$ pip install mysqlclient

DB 연결 설정하기

app.py 혹은 Flask 메인파일에서 DB 연결을 설정해준다. 이 때 보안을 위해 DB 정보는 별도 파일에 작성 후 .gitignore에 등록하여 업로드를 막도록 하자.

app.py

from flask import Flask
from flask_sqlalchemy import SQLAlchemy
from flask_migrate import Migrate
from models import db    # 아래에서 작성
from config import DB_USERNAME, DB_PASSWORD, DB_HOST, DB_NAME, DB_PORT

app = Flask(__name__)
app.config['SQLALCHEMY_DATABASE_URI'] = f'mysql://{DB_USERNAME}:{DB_PASSWORD}@{DB_HOST}:{DB_PORT}/{DB_NAME}'

db = SQLAlchemy(app)
migrate = Migrate(app, db)

config.py

DB_USERNAME = 'USERNAME'
DB_PASSWORD = 'PASSWORD'
DB_HOST = 'localhost'
DB_NAME = 'DBNAME'
DB_PORT = '3306'

DB 초기화하기

코드 작성 완료 후 아래 명령어를 통해 실제 DB를 생성하거나, 이미 생성된 DB의 경우 migration을 활성화 해준다.

$ flask db init

정상적으로 실행될 경우 아래 이미지처럼 migrations 디렉토리가 생성되고 하위에 다음과 같은 파일들이 생긴다. versions 디렉토리는 migration 파일들을 생성한적이 없으므로 비어있다.

모델 작성하기

테이블과 맵핑될 모델을 작성해준다.

app.py

from flask_sqlalchemy import SQLAlchemy

...


db = SQLAlchemy(app)
migrate = Migrate(app, db)

...


class Post(db.Model):
    __tablename__ = 'blogposts'

    id = db.Column(db.Integer, primary_key=True)
    title = db.Column(db.String(120))
    content = db.Column(db.Text)
    date = db.Column(db.DateTime)
    tag = db.Column(db.String(120))
    cover = db.Column(db.String(120))

    def __repr__(self):
         return '<Post: %r>' % (self.title)

migration 생성하기

작성한 모델을 토대로 아래 명령어를 통해 migration version 파일을 생성해준다.

$ flask db migrate

주의점

• 공식 문서에서는 db init시 데이터베이스가 없을 경우 생성해준다고 나와있지만 실제로 해보니 DB를 따로 만들어두지 않으면 (1049, "Unknown database 'mayacrew'") 라는 오류와 함께 실행되지 않았다.
• MySQL User permission이 부족할 경우에도 Permission Denied 오류로 실행되지 않으니 확인 후 설정해주도록 하자.

문제없이 실행되면 다음과같은 로그가 뜬다. 모델과 기존 DB의 차이를 확인하여, migrations/versions 하위에 파일을 생성한다. 파일을 확인해보면 upgrade시 해당 컬럼들을 가진 테이블을 생성해주고 downgrade하면 해당 테이블을 삭제해주는 것을 볼 수 있다.

cc59fedc5e62_.py

"""empty message

Revision ID: cc59fedc5e62
Revises: 
Create Date: 2022-01-04 15:05:05.135042

"""
from alembic import op
import sqlalchemy as sa


# revision identifiers, used by Alembic.
revision = 'cc59fedc5e62'
down_revision = None
branch_labels = None
depends_on = None


def upgrade():
    # ### commands auto generated by Alembic - please adjust! ###
    op.create_table('blogposts',
    sa.Column('id', sa.Integer(), nullable=False),
    sa.Column('title', sa.String(length=120), nullable=True),
    sa.Column('content', sa.Text(), nullable=True),
    sa.Column('date', sa.DateTime(), nullable=True),
    sa.Column('tag', sa.String(length=120), nullable=True),
    sa.Column('cover', sa.String(length=120), nullable=True),
    sa.PrimaryKeyConstraint('id')
    )
    # ### end Alembic commands ###


def downgrade():
    # ### commands auto generated by Alembic - please adjust! ###
    op.drop_table('blogposts')
    # ### end Alembic commands ###

migration 적용하기

upgrade 명령어를 통해 실제 DB에 적용해준다.

$ flask db upgrade

다음과 같은 로그가 뜨면 적용 완료된 것이다.

실제 MySQL workbench에서 확인해보면 테이블이 잘 생성된 것을 볼 수 있다.

migration 버전은 DB내 alembic_version 테이블을 통해 관리된다. upgrade를 적용할 때 마다 테이블에 최신 revision id가 저장되고, downgrade 할 경우 migration 파일의 down_revision 변수에 저장된 이전 revision id가 저장된다.

마치며

Flask-Migrate 사용법을 공식 문서를 참고하여 간단하게 익혀봤다. 실제 사용할 때에는 model 코드와 view 코드, 설정 코드 등등 다양한 내용을 한 파일에 다 때려박으면 유지보수가 불편하기 때문에 파일 구조를 나눠서 사용해야 할 것 이다. 해당 내용은 스택오버플로우와 github issue를 참조하려고 한다. 원래 이 포스트에 함께 쓰려고 했는데 글이 너무 길어진 것 같아 참조 링크만 남기고 여기서 줄인다.

설치하기

맥에는 homebrew라는 패키지 관리자가 있어 쉽고 편하게 패키지들을 관리할 수 있다. 맥에 기본적으로 되장되어 있는 패키지 매니저는 아니기 때문에 따로 설치해주어야 한다.

https://brew.sh/index_ko homebrew 공식 홈페이지에 자세한 설명이 나와있다.

homebrew를 이용해 mysql을 설치해보자

$ brew update
$ brew install mysql

설치가 완료되면 다음과 같은 안내문들이 나온다. 설치가 되었고, 기본적으로 localhost에서만 접속이 가능하며 root 계정의 패스워드가 지정되어 있지 않으니 보안을 위해서 비밀번호 설정을 하라는 얘기

We've installed your MySQL database without a root password. To secure it run:
    mysql_secure_installation

MySQL is configured to only allow connections from localhost by default

To connect run:
    mysql -uroot

To restart mysql after an upgrade:
  brew services restart mysql
Or, if you don't want/need a background service you can just run:
  /usr/local/opt/mysql/bin/mysqld_safe --datadir=/usr/local/var/mysql

설치 확인을 위해 버전 체크를 해보았다.

$ mysql --version
mysql  Ver 8.0.27 for macos11.6 on x86_64 (Homebrew)

root 계정 비밀번호 변경

권장하는대로 mysql_secure_installation을 입력해보면 다음과 같이 root계정 패스워드를 지정할 수 있다.

Securing the MySQL server deployment.

Enter password for user root: 

비밀번호를 지정하지 않고 접속했을 경우 따로 지정해줄 수 있다. (MYSQL5에선 비밀번호 변경 방법이 다르므로 버전을 먼저 체크하자)

 mysql> alter user root identified with mysql_native_password by 'PASSWORD';

alter user 구문의 경우 CREATE USER 또는 mysql 시스템 DB에 대한 UPDATE 권한이 필요한데, 이들은 global 권한으로 SUPER 권한이기 때문에 일반유저로 접속 시 사용하는 것은 권장되지 않으며 root계정에서 실행하는 것이 좋다. 일반유저로 실행시 기본적으로 access denied 오류와 함께 실행되지 않으며 grant를 이용해 권한을 설정해주어야 사용가능하다.

사용자 생성 및 권한 설정

데이터의 안전한 사용/관리를 위해 root계정으로 mysql을 이용하는 것 보다는 특정 서비스 데이터를 관리할 계정을 생성해서 사용하도록 한다.

// 비밀번호가 지정되어 있지 않을 때
$ mysql -u root
// 비밀번호가 지정되어 있을 때
$ mysql -u root -p DBNAME(optional)
Enter password:PASSWORD

mysql> create user 'USERNAME' identified by 'PASSWORD';
mysql> select user, host from mysql.user; //mysql DB의 user테이블에서 새로 생성된 유저 정보 확인

mysql> alter user USERNAME identified by 'PASSWORD'; // root에서 USERNAME 계정 비밀번호 변경
mysql> alter user current_user() identified by 'PASSWORD'; // USERNAME 계정 자체 비밀번호 변경

생성한 USERNAME 계정에서 특정 DB에 접근할 수 있도록 권한을 준다. 이 때 생성된 USERNAME에는 특정 DB에 권한을 지정할 수 있는 권한이 없으므로 root계정에서 실행한다. 권한을 줄 당시에 DBNAME이라는 DB가 실제 존재하지 않아도 괜찮다.

mysql>  grant ALL PRIVILEGES on DBNAME.* to USERNAME 

권한을 지정해줬으면 해당 USERNAME으로 접속하여 DB 사용이 가능한지 테스트한다.

mysql> create database DBNAME;
Query OK, 1 row affected (0.01 sec)

이번 휴가때 평소 눈여겨보던 유기견 보호단체의 민간단체 신생설립을 위해 법적으로 필요하다는 단체 홈페이지를 만들 사람을 구하고 있기에 냉큼 지원했다. 신생 민간단체이고 아픈 유기견 위주로 구조 / 치료 활동을 진행하기에 항상 후원을 필요로 하고 돈이 쪼들리는 단체다보니 서버비용을 최대한 아껴야만 했다. 어쩔 수 없이 구식 웹호스팅 업체를 찾았다. php 7.0이 지원된다고 해서 이번 기회에 라라벨을 써볼까 설레는 마음으로 쓸 수 있을 방법을 한참 찾아봤지만, ssh조차 지원하지 않는 웹호스팅 업체였기에 과감하게 포기하고 구식으로, 10년도 전에 처음 웹을 만들던 기억을 되살리며 개발을 해보고 있다. 개발하다보니 static 파일들까지 생으로 다 파일관리 해가며 작성하기엔 좀.. 유지보수가 너무 안될 거 같아서 sass를 적용했다. 그런데 사이트 개발을 하다보면 역시, 스타일시트도 길고 복잡해질 수 밖에 없고 파일 한두개로 작업하기에는 수정에 숱한 시간을 쓸 수 밖에 없기에 파일이 점점 늘어났다. 처음엔 sass로 디렉토리 전체를 빌드하는 방식을 써봤는데, 결과물 css파일이 너무 많아서 일일이 가져다 쓰기엔 성능상이나 편의상이나 무리라고 생각되어 static 파일 빌드에 사용해봤던 gulp를 떠올리고 적용하게 되었다. 오랜만에 쓰려니 gulpfile 작성하는데도 서치를 좀 해야됐다. 사실 gulp를 또 쓸 일이 있을까? 최근에 react 혹은 react-native 위주의 작업만 진행해서 gulp를 마지막으로 쓴지 최소 6년은 넘은 것 같다. 요즈음의 프론트엔드 개발이 framework 위주로 돌아가거나, vanila js로 작업하더라도 webpack을 주로 사용하기에 gulp도 사실 조금 시대가 지난 툴이라고 볼 수 있다. 다시 볼 일이 있을지는 모르겠지만 블로그를 해보자고 최근에 마음 먹었기에 이 글을 써본다.

gulp 사용절차

1. gulp 설치

gulp는 nodejs 기반 툴이기에 npm으로 설치 가능하다. 커맨드라인 사용을 위해 gulp-cli도 함께 설치해준다.

npm i -g gulp-cli
npm i --save-dev gulp

2. 필요 패키지 설치

내 경우엔 sass 관련 패키지들과 파일들을 합쳐주는 concat 패키지, css minify 및 optimizing을 위한 clean-css 패키지를 설치했다. (사이트가 구식이다보니 아직 js가 들어간 페이지가 없다. 있다면 나중에 uglify 패키지를 추가할 듯..)

npm i --save-dev sass gulp-sass gulp-concat gulp-clean-css

3. gulpfile 작성

현재 스타일시트 관련 디렉토리 구조는 다음과 같다.

공용으로 사용되는 스타일들은 common 디렉토리에, 그 외 페이지별 파일들은 상위 디렉토리에 있다. 각 파일별 내용이 길지 않아서 네트워크 요청을 줄일 수 있도록 전체를 하나의 파일로 합쳤다.

const gulp = require("gulp");
const sass = require("gulp-sass")(require("sass"));
const concat = require("gulp-concat");
const cleanCss = require("gulp-clean-css");

gulp.task("build-css", function () {
  return gulp
    .src("styles/*.scss") // styles 하위의 파일들을
    .pipe(sass().on("error", sass.logError)) // sass로 빌드한 후
    .pipe(concat("index.css")) // index.css 라는 하나의 파일로 합치고
    .pipe(cleanCss({ compatibiliy: "ie8" })) // minify 해준 후
    .pipe(gulp.dest("styles")); // styles 디렉토리에 저장
});

gulp.task("default", gulp.parallel("build-css"));

gulp.task("watch-css", function () {
  gulp.watch(
    ["styles/*.scss", "styles/common/*.scss"],
    gulp.series("build-css")
  );
});

저번 주말에 작업을 맡기로 했는데 단체 설립을 서두르고 싶다며 이번주안에 작업을 끝내달라 하신 단체장님;; 어차피 후원 관련 기능은 단체설립을 해야 CMS 등 계약이 가능하기에 일단 기능들을 최대한 빼고 완성을 목표로 작업중인데 기획도 디자인도 없이 혼자 맨땅에 헤딩하려니 골치아프다.. 그렇지만 크리스마스를 즐길 수 있도록 일단 낼까지 노력해보기.. 안되면? 죄송한데 시간이 너무 촉박해서 일주일 더 기다려주셔야 될 것 같아요 시전해야.. 😂