아카이브

#FFFFFF 화이트가 안되는 이유 눈이 시려서 오래 못 본다. PPT 흰 배경보다가 눈 아팠던 경험, 화면의 #FFFFFF는 빛을 그대로 쏘기 때문에 글자가 오히려 안 읽힌다. 병원 관공서 느낌이 난다. 순수 흰색은 차갑고 사무적이다, 따듯한 카페 · 감성 브랜드 · 고급스러운 무드를 원한다면 비추한다. 인쇄하면 종이색과 맞지 않는다. 종이는 살짝 누런빛(웜톤)이거나, 푸른빛(쿨톤)을 띄는데, 순수 #FFFFFF로 디자인한 흰 영역이 인쇄물에서는 어색하게 도드라진다. 럭셔리 · 프리미엄 브랜드에서는 잘 사용하지 않는다. 럭셔리 · 하이엔드 브랜드는 거의 모두 오프하이트(#F5F5F0, #FAF7F2) 계열을 씁니다. 샤넬 · 에르메스 · 디올의 화이트는 절대 #FFFFFF가 아니다. 흰색 대신 이런 톤으로 바꿔보기 #FDFCF8 럭셔리 패션이나 미니멀 패키지의 기본 배경 값 #F3F0E9 종이 질감 매거진 · 브랜딩 명함의 따듯한 배경 값 #F8F9F6 애플 · 삼성 같은 테크 · 가전 브랜드의 깔끔한 배경 값 #FAFAF8 웹 사이트 · 앱 UI 본문의 가장 무난한 기본 배경 값 #FCFCF0 베이커리 · 디저트 · 플라워 샵의 손편지 같은 무드의 배경 값

입사 후에도 사이드 프로젝트를 하실건가요? 면접에서 수차례 받았던 질문이다. 이에 따른 대답은 "YES".. 면접관들의 질문은 그저 궁금한 질문일 수 있었으나, 사이드 프로젝트가 업무 몰입에 방해가 될 수도 있다는 의도로 질문을 했던 면접관도 분명 있을 것이다. 하지만 나는 계속 내가 운영하는 프로덕트들을 그로스할 것이다. 왜냐하면 현업에서 겪지 못하는 것들을 사이드 프로젝트에서 겪을 수 있으니까 사이드 프로젝트의 첫 시작, 무작정 웹 개발 시작하기 나는 사실 창업에 관심이 많은 학생이었다, 2017년에 학교를 입학해서 무작정 웹 개발 동아리에 들어가서 Ruby on Rails로 웹 개발의 첫 한걸음을 하고, 벤쳐 창업 동아리 SOPT에 들어가 엔젤 투자자, 여러 CEO 분들을 보면서 창업에 대한 꿈을 키웠다. "내가 만든 서비스로 돈을 벌고, 내가 만든 서비스를 사랑해준다니.. 이 도대체 멋진 일이 아닌가.." 그런데 막상 현실은 정말 어렵다. 프리랜서가 자신을 PR하기 위해 셀프 브랜딩을 하듯, 창업은 CEO인 자신과 서비스를 동시에 브랜딩하면서 프로덕트의 경쟁성을 키워야한다. 또 가정 형편상 집에서는 그다지 도전적인 분위기를 좋아하지 않았다. 그러면서 안정적으로 학교 생활을 하고, 또 안정적으로 개발자로의 직장생활을 하게 되었다. 그러면서 우연히 현직자들과 함께 빠르게 프로덕트를 런칭할 수 있는 디프만이라는 활동을 하게 되었다. 약 5~6주 동안 기획부터 디자인 · 개발 및 런칭까지의 프로세스를 치열하게 고민하고 밤샘작업하는 과정에서 무언가 조그마한 불씨가 타올랐다. "실패하면 어때, 그냥 시중에 프로덕트로 운영부터 해보자" 그렇게 만들어진게 글을 작성하고, 회고를 좋아하는 나에게 정말 꼭 필요했던 서비스 "레이어" 이다. 그리고 최근에는 빅테크 채용 공고 서비스도 그로스 하는 과정을 겪고 있다. 반짝이고 사라지는 서비스 보다는, 5명이라도 지속적으로 사용할 수 있는 서비스를 만들고싶어. 시작이 창대하면 얼마나 좋을까, 항상 모든 프로덕트의 시작은 그리 창대하지 않다. 디프만에서 처음으로 만들었던 서비스가 "칭찬감옥" 이라는 재미난 요소에서 시작했던 프로덕트였는데, 잠깐 반짝하고 사라지는 서비스가 되어버렸고 그렇게 빠르게 서비스도 종료가 되었다.

사이드 프로젝트를 진행하다보면 신규 팀원이 들어오는 경우에는 환경변수 파일에 대한 내용을 공유한다. 그런데 사실 이미 개발을 진행하다보면, 프로젝트가 점점 커지면서 어떤 환경변수가 구성되어있는지 잘 모르는 경우도 있고, 만약 누군가 새로운 환경변수를 추가한 경우에는 다른 사람에게 알림을 주지 않는 이상 잘 모르고 넘어간다. 그런데 여기서 문제는.. 나중에 빌드 상황에서 누락된 환경변수로 인해 빌드 에러가 발생하거나, 환경변수 히스토리가 누락된 경우에는 어떤 환경 변수가 있었는지에 대한 추적이 불가능하다. 여기서 매번 .env 파일을 공유하다 문득 궁금한 점이 생겼다. "환경 변수를 이렇게 매번 파일로 공유하고, 매번 메신저로 공유해줘야하나?" 클라우드 환경에서 환경변수 가져오기 보통 .env 의 경우에는 파일 내에 정적 정보로 저장된다. 그래서 .env 는 외부로 유출되면 절대적으로 안되며, 정말 중요한 정보들이 들어가는 경우가 많다. 또 실수로 환경변수가 공개된 저장소에 올라가게되면, 잠깐의 찰나라도 공격당하는 경우가 있을 수 있다. (여기서 공격 당하는 경우라고 하면, 중요한 내부 키가 탈취당해 과금이 나오는 경우 ^,^ ..) 그래서 이러한 환경변수들을 클라우드 환경에서 업데이트될 때마다 내려받고, 더이상 개발자는 환경변수가 어떤 것들이 비어져있고, 담당자는 누구인지를 체킹하지 않아도 되는 번거로움을 없앨 수 있다. dotenv-vault로 환경 변수 컨트롤하기 가장 단순하면서 환경변수 파일을 가장 쉽게 관리할 수 있는 오픈소스 솔루션이다. 기존의 .env 워크 플로우를 유지하면서 암호화된 .env.vault파일만을 git 에 올리는 방식이다. 변경사항은 팀원이 pull 을 하면 항상 반영되며 도입 시에 가장 진입 장벽이 낮다. 가장 빠르게 적용 가능하면서, 팀원들이 혼동하지 않도록 하는 방식이 제일 효율적이었다. doppler와 같은 다른 솔루션의 경우에는 권한에 따른 환경변수 부여도 가능하지만, 내가 진행하는 사이드 프로젝트에서는 개발자 모두가 동등한 권한을 가지고 개발을 진행하는 것이기에 dotenv-valut 로 불편한 점들을 먼저 해결하고, 추가적으로 필요할 때 고려해보고자 했다.

최근에 전직장 멘토님과 이야기를 하면서, 전 직장에 AI 플로우가 도입되고 있다는 것을 알게되었다. 이야기 중에 PRD(Product Requirements)와 WRD(Work Requirement Document)를 먼저 정의해놓고 개발을 진행하신다는 이야기를 듣게 되면서, PRD와 WRD가 대체 무엇인지 그리고 이 두가지 문서를 사용하게 되면 어떤 이점들이 있는지 알아보고자 한다. 처음엔 에이전트에게 "기능 만들어줘"라고 입력하는 것으로만 기능 구현을 할 수 있었지만, 프로젝트가 커질수록 담고있어야하는 컨텍스트 크기 뿐만 아니라 기능에 대한 정의가 이전 대화 기록으로 남아있어 사용자는 기억하기 쉽지 않았다. 만약 컨텍스트가 초기화되면 이전 요청한 기능들을 다시 기억하게 해줘야하는 순간들도 생각보다 많다 ^,^.. AI가 앞에서 했던 맥락을 잊어버리거나, 같은 기능을 요청했는데 매번 다른 구조로 짜주거나, 토큰이 터져서 대화 자체가 중단되는 순간들도 빈번하다. AI 기반 개발 방식이 자리를 잡으면서, 프롬프트 한 줄로 코드를 생성하는 것 이상의 체계가 필요해졌다. 그 중심에 PRD(Product Requirements Document)와 WRD(Work Requirement Document)를 먼저 작성하고, 이를 기반으로 AI가 구현하게 만드는 흐름, 일명 "플로우(Flow)" 방식이 있다. 왜 이 방식이 사용되고 있을까? AI 코딩 도구가 처음 나왔을 때, 대부분의 사용법은 단순했다. 프롬프트로 함수 하나를 만들고, 수정하고, 반복하는 식이었다. 그런데 GPT-4 급의 모델이 대화 컨텍스트를 길게 유지하면서 더 복잡한 작업을 하게 되자, 기존 방식의 한계가 드러났다. AI에게 프로젝트 전체를 설명하려면 대화 초반부터 엄청난 토큰을 소모하게 된다. 매 세션마다 같은 배경을 반복 설명해야 하고, 맥락이 흐릿한 상태에서 생성된 코드는 전체 구조와 맞지 않는 경우가 많다. 그 대안으로 나온 것이 문서를 먼저 작성하고, 그 문서를 AI의 참고 자료로 삼는 방식이다. 소프트웨어 개발에서 PM이 작성하던 PRD의 개념을 AI 개발 워크플로우에 끌어들인 것이다. WRD는 그보다 한 단계 더 내려가서, 실제로 어떤 기능들을 만들 것인지를 정리한 문서다.

글을 시작하며 사내에서 백오피스 프론트엔드 프로젝트에 타입스크립트가 적용되면서 내부 컨벤션이 정의되며, 구조에 대해 한번 더 생각할 기회가 있었다. 이 과정에서 초기 사내 백오피스 프론트엔드 프로젝트의 폴더 구조는 아래와 같이 도메인 별 1:1 매핑되는 구조로 가져고 있었다. 프로젝트를 진행하다보니 이 구조가 기능 도메인이 점차 커질수록 많은 문제점을 야기한다는 것을 알게되었다. 위에 코드는 실제 프로젝트로 기존에 구성되어있던 구조이다. 초기에는 프로젝트 도메인 별로 구분이 되어있다는 느낌을 받으면서 직관적이고 모든 API는 api/ 폴더 안에, 그리고 모든 페이지를 구성하는 뷰(페이지)는 views/ 폴더 안으로 구성하면되니 일관성을 확보할 수 있었다. 다만 점차 프로젝트의 기능 별 도메인이 많아지면서 백오피스에서 관리해야하는 영역들이 많아지고 있음을 느꼈다. 그리고 이런 문제점들이 발생했다. 기능 별 도메인이 추가될 때마다 views 폴더 안에 관련 폴더를 만들어주고, api , components , composable 과 관련된 폴더들에서도 동일한 이름으로 만들어줘야한다. 이 과정에서 네이밍 규칙이나, lookAlike 라는 기능 도메인을 lookAlikeDomain 과 같이 자유분방한 이름으로 통일성이 지켜지지 않는 경우가 있다. components , util 과 같은 우리가 평소 쓸만한 폴더 명이 아니기도 하면서, 익숙하지 않기 때문이다. 기능이 2~30개 정도가 되면 한 views 폴더 안에서 해당 컴포넌트를 찾기 위해서 여러 파일들을 탐색해야하는 경우가 생기는데, 이 과정이 점점 오래 걸리기 시작한다. 기능을 수정할 때도 동일하다. views 폴더에서 컴포넌트로 이동을 했다가 또 views 파일로 이동을 하는 반복적인 과정들이 생긴다. 레이어(기술 중심) 폴더로 설계를 하다보니, 각 폴더를 "무엇을 하는가" 에 따라 분류하면서 낮은 응집도와 확장성, 그리고 네이밍 중복에 대한 문제가 발생한다. 어떻게 해결할 수 있을까? 처음 백오피스 구조를 살펴보면 여러 컴포넌트들과 컴포저블들은 궁극적으로 views 폴더 안에 존재하는 기능 도메인 파일을 위해 구성되는 여러 요소들이다. 이 목적성에 따라 views 를 기점으로, 그러니까 각 기능 별 도메인을 기준으로 폴더를 구성한다.