user = {
email: 'elsa@prisma.io',
name: 'Elsa Prisma',
posts: {
create: {
title: 'Include this post!',
},
},
}
frontend도 많이 개발해보자.
- 개인적으로 하고 싶은 사이드 프로젝트를 하는데 도움이 될 것이다.
- 혼자서 아이디어를 구현할 수 있는 능력이 생기게 될 것이고, 나는 나의 아이디어를 빠르게 구현하는 것을 원한다.
Notification System
nextjs에서 router는 기능의 중심이되는 개념이다. router의 종류에는 page router와 app router가 있으며 app router는 서버 중심의 라우팅, page router는 클라이언트 중심 라우팅이다. 구현 방법으로 page router는 pages 디렉토리에서 파일의 경로에 따라 자동으로 라우팅이되며 app router는 src/apps 디렉토리를 사용한다.
[공식문서] https://nextjs.org/docs/getting-started/installation [관련 블로그글] https://velog.io/@jjunyjjuny/nextjs-13.4.0%EB%B6%80%ED%84%B0-%EC%95%88%EC%A0%95%ED%99%94%EB%90%9C-App-Router.-Pages-Router%EC%99%80-%EB%B9%84%EA%B5%90
진정한 자유란 무엇인가. "지유란 타인에게 미움을 받는 것" 누근가에게 미움을 받는 것. 그것은 내가 자유롭게 살고 있다는 증거이자 스스로의 방침에따라 살고 있다는 증표다. - [미움받을 용기 / p192]
타인에게 미움받고 싶지 않은 마음은 인간에게 극히 자유로운 욕망이라고 한다. 칸트는 이러한 욕망을 '경향성'이라고 지칭했다고 한다. 누군가가 나를 미워한다는 것을 알게되었을 때, 스트레스와 고민이 생긴다. 위의 글은 미움을 받는 상황에 대한 새로운 관점을 깨닫게 한다.
React - component, state, props
어떤 테이블의 컬럼이 추가되어야하는 상황일 때, entity에만 컬럼을 추가하고 조회와 같은 로직을 수행하면 (db에는 컬럼 추가 x) 해당 컬럼이 없다는 에러를 낸다.
반대로 db에있는 컬럼이 매핑되는 엔티티에 없더라도 에러를 내지 않는다.
특정 컬럼이 추가되는 경우 반드시 DB에 먼저 추가한 후, 엔티티를 수정하여 반영하자. 반대로 특정 컬럼을 수정, 삭제하는 경우에는 엔티티에 먼저 작업을 하고 db에 해당된 컬럼을 수정, 삭제하자.
오브젝트 책을 읽다가 객체지향설계는 책임을 중심으로 객체들을 분할할 수 있고, 상태(데이터)를 중심으로 객체들을 분할 할 수 있다고 한다. 그리고 변경을 이유로 책임을 중심으로 하는 것이 바람직하다고 말한다.
데이터 중심으로 객체들을 분할하고 영화 예매 시스템을 구현해봄으로써 그 이유를 파악하는데 데이터 중심설계는 캡슐화가 완전히 되지않고, 높은 결합도와 낮은 응집도를 가짐으로써 변경이 발생했을 때 여러군데에 수정이 필요하였다.
그런데 읽다보니 서버 프레임워크에서 정한 구조에 따라 entity를 생성하고 service 레이어에서 관련 도메인에 대한 로직을 구현하는 것이 전형적인 데이터 중심의 설계인 것이라고 생각되었다.
DDD를 사용하면 서버 프레임워크로 코드를 작성할 때도 객체지향적으로 짤 수 있는 것일까 ? 아니면 이러한 서버 프레임워크에서 짜놓은 틀은 어쩔 수 없는 것일까? 혹은 이러한 서버 프레임워크의 구조는 객체지향적 설계의 개념을 고려할만한 대상이 아닌 것일까 ?
우리 팀은 NestJS로 서버개발을 하고 있는데, 초반에 nest를 학습하면서 Spring과 아주 비슷해서 어느 순간부터 nest 학습을 안하다가, 몰랐던 개념을 알게되어 기록한다.
이름하여 Pipe.
파이프는 보통 2가지의 목적을 위해 사용된다.
해당 처리 시점은 라우터 핸들러로 전달되기 전.
class-validator와 class-transformer 라이브러리와 함께 사용하면 더욱 편리하게 유효성 검사와 변환이 가능합니다.
프로젝트에서 사용되는 부분
좋은 날이 있으면 안 좋은 날도 있고, 안 좋은 날이 있으면 좋은 날도 있더라,
좋았던 날에는 그 느낌을 즐기되 겸손하자.
안좋았던 날에는 좋은 날이 올 차례라는 것에 설레여하자.
상대성 이론이 궁금해진 하루 ~
상황 - 급하게 이슈를 해결하느라 prod db에만 데이터 변동이 생긴 상황, 추후 추가적인 이슈가 발생하지 않도록 코드 검토가 필요하며 dev 환경에서 검토를 위해 dev db와 prod db의 sync를 맞춰주어햐 한다.
해결 방안 - prod db를 dev db로 마이그레이션하자. 마이그레이션 방법은 dump 파일을 사용해 dev db에 덮어 씌운다. ( prod와 dev db의 데이터 구조와 데이터들이 꽤나 달라서 dump를 선택)
환경 - azure posgresql db
방법 - https://learn.microsoft.com/ko-kr/azure/postgresql/migrate/how-to-migrate-using-export-and-import
db migration - 현재 db 운영 환경에서 어떤이유로 인해 다른 운영환경으로 옮기는 것을 의미.
db dump - db의 모든 구조 및 데이터등을 포함하여 SQL문의 목록 형식으로 보관하는 것. 데이터베이스 손실 시 내용을 복원할 수 있도록 백업하는 용도로 가장 많이 활용됨.
현재 우리 팀은 신규 서비스를 담당하여 개발하고 있으며, 신규 서비스가 하나가 아닌 여러가지가 계속해서 생겨나고 있다. 그 중 하나의 서비스의 서버개발을 이번에 진행하게 되었는데, 시간이 여유롭지않았지만 구현할 때 충분히 고민하고 내가 짠 코드에 대한 충분한 이해를 가지고 구현했기에 문제가 없을 것이라 자신하며 출시를 진행하였다.
해당 서비스에 별도의 QA절차가 없었으며 코드를 작성한 나는 자만하며 테스트 및 검토를 꼼꼼히 하지 않았다.
그리고 이는 버그 발생으로 이어졌다.
오늘 낮잠을 자다가 부랴부랴 이슈를 해결하였고, 지금이라도 다시 꼼꼼히 검토하고 테스트 해봐야겠다는 생각이 들었던 하루다. (테스트 코드 작성까지 해보자!)
이용자가 추이를 확인할 수 있게 선 그래프를 표현하기 위한 데이터 리스트를 반환해주는 API를 구현하면서 여러 고민이 들었다.
그래프 표현 용 데이터에 대해 저장과 조회 두가지 관점에서 고민하였다.
매 분마다 저장되어있는 테이블의 데이터에 대해서 특정 간격에 따라 데이터를 가져오기 위해 쿼리문에 조건을 추가하여 구현하였다. timestamp (type- datetime) 컬럼이 존재하며,
일(10분 간격) → 분 부분이 10으로 나누어 떨어지는 데이터들 주(1시간 간격) → 분 이 00인 데이터들 월(8시간 간격) → 분이 00이고 시간이 8로 나누어 떨어지는 데이터들 년(1일 간격) → 분, 시간이 00인 데이터들
로 쿼리문을 날려 구현하였다.
쿼리문 예시 - SELECT * FROM table_name tn WHERE tn.timestamp BETWEEN :beforeDate AND :nowDate AND EXTRACT(MINUTE FROM tn.timestamp) = 0 AND MOD(EXTRACT(HOUR FROM tn.timestamp), 8) = 0 ORDER BY tn.timestamp ASC;
EXTRACT는 날짜 함수로써 원하는 날짜 영역을 추출할 수 있다. MOD는 나누기 함수.
현재 골프 선수, 일정, 결과 데이터를 보관하고, 데이터 리스트를 커스터마이징하여 반환해주는 서버를 개발하고있다. (사내 NFT 프로젝트의 일환으로)
경기 결과, 선수의 랭킹 리스트등을 반환해 줄 때 데이터들의 정렬 기준이 있는데, (크게 랭킹 리스트 정렬 기준, 경기 결과 리스트의 정렬 기준) 데이터를 저장할 때는 정렬을 하고 저장하지 않으며 단 정렬값으로 사용될 데이터들을 보관한다. 그리고 조회할 때 order by, where, join을 적절히 활용하여 정렬된 기준으로 리스트를 조회해하는 식으로 구현하였다.
우선 쿼리문으로 작성을 하였는데, oder by의 정렬값으로 사용할 값들이 매핑된 다른 테이블의 값들도 있었으며, 정렬 시, 동점자를 발생시키지 않기 위해 기획적으로 굉장히 여러 정렬값이 존재하여 쿼리문을 작성하는데도 어려움이 많았다. (결국 실장님의 도움으로 해결하였으며 새로운 sql 함수들과 지식들을 알게되었다.)
쿼리문 작성이 끝나고 이제 서버에 typeorm으로 구현을 할 차례인데, 난관이었다. 진행을 하면서 쿼리문법과 orm 구현체 코드의 문법에 대해 평소에 잘 모르다보니 이런 정렬이 가능한지도 가늠이 안되고, 구현하는데까지 너무 많은 시간이 걸렸다. (subquery, leftjoin으로 다른 테이블을 조인하고 다른 테이블의 컬럼을 order by의 정렬값으로 사용하는 것, transaction 범위를 커스터마이징 하는 것 등)
결국 구현을 했지만 구현한 쿼리문보다 더 효율적인 쿼리를 작성할 수 있으려면 쿼리문법과 orm 라이브러리를 좀 더 깊이 있게 학습할 필요가 있다고 생각했던 하루다.
오랜만에 김영한님의 자바 orm 표준 JPA프로그래밍 책을 꺼내서 코드를 따라치고, 서버를 실행했는데 오랜만에 봐서 반가운( 현재 회사에서 nest를 사용 중 )로고를 보여줬는데, 문제는 다음 로그를 보여주지 않았다.
얼른 실행시켜서 확인하고 책을 다음장으로 넘어가고 싶은데 서버가 실행이 안된다.
알고보니 라이브러리의 버전 문제였다. 스프링 부트는 라이브러리의 의존성 버전을 자동으로 맞춰주는데 이 때 충돌이 발생한 것이다.
각 라이브러리의 버전 명시를 제외함으로써 해결.
우리 팀은 모노 레포로 프로젝트들을 관리하고 있다.
이전 회사에서는 서비스마다 레포지토리를 분리하여 관리하고 있었기 때문에 처음 입사하고 모노레포를 clone 받아 코드 구조를 파악할 때 낯설었던 기억이 있었다.
나는 당연히 프로젝트 단위로 레포지토리를 관리하는 것이 CVS의 의도대로 코드를 관리하는 것이며 적합한 방법이라고 생각했는데, 이번에 monorepo로 작업하면서 직접 느끼고, 찾아보면서 다른 시각을 가지게 되었다.
monorepo(여러 프로젝트를 하나의 레포지토리로 관리)의 장점으로 제가 직접 느낀 부분은 모듈화가 간편하다는 점이었다, 여러 프로젝트에 사용할 만한 컴포넌트들을 모듈화해서 손쉽게 공유할 수 있는 것이 장점이라고 느껴졌다. (서로 다른 레포로 관리하더라도 라이브러리화해서 어떻게 공유할 수 있겠지만 고려해야될 부분과 불편한 부분이 많을 것이다. )그리고 여러 라이브러리들의 버전관리가 용이하다는 것도 큰 장점이라 여겨졌다.(특히 버전이 자주 바뀌고, 하위호환이 잘 안되는? Javascript 진영에서는 더욱이 큰 장점이라 생각들었다.)
그리고 한 팀에서 여러 서비스를 개발하고 관리하는 우리 팀의 특성상 monorepo를 사용하는 것이 작업의 효율성을 증대시키는데도 도움이 될 것이라 생각한다. (반대로 이전회사에서는 서비스 별로 팀이 나눠져 있었고, 각 팀 단위로 개발 규칙들이 있을 것이기 때문에 레포를 분리해서 관리하는 것이 편할 것이다.)
구글도 크롬과 안드로이드를 제외한 나머지 코드를 하나의 모노레포로 관리한다고 한다! 레포지토리 용량이 86TB이고, 해당 레포에 하루 커밋수가 40,000정도 된다고 한다. ㅋㅋ
async, await은 비동기 처리를 위한 문법입니다.
비동기 처리를 한다는 것은 비동기로 실행되는 코드를 순서가 보장되도록 처리한다는 의미로 이해했습니다.
(실제 프로세스가 동작하는 순서와 개발자가 작성한 코드의 순서의 싱크를 맞추는 처리 작업으로 이해했습니다.)
예를 들어 어떤 함수에 비동기로 실행되는 메소드가 있을 때, 순차적으로 수행되어야 원하는 로직의 결과가 나오는 경우, 순차 수행이되도록 보장하는 것입니다.
가령 아래와 같이 Dao를 찾아서 출력하는 메소드가 있을 때, 비동기 처리를 하지 않는다면,(findOne은 Promise객체를 반환하는 메소드.) findOne코드 부분의 처리가 if (dao)조건문 처리보다 늦어지게 되는 상황이 발생하는 경우, dao 변수 값은 undefined (혹은 null?)이 되어 실제로 dao가 DB에 있더라도 if 조건문은 실행되지 않게 될 것입니다.
function findDao() {
const dao = this.daoRepository.findOne({
where: where,
});
if (dao) {
console.log(dao);
}
}
아래와 같이 함수에 async 예약어를 붙이고 내부의 비동기 처리를 하고자하는 코드에 await을 붙이게 되면, 해당 코드는 비동기 처리가 되어 코드의 순서가 보장되게 됩니다. 즉, .findOne이 수행되고 이후 조건문이 수행되게 됩니다.
async function findDao() {
const dao = await this.daoRepository.findOne({
where: where,
});
if (dao) {
console.log(dao);
}
}
주의 사항 - 비동기 처리를 하고자하는 메소드는 Promise 객체 타입이어야 정상적으로 비동기 처리가 됩니다. 즉, 위의 예시에서 findOne메소드는 Promise 객체를 반환합니다.
특정 포인트를 기준으로 랭킹 리스트를 반환해주는 API 구현이 필요한 상황.
랭킹 데이터를 어떻게 보관하고 반환해주는 것이 효율적일지 우선 고민해보았다.
결론적으로 기획단에서 정해질 랭킹이 갱신되는 주기가 짧냐, 길냐에 따라 두 가지 방법을 생각하였다.
만약 랭킹이 갱신되는 주기가 짧거나 실시간이라면 랭킹 관련 DB 함수를 사용해서 API 요청마다 계산 후 반환하는 것으로 계획하였으며, 랭킹과 관련된 함수는 일반적인 정렬 함수보다 효율적으로 특정 컬럼을 기준으로 레코드 순위를 정해주는 것으로 이해하였다. 만약 랭킹이 갱신되는 주기가 길다면, 갱신되는 시점에 랭킹을 계산해 DB에 저장하고, 그 사이에는 계산된 랭킹 순으로 데이터를 반환해주기만 하는 것이 효율적일 것이다.
결론적으로 내가 구현하는 서비스의 특성상 특정 경기가 종료될 때마다 랭킹이 갱신되며, 경기의 텀이 일주일정도 있기 떄문에 후자의 방법으로 구현하였다.
참고자료 : postgresql 랭킹 함수 , azure에서 지원하는 game 관련 서비스의 ranking system
JPA 공부를 하다가 실습 테스트 코드를 작성중에 고민이 들었다.
아직 테스트코드 작성에 익숙하지 않고, 가장 베스트인 단위 테스트 코드가 무엇인지 고민해나가는 단계이다.
테스트 코드 작성을 익히기 위해 지난 회사 온보딩 기간에 인증서버 테스트코드 작성을 업무로 가져가면서 많은 검색과 고민을 반복했었는데 오랜만에 테스트코드를 작성하려니 새로 작성하는 기분이다.
entityManager를 사용해 간단하게 회원가입하는 로직을 테스트하려는 도중에 또 어느 정도까지 테스트 코드를 작성해주어야하는지 고민이 든다. (이전에도 같은 고민을 한 것 같기도 하다.)
단위테스트에 걸맞게 의존성을 최소화하기 위해 mocking을 해준다. repository가 mock객체이기 때문에 실제 db에 저장되지는 않을 것이며 그러면 저장된 값을 임의로 지정해주어 테스트해준다.
(왜냐하면 repository 반환값을 반환하도록 짜게되면, 단위테스트 시 실제 repostory는 null을 반환할 것이고(mock객체기 때문에)그러면 테스트 대상인 join 메소드의 반환값도 지정해주어야하는데 이렇게 반환되는 값들을 모두 지정해주는 것이 테스트의 의미를 더 퇴색시키는 느낌이라 생각했다.)
도메인 모델 패턴 - 비즈니스 로직 대부분을 엔티티에 작성하고 서비스 계층은 엔티티에 필요한 요청을 위임하는 역할의 형태로 객체지향의 특성을 적극 활용하는 형태.
트랜잭션 스크립트 패턴 - 엔티티에는 비즈니스 로직이 거의 없고 서비스 계청에서 대부분의 비즈니스 로직을 처리하는 형태.
그렇다면 둘 중에 베스트는 무엇일까 ? 혹은 두 패턴의 장단점은 무엇일까?
우선 내가 생각했을 때는 자주 사용되는 메소드의 경우 엔티티에 작성하는 것이 객체지향적이라고 생각이 든다. 다만 그렇지 않은 경우 비즈니스로직은 서비스 계층에 작성하여 엔티티와 서비스 레이어의 각 역할을 명확히 하는 것이 좋지않을까하는 생각이다.
나는 현재 회사에서 혼자 개발하고 있다.
오늘은 내가 담당하고 있는 프로젝트가 사실은 나 혼자 개발하고 있는 프로젝트가 아니라는 깨달음을 준 사건을 기록하고자 한다.
문제는 어제 저녁에 발생했다. 쿠폰 기능 출시가 코 앞으로 다가왔고, 빠른 테스트 → 수정 → 반영의 반복이 스테이징 환경에서 이뤄지고 있는 상황이었다.
그런데 갑자기 스테이징 환경으로의 github action 배포과정에서 gradle build에서 실패를 반복해서 하는 것이다.
로그는 iamport-rest-client-java 라이브러리를 해결할 수 없다는 문구였다.
마침 또 아임포트 스테이징용 계정을 새로만들어 적용하는 시점에 발생한 에러였기에 뭔가 아임포트 관련해서 문제가 있으리라 짐작하였고, 라이브러리 버전이 최신 버전이 아니었기 때문에 해당 버전을 최신 버전으로 올렸더니 잘 배포가 되었다.
그러고 작업이 남아 집에서 다시 다른 브랜치(새로 만든 아임포트 계정을 반영하지 않은 브랜치)로 배포를 진행했는데 동일한 로그로 배포에 실패하는 것이다..!
뭔가 잘못됬음을 느꼈다. 이 후에 해당 브랜치도 아임포트 라이브러리의 버전을 변경해보았고 변경해도 실패하였다.
이후로 여러가지 원인분석을 하였는데, 결론은 상황에 관계없이 규칙적이지 않은 결과를 보였다. (배포가 실패하고 성공하는 기준이 규칙성이 전혀없음.)
오늘 아침에 기존에 같은 팀에 계셨던 사수께 양해를 구하고 허들을 요청했다. (젠틀하고 명석하신 분이시다.)
함께 원인을 파악하다보니 발견한 엄청난 사실.. iamport라이브러리는 jitpack이라는 서비스에서 관리되었고 해당 jitpack api 들이 다 다운 된 것이다.
또 공교롭게도 해당 서비스를 담당하는 개발자 분들은 휴가신 것 같았다.
아임포트 개발자분들께 해당 상황을 문의드렸고, 전 세계적으로 동일한 문제이며 해당 회사에서도 대응을 기다리고 있다는 답..
다른 팀의 개발자분의 조언으로 아임포트라이브러리를 내장 라이브러리로 프로젝트에 삽입하고 연결하여 해결은 하였지만, 정말 벙찐 순간이었다.
이번 사건을 계기로 내가 짠 코드에 옆에는 없지만 많은 개발자분들이 함께 작업하고 있다는 것을 느꼈다.
동지들
홀리
다행히 잘 해결됨ㅎㅎ
최근 사내에서 신규로 출시한 웹서비스의 유지 보수 및 기능 고도화 작업을 진행하고 있다.
프론트와 백엔드 개발은 혼자서 담당하고 인프라 쪽만 데브옵스 개발자 분들이 도와주고 계시는데, 프론트와 백엔드를 모두 담당하면서 얻게 된 깨달음이 있어 기록을 남긴다.
사이드 프로젝트로 간단한 앱을 만드는 프로젝트를 6개월 째 진행하고 있는데, 해당 프로젝트에서는 백엔드만 담당하여 API의 응답 값이 프론트에서 어떻게 다뤄지는지에 대한 고민을 해보지 못했다. 단순히 프론트 개발자분과 약속을 통해, 응답 데이터에 status, data, message 정보를 담아 보내기로(badRequest, notfound, internal server error 등 모든 예외에 대한 응답을! ) 약속만 하고 그냥 그 약속을 지키기만 했다.
그러다가 회사 업무를 하면서, 한가지 이슈를 통해 응답 처리에 대한 고민을 하게 되었다. 이슈는 다음과 같다.
쿠폰을 발급하는 기능을 구현하였고, 해당 유저가 쿠폰을 이미 발급받은 경우(디비에 발급받은 쿠폰이 있는지 조회) 커스텀하게 만든 Response 객체에 data로 badRequest를 담아서 리턴하도록 API를 만들었는데(약간은 다르지만 사이드 프로젝트에서 하던 방식과 비슷하게) 프론트단에서 실행해보면 중복으로 발급해도 정상적으로 동작을 하는 것 처럼 보이는 것이다.
크롬 개발자 모드로 들어가보니 서버는 응답으로 badrequest를 데이터로 반환하였지만 응답 상태는 200(초록불)이었던 것이다. 또한 프론트 코드에서는 try,catch문으로 로직이 작성되었기 때문에 해당 응답은 정상처리가 되어 별도의 다른 처리를 하지 않았던 것.
이 때 선택지는 두가지임을 깨달았다.
첫번째로 try,catch로 예외를(여기서는 쿠폰이 이중발급되는 상황) 처리하는 것이 아닌 응답 데이터 값으로 조건문을 통해 처리하는 것.
두번째로 서버에서 응답 객체를 반환하는 것이 아닌, 예외를 발생(throw)시키고 프론트엔드에서는 try catch를 통해 해당 예외를 처리하는 것.
그리고 try catch와 예외발생으로 처리하는 것이 해당 기능을 잘 사용하는 것이고, 또 로직적으로 깔끔하다는 것을 꺠달았다.
또한 이전에 서버 관점에서만 생각할 때, 예외를 발생시키면 프론트에서 어떻게 처리하는지 추측이 안되서 예외를 최대한 발생안시키려고( js에도 try catch가 당연히 있음을 알았음에도, 프론트의 코드를 볼일이 없었으니 어떻게 처리하는지를 몰랐다.) 했었는데 이 때 추측하지 못했던 것들을 깨닫게 되었다.
처음 사내에서 해당 프로젝트를 담당하면서 고민이 많았는데 (프론트, 백엔드 두가지 모두 맡게되어) 두 가지를 모두 담당함으로써 얕지만 새로 얻는 지식들이 있음을 느끼고 있다.
AWS에서는 아주 아주 많은 세미나 및 교육 프로그램을 제공한다.
구체적인 교육 프로그램 구성이나 절차에 대해 알지는 못하지만, 체감적으로 한달에 1-2번은 나에게 필요한 교육 프로그램이 열리는 것 같다. (메일, 광고를 통해 주로 교육이 열린다는 것을 알게 된다.)
이전 부터 신청은 2,3번 했었지만, 일반적으로 낮에 세미나가 열리거나 몇일에 걸쳐 진행이 되었고, 당시에는 나의 주된 관심사가 아니었기에 결국 한번도 들어보지 못했었다.
요즘 온라인 스터디에서 진행하는 프로젝트가 배포단계를 거치고 있는데, lightsail로 배포를 계획하게되어 겸사겸사 세미나를 신청하게 되었다. (신청하면서 몇번의 고민이 있었음.. 또 안들을 것 같아서)
결국 AWS 첫 세미나를 참석하게 되었고, lightsail을 이용해 wordpress 블로그를 배포하는 절차를 통해 lightsail을 학습할 수 있었다.
또 부하테스트를 진행할 수 있다는 것을 새로 알게 되었고 진행해보아야겠다는 생각을 하게되었다.
1시간 30분동안 진행하며, 질의도 가능하기에 세미나에서 교육하는 기술에 대해 처음 접하시는 분이나 이미 사용하고 있지만 평소 궁금한 점이 있었던 분들도 들으면서 많은 것을 얻어 갈 수 있는 시간이라 생각된다.
관심있는 교육이 열리면 하나씩 참여해봐야지!!
사내에서 담당 개발 중인 채용 사이트의 admin페이지 계정이 평문으로 DB에 저장되어있는 것을 확인하였다.
지난주 면접(N사)에서 암호화와 관련된 질문을 받았던 적이 있어서 채용 사이트 어드민 계정 암호화를 진행하면서 정리해보자.
Hash와 Encryption
두 가지 모두 암호화 기법이지만 Hash는 단방향 암호화 기법이며 Encryption은 양방향 암호화 기법이다.
따라서 Hash는 암호화가 된 값을 다시 원래의 평문으로 돌리는 것이 불가능하지만 Encryption은 가능하다.
평문에 임의의 값들을 덧붙여 해시함수에 넣는 것을 말한다. (패스워드에 소금을 치는 것.)
이렇게 하면 값의 길이가 길어져 Rainbow Table(해시 함수를 사용하여 만들 수 있는 값들을 왕창 저장한 표, db)를 이용해도 쉽게 알아내지 못하도록 할 수 있다.
나는 spring security 프로젝트의 BycryptPasswordEncoder를 사용하고자한다.
사용한 이유는 다음과 같다.
로그인 시 db의 패스워드와 비교하는 로직은 다음과 같다.
→ DB의 암호화된 패스워드를 복호화하여 입력받은 패스워드와 비교할 수도 있지 않을까?라는 생각이 들 수 있지만 해시알고리즘을 사용하기 때문에 한번 암호화된 값은 복호화가 불가능하다. 따라서 동일한 값을 해시 함수에 넣을 경우 항상 동일한 해시 값을 리턴하는 것을 이용해 인증을 한다.
→임의의 salt값이 붙어져서 암호화 되기 때문에 같은 패스워드라도 암호화된 값은 매번 달라질 수 있다. 따라서 equals가 아닌 클래스에서 지원하는 matches 메소드를 사용하여 비교한다.
해시 함수는 완벽하지 않다.
충돌이 발생할 수 있으며 충돌이 발생한다는 것은 다른 값에 대해 동일한 해시값이 발생할 수도 있다는 것이다. 따라서 동일한 해시값이 적게 발생하는 해시 함수가 좋은 함수이다.
또한 암호화가 아닌 검색(조회) 속도 향상을 위해 만들어진 것이기 때문에 부르트포스 방법으로 임의의 값을 넣어 대면 해킹을 당할 수도 있다.
참고자료
주말마다 감사하게도 온라인 스터디를 진행하고 있다.
이번 스터디에서 기본적이지만 평소에 생각해보지 않았던 것이 생겨 글로 당시의 깨달음을 남긴다.
구현된 API중에 GET Method로 정보를 요청하는 API가 있다. 해당 API는 요청 파라미터로 4가지의 파라미터를 필요로한다.
나는 문득 생각이 들었고 해당 코드에 리뷰를 남겼다.
“4가지 값들을 파라미터로 받는 이유가 있을까요?”
해당 리뷰를 남긴 이유는 경로 파라미터로 4가지를 넘겨주는 것보다는 body로 넘겨주는 것이 낫지 않을까? 하는 생각이 들었기 때문이다.
여기서 팀원분들의 의견을 듣다가 알게된, 내가 잊고 있었던 개념이 있다.
관례적으로 GET Method는 Body를 사용하지 않는다는 것이다.
(웹 개발자로 진로를 준비하던 오래되지 않은 과거에 이러한 개념을 공부했던 기억이 났다..ㅋㅋ
POST와 GET의 차이는 무엇인가요 ? → POST는 body에 데이터를 담고, GET은 uri에 담는다. GET은 url에 데이터가 바로 드러나며 POST는 바로 드러나지는 않지만 Client가 확인할 수 있기에 보안상 데이터 암호화가 필요하면 둘다 해야한다..와 같은 기억이 새록새록)
stackoverflow에서 GET메소드에 body를 사용하는 것에 대해 많은 사람들이 함께 고민을한 흔적들을 볼 수 있었다.
질문글을 요약하면 다음과 같다.
‘어플리케이션을 위한 새로운 RestFul 웹서비스를 만들고 있다. 특정 Entity들을 얻기위한 GET동작 API를 만들고 있으며 나는 GET요청을 위해 사용되는 parameter를 reqeust body에 담아 요청할 수 있게 하고 싶다. HTTP/1.1에서는 이를 금지하고 있지 않는 것으로 보인다. 이러한 방법(body에 parameter를 담는 것)은 더욱 명확한 요청을 할 수 있게 하고 복잡한 XML 요청을 쉽게 할 것이다.’
채택된 답변을 내용을 보면 간략하게 다음과 같다.
‘HTTP/1.1 문서를 보면 “그러한 방법을 권장하지 않는다.”, “GET 메소드는 “URI를 통한 요청”으로 정보를 얻는 것을 의미한다.”와 같은 내용이 있다. 즉 GET으로 바디에 값을 담아 요청을 하는 것이 가능은 하지만 바디의 값은 어떠한 의미도 갖지 않는다.’
그리고 해당 답변에 업데이트된 내용이 있다. 2014년도 HTTP/1.1 문서에서는 앞서 말한 문서의 내용이 삭제 되었고, 요청 데이터를 담는 것은 메소드의 의미론과는 독립적인 개념이라는 내용으로 대체되었다는 내용이다.
그리고 부가적인 코멘트의 내용들 중 elasticsearch는 GET요청시 body에 data를 담아 전달하는 대표적인 프로덕트라는 내용이 있었다.
elasticsearch Getting Started 문서를 보면 다음과 같은 내용을 확인할 수 있다.
요약 : RFC 문서에 따로 GET메소드에 body를 사용하는 것에 대한 제약조건이 없기 때문에 사용할 수 없는 것은 아니며, elasticseach 관리자는 body를 사용하더라도 의미적으로 정보를 조회하기 때문에 GET 메소드를 사용하는 것을 선호한다. 다만 언어적으로 GET메소드에 body를 담는 것을 허용하지 않는 언어들이 있기 때문에 POST또한 당연히 지원을 한다. 가령 javascript의 http 라이브러리는 해당 방식을 허용하지 않는다.
Spring에서 테스트를 해보니 GET 요청 시 body에 값을 담아보내고 @RequestBody로 값을 받을 경우 별도의 예외처리가 되어있지 않다.
stackoverflow 해당 내용을 보면 SpringMVC에서도 과거에는 해당 방법을 허용하지 않았던 것 같다. v5.3.6(spring)이후로 GET 요청에 body에 데이터를 담아 보내는 것을 허용했다는 코멘트는 확일할 수 있다.
2014년도를 기점으로 HTTP 문서에서 메소드정의와 데이터 요청 처리 방법은 별개의 개념이라는 것을 명시하였다.
elasticsearch는 GET 메소드에 body를 사용하는 것을 권장한다.
하지만 소위 말하는 RestFul하게, HTTP Spec을 준수하여(지금은 HTTP Spec에 관련 내용은 삭제되었지만) 예전부터 관례적으로 룰을 정해 사용해왔기 때문에 이러한 설계 규칙을 벗어나는 것은 함께하는 공동체의 동의 및 부수적인 고민들이 필요할 것이다.
일주일간의 온보딩 기간 후에 두가지 태스크를 정하여 두달간 진행하게 되었다.
그 중 하나의 태스크는 바로 채용 사이트 담당 개발!
이미 1차적으로 만들어져있는 상황이며 추가적인 요구사항에 맞춰 공지사항과 몇가지 수정, 전반적인 코드리팩토링을 진행하게 되었다.
(외주로 급하게 만든 프로젝트이기에 이후에도 안정적인 유지 관리를 위해 리팩토링 하기로 결정.)
기존에 배포되어있는 환경(ec2)에서 eks로의 프로젝트 이전이 필요했으며 프론트 작업도 필요했기에 꽤나 여러분과의 커뮤니케이션이 필요한 작업이었다.
devops 엔지니어와의 소통, 프론트 엔지니어와의 소통, 디자이너와의 소통, 인수인계 해주신 백엔드 개발자와의 소통..!
결과적으로 2주간의 작업 끝에 오늘 배포를 진행하였으며 공지사항의 이미지 업로드 기능을 제외한 채 배포를 하게 되었고 이미지 업로드 기능은 차주 수요일 배포로 연장하게 되었다..
다행히 급한 요구사항이 아니어서 늦출 수 있었지, 만약 급한 요구사항이었다면 굉장히 난감한 상황이 생길 뻔했다.
이렇게 약간은(?) 아쉬운 결과가 나오게된 원인을 생각해 봤다.
그 원인은 바로 바로 여러명의 인원이서 함께 작업을 진행할 때, 결코 나의 계획대로 진행되지는 않는다는 것을 몰랐고 그래서 계획에 차질이 생겼을 때 대처할 만한 준비를 하지 않았다는 것이다.
다양한 사람들이 각자의 상황이 존재하기 때문에 당연하게도 내가 계획한대로 진행되기에는 변수가 너무 많은 것이다.
다음 부터는 항상 최악의 상황, 혹은 다양한 변수를 고려하여 업무를 진행할 필요가 있다는 것을 깨달은 하루였다.
오늘 코드 리뷰를 받으면서 @Data와 @Setter를 지양하는 방향으로의 수정을 제안 받았다.
(이 때 @Setter는 객체 초기화가 아닌 필드 수정 시 사용되는 상황입니다.)
해당 리뷰를 통해 언급한 두가지 어노테이션을 지양해야되는 이유에 대해 고민해보았다.
@Setter를 클래스에 적용하면 해당 클래스의 필드들을 수정하는 메소드가 모두 생성이 된다. 수정 가능성이 없는 필드들에 대해서도 수정 메소드가 생기는 것은 원하지 않는 동작이 발생할 가능성을 만들어낸다.
즉, 객체의 일관성을 유지하기 어렵게 만든다.
필드에 @Setter를 적용하면은?? 그러면 위 문제는 해결된다고 생각한다. 지양해야되는 다른 이유가 또 무엇이 있을까??
리뷰를 주신 분께서 앞전에 다른 레포에서 의견이 오고갔던 @Setter사용 관련 코멘트들을 보여주셨고 해당 의견에는 이러한 내용도 있었다.
“@Setter를 사용하는 것이 아닌 메소드를 따로 구현하면 메소드 명을 통해 해당 값을 변경하는 의도를 좀 더 명확히 표현할 수 있습니다.”
즉, @Setter 수정 메소드를 사용함으로써 코드 가독성을 높이고 유지보수측면에서 이점을 가져갈 수 있다.
별개로 @Setter를 지양하는 것에 대해 구글링을 해보니, 객체를 생성하여 값들을 초기화하는 상황에서 @Setter를 지양해야한다는 글들이 많아 해당 내용도 간략히 정리해보자.
언급한 상황에서 @Setter를 사용하면 두가지 문제점이 있다.
수정할 때 @Setter를 사용하는 상황과 비슷한 문제점이다.
이를 해결하기 위한 방법으로는
이 있다.
생성자를 사용하면 인자들이 다양하게 들어오는 것에 대해 일일이 생성자들을 만들어주어야하며 어떤 필드에 어떤 값이 들어가는지 확인이 어렵기 때문에 가독성이 떨어지는 문제가 있다.
빌더 패턴을 사용하면 이러한 문제들을 해결할 수 있다!
지속 가능한 소프트웨어 설계 패턴: 포트와 어댑터 아키텍처 적용하기
회사에 입사한지 일주일정도가 다 되가는 시점..! 노션을 이곳저곳 기웃거리던 중에 흥미로운 글을 발견했다.
입사 면접 당시 아키텍쳐에 대한 책을 읽어보거나 공부를 해본적이 있냐는 질문을 받은 기억이 났다. 또한 3개월간 인턴 근무를 했던 이전 회사에서 프로젝트를 설계할 때, 사수에게 어떤 아키텍쳐를 도입할 계획인지에 대해 질문을 받았던 기억이 났다.
점점 더 큰 규모의 프로젝트를 접할 기회가 생기면서 DDD, TDD등과 함께 아키텍쳐 설계에 대해 공부해야할 필요성을 느끼고 있던 와중에 새로운 아키텍쳐 이름을 발견했다!
헥사고날, 육각형 설계 방식은 어떤 것일까
좋은 분들과 진행하고 있는 디자인 패턴 스터디가 장장 3달을 이라는 시간이 흘러 마지막 주가 되었다.
마지막으로 정리를 담당하였는데, 정리를 위해 스터디한 내용을 다시 읽어보니 내가 이걸 공부했었나 싶은 놀라운 상황이..
언젠가 써먹을 때가 있겠지 싶어 그래도 개념들을 다시 한번 정리해보자.
사실 디자인 패턴이라는 개념에 어떤 식으로 접근을 해야할지 스터디 마지막 주까지도 감이 잘 오지 않는다.
그래서 현직자의 시선을 빌려보고자 여러 개발자분들의 블로그에 디자인 패턴에 대한 내용이 있는지 찾아보다가 현재 인프런 CTO를 맞고 게신 이동욱님의 블로그의 포스트로 들어가게 되었다.
자바지기(박재성)님의 세미나 내용 정리 글이었다.
좋은 글귀와 함께, 스터디의 막바지에 와서도 디자인 패턴에 대한 감이 잘 오지 않는 내가 정상이라는 것을 말해주는 문장이 있다.
맞다. 사실 지금의 나한테 디자인 패턴은 반드시 필요한 개념은 아닐 수 있다.