신입 개발자의 인프콘2022 참가 후기 - 에잇퍼센트 공식 블로그

0. 들어가며

안녕하세요! 8퍼센트의 프론트엔드 개발자 김민정, 조승희입니다.

지난 8월 26일, 11.5:1의 경쟁률을 뚫고 인프콘에 참가할 기회를 얻게 되었습니다. 신입 개발자로서 처음인 IT 컨퍼런스인 만큼, 설레는 마음으로 오프닝부터 클로징까지 열심히 참가하였습니다.

인프런 슬로건인 배우고 나누고 성장하세요(Learn, Share, Grow)에 알맞게 다양한 세션들과 이벤트를 만나볼 수 있었는데요. 인프콘을 참가하여 얻은 지식과 느낀 점들을 나누고자 합니다.

1. 세션

① 우리는 오늘도 성장합니다. (장우현, 인프랩)

인프랩 장우현 개발자님께서 ‘업무 프로세스의 발전 과정’에 관해 세션을 진행해주셨습니다. 기존 애자일 방식에서의 프로젝트 QA 기간 산정에 대한 어려움을 인프랩에서는 어떤 방식으로 해결하게 되었는지에 대해 알 수 있었습니다.

인프랩과 8퍼센트를 포함한 많은 스타트업 기업들이 애자일(Agile) 방식으로 프로젝트를 진행하고 있으실 텐데요. 애자일은 사전적으로 ‘날렵한’, ‘민첩한’이라는 의미입니다. 기존 워터폴(Waterfall) 방식이 문서와 계획에 중점을 두었다면 애자일은 변화에 대한 대응을 중심으로 고객에게 실행할 수 있는 소프트웨어를 제공하는 것에 가치를 두고 있습니다.

애자일 방식으로 프로젝트를 진행할 때 애초에 산정한 QA 기간을 초과하는 경험이 있지 않으신가요? 우측 그래프처럼 프로젝트 기간에 비례해 이슈가 누적되며 발생하는 현상입니다. 이를 해결하기 위해 인프랩에서는 QA를 스프린트 별로 진행하며 극복하고자 한 경험을 공유해 주셨습니다.

인프랩의 스프린트 일정 (1주)

월: 스프린트 플래닝 (업무, 리소스 파악)
화 ~ 수: 개발
목 ~ 금: QA

QA를 스프린트 별로 실행했을 시 이슈는 좌측 그래프처럼 균일하게 증가하게 됩니다. 이에 따라 개발자는 프로젝트 기간을 예측하는 데 있어 도움을 받을 수 있습니다. 하지만 인프랩에서는 해당 스프린트의 단위가 한 주이기 때문에, 체력 관리나 물리적인 코딩 시간의 부족 등 고민할 부분이 발생하게 되었습니다. 이를 해결하기 위해 회의록을 미리 작성하는 등 업무 프로세스를 효율적으로 발전시키기 위한 인프랩 분들의 노력은 계속 진행 중입니다.

8퍼센트에서의 업무 프로세스, 어떻게 진행될까?

8퍼센트 플랫폼 그룹은 현재 2주 단위의 스프린트로 프로젝트를 진행하고 있습니다. 먼데이닷컴이라는 도구를 사용하여 각 팀별 로드맵(장기적인 목표 및 업무 카테고리)을 정의하고, 해당 로드맵에 해당하는 업무 아이템들을 산정하여 스프린트 동안 진행합니다.

데일리 스탠드업 미팅(stand-up meeting)에서는 이번 스프린트에 맡은 업무가 얼마나 진행되고 있고, 어떤 부분에서 어려움을 겪고 있는지 공유하고 있습니다. 고민하는 부분들이 팀원들과의 소통을 통해 그 자리에서 결정되기도 합니다.

스프린트 마지막 날에는 다 같이 해당 스프린트에 각자가 느낀 점에 대해 회고하고, 다음 스프린트 플래닝을 하는 별도의 시간이 있습니다. 그 외에도 개인이나 팀이 공유하고 싶은 지식이나 프로젝트에 대한 설명이 있다면 데모를 진행합니다.

스프린트 주기마다 QA를 진행하게 된다면, 프론트엔드 분야에서도 놓치거나 변경되는 UI 디자인 및 기획에 의한 이슈를 주기적인 피드백을 통해 점진적으로 해결할 수 있다고 생각합니다. 그에 따라 신뢰도 높은 기간 산정을 할 수 있는 점은 분명 매력적입니다. 기간 산정에 대한 어려움을 겪고 있다면 프로젝트 구성원들과 협의하여 주기적인 QA 진행을 시도해 보면 좋을 것 같습니다.

by 김민정

② 운영중인 Vue.js 웹서비스를 타입스크립트로 다시 쓰기 (장기효, 네이버)

다음으로는 네이버의 장기효 개발자님(캡틴판교님!)께서 Vue.js 프레임 워크로 구현된 웹 서비스를 Typescript로 다시 구현하며 얻은 경험과 지식을 공유해 주셨습니다. 기존 Javascript로 구현된 소스 코드에는 Typescript가 점진적으로 적용이 불가하다고 판단 되었기에, 점진적으로 도입하는 방식이 아닌 별도의 신규 Vue.js 프로젝트 환경을 구성한 경험이었습니다.

기존 소스 코드(Javascript)의 버그 수정을 위해, 신규로 작성된 코드(Typescript)를 타입만 제거하여 역으로 기존 코드에 병합을 시도하는 등 참고할 만한 방법들이 많았습니다.

8퍼센트 웹 프론트팀의 Typescript 도입

현재 8퍼센트 웹 프런트 팀에는 Javascript로 작성된 Vue 프로젝트에 점진적으로 Typescript를 도입해 나가는 단계입니다. 현재 API나 상태관리를 포함한 모든 .js 파일들은 모두 .ts 파일로 변환되었으나, 모든 SFC(.vue)들이 Typescript를 사용하고 있지는 않습니다.

이처럼 프로젝트 볼륨이 클수록 짧은 기간 내에 모든 Javascript 파일을 Typescript로 변환하기는 어려울 수도 있습니다. 전체가 아닌, 점진적으로 변환을 시도할 시에도 해당하는 지식을 공유해 주셨습니다.

Javascript 환경에서는 JSDoc 활용하기

JSDoc이란 Javascript 환경에서 소스 코드에 대한 설명을 제공하는 API 문서 생성기입니다. 소스 코드와 함께 주석 형태로 작성되며, Javascript가 지원하는 기능이기 때문에 Typescript와 달리 컴파일 단계가 없습니다. 그에 따라 Javascript 환경에서 해당 코드의 타입 정보를 제공할 수 있다는 장점이 있습니다.

/**
 * 함수의 역할이나 추가 정보를 기재합니다.
 * @constructor
 * @param {string} name - 이름을 의미합니다.
 * @param {number} [age] - 나이를 의미합니다. 필수 값이 아닙니다.
 * @param {boolean} [hasCat] - 집사 여부를 의미합니다. 필수 값이 아닙니다.
 */
function nameAndOptionalInfo(name, age, hasCat) {
  // ...
}

JSDoc 공식 페이지에서 @constructor, @param 외에도 @type, @readonly, @example 등 다양한 블록 태그와 예시를 확인할 수 있습니다. 이처럼 Javascript 환경에서 소스 코드의 타입 정보를 제공하고 싶지만 Typescript를 당장 도입하기 힘든 상황이라면, API 또는 비즈니스 로직같이 중요도가 높은 코드부터 JSDoc을 통해 효율적으로 타입을 도입할 수 있습니다.

Typescript와 Javascript의 공존을 위해 allowJS 사용하기

Typescript를 도입할 준비가 되었다면, typescript 및 @types 관련 library를 추가합니다. 다음으로 타입스크립트 설정 파일인 tsconfig.json을 아래와 같이 작성합니다.

// tsconfig.json
{
  "compilerOptions": {
    "allowJs": true, // `.ts` 파일 내에서 `.js` 파일이 import 되는 것을 허용
    "target": "es5",
    "outDir": "./dist",
    "moduleResolution": "node",
    "lib": ["ES2015", "DOM", "DOM.Iterable"]
  },
  "include": ["./src/**/*"],
  "exclude": ["node_modules", "dist"]
}

"compilerOptions" 항목의 "allowJs": true 옵션은 .ts 파일 내에서 .js 파일이 import 되는 것을 허용하는 것을 의미합니다. 이를 통해 기존 Javascript 코드 베이스에서 Typescript를 도입할 수 있는 환경을 구축할 수 있습니다. 세션을 진행해주신 장기효 님이 작성하신 글에 더욱 자세히 나와 있으니 참고하셔도 좋습니다.

by 김민정

③ 인프런 아키텍처의 과거와 현재, 그리고 미래 (이동욱, 인프랩)

인프런의 CTO 이동욱 님의 세션입니다. 최근 8퍼센트에도 아키텍처 변화가 생겨 아키텍처에 대한 관심이 생기기 시작했는데요. 그래서인지 더욱 기대가 가는 세션이었습니다. 인프런 아키텍처의 과거부터 현재까지 어떻게 발전해왔고 미래에는 어떤 아키텍처를 그리고 있는지 공유해주셨습니다.

세션을 듣기 전엔 ‘아키텍처’라는 단어의 무거움 때문에 내용이 어렵지는 않을까 걱정했었습니다. 하지만 아키텍처 변화를 시간대별로 풀어서 설명해주신 덕분에 쉽게 이해할 수 있었습니다. 그 당시의 아키텍처는 어떤 문제점을 가지고 있었는지, 그 문제점을 어떻게 해결하려고 했는지를 중점으로 진행된 세션이어서 특정 기술에 대한 배경지식 없이도 공감할 수 있었습니다.

다음과 같은 내용이 공감이 가고 인상에 남았는데요.

“스타트업에서의 6개월은 일반 기업의 2년에 준한다”
“기술의 가짓수를 최소화하고 가장 좋은 아키텍처/기술보다는 2~3년 버틸 수 있는 적절한 아키텍처/기술을 선택한다”
“점진적 개편을 통해 팀원들에게 서비스를 중단 없이 개편하는 선물을 하고 싶었다”

한정된 자원을 가지고 있는 스타트업의 적정 아키텍처에 대한 고민을 엿볼 수 있었던 세션이었습니다.

8퍼센트의 아키텍처 변화

8퍼센트 개발자들도 상황에 맞는 적정 아키텍처를 구성해왔습니다. 이전까지는 모든 개발자가 풀스택으로 작업을 해왔기 때문에 프론트엔드와 백엔드가 결합한 형태로 하나의 레포지토리에 존재했었습니다. 그러다 8퍼센트가 빠르게 성장하고 조직이 변화하면서 당시에는 적정 아키텍처였던 것들의 문제점을 느끼기 시작했습니다. 프론트엔드와 백엔드가 종속된 형태를 가지게 되면 아래와 같은 문제점이 있습니다.

백엔드 없이 프론트엔드 어플리케이션을 단독으로 실행할 수 없음
불필요한 reload, build, 배포 프로세스로 인한 개발 생산성 저하
의존성으로 인한 프론트엔드 기술 스택 전환의 어려움

이를 해결하기 위해 프론트엔드 분리를 결정했습니다. 입사 후 프론트엔드 분리에 필요한 CI/CD 작업과 정적 웹 서버 인프라를 구축하는 일을 진행할 수 있어서 많은 것을 배울 수 있었는데요. 올해 7월, 성공적으로 분리가 완료되었습니다. 이제 프론트엔드는 종속성에서 벗어나 적정기술로 빠르게 전환할 수 있는 독립성과 유연한 확장성을 가지게 된 것입니다.

하지만 여전히 백오피스 프론트엔드를 포함한 일부 서비스가 분리를 필요로 하고 있는데요. 아직까지는 숙제로 남겨둔 상태입니다. 성장하고 있는 8퍼센트는 현재 조직에 맞는 적정 아키텍처를 구성하기 위해 계속해서 노력하고 있습니다.

by 조승희

④ 개발자의 셀프 브랜딩 (김민준, 리디)

개발자들을 위한 블로그 서비스 velog의 개발자인 벨로퍼트님의 세션입니다. 주니어 프론트엔드 개발자라면 모르는 분이 없으실 정도로 프론트엔드 분야에서 책과 강의 활동이 활발하신 분이신데요. 셀프 브랜딩이라는 주제에 딱 맞는 발표자가 아닐까 생각이 들었습니다. 많은 활동과 경험을 하신 만큼 다양한 내용을 공유해주셨습니다.

세션을 통해 셀프 브랜딩이라는 것이 내가 어떤 개발자인지, 무엇을 잘하고 관심이 있는지에 대해 정의하는 과정이라는 것을 알 수 있었습니다. 그 과정에서 다른 사람으로부터 긍정적인 영향과 피드백을 받을 수 있고, 동기부여를 통해 더욱더 성장하는 개발자가 될 수 있다는 것을 알았습니다. 인상 깊었던 내용을 정리하면 다음과 같습니다.

브랜딩을 통해 색깔 있는 개발자가 되자
나는 무엇을 잘하는 개발자인지? 어떤 것에 관심 있는 개발자인지?
콘텐츠 제작을 통해 동기부여와 피드백을 통한 배움을 얻자
독자들의 피드백을 통해 성장하자
꾸준하게 콘텐츠 제작을 하자
처음엔 TIL을 통해서 오늘 배운 내용을 정리해보고, 글을 쓰다가 익숙해지면 “독자”에 대해서 고민해보자
나만 다룰 수 있는 주제는 뭐가 있을지 고민해보자
글을 공유하고 피드백을 통해 완성하자

저도 좋은 글을 쓰고 싶다는 생각은 항상 가지고 있지만 글 쓰는 것이 부담스럽다는 이유로 실행하는 데 어려움을 겪었습니다. 벨로퍼트님의 세션을 듣고 자극받아 TIL부터 꾸준히 쓰며 글 쓰는 습관을 만들기로 마음먹었습니다. 대신 혼자만의 TIL이 아닌 8퍼센트의 TIL 문화를 적극적으로 활용하고 있습니다.

8퍼센트의 TIL 문화

8퍼센트에는 배운 것을 기록하는 ‘TIL(Today I Learned) 문화’가 있습니다. 입사 후에 한 달 동안 매일 배운 것을 기록하고 공유하고 있습니다. 다른 팀원들이 볼 수 있도록 공개적으로 작성하여 피드백을 받을 수 있고 성장하고 기록하는 습관을 기를 수 있습니다. 자신이 겪은 어려움이나 배움들을 공유하며 다른 팀원들의 생각과 의견을 통해 성장할 수 있는 문화입니다.

물론 입사 한 달이 지나도 TIL을 공유하면 동료 개발자들이 피드백으로 반갑게 맞아주는데요. 인프콘에 갔다 온 후 다시 TIL을 꾸준히 작성하고 있습니다. 좋은 콘텐츠의 글을 통해 내가 어떤 개발자인지 알아가는 셀프 브랜딩의 첫걸음이라고 생각합니다. 여러분들도 좋은 콘텐츠의 글을 쓰고 싶다면 TIL부터 시작하는 건 어떨까요? (8퍼센트의 TIL문화에 대해 자세히 알고싶다면 이 글을 읽어주세요!)

by 조승희

2. 후기

승희
컨퍼런스 참가는 처음이었는데요. 많은 분의 개발에 대한 열정을 직접 느낄 수 있었습니다. 성장하고자 하는 분들을 통해 자극받고 개발에 대한 열정을 다시 느낄 수 있는 계기가 되었습니다. 인프런의 슬로건처럼 ‘배우고 나누고 성장’할 수 있었던 시간이었습니다.

민정

다양한 주제와 스토리를 가진 수많은 개발자분을 직접 만나고, 그분들이 마주한 경험이나 고민을 생생하게 전달받을 수 있는 지식의 장이었습니다. 영상이나 텍스트로만 접하던 개발자님께 궁금했던 부분에 대해 직접 질문도 드리고 이야기도 나눌 수 있는 만큼 값진 자리였습니다.

우리 내년에도 인프콘에서 만나요~! (제발~!)

글 조승희, 김민정