티스토리

기억보단 기록을
검색하기

블로그 홈

기억보단 기록을

IT 분야 크리에이터
jojoldu.tistory.com/m

좋은 애플리케이션 구현 & 설계 / 데이터베이스 / 클라우드 / 스타트업 이야기 등을 이야기합니다.

구독자
1,837
방명록 방문하기
공지 EO 커리어콘 2021 연사로 참석합⋯ 모두보기
반응형

주요 글 목록

  • 1. TS를 만나고 - 디자인 JVM 컨퍼런스가 있으면 "Java 세상에서 살던 사람이 처음 TS 세계를 만나고 느낀 여러가지 차이점" 을 발표하려고했는데, 시간도 너무 지났고, 발표 준비하기도 쉽지 않은 것 같아 블로그에 시리즈로 시작한다.Java가 구린 언어다를 표현하기 위한 글이기 보다는 전작(다른 언어로 성장하기)과 마찬가지로 타 생태계를 통해 성장할 수 있음을 알리는 글이다자바를 처음 배울때 getter/setter 에 대한 이야기를 많이 들었다.캡슐화 등의 장점을 들으면서 클래스 안에는 항상 무분별하게 getter/setter 를 생성했다.(그때는 Lombok을 배우지 못했던 터라) IDE의 자동 생성 기능을 사용하면서 열심히 getter/setter를 생성했다.물론 예전부터 많은 분들은 무분별한 getter/setter를.. 공감수 42 댓글수 5 2024. 8. 26.
  • HTTP API 디자인 - URI편 마틴 파울러의 블로그를 가보면 Leonard Richardson이 제안한 HTTP API 성숙도 모델 (Richardson Maturity Model - RMM)을 소개한다.여기서는 다음과 같이 4단계를 설명한다.레벨 0: 하나의 URI를 정의하고 모든 작업은 이 URI에 대한 POST 요청레벨 1: 개별 리소스에 대해 별도의 URI를 만든다.레벨 2: HTTP 메서드를 사용하여 리소스에 대한 작업을 정의레벨 3: 하이퍼미디어(HATEOAS 등)를 사용Roy Fielding 의 정의에 따르면 레벨 3이 진정한 RESTful API에 해당한다.대부분의 RESTful API는 진짜 RESTful API는 아니며 보통 레벨2 부근에 해당한다.아래는 마틴 파울러 블로그에 나와있는 성숙도 레벨이 무엇을 의미하는지.. 공감수 81 댓글수 23 2024. 5. 21.
  • Public API의 CDN 캐시 API의 캐시 중에는 모든 사용자 (로그인/비로그인 관계없이) 동일한 응답값을 줘야하는 것들이 있다. 로그인/비로그인에 관계없이 항상 일정한 데이터가 사용자 UI에 필요한 경우이다. 이를테면 인프런 서비스의 상단 헤더에 노출되는 강의 카테고리 (1 depth, 2depth, 3depth) 같은 경우. 이 캐시 데이터는 서비스의 모든 페이지에서 호출하고 있다보니 페이지 조회수 만큼 캐시 API를 호출하게 된다. Redis 캐시 -> 로컬 캐시 등으로 캐싱처리를 해도 결국 서버로 가는 조회 요쳥수가 개선되는 것은 아니고, 서비스 전체에서 가장 많이 호출되는 API 영역이 개선된 것이 아니다. SSR을 CDN으로 캐시 해도, SSG로 정적 페이지를 만들어도 헤더 영역은 사용자별 로그인 구분을 위해 CSR로 구.. 공감수 60 댓글수 24 2024. 4. 14.
  • 운영 로그와 디버그 로그 분리하기 최근에 Pete Hodgson가 martinfowler 블로그에 기재한 글을 보면서 로깅도 하나의 기능으로 봐야한다는 생각이 더 강해져서 이 글을 쓰게 되었다. 시스템을 구축하다보면 다음과 같이 크게 두 종류의 로그를 남긴다. logger.error(`API Timeout: ${timeout} seconds`, e); logger.info(`Ordered Food Product Id: ${product.id}`); logger.debug(`Total Order Price Amount: ${sum(products.amount)}`); 이 로그들은 모두 필요한 메세지를 노출시키지만, 실상은 목적이 다르다. Error와 Info 로그는 운영 환경에서 장애를 디버깅하거나 실행 중인 시스템의 여러 진행 상황, 지.. 공감수 80 댓글수 6 2024. 3. 15.
  • [리팩토링] 코드 배치와 변수 줄이기 비즈니스 로직 위주로만 생각하고 바로 코드를 작성하다보면 코드가 길어지고, 가독성이 떨어지는 경우가 많다. 특히 가독성이 떨어지면 코드를 리팩토링할때도 이상한 방향으로 할 때가 있다. 이럴때 가독성을 높이기 위해 코드 배치와 변수를 줄이는 방법을 알아보자. 예제 ORM 없이 직접 SQL을 작성하는 환경에서 다음과 같이 코드를 작성했다고 가정하자. export class ProductRepository { async create (createDtos: ProductCreateDto[]) { const promiseList = []; const results: Product[] = []; // 반복문을 수행하면서 DTO를 Entity로 변환하고 SQL Promise를 쌓아둔다. for(const dto of.. 공감수 72 댓글수 13 2023. 11. 12.
  • 좋은 예외(Exception) 처리 좋은 예외 처리는 견고한 프로그램을 만들고, 좋은 사용자 경험을 줄 수 있다. 예외 처리를 통해 애플리케이션이 예기치 않게 종료되는 것을 방지하고, 갑작스런 종료 대신 사용자는 무엇이 잘못되었는지, 그리고 가능하다면 어떻게 바로잡을 수 있는지에 대한 의미 있는 오류 메시지를 받을 수 있다. 뿐만 아니라 좋은 예외처리는 개발자가 문제를 진단하는 데 큰 도움이 되어 이로 인해 문제 해결 시간이 단축된다. 특히, 복잡한 시스템에서 여러 단계의 프로세스가 있는 경우 예외는 프로세스의 위치에 따라 다르게 처리되어 적절한 예외 처리는 이러한 프로그램의 프로세스를 관리하는 데 유연성을 제공한다. 반면, 이를 위해 과도하게 사용하면 메인 비즈니스 로직이 무엇인지 파악하기 힘들 정도로 너무 많은 오류 처리를 가지고 있는.. 공감수 144 댓글수 3 2023. 9. 5.
  • 3. 좋은 함수 만들기 - Null 을 다루는 방법 여기서는 null 과 undefined 를 구분하지 않고 null 로 통일해서 표현한다. 정적 분석 서비스 rollbar 에서 1000개 이상의 JS 프로젝트에서의 소프트웨어 결함 통계를 공개했다. (출처: top-10-javascript-errors-from-1000-projects) 상위 1~10위까지의 대부분이 null과 undefined 로 인한 문제였다. 이 외에 (과거 자료지만) 안드로이드 플레이 스토어의 Top 1,000 Popular Apps 들을 분석한 결과에서도 NullPointerException 가 전체 결함 중 2번째였다. (출처: Multi-objective Automated Testingfor Android Applications) 이 만큼 빈값(Null, Undefined) .. 공감수 27 댓글수 4 2023. 6. 24.
  • 좋은 API Response Body 만들기 기존 SSR 시스템(jquery + Server Template)을 API 기반의 신규 시스템으로 전환하는 작업을 하면서 팀의 백엔드 개발자분들께 Response Body 관해서 종종 코멘트를 한다. 이런 코멘트들이 쌓이다보니 그냥 한번에 사내 위키로 정리하는게 좋겠단 생각에 먼저 블로그에 정리하게 되었다. 일반적인 내용들 + 팀 전용 내용들을 다 같이 담아서 사내 위키에 남기려고. 정답이 있는 것은 아니지만, 개인적으로 선호하는 Reponse Body 규칙들이 있다. API 역시 사용자 인터페이스이다. 인터페이스라는 측면을 무시하고, 내가 편한 방법, 혹은 기준 없이 API의 Body를 만들다보면 정작 사용해야하는 쪽에서 불편할때가 많다. (사용자 인터페이스임에도 불구하고 말이다) 아래는 내가 선호하는.. 공감수 126 댓글수 1 2023. 6. 10.
  • Number와 boolean 은 최대한 Not Null로 선언하기 테이블 설계시 종종 받는 질문 중 하나가 Boolean과 Number 컬럼의 Not Null 유무이다. 비즈니스적으로 기본값이 있는 경우가 아니면 유연하게 하기 위해 nullable 로 선언하는 경우를 자주 본다. 테이블의 Boolean과 Number 타입 컬럼을 nullable 로 설정하면 여러 문제가 발생할 수 있어서 가급적 추천하지 않는다. 대표적으로 다음과 같은 문제가 있다. 1. 혼란스러운 의미 컬럼을 nullable 로 설정하면 기본값이 null 이 되므로, 데이터의 의미가 굉장히 혼란스럽게 된다. 예를 들어, boolean 컬럼이면 값이 true, false, null 세 가지 상태가 될 수 있다. 이는 '참', '거짓', '미확인' 의 세 가지 상태가 된다는 것이다. (일부 상황에서는 유용.. 공감수 31 댓글수 0 2023. 6. 2.
  • 1. 효율적으로 로그 모니터링하기 - 로그 레벨 구분하기 365/24 로 관리하는 시스템에서 로그는 굉장히 중요하다. 하지만 로그가 중요하다는 생각에 무분별하게 남기는 것은 좋지 않다. 대표적인 예로 습관적으로 예외 상황이 발생하면 ERROR 레벨로 로그를 남기는 경우이다. 보통의 서비스에서는 시간 내 에러 로그가 일정 수치 이상 쌓이면 알람을 발생시키도록 구성한다. 정상적이지 않은 모든 상황에서 전부 ERROR 레벨로 처리하게 되면 불필요하게 많은 알람들로 인해 정작 봐야할 심각한 에러 로그들도 놓칠 수 있다. 그래서 적정 수준에서 로그 레벨을 구분하여 알람 경보 수준도 구분하는 것이 필요하다. 1. 로그 레벨 로그 레벨은 해당 로그 메세지가 얼마나 중요한지를 알려주는 정보이다. 로그 레벨의 중요도는 담당 개발자가 밤에 계속 잠을 잘 수 있는지, 즉시 침대에.. 공감수 45 댓글수 1 2023. 4. 16.
  • 2. 좋은 함수 만들기 - 암묵적 입력/출력 지난 시간에 부작용 (부수효과) 함수에서 어떻게 최대한 부작용과 거리두기를 해서 좋은 함수를 만드는지 간단한 예제로 연습해봤다. 이번 시간에는 좋은 함수가 되기 위해 관리해야할 부작용이란 어떤 것들이 있는지 알아보자. 1. 암묵적 입력/출력 좋은 함수는 "부작용 (부수효과) 이 없으며, 멱등성을 유지할 수 있는 함수" 라고 했다. 이 부작용 (부수효과) 함수에는 크게 2가지 특징이 있다. 암묵적 입력 (implicit input) 암묵적 출력 (implicit output) 1-1. 암묵적 입력 (implicit input) 암묵적 입력이란 함수의 입력값으로 명시적으로 전달되지 않는 파라미터를 의미한다. 예를 들자면 다음과 같은 경우 암묵적 입력이다. 함수의 인자는 없는데 함수 내부에서 쿠키에서 값을 가.. 공감수 39 댓글수 1 2023. 3. 1.
  • 1. 좋은 함수 만들기 - 부작용과 거리두기 요즘의 개발에서 프레임워크나 라이브러리 사용이 없는 개발은 생각하기 어렵다. 특히 DDD 등의 개념까지 기본지식처럼 취급되어 점점 추상화된 개발에 익숙해지고 있다. 복잡한 애플리케이션 구현을 하다보면 이러한 것들에 대해 당연히 필요하다. 다만, 이게 심해지다보면 실제 구현을 해야할 변수, 함수, 클래스 등을 잘 작성하는 것보다 프레임워크나 라이브러리의 기능을 얼마나 많이 알고 있느냐를 개발자의 성장으로 오해할 수도 있다. 프레임워크와 라이브버리와 같은 도구에 대해서 숙련도가 높다면 당연히 좋겠지만, 그 이전에 좋은 변수, 함수, 클래스에 대해 먼저 고민하는 것도 필요하다. 그래서 이번 시리즈에서는 좋은 함수에 대해서 이야기하려고 한다. JS/TS 환경에서 불변객체 다루는 방법이 순수 함수형 언어들에 비해.. 공감수 77 댓글수 1 2023. 1. 18.
  • 데이터 변환 계층 (Data Transform Layer) Express와 JS/TS만을 가지고 프로젝트를 진행하다보면 데이터 변환 계층의 기준이 정해져있지 않은 경우를 많이 본다. 사람마다 다르기도 하고, 혹은 같은 사람이 작성한 코드에도 천차만별이다. 이에 대해서는 팀에서 확실하게 컨벤션을 잡지 않으면 서로 데이터 변환 계층을 다르게 두어 프로젝트 전체가 일관성이 떨어지고 코드 가독성과 리팩토링 내성도 떨어지게 된다. 그렇다면 데이터 변환 계층의 기준을 어떻게 세우면 좋을까? 문제 예를 들어 다음과 같은 상황이 있다고 해보자. 프로젝트에서는 js-joda (혹은 Dayjs 등) 날짜 타입을 쓰고 있는 상황에서 Database SQL에서 사용하기 위해서는 Date 로 치환해야하는 경우 API 로 외부에 데이터를 전송 (혹은 요청) 하기 위해 String 으로 .. 공감수 17 댓글수 0 2022. 11. 28.
  • 현실 세계의 속성에 의존하지 않기 최근에 들었던 질문 중 현실 세계의 식별자를 데이터베이스 기본키로 써도 되냐는 것이 있었다. 이를테면 현실 세계에서 유일함을 보장하는 값들이다. 주민 등록 번호 전화 번호 여권 번호 이들을 데이터베이스의 기본키 (PK) 로 지정해서 쓰는게 어떤가 하는 것이다. 최근의 ORM 예제들을 보면 auto_increment 혹은 uuid 등 개발자가 직접 생성한 기본키을 지정하는데, 왜 그렇게 하는지 모르겠다는 이야기도 들었다. (나 뿐만 아니라 여러 개발자분들이 같은 생각을 하실것 같은데) 기본키는 절대 바뀌지 않아야 한다. 기본키를 수정하는 것은 항상 많은 문제를 일으킨다. 대부분의 기본키가 여러 테이블의 FK와 인덱스로 지정되어 사용되기 때문이다. 더군다나 위와 같이 현실 세계의 값들은 사용자들이 직접 입력.. 공감수 40 댓글수 0 2022. 5. 31.
  • 계층형 아키텍처 학교 다닐때 잠깐 JAVA 관련 수업을 들은적이 있다. 그때 수업 내용은 넷빈즈(Netbeans) IDE를 통해 JAVA로 윈도우 애플리케이션을 만드는 것이였다. 간단한 시간표 관리 프로그램을 만드는 과제는 얼핏보면 웹과 크게 다르지 않았다. (이미지 출처: blog.asata.pe.kr) 개발 자체는 꽤나 간단해서 JAVA (Swing)로 애플리케이션 UI와 로직을 작성하고, 로컬 PC에 설치된 Database에 접근해서 시간표를 저장하고 불러오는 방식이였다. 당시에는 계층 (Layer) 혹은 모듈화라는 개념이 없어서 UI를 담당하는 클래스에서 검증, 계산, DB 접근등을 모두 처리했었다. 기능 자체는 잘 작동했고, 실제로 과목 점수도 잘 받았다. (컴공과 수업이 아니였어서…) 하지만 이게 실제 회사의.. 공감수 45 댓글수 0 2021. 10. 2.
  • 객체지향 (Object Oriented) 디자인 (Design) 여기서 이야기하는 디자인은 코드 설계와 동일하게 봐도 무방하다. 디자인이 왜 중요한가? 요즘의 웹 애플리케이션 개발에서는 디자인에 대한 지식이 없더라도, 원하는 바대로 작동하는 웹 애플리케이션을 만들 수 있다. 특히나 최근의 언어들은 문법이 너무나 친절하여 자신의 생각을 순차적으로 정리만 할 수 있다면 누구나 원하는 웹 애플리케이션을 만들 수 있다. 작은 규모의 웹 애플리케이션에서는 이렇게 디자인을 전혀 고려하지 않고, 기능 구현에만 신경써도 문제는 없다. 아니, 아예 좋지 못한 디자인이라해도 문제가 되지 않는다. 객체간의 복잡한 관계, 계층화 되지 않은 구조 등 모듈화가 전혀 없어도 개발자의 머릿속에 모든 것들을 담아두고 개발을 할 수 있기 때문이다. 반대로 얘기하면 특정 누군가만 손댈수 있고, 그 사.. 공감수 37 댓글수 0 2021. 8. 13.
  • Public / Private 인터페이스 여기서의 인터페이스란 class, interface, abstract class 등에서 이야기하는 interface 가 아니다. 서로 다른 객체간에 어떤 것들을 사용할 수 있을지에 대한 명세를 이야기한다. Method, Function 등이 모두 포함된다. (위 2개 그림은 모두 동일한 원 (클래스)를 가지고 있으며, 화살표 (의존)만 다르다.) 똑같은 클래스들을 가지고, 누구는 첫번째처럼 얼기설기 얽혀있는 구조로 모든 객체가 서로 연결된 구조를 만들고, 누구는 두번째처럼 각 클래스들이 전달 하는 메세지와 관계가 명확하게 드러내도록 만든다. 이렇게 차이 나는 이유는 클래스가 하는 일에만 집중하고, 무엇을 드러내고, 무엇을 숨길지에 대해 전혀 고려하지 않았기 때문이다. 첫번째는 이를 전혀 고려하지 않아서 .. 공감수 16 댓글수 0 2021. 7. 28.
  • is_left vs left_at vs left_status 트위터를 보다가 재미난 포스팅을 하나 발견했다. you-might-as-well-timestamp-it 전체적인 글의 주장은 다음과 같다. 소프트웨어 개발에서는 상황에 의존하는게 좋은 설계이지, 어떤 상황에도 좋은 기준이라는건 있을 수 없다고 생각한다. 다만, boolean (is_deleted) 대신 timestamp (deleted_at) 를 저장하는 것은 상황에 관계 없이 확실하게 좋은 설계라고 생각한다. 일반적으로 어떤 flag 값이 필요하다고 하면 그 flag가 언제 변경되었냐도 거의 필수적으로 필요하게 된다. 이미 boolean으로 결정해서 사용할 경우 이 시간을 찾아 내기 위한 마이그레이션 비용이 생각보다 많이 필요하고, 그때 가서 변경하기엔 많이 늦었다. 만약 timestamp (delet.. 공감수 11 댓글수 0 2021. 6. 3.
    728x90
    반응형
    문의안내
    • 티스토리
    • 로그인
    • 고객센터

    티스토리는 카카오에서 사랑을 담아 만듭니다.

    © Kakao Corp.