Open
Conversation
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
TaeHyoungKwon
added this to the
Street Coder: The Rules to Break and How to Break milestone
TaeHyoungKwon
added
2026
Street Coder: The Rules to Break and How to Break
TaeHyoungKwon
requested review from
GeunJuLEE,
benscookie,
chichoon,
dhlee3994,
jongfeel,
tttghost and
ymkim97
|
우측에 있는 |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Code Review
This pull request adds reflection notes for chapters 4, 5, and 6 of "Street Coder," covering topics such as pragmatic testing strategies, the purpose of refactoring for maintainability, and fundamental security principles like threat modeling and least privilege. The review feedback correctly identifies several typographical errors in the Korean text, including incorrect word choices and trailing characters, and provides appropriate suggestions for correction.
| - 이전 아카데믹 컨퍼런스에서 틱톡에서는 테스트 코드를 작성하지 않는다고 말씀해주시는 것을 들었던 적이 있었다. 내가 이걸 기억하는 이유는 당시에 나 스스로 테스트 코드는 반드시 작성해야하는 대상으로써, 바라보고 있었기 때문이다. 테스트는 반드시 작성해야한다는 일종의 편견이 있었던 것인데, 그 편견을 깨는 얘기였기 때문이다. 책에 나오는 페이스북의 사례도 비슷한 맥락인데, 테스트를 작성해야할지 말지에 대한 것은 그 회사와 구성원의 철학 혹은 상황에 맞는 적절한 조치, 문화로 보는게 맞지 무조건 정답이 아니라는 뜻이다. 만약에 회사의 철학이 버그가 발생하면 빠르게 고치는 것이라면, 테스트 코드는 오히려 병목이 될 수 있다. 코드 리뷰도 마찬가지인데 무조건 장점만 있는 것은 없다. 어떤 면에서 장점이 있다면, 어떤 면에서는 단점이 있는 것이다. 이를 선택하는 것은 각 구성원들의 선택이다. 선택할 때, 나 그리고 우리팀이 의도하는 바는 무엇인지에 대해서 확실히 정하고 그대로 이행해서 문제가 없으면 된다고 생각한다 | ||
| - 자동화된 테스트가 없이 운영되었기 때문에 수많은 오류와 서버의 다운타임을 겪어야만했다 라고 말하는 내용에 대해서는 그 사람의 경험 하에서는 그렇게 볼 수 있지만, 일반적으로 그렇다고 볼 순 없다고 생각한다. 꼭 자동화된 테스트가 없다는 것 외에도 그 외 다른 요인들도 많기 때문이다. 책에서 말하는 자동화 테스트의 장점은 모두 자동화 테스트를 매우 잘 작성하고, 잘 관리했을 때는 전제로 한다. 만약에 자동화된 테스트 작성 자체부터 제대로 안되었다면? 그렇다면 테스트가 있더라도 수많은 오류와 서버의 다운타임은 겪을 수 있다. 그냥 안된 이유 중하나가 자동화된 테스트가 없었던 것이였는데, 그게 전부라고 생각했던 것은 아닐까? 라는 생각도 든다. | ||
| - 테스트 코드를 작성할 때 얻는 흔한 장점은 회귀 테스트가 가능하다는 것이고, 리팩토링을 훨씬 더 수월하게 할 수있다는 점이다. 하지만 이 장점들은 모두 테스트 코드를 잘 작성해야하며, 의도에 맞게 작성해야만 회귀테스트도 기대한 대로 할 수 있고, 리팩토링도 가능해진다. 이 사실을 모른채 무작정 테스트 코드를 어떤 형태로도 작성하면 도움이 될 것이다라고 생각한다면, 오히려 이 테스트 코드들 때문에 더 고통 받을 가능성이 크다 예를 들어서, 회귀 테스트의 목적은 새로운 기능을 수정 혹은 추가 했을 때, 이전 기능들이 영향을 받지 않았는지를 확인하기 위한 테스트인데, 애초에 테스트 코드의 커버리지가 내가 인지하는 만큼 채워지지 않았던지 엉뚱한 형태로 작성 되었다면, 내 기대를 충족시킬 수 없다. 리팩토링의 경우에 내가 어떤 테스트를 작성했느냐에 따라 내 리팩토링의 범위가 결정되는데, 단위 테스트 단위로 작성하게 되면, 내 리팩토링의 범위도 단위 테스트의 범위로 줄어들게 된다 이게 내 의도가 맞다면 괜찮지만, 내 리팩토링 의도가 단위 테스트 이상의 통합적으로 비즈니스 로직을 체크해보고 싶은 거였다면, 이 단위 테스트는 아쉽지만 쓸모 없게 된다. | ||
| - 내 경우 최근에는 테스트 코드를 내 이득을 위해서 작성한다 에 취중 되어있다. 과거의 무작정 테스트 코드 부터 작성하던 습관에서 벗어나서 좀 더 실용적인 관점에서 접근하는 것이다. 내가 생각했을 때, 가장 중요한 것은 현재 내 상황에서, 내가 테스트해야하는 이유는 무엇이고, 자동화된 테스트가 왜 필요한가에 대해서 스스로 답을 할 수 있어야 한다는 것이다. 내가 작업하는 기능이 매우 간단하고, 버그가 좀 나도 핫픽스하면되고, 나혼자 유지보수를 하며, 추후 수정가능성도 높지 않다면 나는 과감하게 테스트 코드를 작성하지 않는 선택을 할 것 같다. 다만, 내가 생각했을 때 어떤 부분이 매우 복잡하고 제대로된 자동화 테스트를 만들지 않으면 테스트하기 매우 곤란한 상황이면서, 나 외 내 동료들도 다같이 꼼꼼하게 봐야하는, 문제가 생기면 큰일 나는 코드라면, 테스트 코드를 오히려 엄청 빡빡하게 모든 경우의수를 꼼꼼이 따져서 작성하지 않을까 생각된다 이렇듯 내 상황과 의도에 따라서 테스트 코드를 작성할 수 있어야 한다고 생각한다 |
Contributor
There was a problem hiding this comment.
'취중'은 술에 취한 상태를 의미하므로 문맥상 '치중'이 적절하며, '꼼꼼이'는 '꼼꼼히'의 오기입니다.
Suggested change
| - 내 경우 최근에는 테스트 코드를 내 이득을 위해서 작성한다 에 취중 되어있다. 과거의 무작정 테스트 코드 부터 작성하던 습관에서 벗어나서 좀 더 실용적인 관점에서 접근하는 것이다. 내가 생각했을 때, 가장 중요한 것은 현재 내 상황에서, 내가 테스트해야하는 이유는 무엇이고, 자동화된 테스트가 왜 필요한가에 대해서 스스로 답을 할 수 있어야 한다는 것이다. 내가 작업하는 기능이 매우 간단하고, 버그가 좀 나도 핫픽스하면되고, 나혼자 유지보수를 하며, 추후 수정가능성도 높지 않다면 나는 과감하게 테스트 코드를 작성하지 않는 선택을 할 것 같다. 다만, 내가 생각했을 때 어떤 부분이 매우 복잡하고 제대로된 자동화 테스트를 만들지 않으면 테스트하기 매우 곤란한 상황이면서, 나 외 내 동료들도 다같이 꼼꼼하게 봐야하는, 문제가 생기면 큰일 나는 코드라면, 테스트 코드를 오히려 엄청 빡빡하게 모든 경우의수를 꼼꼼이 따져서 작성하지 않을까 생각된다 이렇듯 내 상황과 의도에 따라서 테스트 코드를 작성할 수 있어야 한다고 생각한다 | |
| - 내 경우 최근에는 테스트 코드를 내 이득을 위해서 작성한다 에 치중 되어있다. 과거의 무작정 테스트 코드 부터 작성하던 습관에서 벗어나서 좀 더 실용적인 관점에서 접근하는 것이다. 내가 생각했을 때, 가장 중요한 것은 현재 내 상황에서, 내가 테스트해야하는 이유는 무엇이고, 자동화된 테스트가 왜 필요한가에 대해서 스스로 답을 할 수 있어야 한다는 것이다. 내가 작업하는 기능이 매우 간단하고, 버그가 좀 나도 핫픽스하면되고, 나혼자 유지보수를 하며, 추후 수정가능성도 높지 않다면 나는 과감하게 테스트 코드를 작성하지 않는 선택을 할 것 같다. 다만, 내가 생각했을 때 어떤 부분이 매우 복잡하고 제대로된 자동화 테스트를 만들지 않으면 테스트하기 매우 곤란한 상황이면서, 나 외 내 동료들도 다같이 꼼꼼하게 봐야하는, 문제가 생기면 큰일 나는 코드라면, 테스트 코드를 오히려 엄청 빡빡하게 모든 경우의수를 꼼꼼히 따져서 작성하지 않을까 생각된다 이렇듯 내 상황과 의도에 따라서 테스트 코드를 작성할 수 있어야 한다고 생각한다 |
| # 6장 | ||
|
|
||
| - 논의 주제 | ||
| - 누구라 보안이 중요하다고 하지만, 생각외로 각 회사마다 사각지대가 있고, 정말 말도 안되게 처리되어있는 경우도 있는 것 같습니다. 보안과 관련된 본인의 인식과 그 인식을 만들어준 사건이 있다면 공유해보면 좋을거 같습니다 |
Contributor
There was a problem hiding this comment.
'누구라'는 '누구나'의 오타로 보입니다.
Suggested change
| - 누구라 보안이 중요하다고 하지만, 생각외로 각 회사마다 사각지대가 있고, 정말 말도 안되게 처리되어있는 경우도 있는 것 같습니다. 보안과 관련된 본인의 인식과 그 인식을 만들어준 사건이 있다면 공유해보면 좋을거 같습니다 | |
| - 누구나 보안이 중요하다고 하지만, 생각외로 각 회사마다 사각지대가 있고, 정말 말도 안되게 처리되어있는 경우도 있는 것 같습니다. 보안과 관련된 본인의 인식과 그 인식을 만들어준 사건이 있다면 공유해보면 좋을거 같습니다 |
| - 누구라 보안이 중요하다고 하지만, 생각외로 각 회사마다 사각지대가 있고, 정말 말도 안되게 처리되어있는 경우도 있는 것 같습니다. 보안과 관련된 본인의 인식과 그 인식을 만들어준 사건이 있다면 공유해보면 좋을거 같습니다 | ||
| - 내 생각 | ||
| - 보안과 관련된 내 생각은 책에서 정확히 제시를 해주고 있다. 첫째로는 위협모델을 검토하는 것이다. 개발자라면 본인의 설계에서 보안적으로 문제가 될 수있는 부분을 스스로 생각해서 어떤 문제가 발생할 수 있을지 미리 인지하고 대처할 수 있어야한다. 둘째로, 시스템 암호 및 중요한 값들은 별도의 서비스로 관리하는 것이다. 요즘은 이런 SaaS 서비스들 좋은것들이 쓰기 좋게 되어있기 때문에 안쓸 이유가 없다. 특히나 운영환경이라면 적극적으로 활용해야한다 세번째는 최소한의 권한만 주는 것이다. 작은 회사는 예외이겠지만 회사 사이즈가 크면 클 수록 권한의 오남용으로 생길 문제의 영향도가 커진다 불필요한 권한은 절대 부여해선 안된다. | ||
| - 사실 위 내용에 대해서만 평소에 생각하고 개발하더라도, 사실 개발자가 신경써야할 보안적인 요소는 그렇게 많지는 않다고 생각한다. 책에 나온 XSS 나, SQL 인젝션 경우도 FE 프레임워크가 변변치 않았던 시절이나, ORM을 사용하지 않고, 보안에 취약할수밖에 없었던 시절에는 신경써야할 중요한 보안 위협이였지만, 요즘 세상에서 최신 웹 프레임워크 환경에서 개발하는 과정에서는 사실 위 보안 문제에 대해서는 이미 패치가 되어있는 경우가 대부분이기 때문에, 특히나 내가 보안에 잘 모르고 신경을 덜 쓰고 싶다면, 가능한 많은 사람들이 사용하는 범용적인 웹 프레임워크를 사용하도록 하자ㄹ |
Contributor
There was a problem hiding this comment.
문장 끝에 오타로 보이는 'ㄹ'이 포함되어 있습니다.
Suggested change
| - 사실 위 내용에 대해서만 평소에 생각하고 개발하더라도, 사실 개발자가 신경써야할 보안적인 요소는 그렇게 많지는 않다고 생각한다. 책에 나온 XSS 나, SQL 인젝션 경우도 FE 프레임워크가 변변치 않았던 시절이나, ORM을 사용하지 않고, 보안에 취약할수밖에 없었던 시절에는 신경써야할 중요한 보안 위협이였지만, 요즘 세상에서 최신 웹 프레임워크 환경에서 개발하는 과정에서는 사실 위 보안 문제에 대해서는 이미 패치가 되어있는 경우가 대부분이기 때문에, 특히나 내가 보안에 잘 모르고 신경을 덜 쓰고 싶다면, 가능한 많은 사람들이 사용하는 범용적인 웹 프레임워크를 사용하도록 하자ㄹ | |
| - 사실 위 내용에 대해서만 평소에 생각하고 개발하더라도, 사실 개발자가 신경써야할 보안적인 요소는 그렇게 많지는 않다고 생각한다. 책에 나온 XSS 나, SQL 인젝션 경우도 FE 프레임워크가 변변치 않았던 시절이나, ORM을 사용하지 않고, 보안에 취약할수밖에 없었던 시절에는 신경써야할 중요한 보안 위협이였지만, 요즘 세상에서 최신 웹 프레임워크 환경에서 개발하는 과정에서는 사실 위 보안 문제에 대해서는 이미 패치가 되어있는 경우가 대부분이기 때문에, 특히나 내가 보안에 잘 모르고 신경을 덜 쓰고 싶다면, 가능한 많은 사람들이 사용하는 범용적인 웹 프레임워크를 사용하도록 하자 |
jongfeel
approved these changes
Apr 16, 2026
| # 4장 | ||
|
|
||
| - 논의 주제 | ||
| - 저도 TDD를 예찬하고, 테스트코드를 어떻게 하면 빡빡하게 잘 작성할 수 있을까에 대해서 과거에 집착을 많이 했던 사람의 입장에서 지금 돌이켜 생각해보면, 테스트코드 작성의 너무 좋은 면만 바라본 것은 아닐까 생각됩니다. 분명히 상황에 따라서 내 의도를 정확히 확인해보는 용도로써, 실용적으로 활용했어야 하는 도구였는데, 원론적으로만 바라보고 어떻게 되든 지키려고 했었던 것 같습니다. 돌이켜보면, 잘못된 테스트코드 작성, 의도에 맞지 않는 테스트코드 작성, 불필요한 테스트 코드 작성으로 인해서 병목이되는 부분들이 많았었는데요. 테스트 코드 작성에 대한 단점은 없었는지에 대해서 말해보면 좋을것 같습니다 |
Member
There was a problem hiding this comment.
예전에 academic conference에서 테스트 관련 논의 주제 얘기하면서 코드 커버리지 한참 얘기했던 기억이 나네요.
코드 커버리지 달성을 위해 불필요한 테스트 코드를 작성했던 기억이 나는데, 돌이켜 보면 그 테스트 코드가 그렇게 중요했을까? 라는 생각이 들었습니다.
메소드 하나 테스트 커버리지 채우는데 드는 노력 보다는 우선 happy case 하나에 대한 테스트 코드를 빠르게 작성하고 의도대로 동작하는지 확인이 된 후에, 이후 예외 케이스에서 실패가 되면 보완하는 테스트 코드를 그때 추가해도 되지 않나 하는 생각입니다.
| # 6장 | ||
|
|
||
| - 논의 주제 | ||
| - 누구라 보안이 중요하다고 하지만, 생각외로 각 회사마다 사각지대가 있고, 정말 말도 안되게 처리되어있는 경우도 있는 것 같습니다. 보안과 관련된 본인의 인식과 그 인식을 만들어준 사건이 있다면 공유해보면 좋을거 같습니다 |
Member
There was a problem hiding this comment.
책에서 나오는 사례인 암호를 소스코드에 적기였습니다.
정확히는 암호 문자열 자체를 코드에 적은 건 아니었고 JWT secret에 expires in 값을 을 설정 파일에서 읽어와서 적용하는 방식인데 코드 상에 대충 30d 인 한 달로 하드코딩해 두고 개발했다가 그걸 그대로 배포할 뻔했던 경험이 있었습니다. 코드리뷰에서 걸려서 다행이었지만요.
그래서 설정 파일을 개발 환경에서만 로드하는 방법으로 변경해서 했었는데, 그런 부분들에 대해 인식을 잘 하고 개발하는 게 좋을 거 같긴 합니다.
dhlee3994
approved these changes
Apr 16, 2026
| # 4장 | ||
|
|
||
| - 논의 주제 | ||
| - 저도 TDD를 예찬하고, 테스트코드를 어떻게 하면 빡빡하게 잘 작성할 수 있을까에 대해서 과거에 집착을 많이 했던 사람의 입장에서 지금 돌이켜 생각해보면, 테스트코드 작성의 너무 좋은 면만 바라본 것은 아닐까 생각됩니다. 분명히 상황에 따라서 내 의도를 정확히 확인해보는 용도로써, 실용적으로 활용했어야 하는 도구였는데, 원론적으로만 바라보고 어떻게 되든 지키려고 했었던 것 같습니다. 돌이켜보면, 잘못된 테스트코드 작성, 의도에 맞지 않는 테스트코드 작성, 불필요한 테스트 코드 작성으로 인해서 병목이되는 부분들이 많았었는데요. 테스트 코드 작성에 대한 단점은 없었는지에 대해서 말해보면 좋을것 같습니다 |
Contributor
There was a problem hiding this comment.
비즈니스적으로 자주 변경되는 부분까지도 메서드 호출 횟수나 구체적인 값 같은 상세 구현을 검증하다 보니 작은 변화에도 수정해야 할 테스트 코드가 많아졌던 경험이 있습니다.
그 뒤로는 핵심 의도 위주로 테스트하고 상세 구현을 검증하는 부분은 줄여서 테스트를 작성하고 있습니다.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #643