Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 42 additions & 0 deletions 2026/Street_Coder/ymkim97/chapter4_5_6.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
# 스트리트 코더
## 4장 ~ 6장
---
## 논의 내용
* 회사의 보안을 위해 무엇을 할 수 있을지, 또는 향상에 기여해보신 경험이 있으시다면 얘기해 보고 싶습니다.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

그런 활동을 해본 적이 없긴 합니다.
지금은 프레임워크 레벨에서 대부분 기본적인 보안 관련된 처리를 쉽게 해주기 때문에
사람의 실수가 가장 큰 보안 위협이지 않나 싶네요.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

음.. 저도 그런 활동을 해본 적이 없네요

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

보안이라고 하는게 범위가 되게 넓어서, 꼭 코드를 작성하는게 아니더라도 개선 자체는 이것저것 해봤습니다

제가 현재 하고 있는 업무가 주로 외부 중개사들과 API연동 하는 작업이 많다보니, 내부 정보를 외부에 직접적으로 노출시키지 않는 다는 관점에서 해본 것은

  1. 외부사 연동 시, 서버 앞단에 CDN(Akamai) 배치 후, WAF 용도로 활용
    • 외부 중개사 서버 IP 화이트리스트 관리
  2. API gateway를 내부 서버 앞단에 배치하여 인증/인가를 통합처리함
  3. 인증 체계 변경(업체별 고정 인증토큰 에서, 업체별 동적으로 생성하는 인증토큰)
  4. 외부로 공유하는 API spec 문서에 대외비 표시하기

애플리케이션 단에서는

  1. 라이더 입직(회원가입) 프로세스를 순서대로 진행하는 것을 강제하기위해서, 입직 서버에서 가지고 있는 대칭키로 암호화한 토큰을 발행해서, 전단계의 토큰이 있어야 다음 단계로 갈 수있도록 강제
  2. 민감정도(주민등록번호, 이름, 전화 번호 등) DB 저장할 때, 대칭키로 암호화해서 저장하기
  3. admin 에서 민감정보 노출 시킬 때, 마스킹 처리
  4. admin 운영자 권한에 따라서, 민감정보 노출도 레벨 조정
  5. 라이더 탈퇴 시, 개인정보 보관기간 준수 및 일정 기간 이후 하드 딜리트 및 백업 처리

대충 기억나는건 요정도가 있네요

* 저는 회사에서 연초에 진행했던 모의해킹 - 취약점 분석에서 나온 부분 일부를 보완했었는데요, 예상외인 곳에서 잘 처리되고 있지 않았다는 것에서 놀랐습니다.

## Chapter 4- 맛있는 테스트
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

Chapter 5의 형식(-)과 일관성을 유지하기 위해 하이픈 앞뒤로 공백을 추가하는 것이 좋습니다.

Suggested change
## Chapter 4- 맛있는 테스트
## Chapter 4 - 맛있는 테스트

많은 개발자가 생각보다 많이 쓰지 않는 테스트의 중요성을 알려주며 강조한다.
요즘에는 AI로 인해 테스트 작성 진입 장벽이 정말 많이 낮아졌으나, 중요성은 변함 없다고 생각한다.
나도 분명 테스트가 중요하다는 것을 알지만 왜 업무를 하면서는 잘 쓰지 않았는지 고민했었는데, 책에서 말하는 것이 딱 와닿았다.

> *소프트웨어 개발의 일부가 아니라는 인식 때문에 개발자들은 테스트를 외부적인 활동으로 생각하며, 가능한 한 참여하지 않으려고 한다.*

나도 모르게 무의식적으로 개발의 일부가 아니라는 것이 있었다고 생각하며 반성했다.

테스트 작성은 소프트웨어를 당연히 향상 시키면서도, 개발자의 생활 수준도 향상시킨다.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

'-시키다'는 접미사이므로 앞말에 붙여 쓰는 것이 올바릅니다.

Suggested change
테스트 작성은 소프트웨어를 당연히 향상 시키면서도, 개발자의 생활 수준도 향상시킨다.
테스트 작성은 소프트웨어를 당연히 향상시키면서도, 개발자의 생활 수준도 향상시킨다.

나중에 코드를 완전히 잊은 후에라도 코드 동작을 중단시킬 걱정 없이 중요한 코드를 쉽게 변경할 수 있기 때문이다.
그러나, 테스트 코드를 오로지 커버리지를 높이기 위해서 작성하면 위와 같은 목적에 달성할 수는 없다고 생각한다.

책에서 소제목으로 중간에는 “테스트를 작성하지 마라” 라는 내용이 있다.
처음부터는 테스트가 얼마나 중요하고 필요한지 설명하다가 조금 뜬금 없어서 혼란스러웠지만, 결국은 다음과 같은 내용이었다.
존재하지 않는 코드를 테스트 하지마라, 모든 테스트를 작성하려고 하지마라.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

'테스트하다'는 한 단어이므로 '테스트하지'로 붙여 쓰고, 보조 동사 '마라'와는 띄어 쓰는 것이 올바릅니다.

Suggested change
존재하지 않는 코드를 테스트 하지마라, 모든 테스트를 작성하려고 하지마라.
존재하지 않는 코드를 테스트하지 마라, 모든 테스트를 작성하려고 하지 마라.


## Chapter 5 - 보람 있는 리팩터링
저자는 리팩터링에 대해서 특히 다른 팀원 개발자들과 협업하면서 어떻게 진행하는 것이 좋은지 집중하는 것 같았다.
보통 다른 책에서는 리팩터링 방법, 자체에 대한 내용을 다루지만 해당 책의 저자는 다른 개발자와의 충돌 등도 잘 고려해야 한다는 것을 알려주는 것이 좋았다.

더 쉽게 리팩터링되도록 리팩터링하는 내용에서 종속성 주입에 관한 이야기도 나온다.
당연하게 받아들이고 있는 종속성 주입에 대한 이름에 대해서도 비판적인 시각을 조금 들어내는데, 확실히 저자의 나름 시각?이 있는 것 같았다.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

'들어내다'는 물건을 밖으로 옮긴다는 뜻입니다. 저자의 시각을 보여준다는 의미로는 '드러내다'가 올바른 표현입니다.

Suggested change
당연하게 받아들이고 있는 종속성 주입에 대한 이름에 대해서도 비판적인 시각을 조금 들어내는데, 확실히 저자의 나름 시각?이 있는 것 같았다.
당연하게 받아들이고 있는 종속성 주입에 대한 이름에 대해서도 비판적인 시각을 조금 드러내는데, 확실히 저자의 나름 시각?이 있는 것 같았다.


책 중간 곳곳에 농담을 던지는 부분들이 보이는데, 솔직히 읽는데 조금 방해가 된다는 느낌이 없지않아 있다.
그래도 리팩터링을 무조건 장려하는 것이 아니라, 어떠한 상황에서는 오히려 리팩터링을 피하거나 최소한 연기하는 것을 고려해야하는지 조언하는 부분이 인상적이었다.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

'고려해야'와 '하는지' 사이에는 공백이 필요합니다.

Suggested change
그래도 리팩터링을 무조건 장려하는 것이 아니라, 어떠한 상황에서는 오히려 리팩터링을 피하거나 최소한 연기하는 것을 고려해야하는지 조언하는 부분이 인상적이었다.
그래도 리팩터링을 무조건 장려하는 것이 아니라, 어떠한 상황에서는 오히려 리팩터링을 피하거나 최소한 연기하는 것을 고려해야 하는지 조언하는 부분이 인상적이었다.


## Chapter 6- 조사를 통한 보안
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

Chapter 5의 형식(-)과 일관성을 유지하기 위해 하이픈 앞뒤로 공백을 추가하는 것이 좋습니다.

Suggested change
## Chapter 6- 조사를 통한 보안
## Chapter 6 - 조사를 통한 보안

보안 사고가 날이 갈수록 증가하는 요즘에 읽기 좋았던 것 같다.
회사의 보안 담당자에게도 늘 듣는 것이지만 보안은 절대라는 것이 없고, 어떻게든 뚫릴 수 있는 것이긴 하다.
그러나 위협 모델링을 통해서 의식해서 보안을 염두에 두고 설계를 진행하면 장기적으로 훨씬 더 좋아진다.

유명한 SQL Injection을 소개하면서 이스케이핑 처리 또는 parameterized query 등을 이용하여 방지법을 소개한다.
그 후 XSS, CSRF 등 기본적인 악의적 요청에 대해서도 설명해준다.
내가 예전에 조금 관심을 가졌었던 암호에 대해서도 짧지 않게 설명해주는 부분을 재미있게 읽었다.
Loading